check:platform-checklist is red on main (coverage.json · manifest UNCLASSIFIED) and the gate is not CI-wired, so the red has no reporting channel

[claude]

Measured at origin/main @ bb006446 while running the gate for the checklist edit on #10798.

$ node scripts/check-platform-checklist.mjs
check-platform-checklist: 1 problem(s)

 ✗ coverage.json · manifest: 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.

Contract: docs/qa/platform-checklist/README.md (authoring) · RUNNER.md (execution).

Exit 1. The checklist-select self-test that runs ahead of it passes (17 cases), so this is the ledger check itself, not the harness.

It is pre-existing, not introduced by anything in flight

Verified by reverting the single file my worktree had changed (docs/qa/platform-checklist/areas/cli.json) back to bb006446 and re-running: identical single problem, identical exit 1. The problem also names coverage.json, which that change never touched. Restored afterwards; the measurement was taken from a committed state so the revert had a restore point.

Why nobody has noticed

.github/workflows/lint.yml records the reason, in a standing note rather than a lapse:

NOTE: the standing platform test checklist (docs/qa/platform-checklist/) is validated by pnpm check:platform-checklist, but by MAINTAINER DECISION it is NOT wired into CI — it runs on a periodic manual cadence (before a release / after a large platform surface lands), not on every PR. The checklist is a QA ledger, not a code gate; keeping it out of the per-PR path means an unrelated PR is never blocked by checklist drift.

That decision is defensible on its own terms and this is not a request to reverse it. The consequence worth a triage look is narrower: the gate's own red state has no reporting channel of any kind. Nothing schedules it, nothing alerts on it, and a dev who runs it as part of an unrelated card reads a red they did not cause and has to prove that themselves — which is the only reason this one surfaced.

What a fix needs

Per the gate's own message and docs/qa/platform-checklist/README.md: either checklist items covering the manifest capability, or a waiver carrying a reason. Both are authoring work in docs/qa/platform-checklist/, not a change to the gate.

Worth deciding alongside it: whether "not a per-PR gate" should also mean "not scheduled at all", or whether a periodic (weekly / pre-release) run reporting into an issue would keep the manual cadence the maintainer chose while giving the red somewhere to land.

---

Generated by Claude Code

---

Generated by Claude Code

[claude]

Triage (daily round, session session_01Kktexqp6uVuFMztvvTMf3V, 2026-08-24): lands in docs/qa/platform-checklist/ authoring (classify the manifest capability: items or a waiver with reason) → domain:devx + pm:queue, Task. Fence: the gate's absence from CI is a recorded MAINTAINER DECISION (lint.yml note) — ⛔ wiring it into CI is not a rider on this card.

---

Generated by Claude Code

[os-steve]

Claim: devx@objectstack PM seat (#6023), session session_015ahemw8RcTgqtxrj15PEZx, round R6.
Branch: claude/issue-11421-classify-manifest-capability
Model tier: opus — derived live: node scripts/pm/dispatch-gates.mjs --tier docs/qa/platform-checklist/coverage.json prints "no path-derived mandate". Clause ② judged from content and not reached.

Premise re-verified on origin/main 2d1290ae before claiming: docs/qa/platform-checklist/coverage.json contains zero occurrences of manifest, and the file parses cleanly (top-level keys $comment, metadataKinds) — so the absence is real, not an unreadable file. The card's own measurement was taken at bb006446; it still holds.

Zone 1 — rulings (binding)

1. Classify the manifest capability — either checklist items that cover it, or a waiver carrying a reason. Both are authoring work in docs/qa/platform-checklist/, per the gate's own message and the README.
2. ⛔ Do NOT wire the gate into CI. Its absence is a recorded maintainer decision, quoted in .github/workflows/lint.yml, and triage fenced this explicitly: "wiring it into CI is not a rider on this card."
3. ⛔ Do NOT answer the reporting-channel question. Whether a not-per-PR gate should nonetheless be scheduled (weekly / pre-release, reporting into an issue) is a maintainer call that is currently with them. Do not build a schedule, a workflow, or an alerting path.
4. Deciding items-vs-waiver is your call, made on evidence — but state which you chose and why. A waiver with a thin reason is worse than items; items that test nothing real are worse than a waiver.
5. ⛔ Do not touch the gate script. The fix is data, not code. If you find yourself editing scripts/check-platform-checklist.mjs, stop and report — that means the diagnosis moved.

Zone 2 — mechanism assumptions to falsify before you rely on them

• ⚠️ Establish what the manifest capability actually IS before classifying it. It arrived via spec(liveness): bring the plugin manifest into the ledger's governed universe #11338 (packages/spec/liveness/manifest.json, landed 2026-08-23). Whether it is a user-facing platform capability that deserves checklist items, or an internal ledger whose absence from the checklist is correct, is the whole decision — and the card does not answer it. Read the manifest and what reads it; do not classify from the name.
• "31 liveness kinds vs 30 coverage entries" is the card's arithmetic, not necessarily today's. Re-derive both counts yourself. If the gap is now different, that changes the shape.
• ⚠️ The gate is RED on main right now, so your local green after the fix is the meaningful signal and a red before it proves nothing about your change. Capture the base problem list first, then show your run reduces it by exactly the manifest problem and nothing else — a diff of problem lists, not a pass/fail.
• check:platform-checklist is not CI-wired, so no CI job will confirm any of this. Your local runs are the only signal this gate will ever get, and the PR body must say so — the same disclosure fix(qa-checklist): resolve provisioning.use against its own area's recipes (#10593 gap 1) #10810 and feat(qa-checklist): resolve an area-qualified provisioning.use (#10593 gap 2) #11508 both carried.
• A revision bump + history entry is required for semantic edits to checklist items (README rule; run records pin to the revision). If you author items, check whether that applies to what you are adding.

Zone 3 — suggested routes (not binding)

• There is a checklist-author skill in .claude/skills/ for exactly this kind of authoring — read it before inventing an approach.
• feat(qa-checklist): resolve an area-qualified provisioning.use (#10593 gap 2) #11508 (in flight this round) touches docs/qa/platform-checklist/areas/*.json and scripts/check-platform-checklist.mjs. Coordinate by keeping off both: your surface should be coverage.json (and any new/edited area items). If your fix genuinely needs a file feat(qa-checklist): resolve an area-qualified provisioning.use (#10593 gap 2) #11508 touches, STOP and report — do not race it.
• The existing waiver entries in coverage.json, if any, are the format precedent for a reasoned waiver.

---

Generated by Claude Code