Observation-class finding, noticed while editing docs/qa/platform-checklist/areas/approvals.json for #7331. Filed unassigned, no pm:queue — for triage to grade. Nothing a product user hits; it is a QA-ledger ratchet that is currently red and, by design, has no CI job to say so.
What happens
On a clean origin/main (88154bee1), with no local edits:
$ node scripts/check-platform-checklist.mjs
check-platform-checklist: 1 problem(s)
✗ coverage.json · qa: UNCLASSIFIED — the platform has this capability (liveness ledger exists)
but the checklist neither tests nor waives it. Add items or a waiver with a reason.
Why it appeared now
packages/spec/liveness/qa.json was seeded on 2026-08-10 by #6247 / PR #7255 ("govern the QA testing domain and enforce TestSuiteSchema at the os test load site"). coverage.json's ratchet derives its universe of capabilities from exactly that set — "every metadata kind with a packages/spec/liveness/{kind}.json ledger must be mapped to at least one checklist item, or waived with a written reason" (docs/qa/platform-checklist/README.md). A new ledger therefore makes the validator red until coverage.json gains a row.
That is the ratchet working as intended: the platform grew a governed capability the checklist does not test. It is worth a card only because the validator runs on a manual cadence by maintainer decision, not in CI (README, same section), so nothing will surface this until the next release sweep or coverage-sweep run — and whoever hits it next will spend the same minutes deciding whether it is their own edit's fault. (It is not: I confirmed it reproduces with a pristine tree, before touching the approvals area file.)
What the row should say is a real question, not a formality
The qa domain is the Quality Protocol file surface — an author writes qa/*.test.json and the shipped os test command loads, validates and runs it (packages/core/src/qa/runner.ts, packages/core/src/qa/http-adapter.ts, packages/cli/src/commands/test.ts). So a genuine mapping would be a checklist item that authors a suite and drives os test against a booted app — a surface: cli item, which the approvals-area work has no business inventing on the side. A waiver would have to argue that the capability is out of the checklist's scope, which looks wrong given it is a shipped, documented CLI command.
Deliberately not patched in #7331's PR: picking between "author a real qa item" and "waive it" is a QA-ledger scoping call, and silently adding a thin item just to make the validator green would defeat the ratchet.
Evidence
Measured 2026-08-10 against origin/main 88154bee1; packages/spec/liveness/qa.json present, docs/qa/platform-checklist/coverage.json metadataKinds carries no qa key. The same command is green for every other kind.
Generated by Claude Code
Observation-class finding, noticed while editing
docs/qa/platform-checklist/areas/approvals.jsonfor #7331. Filed unassigned, nopm:queue— for triage to grade. Nothing a product user hits; it is a QA-ledger ratchet that is currently red and, by design, has no CI job to say so.What happens
On a clean
origin/main(88154bee1), with no local edits:Why it appeared now
packages/spec/liveness/qa.jsonwas seeded on 2026-08-10 by #6247 / PR #7255 ("govern the QA testing domain and enforceTestSuiteSchemaat theos testload site").coverage.json's ratchet derives its universe of capabilities from exactly that set — "every metadata kind with apackages/spec/liveness/{kind}.jsonledger must be mapped to at least one checklist item, or waived with a written reason" (docs/qa/platform-checklist/README.md). A new ledger therefore makes the validator red untilcoverage.jsongains a row.That is the ratchet working as intended: the platform grew a governed capability the checklist does not test. It is worth a card only because the validator runs on a manual cadence by maintainer decision, not in CI (README, same section), so nothing will surface this until the next release sweep or
coverage-sweeprun — and whoever hits it next will spend the same minutes deciding whether it is their own edit's fault. (It is not: I confirmed it reproduces with a pristine tree, before touching the approvals area file.)What the row should say is a real question, not a formality
The
qadomain is the Quality Protocol file surface — an author writesqa/*.test.jsonand the shippedos testcommand loads, validates and runs it (packages/core/src/qa/runner.ts,packages/core/src/qa/http-adapter.ts,packages/cli/src/commands/test.ts). So a genuine mapping would be a checklist item that authors a suite and drivesos testagainst a booted app — asurface: cliitem, which the approvals-area work has no business inventing on the side. Awaiverwould have to argue that the capability is out of the checklist's scope, which looks wrong given it is a shipped, documented CLI command.Deliberately not patched in #7331's PR: picking between "author a real
qaitem" and "waive it" is a QA-ledger scoping call, and silently adding a thin item just to make the validator green would defeat the ratchet.Evidence
Measured 2026-08-10 against
origin/main88154bee1;packages/spec/liveness/qa.jsonpresent,docs/qa/platform-checklist/coverage.jsonmetadataKindscarries noqakey. The same command is green for every other kind.Generated by Claude Code