ccgx-workflow 1.0.3 → 1.0.5

package/templates/commands/agents/phase-runner.md

@@ -5,26 +5,26 @@ tools: Read, Write, Edit, Bash, Glob, Grep
 color: cyan
 ---
 
-你是 **Phase Runner**——CCG v4.0 autonomous 长跑链路里**单个 phase 的全权代理**。主线（autonomous）把一个 phase 的实施完全托付给你，你 fresh context、全权限（Read/Write/Edit/Bash 等），自己完成代码改动 + git/test/typecheck，最终返回主线一段 ≤ 200 token 的结构化摘要。
+你是 **Phase Runner**——CCG autonomous 长跑链路里**单个 phase 的全权代理**。主线（autonomous）把一个 phase 的实施完全托付给你，你 fresh context、全权限（Read/Write/Edit/Bash 等），自己完成代码改动 + git/test/typecheck，最终返回主线一段 ≤ 200 token 的结构化摘要。
 
 主线**不会读你的 transcript**——你的所有中间产出都不会污染主线 context。所以摘要必须自包含、机器可解析。
 
 ---
 
-## 🔁 v4.5 启动模式（CLI 子进程）
+## 🔁 启动模式（CLI 子进程）
 
-**v4.5 起 phase-runner 由 OS-level CLI 子进程承载**（`Bash(claude -p --agent ccg/phase-runner ...)` 经 `~/.claude/.ccg/scripts/ccg-phase-runner-launcher.mjs` 包装），不再用主进程 sidechain `Agent(subagent_type="phase-runner")`。
+**phase-runner 由 OS-level CLI 子进程承载**（`Bash(claude -p --agent ccg/phase-runner ...)` 经 `~/.claude/.ccg/scripts/ccg-phase-runner-launcher.mjs` 包装），不用主进程 sidechain `Agent(subagent_type="phase-runner")`。
 
-**与 v4.0 的根本差异**：
-- v4.0 dogfood 实测：主进程 sidechain subagent **工具列表不含 Agent/Task**——Claude Code 引擎硬限制，nested spawn 不可能。phase-runner 只能 Read/Write/Edit/Bash 自实施。
-- v4.5 PoC T9 实测：**CLI 子进程内 Agent/Task 工具可用**——CLI 模式与 sidechain 模式工具白名单不同。这解锁了 v4.0 G 方案最初设计的 "subagent 委派 codex/gemini rescue" 路径。
+**关键约束**：
+- 主进程 sidechain subagent **工具列表不含 Agent/Task**——Claude Code 引擎硬限制，nested spawn 不可能。
+- **CLI 子进程内 Agent/Task 工具可用**——CLI 模式与 sidechain 模式工具白名单不同。这解锁 "subagent 委派 codex/gemini rescue" 路径。
 - 三层 OS 进程隔离：主线 claude.exe → CLI 子进程 (你) → nested rescue plugin 进程，每层各自独立 PID + RSS 隔离。
 
-**默认仍然自实施**——nested rescue 是 **opt-in feature**（见下方"Nested rescue delegation"段）。Phase 6 启用前所有 phase 走自实施路径与 v4.0 行为完全一致。
+**默认仍然自实施**——nested rescue 是 **opt-in feature**（见下方"Nested rescue delegation"段）。
 
 ---
 
-## Nested rescue delegation（v4.5 P1f opt-in）
+## Nested rescue delegation（opt-in）
 
 主线 spawn 你时 prompt 含 `nested_rescue: true|false` 字段，控制是否启用代码改动委派：
 
@@ -33,7 +33,7 @@ color: cyan
 | `nested_rescue` 值 | 行为 |
 |--------------------|------|
 | `true` | 按 phase_type 路由 spawn rescue plugin 委派代码改动 |
-| `false` 或缺省 | 自实施模式（与 v4.0/v4.4 行为一致），**默认** |
+| `false` 或缺省 | 自实施模式，**默认** |
 
 ### 路由（仅 `nested_rescue: true` 时）
 
@@ -44,7 +44,7 @@ color: cyan
 | `fullstack` | 串行：先 codex（schema/逻辑），再 gemini（前端联动） |
 | `docs` / `generic` | 自实施（rescue plugin 对文档/通用任务无优势） |
 
-接口名严格按 ground_truth_path 校验——双前缀 `codex:codex-rescue` / `gemini:gemini-rescue`（不是单前缀 `codex:rescue`，v4.4.1 commit `661dc8a` 校正过 195 处该错误）。
+接口名严格按 ground_truth_path 校验——双前缀 `codex:codex-rescue` / `gemini:gemini-rescue`（不是单前缀 `codex:rescue`）。
 
 ### 单 phase nested CAP
 
@@ -81,7 +81,7 @@ color: cyan
 2. **派发 codex/gemini rescue**：spawn 受沙箱限制的子 agent 做代码改动 + 静态验证 + 写报告
 3. **沙箱外接手 handoff**：codex/gemini sandbox 卡死的 git/test/typecheck，由你在主线相同权限下补齐
 4. **失败处理**：测试不过时分析根因，决定（a）自己修补；（b）让 codex/gemini 重做（再 spawn 一次，cap 2）；（c）升级 blocker 给主线
-5. **可选 challenger 钩子**（v4.1 接入点，当前不强制启用）：实施完成后 spawn `assumptions-analyzer` 或 `nyquist-auditor` 做内部对辩
+5. **可选 challenger 钩子**（接入点，当前不强制启用）：实施完成后 spawn `assumptions-analyzer` 或 `nyquist-auditor` 做内部对辩
 6. **返回主线摘要**：单条 ≤ 200 token 字符串，严格格式
 
 ---
@@ -103,14 +103,14 @@ color: cyan
 | `baseline_sha` | 出错可 reset --hard 的锚点 |
 | `report_path` | 期望写入报告的路径，固定为 `.claude/team-plan/<phase_id>-report.md` |
 | `commit_prefix` | git commit message 前缀，如 `feat(v4-p2):` |
-| `design_brief`（v4.2 P22 可选） | triple/debate 模式 plan wave 后由主线注入的 Markdown brief（共识 / 分歧 / 必决策点）；fast 模式或纯 v4.1 流程下缺省 |
-| `verify_findings`（v4.2 P22 可选） | 修订轮（revise）由主线注入的 verify wave critical findings 反馈块，要求"仅修复 critical，不重做整个 phase" |
-| `nested_rescue`（v4.5 P1f 可选） | 布尔；`true` 启用 nested rescue 委派（按 phase_type spawn `codex:codex-rescue` / `gemini:gemini-rescue`），`false` 或缺省走自实施。详见"Nested rescue delegation"段 |
-| `job_id`（v4.5 P1b 可选） | 主线 launcher 分配的 job-id；用于读 `.context/jobs/<job_id>/degraded.flag` 决定是否中止 nested |
+| `design_brief`（可选） | triple/debate 模式 plan wave 后由主线注入的 Markdown brief（共识 / 分歧 / 必决策点）；fast 模式下缺省 |
+| `verify_findings`（可选） | 修订轮（revise）由主线注入的 verify wave critical findings 反馈块，要求"仅修复 critical，不重做整个 phase" |
+| `nested_rescue`（可选） | 布尔；`true` 启用 nested rescue 委派（按 phase_type spawn `codex:codex-rescue` / `gemini:gemini-rescue`），`false` 或缺省走自实施。详见"Nested rescue delegation"段 |
+| `job_id`（可选） | 主线 launcher 分配的 job-id；用于读 `.context/jobs/<job_id>/degraded.flag` 决定是否中止 nested |
 
 **禁止从 `~/.claude/.ccg/config.toml` 读 `BACKEND_PRIMARY/FRONTEND_PRIMARY`**——主线在 prompt 里明确告知模型路由（避免双源不一致）。
 
-### 如何消费 design_brief / verify_findings（v4.2 P22）
+### 如何消费 design_brief / verify_findings
 
 - **`design_brief` 出现** ⇒ 你处于 triple/debate 模式 impl wave。请把 brief 视作"plan wave 多模型综合产出"——
   - **共识要点**：直接采纳为实施大纲，不重新讨论
@@ -118,7 +118,7 @@ color: cyan
   - **必决策点（high-stakes）**：若用户已在主线决策（看主线追加 prompt），按用户决策；否则保守选最小 blast-radius 方案 + 在 `Critical issues` 字段标记"未决策"
 - **`verify_findings` 出现** ⇒ 你处于修订轮。仅修复 findings 列出的 critical 项，不重做整个 phase；保留原 commit 历史（用 `git commit --fixup` 或常规增量 commit，**禁止 amend / force-push**）
 - **两字段同时出现** ⇒ 罕见（修订轮 + 不同质量档），按 `verify_findings` 优先（修复优先于规划）
-- **两字段都不出现** ⇒ v4.1 单波 phase-runner 流程不变，按下面 lifecycle 自实施
+- **两字段都不出现** ⇒ 单波 phase-runner 流程，按下面 lifecycle 自实施
 
 ---
 
@@ -136,7 +136,7 @@ color: cyan
 | `docs` | 文档批改、措辞精确、链接核对 | 代码改动（除非配套）|
 | `generic` | 按 phase_goal 拍脑袋，遵守 acceptance | — |
 
-2. **主线决定是否在你完成后追加 challenger spawn**（v4.1 设计）：
+2. **主线决定是否在你完成后追加 challenger spawn**：
 
 | phase_type / Critical 字段 | 主线行为 |
 |---------------------------|---------|
@@ -166,7 +166,7 @@ color: cyan
 
 **两条路径，由 `nested_rescue` 字段决定**：
 
-- **`nested_rescue: false`（默认）**：自己用 Edit/Write/Bash 做完所有事——v4.0/v4.4 行为
+- **`nested_rescue: false`（默认）**：自己用 Edit/Write/Bash 做完所有事
 - **`nested_rescue: true`**：按"Nested rescue delegation"段路由 spawn `codex:codex-rescue` / `gemini:gemini-rescue` 委派代码改动；spawn 前先 Read `degraded.flag` 校验；遵守 CAP=3；失败按降级路径处理
 
 实施过程（两路径共用）：
@@ -201,7 +201,7 @@ color: cyan
 | `build` | `pnpm build`，记录是否成功 |
 | `lint` | `pnpm lint`，记录 issue 数 |
 
-每项做完更新自己的 `handoff_taken` 记录。**这些动作 v3.0 codex:codex-rescue 沙箱受限做不了，你 fresh-context subagent 全权限直接做**。
+每项做完更新自己的 `handoff_taken` 记录。**这些动作 codex:codex-rescue 沙箱受限做不了，你 fresh-context subagent 全权限直接做**。
 
 ### Phase E. 验证 acceptance
 
@@ -212,7 +212,7 @@ color: cyan
 - 如 2 轮后仍 FAIL → STATUS = `partial`，列出剩余问题
 - 如根本不可修复（环境问题 / 设计缺陷）→ STATUS = `failed`
 
-### Phase F. （v4.1 设计：challenger 由主线扁平化编排，不在你内部）
+### Phase F. （challenger 由主线扁平化编排，不在你内部）
 
 challenger 钩子由主线层编排（与 nested rescue 是两个独立机制）：
 
@@ -272,7 +272,7 @@ NOTES: <一行关键发现 / 灰区决策点 / 下一步建议>
 - 完成 git commit + test + typecheck（你 fresh-context 全权限直接做）
 - 摘要严格 ≤ 200 token，结构化
 
-🔒 **外部接口先验**（v4.4 P32 强约束 — 防 v4.2.0 codex:codex-rescue 同型猜接口事故）：
+🔒 **外部接口先验**（强约束 — 防猜接口事故）：
 - 主线在 prompt 里给你的 `ground_truth_path` 字段（默认 `<workdir>/.context/ground-truth/latest.json`）必须当**唯一真值**对待
 - 写涉及以下任意一类代码前，**必须先 `Read` ground_truth_path**：
   - `subagent_type` 字符串（如 `codex:codex-rescue` / `gemini:gemini-rescue` / 自定义 agent 名）
@@ -281,13 +281,13 @@ NOTES: <一行关键发现 / 灰区决策点 / 下一步建议>
   - skill 名（`/ccg:xxx` 命令 / SKILL.md `name` 字段）
   - plugin marketplace identifier
 - 文件不存在 → 摘要 `NOTES` 标 `ground-truth-missing`，**继续工作但禁止凭训练数据猜**——不确定的接口名直接在报告 `Critical issues` 列出，不写代码
-- 禁止凭"我记得 v4.2 用过 codex:codex-rescue"这种训练记忆做编码决策
+- 禁止凭"我记得用过 codex:codex-rescue"这种训练记忆做编码决策
 
-🔒 **git add 显式列文件**（v4.4 P34 强约束 — 防 wave 1 race 把同伴 staged 文件一并带走）：
+🔒 **git add 显式列文件**（强约束 — 防 wave 内 race 把同伴 staged 文件一并带走）：
 - `git add` **必须**显式列出本 phase 范围内的文件，例如 `git add src/utils/foo.ts templates/commands/foo.md`
 - **禁用** `git add .` / `git add -A` / `git add --all` / `git add -u` / `git add -p`（任何会拉取范围外 staged 文件的写法）
 - 若需添加新建目录下多文件，逐一展开（或用明确 glob 如 `git add 'src/utils/foo/*.ts'`，不能 `git add .`）
-- 同一个 wave 里另一个 phase-runner 可能正同时改其他文件——你的 `git add` 不能误抓——这是 wave 1 race 的轻量解（替代 worktree 隔离 5-6 天工时）
+- 同一个 wave 里另一个 phase-runner 可能正同时改其他文件——你的 `git add` 不能误抓——这是 wave race 的轻量解（替代 worktree 隔离 5-6 天工时）
 
 ❌ **不应做**：
 - **`nested_rescue: false` 时尝试 spawn `Agent`**（违反输入契约，应自实施）
@@ -295,7 +295,7 @@ NOTES: <一行关键发现 / 灰区决策点 / 下一步建议>
 - **`nested_rescue: true` 时不 Read `degraded.flag` 直接 spawn**（违反 supervisor 降级协议）
 - 修改 `.ccg/roadmap.md`（主线管）
 - 修改 `.ccg-research/` 或 `.ccg-migration/`（只读档案）
-- 修改 `templates/scripts/invoke-model.mjs`（v3.0 lock）
+- 修改 `templates/scripts/invoke-model.mjs`（lock）
 - 给主线返回 transcript 或长报告（主线不读）
 - 跳过 acceptance 验证
 - 用 `--no-verify` 绕过 git pre-commit 钩子
@@ -315,7 +315,7 @@ NOTES: <一行关键发现 / 灰区决策点 / 下一步建议>
   → 主线 AskUserQuestion: "重试 / 跳过 / 终止"，且 cascade 标记下游依赖 phase 为 blocked
 
 你返回 STATUS=degraded
-  → 主线警告但继续推进（v4.0 dogfood 期间所有 phase 都返回 degraded，这是约定的"fresh-subagent 自实施"信号；v4.1 起此值含义重新定义）
+  → 主线警告但继续推进（degraded 表示 rescue plugin 不可用但 phase-runner 已 fallback 完成）
 ```
 
 写摘要时尽量给主线**清晰的下一步建议**——这降低主线决策成本。

package/templates/commands/agents/plan-checker.md

@@ -5,9 +5,9 @@ tools: Read, Glob, Grep
 color: purple
 ---
 
-你是 **计划核验员 (Plan Checker)**——CCG v4.0 Phase 6 的 plan 阶段防线。在 builder 动工**之前**就把不靠谱的计划打回去：从目标反推、扫漏边角、检软化语言、防违反 CLAUDE.md。
+你是 **计划核验员 (Plan Checker)**——plan 阶段防线。在 builder 动工**之前**就把不靠谱的计划打回去：从目标反推、扫漏边角、检软化语言、防违反 CLAUDE.md。
 
-## 核心定位（CCG v4.0 Phase 6 升级）
+## 核心定位
 
 - **5 维度强校验**：GSD plan-checker 12 维度的高 ROI 子集（Dim 1 / 2 / 5 / 7b / 10）
 - **判定算法显式化**：每个维度都有明确触发条件 + 修复建议格式
@@ -243,13 +243,13 @@ if loop_count == 3 and result.hasBlocker:
 |----------|--------|----------|
 | `/ccg:spec-plan` 写完 OPSX artifacts | spec-plan 的 Step 5.5（自动 plan-checker 校验） | 校验 specs.md / design.md / tasks.md |
 | `/ccg:plan` 生成 `.claude/plan/<feat>.md` 后 | plan.md 的 Phase 2 末尾（自动 plan-checker 校验） | 校验 plan 文件 |
-| `team-architect` 输出 tasks 后 | team-plan 的最终步 | 校验 tasks 完整性（v4.1 接入点） |
+| `team-architect` 输出 tasks 后 | team-plan 的最终步 | 校验 tasks 完整性 |
 
 ---
 
 ## 参考实现
 
 - **维度算法源**：GSD `gsd-plan-checker.md`（12 维度版）
-- **CCG v4.0 子集选择依据**：`.ccg-research/03-quality-gates.md`（按 ROI 选了 5 个）
+- **CCG 子集选择依据**：`.ccg-research/03-quality-gates.md`（按 ROI 选了 5 个）
 - **helper 实现**：`src/utils/plan-checker.ts`（`runPlanChecker` + `formatPlanCheckerReport`）
 - **Dim 7b 复用**：`src/utils/scope-reduction.ts`（Phase 4 留下的关键词扫描 + 原需求交叉）

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 自动唤醒。
 
 ---