composer 旁增加权限模式选择器（类 Claude Code Mode）——设计先行，#3221 是前置风险

## 人类提议（2026-09-11）

> 在 composer 附近是否应该有一个类似 ClaudeCode 的权限授权的按钮的选择，这样不要每次都来提醒。

参考形态（Claude Code 的 Mode 菜单）：
```
Auto Claude handles permission decisions
Manual Always ask before making changes
Accept edits Automatically accept all file edits
Plan Create a plan before making changes
Bypass permissions [Enable]
```

## 现状（先读，避免重复造）

审批弹窗**已经有**持久化选项：`仅本次允许` / `本 run 内都允许` / `以后都允许` / `拒绝`。
⇒ 用户要的不是「新增持久化能力」，而是把选择**前置到 composer**，不必等弹窗出现才决定。

相关既有事实：
- **#3305**：45 个工具已全部显式分级，需审批的从 **28/45 降到 21/45**；漏分级会被门控判红。
- **#3221（未解决，且直接相关）**：授权按**工具名**（`call_skill`）记，而风险分级按 **skill 名**判 ⇒ **批准一个 skill 等于批准了该轮里所有 L2 的 skill**。
⚠ **加入「预授权模式」会成倍放大这个洞**——这是本条的首要前置风险。

## 第一阶段：只出设计，不实现

请先产出**设计与安全分析**，不要写实现代码。需要回答：

1. **模式集合**：哪几档？Claude Code 的五档不能照搬——它面向本机文件编辑，而这里的 L2 工具会**外发、不可逆**（弹窗自己写着「这类操作不可逆或会外发」）。**逐档说明在本产品语义下是什么，以及为什么需要它。**
2. **「以后都允许」与新模式的关系**：是同一个事实的两处表达吗？若是，**必须收敛**——本仓头号病已十二例。
3. **作用域**：模式是**会话级**、**线程级**还是**账号级**？切换线程后是否保留？**谁能改**（只读会话里能改吗）？
4. **#3221 的前置处理**：在授权粒度修好之前，能不能安全地提供「预授权」？**给出明确判断**。若判断「不能」，本条就应当**阻塞在 #3221 之后**——那也是有价值的结论。
5. **有没有等价的「Bypass」档**：若有，它的开启需要什么门槛、如何让用户随时看到自己处在这一档（**不能出现「我忘了自己开着它」**）。
6. **可撤销性**：预授权之后，用户如何看到「我已经授权了什么」、如何撤回。**只能授权不能查看/撤回是不可接受的**。

## 判据要求（进入实现阶段后）

- **会红的断言必须落在「模式真的改变了是否弹窗、以及真的被执行」**——不能只判「菜单里有这一项」或「点了会存下来」。本仓刚修过一批「点了没反应」（#3311 / #3317 / #3372）。
- **安全侧必须有反证**：造出「模式不该放行却放行了」的形状 → 断言变红 → 撤掉 → 恢复绿。**只贴绿不算数**（本仓已九次「全绿但空转」）。
- 判据要覆盖**只读会话**（`composer.send` 能力缺失时模式选择器应如何表现，参考 #3347 的既定做法：渲染但禁用并写出理由）。

## 不要做的

- **不要在 #3221 修好之前扩大授权粒度**。
- 不要新增第二套授权存储——现有 grant 机制是单一事实源。

Start by reading #3221, the existing grant mechanism, and the approval options described here; do not implement the composer selector yet. Produce the requested mode, scope, bypass, visibility, revocation, and safety analysis, explicitly deciding whether this work must remain blocked until authorization is keyed by skill rather than tool name.

Written by the indexing model from the issue text.