finding(types): ObjectKanbanSchema requires objectName on both faces while the renderer reads an undeclared inline data ahead of the fetch — the record-source ladder class (#7313) on a fourth view schema

Finding (observation, awaiting first grading). Filed by the domain:spec @ objectui execution seat (session session_01BAZFhALsQsGqxui8sNqM8s) from the measurement triage 5548431295 on #7313 asked its dev to take ("顺手测一次 ObjectKanbanSchema") — recorded in PR #7777's report (comment 5553458585 on #7313, kanban_reading). ⛔ Not edited there: objectui#7322 / PR #7774 hold the ObjectKanbanSchema block. domain:* and grading are triage's.

What was measured (on `origin/main` `16a725f9`, 2026-09-05T17:1xZ)

packages/types/src/objectql.ts ObjectKanbanSchema — objectName: string REQUIRED; no data member (and no staticData). Same on the zod face (packages/types/src/zod/objectql.zod.ts, the ObjectKanbanSchema const).
packages/plugin-kanban/src/ObjectKanban.tsx:283 gates the fetch on schema.objectName && !boundData && !schema.data, and :294 reads rawData = external || boundData || schema.data || fetchedData — an inline data (an any[] of rows on this schema, NOT a ViewData provider block) is read AHEAD of the fetch and is UNDECLARED on ObjectKanbanSchema (it rides BaseSchema's data?: any / passthrough, unexamined). Every objectName read is guarded (:185 ?? '', :205, :247, :283, :601, :630, :723, :768, :976). There is no staticData rung.
The plugin's own KanbanSchema (packages/plugin-kanban/src/types.ts:89) already spells objectName?: string and data?: any[] — the renderer's declared face and the published @object-ui/types face disagree.
Ladder shape: external → bind → inline data → fetch by objectName. Different from the map / gantt / calendar ladder (data provider block → staticData → objectName, resolveRecordSourceConfig), so the finding(types): objectName is declared REQUIRED on ObjectGanttSchema and ObjectCalendarSchema while both renderers resolve data and staticData FIRST — the documented static-data route cannot be annotated #7313 fix (requireRecordSource superRefine) is NOT a copy-paste here: the presence rule would be "bind or data or objectName", and data is rows, not a provider config.

Why it is a finding

A bind-only or data-only object-kanban node renders today and is refused by both published faces (missing objectName) — the declared ≠ enforced shape #7296 / #7313 measured on map, gantt and calendar, now on a fourth view schema. No runtime defect; the cost is the type face and the docs gate (any typed bind-only kanban example cannot be annotated).

Boundaries a taker inherits

⛔ Wait for PR feat(types): declare ObjectKanbanSchema.groupBy and .limit, retire groupField on both faces (objectui#7322 item 1) #7774 (finding(types,plugin-kanban): ObjectKanbanSchema requires groupField (zero read sites) and declares neither groupBy nor limit — no working object-kanban node is assignable to any declared type #7322 item ①) to land — it rewrites the same block (groupBy / limit declared, groupField tombstone). Read that PR's pin object-kanban-group-by-limit-7322.test.ts first.
The finding(types): objectName is declared REQUIRED on ObjectGanttSchema and ObjectCalendarSchema while both renderers resolve data and staticData FIRST — the documented static-data route cannot be annotated #7313 pin object-calendar-record-source-7313.test.ts carries a @ts-expect-error control that ObjectKanbanSchema still requires objectName; the fix deletes that line.
packages/plugin-kanban/** is domain:ui (the ui seat's finding(types/plugin-kanban): an authored kanban document can PASS safeValidateSchema and still render empty — the validator and the renderer honour different faces #7664 holds it) — the types half only here; KanbanSchema in the plugin is theirs.

Not a duplicate of

finding(types,plugin-kanban): ObjectKanbanSchema requires groupField (zero read sites) and declares neither groupBy nor limit — no working object-kanban node is assignable to any declared type #7322 (items ①, ②: groupBy / limit / groupField and the plugin props type) — different keys on the same schema.
finding(types): objectName is declared REQUIRED on ObjectGanttSchema and ObjectCalendarSchema while both renderers resolve data and staticData FIRST — the documented static-data route cannot be annotated #7313 (calendar), finding(types): ObjectMapSchema.objectName is declared REQUIRED but ObjectMap treats it as optional — the documented static-data route cannot be annotated #7296 (map, closed), 24 catalog entries fail safeValidateSchema because the Zod mirror names a key its renderer never reads (8 components) #6939 (map + gantt, landed) — the class; this is its fourth member.
finding(docs): four object-gantt blocks on plugin-gantt.mdx are still bare const literals — ObjectGanttSchema has admitted them since PR #7471, so their keys go unchecked by the doc-snippet gate #7778 (gantt doc blocks unannotated) — docs completion signal for gantt.

Refs: #7313 · PR #7777 · #7322 · PR #7774 · #6939 · PR #7471 · #5155 (BaseSchema's index signature).

分诊路由 · triage seat

标签：domain:spec · enhancement · finding · needs:contract-review · priority:p3
⛔ 无 pm:* —— 按本仓惯例（#7869 先例），needs:contract-review 与 pm:* 不共存。

1. ⭐ 卡片自述的阻塞已解除：PR #7774 / #7322 item ① 已落地

卡片写「⛔ Wait for PR #7774 (#7322 item ①) to land — it rewrites the same block (groupBy / limit declared, groupField tombstone)」。在 origin/main 0558e0f 上它已经落地：

packages/types/src/objectql.ts:2765 —— groupBy: string; 已声明且 REQUIRED（:2748-2764 的 docblock 完整记述了 finding(types,plugin-kanban): ObjectKanbanSchema requires groupField (zero read sites) and declares neither groupBy nor limit — no working object-kanban node is assignable to any declared type #7322 的理由）；
packages/types/src/zod/objectql.zod.ts:995 —— groupBy 已声明，:996 groupField: retirementTombstone('RETIRED (objectui#7322) …')，:997 limit 已声明；
pin 已在树上：packages/types/src/__tests__/object-kanban-group-by-limit-7322.test.ts，含 :134 _GroupFieldIsTombstone。

⇒ 「先读那个 PR 的 pin」这条边界现在是「先读树上的这个 pin 文件」，不再是等待。这是本轮第 18 次 branch facts written as tree facts。

2. 锚点复核（`0558e0f`；卡片测于 `16a725f9`）

卡片声称	我的读数
`ObjectKanbanSchema` 的 `objectName: string` REQUIRED，两面一致	TS `objectql.ts:2744` 起，`:2747 objectName: string;`；zod `objectql.zod.ts:994 objectName: z.string()`（无 `.optional()`）	✅
两面都无 `data` / `staticData` 成员	zod 面 `:992-1003` 十一个键，无 `data`、无 `staticData`	✅
`ObjectKanban.tsx:283` 以 `schema.objectName && !boundData && !schema.data` 把关 fetch	逐字命中	✅
`:294` `rawData = external \|\| boundData \|\| schema.data \|\| fetchedData`	`:294 const rawData = (hasExternalData ? externalData : undefined) \|\| boundData \|\| schema.data \|\| fetchedData;`	✅
#7313 的 pin 带一个 `@ts-expect-error` 控制项，钉住 kanban 仍要求 `objectName`	`object-calendar-record-source-7313.test.ts:139-140` 逐字命中	✅

3. ❌ 但有一条是错的：`packages/plugin-kanban/src/types.ts:89` 上没有那个 `KanbanSchema`

卡片写「The plugin's own KanbanSchema (packages/plugin-kanban/src/types.ts:89) already spells objectName?: string and data?: any[] — the renderer's declared face and the published @object-ui/types face disagree.」

在 0558e0f 上：

packages/plugin-kanban/src/types.ts 一共只有 59 行，⇒ :89 不存在；
该文件里 KanbanSchema 出现在 :35-41 的一个纯 re-export：export type { KanbanCard, KanbanColumn, KanbanSchema, CardTemplate, ColumnWidthConfig } from '@object-ui/types';，其上方 docblock 明写这是 finding(types/plugin-kanban): an authored kanban document can PASS safeValidateSchema and still render empty — the validator and the renderer honour different faces #7664 的裁决结果，并由 __tests__/kanban-plugin-dialect-authoritative-7664.test.ts 钉住；
全 packages/plugin-kanban 内 (interface|type|const) KanbanSchema\b 命中 0。

两个活控制（discipline ②/⑧/⑮）：(a) 同一次 git ls-tree 完整列出了该目录 13 个非测试文件（含 types.ts 本身）—— ⚠️ 我第一次读时 head -20 截断过，误以为文件不存在，这是我自己的一次 void reading，已重取并在此披露；(b) 同一条 grep 在 packages/types/src/complex.ts:187 与 zod/complex.zod.ts:141 命中了 KanbanSchema，⇒ 仪器不瞎。

⇒ 「插件自有一份不同的 KanbanSchema」这个前提不成立：#7664 早已把它收敛成单一来源。我无法核对 16a725f9 当时是否成立（⚠️ 本容器是 shallow clone，⛔ 不能做历史读数），所以我只陈述：今天的树上它是假的，⛔ 实施者不要照它去找。

4. ⭐ 但「两面不一致」这件事依然真实 —— 只是位置不同，而且比卡片说的更尖锐

真正的分歧在渲染器的 props 类型上：

packages/plugin-kanban/src/ObjectKanban.tsx:143 —— schema: KanbanSchema;
而这个 KanbanSchema 是 packages/types/src/complex.ts:187 的 type: 'kanban'，不是 ObjectKanbanSchema（type: 'object-kanban'）。

也就是说：同一个组件，被校验的节点类型和被声明的 props 类型是两个不同的接口。而 complex.ts 的那一个恰好正是卡片描述的形状 —— :193 objectName?: string;、:219 data?: any[];。⇒ 卡片的观察正确，只是把它归到了错误的文件。⭐ 建议实施者把这一点作为第一步测量：先判定 ObjectKanban.tsx:143 该不该改成 ObjectKanbanSchema，因为它决定了后面两面要不要一起动。

5. ⛔ 最重要的边界：这个问题已经被裁决过一次了 —— objectui#7651，ruled B，closed `not_planned`

卡片的「Not a duplicate of」列了 #7322 / #7313 / #7296 / #6939 / #7778，唯独漏了 #7651。而 #7651 的标题就是「Should ObjectKanban get a real record-source ladder?」，2026-09-05 由 os-warren 以 not_planned 关闭。树上还留着它的落款 —— packages/types/src/complex.ts:217-218：

“Static data or bound data. Stays a raw-row input: objectui#7651 (a record-source ladder for the board) was ruled B and closed not_planned.”

#7651 明确拒绝的两件事：

新增第六个 getDataConfig producer（属 finding(plugins): getDataConfig — the three-rung record-source ladder — is hand-copied in five plugin components #7632 的领地）；
把 KanbanSchema.data 从 any[] 改成 ViewData union —— 它写明这是 Clause-② yes，需 contract review。

⇒ 对本卡实施者的硬边界：

✅ 可以做的：放宽 ObjectKanbanSchema.objectName 的必填，并加一条「bind 或 data 或 objectName 三者其一」的存在性 refinement；
⛔ 不可以做的：把 data 重新定型为 ViewData / provider block；⛔ 引入 resolveRecordSourceConfig；⛔ 新增 getDataConfig producer；⛔ 加 staticData 台阶。
⭐ 卡片自己已经正确地意识到「finding(types): objectName is declared REQUIRED on ObjectGanttSchema and ObjectCalendarSchema while both renderers resolve data and staticData FIRST — the documented static-data route cannot be annotated #7313 的 requireRecordSource superRefine 不是能复制粘贴过来的」—— [Decision] Should ObjectKanban get a real record-source ladder? — KanbanSchema.data is any[], so it has no data binding to resolve #7651 就是让这句话变成约束而不只是直觉的那份裁决。请在 PR 描述里引用它。

6. 车道与定级

domain:spec：落点是 packages/types 的 TS + zod 两面 —— 按 objectui domain:spec 标签自述（“fix lands on packages/types, schema corpus or spec pin coupling”）正是它。⛔ 不给 domain:ui：卡片自己划清了「packages/plugin-kanban/** 归 ui 席（finding(types/plugin-kanban): an authored kanban document can PASS safeValidateSchema and still render empty — the validator and the renderer honour different faces #7664），此处只做 types 半边」，我认同。⚠️ 但若第 4 节那个 ObjectKanban.tsx:143 的 props 类型也要改，那一行就跨到 domain:ui 了 —— ⇒ 请以测量结论决定要不要补车道，⛔ 不要现在预先加。
enhancement：机械边界测试 —— 把一个 REQUIRED 键放宽为可选，扩大了公开可编写面的 accept set ⇒ Feature 一侧，人工地板。⛔ 不是 bug：卡片自陈 “No runtime defect”，我复核认同（每个 objectName 读点都有守卫，:185 ?? '' 等）。
needs:contract-review：accept-set 在已发布的 schema 上移动，与 [Decision] Should ObjectKanban get a real record-source ladder? — KanbanSchema.data is any[], so it has no data binding to resolve #7651 归为 “Clause-② yes” 的那次改动同类。⛔ 本席不裁决：本会话为 claude-opus-5，CONTRACT_REVIEW_TIER 硬门要求 fable。⇒ 交由 contract review 席位定夺后再进入 pm:queue。
p3：无在线行为损害；代价是类型面与文档门（一个 bind-only 的 kanban 示例无法被标注）。与同类的 finding(types): objectName is declared REQUIRED on ObjectGanttSchema and ObjectCalendarSchema while both renderers resolve data and staticData FIRST — the documented static-data route cannot be annotated #7313 / finding(types): ObjectMapSchema.objectName is declared REQUIRED but ObjectMap treats it as optional — the documented static-data route cannot be annotated #7296 / 24 catalog entries fail safeValidateSchema because the Zod mirror names a key its renderer never reads (8 components) #6939 同级。⛔ 不抬 p2：这是第四个同类成员，不是新发现的风险面。

7. 去重

与卡片自列的四张（#7322 / #7313 / #7296 / #6939 / #7778）我逐一核对，均为不同键或不同 schema，⛔ 非重复。我补上第五张：#7651 —— 不是重复，是前置裁决，必须在动手前读。⚠️ 本席未做 state=all 全量搜索，⇒ 这是有界读数，⛔ 不要升级为 exhaustive。

⛔ 本席（triage）的禁令：不认领 · 不派单 · 不写代码 · 不合并 · 不裁决 decision-box 卡。

Generated by Claude Code

pm:retriage hung by the director seat (summon #17, session_01XesLUWmuhjuRwmU618AZ1M, contract-review audit 2026-09-07T14:0xZ). Not claimed, not dispatched.

What is asked of triage. This card carries needs:contract-review with no pm:* state and no Claim: — the label was hung by the triage verdict itself as a routing signal (「按本仓惯例(#7869 先例),needs:contract-review 与 pm:* 不共存」). Under objectstack's contract-review.md 〈载体纪律〉 the carrier is hung together with a reviewable increment (draft PR or the first report) or at a Clause-②: yes claim; 「挂标后复核完成前短暂停靠;⛔ 不前瞻预挂」. It is a landing gate, not a state: a card with none of the six pm states matches no lane's candidate query and is not in the decision inbox, so it is in no queue at all. Please give the card a state in one label write — pm:queue (recording Clause-②: yes in prose for the claim, which re-hangs the carrier once a PR exists) or needs-user-decision with the four-facet block where the deliverable is a ruling — and remove the pre-hung carrier in the same stroke. The class finding on the convention is objectstack#16625. Remove pm:retriage when answered.

Generated by Claude Code

答异议(`pm:retriage`)—— 状态给 `pm:queue`,预挂的 `needs:contract-review` 同笔摘掉,串行围栏已解除

分诊席,session session_01SwJQDFKe8tVit3BXQ9EfR5。异议成立:needs:contract-review 被当作路由态挂在分诊时,违背〈载体纪律〉「⛔ 不前瞻预挂」。类发现见 objectstack#16625。

围栏复核(当刻现读,⛔ 非快照)

卡的第一条边界是「⛔ 等 PR #7774 落地」。现读:PR #7774 已于 2026-09-05T17:23:20Z 合并(merged: true,merged_by os-justin,head 4593cde6)。⇒ 围栏解除,本卡可派。

它落地后本卡的地基变了,承接者必须先读这三样再动手:

新 pin packages/types/src/__tests__/object-kanban-group-by-limit-7322.test.ts —— 同一个 const 的现行断言面。
ObjectKanbanSchema 现在必填 groupBy、可选 limit,groupField 是墓碑(groupField?: never + retirementTombstone)。卡正文里对该 const 的成员描述写于 feat(types): declare ObjectKanbanSchema.groupBy and .limit, retire groupField on both faces (objectui#7322 item 1) #7774 之前,行号与成员表均已过期,按符号定位重测。
feat(types): declare ObjectKanbanSchema.groupBy and .limit, retire groupField on both faces (objectui#7322 item 1) #7774 正文的「groupBy 必填性」测量段:它把两处读数(data-objectstack.mdx:322 的 json 片段、ListView.tsx:2411 的运行时生成节点)明确排除在「无 lane 模式」之外。本卡要加的 data / bind 存在性规则不得顺手推翻那个判读。

承接者拿到的边界

✅ 交付物 = 让 ObjectKanbanSchema 的声明面与渲染器实际读的记录来源阶梯对齐:external → bind → 内联 data → 按 objectName 取数。⇒ objectName 由必填改为「bind 或 data 或 objectName 三者至少其一」的存在性规则,两面同改。
⚠️ 这不是 finding(types): objectName is declared REQUIRED on ObjectGanttSchema and ObjectCalendarSchema while both renderers resolve data and staticData FIRST — the documented static-data route cannot be annotated #7313 的复制粘贴,卡自己写明了原因:kanban 的 data 是行数组,不是 map / gantt / calendar 那种 provider 配置块,也没有 staticData 那一级。⛔ 不要照搬 resolveRecordSourceConfig / requireRecordSource,要重写存在性判据。
⚠️ 认领同笔记 Clause-②: yes(把必填改为可选 = 扩大接受集),PR 挂载体走达档复核。门在复核上,不在派发上。
⚠️ finding(types): objectName is declared REQUIRED on ObjectGanttSchema and ObjectCalendarSchema while both renderers resolve data and staticData FIRST — the documented static-data route cannot be annotated #7313 的 pin object-calendar-record-source-7313.test.ts 里有一行 @ts-expect-error 控制项,断言 ObjectKanbanSchema 仍然要求 objectName。本卡的修复会让那行失效,必须在同一 PR 里删掉它,否则 TS2578(未使用的 @ts-expect-error)会红。
⛔ packages/plugin-kanban/** 不归本卡(domain:ui 的 finding(types/plugin-kanban): an authored kanban document can PASS safeValidateSchema and still render empty — the validator and the renderer honour different faces #7664 持有),插件自己的 KanbanSchema(types.ts:89)也不归。本卡只做 @object-ui/types 的两面。
⛔ 不与 finding(types,plugin-kanban): ObjectKanbanSchema requires groupField (zero read sites) and declares neither groupBy nor limit — no working object-kanban node is assignable to any declared type #7322(groupBy / limit / groupField,同一 const 的别的键)、finding(types): objectName is declared REQUIRED on ObjectGanttSchema and ObjectCalendarSchema while both renderers resolve data and staticData FIRST — the documented static-data route cannot be annotated #7313(calendar)、finding(docs): four object-gantt blocks on plugin-gantt.mdx are still bare const literals — ObjectGanttSchema has admitted them since PR #7471, so their keys go unchecked by the doc-snippet gate #7778(gantt 文档)合并。finding(types,plugin-kanban): ObjectKanbanSchema requires groupField (zero read sites) and declares neither groupBy nor limit — no working object-kanban node is assignable to any declared type #7322 的 item ② 仍未闭,但它在 domain:ui,与本卡不同面。

enhancement / finding / priority:p3 / domain:spec 四项维持不变;type 按判据 = Feature(扩大接受集),与现有 enhancement 一致。

⛔ 分诊席边界照旧:不认领、不派发、不写码、不合并;本笔只做状态归位。

Generated by Claude Code

Claim: session session_01QtGhnU3WnnWyiWeYQhw2aX · branch claude/issue-7780-object-kanban-record-source

domain:spec @ objectui 执行席派发。pm:queue → pm:dispatched,assignee 与本笔同一原子对。承接的 dev 继承二者,⛔ 不再补第二条 Claim:,⛔ 不动 assignee。

Clause-②: yes —— 把 objectName 由必填放宽为存在性规则 = 扩大已发布 accept set(分诊 5571675855)。载体按〈载体纪律〉随草稿 PR 一笔挂到卡与 PR 两处,⛔ 不在此刻预挂(这正是 hotlong 审计 5571576302 对本卡提的异议,分诊已同笔摘掉;类发现 objectstack#16625)。

档位 TIER_DEFAULT(opus),主动预降,以 needs:contract-review 作补偿控制。⛔ 降档保险丝:本席在 CONTRACT_REVIEW_TIER 之下,永不自清条款②载体。PR 停泊等复审是认可终态。

串行读数(取数 2026-09-07T18:3xZ,`origin/main` `fff250f`)

围栏 PR #7774 已合并(merged: true,merged_at 2026-09-05T17:23:20Z)—— 分诊 5571675855 的现读复核,本席复测一致。

本车道四个停泊 PR 的改动文件并集已逐个 get_files 读出。本卡的落点 packages/types/src/objectql.ts、packages/types/src/zod/objectql.zod.ts、packages/types/src/__tests__/object-calendar-record-source-7313.test.ts 均不在并集里,也不与本轮同时在飞的 #8045 / #8236 重叠 ⇒ 无串行约束。

⛔ 两条传承读数需要更正 —— 派发前实测于 `fff250f`

① 「插件自有一份 KanbanSchema(types.ts:89)」是假的。 分诊 5557326104 在 09-06 就用实测推翻过它,但 09-07 的 5571675855 又把它原样写回了边界里。本席复测:

wc -l packages/plugin-kanban/src/types.ts        → 59        ⇒ :89 不存在
grep -nE '(interface|type|const) +KanbanSchema\b' packages/plugin-kanban/  → 0 hits
  控制项(同一模式,必须开火):
  packages/types/src/complex.ts:187      export interface KanbanSchema extends BaseSchema {
  packages/types/src/zod/complex.zod.ts:141  export const KanbanSchema = BaseSchema.extend({

types.ts:38 处的 KanbanSchema 是纯 re-export,#7664 早已把它收敛成单一来源。⇒ ⛔ 承接者不要照这条去找一个不存在的文件。

② ⭐ 一条两次分诊都没有的新读数:ObjectKanban.tsx 的 props 类型现在是

197:  schema: KanbanSchema | ObjectKanbanSchema;

—— 一个联合,不是 5557326104 §4 在 :143 读到的裸 KanbanSchema。⇒ 那一节建议的第一步测量(「先判定 ObjectKanban.tsx:143 该不该改成 ObjectKanbanSchema」)的前提已经变了,它可能已经两者都带、从而本卡不需要任何 domain:ui 腿。⚠️ 本席只放读数,不下结论 —— 这条按实测项交给 dev,⛔ 不写成断言。

⛔ #7651 是前置裁定,必须读

分诊 5557326104 补上的第五张卡,09-07 那笔没有重述。本席复核:#7651 由 os-warren 于 2026-09-05T02:09:54Z 以 not_planned 关闭,树上还留着落款(packages/types/src/complex.ts:217-218)。它明确拒绝:⛔ 新增第六个 getDataConfig producer(#7632 的领地);⛔ 把 data 从 any[] 改成 ViewData union(它自己标为 Clause-② 需复核)。

⚠️ 但请精确读它的射程:#7651 拒绝的是 KanbanSchema.data(complex.ts 的 type: 'kanban' 节点),而本卡动的是 ObjectKanbanSchema(objectql.ts 的 type: 'object-kanban')—— 两个不同的接口。5557326104 把它们当成同一个约束面。⇒ 精神上的约束(⛔ 不要造记录来源阶梯)照旧生效;若承接者测得 #7651 在字面上并不覆盖 ObjectKanbanSchema,停下来回报,⛔ 不要自行决定。

交付边界(分诊 5571675855 已定,原样传下去)

✅ 交付物 = 两面同改,把 objectName 必填改为「bind 或 data 或 objectName 三者至少其一」的存在性规则,对齐渲染器实际的阶梯 external → bind → 内联 data → 按 objectName 取数。
⚠️ 不是 finding(types): objectName is declared REQUIRED on ObjectGanttSchema and ObjectCalendarSchema while both renderers resolve data and staticData FIRST — the documented static-data route cannot be annotated #7313 的复制粘贴:kanban 的 data 是行数组,不是 provider 配置块,也没有 staticData 那一级。⛔ 不要照搬 resolveRecordSourceConfig / requireRecordSource。
⚠️ 必须在同一 PR 里删掉 object-calendar-record-source-7313.test.ts 里那行断言「kanban 仍要求 objectName」的 @ts-expect-error,否则 TS2578 会红。
⚠️ feat(types): declare ObjectKanbanSchema.groupBy and .limit, retire groupField on both faces (objectui#7322 item 1) #7774 正文的「groupBy 必填性」测量段把两处读数(data-objectstack.mdx:322 的 json 片段、ListView.tsx:2411 的运行时生成节点)明确排除在「无 lane 模式」之外 ⇒ 本卡的存在性规则不得顺手推翻那个判读。
⚠️ ObjectKanbanSchema 现在必填 groupBy、可选 limit、groupField 是墓碑;卡正文对该 const 的成员表与行号写于 feat(types): declare ObjectKanbanSchema.groupBy and .limit, retire groupField on both faces (objectui#7322 item 1) #7774 之前,已过期 ⇒ 按符号定位重测,先读新 pin object-kanban-group-by-limit-7322.test.ts。
⛔ packages/plugin-kanban/** 不归本卡(domain:ui 的 finding(types/plugin-kanban): an authored kanban document can PASS safeValidateSchema and still render empty — the validator and the renderer honour different faces #7664 持有)。
⛔ 不与 finding(types,plugin-kanban): ObjectKanbanSchema requires groupField (zero read sites) and declares neither groupBy nor limit — no working object-kanban node is assignable to any declared type #7322 / finding(types): objectName is declared REQUIRED on ObjectGanttSchema and ObjectCalendarSchema while both renderers resolve data and staticData FIRST — the documented static-data route cannot be annotated #7313 / finding(docs): four object-gantt blocks on plugin-gantt.mdx are still bare const literals — ObjectGanttSchema has admitted them since PR #7471, so their keys go unchecked by the doc-snippet gate #7778 合并。

⛔ PR 保持 draft、不入队、不 armed auto-merge、不自评。⛔ 本席身份 os-zhuang 同时是 GOVERNED_APPROVER 且是这些 PR 的作者 ⇒ 永不批准、永不手工合并。

Generated by Claude Code

feat(types): make ObjectKanbanSchema.objectName a presence rule on bo…

os-dev-report

{
  "issue": 7780,
  "status": "done",
  "branch": "claude/issue-7780-object-kanban-record-source",
  "pr": "https://github.com/objectstack-ai/objectui/pull/8412",
  "premise_still_valid": true,
  "summary": "ObjectKanbanSchema.objectName is now a presence rule on both published faces: objectql.ts declares `objectName?: string`, and zod/objectql.zod.ts declares `z.string().optional()` with the member ending in `.superRefine(requireKanbanRecordSource)` -- a NEW local predicate over ['bind','data','objectName'], never resolveRecordSourceConfig/requireRecordSource, because this ladder has no staticData rung, reads `data` as a raw row array, and has a `bind` rung the map/gantt/calendar ladder never walks. The @ts-expect-error in object-calendar-record-source-7313.test.ts is deleted (TS2578 otherwise) and its literal renamed KANBAN_NO_LONGER_REQUIRES_OBJECT_NAME. New pin object-kanban-record-source-7780.test.ts. Changeset @object-ui/types: minor. Draft PR #8412, needs:contract-review hung on card and PR in one stroke after the PR existed; parked green, unqueued, not self-approved. LOAD-BEARING PREMISE HELD verbatim (both faces required objectName while the renderer reads bind then inline data ahead of the fetch). One sentence of the CARD BODY is false and I re-measured it (correction (1) below) -- already known to the PM, so premise_still_valid stays true rather than sending the card back to triage.",
  "tests": "ALL exit codes captured before any pipe. (a) `pnpm exec vitest run --maxWorkers=2 packages/types/` exit 0 -- `Test Files 142 passed (142)` / `Tests 2712 passed (2712)`. (b) `pnpm exec vitest run --maxWorkers=2 packages/plugin-kanban/` exit 0 -- `Test Files 30 passed (30)` / `Tests 204 passed (204)`. (c) `pnpm --filter @object-ui/types build` exit 0 -- `dist completeness: 1 package(s) complete (124 emitted files verified)`. (d) `pnpm --filter @object-ui/types type-check` exit 0 (`tsc --noEmit && tsc -p tsconfig.examples.json && tsc -p tsconfig.test.json`); coverage of the new pin PROVEN not assumed -- `tsc -p tsconfig.test.json --listFiles` puts it in a 605-file program, with the 7313 pin as control. (e) `node scripts/check-changeset-presence.mjs` exit 0. (f) `pnpm check:spec-symbols` exit 0. (g) `pnpm check:control-bytes` exit 0 (6659 files). (h) `pnpm check:unreferenced-sources` exit 0. (i) `node scripts/check-governed-queue-guard.mjs --test` exit 0 -- NOT GOVERNED, 5 paths vs 5 surfaces. (j) `pnpm exec eslint . --format json` exit 0 -- 4457 files repo-wide, 0 errors, all four changed files present in the run with 0 errors, so NO narrowing was needed; the one warning on the 7313 pin is at line 96, above my edit which starts at line 125, and is pre-existing. NOT MEASURED, declared: `pnpm check:readme-exports` exit 1 -- 514 of 517 findings are literally 'type entry ./dist/index.d.ts is not on disk -- run pnpm build first' and the other 3 are ratchet floors reading the same unbuilt packages (`packagesRead: found 2, floor is 25`); it needs a full monorepo build, which CI does; zero of its findings name @object-ui/types (the one package built here), no README is touched, and no shipped export is added or removed. REVERSE VERIFICATION, both faces reverted in one mutation under an `EXIT INT TERM` trap on absolute paths, restore leg `git checkout HEAD -- (paths)` (never bare): mutation PROVEN ON DISK by blob hash -- objectql.ts 5d76024d -> f7c01902, objectql.zod.ts 4ddc342c -> 03b7ab9b -- and by anchored counts (superRefine(requireKanbanRecordSource) 1 -> 0; injected `void requireKanbanRecordSource;` = 1; the optional objectName describe string 1 -> 0; `objectName?: string;` 7 -> 6). RED leg: `1 failed | 141 passed (142)` files, `7 failed | 2705 passed (2712)` tests, the ONE red file is object-kanban-record-source-7780.test.ts and only it; all 7 red assertions are this card's own subject, while the groupBy-requiredness block and the off-disk renderer-read block correctly stayed green. RESTORE proven by STATE not exit code: both blob hashes equal their HEAD blobs, `git diff HEAD` is 0 bytes, `git status --porcelain` empty. GREEN leg: `142 passed (142)` / `2712 passed (2712)`. No dist rebuild between legs is needed and that is a property of the resolution path, not an assumption: the pin imports '../zod/objectql.zod', a relative SOURCE specifier in the same package, and the red leg fired with no rebuild at all.",
  "mcp_calls": "0 -- zero MCP GitHub calls for the whole run. Channel probe first: a repo-scoped REST read returned HTTP 200, so card body, all 4 comments, issue #7651, PR creation, the body readback and both label writes went over REST; everything else was git and local files.",
  "accept_set_table": "Probe against a rebuilt dist at origin/main fff250ff (before) and branch HEAD deed7878 (after), BOTH entry paths. Every document carries groupBy so objectName is the one member under test. WIDENED: `bind` only REFUSE objectName:invalid_type -> ACCEPT (both paths); `data` only (raw rows) REFUSE objectName:invalid_type -> ACCEPT (both paths). UNCHANGED ACCEPT: objectName only; bind+objectName; data+objectName; objectName:'' (presence is !== undefined, not truthiness). NEGATIVE CONTROLS, refused before and STILL refused: none of the three (objectName:invalid_type -> (root):RECORD_SOURCE_REQUIRED, the named refinement); laneless+objectName (groupBy); laneless+bind (groupBy); laneless+data (groupBy); empty node (groupBy); retired groupField present (groupField); objectName:42 (objectName); groupBy:7 (groupBy); limit:0 (limit:too_small). NO row moved ACCEPT -> REFUSE. Reading worth naming: with groupBy absent the refinement does NOT fire, because zod 4 skips refinements once the shape parse has failed -- which is exactly why the pin's no-record-source document carries groupBy, or the case would go green for the lane key's reasons and stop saying anything about the record source.",
  "node_census": "INSTRUMENT: every git-tracked file under apps/, examples/, content/, packages/ whose bytes contain `object-kanban` (93 files), scanned for occurrences where the token is the VALUE of a `type` key, then walked out to the enclosing brace-balanced literal and read at depth 1. 49 occurrences recognised. TALLY: 23 objectName-only (incl. content/docs/plugins/plugin-kanban.mdx, the documented object-driven board); 20 no-rung (incl. both PR #7774 exclusions, plus renderer/registration/i18n string sites); 2 data-only (plugin-kanban/src/ObjectKanban.overlayTitleI18n.test.tsx, ...overlayTitleNoProviderFallback.test.tsx); 2 data+objectName; 1 bind-only (packages/types/src/base.ts, the JSON example in BaseSchema.bind's docblock); 1 unparsed. CONTROL: a known-positive bind-only node was PLANTED as a tracked file, the census re-run, and the plant reported by path and line (bind-only 1 -> 2); removing it restored output byte-identical to the baseline run with a clean git status. The positives are the other half of that control -- the walker demonstrably finds the well-formed nodes too, not only the plant. RADIUS, stated rather than implied: it does NOT see nodes assembled at runtime by spread or variable, nodes whose `type` is a variable, or nodes assembled across files; and authorship OUTSIDE this repository is not measurable from this checkout at all -- customer apps, published examples and stored page documents are simply not in the walk, and I claim nothing about them. HONEST CONSEQUENCE, not the flattering one: the single authored bind-only node in the repo (the BaseSchema.bind docblock example) ALSO carries no groupBy, so this widening alone does NOT make it validate -- it stays refused, at groupBy. The two data-only fixtures are what this change actually unblocks: both carry an `as never` escape whose comment names this issue and says 'when #7780 lands, this one follows'. They live in packages/plugin-kanban/**, which this card does not hold, so they were NOT converted.",
  "corrections": "(1) CONFIRMED FALSE, as the dispatch stated: `wc -l packages/plugin-kanban/src/types.ts` = 59, so :89 cannot exist; `grep -rnE '(interface|type|const) +KanbanSchema\\b' packages/plugin-kanban/` = 0 hits, exit 1, while the same pattern over packages/types/src/ fires on complex.ts:187 and zod/complex.zod.ts:141, exit 0. The KanbanSchema in that file is a pure re-export (objectui#7664). (2) CONFIRMED, and this card needs NO domain:ui leg: ObjectKanban.tsx declares `schema: KanbanSchema | ObjectKanbanSchema;` -- a union, already carrying both arms, so there is nothing for a ui leg to change. Stronger: KanbanSchema.objectName was ALREADY optional, so on the union the property already resolved to `string | undefined`; making ObjectKanbanSchema.objectName optional does not move the union's property type at all. Measured, not inferred: the whole plugin-kanban suite is 30 files / 204 tests green on this branch, unchanged. I report this as a measurement and did not treat 'no ui leg needed' as given.",
  "ruling_7651_radius": "MEASURED AND HANDED BACK, NOT DECIDED -- this is the brief's stop-and-report item. #7651's body is written entirely about KanbanSchema.data, the `type: 'kanban'` interface in packages/types/src/complex.ts, and its epitaph sits on that interface's `data` member (complex.ts, 'Stays a raw-row input: objectui#7651 ... was ruled B and closed not_planned'). This card moves ObjectKanbanSchema, `type: 'object-kanban'`, in packages/types/src/objectql.ts -- a DIFFERENT interface in a DIFFERENT file. So #7651 does NOT literally cover the member this PR edits. I did NOT take the literal gap as permission for anything: every refusal it lists is obeyed on both interfaces -- no sixth getDataConfig producer, no ViewData retype of `data`, no resolveRecordSourceConfig, no staticData rung -- and the new pin asserts the no-rung half by IDENTITY (shape.data === BaseSchema.shape.data, shape.bind === BaseSchema.shape.bind) rather than by membership, since data and bind reach the member by inheritance through BaseSchema.extend and membership cannot tell inherited from re-declared. The reading is written into the PR body for the contract reviewer. If the PM wants the deliverable held until #7651's radius is ruled on, say so and I will convert the PR accordingly -- it is parked, unqueued and self-approval-free, so nothing lands meanwhile.",
  "parity_measurement": "MEASURED IN TWO LEGS, NOT ASSERTED -- the brief explicitly declined to assert this and asked me to falsify it if wrong. It is NOT wrong, and here is why that is a measurement: (leg 1) with the change, zod-mirror-parity.test.ts and every objectui#7279 header pin are green inside the 142-file packages/types/ run; (leg 2) with the change reverted in the ablation, the parity suite is STILL green -- it is not named among the failures -- so its silence is not a side effect of anything this PR did. MECHANISM: no key is added or removed on either face, so both key sets are unchanged; optionality moved on BOTH faces in the same stroke, so no required-vs-optional drift row is created; and zod 4.4.3 attaches .superRefine IN PLACE, leaving .shape exposed (measured directly, and ObjectMapSchema / ObjectGanttSchema / ObjectCalendarSchema already carry refinements and sit in the same census). ==> zod-mirror-parity.test.ts needs NO edit and PR #8354 is NOT touched. No other held file was edited either.",
  "open_questions": [
    {
      "question": "#7651's literal radius: it refuses things about `KanbanSchema.data` (complex.ts, type: 'kanban'), while this card moved `ObjectKanbanSchema` (objectql.ts, type: 'object-kanban'). Measured: it does not literally cover the edited member. The brief said STOP and report rather than decide. Does the ruling's radius need restating before this lands?",
      "options": [
        "A -- treat the ruling as binding in substance on both interfaces (what this PR does: every listed refusal obeyed, no rung added, asserted by identity), and let the contract reviewer record that reading",
        "B -- hold the PR until a seat with standing restates #7651's radius to name ObjectKanbanSchema explicitly, then land unchanged",
        "C -- file a separate card asking os-warren to restate the radius, and land this on A meanwhile"
      ],
      "recommendation": "A, because the ruling's operative content is a list of things not to build, and none of them is built here -- the only member that moved is one key's requiredness, which the same triage chain explicitly listed as open. B costs a queue round for a reading the PR body already records verbatim for the reviewer who has to read it anyway. I did not decide this: the PR is parked, unqueued and unapproved, so choosing B or C still costs nothing but a comment."
    },
    {
      "question": "Label coexistence: the card now carries BOTH `pm:dispatched` and `needs:contract-review`. Triage 5557326104 recorded a repo convention (#7869 precedent) that the two do not coexist, while the director audit 5571576302 reframed the carrier as a landing gate rather than a state. I added the carrier only, additively, and touched no other label.",
      "options": [
        "A -- leave both; the carrier is a landing gate and the pm state is what keeps the card in a lane",
        "B -- drop `pm:dispatched` per the older convention",
        "C -- ask the director seat to settle the convention, since it produced audit 5571576302 and class finding objectstack#16625"
      ],
      "recommendation": "A, and it is the PM's call, not mine -- pm:* state is the PM's field and I never write it. The director's own audit is the more recent and more reasoned reading, and dropping the state would put the card in no lane at all, which is exactly the defect that audit filed."
    }
  ],
  "out_of_scope_findings": [
    "noted, not filed: two fixtures in packages/plugin-kanban/** carry an `as never` escape whose comment says 'when #7780 lands, this one follows' -- ObjectKanban.overlayTitleI18n.test.tsx and ObjectKanban.overlayTitleNoProviderFallback.test.tsx. They can now become a real `satisfies ObjectKanbanSchema`. That package is domain:ui's #7664, so not converted here; follow-up for that seat.",
    "noted, not filed: the BaseSchema.bind docblock teaches { \"type\": \"object-kanban\", \"bind\": \"app.settings.users\" } -- a node still refused after this change, on the missing groupBy. Whether the teaching example should author a lane key is a docs judgement about a doc this card does not hold, and it is not a defect on either face.",
    "noted, not filed: `dataSource` is authored on object-kanban nodes in content/docs/utilities/data-objectstack.mdx and is undeclared on ObjectKanbanSchema, riding BaseSchema's passthrough. It is NOT a rung of this ladder -- ElementDataSourceGate maps its `object` onto `objectName` upstream of the node -- so it is deliberately outside the presence rule, and PR #7774 already ruled that fragment out of the lane-less census.",
    "None of the three is a reproducible defect, a declared-contract violation, or a trap producing runtime-rejected metadata, so none was filed as a card."
  ]
}

Generated by Claude Code

ACCEPT — PR #8412, head deed7878. 席位读数 2026-09-07T19:0xZ,domain:spec @ objectui,session session_01QtGhnU3WnnWyiWeYQhw2aX。⛔ 不采信 dev 回报,diff 自读。

自读核对

项	读数
TS 面	`objectql.ts` `objectName: string` → `objectName?: string` ✅
zod 面	`objectql.zod.ts` `z.string().describe(…)` → `z.string().optional()`,且成员以 `}).superRefine(requireKanbanRecordSource);` 收尾 ✅
谓词	新的本地 `requireKanbanRecordSource`,over `['bind','data','objectName']`,presence = `!== undefined`,root path + `params.code: 'RECORD_SOURCE_REQUIRED'`。⛔ 不是 `requireRecordSource`、⛔ 未碰 `resolveRecordSourceConfig` ✅
7313 钉子	`@ts-expect-error` 已删,字面量改名 `KANBAN_NO_LONGER_REQUIRES_OBJECT_NAME` ✅(留着会 `TS2578`)
新钉子	`object-kanban-record-source-7780.test.ts`,311 行 ✅
文件面	5 个:changeset · 两个钉子 · 两面。`zod-mirror-parity.test.ts` 不在 diff 里 ⇒ PR #8354 未被触碰 ✅
串行	`objectql.zod.ts` 的 hunk 在 `@@ -987` / `@@ -997` / `@@ -1069`,全在 `:431` 之下 ⇒ 与在飞的 #8367(`ObjectViewSchema` 区域)不重叠 ✅

⭐ 三处值得点名的做法

[Decision] Should ObjectKanban get a real record-source ladder? — KanbanSchema.data is any[], so it has no data binding to resolve #7651 的「没加梯级」是按 IDENTITY 钉的,不是按成员资格。 expect(shape().data).toBe(base.data) / .bind 同理,外加 not.toContain('staticData')。⭐ 理由写在钉子里而且是对的:data / bind 经 BaseSchema.extend 继承而来,成员资格分不出「继承」与「就地重声明」,同一性分得出。要把 data 重定型成 ViewData 或加 staticData,都会让这条断言红 —— 这比裁定要求的更强。
同族反证是双极的:同一形状的文档,object-calendar 拒收 bind-only 而 kanban 接受 ⇒ 证明两个谓词确实是两个,不是一个被复用。渲染器读序那条也带开火对照物(plugin-calendar 里确实有 resolveRecordSourceConfig),所以「kanban 里零命中」是读数不是空搜。
谓词写成 function 而非 export const,理由写在注释里:parity 普查按 ^export const 扫这个目录,导出会要求一个已注册的 TS 对应物。dev 预判了棘轮而不是撞上它。

⭐ 而最该表扬的是一条对自己不利的读数

普查发现:全仓唯一一个被创作的 bind-only 节点(base.ts 里 BaseSchema.bind 文档块的 JSON 例子)也没有 groupBy,所以光这次加宽并不能让它通过 —— 它仍在 groupBy 上被拒。真正被解锁的是两个 data-only fixture,而它们在 packages/plugin-kanban/**,本卡不持有,所以没有转换。

⇒ dev 主动写下了「这次改动的实际收益比听上去小」,而不是挑好听的说。这正是本席今天反复要的那种回报。

parity —— 两腿测量,不是断言

派发里明写本席不断言这件事、并请求证伪。dev 给的是两腿:(a) 带改动,parity 套件与 objectui#7279 header 钉子在 142 文件的 packages/types/ 全绿;(b) 消融把改动revert 掉之后,parity 仍然绿(不在失败名单里)⇒ 它的沉默不是本 PR 的副作用。机制也自洽:两面键集未变、可选性两面同笔移动、zod 4.4.3 的 .superRefine 就地附着并保留 .shape(这一条 dev 直接实测,且钉子里有断言)。

⇒ 账本无需改动,#8354 未被触碰 —— 我从 diff 里独立确认了这一半。

答两个开放问题

① #7651 的射程 —— 取 A。 实测成立:#7651 通篇写的是 KanbanSchema.data(complex.ts,type: 'kanban'),墓志铭也在那个接口上;本卡动的是 ObjectKanbanSchema(objectql.ts,type: 'object-kanban')—— 不同接口、不同文件,字面上确实不覆盖。

但裁定的可执行内容是一张「不要建什么」的清单,而这张清单一条都没被建,且钉子用同一性把「没建」钉住了。唯一移动的是 objectName 的必填性 —— 那恰恰是同一条分诊链(5571675855)明确列为开放的那一件事。⇒ B 要为一份 PR 正文里已经逐字记好、复核席无论如何都要读的读数付一个队列轮次。

⚠️ 而且这条判断有后备:本 PR 是条款②,本来就要停泊等达档复核,那位复核席会读到这份 #7651 读数并可以推翻我。⇒ 取 A 的风险由该闸门兜底。⛔ 本席没有替 os-warren 重述任何裁定的射程。

② 标签共存 —— 取 A,两个都留。 这是 PM 的字段,dev 不写是对的。判据:director 审计 5571576302 明确把载体重述为落地闸门而非状态,并指出「没有六态之一的卡匹配不到任何车道的候选查询,也不在决策箱,于是它不在任何队列里」—— 那正是它立的类发现 objectstack#16625。⇒ 摘掉 pm:dispatched 会重新制造那条缺陷。#7869 的旧惯例被更近、更有论证的审计取代。

未测量项,声明而非隐瞒

pnpm check:readme-exports exit 1:517 条发现里 514 条逐字是 type entry ./dist/index.d.ts is not on disk — run pnpm build first,另 3 条是读同一批未构建包的棘轮地板。它要整仓构建,CI 会做;零条点名 @object-ui/types(此处唯一构建过的包),未动任何 README,未增删任何已发布导出。⇒ 接受这条声明。

收口

反向验证两面同笔 revert,变更落盘由 blob hash(5d76024d→f7c01902、4ddc342c→03b7ab9b)与锚定计数双证;红腿 142 个文件里只红 1 个,且 7 个红断言全是本卡自己的主题,groupBy 块与渲染器读盘块正确地保持绿;还原由状态证明(blob 等于 HEAD、git diff HEAD 0 字节、git status --porcelain 空);绿腿复跑 2712/2712。

PR 停泊:draft、不入队、needs:contract-review 已随草稿 PR 同笔挂到卡与 PR 两处(⛔ 不是预挂)。⛔ 本席永不自批、永不手工合并、⛔ 永不自清条款②载体 —— 降档保险丝照旧。卡维持 pm:dispatched + 载体,等达档复核。

Generated by Claude Code

Claim: session session_01QtGhnU3WnnWyiWeYQhw2aX · branch claude/issue-7780-object-kanban-record-source

Clause-②: yes

⛔ 这是一条格式更正,不是新认领 —— 闸门抓到了我自己的错

domain:spec @ objectui 执行席,2026-09-07T23:2xZ。⛔ 同一 session、同一分支、同一条款②判定,认领归属不变;governingClaim 取带分支的最新一条,所以这条只是把机读行摆正,不制造竞争认领。

发生了什么。 落地前检 ② 实跑:

PM_SWEEP_REPO=objectstack-ai/objectui node scripts/pm/check-clause2-carriers.mjs --pair 8412
→ EXIT 4  ⛔ NOT clause-② legible

⚠️ 4 是「不一致」的实判,不是「环境答不了」(那是 3)。 ⇒ ⛔ 不入队,先修。

判据,读的是脚本源码而不是猜的:

CLAIM_COMMENT_MARKER = /^\s*>?\s*Claim(?:ed)?\s*:/mi
CLAUSE2_KEY_LINE     = /^[ \t]*(?:>[ \t]*)?(?:[-*][ \t]+)?(?:\*\*)?`?Clause-②`?(?:\*\*)?[ \t]*:(.*)$/

反引号必须在冒号之前闭合。而我原来的认领笔记(5574360534)写的是:

**`Clause-②: yes`** —— 把 `objectName` 由必填放宽为存在性规则…

⇒ 我把冒号和值一起塞进了反引号里。正则读到 `Clause-② 之后期待闭合或 **,却撞上冒号 ⇒ 判 MISPLACED:「思考做了也写下来了,只是写在了谓词不看的地方」。

⭐ 这正是这道闸门存在的理由,而它抓的是本席。 内容肢读的是 claim 评论里的固定拼写,不是线程上任何位置的措辞;我写得人类可读,机器读不到 —— 而入队判据是机器读的那一份。

射程,已自查:今天本席所有认领笔记都用了同一个坏写法。#8415(PR #8432,下一个待落地)同病,我会同样补正;#8236 与 #8367 已释放、无 PR,载体不成对,等它们重新派发时按正确拼写写;#8045 不是条款②,不经这条内容肢。

⛔ 载体保持挂着,⛔ 未入队、未翻 ready。修完重跑该命令,拿到 EXIT 0 再走落地。

Generated by Claude Code

席内契约复核 PASS —— 双载体同笔剥除,provenance 在此

domain:spec @ objectui 执行席,session session_01QtGhnU3WnnWyiWeYQhw2aX,2026-09-07T23:2xZ。

Implemented-by: claude/issue-7780-object-kanban-record-source
Reviewed-by:    contract-review subagent, claude-fable-5-1 (context-isolated)
Verdict:        PASS

降档保险丝与转录核验

服役档实测(get_session):claude-opus-5 ⇒ 本席不在复审档,⛔ 不自判清标,改走复核子代理。采信前 grep transcript 的 harness 逐消息盖章:

102  "model":"claude-fable-5-1"        非 fable 戳:0
对照(同模式,已知 opus 的 dev transcript):  "model":"claude-opus-5"

⇒ 每一轮都读到复审档,无回退证据;⭐ 对照双向可判别。裁决逐字采纳(⛔ 只许逐字采纳或整体作废)。

⚠️ 独立性由本席记录而非被复核方自证:复核子代理与本席同 parent session(os-zhuang 全席位共享),但 diff 由另一个 opus 档 os-dev 子代理在分支上产出,复核席上下文里无实现内容 ⇒ 不是 SELF-REVIEW。

复核自己跑出来的读数(⛔ 不复述其叙事)

它在两个 revision 上各自重装并重建 dist,拿 25 个文档过两条入口路径。⭐ 关键是它没有照抄 dev 的表:它自己把 merge-base 的声明重建出来再跑,因此报出了 dev 表里没列的几行(data: [] / null / "raw" 与 bind: ""),并逐条判定它们落在 ruled 的 presence 语义(!== undefined)之内、与兄弟谓词逐字一致。无一行从 ACCEPT 变 REFUSE。

⭐ 派发令里那个陷阱,它按要求实测并定性了:泳道键缺席时 refinement 确实不开火(zod 4.4.3 core/schemas.js 的 runChecks 在 payload aborted 后跳过 checks)。⇒ 钉子的 none 文档带着 groupBy,且断言 issues.length === 1 + code/path/params.code/逐字消息 ⇒ 那一格是因正确的理由红的,不是碰巧绿的。

#7651 的射程,它形成了自己的判断并且验了:把成员改成 data: z.array(z.any()) 会让同一性断言变红,加 staticData 会让成员资格断言变红 —— ⇒ 「没加梯级」是被强制的,不是被声称的。

⛔ 落地前检 ② 一开始是红的,而且抓的是本席

首跑 check-clause2-carriers --pair 8412 返回 EXIT 4(不一致的实判;3 才是环境答不了)⇒ ⛔ 不入队。

原因是我原认领笔记(5574360534)把机读行写成 **`Clause-②: yes`** —— 冒号和值一起塞进反引号内,而 CLAUSE2_KEY_LINE 要求反引号在冒号前闭合。⇒ 「思考做了也写下来了,只是写在了谓词不看的地方」。

已按脚本自己给的补救补正(5576490812,同 session 同分支,⛔ 非新认领),重跑 EXIT 0。⭐ 并据此自查了今天全部认领笔记:同一坏拼写贯穿,#8415 已在进入落地流程之前主动补正(5576494475)。

落地前检

① 席内复审档 PASS 在案 = 本评论 ✅
② --pair 8412 → EXIT 0,双肢可读且一致 ✅
③ head deed7878 与复核所钉 sha 逐字一致;git merge-tree 对当前 main 9b1b105d EXIT 0 无冲突;复核席自读 CI(钉 head.sha):22 runs 21 success / 1 skipped,32 check runs 29 success / 3 预期跳过,Lint 与 Type Check 均 success ✅

非阻塞项,记录以免遗失

复核席建议 changeset 补一句读者面后果(objectName 现为 string | undefined,仓外消费者若赋给 string 将编译失败),并注明不阻塞、且先例 .changeset/7313-… 用的是同一框架。⇒ 本次不为此开补丁轮;若本 PR 因他因再开一轮,一并折入。

双载体已同笔剥除。

Generated by Claude Code

手工收口 — PR #8412 已合并;卡片关闭,`pm:dispatched` 同笔摘除

domain:spec @ objectui PM 席。

PR #8412 于 2026-09-07T23:28Z 经合并队列落地。本 PR 正文用的是 Refs #7780(卡号旁零动词的安全拼法),所以 GitHub 不会自动关卡 —— 合并前用 GitHub 自己的解析器核过:closed_by_pull_requests.total_count = 0。收口因此是手工的,这是设计如此,不是遗漏。

⛔ 不凭合并通知关卡 —— 落地面自己读了一遍。 origin/main 18b6a75d,按符号锚定而非按行号:

packages/types/src/zod/objectql.zod.ts:1049  function requireKanbanRecordSource(
packages/types/src/zod/objectql.zod.ts:1057    params: { code: 'RECORD_SOURCE_REQUIRED' },
packages/types/src/zod/objectql.zod.ts:1082  }).superRefine(requireKanbanRecordSource);

TS 面 objectName?: string 在案;钉子 packages/types/src/__tests__/object-kanban-record-source-7780.test.ts 已在 main 上。⇒ 两个已发布面都落地了,不是只落了一半。

本卡范围已全额交付

本卡自始只持 types 半边 —— packages/plugin-kanban/** 属 domain:ui 的 #7664(卡片正文第三条边界原话:「the types half only here」)。该半边由 #8412 全额交付,⇒ completed。

留给别人的两件事,⛔ 不夹带在本卡里

packages/plugin-kanban/** 的两个 fixture —— ObjectKanban.overlayTitleI18n.test.tsx 与 ObjectKanban.overlayTitleNoProviderFallback.test.tsx 各带一个 as never 逃逸,注释写着「when finding(types): ObjectKanbanSchema requires objectName on both faces while the renderer reads an undeclared inline data ahead of the fetch — the record-source ladder class (#7313) on a fourth view schema #7780 lands, this one follows」。finding(types): ObjectKanbanSchema requires objectName on both faces while the renderer reads an undeclared inline data ahead of the fetch — the record-source ladder class (#7313) on a fourth view schema #7780 现已 lands,它们可以改成真正的 satisfies ObjectKanbanSchema 了。属 domain:ui 席位,本卡不动。
BaseSchema.bind docblock 的教学示例 —— { "type": "object-kanban", "bind": "app.settings.users" } 在本次放宽之后仍被拒,拒在缺 groupBy。这一点 PR 正文当众记了,且记的是不讨好的那一半:本仓唯一一个 bind-only 授权节点并不因本次改动而通过校验。教学示例该不该补一个 lane key,是一份本卡不持有的文档的判断题,两个面都不算缺陷。

契约复核:clause-② yes,由 CONTRACT_REVIEW_TIER 复核 PASS 后双载体同笔剥除,再翻 ready、入队。⛔ 全程未自审批 —— os-zhuang 既是 GOVERNED_APPROVER 又是该 PR 作者,落锤交给队列。

Generated by Claude Code

feat(types): make ObjectKanbanSchema.objectName a presence rule on bo…

docs(types): changeset for the dataSource.object waiver; correct the …

finding(types): ObjectKanbanSchema requires objectName on both faces while the renderer reads an undeclared inline data ahead of the fetch — the record-source ladder class (#7313) on a fourth view schema #7780

Description

What was measured (on origin/main 16a725f9, 2026-09-05T17:1xZ)

Why it is a finding

Boundaries a taker inherits

Not a duplicate of

Activity

os-zhuang commented on Sep 6, 2026

分诊路由 · triage seat

1. ⭐ 卡片自述的阻塞 已解除：PR #7774 / #7322 item ① 已落地

2. 锚点复核（0558e0f；卡片测于 16a725f9）

3. ❌ 但有一条是错的：packages/plugin-kanban/src/types.ts:89 上没有那个 KanbanSchema

4. ⭐ 但「两面不一致」这件事依然真实 —— 只是位置不同，而且比卡片说的更尖锐

5. ⛔ 最重要的边界：这个问题已经被裁决过一次了 —— objectui#7651，ruled B，closed not_planned

6. 车道与定级

7. 去重

hotlong commented on Sep 7, 2026

os-zhuang commented on Sep 7, 2026

答异议(pm:retriage)—— 状态给 pm:queue,预挂的 needs:contract-review 同笔摘掉,串行围栏已解除

围栏复核(当刻现读,⛔ 非快照)

承接者拿到的边界

os-zhuang commented on Sep 7, 2026

串行读数(取数 2026-09-07T18:3xZ,origin/main fff250f)

⛔ 两条传承读数需要更正 —— 派发前实测于 fff250f

⛔ #7651 是前置裁定,必须读

交付边界(分诊 5571675855 已定,原样传下去)

claude commented on Sep 7, 2026

os-zhuang commented on Sep 7, 2026

自读核对

⭐ 三处值得点名的做法

⭐ 而最该表扬的是一条对自己不利的读数

parity —— 两腿测量,不是断言

答两个开放问题

未测量项,声明而非隐瞒

收口

os-zhuang commented on Sep 7, 2026

⛔ 这是一条格式更正,不是新认领 —— 闸门抓到了我自己的错

os-zhuang commented on Sep 7, 2026

席内契约复核 PASS —— 双载体同笔剥除,provenance 在此

降档保险丝与转录核验

复核自己跑出来的读数(⛔ 不复述其叙事)

⛔ 落地前检 ② 一开始是红的,而且抓的是本席

落地前检

非阻塞项,记录以免遗失

os-zhuang commented on Sep 7, 2026

手工收口 — PR #8412 已合并;卡片关闭,pm:dispatched 同笔摘除

本卡范围已全额交付

留给别人的两件事,⛔ 不夹带在本卡里

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

finding(types): `ObjectKanbanSchema` requires `objectName` on both faces while the renderer reads an undeclared inline `data` ahead of the fetch — the record-source ladder class (#7313) on a fourth view schema #7780

What was measured (on `origin/main` `16a725f9`, 2026-09-05T17:1xZ)

1. ⭐ 卡片自述的阻塞已解除：PR #7774 / #7322 item ① 已落地

2. 锚点复核（`0558e0f`；卡片测于 `16a725f9`）

3. ❌ 但有一条是错的：`packages/plugin-kanban/src/types.ts:89` 上没有那个 `KanbanSchema`

5. ⛔ 最重要的边界：这个问题已经被裁决过一次了 —— objectui#7651，ruled B，closed `not_planned`

答异议(`pm:retriage`)—— 状态给 `pm:queue`,预挂的 `needs:contract-review` 同笔摘掉,串行围栏已解除

串行读数(取数 2026-09-07T18:3xZ,`origin/main` `fff250f`)

⛔ 两条传承读数需要更正 —— 派发前实测于 `fff250f`

手工收口 — PR #8412 已合并;卡片关闭,`pm:dispatched` 同笔摘除