ToolPreview 仍渲染已退役的 requiresConfirmation 徽标 —— spec 侧 #3715 prune 的最后一处残留

[os-zhuang]

objectstack#3715(ADR-0033:删除从未实施的 tool.requiresConfirmation)的 spec 侧移除已在 @objectstack/spec 落地(ToolSchema .strict() + 墓碑,处方指向 action.ai.requiresConfirmation + 审批队列),cloud 侧 24 处声明也已清理。2026-08-03 维护者裁决:metadata tools(*.tool.ts)暂定为平台内部管线,第三方扩展面只开放 skills——per-tool 确认门不再回归。

三仓扫描后的最后一处残留在本仓:

• packages/app-shell/src/views/metadata-admin/previews/ToolPreview.tsx:101 — const requiresConfirmation = !!d.requiresConfirmation;
• 同文件 :168 — 据此渲染确认徽标
• 同文件 :10 — 头注释仍把它列为展示项(与 active、builtIn 并列,后两者也已随 objectstack#3896 移除,建议一并核)

现状危害:spec 已拒收该键,新元数据不会带它;但 admin 预览对陈旧存量行仍会亮出「需确认」徽标——这正是 objectui#2962 从 sharing-criteria builder 里移除过的「advertising the failure mode」形状(一个 UI 徽标宣传一个从未存在的安全暂停)。

建议:删掉该变量与徽标分支(纯删代码,无行为损失);顺手核对同文件对 active/builtIn 的处理是否也是同型残留。

Refs: objectstack#3715(裁决与全链记录)、objectstack ADR-0033、objectui#2962(同型先例)。

[xuyushun441-sys]

认领:PM 循环第 2 轮
会话:session_01NVPjPzmmAJ2Ngtvgg5MSRa(objectui 分片 PM,账号 xuyushun441-sys,已在 objectstack#4604 登记)
分支:claude/issue-3236-toolpreview-requiresconfirmation
Worktree:objectui-issue-3236

分诊:本单从无标签直接进队列,无需维护者确认

补一句为什么这单不走 needs-user-decision:它看起来像"删掉一个安全相关的确认徽标",但决策已经做完了 —— 单子正文记录了 2026-08-03 维护者对 objectstack#3715 的裁决(metadata tools 暂定为平台内部管线,第三方扩展面只开放 skills,per-tool 确认门不再回归),spec 侧已 .strict() + 墓碑,cloud 侧 24 处也清理完了。本仓这处是三仓扫描后的最后一处残留,属于执行既定裁决,不是重新拍板。

派发范围

packages/app-shell/src/views/metadata-admin/previews/ToolPreview.tsx:

1. 删 :101 的 const requiresConfirmation = !!d.requiresConfirmation; 与 :168 据此渲染的徽标分支;
2. :10 的头注释仍把它列为展示项,一并改掉;
3. 顺带核对同文件对 active / builtIn 的处理 —— 单子提示这两个也已随 objectstack#3896 移除,可能是同型残留。先核实再动:如果它们仍是 spec 认的键,就不要碰;如果确认同型,一并清掉并在 PR 里说明。核实结论无论正反都要写进报告。

为什么这不是"纯删代码"那么简单,值得一条测试

现状危害是单子写明的:spec 已拒收该键,新元数据不会带它,但 admin 预览对陈旧存量行仍会亮出「需确认」徽标 —— 一个 UI 徽标在宣传一个从未存在的安全暂停(objectui#2962 的同型先例)。这是"界面宣传了运行时不兑现的能力"。

所以删完之后请加一条断言:给预览喂一个仍带 requiresConfirmation: true 的陈旧对象,断言不渲染任何确认徽标。只删代码而不钉住,下一个人看到 spec 墓碑里的这个名字,很可能"顺手"把徽标加回来。

---

Generated by Claude Code

[xuyushun441-sys]

PM 验收:ACCEPT — PR #3258,已入合并队列

项	结果
PR targets main、Fixes objectstack-ai/objectui#3236	✅
改动范围	✅ 3 个文件,全在 packages/app-shell + changeset
content/docs/releases/ 零改动	✅
CI	已完成的全绿、零失败(含 Type Check、Changeset Bump Policy、Build & E2E);test shards / Lint / Bundle 仍在跑,已开 auto-merge 由队列在全绿后落地

「顺手核对 active / builtIn」被实测回答了,不是猜的

我在派发里要求"先核实再动,正反结论都要报"。它没有靠读代码推断,而是直接拿本仓装着的 @objectstack/spec@17.0.0-rc.1 跑 ToolSchema.parse() 逐键探测:

requiresConfirmation => REJECTED active => REJECTED
builtIn => REJECTED category => REJECTED
permissions => REJECTED objectName+outputSchema => ACCEPTED

结论有两条超出原单:

1. active / builtIn 确认是同型残留(objectstack#3896),不是仍然活着 —— 原单只说"建议一并核";
2. category 也是,而原单根本没点名它。一并清掉是对的。

同时 objectName 被证明仍然是活键并保留了下来 —— 这一条同样重要:本单是"删残留",不是"把 header strip 清空"。

测试形态正确:既钉住删除,也钉住没有误删

7 个用例分两组。第一组喂一个仍带全部四个退役键的陈旧草稿,断言一个徽标都不渲染(还额外覆盖 active: true 的情形 —— "键是没了,不是反转了")。第二组是正向断言:label、机器名、description、仍然合法的 objectName 徽标、参数表、Example LLM Call 都必须还在。

负向验证做了:把徽标分支放回去,7 个用例红 3 个,并给出准确 diff(+ Received: <span…>Requires confirmation</span>)。

一处我没要求但做对了的收尾

Pill 辅助组件的 tone('green' / 'amber')词汇被一并删掉,因为那些徽标是它仅有的调用者。注释写明了理由:「一套没有调用者却留着的 tone 词汇,正是被删掉的徽标长回来的方式」。这与本单的病理是同一个 —— 留着没有生产者的机制,就是在邀请下一个人把它接回去。

changeset:加了,同意

与 #3207 / #3227 不同,这次是用户可见变化(admin 预览里四个徽标消失,包括此前无条件显示的 Active),patch 合理。changeset 正文把危害方向写清楚了:Requires confirmation 宣传了一个没有任何执行路径实施过的安全暂停(真正的门是 action.ai.requiresConfirmation + HITL 审批队列),而 Disabled 声称工具已撤下,同时 ToolRegistry.getAll() 仍在把它交给 LLM、execute 路由仍在跑它。这两条比"徽标不该显示"严重得多 —— 是审查者会被误导的方向。

越界发现 #3257,已入队

apps/console/src/preview-samples.ts 的 tool 样例仍声明 category / active / requiresConfirmation 三个退役键 —— 同型残留,但在本单 scope fence 之外,且它是设计器预览画廊里展示的模板,照抄它的人会得到一份 ToolSchema.parse() 直接拒收的元数据。已标 pm:queue,下一轮排。

另外它做了全仓扫描并给出否定结论:除 ToolPreview.tsx 与上述 console 样例外,packages/、apps/、content/、examples/、e2e/ 再无 requiresConfirmation 或 tool-builtIn 残留。否定结论也被如实记录,这正是我要的 —— "我查了,没有"是有用的产出,沉默不是。

---

Generated by Claude Code