[os-bill]

Fixes #18910

Clause-②: no — docblock prose only. The accept set, the key list and strictObject are byte-identical; no public surface moves.

What the card said, and what I measured

The card said ListMapConfigSchema's docblock asserts a mechanism the renderer does not perform:

it validates schema.map against a local zod schema with exactly these keys, so an extra key here would be dropped there

I re-derived every reading first-hand at the pin — .objectui-sha reads 53ded82bf7a494f54e344e19099dbf00854b8694, and I checked that commit out into its own detached worktree (git worktree add --detach, HEAD 53ded82bf7a494f54e344e19099dbf00854b8694), never objectui main. Rather than reading the source and believing it, I extracted the pinned declarations byte-exact by line range (anchor-verified, sha256-stamped) and executed them under zod 4.4.3 — the version the pin's own lockfile resolves. Every zero/negative reading below carries a same-subject control that HITS.

#	reading at the pin	lit control	control result
1	ObjectMapConfigSchema (packages/types/src/zod/objectql.zod.ts:562) is a plain z.object: safeParse({…, extraKey}) → success=true, zero issues, no warning	(a) the same extracted declaration with .strict() appended, same input; (b) the real declaration with zoom: 'far'	(a) success=false → unrecognized_keys at the ROOT path; (b) success=false → invalid_type@zoom. The probe can see closure, and it reaches the schema
2	getMapConfig (packages/plugin-map/src/ObjectMap.tsx:373-376) consults that safeParse only to pick a console.warn: with an undeclared key, 0 warn calls	same call with zoom: 'far'	exactly 1 warn, [ObjectMap] Invalid map configuration: — the warn path is reachable and my capture works
3	:378 returns a spread of the AUTHORED block: getMapConfig({map:{locationField,extraKey}}) → {"locationField":"loc","extraKey":"x"} — carried through	the failing-parse call above still returns {"locationField":"loc","zoom":"far"}	the parse result is provably not the value
4	New. On the path this block actually takes, the key IS dropped: resolveListMapConfig (packages/plugin-list/src/ListView.tsx:113) → {"locationField":"loc","titleField":"name"} — extraKey gone, and style with it	the declared locationField / titleField in the same call	both survive — the instrument transmits, so the two absences are readings

Per the dispatcher's warning about counting rather than printing: every negative above is a printed value, not a count. The one search-shaped reading — "objectql.zod.ts declares nothing strict" — is printed too: its only strict hit in that file is a comment at :392 (「Note UserActionsConfigSchema is NOT .strict()」), and the lit control that the search would find a real one is packages/types/src/zod/complex.zod.ts:635 → }).strict();.

What turned out false — in the card, not in the fix

The card's three readings are all accurate, and its line numbers still land. But its conclusion — "an undeclared key inside map is neither flagged nor dropped by the renderer" — is false for the path this block governs. A spec list view's map block never reaches getMapConfig as a map block: ListView and ObjectView flatten it through the hand-listed FLAT_MAP_CONFIG_KEYS whitelist first, and both emit flat props ("neither flattener emits a map key at all"). So the docblock's outcome word — "would be dropped" — happens to hold; its mechanism — a closed local zod schema — does not, anywhere.

That distinction is the whole fix, because the mechanism is what a future editor would act on. Believing "the renderer validates it" and relaxing this block to passthrough buys an author no check at all: the key dies in a whitelist without a word, and the one schema that could have reported it is open and warn-only.

The edit

Before:

Closed (strict) from the start: the map renderer's read set is itself closed — it validates schema.map against a local zod schema with exactly these keys, so an extra key here would be dropped there.

After (opening sentence; the full replacement is in the diff):

Closed (strict) from the start, and the strictness stands on its own: it does NOT rest on the renderer refusing an undeclared key, because nothing downstream refuses one.

followed by the two measured bullets, and by the reason the strictness survives losing its old argument: nothing downstream reports an undeclared key, so this parse is the only place an author is told anywhere — map is not in objectui's LIST_VIEW_LOCAL_OVERRIDES, so objectui's own ListViewSchema imports this block by reference and the document check on that side is this same schema.

⛔ strictObject is untouched. No key was added, removed or renamed.

The anchors are now machine-checked, not just asserted

This defect is a cross-repo claim that rotted because nothing re-read it. check:objectui-pin-citations already has the instrument for that — an anchor that quotes its first line is verified against objectui at the pin — and it was sitting at zero coverage. The seven anchors in this record now carry their quoted line, so the gate reds on the next pin bump instead of rotting, and ASSERTED_ANCHOR_FLOOR moves 0 → 7 with its note rewritten (that ratchet is an equality in both directions).

Verified, not assumed: check:objectui-pin-citations prints 7 anchor content assertion(s) verified against objectui at 53ded82bf.

Ablation — the new assertions can fail. Committed the change first, then mutated one quoted line through scripts/ablation-replace.mjs (on-disk anchor hit + blob hashes, not an editor's exit code): export const ObjectMapConfigSchema = z.object({ → … z.strictObject({. The gate went exit 1 and named it:

✗ packages/spec/src/ui/view.zod.ts:1764 — the asserted first line does not match
  `packages/types/src/zod/objectql.zod.ts:562` at this pin.
      asserted: export const ObjectMapConfigSchema = z.strictObject({
      actually: export const ObjectMapConfigSchema = z.object({

Restore was verified on disk, not by an exit code: blob after restore 358aed5fc71d99c6… == blob at HEAD 358aed5fc71d99c6…, git diff HEAD empty.

Tests and gates

• pnpm --filter @objectstack/spec exec vitest run --maxWorkers=2 src/ui/view.test.ts src/ui/component.test.ts src/ui/view-gantt-tree-config-closed-15469.test.ts src/ui/view-strictness-batch18.test.ts — 4 files, 878 tests passed.
• pnpm --filter @objectstack/spec typecheck — green (includes check:scripts-typecheck, which covers the edited gate script, and check:test-typecheck).
• pnpm --filter @objectstack/spec build && … check:generated — all 16 generated artifacts up to date; no regeneration was owed.
• Gate families derived with node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack (its own change-set derivation, not a hand-written list) and run; six dist-reading gates first refused with PREREQUISITE NOT MET against a dist older than the edit, and were green on re-run after pnpm --filter @objectstack/spec build — recorded as NOT MEASURED → measured, never as findings.

Acceptance notes

Noted here rather than filed or fixed — ⛔ no diff was widened for any of them.

1. ListMapConfigSchema.style does not reach the renderer on the list-view path at this pin. #18406 added style because getMapConfig reads schema.map?.style. Measured: FLAT_MAP_CONFIG_KEYS is this block's keys minus style, resolveListMapConfig drops it (printed above), baseProps carries no style/mapStyle, and mapStyle appears in neither flattener (printed hits; lit control: locationField, which IS forwarded, hits in both files). Radius of the instrument: the two flatten sites plus baseProps in packages/plugin-list/src/ListView.tsx and packages/plugin-view/src/ObjectView.tsx at 53ded82b — it does not cover an object-map component node written by hand, where map.style does reach getMapConfig. A style URL authored through this face parses green and the map renders on the default demo tiles, silently. The landing repo would be objectui, and the docblock sentence it touches is #18406's ruling text, so it is a card, not a rider.
2. This docblock's opening still claims "every key here has a live read there". True as written for style (the read is in getMapConfig) but not on the path this block takes — see 1. Left byte-identical: correcting it is the same card as 1.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

⚠️ 1 changed file(s) yielded no anchor (packages/spec/src/ui/view.zod.ts), so the pages documenting them are NOT COVERED by this run — this is not a clean bill of health for those files. Nothing else in this diff resolved to a documentable surface (no symbol, route or SDK anchor derived from 1 changed package(s)).

What this run could not see

• 1 changed file(s) yielded no anchor (packages/spec/src/ui/view.zod.ts) — pages documenting those are invisible to this run
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 136 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 07c6f822edd9c4c48a7ce34767de420c6096b9c3 → packageMentionDocs.