chore(openspec): archive the two changes the stack landed - #163
Merged
Conversation
`main` went red on the unarchived-changes check in validate.yml. A change is archived exactly once, on whichever PR is the tip of the stack, and this stack merged forward — #161 was the tip and carried no OpenSpec change of its own, so nothing archived #155's and #156's. That is the documented consequence of a forward-merging stack, not a surprise: CLAUDE.md says such a stack leaves `main` red until its final slice archives. The slice was missing. Archiving applied both deltas to the permanent specs, which is the point of the step rather than a side effect: `cli-rule-routing` gains the requirement that the routing recipe states each engine's reach derived from the pinned versions rather than transcribed, and `cli-rule-validation` gains the ast-grep fixture-bucket scenario that its Vale counterpart already had. `openspec validate --specs --strict` passes, 24 items. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Cyga14bww8rmazH2XrF8ms
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
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.
mainis red onCheck for unarchived OpenSpec changes on main:Why it happened
A change is archived exactly once, on whichever PR is the tip of the stack. This stack merged forward — #155 → #156/#157 → #161 — and #161 was the tip but carried no OpenSpec change of its own, so nothing archived #155's or #156's.
That is the documented consequence rather than a surprise.
CLAUDE.mdsays a forward-merging stack leavesmainred until its final slice archives, and that the archive check lives onmainprecisely because a PR-time gate cannot tell an in-flight change directory from a forgotten one. The signal worked; the slice was missing.What archiving actually did
The rename is the visible part, but the point of the step is that it applies each delta to the permanent specs:
cli-rule-routing/spec.md— gains Route states each local engine's reach from the pinned engine versions, whose normative core is that the statements are derived from the pinned versions rather than transcribed, and pinned by tests that invoke the engine binaries.cli-rule-validation/spec.md— the fixture-bucket requirement gains its ast-grep scenario, so the spec no longer specifies the Vale rule and stays silent about sg. That silence is what made the sg gap look correct.pnpm openspec validate --specs --strict→ 24 passed, 0 failed.No source changes; specs and the archive move only.
One thing worth a second opinion
The archived
cli-rule-routingrequirement describes converter-dependent formats as failing "because Vale delegates their parse to an external converter this CLI does not ship." That is still accurate about the recipe's content, so it is not stale.But it predates two later decisions on #157/#161: that we do not support any format needing an external program (rather than merely lacking the converter), and that
.mdxbecame supported in Vale 3.18. Neither contradicts the requirement as written, so I have not touched it here — but if the no-external-programs policy should be specified rather than just implemented, that is a follow-up delta rather than something to fold into an archive PR.