[REQ-131][CODE] 在目录与工具执行咽喉执行同一策略

[jinjunnn]

Parent

• [REQ-131] 用户可按来源和工具控制模型可调用能力 #723(REQ-131)

方案基线

jinjunnn/alpha-code#724 的 CLOSE_DECIDE §9 第 2 条 + §6 的 E1–E7 表。本票正文逐字取自该基线,未新增任何 AC 或准入条件。

依赖

jinjunnn/alpha-code#1128(CODE#1)先落地 —— 本票执行的是它提供的同一个 resolver,不自建第二套。

负责(基线原文)

V1 catalog + E1–E6;E7/internal 排除 ratchet;dynamic inventory/API;stale/direct call 运行时重读。

边界(基线原文)

session/tools.ts、session/llm/request.ts、tool/code-mode.ts、session/llm.ts、session/prompt.ts 及窄测。

Out of scope(基线原文)

不切 V1↔V2、不替换现有 ability/sovereignty 闸。

退出条件(基线原文)

disabled 双闸、ask-before-hook/side-effect、enabled 保留能力闸;bin/check 绿。

已实测的用户可观察缺陷(本票落地即应消失)

jinjunnn/alpha-code#1121(P1)—— #725 双咽喉取证量到,判据全部驱动生产入口 SessionTools.resolve() 返回对象的 .execute(),副作用用真实计数(不是「抛没抛异常」):

判据	identity 规则	期望	实测
B3	builtin::write = deny	拒绝,文件不落盘	文件真的写出来了
B10	builtin::write = ask	先请求批准	不问,直接落盘
B2	plugin:probe:default = deny	拒绝,marker 不落盘	插件工具照跑

用户可达路径已用真 opencode.json + 真 Config + 真 Agent.Service 量到 —— v1/config/permission.ts:18-36 的 InputObject 接受任意键,所以用户写得出这条规则,而它在执行面无声无效。

最要紧的一句:用户把某个内置/插件/宿主工具设成「询问」,它照跑不误、不弹窗。

#725 同时量到的对照(说明缺口精确在哪)

• 咽喉 A(模型目录)= LLMRequestPrep.prepare() 返回的 tools —— 真绿。四来源 identity deny 都真把工具拿掉且只拿掉它自己;摘掉 permission/index.ts:300-304 的 identity hard-deny 分支 ⇒ A1–A4 当场翻红。
• 咽喉 B(执行)= SessionTools.resolve() 返回对象的 .execute() —— 只对 MCP 成立。摘掉 session/tools.ts:437-442 的 ctx.ask({permission: canonicalToolIdentity(...)}) ⇒ B1/B5/B7/B8 当场翻红,全部 A 判据不动。

⇒ 缺口 = builtin / plugin / 宿主 MCP-resource 工具完全不接 identity 轴。

⚠️ #1121 不要单独打补丁。 基线 §10 明写「不另造第二个审批引擎 / 第二张 identity 映射」;症状级修复会撞上这条。

基线 §6 里已点名、本票必须逐个处理的接缝

接缝	基线要求
E4 Code Mode child(tool/code-mode.ts:136-190)	子工具不走 register wrapper;在 hook(:143-147)之前用同一 resolver/ask,disabled child 也不进 child catalog(:211-215)
E5 workflow executor(session/llm.ts:127-163)	preapproved 列表只收 effective enabled,ask/disabled 均不得预批;executor 仍二次重读
E6 direct subtask(session/prompt.ts:263-397)	绕过 SessionTools;在 plugin hook、subsession/Task execute 副作用前单独用相同 resolver。现有 :284-288 只完成 deny,不足以实现 ask
E7 attachment ingestion(prompt.ts:830-849)	明确排除,保留 ask:()=>Effect.void 并以 #731 I6 负向测试锁死
internal sentinel	host::StructuredOutput 与 _noop 按窄例外锁死,不进 Settings

#725 的记录:E4 / E6 / E7 本轮只有源码级确认,没在运行期量到(E4 因探针把 experimentalCodeMode 钉成 false;E6 要起整回合;E7 的「显式排除」今天没有锁死断言)。本票落地后由 VERIFY 补运行期证据。

复杂度

M(基线已定方案,接缝逐个指名到 file:line)。

[jinjunnn]

Reopen(2026-08-26)—— 本票「负责」里点名的 dynamic inventory/API 未交付

契约:「未完成/超卖:reopen 原票补窄子票,不换编号」。本票关闭时有一项名下交付物没做,
因此 reopen,不另起编号。

票面「负责(基线原文)」逐字

V1 catalog + E1–E6;E7/internal 排除 ratchet;dynamic inventory/API;stale/direct call 运行时重读

交付物 PR #1135 正文「主动没做的」逐字

AlphaToolPolicy.Service(策略文档轴)未接进咽喉:harness 的层图不含该节点
(加硬依赖 = 23 条全崩),且该文档轴的编译落点是 #1130 的 Settings 物化;
咽喉消费的是同一引擎的 ruleset 轴(#1128 的 grants/合成语义原样生效)。
dynamic inventory/API 同理留给 #1130 消费面。

⇒ dynamic inventory/API 在本票名下,却被移交给了 #1130。这是超卖,不是范围裁剪 ——
范围裁剪要显式改票面并留痕,而票面至今写着它。

实读地面真相(两条互相独立的检索轴,交叉一致)

轴1 符号名  grep -rn -a "ToolPolicy" packages --include=*.ts --include=*.tsx | 排除 test/cases
轴2 键名    grep -rln -a "bindingDigest\|binding-changed" ...
两轴命中完全一致,只有三个文件:
   packages/schema/src/alpha-tool-policy.ts
   packages/opencode/src/permission/alpha-tool-policy.ts
   packages/opencode/src/permission/alpha-tool-policy-store.ts
零 server route · 零 SDK 投影 · 零 preload/main IPC · 零 renderer 消费者

AlphaToolPolicy 在模块外零引用      (对照:Permission.node 有 7 处装配点)
session/tools.ts:86 与 :128 读的是:
   ruleset: Permission.merge(input.agent.permission, input.session.permission ?? [])
   而 agent.permission ← Permission.fromConfig(cfg.permission ?? {})(agent/agent.ts:138)

本票 reopen 后要补的两件(都窄,都指名)

1. dynamic inventory/API —— 从 live MCP / plugin / builtin / host registry 派生
   identity + 可信 authority + 继承 + effective + binding change + 新发现 + 无法核验计数
   (#724 §5 契约)。这是票面已点名的那一项。
2. 策略文档轴如何抵达咽喉 —— 票面「依赖」一行写着「本票执行的是 #1128 提供的
   同一个 resolver,不自建第二套」,而实现走的是 ruleset 轴。两条轴的合成次序、
   binding guard(enabled + digest,rebind 回 ask)如何进 identityGate,是设计决定,
   不是实现细节 —— 它决定 Settings 面板里那个「生效」徽标能不能说真话。

为什么不能留给 #1130 顺手做

#1130 的复杂度定的是 M,而 M 的前提是「只消费既有 API」——该前提为假。
照已批稿在缺口上实现 = 面板显示「已停用」而模型照调,正是 #1121 那个已实测缺陷
在 Settings 层原样复活,而本 REQ 存在的目的就是杀死它。

绕过文档轴的替代路线被基线封死(不要走)

#724 §3 明禁「Settings 和调用方不得手拼 wildcard」「禁止各处拼 mcp:<server>:*」;
且 binding guard 与 9 型 reason 在 ruleset 语言里不可表达。

我这边的连带错误已更正

我 2026-08-26 批准 #1130 设计稿时,把 §3 表里三行从「契约,#1129 在途」改成
「已落地(#1129 已合)」—— 那是只看 issue 状态为 CLOSED 就下的,没读 PR #1135 正文。
已更正:PR #1146,设计稿新增 §9 记录假前提与地面真相。