ccgx-workflow 1.0.4 → 1.0.5

package/templates/commands/analyze.md

@@ -13,7 +13,7 @@ argument-hint: "<分析问题或任务> [--role=architect|critic|implementer|tes
 /analyze <分析问题或任务> [--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|tes
 | **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}} analyzer.md），完全兼容**。`--role=critic` 触发敌对分析（专挑漏洞 / 反对主流意见）。详见 `src/utils/specialist-router.ts`。
+**未传 --role 时按双模型并行（{{BACKEND_PRIMARY}}/{{FRONTEND_PRIMARY}} analyzer.md），完全兼容**。`--role=critic` 触发敌对分析（专挑漏洞 / 反对主流意见）。详见 `src/utils/specialist-router.ts`。
 
 ## 你的角色
 
@@ -35,12 +35,12 @@ argument-hint: "<分析问题或任务> [--role=architect|critic|implementer|tes
 
 ---
 
-## 调用通道路由（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`。
 
@@ -55,7 +55,7 @@ CCG v4.1 把双模型并行通道从 `Bash(codeagent-wrapper)` **默认切换**
 - 如果用户通过 `/add-dir` 添加了多个工作区，先用 Glob/Grep 确定任务相关的工作区
 - 如果无法确定，用 `AskUserQuestion` 询问用户选择目标工作区
 
-**调用语法**（v4.1 Phase 20 双通道）：
+**调用语法**（双通道）：
 
 **通道 A — plugin spawn（默认）**：
 
@@ -96,7 +96,7 @@ EOF",
 })
 ```
 
-> ⚠️ 通道 B `codeagent-wrapper` 在 v4.1 已标 **deprecated**，将在 v5.0 移除。
+> ⚠️ 通道 B `codeagent-wrapper` 已标 **deprecated**。
 
 **角色提示词**：
 
@@ -105,7 +105,7 @@ EOF",
 | 后端 | `~/.claude/.ccg/prompts/{{BACKEND_PRIMARY}}/analyzer.md` |
 | 前端 | `~/.claude/.ccg/prompts/{{FRONTEND_PRIMARY}}/analyzer.md` |
 
-**并行调用 + 事件驱动等待（v4.5.2 起）**：
+**并行调用 + 事件驱动等待**：
 
 1. 同 message 内 spawn 多个 `Bash(run_in_background: true)` 并行任务
 2. spawn 完后主线说明已启动 task-id，**直接 turn end**，**不调 TaskOutput**
@@ -114,7 +114,7 @@ EOF",
 5. **必须等所有相关 task 都收到通知**才进入下一阶段（按 task-id 计数已收齐）
 
 ⛔ **禁止**：
-- 调 `TaskOutput({block: true, timeout: 600000})` —— v4.5.1 之前的旧 freeze poll 模式，已废弃（freeze 主线 10 min + 超时还要轮询，体验极差）
+- 调 `TaskOutput({block: true, timeout: 600000})` —— 旧 freeze poll 模式，已废弃（freeze 主线 10 min + 超时还要轮询，体验极差）
 - 收到部分通知就跳过等其他模型
 - 主动 Kill task
 
@@ -152,7 +152,7 @@ EOF",
    - ROLE_FILE: `~/.claude/.ccg/prompts/{{FRONTEND_PRIMARY}}/analyzer.md`
    - OUTPUT：UI/UX 影响、用户体验、视觉设计考量
 
-事件驱动等待 (v4.5.2)：spawn 完两个 Bash bg 后主线 turn end，等 task-notification 自动唤醒。**必须等所有模型返回后才能进入下一阶段**。
+事件驱动等待：spawn 完两个 Bash bg 后主线 turn end，等 task-notification 自动唤醒。**必须等所有模型返回后才能进入下一阶段**。
 
 **务必遵循上方 `多模型调用规范` 的 `重要` 指示**
 

package/templates/commands/autonomous.md

@@ -24,11 +24,11 @@ allowed-tools:
 
 `/ccg:autonomous` 是**编排层之上的编排层**：读 `.ccg/roadmap.md` 一次性跑完整个 milestone 的所有 phase，每个 phase 内部委托给 `/ccg:team`（或 `/ccg:spec-impl`）完成 8 阶段流程，仅在 blocker / 灰区接受 / 用户决策点暂停。
 
-> **v4.1 调度模型变更**：默认行为从 v4.0 的"逐 phase 顺序串行"升级为 **wave 并行**。
+> **调度模型**：默认采用 **wave 并行**。
 > autonomous 用 Kahn 拓扑排序把 EXEC_QUEUE 划分成 wave，wave 内 phase 一次性并行
 > spawn `Agent(phase-runner)`（max-concurrent 默认 4），wave 之间顺序执行——这与
-> v3.0 起的 `team-exec` wave 调度心智模型对齐，墙钟时间通常压缩 30-40%。
-> v4.0 的串行行为通过 `--sequential` flag 保留作为调试 / API 限额场景的降级路径。
+> `team-exec` wave 调度心智模型对齐，墙钟时间通常压缩 30-40%。
+> 顺序串行行为通过 `--sequential` flag 保留作为调试 / API 限额场景的降级路径。
 
 **与 `/ccg:team` 的边界**：
 
@@ -105,10 +105,10 @@ allowed-tools:
 | 同时给 `--only` 和 `--from`/`--to` | `--only` 优先，其余忽略并提示 |
 | `--interactive` | 每个 phase 内的 plan 阶段保留与用户问答（不自动判定灰区） |
 | `--offload` | **重型 phase 自动外包给 codex plugin**（fresh context + 后台 + 主线只 poll status），默认开启自动判定，flag 显式时强制开启 |
-| `--sequential` | **降级为 v4.0 行为**：禁用 wave 并行，单 phase 一波顺序串跑。调试 / API 限额场景使用 |
+| `--sequential` | **降级为顺序串行**：禁用 wave 并行，单 phase 一波顺序串跑。调试 / API 限额场景使用 |
 | `--max-concurrent N` | 单 wave 内最大并发 phase 数，默认 4。`--max-concurrent 1` 等价 `--sequential` |
-| `--quality=fast\|triple\|debate` | **v4.2 P22 旗舰**：单 phase 内的质量档分级。`fast`=v4.1 单波 + 1 路 verify；`triple`=Plan-Critic-Verify 4 wave（**默认**）；`debate`=triple + codex↔gemini 多轮对辩。详见 Step 4.0 |
-| `--nested=on\|off` | **v4.5 P1f**：phase-runner 是否启用 nested rescue 委派（CLI 子进程内 spawn `codex:codex-rescue` / `gemini:gemini-rescue` 委派代码改动）。默认 `off` 保守。phase frontmatter `nested_rescue: true\|false` 优先级更高。详见 Step 4.0c |
+| `--quality=fast\|triple\|debate` | 单 phase 内的质量档分级。`fast`=单波 + 1 路 verify；`triple`=Plan-Critic-Verify 4 wave（**默认**）；`debate`=triple + codex↔gemini 多轮对辩。详见 Step 4.0 |
+| `--nested=on\|off` | phase-runner 是否启用 nested rescue 委派（CLI 子进程内 spawn `codex:codex-rescue` / `gemini:gemini-rescue` 委派代码改动）。默认 `off` 保守。phase frontmatter `nested_rescue: true\|false` 优先级更高。详见 Step 4.0c |
 
 附加规则：
 - 状态已是 `completed` 的 phase 默认跳过（除非 `--only N` 强制重跑）
@@ -138,12 +138,12 @@ allowed-tools:
 
 `--interactive` 模式下，每个 phase 的 plan 阶段保留与用户问答（不自动判定灰区），其余阶段照常自治。
 
-### Step 4: Phase 主循环（v4.1 wave 并行 + v4.2 P22 质量档分级）
+### Step 4: Phase 主循环（wave 并行 + 质量档分级）
 
-#### 4.0 Ground-Truth 采样（v4.3 P26 / v4.4 P32 集成）
+#### 4.0 Ground-Truth 采样
 
 **进入主循环前**，主线必须采样真实外部接口状态，写入 `.context/ground-truth/<ISO timestamp>.json` + 软链 `latest.json`。
-phase-runner 的 prompt 强约束 "写涉及 plugin subagent_type / hook event / settings.json schema / skill 名 等代码前必须 Read latest.json"，避免 v4.2.0 `codex:codex-rescue` 同型猜接口事故重演。
+phase-runner 的 prompt 强约束 "写涉及 plugin subagent_type / hook event / settings.json schema / skill 名 等代码前必须 Read latest.json"，避免猜接口同型事故。
 
 **主线动作**（伪码）：
 
@@ -165,11 +165,11 @@ catch { writeFileSync(`${dir}/latest.json`, JSON.stringify(gt, null, 2)) }
 console.log(summarizeGroundTruth(gt))   // ≤500 token brief 写入主线对话以便 phase-runner 拷贝
 ```
 
-**容错**：若采样抛错，主线打印警告但**不阻塞推进**——单 phase 仍可工作（degraded：phase-runner prompt 走"无 ground truth"分支，凭 spec 文档猜，恢复至 v4.2 行为）。
+**容错**：若采样抛错，主线打印警告但**不阻塞推进**——单 phase 仍可工作（degraded：phase-runner prompt 走"无 ground truth"分支，凭 spec 文档猜）。
 
 **phase-runner 注入路径**：每次 spawn phase-runner 时，主线在 prompt 里加一行 `ground_truth_path: <workdir>/.context/ground-truth/latest.json`，并要求子 agent 在动外部接口代码前必须 Read 该文件。
 
-#### 4.0a 质量档解析（v4.2 P22 新增，单 phase 内调度）
+#### 4.0a 质量档解析（单 phase 内调度）
 
 每个 phase 进入主循环前，主线先确定**该 phase 内部使用什么质量档**——这决定单个 phase 的 wave 编排（不是整个 milestone 的 wave 拓扑，那是 4.0b）。
 
@@ -182,7 +182,7 @@ console.log(summarizeGroundTruth(gt))   // ≤500 token brief 写入主线对话
    - **Quality**: debate    ← phase 自带，优先级最高
    ```
 2. `--quality=<tier>` CLI flag（autonomous 命令行参数）
-3. 默认 `triple`（**v4.2 行为变化**：v4.1 默认是单波 phase-runner = `fast`）
+3. 默认 `triple`
 
 主线引用 `src/utils/quality-router.ts` 的 `buildQualityPlan()` helper（实际逻辑已落地为单元测试覆盖；本模板只描述 LLM 主线该做什么）：
 
@@ -192,8 +192,8 @@ qualityPlan = buildQualityPlan(
   { phaseId, phaseType, quality, workdir, jobId, nestedRescue: <从 frontmatter 读> },
   pluginAvailability,
   {
-    useDirectBashInvocation: true,    # ⛔ v4.5 P1a 强制 ON
-    useLauncherWiring: true,          # ⛔ v4.5 P1f 强制 ON（解锁 supervisor 全部能力）
+    useDirectBashInvocation: true,    # ⛔ 强制 ON
+    useLauncherWiring: true,          # ⛔ 强制 ON（解锁 supervisor 全部能力）
   },
 )
 // qualityPlan.tier  → 'fast' | 'triple' | 'debate'
@@ -201,16 +201,16 @@ qualityPlan = buildQualityPlan(
 // qualityPlan.degraded / degradedTo  → plugin 缺失自动降阶
 ```
 
-**⛔ v4.5 P1a 强约束（impl wave Bash 直调）**：
+**⛔ 强约束（impl wave Bash 直调）**：
 
 `useDirectBashInvocation: true` 时 impl wave 的 phase-runner spawn 会标
 `invocationMode: 'bash-direct'` + 附 `bashCommand`，主线**必须用 Bash 工具**执行
 该命令（启 OS-level `claude -p --agent ccg/phase-runner` 子进程），**不可**走
 `Agent(subagent_type="phase-runner")` 主进程 sidechain。
 
-理由：v4.4.x dogfood 实测主进程 RSS 7.5h 累积 23GB 把 VM 弄崩，根因是 Agent
+理由：dogfood 实测主进程 RSS 长跑会累积到 GB 级把 VM 弄崩，根因是 Agent
 sidechain transcript 留在主进程内存。Bash 子进程的 RSS 与主进程隔离，phase
-结束后内存全部回收。详见 `.ccg/v4.5-roadmap.md` P1a。
+结束后内存全部回收。
 
 **三档对照（dogfood + SOTA 实测预算）**：
 
@@ -239,7 +239,7 @@ sidechain transcript 留在主进程内存。Bash 子进程的 RSS 与主进程
 - **Implementer 单 strong model**（phase-runner 全权 Bash）—— 一致性 > 多样性，避免多 implementer 的 merge 痛苦
 - **Verify cross-vendor**（codex + gemini）—— 抓 race condition / commit drift / 半成品状态
 
-#### 4.0c Nested rescue 解析（v4.5 P1f opt-in）
+#### 4.0c Nested rescue 解析（opt-in）
 
 每个 phase 进入主循环前，主线确定 phase-runner CLI 子进程内是否启用 **nested rescue 委派**——即在 CLI 子进程内 spawn `Agent(codex:codex-rescue)` / `Agent(gemini:gemini-rescue)` 委派代码改动。
 
@@ -252,7 +252,7 @@ sidechain transcript 留在主进程内存。Bash 子进程的 RSS 与主进程
    - **nested_rescue**: true    ← phase 自带，优先级最高
    ```
 2. `--nested=on|off` CLI flag（autonomous 命令行参数）
-3. 默认 `false`（保守：与 v4.5 v1 保守路线 100% 等价）
+3. 默认 `false`（保守路线）
 
 主线引用 `src/utils/quality-router.ts` 的 `resolveNestedRescue()` helper：
 
@@ -273,10 +273,10 @@ job_id: <主线 launcher 分配>      # phase-runner 需 Read .context/jobs/<job
 ```
 
 phase-runner 按 `nested_rescue` 字段切换实施路径（详见 `~/.claude/agents/ccg/phase-runner.md` "Nested rescue delegation" 段）：
-- `false` → 自实施（v4.0/v4.4 行为）
+- `false` → 自实施（保守路径）
 - `true` → 按 phase_type 路由 spawn rescue plugin；CAP=3；监听 `degraded.flag`
 
-**默认 `--nested=off` 行为不变**——与 v4.5 v1 单波 phase-runner 自实施 100% 等价。
+**默认 `--nested=off`** —— 单波 phase-runner 自实施。
 
 #### 4.0b 拓扑分波（Kahn 算法）
 
@@ -297,7 +297,7 @@ waves, skipped, batches = schedule(phases, {
 ```
 
 **`--sequential` 降级**：等价 `maxConcurrent = 1`，每 phase 单独成一批，顺序执行。
-调试 / 复现历史 v4.0 行为 / API 限额场景使用。
+调试 / API 限额场景使用。
 
 **Cascade skip**：若某 phase 状态为 `failed` 或 `skipped`，所有（直接 / 间接）
 依赖它的 phase 自动标 `skipped`，从 EXEC_QUEUE 移除并在 roadmap.md 写
@@ -319,7 +319,7 @@ waves, skipped, batches = schedule(phases, {
 
 #### 4.1 准备 phase（按 wave 迭代 + 单 phase 质量档子 wave）
 
-**两层 wave 概念**（v4.2 P22 起）：
+**两层 wave 概念**：
 
 - **外层 wave**（4.0b 拓扑）：milestone 级别，按 phase 间 Depends on 关系分波，wave 内 phase 并行
 - **内层 wave**（4.0a 质量档）：单 phase 内部，按 fast/triple/debate 分 2/4/7 个子 wave，**子 wave 之间顺序执行**
@@ -367,7 +367,7 @@ runPhaseWithQualityPlan(phase, plan):
                 #                         commit-diff drift / mock-drift）
                 # fast 模式不加 interface-auditor（fast 优先速度）。
                 #
-                # ⛔ v4.4.2 verify wave 强制 Bash 直调 plugin script：
+                # ⛔ verify wave 强制 Bash 直调 plugin script：
                 #   verifyWave = planVerifyWave(tier, layer, plugins,
                 #                               { useDirectBashInvocation: true })
                 #   for each spawn entry where invocationMode === 'bash-direct':
@@ -389,7 +389,7 @@ runPhaseWithQualityPlan(phase, plan):
                     AskUserQuestion → blocker path
 ```
 
-**impl wave 的 phase-runner prompt 增量**（v4.2 P22）：
+**impl wave 的 phase-runner prompt 增量**：
 
 triple/debate 模式 plan wave 完成后，主线把 `aggregatePlans` 输出经
 `serializeBriefForPrompt()` 序列化（≤500 token）注入 phase-runner prompt 的
@@ -412,7 +412,7 @@ verify wave 后若 decision='revise'，主线再 spawn 一次 phase-runner，
 按以下优先级判定（**前序匹配后短路**）：
 
 1. **phase 标题含 `opsx://` 引用** → 走 OpenSpec 路径，调 `/ccg:spec-impl` 并传入 change_id
-2. **runner 模式 phase**（`--offload` flag 或 phase 标 `[offload]` tag 或满足重型自动触发）→ 用 `Bash(claude -p --agent ccg/phase-runner ...)` 启 OS-level 子进程（**v4.5 P1a**；详见下方"phase-runner 调用方式"），把 phase 完整定义 + Type 字段写到 prompt 文件传给子进程
+2. **runner 模式 phase**（`--offload` flag 或 phase 标 `[offload]` tag 或满足重型自动触发）→ 用 `Bash(claude -p --agent ccg/phase-runner ...)` 启 OS-level 子进程（详见下方"phase-runner 调用方式"），把 phase 完整定义 + Type 字段写到 prompt 文件传给子进程
 3. **默认** → 走 Agent Teams 路径，调 `/ccg:team <phase goal>`
 
 ##### runner 模式判定（决定走第 2 路）
@@ -426,14 +426,14 @@ verify wave 后若 decision='revise'，主线再 spawn 一次 phase-runner，
 - phase 预估涉及 > 20 个文件
 - 上一个 phase 的 plan 文件 > 800 行
 
-##### phase-runner 调用方式（v4.5 P1a：Bash 直调 OS 子进程）
+##### phase-runner 调用方式（Bash 直调 OS 子进程）
 
-phase-runner 是 CCG v4.0 引入的**单 phase 全权代理 agent**——它按 phase Type
+phase-runner 是 CCG 的**单 phase 全权代理 agent**——它按 phase Type
 字段决定工作风格，沙箱外补 git/test/typecheck handoff，最终返回主线 ≤200
 token 摘要。详见 `~/.claude/agents/ccg/phase-runner.md`。
 
-**v4.5 起 phase-runner 通过 OS-level subprocess 启动**（不再用 Agent sidechain）。
-**v4.5.1 P1f 起经 launcher 包装**（解锁 Phase 2 supervisor 能力：atomic state /
+**phase-runner 通过 OS-level subprocess 启动**（不用 Agent sidechain）。
+**经 launcher 包装**（解锁 supervisor 能力：atomic state /
 process-tree kill-tree / cancel.flag 协作 / reconciler）。
 
 主线读 `qualityPlan.waves[i].spawns[0]`（impl wave）的 `bashCommand` 字段直接跑：
@@ -457,9 +457,9 @@ Bash(node '~/.claude/.ccg/scripts/ccg-phase-runner-launcher.mjs' \
 # 抽末行 result.result 字段拿 ≤200 token SUMMARY
 ```
 
-**裸 `claude -p` 路径**（旧 P1a，无 supervisor 包装）保留作 BC：仅 dev workflow / 单测覆盖。生产走 launcher（`useLauncherWiring: true`）。
+**裸 `claude -p` 路径**（无 supervisor 包装）保留作 BC：仅 dev workflow / 单测覆盖。生产走 launcher（`useLauncherWiring: true`）。
 
-prompt.txt 的内容（**v4.5 P1f 起**新增 `nested_rescue` + `job_id` 字段）：
+prompt.txt 的内容（含 `nested_rescue` + `job_id` 字段）：
 
 ```yaml
 phase_id: phase-<N>-<slug>
@@ -476,23 +476,22 @@ baseline_sha: <最近一次 baseline commit sha7>
 report_path: .claude/team-plan/phase-<N>-<slug>-report.md
 commit_prefix: feat(v4-p<N>):
 enable_challenger: false
-nested_rescue: <true | false>     # v4.5 P1f：来自 4.0c resolveNestedRescue()
-job_id: <主线 launcher 分配的 job-id>  # v4.5 P1b：phase-runner 需 Read degraded.flag
+nested_rescue: <true | false>     # 来自 4.0c resolveNestedRescue()
+job_id: <主线 launcher 分配的 job-id>  # phase-runner 需 Read degraded.flag
 ```
 
-**为什么 Bash 直调**：v4.4.x dogfood 主进程 RSS 7.5h 累积 23GB 撞 VM 极限。
+**为什么 Bash 直调**：dogfood 实测主进程 RSS 长跑会累积到 GB 级撞 VM 极限。
 Agent sidechain 的 transcript 留主进程内存；OS 子进程则是独立 PID，phase 结束
-后内存全部回收。三层 OS 进程隔离（主线 / phase-runner / nested rescue）首次
-落地。详见 `.ccg/v4.5-roadmap.md` P1a + `.ccg/poc-v45/poc-results.md` T9。
+后内存全部回收。三层 OS 进程隔离（主线 / phase-runner / nested rescue）落地。
 
 **禁用** `Agent(subagent_type="phase-runner")` —— 已弃用。autonomous 主线**不得**
-回退到该路径（除非 P1f gate 失败显式降级，由 release notes 公示）。CLI 子进程内
-phase-runner 内部 `Agent` 工具可用——CLI 模式与 sidechain 模式工具白名单不同
-（PoC T9 实测）；nested rescue 委派由此路径解锁。
+回退到该路径（除非 launcher gate 失败显式降级）。CLI 子进程内
+phase-runner 内部 `Agent` 工具可用——CLI 模式与 sidechain 模式工具白名单不同；
+nested rescue 委派由此路径解锁。
 
-**模型路由委派给 phase-runner**：autonomous 主线不再硬编码 codex/gemini，phase-runner 根据 prompt 里的 `phase_type` 字段决定 spawn `codex:codex-rescue` 还是 `gemini:gemini-rescue`。这修复了 v3.0 路由 bug（autonomous 绕过 `{{FRONTEND_PRIMARY}}/{{BACKEND_PRIMARY}}` 配置）。
+**模型路由委派给 phase-runner**：autonomous 主线不再硬编码 codex/gemini，phase-runner 根据 prompt 里的 `phase_type` 字段决定 spawn `codex:codex-rescue` 还是 `gemini:gemini-rescue`。这避免 autonomous 绕过 `{{FRONTEND_PRIMARY}}/{{BACKEND_PRIMARY}}` 配置。
 
-**降级路径**：若 `Agent(phase-runner)` 调用失败（v3.0 旧版未装该 subagent），输出告警 + fallback 到第 3 路 `/ccg:team`，roadmap.md 备注 `Note: phase-runner unavailable, fell back to team`。
+**降级路径**：若 `Agent(phase-runner)` 调用失败（旧版未装该 subagent），输出告警 + fallback 到第 3 路 `/ccg:team`，roadmap.md 备注 `Note: phase-runner unavailable, fell back to team`。
 
 #### 4.3 监控 phase 内信号
 
@@ -505,7 +504,7 @@ phase-runner 内部 `Agent` 工具可用——CLI 模式与 sidechain 模式工
   - **Phase 完成但 Critical > 0**（用户在 team 内选了"接受失败"） → 进入 **blocker 路径**
   - **Phase 失败**（team 异常退出 / 测试不可恢复地失败） → 进入 **blocker 路径**
 
-**走 phase-runner 路径**（4.2 第 2 路，v4.5 P1a Bash 直调 + P1f launcher wiring）：
+**走 phase-runner 路径**（4.2 第 2 路，Bash 直调 + launcher wiring）：
 
 - 主线 `Bash(run_in_background=true)` 启动 `node ccg-phase-runner-launcher.mjs ...` 子进程后**不阻塞**继续做别的；用 `Bash(wc -l .context/jobs/<id>/progress.jsonl)` / `Bash(tail -n 5 ...)` 轮询观察进度（launcher 透传子进程 stdout 到 progress.jsonl）
 - 子进程结束（exit code 写到 background job 状态）后主线读 `progress.jsonl` 末行，调 `parsePhaseRunnerStreamSummary()` helper 抽 `result.result` 字段拿 ≤200 token 摘要
@@ -532,7 +531,7 @@ phase-runner 内部 `Agent` 工具可用——CLI 模式与 sidechain 模式工
 
 #### 4.4 Phase 推进（wave 级批处理）
 
-- **4.4.a Critical phase challenger 编排（v4.1 Phase 16）**：
+- **4.4.a Critical phase challenger 编排**：
   当 phase 摘要 `STATUS: completed` 时，主线先读 phase frontmatter `Critical:` 字段
   （默认 `false`）。若 `Critical: true` 且**未进入修订轮**，主线**不立即推进**，
   改为 spawn 一组 challenger agents 做"双视角对辩 + 假设/边界审计"：
@@ -549,7 +548,7 @@ phase-runner 内部 `Agent` 工具可用——CLI 模式与 sidechain 模式工
 
   **plugin 缺失降级**（acceptance d）：installer 检测不到 `codex:codex-rescue` 或
   `gemini:gemini-rescue` 命令时，主线只 spawn specialist（CCG 自家 agent，必装），
-  **不 fallback** 到 codeagent-wrapper（避免重新建立 v3.0 已退役的依赖）。
+  **不 fallback** 到 codeagent-wrapper（已退役依赖）。
   roadmap.md 备注 `Note: challenger degraded — plugin <name> missing`。
 
   spawn 范式（一个 message 内并行）：
@@ -675,7 +674,7 @@ autonomous 是 **roadmap.md 的唯一写者**。team-exec 不动它。
 - `Plan` 字段指向该 phase 内 team 产出的 plan 目录
 - `Outcome` 一句话总结，便于下次回顾
 - `opsx://<change-id>` 标记走 OpenSpec 路径
-- `Quality: fast|triple|debate`（**v4.2 P22 新增，可选**）：单 phase 覆盖全局 `--quality` flag。例：
+- `Quality: fast|triple|debate`（可选）：单 phase 覆盖全局 `--quality` flag。例：
   ```markdown
   ## Phase 22: schema migration (pending)
   - **Goal**: 数据库 schema 破坏性变更

package/templates/commands/cancel.md

@@ -1,5 +1,5 @@
 ---
-description: '中止活跃后台任务：先写 cancel.flag（cooperative）→ grace 5s → kill-tree 强制（v4.5 P1b 升级）'
+description: '中止活跃后台任务：先写 cancel.flag（cooperative）→ grace 5s → kill-tree 强制'
 argument-hint: "<job-id> [--force]"
 allowed-tools:
   - Read
@@ -7,11 +7,11 @@ allowed-tools:
   - Bash
 ---
 
-# Cancel - 中止活跃后台任务（v4.5 升级）
+# Cancel - 中止活跃后台任务
 
 写一个**协作式**取消信号到 `.context/jobs/<job-id>/cancel.flag`，并在 grace period（默认 5s）后**强制 kill 进程树**作为兜底。后台子任务（codex:codex-rescue / phase-runner / autonomous loop）每次推进步骤前轮询 cancel.flag，发现存在则清理并退出。卡在 OS-level 不可中断 syscall 的子进程由 kill-tree fallback 兜底。
 
-> ⚠️ v4.5 之前是**纯协作**取消（不持有 PID），v4.5 P1b 引入 supervisor + cli_pid + process_group_id 后升级为**协作 + 强制兜底**。如果 phase-runner 已通过 `ccg-phase-runner-launcher.mjs` 启动，state.json 会含 `cli_pid`，本命令在 grace period 后调用 kill-tree（POSIX：`kill -TERM -<pgid>` → `kill -KILL`；Windows：`taskkill /T /F /PID`）。
+> ⚠️ 当前模式为 **协作 + 强制兜底**（supervisor + cli_pid + process_group_id）。如果 phase-runner 已通过 `ccg-phase-runner-launcher.mjs` 启动，state.json 会含 `cli_pid`，本命令在 grace period 后调用 kill-tree（POSIX：`kill -TERM -<pgid>` → `kill -KILL`；Windows：`taskkill /T /F /PID`）。
 
 ## 使用方法
 
@@ -38,7 +38,7 @@ allowed-tools:
    requested-by: /ccg:cancel
    ```
 
-   v4.5+：`src/utils/jobs.ts` 的 `requestCancel` 走 `atomicWriteFileSync`（temp + rename），cancel.flag 永远不会半写。
+   `src/utils/jobs.ts` 的 `requestCancel` 走 `atomicWriteFileSync`（temp + rename），cancel.flag 永远不会半写。
 
 2. 更新 state.json：把 `cancel_requested` 设为 `true`（**status 仍保持 running/queued** —— 真实 status 转 `canceled` 由子任务退出时自己写或由 Step 4 兜底写）
 
@@ -50,7 +50,7 @@ allowed-tools:
 
 读取 state.json 中的 `cli_pid` + `process_group_id`：
 
-- **没有 cli_pid**（v4.5 之前的 legacy job 或非 launcher 路径）：保持原有协作行为，提醒用户"无 PID 记录，请手动 `kill -9` 残留进程"。
+- **没有 cli_pid**（legacy job 或非 launcher 路径）：保持原有协作行为，提醒用户"无 PID 记录，请手动 `kill -9` 残留进程"。
 - **有 cli_pid**：用 Bash 执行 kill-tree：
   - **POSIX**: 优先 `kill -TERM -<pgid>` 走进程组（含 nested plugin 子进程）；失败回退 `kill -TERM <cli_pid>`；再 grace 1s 后 `kill -KILL`。
   - **Windows**: `taskkill /T /F /PID <cli_pid>` 杀整棵进程树（含 nested plugin）。
@@ -88,10 +88,10 @@ Status: canceled (forced via kill-tree)
 ## 严格约束
 
 - ✅ **协作优先**——总是先写 cancel.flag 给子进程自己退的机会，避免半写文件
-- ✅ **强制兜底**（v4.5+ supervised job）——grace 后 kill-tree 防 hang 死循环
+- ✅ **强制兜底**（supervised job）——grace 后 kill-tree 防 hang 死循环
 - ✅ 幂等——多次调用不报错，不重写 flag
 - ✅ 已终态的 job 调用 cancel 也不报错（友好降级）
-- ✅ atomic write（v4.5 P1b）——cancel.flag 永远不会半写
+- ✅ atomic write——cancel.flag 永远不会半写
 - ❌ **不要**直接把 status 改成 `canceled`——会与子任务退出时的写入产生竞态（除非 kill-tree 生效后）
 - ❌ **不要**删除 `.context/jobs/<id>/` 目录——历史可观测性必须保留
 
@@ -111,7 +111,7 @@ if (isCancelRequested(workdir, jobId)) {
 }
 ```
 
-phase-runner / codex:codex-rescue / autonomous loop 全部接入此契约（v4.0 Phase 7 + v4.5 P1b）。
+phase-runner / codex:codex-rescue / autonomous loop 全部接入此契约。
 
 ## 与其他命令的协作
 

package/templates/commands/codex-exec.md

@@ -106,7 +106,7 @@ REVIEW_EOF",
 |------|-------|--------|
 | 审查 | `~/.claude/.ccg/prompts/{{BACKEND_PRIMARY}}/reviewer.md` | `~/.claude/.ccg/prompts/{{FRONTEND_PRIMARY}}/reviewer.md` |
 
-**事件驱动等待（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。
 
@@ -223,7 +223,7 @@ EXEC_EOF",
 
 如果计划中无 `CODEX_SESSION`（用户跳过了 `/ccg:plan` 的多模型分析），则使用新会话。
 
-事件驱动等待 (v4.5.2)：spawn 完后主线 turn end，等 task-notification 自动唤醒。
+事件驱动等待：spawn 完后主线 turn end，等 task-notification 自动唤醒。
 
 ---
 

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/` 下对应文件，主线只接收一行确认。