docs(qa): R4 coverage sweep — retire both stale waivers, author 8 items for the post-2026-08-08 window

[os-zhuang]

Fixes#9299

Part of the #9296 QA wave (round 4, ran in parallel with R0). Docs-only diff:
docs/qa/platform-checklist/** and nothing else.

Result

node scripts/check-platform-checklist.mjs green at d23a746c7:

✓ checklist-select self-test: 17 cases pass.
check-platform-checklist: OK — 15 areas, 190 items (190 active); coverage: 30 kinds mapped, 0 waived.

reading	before	after
items	182	190
kinds mapped	28	30
waived	2	0
since:v17 selectable	14	20

Both surviving waivers were stale

book and doc each claimed the kind is "display-only ... no independent runtime
behavior to gate beyond serving". Grounding disproved it. The REST read layer runs:

• a three-member audience vocabulary (public / org / { permissionSet }) with an
  ADR-0049 fail-closed branch — unresolvable permission-set holdings deny;
• a two-layer gate: the book audience gates the tree, then entries are filtered
  again by each doc's effective audience (the union over claiming books), so an
  anonymous reader never sees a nav entry that would refuse on click;
• a deliberate non-leak rule — the synthetic Uncategorized orphan group is excluded
  from claimed-docs resolution because including it "would leak every unclaimed doc of a
  package through any public book it ships";
• implicit per-package book fallback, and doc locale resolution.

That is an access-control surface, and it now has an item. Running total: 6 of 6
waivers ever written turned out stale — SWEEP.md records that, since it is the
strongest argument in the file for auditing waivers against the runtime rather than
against their own prose.

Items authored

Each was grounded in a real file path before anything was asserted, and each names the
sibling item it deliberately does not duplicate.

id	why it was invisible
platform-core.docs-audience-gate	kind was waived, so no ratchet looked
access-security.no-active-org-session-semantics (P0)	ADR-0123 — new behavior across already-mapped kinds
api-backend.filter-comparand-conformance	operators were covered; comparand types were not
api-backend.date-range-preset-matrix	enum landed 2026-08-15, never pinned
api-backend.retired-def-refusal	retired keys covered; retired definitions not
integration-system.datasource-credential-refusal-matrix (P0)	datasource already mapped; the doors are not enum members
cli.migrate-meta-codemod	listed as a variant of the DB-migrate item, asserted nowhere
cli.scaffold-console-first-paint	the seam between two first-run items

Two new variants matrices are pinned with enumSource, verified against the
validator's own extractor rather than by eye:

• ACCEPTED_FILTER_COMPARAND_TYPES — 6 members
• DATE_RANGE_PRESETS — 13 members

I also probed SCALAR_FILTER_HEAD_TYPES and did not pin it: it is a new Set([...]),
which the extractor reads as zero members, so a pin would have been a permanently
vacuous green.

The blind spot the card predicted, confirmed

The window added 156 non-test source files but zero new metadata kinds. Every
finding above is new behavior inside an already-mapped kind — invisible to the coverage
ratchet (no new kind) and to the enumSource ratchet (no new enum member). So none of it
could have been caught by check:platform-checklist however often it ran. That is now
stated explicitly in SWEEP.md.

One refinement to the card's framing, from evidence: the gap is not only recency. Two
of the eight items cover capabilities that predate the ledger's own baseline
(since: v14.1 and v14.7) and were simply never authored. Under-authoring of v17 is
real — since:v17 goes 14 → 20 here — but recency was not the whole story.

SWEEP.md fact correction

The runbook claimed the validator runs in "CI, every PR" and that this half "needs no
human at all". It does not run in CI: .github/workflows/lint.yml:426 carries the
maintainer decision as a comment with norun: step, and the only two mentions of
the script in all of .github/workflows/ are that comment. Corrected the fact, kept the
posture, and spelled out the consequence a sweep actually depends on — the ratchets catch
drift at the next manual run, so a green ledger is not evidence that drift is gated.

On cost: my own measurements came out above the ones supplied with the card (validator
~0.12–0.18 s vs ~80 ms; pnpm check:platform-checklist ~2.9 s wall vs 0.165 s), which I
attribute to the parallel cold install running in the same container plus pnpm's own
startup. Rather than bake in a figure that will read as wrong on the next machine, the
corrected text records the direct-node cost (~0.25 s for self-test + validator) and warns
that timing through pnpm measures the wrapper. Flagged for you in FOLLOW-UPS.md §5c.

FOLLOW-UPS.md

New 2026-08-17 section, carrying one drift finding, the checked-and-clean readings, and
notes for you.

One hypothesis this sweep raised was refuted by source-checking, and is recorded as
refuted. I read the blank template's bare "dev": "objectstack dev" against
quick-start's npx os dev --ui and inferred that npm run dev would strand a newcomer
with no console. Tracing the chain disproves it:

• packages/cli/src/commands/serve.ts:221 — ui: Flags.boolean({ …, default: true, allowNo: true }); the console is default-ON at serve, and --no-ui is the off switch.
• packages/cli/src/commands/dev.ts:370 — ...(flags.ui ? ['--ui'] : []) only ever adds the flag, never forwards --no-ui; with dev.ts:69 declaring ui with no default, an unflagged dev inherits serve's default.
• content/docs/deployment/cli.mdx:139 states it outright: "--ui | Force Console UI on (already on by default in dev)".

So --ui on dev is a no-op forwarder, the bare script is correct, and there is no
divergence. The reading now lives in §5b as a checked-and-clean entry with the full
trace rather than being deleted — the wrong inference is an easy one to make twice, and
a bare deletion invites the next sweep to re-derive it.

cli.scaffold-console-first-paint survives, because the seam it covers is real: no other
item drives the console against a freshly scaffolded blank project (cli.scaffold-first-run
boots headless via os start --artifact; cli.dev-boot-contract drives the fully-populated
showcase). Its clause 3 now asserts the two invocations agree, with a difference
between them as the failure, and its negatives cover the real regressions — a future ui
default of false on dev, or --no-ui being forwarded.

The remaining drift row is a stale note in packages/spec/liveness/doc.json describing a
tags defect that is fixed (DocSchema declares tags now) — reported, not edited,
since it sits outside this card's file surface.

Checked and clean, recorded so the next sweep does not re-derive it: no published doc
prescribes a retired scaffolder template (zero hits across content/docs/ for all five),
and npm run validate is the same binary as npx os validate.

Verification

Docs-only; no path-derived gate families (node scripts/pm/dispatch-gates.mjs on the
changed paths places none). Run at d23a746c7, after the final commit:

• node scripts/checklist-select.mjs --self-test — 17 cases pass
• node scripts/check-platform-checklist.mjs — OK, 190 items, 0 waived
• node scripts/check-nul-bytes.mjs — OK, 6067 files, no raw control bytes
• every new id resolves through checklist-select.mjs, including the two new
  since: values

No changeset: docs-only, publishes nothing. Carrying this repo's real skip-changeset
label rather than an empty changeset.

⛔ Draft, per the card. Not merged, no auto-merge, not enqueued.

---

Generated by Claude Code