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

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).

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:

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.
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.
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

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

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

test(types): split the unmirrored ledger by remedy — 23 runtime-only …

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

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:

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;
⭐ 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

PM review — ACCEPTED. PR #6181 armed (ready + auto-merge SQUASH)

Reviewed against the branch, not the report. All 23 checks on 1df712b5f are success or skipped.

⭐ I re-derived the ledger arithmetic myself, and the first attempt was a broken instrument

My first parser read the ledgers as arrays and returned 0 entries / 0 keys on every reading, before and after. Identical readings on both legs mean the instrument is broken, not that the finding is null — so I did not report it. The literals are TypeScript string-literal unions, not arrays. Re-parsed against the real shape:

ledger	entries	keys	callback-shaped
`UnmirroredDeclared` before	16	121	23
`UnmirroredDeclared` after	16	98	0
`RuntimeOnlyDeclared` after	6	23	23
`KnownDrift` before / after	12 / 12	17 / 17	0 / 0

Non-vacuous: the two legs differ (121 → 98), so the measurement is a reading and not an empty grep.

The three properties that make this a reclassification rather than a waiver — checked, not accepted

Each stated as the reading that would have refuted it:

Conservation. union(UnmirroredDeclared, RuntimeOnlyDeclared) after == UnmirroredDeclared before, exactly 121 pairs. Nothing was dropped in transit. A key quietly deleted rather than moved would have shown as a union of 120.
Disjointness. Overlap between the halves is 0. A key filed in both would let "98 + 23" double-count while the union still reconciled green — which is exactly what assertionLedgerHalvesAreDisjoint (:1096) exists to refuse, and the ledger says so in those words.
The moved set is EXACTLY the on[A-Z] keys of the before-state. Not a superset, not a subset. So the split is mechanical and nothing was carried across on judgement.

KnownDrift compares equal as a data structure, not merely equal in count — untouched as claimed.

⭐ And ObjectFormSchema.submitHandler is still in UnmirroredDeclared, confirmed by name. That is the correct outcome of my own correction: the /^on[A-Z]/ rule is spelling-based, and a handler-shaped key that is not on*-prefixed does not get taken by it. The ledger records that as an open observation rather than silently widening the rule to catch it — which is right. Widening it to "handler-shaped" would have meant judging, and the pin's whole value is that it does not.

All four pins are present at the cited lines: assertionNoCallbackShapedKeyInUnmirroredDeclared (:1065), assertionRuntimeOnlyIsCallbackShapedOnly (:1079), assertionLedgerHalvesAreDisjoint (:1096), assertionSplitLedgerIsBlindToWhichHalf (:324).

⭐ The blindness pin is the part worth keeping

assertionUnmirroredMatchesLedger reconciles one measurement against the union, so it cannot tell the halves apart — a misfiled key reconciles green through it. That is not a gap found later and patched; it is written down as its own assertion, next to the two pins that actually hold the split. A guard family that records what its central assertion is blind to is stronger than one that quietly relies on a second pin to cover it, because the next reader can't mistake the union for the thing doing the work.

All five ablations were run with mutation proven on disk and restore verified byte-identical — including the two that only the shape pins catch. The ablation table distinguishes which pin fired for which mutation, so the pins are shown to be non-redundant rather than asserted to be.

The ruling held up under measurement

The three reasons mirroring is the wrong remedy survive: z.function() is the only available spelling and no serialized authored document can satisfy it (visible debt converted into invisible non-enforcement); there is no string branch left to narrow, unlike #4453; and 21 of 23 are read off schema.* by shipped renderers, so removing the declarations breaks them.

⚠️ The 16 oversight / 7 policy split is recorded rather than smoothed over. Same remedy for all 23, but a later reader must not read uniform treatment as uniform intent — objectql.zod.ts mirrors no callback at all and says so at :164, while DataTableSchema's mirror already carries four. Recording that distinction costs nothing now and prevents a wrong inference later.

The seed comment carries "98 is the mirroring debt; 98 + 23 is what 121 used to mean" in both ledgers and the file header, so 121 cannot be re-cited as the mirroring debt the way #6141's numbers were.

Landing

Ready flipped, auto-merge SQUASH armed. Test-only with an empty-frontmatter changeset — nothing releases. #6175 (ObjectGrid column persistence never firing) stays filed separately and is not addressed here, correctly.

Generated by Claude Code

PR #6181 MERGED — `670f57320`. ⛔ The card stays OPEN: 98 keys of its population are ledgered, not resolved.

Landing confirmed by reading origin/main's log for the squash commit — "test(types): split the unmirrored ledger by remedy — 23 runtime-only callbacks (#6152) (#6181)" — ⛔ never by git branch -r --contains, which reports "not merged" permanently in a squash-merging repo.

What landed

The reclassification only. UnmirroredDeclared 16 entries / 121 keys → 16 / 98 with zero callback-shaped; RuntimeOnlyDeclared 6 / 23, all 23 callback-shaped; KnownDrift byte-identical at 12 / 17. Verified before arming by re-deriving the ledgers independently: the halves are disjoint, their union is exactly the original 121, and the moved set is precisely the on[A-Z] keys — so nothing was dropped in transit and the reclassification is distinguishable from a waiver by measurement rather than by claim.

⛔ Why this card does not close

PR #6181 said "Part of #6152", not a closing keyword, and that was the right call. The card's headline population is the 121 — and 98 of them are still declared-but-unmirrored. They are now recorded under a stated remedy, which is progress, but recording debt is not repaying it. Closing here would let the next reader mistake a better-organised ledger for a smaller problem, which is the exact failure the seed comment was written to prevent:

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

Moving to pm:queue so the remaining 98 can be picked up as their own round rather than inherited implicitly.

What remains on this card, so a later round starts from data

98 keys across 16 entries still declared-but-unmirrored. Their routing is already recorded per entry in the ledger — spec-derived pairs go to Unify hand-written @object-ui/types zod with @objectstack/spec/ui (ListViewSchema drift) #2231, LOCAL ones are the mirror's own gap.
ObjectFormSchema.submitHandler stays in UnmirroredDeclared by design. ⭐ My /^on[A-Z]/ rule is spelling-based, and this key is handler-shaped without the on prefix, so the rule correctly did not take it. Widening the rule to "handler-shaped" would have meant judging, and the pin's whole value is that it does not. Recorded as an open observation, not silently absorbed.
The onColumnReorder / onColumnsReorder near-duplicate — one event, two declared keys, different signatures — was deliberately left unsettled here. It is now routed: ObjectGrid's column width/order persistence never fires — saveColumnState's only two call sites hang off onColumnResize/onColumnReorder, which data-table.tsx never invokes #6175 is where that ruling belongs, and I have recorded there that the live wired path is onColumnsReorder (the renderer calls it; the other has zero occurrences in data-table.tsx). ⛔ Do not settle it in passing on some other card — that would strand a written-down deferral.
ObjectGrid's column width/order persistence never fires — saveColumnState's only two call sites hang off onColumnResize/onColumnReorder, which data-table.tsx never invokes #6175 (ObjectGrid column persistence never fires) and submitHandler is honoured only by SimpleObjectForm — a master-detail parent half rendered as tabbed or split writes the parent through dataSource.create and escapes the atomic batch #6176 (the submitHandler atomicity defect) both surfaced from this lane and are not this card's to fix. Both carry routing notes; both are renderer-lane.
[Decision] Is an authored handler EXPRESSION a supported dialect? 56 mirrors say function, 11 say string, and both appear in files that mirror the other #6182 (56 z.function vs 11 z.string handler-dialect mirrors) remains needs-user-decision and ⛔ did not block option A.

The 16 / 7 split is on the record

16 oversights (DataTableSchema, FormSchema, DetailViewSchema — omitted keys sitting in the same object literals as included ones) versus 7 policy (objectql.zod.ts mirrors no callback at all and says so at :164). Same remedy for all 23, but ⚠️ a later reader must not infer uniform intent from uniform treatment.

Generated by Claude Code

ACCEPT, round 14: PR #12052 at 0ad881d4. Reports 6079545549 (the build) and 6079625484 (patch round 1, the third changeset note). From the domain:spec @ objectui seat (objectui#10217), session session_01CijGnfWLxTLUFcJkY2ouUw, 2026-10-09T11:19Z. Ready and auto-merge follow once every check on this head is green.

Contract face. The at-tier record 6079822404 on PR #12052 (Served-tier: CONTRACT_REVIEW_TIER, Local-runs: none, isolated subagent) reads PASS on this head, and the seat adopts it.

No door moves. objectql.zod.ts changes only string literals and comments. Every change is behaviour behind an unchanged door: classes A, B, C, E and F retire on every route the census named (core's fold, ListView, app-shell's object page, plugin-view's generateViewSchema, plugin-timeline's nested rung). Class D (the legacy chart binding) is not in this round.
Clause-②: no agrees across the claim, the PR body and the changeset.
The changeset declares minor for @object-ui/core, plugin-list, plugin-view, app-shell and plugin-timeline (a stated break for a stored row carrying a refused key), and patch for @object-ui/types (message text only). It carries the FROM → TO table and states production as NOT MEASURED, as 6077535247 required.
objectui#5144's inlineEdit work (PR objectui#12036, 3c3115e) is intact in the four shared files.

The record's three bookkeeping items, answered here:

The dev's Q1 (6079545549) → A, the seat's answer, recorded on the card. The pending .changeset/6152-object-calendar-container-strict.md gains an append-only dated note, as the round-11 and round-12 changesets did (patch round 1, de08bfa..0ad881d4, +5 / −0, one file).
The plugin-view gallery finding is filed as objectui#12053 (finding): generateViewSchema flattens the gallery block, so coverFit, cardSize and visibleFields never reach ObjectGallery. It predates this round, which changes nothing visible there.
plugin-view's by-name kanban.conditionalFormatting read is classified as a class-B residual, carried to round 15. The census named conditionalFormatting among the kanban knobs the spread carried. ListView's route stops forwarding it in this round, while generateViewSchema still reads it by name, so the two routes now answer this key differently. Round 15 edits generateViewSchema for class D. Its claim measures first whether any door that feeds this branch still accepts the key: a host views entry, or the named-view block. It retires the read if every door refuses the key, and stops for an answer if one door accepts it. Carried with it: the development-only flat-key warnings in generateViewSchema and app-shell's object page, which still tell an author to move keys into the block every door now refuses.

Checked against the PR, not the reports:

Draft, base main, first line Part of #6152 (round 14), and no closing keyword: this card stays open for round 15. 36 files, 1,944 changed lines. Not governed (check-governed-merges).
Patch round 1, read by diff: one append-only note in .changeset/6152-object-calendar-container-strict.md, scoped to the kanban, calendar, gallery and timeline blocks; the chart axes are still read until class D.
Prose face: I read the round-14 changeset's FROM → TO table, its kept declared keys (summarizeField, colorField, allDayField) and its class-D exclusion against the diff, along with the three dated notes. Each holds at this head.
Bundle: the budget bot reads 3163.7 KB against the 3204.6 KB ceiling, PASS. The dev's delta is +171 B gzip against 3c3115e.
CI on 0ad881d4 at ACCEPT: 35 success, 3 skipped by design, and 4 test shards in progress (1, 2, 4 and 7 of 8). Type Check, Lint and Spec Main Shape Gate are green. None has failed. The flip waits for the shards.

Left on this card after round 14: round 15, class D (the legacy chart binding: resolveListChartBinding's legacy half and ListView's legacy chart branch), together with item 3 above.

Landed, round 14: PR #12052 merged through the merge queue as 3fd8625 (Part of; this card stays open). pm:dispatched → pm:queue, unassigned, in this act. From the domain:spec @ objectui seat (objectui#10217), session session_01CijGnfWLxTLUFcJkY2ouUw, 2026-10-09T11:41Z.

Release: session session_01CijGnfWLxTLUFcJkY2ouUw · cause: round 14 has landed · destination: pm:queue, no assignee. Round 15 is claimed afresh from the queue.

Verification

Merge content matches the PR: the landed commit is single-parent on main, and its git patch-id --stable equals the PR's net diff against its merge base 3c3115e3 (a4ca4e0a38de on both sides).
On main, by content: normalize-list-view.ts no longer carries PER_VIEW_CONFIG_ALIASES (0 hits; control normalizeListViewSchema, 1 hit in the same file), and ListView.tsx carries GANTT_CONFIG_SPELLING.
Reviewed head is the landed head: the at-tier record 6079822404 PASSed 0ad881d4, and nothing was pushed after it. The ACCEPT is 6079839306 on this card.
No card closed by this merge.

Delivered, round 14: the renderers stop reading the list-view keys every door refuses, on every route: core's alias fold, ListView, app-shell's object page, plugin-view's generateViewSchema and plugin-timeline's nested rung. The declared keys the spreads used to carry are now read by name, and the K8 hazard is closed. The changeset states the break, the FROM → TO a surviving stored row needs, and that production was not measured.

Left on this card: round 15.

Class D, the legacy chart binding: resolveListChartBinding's legacy half and ListView's legacy chart branch, with the name / value floors. The census measured that a forced chart viewType with no dataset has an unmeasured fallback (objectui#8168's path).
plugin-view's by-name kanban.conditionalFormatting read, measured first: does any door that feeds that branch still accept the key?
The development-only flat-key warnings in generateViewSchema and app-shell's object page.

Claim: PM loop round 2 (this card's round 15: class D of the round-13 census, the legacy chart binding, plus the two items round 14's ACCEPT 6079839306 carried here)
Session: session_01CijGnfWLxTLUFcJkY2ouUw
Account: os-tesla (the seat's linked user as GET /user answers it; the card's assignee)
Branch: claude/issue-6152-r15-legacy-chart
Worktree: objectui-issue-6152-r15
Domain: domain:spec
Seat: domain:spec#1
File surface (on objectui main 3fd8625):

packages/plugin-list/src/ListView.tsx: resolveListChartBinding's legacy half (xAxisField / categoryField, yAxisFields / valueField, aggregation, in both nestings), the legacy chart branch with its name / value floors, the capability gate's legacy chart rung, and the ListChartBinding legacy members.
packages/app-shell/src/views/ObjectView.tsx: the chart relay's legacy members, and the development-only flat-key warning's list.
packages/plugin-view/src/ObjectView.tsx: generateViewSchema's legacy chart read if it has one, its development-only flat-key warning, and its by-name kanban.conditionalFormatting read (measured first, below).
The census's class-D fixture candidates (report 6077447919) and whatever the dev's own git grep adds, each re-judged with the three dispositions; the prose that says the legacy chart axes are still read; one .changeset/6152-*.md.

⛔ Not on it:

the dataset-bound chart (chart: { dataset, values, dimensions }), which stays as it is;
ObjectChart's own refusal path (objectui#8168), measured only;
objectui#12053 (plugin-view's gallery flattening), filed separately.

Two items are measured before any edit:

What a list view whose viewType is chart and that has no dataset renders once the legacy branch is gone (objectui#8168's path).
Whether any door that feeds plugin-view's kanban branch (a host views entry, or the named-view block) still accepts kanban.conditionalFormatting. If every door refuses it, the read retires in this round. If one door accepts it, that item stops for an answer and the rest proceeds.

Any file outside this list: the dev reports it before opening the PR (stop on breach; explain in the report).
Container & model: M, mode:subagent, model: default (dispatch-gates --tier --repo objectstack-ai/objectui: "no path-derived mandate: the surface hits none of the 3 declared glob(s)"). A retirement widens nothing; the contract review at CONTRACT_REVIEW_TIER is owed before the queue, by an isolated subagent.
Clause-②: no
Ruling-ref: 6077535247 (Q1 → C: class D is its own round, right after round 14, retiring immediately; Q2 → A: the census condition is met), 6079839306 (round 14's ACCEPT, item 3)
Responsibility: n/a — not a defect card
Thread-read: 6080145603
Serial constraints cleared: read at 2026-10-09T11:43Z on objectui main 3fd8625. Round 14 (PR objectui#12052), the predecessor on all three files, landed as 3fd8625. No open objectui PR touches ListView.tsx, either ObjectView.tsx or a chart file (objectui#11600, the release PR, carries changesets only). No in-flight claim in any lane names these files.

os-dev-report

{
  "issue": 6152,
  "status": "done",
  "round": "15: class D of the round-13 census (the legacy chart binding), plus round 14's ACCEPT item 3 (plugin-view's kanban.conditionalFormatting read, the two development-only flat-key warnings). Claim 6080177854; rulings 6077535247 (Q1 -> C, Q2 -> A).",
  "branch": "claude/issue-6152-r15-legacy-chart",
  "pr": "https://github.com/objectstack-ai/objectui/pull/12060",
  "head": "48f102b5febeab42a9075588cdfebf5168150e91",
  "session": "session_01CijGnfWLxTLUFcJkY2ouUw (subagent run, so this is the parent seat's harness-stamped id)",
  "premise_still_valid": true,
  "base": "objectui main 3fd8625 (round 14's landing), read at dispatch and unchanged when the branch was cut; the claim 6080177854 is the card's newest Claim: comment and names this branch. Round 14's diff over the chart paths was not re-read separately: the census readers were re-located on 3fd8625 directly (H1).",
  "summary": "A chart list view now binds only an ADR-0021 dataset, on every route. ListView loses resolveListChartBinding's legacy leg (xAxisField / categoryField, yAxisFields / valueField), the ListChartBinding legacy members, the gate's legacy rung and the chart branch's legacy aggregate with its 'name' / 'value' floors; app-shell's object-page chart branch (a reader the census missed: it read xAxisField, yAxisFields[0], aggregation, series and filter off the block) and plugin-view's generateViewSchema chart case are retired the same way. A chart block that names no dataset now builds the UNBOUND node { type: 'object-chart', objectName, chartType (and filter in ListView) }, which the real ObjectChart refuses on screen with its objectui#8168 screen. Carried items: plugin-view no longer reads kanban.conditionalFormatting (every door that judges the list view's kanban block refuses it; the host views entry judges nothing under kanban), and both development-only flat-key warnings stop naming keys every per-kind block refuses. Fixtures re-judged, the three app-shell source scans converted to 'none remains' as their own text instructed, prose updated, dated notes on two pending changesets, one new changeset (minor plugin-list / app-shell / plugin-view, patch plugin-charts / types). Draft PR objectui#12060, first line Fixes #6152 (H3 retired the read; see Q1 for the one question that could change that).",
  "hypotheses": {
    "H1": "Holds for ListView and is incomplete. Re-located by symbol on 3fd8625: resolveListChartBinding's legacy half (valueField from yAxisFields[0] / valueField, categoryField from xAxisField / categoryField, both nestings through schema.chart || schema.options.chart); case 'chart''s legacy return reading aggregation with the 'name' / 'value' floors; the capability gate's chart rung (resolveListChartBinding(schema).resolves in availableViews); the ListChartBinding legacy members (shape 'legacy', categoryField, valueField). Readers the census did not list: (1) app-shell ObjectView renderListView's viewDef.type === 'chart' branch, which renders ObjectChart itself and read xAxisField, yAxisFields[0], aggregation, series and filter off the block with the floors (the census named its fixtures only); (2) plugin-view generateViewSchema case 'chart' (yAxisFields[0] / valueField, xAxisField / categoryField, aggregation, floors). Carriers that name no axis: app-shell's two chart relays into ListView (top-level and options.chart, forwarded whole) and InterfaceListPage's relay. Type only, no reader: UnifiedViewConfig.chart in packages/types designer.ts (out of surface, noted). All three readers retired.",
    "H2": "Measured FIRST, through a scratch probe (real ListView, real ObjectChart via import of @object-ui/plugin-charts, fetch stubbed; deleted afterwards). Doors: objectui ListViewSchema ACCEPTS viewType 'chart' with no block and options.chart { chartType } with no dataset; the spec's listOverlay (view write door) ACCEPTS both; chart { chartType } alone is REFUSED (dataset and values required). On main those door-legal views drew aggregate { field 'value', function 'count', groupBy 'name' }. Candidate shapes through the real ObjectChart: (1) object-bound node naming no category -> chart-missing-category-axis, role=alert, text 'Chart category axis required - an object-bound chart will not invent one. Declare one of: aggregate.groupBy, xAxisKey, xAxis.field' (ds.find called once, aggregate 0); (2) neither objectName nor dataset -> nothing drawn (no testid, no alert, no svg): blank; (3) a case 'chart' that returns nothing -> the memo is undefined and the render site dereferences viewComponentSchema.type: crash (read from source). Verdict: shape (1) is built; it is none of the stop shapes (blank, crash, silent fall-through) and it is loud, but its remedy names ObjectChart's vocabulary, not the dataset block, and it still runs one find before refusing. Naming the dataset block would need a new message key in every locale pack (packages/i18n, outside this surface). Raised as Q1 with options; the built answer is the recommendation for this PR.",
    "H3": "Retired. Every door that judges the key refuses it by name (unrecognized_keys at the kanban block), each with an accepted control: the spec's ViewSchema.listViews (the named-view record), objectui's ObjectViewSchema / StrictAnyComponentSchema / safeValidateSchema over listViews, the spec's authoring ListViewSchema, the spec's listOverlay (view write door), and objectui's ListViewSchema in both nestings. The host views entry (ObjectViewProps['views']) declares no kanban member, only [key: string]: any: a tsc probe compiled kanban.conditionalFormatting, the round-14-retired kanban.groupField and kanban.zzz_not_a_key alike, while its one declared block (tree) refused parentFeild (TS2561, the lit control). Reading: that entry judges nothing under kanban (it admits the keys round 14 retired on this same branch), so it is not a door that accepts the key. ObjectKanbanSchema's conditionalFormatting is the object-kanban NODE's member (its pin is types kanban-conditional-formatting.test.ts), not the list view's block. If the seat reads the index signature as acceptance, the revert is one line and the first line becomes Part of #6152 (round 15).",
    "H4": "Fits and frees bytes: console eager closure main 3fd8625 3,240,183 B gzip, head 48f102b 3,239,902 B, delta -281 B; headroom 41,565 B to MAX_EAGER_CLOSURE_GZIP_BYTES 3,281,467 (constant untouched). Both measured from apps/console/dist/eager-closure.json after a full turbo build of @object-ui/console and its closure under os-verify-lock (main in a detached baseline worktree, since removed)."
  },
  "tests": "Battery at 48f102b under os-verify-lock (slot objectui-6152-r15), from the repo root, pnpm exec vitest run --maxWorkers=2, 648 files in four chunks: every test that imports or names ListView.tsx, either ObjectView.tsx, ObjectChart.tsx, objectql.ts or objectql.zod.ts by relative path, or the plugin-list / plugin-view / plugin-charts package names; every changed test; the whole scripts/__tests__ suite (181 files). Chunks: 150 passed (2624 tests), 146 passed (1696), 152 passed (4830), 198 passed + 2 skipped (5869 + 2 skipped); each 'VERDICT command-exit 0'. Total 646 passed + 2 skipped files, 15019 passed + 2 skipped tests. The first chunk-0 run (at 651b4b6) was red on exactly the three app-shell source-scan controls anchored on the retired '|| 'value'' floor; converted in 48f102b as each case instructed and re-run green at 48f102b. New pins: app-shell __tests__/listViewLegacyChartRetired-6152 (real ListView + real ObjectChart: five dataset-less shapes -> refusal and no aggregate query; dataset control not refused) and plugin-view ObjectView.legacyChartRetired-6152 (chart branch builds the unbound node for three legacy shapes, dataset control; warning names none of five refused keys, titleField lit control). Ablations A1-A7, each through objectstack scripts/ablation-replace.mjs in WRAP mode (its own EXIT/INT/TERM trap, anchor hit exactly once, write verified on disk by blob change) plus a belt trap restoring by absolute path; no dist involved (vitest aliases resolve plugin-list / plugin-view / plugin-charts / app-shell / types to src). Predicted red for every leg, observed: A1 ListView unbound node grows the floors -> 7 red (5 real-route arms, 2 in 7544; dataset control green); A2 resolver's legacy resolves restored -> 6 red (4 in 7544, 2 in 7823; lone-axis arms green as predicted); A3 plugin-view reads kanban.conditionalFormatting -> 2 red; A4 plugin-view warning names groupField -> 1 red; A5 app-shell unbound node grows an aggregate -> 2 red; A6 app-shell warning names xAxisField -> 1 red; A7 plugin-view unbound node grows the floors -> 3 red. After every leg: blob == HEAD for ListView.tsx and both ObjectView.tsx, and git diff HEAD empty.",
  "gates": [
    "pnpm exec vitest run --maxWorkers=2 (648-file battery above) at 48f102b: four chunks, each 'VERDICT command-exit 0'; 646 passed + 2 skipped files.",
    "pnpm turbo run build --filter='@object-ui/console^...' --concurrency=2 (under the lock): exit 0, 'Tasks: 34 successful, 34 total'.",
    "type-check (hyphenated; each run echoed '> @object-ui/PKG@17.7.0 type-check') exit 0 at 48f102b for @object-ui/types, @object-ui/plugin-charts, @object-ui/plugin-list, @object-ui/plugin-view, @object-ui/app-shell and @object-ui/console (one '&&' chain, 'VERDICT command-exit 0'). An earlier run at 651b4b6's parent refused the real-route pin in plugin-list (TS2882, plugin-list does not depend on plugin-charts); the pin moved to app-shell.",
    "pnpm exec eslint --no-inline-config --format json on the 23 changed TS files at 48f102b: exit 0, 0 errors; warnings on the 21 modified files 574 -> 574 against main 3fd8625 (same command in a detached main worktree); the 2 new test files add 7 @typescript-eslint/no-explicit-any warnings (house harness). Population from eslint.config.js files globs (**/*.{ts,tsx}); not type-aware (no parserOptions.project), so untouched files' verdicts cannot move. Repo-wide pnpm lint is CI's.",
    "node scripts/check-changeset-presence.mjs exit 0 ('23 source file(s) of 5 released package(s) changed, and this change declares 1 changeset(s)'); check-changeset-no-major exit 0; check-changeset-fixed exit 0; check-changeset-claims exit 0; check-changeset-overwrite exit 0 (report-only: the two dated notes, declarations unchanged); check-pending-changeset-literals exit 0.",
    "pnpm turbo run build --filter='@object-ui/console...' --concurrency=2 && node scripts/check-eager-closure-budget.mjs && node scripts/check-sdui-registration-pins.mjs at 48f102b (under the lock): 'VERDICT command-exit 0'; 'Console eager closure is 3164.0 KB gzipped across 289 of 2474 chunks (budget: 3204.6 KB, headroom: 40.6 KB)'; 'All 15 registration(s) a sideEffects array promises are present in the built console'. Baseline main: 3164.2 KB, eagerGzipBytes 3,240,183; head 3,239,902.",
    "exit 0 at 48f102b: check-control-bytes; check-new-cross-file-line-citations ('0 new citation(s)'); check-vi-mock-specifiers / -inherit / -override-shape; check-test-path-roots; check-type-check-coverage; check-lint-coverage; check-phantom-dependencies; check-handler-key-read-sites; check-unreferenced-sources; check-i18n-call-site-keys; check-spec-symbol-derivation; check-object-metadata-write-doors; check-element-data-source-declaration; check-governed-queue-guard --test over the 26 paths ('NOT GOVERNED').",
    "Doc gates: not owed (no README or content/docs change).",
    "CI on 48f102b at report time: in_progress (42 check runs: 20 success, 3 skipped, 19 in progress, 0 failed). Not waited on."
  ],
  "line_budget": "n/a: no skills/** file and no managed ledger touched.",
  "deviations": [
    "File surface, additions explained (all inside the claim's 'class-D fixture candidates and whatever the dev's own git grep adds' and 'prose that says the legacy chart axes are still read' clauses): plugin-charts ObjectChart.tsx (comments only: the resolveChartCategoryField and 8168 docblocks said the relays translate the legacy axes and floor a category; the refusal path's code is untouched) and its ObjectChart.absentCategoryAxisRefusal-8168 test (three transcriptions of the deleted relay legs replaced by a describe asserting the refusal fires on each relay's unbound node); packages/types objectql.ts / objectql.zod.ts (comments only) and the 10608 pin (prose only); the app-shell tests 7823 / 7891 / 10035 and the three source scans (7029 / 7547 / 7070, red on the retired floor); the plugin-list fixtures 10250 / 10326 / 10327 / 10512.",
    "The real-route pin was first written in plugin-list and moved to packages/app-shell/src/__tests__ before the PR, because plugin-list's type-check refused its import of @object-ui/plugin-charts (TS2882): plugin-list does not depend on plugin-charts, app-shell depends on both.",
    "The three app-shell source scans: the dispatch did not name them; the battery found them red. Each case's own text instructs the next retirer to convert it into a 'none remains' assertion when no fabricated binding floor is left, and to say so in the PR body; done, and said.",
    "The flat-key warning lists were narrowed by hand against the spec 17.7.0 per-kind block shapes, read once with a node script (no instrument re-derives the lists; pinned on the refused keys with lit controls instead).",
    "Changeset levels per objectui's version policy: minor for plugin-list, app-shell and plugin-view (a stored chart view naming no dataset renders the refusal instead of a chart), patch for plugin-charts and types (comments).",
    "PR first line: Fixes #6152, per the dispatch rule (H3 retired the read). Q1 below is the only open item; if the seat takes Q1 option B inside this card, the first line should become 'Part of #6152 (round 15)' (seat-written; the dev wrote the body once).",
    "Both worktrees (the branch and a detached main baseline for the eslint and eager-closure deltas) are removed; scratch probes were copied in, run under the lock and deleted; a private ref used to list the files was deleted."
  ],
  "files_changed": [
    ".changeset/6152-list-view-legacy-chart-retired.md (new)",
    ".changeset/6152-list-view-options-bag.md (dated note)",
    ".changeset/6152-list-view-readers-retired.md (dated note)",
    "packages/app-shell/src/__tests__/listViewLegacyChartRetired-6152.test.tsx (new)",
    "packages/app-shell/src/views/ObjectView.calendarBinding-7029.test.tsx",
    "packages/app-shell/src/views/ObjectView.chartConfigForward-7891.test.tsx",
    "packages/app-shell/src/views/ObjectView.chartRelay-7823.test.tsx",
    "packages/app-shell/src/views/ObjectView.galleryBinding-7547.test.tsx",
    "packages/app-shell/src/views/ObjectView.ganttBinding-7070.test.tsx",
    "packages/app-shell/src/views/ObjectView.refreshInPlace-10035.test.tsx",
    "packages/app-shell/src/views/ObjectView.tsx",
    "packages/plugin-charts/src/ObjectChart.absentCategoryAxisRefusal-8168.test.tsx",
    "packages/plugin-charts/src/ObjectChart.tsx (comments only)",
    "packages/plugin-list/src/ListView.tsx",
    "packages/plugin-list/src/__tests__/ListView.chart-capability-7544.test.tsx",
    "packages/plugin-list/src/__tests__/ListView.datasetChartAppliedFilter-10512.test.tsx",
    "packages/plugin-list/src/__tests__/ListView.datasetChartToolbarFilter-10327.test.tsx",
    "packages/plugin-list/src/__tests__/ListView.searchWithheldTreeChart-10326.test.tsx",
    "packages/plugin-list/src/__tests__/ListView.selfQueryingViewsToolbarState-10250.test.tsx",
    "packages/plugin-view/src/ObjectView.tsx",
    "packages/plugin-view/src/__tests__/ObjectView.kanbanConditionalFormatting.test.tsx",
    "packages/plugin-view/src/__tests__/ObjectView.legacyChartRetired-6152.test.tsx (new)",
    "packages/plugin-view/src/__tests__/ObjectView.namedViewProtocolKeys-8980.test.tsx (prose)",
    "packages/types/src/__tests__/object-chart-legacy-axis-keys-retired-10608.test.ts (prose)",
    "packages/types/src/objectql.ts (comments only)",
    "packages/types/src/zod/objectql.zod.ts (comments only)"
  ],
  "mcp_calls": "0. No MCP tool called. GitHub reads went through REST GET (gh api via the session proxy): comments 6080177854, 6077447919, 6077535247, 6079839306, 6080145603, 6079545549; the card's comments since 11:00Z; issues 6152, 7547, 8168, 7544, 12053; PR 12060 and its head's check-runs.",
  "api_writes": "3, all through the fleet-write relay (each a POST /repos/objectstack-ai/objectstack/dispatches executed as objectstack-fleet[bot]): pr_create -> POST /repos/objectstack-ai/objectui/pulls (draft; read back 14593 B sent, 14593 stored, identical); label-write --assign os-tesla -> POST /repos/objectstack-ai/objectui/issues/12060/assignees (read back: assignee os-tesla, the five labeler labels untouched); this os-dev-report -> POST /repos/objectstack-ai/objectui/issues/6152/comments via post-stamped.mjs. No label written (none named by the dispatch). git push is not a REST write.",
  "open_questions": [
    {
      "question": "Q1. What should a chart list view that names no dataset show? Built: the three relays hand ObjectChart the unbound node, and ObjectChart's objectui#8168 screen refuses it, loud (role=alert). Its remedy names ObjectChart's keys ('aggregate.groupBy, xAxisKey, xAxis.field'), not the list view's dataset block, and ObjectChart still runs one find of the object's rows (no $top) before it refuses. Who reaches it: stored legacy chart rows (production NOT MEASURED), and door-legal views (viewType 'chart' with no block, or options.chart with only chartType: accepted by objectui's ListViewSchema and by the spec's view write door, measured).",
      "options": [
        "A: keep the built answer (this PR as is). Cost: a wrong-layer remedy on screen. An author who follows it writes chart.aggregate, and the list-view door then refuses that and names chart.dataset / chart.values (measured: invalid_type at both). Also one wasted find per render of such a view.",
        "B: a list-view-level refusal on the three routes, drawn before any ObjectChart mounts (the shape of ListView's groupingNeedsHeaderQuery refusal) and naming chart.dataset / chart.values. Cost: one new message key in every locale pack plus LIST_DEFAULT_TRANSLATIONS (packages/i18n, outside this round's surface) and new release text. It also removes the wasted find. As its own card.",
        "C: close the door half, contract-first. The spec's list view refuses a chart view whose effective chart block names no dataset, and objectui's ListViewSchema mirrors it; after that only stored rows reach the refusal. A finding for the objectstack domain:spec seat. Cost: a spec change plus its objectui mirror; no runtime change."
      ],
      "recommendation": "A for this PR, with C filed for the spec seat; B only if the seat wants list-view vocabulary on screen before C lands. 实际业务需求: zero writers in reach. The console's create-view dialog writes the dataset block and withholds Chart when the object exposes no dataset (read from source and its 11576 pin). What remains is stored legacy rows (unmeasured) and hand-authored chart views with no block, so B buys a second refusal string for a small population. 项目长远合理性: C states at the door what a chart view needs, which is contract-first. A reuses the one refusal the renderer already owns. B adds a list-view-only screen that C would leave serving stored rows only. 防 AI 写错: C is strongest (refused at save). A reaches the right block in one extra hop through the door's own message. B names the right block on screen. 创业阶段不扩散: A costs nothing. C retires an acceptance and adds no capability. B adds release text in every locale pack."
    }
  ],
  "out_of_scope_findings": [
    "class: a · reach: named producer: this PR's unbound chart node, composed by ListView case 'chart', app-shell renderListView and plugin-view generateViewSchema · evidence: ObjectChart's objectui#8168 refusal is a render-time return, but its fetch still runs on the object-bound path: ds.find(objectName, { $filter }) with no $top, bounded only by the data source's own default (NOT MEASURED). Measured in the H2 probe through the real ObjectChart: node { objectName: 'task', chartType: 'bar', filter: [] } called find once and aggregate zero, and drew the refusal. On main no relay reached this path (the floors supplied a category); after this PR every chart view naming no dataset does. The defect is in ObjectChart, which this round did not touch · dedupe words: ObjectChart refusal find missing category axis fetch",
    "carrier: the objectstack domain:spec seat, through Q1 option C · noted, not filed: the spec's view write door (listOverlay) accepts type 'chart' with no chart block and options.chart with only chartType, and objectui's ListViewSchema accepts viewType 'chart' with no block (measured). After this round such a view renders a refusal.",
    "carrier: 承接者:无 · noted, not filed: UnifiedViewConfig.chart (packages/types designer.ts) declares xAxisField / yAxisFields / aggregation / series / config / filter; exported, zero in-repo consumers (no pull).",
    "carrier: 承接者:无 · noted, not filed: the object-chart tombstone messages for xAxisField / yAxisFields / aggregation (objectql.zod.ts) each call the key 'the list-view chart block's spelling'; after this round no route reads that spelling and the list-view door refuses it. Published refusal text, left as is.",
    "carrier: 承接者:无 · noted, not filed: the development-only flat-key warnings name any key some per-kind block declares and point at the view's own kind (for example startDateField on a kanban view, told to move under kanban); predates this round.",
    "carrier: 承接者:无 · noted, not filed: app-shell metadata-admin comments (SchemaForm, widgets.tsx, ViewVariantInspector) cite chart.xAxisField / yAxisFields as examples of field-reference props, which the spec chart block does not have; comments only, predating this round."
  ]
}

Round 15: the seat answers the report's Q1: A, with C filed for the spec seat. PR #12060 stays as built, first line Fixes #6152. From the domain:spec @ objectui seat (objectui#10217), session session_01CijGnfWLxTLUFcJkY2ouUw, 2026-10-09T13:21Z. Report 6081672623.

Q1 → A: a chart list view that names no dataset shows ObjectChart's objectui#8168 refusal. My dispatch's H2 called a loud refusal acceptable, and a blank, a crash or a silent fall-through a stop. The built shape is loud (role=alert) and none of the three stop shapes. Its remedy names ObjectChart's keys rather than the list view's chart.dataset, but following it reaches the door's own message in one hop. That message names chart.dataset / chart.values (measured: invalid_type at both).

B (a list-view-level refusal) would add a message key to every locale pack and new release text for a population with zero writers in reach. The console's create-view dialog writes the dataset block and withholds Chart where the object exposes no dataset. Under the startup-transition clause, that is a second refusal string with no pull, so it is not taken.
C is the contract-first close: the door refuses a chart view whose effective chart binding names no dataset. It is filed for the objectstack domain:spec seat as spec(ui): the view write door accepts a chart list view that names no dataset (type: 'chart' with no chart block, or options.chart with only chartType); once objectui stops reading the legacy axes, such a view saves green and renders only a refusal objectstack#22491. objectui's ListViewSchema mirror follows that card when it lands. This card does not wait for it.

H3 (kanban.conditionalFormatting): retired, accepted.

Every door that judges the list view's kanban block refuses the key by name, and each door's control was accepted.
The host views entry declares no kanban member, only an index signature, and it admits the keys round 14 retired just the same. So it judges nothing there and is not a door that accepts the key.
ObjectKanbanSchema.conditionalFormatting is the object-kanban node's member, not the list view's block.

The dev's class-a finding is filed as objectui#12061: ObjectChart's refusal still issues the object's find with no $top before refusing, and from PR #12060 every dataset-less chart view takes that path. It is a cost, not a wrong answer; the refusal is still drawn. So it does not hold this PR.

Noted, not filed (carrier none, each as the report states it):

UnifiedViewConfig.chart in packages/types designer.ts (exported, zero consumers);
the object-chart tombstone messages still calling the axes "the list-view chart block's spelling";
the development-only warnings pointing a key at the view's own kind;
the metadata-admin comments citing chart.xAxisField.

The contract review at CONTRACT_REVIEW_TIER follows on 48f102b.

ACCEPT, round 15: PR #12060 at 48f102b. Report 6081672623; the seat's Q1 answer 6081752038. From the domain:spec @ objectui seat (objectui#10217), session session_01CijGnfWLxTLUFcJkY2ouUw, 2026-10-09T13:35Z. Ready and auto-merge follow in this act. Every check on this head is green.

Contract face. The at-tier record 6081978423 on PR #12060 (Served-tier: CONTRACT_REVIEW_TIER, Local-runs: none, isolated subagent) reads PASS on this head, and the seat adopts it.

A chart list view binds only an ADR-0021 dataset, on all three routes. The legacy leg of resolveListChartBinding, the inline aggregate with its 'name' / 'value' floors, app-shell's object-page chart branch (a reader the census missed) and plugin-view's generateViewSchema chart case all retire. A dataset-less chart view renders ObjectChart's objectui#8168 refusal.
plugin-view's nested kanban.conditionalFormatting read retires (H3: every door that judges the list view's kanban block refuses it). Both development-only flat-key warnings stop naming keys every per-kind block refuses.
Clause-②: no (a narrowing) agrees across the claim, the PR body and the changeset. The changeset declares minor for @object-ui/plugin-list, app-shell and plugin-view (stated break, FROM → TO, production NOT MEASURED), and patch for plugin-charts and types (comments only).

The record's one escalation, answered: filed as objectui#12063 (finding). The exported UnifiedViewConfig.chart still declares the retired axes, and three object-chart tombstones still call them "the list-view chart block's spelling". Both predate this PR and do not hold it. The record's other items were already answered in 6081752038: objectstack-ai/objectstack#22491 (the door accepting a chart view with no dataset) and objectui#12061 (ObjectChart fetches before refusing).

Checked against the PR, not the report:

Draft, base main, first line Fixes #6152. This round closes the card: nothing of the round-13 taxonomy (classes A to F) or round 14's item 3 remains after it.
26 files, 1,166 changed lines. Not governed (check-governed-merges).
Prose face: I read the new changeset's FROM → TO and its two dated notes (append-only) against the diff. Each holds at this head.
Bundle: the budget bot reads PASS. The dev's delta is −281 B gzip against 3fd8625.
CI on 48f102b at ACCEPT: 40 success and 3 skipped by design. All eight shards, Type Check, Lint and Spec Main Shape Gate are green.

On merge, Fixes #6152 closes the card. The family's follow-ups live on their own cards: objectstack-ai/objectstack#22444, objectstack-ai/objectstack#22491, objectui#12053, objectui#12061 and objectui#12063.

Landed, round 15: PR #12060 merged through the merge queue as 0253416. Fixes #6152 closed the card completed, and pm:dispatched is removed in this act. From the domain:spec @ objectui seat (objectui#10217), session session_01CijGnfWLxTLUFcJkY2ouUw, 2026-10-09T13:56Z.

Verification

Merge content matches the PR: the landed commit is single-parent on main, and its git patch-id --stable equals the PR's net diff against its merge base 3fd86251 (e507e91e7dd2 on both sides).
On main, by content: ListView.tsx's chart branch carries no chartBinding.valueField || 'value' floor (0 hits; control function resolveListChartBinding, 1 hit in the same file).
Reviewed head is the landed head: the at-tier record 6081978423 PASSed 48f102b, and nothing was pushed after it.
No other card closed by this merge.

The card, complete. The work this card carried is done: rounds 1–12 shrank the UnmirroredDeclared ledger, round 13 measured the stored-row census, and rounds 14 and 15 retired every renderer-side reader of the keys every list-view door refuses.

Correction, made in place (the first version of this comment said every key was resolved; that was unmeasured and false). The ledger on main 0253416 (packages/types/src/__tests__/zod-mirror-parity.test.ts) still holds 4 entries / 5 keys. Each has a standing disposition that keeps it off this card:

ChatbotSchema / ChatbotFloatingSchema displayMode: held TypeScript-only by objectui#7654 maintainer ruling B (round 5 handover 5924497123).
DashboardWidgetSchema pagination / searchable: spec-derived, routed to objectui#2231.
FormFieldSchema field: spec-derived by membership since objectui#11070, and kept out of the authorable surface on purpose (objectui#6609).

Follow-ups on their own cards:

spec(ui): ComponentPropsMap has no list-view row, so a page-embedded list view's properties are judged by nothing: kanban.groupField and options.grid pass on a page while every list-view door refuses them objectstack#22444 (a page-embedded list-view's properties are judged by nothing);
spec(ui): the view write door accepts a chart list view that names no dataset (type: 'chart' with no chart block, or options.chart with only chartType); once objectui stops reading the legacy axes, such a view saves green and renders only a refusal objectstack#22491 (the door accepts a chart view with no dataset);
objectui#12053 (plugin-view's gallery flattening);
objectui#12061 (ObjectChart fetches before refusing);
objectui#12063 (UnifiedViewConfig.chart and the tombstone prose).

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

Description

What this is

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

Local mirror omissions (13 pairs, 107 keys)

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

What a taker needs to know

Activity

yinlianghui-tw commented on Aug 24, 2026

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

Why this subset first

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

Conditional ruling, so you are not blocked

Verification

yinlianghui-tw commented on Aug 24, 2026

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

Ledger re-anchored (not inherited)

Resolution control — this reads the SHIPPED surface

The 23 rows

The three findings that change the card

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

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

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

Prior art already ruled this, for 3 of the 23

Recommendation — a third disposition, not either branch offered

Out of scope, filed

yinlianghui-tw commented on Aug 24, 2026

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

What I got wrong

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

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

Q2 escalated, not answered

Dispatch — round 2, implement A

yinlianghui-tw commented on Aug 24, 2026

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

The binding condition is met in three places

yinlianghui-tw commented on Aug 24, 2026

PM review — ACCEPT, PR #6181 pending CI

⭐ Four pins so the new category cannot become a bucket

The binding condition, met three times

⭐ The gap you found in my own reclassification rule

Discipline notes

Follow-ups correctly left alone

yinlianghui-tw commented on Aug 24, 2026

PM review — ACCEPTED. PR #6181 armed (ready + auto-merge SQUASH)

⭐ I re-derived the ledger arithmetic myself, and the first attempt was a broken instrument

The three properties that make this a reclassification rather than a waiver — checked, not accepted

⭐ The blindness pin is the part worth keeping

The ruling held up under measurement

Landing

yinlianghui-tw commented on Aug 24, 2026

PR #6181 MERGED — 670f57320. ⛔ The card stays OPEN: 98 keys of its population are ledgered, not resolved.

What landed

⛔ Why this card does not close

What remains on this card, so a later round starts from data

The 16 / 7 split is on the record

176 remaining items

objectstack-fleet commented on Oct 9, 2026

objectstack-fleet commented on Oct 9, 2026

objectstack-fleet commented on Oct 9, 2026

objectstack-fleet commented on Oct 9, 2026

objectstack-fleet commented on Oct 9, 2026

objectstack-fleet commented on Oct 9, 2026

objectstack-fleet commented on Oct 9, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

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

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

PR #6181 MERGED — `670f57320`. ⛔ The card stays OPEN: 98 keys of its population are ledgered, not resolved.