ccgx-workflow 1.0.3 → 1.0.5

package/templates/commands/debate.md

@@ -67,7 +67,7 @@ argument-hint: "<topic> [--max-rounds N] [--layer backend|frontend|fullstack]"
    - **降级路径**（`models[idx] === 'general-purpose'`）：spawn `Agent(subagent_type="general-purpose", prompt=<内嵌 round.ccgPromptFiles[idx] 文件全文> + <下面的 prompt 模板>)`
 3. ⛔ **plugin spawn 失败必须重试**：若 `Agent(subagent_type="codex:codex-rescue"|"gemini:gemini-rescue")` 调用失败（spawn 抛错 / 返回非结构化错误 / `parseRoundSummary` 返回 `parsed=false`），最多重试 **2 次**（间隔 **5 秒**）。仅当 **3 次全部失败**时才把该模型本轮替换为 general-purpose 降级路径，并在合成的 `RoundSummary.notes` 标 `plugin spawn failed after 3 attempts, degraded: <具体根因>`。⛔ **禁止**单次失败或单次 broker 负信号即降级——broker 懒启动属正常态。
 
-   **v4.4.3 schema 硬约束**：标记格式必须是 `plugin spawn failed after N attempts, degraded: <reason>` 三段式（N 必须 ≥ 3，reason 必须给具体根因如 `broker timeout` / `API quota` / `parse-failed`，禁用占位文本如 `unknown` / `n/a`）。`parseRoundSummary` 自动从 NOTES 抽取 populate `RoundSummary.degraded`，Step 2 综合阶段会调 `validateRetryProtocol(累积 RoundSummary[])` 校验合规——违规会出现在最终输出的 ⚠️ 协议违规区段（用户可见）。这是把"3 次重试 + degraded 标记"从 prompt 软约束硬化为 schema-level 校验。
+   **schema 硬约束**：标记格式必须是 `plugin spawn failed after N attempts, degraded: <reason>` 三段式（N 必须 ≥ 3，reason 必须给具体根因如 `broker timeout` / `API quota` / `parse-failed`，禁用占位文本如 `unknown` / `n/a`）。`parseRoundSummary` 自动从 NOTES 抽取 populate `RoundSummary.degraded`，Step 2 综合阶段会调 `validateRetryProtocol(累积 RoundSummary[])` 校验合规——违规会出现在最终输出的 ⚠️ 协议违规区段（用户可见）。这是把"3 次重试 + degraded 标记"从 prompt 软约束硬化为 schema-level 校验。
 4. **等待所有 model 返回**（`run_in_background: true` + 事件驱动等通知（不调 TaskOutput））
 5. 对每个返回的 ≤200 token 摘要调用 `parseRoundSummary(text)` → `RoundSummary`
 6. 把本轮的 `RoundSummary[]`（fullstack 为 2 条；backend/frontend 为 1 条）合成一条主 `RoundSummary`（取最长 length，合并 propose/challenge/respond/notes 字段）追加到累积数组
@@ -80,10 +80,10 @@ argument-hint: "<topic> [--max-rounds N] [--layer backend|frontend|fullstack]"
 - **分歧点列表**（所有 challenge 内容去重 + 简化）
 - **各方观点摘要表**（每轮 model × kind × 一行核心观点）
 - **收敛理由**（哪个信号触发了停止：`no critical` / `max rounds` / `length-converged`）
-- ⚠️ **协议违规区段**（**v4.4.3 强制**）：在输出最终 markdown 前调用 `validateRetryProtocol(累积 RoundSummary[])` → `RetryProtocolReport`：
+- ⚠️ **协议违规区段**（**强制**）：在输出最终 markdown 前调用 `validateRetryProtocol(累积 RoundSummary[])` → `RetryProtocolReport`：
   - `report.compliant === false` → 主线 **必须** 在最终输出加一段 `## ⚠️ Retry Protocol Violations`，逐条列 `report.violations[]`（含 `round` / `kind` / `message`）
   - 4 类违规枚举：`parse-failed-no-degraded` / `insufficient-attempts` / `missing-reason` / `silent-success`
-  - 设计动机：原 prompt 软约束 "3 次重试 + degraded 标记" 实测会被主线 LLM 跳过（v4.4.2 dogfood 真实案例：主线 R1 一次 fallback 就接受未重试也未标 degraded）。schema 硬校验让违规可观测、可枚举，避免 silent fallback 在 debate 综合阶段被吞
+  - 设计动机：原 prompt 软约束 "3 次重试 + degraded 标记" 实测会被主线 LLM 跳过（真实案例：主线 R1 一次 fallback 就接受未重试也未标 degraded）。schema 硬校验让违规可观测、可枚举，避免 silent fallback 在 debate 综合阶段被吞
   - **不要**把 violations 摘要塞进对辩主体内容然后跑路——必须独立成段，让用户看见具体哪轮哪种违规
 
 主线输出 markdown 表格，**不写文件**——主线直接展示给用户。
@@ -147,9 +147,9 @@ shouldStop(rounds, maxRounds) → boolean
 
 helper 暴露：
 - `debateStateMachine(topic, options)` → `DebateRoundPlan[]`
-- `parseRoundSummary(text)` → `RoundSummary`（v4.4.3: 含 `degraded?: { attempts, reason }` 字段）
+- `parseRoundSummary(text)` → `RoundSummary`（含 `degraded?: { attempts, reason }` 字段）
 - `shouldStop(rounds, maxRounds)` → `boolean`
-- `validateRetryProtocol(rounds)` → `RetryProtocolReport`（**v4.4.3**: Step 2 综合阶段必须调；非 compliant 时主线必须在输出加协议违规区段）
+- `validateRetryProtocol(rounds)` → `RetryProtocolReport`（Step 2 综合阶段必须调；非 compliant 时主线必须在输出加协议违规区段）
 - `REQUIRED_RETRY_ATTEMPTS` = `3`（与 Step 1.3 的 "3 次全部失败" 文档同步）
 
 ## 不做

package/templates/commands/debug.md

@@ -1,11 +1,11 @@
 ---
-description: '多模型调试（v4.0 manager + debugger 双层 fresh-context）：科学方法 hypothesis 链 + 持久 session + cap 3 升级'
+description: '多模型调试（manager + debugger 双层 fresh-context）：科学方法 hypothesis 链 + 持久 session + cap 3 升级'
 argument-hint: "<问题描述> [--mode=find_root_cause_only|find_and_fix] [--role=architect|critic|implementer|tester|writer]"
 ---
 
-# Debug - 多模型调试（v4.0 重写）
+# Debug - 多模型调试（manager + debugger 双层）
 
-## Role-based routing（v4.1 specialist matrix）
+## Role-based routing（specialist matrix）
 
 可选 `--role=<name>` 叠加 role 维度路由（debug-session-manager 内 spawn 的 debugger 用 role 选 prompt）：
 
@@ -15,11 +15,11 @@ argument-hint: "<问题描述> [--mode=find_root_cause_only|find_and_fix] [--rol
 | **frontend**  | gemini/architect.md | gemini/reviewer.md (adversarial) | gemini/debugger.md | gemini/tester.md | gemini/analyzer.md |
 | **fullstack** | codex+gemini/architect.md | both reviewer.md (adversarial) | runner 决 | runner 决 | claude |
 
-**未传 --role 时按 v4.0 manager + debugger 双层流程**（debugger.md 默认 implementer 角色）——完全兼容。`--role=critic` 触发"反向假设"调试（强制构造反证），适合定位概率性 bug。详见 `src/utils/specialist-router.ts`。
+**未传 --role 时按 manager + debugger 双层流程**（debugger.md 默认 implementer 角色）——完全兼容。`--role=critic` 触发"反向假设"调试（强制构造反证），适合定位概率性 bug。详见 `src/utils/specialist-router.ts`。
 
 ---
 
-**v4.0 重大变更**：从单次双模型并行调用 → **manager + debugger 双层 fresh-context** 模式。
+**核心架构**：从单次双模型并行调用 → **manager + debugger 双层 fresh-context** 模式。
 
 主线（你）只 spawn `debug-session-manager` 一次，manager 在隔离 context 内跑完整 hypothesis 多轮循环，最终返回 ≤ 200 token 的紧凑摘要。**主线 context 不再被多轮调试 transcript 污染**——这是 GSD ROI #3 (`02-subagent-matrix.md` Section 2.6) 的核心模式。
 
@@ -198,16 +198,16 @@ manager 的 3 轮 hypothesis 都被证伪。这通常意味着：
 
 1. **只 spawn manager 一次**：禁止主线自己跑多轮 hypothesis 循环（违反 fresh-context 隔离的 GSD ROI #3 设计）
 2. **不读 manager transcript**：主线只读返回的 ≤ 200 token 摘要 + （用户需要时）`.context/debug/<slug>.md` 文件
-3. **mode 默认 find_and_fix**：与 v3.0 行为一致（用户期待修好），仅在 `--mode=find_root_cause_only` 时仅找根因
+3. **mode 默认 find_and_fix**：用户期待修好，仅在 `--mode=find_root_cause_only` 时仅找根因
 4. **cap 3 = 升级**：CCG 全体系硬规约，manager 不会偷偷继续；主线尊重 CHECKPOINT_REACHED 不重 spawn
 5. **session 文件持久**：中断恢复 / 用户审计的唯一通道
 6. **科学方法守门**：每个 hypothesis 必须 falsifiable（manager 会拒收 debugger 给的空话）
 
 ---
 
-## 与 v3.0 的差异
+## 与早期实现的差异
 
-| 维度 | v3.0（已废） | v4.0（当前） |
+| 维度 | 早期实现（已废） | 当前 |
 |------|-------------|-------------|
 | 调用模式 | 双模型并行单次诊断 | manager + debugger 双层 fresh-context |
 | 多轮 | ❌ 没有（一次性） | ✅ hypothesis 链，cap 3 |

package/templates/commands/execute.md

@@ -20,12 +20,12 @@ $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 摘要。
-2. **降级 codeagent-wrapper 路径**（v4.0 BC fallback）：plugin 未装 → fallback 到 `Bash(~/.claude/bin/codeagent-wrapper ...)`，与 v4.0 行为完全一致。
+2. **降级 codeagent-wrapper 路径**（BC fallback）：plugin 未装 → fallback 到 `Bash(~/.claude/bin/codeagent-wrapper ...)`，行为与 plugin 路径等价。
 
 **判断方法**：preflight 用 `Bash` 跑 `ls ~/.claude/plugins/ 2>/dev/null | grep -E '^(codex|gemini)@'`；两个 plugin 独立判定。
 
@@ -42,7 +42,7 @@ CCG v4.1 把 6 核心命令的"双模型并行"通道从 `Bash(codeagent-wrapper
 - 如果用户通过 `/add-dir` 添加了多个工作区，先用 Glob/Grep 确定任务相关的工作区
 - 如果无法确定，用 `AskUserQuestion` 询问用户选择目标工作区
 
-**调用语法**（v4.1 Phase 20 双通道）：
+**调用语法**（双通道）：
 
 **通道 A — plugin spawn（默认，原型生成）**：
 
@@ -133,7 +133,7 @@ EOF",
 
 **会话复用**：如果 `/ccg:plan` 提供了 SESSION_ID，使用 `resume <SESSION_ID>` 复用上下文。
 
-**事件驱动等待（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。
 
@@ -296,7 +296,7 @@ EOF",
 3. 执行必要的修复
 4. 修复后按需重复 Phase 5.1（直到风险可接受）
 
-#### 5.3 写入 phase-scoped SUMMARY.md（v4.0 Phase 2 状态机）
+#### 5.3 写入 phase-scoped SUMMARY.md（状态机）
 
 **强制**：每完成一个 plan 后，写 `.context/<phase>/SUMMARY.md` 让上层 orchestrator（autonomous / team-exec）只读 frontmatter（< 200 tokens / phase）就能决策推进，避免接整段 builder stdout 污染主线 context。
 

package/templates/commands/init.md

@@ -42,7 +42,7 @@ Task({
 
 等待返回时间戳后，保存为 `$TIMESTAMP` 供后续使用。
 
-### 🗺️ 步骤 1.5：codebase-mapper 4 路并行扫描（v4.0）
+### 🗺️ 步骤 1.5：codebase-mapper 4 路并行扫描
 
 **强制**：在调用 init-architect 之前，**必须在同一条 assistant message 中并行 spawn 4 个 `codebase-mapper`**（多 tool calls 一次发出）。每个实例只处理一个 focus，把扫描结果写到 `.context/codebase/` 下对应文件，主线只接收一行确认。
 

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,27 +49,55 @@ 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（v4.4.2 默认，绕开 sonnet wrapper）**：
+**通道 A — Bash 直调 plugin script（默认，绕开 sonnet wrapper）**：
 
-```
-Bash({
-  command: `node "$(ls ~/.claude/plugins/cache/openai-codex/codex/*/scripts/codex-companion.mjs | head -1)" task -p "<整段 prompt 含 ROLE_FILE + TASK + OUTPUT 要求>" --json`,
-  description: "Review: backend (codex direct)",
-  run_in_background: true,
-  timeout: 3600000
-})
+> 占位符 `{{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 不参与任何命令构造。
+
+**LLM 工作流（严格 3 步）**：
 
-Bash({
-  command: `node "$(ls ~/.claude/plugins/cache/google-gemini/gemini/*/scripts/gemini-companion.mjs | head -1)" task -p "<整段 prompt>" --json`,
-  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 解析。
+```
+
+⛔ **严禁** 任何形式自拼命令：
+- 不要写 `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")` —— plugin spawn 走 sonnet wrapper，broker 故障/CLI 空答时 wrapper 可能 silent fallback 自答冒充 cross-vendor 视角（v4.4.2 hotfix 决策，详见 `src/utils/verify-orchestrator.ts:planVerifyWave` `useDirectBashInvocation` 选项）。
+⛔ **不要**用 `Agent(subagent_type="codex:codex-rescue"|"gemini:gemini-rescue")`：
+
+review/verify 路径输出**直接落地**决策（PR merge / advance / revise / escalate），无下游兜底。
+plugin 经由 `Agent(...)` spawn 时引擎启动 sonnet wrapper 扮演 codex/gemini 客户端，broker 故障 /
+CLI 空答 / auth 过期时 wrapper 受 instruction-tuning 驱动**自答 fabricated cross-vendor 视角**
+（silent fallback），主线无法察觉。Bash 直调消除 wrapper 层，stdout 即真实 plugin 输出。
+
+详见 `src/utils/verify-orchestrator.ts:planVerifyWave` 的 `useDirectBashInvocation` 选项 +
+`src/utils/plugin-bash-codegen.ts`（1.0.4 install-time codegen）。
 
 主线接 stdout JSON（5-50KB），按 plugin --json schema 解析 `result.text` 字段，失败信号：
 - exit code ≠ 0 → loud fail，触发 v1.7.87 标准 2-retry / 5s / 3-attempts 规则
@@ -95,7 +123,7 @@ EOF",
 })
 ```
 
-> ⚠️ 通道 B `codeagent-wrapper` 在 v4.1 已标 **deprecated**，将在 v5.0 移除。
+> ⚠️ 通道 B `codeagent-wrapper` 已标 **deprecated**。
 
 **角色提示词**：
 
@@ -104,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**
@@ -116,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
 
@@ -165,11 +193,25 @@ EOF",
 
 **仅当 `$ARGUMENTS` 含 `--adversarial` 字面量时启动**。否则跳过本阶段。
 
-调用方式（v4.4.2 起 Bash 直调，绕开 sonnet wrapper）：
+调用方式（Bash 直调，绕开 sonnet wrapper）：
 
 ```
-Bash({
-  command: `node "$(ls ~/.claude/plugins/cache/openai-codex/codex/*/scripts/codex-companion.mjs | head -1)" task -p "--adversarial-review
+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
+   })
+```
+
+**Adversarial prompt body**（写入 tmpfile 的内容）：
+
+```
+--adversarial-review
 
 请对以下代码变更进行敌对视角审查：
 
@@ -184,14 +226,11 @@ Bash({
 你的任务：
 1. 找出前两轮**未发现或低估**的安全/性能/正确性漏洞
 2. 假设代码作者刻意误导，挑刺
-3. 输出格式：[Critical-Adversarial] / [Major-Adversarial] 列表，每条标'为什么前两轮没发现'" --json`,
-  description: "Adversarial review (codex direct)",
-  run_in_background: true,
-  timeout: 3600000
-})
+3. 输出格式：[Critical-Adversarial] / [Major-Adversarial] 列表，每条标"为什么前两轮没发现"
 ```
 
-⛔ 不用 `Agent(subagent_type="codex:codex-rescue")` —— v4.4.2 决策：review/verify 路径绕开 sonnet wrapper，避免 silent fallback 冒充 adversarial 视角。
+⛔ 不用 `Agent(subagent_type="codex:codex-rescue")`：review/verify 路径输出直接落地，silent fallback
+风险（sonnet wrapper 受 instruction-tuning 自答冒充 adversarial 视角）不可接受。详见前文「通道 A」段。
 
 收到 stdout JSON 后解析 `result.text` 字段保留待阶段 3 综合。stdout 空或 exit≠0 → 走标准 2-retry 规则。
 

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 次全失败才降级单模型。