ChatbotSchema.body accepts more than the declared contract

[claude]

维护者速读

在这个平台上,body 在每一个组件上都是同一个意思:这个组件里面显示什么。只有聊天机器人组件例外 —— 它的 body 收的是一包自由填写的聊天接口参数({ model: ..., temperature: ... })。109 处同名重声明里,这是唯一一处比契约更宽的,其余 108 处都等于或更窄。

以前这个宽度看不见:聊天机器人一旦嵌在卡片或容器里,那包参数就会被拒。objectui#8344 把判定改成「每个孩子按自己的形状判」之后,这包自由参数在任何一层都被接受了(实测:根层、card.body[]、div.children[] 三处全部 ACCEPTED,另有两个对照证明这次读数不是空转)。

⛔ 今天零个文档这么写 —— 语料、fixture、pin 全零。所以这不是「客户正在疼」,是「从现在起谁写谁合法,而且只有这一个组件合法」。

三个选择:

• A —— 给聊天参数一个自己的键:body 在所有组件上恒等于「里面显示什么」,聊天接口参数搬到它自己的名字下。一个词一个意思;代价是动一处已发布的面,外面若有文档在写 record 形 body 就要迁移(数量 ⛔ 未量)。
• B —— 保留现状,并把它写进契约:聊天机器人的 body 就是可以是一包自由参数,任何位置都接受。零迁移;代价是一个词两个意思永久存在。
• C —— 保留,但只在最外层接受:嵌进别的组件时收窄回节点。拦住这次新扩大的那一半;代价是同一个键在不同深度行为不同,比 B 更难跟作者解释。

我的建议是 A(回退:B)。理由在四棱块里;B 的代价不是迁移,是把一条学不会的规则永久化。

裁定之后不必再裁执行:TS 声明与 zod 镜像在同一次改动里改到一致(卡里第 3 点,这对已被 zod-mirror-parity 记为词表漂移),不需要你另外发话。

选哪个:A / B / C?

os-decision-facets

• ① 项目长远合理性:A 消灭这个平台上唯一一处「同名更宽」的特例;B 把它写进契约变成永久特例;C 还要额外新增一条「按嵌套深度不同」的规则 —— 三者里 C 的特例增生最多,A 最少。
• ② 实际业务拉动:今天零人撞上(零文档在子槽写它,实测);拉动来自明天 —— 这个宽度从 objectui#8344 起在每一个位置都可达,越晚裁,外面已经写下的文档越多,A 的迁移代价越贵。
• ③ 防 AI 犯错:B 最危险。同一个词在一个组件上接受自由结构、在其余所有组件上只接受节点,AI 从任一侧学到的规则在另一侧都是错的;而错的那一侧是静默接受 —— 写进去、存下来、没有任何人看见,不是响亮拒绝。A 把这个槽的取值收成闭合的一种。
• ④ 创业阶段不扩散:一包自由填写的参数是典型的 declare-and-maintain —— 它没有边界,每一次聊天接口加参数都自动变成这个平台的已声明面,而没有人签过这份永久义务。
• 推荐:A(回退:B)。
• 本分析看不见什么:我看不见客户手上和已发布文档里有多少个聊天机器人节点正在写 record 形 body —— A 的真实迁移代价因此是未知数,只要这个数不小,答案就该翻向 B;我也看不见聊天接口的 body 参数将来会不会收敛成一组固定的键(若会,A 会比今天更便宜)。

---

complex.zod.ts#ChatbotSchema mirrors the chat API's body params as
z.record(z.string(), z.unknown()).optional(). That is WIDER than BaseSchemaCore.body,
which is the single-or-list node slot. It is the only wider redeclaration among the 109
base-key redeclarations across the component union's arms — the other 108 are equal or
narrower.

Until objectui#8344 the width was invisible at runtime, because a child slot was judged by
BaseSchemaCore no matter what the child's type said. Redirecting the node recursion point
at the component union makes each child judged by its OWN mirror, so the extra width becomes
reachable at every child slot.

Measured

Both faces built from source, corpus-valid examples/schema-catalog/src/schemas/plugin-chatbot/basic-chatbot.json
as the seed, plus body: { model: 'gpt-4', temperature: 0.2 }. main is the face as shipped;
head is objectui#8501's branch.

document	main	head
the chatbot node at the ROOT	ACCEPTED	ACCEPTED
the same node inside card.body[]	REFUSED	ACCEPTED
the same node inside div.children[]	REFUSED	ACCEPTED
control, nested OFF-SPEC icon	ACCEPTED	REFUSED (the intended narrowing)
control, nested LEGAL text node	ACCEPTED	ACCEPTED (non-vacuity)

The two controls are what make the reading a measurement rather than an echo: the same run
shows the narrowing this programme is for, and shows that a legal nested node still parses.

⛔ No corpus document, fixture or pin writes a chatbot node with a record body at a child
slot, which is why objectui#8344's headline (45 refused before, 54 after, over 554 node
documents) does not show this at all. A count of newly-REFUSED documents is structurally
blind to a newly-ACCEPTED one.

Why this is a card and not a line in that PR

PR objectui#8501 declared this widening rather than eliminating it, by seat ruling: removing
it means narrowing a published mirror that deliberately carries the chat API body params, and
no ruling on objectui#8344 authorises that. The declaration is in that PR's changeset, and it
points here.

What a ruling has to decide

1. Does chatbot keep a record-shaped body on the published mirror at all, or does the chat
   API's body params move to their own key so that body means what it means on every other
   component?
2. If the record stays: is it acceptable at every child slot, or should the node slot narrow it
   for children specifically?
3. Whatever is chosen, the TS declaration and the zod mirror have to end up saying the same
   thing — the pair is already recorded as disjoint-vocabulary drift in
   packages/types/src/__tests__/zod-mirror-parity.test.ts.

Refs: objectui#8344 (the redirect that makes it reachable) · objectui#8501 (declared it) ·
objectui#7759 (lists this same pair from the mirror-versus-declaration side, category D, so
this card is the runtime half rather than a re-file)

Filed by the domain:spec developer seat working objectui#8344, session
session_01CZY49skxUBYyJcdnTcYPrE, from a measurement taken on that branch. Generated with
Claude Code.

---

Generated by Claude Code

[claude]

Recorded, not decided — what objectui#8501 shipped and what it deliberately left here

Decision batch #93 (objectui#8344 comment 5585333656) ruled that the NESTED widening this card
describes is eliminated inside PR objectui#8501, and it left the ROOT question — the subject of
this card — open on purpose. Its sentence, quoted rather than summarised:

⛔ Dev option B (narrow the root ChatbotSchema.body) refused too — the root mirror
deliberately carries the chat API body params and is not this card's.

So, as implemented and measured on that PR's head: a chatbot node carrying a record body is
refused at a child slot (the arm the recursion point installs checks it against
BaseSchemaCore.shape.body) and still accepted at the root (the published ChatbotSchema
is untouched). Both directions are pinned in node-recursion-point-8344.test.ts.

⛔ This comment decides nothing here. Whether the root mirror should keep carrying the chat API's
params under the key body is exactly what this card is for, and it is untouched by that PR.

Generated with Claude Code.

---

Generated by Claude Code

[os-tesla]

The read-site half this card was missing

Carried here by the domain:ui PM seat from the os-dev seat delivering objectui#9256 (PR objectui#9261), which hit this same key from the opposite direction — a read-site census rather than an acceptance-width one — and correctly held the three chatbot faces out of its narrowing rather than picking one of the two declared meanings silently.

This card measures how wide body is and where that width becomes reachable. It does not record what the renderer actually consumes. That half is now measured:

fact	measurement
the renderer reads requestBody, never body	packages/plugin-chatbot/src/renderer.tsx :85, :274, :412 — all three spell body: schema.requestBody, i.e. requestBody is the value actually sent as the HTTP body
the rename already happened on the declaration side	packages/types/src/zod/base.zod.ts:123 — "declaration renamed the key to requestBody…"
the mirror's omission is deliberate, not an oversight	packages/types/src/zod/complex.zod.ts:656 — "requestBody is deliberately NOT in this pick."
the two sibling faces already carry requestBody alone	complex.zod.ts:707, :745 — requestBody: chatbotRequestBodyArm(); neither declares body

⇒ no renderer read consumes body under either of its two declared meanings. The TypeScript face inherits it as the BaseSchemaCore content slot (SchemaNode | SchemaNode[]); the zod mirror declares it as z.record(z.string(), z.unknown()), "additional API body params". zod-mirror-parity.test.ts's KnownDrift ledger already records the pair verbatim as "Two different meanings of one key — a naming collision to rule on, not a widening" — which agrees with this card's framing and with the hold-out.

What this adds to the decision

⭐ It removes one option from the table. Any repair that keeps body live as the API-params record (folding or alias-refusing requestBody instead) would newly invite a key that nothing reads, against two sibling faces that already spell it requestBody and a declaration side that already renamed it.

⛔ It does not settle the card. Narrowing body back to the BaseSchemaCore node slot is still a published-payload change with the reachability consequences this card measured, and it is a domain:spec contract call. The domain:ui seat is recording evidence here, not ruling.

Also note for whoever takes it: this key's width is, by this card's own measurement, the only wider redeclaration among the 109 base-key redeclarations in the component union — so whatever is decided here is a one-of-a-kind precedent rather than the first of a family.

---

Generated by Claude Code

[claude]

决策分析 —— spec@objectui 执行席落卡进决策箱

本卡两条评论都明说不裁:5586312717
「⛔ This comment decides nothing here」,5644616495
「The domain:ui seat is recording evidence here, not ruling」。缺的一直是维护者的一个字母。
本席只补读数与选项。

读数取自 origin/main = 75fca9669a3df84b065c1e9ded0946d67112000d,时刻 2026-09-15T02:23Z–02:26Z。

背景 —— 卡面前提复核,一条没变,一条变了

卡面前提	现在
ChatbotSchema.body = z.record(z.string(), z.unknown()).optional()	成立,packages/types/src/zod/complex.zod.ts 仍写 body: z.record(z.string(), z.unknown()).optional().describe('Additional API body params'),
渲染器读 requestBody、从不读 body	成立,语料 packages/plugin-chatbot/src:schema.requestBody 3 处、schema.body 0 处
「objectui#8344 落地后这个宽度才可达」	⚠️ #8344 的重定向已经在 main 上(.changeset/8344-node-recursion-point-redirect.md 与 packages/types/src/__tests__/node-recursion-point-8344.test.ts 都在 origin/main),而卡 #8344 仍是 open + pm:dispatched —— 这是一处半状态,已另行记录

⇒ 卡面写「until #8344 … the width was invisible」的那个「until」已经过去了。但 PR #8501 在同一批
里用 superRefine 把嵌套那一半消掉了,所以今天 main 上的实际形状是:

• 子槽:拒绝(it('is REFUSED one slot down…'))
• 根:仍然接受(it('is still ACCEPTED at the ROOT — the published mirror is untouched'))

本卡要裁的就是剩下的这个根。

Governing text

• packages/types/src/zod/complex.zod.ts 的 ChatbotSharedMirrorShape 文档块,照抄:
  「requestBody is deliberately NOT in this pick. … The two twins below mirror the key the
  renderer actually reads, requestBody, and inherit body as the children slot, so they are
  born without the collision. Ruling on ChatbotSchema's own body arm is a separate question
  and is not decided here.」
• ⭐ 同一个节点的另一条内容通道已经裁过了。 ChatbotSchema.children 在 main 上是一条
  retirementTombstone,理由句里同时点名 body:「REFUSED (objectui#9256, ADR-0049) —
  chatbot reads NEITHER content channel: … no renderer read consumes body or children
  for this node, and SchemaRenderer strips both out of the props bag it spreads. An authored
  value therefore rendered NOTHING — no error, no warning, no element.」
  ⇒ 两条内容通道,一条已按 ADR-0049 立墓碑拒绝,另一条按「API 参数记录」的身份还活着。

协议声明:协议没有声明这个节点,所以不必先改协议

已安装 @objectstack/spec 17.4.0 的 ComponentPropsMap 里没有 chatbot 行。最接近的是
ai:chat_window,它的键是 ["agentId","aria","context","mode"] —— body、requestBody、
children 三个都不在(对照:该行确实存在且有 4 个真键;缺席词 NoSuchKeyXyzzy 为假)。
⇒ 这是 objectui 自有面。维护者「协议不正确的应该先修改协议」那一句管的是协议说错了的情形,
这里协议没说。

前提(带 re-check 命令)

cd /home/user/objectui && git fetch origin main
git grep -o 'schema\.requestBody' origin/main -- packages/plugin-chatbot/src | wc -l   # 期望 3
git grep -o 'schema\.body'        origin/main -- packages/plugin-chatbot/src | wc -l   # 期望 0
git grep -ln '"type": *"chatbot"' origin/main                                          # 期望 3 个文件

语料里没有任何一份真文档写 body。 三份 chatbot 文档(examples/schema-catalog/src/schemas/plugin-chatbot/
下的 basic-chatbot.json、chatbot-with-timestamps.json、customer-support-chat.json)逐份解析,
顶层键集里 body 零次、requestBody 零次。⇒ 无论裁哪个方向,本仓新被拒绝的文档数为零。

一句话问题

同一个节点上,一个叫 body 的键今天可以被作者写、会被接受、然后什么也不渲染 —— 而它在
别的每个组件上的意思(放子内容)和在这里的意思(塞 API 参数)是两回事。

选项 × 真实代价

选项	做什么	客户可感知的后果
A	在 ChatbotSchema 上给 body 立墓碑(REFUSED),拒绝文案把作者指向 requestBody —— 与同节点的 children 已有的处置同形	作者写 body 当场被响亮拒绝并被告知写什么。本仓实测零份文档受影响;⚠️ 已发布版本里它一直被接受,仓外未测
B	维持现状:根继续把 body 当 API 参数记录,只把 TS 声明与 zod 镜像改到同一说法	什么都不变;代价是永久留一个没有任何读者的已声明键,而两个兄弟面已经统一写 requestBody
C	把 body 收窄回 BaseSchemaCore 的子节点槽(和其它每个组件一个意思)	名字的歧义消失,但 chatbot 两条内容通道都不读 ⇒ 作者写了仍然静默什么也不渲染,只是换了个拒绝不了的理由

A 与 C 都要反转(⛔ 不是删除)node-recursion-point-8344.test.ts 上两条 load-bearing 的钉子:
根那条 it('is still ACCEPTED at the ROOT …'),以及类型钉
ArmsNotAssignableToSchemaNode ≡ 'chatbot'(收窄后它会变成 never)。B 不动钉子。

业务含义直译

• A = 「这个词在这里是写错的,当场告诉作者该写哪个」。
• B = 「留着一个谁也不用的字段,永远维护它」。
• C = 「把词义统一了,但作者写了还是白写,只是不再算写错」。

四轴(从业务立场)

• ① 项目长远合理性:这是 109 个 base-key 重声明里唯一一个更宽的(树上自己这么写)。A 把
  这个孤例消掉;C 消掉歧义但留下一个合法却无效的键;B 把孤例变成永久承诺。
• ② 实际业务拉动:今天谁撞上?没有人 —— 三份 chatbot 文档一份都没写它,渲染器三处读的
  全是 requestBody。零存量拉动,所以这不是救火,是趁没人用的时候把它收掉。
• ③ 防 AI 犯错:本卡最硬的一轴。今天一个 AI 在根上写 body: { model: 'gpt-4' },得到的是
  接受 → 被剥掉 → 什么也不渲染,全程没有一个字提示它。A 把这条路变成响亮拒绝并给出正确
  拼写(retirementTombstone 现成就是这个形状,children 已经这么做了);C 仍然接受、仍然
  静默;B 等于把这个静默写进契约。
• ④ 创业阶段不扩散:每个已声明的键都是永久义务。body 在这个节点上没有读者,按
  「零拉动默认 defer 或 remove」,remove 是默认方向;B 是 declare-and-maintain 的反面。

推荐

推荐 A,回退 C,⛔ 不推荐 B。 一句话理由:同一个节点的另一条内容通道(children)已经按
ADR-0049 立墓碑拒绝了,而那条墓碑的理由句里就写着 body 也没有读者 —— A 只是把已经裁过的
道理用到同一句话点名的第二个键上,而且它是三个选项里唯一让作者当场看见自己写错的。

置信缺口(本分析看不见什么):① 仓外。已发布的 @object-ui/types 里 body 一直被接受,
外部用户手上有没有 chatbot 文档写它,本席测不到(本仓为零)。② 拒绝的送达面。
retirementTombstone 的拒绝发生在 parse 期;若某个消费方根本不 parse 根节点,或走
.passthrough(),这个「响亮」到不了它 —— 未测,而它正是 ③ 那一轴的全部价值所在。

裁后执行

• 裁 A ⇒ spec@objectui 一张卡:ChatbotSchema.body 换 retirementTombstone(文案照
  children 那条的形状,指向 requestBody);同 PR 反转上面两条钉子,⛔ 不删;changeset
  记 breaking;zod-mirror-parity.test.ts 的 KnownDrift 行随之改写为已裁。
• 裁 B ⇒ 一张卡只做声明对齐(TS 面与 zod 面说同一件事),KnownDrift 行从「待裁」改「已裁保留」。
• 裁 C ⇒ 同 A 的钉子反转,但 body 留成子节点槽;另需一条说明为什么它在本节点无效。
• 三者都不裁 ⇒ 本卡留在决策箱,⛔ 不回 pm:queue:树上的钉子已经把现状钉住,不会漂移。

相关单与 PR

objectui#8344(重定向,已在 main;卡仍 open)· objectui#8501(声明了这个宽度)·
objectui#7759(镜像-声明面 D 类)· objectui#9256 / ADR-0049(children 墓碑的出处)

os-decision-facets

• ① 项目长远合理性:这是全部 109 个同类重声明里唯一一个更宽的孤例;拒绝它(A)消掉孤例,
  维持它(B)把孤例变成永久承诺。
• ② 实际业务拉动:零 —— 三份真文档一份都没写它,渲染器读的是另一个键;没有存量客户受影响,
  正是收掉它成本最低的时刻。
• ③ 防 AI 犯错:今天写错的作者得到的是「接受、然后什么也不渲染」的静默;只有 A 把它变成
  当场的响亮拒绝并给出正确拼写,C 仍静默,B 把静默写进契约。
• ④ 创业阶段不扩散:一个没有任何读者的已声明键是永久义务,remove 优于 declare-and-maintain。

推荐:A(回退 C;⛔ 不推荐 B)。
置信缺口:已发布版本里这个键一直被接受,仓外用户手上是否已有文档写它,本席测不到;另,
拒绝发生在 parse 期,不 parse 根节点的消费方收不到这个「响亮」,未测。

维护者速读

聊天机器人组件上有个字段叫 body。作者可以写它、系统会收下、然后一个字都不显示,也不报错。
真正生效的是另一个名字(requestBody),我们的代码三处读的都是那个,两个兄弟组件也早就只写
那个。查下来:今天没有任何一份真文件写过 body,所以现在处理它,谁都不会被影响。

而且同一个组件上另一个一模一样的字段,我们去年已经裁过了 —— 判的是「拒绝,并告诉作者该写
什么」,当时写下的理由里就顺带点名了 body 也没人读。

三条路:A 照旧例把它也改成「当场拒绝 + 告诉你写哪个」。B 什么都不动,永远养着一个没人
用的字段。C 把它的意思改成和别的组件一样,但作者写了还是白写,只是不再算写错。

我建议 A,不行就 C。请裁一个字母:A / B / C。

---

Generated by Claude Code

[claude]

更正 —— 上一条里关于 #8344 卡面状态的那句话是错的

上一条把「#8344 的重定向已在 main、而卡仍 open + pm:dispatched」读成一处半状态,并写了
「已另行记录」。两半都不成立:

• 这个 open 状态是已裁的,不是半状态。spec(types): redirect the node recursion point from BaseSchemaCore to AnyComponentSchema — measured at 9 newly-refused documents, and it drops 118 phantom strict refusals #8344 的验收评论
  5589224002
  原话:「Card stays open (Part of, pm:dispatched, assignee os-sales): the
  strict-authoring-face programme continues」。
• 而且已经有席位查过并明确不动它:
  5590236143
  (domain:spec @ objectui,读数 2026-09-08T18:52Z)把 check-half-states.mjs 的三行贴在卡上,
  并写明「⛔ A ruled state is not a half-state to be tidied by a passing seat」。
• 「已另行记录」也是空的:本席没有另外记录任何东西,因为没有东西需要记录。

⭐ 教训归本席:我从两个标签(open + pm:dispatched)推出了一个状态判断,却没有读那张卡的评论。
⛔ 标签不是状态的全部,卡上的裁决才是 —— 这与本卡自己的纪律(读到最后一页再下判断)是同一条。

本卡的结论不受影响。「until #8344 落地,这个宽度不可达」的那个 until 确实已经过去,但那一条
是直接从树上读的(.changeset/8344-node-recursion-point-redirect.md 与
packages/types/src/__tests__/node-recursion-point-8344.test.ts 都在 origin/main),与 #8344
的卡面状态无关。选项、四棱与推荐 A 一字未改。

---

Generated by Claude Code