ccgx-workflow 1.0.4 → 1.0.5

package/templates/commands/optimize.md

@@ -13,7 +13,7 @@ argument-hint: "<优化目标> [--role=architect|critic|implementer|tester|write
 /optimize <优化目标> [--role=<name>]
 ```
 
-## Role-based routing（v4.1 specialist matrix）
+## Role-based routing（specialist matrix）
 
 可选 `--role=<name>` 叠加 role 维度路由：
 
@@ -23,7 +23,7 @@ argument-hint: "<优化目标> [--role=architect|critic|implementer|tester|write
 | **frontend**  | gemini/architect.md | gemini/reviewer.md (adversarial) | gemini/architect.md | gemini/tester.md | gemini/analyzer.md |
 | **fullstack** | codex+gemini/architect.md | both reviewer.md (adversarial) | runner 决 | runner 决 | claude |
 
-**未传 --role 时按 v4.0 双模型并行（{{BACKEND_PRIMARY}}/{{FRONTEND_PRIMARY}} optimizer.md），完全兼容**。`--role=critic` 触发"性价比反对意见"——挑战通用优化套路（如盲目缓存 / over-engineering）。详见 `src/utils/specialist-router.ts`。
+**未传 --role 时按双模型并行（{{BACKEND_PRIMARY}}/{{FRONTEND_PRIMARY}} optimizer.md），完全兼容**。`--role=critic` 触发"性价比反对意见"——挑战通用优化套路（如盲目缓存 / over-engineering）。详见 `src/utils/specialist-router.ts`。
 
 ## 上下文
 
@@ -40,12 +40,12 @@ argument-hint: "<优化目标> [--role=architect|critic|implementer|tester|write
 
 ---
 
-## 调用通道路由（v4.1 Phase 20，CCG codeagent 退役）
+## 调用通道路由（CCG codeagent 退役）
 
-CCG v4.1 把双模型并行通道从 `Bash(codeagent-wrapper)` **默认切换**为 plugin spawn：
+CCG 把双模型并行通道从 `Bash(codeagent-wrapper)` **默认切换**为 plugin spawn：
 
 1. **优先 plugin spawn**（默认）：装了 `codex@openai-codex` + `gemini@google-gemini` plugin → 用 `Agent(subagent_type="codex:codex-rescue")` + `Agent(subagent_type="gemini:gemini-rescue")` 并行，主线接 ≤200 token 摘要。
-2. **降级 codeagent-wrapper**（v4.0 BC fallback）：plugin 未装 → fallback 到 Bash 调用，行为与 v4.0 完全一致。
+2. **降级 codeagent-wrapper**（BC fallback）：plugin 未装 → fallback 到 Bash 调用，行为与 plugin 路径等价。
 
 **判定**：preflight `Bash` 跑 `ls ~/.claude/plugins/` 看有无 `codex@*` / `gemini@*` 子目录。helper 见 `src/utils/plugin-detection.ts`。
 
@@ -60,7 +60,7 @@ CCG v4.1 把双模型并行通道从 `Bash(codeagent-wrapper)` **默认切换**
 - 如果用户通过 `/add-dir` 添加了多个工作区，先用 Glob/Grep 确定任务相关的工作区
 - 如果无法确定，用 `AskUserQuestion` 询问用户选择目标工作区
 
-**调用语法**（v4.1 Phase 20 双通道）：
+**调用语法**（双通道）：
 
 **通道 A — plugin spawn（默认）**：
 
@@ -101,7 +101,7 @@ EOF",
 })
 ```
 
-> ⚠️ 通道 B `codeagent-wrapper` 在 v4.1 已标 **deprecated**，将在 v5.0 移除。
+> ⚠️ 通道 B `codeagent-wrapper` 已标 **deprecated**。
 
 **角色提示词**：
 
@@ -110,7 +110,7 @@ EOF",
 | 后端 | `~/.claude/.ccg/prompts/{{BACKEND_PRIMARY}}/optimizer.md` |
 | 前端 | `~/.claude/.ccg/prompts/{{FRONTEND_PRIMARY}}/optimizer.md` |
 
-**并行调用 + 事件驱动等待（v4.5.2 起）**：
+**并行调用 + 事件驱动等待**：
 
 1. 同 message 内 spawn 多个 `Bash(run_in_background: true)` 并行任务
 2. spawn 完后主线说明已启动 task-id，**直接 turn end**，**不调 TaskOutput**
@@ -119,7 +119,7 @@ EOF",
 5. **必须等所有相关 task 都收到通知**才进入下一阶段（按 task-id 计数已收齐）
 
 ⛔ **禁止**：
-- 调 `TaskOutput({block: true, timeout: 600000})` —— v4.5.1 之前的旧 freeze poll 模式，已废弃
+- 调 `TaskOutput({block: true, timeout: 600000})` —— 旧 freeze poll 模式，已废弃
 - 收到部分通知就跳过等其他模型
 - 主动 Kill task
 
@@ -165,7 +165,7 @@ EOF",
    - 需求：分析前端性能问题（Core Web Vitals）
    - OUTPUT：性能瓶颈列表、优化方案、预期收益
 
-事件驱动等待 (v4.5.2)：spawn 完两个 Bash bg 后主线 turn end，等 task-notification 自动唤醒。**必须等所有模型返回后才能进入下一阶段**。
+事件驱动等待：spawn 完两个 Bash bg 后主线 turn end，等 task-notification 自动唤醒。**必须等所有模型返回后才能进入下一阶段**。
 
 **务必遵循上方 `多模型调用规范` 的 `重要` 指示**
 

package/templates/commands/plan.md

@@ -9,9 +9,9 @@ $ARGUMENTS
 
 ---
 
-## Role-based routing（v4.1 specialist matrix）
+## Role-based routing（specialist matrix）
 
-可选参数 `--role=<name>` 在 v4.0 的 backend/frontend layer 路由之上叠加 **role 维度**，自动选择更精准的 prompt 文件。**未传 `--role` 时按现状路由（{{BACKEND_PRIMARY}}/{{FRONTEND_PRIMARY}}），完全保留 v4.0 行为兼容**——无破坏性变更。
+可选参数 `--role=<name>` 在 backend/frontend layer 路由之上叠加 **role 维度**，自动选择更精准的 prompt 文件。**未传 `--role` 时按现状路由（{{BACKEND_PRIMARY}}/{{FRONTEND_PRIMARY}}），完全保留默认行为兼容**——无破坏性变更。
 
 **Role × Layer 路由矩阵**：
 
@@ -23,11 +23,11 @@ $ARGUMENTS
 
 **判定流程**：
 
-1. **解析 layer**：根据 $ARGUMENTS 涉及文件类型推断 `backend` / `frontend` / `fullstack`（与 v4.0 现有逻辑一致）。
-2. **解析 role**：从 $ARGUMENTS 提取 `--role=<name>`（5 个合法值：`architect` / `critic` / `implementer` / `tester` / `writer`），不存在或非法值 → fallback v4.0 模型路由。
+1. **解析 layer**：根据 $ARGUMENTS 涉及文件类型推断 `backend` / `frontend` / `fullstack`。
+2. **解析 role**：从 $ARGUMENTS 提取 `--role=<name>`（5 个合法值：`architect` / `critic` / `implementer` / `tester` / `writer`），不存在或非法值 → fallback 默认模型路由。
 3. **选 prompt 文件**：按矩阵查 `(role, layer)` 单元格 → ROLE_FILE 路径。
 4. **adversarial 标记**：role=critic 时，prompt 段额外注入 "deliberately hunt for flaws / contradict majority view" 指令，触发敌对审查模式。
-5. **runner 决**：fullstack × {implementer, tester} 时，per-file 选 codex 或 gemini（同 v4.0 phase-runner Type 路由逻辑）。
+5. **runner 决**：fullstack × {implementer, tester} 时，per-file 选 codex 或 gemini（同 phase-runner Type 路由逻辑）。
 
 **示例**：
 
@@ -50,18 +50,18 @@ $ARGUMENTS
 
 ---
 
-## 调用通道路由（v4.1 Phase 20，CCG codeagent 退役）
+## 调用通道路由（CCG codeagent 退役）
 
-CCG v4.1 把 6 核心命令的"双模型并行"通道从 `Bash(codeagent-wrapper)` **默认切换**为 plugin spawn。判定流程：
+CCG 把 6 核心命令的"双模型并行"通道从 `Bash(codeagent-wrapper)` **默认切换**为 plugin spawn。判定流程：
 
 1. **优先 plugin spawn 路径**（默认）：用户已装 `codex@openai-codex` 和 `gemini@google-gemini` plugin → 用 `Agent(subagent_type="codex:codex-rescue")` + `Agent(subagent_type="gemini:gemini-rescue")` 并行 spawn，主线只接 plugin 自家 ≤200 token 摘要协议（`STATUS: ... / FINDINGS: ... / NOTES: ...`）。
-2. **降级 codeagent-wrapper 路径**（v4.0 BC fallback）：plugin 未装 → fallback 到 `Bash(~/.claude/bin/codeagent-wrapper --backend ... resume ... <<'EOF' ... EOF)`，与 v4.0 行为完全一致。
+2. **降级 codeagent-wrapper 路径**（BC fallback）：plugin 未装 → fallback 到 `Bash(~/.claude/bin/codeagent-wrapper --backend ... resume ... <<'EOF' ... EOF)`，与 plugin 路径行为等价。
 
 **判断方法**：preflight 用 `Bash` 跑 `ls ~/.claude/plugins/ 2>/dev/null | grep -E '^codex@'` 与 `... | grep -E '^gemini@'` 各一次。匹配到对应行 → plugin 已装。两个 plugin 独立判定，可分别 mix-and-match（仅 codex plugin 装了 → backend 走 plugin、frontend 走 codeagent）。
 
 **单一真相源**：plugin 检测逻辑 helper 见 `src/utils/plugin-detection.ts`（导出 `detectPlugin` / `detectPluginAvailability` / `bothPluginsInstalled`）。命令模板把判定结果渲染到执行计划，`Agent(...)` 调用与 `Bash(...)` 调用的具体语法见下面"多模型调用规范"段。
 
-**为什么默认 plugin**：v4.0.1 nested-spawn 测试证明 plugin advisor 摘要协议（≤200 token）压制了 codeagent stdout 全文回灌主线的痛点，主线 context 增量从 +5%/调用 降到 +1.5%/调用。详见 `.ccg-research/07-multimodel-collaboration-rethink.md`。
+**为什么默认 plugin**：nested-spawn 测试证明 plugin advisor 摘要协议（≤200 token）压制了 codeagent stdout 全文回灌主线的痛点，主线 context 增量从 +5%/调用 降到 +1.5%/调用。详见 `.ccg-research/07-multimodel-collaboration-rethink.md`。
 
 ⚠️ **重要**：本命令本身不在 subagent context 内（主线命令），**可以**调 `Agent(...)` 工具——这跟 `phase-runner` 等 subagent 的"引擎层禁止嵌套 spawn Agent"约束不冲突。
 
@@ -74,7 +74,7 @@ CCG v4.1 把 6 核心命令的"双模型并行"通道从 `Bash(codeagent-wrapper
 - 如果用户通过 `/add-dir` 添加了多个工作区，先用 Glob/Grep 确定任务相关的工作区
 - 如果无法确定，用 `AskUserQuestion` 询问用户选择目标工作区
 
-**调用语法**（v4.1 Phase 20 双通道）：
+**调用语法**（双通道）：
 
 **通道 A — plugin spawn（默认）**：
 
@@ -115,7 +115,7 @@ EOF",
 })
 ```
 
-> ⚠️ 通道 B 走 `codeagent-wrapper`（Node 脚本 `templates/scripts/invoke-model.mjs`），v4.1 已标 **deprecated**，将在 v5.0 移除。建议用户安装 codex/gemini plugin 享受 v4.1 主线 context 优化。
+> ⚠️ 通道 B 走 `codeagent-wrapper`（Node 脚本 `templates/scripts/invoke-model.mjs`），已标 **deprecated**，建议用户安装 codex/gemini plugin 享受主线 context 优化。
 
 **角色提示词**：
 
@@ -126,7 +126,7 @@ EOF",
 
 **会话复用**：每次调用返回 `SESSION_ID: xxx`（通常由 wrapper 输出），**必须保存**以供后续 `/ccg:execute` 使用。
 
-**事件驱动等待（v4.5.2 起）**：spawn 后主线说明 task-id 然后 **turn end**，引擎自动 `<task-notification>` 触发新 turn 处理结果。**不调 TaskOutput**。
+**事件驱动等待**：spawn 后主线说明 task-id 然后 **turn end**，引擎自动 `<task-notification>` 触发新 turn 处理结果。**不调 TaskOutput**。
 
 ⛔ **禁止**：调 `TaskOutput({block: true, timeout: 600000})` 旧 freeze poll 模式 / Kill task。
 
@@ -192,7 +192,7 @@ EOF",
    - 关注：UI/UX 影响、用户体验、视觉设计
    - OUTPUT: 多角度解决方案 + 优劣势分析
 
-事件驱动等待 (v4.5.2)：spawn 完两个 Bash bg 后主线 turn end，等 task-notification 自动唤醒。**📌 保存 SESSION_ID**（`CODEX_SESSION` 和 `GEMINI_SESSION`）。
+事件驱动等待：spawn 完两个 Bash bg 后主线 turn end，等 task-notification 自动唤醒。**📌 保存 SESSION_ID**（`CODEX_SESSION` 和 `GEMINI_SESSION`）。
 
 #### 2.2 交叉验证
 
@@ -251,7 +251,7 @@ EOF",
 - GEMINI_SESSION: <session_id>
 ```
 
-### 🛡 Phase 2.5：自动 plan-checker 校验（5 维度 + max-3-loop，CCG v4.0 Phase 6）
+### 🛡 Phase 2.5：自动 plan-checker 校验（5 维度 + max-3-loop）
 
 写出 `.claude/plan/<功能名>.md` 后、向用户交付前，**必须**自动 spawn `plan-checker` agent 做 5 维度强校验：
 
@@ -289,7 +289,7 @@ if loop_count == 3 and result.hasBlocker:
 
 1. 向用户展示完整实施计划（含伪代码）+ plan-checker 报告摘要（BLOCKER/WARNING 数量 + verdict）
 2. 将计划保存至 `.claude/plan/<功能名>.md`（功能名从需求中提取，如 `user-auth`、`payment-module` 等）
-3. **写 phase-scoped CONTEXT.md**（v4.0 Phase 2 状态机）：把本次 plan 的冻结决策固化到 `.context/<phase>/CONTEXT.md`，下游 `/ccg:execute` 与 `/ccg:team-exec` 仅读此文件的 YAML frontmatter 即可获得全部决策（< 200 tokens / phase）。**目录约定**：`<phase>` 取计划文件主名（如 `user-auth`），用 `sanitizePhase()` 规范化非法字符。
+3. **写 phase-scoped CONTEXT.md**（状态机）：把本次 plan 的冻结决策固化到 `.context/<phase>/CONTEXT.md`，下游 `/ccg:execute` 与 `/ccg:team-exec` 仅读此文件的 YAML frontmatter 即可获得全部决策（< 200 tokens / phase）。**目录约定**：`<phase>` 取计划文件主名（如 `user-auth`），用 `sanitizePhase()` 规范化非法字符。
 
    **CONTEXT.md 必含 frontmatter 字段（机器可读契约）**：
    ```yaml

package/templates/commands/result.md

@@ -1,5 +1,5 @@
 ---
-description: '取后台任务最终结果：读取 .context/jobs/<id>/result.md，输出 ≤ 200 token 摘要（v4.0 异步三件套）'
+description: '取后台任务最终结果：读取 .context/jobs/<id>/result.md，输出 ≤ 200 token 摘要'
 argument-hint: "<job-id>"
 allowed-tools:
   - Read

package/templates/commands/review.md

@@ -5,7 +5,7 @@ argument-hint: "[代码或描述] [--adversarial] [--fix [--all] [--auto]] [--ro
 
 # Review - 多模型代码审查
 
-## Role-based routing（v4.1 specialist matrix）
+## Role-based routing（specialist matrix）
 
 可选 `--role=<name>` 叠加 role 维度路由：
 
@@ -15,13 +15,13 @@ argument-hint: "[代码或描述] [--adversarial] [--fix [--all] [--auto]] [--ro
 | **frontend**  | gemini/architect.md | gemini/reviewer.md (adversarial) | gemini/architect.md | gemini/tester.md | gemini/analyzer.md |
 | **fullstack** | codex+gemini/architect.md | both reviewer.md (adversarial) | runner 决 | runner 决 | claude |
 
-**未传 --role 时按 v4.0 双模型路由（{{BACKEND_PRIMARY}}/{{FRONTEND_PRIMARY}} reviewer.md）**——完全兼容现有 `--adversarial` / `--fix` 行为。`--role=critic` 等价于隐式 `--adversarial`（语义同义）。详见 `src/utils/specialist-router.ts`。
+**未传 --role 时按双模型路由（{{BACKEND_PRIMARY}}/{{FRONTEND_PRIMARY}} reviewer.md）**——完全兼容现有 `--adversarial` / `--fix` 行为。`--role=critic` 等价于隐式 `--adversarial`（语义同义）。详见 `src/utils/specialist-router.ts`。
 
 ---
 
 双模型并行审查，交叉验证综合反馈。无参数时自动审查当前 git 变更。
 
-**v4.1 Phase 20**：双模型并行通道从 `Bash(codeagent-wrapper)` **默认切换**为 plugin spawn —— 装了 `codex@openai-codex` + `gemini@google-gemini` plugin → 用 `Agent(subagent_type="codex:codex-rescue")` + `Agent(subagent_type="gemini:gemini-rescue")` 并行，主线只接 ≤200 token 摘要；plugin 未装 → fallback 到 codeagent-wrapper 路径（v4.0 BC，将在 v5.0 移除）。preflight 用 `Bash` 跑 `ls ~/.claude/plugins/` 检测，helper 见 `src/utils/plugin-detection.ts`。
+**双模型并行通道**：默认走 plugin spawn —— 装了 `codex@openai-codex` + `gemini@google-gemini` plugin → 用 `Agent(subagent_type="codex:codex-rescue")` + `Agent(subagent_type="gemini:gemini-rescue")` 并行，主线只接 ≤200 token 摘要；plugin 未装 → fallback 到 codeagent-wrapper 路径（BC fallback）。preflight 用 `Bash` 跑 `ls ~/.claude/plugins/` 检测，helper 见 `src/utils/plugin-detection.ts`。
 
 `--adversarial` 模式下额外触发第三层"敌对视角"审查，由官方 codex plugin 的 `Agent(codex:codex-rescue)` 在 fresh context 中专门挑前两轮意见的漏洞，适合极重要 PR / 安全敏感变更。需用户已装 `codex@openai-codex` plugin，否则降级为双模型审查。
 
@@ -49,36 +49,45 @@ argument-hint: "[代码或描述] [--adversarial] [--fix [--all] [--auto]] [--ro
 - 如果用户通过 `/add-dir` 添加了多个工作区，先用 Glob/Grep 确定任务相关的工作区
 - 如果无法确定，用 `AskUserQuestion` 询问用户选择目标工作区
 
-**调用语法**（v4.4.2 起 review/verify 路径默认走 Bash 直调）：
+**调用语法**（review/verify 路径默认走 Bash 直调）：
 
 **通道 A — Bash 直调 plugin script（默认，绕开 sonnet wrapper）**：
 
-> 1.0.4 起 Bash 命令字符串由 install 时直接渲染（基于 `~/.claude/plugins/installed_plugins.json`
-> 真值源），LLM 只需 copy 整段 + 替换 `%PROMPT%` 即可。**禁止凭印象拼 `node "$(ls ...) | head -1"
-> task -p ...` inline 命令** —— glob hack 在 plugin 多版本 cache 下行为不可预测，且参数漂移
-> 与 v4.4.1 的 195 处错名 bug 同型。
+> 占位符 `{{CODEX_BASH_TASK}}` / `{{GEMINI_BASH_TASK}}` 由 install 时渲染为
+> `node <ccgx-call-plugin.mjs 绝对路径> <vendor> --json`。LLM **只需把 prompt
+> 写入 tmpfile、追加 `--prompt-file <tmpfile>`、运行**。helper 内部处理路径解析、
+> spawn array args、shell escape 全部规避——LLM 不参与任何命令构造。
 
-```
-# 后端审查（codex 视角）
-Bash({
-  command: `{{CODEX_BASH_TASK}}`,   ← install 时已渲染为完整命令，含 heredoc 安全 prompt 注入
-  description: "Review: backend (codex direct)",
-  run_in_background: true,
-  timeout: 3600000
-})
+**LLM 工作流（严格 3 步）**：
 
-# 前端审查（gemini 视角）
-Bash({
-  command: `{{GEMINI_BASH_TASK}}`,
-  description: "Review: frontend (gemini direct)",
-  run_in_background: true,
-  timeout: 3600000
-})
+```
+Step 1. 用 Write 工具把完整 prompt 写到 tmpfile
+   Write({ file_path: "/tmp/ccg-review-codex-$JOB.txt", content: "<完整 prompt>" })
+   Write({ file_path: "/tmp/ccg-review-gemini-$JOB.txt", content: "<完整 prompt>" })
+
+Step 2. 用 Bash 调 helper（占位符已渲染）：
+   Bash({
+     command: `{{CODEX_BASH_TASK}} --prompt-file /tmp/ccg-review-codex-$JOB.txt`,
+     description: "Review: backend (codex direct)",
+     run_in_background: true,
+     timeout: 3600000
+   })
+   Bash({
+     command: `{{GEMINI_BASH_TASK}} --prompt-file /tmp/ccg-review-gemini-$JOB.txt`,
+     description: "Review: frontend (gemini direct)",
+     run_in_background: true,
+     timeout: 3600000
+   })
+
+Step 3. 等 task-notification 通知后 Read 各自 stdout（即 helper 输出的 JSON），parse
+   `result.stdout` 拿真实 plugin 输出，再按 plugin --json schema 解析。
 ```
 
-LLM 消费协议：把上面命令字符串里的 `%PROMPT%` 替换为完整 prompt 文本（含 ROLE_FILE 引用 +
-TASK 描述 + OUTPUT 要求），**不要在外面加任何 escape**——heredoc `<<'CCG_PROMPT_EOF'`
-的单引号 delimiter 已保证 `$` / `'` / `"` / `\` 全部按字面量处理。
+⛔ **严禁** 任何形式自拼命令：
+- 不要写 `node "$(ls ...)/codex-companion.mjs"`
+- 不要 `cat <<EOF`、不要 heredoc、不要 `-p "..."` 内联 prompt
+- 不要硬编码 plugin 路径——helper 内部解析 SSoT
+- **唯一允许**：copy 占位符内容 + 追加 `--prompt-file <tmpfile>`
 
 ⛔ **不要**用 `Agent(subagent_type="codex:codex-rescue"|"gemini:gemini-rescue")`：
 
@@ -114,7 +123,7 @@ EOF",
 })
 ```
 
-> ⚠️ 通道 B `codeagent-wrapper` 在 v4.1 已标 **deprecated**，将在 v5.0 移除。
+> ⚠️ 通道 B `codeagent-wrapper` 已标 **deprecated**。
 
 **角色提示词**：
 
@@ -123,7 +132,7 @@ EOF",
 | 后端 | `~/.claude/.ccg/prompts/{{BACKEND_PRIMARY}}/reviewer.md` |
 | 前端 | `~/.claude/.ccg/prompts/{{FRONTEND_PRIMARY}}/reviewer.md` |
 
-**并行调用 + 事件驱动等待（v4.5.2 起）**：
+**并行调用 + 事件驱动等待**：
 
 1. 在同一 message 内 spawn 两个（或多个）`Bash(run_in_background: true)` 并行任务
 2. spawn 完成后主线说明已启动哪些 task（含 task-id），然后**直接 turn end**，**不调 TaskOutput**
@@ -135,7 +144,7 @@ EOF",
 5. **必须等所有相关 task 都收到通知**才进入下一阶段（主线按 task-id 计数已收齐）
 
 ⛔ **禁止做**：
-- 调 `TaskOutput({block: true, timeout: 600000})` —— 这会 freeze 主线 10 分钟，且超时后还要轮询，体验极差（v4.5.1 之前的旧模式，已废弃）
+- 调 `TaskOutput({block: true, timeout: 600000})` —— 这会 freeze 主线 10 分钟，且超时后还要轮询，体验极差（旧模式，已废弃）
 - 收到部分通知就跳过等其他模型
 - 主动 Kill task
 
@@ -187,15 +196,19 @@ EOF",
 调用方式（Bash 直调，绕开 sonnet wrapper）：
 
 ```
-Bash({
-  command: `{{CODEX_BASH_TASK}}`,   ← 同上，install 时渲染为完整命令
-  description: "Adversarial review (codex direct)",
-  run_in_background: true,
-  timeout: 3600000
-})
+Step 1. 用 Write 把以下 adversarial prompt 写入 tmpfile:
+   Write({ file_path: "/tmp/ccg-review-adv-$JOB.txt", content: <见下方 prompt body> })
+
+Step 2. 调 helper:
+   Bash({
+     command: `{{CODEX_BASH_TASK}} --prompt-file /tmp/ccg-review-adv-$JOB.txt`,
+     description: "Adversarial review (codex direct)",
+     run_in_background: true,
+     timeout: 3600000
+   })
 ```
 
-把命令里的 `%PROMPT%` 替换为以下完整 prompt 文本（heredoc 已保证字面量传递，不需要 escape）：
+**Adversarial prompt body**（写入 tmpfile 的内容）：
 
 ```
 --adversarial-review

package/templates/commands/spec-impl.md

@@ -100,7 +100,7 @@ description: '按规范执行 + 多模型协作 + 归档'
    })
    ```
 
-   **Step 7.2 (v4.5.2 事件驱动)**: spawn 两个 Bash bg 后说明 task-id 然后 **turn end**。引擎在每个 task 完成时自动发 `<task-notification>`，主线在通知触发的新 turn 处理结果。**不调 TaskOutput**。两个 task 都收到通知后才进 step 7.3。
+   **Step 7.2 (事件驱动)**: spawn 两个 Bash bg 后说明 task-id 然后 **turn end**。引擎在每个 task 完成时自动发 `<task-notification>`，主线在通知触发的新 turn 处理结果。**不调 TaskOutput**。两个 task 都收到通知后才进 step 7.3。
 
    ⛔ **禁止**：调 `TaskOutput({block: true, timeout: 600000})` (旧 freeze poll 模式) / Kill task。
    ⚠️ **失败处理**：notification status=failed / exit ≠ 0 / parse 失败 → v1.7.87 标准 2-retry / 5s / 3-attempts；3 次全失败才降级单模型。

package/templates/commands/spec-plan.md

@@ -50,7 +50,7 @@ description: '多模型分析 → 消除歧义 → 零决策可执行计划'
    })
    ```
 
-   **Step 2.2 (v4.5.2 事件驱动)**: spawn 两个 Bash bg 后说明 task-id 然后 **turn end**。引擎在每个 task 完成时自动发 `<task-notification>`，主线在通知触发的新 turn 处理结果。**不调 TaskOutput**。两个 task 都收到通知后才进 step 2.3。
+   **Step 2.2 (事件驱动)**: spawn 两个 Bash bg 后说明 task-id 然后 **turn end**。引擎在每个 task 完成时自动发 `<task-notification>`，主线在通知触发的新 turn 处理结果。**不调 TaskOutput**。两个 task 都收到通知后才进 step 2.3。
 
    ⛔ **禁止**：调 `TaskOutput({block: true, timeout: 600000})` (旧 freeze poll 模式) / Kill task。
    ⚠️ **失败处理**：notification status=failed / exit ≠ 0 / parse 失败 → v1.7.87 标准 2-retry / 5s / 3-attempts；3 次全失败才降级单模型。
@@ -158,7 +158,7 @@ description: '多模型分析 → 消除歧义 → 零决策可执行计划'
      "Plan phase complete. Artifacts generated: specs.md, design.md, tasks.md. Run `/ccg:spec-impl` to start implementation."
      Do NOT proceed to modify source code.
 
-5.5. **自动 plan-checker 校验（5 维度 + max-3-loop，CCG v4.0 Phase 6）**
+5.5. **自动 plan-checker 校验（5 维度 + max-3-loop）**
 
    生成 OPSX artifacts 后，**必须**自动 spawn `plan-checker` agent 对 specs.md / design.md / tasks.md 做 5 维度校验：
 

package/templates/commands/spec-research.md

@@ -89,7 +89,7 @@ description: '需求 → 约束集（并行探索 + OPSX 提案）'
    })
    ```
 
-   **Step 4.2 (v4.5.2 事件驱动)**: spawn 两个 Bash bg 后说明 task-id 然后 **turn end**。引擎在每个 task 完成时自动发 `<task-notification>`，主线在通知触发的新 turn 处理结果。**不调 TaskOutput**。两个 task 都收到通知后才进 step 4.3。
+   **Step 4.2 (事件驱动)**: spawn 两个 Bash bg 后说明 task-id 然后 **turn end**。引擎在每个 task 完成时自动发 `<task-notification>`，主线在通知触发的新 turn 处理结果。**不调 TaskOutput**。两个 task 都收到通知后才进 step 4.3。
 
    ⛔ **禁止**：调 `TaskOutput({block: true, timeout: 600000})` (旧 freeze poll 模式) / Kill task。
    ⚠️ **失败处理**：notification status=failed / exit ≠ 0 / parse 失败 → v1.7.87 标准 2-retry / 5s / 3-attempts；3 次全失败才降级单模型。

package/templates/commands/spec-review.md

@@ -51,7 +51,7 @@ description: '双模型交叉审查（独立工具，随时可用）'
    })
    ```
 
-   **Step 3.2 (v4.5.2 事件驱动)**: spawn 两个 Bash bg 后说明 task-id 然后 **turn end**。引擎在每个 task 完成时自动发 `<task-notification>`，主线在通知触发的新 turn 处理结果。**不调 TaskOutput**。两个 task 都收到通知后才进 step 3.3。
+   **Step 3.2 (事件驱动)**: spawn 两个 Bash bg 后说明 task-id 然后 **turn end**。引擎在每个 task 完成时自动发 `<task-notification>`，主线在通知触发的新 turn 处理结果。**不调 TaskOutput**。两个 task 都收到通知后才进 step 3.3。
 
    ⛔ **禁止**：调 `TaskOutput({block: true, timeout: 600000})` (旧 freeze poll 模式) / Kill task。
    ⚠️ **失败处理**：notification status=failed / exit ≠ 0 / parse 失败 → v1.7.87 标准 2-retry / 5s / 3-attempts；3 次全失败才降级单模型。

package/templates/commands/status.md

@@ -1,5 +1,5 @@
 ---
-description: '后台任务观测：列表 / 单查 / 阻塞等待 / dashboard / tail 流式 / 卡点检测 / 单 phase cancel（v4.5 P7 升级）'
+description: '后台任务观测：列表 / 单查 / 阻塞等待 / dashboard / tail 流式 / 卡点检测 / 单 phase cancel'
 argument-hint: "[<job-id>] [--wait --timeout-ms <ms>] [--tail <job-id>] [--cancel <phase-id>]"
 allowed-tools:
   - Read
@@ -7,9 +7,9 @@ allowed-tools:
   - Glob
 ---
 
-# Status — 后台任务观测（v4.5 dashboard + tail）
+# Status — 后台任务观测（dashboard + tail）
 
-CCG v4.5 起 phase-runner 走 Bash subprocess（`claude -p --output-format stream-json ...`），stream 落盘到 `<workdir>/.context/jobs/<job-id>/progress.jsonl`。失去 sidechain inline UI 后，本命令是用户**唯一**的微观干预入口，必须复刻这四个长跑场景：
+phase-runner 走 Bash subprocess（`claude -p --output-format stream-json ...`），stream 落盘到 `<workdir>/.context/jobs/<job-id>/progress.jsonl`。失去 sidechain inline UI 后，本命令是用户**唯一**的微观干预入口，必须复刻这四个长跑场景：
 
 | 场景 | 模式 |
 |------|------|
@@ -33,8 +33,8 @@ CCG v4.5 起 phase-runner 走 Bash subprocess（`claude -p --output-format strea
 /ccg:status                                  # 模式 A：列表 / dashboard
 /ccg:status <job-id>                         # 模式 B：单查详情
 /ccg:status <job-id> --wait --timeout-ms <ms>  # 模式 C：阻塞等待
-/ccg:status --tail <job-id>                  # 模式 D：流式 tail（v4.5 新增）
-/ccg:status --cancel <phase-id>              # 模式 E：单 phase 协作 cancel（v4.5 新增）
+/ccg:status --tail <job-id>                  # 模式 D：流式 tail
+/ccg:status --cancel <phase-id>              # 模式 E：单 phase 协作 cancel
 ```
 
 ## 模式 A：Dashboard（无参数）
@@ -77,7 +77,7 @@ Phase 7 (Status v2) [============>       ]  60%  (12m 04s) 🛠️  edit_file
 4. 超时 → "⏱ Timeout after <X>s — job still in <status>，retry with longer --timeout-ms 或 /ccg:cancel <id>"
 5. 超时退出码 0（不视为失败）
 
-## 模式 D：Tail 流式（v4.5 新增）
+## 模式 D：Tail 流式
 
 `/ccg:status --tail <job-id>` 持续读 `progress.jsonl`，单行覆写：
 
@@ -130,7 +130,7 @@ done
 
 每次 tail 前调 `detectStuck` 注入 banner（loop / slow-tool / stalled 三类警告）。
 
-## 模式 E：单 phase 协作 cancel（v4.5 新增）
+## 模式 E：单 phase 协作 cancel
 
 `/ccg:status --cancel <phase-id>` 流程：
 
@@ -138,7 +138,7 @@ done
 2. 写 `.context/jobs/<job-id>/cancel.flag` —— 内容 `phase=<phase-id>\nrequested-at=<iso>`
 3. 翻 `state.cancel_requested=true`
 4. **5 秒 grace 等待** —— 给 phase-runner 子进程读 cancel.flag 优雅退出
-5. 5s 后子进程仍 running → 调用 `killProcessTree({ pid: state.cli_pid, pgid: state.process_group_id, graceMs: 5000 })`（来自 `src/utils/process-tree.ts`，v4.5 P1b 已落地，P1f wired）
+5. 5s 后子进程仍 running → 调用 `killProcessTree({ pid: state.cli_pid, pgid: state.process_group_id, graceMs: 5000 })`（来自 `src/utils/process-tree.ts`）
 6. 输出最终结果：`canceled gracefully` / `force-killed pid=N` / `not found`
 
 **实施样板**（主线 LLM 用 Bash + node -e 调用 helper）：
@@ -187,20 +187,20 @@ const { renderJsonl, progressBar, formatElapsed } = require('~/.claude/.ccg/dist
 // 卡点检测
 const { detectStuck, hasStuckWarning } = require('~/.claude/.ccg/dist/index.mjs')
 
-// 已有 v4.0 helper
+// job helper
 const { listJobs, getJob, requestCancel } = require('~/.claude/.ccg/dist/index.mjs')
 ```
 
 源码真相：
 - `src/utils/jobs.ts` — `listJobs / getJob / requestCancel`
-- `src/utils/stream-renderer.ts`（v4.5 P7） — `renderJsonl / renderEvent / progressBar / formatElapsed`
-- `src/utils/stuck-detector.ts`（v4.5 P7） — `detectStuck / hasStuckWarning`
-- `src/utils/process-tree.ts`（v4.5 P1b 落地 + P1f wired） — `killProcessTree / sampleProcessRssMb / writeDegradedFlag / readDegradedFlag / reconcileStaleJobs`
+- `src/utils/stream-renderer.ts` — `renderJsonl / renderEvent / progressBar / formatElapsed`
+- `src/utils/stuck-detector.ts` — `detectStuck / hasStuckWarning`
+- `src/utils/process-tree.ts` — `killProcessTree / sampleProcessRssMb / writeDegradedFlag / readDegradedFlag / reconcileStaleJobs`
 
-v4.x 暂未把 `dist/` 暴露给命令模板，主线 LLM 走 Bash + Read 等价行为：
+`dist/` 未暴露给命令模板时，主线 LLM 走 Bash + Read 等价行为：
 
 - dashboard：调 `node -e` 读各 state.json + 简单进度推断 + `=`/`>`/空格手动拼字符串
 - tail：调 `node -e` 解析 ndjson + 走 `renderEvent` 等价 switch（TS helper 是真相源）
-- cancel：直接 `echo > cancel.flag` + sleep 5 + 调 process-tree（Phase 2 ready 后）
+- cancel：直接 `echo > cancel.flag` + sleep 5 + 调 process-tree
 
-升级路径见 `.ccg-migration/v4.4-to-v4.5.md` § "/ccg:status v2 升级"。
+历史升级记录见 `.ccg-migration/INTERNAL-DEV-LOG.md`。

package/templates/commands/team-exec.md

@@ -167,7 +167,7 @@ subagent_freshness: required
 
 用 `AskUserQuestion` 让用户选择。**重试**最多再走一轮 wave 调度，第二次仍失败则强制选 2/3。
 
-### Step 5.5: Frontmatter-only Summary 读取（v4.0 Phase 2 状态机）
+### Step 5.5: Frontmatter-only Summary 读取（状态机契约）
 
 **核心契约**：Lead 不接 Builder 的全部 stdout。每个 Builder 完成任务后，**必须由 Lead 读取该任务对应的 `.context/<phase>/SUMMARY.md` 的 YAML frontmatter**——不读 body，不读 builder transcript。
 

package/templates/commands/team.md

@@ -3,16 +3,16 @@ description: 'Agent Teams 8 阶段企业级工作流 - 7 角色全流程统一
 ---
 <!-- CCG:TEAM:UNIFIED:START -->
 
-## 子命令路由（v4.1-p18）
+## 子命令路由
 
 `/ccg:team` 同时承载子命令调度。根据 `$ARGUMENTS` 第一个 token 路由到具体阶段：
 
 | 子命令 | 含义 | 替代旧命令 |
 |--------|------|----------|
 | `/ccg:team` (无参 / 任意非保留字)        | 8 阶段全流程         | （主流程） |
-| `/ccg:team research <需求>`              | 仅跑需求研究阶段       | `/ccg:team-research`（v4.1 删除） |
-| `/ccg:team plan <约束文件>`              | 仅跑规划阶段          | `/ccg:team-plan`（v4.1 删除） |
-| `/ccg:team review [git-range]`           | 仅跑双模型审查阶段     | `/ccg:team-review`（v4.1 删除） |
+| `/ccg:team research <需求>`              | 仅跑需求研究阶段       | `/ccg:team-research`（已删除） |
+| `/ccg:team plan <约束文件>`              | 仅跑规划阶段          | `/ccg:team-plan`（已删除） |
+| `/ccg:team review [git-range]`           | 仅跑双模型审查阶段     | `/ccg:team-review`（已删除） |
 | `/ccg:team exec <plan-file>`             | 仅跑并行实施阶段       | 等价 `/ccg:team-exec` |
 
 > **路由规则**：将 `$ARGUMENTS` 拆分为 `[subcmd, ...rest]`。若 `subcmd ∈ {research, plan, review, exec}`，跳到对应 Phase（Research → Phase 1 / plan → Phase 3 / review → Phase 6 / exec → Phase 4）；否则走完整 Phase 0-8。
@@ -178,7 +178,7 @@ Phase 8: INTEGRATION   → Lead 全量验证 + 报告 + 清理
    })
    ```
 
-   **事件驱动等待 (v4.5.2)**：spawn 两个 Bash bg 后说明 task-id 然后 **turn end**。引擎在每个 task 完成时自动发 `<task-notification>`，主线在通知触发的新 turn 处理结果。**不调 TaskOutput**。两个 task 都收到通知后才进下一步。
+   **事件驱动等待**：spawn 两个 Bash bg 后说明 task-id 然后 **turn end**。引擎在每个 task 完成时自动发 `<task-notification>`，主线在通知触发的新 turn 处理结果。**不调 TaskOutput**。两个 task 都收到通知后才进下一步。
 
    ⛔ **禁止**：调 `TaskOutput({block: true, timeout: 600000})` (旧 freeze poll 模式) / Kill task。
    ⚠️ **失败处理**：notification status=failed / exit ≠ 0 / parse 失败 → v1.7.87 标准 2-retry / 5s / 3-attempts；3 次全失败才降级单模型。
@@ -330,7 +330,7 @@ Phase 8: INTEGRATION   → Lead 全量验证 + 报告 + 清理
    })
    ```
 
-   **事件驱动等待 (v4.5.2)**：spawn 两个 Bash bg 后说明 task-id 然后 **turn end**。引擎在每个 task 完成时自动发 `<task-notification>`，主线在通知触发的新 turn 处理。**不调 TaskOutput**。两个 task 都收到通知才进 step 3。
+   **事件驱动等待**：spawn 两个 Bash bg 后说明 task-id 然后 **turn end**。引擎在每个 task 完成时自动发 `<task-notification>`，主线在通知触发的新 turn 处理。**不调 TaskOutput**。两个 task 都收到通知才进 step 3。
 
    ⛔ **禁止**：调 `TaskOutput({block: true, timeout: 600000})` (旧 freeze poll 模式) / Kill task。
    ⚠️ **失败处理**：notification status=failed / exit ≠ 0 / parse 失败 → v1.7.87 标准 2-retry / 5s / 3-attempts；3 次全失败才降级单模型。

package/templates/commands/test.md

@@ -13,7 +13,7 @@ argument-hint: "<测试目标> [--role=architect|critic|implementer|tester|write
 /test <测试目标> [--role=<name>]
 ```
 
-## Role-based routing（v4.1 specialist matrix）
+## Role-based routing（specialist matrix）
 
 可选 `--role=<name>` 叠加 role 维度路由（默认 `tester`，可显式覆盖）：
 
@@ -23,7 +23,7 @@ argument-hint: "<测试目标> [--role=architect|critic|implementer|tester|write
 | **frontend**  | gemini/architect.md | gemini/reviewer.md (adversarial) | gemini/architect.md | gemini/tester.md | gemini/analyzer.md |
 | **fullstack** | codex+gemini/architect.md | both reviewer.md (adversarial) | runner 决（per-file） | runner 决（per-file） | claude |
 
-**未传 --role 时按 v4.0 智能路由（后端 → {{BACKEND_PRIMARY}}/tester.md，前端 → {{FRONTEND_PRIMARY}}/tester.md，全栈并行），完全兼容**。`--role=critic` 触发"测试用例反例挖掘"——专门构造打破现有测试假设的边界条件。详见 `src/utils/specialist-router.ts`。
+**未传 --role 时按智能路由（后端 → {{BACKEND_PRIMARY}}/tester.md，前端 → {{FRONTEND_PRIMARY}}/tester.md，全栈并行），完全兼容**。`--role=critic` 触发"测试用例反例挖掘"——专门构造打破现有测试假设的边界条件。详见 `src/utils/specialist-router.ts`。
 
 ## 上下文
 
@@ -40,12 +40,12 @@ argument-hint: "<测试目标> [--role=architect|critic|implementer|tester|write
 
 ---
 
-## 调用通道路由（v4.1 Phase 20，CCG codeagent 退役）
+## 调用通道路由（CCG codeagent 退役）
 
-CCG v4.1 把双模型并行通道从 `Bash(codeagent-wrapper)` **默认切换**为 plugin spawn：
+CCG 把双模型并行通道从 `Bash(codeagent-wrapper)` **默认切换**为 plugin spawn：
 
 1. **优先 plugin spawn**（默认）：装了 `codex@openai-codex` + `gemini@google-gemini` plugin → 用 `Agent(subagent_type="codex:codex-rescue")` + `Agent(subagent_type="gemini:gemini-rescue")` 并行，主线接 ≤200 token 摘要。
-2. **降级 codeagent-wrapper**（v4.0 BC fallback）：plugin 未装 → fallback 到 Bash 调用，行为与 v4.0 完全一致。
+2. **降级 codeagent-wrapper**（BC fallback）：plugin 未装 → fallback 到 Bash 调用，行为与 plugin 路径等价。
 
 **判定**：preflight `Bash` 跑 `ls ~/.claude/plugins/` 看有无 `codex@*` / `gemini@*` 子目录。helper 见 `src/utils/plugin-detection.ts`。
 
@@ -60,7 +60,7 @@ CCG v4.1 把双模型并行通道从 `Bash(codeagent-wrapper)` **默认切换**
 - 如果用户通过 `/add-dir` 添加了多个工作区，先用 Glob/Grep 确定任务相关的工作区
 - 如果无法确定，用 `AskUserQuestion` 询问用户选择目标工作区
 
-**调用语法**（v4.1 Phase 20 双通道）：
+**调用语法**（双通道）：
 
 **通道 A — plugin spawn（默认）**：
 
@@ -109,7 +109,7 @@ EOF",
 })
 ```
 
-> ⚠️ 通道 B `codeagent-wrapper` 在 v4.1 已标 **deprecated**，将在 v5.0 移除。
+> ⚠️ 通道 B `codeagent-wrapper` 已标 **deprecated**。
 
 **角色提示词**：
 
@@ -126,7 +126,7 @@ EOF",
 | 前端 | {{FRONTEND_PRIMARY}} |
 | 全栈 | 并行执行两者 |
 
-**并行调用 + 事件驱动等待（v4.5.2 起）**：
+**并行调用 + 事件驱动等待**：
 
 1. 同 message 内 spawn 多个 `Bash(run_in_background: true)` 并行任务
 2. spawn 完后主线说明已启动 task-id，**直接 turn end**，**不调 TaskOutput**
@@ -135,7 +135,7 @@ EOF",
 5. **必须等所有相关 task 都收到通知**才进入下一阶段（按 task-id 计数已收齐）
 
 ⛔ **禁止**：
-- 调 `TaskOutput({block: true, timeout: 600000})` —— v4.5.1 之前的旧 freeze poll 模式，已废弃
+- 调 `TaskOutput({block: true, timeout: 600000})` —— 旧 freeze poll 模式，已废弃
 - 收到部分通知就跳过等其他模型
 - 主动 Kill task