121 declared-but-unmirrored keys across 16 schema pairs — the lane #6058's new UnmirroredDeclared ledger made visible

[yinlianghui-tw]

Filed unassigned, no pm:* label — triage owns grading and routing. Recorded by the domain:devx @ objectui execution seat (#5748), PM session session_019b5UBNMtTzKbVtZZGvFuxe, from the handback of #6058 (PR #6149).

What this is

#6058 fixed a blind guard: zod-mirror-parity's forward comparison mapped over the intersection of mirrored keys and keyof the declaration, so a key declared on the TypeScript side and absent from the mirror did not compare unequal — it left the comparison entirely. PR #6149 lands the union comparison and seeds a second, separately-ratcheted ledger, UnmirroredDeclared, at the measured debt.

⛔ This card is that debt. It is not a defect in the guard and not a regression — every fact below was already true; nothing was watching. KnownDrift and NarrowerThanDeclared are untouched at 12 entries / 17 keys, and #5927 / PR #6032's citable 17 → 13 shrink stays comparable.

16 pairs carry 121 declared-but-unmirrored keys, out of 158 registered pairs. Each one is a key the published TypeScript invites an author to write and the published validator has never heard of — the "declared ≠ enforced" shape this whole family exists to close.

⚠️ Note on the arithmetic, because two different counts are in circulation: #6058's round-1 report counted 23 red pairs under the union comparison, of which 7 were red only via their pre-existing KnownDrift entries. The 16 here are the pairs that actually carry unmirrored keys. The earlier 4-vs-19 spec split maps to 3-vs-13 below because PageNodeSchema's redness is entirely KnownDrift and it contributes zero unmirrored keys.

Spec-derived — ⛔ route to #2231, do not fix locally (3 pairs, 14 keys)

On these the mirror takes its shape by reference from @objectstack/spec, so an unmirrored declared key means the local declaration carries members the spec schema does not model. That is the unification question, not a local mirror edit — and SPEC_DERIVED_PAIRS' own doc notes a spec bump legitimately moves these sets. They are marked in the ledger rather than exempted in the instrument.

pair	keys
complex.zod.ts#DashboardComponentSchema	title
complex.zod.ts#DashboardWidgetSchema	pagination, searchable
objectql.zod.ts#ObjectViewSchema	allowCreateView, defaultListView, defaultViewType, filterableFields, listViews, navigation, onNavigate, searchableFields, showViewSwitcher, viewActions, viewTabBar

Local mirror omissions (13 pairs, 107 keys)

pair	count	keys
objectql.zod.ts#ObjectFormSchema	26	allowSkip, buttons, defaultTab, defaults, drawerSide, drawerWidth, formType, mobile, modalCloseButton, modalSize, nextText, onCancel, onError, onOpenChange, onStepChange, onSuccess, open, prevText, sections, showStepIndicator, splitDirection, splitResizable, splitSize, subforms, submitHandler, tabPosition
data-display.zod.ts#DataTableSchema	29	disableInnerScroll, editable, manualPagination, manualSearch, manualSorting, onAddRecord, onBatchSave, onCellChange, onColumnReorder, onColumnResize, onPageChange, onPageSizeChange, onRowActionDef, onRowClick, onRowSave, onSearchChange, onSortChange, page, rowActionDefs, rowClassName, rowCount, rowStyle, search, selectionResetKey, selectionStyle, showAddRow, showSelectionCount, singleClickEdit, sort
objectql.zod.ts#ObjectGridSchema	17	aggregations, bulkActionDefs, bulkSpecActions, conditionalFormatting, emptyState, exportOptions, grouping, navigation, onNavigate, operations, reorderableColumns, resizableColumns, rowColor, rowHeight, rowSpecActions, singleClickEdit, title
views.zod.ts#DetailViewSchema	14	activities, autoDiscoverRelated, autoTabs, comments, defaultTab, highlightFields, history, onAddComment, onNavigate, onTabChange, primaryField, recordNavigation, sectionGroups, summaryFields
form.zod.ts#FormSchema	9	defaultFieldTab, fieldContainerClass, fieldPanes, fieldPanesOrientation, fieldPanesResizable, fieldTabs, fieldTabsPosition, mobileStickyActions, onDirtyChange
complex.zod.ts#ChatbotSchema	3	displayMode, floatingConfig, requestBody
reports.zod.ts#ReportComponentSchema	3	chartConfig, conditionalFormatting, reportType
data-display.zod.ts#ChartSchema	1	drillDown
form.zod.ts#FormFieldSchema	1	field
form.zod.ts#InputSchema	1	wrapperClass
form.zod.ts#LabelSchema	1	content
navigation.zod.ts#PaginationSchema	1	currentPage
views.zod.ts#DetailViewSectionSchema	1	hideEmpty

Three were verified by hand against both sources during #6058, as a spot-check that these are defects rather than instrument noise: InputSchema.wrapperClass (declared in src/form.ts, absent from the mirror), DetailViewSectionSchema.hideEmpty, ChartSchema.drillDown.

⭐ The sorting that should come before any batching — 23 of the 121 are callback-shaped

23 keys are on* props: 12 on DataTableSchema, 5 on ObjectFormSchema, 3 on DetailViewSchema, and 1 each on FormSchema, ObjectGridSchema, ObjectViewSchema.

⚠️ For those, "mirror it" may be the wrong remedy. The right one may be to narrow the declaration so it stops advertising a runtime callback as authorable metadata — which shrinks the ledger without touching any mirror, and is a scope reduction. objectui#4453 already picked that direction once, narrowing to typeof === 'function' so an authored string handler is dropped; and #6122 / PR #6142 landed the documentation half of the same judgement an hour ago, after measuring that no renderer reads any of 16 schema-level event slots.

⛔ So this subset is worth one ruling covering all 23, not 23 per-key decisions and not a blanket mirroring sweep. Deciding it first also shrinks whatever remains.

What a taker needs to know

• ⛔ Growing KnownDrift is not the remedy for anything here — that ledger means "mirrors that refuse a declared spelling" and is a different, honest 12. UnmirroredDeclared is the ledger these belong to, and it is shrink-only: any new declared-but-unmirrored key on any of the 158 pairs reddens immediately, so the debt cannot grow while it is worked off.
• The ledger is pinned in both directions by ReconcileAgainstLedger with synthetic-pair tests, so a fact deleted from the seed is not silently re-acceptable and a stale entry names itself.
• ⚠️ --noErrorTruncation will not show you the whole list through a named alias — TS prints the alias name and elaborates exactly one member with no ellipsis. finding: the #5684 zod-mirror-parity guard is BLIND to a key declared on the TS side but absent from the mirror — measured on ObjectGanttSchema, and it is the guard #5927 just used as authoritative #6058 measured that an inline spelling resolves the union and prints a real ... N more ..., and wrote both readings into the file. Read the ledger, not the compiler error, to see the set.
• The measurement instrument is the TypeScript compiler API walking each pair's union members via isStringLiteral().value; its non-vacuity control is that it read all 158 pairs and returned empty for 142.

Refs: #6058 / PR #6149 (where this was measured and where the ledger lands) · #6141 (the stale 163/13 prose, corrected by that PR) · #5927 / PR #6032 (the 17 → 13 shrink this preserves) · #2231 (spec unification, where the 3 spec-derived pairs go) · #5155 (what an index signature does and does not cap) · #4453 / #6122 (the callback-narrowing precedent).

[yinlianghui-tw]

PM claim + dispatch order — R24, the callback subset only, measurement-first

Claimed by the domain:devx @ objectui execution seat (#5748), PM session session_019b5UBNMtTzKbVtZZGvFuxe. Branch: claude/issue-6152-callback-subset.

⛔ This round takes 23 of the 121 facts, not all of them. The other 98 are not dispatched and must not be touched.

Why this subset first

23 of the 121 declared-but-unmirrored keys are callback-shaped on* props — 12 on DataTableSchema, 5 on ObjectFormSchema, 3 on DetailViewSchema, 1 each on FormSchema, ObjectGridSchema, ObjectViewSchema.

⭐ For these, mirroring may be the wrong remedy entirely. If nothing authors them and no renderer reads them as authored metadata, the honest fix is to narrow the declaration so it stops advertising a runtime callback as an authorable key — which shrinks the ledger without touching a single mirror, and is a scope reduction rather than an expansion.

That direction has landed precedent twice: objectui#4453 narrowed to typeof === 'function' so an authored string handler is dropped, and #6122 / PR #6142 landed the documentation half after measuring that no renderer reads any of 16 schema-level event slots. Deciding these 23 first also shrinks whatever remains of the 121.

Step 1 — the measurement, and it is this round's deliverable

For each of the 23, report:

1. Is it ever authored? Search examples/, apps/, content/, fixtures, catalog entries and tests for an authored value at that key. ⚠️ An empty result is not a reading without a positive control — plant one and show the search finds it.
2. Does any renderer read it off the schema, as opposed to receiving it as a React prop? ⭐ This is the distinction that decides the card: a prop passed by a parent component is not authorable metadata, and a key read off schema.* is.
3. Does the zod mirror's sibling for that pair already omit callbacks deliberately? If the mirrors are consistently callback-free, that is evidence the omission is a policy rather than 23 oversights — and the ledger entry, not the mirror, is what is wrong.

Conditional ruling, so you are not blocked

• If none of the 23 is authored and none is read off the schema → recommend narrowing, name exactly which declarations change, and ⛔ stop there. Do not implement: removing 23 keys from published TypeScript is a public-surface change and that is a ruling, not an implementation detail.
• If some are genuinely authorable → they belong with the other 98 as ordinary mirror omissions. Say which, and why.
• If the answer is mixed → that is the expected outcome; the split is the deliverable.

⛔ Do not edit any mirror. Do not edit UnmirroredDeclared, KnownDrift or NarrowerThanDeclared. Do not remove any declaration. This round produces a measurement and a recommendation.

⚠️ Also do not touch the 3 spec-derived pairs (DashboardComponentSchema, DashboardWidgetSchema, ObjectViewSchema) beyond noting which of their keys are callback-shaped — those route to #2231, and ObjectViewSchema.onNavigate sits in both sets.

Verification

• The 23-row table: authored anywhere (with the positive control), read off schema.*, and the mirror-policy reading.
• ⚠️ Build before you judge and quote the resolution control — read the shipped dist/*.d.ts, not source.
• The UnmirroredDeclared ledger landed in test(types): ledger the declared-but-unmirrored half of the zod mirror comparison #6149 (merged 21:46:05); confirm it is in your base and quote its current entry count so the 121 is re-anchored rather than inherited from my card.
• Root vitest only, never package-scoped (objectui#3378).

⚠️ Re-derive your branch point at claim. Many PRs landed in the last hour; three near-misses today came from stale branches, one of which would have silently reverted another PR with no conflict and no red gate.

⚠️ Commit before any ablation whose restore leg is git checkout. git checkout HEAD -- plus the path, never the bare form. ⛔ Never git stash — shared stack.

⚠️ Lead your report with the literal text os-dev-report. Write angle-bracket fragments in words — ⭐ and read your report back after posting: the sanitizer was confirmed today stripping such a fragment from the JSON body of a report, not only from titles and fences.

needs_decision with no PR is the expected outcome for this round.

Refs: #6058 / PR #6149 (the ledger) · #4453 (the narrowing precedent) · #6122 / PR #6142 (no renderer reads 16 schema-level event slots) · #2231 (where the spec-derived pairs go).

---

Generated by Claude Code

[yinlianghui-tw]

os-dev-report

R24 measurement — the 23 callback-shaped keys. needs_decision, no PR.

Base 075297587 (re-derived from origin/main at claim). Branch claude/issue-6152-callback-subset pushed as the write-route probe and carries zero commits — nothing was implemented, nothing was edited. #6152 remains open.

Ledger re-anchored (not inherited)

Parsed mechanically out of packages/types/src/__tests__/zod-mirror-parity.test.ts at base — interface UnmirroredDeclared brace-matched, block comments stripped, keys counted:

ENTRIES: 16
TOTAL KEYS: 121
CALLBACK-SHAPED (on[A-Z]) COUNT: 23

Per-pair on* split matches the card exactly: DataTable 12, ObjectForm 5, DetailView 3, FormSchema 1, ObjectGrid 1, ObjectView 1. #6149 (7797e3b74) is in the base. Ledger green: pnpm vitest run packages/types/src/__tests__/zod-mirror-parity.test.ts from the repo root (objectui#3378) — Test Files 1 passed (1) / Tests 5 passed (5).

Resolution control — this reads the SHIPPED surface

pnpm --filter @object-ui/types build first (VERDICT command-exit 0), then ts.resolveModuleName from a real consumer:

RESOLUTION-CONTROL [Bundler] '@object-ui/types' from packages/plugin-form/src/ObjectForm.tsx -> packages/types/dist/index.d.ts
RESOLUTION-CONTROL [Node16] '@object-ui/types' from packages/plugin-form/src/ObjectForm.tsx -> packages/types/dist/index.d.ts

All 23 keys resolved off dist/*.d.ts via the compiler API.

---

The 23 rows

Authored anywhere = NO for all 23, positive-controlled. on* keys searched as a JSON/YAML/MDX authored key across the repo returned 0; planting "onRowClick": "OS_POSITIVE_CONTROL_6152" into examples/schema-catalog/src/schemas/components-complex-data-table/simple-table.json made the same search return exactly that line and nothing else; restore verified byte-identical against a pre-mutation copy with a clean git status. A whole-repo sweep for a serializable value (string/number/bool) at any of the 21 distinct names found 5 hits, all disqualified on inspection: 2 are ReportBuilderSchema (a different pair, z.string() dialect), 1 is a key-presence marker map in object-view-spec-parity.test.ts, 2 are docs for the blocks dialect.

"Read off schema" below means read off the pair's own declaration in shipped renderer src (not tests), counted by AST so destructuring cannot hide a read — a plain schema.onX grep undercounts, because data-table.tsx destructures four of them.

#	pair · key	read off schema.* in renderer src	site
1	DataTableSchema.onAddRecord	YES	data-table.tsx:2381
2	DataTableSchema.onBatchSave	YES	:1567
3	DataTableSchema.onCellChange	YES	:1415
4	DataTableSchema.onColumnReorder	NO — zero reads	written by ObjectGrid.tsx:3090, never read
5	DataTableSchema.onColumnResize	NO — zero reads	written by ObjectGrid.tsx:3084, never read
6	DataTableSchema.onPageChange	YES (destructure)	:694
7	DataTableSchema.onPageSizeChange	YES (destructure)	:695
8	DataTableSchema.onRowActionDef	YES	:493, :554
9	DataTableSchema.onRowClick	YES	:2025, :2032, :2057
10	DataTableSchema.onRowSave	YES	:1507
11	DataTableSchema.onSearchChange	YES (destructure)	:702
12	DataTableSchema.onSortChange	YES (destructure)	:698
13	ObjectFormSchema.onCancel	YES	ObjectForm.tsx:227, :993
14	ObjectFormSchema.onError	YES	:226, :983
15	ObjectFormSchema.onOpenChange	YES	:336, :365
16	ObjectFormSchema.onStepChange	YES	:279
17	ObjectFormSchema.onSuccess	YES	:225, :778, :846
18	DetailViewSchema.onAddComment	YES	DetailView.tsx:1458, :1684
19	DetailViewSchema.onNavigate	YES	:594, :608-613, :677
20	DetailViewSchema.onTabChange	YES, through an as any cast	:1402
21	FormSchema.onDirtyChange	YES (destructure)	form.tsx:997
22	ObjectGridSchema.onNavigate	YES	ObjectGrid.tsx:1334
23	ObjectViewSchema.onNavigate (SPEC-DERIVED)	YES	ObjectView.tsx:856, :871, :883, :925

Two attributions I checked and excluded: containers.tsx:586 reads onTabChange off a tabs container schema, not DetailViewSchema; plugin-chatbot/renderer.tsx reads onError off ChatbotSchema (already mirrored). The plugin-form siblings WizardForm/ModalForm/DrawerForm/SplitForm/TabbedForm/MasterDetailForm read their own local interfaces (export interface WizardFormSchema etc., declared in plugin-form), not ObjectFormSchema, so they are not counted above.

---

The three findings that change the card

1. The narrowing precedent does not apply — all 23 are ALREADY function-only

Every one of the 23 came back callable=true with no string alternative in the shipped .d.ts:

onRowClick: ((row: any) => void) | undefined [callable=true]
onSuccess: ((data: any) => void | Promise) | undefined [callable=true]
onNavigate: ((recordId: string | number, mode: "view" | "edit") => void) | undefined [callable=true]

objectui#4453 narrowed a key that accepted string OR a function down to typeof === 'function', so an authored string handler is dropped. There is no such string branch left here. The published TypeScript is not advertising these as authorable — it is already declaring them as functions, which no JSON author can write. The premise the subset was carved on ("mirroring may be the wrong remedy; narrow instead") survives, but its mechanism does not: there is nothing to narrow.

2. Removing them would break shipped renderers — 21 of 23 are live schema reads

This is the direct answer to the conditional ruling. The "none is read off the schema" branch is false. 21 of the 23 are read off their own declaration by shipped renderer code, and the values come from a third channel the card's binary did not anticipate: not authored metadata, and not a React prop either, but a sibling component synthesizing a schema-shaped object in code and handing it down. ObjectGrid.tsx:2937 builds const dataTableSchema: any = { … onAddRecord, onRowClick, onCellChange, onRowSave, onBatchSave, … } and renders it through SchemaRenderer at :3735; ListView, ObjectView, RelatedList, ObjectKanban, ObjectCalendar, ObjectGantt and ObjectGallery all do the same. Deleting these 23 keys from published TypeScript would red every one of those producers.

3. Callback-omission is NOT a mirror-wide policy — except in one file

73 on* keys are already mirrored across packages/types/src/zod/, in two dialects: 56 as z.function(), 11 as z.string() (an authored handler-expression dialect), 3 z.any(), 3 named schemas. Per pair:

mirror	already declares callbacks?	reading
data-display.zod.ts#DataTableSchema	YES — 4: onRowEdit, onRowDelete, onSelectionChange, onColumnsReorder, all z.function()	the 12 omissions sit in the same object literal as 4 inclusions. Oversight, not policy.
form.zod.ts#FormSchema	YES — 3: onSubmit, onChange, onCancel, all z.function()	onDirtyChange is a plain omission beside three mirrored siblings. Oversight, not policy.
views.zod.ts#DetailViewSchema	YES — 1: onBack, as z.string()	not callback-free; and it uses the other dialect than the three omitted keys would need.
objectql.zod.ts (ObjectForm, ObjectGrid, ObjectView)	NO — zero on*, zero z.function() in the entire file	the policy reading holds here, and is corroborated: objectql.zod.ts:164 describes successMessage as "Success toast text after create/update when no onSuccess handler is given" — the mirror naming the authored alternative to a runtime callback it deliberately does not model.

So the answer to question 3 is split 16 / 7: for the 16 keys on DataTableSchema, FormSchema and DetailViewSchema the omission is an ordinary oversight; for the 7 on ObjectFormSchema / ObjectGridSchema / ObjectViewSchema it is a documented policy of a callback-free file.

⚠️ But note what "mirror it" would actually buy on the 16: z.function() is unreachable from any serialized document. A JSON author can never satisfy it. Mirroring the 16 that way would move 16 rows off the ledger while adding validator surface no authored payload can ever populate — the ledger shrinks and nothing is enforced. That is the cost that makes this one ruling rather than 23.

---

Prior art already ruled this, for 3 of the 23

docs/audits/2026-07-objectview-detailview-schema.md reached the same verdict by a different route. At :148, on onNavigate: "A function. Non-serializable; cannot live in a JSON protocol." — listed under Keep local. And at :237-241:

"loading, data, history, comments, activities, recordNavigation, onNavigate, onTabChange, onAddComment are live state and callbacks, not metadata. They are correctly local and must never enter a serializable protocol. Their existence on a schema is itself the smell: they are why this 'schema' cannot be validated, persisted, or authored — it is a props bag wearing a schema's clothes."

That covers rows 18-20 and 23 and points at neither of the card's two options: keep the declaration, never mirror it.

Recommendation — a third disposition, not either branch offered

Neither "mirror them" nor "narrow them away" fits the measurement. Recommend a third ledger category — runtime-only, non-authorable, permanently unmirrored — covering all 23 in one ruling:

• keep every declaration (21 are live reads; removing them breaks shipped renderers, and Resolve the spec-named symbol collisions with 17.0.0 GA exports (check:spec-symbols): SECRET_MASK + ObjectCalendarProps/ObjectFormProps/ObjectGridProps/ObjectKanbanProps + one more #4650 already established the two-layer split these belong to: ObjectFormPropsSchema in @objectstack/spec/ui is "serialisable authoring keys only", ObjectFormComponentProps is "the RENDERER's props ... none of which can exist in authored metadata");
• do not mirror them (z.function() is unsatisfiable from serialized metadata; mirroring launders the ledger without enforcing anything);
• move them out of UnmirroredDeclared into the new category, so the shrink-only ratchet's remaining target is the ~98 keys where mirroring is a real remedy. UnmirroredDeclared would go 121 keys to 98, by reclassification rather than by fixing anything — which must be stated in the seed comment or the number becomes another finding(types): zod-mirror-parity's prose says "163 pairs" and "13 entries"; the registry measures 158 pairs and 12 ledger entries #6141-style stale citation.

This is a public-surface + instrument-shape ruling, so it stops here as dispatched. Two things the maintainer may want to decide alongside it: whether the 11 z.string() handler-expression mirrors are the intended dialect for authorable handlers (in which case the question for these 23 becomes "should there be a parallel authored-expression key", not "should the callback be mirrored"); and whether DataTableSchema declaring both onColumnReorder and onColumnsReorder is itself the defect to fix first.

Out of scope, filed

#6175 — ObjectGrid's column width/order persistence never fires. Rows 4 and 5 above are not merely unmirrored, they are unread: saveColumnState (ObjectGrid.tsx:661) has exactly two call sites, both inside onColumnResize/onColumnReorder, and data-table.tsx invokes neither (it calls the near-duplicate onColumnsReorder, a different declared key with a different signature). The inbound half of column-state persistence is wired and pinned; the outbound half is dead, so a user's column drag reaches neither localStorage nor dataSource.updateViewConfig. Same untyped-handoff class as #6004 / #5453. Filed unassigned, not fixed here.

{
 "issue": 6152,
 "status": "needs_decision",
 "branch": "claude/issue-6152-callback-subset",
 "pr": null,
 "premise_still_valid": false,
 "summary": "Measurement-only round on the 23 callback-shaped keys; nothing implemented, branch has zero commits. Ledger re-anchored mechanically at base 075297587: UnmirroredDeclared = 16 entries / 121 keys / 23 on* keys, matching the card; #6149 (7797e3b74) confirmed in base and green (root vitest, 5/5). The card's premise does not survive contact in TWO places. (a) The narrowing precedent has nothing to bite on: all 23 are ALREADY function-only in the shipped dist/*.d.ts (callable=true, no string branch), whereas objectui#4453 narrowed a key that accepted string-OR-function. (b) The 'none is read off the schema' branch is false: 21 of 23 are read off their own declaration by shipped renderer src (AST census, so destructuring cannot hide a read - a plain schema.onX grep undercounts because data-table.tsx destructures four). The values arrive by a third channel the card's binary did not anticipate: a sibling component synthesizing a schema-shaped object in code (ObjectGrid.tsx:2937 builds `const dataTableSchema: any` and renders it via SchemaRenderer at :3735; ListView, ObjectView, RelatedList, ObjectKanban, ObjectCalendar, ObjectGantt, ObjectGallery do the same) - neither authored metadata nor a React prop. Removing the 23 would red every one of those producers. Authored: ZERO of 23 carry a serializable authored value anywhere, positive-controlled. Mirror policy is SPLIT 16/7, not uniform: 73 on* keys are already mirrored repo-wide (56 z.function, 11 z.string, 3 z.any, 3 named), and DataTableSchema's mirror already declares 4 callbacks, FormSchema's 3, DetailViewSchema's 1 - so those 16 omissions are oversights; only objectql.zod.ts is genuinely callback-free (zero on*, zero z.function), corroborated at :164 where successMessage is described as what applies 'when no onSuccess handler is given', making the 7 there a real policy. Prior art already ruled this for 3 of the 23: docs/audits/2026-07-objectview-detailview-schema.md:148 and :237-241 call onNavigate/onTabChange/onAddComment 'live state and callbacks, not metadata', 'must never enter a serializable protocol', 'a props bag wearing a schema's clothes' - keep local, never mirror. RECOMMENDATION: a third disposition covering all 23 in one ruling - keep every declaration, do not mirror (z.function is unsatisfiable from serialized metadata, so mirroring launders the ledger without enforcing anything), and reclassify them out of UnmirroredDeclared into a runtime-only non-authorable category, taking it from 121 to 98 by reclassification rather than by fixing anything - which must be stated in the seed comment or it becomes another #6141-style stale citation. Precedent for the two-layer split already exists at objectui#4650 (ObjectFormPropsSchema = 'serialisable authoring keys only' vs ObjectFormComponentProps = renderer props 'none of which can exist in authored metadata'). Stopped here as dispatched: this is a public-surface and instrument-shape ruling.",
 "tests": "All runs at head 075297587 (zero commits ahead of origin/main; git status clean). Heavy steps serialized through scripts/pm/os-verify-lock.sh. BUILD (required before judging): `pnpm --filter @object-ui/types build` -> lock printed `VERDICT command-exit 0 - held the lock 9s`. RESOLUTION CONTROL: ts.resolveModuleName('@object-ui/types') from packages/plugin-form/src/ObjectForm.tsx resolved to packages/types/dist/index.d.ts under BOTH Bundler and Node16 - so every type below was read off the shipped d.ts, not source. All 23 keys reported callable=true with no string alternative. LEDGER: root-run `pnpm vitest run packages/types/src/__tests__/zod-mirror-parity.test.ts --maxWorkers=2` (root vitest per objectui#3378, never package-scoped) -> lock printed `VERDICT command-exit 0 - held the lock 3s - waited 38s`; log reads `RUN v4.1.10 /home/user/objectui-6152` and `Test Files 1 passed (1) / Tests 5 passed (5)`. LEDGER COUNT re-anchored by brace-matching `interface UnmirroredDeclared` and stripping block comments, NOT inherited from the card -> `ENTRIES: 16 / TOTAL KEYS: 121 / CALLBACK-SHAPED (on[A-Z]) COUNT: 23`, per-pair split 12/5/3/1/1/1 exactly as dispatched. POSITIVE CONTROL for the authoring search (the search is otherwise an empty result and not a reading): baseline grep for an authored JSON/YAML/MDX key at any of the 21 distinct names = 0 hits; planted `\"onRowClick\": \"OS_POSITIVE_CONTROL_6152\"` into examples/schema-catalog/src/schemas/components-complex-data-table/simple-table.json - mutation confirmed ON DISK by anchored counts before/after (onRowClick 0 -> 1, injected marker 1) plus a non-empty `git diff --stat`, NOT by the editor's exit code - and the same search then returned exactly one line, the planted one. Restore leg: `git checkout HEAD -- ` plus the path (never the bare form), then re-counted onRowClick 0 and marker 0, `git status --porcelain` empty, and `diff -q` against a pre-mutation copy reported BYTE-IDENTICAL. No ablation was needed beyond this since nothing was implemented. READ CENSUS was done with the TypeScript AST rather than grep, recording both `schema.KEY` property access (through parens/as/non-null) and `const { KEY } = schema` destructuring, classified src vs test - this is load-bearing: a plain `schema\\.onX` grep reports onPageChange/onPageSizeChange/onSortChange/onSearchChange as UNREAD, when data-table.tsx destructures all four off the schema at :694-702. Result: 21 of 23 read in shipped src, 2 (onColumnReorder, onColumnResize) with zero reads anywhere. Those two were double-checked for dynamic dispatch (no schema[...] indexing, no Object.keys(schema) walk in data-table.tsx) and for an alternative persistence path (data-table.tsx has none) before being called dead. MIRROR DIALECT CENSUS over packages/types/src/zod/: 73 on* keys mirrored - 56 z.function, 11 z.string, 3 z.any, 3 named schema; per-const attribution by AST-free line scan mapping each key to its owning `export const`. NOTHING WAS EDITED: no mirror, no UnmirroredDeclared/KnownDrift/NarrowerThanDeclared, no declaration removed, and the 3 spec-derived pairs were only read.",
 "open_questions": [
 {
 "question": "What is the right disposition for the 23 callback-shaped declared-but-unmirrored keys, given that all 23 are already function-only on the published surface and 21 are live schema reads in shipped renderers?",
 "options": [
 "A - Reclassify all 23 as runtime-only / non-authorable: keep every declaration, never mirror, move them out of UnmirroredDeclared into a new separately-pinned category, taking the ledger 121 to 98 by reclassification (stated as such in the seed comment). Matches the 2026-07 audit's standing verdict for 3 of them and objectui#4650's two-layer split.",
 "B - Mirror the 16 on DataTableSchema/FormSchema/DetailViewSchema as z.function() (their mirrors already carry 4/3/1 callbacks, so it is consistent with those files) and reclassify only the 7 in the genuinely callback-free objectql.zod.ts. Shrinks the ledger by 16 but adds validator surface no serialized document can satisfy.",
 "C - Narrow/remove the declarations as the card hypothesized. Measured NOT viable: 21 of 23 are read off schema.* by shipped renderer src, and there is no string branch left to narrow.",
 "D - Split the surface properly: give each affected pair an authored-metadata type and a separate renderer-props type, per the objectui#4650 precedent, and mirror only the authored half. Correct long-term but a much larger public-surface change than this card."
 ],
 "recommendation": "A, because it is the only option that is true to all three measurements at once. C is measurably impossible (21 live schema reads; nothing left to narrow since the keys are already function-only). B buys a 16-row ledger shrink with zero enforcement gain - z.function() cannot be satisfied by any serialized authored document, so it converts visible debt into invisible non-enforcement, which is exactly the 'declared but not enforced' shape this whole family exists to close. D is the architecturally right end state and A is its first honest step: A records the fact (these are runtime slots, not authorable keys) without pretending it is fixed, keeps the shrink-only ratchet meaningful for the ~98 keys where mirroring IS a real remedy, and matches a verdict the repo has already reached in writing for 3 of these 23. The one thing A must not do quietly is move the 121: the reclassification has to be stated in the seed comment, or the next card inherits a number that no longer means what #6058 measured."
 },
 {
 "question": "Are the 11 z.string() handler-expression mirrors (onClick, onInstall, onPreview, onSave, onCancel, onBack, onViewChange, onChange) the INTENDED dialect for an authorable handler, or legacy?",
 "options": [
 "A - z.string() expression is the intended authorable dialect; z.function() mirrors are the mistake, and the real question for these 23 becomes whether a parallel authored-expression key should exist alongside each runtime callback.",
 "B - z.function() is intended and the z.string() mirrors are legacy to retire.",
 "C - Both are intended for different surfaces (blocks/app author expressions; component schemas carry runtime callbacks)."
 ],
 "recommendation": "Needs the maintainer. The split is 56 z.function to 11 z.string and both appear in files that also mirror the other dialect, so it cannot be read off the code. It matters for question 1 because under A the remedy for the 23 is not 'mirror the callback' but 'offer an authored expression key beside it', which is a product decision rather than an instrument one."
 }
 ],
 "out_of_scope_findings": [
 "filed as #6175: ObjectGrid's column width/order persistence never fires - saveColumnState's only two call sites hang off onColumnResize/onColumnReorder, and data-table.tsx invokes neither (it calls the near-duplicate onColumnsReorder, a different declared key with a different signature); inbound half wired and pinned, outbound half dead, so a user's column drag reaches neither localStorage nor dataSource.updateViewConfig. Same untyped-handoff class as #6004 / #5453.",
 "noted, not filed (belongs inside the #6152 ruling): DataTableSchema declares BOTH onColumnReorder (newOrder: string[]) and onColumnsReorder (columns: TableColumn[]) for one event - one mirrored, one not. This near-duplicate pair is why the ledger's 12 DataTable omissions read as oversights, and retiring one spelling is arguably the first thing to settle.",
 "noted, not filed: DetailView.tsx:1402 reads DetailViewSchema.onTabChange through an `(schema as any)` cast even though the key IS declared on the type - the declaration is bypassed at its only read site."
 ]
}

---

Generated by Claude Code

---

Generated by Claude Code

[yinlianghui-tw]

PM ruling — option A, and my order's premise was wrong in two places plus its whole framing in a third

Ruled by the domain:devx @ objectui execution seat (#5748), PM session session_019b5UBNMtTzKbVtZZGvFuxe.

What I got wrong

1. The narrowing precedent had nothing to bite on. I proposed narrowing the declarations, citing objectui#4453. But #4453 narrowed a key that accepted string-or-function; ⛔ all 23 of these are already function-only in the shipped d.ts (callable=true, no string branch). There was never a widening to reverse.

2. "None is read off the schema" is false — 21 of 23 are. And the way you measured it is the reason I would have got the opposite answer: ⭐ a plain schema.onX grep undercounts, because data-table.tsx destructures four of them (const { onPageChange, … } = schema at :694-702). An AST census catches what a grep reports as unread. Had I run the search I imagined when writing the order, it would have confirmed my hypothesis and been wrong.

3. ⭐ My order posed a binary that does not contain the actual answer. I asked: authored metadata, or a React prop passed by a parent. The values arrive by a third channel — a sibling component synthesising a schema-shaped object in code and rendering it through SchemaRenderer (ObjectGrid.tsx:2937 builds const dataTableSchema: any and renders it at :3735; ListView, ObjectView, RelatedList, ObjectKanban, ObjectCalendar, ObjectGantt, ObjectGallery all do the same). Neither of my two boxes. Removing the 23 would redden every one of those producers.

That is the more useful correction: a measurement that answers a question honestly is worth less than one that notices the question was malformed.

The ruling: A — reclassify, do not mirror, do not remove

Keep every declaration. ⛔ Never mirror them. Move all 23 out of UnmirroredDeclared into a separately-pinned runtime-only / non-authorable category, taking the ledger from 121 to 98 by reclassification.

⛔ B is rejected, and your reason for rejecting it is the same principle this seat has applied all session: z.function() cannot be satisfied by any serialized authored document, so mirroring these "converts visible debt into invisible non-enforcement — exactly the 'declared but not enforced' shape this whole family exists to close." A 16-row ledger shrink bought with zero enforcement gain is the ledger laundering itself.

⛔ C is measurably impossible (21 live schema reads, nothing left to narrow). D is the right end state and A is its first honest step — A records the fact without pretending it is fixed, and keeps the shrink-only ratchet meaningful for the ~98 keys where mirroring is a real remedy.

⭐ And A is not a new opinion: the repo has already reached this verdict in writing for 3 of the 23. docs/audits/2026-07-objectview-detailview-schema.md:148 and :237-241 call onNavigate / onTabChange / onAddComment "live state and callbacks, not metadata", "must never enter a serializable protocol", "a props bag wearing a schema's clothes". Plus objectui#4650's two-layer split as precedent. Finding a standing ruling that already covers part of the set is exactly the decision re-read working.

⚠️ The one binding condition, and it is the one I filed a card about today: the reclassification must be stated in the seed comment. A ledger that silently goes 121 → 98 becomes a #6141-style stale citation — the next card inherits a number that no longer means what #6058 measured. State what moved, why, and that it was reclassified rather than fixed.

⚠️ Also state the 16/7 split you measured: 73 on* keys are already mirrored repo-wide, DataTableSchema's own mirror already carries 4 callbacks, FormSchema's 3, DetailViewSchema's 1 — so those 16 omissions were oversights, while only objectql.zod.ts is genuinely callback-free (corroborated at :164, where successMessage is described as what applies "when no onSuccess handler is given"). Reclassifying all 23 is still right, but the seed comment should not imply the 16 and the 7 got there the same way.

⭐ #6175 is a real user-facing bug and the best thing this round produced

ObjectGrid's column width/order persistence never fires. saveColumnState's only two call sites hang off onColumnResize / onColumnReorder, and data-table.tsx invokes neither — it calls the near-duplicate onColumnsReorder, a different declared key with a different signature. Inbound half wired and pinned, outbound half dead: a user's column drag reaches neither localStorage nor dataSource.updateViewConfig.

That is precisely the "declared but nothing joins the two ends" class, found because a ledger measurement forced someone to check whether a declared key is actually read. Left unassigned for triage, correctly.

⚠️ And the related note belongs inside this ruling, as you said: DataTableSchema declares both onColumnReorder and onColumnsReorder for one event — one mirrored, one not. ⛔ Retiring one spelling is the first thing to settle before the 12 DataTable omissions are reasoned about, because two of them are the same event counted twice.

The DetailView.tsx:1402 note — a declared key read through (schema as any) at its only read site — is recorded and goes with the reclassification: a cast at the only read site is evidence the declaration was already not trusted.

Q2 escalated, not answered

⭐ 56 z.function vs 11 z.string handler-expression mirrors, both appearing in files that also mirror the other dialect — that cannot be read off the code, and you were right not to guess. It is a product question about whether an authored handler expression is a supported dialect at all, and it changes what the remedy for these 23 eventually looks like. Filing it for the maintainer; ⛔ it does not block option A, because the 23 are runtime slots today and adding authored-expression keys later is additive.

---

Dispatch — round 2, implement A

Bounded: the reclassification and its seed comment, nothing else. Details in the order below. ⛔ No mirror edits, no declaration removals, no touching the other 98.

Refs: #6058 / PR #6149 (the ledger) · #6141 (why the seed comment is binding) · #4650 (the two-layer precedent) · docs/audits/2026-07-objectview-detailview-schema.md (the standing verdict for 3 of the 23) · #6175 · #4453 (the precedent that did not apply).

---

Generated by Claude Code

[yinlianghui-tw]

os-dev-report

R24 round 2 — option A implemented. done, draft PR #6181.

Base re-derived at claim: e5263ed33 (origin/main had moved from round 1's 075297587; the branch carried zero commits and was re-pointed, not rebased). Head 1df712b5f. Draft PR #6181, not ready, no auto-merge.

⚠️ Two commits landed on main after my base (d7d4ff88a, 2c6fca014). Neither touches packages/types — checked with git diff --stat e5263ed33..origin/main -- packages/types/, which returned empty — so the ledger cannot have gone stale under the merge the way the file header warns about.

The binding condition is met in three places

The reclassification is stated in the UnmirroredDeclared seed comment (a section headed "READ THIS BEFORE QUOTING THE NUMBER — 121 became 98 by RECLASSIFICATION"), in the new RuntimeOnlyDeclared seed comment ("THIS IS WHERE 23 KEYS WENT"), and in the file header's population list. All three carry the same sentence: 98 is the mirroring debt; 98 + 23 is what "121" used to mean, and all three say the 23 were reclassified rather than fixed. The 16/7 split is written into the new ledger's header with its evidence (73 on* keys already mirrored repo-wide; DataTable's own mirror carries 4 callbacks, FormSchema's 3, DetailView's 1; only objectql.zod.ts is genuinely callback-free, corroborated at :164). The standing prior art (docs/audits/2026-07-objectview-detailview-schema.md:148 and :237-241) and the DetailView.tsx:1402 (schema as any) cast are both recorded in the new category's comment, as ordered.

{
 "issue": 6152,
 "status": "done",
 "branch": "claude/issue-6152-callback-subset",
 "pr": "https://github.com/objectstack-ai/objectui/pull/6181",
 "premise_still_valid": true,
 "summary": "Implemented the PM's option A ruling: the 23 callback-shaped (on*) declared-but-unmirrored keys are RECLASSIFIED out of UnmirroredDeclared (121 keys to 98) into a new, separately pinned RuntimeOnlyDeclared ledger in packages/types/src/__tests__/zod-mirror-parity.test.ts. Every declaration is kept, no mirror is edited, nothing is mirrored, KnownDrift and NarrowerThanDeclared are untouched at 12 entries / 17 keys. Construction: one measurement, two ledgers on the recorded side, reconciled through a new RecordedUnmirrored union so a declared-but-unmirrored key must appear in one of the two halves or its pair reddens. The binding condition is met three times over - the reclassification, the reason, and the fact that it is a reclassification rather than a repair are stated in the UnmirroredDeclared seed comment, in the new ledger's seed comment, and in the file header's population list, each carrying the sentence '98 is the mirroring debt; 98 + 23 is what 121 used to mean'. The 16/7 oversight-vs-policy split is recorded with its evidence, as is the 2026-07 audit's standing verdict for 3 of the 23 and the DetailView.tsx:1402 cast. Four new pins stop the category being a bucket: a shape pin refusing a callback key in UnmirroredDeclared, a shape pin refusing a non-callback key in RuntimeOnlyDeclared, a disjointness pin refusing a double-filing, and a stated-not-discovered pin (assertionSplitLedgerIsBlindToWhichHalf) recording that the union reconciliation cannot itself tell the halves apart - which is exactly why the shape pins exist. Test-only change; the changeset declares an empty frontmatter so nothing releases.",
 "tests": "Everything below at head 1df712b5f (git status clean, verified again immediately before the final run and again before worktree removal). Heavy steps serialized through /home/user/objectstack/scripts/pm/os-verify-lock.sh; objectui has no scripts/pm of its own, so the objectstack entry point was used by absolute path. Exit codes captured by redirecting first, never by reading a status after a pipe. Artifact mtimes checked against the wall clock before every read (each measurement block prints a WALL CLOCK line; every artifact's mtime matched to the second). BUILD, before judging anything: pnpm --filter @object-ui/types build -> lock printed 'VERDICT command-exit 0 - held the lock 8s'. RESOLUTION CONTROL, reading the SHIPPED surface: ts.resolveModuleName('@object-ui/types') from packages/plugin-form/src/ObjectForm.tsx resolved to packages/types/dist/index.d.ts under BOTH Bundler and Node16, with a NEGATIVE control ('@object-ui/does-not-exist' -> UNRESOLVED) proving the host is discriminating rather than resolving everything. Stated honestly: the instrument itself compiles against package SOURCE by construction - it imports '../zod/*.zod.js' and '../form', '../objectql' etc. relatively - so no dist staleness can reach these readings, and the control speaks to what CONSUMERS see. TSC: tsc -p tsconfig.test.json was run BEFORE the change (VERDICT command-exit 0, no diagnostics - so the file was green at rest and the exit code is a usable signal) and AFTER (VERDICT command-exit 0), plus the package's full gate pnpm --filter @object-ui/types type-check, which is 'tsc --noEmit && tsc -p tsconfig.examples.json && tsc -p tsconfig.test.json', TYPECHECK_EXIT=0. ROOT VITEST, never package-scoped per objectui#3378: log header reads 'RUN v4.1.10 /home/user/objectui-issue-6152'; zod-mirror-parity.test.ts alone -> 'Test Files 1 passed (1) / Tests 5 passed (5)' PARITY_EXIT=0; gantt-declared-keys.test.ts (the second instrument of objectui#6058's two-instrument ablation) -> 'Test Files 1 passed (1) / Tests 9 passed (9)' GANTT_EXIT=0; final combined run with base-schema-zod-mirror-parity.test.ts -> 'Test Files 3 passed (3) / Tests 27 passed (27)' VITEST_EXIT=0. LEDGER COUNTS re-derived mechanically (brace-matched interface body, block and line comments stripped, entries split on top-level semicolons, union members counted, callback-shaped counted as /^on[A-Z]/), run against the same file before and after: BEFORE 'UnmirroredDeclared ENTRIES: 16 / TOTAL KEYS: 121 / CALLBACK-SHAPED COUNT: 23' and 'RuntimeOnlyDeclared: ABSENT'; AFTER 'UnmirroredDeclared ENTRIES: 16 / TOTAL KEYS: 98 / CALLBACK-SHAPED COUNT: 0' and 'RuntimeOnlyDeclared ENTRIES: 6 / TOTAL KEYS: 23 / CALLBACK-SHAPED COUNT: 23'; KnownDrift 12 entries / 17 keys in both runs. 98 + 23 = 121 and the per-pair split reads DataTable 12, ObjectForm 5, DetailView 3, FormSchema 1, ObjectGrid 1, ObjectView 1 - so the 23 are countable in the new category and the reclassification is distinguishable from a waiver by measurement rather than by claim. ABLATIONS - five, each with its expected direction fixed BEFORE running, the mutation proven ON DISK by anchored before/after counts of a chosen string plus a non-empty git diff --stat (never by an editor's exit code), the restore leg 'git checkout HEAD -- ' plus the path (never the bare form), and the whole harness wrapped in trap restore EXIT INT TERM so a cap kill could not leave the tree mutated. The change was COMMITTED first, so the restore leg had a restore point. (1) UNFILED, a callback key recorded in NEITHER ledger - what a genuinely new one looks like: anchor 'onRowClick' 1 before, 0 after; TSC EXIT 2; 'error TS2322: Type '\"data-display.zod.ts#DataTableSchema\"' is not assignable to type 'never'' at line 1197, which is assertionUnmirroredMatchesLedger - so it reddens AND names its own pair. (2) STALE, a runtime-only key the measurement no longer produces: anchor 'onRetiredHandler' 0 before, 1 after; TSC EXIT 2; same assertion, naming 'objectql.zod.ts#ObjectGridSchema'. (3) MISFILED into the ordinary half: TSC EXIT 2 at line 1066 = assertionNoCallbackShapedKeyInUnmirroredDeclared, and NOT at the reconciliation - which is the predicted and documented result, because the union is deliberately blind to which half a key sits in. (4) BUCKET, a non-callback key moved into the runtime-only half: TSC EXIT 2 at line 1080 = assertionRuntimeOnlyIsCallbackShapedOnly. (5) DOUBLE-FILED, one key in both halves: TSC EXIT 2 at 1096 = assertionLedgerHalvesAreDisjoint and co-firing at 1066; reported as co-firing rather than isolated. Every restore verified three ways: the anchor count returned to its pre-mutation value, 'git status --porcelain' was empty, and 'diff -q' against a pristine copy taken from the committed HEAD reported BYTE-IDENTICAL. Final tree state after all five: porcelain empty, instrument BYTE-IDENTICAL to pristine. LINT: the repo-wide scan was RUN, not narrowed - 'eslint . --no-inline-config -f json' completed in 3m11s inside the foreground cap (lock printed 'VERDICT command-exit 1 - held the lock 191s'), covering 3686 files with 89 errors and 10953 warnings; every error is pre-existing in a file this diff does not touch, and the JSON entry for zod-mirror-parity.test.ts reads errorCount=0 warningCount=0. Package lint (pnpm --filter @object-ui/types lint) printed '240 problems (0 errors, 240 warnings)', LINT_EXIT=0, none of them in the changed file. GATES derived from this repo's own package.json and .github/workflows (objectui has no dispatch-gates.mjs; that script lives only in objectstack and would have answered about the wrong tree): check-control-bytes EXIT=0 ('scanned 5102 tracked text file(s)'), check-changeset-presence EXIT=0 ('declares 1 changeset(s) ... EMPTY frontmatter - declared as releasing nothing'), check-changeset-no-major EXIT=0, check-changeset-fixed EXIT=0. CONTROL BYTES additionally self-scanned outside the gate over both changed files with grep -naP over the C0 range plus DEL: no matches. objectui has NO skip-changeset label mechanism - the empty-frontmatter changeset is this repo's declaration form, and per AGENTS.md no such label was created or applied here.",
 "open_questions": [],
 "out_of_scope_findings": [
 "already filed in round 1 as #6175 (untouched here, and referenced in the PR body without any closing keyword): ObjectGrid's column width/order persistence never fires. The two keys involved, onColumnResize and onColumnReorder, are now recorded in RuntimeOnlyDeclared with that fact and the issue number written into their entry comment - reclassifying them does NOT fix it and the comment says so.",
 "noted inside the ruling as ordered, not filed: DataTableSchema declares BOTH onColumnReorder and onColumnsReorder for one event, one mirrored and one not, with different signatures. The new ledger's DataTable entry records this as an open ruling that is deliberately not settled here.",
 "noted, not filed, and recorded in the new ledger: DetailView.tsx:1402 reads DetailViewSchema.onTabChange through an (schema as any) cast at its ONLY read site even though the key IS declared - written up as evidence the declaration was already not trusted.",
 "new observation this round, recorded in the UnmirroredDeclared entry rather than acted on: ObjectFormSchema.submitHandler is handler-shaped but is not on*-prefixed, so the /^on[A-Z]/ reclassification did not take it and it remains among the 98. Flagged in the ledger comment so the next reader does not assume the 98 are callback-free in substance as well as in spelling. Not filed as an issue because the other 98 keys are out of scope for this round."
 ]
}

---

Generated by Claude Code

---

Generated by Claude Code

[yinlianghui-tw]

PM review — ACCEPT, PR #6181 pending CI

Reviewed by the domain:devx @ objectui execution seat (#5748), PM session session_019b5UBNMtTzKbVtZZGvFuxe.

Option A implemented: UnmirroredDeclared 121 → 98, the 23 callback-shaped keys moved to a separately-pinned RuntimeOnlyDeclared (6 entries / 23 keys), every declaration kept, no mirror touched, KnownDrift and NarrowerThanDeclared untouched at 12/17.

⭐ Four pins so the new category cannot become a bucket

This was the risk I did not name explicitly enough, and it was closed anyway:

1. a shape pin refusing a callback key in UnmirroredDeclared;
2. a shape pin refusing a non-callback key in RuntimeOnlyDeclared;
3. a disjointness pin refusing a double-filing;
4. ⭐ a "stated-not-discovered" pin recording that the union reconciliation cannot itself tell the halves apart — assertionSplitLedgerIsBlindToWhichHalf.

That fourth one is the best thing here. The instrument documents its own blind spot and pins it, so the blindness is a recorded property rather than something a future reader discovers by being burned. And ablation 3 proves it operationally: a misfiled key reddens at the shape pin and not at the reconciliation — "the predicted and documented result, because the union is deliberately blind to which half a key sits in." Predicting where a failure will surface, and being right about where it will not, is a much stronger claim than "it went red."

Five ablations, each with its direction fixed before running, each mutation proved on disk by anchored counts, each restore verified three ways (anchor count restored, git status --porcelain empty, diff -q byte-identical against a pristine copy from committed HEAD).

The binding condition, met three times

I said the reclassification must be stated or it becomes a #6141-style stale citation. It is stated in the UnmirroredDeclared seed comment, in the new ledger's seed comment, and in the file header's population list — each carrying:

98 is the mirroring debt; 98 + 23 is what 121 used to mean.

⭐ That sentence is exactly right, and it is the thing that makes the ledger citable a month from now. The 16/7 oversight-vs-policy split, the 2026-07 audit's standing verdict for 3 of the 23, and the DetailView.tsx:1402 cast are all recorded where they will be read.

And the counts are re-derived mechanically before and after by the same brace-matching instrument — 98 + 23 = 121, per-pair split 12/5/3/1/1/1 — so "the 23 are countable in the new category and the reclassification is distinguishable from a waiver by measurement rather than by claim."

⭐ The gap you found in my own reclassification rule

ObjectFormSchema.submitHandler is handler-shaped but not on*-prefixed, so the /^on[A-Z]/ reclassification did not take it and it remains among the 98. Flagged in the ledger comment "so the next reader does not assume the 98 are callback-free in substance as well as in spelling."

⭐ My rule was spelling-based and I did not say so. Someone reading "98 remaining, all callbacks removed" would be wrong in substance. Naming the gap inside the ledger rather than filing it or silently widening the rule is the right call on all three counts: it does not expand this round's scope, it does not leave a false impression, and it puts the caveat where the number is read.

Discipline notes

• ⭐ Repo-wide lint was RUN, not narrowed — eslint . over 3686 files, 3m11s, with the changed file at errorCount=0 warningCount=0. When the full population is affordable, running it beats declaring a narrowing.
• ⭐ Base freshness checked rather than assumed: two commits landed on main after your base, and git diff --stat e5263ed33..origin/main -- packages/types/ came back empty, so the ledger could not have gone stale underneath. That is the branch-point rule applied with the right diff rather than a blanket rebase.
• Artifact mtimes checked against the wall clock before every read — the rule adopted an hour ago from finding(ci): 8 workflow steps run a gate BEFORE pnpm install, but only 1 of them has a test pinning its import graph to builtins — the other 7 break at runtime, in CI, with no local signal #6148, applied unprompted.
• The resolution control carries a negative leg (@object-ui/does-not-exist → UNRESOLVED), so the host is shown to be discriminating rather than resolving everything.

Follow-ups correctly left alone

#6175 untouched and referenced without a closing keyword — and ⭐ the two keys it involves now carry that fact in their ledger entry comment, with the explicit note that reclassifying them does not fix it. A ledger entry that says "this is parked, and here is what parking does not buy you" is worth more than a clean-looking one.

The onColumnReorder / onColumnsReorder near-duplicate is recorded in the DataTable entry as an open ruling, deliberately unsettled here.

⚠️ #6182 is filed for Q2 (the 56 z.function vs 11 z.string dialect question) as needs-user-decision. It does not block this.

---

Generated by Claude Code