Decision: §10 wants a multi-entity group, but `clm_contract.our_entity` ships exactly one option and a seed cannot add one

[hotlong]

Raised by card 08 (#18, seed data), by Claude Code session session_01KcrVDXSptwDukFsHPHPR1V, rather than editing the governed surface.

The conflict

• §03 declares the field as our_entity select（签约主体，种子） — the parenthetical says the value list is seed data.
• §10 asks the demo to be "一家虚构的跨国集团（美国母公司，欧洲与亚太子公司）" — a US parent with European and Asia-Pacific subsidiaries, which only means something if a contract can say which entity signed it.
• src/objects/contract.object.ts implements it as a select with exactly one option, head_office, and a comment saying a group with several legal entities replaces the list with its own: "The shipped list is a single placeholder — a group with several legal entities replaces it with its own (DESIGN.md §01: signing entities are configuration, not schema)."

A select's options are schema. A seed writes values, and the value vocabulary is closed.

Measured (@objectstack/* 17.3.0), both write paths

Through the REST API, as the platform admin:

POST /api/v1/data/clm_contract  {"our_entity":"meridian_holdings_us", ...}
  -> HTTP 400
  {"error":"Our Signing Entity must be one of: head_office","code":"VALIDATION_FAILED",
   "fields":[{"field":"our_entity","code":"invalid_option","options":["head_office"]}]}

Through the seed loader, which is a system write and bypasses RBAC:

✗ Failed to write clm_contract record #0 (title=PROBE entity vocab):
  Our Signing Entity must be one of: head_office

Positive control: the other 14 rows of the same seed load inserted without complaint, so the refusal is about the value and not about the seed path. isSystem bypasses RBAC; it does not widen a select's vocabulary.

What card 08 did instead

#18 seeds our_entity: 'head_office' on all 120 contracts and expresses the multi-entity group through the axes that ARE data: governing law (US-NY 37 / Germany 38 / England and Wales 35), currency (USD 42 / EUR 41 / GBP 37), jurisdiction, and the counterparty base. That satisfies §10's observable requirements — three currencies, three governing laws — but the group's own signing entities are invisible, and "which of our entities signed this" is not answerable from the demo data.

Options

A. Leave it. The demo shows a multi-jurisdiction book signed by one entity. Honest, and the placeholder comment already says a customer replaces the list. Cost: §03's "（种子）" stays untrue for this field, and the §10 story is thinner than the table promises.

B. Ship three options (head_office, plus an EU and an APAC entity) in contract.object.ts and let the seed spread contracts across them. Cheapest thing that makes §10 true. Cost: an edit to a card-02 file and, arguably, to §01's rule that signing entities are configuration rather than schema — three placeholder entities in the shipped product is still schema, just three of them.

C. Make the signing entity a lookup to a real object (a clm_entity, or the platform's sys_business_unit), so the list genuinely is data and a seed can extend it. This is what "（种子）" describes. Cost: a §03 change, a new object or a platform-object dependency, and a migration for anyone already on our_entity.

Recommendation: B if the demo matters more, C if §03's word matters more. B is one field edit and makes the seed table honest today. C is the shape §03 actually describes and the one a group with a real entity list needs, but it is a governed-surface decision with a migration behind it. Either way, this is not card 08's to take.

[zhuangjianguo]

维护者速读

⚠️ 拟稿，不是裁决。 总监席本场服役档 claude-opus-5 ≠ CONTRACT_REVIEW_TIER（claude-fable-5-1，dispatch-gates.mjs:10446，精确比较），四职停放，⛔ 不裁不清标。本评论补这张卡欠的四棱块、速读，以及一个推荐（卡片正文给的是二选一的分叉，不符合一卡一推荐的格式）。标签一动未动。

事情：设计方案第 10 章要演示「一家虚构的跨国集团（美国母公司，欧洲与亚太子公司）」，而第 3 章把签约主体标注为「（种子）」—— 意思是主体清单属于数据。但实现是一个只有一个选项的 select（head_office），而 select 的选项是 schema，种子写不进新选项。

两条写入路径都实测过（17.3.0）：REST 写一个新主体 400 VALIDATION_FAILED / invalid_option；种子加载器（系统写入、绕过 RBAC）同样被拒 —— isSystem 绕的是权限，不加宽 select 的词表。同一次种子加载的另外 14 行正常插入，所以拒绝是关于值本身，不是种子路径。

卡 08 于是用真正是数据的那些轴表达跨国集团：适用法律（美国-纽约 37 / 德国 38 / 英格兰与威尔士 35）、币种（USD 42 / EUR 41 / GBP 37）、司法辖区、相对方基底。§10 可观测的要求（三币种、三法律）满足了，但「我们哪个主体签的这份合同」在 demo 数据里答不出来。

你要做的：回一个字母，A、B 或 C。

四棱分析

卡片正文（英文，卡 08 所写）没有给单一推荐，给的是「demo 更重要就 B，§03 的字眼更重要就 C」。四棱算下来偏 C，理由在第二、三棱。

实际业务需求 — 偏 C。本车道收卡第一问恒为「这张卡展现哪项平台能力」。B（往 schema 里塞三个虚构主体）展现不了任何平台能力，它只是让表格好看；C（主体改成指向真实对象的 lookup）展现的正是 §01 主张的配置即数据。而「我们哪个主体签的」对多主体集团是真问题 —— 集团内部结算、税务与授权链都挂在它上面。

项目长远合理性 — 明确偏 C，这一棱差距最大。§03 已经写了「（种子）」，C 就是那个词描述的形状；A 让那个词长期不成立，B 让它以「三个也是 schema，只是三个」的方式继续不成立。更硬的是 §01 自己说签约主体是配置而非 schema —— B 直接违背它，只是违背得比现状少两个数量级。

防 AI 写错 — 偏 C。今天那个单选项占位符的注释写着「有多个法律主体的集团用自己的清单替换它」，也就是教下一个作者去改我们发布的 schema。展品撒谎等于教每个照抄的 AI 撒谎 —— 这条注释就是在教一件错事。C 把主体变成数据，客户加主体是加一行记录，不是改 schema。B 把「往发布的 select 里加占位选项」立成惯例，下一个 AI 会在别的字段照抄。

创业阶段不扩散 — 偏 B。B 是一次字段编辑；C 要新增一个 clm_entity 对象（或依赖平台的 sys_business_unit），加一次 §03 编辑，还要给已经用 our_entity 的人一条迁移。这是 C 唯一的实质代价，也是唯一让 B 有理由的一棱。

结论：三棱同向 C，一棱（不扩散）偏 B。按「长远合理性权重恒 ≥50%，四棱冲突时其余各棱合起来投不翻它」，并按分歧推荐序「有实测拉动 ⇒ 荐长远形态一次付清」（§10 是已声明的展品要求，即拉动），拟推荐 C。

⚠️ 但 C 触受管面（§03 编辑）且带一条迁移，所以无论如何要你点头 —— 这也是这张卡不该由循环自裁的原因。若你选 B，请一并要求删掉那条「客户替换清单」的注释并改写成「主体清单是 schema，扩展需改 schema」，否则注释会继续教错事；若你选 A，请把 §03 的「（种子）」改掉，别让文档留一个不成立的词。

⚠️ 前提新鲜度

两次实测取自 @objectstack/* 17.3.0。核心前提「select 的选项是 schema，isSystem 不加宽词表」是一句平台能力断言。#35 正在把应用推到 17.4.0（396 changeset / 35 breaking）。

⇒ 建议：这张排在 #35 落地之后。若 17.4 让选项词表可由数据扩展，C 的成本会大幅下降，甚至变成 A 的自然演进。

---

Generated by Claude Code