docs(examples): the corpus header points at the bucket instead of naming it (objectui#7548)

[os-sam]

Fixes #7548

The half that was already right, and the half this carries out

The closing paragraph of the module docblock in examples/schema-catalog/test/safe-validate-corpus-6318.test.ts already refused to pin the size of the remaining bucket, and its reason was good:

a number pinned here would turn red on the card that repairs any one of them.

Then it enumerated the contents by name, which nothing pinned either. The same reason applies to the contents word for word: objectui#6939 repairs that bucket one group at a time, so every group it lands makes one more line of the enumeration false. It is a list with a scheduled falsifier.

The re-check, every row, on this tree (3faaa7d0f)

Both by reading the declaration and by running the validator. The runtime column is a probe that was run and then deleted — it is reproduced in the report, not added to the repo.

the header's claim	declaration on 3faaa7d0f	validator says	verdict
"tooltip and context-menu demand a children their renderers never read"	neither TooltipSchema nor ContextMenuSchema declares children at all; it is only inherited from BaseSchema, where it is .optional()	a tooltip with no children → success = true; a context-menu with no children → success = true; the catalog's basic-tooltip and basic-context-menu author no children and both validate	FALSE
"tree-view demands data where the renderer reads nodes first"	TreeViewSchema.data is an ADR-0049 retirement tombstone (objectui#6951 B1), and the renderer reads boundData || schema.nodes || [] — data is not a limb of that read at all any more	tree-view with nodes and no data → success = true; tree-view with data → success = false, refused	FALSE, and now false in the opposite direction — the key the header called "demanded" is refused by name
"kanban declares columns[].items …"	not present — objectui#7541 removed this row from the paragraph when its group landed	—	already hand-deleted
"The 28 entries still in it"	nothing computes or asserts this number here	not measured — see What I did not run	UNVERIFIED

Why hand-updating the list is not the cheap fix — it is the defect, measured on this paragraph

The "just correct it" remedy was already tried here, and its failure is on the record in this file's own history:

when	what	effect on the list
2026-09-03 08:35:49	bfaa1589c (objectui#7456) removes the required children from TooltipSchema and ContextMenuSchema in one commit	row 1 becomes false
2026-09-03 18:57:08	777e5c6f4 (objectui#7533, objectui#6939 group 2) stops tree-view requiring the limb it reads third	row 2 becomes false
2026-09-03 19:55:15	240b80f31 (objectui#7541) edits this very paragraph, deleting the one row it had itself just repaired	row 3 removed; rows 1 and 2 left standing, already false for 11h19m and 58m
2026-09-05 16:48:28	16a725f96 (objectui#7769) turns TreeViewSchema.data into a retirement tombstone	row 2 becomes false a second time, in the opposite direction

An author editing this list, with this file open, 58 minutes after the most recent falsification, corrected only the row they had personally just falsified. That is not carelessness — it is the mechanism: nothing links the list to the card that falsifies it, and nothing goes red.

What this changes

The by-name enumeration is replaced by a pointer to where the list actually lives — the shape this repo has converged on three separate times (check-doc-snippet-types.mjs's UNGATED_DOCS header repaired itself into "a pointer to the list now rather than a copy of its length"; PR objectui#7827 applied it to two workflow headers):

• what the bucket is — open findings on the Zod union, and objectui#6939's worklist;
• what computes it — packages/cli/src/commands/check.ts, printed uncapped and per file with its type, deliberately not as a bare number (objectui#6075);
• where to read it — run objectui check over examples/schema-catalog; the cards that own it are objectui#6318 and objectui#6939, and ls examples/schema-catalog/test/*-6939.test.* lists the pins its landed groups left beside this file.

Two things kept deliberately:

• The refusal to pin the count stays, and is now extended to the contents with the reason spelled out — pinned, a restatement turns red; written as prose, it rots quietly, which is worse.
• The 28 is dropped. That is the opposite of pinning it: a copy of the list's length rots on exactly the same schedule as a copy of its names, and it is the same thing UNGATED_DOCS removed for the same reason. Nothing here asserts a size.

The acceptance question

After objectui#6939 repairs another group, is that paragraph still true? Yes. Every remaining sentence is either a property of the text itself, a pointer to a computed list, or a dated historical fact. Nothing in it is a restatement of the bucket's contents or size.

Evidence

The test file, before and after — a comment-only change should move nothing

BEFORE (3faaa7d0f)   Test Files  1 passed (1)      Tests  8 passed (8)
AFTER  (0b71b0418)   Test Files  1 passed (1)      Tests  8 passed (8)

All eight test names are unchanged, and the static expect( count in the file is 17 on both sides. Run as pnpm exec vitest run --project unit --maxWorkers=2 examples/schema-catalog/test/safe-validate-corpus-6318.test.ts, through this container's shared heavy-verify lock; the wrapper's verdict line reads VERDICT command-exit 0 on both runs.

Comment-only, proven the two independent ways

Either one alone can be fooled; together they cannot.

1. Every changed line is a docblock comment line. Over git diff -U0, payload lines only: 29 lines, +24 / −5, 0 of them failing to match a comment prefix.

2. Both revisions transpile to byte-identical output.

before  sha256 7e5e60df00048b64fad39dc01f5eaa2abcfc548c7e4e9b5bdbfd646b599dfdd3  3119 bytes
after   sha256 7e5e60df00048b64fad39dc01f5eaa2abcfc548c7e4e9b5bdbfd646b599dfdd3  3119 bytes

esbuild, --format=esm --target=es2022 --legal-comments=none. The first attempt at this proof produced 0 bytes on both sides — a wrong flag combination — and two empty files hash identically, which is a passing-looking proof of nothing. Both outputs are therefore guarded as non-empty and asserted to still contain the code (8 safeValidateSchema occurrences, 2 describe() with no comment text left in them.

Changeset — the gate's verdict, verbatim

Compared the working tree with 3faaa7d0f (merge-base with origin/main): 1 file(s) changed, 0 of them published source of a package the release covers, 0 of them a manifest whose published contract moved, 0 under a package changesets ignores, 0 changeset(s) added.
✅  No source or published contract of a released package changed in this range, so no changeset is owed.

Acted on as written: no changeset added, and no skip-changeset label applied — that label reads nothing in this repo and exempts nothing here.

Lint

pnpm --filter @object-ui/example-schema-catalog run lint (which is what turbo run lint runs for this package) exits 0, with the script name echoed so this is not a zero-match filter passing silently. Population read from eslint's own resolution rather than guessed: --format json reports 30 files for this package, the changed file among them, 0 errors / 0 warnings. The repo-wide eslint . is CI's run, and narrowing to this package is safe here because this config is not type-aware — eslint.config.js sets no projectService and no parserOptions.project — so a change confined to one file cannot move a diagnostic on a file that does not contain it.

Type-check — a pre-existing failure, provably untouched

pnpm --filter @object-ui/example-schema-catalog run type-check fails on this tree, and fails identically without this change. The failures are unresolved package imports (Cannot find module '@object-ui/types/zod' and friends) because this fresh worktree has not built the dependency closure's dist/; CI builds it.

Measured rather than assumed, from a committed state so the restore had a real reference point: the file was replaced with its 3faaa7d0f content, type-check re-run, and the file restored from HEAD — restoration confirmed by observed state (git diff HEAD empty, worktree blob 8220be2868… equal to the HEAD blob), not by an exit code.

BASE   94 "error TS" lines
AFTER  94 "error TS" lines
diff of the two sorted error sets, line:col normalised away:  IDENTICAL

The only two lines that move are the two on this file, each by exactly +19 — this diff's net line count (51 → 70, 64 → 83).

What I did not run

• The bucket was not recounted. That needs node packages/cli/dist/cli.js check, which needs a full workspace build. The 28 is removed as an unpinned copy of a length, not because it was measured wrong — it was not measured at all, and this PR does not repeat it as though it had been.
• No repo-wide eslint ., no repo-wide vitest, no dependency-closure build. CI runs the farm; the narrowing above is declared, with its population and its invariance argument.
• No CI wait. Reported at draft-PR time as this seat's contract requires.

Out of scope, filed separately

Measuring this change turned up a defect of the same class one level up, filed as objectui#7853 (no assignee, finding only): component-fixture-declared-keys.test.ts:835 cites safe-validate-corpus-6318.test.ts:98 by line. That citation is accurate on 3faaa7d0f — line 98 really is that assertion — and this comment-only diff moves it to line 117, with nothing going red. It is deliberately not repaired here: renumbering 98 to 117 is the very hand-update remedy this card exists to reject, the right remedy is a decision rather than a mechanical edit, and that address lives in a file this dispatch bounded me away from.

---

Generated by Claude Code