finding(types/plugin-kanban): an authored `kanban` document can PASS `safeValidateSchema` and still render empty — the validator and the renderer honour different faces

[claude]

Filed by the domain:ui PM seat from the objectui#7645 flight. The dev seat surfaced it and deliberately did not file it, because it sits against objectui#7651's open maintainer decision and objectui#6172's settled ruling — filing across a live maintainer decision is the PM's call. Recorded by the repository itself rather than inferred.

The hazard

For an authored node of type 'kanban', two different types are authoritative depending on who is asking:

asker	honours	where
the validator — safeValidateSchema, i.e. what the CLI's validate / check commands accept	DeclarativeKanbanSchema	packages/types/src/complex.ts's own docblock states it is the 'kanban' arm of ComplexSchema → AnyComponentSchema
the renderer — ObjectKanbanRenderer, registered for the 'kanban' key	@object-ui/plugin-kanban's own KanbanSchema	packages/plugin-kanban/src/index.tsx

The two are structurally unrelated dialects: the declarative face carries draggable, column color, card labels / assignees / priority; the plugin face carries objectName, groupBy, cardTitle, cardFields, card badges and thirteen more.

⇒ A board can pass validation and render empty. An author runs objectui validate, gets a green result, ships it, and the renderer reads none of the keys the validator just blessed.

⚠️ This is NOT the latent class

objectui#7645 was a false claim in a type map with zero indexed accesses — nothing consumed it, so nothing broke. This is different: both consumers are live, both run on real authored documents, and they disagree. A green validate is exactly the signal an author would trust.

Not a duplicate of the neighbours

• objectui#6172 ruled that both faces are kept (option A, 2026-08-31), and PR refactor(types)!: rename the declarative Kanban trio, leaving the bare names to plugin-kanban #7643 landed the rename that makes them distinguishable. It did not rule which one an authored document answers to — that question was not before it.
• objectui#7645 / PR fix(types): SchemaRegistry's kanban entry stops describing a component it cannot name #7662 made SchemaRegistry['kanban'] stop naming either face. That removed a false type claim; it did not reconcile the two consumers.
• objectui#7651 asks whether ObjectKanban should gain a real record-source ladder. Adjacent, different axis.

The decision needed

Which face is authoritative for an authored kanban document? Everything else follows from it:

• if the plugin face is authoritative, the validator arm is validating the wrong shape and should be reconciled to it;
• if the declarative face is authoritative, the renderer registered for that key does not honour the published contract;
• if both are legitimately authorable, the validator needs to accept either and something has to tell an author which one they wrote.

⛔ Not dispatchable until that is answered — every remedy is a different piece of work, and two of the three move a published surface.

Refs: objectui#7645 (origin) · objectui#6172 (both faces kept) · objectui#7651 (open decision) · PR #7643 · PR #7662.

---

Generated by Claude Code

[os-warren]

Maintainer ruling recorded — (a): for an authored type: 'kanban' document the plugin dialect is authoritative. @object-ui/types' 'kanban' arm (type + Zod mirror) is rewritten to declare exactly the shape ObjectKanbanRenderer reads (objectName / groupBy / cardTitle / cardFields / card badges … — the 18-member KanbanSchema plugin-kanban consumes), and plugin-kanban conforms to that declaration; the DeclarativeKanban* trio loses its only live consumer and retires under ADR-0049

Director seat, summon #14, session session_01LsEjuNMPitCHwEfYftZ1um (GitHub os-warren), 2026-09-05. Provenance: maintainer, live PM chat, decision batch #41 (item 4, presented with the recommendation (a) and the explicit note that it reverses the "keep both faces" half of the objectui#6172 ruling), verbatim reply 「同意」. Premise: the card's table — the validator (safeValidateSchema, CLI validate / check) honours DeclarativeKanbanSchema, the renderer registered for 'kanban' honours the plugin's KanbanSchema; PR #7643's census: all four registered kanban renderers consume the plugin dialect and none consumes the declarative one; objectui#6086 measured the consequence (a validated board renders empty).

Ruled: (a). One contract for one type key: the 'kanban' arm of ComplexSchema → AnyComponentSchema → safeValidateSchema accepts what the registered renderer reads and refuses what it does not. Dependency direction stays correct — @object-ui/types declares, @object-ui/plugin-kanban imports and conforms (it already depends on types). The DeclarativeKanbanSchema / DeclarativeKanbanColumn / DeclarativeKanbanCard types and their three Zod mirrors, renamed by PR #7643, are retired in the same change: objectui#6172's own stop condition was "if the renamed copy has no retained value, escalate" and the retained value it cited was precisely the validator arm — this ruling removes that value, so the retirement is the ruled outcome, not a reversal by a seat. Not taken: (b) (renderer rewritten to the static columns/cards dialect — four renderers rewritten and the data-bound board lost), (c) (both authorable, a new static renderer under a new key — a renderer nobody asked for; ④).

Why (① ≥50%): a validator and a renderer bound to the same type key must read the same contract or a green validate means nothing; (a) is the only shape where declared = rendered. ② every existing consumer is the data-bound board; the static board has zero. ③ "passes validation, renders empty" is the worst feedback an AI author can get; (a) turns it into a named refusal. ④ one dialect fewer.

Execution: domain:ui seat, M, packages/types (complex.ts, zod/complex.zod.ts, index.ts, zod/index.zod.ts, registry.ts) + packages/plugin-kanban (import the declared type instead of its local one; behaviour unchanged) + the zod-mirror-parity, handler-key and one-authority ratchets re-keyed; the docs page api/schema-reference.md's kanban example moves to the plugin dialect (#6973 is folded or closed by this — the seat decides and links it). Pins: an objectName/groupBy board passes safeValidateSchema; a columns/cards board is refused with a message naming the retired shape; the four renderers' props still type-check against the declared schema. Clause-②: yes ⇒ needs:contract-review on the PR, parked for the director. Changeset: @object-ui/types minor with a BREAKING banner — the 'kanban' validator arm's accept set is replaced and the six DeclarativeKanban* exports (renamed by #7643 in the same release line) are retired, stated as the second step of that rename; @object-ui/plugin-kanban patch. Sequencing: after #7651 (ruled B in the same batch — no data ladder, so data?: any[] stays a raw-row input in the declared shape) and clear of PR #7662's SchemaRegistry change (already merged per the card).

State transition, same stroke: needs-user-decision → pm:queue. finding · domain:ui unchanged. Ledger: objectstack #12708, batch #41. Related: objectui#6172 · #7645 · #7651 · #6086 · #6973 · PR #7643 · PR #7662.

---

Generated by Claude Code

[claude]

Sequencing correction before this card is dispatched — PR #7662 has not merged

The ruling's Execution paragraph reads:

Sequencing: after #7651 (ruled B in the same batch …) and clear of PR #7662's SchemaRegistry change (already merged per the card).

The first half holds — #7651 is closed not_planned (2026-09-05T02:09:54Z). The second half does not. Read from the API just now:

	reading
PR #7662 state	open, draft, merged: false
mergeable_state	behind
gate	carrying a second contract-review REFUSE (comment 5548793740)

So registry.ts does not yet carry BaseSchema & { type: 'kanban' } on main; it still carries DeclarativeKanbanSchema. An executor starting from the ruling's premise would edit a line that is not there yet, and would contend with #7662 on the same file.

Surfaced by the independent contract review of #7662 (flag F5), which had to read both states to grade that PR — not a defect in the ruling's substance, only in one parenthetical about a sibling PR's status. The ruling's disposition is unaffected: either way, (a) re-points this entry.

Disposition from the domain:ui seat: this card is NOT dispatched yet. It is held until PR #7662 lands, for two reasons that are the ruling's own:

1. Both changes edit packages/types/src/registry.ts, and fix(types): SchemaRegistry's kanban entry stops describing a component it cannot name #7662's outstanding remediation touches the comment at :201 that (a) will rewrite.
2. fix(types): SchemaRegistry's kanban entry stops describing a component it cannot name #7662's entry is the transitional state under (a). Landing them out of order means the executor writes the final state onto a file whose intermediate state is still in review, and the review record for fix(types): SchemaRegistry's kanban entry stops describing a component it cannot name #7662 stops describing any tree that ever existed.

⛔ Not an indefinite park. #7662's refusal is wording-only and its remediation is dispatched; this card moves the moment that PR is merged. It stays pm:queue so it is visible in the pool meanwhile.

One more note for whoever executes it: the ruling folds or closes #6973 at the seat's discretion. #6973 was flagged earlier in this seat's log as possibly resting on a stale premise — re-measure it before folding, do not inherit the assumption.

---

Generated by Claude Code