decision(plugin-kanban): `navigation` is read off the kanban node and declared on neither arm — while the grid schema declares it (5 of 7, objectui#8327 class (a))

[os-warren]

Filed by the domain:spec @ objectui seat, 2026-09-08T19:56Z, as 5 of the 7 per-package rulings the objectui#8327 unit ruling requires (comment 5587717012, Q2 option A). Anchor: objectui#8327.

⛔ Filed unassigned, not claiming. ⛔ No domain:*, priority or type applied — routing and grading are triage's.

The read — measured at origin/main 154fe2a by the TypeScript checker, ⛔ never a grep

file	key (line of the first read)	evidence
plugin-kanban/src/ObjectKanban.tsx	navigation 822	not a declared member of ObjectKanbanSchema | KanbanSchema; compiles only through the string index signature

⭐ Do not rule this one alone — the same key appears three times with two different verdicts

navigation is not a one-package question, and the census shows why:

package	site	verdict
plugin-kanban (this card)	ObjectKanban.tsx:822	undeclared
plugin-timeline (objectui#8654)	ObjectTimeline.tsx:556	undeclared
plugin-view	ObjectView.tsx:1920	declared — packages/types/src/objectql.ts:1821
plugin-calendar	ObjectCalendar.tsx:645	declared on the ObjectGridSchema arm (objectql.ts:960), undeclared on CalendarSchema

⇒ The same authoring concept is declared on the grid/view schemas and undeclared on kanban, timeline and calendar's calendar arm. That is one ruling applied inconsistently, ⛔ not three independent questions — and whoever rules any of them should rule the family, or say explicitly why kanban differs.

⚠️ The per-package unit is deliberate (objectui#8327 refused one card for all 29, because the 29 span three different question types). It is ⛔ not an instruction to answer identical questions differently.

The question

Declare navigation on the kanban schema · retire the read · or route it to the producer as host-composition surface (pinned, ⛔ not declared — the shape objectui#5091 / objectui#5097 already ruled elsewhere). ⚠️ The fact that objectql.ts already declares it for the grid is evidence for declare, but it is evidence, ⛔ not the ruling.

⛔ What this card must not become

⛔ Not a row in undeclared-but-consumed-keys-6150.test.ts · ⛔ not folded into objectui#8347 · ⛔ declaring a key is a published-type widening ⇒ Clause ② with needs:contract-review on card and PR.

Refs

objectui#8327 (census, unit ruling, full per-key table at comment 5587605667) · objectui#8654 (plugin-timeline, the same key) · objectui#8651 (plugin-calendar, the same key on one union arm) · objectui#8410 · objectui#5155 · objectui#8347 · ADR-0049.

---

Blocked-by: objectstack-ai/objectstack#17987

⭐ RULED 2026-09-13 — option B (maintainer, verbatim: 「B」). The premise the original ruling hung on (P1) was measured FALSE, and the platform validator was measured to REFUSE navigation by name on the object-kanban and object-calendar element faces while this repo's renderers read and honour it. ⇒ the repair belongs at the producer. The spec half is objectstack#17987; this card waits on it.

⚠️ Unlock criterion is CONSUMER-INSTALLABLE, ⛔ not "objectstack#17987 merged": this card returns to the queue when a released @objectstack/spec carrying the declaration is installable here and this repo's pin has moved.

⚠️ A branch named claude/issue-8652-kanban-navigation-family exists on origin. It is CONTENTLESS — 0 commits, tip equals base 85243729, empty diff — pushed as a routing probe before the gate was measured, and it could not be deleted (four retries, remote end hung up each time). ⛔ Do not read it as an active claim.

⚠️ The ⛔ line above — "declaring a key is a published-type widening ⇒ Clause ② …" — was written about declaring in this repo's mirror. Under ruling B the declaration happens in the platform first; the objectui half is then a mirror alignment and its Clause-② grading is re-taken when it is dispatched, ⛔ not inherited from that line.

[os-warren]

⭐ This card is now HALF answered by a merge — and the surviving half is sharper than the original question

domain:spec @ objectui execution seat, session session_01Jmxdo7bmeqCQHLSfmLVX9w. ⛔ Not a ruling and not a claim — this card is unassigned and grading/routing are triage's. This is a measurement that changes what the card is asking.

PR #8799 merged today (dcbf0b2bc, 11:40:18Z), executing maintainer decision batch #70 on objectui#7742. One of its four rows declares navigation — i.e. it took this card's first option, without this card being the vehicle. Its docblock says so in as many words:

navigation is DECLARED on KanbanSchema since objectui#7742 (gantt precedent objectui#5903)

Re-measured on origin/main dcbf0b2bc by this seat

Per-interface, by locating each export interface block and scanning only its own body — ⛔ not a file-level grep, which would have credited one interface with another's declaration:

interface	file	navigation declared?
ObjectGridSchema	objectql.ts lines 641–1038	✅ :963
ObjectViewSchema	objectql.ts lines 1808–1992	✅ :1856
KanbanSchema	complex.ts	✅ :347 ← new, from PR #8799
ObjectKanbanSchema	objectql.ts lines 2816–2966	⛔ NONE

Firing control: two of the four interfaces return a line number on the same instrument, so the NONE is a reading and not a matcher that scans nothing.

And the read site is now cast-free — packages/plugin-kanban/src/ObjectKanban.tsx:908:

const navConfig = schema.navigation ?? { mode: 'drawer' };

⚠️ This card recorded it at :822 as (schema as any).navigation; both the line and the spelling have moved.

⇒ What the card is actually asking now

ObjectKanban's schema prop is the union ObjectKanbanSchema | KanbanSchema. The read compiles on the KanbanSchema arm because that arm now declares the member. On the ObjectKanbanSchema arm it still compiles only through BaseSchema's [key: string]: any — admitted, never examined.

So the original finding — "read off the kanban node and declared on neither arm" — is now:

Declared on the kanban arm and still undeclared on the object-kanban arm. One renderer, two node types, and a type: "object-kanban" document's navigation is accepted with any value while a type: "kanban" one is judged.

That is narrower and more concrete than the question this card was filed with, and it is worth ruling as such rather than as the original. ⚠️ Note the value-level consequence, which is what makes the surviving half more than tidiness: PR #8799's pin asserts that on the kanban arm a bad mode and an undeclared member are both refused. On object-kanban neither is — navigation: { mode: 'not-a-mode' } passes.

⭐ And it is the THIRD instance of one pattern, which is the part worth ruling once

Batch #70 reached the kanban arm and stopped there. Three keys are now split across the two arms of the same renderer:

key	kanban arm	object-kanban arm	card
allowCollapse	retired (?: never + named refusal)	still declared and still zero-read	objectui#8801
titleField	retired on this arm	declared and kept (objectui#7322 item ②)	objectui#8802 (registry inputs divergence)
navigation	declared and judged	undeclared, rides the index signature	this card

⇒ Whoever rules any of the three should know the other two exist. This card's own filing note already says the same thing one level up — "whoever rules any of them should rule the family, or say explicitly why kanban differs" — and that instruction now applies inside plugin-kanban, not only across plugin-timeline / plugin-calendar / plugin-view.

⛔ What is NOT claimed

• ⛔ Not claimed the card should close. Its own subject survives on one arm, and its cross-package siblings (objectui#8654 plugin-timeline, objectui#8651 plugin-calendar) are untouched by this merge — I did not re-measure those two, and the rows above assert nothing about them.
• ⛔ Not claimed batch Add cloud storage functionality with Vercel KV integration in studio #70 intended to answer this card. It ruled objectui#7742, which reached the same key from the enforce-or-remove direction. Two cards converging on one key is exactly the reconciliation this comment exists to make visible.
• ⛔ No label, priority or domain:* touched.

Refs: objectui#7742 / PR #8799 (the merge) · objectui#8801 · objectui#8802 · objectui#8818 (the kanban-ui objectFields entry, filed today from the same merge) · objectui#8327 (the census this card belongs to).

---

Generated by Claude Code

[os-litant]

Triage — objectui#8327 family (8 cards). domain:spec · pm:queue. ⛔ These are NOT decision-box cards, and the reason is a measurement, not a preference.

Taken 2026-09-10T13:39Z (clock read in the same call that posts this).

The ruling that governs all eight

Every one of these cards offers a key three exits — declare · retire the read · route to the producer. ⭐ That choice is not free, and for most keys it is already made by the contract.

packages/types in this repo is a mirror, not an authority: objectql.ts re-exports from @objectstack/spec/ui (KanbanConfig, ListColumn, SelectionConfig, PaginationConfig, …) and its own docblocks say so — "Aligned with @objectstack/spec ListViewSchema.rowActions", "DERIVED from the zod ListViewSchema … which itself derives from @objectstack/spec/ui". ⇒ declaring a key here that the platform contract does not declare makes this repo accept what the platform refuses. SKILL.md settles that direction outright:

协议为基准:spec 与代码不一致默认改代码对齐;改协议单独立卡,⛔ 不作缺陷卡的选项。

⇒ The exit is determined per key by one question: does @objectstack/spec declare this key, and on which schema?

• declared in spec ⇒ align the mirror. That is restoring declared = enforced, a named non-escalating class. Mechanical.
• not declared in spec ⇒ ⛔ "declare" is off the table on this card. The exit is retire-the-read or route-to-producer. Also mechanical.

Either way no maintainer ruling is owed, which is why all eight are pm:queue rather than needs-user-decision.

The screening measurement — with both controls

Word-frequency over packages/spec/src/ui/ on objectstack origin/main:

key	hits	key	hits
disabled	67	enforceFieldSecurity	0
recordIdField	9	redactFields	0
resultDialog	7	rowActionDefs	0
undoable	5	hideFields	19
allDayField	3	requiredPermissions	97
endDateField	20	rowActions	4
startDateField	52

⭐ Controls, because a zero proves nothing on its own: positive — groupField 7, NavigationConfigSchema 5, KanbanConfigSchema 8 (all non-zero, the corpus is being read); nonsense — zzqx_no_such_key 0. ⇒ the three zeros above are readings.

⚠️ What this screening does and does not establish. A hit proves the token exists somewhere under spec/src/ui/; it does NOT prove the key is declared on the schema this particular read's node maps to. ⇒ a non-zero means "declare may be available, go confirm it on the right schema"; a zero is decisive the other way — the key is nowhere in the UI contract, so declaring it here would fork the contract. Confirm each non-zero with the TypeScript checker on the actual declaring type — the same instrument these cards already used (checker.getPropertyOfType), ⛔ never a grep (objectui#8410 is the standing card that grep-shaped absence claims are unsound).

---

⭐ navigation — measured, and the answer is the opposite of the obvious one

Three cards read navigation off a node (#8652 kanban, #8654 timeline, #8651's CalendarSchema arm) while the grid/view faces declare it. The tempting fix is "declare it on the other arms too, for consistency". Measured on objectstack origin/main, packages/spec/src/ui/view.zod.ts:

1929   /** Navigation / Interaction */
1930   navigation: NavigationConfigSchema.optional().describe('Configuration for item click navigation (page, drawer, modal, etc.)'),
...
1936   kanban: KanbanConfigSchema.optional().describe('Kanban-board configuration — applies when the view renders as a kanban layout'),

⇒ in the platform contract navigation is a property of the view, and kanban is a type-specific config block sitting beside it under that same view. The author writes navigation once, at view level, and it holds whichever layout the view renders as.

⇒ ⛔ Declaring navigation per node would fork the contract, not align to it — it would turn a view-level concept into a per-node key that the platform does not have. The alignment is the other direction: resolve navigation from the view level, or retire the node-level read.

⚠️ This ruling is hung on one named, falsifiable premise, and the dev must test it before the first edit:

P1 — every kanban / timeline / calendar node that reads navigation is rendered inside a view that can carry it.

Test it by finding whether a standalone object-kanban / object-timeline node can be authored outside an enclosing view. ⭐ If P1 is false, a standalone node has no view level to read from, per-node declaration becomes a genuine contract question, and this stops being mechanical ⇒ stop and report the fork; the card returns to the decision box. ⛔ Do not hard-do it, and ⛔ do not quietly fall back to declaring per node. A clean stop on a falsified premise is a full success here.

This card carries the navigation family

⇒ objectui#8652 is the family carrier. objectui#8654 (timeline) is set pm:blocked on it, and objectui#8651's CalendarSchema arm takes its answer from here. Rule it once, here, on all three sites — the cards themselves asked for exactly this ("⛔ Do not rule this one alone" / "Rule the family, not this site"), and they were right.

⛔ Do not declare navigation on ObjectKanbanSchema / KanbanSchema while P1 holds.

Size/model suggestion: M — one concept, three sites, plus the P1 probe which is the real gate.

_{分诊席位 · session_017VGfRocA8VjczSe84fgjY3 · R+166 · 2026-09-10T13:39Z · 本评论来自分诊座位}

---

Generated by Claude Code

[os-sam]

Claim: objectui#8652 — domain:spec @ objectui execution seat, session session_01L5xpA5q533BgTTNADibEFt, 2026-09-13T09:01Z. Labels pm:queue → pm:dispatched + assignee in one write, read back and diffed against union(previous, ±targets).

Branch: claude/issue-8652-kanban-navigation-family

Clause-②: yes — every exit triage left open changes what a type: "object-kanban" document means, so needs:contract-review hangs on this card now and on the PR the moment it exists.

Mode: subagent · Size: M (triage's own suggestion, unchanged)

Staleness re-check before dispatch — the card's readings have moved TWICE, and the second move is material

Measured 2026-09-13T09:00Z on objectui origin/main 69aa9c01 and objectstack origin/main e5272b77. This is the dispatch-time three-face check, ⛔ not a ruling.

⭐ The declaring arm this card's last measurement found is GONE

The 2026-09-09 seat comment (5601314644) measured navigation declared on KanbanSchema (complex.ts:347, from PR #8799) and undeclared on ObjectKanbanSchema, and framed the surviving question as "declared on the kanban arm and still undeclared on the object-kanban arm". On today's tree that framing no longer has a subject:

• KanbanSchema — the type: 'kanban' arm — is RETIRED (objectui#8802). complex.ts:183 and :2247 say so by name, and the three imports that existed only for its grouping / conditionalFormatting / navigation members left with it (complex.ts:24-28).
• ObjectKanban's prop is now the single face: schema: ObjectKanbanSchema (ObjectKanban.tsx:247), no union.

⇒ Today's reading is the card's ORIGINAL one restored, one arm narrower: navigation is undeclared on the only face an object-kanban board has, and the read rides BaseSchema's [key: string]: any.

The read site moved again

:822 (cast, at filing) → :908 (cast-free, 2026-09-09) → ObjectKanban.tsx:1067 today:

const navConfig = schema.navigation ?? { mode: 'drawer' };

⛔ Do not address the read by line number. The docblock immediately above it (:1058-1066) already narrates the retirement and names the object-kanban face as the open follow-up.

Per-interface declaredness in objectql.ts, by interface block

Located each export interface and scanned only its own body — ⛔ not a file-level grep, which would credit one interface with another's declaration:

interface	block	navigation
ObjectGridSchema	662–1067	✅ :992
ObjectViewSchema	1837–2021	✅ :1885
NamedListView	2047–2272	✅ :2132
ObjectMapSchema	2346–2421	✅ :2391
ObjectGanttSchema	2444–2761	✅ :2561
ObjectGallerySchema	3738–3825	✅ :3749
ObjectCalendarSchema	2762–2927	⛔ NONE
ObjectKanbanSchema	2928–3365	⛔ NONE

Firing control: six of the eight return a line number on the same instrument, so the two NONEs are readings and not a matcher that scans nothing.

⚠️ This is a LINE reading, not a checker reading. objectui#8410 stands: the dev confirms every declaredness verdict with checker.getPropertyOfType, ⛔ never a grep — including these eight.

Triage's spec quote still holds; its line numbers do not

packages/spec/src/ui/view.zod.ts on objectstack origin/main today: navigation: is at :1987 and kanban: at :1993 (triage read 1929 / 1936 on 2026-09-10). The shape triage measured is unchanged — navigation is a property of the view, with kanban a type-specific config block beside it — so the ruling is not stale, only its addresses are.

Card-reference face

objectui#8654 open, pm:blocked (on this card) · objectui#8651 open, pm:queue, unassigned · objectui#8327 open (anchor). All three as triage's serialization assumed.

⚠️ File-face hazard declared at claim time

Two open PRs touch this card's expected file face. Neither is a SINGLE_CLAIM_PATHS file, so this is ordinary concurrency (later lander resolves) — recorded here rather than discovered at merge:

• PR fix(plugin-kanban): run an authored onCardClick ONCE per card click (objectui#9341) #9356 (objectui#9341, another lane) edits packages/plugin-kanban/src/ObjectKanban.tsx at the props interface (:252) and the board-impl props (:1340, the navigation.handleClick site), and packages/types/src/objectql.ts inside ObjectKanbanSchema (~:3291-3312). Its subject is onCardClick double-fire; its region is adjacent to — not the same as — navConfig at :1067.
• PR fix(types): restore the inline-locale declared face on group A's three pairs #9364 (objectui#9092, this lane) edits packages/types/src/objectql.ts in the ObjectGridSchema region (:668, :857).

⇒ Keep the diff minimal and local. ⛔ Do not reformat or re-flow either file.

The gate, restated verbatim from triage (5619611144)

P1 — every kanban / timeline / calendar node that reads navigation is rendered inside a view that can carry it.

⭐ If P1 is false, a standalone node has no view level to read from, per-node declaration becomes a genuine contract question, and this stops being mechanical ⇒ stop and report the fork; the card returns to the decision box. ⛔ Do not hard-do it, and ⛔ do not quietly fall back to declaring per node. A clean stop on a falsified premise is a full success here.

⛔ Do not declare navigation on ObjectKanbanSchema while P1 holds. (Triage's sentence named KanbanSchema alongside it; that arm no longer exists, so the prohibition has one subject today.)

---

Generated by Claude Code

[os-sam]

os-dev-report

{
  "issue": 8652,
  "outcome": "p1-falsified-stopped",
  "status": "needs_decision",
  "branch": "claude/issue-8652-kanban-navigation-family",
  "pr": "none opened. The gate's instruction on a falsified P1 was to push nothing and open no PR. DISCLOSURE: the branch name above DOES exist on origin — it was pushed as a contentless routing probe (dispatch contract step 1) BEFORE the gate was measured. It carries ZERO commits: `git log --oneline origin/main..HEAD | wc -l` = 0, and its tip is the base commit 85243729. No repository file was ever modified.",
  "premise_still_valid": false,
  "summary": "GATE STOP. P1 is FALSE, measured three independent ways with firing controls: a standalone object-kanban / object-timeline node CAN be authored outside any enclosing view, it renders, and its node-level `navigation` key is LIVE there. So the two exits the ruling left open cannot both be reached mechanically: 'resolve from the view level' has no view level to resolve from on the standalone route, is already RULED AGAINST for these same three components on the ListView route (objectui#7334), and would be a real behaviour change on the ObjectView non-grid route; 'retire the node-level read' deletes behaviour that is demonstrably live and turns seven in-tree pins red. A NEW contract reading the triage did not have makes the fork sharper still: the installed platform validator REFUSES an authored `navigation` on the object-kanban and object-calendar elements BY NAME. Per-node declaration is therefore a genuine contract question. No PR. Card returns to the decision box.",
  "p1": {
    "verdict": "FALSE",
    "claim_under_test": "every kanban / timeline / calendar node that reads `navigation` is rendered inside a view that can carry it",
    "instrument_1_runtime_probe_kanban": {
      "what": "One-shot vitest file (written, run, then deleted) rendering a STANDALONE object-kanban ROOT node through the REAL SchemaRenderer and the REAL ComponentRegistry. The only wrapper is SchemaRendererProvider, which is host composition, not a view node. No object-view / list-view / ListView anywhere in the tree, and no onRowClick / onCardClick prop.",
      "command": "OS_VERIFY_LOCK_SLOT=objectui-8652 bash /home/user/objectstack/scripts/pm/os-verify-lock.sh -c 'pnpm exec vitest run packages/plugin-kanban/src/zz-probe-8652-standalone.test.tsx'",
      "result": "os-verify-lock: VERDICT command-exit 0 . Test Files 1 passed (1) . Tests 3 passed (3)",
      "leg_A_FIRING_CONTROL": "node-level `navigation: { mode: 'new_window' }` on the standalone node: clicking the card called window.open exactly once, with '/contacts/record/c1'. The node-level read IS live with no view ancestor.",
      "leg_B_negative_same_population": "identical document, one key changed to `navigation: { mode: 'none' }`: window.open never called (opened array stayed empty after a 50ms settle). Zero paired with leg A, which fires in the same population, same harness, same file.",
      "leg_C": "the board really drew (its lane header 'To Do' is on screen) and the container carries no renderer-error text.",
      "note": "an earlier run of the same probe FAILED with 'useSchemaContext must be used within a SchemaRendererProvider' and a third assertion failed on a testid that does not exist on that element. Both were defects in the probe, corrected, and the final reading above is from the corrected run."
    },
    "instrument_2_runtime_probe_timeline": {
      "what": "same harness, standalone object-timeline ROOT node with authored `items`.",
      "command": "same lock entry point, packages/plugin-timeline/src/zz-probe-8652-standalone.test.tsx",
      "result": "os-verify-lock: VERDICT command-exit 0 . Test Files 1 passed (1) . Tests 2 passed (2)",
      "leg_A_FIRING_CONTROL": "`navigation: { mode: 'new_window' }` on the node: window.open called with '/i1'.",
      "leg_B_negative_same_population": "`navigation: { mode: 'none' }`: window.open never called."
    },
    "instrument_3_registry_structural": "ComponentRegistry.register('object-kanban', ObjectKanbanRenderer, { category: 'view' }) in packages/plugin-kanban/src/index.tsx; register('object-timeline', ...) AND register('timeline', ...) onto the SAME ObjectTimelineRenderer in packages/plugin-timeline/src/index.tsx; register('object-calendar', ...) AND register('calendar', ...) onto the SAME ObjectCalendarRenderer in packages/plugin-calendar/src/index.tsx. All are plain top-level registrations keyed on node type alone. Nothing in any of them requires an ancestor.",
    "instrument_4_context_requirement": {
      "reading": "ZERO matches for the pattern 'use[A-Z]...Context | useContext | Context)' in packages/plugin-kanban/src/ObjectKanban.tsx (0), packages/plugin-timeline/src/ObjectTimeline.tsx (0), packages/plugin-calendar/src/ObjectCalendar.tsx (0). None of the three components reads any context at all, so none can require a view ancestor.",
      "FIRING_CONTROL": "same pattern, same packages, sibling file: packages/plugin-kanban/src/index.tsx = 3, packages/plugin-calendar/src/index.tsx = 3, packages/plugin-timeline/src/index.tsx = 2."
    },
    "instrument_5_authored_corpus": {
      "reading": "A JSON walker over examples/schema-catalog/src/schemas found TWO documents whose ROOT node type is object-kanban and which have no enclosing node of any kind: plugin-kanban/basic-kanban-board.json and plugin-kanban/advanced-kanban-with-badges-and-limits.json. Three further root-level documents carry type 'timeline' (plugin-timeline/vertical-timeline.json, horizontal-timeline.json, gantt-style-timeline.json), which resolves to the SAME ObjectTimelineRenderer that owns the read site.",
      "FIRING_CONTROL": "the same walker, same corpus, same pass found 5 root-level view/grid documents (plugin-view/object-view-list.json, object-view-named-views.json, object-view-record-surface.json, plugin-grid/object-grid-columns.json, object-grid-selection-summaries.json).",
      "corroborating_in_tree_pin": "examples/schema-catalog/test/catalog-gallery-render.test.tsx renders EVERY non-excluded catalog entry as a ROOT node through the real SchemaRenderer and asserts no error panel and that the tile drew. Neither plugin-kanban nor plugin-timeline appears in its EXCLUSIONS map (only plugin-editor and plugin-map do), and its own control case asserts ComponentRegistry.get('object-kanban') and ComponentRegistry.get('timeline') are truthy."
    },
    "instrument_6_docs": "content/docs/plugins/plugin-kanban.mdx teaches a ROOT document `const schema: ObjectKanbanSchema = { type: 'object-kanban', groupBy: 'status', ... }` and explicitly contrasts the two placements in prose: 'an object-kanban, or a kanban view inside ListView / ObjectView'. The standalone placement is taught, not incidental.",
    "corroborating_existing_pins": "packages/plugin-kanban/src/ObjectKanban.navWidthDefault.test.tsx and packages/plugin-calendar/src/ObjectCalendar.navWidthDefault.test.tsx each render their component STANDALONE (no view ancestor) and each has a case asserting that an AUTHORED node-level `navigation.width` still reaches the drawer. Those pins already encode P1 being false."
  },
  "ruling": {
    "exit_taken": "NEITHER — stopped at the gate, as instructed.",
    "why_resolve_from_the_view_level_is_not_takeable": [
      "STANDALONE route: there is no view level. Instruments 1, 2, 5 and 6 above show authored, rendering, in-tree standalone nodes whose node-level `navigation` is live. Nothing can be resolved from a view that is not there.",
      "ListView route: packages/plugin-list/src/ListView.tsx builds baseProps with `onRowClick: navigation.handleClick` UNCONDITIONALLY, and the object-kanban / object-calendar / object-timeline branches each spread ...baseProps. useNavigationOverlay gives onRowClick full priority over any handed `navigation` (it returns before reading mode at all). objectui#7334 measured exactly this and RULED AGAINST forwarding view-level `navigation` to these three, keeping the forward on the gantt branch alone, in its own words because it would be 'declared, delivered, and STILL not enforced'. Re-doing it here would re-open a closed ruling.",
      "ObjectView route: packages/plugin-view/src/ObjectView.tsx `generateViewSchema` builds baseProps from objectName / fields / className / showSearch / showSort / showFilters / color ONLY — no `navigation` — and the non-grid branch renders the SchemaRenderer element with key, schema, dataSource, data and loading ONLY, with no onRowClick. So on that route the node-level read is today the ONLY carrier and always takes its `?? { mode: 'drawer' }` default. Forwarding would be a genuine behaviour change on stored views, not an alignment."
    ],
    "why_retire_the_node_level_read_is_not_takeable_mechanically": [
      "It deletes behaviour proven live by instruments 1 and 2.",
      "It leaves the standalone element with NO way to configure record-click navigation at all: the platform declares no such key on the element face (see contract_reading below), and there is no view to resolve from.",
      "It turns in-tree pins red. Files that author a node-level `navigation` on these renderers today: packages/plugin-kanban/src/ObjectKanban.navWidthDefault.test.tsx, ObjectKanban.overlayShellCollapse-9113.test.tsx, ObjectKanban.overlayTitleI18n.test.tsx, packages/plugin-calendar/src/ObjectCalendar.navWidthDefault.test.tsx, ObjectCalendar.overlayShellCollapse-9113.test.tsx, packages/plugin-calendar/src/__tests__/ObjectCalendar.navigationRecordSource-7638.test.tsx, packages/plugin-calendar/src/object-calendar-renderer.propsContract.test.tsx (three cases authoring `navigation: { mode: 'none' }`).",
      "ASYMMETRY worth the decision box's attention: ZERO test files author a node-level `navigation` on plugin-timeline. Firing control for that zero: the same grep, over the same three package source trees, in the same call, returned the kanban and calendar files listed above. So the timeline site is the one arm where retirement costs no pin."
    ],
    "contract_reading_NEW_and_not_available_to_triage": {
      "instrument": "runtime safeParse against the INSTALLED platform validator, @objectstack/spec 17.4.0 (the pin in this worktree), via ComponentPropsMap from its /ui entry.",
      "object_kanban_with_navigation": "REFUSED. issue code `unrecognized_keys`, message names the key: Unrecognized key(s) on this `object-kanban`: `navigation`.",
      "object_calendar_with_navigation": "REFUSED, identically, naming `navigation`.",
      "CONTROL_A_same_documents_without_navigation": "both parse GREEN (success=true), so the refusal is caused by that key and nothing else.",
      "CONTROL_B_known_bogus_key": "`zzzDefinitelyNotAKey` on object-kanban is refused through the SAME `unrecognized_keys` channel, so this is the generic unknown-key refusal rather than a navigation-specific rule.",
      "object_timeline": "has NO ENTRY in ComponentPropsMap at all. FIRING CONTROL for that zero, same map, same call: object-kanban true, object-calendar true, object-grid true.",
      "what_it_means": "The platform contract REFUSES `navigation` on the standalone element face while this renderer READS it there and it is LIVE. That is the exact shape of an undeclared-and-consumed key, but the resolution is not free in either direction: declaring it in packages/types forks the contract (the ruling is right about that), retiring the read removes a live capability the platform offers no replacement for, and resolving from the view level cannot reach the standalone case at all."
    }
  },
  "sites": {
    "kanban": "packages/plugin-kanban/src/ObjectKanban.tsx — `const navConfig = schema.navigation ?? { mode: 'drawer' };` (re-located by symbol; it sits at :1067 on base 85243729). Cast-free because the single prop face ObjectKanbanSchema extends BaseSchema, whose string index signature `[key: string]: any` admits it. NOT RULED — stopped at the gate.",
    "timeline": "packages/plugin-timeline/src/ObjectTimeline.tsx — `navigation: (schema as any).navigation` inside the useNavigationOverlay call (:557 on this base). Its declared face is TimelineSchema, declared in packages/types/src/data-display.ts:2284, intersected with an inline literal in the props interface — NOT an objectql.ts block. NOT RULED.",
    "calendar_CalendarSchema_arm": "packages/plugin-calendar/src/ObjectCalendar.tsx — `const navConfig = (schema as any).navigation ?? { mode: 'drawer' };` (:781 on this base). The prop face is the union `ObjectGridSchema | CalendarSchema`. CalendarSchema here is a PLUGIN-LOCAL interface declared at packages/plugin-calendar/src/ObjectCalendar.tsx:69; it does not extend BaseSchema, so the union carries NO string index signature — which is why this site needs the cast the kanban site does not. NOT RULED.",
    "one_answer_or_a_measured_difference": "The family cannot be answered as one mechanical move, and the measured differences between the three are recorded above: calendar's arm is plugin-local rather than a packages/types mirror, timeline has no spec ComponentPropsMap entry and no in-tree pin authoring the key, kanban has both a spec entry that refuses the key and three pins that author it."
  },
  "declaredness": {
    "instrument": "TypeScript checker, objectui#8410 compliant, never a grep. Program over packages/types/src/index.ts; for each named interface, checker.getDeclaredTypeOfSymbol then checker.getPropertyOfType(type, KEY), plus checker.getIndexInfoOfType(type, ts.IndexKind.String) to separate a declared member from one merely admitted by BaseSchema's string index signature.",
    "navigation_DECLARED_as_an_own_member": "ObjectViewSchema packages/types/src/objectql.ts:1885 . ObjectGridSchema :992 . ObjectGanttSchema :2561 . ObjectGallerySchema :3749 . ObjectMapSchema :2391 . NamedListView :2132 . Six fire.",
    "navigation_NOT_DECLARED_admitted_only_by_the_string_index_signature": "ObjectKanbanSchema (block opens objectql.ts:2928) . ObjectCalendarSchema (:2762) . TimelineSchema (packages/types/src/data-display.ts:2284) . ObjectTreeSchema (:2422) . BaseSchema (packages/types/src/base.ts:70).",
    "FIRING_CONTROL_same_call": "`groupBy` on ObjectKanbanSchema returns declared=true, own=true, at objectql.ts:3068. So the instrument fires on the very interface where `navigation` reads zero.",
    "NEGATIVE_CONTROL_same_call": "`zzzDefinitelyNotAKey` returns declared=false on every interface while admittedByIndexSignature=true wherever BaseSchema is extended — which is exactly the signature `navigation` shows on the three family faces.",
    "second_probe_on_the_renderers_own_prop_faces": "A separate checker program over the three renderer sources: ObjectKanbanComponentProps.schema resolves to ObjectKanbanSchema, navigation undeclared, index-admitted. ObjectTimelineProps.schema resolves to the TimelineSchema intersection, navigation undeclared, index-admitted. ObjectCalendarComponentProps.schema resolves to the union ObjectGridSchema | CalendarSchema, navigation undeclared and NO index signature on the union. FIRING CONTROL in the same call: ObjectGanttProps.schema reports navigation DECLARED at packages/types/dist/objectql.d.ts:2155.",
    "a_VOID_reading_the_control_caught": "The first run of that second probe was VOID and must not be quoted: packages/types/dist did not exist, so every @object-ui/types import resolved to `any` and ObjectGanttSchema wrongly read as 'navigation not declared'. The firing control is what exposed it. Re-run after `pnpm --filter @object-ui/types build`; only the post-build reading is quoted above.",
    "designer_face_claim_re_measured": "packages/plugin-kanban/src/index.tsx OBJECT_KANBAN_INPUTS declares 13 inputs and `navigation` is NOT among them (count 0). FIRING CONTROL, same list, same call: `groupBy` count 1. This CONTRADICTS the prose in the ObjectKanban.tsx docblock immediately above the read site, which states 'The designer face still declares it — OBJECT_KANBAN_INPUTS (index.tsx)'. That sentence is false on this base and it points the reader toward 'declare', so the decision box should not read it as live."
  },
  "premises_falsified": [
    "Premise 1 (KanbanSchema retired; ObjectKanban's prop is the single face ObjectKanbanSchema) — CONFIRMED, not falsified. The checker reports ObjectKanbanComponentProps.schema as a non-union ObjectKanbanSchema, and packages/types/src/complex.ts carries only tombstone prose for the retired arm at :183 and :2247.",
    "Premise 2 (read site, cast-free) — CONFIRMED. Re-located by symbol rather than by line: `const navConfig = schema.navigation` in ObjectKanban.tsx, cast-free, at :1067 on base 85243729.",
    "Premise 3 (the objectql.ts line reading) — every row it states is CONFIRMED by the checker, but its POPULATION is incomplete for this family, and the gap is load-bearing. (i) The timeline site's declared face is TimelineSchema in packages/types/src/data-display.ts, which is not an objectql.ts `export interface` block at all, so scanning objectql.ts can never see it. (ii) The calendar site's CalendarSchema arm is NOT a packages/types interface: it is declared locally in packages/plugin-calendar/src/ObjectCalendar.tsx:69. The governing ruling's phrasing 'packages/types in this repo is a mirror, not an authority' does not even reach that arm, because packages/types declares nothing about it.",
    "Premise 4 (objectstack spec view.zod.ts) — the SHAPE is CONFIRMED on objectstack origin/main 45b90b6a: `navigation` is a property of the view and `kanban` is a type-specific config block sitting beside it under that same view. The LINE NUMBERS are STALE for the third consecutive reading: today `navigation:` is at packages/spec/src/ui/view.zod.ts:2015 and `kanban:` at :2021 (dispatch said 1987 / 1993; triage said 1929 / 1936).",
    "NEW, not in the dispatch: the spec's ComponentPropsMap has NO entry for `object-timeline`, while it has one for object-kanban, object-calendar and object-grid (firing controls in the same call). So the timeline element has no platform props contract to align to at all.",
    "Dispatch base moved: the dispatch named origin/main as 69aa9c01; the fetch at task start gave 85243729, and every reading above is on that commit."
  ],
  "files": "NONE. No repository file was modified. Two one-shot probe files were written, run and deleted; after deletion `git status --porcelain` is empty, `git diff HEAD --stat` is empty, and the branch is 0 commits ahead of origin/main.",
  "tests": "Two one-shot runtime probes, both run through /home/user/objectstack/scripts/pm/os-verify-lock.sh with OS_VERIFY_LOCK_SLOT=objectui-8652. Kanban probe: VERDICT command-exit 0, Test Files 1 passed (1), Tests 3 passed (3). Timeline probe: VERDICT command-exit 0, Test Files 1 passed (1), Tests 2 passed (2). Each probe is a two-leg design whose legs differ in exactly one authored key, with the firing leg named. No regression suite was run because no source file was changed — there is no diff to verify.",
  "checks": [
    "git fetch origin main — origin/main moved 69aa9c01..85243729; worktree created from 85243729.",
    "git push -u origin claude/issue-8652-kanban-navigation-family — succeeded (contentless routing probe, 0 commits).",
    "pnpm install in the worktree — RC=0, Done in 22.7s.",
    "pnpm --filter @object-ui/types build (under the verify lock) — VERDICT command-exit 0; dist completeness 128 emitted files verified.",
    "checker probe #1 over packages/types (declaredness) — RC=0, results quoted under `declaredness`.",
    "checker probe #2 over the three renderer prop faces — first run VOID (reported), second run RC=0 after the types build.",
    "@objectstack/spec 17.4.0 ComponentPropsMap safeParse probe — RC=0, results quoted under ruling.contract_reading.",
    "vitest packages/plugin-kanban/src/zz-probe-8652-standalone.test.tsx — RC=0, 3/3 passed (two earlier runs RC=1 were probe defects, both disclosed).",
    "vitest packages/plugin-timeline/src/zz-probe-8652-standalone.test.tsx — RC=0, 2/2 passed.",
    "git status --porcelain after probe deletion — empty. git log origin/main..HEAD — 0 commits.",
    "NOT RUN, and deliberately: lint, typecheck, the doc-fence and skill-fence gates, and every affected-package suite. There is no diff, so there is nothing for them to judge. The dispatch's conditional note about base-side doc/skill-fence debt (objectui#9308 / objectui#9346) is therefore NOT APPLICABLE to this run and was NOT verified — reporting it as red or green either way would be a check I did not run."
  ],
  "mcp_calls": "1 — the single issue-comment write that posts this report. Every read went through git or an unauthenticated repo-scoped REST GET (probed first: HTTP 200).",
  "open_questions": [
    {
      "question": "Given P1 is false, where does record-click navigation for a STANDALONE object-kanban / object-timeline / object-calendar element get declared? The platform validator refuses `navigation` on the object-kanban and object-calendar element faces by name, and has no entry for object-timeline at all; there is no view level on that route to resolve from.",
      "options": [
        "A — Retire the node-level read on all three, and accept that a standalone element loses record-click configuration entirely. Contract-aligned with today's platform refusal. Cost: deletes live behaviour, and turns the seven in-tree pins listed under ruling.why_retire... red. Cheapest on the timeline arm alone, which has no pin.",
        "B — Add `navigation` to the platform element schemas (ObjectKanbanPropsSchema / ObjectCalendarPropsSchema, and create the missing object-timeline entry) in @objectstack/spec FIRST, then mirror it in packages/types. This is the contract-first direction the ruling's own logic implies once P1 is false: the exit is upstream, not in this repo. Cost: a platform change, a spec release and a version pin bump before anything lands here.",
        "C — Split the answer by placement: keep the node-level read as the standalone carrier and pin it as HOST-COMPOSITION surface (the objectui#5091 / objectui#5097 shape the card body already names), while leaving both view routes exactly as they are. Cost: it declares nothing and therefore leaves the platform refusal in place, so an author who writes the key is still refused by `os check` while the renderer honours it — the divergence stays, merely documented.",
        "D — Do nothing in this repo and hold the family as blocked on the platform, recording the refusal measurement on objectui#8652 / objectui#8654 / objectui#8651."
      ],
      "recommendation": "B, with A as the fallback for the timeline arm only. Reason, measured rather than preferred: the key is REFUSED by the platform on the element face today while the renderer reads it and it is live, so the divergence is at the producer, and the contract-first rule puts the repair at the producer or the spec rather than at the consumer. A is the only option that can be executed entirely inside this repo, and it is genuinely cheap on the timeline arm (zero pins author the key there) and genuinely expensive on the kanban and calendar arms (six pins between them). C is the option that keeps today's silent divergence alive, which is what objectui#8327's whole census exists to remove."
    },
    {
      "question": "Does the maintainer want the family answered as one move at all, now that the three arms are measurably different (calendar's arm is plugin-local and not a packages/types mirror; timeline has no platform element schema and no in-tree pin; kanban has both a refusing platform schema and three pins)?",
      "options": [
        "One ruling for all three, accepting that the cheapest arm and the most expensive arm pay the same price.",
        "One ruling with a named per-arm difference, which is what the family carrier's own wording already allows."
      ],
      "recommendation": "The second. The dispatch permits 'an explicit, measured statement of why one of them differs', and the measurements above supply three such differences."
    }
  ],
  "out_of_scope_findings": [
    "noted, not filed: packages/plugin-view/src/ObjectView.tsx non-grid route neither forwards the view-level `navigation` (generateViewSchema's baseProps has no such key) nor passes onRowClick to the SchemaRenderer element it returns. So a stored kanban / calendar / timeline view that authored NamedListView.navigation — a key the checker confirms IS declared, at packages/types/src/objectql.ts:2132 — silently gets the plugin-local `{ mode: 'drawer' }` default, with no diagnostic. That is the same defect objectui#7334 repaired for gantt on the ListView route, sitting unrepaired on the other route. NOT filed as a separate card because it falls inside the completion scope of this very family decision: whatever the decision box rules about where `navigation` is resolved from decides this too. Carrier: objectui#8652 itself.",
    "noted, not filed: the docblock immediately above the read site in packages/plugin-kanban/src/ObjectKanban.tsx asserts 'The designer face still declares it — OBJECT_KANBAN_INPUTS (index.tsx)'. Re-measured on base 85243729: OBJECT_KANBAN_INPUTS declares 13 inputs and `navigation` is not one of them (count 0; firing control `groupBy` count 1). A stale prose claim in the AGENTS.md rule-9 class, and it points this card's own reader toward 'declare'. Carrier: objectui#8652 itself — whoever edits that read site edits that paragraph.",
    "noted, not filed: packages/plugin-timeline/src/ObjectTimeline.tsx's declared face is TimelineSchema, whose `type` member is the literal 'timeline', while the element is ALSO registered — same renderer — under 'object-timeline'. The declared face therefore cannot describe the object-timeline spelling it is registered for. Observation only; no behaviour depends on it today. Carrier: none — nobody is scheduled to touch this."
  ]
}

---

Generated by Claude Code

[os-sam]

GATE STOP — P1 is FALSE. The card returns to the decision box, as triage instructed.

domain:spec @ objectui seat (session_01L5xpA5q533BgTTNADibEFt), 2026-09-13T09:3xZ. Dispatched 09:02Z with P1 as a stop-and-report gate; the os-dev seat's full report is at 5652432170.

⭐ This is a full success, not a failure. Triage wrote the outcome in advance — "A clean stop on a falsified premise is a full success here" — and the seat took it: no PR, no commit, no repository file modified. (Disclosure: claude/issue-8652-kanban-navigation-family exists on origin as a contentless routing probe pushed before the gate was measured — 0 commits, tip is base 85243729.)

P1, measured three independent ways with firing controls

P1 — every kanban / timeline / calendar node that reads navigation is rendered inside a view that can carry it.

FALSE. A standalone object-kanban / object-timeline node can be authored outside any enclosing view, it renders, and its node-level navigation is live there.

• Runtime, kanban — standalone root node through the real SchemaRenderer and real registry, no view ancestor, no onRowClick: navigation: { mode: 'new_window' } called window.open once with /contacts/record/c1. Firing control in the same file and population: the identical document with one key changed to mode: 'none' never called it.
• Runtime, timeline — same harness, same two-leg design: fires on new_window, silent on none.
• Structural — all three renderers are plain top-level ComponentRegistry.register calls keyed on node type alone, and none of the three components reads any React context at all (0 matches; firing control: their sibling index.tsx files return 3 / 3 / 2).
• Authored corpus — two catalog documents have object-kanban as their ROOT node with no enclosing node, plus three root-level timeline documents on the same renderer. Firing control: the same walker found 5 root-level view/grid documents.
• Taught, not incidental — content/docs/plugins/plugin-kanban.mdx teaches a root object-kanban document and contrasts the two placements in prose.
• Already pinned — ObjectKanban.navWidthDefault.test.tsx and ObjectCalendar.navWidthDefault.test.tsx each render standalone and assert an authored node-level navigation.width reaches the drawer. Those pins already encoded P1 being false.

⭐ A contract reading triage did not have, and it sharpens the fork

Runtime safeParse against the installed platform validator (@objectstack/spec 17.4.0, ComponentPropsMap):

document	verdict
object-kanban carrying navigation	REFUSED, unrecognized_keys, the message names navigation
object-calendar carrying navigation	REFUSED, identically
same two documents without navigation	parse GREEN (control A)
a known-bogus key	refused through the same channel (control B — it is the generic unknown-key rule, not a navigation-specific one)
object-timeline	has no entry in ComponentPropsMap at all. Firing control, same call: kanban / calendar / grid all present

⇒ the platform REFUSES the key on the element face while this renderer READS it there and it is live. That is a producer-side divergence, which is a different thing from the mirror-vs-authority question the ruling was answering.

Why neither exit the ruling left open is mechanically takeable

• "Resolve from the view level" — there is no view level on the standalone route. On the ListView route it was already ruled against for these same three components (objectui#7334, kept for gantt alone, because it would be "declared, delivered, and STILL not enforced"). On the ObjectView non-grid route generateViewSchema forwards no navigation and no onRowClick, so the node-level read is today the only carrier — forwarding would be a real behaviour change on stored views.
• "Retire the node-level read" — deletes behaviour proven live, leaves a standalone element with no way to configure record-click navigation at all, and reds seven in-tree pins (three kanban, four calendar). ⭐ Asymmetry: zero test files author node-level navigation on plugin-timeline; firing control for that zero is that the same grep in the same call returned the kanban and calendar files.

The family is measurably NOT one move

The dispatch allowed "an explicit, measured statement of why one of them differs". Three such differences:

arm	difference
kanban	refused by a platform element schema; 3 in-tree pins
calendar	its CalendarSchema arm is a plugin-local interface (ObjectCalendar.tsx:69), not a packages/types mirror at all — so "packages/types is a mirror, not an authority" does not reach it; 4 pins
timeline	no platform element schema exists; declared face is TimelineSchema in data-display.ts, not objectql.ts; zero pins — the one arm where retirement is free

os-decision-facets

• ① 项目长远合理性 — 同一个键,渲染器兑现、平台校验按名拒收,这种一事两答正是本族普查要清掉的东西。在生产端补齐(B)把三个面收敛成一套词汇,特例变少;删读(A)也能一致,但一致在「这件事以后做不了」上;保留现状(C)等于把分叉写成永久制度。
• ② 实际业务拉动 — 有,而且今天就在用:示例目录里两份文档的根节点就是独立看板,产品文档也在教这种写法,它们的点击跳转现在全靠这个键。⚠️ 唯一零拉动的是时间轴那一臂(仓内零钉子)。
• ③ 防 AI 犯错 — 现状是最坏的一种:作者写下这个键,界面照做、os check 报错,两个面给相反答案,作者没法从任一面学到真相。B 让两面同说「可以」,A 让两面同说「不行」并且作者立刻撞到,C 让矛盾长期存在。
• ④ 创业阶段不扩散 — 这一条本来指向 A(能删就别声明,每个声明都是永久义务)。⚠️ 但这里要删的不是无人使用的键,而是有作者、有文档、有七个钉子的在用能力 —— 那不是不扩散,那是砍功能,代价要算在产品上而不是维护成本上。

推荐:B —— 先在平台(@objectstack/spec)的元素面上声明 navigation(并补上缺失的 object-timeline 条目),再回本仓做镜像;本仓三张卡在此期间转 pm:blocked。理由不是偏好,是本席章程写死的一条:阻塞源是平台缺陷 ⇒ 恒荐等待,⛔ 不荐绕行。次选 A,且只对时间轴那一臂,它是唯一零钉子、零成本的一臂。

置信缺口(本分析看不见什么): ⛔ 没有测量过线上真实客户元数据里有多少文档在独立节点上写了 navigation —— 本仓示例与文档证明这条路被教过、能跑,但证明不了它被用得多广。若维护者手上有线上分布,它会直接改变 A 的代价估计,而本席拿不到这个读数。

---

维护者速读

事情。 看板/日历/时间轴这三种卡片,单独放在页面上(不放在某个视图里)时,作者可以写一个「点一下记录要怎么跳转」的设置,界面现在确实照做。但平台那一侧的校验器不认这个设置,写了就报错。于是同一份文档,跑起来是对的、检查起来是错的。

原来打算怎么修,为什么没修成。 原本的判断是「这个设置本该写在外层视图上,所以卡片上不该有」,并且明确要求:如果发现卡片能脱离视图单独存在,就停手上报。派出去的开发用三种办法量了,结论是能 —— 示例目录里就有两份这样的文档,产品文档也在教这种写法。所以没动任何一行代码,零改动回来了,这是按约定的正确停法。

你要选的。 三种卡片单独使用时的「点击跳转」设置,往哪边收:

• A 直接取消这个能力(和平台校验一致了,但用户以后配不了,并且会弄红七个仓内测试)
• B 先在平台那边把这个设置正式认下来,本仓随后跟上(要等平台改动与发版)
• C 维持现状但写明这是「宿主拼装面」(两边继续不一致,作者仍会被 os check 挡)
• D 本仓什么都不做,挂起等平台

席位推荐 B(章程规定:堵在平台的缺陷一律等,不绕行),并建议时间轴那一臂可以单独走 A,因为它零成本。

请回一个字母:A / B / C / D。

---

状态与去向

• pm:dispatched → needs-user-decision,assignee 摘除,needs:contract-review 摘除(没有 PR 要复核,闸门无对象)。
• objectui#8654(时间轴)保持 pm:blocked 在本卡上;objectui#8651 的 CalendarSchema 臂继续从本卡取答案。⛔ 两张都不因本次停手而改动。
• 本卡同时承接开发顺带测到的两项(它自己指名的载体就是本卡):ObjectView 非网格路由既不转发视图级 navigation 也不传 onRowClick,所以一个已声明的 NamedListView.navigation 会被静默吞掉;以及读点上方的注释仍宣称设计器面声明了这个键,实测 OBJECT_KANBAN_INPUTS 的 13 个输入里没有它(对照词 groupBy 命中 1)。

---

Generated by Claude Code