Repository navigation
docs(openspec): write the Purpose for the three placeholder living specs - #296
Merged
Merged
Conversation
`community-boot-readiness`, `tenant-auth-config-surface` and `typed-response-schemas` were each born by archiving a change, which seeds `## Purpose` with the CLI's own placeholder — "TBD - created by archiving change <name>. Update Purpose after archive." None was revisited, so three capabilities have carried a TBD since they were created. This edits the living specs directly. A `## Purpose` written into a MODIFIED delta would silently do nothing: the CLI reads a Purpose only when the capability is created, so a change proposal is the wrong instrument here. Green under the pinned CLI (1.8.0 — `validate --all --strict` 30 passed, 0 failed) and under 1.13.1, which since 1.11.0 rejects the placeholder outright. That is the point of landing this on its own: it carries no decision about the pin, and it is what makes a later pin bump a one-line change per repo rather than a PR that is red on arrival.
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
1 participant
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.
What
Three living specs carry the CLI's birth placeholder at line 4:
openspec/specs/community-boot-readiness/spec.mdopenspec/specs/tenant-auth-config-surface/spec.mdopenspec/specs/typed-response-schemas/spec.mdEach was created by archiving a change and never revisited. This writes a real Purpose for each, from the requirements the spec actually holds.
Why now
The OpenSpec validator has rejected a placeholder
## Purposesince 1.11.0 (upstream #1671). Under the CLI version this repo pins today (1.8.0) these three pass; under 1.13.1 they are 3 of this repo's 30 items failing, and theOpenSpec Validatejob is a required check that always runs with--all.So a PR that moves the pin line would be red on arrival. Landing the Purposes first makes the later pin bump a genuine one-line change.
Verified
validate --all --strict --no-interactiveGreen under both, so this PR carries no decision about the pin. It can land on its own merits.
Also run locally on the integrated branch:
python3 scripts/check-endpoint-invariants.py(all gates OK) andpython3 -m unittest discover scripts/tests(82 passed). Correction to an earlier revision of this description: I first reporteddocs_only=falsefor this change — that was a local run against an uncommitted tree. CI classified the real commit as docs-only, sobuild-and-test, coverage and the heavy lanes are legitimately SKIPPED; the ungated checks (OpenSpec Validate, and this repo's tree-scanning guards) all ran and are green.Note on the instrument
This edits the living specs directly, not through a change proposal. A
## Purposewritten into aMODIFIEDdelta silently does nothing — the CLI reads a capability's Purpose only when the capability is created, and says so itself when you try.One thing worth a second pair of eyes
community-boot-readinessholds a requirement titled "The released-image smoke asserts thedialer-engineDegraded shape as a gating leg", but that leg is stillcontinue-on-error: trueinrelease.yml— its promotion is tracked by the still-open follow-ups 3.2/6.4 in the archived2026-07-26-license-gated-engine-health-degraded. I wrote the Purpose to say the smoke leg asserts the shape without claiming it gates, so the Purpose does not inherit the overstatement. The requirement body itself is left untouched — correcting it is a separate call, not something to smuggle into a Purpose PR.