fix(schemas): honor canonical root selection - #1616
Merged
Merged
Conversation
Contributor
📝 WalkthroughWalkthroughThe ChangesSchema root selection
Estimated code review effort: 3 (Moderate) | ~25 minutes Sequence Diagram(s)sequenceDiagram
participant CLI as schemas CLI
participant Resolver as resolveRootForCommand
participant Lister as listSchemasWithInfo
CLI->>Resolver: resolve root from store and project context
Resolver-->>CLI: resolved root or diagnostics
CLI->>Lister: list schemas from resolved root
Lister-->>CLI: schema results
Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@skills/openspec-onboard/SKILL.md`:
- Line 14: Remove view from the shared store-scoped command list in the
generator source while retaining schemas, then regenerate the committed skill
artifacts. Apply the resulting change to skills/openspec-onboard/SKILL.md (line
14), skills/openspec-propose/SKILL.md (line 28),
skills/openspec-sync-specs/SKILL.md (line 16),
skills/openspec-update-change/SKILL.md (line 14), and
skills/openspec-verify-change/SKILL.md (line 14); all listed files require the
same generated update.
In `@src/commands/workflow/schemas.ts`:
- Around line 25-29: Update the resolveRootForCommand options in schemasCommand
to set allowImplicitRoot: true, enabling schema discovery without an OpenSpec
root while preserving strict handling of explicit store failures.
In `@test/commands/schemas.test.ts`:
- Around line 117-132: Strengthen the successful JSON assertions in the schemas
CLI test by validating the complete entry for store-only, including its
documented description, artifacts, and source fields and their expected values.
Keep the existing exit, stderr, inclusion, and exclusion assertions, and use the
parsed schema result from parseSchemas rather than only checking the name.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 6e375e19-a242-4f60-b1cf-8b329573ab96
📒 Files selected for processing (29)
docs/agent-contract.mddocs/cli.mddocs/stores-beta/user-guide.mdopenspec/changes/fix-schemas-root-selection/.openspec.yamlopenspec/changes/fix-schemas-root-selection/design.mdopenspec/changes/fix-schemas-root-selection/proposal.mdopenspec/changes/fix-schemas-root-selection/specs/schema-resolution/spec.mdopenspec/changes/fix-schemas-root-selection/tasks.mdskills/openspec-apply-change/SKILL.mdskills/openspec-archive-change/SKILL.mdskills/openspec-bulk-archive-change/SKILL.mdskills/openspec-continue-change/SKILL.mdskills/openspec-explore/SKILL.mdskills/openspec-ff-change/SKILL.mdskills/openspec-new-change/SKILL.mdskills/openspec-onboard/SKILL.mdskills/openspec-propose/SKILL.mdskills/openspec-sync-specs/SKILL.mdskills/openspec-update-change/SKILL.mdskills/openspec-verify-change/SKILL.mdsrc/cli/index.tssrc/commands/workflow/schemas.tssrc/core/completions/command-registry.tssrc/core/templates/workflows/propose.tssrc/core/templates/workflows/store-selection.tstest/commands/schemas.test.tstest/core/completions/command-registry.test.tstest/core/templates/propose.test.tstest/core/templates/skill-templates-parity.test.ts
alfred-openspec
requested changes
Aug 11, 2026
alfred-openspec
left a comment
alfred-openspec
left a comment
Collaborator
There was a problem hiding this comment.
The root-selection implementation and tests are sound, but the edited Stores guide still says view has no --store support even though it already does. Remove view from that cwd-only sentence, then this is ready.
Collaborator
|
@alfred-openspec addressed: removed |
view already accepts --store <id> (registered in src/cli/index.ts), so listing it among the commands that act on the current directory only was incorrect. Remove it; templates and the deprecated noun forms remain. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
clay-good
force-pushed
the
fix/schemas-root-selection
branch
from
August 11, 2026 21:25
200198f to
cb4f468
Compare
Collaborator
|
Rebased onto current
|
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@skills/openspec-apply-change/SKILL.md`:
- Line 14: Update the store-selection guidance in the skill generator so --store
<id> is appended only after a registered standalone store is selected or an
existing command hint establishes it. Keep commands targeting the nearest local
openspec/ root unscoped, remove the blanket instruction that rewrites every
example, and regenerate SKILL.md from the updated generator.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: e3fb1a71-0a65-4fcd-9d91-c949762294d1
📒 Files selected for processing (5)
docs/cli.mdskills/openspec-apply-change/SKILL.mdsrc/cli/index.tssrc/core/completions/command-registry.tstest/core/templates/skill-templates-parity.test.ts
🚧 Files skipped from review as they are similar to previous changes (4)
- src/core/completions/command-registry.ts
- docs/cli.md
- src/cli/index.ts
- test/core/templates/skill-templates-parity.test.ts
| Implement tasks from an OpenSpec change. | ||
|
|
||
| **Store selection:** If the user names a store (a store is a standalone OpenSpec repo registered on this machine) or the work lives in one, run `openspec store list --json` to discover registered store ids, then pass `--store <id>` on the commands that read or write specs and changes (`new change`, `status`, `instructions`, `list`, `show`, `validate`, `archive`, `doctor`, `context`, `view`). Once selected, treat `--store <id>` as sticky for the rest of the workflow. Every unscoped example of those commands below is shorthand: before running it, append the flag. For example, run `openspec status --change "<name>" --json --store "<id>"`, not the unscoped form shown below. Other commands do not take the flag. Hints printed by commands already carry the flag; keep it on follow-ups. Without a store, commands act on the nearest local `openspec/` root. | ||
| **Store selection:** If the user names a store (a store is a standalone OpenSpec repo registered on this machine) or the work lives in one, run `openspec store list --json` to discover registered store ids, then pass `--store <id>` on the commands that read or write specs and changes (`new change`, `status`, `instructions`, `list`, `show`, `validate`, `archive`, `doctor`, `context`, `schemas`, `view`). Once selected, treat `--store <id>` as sticky for the rest of the workflow. Every unscoped example of those commands below is shorthand: before running it, append the flag. For example, run `openspec status --change "<name>" --json --store "<id>"`, not the unscoped form shown below. Other commands do not take the flag. Hints printed by commands already carry the flag; keep it on follow-ups. Without a store, commands act on the nearest local `openspec/` root. |
Contributor
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Keep --store <id> conditional.
The instruction to append --store <id> to every unscoped example conflicts with the local-root behavior described later on the same line. Agents can pass an unbound store identifier and fail workflows that do not use a registered standalone store.
Append the flag only after a registered standalone store is selected or a command hint establishes the store. Keep local-root examples unscoped. Update the skill generator and regenerate this file.
Based on learnings: generated workflow skills must use --store <id> conditionally and must keep default local-root examples free of an unbound placeholder.
🧰 Tools
🪛 LanguageTool
[style] ~14-~14: It’s more common nowadays to write this noun as one word.
Context: ...ec change. Store selection: If the user names a store (a store is a standalone OpenSp...
(RECOMMENDED_COMPOUNDS)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@skills/openspec-apply-change/SKILL.md` at line 14, Update the store-selection
guidance in the skill generator so --store <id> is appended only after a
registered standalone store is selected or an existing command hint establishes
it. Keep commands targeting the nearest local openspec/ root unscoped, remove
the blanket instruction that rewrites every example, and regenerate SKILL.md
from the updated generator.
Source: Learnings
alfred-openspec
approved these changes
Aug 11, 2026
alfred-openspec
left a comment
alfred-openspec
left a comment
Collaborator
There was a problem hiding this comment.
The Stores guide now correctly removes view from the cwd-only, no-store list. Root-selection code remains unchanged from the reviewed head; fresh build, 59 schemas, completion, template, and parity tests, strict change validation, and the exact-head hosted matrix pass.
Stanley00
pushed a commit
to stanley-fork/OpenSpec
that referenced
this pull request
Aug 12, 2026
…ion-AI#1640) Six user-facing fixes merged after v1.8.0 without a changeset, so they would ship in v1.9.0 with no changelog entry and their authors uncredited. All are patch fixes; the release target stays at 1.9.0. Covers: Fission-AI#1637, Fission-AI#1607, Fission-AI#1632, Fission-AI#1616, Fission-AI#1612, Fission-AI#1523. Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
clay-good
added a commit
that referenced
this pull request
Aug 19, 2026
Both conventions exist in this repo's history, but the two most recent behavior fixes (#1609, #1616) carry an `openspec/changes/` delta rather than editing the main spec in place, which is also the workflow this project asks of everyone else. The delta reproduces the whole Capability Retirement requirement, so archiving it drops no scenario. Verified by archiving into a scratch copy of `openspec/`: the merged main spec differs from today's by exactly the three added bullets.
pull Bot
pushed a commit
to ben-vargas/ai-openspec
that referenced
this pull request
Aug 19, 2026
* fix(archive): never dead-end a capability retirement A change whose delta removes the last requirement a capability has rebuilds the main spec empty, which can never validate. Archive already knows retiring is the fix and names the `retire_capabilities: true` marker that authorises deleting the spec - but only when the marker is the single thing missing. If the spec also holds a line the merge cannot account for (a `## Notes` section, a comment under a requirement - both ordinary), that hint was suppressed, and the hint that names such lines only spoke to authors who had already set the marker. Neither fired, so the archive aborted on "Spec must have at least one requirement" with no guidance at all: the exact dead end the marker exists to close. Archive now names the blocking content in that case. It deliberately does not name the marker there - adding it would not have let this run through, and the marker is only ever named when it really is the one thing missing. Once the content is resolved, the rerun names the marker. Closes Fission-AI#1696 * fix(archive): harden the blocked-retirement abort Three follow-ups to the same message. The blocking lines are authored spec content printed verbatim to a terminal, so they now get the treatment `describeChangeName` already gives a change directory name: control characters replaced, since a raw CR could forge a line of its own and an ESC could redraw the screen. Each line is bounded too - one very long line would push the way out of the abort off the reader's screen - and the cut counts code points so it can never leave half a surrogate pair. Both the declared and undeclared branches share the helper, so the marker-declared abort that shipped with Fission-AI#1484 is hardened with it. The wording no longer claims retiring is "the way through". It is not, in the one case this fires on that has a live requirement hiding in a second `## Requirements` section: merging the sections fixes that spec without deleting anything. `openspec/specs/cli-archive/spec.md` records the behavior change - the blocking lines are named whether or not the marker was declared, and the marker is still named only when adding it would let the archive through. * refactor(archive): drop a helper the revised wording made single-use The marker sentence is said in one place again, so it goes back inline rather than through a function that now has one caller. Also corrects the comment above `emptiedByThisRun`: retiring is not the only fix in every case it covers, which is exactly why the message stopped saying so. * docs(openspec): record the change as a delta, not a direct spec edit Both conventions exist in this repo's history, but the two most recent behavior fixes (Fission-AI#1609, Fission-AI#1616) carry an `openspec/changes/` delta rather than editing the main spec in place, which is also the workflow this project asks of everyone else. The delta reproduces the whole Capability Retirement requirement, so archiving it drops no scenario. Verified by archiving into a scratch copy of `openspec/`: the merged main spec differs from today's by exactly the three added bullets. * fix(archive): report an unhonorable marker alongside the blocking content An author who set `retire_capabilities: yes-please` believes they have authorised the deletion. Clearing the blocking content first, only to then learn the marker was never read, is two aborts for one mistake. The abort still never invites the marker to be added while content blocks the retirement - it only reports the one already there. The spec delta records that distinction, which the old bullet ("say nothing about the marker") did not draw. * style(archive): use one sentence for an unhonorable marker in both aborts * fix(metadata): strip control characters from an unhonorable marker reason Every reason a boolean change-metadata marker gives quotes something the author wrote - a schema name, a parser message carrying one, a filesystem error carrying a path - and two commands print it straight to a terminal. A schema name carrying a raw ESC, with the marker set, put that ESC on screen through `openspec archive`; `openspec validate` prints the same reason. Fixed at the source in `readBooleanMarker` rather than at either call site, so no consumer has to remember. The reason still quotes the name recognisably; only control characters are replaced. Reported by CodeRabbit on Fission-AI#1699. Pre-existing on main, and this PR would have added a second place it reaches the terminal. * test(archive): fix a comment left behind by the reworded abort
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
openspec schemasthrough the canonical OpenSpec root-selection precedence.--store <id>and the standard hidden--store-pathrejection path while preserving successful human output and the bare JSON array.Root cause
schemasCommand()always read schemas fromprocess.cwd(), and the command did not expose--store. As a result, schema discovery ignored an explicitly selected registered store and could disagree with the canonical root chosen by the rest of the workflow.Impact
Schema discovery now follows the same authoritative root as other root-scoped commands. Existing successful output shapes remain compatible; ambiguous registered-store environments fail closed with actionable diagnostics instead of silently reading the wrong directory.
Validation
pnpm run lintpnpm run buildpnpm test— 3,867 tests passedpnpm exec openspec validate fix-schemas-root-selection --strictgit diff --checkWindows/pwsh path behavior, including the store path containing spaces, remains gated by the repository CI matrix.
AI disclosure
Generated and verified with Codex using
gpt-5.6-solat max reasoning effort.Summary by CodeRabbit
New Features
openspec schemasnow supports--store <id>and standard project/store root selection.Bug Fixes
Documentation
Tests