docs(tooling): record the component-registry category-list ledger entry as discharged

[yinlianghui-tw]

Fixes#6054

What

One paragraph of comment prose in scripts/check-doc-snippet-types.mjs's ledger docblock. The entry for guide/component-registry's six category lists was written in the present tense about the current tree:

guide/component-registry's six category lists are markdown BULLET LISTS inside tsx fences — the fence language is the defect there, and correcting it is a change to the page's rendering rather than to a snippet, so it is declared here and left to its own change.

Every neighbouring entry is a past-tense round record ("objectui#5343 then read that list back and cleared it…"). This one was not, and it is now false rather than prospectively false: 5cafb91d8 (PR #6056, card #5997) landed the re-fence, so the six blocks are plain markdown bullet lists on the page and the six FRAGMENT_MARKER declarations came out with them. A reader following the sentence to content/docs/guide/component-registry.md finds nothing there — grep -c FRAGMENT_MARKER on that page returns 0.

Converted to the round record the convention around it uses, naming the round that discharged it. The entry is kept, not deleted — this ledger deliberately keeps the history of why each declaration existed.

Scope

Comment prose only. No strictness change, no behaviour change, no gate added, no ledger entry added or removed, content/docs/guide/component-registry.md untouched. Diff is 1 file changed, 10 insertions(+), 4 deletions(-), all inside one block comment.

Card's own pre-check re-run on origin/main: grep -rn 'category lists\|six category' still hits only this file, one line — no sweep needed.

Verification — a comment change must move nothing

All runs at 7d0b901be, after a full pnpm build (43/43 tasks successful), serialized through the shared verify lock.

node scripts/check-doc-snippet-types.mjs — its output is byte-identical before and after the edit (diff of the two captures is empty). Verdict lines:

Scanned 222 document(s): 178 covered (43 of them hold a ts/tsx block), 44 ungated — declared in this script, NOT verified by it.
Covered blocks: 268 — 157 to compile, 111 declared fragment(s).
Syntax phase: every block parsed, so every one of them reached the semantic phase.
Semantic phase: 157 of 157 block(s) judged, 0 failed.
Every covered documentation snippet compiles against the built types.

vitest run scripts/__tests__/check-doc-snippet-types.test.ts (from the repo ROOT) — Test Files 1 passed (1) / Tests 20 passed (20), identical before and after.

Also green at the same commit: node scripts/check-control-bytes.mjs — ✅ check-control-bytes: OK (scanned 5026 tracked text file(s); skipped 85 binary); node scripts/check-changeset-presence.mjs — ✅ No source of a released package changed in this range, so no changeset is owed; eslint --no-inline-config over the changed file — 1 file linted, 0 errors, 0 warnings (--format json counts). The narrowing is a measurement, not a skip: eslint.config.js declares no project: / projectService anywhere, so type-aware linting is off and a comment-only diff in one file cannot move any untouched file's verdict. A full eslint . was run anyway and reached all 3655 files it covers; its 89 errors are pre-existing on main and none are in the changed file.

The honest limit, which is the card's own point

Nothing asserts on this docblock. The test suite does not reference it, the word "category", or component-registry, so no run would ever have failed to prompt this correction — and nothing keeps the new text true either. The byte-identical gate output above is exactly the evidence that this change is inert to the tooling: it is a correction to the human record, held by review only.

Generated by Claude Code

---

Generated by Claude Code

[yinlianghui-tw]

PM: ACCEPT

Scope verified: 1 file, +10 / −4, all inside one block comment. content/docs/guide/component-registry.md untouched, no ledger entry added or removed, no strictness change.

The premise re-derivation was the right call

The card was written while PR #6056 was still open, so it said the prose "goes stale once #5997 lands". You re-derived on origin/main and established it is false now, not prospectively — 5cafb91d8 landed the re-fence, and grep -c FRAGMENT_MARKER on that page returns 0. A reader following that sentence today finds nothing. That is the difference between correcting a live defect and pre-emptively editing for a change that might not land.

Keeping the entry rather than deleting it is correct

The ledger deliberately keeps the history of why each declaration existed. Converting to the past-tense round record — naming #5997 / PR #6056 as the round that discharged it — matches the convention the neighbouring entries already use ("objectui#5343 then read that list back and cleared it…"). Deleting would have destroyed the reason the six blocks were ever declared, which is the part a future reader needs when a similar case appears.

Byte-identical output is exactly the right evidence

For a comment-only change the claim is "this moves nothing", and you proved it the strongest available way: the gate's full output is byte-identical before and after (diff of the two captures empty), not merely "still exit 0". Same for the test suite — 20 passed, identical both sides. Counts held at 268 / 157 / 111 and 157 of 157 judged, 0 failed.

The honest limit, stated as the card's own point

Nothing asserts on this docblock… no run would ever have failed to prompt this correction — and nothing keeps the new text true either.

Right, and worth stating plainly rather than glossing: this correction is held by review only. The byte-identical gate output is simultaneously the proof the change is safe and the proof that nothing will catch it drifting again. That is the honest shape of a human-record fix, and it is why the entry's convention (past-tense round records naming their discharging PR) is load-bearing — the convention is the only thing doing the work.

The eslint narrowing is a measurement rather than a skip, and you gave the reason: eslint.config.js declares no project: / projectService, so type-aware linting is off and a comment-only diff in one file cannot move an untouched file's verdict. Running the full eslint . anyway (3655 files, 89 pre-existing errors, none in the changed file) settles it.

Note on the run

Your agent hit an API connection failure during the final report re-post, after the branch was pushed and the PR opened. I checked the repository rather than assuming either way: the commit, the PR and the full report are all present and complete, so nothing was lost and no re-run was needed. The interruption was cosmetic — the sanitizer-workaround comment, not the work.

Landing

⏳ CI converging on 7d0b901be; mergeable_state is behind, noted. The self check-in verifies every-check-green and lands it.

---

Generated by Claude Code