You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
CI: gate main on openspec validate --all --strict #105
No workflow runs openspec validate. Add one so a spec that fails --strict can't reach main.
What exists today
There are two OpenSpec workflows, and neither validates spec content:
pr-check-openspec.yml: the archive gate. Checks that a change directory got archived, on the tip PR of a stack only.
openspec-rot.yml: a daily sweep of main for unarchived change debris.
Both are about change lifecycle. Nothing checks that the specs in openspec/specs/ are well-formed.
Why it matters
Because nothing enforces it, spec rot accumulates silently and only gets found by hand. Three examples turned up recently, all pre-existing on main:
openspec/specs/cli-help/spec.md carried an orphaned duplicate of a requirement that had lost both its ### Requirement: header and its opening code fence. A documentation template parsed as real ## Goal / ## Preconditions headings, which ended the Requirements section and hid every requirement below it from the parser. We only found it because it made an unrelated openspec archive fail.
openspec/specs/cli-rules/spec.md fails --strict with roughly 18 errors: requirements with no #### Scenario: block, and requirements whose text contains neither SHALL nor MUST.
openspec/specs/cli-update-engine/spec.md fails because it has zero requirements. It's a tombstone for a decommissioned capability, retained "for historical reference".
Suggested shape
A job running pnpm openspec validate --all --strict on pull requests and on pushes to main.
It has to be repo-wide (--all). The failures above live in specs that a given PR doesn't touch, so a changed-files-only check would never have surfaced them.
Blocked until the specs are clean
Turning the gate on while cli-rules and cli-update-engine fail would make it red from day one, which is how a check gets ignored. A cleanup PR addressing both is in flight on top of the current stack. Land that first, then add the gate.
Follow-up from the cleanup in #106: --strict alone isn't enough. It misses a whole class of rot.
A second ## silently truncates a spec
Anything after a second ## heading inside the requirements section stops being parsed as a requirement. What's below it isn't invalid, it's invisible. Measured across openspec/specs/:
Spec
Requirements in file
Visible to the parser
--strict verdict
cli-rules
33
23
failing (for unrelated reasons)
infrastructure
20
1
passing
skills
7
1
passing
infrastructure and skills were green the whole time. 35 requirements went unread while the validator reported success. That's worse than a red check: a passing gate is an active claim that the spec was read.
Same shape as the cli-help defect found earlier, where a lost opening code fence turned a documentation template's ## Goal / ## Preconditions into real headings and hid every requirement below them.
So the gate wants two checks
pnpm openspec validate --all --strict (the original ask)
Every ### Requirement: sits under ## Requirements
The second is a few lines and catches what the first structurally cannot:
#106 brings all 23 specs to 0 failures with every requirement visible, so both checks are green today and the gate can go on without landing red.
Topical grouping inside a requirements section still works, just as a bold lead-in line rather than a heading. #106 converts ## API Contract, ## Build Tooling, ## Distribution and friends that way.
Activity
theCodeDrift commentedon Aug 15, 2026
Follow-up from the cleanup in #106:
--strictalone isn't enough. It misses a whole class of rot.A second
##silently truncates a specAnything after a second
##heading inside the requirements section stops being parsed as a requirement. What's below it isn't invalid, it's invisible. Measured acrossopenspec/specs/:--strictverdictcli-rulesinfrastructureskillsinfrastructureandskillswere green the whole time. 35 requirements went unread while the validator reported success. That's worse than a red check: a passing gate is an active claim that the spec was read.Same shape as the
cli-helpdefect found earlier, where a lost opening code fence turned a documentation template's## Goal/## Preconditionsinto real headings and hid every requirement below them.So the gate wants two checks
pnpm openspec validate --all --strict(the original ask)### Requirement:sits under## RequirementsThe second is a few lines and catches what the first structurally cannot:
#106 brings all 23 specs to 0 failures with every requirement visible, so both checks are green today and the gate can go on without landing red.
Topical grouping inside a requirements section still works, just as a bold lead-in line rather than a heading. #106 converts
## API Contract,## Build Tooling,## Distributionand friends that way.docs(openspec): make every spec pass validate --all --strict
docs(openspec): make every spec pass validate --all --strict
docs(openspec): make every spec pass validate --all --strict
docs(openspec): make every spec pass validate --all --strict
ci: gate main on spec validity and requirement visibility