Plan exclusive --adapter targeting for installation commands - #540
Plan exclusive --adapter targeting for installation commands#540eXamadeus wants to merge 1 commit into
--adapter targeting for installation commands#540Conversation
|
Bugbot is paused — on-demand spend limit reachedBugbot uses usage-based billing for this team and has hit its on-demand spend limit. A team admin can raise the spend limit in the Cursor dashboard, or wait for the next billing cycle to continue. |
This stack of pull requests is managed by Graphite. Learn more about stacking. |
|
Warning Review limit reached
Next review available in: 56 minutes Limit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?Wait for the limit to reset, then comment An organization admin can change what happens after included review limits in Billing. How do review limits work?CodeRabbit enforces per-developer PR review limits within each organization. For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (8)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
beb94b4 to
799e322
Compare
50b4b8e to
6c71c97
Compare
Bugbot is paused — on-demand spend limit reachedBugbot uses usage-based billing for this team and has hit its on-demand spend limit. A team admin can raise the spend limit in the Cursor dashboard, or wait for the next billing cycle to continue. |
6c71c97 to
9cdacdf
Compare
799e322 to
71610cd
Compare
Bugbot is paused — on-demand spend limit reachedBugbot uses usage-based billing for this team and has hit its on-demand spend limit. A team admin can raise the spend limit in the Cursor dashboard, or wait for the next billing cycle to continue. |
💡 Codex Reviewfacets/openspec/changes/filter-installation-by-adapter/design.md Lines 104 to 105 in beb94b4 When a target adapter and a purge adapter resolve an asset to the same physical path, the required pre-mutation planning can mark the target install as Line 56 in beb94b4 When a repository facet introduces or changes an MCP declaration, or an existing native entry requires takeover, every routine AGENTS.md reference: scripts/AGENTS.md:L1-L2 ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
71610cd to
4579b17
Compare
Adds the OpenSpec change `filter-installation-by-adapter` — proposal, design, delta specs, and task plan. Planning artifacts only; no product code changes, so `facet add`, `facet install`, and `facet remove` behave exactly as before. Explicit targets are exclusive: each named adapter receives the complete desired project state and every other installed capable adapter is purged of receipt-owned assets and MCP entries in the same transaction. That is what keeps the machine-local receipt adapter-agnostic at schema `0.4` — no adapter dimension, no migration. The plan also retires the adapter-agnostic removal-refinement fast path globally rather than teaching it target and purge roles. Every removal resolves the complete remaining target state from cache or source before mutating, so a cold-cache removal without source access fails unchanged instead of completing receipt-only. Also gitignores the local OpenSpec archive and `adversarial/` review artifacts.
4579b17 to
79bf40e
Compare
--adapter exclusive targeting spec for installation commands--adapter targeting for installation commands
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 79bf40ecba
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| There is no deferred reconciliation state and no adapter-specific catch-up metadata. A later operation simply applies its own target/purge partition. An unfiltered operation targets every installed materialization-capable adapter and purges none. | ||
|
|
||
| The existing adapter-agnostic removal-refinement path SHALL be disabled globally rather than expanded to prove role-aware target/purge transitions. Every removal SHALL resolve complete remaining target state before mutation, using cached content when available and source/network resolution on cache miss. This intentionally changes the execution strategy for unfiltered removal: a cold-cache invocation without source availability SHALL fail unchanged instead of completing through receipt-only refinement. Target selection, placement postconditions, and receipt-driven deletion authority remain unchanged. |
There was a problem hiding this comment.
Replace the canonical removal-refinement requirement
Disabling refinement here does not update the existing Removing a facet uninstalls it requirement in openspec/specs/installation/spec.md, which still requires fully tracked removal-only operations to refine locally without fetching and includes cold-cache offline-success scenarios. Applying this delta therefore leaves the normative specification requiring the exact path this design and task 4.5 remove, so implementation and acceptance tests cannot satisfy both; add a MODIFIED replacement for that requirement and its affected scenarios.
Useful? React with 👍 / 👎.
|
|
||
| ### Requirement: Unsupported MCP adapters are reported completely | ||
|
|
||
| When active MCP declarations exist and any target adapter declares no MCP support, the command SHALL fail before prompting or mutation. When the receipt owns an effective MCP identity requiring deletion from a purge adapter and that adapter cannot safely plan the removal, the command SHALL also fail before prompting or mutation. One error SHALL identify every affected adapter and SHALL give actionable remediation. |
There was a problem hiding this comment.
Validate MCP cleanup capability for target adapters
When there are no active MCP declarations but the receipt owns a stale server that must be deleted from a target adapter—for example after removing or omitting the last declaration—neither condition here requires that target to support planning the deletion; cleanup capability is checked only for purge adapters. The modified requirement previously covered receipt-owned identities needing deletion on every selected adapter, and without that gate the operation can drop the receipt claim while leaving the native entry orphaned. Require cleanup support for targets whenever receipt-owned MCP deletion is pending.
Useful? React with 👍 / 👎.
Greptile SummaryThe PR adds planning artifacts for exclusive
Confidence Score: 5/5The planning-only PR appears safe to merge. No blocking failure remains. Reviews (2): Last reviewed commit: "Plan exclusive `--adapter` targeting for..." | Re-trigger Greptile |

Why
Projects with multiple installed adapters currently materialize every facet into every compatible adapter. There is no way to say "this project's Facet-managed state belongs in OpenCode only" for a given invocation without hand-deleting files afterwards.
This PR is the plan for that feature, not the feature: it adds the OpenSpec change
filter-installation-by-adapter(proposal, design, delta specs, task plan). No product code changes —facet add,facet install, andfacet removebehave exactly as they do today.Details
The central decision is that explicit
--adaptertargets are exclusive, not additive. Every named adapter receives the complete desired project state, and every other installed materialization-capable adapter is purged of all receipt-owned assets and MCP entries in the same atomic operation.That choice is what keeps the rest of the design small. Leaving non-target adapters untouched would require adapter-scoped receipt history so later filtered updates and removals could still prove what they were allowed to delete. Because no successful operation leaves project-owned state behind in a discoverable non-target adapter, the machine-local receipt stays adapter-agnostic at schema
0.4— no adapter dimension, no version bump, no migration.Constraints worth reviewing:
One deliberate behavioral regression outside the new flag: the adapter-agnostic removal-refinement fast path is retired globally rather than taught target/purge roles. Every removal will resolve complete remaining target state from cache or source before mutating, so a cold-cache
facet removewith no source access will fail unchanged instead of completing receipt-only. Design decision 7 records the trade-off.The task plan sequences this across ten phases: CLI parsing and flag strictness, engine scope migration and asset purge, MCP purge and frozen mode, scope reporting and failure remedies, then integration, documentation, and release metadata.
Verification
Nothing to run — the diff is planning artifacts plus two
.gitignoreentries. All four artifacts are complete perbun openspec status, and each went through independent adversarial authoring, comparison review, and reconciliation.