@tencent-ai/codebuddy-code 2.105.0 → 2.105.1

package/dist/web-ui/docs/cn/cli/permissions.md

@@ -1,25 +1,25 @@
-# 权限规则（Permissions）
+# 权限规则
 
 > 用细粒度的 allow / ask / deny 规则、权限模式与多层 settings 精准约束 CodeBuddy Code 能做什么。规则可以提交到版本库与团队共享，也可以由开发者本地覆盖。
 
 ## 权限系统概览
 
-CodeBuddy Code 用一套分层评估机制平衡能力与安全。它在主代理执行任何工具调用前都会过一次权限服务（`tool-permission-service.ts::checkToolPermission`），8 个 Phase 顺序判定：
+CodeBuddy Code 用一套分层评估机制平衡能力与安全。每次工具调用前都会按下述 8 个 Phase 顺序判定：
 
 | Phase | 检查项 | 命中后行为 |
 | :---- | :---- | :--------- |
 | 1 | **Deny 规则** | 立刻拒绝，最高优先级 |
 | 2 | **可信 Allow 规则**（user / cli / flag / session / policy / 信任目录下的 project / `--allowedTools`） | 立刻放行，**可越过命令安全检查** |
-| 3 | **命令安全检查**（`checkCommandSafety`，仅交互式） | 高危/危险命令强制询问 |
+| 3 | **命令安全检查**（仅交互式） | 高危 / 危险命令强制询问 |
 | 4 | **Ask 规则** | 强制询问 |
 | 5 | **Bypass 模式短路** | `bypassPermissions` 模式直接放行；`disableBypassPermissionsMode` 已禁用时降级 default |
 | 6 | **不可信 Allow 规则**（不在信任目录的 project / local，以及 command / sandbox 来源） | 放行，但**不能越过命令安全检查** |
-| 7 | **权限模式策略**（`tool-permission-strategy.ts`） | 按当前 [PermissionMode](permission-modes.md) 决定是否需要审批 |
+| 7 | **权限模式策略** | 按当前 [权限模式](permission-modes.md) 决定是否需要审批 |
 | 8 | dontAsk / async agent 兜底 | print / 异步代理场景把 `ask` 转成 `deny` 避免死锁 |
 
-> **要点**：deny 永远优先，且分"可信 / 不可信" allow 两层 —— 项目根目录被列入信任目录前，`.codebuddy/settings.json` 的 allow 规则**不能越过命令安全门**。这是与 cc 不一样的地方，目的是防止恶意仓库把自己的 settings 推到团队 PR 时绕过本地安全保护。
+> **要点**：deny 永远优先，且分"可信 / 不可信" allow 两层 —— 项目根目录被列入信任目录前，`.codebuddy/settings.json` 的 allow 规则**不能越过命令安全门**。目的是防止恶意仓库把自己的 settings 推到团队 PR 时绕过本地安全保护。
 
-读类工具（Read / Grep / Glob 等）默认在信任目录内不弹审批，编辑类与 Bash 一律走完整 Phase 链。具体在 `tool-permission-strategy.ts::ToolPermissionDefaultStrategy` 与 `permission-utils.ts::isArgsInTrustedDirectories`。
+读类工具（Read / Grep / Glob 等）默认在信任目录内不弹审批，编辑类与 Bash 一律走完整 Phase 链。
 
 ## 规则的三种行为
 
@@ -43,7 +43,7 @@ CodeBuddy Code 用一套分层评估机制平衡能力与安全。它在主代
 
 ### `/permissions` 命令
 
-会话里输入 `/permissions` 打开权限管理面板（命令实现见 `permissions-command-executor.ts`），可以查看当前所有 allow / ask / deny 规则、它们来自哪一层 settings，并临时增删（写到 user / project 或 project-local 任一作用域）。
+会话里输入 `/permissions` 打开权限管理面板，可以查看当前所有 allow / ask / deny 规则、它们来自哪一层 settings，并临时增删（写到 user / project 或 project-local 任一作用域）。
 
 弹窗里勾选 **"Yes, don't ask again"** 时，CodeBuddy 会把当前命令对应的最稳前缀写入对应作用域 settings 的 `allow` 数组。
 
@@ -56,8 +56,6 @@ CodeBuddy Code 用一套分层评估机制平衡能力与安全。它在主代
 | `--add-dir <path>` | 把额外目录加入信任目录范围（影响 Read 是否需要弹询问） |
 | `-y` / `--dangerously-skip-permissions` | 等价于 `--permission-mode bypassPermissions` |
 
-定义见 `cli-provider.ts:40-55`。
-
 ### 配置文件
 
 详见 [Settings 配置](settings.md)。CodeBuddy 按这 4 个作用域合并：
@@ -69,8 +67,6 @@ CodeBuddy Code 用一套分层评估机制平衡能力与安全。它在主代
 | project-local | `<repo>/.codebuddy/settings.local.json`（不进 git，本地覆盖） |
 | cliArg / flagSettings / session / policySettings | 进程态，不落盘 |
 
-具体合并代码见 `tool-permission-service.ts:647-741`。
-
 ## 规则语法
 
 规则形态：`Tool` 或 `Tool(specifier)`。
@@ -86,7 +82,7 @@ CodeBuddy Code 用一套分层评估机制平衡能力与安全。它在主代
 | `Read` | 所有文件读 |
 | `Edit` | 所有文件编辑 |
 
-`*` 也可以单独作为规则（`permission-utils.ts:194` 把它当成全匹配通配）。
+`*` 也可以单独作为规则，相当于全匹配通配。
 
 ### 加 specifier 做细粒度
 
@@ -108,22 +104,22 @@ CodeBuddy Code 用一套分层评估机制平衡能力与安全。它在主代
 
 ### Bash
 
-Bash 规则支持三种语法（实现见 `permission-utils.ts::matchSingleCommandAgainstPattern`，`414-450 行`）：
+Bash 规则支持三种语法：
 
 | 语法 | 含义 | 示例 |
 | :--- | :--- | :--- |
 | 精确匹配 | pattern 完全等于命令 | `Bash(npm run build)` 仅匹配 `npm run build` |
 | `:*` 前缀 | pattern 末尾 `:*` → 匹配命令第一个词 / 多词前缀 | `Bash(git:*)` 匹配 `git status` / `git push origin main` |
-| 通配符 | pattern 含 `*` 时走 picomatch bash 模式（**`*` 可跨 `/`**） | `Bash(npm run *)` 匹配 `npm run build`；`Bash(ls *)` 匹配 `ls -al /tmp/x` |
+| 通配符 | pattern 含 `*` 时按 bash glob 模式匹配（**`*` 可跨 `/`**） | `Bash(npm run *)` 匹配 `npm run build`；`Bash(ls *)` 匹配 `ls -al /tmp/x` |
 
-> 与 minimatch 不同，cbc Bash 通配符模式刻意启用 `bash: true`，让 `*` 能跨越 `/` —— 否则 `ls *` 无法匹配 `ls -al /xxx`，这是用户最常踩的坑（见 `permission-utils.ts:441-446` 的注释）。
+> 通配符模式刻意让 `*` 能跨越 `/` —— 否则 `ls *` 无法匹配 `ls -al /xxx`，这是用户最常踩的坑。
 
 #### 复合命令
 
-CodeBuddy 用 `CommandParserService`（优先级：tree-sitter > shell-quote > regex 兜底，见 `permission-utils.ts:357-378`）解析 shell 操作符 `&&` / `||` / `;` / `|`，对每个子命令独立判定：
+CodeBuddy 会解析 shell 操作符 `&&` / `||` / `;` / `|`，对每个子命令独立判定：
 
-- **deny / ask 规则**：任一子命令命中即触发（`matchCommandRule`，`305-334 行`）
-- **allow 规则**：要求**所有子命令都命中**才放行（`isCommandAllowed`，`478-500 行`）。这是和 cc 不一样的取舍 —— 一个命中、一个不命中的复合命令仍会询问，避免攻击者把危险命令藏在被允许的命令旁边
+- **deny / ask 规则**：任一子命令命中即触发
+- **allow 规则**：要求**所有子命令都命中**才放行 —— 一个命中、一个不命中的复合命令仍会询问，避免攻击者把危险命令藏在被允许的命令旁边
 
 举例：
 
@@ -137,11 +133,11 @@ git status; rm *   → 询问（同上)
 
 #### 重定向
 
-包含 `>` / `<` / `>>` / `<<` / `&>` 的命令在 allow 规则下要求**精确匹配**（`permission-utils.ts:482-485`），通配符规则不生效。
+包含 `>` / `<` / `>>` / `<<` / `&>` 的命令在 allow 规则下要求**精确匹配**，通配符规则不生效。
 
 ### Read / Edit / Write
 
-文件类规则用 `minimatch` 做 glob 匹配，并做了三层路径归一（`permission-utils.ts::matchFileRule` 和 `normalizePath`，`241-268 行`）：
+文件类规则按 glob 匹配，并做了三层路径归一：
 
 | pattern | 解释 | 示例 |
 | :------ | :--- | :--- |
@@ -150,12 +146,12 @@ git status; rm *   → 询问（同上)
 | `/path` | 项目根起 | `Edit(/src/**/*.ts)` |
 | `path` 或 `./path` | 当前工作目录起 | `Read(.env)` |
 
-匹配开关：`dot: true`（允许点开头）、`nocase: true`（不区分大小写）、`matchBase: true`（裸文件名可匹配任意深度）。
+匹配开关：允许点开头、不区分大小写、裸文件名可匹配任意深度。
 
 注意：
 
 - `Edit(.git/**)` 之类的 deny 规则会阻挡所有走 Edit / Write / NotebookEdit 的尝试；但**不阻挡**通过 Bash 跑 `python -c 'open(".git/config", "w")...'` 这类间接路径 —— 操作系统级保护需要靠 [Bash 沙箱](bash-sandboxing.md)
-- Read 规则同样会被部分 Bash 文件读命令（`cat`、`head`、`tail` 等）拦截解析（见 `command-utils.ts::checkCommandSafety` 内部对这类命令的特殊识别）
+- Read 规则同样会被部分 Bash 文件读命令（`cat`、`head`、`tail` 等）拦截解析
 
 ### WebFetch
 
@@ -164,7 +160,7 @@ WebFetch                       # 任何 URL
 WebFetch(domain:example.com)   # 仅 example.com 及子域
 ```
 
-匹配实现见 `permission-utils.ts::matchURLRule`（`515 行`），支持 `domain:` 前缀做主机名匹配。
+支持 `domain:` 前缀做主机名匹配（含子域）。
 
 ### MCP 工具
 
@@ -176,7 +172,7 @@ MCP 工具命名格式：`mcp__<server>__<tool>`。规则三种粒度：
 | `mcp__puppeteer__*` | 同上（通配符写法） |
 | `mcp__puppeteer__navigate` | 仅 navigate 工具 |
 
-`tool-permission-service.ts:152` 起判定 `tool.name.startsWith('mcp__')`，进入 MCP 专用分支。
+工具名以 `mcp__` 开头时按 MCP 规则匹配。
 
 ### Agent（子代理）
 
@@ -206,7 +202,7 @@ codebuddy --disallowedTools "Agent(Explore) Agent(Plan)"
 }
 ```
 
-Skill 规则**必须**是精确匹配（`permission-utils.ts::matchSkillRule`，`458-464 行`），不支持通配符。
+Skill 规则**必须**是精确匹配，不支持通配符。
 
 ## 信任目录
 
@@ -221,22 +217,22 @@ CodeBuddy 默认认为只有**当前工作目录**是受信任的。Read 工具
 | `permissions.additionalDirectories` 配置项 | 持久化 |
 | `permissions.trustedDirectories` 配置项 | 持久化 |
 
-实现见 `permission-utils.ts:561-583`：信任目录列表 = `工作区根 + settings.trustedDirectories + session.options.addDir`。
+最终生效的信任目录 = 工作区根 + `settings.trustedDirectories` + 启动时 `--add-dir` / 会话内 `/add-dir` 添加的目录。
 
-> `--add-dir` 和 `permissions.additionalDirectories` 都只授予**文件访问权**，**不会**让 CodeBuddy 加载这些目录里的 `.codebuddy/` 配置（agents / hooks / settings 等都仍以启动目录的为准）。这与 cc 行为一致。
+> `--add-dir` 和 `permissions.additionalDirectories` 都只授予**文件访问权**，**不会**让 CodeBuddy 加载这些目录里的 `.codebuddy/` 配置（agents / hooks / settings 等都仍以启动目录的为准）。
 
 ### 项目目录信任开关
 
-仓库目录是否被你"显式信任"还会影响 allow 规则的可信级别（`tool-permission-service.ts:182`）。当目录**未被信任**时：
+仓库目录是否被你"显式信任"还会影响 allow 规则的可信级别。当目录**未被信任**时：
 
 - `<repo>/.codebuddy/settings.json` 与 `.codebuddy/settings.local.json` 里的 `allow` 规则会被归到**不可信**层（Phase 6），**不能**越过命令安全检查
-- 用户在交互界面确认信任后（`directoryTrustService.isTrustDirectory`），项目级规则会被提升到 Phase 2 可信层
+- 用户在交互界面确认信任后，项目级规则会被提升到 Phase 2 可信层
 
-这是 cbc 独有的安全模型，目的是缓解仓库被克隆后立即跑产生的横向风险。
+目的是缓解仓库被克隆后立即跑产生的横向风险。
 
 ## 受保护文件 / 路径
 
-任意模式下，CodeBuddy 都会对一组关键路径加额外保护（与 [PermissionMode 文档](permission-modes.md#受保护的关键文件) 重合）：
+任意模式下，CodeBuddy 都会对一组关键路径加额外保护（与 [权限模式](permission-modes.md#受保护的关键文件) 一致）：
 
 - 仓库自身：`.git`、`.gitconfig`、`.gitmodules`
 - shell 配置：`.bashrc` / `.zshrc` / `.envrc` 等
@@ -245,7 +241,7 @@ CodeBuddy 默认认为只有**当前工作目录**是受信任的。Read 工具
 - CodeBuddy 自身：`.codebuddy`（除 `.codebuddy/worktrees`）
 - MCP / 配置：`.mcp.json` / `.codebuddy.json`
 
-`bypassPermissions` 模式仍然会让其中绝大部分通过，但 `rm -rf /` / `rm -rf ~` 这类"灾难性命令"会通过 `isDangerousCommand` 兜底强制询问（`tool-permission-service.ts:244`）。
+`bypassPermissions` 模式仍然会让其中绝大部分通过，但 `rm -rf /` / `rm -rf ~` 这类"灾难性命令"会被强制询问。
 
 ## 用 Hooks 扩展权限
 
@@ -274,8 +270,8 @@ CodeBuddy 默认认为只有**当前工作目录**是受信任的。Read 工具
 
 注意：
 
-- **deny / ask 规则始终先于钩子生效**。钩子返回 `"allow"` 不能越过 settings 里的 deny —— 这条与 cc 行为一致
-- 但**阻断式钩子**（exit code 2）能在 Phase 1 之前 short-circuit allow 规则，所以可以"先放行 Bash 全部，但用钩子单独拦几条特定命令"
+- **deny / ask 规则始终先于钩子生效**。钩子返回 `"allow"` 不能越过 settings 里的 deny
+- 但**阻断式钩子**（exit code 2）能在 Phase 1 之前短路 allow 规则，所以可以"先放行 Bash 全部，但用钩子单独拦几条特定命令"
 
 ## 与沙箱的协作
 
@@ -301,9 +297,9 @@ projectSettings > localSettings > command/sandbox 来源
 
 但**评估顺序**比 settings 优先级更重要：
 
-- `deny` 数组从所有作用域合并（`PermissionUtils.mergeRulesFromAllSources`），**任一作用域 deny 即拒**
-- `allow` 数组按"可信 / 不可信"分两次合并：可信合并里 user/cli/flag/session/policy 永远在；project/local 仅在目录被信任时算可信
-- `disableBypassPermissionsMode` 在 `user / project / local / cliArg` 四层任一为 `"disable"` 即生效（见 `tool-permission-service.ts:670-673`）—— 比 cc 多了项目级硬关闭通道
+- `deny` 数组从所有作用域合并，**任一作用域 deny 即拒**
+- `allow` 数组按"可信 / 不可信"分两次合并：可信合并里 user / cli / flag / session / policy 永远在；project / local 仅在目录被信任时算可信
+- `disableBypassPermissionsMode` 在 user / project / local / CLI 启动参数四层任一为 `"disable"` 即生效
 
 ## 示例配置
 
@@ -371,7 +367,7 @@ projectSettings > localSettings > command/sandbox 来源
 
 ## 相关资源
 
-- [权限模式（Permission Mode）](permission-modes.md)：default / acceptEdits / plan / bypassPermissions / delegate 等模式
+- [权限模式](permission-modes.md)：default / acceptEdits / plan / bypassPermissions / delegate 等模式
 - [Settings 配置](settings.md)：完整配置字段、作用域与合并规则
 - [Hooks 钩子系统](hooks-guide.md)：用钩子做编程式权限决策
 - [Bash 沙箱化](bash-sandboxing.md)：Bash 命令的 OS 级隔离

package/dist/web-ui/docs/cn/cli/tools-reference.md

@@ -22,11 +22,14 @@ CodeBuddy Code 内置一系列工具来帮助理解和修改代码库。下表
 | `ImageEdit` | 基于文本指令编辑或修改已有图片 | 是 |
 | `ImageGen` | 根据文本描述生成图片 | 是 |
 | `LeaveWorktree` | 退出 worktree 会话并返回原始目录 | 是 |
+| `ListMcpResources` | 列出已连接 [MCP 服务器](mcp.md)暴露的所有资源/模板，可选按服务器名过滤 | 否 |
 | `LSP` | 通过语言服务器提供代码智能。文件编辑后自动报告类型错误和警告。还支持跳转定义、查找引用、获取类型信息、列出符号、查找实现、追踪调用层级等导航操作。需要[代码智能插件](plugins.md)及其语言服务器二进制文件 | 否 |
 | `MultiEdit` | 在单个原子操作中对同一文件执行多步编辑 | 是 |
 | `NotebookEdit` | 修改 Jupyter notebook 单元格内容 | 是 |
+| `NotebookRead` | 读取 Jupyter notebook 单元格内容，可指定 `cell_id` 读单个 cell | 否 |
 | `PowerShell` | 在 Windows 上执行 PowerShell 命令。仅 Windows 可用，参见 [PowerShell 工具行为](#powershell-工具行为) | 是 |
 | `Read` | 读取文件内容，支持图片、PDF 和 Jupyter notebook | 否 |
+| `ReadMcpResource` | 按 server + URI 读取指定 MCP 资源的内容，配合 `ListMcpResources` 使用 | 是 |
 | `SendMessage` | 在 [Agent 团队](agent-teams.md)中向队友发送消息 | 否 |
 | `Skill` | 在主对话中执行 [Skill 技能](skills.md) | 否 |
 | `SlashCommand` | 执行自定义[斜杠命令](slash-commands.md) | 是 |
@@ -40,8 +43,10 @@ CodeBuddy Code 内置一系列工具来帮助理解和修改代码库。下表
 | `TeamCreate` | 创建 [Agent 团队](agent-teams.md)以协调多个代理协作 | 否 |
 | `TeamDelete` | 删除 Agent 团队及其任务目录 | 否 |
 | `ToolSearch` | 搜索并加载延迟加载的工具，支持内置工具和 [MCP 工具](mcp.md#延迟加载-defer_loading) | 否 |
+| `WaitForMcpServers` | 等待指定的 MCP 服务器完成连接（默认等所有 pending 的服务器），最长 5 秒 | 否 |
 | `WebFetch` | 获取指定 URL 的内容并进行 AI 分析 | 是 |
 | `WebSearch` | 执行网络搜索 | 是 |
+| `Workflow` | 启动 [Dynamic Workflow](workflows.md) 异步运行，立刻返回 runId 并在后台执行；通过 `TaskOutput` 拉取结果 | 是 |
 | `Write` | 创建或覆盖文件 | 是 |
 
 权限规则可通过 `/permissions` 命令或在[权限设置](settings.md#权限设置)中配置。另请参阅[工具特定的权限规则](iam.md#工具特定的权限规则)。
@@ -104,18 +109,6 @@ PowerShell 工具内置安全检查器，覆盖代码注入、下载执行、提
 
 部分工具（如通过 [MCP 服务器](mcp.md)提供的工具）采用延迟加载机制。这些工具不会在初始工具列表中出现，需要通过 `ToolSearch` 发现和激活。一旦激活，工具在会话剩余时间内保持可用。
 
-通过产品配置可以将内置工具设置为延迟加载：
-
-```json
-{
-  "tools": {
-    "ToolName": {
-      "deferLoading": true
-    }
-  }
-}
-```
-
 ## 另请参阅
 
 * [身份和访问管理](iam.md)：权限系统、规则语法和工具特定规则

package/dist/web-ui/docs/cn/cli/workflows.md

@@ -1,19 +1,19 @@
-# Dynamic Workflows：用脚本编排成规模的子代理
+# Dynamic Workflows（动态工作流）
 
 > Dynamic Workflows 让 CodeBuddy 写一段 JavaScript 编排脚本，由运行时在后台调度数十甚至数百个子代理协作完成任务。脚本本身可读、可改、可重跑，适合代码库审计、大型迁移、需要交叉验证的研究类任务。
 
 <Note>
-Dynamic Workflows 目前为研究预览阶段，要求 CodeBuddy Code v2.1.154 或更高版本。在 `/config` 中通过 "Dynamic workflows" 开关启用。
+Dynamic Workflows 目前为研究预览阶段，要求 CodeBuddy Code v2.105.0 或更高版本，默认已启用。如需关闭，可在 `/config` 中关掉 "Dynamic workflows" 开关。
 </Note>
 
 Dynamic Workflow 是一段由 CodeBuddy 为你的任务现场编写的 JavaScript 脚本，运行时在后台执行它，你的会话保持响应。脚本里包含一个或多个 [`agent()`](#脚本-api) 调用，每次调用都派出一个独立的子代理工作；脚本拿到中间结果后，可以分支、可以并行、可以再投递给下一批子代理。
 
 当一项任务大到一个会话装不下，或者你希望编排逻辑被记录成"可重跑的脚本"时，就该用 Workflow。典型场景：
 
-- 全代码库的 Bug 巡检
-- 跨 500 个文件的迁移
-- 一个需要从多源交叉印证的研究问题
-- 一个值得从多个独立角度先草拟、再对比择优的复杂方案
+- 全 monorepo 的接口契约 / 鉴权 / 埋点巡检
+- 一组 issue 的批量分诊与归属定位
+- 跨多个仓库 / 多源资料的交叉印证调研
+- 一个值得从多个独立角度先各自起草、再相互对照择优的方案
 
 本页介绍：
 
@@ -50,7 +50,7 @@ Workflow 把"计划"挪进了代码。子代理 / Skills / Agent Teams 的编排
    带一个想调研的问题运行 `/deep-research`。它会从多个角度并行搜索、抓取并交叉印证来源，最终合成一份带引用的报告。
 
    ```text
-   /deep-research Node.js 的 permission model 在 v20 到 v22 之间有什么变化？
+   /deep-research 主流前端 monorepo 工具（Turborepo / Nx / Lerna）近一年在远端缓存与任务图上的演进对比
    ```
 
 2. **批准运行**
@@ -81,7 +81,7 @@ CodeBuddy Code 内置如下 Workflow：
 
 | 命令                          | 作用                                                                                                                                                                                                              |
 | :---------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `/deep-research <问题>`       | 多角度并行搜索、抓取并交叉印证来源，对每条主张投票，剔除未通过印证的部分，输出一份带引用的报告。需要 [WebSearch 工具](tools-reference.md#websearch-tool-behavior) 可用。                                            |
+| `/deep-research <问题>`       | 多角度并行搜索、抓取并交叉印证来源，对每条主张投票，剔除未通过印证的部分，输出一份带引用的报告。需要 [WebSearch 工具](tools-reference.md) 可用。                                            |
 
 [你自己保存的 Workflow](#保存-workflow-以便复用) 会以同样方式注册成命令，在 `/` 自动补全里与内置 Workflow 一同出现。
 
@@ -120,7 +120,7 @@ Workflow 在后台运行，会话保持响应。任何时候 `/workflows` 都能
 不想改会话整体 effort 等级，只想让某次任务走 Workflow，在提示里加上关键词 `ultracode`。用自然语言说"用一个 workflow 跑这个"或者 "use a workflow"，效果一样：CodeBuddy 把直接请求当作同等的显式 opt-in。
 
 ```text
-ultracode：审计 src/routes/ 下每个 API 端点是否漏了鉴权检查
+ultracode：扫描 packages/ 下所有 domain，找出哪些 Facade / CloudRepo 方法缺单测，按风险排序
 ```
 
 CodeBuddy Code 会高亮你输入里的关键词，CodeBuddy 收到这个提示后，会为该任务写一段 Workflow 脚本，而不是逐轮地展开工作。如果你不想触发 Workflow，按 macOS 的 `Option+W`、Windows / Linux 的 `Alt+W` 取消本次提示的高亮；或者光标停在关键词后面按 Backspace 删掉它即可。要彻底关闭关键词触发，到 `/config` 关掉 "Ultracode keyword trigger"。
@@ -131,7 +131,7 @@ CodeBuddy Code 会高亮你输入里的关键词，CodeBuddy 收到这个提示
 
 ### Ultracode 模式：让 CodeBuddy 自己决定
 
-Ultracode 是 CodeBuddy Code 的一个组合配置：把 [推理强度](models.md#调整推理强度) 推到 `xhigh`，并叠加自动 Workflow 编排。开启后，CodeBuddy 会主动判断哪些任务值得走 Workflow，不必你每次提醒。
+Ultracode 是 CodeBuddy Code 的一个组合配置：把 [推理强度](models.md#配置字段说明) 推到 `xhigh`，并叠加自动 Workflow 编排。开启后，CodeBuddy 会主动判断哪些任务值得走 Workflow，不必你每次提醒。
 
 ```text
 /effort ultracode
@@ -139,28 +139,24 @@ Ultracode 是 CodeBuddy Code 的一个组合配置：把 [推理强度](models.m
 
 进入 ultracode 后，一个请求可能被拆成连续多个 Workflow：先一个 run 摸代码现状、再一个 run 实施改动、再一个 run 验证。会话里**每个**任务都按这个模式跑，每条请求消耗的 Token 会比低 effort 等级显著更多、耗时也更长。
 
-ultracode 仅在当前会话生效，新开会话自动重置。回到日常工作时用 `/effort high` 回退即可。它仅在支持 `xhigh` [推理强度](models.md#调整推理强度) 的模型上可用；不支持的模型上 `/effort` 菜单不会展示该选项。
+ultracode 仅在当前会话生效，新开会话自动重置。回到日常工作时用 `/effort high` 回退即可。它仅在支持 `xhigh` [推理强度](models.md#配置字段说明) 的模型上可用；不支持的模型上 `/effort` 菜单不会展示该选项。
 
 ### 运行前批准计划
 
 CLI 里，每次启动都会弹出运行前确认：
 
-- **Yes, run it**：开始运行
-- **Yes, and don't ask again for `<name>` in `<path>`**：开始运行，并对该项目内同名 Workflow 不再询问
-- **View raw script**：先读脚本再决定
-- **No**：取消
-
-`Ctrl+G` 在你的编辑器里打开脚本；`Tab` 可以在运行前调整提示。
+- **Yes**：开始运行
+- **Yes, and don't ask again this session**：开始运行，并在当前会话内对 Workflow 工具不再询问（仅会话级，新会话会重新询问）
+- **No**：取消（也可按 `Esc`）
 
 是否会出现这个询问，取决于你的 [权限模式](permission-modes.md)：
 
 | 权限模式                                   | 何时询问                                                                                                                          |
 | :----------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------- |
-| Default、Accept edits                      | 每次都询问；除非你为该 Workflow 在该项目下选过 **Yes, and don't ask again**                                                       |
-| Auto                                       | 只在首次启动时询问；任何 **Yes** 都会写入用户设置，后续直接启动。ultracode 开启时整个询问被跳过                                   |
+| Default、Accept edits、Auto                | 每次都询问；除非你在当前会话里选过 **Yes, and don't ask again this session**。ultracode 开启时整个询问被跳过                       |
 | Bypass permissions、`codebuddy -p`、Agent SDK | 永不询问，运行直接开始                                                                                                            |
 
-权限模式只影响**启动前**这个询问。Workflow 派出去的子代理始终在 `acceptEdits` 模式下跑，并继承你的[工具白名单](settings.md#permission-settings)，与你会话当前模式无关。文件改动是自动批准的。
+权限模式只影响**启动前**这个询问。Workflow 派出去的子代理始终在 `acceptEdits` 模式下跑，并继承你的[工具白名单](settings.md#权限设置)，与你会话当前模式无关。文件改动是自动批准的。
 
 不在白名单里的 Shell 命令、Web Fetch、MCP 工具调用，仍可能在运行中弹询问。要避免长任务被打断，启动前把代理需要的命令加进白名单。
 
@@ -186,7 +182,7 @@ CLI 里，每次启动都会弹出运行前确认：
 下面这段提示触发一个保存的 Workflow，并把 issue 列表作为参数传入：
 
 ```text
-> 用 /triage-issues 跑一下 issue 1024、1025、1030
+> 用 /review-branch 把 feat/skills-center 最近 20 条 commit 各自跑一遍架构评审
 ```
 
 CodeBuddy 把列表作为结构化数据传入，脚本可以直接对 `args` 用数组 / 对象方法，无需自己解析。如果调用方没传 `args`，脚本里 `args` 是 `undefined`。
@@ -235,8 +231,6 @@ CodeBuddy 把列表作为结构化数据传入，脚本可以直接对 `args`
 | `args`                        | 调用方传入的参数（见 [给已保存的 Workflow 传参](#给已保存的-workflow-传参)）                                                           |
 | `workflow(name, args?)`       | 嵌套调用一个**已保存**的 Workflow（仅父级可调用，子级不再暴露此 hook，禁止深度嵌套）                                                    |
 
-更多模式见 [`build/patches/cli-saas/templates/workflow-tool-description.tpl`](../../../build/patches/cli-saas/templates/workflow-tool-description.tpl) 与 [`workflow-subagent-system-preamble.tpl`](../../../build/patches/cli-saas/templates/workflow-subagent-system-preamble.tpl)。
-
 ## 运行管理
 
 run 一旦启动，从 `/workflows` 视图管理；也可以展开输入框下方任务面板里的进度行。
@@ -268,7 +262,7 @@ Workflow 在 CLI、桌面端、IDE 扩展、`codebuddy -p` 非交互模式与 [A
 - `~/.codebuddy/settings.json` 设 `"disableWorkflows": true`，会持久化
 - 设环境变量 `CODEBUDDY_DISABLE_WORKFLOWS=1`，启动时读取，在哪儿设就在哪儿生效
 
-为整个组织关闭：在 [托管设置](settings.md#enterprise-managed-policy-settings) 里设 `"disableWorkflows": true`。
+为整个组织关闭：在 [托管设置](settings.md) 里设 `"disableWorkflows": true`。
 
 关闭后，内置 Workflow 命令不可用，关键词 `ultracode` 不再触发，`/effort` 菜单也不再展示 ultracode 选项。
 
@@ -277,5 +271,5 @@ Workflow 在 CLI、桌面端、IDE 扩展、`codebuddy -p` 非交互模式与 [A
 - [子代理](sub-agents.md)：Workflow 编排的底层"工人"原语
 - [Agent Teams](agent-teams.md)：另一种多代理协作形态，由领导代理管计划
 - [Skills 技能系统](skills.md)：把"指令"沉淀成可复用 Skill
-- [推理强度调整（含 ultracode）](models.md#调整推理强度)
+- [推理强度调整（含 ultracode）](models.md#配置字段说明)
 - [Hooks 钩子系统](hooks-guide.md)：在工具调用与会话事件上挂钩子

package/dist/web-ui/docs/en/cli/permission-modes.md

@@ -4,7 +4,7 @@
 
 ## Available Modes
 
-All modes actually defined by CodeBuddy Code in the `src/node/settings/settings-protocol.ts::PermissionMode` enum are listed below. The first four are directly exposed to CLI users, and the remaining modes are for programmatic or integration scenarios.
+CodeBuddy Code provides the following permission modes. The first four are directly exposed to CLI users; the rest are for IDE integrations and subagent scenarios.
 
 ### Modes You Can Switch Manually
 
@@ -14,14 +14,14 @@ All modes actually defined by CodeBuddy Code in the `src/node/settings/settings-
 | [`acceptEdits`](#acceptedits-auto-approve-file-edits)        | Read + Edit-family tools inside trusted directories                                                           | Keep writing, then review with git diff                     |
 | [`plan`](#plan-explore-before-changing)                      | Delegates to the mode active before entering plan (default = `default`); additionally allows writing session plan files | Explore the code before deciding what to change              |
 | [`bypassPermissions`](#bypasspermissions-skip-all-checks)    | All tools, without asking                                                                                     | Use only in sandbox containers / VMs / offline dev containers |
-| [`delegate`](#delegate-multi-agent-coordination-mode)        | Coordination tools only (such as Agent / TaskCreate / SendMessage / team management); implementation tools are blocked by the assembly layer | The main agent only decomposes and delegates work to subagents |
+| [`delegate`](#delegate-multi-agent-coordination-mode)        | Coordination tools only (such as Agent / TaskCreate / SendMessage / team management); implementation tools are blocked | The main agent only decomposes and delegates work to subagents |
 
 ### Programmatic / Integration Modes (Not in the Shift+Tab Cycle)
 
 | Mode            | When it appears                                                                                                                   |
 | :-------------- | :-------------------------------------------------------------------------------------------------------------------------------- |
-| `fullAccess`    | Passed by an ACP client (IDE integration) through the protocol; semantically equivalent to globally allowing everything like `bypassPermissions` (see `sandbox-orchestrator.ts:946`) |
-| `work`          | Passed by an ACP client. Read is allowed directly (without checking trusted directories), Edit always asks, Bash allows only safe commands directly, and other tools ask |
+| `fullAccess`    | Passed by an IDE client through the protocol; semantically equivalent to globally allowing everything like `bypassPermissions` |
+| `work`          | Passed by an IDE client. Read is allowed directly (without checking trusted directories), Edit always asks, Bash allows only safe commands directly, and other tools ask |
 | `ignore`        | Only takes effect for subagents / teammates. It means “use the main session’s mode; do not let the subagent’s own frontmatter override it”. Main sessions do not use it |
 
 ## Switching Permission Modes
@@ -30,7 +30,7 @@ You do not switch modes by telling CodeBuddy in chat. Set them through the follo
 
 ### Switch During a Session: Shift+Tab
 
-In the CLI, press `Shift+Tab` to cycle through the following five modes (order defined in `input-hint-box.tsx:72`):
+In the CLI, press `Shift+Tab` to cycle through the following five modes:
 
 ```
 default → bypassPermissions → acceptEdits → plan → delegate → default → ...
@@ -56,7 +56,7 @@ codebuddy --permission-mode bypassPermissions
 codebuddy --permission-mode default
 ```
 
-The CLI option `--permission-mode` accepts only these four literals (see `cli-provider.ts:36`). Other modes (`delegate` / `work` / `fullAccess` / `ignore`) cannot be passed on the command line.
+The CLI option `--permission-mode` accepts only these four literals. Other modes (`delegate` / `work` / `fullAccess` / `ignore`) cannot be passed on the command line.
 
 It also works under `-p` ([headless mode](headless.md)):
 
@@ -66,7 +66,7 @@ codebuddy -p --permission-mode acceptEdits "refactor src/utils/foo.ts"
 
 You can also add the following at startup:
 
-- `-y` / `--dangerously-skip-permissions`: equivalent to `--permission-mode bypassPermissions`; skips all permission checks (see `cli-provider.ts:35`)
+- `-y` / `--dangerously-skip-permissions`: equivalent to `--permission-mode bypassPermissions`; skips all permission checks
 
 ### Persistent Default: `defaultMode`
 
@@ -80,17 +80,15 @@ Write it to `~/.codebuddy/settings.json` or repository `.codebuddy/settings.json
 }
 ```
 
-If `--permission-mode` is also provided at startup, the CLI argument takes precedence (see the fallback chain in `stream-json-view.ts:525`: `current session value → permissions.defaultMode → PermissionMode.Default`).
+If `--permission-mode` is also provided at startup, the CLI argument takes precedence. The fallback order is: current session value → `permissions.defaultMode` → `default`.
 
 ### Automatic Memory of the “Pre-Plan Mode”
 
-When entering `plan`, CodeBuddy saves the current mode to `session.meta.prePlanPermissionMode` and restores it when leaving plan. This means:
+When entering `plan`, CodeBuddy remembers the current mode and restores it when leaving plan. This means:
 
 - If you press `Shift+Tab` from `acceptEdits` into `plan`, the approval strategy for Read/Edit/Bash during plan still follows `acceptEdits` rules (except for the plan file, which never asks)
 - When leaving plan, you return to `acceptEdits`; it will not be forcibly dropped to `default`
 
-The implementation is `delegateToPrePlanStrategy` in `tool-permission-strategy.ts:92`.
-
 ## Detailed Semantics by Mode
 
 ### default (Default)
@@ -117,20 +115,20 @@ Suitable when you want to keep writing and review the diff later, without being
 
 Notes:
 
-- Only **Edit-family tools** are auto-approved (Edit / Write / NotebookEdit, etc.). This does not affect Bash — Bash always follows a separate safety classification (`command-utils.ts::checkCommandSafety`)
-- “Trusted directories” are based on the workspace root + user-configured `permissions.additionalDirectories` + startup `--add-dir` (see `permission-utils.ts:561`)
+- Only **Edit-family tools** are auto-approved (Edit / Write / NotebookEdit, etc.). This does not affect Bash — Bash always follows a separate safety classification
+- “Trusted directories” are based on the workspace root + user-configured `permissions.additionalDirectories` + startup `--add-dir`
 - Writes to [protected files](#protected-critical-files) still ask according to the original mode and do not use automatic allow
 
 ### plan (Explore Before Changing)
 
 In plan mode, CodeBuddy focuses on reading code and running read-only Bash commands to investigate, writes the proposal as a plan, and then comes back for your approval. It does not apply changes to your source code.
 
-See `tool-permission-strategy.ts:75` for the implementation idea — plan mode is not an independent “fully read-only block”; it **delegates to the pre-plan mode**:
+Plan mode is not an independent “fully read-only block”; it **delegates to the pre-plan mode**:
 
 - Read: delegates the decision to the pre-plan mode (default is `default`)
-- Edit: first checks whether the target path is the current session’s **plan file** (`PlanStorageService.getPlanFilePath`) → if yes, allow; otherwise delegate to the pre-plan mode
+- Edit: only allowed when the target path is the current session’s **plan file**; otherwise delegates to the pre-plan mode
 - Bash: delegates to the pre-plan mode
-- Enter plan through `Shift+Tab` or the `EnterPlanMode` tool; exit through another `Shift+Tab` or `ExitPlanMode` (see `enter-planmode-tool.ts:94` and `exit-planmode-tool.ts:73`)
+- Enter plan through `Shift+Tab` or the `EnterPlanMode` tool; exit through another `Shift+Tab` or `ExitPlanMode`
 
 Start directly in plan mode:
 
@@ -167,16 +165,16 @@ Write `permissions.disableBypassPermissionsMode: "disable"` to settings at any l
 }
 ```
 
-After this is written, even if the session switches to `bypassPermissions`, the permission strategy will **fall back to `default` decisions** (see `tool-permission-strategy.ts:192`). If any layer of settings disables it, it takes effect (user / project / local / cli flagSettings with any layer set to `"disable"`; see `tool-permission-service.ts:670`).
+After this is written, even if the session switches to `bypassPermissions`, the permission strategy will **fall back to `default` decisions**. It takes effect when any layer of settings (user / project / local / CLI startup flag) is set to `"disable"`.
 
 ### delegate (Multi-Agent Coordination Mode)
 
 In `delegate` mode, the main agent can **only coordinate**: assign tasks, start subagents, and communicate across members. It does not edit files or run commands itself.
 
-Implementation idea:
+Behavior:
 
-- The assembly layer (tool-manager) removes “implementation tools” (Read/Write/Edit/Bash, etc.) from the main agent’s available tool set
-- By the time execution reaches the `delegate` strategy layer (`tool-permission-strategy.ts:244`), only coordination tools remain (Agent / TaskCreate / SendMessage, etc.), and they are all allowed automatically
+- Only coordination tools (Agent / TaskCreate / SendMessage, etc.) remain in the main agent’s tool set, all allowed automatically
+- Implementation tools (Read / Write / Edit / Bash, etc.) are blocked, and execution is delegated to subagents
 
 This is suitable when you explicitly want the main agent to “plan only, with specialized subagents doing the implementation” ([Agent Teams](agent-teams.md) / [Subagents](sub-agents.md)).
 
@@ -184,26 +182,26 @@ Press `Shift+Tab` until `delegate` appears to enter it.
 
 ### work (IDE Integration)
 
-Set by the ACP client (IDE extension) through the protocol (see `acp-agent.ts:3407`), and not directly exposed to CLI users. Semantics:
+Set by the IDE client through the protocol; not directly exposed to CLI users. Semantics:
 
-| Tool type | Decision                                                                            |
-| :-------- | :---------------------------------------------------------------------------------- |
-| Read      | **Allow directly** (does not check trusted directories)                              |
-| Edit      | Always ask                                                                          |
-| Bash      | Safe commands (marked by `checkCommandSafety` as `isSafe && !requiresApproval`) are allowed; others ask |
-| Other     | Allow                                                                               |
+| Tool type | Decision                                                |
+| :-------- | :------------------------------------------------------ |
+| Read      | **Allow directly** (does not check trusted directories)  |
+| Edit      | Always ask                                              |
+| Bash      | Safe commands are allowed directly; risky ones ask       |
+| Other     | Allow                                                   |
 
 ### fullAccess (IDE Integration)
 
-Only passed through the ACP protocol; same semantics as `bypassPermissions` (the sandbox orchestrator short-circuits it together with `BypassPermissions`, see `sandbox-orchestrator.ts:946`).
+Only passed through the IDE client protocol; same semantics as `bypassPermissions`.
 
 ### ignore (Subagent Only)
 
-Only used by subagent frontmatter / options. When a subagent writes `permissionMode: ignore` in its metadata, agent-task assembly treats it as “do not override the parent agent’s mode” and continues using the parent session’s current mode (see `agent-task.ts:1009`). This value does not appear in main sessions.
+Only used by subagent frontmatter / options. When a subagent writes `permissionMode: ignore` in its metadata, it is treated as “do not override the parent agent’s mode” and continues using the parent session’s current mode. This value does not appear in main sessions.
 
 ## Protected Critical Files
 
-Write operations to the following paths retain special handling even under `acceptEdits` / `bypassPermissions` (aligned with cc):
+Write operations to the following paths retain special handling even under `acceptEdits` / `bypassPermissions`:
 
 - Repository itself: `.git`, `.gitconfig`, `.gitmodules`
 - Shell config: `.bashrc` / `.bash_profile` / `.zshrc` / `.zprofile` / `.envrc`, etc.
@@ -212,8 +210,6 @@ Write operations to the following paths retain special handling even under `acce
 - CodeBuddy itself: `.codebuddy` (except `.codebuddy/worktrees`)
 - MCP / config: `.mcp.json` / `.codebuddy.json`
 
-The exact list and decision logic are defined by `tool-permission-service.ts`.
-
 ## Permission Mode Inheritance for Subagents
 
 Subagents ([Agent](sub-agents.md) tool calls and [Agent Teams](agent-teams.md) members) inherit the main session’s permission mode by default. To force an override at the team / project layer:
@@ -226,7 +222,7 @@ Subagents ([Agent](sub-agents.md) tool calls and [Agent Teams](agent-teams.md) m
 }
 ```
 
-After this is written, all subagents run under `bypassPermissions` (implementation priority chain in `agent-task.ts:1009`). Notes:
+After this is written, all subagents run under `bypassPermissions`. Notes:
 
 - Passing the `mode` parameter explicitly in an Agent tool call → **highest priority**, overrides this setting
 - Writing `permissionMode: ignore` in subagent frontmatter → still runs under the main session mode (not affected by this setting)