finding(plugin-kanban,types): after batch #70 the `view:kanban` registry `inputs` still declares `titleField` while the zod arm refuses it — two published faces of one type key, opposite verdicts, and every pin stays green

[os-warren]

Filed by the dev seat executing objectui#7742 (decision batch #70). This is a residual created by PR #8799 and deliberately left open there rather than closed unilaterally: closing it means re-opening a landed ruling. ⛔ The PR does not address this; it reports it.

What batch #70 ordered, and what it did not reach

The ruling: "titleField on the kanban arm — retire the fallback — one arm, one spelling: cardTitle; named refusal pointing at it; the object-kanban arm keeps its declared titleField."

The objectui#8410 screen recorded on objectui#7742 stated its own radius: it covered the prop-spread channel only, and the registry inputs face was neither confirmed nor falsified. Measuring it is what produced this card.

The measurement

packages/plugin-kanban/src/index.tsx declares ONE array, OBJECT_KANBAN_INPUTS, and spreads it into both registrations:

• ComponentRegistry.register('object-kanban', ObjectKanbanRenderer, { inputs: [...OBJECT_KANBAN_INPUTS] })
• ComponentRegistry.register('kanban', ObjectKanbanRenderer, { inputs: [...OBJECT_KANBAN_INPUTS] })

and that array carries titleField, described as "Legacy spelling of cardTitle".

The sharing is structurally pinned on purpose. packages/plugin-kanban/src/__tests__/scalarKeysAreDeclaredAndHonoured-8201.test.ts states it as its own row 5: "ONE SHARED LIST — both tags are the same renderer, so the declared surfaces must be the same OBJECT, not two lists that happen to agree." That same file carries a row per (tag, key) pair asserting the html tier ACCEPTS titleField for view:kanban.

⇒ After PR #8799, a document { "type": "kanban", "titleField": "name" } gets:

face	verdict
registry inputs / html tier (validateTree)	accepted — no unknown-prop diagnostic
@object-ui/types zod arm (safeValidateSchema)	refused by name, pointed at cardTitle

Why nothing catches it

Measured after the change: apps/console 95 files / 1116 tests green, packages/plugin-kanban and packages/types 197 files / 3381 tests green, pnpm check exit 0. The 8201 rows stay green because they read the SPEC's ComponentPropsMap entry, not this repo's zod mirror — and ComponentPropsMap has an object-kanban entry and no kanban entry at all, so there is nothing for a split list to be compared against. The divergence is mechanically invisible in both directions.

Note the direction. The repo already tolerates the OTHER one — quickAdd is declared on the zod arm and deliberately absent from OBJECT_KANBAN_INPUTS (escalated as objectui#8201). This is the first key in the reverse position: the designer-facing face says yes and the document validator says no, on the same type key.

Why PR #8799 does not fix it

Un-sharing the array for the kanban tag is the mechanical fix, and it costs three things the executing seat has no standing to spend: it reddens objectui#8201's row 5, it contradicts that row's stated reason (one renderer, therefore one surface), and it leaves the split list with no upstream entry to check parity against. That is a ruling, not a repair.

The options

• A — accept the divergence. The zod arm is the stricter, authoritative face and its refusal is loud and names the remedy. Cost: an author gets a green from the designer and a red from objectui validate on the same document, and nothing explains why.
• B — un-share the inputs array so kanban publishes the list minus titleField. Cost: re-opens objectui#8201's structural pin, and needs a rule for what the split list is checked against upstream.
• C — do not retire titleField on the kanban arm after all, keeping both faces accepting. Cost: reverses one row of a maintainer ruling already executed.
• D — take it upstream: give @objectstack/spec a kanban entry distinct from object-kanban, then split the list against it. Largest, and the only one that makes the two arms genuinely independent.

⛔ This seat does not choose. Recommendation for triage, not a decision: A now, D as the real answer — the divergence is loud rather than silent today, and every cheaper fix trades one landed ruling for another.

Refs: objectui#7742 (batch #70) · PR #8799 (its execution, which reports this in its body) · objectui#8201 (the shared list and its pin) · objectui#7322 item ② (the two-arm prop union) · ADR-0049.

Filed from Claude Code session session_01Jmxdo7bmeqCQHLSfmLVX9w; this paragraph is the attribution, written as prose rather than a footer block.

[os-warren]

Ruling input — the maintainer's stated business requirement, and the measurement that prices it

domain:spec @ objectui execution seat, session session_01Jmxdo7bmeqCQHLSfmLVX9w. ⛔ Not a ruling — this card awaits one, and this seat does not produce it. This is the input, with the measurement that makes it cheap.

The maintainer's steer, verbatim: 「从我们的业务需求角度，我应该只需要 object-kanban」 — from our business-requirements point of view, we should only need object-kanban.

That does not select one of this card's four options. It proposes a fifth: retire the bare kanban node key, which dissolves this card's divergence instead of patching it — there is no arm left to disagree with the registry inputs.

I measured what that would cost. It is far less than I first believed, and the reason is the interesting part.

⭐ The finding that changes the price: the console path never produces the bare key

packages/plugin-view/src/ObjectView.tsx is the adapter that turns a stored NamedListView into a rendered node. Its switch (viewType) (:1311) maps every stored view type to a node type, and it already emits object-kanban:

packages/plugin-view/src/ObjectView.tsx
  :1384   type: 'object-kanban',     ← the `case 'kanban':` branch
  :1404   type: 'object-calendar',
  :1419   type: 'object-gallery',
  :1449   type: 'object-timeline',
  :1472   type: 'object-gantt',
  :1490   type: 'object-map',
  :1505   type: 'object-tree',
  :1625   type: 'object-grid',
  :1668   type: 'object-form',

Firing control: twelve emitted node types on the same instrument, an unbroken object-* family — so object-kanban at :1384 is a reading, not a lone match from a matcher that finds one thing.

The only type: 'kanban' anywhere in that file is at :613, inside a JSDoc comment, and it documents the stored NamedListView.type (board: { label: 'By Status', type: 'kanban', options: { kanban: { … } } }) — not an emitted node.

⇒ Two different things at two different layers, and this card has been reading them as one:

layer	value	who writes it	affected by retiring the node key?
stored NamedListView.type	"kanban"	CreateViewDialog, persisted per tenant	⛔ NO
node type key	kanban | object-kanban	hand-authored JSON; ObjectView emits only object-kanban	✅ yes

⇒ Every kanban view any user ever created through the console already renders through object-kanban. The maintainer's business requirement is, on the product surface, already met. ⛔ Retiring the bare node key touches zero stored documents — the data-migration objection that would normally sink a change like this does not arise.

What the bare kanban node key actually is, then

A hand-authoring alias. Both keys dispatch to the same renderer — packages/plugin-kanban/src/index.tsx:579 (object-kanban) and :589 (kanban), both ObjectKanbanRenderer. Re-measured on origin/main dcbf0b2bc, exact node-type spellings, whole repo:

spelling	JSON documents	TS/TSX files
kanban	3	38
object-kanban	0	—
kanban-ui	0	0
kanban-enhanced	0	0
control object-grid	2	128
control zzz-not-a-type	0	—

Two controls, both behaving: a real sibling fires, an absent name is silent.

⭐ Note kanban-ui and kanban-enhanced: registered type keys that no document in the repository authors, in either language. Not this card's business, but they belong in whatever ruling reaches this family — and objectui#8818, filed today, turns on kanban-ui being reachable.

The full migration surface, enumerated

3 JSON documents, all fixtures:

• examples/schema-catalog/src/schemas/plugin-kanban/basic-kanban-board.json
• examples/schema-catalog/src/schemas/plugin-kanban/advanced-kanban-with-badges-and-limits.json
• examples/schema-catalog/src/schemas/components-complex-view-switcher/view-switcher.json

38 TS/TSX files — of which 29 are tests and 9 are non-test, and three of those nine are the retirement itself rather than consumers of it:

file	role
packages/types/src/complex.ts	the arm declaration — is the change
packages/types/src/zod/complex.zod.ts	the mirror — is the change
packages/plugin-kanban/src/index.tsx	the :589 registration — is the change
packages/types/src/registry.ts	'kanban': KanbanSchema at :201
packages/plugin-kanban/src/types.ts
packages/plugin-kanban/src/ObjectKanban.tsx
packages/plugin-view/src/ObjectView.tsx	the case 'kanban': stored-type label — ⚠️ must NOT change
packages/app-shell/src/views/CreateViewDialog.tsx	writes the stored type — ⚠️ must NOT change
packages/types/examples/zod-validation-example.ts

2 docs pages teach the bare spelling and are the real user-facing cost: content/docs/api/schema-reference.md (7 occurrences) and content/docs/utilities/runner.mdx.

⚠️ The two files marked "must NOT change" are the trap in this route. Both mention kanban as the stored view type, and a migration that pattern-matched the spelling would rewrite them and break every stored view — converting a zero-data-migration change into the worst kind. Any dispatch on this route has to name that distinction up front.

⚠️ Corrections to my own earlier figures

I earlier put this migration at ~79 sites (content/docs JSON 6 + TS 9, examples JSON 3 + TS 1, packages JSON 5 + TS 55). That instrument counted the identifier anywhere — prose, imports, object-kanban and kanban-ui substrings included — not authored node-type spellings. The table above is the tighter instrument with controls, and it supersedes those numbers in both directions. I also earlier reported object-kanban as 1 JSON + 1 TS; on this instrument it is 0 JSON, and the reason is the whole finding above — nobody hand-authors it because the adapter emits it.

⛔ What this input does not decide

• ⛔ Not claimed the bare key should be retired. That is this card's ruling to make, and a retirement of a published node key is a narrowing of the accept set ⇒ Clause ② with needs:contract-review on card and PR.
• ⛔ Not claimed the four options are dead. If the ruling is that the alias stays, this card's original divergence stands and needs option A, B, C or D on its own merits.
• ⛔ Not claimed the docs cost is small. schema-reference.md is what teaches authors the spelling; changing it changes what every future hand-authored document says.
• ⛔ No label, priority or domain:* touched, and ⛔ no assignee written.

Refs: objectui#7742 / PR #8799 (which filed this card) · objectui#8801 · objectui#8818 · objectui#8652 · ADR-0049.

---

Generated by Claude Code

[os-warren]

Ruling recorded — retire the bare kanban node key (maintainer, 2026-09-09)

domain:spec @ objectui PM seat, session session_01Jmxdo7bmeqCQHLSfmLVX9w. Asked directly with the measurement in the question; the maintainer chose the fifth option this seat recorded at 5601352531, not one of this card's original four.

⇒ This card's divergence is dissolved rather than patched. With no kanban arm, there is no arm left to disagree with the registry inputs about titleField — options A, B, C and D all become moot.

Why the fifth option was available at all — the finding that made it cheap

⭐ The decisive measurement, re-verified for this ruling: packages/plugin-view/src/ObjectView.tsx's switch (viewType) — the adapter that turns a stored NamedListView into a node — already emits object-kanban (:1384), as it does for the whole family:

:1384 object-kanban   :1404 object-calendar  :1419 object-gallery  :1449 object-timeline
:1472 object-gantt    :1490 object-map       :1505 object-tree     :1625 object-grid

Twelve emitted node types, an unbroken object-* family — that is the firing control that makes :1384 a reading rather than a lone match.

⇒ Two layers, not two spellings of one thing:

layer	value	who writes it	affected by this retirement?
stored NamedListView.type	"kanban"	CreateViewDialog, persisted per tenant	⛔ NO
node type key	kanban / object-kanban	hand-authored JSON only	✅ yes

⇒ Every kanban view any user ever created through the console already renders through object-kanban. Retiring the bare node key touches zero stored documents — the data-migration objection that normally sinks a change like this does not arise.

The migration surface, measured

spelling	JSON	TS/TSX files
bare kanban	3 (all examples/schema-catalog fixtures)	38 — of which 29 tests and 9 non-test
object-kanban	0	—
control object-grid	2	128
control zzz-not-a-type	0	—

Three of the nine non-test files are the retirement itself (complex.ts, zod/complex.zod.ts, plugin-kanban/src/index.tsx). Real user-facing cost: 2 docs pages — content/docs/api/schema-reference.md (7 occurrences) and content/docs/utilities/runner.mdx.

⛔ The trap the implementing seat must not fall into

⚠️ ObjectView.tsx's case 'kanban': and CreateViewDialog.tsx both mention kanban as the STORED view type. They must NOT change. A migration that pattern-matched the string would rewrite them and break every stored kanban view — converting a zero-data-migration change into the worst kind. The ruling covers the node type key only.

⚠️ And the mechanism rule: BaseSchema is .passthrough(), so a dropped key is kept, not refused. A retirement needs a named refusal (retirementTombstone on the zod face, ?: never on the TS face) plus compile-time pins — the objectui#7664 failure, and the pattern PR #8799 executed correctly on this very arm.

Sibling rulings in the same batch — read them together

card	ruling	measured
objectui#8257	retire kanban-enhanced and kanban-ui	both authored 0 times, JSON and TS
objectui#8008	retire the bare gantt registration	authored 0 times

⚠️ objectui#8818 interacts with the kanban-ui half and must be read before that one is implemented: an authored objectFields still reaches the predicate layer through SchemaRenderer's generic prop spread on the kanban-ui entry. Retiring that registration closes that hole as a side effect — which is good, but it means #8818's own disposition changes and should not be ruled independently afterwards.

⇒ These are one family being converged deliberately, not four independent retirements. Whoever implements any of them should sequence with the others rather than racing them into the same files.

---

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. The same claim and the same branch are posted on objectui#8257 and objectui#8008. 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 into three slices would put three writers on one file surface, which is how three green branches make one red merge.

card	ruling	authored occurrences, measured
#8802 (this card)	retire the bare kanban node key	3 JSON fixtures · 38 TS files (29 tests)
#8257	retire kanban-enhanced and kanban-ui	0 / 0 each, JSON and TS
#8008	retire the bare gantt registration	0 / 0
control object-grid	—	2 JSON · 128 TS
control zzz-not-a-type	—	0

needs:contract-review hung on all three cards; the dev hangs it on the PR the moment it exists (双载体). ⛔ No enqueue without an in-seat contract-review-tier PASS.

⛔ Nothing here is re-opened. The maintainer ruled the direction; the dev implements it. If a measurement falsifies a premise, STOP and report — ⛔ do not pick a different route.

---

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