types: does `'kanban-enhanced'` get a declared arm? — its registration reads `onColumnToggle` / `enableVirtualScrolling` / `virtualScrollThreshold` and no schema in `@object-ui/types` declares the type at all (split from #7742)

[os-zhuang]

Filed by the director seat under the #7742 ruling (decision batch #70, 2026-09-07). Split out because the denominator is wrong for #7742: these three keys are undeclared relative to KanbanSchema only because 'kanban-enhanced' has no arm of its own.

Measured (os-sam on #7742, head f88304691)

packages/plugin-kanban/src/index.tsx:338-340 reads onColumnToggle, enableVirtualScrolling, virtualScrollThreshold inside the 'kanban-enhanced' registration. @object-ui/types declares no 'kanban-enhanced' arm; the type is dispatched by the registry and validated by nothing but BaseSchema's passthrough.

Scope (measure, then propose)

1. Population: is type: 'kanban-enhanced' authored anywhere (apps/, examples/, content/, hotcrm)? With a firing control.
2. If authored or intended as public: declare an arm (KanbanEnhancedSchema extending KanbanSchema with the three keys, with onColumnToggle under the finding(types): 28 zod-mirror keys are declared z.function(), which NO JSON document can satisfy — 14 in-repo corpus files author them and are silently invalid #6124 handler-key discipline) and register its inputs; Clause-② yes.
3. If not: retire the registration under ADR-0049 or fold its capabilities into 'kanban' behind declared keys; record which.

The taker proposes on this card; it returns to the decision box only if the measurement leaves a genuine product fork.

Acceptance

• population recorded with control
• arm declared or registration retired, with changeset
• finding(types,plugin-kanban): the ruled KanbanSchema carries three zero-read members (allowCollapse, cardTemplates, columnWidths) and the board reads an undeclared titleField — enforce-or-remove on the shape objectui#7664 declared #7742's ledger rows for these three keys drained

Refs #7742, #7664, #7804, #6124.

[os-warren]

Ruling recorded — retire both zero-author registrations, kanban-enhanced and kanban-ui (maintainer, 2026-09-09)

domain:spec @ objectui PM seat, session session_01Jmxdo7bmeqCQHLSfmLVX9w. Asked directly with the measurement below in the question. ⇒ This card leaves the decision box and is dispatchable.

⭐ Note the ruling went wider than this card asked. The card asks only whether kanban-enhanced gets a declared arm; the answer is that it gets no arm and no registration, and kanban-ui goes with it, for the same measured reason.

The measurement

Exact node-type spellings, whole repo, origin/main:

spelling	JSON documents	TS/TSX	registered?
kanban-enhanced	0	0	✅ plugin-kanban/src/index.tsx:351
kanban-ui	0	0	✅ :252
bare kanban	3	38	✅ :589 — also being retired, objectui#8802
object-kanban	0	—	✅ :579 — the survivor
control object-grid	2	128	—
control zzz-not-a-type	0	—	—

Two controls behaving: a real sibling fires at 130 sites, an absent name is silent. ⇒ both zeros are readings.

⇒ Two registered type keys that no document in this repository has ever authored, in either language. Declaring an arm for either would commit the repo to maintaining a validation face for a spelling with no writers — the opposite of what ADR-0049 enforce-or-remove asks.

⚠️ kanban-ui is NOT a free deletion — read objectui#8818 first

This is the part the implementing seat must not discover late. objectui#8818 (filed today) measured that on the kanban-ui entry an authored objectFields still reaches the predicate layer:

• SchemaRenderer.tsx strips a fixed, enumerated metadata list (:1455-1481) and spreads the rest as React props. objectFields appears in that file 0 times (grep exit 1; firing control className → 22), so it is not stripped.
• KanbanRenderer — registered for kanban-ui — now declares objectFields as a real prop (plugin-kanban/src/index.tsx:217).
• PR feat(types,plugin-kanban): execute the batch #70 ruling on the kanban arm #8799 measured the consequence end-to-end: kanban-ui + authored objectFields ⇒ the card is painted; the same on a kanban node ⇒ unpainted.

⇒ Retiring the kanban-ui registration closes that hole as a side effect. That is a good outcome, but it means:

1. ⛔ objectui#8818 must not be ruled independently after this lands — its four options (strip at the SchemaRenderer boundary / refuse by name / declare and judge / accept and pin) are largely mooted for this entry by the registration going away.
2. The implementing seat should say so on finding(react,plugin-kanban): an AUTHORED objectFields still reaches the predicate layer on the kanban-ui entry — batch #70 closed the kanban arm, not the key #8818 rather than leaving a card describing a hole that no longer exists.
3. ⚠️ finding(react,plugin-kanban): an AUTHORED objectFields still reaches the predicate layer on the kanban-ui entry — batch #70 closed the kanban arm, not the key #8818's option (a) — stripping objectFields at the SchemaRenderer boundary — would have closed the class, not just this entry. Retiring the registration closes only this entry. If another renderer ever declares an objectFields prop, the hole returns. Worth one sentence in the retirement's changeset so the next reader knows the class is still open.

kanban-enhanced's own residue

The card's framing is that its registration reads onColumnToggle / enableVirtualScrolling / virtualScrollThreshold with no declared arm. ⚠️ objectui#8257 is not the only card on those keys — PR #8799's body records that objectui#8257 carries them and that they were deliberately out of scope there. With the registration retired, those three keys have no authorable surface at all, which resolves the card's question by removing its subject. ⛔ The implementing seat should confirm that reading rather than assume it.

Mechanism, same as every retirement in this family

⚠️ BaseSchema is .passthrough() ⇒ a dropped key is kept, not refused. If any schema face declares these type names, the retirement needs a named refusal (retirementTombstone + ?: never) with compile-time pins, not a deletion — the objectui#7664 failure, and the pattern PR #8799 executed correctly.

Sequence with the family — ⛔ do not race these into the same files

card	ruling
this card	retire kanban-enhanced + kanban-ui
objectui#8802	retire the bare kanban node key
objectui#8008	retire the bare gantt registration

All three land in packages/plugin-kanban/src/index.tsx, packages/types/src/complex.ts and zod/complex.zod.ts (the first two at least). One dispatch touching all of the kanban family at once is safer than three racing slices — and the maintainer ruled the family in one batch, which is the signal to implement it that way.

---

Generated by Claude Code

[os-warren]

Claim: session session_01Jmxdo7bmeqCQHLSfmLVX9w (PM seat domain:spec, dispatching os-dev) · branch claude/kanban-gantt-family-retirement
Clause-②: yes

⚠️ ONE dispatch, THREE cards — this card is dispatched together with objectui#8802 and objectui#8008 on a single branch. The full claim, the measurements and the constraints are on objectui#8802 at comment 5604051087; ⛔ read it there rather than duplicating it here.

All three were ruled by the maintainer in one batch on 2026-09-09 and all three land in the same files (packages/plugin-kanban/src/index.tsx, packages/types/src/complex.ts, packages/types/src/zod/complex.zod.ts). ⛔ Splitting them would put three writers on one file surface.

needs:contract-review is hung here and on the PR when it exists (双载体). ⛔ No enqueue without an in-seat contract-review-tier PASS.

---

Generated by Claude Code

[os-warren]

os-dev-report

{
  "issue": 8802,
  "status": "done",
  "branch": "claude/kanban-gantt-family-retirement",
  "pr": "https://github.com/objectstack-ai/objectui/pull/8865",
  "premise_still_valid": true,
  "summary": "All three rulings executed on one branch, one PR (#8865, draft, needs:contract-review hung, not enqueued). PER NAME, WITH THE MEASUREMENT: (1) bare `kanban` #8802 = SCHEMA-DECLARED -> named refusal. Measured: 3 declaring sites (`KanbanSchema` in complex.ts with `type: 'kanban'`, its zod mirror `z.literal('kanban')`, and `SchemaRegistry['kanban']`), population 3 JSON fixtures / 38 TS files (29 tests). Retired via a NEW `retiredNodeType()` helper in zod/tombstone.zod.ts: the arm stays in the discriminated union claiming the literal and refuses with a message naming `object-kanban`; the TS half is the arm's absence from `ComplexSchema` and the key's from `SchemaRegistry`. (2) `kanban-ui` #8257 = REGISTRATION-ONLY -> unregister. Measured: 0 declaring sites in packages/types (firing control `object-kanban` = 2: objectql.ts + its mirror); authored 0 times as a registry-resolved node (1 TS hit, a test fixture handed straight to the component, now re-spelled). (3) `kanban-enhanced` #8257 = REGISTRATION-ONLY -> unregister. Measured 0/0 JSON/TS, 0 declaring sites. (4) bare `gantt` #8008 = REGISTRATION-ONLY -> unregister. Measured 0 declaring sites (`ObjectGanttSchema.type` is the literal 'object-gantt' and nothing else names the bare spelling). STORED-VS-NODE LAYER CHECK (the trap): re-derived on my own head, not taken from the brief. `plugin-view/src/ObjectView.tsx`'s `switch (viewType)` already emits `object-kanban` and `object-gantt`, twelve emitted node types in an unbroken `object-*` family as the firing control. PROOF I DID NOT TOUCH THE STORED LABELS: `git diff --stat 42df92809..HEAD` names neither `packages/plugin-view/src/ObjectView.tsx` nor `packages/app-shell/src/views/CreateViewDialog.tsx`; `NamedListView.type` in objectql.ts is unchanged and TWO new compile-time pins assert `'kanban'` and `'gantt'` are still admitted by it, so a future migration that pattern-matches the string goes red. Zero stored documents move.",
  "tests": "All readings on final head c695a1c8d, taken after the last commit; every exit code captured into a file BEFORE any pipe. TESTS: `pnpm exec vitest run packages/types/ packages/plugin-kanban/ packages/plugin-gantt/ examples/schema-catalog/ apps/console/ packages/cli/ scripts/` EXIT=0 -- 'Test Files 546 passed | 2 skipped (548) / Tests 11259 passed | 2 skipped (11261)'. The SWEEP INCLUDES apps/console, and `apps/console/src/__tests__/registry-inputs-spec-parity.test.ts` was run explicitly: EXIT=0, 'Test Files 1 passed (1) / Tests 198 passed (198)'. packages/types re-run after the final commit: EXIT=0, 161 files / 3144 tests. TYPECHECK: `pnpm --filter @object-ui/types type-check` EXIT=0, `--filter @object-ui/plugin-kanban type-check` EXIT=0. REPO-WIDE LINT (not a narrowing -- the whole farm): `turbo run lint --concurrency=2` EXIT=0, 'Tasks: 47 successful, 47 total', 0 errors in every package. `pnpm check` EXIT=0. GATES, all EXIT=0: check:doc-types, check:doc-snippets, check:doc-examples, check:doc-fences, check:handler-key-reads, check:sdui-registration-pins, check:readme-exports, check:skills-paths, check:skill-examples, check:skill-eval-tokens, check:eager-closure, check:element-data-source-declaration, check:published-dist, check:dist-completeness, check:spec-symbols, check:governed-queue-guard, check:unreferenced-sources, check:doc-example-readers, check:vi-mock-inherit, check:i18n-keys, check:control-bytes, check-changeset-presence, check-changeset-fixed, check-changeset-no-major, check-doc-links. NOT MEASURED: `pnpm check:doc-links` exited 254 because no such package script exists -- ran the script directly instead (`node scripts/check-doc-links.mjs` EXIT=0). Two gates FIRED for real before being fixed, which is the evidence they are live: check:doc-types found two doc pages my grep sweep had missed, check:readme-exports + check:doc-snippets found packages/plugin-kanban/README.md still importing the retired `KanbanSchema`. ABLATION -- five legs, one per retired name. Each: prove pin green at rest; restore the accepted spelling; PROVE THE MUTATION ON DISK BEFORE READING ANY RESULT (`grep -c -F` on both injected and removed text, plus `git hash-object` differing from the HEAD blob); run the pin; restore with `git checkout HEAD -- ABSOLUTE_PATH` from a `trap ... EXIT INT TERM`; PROVE RESTORATION BY BLOB HASH, never by an exit code. Results (before / mutated / after): kanban-named-refusal (types/src/zod/complex.zod.ts, injected 1 hit / removed 0, blob 7f3468a7 vs HEAD 13f47d7e) 0/1/0, restored to 13f47d7e; kanban-ui (plugin-kanban/src/index.tsx, 3/3, blob c8fc541e) 0/1/0; kanban-enhanced (same file, 3/3, blob aa9c683b) 0/1/0; kanban-registration (same file, 3/3, blob ba2c9a00) 0/1/0 -- all three restored to 10324942; gantt (plugin-gantt/src/index.tsx, injected 2 / removed 1, blob 56454b75 vs HEAD 7d6e1f32) 0/1/0, restored to 7d6e1f32. `git status` clean afterwards. NO BUILD is interposed and that is stated rather than assumed: every pin imports the mutated module by a RELATIVE SOURCE PATH, so vitest transforms the edited file directly -- the red column is itself the proof the mutation reached the code under test. BASE->MAIN PRE-FLIGHT: the window is NOT EMPTY (3 commits: 4c8e245e0, 8a388ee76, 561abefd7), so the control CAN fire; the intersection of their changed-file set with this branch's is ZERO files.",
  "mcp_calls": "0 — every GitHub read and write went through repo-scoped REST (probe: GET /repos/objectstack-ai/objectui/issues/8802 -> HTTP 200) plus git; no MCP GitHub tool was invoked",
  "open_questions": [
    {
      "question": "The `kanban` arm was the ONLY schema face that declared `columns` / `cardTitle` / `swimlaneField` / `grouping` / `navigation`, the only one that refused `allowCollapse` / `cardTemplates` / `columnWidths` / `titleField` / `draggable` / `onColumnAdd` / `onCardAdd` BY NAME, and — through `columns: KanbanColumn[]` — the only one that judged a lane's `cards` (objectui#6939). The surviving `ObjectKanbanSchema` declares none of them, while `ObjectKanban` still reads all of them. Does `object-kanban` get those declarations, or does the family stay judged at 5 of 13 read keys?",
      "options": [
        "A — leave it. No `object-kanban` document changes meaning (it was never judged by the `kanban` arm), the designer face still declares the keys via OBJECT_KANBAN_INPUTS, and every flipped reading is pinned where a reader meets it. Cost: `columns[].items` now parses green, a card with no `title` parses green, and three handler keys are read-but-undeclared.",
        "B — declare the missing keys on `ObjectKanbanSchema` (and its TS twin) in a follow-up. Cost: WIDENS a published accept set, so it needs its own ruling; and it re-opens the question of which keys the object-bound board actually honours.",
        "C — declare only the JUDGING half — `columns: z.array(KanbanColumnSchema)` — restoring objectui#6939's lane/card checking without widening the scalar surface."
      ],
      "recommendation": "A now, C as the follow-up card. A is what this PR ships and it is honest: nothing regressed for `object-kanban`, and every changed reading is asserted rather than lost. C is the narrow half worth recovering, because `columns[].cards` judging was a real defect fix (objectui#6939) and its loss is collateral rather than intended. B is the widest and needs the read-site census re-run first. ⛔ This seat did not choose — all three are recorded, none implemented."
    },
    {
      "question": "objectui#8008's ruling recorded bare `gantt` as authored 0 JSON / 0 TS. My re-derivation finds 43 line-occurrences across 25 TS files. Does the PM want the ruling's measurement corrected on the card?",
      "options": [
        "A — correct the number on #8008 and note that the conclusion is unaffected.",
        "B — leave the card as filed; it is being closed by this PR anyway."
      ],
      "recommendation": "A. All 25 are `as any` node objects handed DIRECTLY to the `ObjectGantt` component inside `packages/plugin-gantt` (24 tests + `demo/main.tsx`); none resolves through `ComponentRegistry` (probed across all 25, with the `object-gantt` file set as the firing control, which does hit `ComponentRegistry` in 4 files), so the registration had zero resolved consumers and the ruled route is untouched. But the figure is quoted in three places and will be read again."
    }
  ],
  "out_of_scope_findings": [
    "noted, not filed: `SchemaRegistry` (packages/types/src/registry.ts) has NEVER carried an `object-kanban` entry, so with `'kanban'` retired the kanban family has no entry in that map at all — `ComponentType` (its `keyof`) no longer offers any kanban node type. Recorded in a comment at the retirement site. Carrier: objectui#7665, the standing sweep of that map's coverage; adding an entry widens `ComponentType`, which is a ruling.",
    "noted, not filed: objectui#8818's disposition changed — retiring the `kanban-ui` registration shuts the authored-`objectFields` ENTRY as a side effect but NOT the class. Said in the changeset, pinned in `kanban-family-registry-keys-retired-8257.test.ts`, and reported here. ⛔ Not edited or closed by this seat, per the dispatch. Carrier: the PM, on #8818.",
    "noted, not filed: `packages/types/src/__tests__/kanban-arm-batch70-7742.test.ts` and the types-side `kanban-plugin-dialect-authoritative-7664.test.ts` were DELETED, not edited — their whole subject is the retired arm, so an edit would have left assertions passing because nothing is produced. Their surviving claim (the sibling `object-kanban` arm's verdicts must not move) is carried forward as suite 3 of the new `bare-kanban-node-key-retired-8802.test.ts`. Carrier: this PR's reviewer.",
    "noted, not filed: `check:doc-links` is not a package script in this repo (`pnpm check:doc-links` exits 254) although `scripts/check-doc-links.mjs` exists and is green. Carrier: none — a one-line scripts entry, below the bar for a card, and no PR is near it.",
    "noted, not filed: the `object-kanban` face refuses a purely STATIC board (lanes carrying their own cards, no `groupBy`, no record source), so the two `examples/schema-catalog` kanban fixtures needed `\"groupBy\"` and `\"data\": []` added to survive the migration. Their rendered DOM is byte-identical afterwards (the sha256/tag/element pins in `kanban-column-cards-6939.test.tsx` pass unchanged), because both keys always resolved to the SAME renderer. Carrier: the same follow-up as open question 1."
  ]
}

---

Generated by Claude Code

[huangyiirene]

Contract review pointer — director seat, summon #18 segment 6 (session_017Js5kTpTtxieBjPyScgxJ3). PR objectui#8865 @ head 4dcf544520 (this card is one of its three Fixes targets): REWORK, verdict on the PR: #8865 (comment) — the ruling on this card is executed correctly; the rework items are PR-wide (see the handoff on #8802). The carrier is cleared on this card in the same stroke as on the PR and #8802.

---

Generated by Claude Code