types(plugin-kanban): restore lane/card judging on `object-kanban` — declare `columns: KanbanColumn[]`, the one thing the retired `kanban` arm judged that nothing else does

[os-warren]

Filed by the domain:spec @ objectui PM seat, session session_01Jmxdo7bmeqCQHLSfmLVX9w, as option C of the ruling recorded on this shift.

Maintainer ruling, 2026-09-09: "A now, C as the follow-up card." ⇒ ⛔ this card is not asking whether to do it. It is asking the implementing seat to do exactly C and nothing wider.

What happened

Retiring the bare kanban node type (objectui#8802, PR #8865) removed the only schema face that judged several things. The dev surfaced this as an open question during execution rather than after — the right time.

KanbanSchema (the retired arm) was the only face that:

• declared columns / cardTitle / swimlaneField / grouping / navigation;
• refused by name allowCollapse / cardTemplates / columnWidths / titleField / draggable / onColumnAdd / onCardAdd;
• ⭐ judged a lane's cards, through columns: KanbanColumn[] — which is objectui#6939's actual defect fix.

The surviving ObjectKanbanSchema declares none of them, while ObjectKanban still reads all of them.

⇒ The family went from judging several of 13 read keys to judging 5.

⛔ What this card is NOT

• ⛔ Not option B. It does not declare the missing scalar keys (cardTitle, swimlaneField, grouping, navigation, or the refusal set). That would widen a published accept set, needs its own ruling, and re-opens the settled question of which keys the object-bound board honours. The maintainer chose C over B deliberately.
• ⛔ Not a claim that anything regressed for authors. No object-kanban document changes meaning: it was never judged by the kanban arm. What was lost is judging that only ever applied to the retired spelling.
• ⛔ Not a re-opening of objectui#8802's ruling.

The scope: one declaration

Declare on ObjectKanbanSchema — TS face and zod mirror, moving together:

columns?: KanbanColumn[];               // TS
columns: z.array(KanbanColumnSchema)…   // zod mirror

⇒ This restores the judging half only: a lane's shape and its cards are checked again. The scalar surface is untouched.

⚠️ Direction check the implementing seat owes. BaseSchema closes with [key: string]: any and .passthrough(). On such a face a declaration cannot widen — it can only narrow, by adding validation where there was none. Verify that this is that case before writing the PR body, and state it in the strict/lenient vocabulary. If it turns out to widen anything, ⛔ STOP and report: that flips the clause-② verdict and this becomes option B, which is not ruled.

What is measurably wrong today, and should be the pin

The dev recorded the concrete consequences of the loss. Each is a candidate assertion:

• columns[].items now parses green (it is not a declared member of a lane, and nothing refuses it);
• a card with no title now parses green;
• three handler keys are read but undeclared.

⇒ The pin should assert the restored refusals, each with a firing control showing the same document was accepted before. ⛔ A pin that only asserts a good document parses would have passed before this card too and would pin nothing.

⚠️ Two facts the implementing seat must not rediscover the hard way

1. The two schema-catalog fixtures needed groupBy and data: [] added during the retirement, because the object-kanban face refuses a purely static board (lanes carrying their own cards, no groupBy, no record source). Their rendered DOM is byte-identical afterwards — the sha256/tag/element pins in kanban-column-cards-6939.test.tsx pass unchanged — because both spellings always resolved to the same renderer. ⇒ if this card's declaration interacts with that refusal, say so; a static board is exactly the shape columns[].cards judging is about.
2. 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 and ComponentType no longer offers any kanban node type. ⛔ Adding one widens ComponentType and is a ruling of its own — carrier objectui#7665. ⛔ Do not fix it here.

Refs: objectui#8802 / PR #8865 (the retirement that created this) · objectui#6939 (the lane/card judging defect whose fix is what was lost) · objectui#7665 (SchemaRegistry coverage) · objectui#7322 · ADR-0049.

[os-warren]

Unblocking measurement — the "widening" premise is falsified by the protocol

PM seat (domain:spec, session session_01Jmxdo7bmeqCQHLSfmLVX9w). This card was held pm:blocked on the reading that declaring columns widens the object-kanban accept set and therefore needs a maintainer ruling. Measured against the protocol, it does not.

Maintainer principle now in force (relayed with its source on objectui#8934, 5617613810):

我们的项目以 objectstack 协议为准，文档应该以实际实现为准。协议不正确的应该先修改协议。

The reading

objectstack-ai/objectstack HEAD eabdd66f45f402eba0f8404a8a9de4a501fc83a6, packages/spec/src/ui/component.zod.ts:

• :2656 export const ObjectKanbanPropsSchema = lazySchema(() => strictObject({ … })), bound at :3069 — 'object-kanban': ObjectKanbanPropsSchema.
• :2670-2671:

  columns: z.array(z.unknown()).optional()
    .describe('Swimlane definitions ({ id, title } per `groupBy` value, or bare value strings) — NOT a field projection'),

⇒ columns is already in the protocol. Declaring it in ObjectUI is mirroring, not widening. The block lifts; this card does not need a ruling to be dispatched. Moving pm:blocked → pm:queue.

⚠️ But the shape is now a constraint, not a free choice

The protocol's element type is z.unknown() and its describe states the shape in prose, as a union:

{ id, title } per groupBy value, or bare value strings

So a columns: KanbanColumn[] that admits only the object arm would make ObjectUI narrower than the protocol — refusing an authoring the protocol accepts. That is the same direction the principle refused on objectui#8934, and it is the thing to get right here. Whoever picks this up owes:

1. a KanbanColumn that admits both arms (the { id, title } object and the bare string), or an explicit measurement that the bare-string arm is dead in the protocol's own corpus — ⛔ not an assumption;
2. a reading of what the ObjectUI renderer actually accepts today, so the declaration matches the reader rather than the card's title;
3. ⛔ no narrowing of the zod twin below z.array(z.unknown()) without a spec card first.

⭐ The second held key is a different animal — object-kanban.dataSource

The other object-kanban entry in MEMBER_PIN_EXEMPTIONS is dataSource. Measured: dataSource is not a member of ObjectKanbanPropsSchema at all. It is the shared component-level binding (PageComponentSchema.dataSource), which the kanban docblocks reference as the thing that can supply the object instead of objectName (:2668, :2681, :2695).

That matters for objectui#8071's ledger: SchemaRenderer strips dataSource before spreading a node's keys as React props — it is on the metadata strip list, with a docblock recording that spreading it once shadowed the injected adapter and broke data-bound blocks (objectstack#5576). So object-kanban.dataSource is not a per-block member awaiting a per-block pin the way the other 32 exemptions are; it is one instance of a cross-block binding. Whoever takes it should say which of those two things they are pinning before writing a row.

Not measured

• Whether the bare-string arm of columns is authored anywhere in the protocol's own corpus or in this repo.
• What ObjectUI's object-kanban renderer accepts for columns today.
• Whether any other MEMBER_PIN_EXEMPTIONS entry is a cross-block binding misfiled as a block member.

---

Generated by Claude Code

[os-warren]

Claim: session session_01Jmxdo7bmeqCQHLSfmLVX9w (PM seat domain:spec, dispatching os-dev) · branch claude/issue-8913-object-kanban-columns-declared
Clause-②: yes

⚠️ Corrected 2026-09-10 by this seat, after the dev delivered. This claim first declared Clause-②: no on the reading that declaring columns merely mirrors the protocol. check-clause2-carriers.mjs --pair 8989 exits 4 on that pairing (row C5): the diff carries 7 T1 widening tells — six new keys on the new lane zod object plus columns itself (packages/types/src/zod/objectql.zod.ts:1261) — against a no declaration. The dev hung needs:contract-review on both carriers by its own judgement of the diff, which was the right call and which no contradicted. ⛔ A provisional declaration is not a verdict, and the dev's diff outranks it. Re-declared yes; the label and the declaration now say the same thing.

⭐ The blocker is gone — measured, not argued

This card sat pm:blocked on the reading that declaring columns widens the object-kanban accept set and therefore needs a maintainer ruling. It does not. Full measurement at 5618083792; the short form:

objectstack-ai/objectstack HEAD eabdd66f45f402eba0f8404a8a9de4a501fc83a6, packages/spec/src/ui/component.zod.ts:2670-2671:

  columns: z.array(z.unknown()).optional()
    .describe('Swimlane definitions ({ id, title } per `groupBy` value, or bare value strings) — NOT a field projection'),

inside ObjectKanbanPropsSchema (:2656), bound at :3069. The protocol already declares columns. Declaring it in objectui is mirroring, ⛔ not widening. Clause-②: no follows from that, and it is provisional — your actual diff decides.

⛔ The one thing that will sink this card if you get it wrong

The protocol's element type is z.unknown() and its describe states the shape in prose, as a union:

{ id, title } per groupBy value, or bare value strings

⇒ a KanbanColumn[] that admits only the object arm makes objectui narrower than the protocol — refusing an authoring the protocol accepts. That is the exact direction the maintainer principle now in force forbids:

我们的项目以 objectstack 协议为准，文档应该以实际实现为准。协议不正确的应该先修改协议。

(source and one applied case: objectui#8934 5617613810). It has already overturned one whole PR route today, so this is not decoration.

What you owe, in order:

1. Read what the objectui renderer accepts today — measured, from the code, not from this card's title. The declaration must match the reader, and the card's title (columns: KanbanColumn[]) is a proposal, ⛔ not a finding.
2. A KanbanColumn that admits both arms — the { id, title } object and the bare string — or an explicit measurement that the bare-string arm is dead in the protocol's own corpus. ⛔ An assumption is not that measurement.
3. ⛔ Do not narrow the zod twin below z.array(z.unknown()) without a spec card first. If you conclude the protocol's union is wrong, that is an objectstack spec card, and this card blocks on it — ⛔ you do not narrow locally.
4. If any step forces you to choose between two defensible contracts, STOP and put it in open_questions rather than deciding.

⭐ A second reading you get for free — and it is NOT yours to fix

object-kanban.dataSource, this block's other entry in objectui#8071's MEMBER_PIN_EXEMPTIONS, is not a member of ObjectKanbanPropsSchema at all. It is the shared component-level binding (PageComponentSchema.dataSource), which SchemaRenderer strips before spreading a node's keys as React props. The kanban docblocks reference it only as the thing that can supply the object instead of objectName (:2668, :2681, :2695).

⛔ Out of scope here. Recorded so you do not "helpfully" declare it and so objectui#8071's line knows it is holding a cross-block binding, not a per-block member.

Standing operational rules

• ⛔ Never edit a shared primary checkout. /home/user/objectui is shallow with a stale origin/main — ⛔ never git fetch / git checkout there, ⛔ never cut a worktree from it. /home/user/objectstack is a shared checkout and also behind — ⛔ read-only. Clone fresh into your own directory; report that shared checkout's HEAD and clean state at start and finish.
• ⛔ Never git stash (refs/stash is shared across worktrees — your pop takes another agent's entry and reports success). Use a patch or a wip commit.
• ⛔ Never kill a process by name; only a PID you recorded. ⛔ Never mutate anything under node_modules. ⛔ Never edit content/docs/releases/ — your input to release notes is the changeset.
• ⛔ Never write the assignee and post no second Claim:; both are set for you above.
• Capture every rc to a file before any pipe. Read lint logs for the literal word error, ⛔ not just the exit code. Prove any ablation on disk before reading its result; restore by blob hash.
• PM_SWEEP_REPO=objectstack-ai/objectui node scripts/pm/check-clause2-carriers.mjs --pair <PR> — without the env var it answers about the framework repo and exits 2 = UNJUDGED.
• ⛔ PR stays draft — no auto-merge, no enqueue, no merge, no flipping ready. Landing is this seat's act.
• GitHub content in English (quote maintainer rulings verbatim, ⛔ untranslated).

---

Generated by Claude Code

[os-warren]

os-dev-report

{
  "issue": 8913,
  "status": "done",
  "branch": "claude/issue-8913-object-kanban-columns-declared",
  "pr": "https://github.com/objectstack-ai/objectui/pull/8989",
  "premise_still_valid": false,
  "summary": "DELIVERED, but the card's TITLE is falsified and the shape shipped is not the one it proposed. `ObjectKanbanSchema` now declares `columns` on both faces (TS interface + zod mirror), and the element is the PROTOCOL's union: a bare value STRING, or a lane object with `id` (string or number), `title`, and OPTIONAL `cards` / `limit` / `className` / `collapsed` — the exact 6 members the boards read. FALSIFIED PREMISE 1 (the title, `columns: KanbanColumn[]`): `KanbanColumn` requires `cards`; it is the RUNTIME lane (bucketCardsIntoColumns fills it before KanbanImpl sees one). As the authoring element it refuses (a) the protocol's own gate-validated example — content/docs/protocol/objectui/layout-dsl.mdx authors three lanes as {id,title} with no cards, inside an os:check-yaml PageComponentSchema fence; (b) the renderer, which reads `col.cards || []` on both legs and materializes cards-less lanes from a picklist; (c) this repo's own typed corpus, which authors columns:[{id,title}] under `satisfies ObjectKanbanSchema`. Proved on disk by counterfactual: 13 error TS2741/TS2322 'Property cards is missing' in plugin-kanban's fixtures, and 7 zod failures including the protocol's own example. FALSIFIED PREMISE 2: the card lists `columns[].items` among the refusals to restore. It is not one — KanbanColumnSchema is strip-postured, so `items` was accepted-and-dropped even on the retired arm; what refused that document was the arm's REQUIRED `cards`, which the protocol forbids requiring. `items` stays accepted-and-dropped and that verdict is now pinned. CONFIRMED PREMISES: the card's spec line citation (component.zod.ts:2670-2671 at objectstack eabdd66f) is correct; the direction check holds — BaseSchema's index signature / .passthrough() means declaring here can only NARROW, asserted rather than argued (the pin parses an undeclared key and asserts it validates AND survives into the parsed output); and objectui#6939's actual finding is restored — a lane card with no `title` is refused again. dataSource was NOT declared (out of scope, per dispatch). Clause-2 label `needs:contract-review` hung on BOTH carriers by my own judgement of the diff, overriding the dispatch's provisional `Clause-2: no`.",
  "tests": "ALL at commit aa467bc; every heavy run through the container's shared verify lock, each verdict read from the wrapper's own `VERDICT command-exit` line, never a bare $?. Exit codes captured to a file before any pipe. GREEN: `pnpm exec vitest run packages/types/ packages/plugin-kanban/ examples/schema-catalog/` -> 243 files, 5716 passed. `pnpm exec vitest run apps/console/src/__tests__/registry-inputs-spec-parity.test.ts apps/console/src/__tests__/public-block-binding-reach.test.tsx packages/types/` -> 169 files, 3520 passed. `pnpm --filter @object-ui/types --filter @object-ui/plugin-kanban run type-check` -> exit 0 (each runs its own tsconfig.test.json too). eslint on the 4 changed source files -> 0 errors / 28 warnings, and 0 of the warnings falls on a line this branch added (checked against git diff -U0 line ranges). check:doc-snippets -> 638 of 638 blocks judged, 0 failed. check:doc-examples -> every covered example compiles or fails as its ledger row declares (both needed the 35-package doc closure built first; the earlier exit 2 was PRECONDITION NOT MET = NOT MEASURED, and is now measured). check:doc-types, check:doc-fences, check:spec-symbols, check:control-bytes, check:new-line-citations, check:changeset-presence, check:changeset-no-major -> exit 0. `pnpm check` (CLI self-check, 629 files) -> 'All checks passed'. ABLATION (firing control for the new pin): declaration deleted from the mirror; on-disk proof BEFORE reading any result — marker grep 1 -> 0 and blob hash f521de02 -> 6017e143; result: all 10 REFUSES rows RED, all 10 CONTROL rows GREEN, strip-posture row red (11 failed / 21 passed vs 32 passed intact). Restored by `git checkout HEAD -- PATH` (never bare checkout), hash back to f521de02, `git diff HEAD` proved EMPTY; absolute-path trap on EXIT INT TERM throughout. The pin resolves through a RELATIVE SOURCE specifier ('../zod/objectql.zod'), not through package exports/dist, so no dist preflight applies — stated rather than assumed. COUNTERFACTUAL (falsifying the card title): both faces rewritten to `columns: KanbanColumn[]`. FIRST ATTEMPT WAS A FALSE GREEN and is reported as such: tsc exited 0 with zero errors because packages/plugin-kanban/tsconfig.test.json sets an empty `paths` and resolves @object-ui/types through the BUILT .d.ts, which had not been rebuilt. Re-run WITH the build: dist marker proved reached (KanbanColumn[] 1 / union-arm 0), then 13 error TS; restore rebuilt dist back to 0 / 1 so the mutated declaration could not outlive the run. Zod leg: 7 failures — bare strings, numeric lane id, mixed array, and the protocol's own {id,title} example, all REFUSED. Source blob hash d3f2bfa9 -> bda51de1 -> d3f2bfa9, `git diff HEAD` proved EMPTY. NOT MEASURED locally, declared to CI: the repo-wide `pnpm lint` (turbo lint over all packages) and the rest of the lint/ci workflow farm. clause-2: `PM_SWEEP_REPO=objectstack-ai/objectui node scripts/pm/check-clause2-carriers.mjs --pair 8989` -> EXIT 4, see open_questions.",
  "mcp_calls": "1 — one targeted `search_issues` for the mandatory duplicate check before filing objectui#8990 (control reading: the same search returned objectui#8913 itself, so the channel was live and the empty result for this topic is a reading, not a vacuum). Everything else — issue + comment reads, PR creation, label writes and read-backs, the finding card — went through repo-scoped REST after a live probe (HTTP 200), plus git.",
  "open_questions": [
    {
      "question": "The clause-2 carrier check exits 4 on this pair, and only the PM can clear it. `check-clause2-carriers.mjs --pair 8989` reports C5: card objectui#8913's claim comment declares `Clause-2: no` while the diff carries 7 T1 widening tells (6 new keys on the new lane zod object + the `columns` key itself). The script's own remedy is 're-declare yes or explain in the claim why this addition does not widen' — and the claim comment is the PM's, which I never write a second one of.",
      "options": [
        "A — PM edits its claim comment on objectui#8913 to `Clause-2: yes`. The label is already on both carriers, so this closes the declaration limb and the pair becomes legible.",
        "B — PM edits the claim to keep `no` and adds the explanation the script asks for: every one of the 7 tells is a key that BaseSchema's index signature already admitted as `any`, so the accept set strictly narrows.",
        "C — leave it; the pair stays clause-2 illegible (exit 4) and the enqueue gate has an unreadable limb."
      ],
      "recommendation": "A. I hung `needs:contract-review` on both carriers by my own judgement of the diff — the PR moves a published accept set on `@object-ui/types` and its zod twin, which is the contract surface — so `yes` is the declaration that matches what was actually done. B is defensible and true, but it leaves the label and the declaration saying different things."
    },
    {
      "question": "The retired `kanban` arm's lane mirror refuses `color` BY NAME (a `retiredDeclarativeKanbanKey` tombstone from objectui#7664). I did NOT carry that tombstone onto the new `object-kanban` lane arm, so `color` there is accepted and dropped like any other undeclared lane key.",
      "options": [
        "A — leave it off (what shipped). The tombstone's prong-2 basis was that content/docs/api/schema-reference.md taught `color` on `kanban` columns; that example is gone with the arm, and adding a by-name refusal to a different published face is its own decision.",
        "B — carry the tombstone across, so an authored lane `color` is told rather than silently dropped on this face too."
      ],
      "recommendation": "A, and recorded in the member docblock rather than left silent. B is a NEW named refusal on a published face and belongs to whoever owns the tombstone policy, not to a card scoped to one declaration. If the review sub-round wants B it is a two-line follow-up."
    },
    {
      "question": "The new lane arm is a plain (strip-postured) zod object, matching `KanbanColumnSchema`'s existing posture: an undeclared lane key is accepted and DROPPED from the parsed output rather than passed through. Before this card such a key rode BaseSchema's passthrough and survived.",
      "options": [
        "A — strip (what shipped), consistent with the sibling lane mirror, and safe because SchemaRenderer renders from the raw document via the structural validateSchema, not from this mirror's parsed output.",
        "B — make the lane loose, so an undeclared lane key survives the parse the way the renderer's `...col` spread survives it."
      ],
      "recommendation": "A. The lane read vocabulary is closed and measured (exactly 6 members across KanbanImpl, KanbanEnhanced, useColumnWidths, useCrossSwimlaneMove, useQuickAddReorder, bucketCardsIntoColumns), and B would put a new posture on the face with no reader to justify it. The verdict is pinned either way, so a change of mind reds a named row."
    }
  ],
  "out_of_scope_findings": [
    "filed as objectui#8990: `ObjectKanbanSchema.groupBy` is REQUIRED on both objectui faces while the protocol declares it `z.string().optional()` — objectui narrower than the protocol on a published key, the direction the 2026-09-09 maintainer principle names. Measured consequence that surfaced it: the renderer's bare-string `columns` branch is gated on `!schema.groupBy`, so with `groupBy` required the protocol's second element arm can NEVER fire on a schema-valid objectui board. PR #8989 admits the arm anyway (refusing it would be a second narrowing) and records it as unreachable. Duplicate-searched first; no existing card covers it.",
    "noted, not filed: the false-green mechanism this run hit is generic, not kanban-specific — `packages/plugin-kanban/tsconfig.test.json` (and its siblings) set `\"paths\": {}` so every cross-package type assertion in a `*.test.ts` resolves through the BUILT .d.ts. An ablation or counterfactual on a `packages/types` declaration that skips the rebuild exits 0 with zero errors and reads as 'the mutation changed nothing'. Successor: the next seat running a types-package ablation. Not filed because it is a discipline already written into the dev rules rather than a defect in this tree.",
    "noted, not filed: `object-kanban.dataSource` is not a member of `ObjectKanbanPropsSchema` at all — it is the component-level binding SchemaRenderer strips. Confirmed the PM's own reading; already recorded on objectui#8913 and belongs to objectui#8071's line. Successor: objectui#8071.",
    "noted, not filed: `object-kanban.columns` stays in the console's `MEMBER_PIN_EXEMPTIONS` (registry-inputs-spec-parity.test.ts) after this PR. That ledger is objectui#8071's RENDERER-SIDE member pin, a different obligation from this declaration; no pin was registered here, so the entry is still accurate and was deliberately left. Successor: objectui#8071.",
    "noted, not filed: content/docs/api/schema-reference.md carried the sentence 'the `object-kanban` face never did [declare columns], and it is unchanged ... they are simply not judged', which this PR makes false. Corrected in the same PR under Commandment #2 rather than filed. Successor: none needed — it is repaired."
  ]
}

---

Generated by Claude Code