Found while implementing #65, not caused by it, and out of scope for that PR.
What happens
project-bin/coverage-preflight.sh extract_claims does not read either of these forms:
- a fenced
```claims block
- a
claims: (note) line
A real build plan on a language learning app conversion carries 22 claims across 7 phases. coverage-preflight.sh sees zero of them.
Why it matters
Zero claims is not an error state. The script treats a plan with no claims as a lower coverage level and carries on, which is correct behaviour for a plan that genuinely predates the claims convention. So a plan that carefully records every claim gets treated identically to one that records none, and nothing anywhere says so. The failure is silent and it points the wrong way: the more carefully the plan was written, the more invisible its claims are.
The --json work in #65 had to write its own claims parser to see them, which is how this surfaced. Two parsers for one convention is the situation that produced the register waiver bug in #63, where a reader and a writer disagreed about what a character meant.
Suggested fix
Teach extract_claims the fenced block and the note-line forms, and add a fixture with a real plan shape so the two parsers cannot drift apart again. The parser in project-bin/build-plan-status.sh --json from #65 is a working reference for what the real files contain.
Worth checking whether anything else reads claims, and whether it agrees with either parser.
Found while implementing #65, not caused by it, and out of scope for that PR.
What happens
project-bin/coverage-preflight.shextract_claimsdoes not read either of these forms:```claimsblockclaims: (note)lineA real build plan on a language learning app conversion carries 22 claims across 7 phases.
coverage-preflight.shsees zero of them.Why it matters
Zero claims is not an error state. The script treats a plan with no claims as a lower coverage level and carries on, which is correct behaviour for a plan that genuinely predates the claims convention. So a plan that carefully records every claim gets treated identically to one that records none, and nothing anywhere says so. The failure is silent and it points the wrong way: the more carefully the plan was written, the more invisible its claims are.
The
--jsonwork in #65 had to write its own claims parser to see them, which is how this surfaced. Two parsers for one convention is the situation that produced the register waiver bug in #63, where a reader and a writer disagreed about what a character meant.Suggested fix
Teach
extract_claimsthe fenced block and the note-line forms, and add a fixture with a real plan shape so the two parsers cannot drift apart again. The parser inproject-bin/build-plan-status.sh --jsonfrom #65 is a working reference for what the real files contain.Worth checking whether anything else reads claims, and whether it agrees with either parser.