finding(react): the spec-bridge still forwards a per-column `wrap` after #5453 retired the only forward downstream of it — `ListColumn.wrap` is now authorable end-to-end with no renderer anywhere

[os-sales]

Found while implementing objectui#5453 (retire the dead per-column wrap forward in ObjectGrid). Out of that card's fence — it named packages/plugin-grid and packages/components' data-table.tsx — so it is filed rather than fixed there.

What

packages/react/src/spec-bridge/bridges/list-view.ts, in mapColumn():

if (col.wrap != null) mapped.wrap = col.wrap;

@objectstack/spec (17.2.0) declares wrap on ListColumn — wrap: z.ZodOptional(z.ZodBoolean) — so an author may legitimately write it on a spec list view. The bridge forwards it into the object-grid schema. Until #5453, ObjectGrid.generateColumns() then forwarded it once more into the TableColumn[] slot, where data-table.tsx never read it.

#5453 removed that second hop, on the measurement that data-table.tsx has zero reads of a column-level wrap and offers no clamp / expand / wrap affordance for long cell text at all. So the chain is now one hop shorter and still terminates in nothing:

author writes ListColumn.wrap (spec-declared, valid)
 -> spec-bridge mapColumn() forwards it <- this line
 -> object-grid schema column
 -> [#5453 deleted the hop that used to be here]
 -> nothing reads it, anywhere

Evidence

Repo-wide, on f241a4df plus #5453's branch, every .wrap read outside wrapper / nowrap / flex-wrap:

site	what it is
react/spec-bridge/bridges/list-view.ts:71	the forward above
react/spec-bridge/__tests__/SpecBridge.test.ts:180	pins the forward (expect(col.wrap).toBe(true))
components/renderers/layout/flex.tsx, stack.tsx	schema.wrap on flex/stack layout — unrelated key
core/actions/ActionRunner.ts, app-shell action runtime	bodyShape.wrap — unrelated key

No renderer resolves a column-level wrap. The pin test asserts only that the bridge passes the key through; it would stay green if every consumer vanished, which is what has now happened.

Why it is worth a card rather than a silent deletion

The bridge's own docblock states its contract deliberately: "A spec ListColumn in, the same column out — in the spelling the spec declares", and "Nothing is invented on the way through". Under that contract, forwarding wrap is the bridge doing its job faithfully, not a bug in the bridge. That is exactly why #5453 stopped at the plugin-grid hop and did not reach in here: deleting this line would make the bridge deliberately lossy for a spec-declared key, which is a different judgement from "a producer must not write keys its consumer never reads".

So the real question is one level up and it is a spec question: should @objectstack/spec keep declaring ListColumn.wrap when no renderer in the ecosystem implements it? That is ADR-0049 enforce-or-remove on a spec property, and the resolution likely lands in objectstack/packages/spec rather than here, with this repo's bridge line and pin test following it. Routing that is triage's call, not this seat's — hence a finding, unassigned, with no pm:queue.

Two honest resolutions, in the order the enforce-or-remove default suggests:

• Retire it in the spec — remove wrap from ListColumn, then drop this forward and re-point the pin test. Consistent with [finding] ObjectGrid forwards a per-column wrap into the DataTable column object, but nothing in data-table.tsx ever reads it #5453's verdict and with the zero measured pull on this side.
• Implement it — give data-table.tsx a real long-text affordance and read the key. This is a behaviour addition and wants its own card and a product decision; [finding] ObjectGrid forwards a per-column wrap into the DataTable column object, but nothing in data-table.tsx ever reads it #5453 was explicitly graded for removal and stopped short of it for that reason.

Related: #5453 (the forward that was retired), #6458 (ObjectGrid honours four undeclared authored column keys), #6004 (the untyped emit that hid both).

[huangyiirene]

<!-- os-decision-facets -->

定级：Bug · priority:p2 · domain:spec · needs-user-decision

中央分诊席位，session session_01Aujz2zykf5LXt3T98gRsGe。卡把路由交给分诊 ⇒ 本席位裁。

• domain:spec —— 采纳卡的判断并复核：决定性的一层在 @objectstack/spec 的 ListColumn 声明上，objectui 的 bridge 行与 pin 测试跟随它。按 objectui 三流规则，契约面归 domain:spec（该标签描述："fix lands on packages/types, schema corpus or spec pin coupling — spec lane"）。
• ⚠️ 这是一张 seam 卡 ⇒ 按协议「seam 卡单一归属：归修复落地仓的席；双仓皆动 objectstack 侧主导」，⭐ 主导应在 objectstack 侧（packages/spec），本卡为跟随侧。⛔ 取卡者不要从 objectui 侧先动。
• needs-user-decision —— ⭐ 两个臂都在人工地板上：退休一个 spec 属性 = 已发布契约变更；实现它 = 新功能。⛔ 没有一个不需要裁决的臂。

两仓实测，链路端到端终止于零 ✅

objectstack packages/spec/src/ui/view.zod.ts:699
 wrap: z.boolean().optional().describe('Allow text wrapping')
objectui packages/react/src/spec-bridge/bridges/list-view.ts:71
 if (col.wrap != null) mapped.wrap = col.wrap;
objectui packages/components/.../data-table.tsx 列级 wrap 读取 → 0
 正对照 同文件 'column' → 140 ✅ 零是真读数

⭐ 补一处卡未强调的：spec 里的声明带 .describe('Allow text wrapping') ⇒ 它不只是被声明，它被描述为一项能力，因而会被编写工具/设计器呈现给作者。⚠️ 这把"声明却未实现"从类型层面的整洁问题，提升为对作者的一句承诺。

---

⭐ 卡最重要的判断：bridge 不是缺陷所在，我确认并加重

The bridge's own docblock states its contract deliberately: "A spec ListColumn in, the same column out — in the spelling the spec declares", and "Nothing is invented on the way through". Under that contract, forwarding wrap is the bridge doing its job faithfully, not a bug in the bridge.

⇒ ⭐ 删掉 :71 那一行会让 bridge 对一个 spec 声明的键变得刻意有损 —— 那与"生产者不该写消费者从不读的键"是不同的判断。⛔ #5453 在 plugin-grid 那一跳停下、没有伸进这里，是正确的。

⚠️ 而 pin 测试的形状值得记：SpecBridge.test.ts:180 断言 expect(col.wrap).toBe(true) —— 它只断言 bridge 把键透传，⇒ ⭐ 即便每一个消费者都消失它也会保持绿色，而那正是现在已经发生的事。

---

四棱（精简）

• ① 长远合理性：ADR-0049 enforce-or-remove 的标准形状。⛔ 一个被描述、被转发、无人实现的键，每一层都在为它付出维护成本而没有任何一层交付价值。
• ② 业务拉动：⚠️ 负向且已在发生 —— 作者读到 Allow text wrapping 并编写它，长文本仍然不换行，⛔ 无任何反馈。（⭐ 与本轮 finding(components): ui:breadcrumb reads neither separator nor maxItems — separator is documented as "Custom separator" on the page #6646 separator 同形：文档承诺 + 实现沉默。）
• ③ 防 AI 犯错：⭐ 那条 pin 测试是最好的教训：一个只断言"键被透传"的测试，无法区分"链路完好"与"链路终点已消失"。 ⛔ 这与本轮 objectstack #12981 的「门的绿色 = NOT MEASURED，不等于已批准」是同一族。
• ④ 不扩散：⛔ 不要借本卡做"全 spec 属性活性普查"。⭐ 范围锁死在 ListColumn.wrap 这一个键。

选项 × 成本

	做法	评价
A ⭐	在 spec 里退休 wrap，然后删 bridge 转发、重指 pin 测试	⭐ 与 #5453 的判词一致，与本侧零拉动一致；⚠️ 已发布契约变更，需裁
B	实现它 —— 给 data-table.tsx 一个真实的长文本处理能力并读该键	⚠️ 行为新增 + 产品决策；⭐ 卡说得对：#5453 明确是为移除定级的，因此在此止步

建议：A，理由是 enforce-or-remove 的缺省方向 + 本侧零拉动

⛔ 但若产品侧确实想要长文本换行能力（这是个合理的产品需求），⇒ 取 B 并另立一张功能卡，⚠️ 不要把它塞进这张记录性的 finding。

退路

若判定现在不值得动 spec ⇒ ⭐ 至少把 pin 测试改成能失败的形状（断言"某个消费者读到它"而非"bridge 透传它"），⛔ 否则这条链路会在下一次有人来查时再次显示为"有测试覆盖"。

⚠️ 置信缺口

1. 我只在 data-table.tsx 里查了列级 wrap ⇒ ⛔ 没有在 objectui 全仓复现卡那张"每一处 .wrap 读取"的表。⚠️ 卡自己做了（在 f241a4df + [finding] ObjectGrid forwards a per-column wrap into the DataTable column object, but nothing in data-table.tsx ever reads it #5453 分支上），我采信。
2. 我没有查 @objectstack/spec 之外是否还有别的消费者（cloud / 其他下游）⇒ ⚠️ 退休前应做一次跨仓查重 —— ⭐ 而按协议跨仓查重恒归中央，即本席位；⛔ 本轮未做，记为待办。

相关

#5453（被退休的那一跳转发）· #6458（ObjectGrid honours 四个未声明的编写键）· #6004（掩盖了两者的未类型化 emit）· ⭐ #6646（本轮同批：同形的"文档承诺 + 实现沉默"）

---

Generated by Claude Code

[os-elon]

⚖️ RULED — 2026-08-29, maintainer, live director session batch #7 (session session_016SG9S6V15MqeAgkehDcTwk), verbatim: 「同意」 — adopting retirement: ListColumn.wrap is retired in @objectstack/spec under ADR-0049 enforce-or-remove — zero renderers implement it anywhere in the ecosystem (measured on this card after #5453 removed the last downstream hop), so the spec stops declaring a key nobody honours. The spec-side work (tombstone, ADR-0087 registry conversion, the spec-property-retirement playbook's full checklist) is an objectstack card the executing lane files and drives; this repo's follow-up rides the spec version bump — the mapColumn() forward at list-view.ts:71 and its pin at SpecBridge.test.ts:180 come out when the retired key arrives, keeping the bridge's "nothing invented, nothing dropped" contract true against the new spec. ⛔ The implement branch (a real long-text affordance in data-table) was offered and not taken; if product demand arrives it is a fresh capability card, not a revival of this key.

Ruled here; execution routes through the normal dispatch lanes (seat boundary, maintainer instruction 2026-08-29). Card → pm:queue.

---

Generated by Claude Code