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

Activity

1. xuyushun441-sys

   added

   pm:queue

   pm:dispatched

   on Aug 3, 2026
2. xuyushun441-sys

   self-assigned this

   on Aug 3, 2026
3. xuyushun441-sys commented on Aug 3, 2026

   

   xuyushun441-sys

   on Aug 3, 2026 – with Claude

   Contributor

   More actions

   认领: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
4. xuyushun441-sys

   closed this as completedin #3258on Aug 3, 2026
5. xuyushun441-sys commented on Aug 3, 2026

   

   xuyushun441-sys

   on Aug 3, 2026 – with Claude

   Contributor

   More actions

   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
6. akarma-synetal

   added a commit that references this issue on Aug 3, 2026

   fix(app-shell): ToolPreview stops rendering retired ToolSchema flags (o…

   ...

   30ac2e1