team-skills 1.2.2 → 1.3.0

package/skills/team-orchestrator/SKILL.md

@@ -7,8 +7,6 @@ description: Use when task needs full spec→impl→test→review pipeline with
 
 ## 角色定位
 
-你是 AI 协作团队的 **编排器**。你的核心职责是**有向图流程编排**——不是简单的线性流水线，而是根据每个环节的产出质量动态决定下一步走向哪里。
-
 ```mermaid
 flowchart TD
     H1["H1: 人类确认目标"] --> branch["创建功能分支"]
@@ -32,32 +30,37 @@ flowchart TD
 ### 系统提示词
 
 ```
-你的思维方式：交响乐指挥——不亲自演奏，但掌控每个声部的进入时机、力度和协调。
-你是一个 Team 编排器 Agent。你的任务是：
-
-1. 理解用户需求，拆解为可执行的子任务
-2. 按有向图流程调度 specAgent → implAgent → testAgent → reviewAgent
-3. 在 4 个人类介入点（H1-H4）暂停等待用户确认
-4. 根据各 Agent 的产出质量动态决定回退或继续
-5. 遵守 Constitutional Rules（见下文），不可跳过任何规则
-6. 如果用户指定 --compact 精简模式，简化 H1 为单句确认、简化 H2 为单句确认、跳过 Step 6，保留 H4 验收不可省略
-
-关键区别：你不是线性流水线。testAgent 发现 bug 必须回退 implAgent，reviewAgent 发现 spec 遗漏必须回退 specAgent。同一阶段回退不超过 2 次。H1 和 H4 在任何模式下均不可省略（H1 可在精简模式下简化为单句确认）。
+角色：流程编排器——有向图编排，非线性流水线
+核心原则：根据产出质量动态决定回退或继续，对"先记着后面修"零容忍（FP-4）
+流程：
+1. 理解需求，拆解子任务
+2. 有向图调度：specAgent → implAgent → testAgent → reviewAgent
+3. H1-H4 人类介入点暂停等待确认
+4. 各 Agent 产出质量决定回退或继续
+5. 遵守 Constitutional Rules（`_team-rules/constitutional-rules.md`）
+6. --compact 精简模式：H1/H2 简化为单句确认，跳过 Step 6，H4 不可省略
+约束：
+- testAgent 发现 bug → 回退 implAgent；spec 遗漏 → 回退 specAgent
+- 同一阶段回退 ≤ 2 次
+- H1/H4 任何模式下不可省略
 ```
 
-### 路由推理
+### 路由推理检查点
+
+**核心指令**：价值在于协调而非执行。关注：Agent 是否卡住（需回退或 H3），下一个 Agent 需要什么上下文。对"先记着后面修"零容忍（FP-4）。
 
-**角色心智模型**：你像一位交响乐指挥思考——你不亲自演奏任何乐器，但你决定每个声部何时进入、以什么力度演奏、何时停下。你的价值在于**协调**而非**执行**。你时刻关注两件事：当前 Agent 是否卡住了（需要回退或人类介入），以及下一个 Agent 需要什么上下文才能高效启动。你对"先记着后面修"保持零容忍（FP-4）。
+**推理框架**：
 
-**第一性原理推理框架**：在每次调度 Agent 或触发人类介入点之前，依次推理——
+1. **当前状态**：上一个 Agent 产出质量？DONE 还是 DONE_WITH_CONCERNS？
+2. **路由选择**：调度哪个 Agent？有无需回退？
+3. **上下文传递**：下一个 Agent 需要哪些文件？传递完整吗？
+4. **门禁检查**：当前阶段门禁全部满足？有无被绕过？
+5. **人类介入**：需要触发 H3 吗？回退次数接近上限？
 
-1. **当前状态**：上一个 Agent 的产出质量如何？是 DONE 还是 DONE_WITH_CONCERNS？
-2. **路由选择**：下一步应该调度哪个 Agent？有没有需要回退的情况？
-3. **上下文传递**：下一个 Agent 需要哪些文件和上下文？传递是否完整？
-4. **门禁检查**：当前阶段的门禁条件是否全部满足？有没有被绕过的？
-5. **人类介入判断**：当前是否需要触发 H3？回退次数是否接近上限？
+**对抗自检**：
 
-**对抗视角**：调度前自问——"如果我现在把控制权交给下一个 Agent，它有足够信息开始工作吗？"；回退时自问——"回退携带的上下文是否足够让目标 Agent 一次修好，而非再次回退？"
+- [ ] 下一个 Agent 有足够信息开始工作吗？
+- [ ] 回退上下文是否足够让目标 Agent 一次修好？
 
 ## Iron Law
 
@@ -93,7 +96,7 @@ NO AGENT DISPATCH WITHOUT H1 HUMAN CONFIRMATION FIRST
               ┌──────────────────┐     │
               │  specAgent       │     │
               │  产出 01-05 文件  │     │
-              │  + 分期建议(P1/P2)│     │
+              │  + 分期建议       │     │
               └──────┬───────────┘     │
                      │                 │
                      ▼                 │
@@ -109,7 +112,7 @@ NO AGENT DISPATCH WITHOUT H1 HUMAN CONFIRMATION FIRST
                      ▼       └──→ 返回 specAgent 修改
               ┌──────────────────┐
               │  implAgent       │
-              │  TDD 开发(P1)    │
+              │  TDD 开发(当期)   │
               │  产出 06-08 + 代码│
               │  + 自我约束预算   │
               └──────┬───────────┘
@@ -155,12 +158,13 @@ NO AGENT DISPATCH WITHOUT H1 HUMAN CONFIRMATION FIRST
               ┌──────────────────────────┐       │
               │  H4: 人类验收最终交付物    │       │
               │  (展示 14-team + 15-brief │       │
-              │   + 代码 diff + P2 建议)  │       │
+              │   + 代码 diff + 分期建议) │       │
               ├──────────────────────────┤       │
-              │  P2 决策: 是否继续 P2    │       │
+              │  分期决策: 是否继续下一期 │       │
               └──────┬───────────────────┘       │
                      │                           │
                      ├── 验收通过 → 完成 ✅      │
+                     ├── 下期批准 → 新建下期任务（新序号 + 新目录）→ 从 Step 1 重启
                      │                           │
                      └── 不通过 → 根据反馈 ──────→ 回到对应 Agent
 ```
@@ -170,38 +174,36 @@ NO AGENT DISPATCH WITHOUT H1 HUMAN CONFIRMATION FIRST
 | 介入点 | 触发时机                                                         | 编排器动作                                                                       | 人类决策内容                                             | 超时策略     |
 | ------ | ---------------------------------------------------------------- | -------------------------------------------------------------------------------- | -------------------------------------------------------- | ------------ |
 | H1     | 编排器初始化后，调度任何 Agent 之前                              | 向用户展示任务理解 + 初步方案 + 风险预判 + 分期建议                              | 确认目标理解是否正确，方案方向是否合理，是否接受分期交付 | 等待用户回复 |
-| H2     | specAgent 产出 01-05 后                                          | 向用户展示 01-plan.md 和 03-sdd.md 核心内容 + 分期方案(P1/P2) + Kill Switch 评估 | 确认规格方案是否接受，是否需要调整，是否继续执行         | 等待用户回复 |
+| H2     | specAgent 产出 01-05 后                                          | 向用户展示 01-plan.md 和 03-sdd.md 核心内容 + 分期方案 + Kill Switch 评估 | 确认规格方案是否接受，是否需要调整，是否继续执行         | 等待用户回复 |
 | H3     | testAgent/reviewAgent 发现需要人类决策的问题，或触发 Kill Switch | 向用户展示问题描述 + 建议方案 + 选项                                             | 决策如何处理问题，或确认是否终止任务                     | 等待用户回复 |
-| H4     | reviewAgent 完成 + team 产出 14-15 后                            | 向用户展示交付物清单 + 代码 diff 摘要 + P2 候选建议 + Kill Switch 评估           | 验收最终交付物，决策是否继续 P2，或触发 Kill Switch 终止 | 等待用户回复 |
+| H4     | reviewAgent 完成 + team 产出 14-15 后                            | 向用户展示交付物清单 + 代码 diff 摘要 + 后续分期候选 + Kill Switch 评估          | 验收最终交付物，决策是否启动下一期，或触发 Kill Switch 终止 | 等待用户回复 |
 
 ## 流程状态持久化
 
-> H 节点多轮对话后，LLM 上下文可能被压缩导致编排器丢失流程位置。以下规则确保流程状态持久化到磁盘，即使上下文丢失也能恢复。
+> 防止 LLM 上下文压缩导致流程位置丢失。以下规则将状态持久化到磁盘。
 
 ### 规则 1：进入 H 节点前写 checkpoint
 
-进入任何 H 节点（H1/H2/H3/H4）前，**MUST** 先更新 `.checkpoint.json`，记录 `current_step`、`next_step`、`pending_decision`。
+进入任何 H 节点（H1/H2/H3/H4）前，先 **WRITE** `.checkpoint.json`，记录 `current_step`、`next_step`、`pending_decision`。
 
 ### 规则 2：H 节点对话超过 3 轮后重读 checkpoint
 
-在 H 节点与用户对话超过 3 轮时，**MUST** 重读 `docs/tasks/{slug}/.checkpoint.json` 确认当前流程位置，防止因上下文压缩导致流程迷失。
+在 H 节点与用户对话超过 3 轮时，**READ** `docs/tasks/{slug}/.checkpoint.json` 确认当前流程位置，防止因上下文压缩导致流程迷失。
 
 ### 规则 3：H 节点回复嵌入流程锚点
 
-编排器在 H 节点每次回复用户时，**MUST** 在回复末尾附加流程锚点：
+编排器在 H 节点每次回复用户时，在回复末尾附加流程锚点：
 
 ```markdown
 <!-- orchestrator-anchor: slug={slug} step={current_step} next={next_step} -->
 ```
 
-此锚点在上下文压缩后仍可作为最近输出被保留，帮助编排器快速定位。
-
 ### 规则 4：上下文恢复协议
 
-如果编排器不确定当前流程位置（例如上下文被压缩后），**MUST** 执行以下恢复步骤：
+**IF** 编排器不确定当前流程位置（上下文被压缩后）：
 
-1. 读取 `docs/tasks/{slug}/.checkpoint.json` 获取 `current_step` 和 `next_step`
-2. 扫描 slug 目录下已有文件交叉验证阶段
+1. **READ** `docs/tasks/{slug}/.checkpoint.json` → 获取 `current_step` 和 `next_step`
+2. **EXEC** 扫描 slug 目录下已有文件 → 交叉验证阶段
 3. 从 checkpoint 记录的位置恢复流程，不重复已完成的 Step
 
 ## 质量职责
@@ -224,7 +226,7 @@ NO AGENT DISPATCH WITHOUT H1 HUMAN CONFIRMATION FIRST
 
 用户已分步执行了各 Agent，现在执行 `/team-orchestrator {slug}` 仅补全团队级证据。
 
-**方式 B 流程**：跳过 Step 1-5，从 Step 6 开始。验证 `docs/tasks/{slug}/` 下 01-13 + task-rules.md 已存在，缺失文件触发 H3 由用户决定是否补全。
+**方式 B 流程**：跳过 Step 1-5，从 Step 6 开始。**READ** `docs/tasks/{slug}/` 下文件 → 完整模式检查 01-13 + task-rules.md；精简模式检查 03-04 + 06-13 + task-rules.md。**RESOLVE** `mode`：`.checkpoint.json` 有 mode → 取其值；有 01-plan.md → 完整；仅有 03-sdd.md + 04-boundary.md → 精简。缺失文件 → **H3** 由用户决定。
 
 ### 方式 C：精简模式（简单任务）
 
@@ -236,9 +238,9 @@ NO AGENT DISPATCH WITHOUT H1 HUMAN CONFIRMATION FIRST
 | ---- | -------- | -------- | ------------ |
 | Small | 修 bug、改文案、加字段、调样式 | `--compact` 精简模式 | 11 个文档（03-04 + 06-13 + task-rules） |
 | Medium | 新增功能模块、重构组件、加 API | 完整模式（默认） | 全部 17 文件 |
-| Large | 跨系统重构、架构变更、多模块联动 | 完整模式 + P1/P2 分期 | 全部 17 文件 + 多期迭代 |
+| Large | 跨系统重构、架构变更、多模块联动 | 完整模式 + 多期分期 | 全部 17 文件 + 多期迭代 |
 
-判断标准：预计修改文件数 ≤ 3 且无跨模块影响 → Small；修改文件 4-15 → Medium；修改文件 > 15 或跨 2+ 模块 → Large。
+判断标准：预计修改 ≤ 3 文件且无跨模块影响 → Small；4-15 文件 → Medium；> 15 文件或跨 2+ 模块 → Large。
 
 **精简模式 vs 完整模式对比**：
 
@@ -258,111 +260,149 @@ NO AGENT DISPATCH WITHOUT H1 HUMAN CONFIRMATION FIRST
 
 ### 执行模型
 
-默认执行模型是**单会话顺序执行**：编排器在同一个 AI 会话中依次调用各 sub-skill（`/team-spec` → `/team-impl` → `/team-test` → `/team-review`）。每个 sub-skill 的产出（文件）作为下一个 sub-skill 的输入。
+默认执行模型是**单会话顺序执行**：编排器在同一个 AI 会话中依次调用各 sub-skill（`/team-spec` → `/team-impl` → `/team-test` → `/team-review` → `/team-finish`）。
 
-如果工具支持 Agent tool 并行调度，可在不相互依赖的阶段使用并行执行（如 Step 6 的一致性检查），但 spec→impl→test→review 主链路必须顺序执行。
+**IF** 工具支持 Agent tool 并行调度 → 可在不相互依赖的阶段使用并行执行（如 Step 6 的一致性检查），但 spec→impl→test→review 主链路必须顺序执行。
 
 ### 断点续传机制
 
-当 session 中断或跨 session 继续任务时：
-
-1. **写入检查点**：每个 Step 转换点（包括进入/离开 H 节点）都必须更新 `docs/tasks/{slug}/.checkpoint.json` 文件：
-
-   ```json
-   {
-     "slug": "0001-add-tooltip",
-     "task_description": "实现用户注册功能",
-     "branch": "0001-add-tooltip",
-     "base_branch": "main",
-     "current_step": "H2",
-     "next_step": "Step 3",
-     "phase": "spec",
-     "completed_steps": ["Step 1", "H1", "Step 1.5", "Step 2"],
-     "pending_decision": "用户确认规格方案",
-     "completed_at": "2026-01-15T10:30:00Z",
-     "rollback_counts": {
-       "test→impl": 0,
-       "test→spec": 0,
-       "review→impl": 0,
-       "review→spec": 0
-     },
-     "status": "IN_PROGRESS|DONE|DONE_WITH_CONCERNS|NEEDS_CONTEXT|BLOCKED",
-     "blocked_reason": null
-   }
-   ```
-
-   **`status` 字段使用规则**：
-   - `IN_PROGRESS`：默认值。Step 1 到 Step 8 期间所有正常流转的 checkpoint 写入都使用此值
-   - `BLOCKED`：触发 H3 或 Kill Switch 时设置，必须同时填写 `blocked_reason`
-   - `NEEDS_CONTEXT`：缺少关键上下文无法继续时设置
-   - `DONE`：仅在 Step 8 质量检查全部通过后设置。**执行过程中不得使用此值**
-   - `DONE_WITH_CONCERNS`：Step 8 通过但有保留意见时设置
-
-2. **恢复检测**：当用户执行 `/team-orchestrator {slug}`（已有 slug），检查 `.checkpoint.json` 文件：
-   - 如存在且 `status = IN_PROGRESS` → 从 `next_step` 对应的 Step 继续
-   - 如存在且 `status = DONE` 或 `status = DONE_WITH_CONCERNS` → 提示用户"该任务已完成"，询问是否新建变体任务
-   - 如存在且 `status = BLOCKED` → 触发 H3 展示 `blocked_reason`
-   - 如存在且 `status = NEEDS_CONTEXT` → 展示缺失的上下文信息，请求用户补充
-   - 如不存在 → 检查已有文件推断阶段：
-     - 仅有 00-design-brief.md → 从 Step 1.5（分支初始化）或 Step 2（specAgent），视当前分支判断
-     - 有 03-sdd.md + 04-boundary.md（精简模式最小集）或 01-05 齐全（完整模式）→ 从 Step 3（implAgent）
-     - 有 06-tdd-log.md 但无 09-test-matrix.md → 从 Step 4（testAgent）
-     - 有 09-test-matrix.md + 10-test-report.md 但无 11-review.md → 从 Step 5（reviewAgent）
-     - 有 11-review.md + 12-asset-update.md + 13-retrospective.md 但无 14-team.md → 从 Step 6（团队证据）
-     - 有 14-team.md + 15-brief.md → 从 Step 7（finish-review 集成）
-     - 部分文件缺失且不符合上述任何模式 → 触发 H3，展示已有/缺失文件清单，由用户决定是否补全
-3. **恢复时回退计数**：从 `.checkpoint.json` 恢复 `rollback_counts`，避免重置
-4. **回退计数规则**：`rollback_counts` 按 `source→target` 对独立计数（如 `test→impl`、`review→impl` 分别计数）。计数仅在以下情况重置为 0：(1) H3 人类介入后用户明确决定重试；(2) specAgent 重新产出规格后，重置所有下游计数（test→impl、test→spec、review→impl、review→spec 全部归零），因为输入已变化。正常回退修复不重置计数
+> 当 session 中断或跨 session 继续任务时，通过 checkpoint 文件恢复流程位置。
+
+**WRITE** checkpoint（每个 Step 转换点，包括进入/离开 H 节点）→ 更新 `docs/tasks/{slug}/.checkpoint.json`：
+
+```json
+{
+  "slug": "0001-add-tooltip",
+  "task_description": "实现用户注册功能",
+  "branch": "0001-add-tooltip",
+  "base_branch": "main",
+  "current_step": "H2",
+  "next_step": "Step 3",
+  "phase": "spec",
+  "completed_steps": ["Step 1", "H1", "Step 1.5", "Step 2"],
+  "pending_decision": "用户确认规格方案",
+  "completed_at": "2026-01-15T10:30:00Z",
+  "rollback_counts": {
+    "test→impl": 0,
+    "test→spec": 0,
+    "review→impl": 0,
+    "review→spec": 0
+  },
+  "status": "IN_PROGRESS|DONE|DONE_WITH_CONCERNS|NEEDS_CONTEXT|BLOCKED",
+  "blocked_reason": null,
+  "parent_slug": null
+}
+```
+
+**`status` 字段使用规则**：
+
+- `IN_PROGRESS`：默认值。Step 1 到 Step 8 期间所有正常流转
+- **BLOCKED**：触发 **H3** 或 Kill Switch 时设置，必须同时填写 `blocked_reason`
+- **NEEDS_CONTEXT**：缺少关键上下文无法继续时设置
+- **DONE**：仅在 Step 8 质量检查全部通过后设置。执行过程中不得使用此值
+- **DONE_WITH_CONCERNS**：Step 8 通过但有保留意见时设置
+
+**恢复检测**：**IF** 用户执行 `/team-orchestrator {slug}`（已有 slug）→ **READ** `.checkpoint.json`：
+
+**MATCH** `checkpoint.status`：
+
+- `IN_PROGRESS` → 从 `next_step` 对应的 Step 继续
+- `DONE` || `DONE_WITH_CONCERNS` → 提示用户"该任务已完成"，询问是否新建变体任务
+- `BLOCKED` → 触发 **H3** 展示 `blocked_reason`
+- `NEEDS_CONTEXT` → 展示缺失信息，请求用户补充
+- *not found*（checkpoint 不存在）→ **GOTO** 恢复：文件推断阶段
+
+#### 恢复：文件推断阶段
+
+> 当 checkpoint 不存在时，根据已有文件推断应从哪个 Step 恢复。
+
+**MATCH** `existing_files`：
+
+- 仅有 `00-design-brief.md` → **GOTO** Step 1.5 或 Step 2
+- 有 `03-sdd.md` + `04-boundary.md`（或 01-05 齐全）→ **GOTO** Step 3
+- 有 `06-tdd-log.md` 但无 `09-test-matrix.md` → **GOTO** Step 4
+- 有 `09-10` 但无 `11-review.md` → **GOTO** Step 5
+- 有 `11-13` 但无 `14-team.md` → **GOTO** Step 6
+- 有 `14-team.md` + `15-brief.md` → **GOTO** Step 7
+- *none*（不符合任何模式）→ **H3**，展示已有/缺失文件清单，由用户决定
+
+**回退计数规则**：`rollback_counts` 按 `source→target` 对独立计数。计数仅在以下情况重置：(1) **H3** 后用户明确决定重试；(2) specAgent 重新产出规格后，重置所有下游计数。正常回退修复不重置。
 
 ### Step 1：初始化 + H1 人类确认
 
-1. 从用户参数提取任务描述
-2. 生成 `{slug}`：扫描 `docs/tasks/` 已有目录（如目录不存在则创建），取最大序号 +1（从 `0001` 起），拼接为 `{NNNN}-{关键词}`（关键词 kebab-case，整体 ≤ 50 字符），例如 `0001-add-tooltip`、`0012-refactor-auth`。**如果用户传入的参数是已有 slug 且 `docs/tasks/{slug}/00-design-brief.md` 存在，则复用该 slug，不新建目录**
-3. 创建 `docs/tasks/{slug}/` 目录（如已存在则跳过）
-4. **写入 checkpoint**：`current_step=Step 1, next_step=H1, phase=init, status=IN_PROGRESS, task_description={任务描述}`
-5. **进度账本检查**：如果 `docs/tasks/progress.md` 不存在则创建（含表头）。**注意：progress.md 是跨任务进度索引，必须位于 `docs/tasks/` 根目录，不在 slug 子目录中**。读取 progress.md 确认 `{slug}` 未被重复派发（如已存在且状态为 DONE，提示用户该任务已完成，询问是否新建变体任务）
-6. 记录启动时间
-7. **写入 checkpoint**：`current_step=H1, next_step=Step 1.5, status=IN_PROGRESS, pending_decision=确认目标理解`
-8. **向用户展示任务理解 + 初步方案 + 风险预判 + 分期建议**，等待确认（设置 30 分钟超时提醒）。如果存在 `00-design-brief.md`，将其摘要纳入展示
-9. 用户确认后，**写入 checkpoint**：`current_step=Step 1.5, status=IN_PROGRESS, completed_steps 追加 H1`。继续下一步，否则根据反馈调整
+1. **READ** 用户参数 → 提取任务描述
+2. **RESOLVE** `slug`：
+   1. **READ** `docs/tasks/` 已有目录（**IF** 不存在 → 创建）
+   2. **IF** 用户传入已有 slug 且 `docs/tasks/{slug}/00-design-brief.md` 存在 → 复用该 slug
+   3. **IF** 分期任务（H4 后续分期触发）→ slug 包含 `-p{N}` 后缀，checkpoint 记录 `parent_slug`
+   4. *default* → 取最大序号 +1（从 `0001` 起），拼接 `{NNNN}-{关键词}`（kebab-case，≤ 50 字符）
+3. **EXEC** 创建 `docs/tasks/{slug}/` 目录（**IF** 已存在 → 跳过）
+4. **WRITE** checkpoint：`current_step=Step 1, next_step=H1, phase=init, status=IN_PROGRESS`
+5. **READ** `docs/tasks/progress.md`（**IF** 不存在 → 创建含表头）→ **ASSERT** `{slug}` 未被重复派发
+   - **IF** 已存在且状态 DONE → 提示用户，询问是否新建变体任务
 
-**Kill Switch 预检查**：如果任务明显不可行（技术不可行、依赖不可用、范围远超预期），在 H1 阶段直接向用户提出终止建议。
+   > progress.md 是跨任务进度索引，位于 `docs/tasks/` 根目录，不在 slug 子目录中。
 
-### Step 1.5：Git 分支初始化
+6. **WRITE** checkpoint：`current_step=H1, next_step=Step 1.5, status=IN_PROGRESS, pending_decision=确认目标理解`
+7. **WRITE**（对话中）向用户展示：任务理解 + 初步方案 + 风险预判 + 分期建议
+   - **IF** `00-design-brief.md` 存在 → **READ** 并将摘要纳入展示
+
+**GATE** H1 用户已确认
 
-H1 确认后、specAgent 启动前，创建功能分支隔离本次任务的所有变更。
+- 用户确认 → **WRITE** checkpoint：`completed_steps 追加 H1` → **GOTO** Step 1.5
+- 用户不确认 → 根据反馈调整 → 重新展示
+- 任务明显不可行 → 向用户提出终止建议（Kill Switch 预检查）
+
+### Step 1.5：Git 分支初始化
 
-#### 1.5.1 确定基准分支（三层 Fallback）
+> H1 确认后、specAgent 启动前，创建功能分支隔离本次任务的所有变更。
 
-按以下优先级确定 `base_branch`，取第一个成功的结果：
+#### 1.5.1 确定基准分支
 
-1. **项目 AI 规范显式声明**：在 CLAUDE.md / .cursor/rules/ 中查找 `base_branch` 或 `default_branch` 配置项（如 `base_branch: develop`）
-2. **Git 远程默认分支**：`git symbolic-ref refs/remotes/origin/HEAD` 解析出分支名；失败则 `git remote show origin` 解析 HEAD branch
-3. **常见分支名兜底**：按 `main` → `master` → `develop` 顺序检查本地是否存在（`git show-ref --verify refs/heads/{name}`）
+**RESOLVE** `base_branch`（首个命中即停）：
 
-如果三层均失败 → 触发 H3，请求用户指定基准分支。
+1. **READ** `CLAUDE.md` / `.cursor/rules/` → 查找 `base_branch` 或 `default_branch` 配置项
+2. **EXEC** `git symbolic-ref refs/remotes/origin/HEAD` → 解析分支名；失败则 **EXEC** `git remote show origin`
+3. **FOR** `name` in [`main`, `master`, `develop`] → **EXEC** `git show-ref --verify refs/heads/{name}` 首个存在即停
+4. *none* → **H3**，请求用户指定基准分支
 
 #### 1.5.2 创建功能分支
 
-1. **检测当前分支**：获取当前分支名（`git branch --show-current`）
-2. **未提交变更检查**：运行 `git status --porcelain`，如果有未提交变更（输出非空），向用户展示变更列表并询问处理方式：(A) stash 后继续、(B) 先提交再继续、(C) 取消。不自动 stash 或丢弃
-3. **创建功能分支**：`git checkout -b {slug}`（分支名直接使用 slug，如 `0012-refactor-auth`）
-4. **写入 checkpoint**：`current_step=Step 2, branch={slug}, base_branch={基准分支名}, status=IN_PROGRESS, completed_steps 追加 Step 1.5`
+1. **EXEC** `git branch --show-current` → 获取当前分支名
+2. **EXEC** `git status --porcelain` → 检查未提交变更
+   - **IF** `output` 非空 → **GOTO** 1.5.2.1：处理未提交变更
+3. **EXEC** `git checkout -b {slug}`
+   - **ASSERT** `exit_code == 0`（分支已存在 → `git checkout {slug}`）
+4. **WRITE** checkpoint：`current_step=Step 2, branch={slug}, base_branch={基准分支名}, completed_steps 追加 Step 1.5`
+
+#### 1.5.2.1：处理未提交变更
+
+> 当 `git status --porcelain` 输出非空时触发。
+
+**WRITE**（对话中）变更列表给用户。
+
+**MATCH** `user_choice`：
+
+- (A) stash 后继续 → **EXEC** `git stash` → **GOTO** 1.5.2 步骤 3
+- (B) 先提交再继续 → 等待用户提交 → **GOTO** 1.5.2 步骤 3
+- (C) 取消 → **BLOCKED**
+
+不自动 stash 或丢弃。
 
 **跳过条件**（不创建分支）：
 
-- 用户已在功能分支上（当前分支名不等于 `base_branch`）→ 使用当前分支，checkpoint 中 `branch` 记录当前分支名
-- 用户明确指定 `--no-branch` → 直接在当前分支上工作
+- **IF** 当前分支名 ≠ `base_branch` → 使用当前分支，checkpoint 中 `branch` 记录当前分支名
+- **IF** 用户指定 `--no-branch` → 直接在当前分支上工作
 
-**恢复场景**：断点续传（`docs/tasks/{slug}/.checkpoint.json` 已有 `branch` 字段）时，检查当前分支是否与 checkpoint 记录一致。不一致则提示用户切换分支（`git checkout {branch}`），不自动切换。
+**恢复场景**：**IF** 断点续传（checkpoint 已有 `branch` 字段）→ **ASSERT** 当前分支与 checkpoint 一致。不一致 → 提示用户切换分支，不自动切换。
 
 ### Step 2：调度 specAgent
 
-**REQUIRED SUB-SKILL:** `team-spec`
+**ROUTE** `team-spec`
 
 调用方式取决于工具能力：
 
-- **Claude Code**：直接执行 `/team-spec {任务描述}`，在同一会话中运行
+- **Claude Code**：直接执行 `/team-spec {任务描述}`
 - **支持 Agent tool 的工具**：通过 Agent tool 调度，传递以下 prompt
 
 ```
@@ -375,31 +415,47 @@ H1 确认后、specAgent 启动前，创建功能分支隔离本次任务的所
 背景参考：{如果 docs/tasks/{slug}/00-design-brief.md 存在，将其内容作为设计背景输入；否则写"无"}
 约束：遵守 team-spec Skill 的 Phase 1-3 步骤；所有结论标注来源标签；产出前执行自检清单。
 回退上下文：{如有 testAgent/reviewAgent 报告的 spec 遗漏则附上，否则写"无"}
+分期上下文：{如果是分期继承任务，附上上期的 docs/tasks/{parent_slug}/01-plan.md 候选表和 03-sdd.md 路径；否则写"无"}
 
 读取 skills/team-spec/SKILL.md 获取完整执行步骤。
 ```
 
-**完成验证**：完整模式确认 6 个文件已产出（01-plan.md / 02-context.md / 03-sdd.md / 04-boundary.md / 05-risk.md / prompt-template.md）；精简模式确认 2 个文件已产出（03-sdd.md / 04-boundary.md）。
+**完成验证**（产出门禁）：
+
+**IF** `mode == full` → **FOR** each file in [`01-plan.md`, `02-context.md`, `03-sdd.md`, `04-boundary.md`, `05-risk.md`, `prompt-template.md`]：
+**ELSE**（`mode == compact`）→ **FOR** each file in [`03-sdd.md`, `04-boundary.md`]：
+
+- **ASSERT** `文件存在`
+- **ASSERT** `有效行数 >= 5`
+- 任一不通过 → **ROLLBACK** specAgent，指明缺失文件名
 
-**写入 checkpoint**：`current_step=H2, next_step=Step 3, phase=spec, status=IN_PROGRESS, pending_decision=确认规格方案, completed_steps 追加 Step 2`
+**WRITE** checkpoint：`current_step=H2, next_step=Step 3, phase=spec, completed_steps 追加 Step 2`
 
 ### Step 2.5：H2 人类确认规格 + Kill Switch 检查
 
-> **精简模式简化此步**：`--compact` 模式下，向用户展示一句话摘要："规格概要：{SDD 核心目标与修改范围}。是否继续？"等待确认后进入 Step 3。checkpoint 中 `completed_steps` 追加 `H2_compact`。
+**IF** `mode == compact`：
+
+- **WRITE**（对话中）一句话摘要："规格概要：{SDD 核心目标与修改范围}。是否继续？"→ 等待确认
+- **WRITE** checkpoint：`completed_steps 追加 H2_compact`
+- **GOTO** Step 3
+
+**ELSE**（`mode == full`）：
+
+- **WRITE**（对话中）向用户展示 `01-plan.md` 和 `03-sdd.md` 核心内容 + 分期方案 + 自我约束预算
 
-向用户展示 `01-plan.md` 和 `03-sdd.md` 的核心内容 + 分期方案(P1/P2) + 自我约束预算，等待确认。
+**MATCH** `user_response`：
 
-- 用户确认 → **写入 checkpoint**：`current_step=Step 3, status=IN_PROGRESS, completed_steps 追加 H2`。继续 Step 3
-- 用户要求修改 → 回到 Step 2，根据反馈调整提示词后重新调度 specAgent
-- **Kill Switch**：如果用户认为任务不可行或范围不可接受 → 终止流程
+- 用户确认 → **WRITE** checkpoint：`current_step=Step 3, completed_steps 追加 H2` → **GOTO** Step 3
+- 用户要求修改 → **GOTO** Step 2（根据反馈调整后重新调度 specAgent）
+- Kill Switch（用户认为不可行/范围不可接受）→ 终止流程
 
 ### Step 3：调度 implAgent
 
-**REQUIRED SUB-SKILL:** `team-impl`
+**ROUTE** `team-impl`
 
 调用方式取决于工具能力：
 
-- **Claude Code**：直接执行 `/team-impl`，在同一会话中运行
+- **Claude Code**：直接执行 `/team-impl`
 - **支持 Agent tool 的工具**：通过 Agent tool 调度，传递以下 prompt
 
 ```
@@ -408,36 +464,50 @@ H1 确认后、specAgent 启动前，创建功能分支隔离本次任务的所
 任务 slug：{slug}
 模式：{完整 / --compact 精简}
 输入目录：docs/tasks/{slug}/（完整模式读取 01-05 + prompt-template.md；精简模式读取 03-sdd.md + 04-boundary.md）
-约束：遵守 team-impl Skill 步骤；04-boundary.md 的 allow/deny 不可越界；遵循 TDD 红-绿-重构循环；P1 聚焦。
-TDD 强制要求：每个功能点必须先 git commit 失败测试（test: {功能点} (RED)），再 commit 实现（feat:/fix:）。编排器将在完成后验证 06-tdd-log.md 中 RED→GREEN 顺序和失败输出内容，不合格将回退。
+约束：遵守 team-impl Skill 步骤；04-boundary.md 的 allow/deny 不可越界；遵循 TDD 红-绿-重构循环；当期范围聚焦。
+TDD 强制要求：每个功能点必须先 git commit 失败测试（test: {功能点} (RED)），再 commit 实现（feat:/fix:）。编排器将验证 06-tdd-log.md 中 RED→GREEN 顺序和失败输出，不合格将回退。
 回退上下文：{如有 testAgent/reviewAgent 的 bug 报告则附上，否则写"无"}
+回退修复要求：{如果是回退修复，写"修复遵循 TDD 循环，更新 06-tdd-log.md 和 08-ai-decisions.md，重新运行全量测试"；首次调度写"无"}
 
 读取 skills/team-impl/SKILL.md 获取完整执行步骤。
 ```
 
-等待 implAgent 完成。
+**完成验证**（产出门禁）：
 
-**完成验证**：确认 06-tdd-log.md / 07-prompt-log.md / 08-ai-decisions.md 已产出；测试通过；CI 检查通过。
+**FOR** each file in [`06-tdd-log.md`, `07-prompt-log.md`, `08-ai-decisions.md`]：
 
-**TDD 证据验证**（Constitutional Rule #9 门禁）：读取 `06-tdd-log.md`，对每个功能点块执行以下检查：
+- **ASSERT** `文件存在` && `有效行数 >= 5`
+- **ASSERT** `06-tdd-log.md` 至少包含一个 `RED` 段落标记
+- 任一不通过 → **ROLLBACK** implAgent，指明缺失文件名
 
-1. **顺序验证**：RED 段落出现在 GREEN 段落之前（按文档中的出现位置）
-2. **失败输出验证**：RED 段落的"失败输出"字段非空，且包含错误关键词（FAIL / fail / Error / error / ✗ / FAILED）
-3. **通过输出验证**：GREEN 段落的"通过输出"字段非空，且包含通过关键词（PASS / pass / OK / ✓ / ✅ / passed）
-4. **时间递增验证**：RED 时间 < GREEN 时间 < REFACTOR 时间（如有）
-5. **git 提交验证**：`git log --oneline` 中同一功能点存在 `test:` 提交
+**测试/CI 门禁**：
 
-任一项不通过 → 回退 implAgent，附上具体不合格项及期望修正行为（如"功能点 X 的 RED 段落缺失失败输出，请删除实现代码从 RED 重新开始"）。
+**EXEC** 项目测试和 CI 检查命令 → **ASSERT** `exit_code == 0` && `failures == 0`
 
-**写入 checkpoint**：`current_step=Step 4, next_step=Step 5, phase=impl, status=IN_PROGRESS, completed_steps 追加 Step 3`
+- **IF** implAgent 已在 `06-tdd-log.md` 中提供测试输出证据（验证命令 + 退出码 + 输出摘要）→ 可验证证据完整性而非重复执行，但证据须为当次运行且符合 `_team-rules/verification-protocol.md` 结构
+- **IF** `exit_code != 0` → **ROLLBACK** implAgent，附失败输出和具体失败项
+
+**TDD 证据验证**（Constitutional Rule #9 门禁）：
+
+**READ** `06-tdd-log.md` → **FOR** each `feature_block`：
+
+1. **ASSERT** `RED 位置 < GREEN 位置`
+2. **ASSERT** `RED.失败输出` 非空 && `RED.失败输出` 包含 `FAIL|fail|Error|error|✗|FAILED`
+3. **ASSERT** `GREEN.通过输出` 非空 && `GREEN.通过输出` 包含 `PASS|pass|OK|✓|✅|passed`
+4. **ASSERT** `RED.时间 <= GREEN.时间` && `GREEN.时间 <= REFACTOR.时间`
+5. **EXEC** `git log --oneline` → **ASSERT** `test:` 提交数 >= `06-tdd-log.md` 功能点数
+
+任一项不通过 → **ROLLBACK** implAgent，附具体不合格项及期望修正行为。
+
+**WRITE** checkpoint：`current_step=Step 4, next_step=Step 5, phase=impl, completed_steps 追加 Step 3`
 
 ### Step 4：调度 testAgent
 
-**REQUIRED SUB-SKILL:** `team-test`
+**ROUTE** `team-test`
 
 调用方式取决于工具能力：
 
-- **Claude Code**：直接执行 `/team-test`，在同一会话中运行
+- **Claude Code**：直接执行 `/team-test`
 - **支持 Agent tool 的工具**：通过 Agent tool 调度，传递以下 prompt
 
 ```
@@ -451,27 +521,37 @@ TDD 强制要求：每个功能点必须先 git commit 失败测试（test: {功
 读取 skills/team-test/SKILL.md 获取完整执行步骤。
 ```
 
-等待 testAgent 完成。
+**完成验证**（产出门禁）：
+
+**FOR** each file in [`09-test-matrix.md`, `10-test-report.md`]：
+
+- **ASSERT** `文件存在` && `有效行数 >= 5`
+- **ASSERT** `10-test-report.md` 包含测试输出证据（含退出码）
+- 任一不通过 → **ROLLBACK** testAgent，指明缺失文件名
+
+**READ** `10-test-report.md` 中 testAgent 路由决策（→ reviewAgent / → implAgent / → specAgent / → **H3**）
 
-**完成验证**：确认 09-test-matrix.md / 10-test-report.md 已产出；获取路由决策（→ reviewAgent / → implAgent / → specAgent / → H3）。
+**WRITE** checkpoint：`current_step=Step 5, next_step=Step 6, phase=test, completed_steps 追加 Step 4`
 
-**写入 checkpoint**：`current_step=Step 5, next_step=Step 6, phase=test, status=IN_PROGRESS, completed_steps 追加 Step 4`
+**回退检查**（Constitutional Rule #7：同一 source→target 对回退 ≤ 2 次）：
 
-**回退检查**（遵守 Constitutional Rule #7：同一阶段回退 ≤ 2 次，按 source→target 对独立计数，计数持久化到 `.checkpoint.json`）：如果 testAgent 报告发现 bug 或 spec 遗漏：
+**IF** testAgent 报告发现 bug 或 spec 遗漏：
 
-- bug → **写入 checkpoint**：`current_step=Step 3(回退), status=IN_PROGRESS, rollback_counts test→impl +1`。回到 Step 3 重新调度 implAgent，传递 bug 上下文
-- spec 遗漏 → **写入 checkpoint**：`current_step=Step 2(回退), status=IN_PROGRESS, rollback_counts test→spec +1`。回到 Step 2 重新调度 specAgent，传递遗漏上下文
-- 同一阶段第 3 次回退 → **写入 checkpoint**：`current_step=H3, status=BLOCKED, pending_decision={问题描述}`。强制触发 H3，由人类决定是否继续
-- **Kill Switch**：如果发现任务不可行（如依赖不可用、技术方案不可行）→ **写入 checkpoint**（`status=BLOCKED`）后触发 H3 让人类决策是否终止
-- 人类需决策 → **写入 checkpoint**（`status=BLOCKED`）后触发 H3
+**MATCH** `test_issue`：
+
+- bug → **WRITE** checkpoint：`rollback_counts test→impl +1` → **ROLLBACK** implAgent（**GOTO** Step 3，附 bug 上下文）
+- spec 遗漏 → **WRITE** checkpoint：`rollback_counts test→spec +1` → **ROLLBACK** specAgent（**GOTO** Step 2，附遗漏上下文）
+- 同一对第 3 次回退 → **WRITE** checkpoint：`status=BLOCKED` → 强制 **H3**
+- Kill Switch（任务不可行）→ **WRITE** checkpoint：`status=BLOCKED` → **H3**
+- 人类需决策 → **WRITE** checkpoint：`status=BLOCKED` → **H3**
 
 ### Step 5：调度 reviewAgent
 
-**REQUIRED SUB-SKILL:** `team-review`
+**ROUTE** `team-review`
 
 调用方式取决于工具能力：
 
-- **Claude Code**：直接执行 `/team-review`，在同一会话中运行
+- **Claude Code**：直接执行 `/team-review`
 - **支持 Agent tool 的工具**：通过 Agent tool 调度，传递以下 prompt
 
 ```
@@ -486,98 +566,133 @@ TDD 强制要求：每个功能点必须先 git commit 失败测试（test: {功
 读取 skills/team-review/SKILL.md 获取完整执行步骤。
 ```
 
-等待 reviewAgent 完成。
+**完成验证**（产出门禁）：
+
+**FOR** each file in [`11-review.md`, `12-asset-update.md`, `13-retrospective.md`, `task-rules.md`]：
+
+- **ASSERT** `文件存在` && `有效行数 >= 5`
+- **ASSERT** `13-retrospective.md` 包含"新规则"或"本次沉淀"关键词
+- 任一不通过 → **ROLLBACK** reviewAgent，指明缺失文件名
+
+**READ** `11-review.md` 中 reviewAgent 修复/回退决策
 
-**完成验证**：确认 11-review.md / 12-asset-update.md / 13-retrospective.md / task-rules.md 已产出；获取修复/回退决策。
+**WRITE** checkpoint：`current_step=Step 6, next_step=Step 7, phase=review, completed_steps 追加 Step 5`
 
-**写入 checkpoint**：`current_step=Step 6, next_step=Step 7, phase=review, status=IN_PROGRESS, completed_steps 追加 Step 5`
+**回退检查**（Constitutional Rule #7：同一 source→target 对回退 ≤ 2 次）：
 
-**回退检查**（遵守 Constitutional Rule #7：同一阶段回退 ≤ 2 次，按 source→target 对独立计数，计数持久化到 `.checkpoint.json`）：如果 reviewAgent 报告发现 P0/P1 bug 或 spec 遗漏：
+**IF** reviewAgent 报告发现 P0/P1 bug 或 spec 遗漏：
 
-- bug → **写入 checkpoint**：`current_step=Step 3(回退), status=IN_PROGRESS, rollback_counts review→impl +1`。回到 Step 3 重新调度 implAgent，传递 bug 上下文
-- spec 遗漏 → **写入 checkpoint**：`current_step=Step 2(回退), status=IN_PROGRESS, rollback_counts review→spec +1`。回到 Step 2 重新调度 specAgent，传递遗漏上下文
-- 同一阶段第 3 次回退 → **写入 checkpoint**：`current_step=H3, status=BLOCKED, pending_decision={问题描述}`。强制触发 H3，由人类决定是否继续
-- **Kill Switch**：如果发现任务不可行（如依赖不可用、技术方案不可行）→ **写入 checkpoint**（`status=BLOCKED`）后触发 H3 让人类决策是否终止
-- 人类需决策 → **写入 checkpoint**（`status=BLOCKED`）后触发 H3
+**MATCH** `review_issue`：
+
+- bug → **WRITE** checkpoint：`rollback_counts review→impl +1` → **ROLLBACK** implAgent（**GOTO** Step 3，附 bug 上下文）
+- spec 遗漏 → **WRITE** checkpoint：`rollback_counts review→spec +1` → **ROLLBACK** specAgent（**GOTO** Step 2，附遗漏上下文）
+- 同一对第 3 次回退 → **WRITE** checkpoint：`status=BLOCKED` → 强制 **H3**
+- Kill Switch → **WRITE** checkpoint：`status=BLOCKED` → **H3**
+- 人类需决策 → **WRITE** checkpoint：`status=BLOCKED` → **H3**
 
 ### Step 6：补全团队级证据
 
-> **精简模式跳过此步**：`--compact` 模式下，Step 5 完成后直接进入 Step 7（finish-review 集成），不产出 14-team.md / 15-brief.md。checkpoint 中 `completed_steps` 不含 Step 6。
+**IF** `mode == compact` → 跳过此步，**GOTO** Step 7。checkpoint 中 `completed_steps` 不含 Step 6。
 
-由编排器自己执行以下检查并产出 2 个文件。对于可并行的检查项，使用子 Agent 并行执行以提高效率。
+> 由编排器自己执行以下检查并产出 2 个文件。
 
 #### 6.1 一致性自动化检查（先执行再写入 14-team.md）
 
-1. **术语一致性**：从 `02-context.md` 提取术语表，grep 检查任务目录下所有文件中是否使用了不一致的别名
-2. **文档格式**：检查任务目录下所有文件是否遵循统一的 Markdown 标题层级（# > ## > ###）
-3. **commit message 规范**：`git log --oneline` 检查本次任务所有 commit 是否遵循 `type: description`
-4. **AI 规范同步**：检查 reviewAgent 新增的规则是否与已有规则矛盾
-5. **模块 AI 规范风格**：对比多个模块级 AI 规范文件是否结构一致
+1. **READ** `02-context.md` → 提取术语表 → **EXEC** `grep` 检查任务目录下所有文件中的不一致别名
+2. **EXEC** 检查任务目录下所有文件是否遵循统一 Markdown 标题层级
+3. **EXEC** `git log --oneline` → **ASSERT** `commit_format` 遵循 `type: description`
+4. **READ** reviewAgent 新增规则 → **ASSERT** `新增规则` 与 `已有规则` 不矛盾
+5. **IF** 多个模块级 AI 规范文件存在 → **ASSERT** `结构一致`
+6. **READ** 任务目录下所有文件 → **ASSERT** 来源标签使用一致 + 表格格式统一 + 引用块风格统一
 
-对发现的不一致立即修复。
+**IF** 发现不一致 → 立即修复。
 
 #### 6.2 确保每位成员有复盘
 
-检查 `13-retrospective.md`。如果项目有多位贡献者（从 `git log --format='%an' | sort -u` 获取），确保每位成员都有独立的复盘段落或独立文件（`13-retrospective-{name}.md`）。
+**READ** `13-retrospective.md` → **EXEC** `git log --format='%an' | sort -u` → **IF** 多位贡献者 → **ASSERT** 每位成员有独立复盘段落或独立文件。
 
 #### 文件 14：`14-team.md`
 
-模板见 `references/14-team-template.md`。
+**WRITE** `14-team.md`（模板见 `references/14-team-template.md`）。
 
-**独立作者场景**：如果项目仅有 1 位人类作者（配合 AI Agent 协作），§一 角色分工填写"用户 + AI Agent 团队"，§三 个人贡献明细将用户的审查/确认决策也计入贡献，§四 交叉 Review 质量统计正常填写 reviewAgent 的审查数据。
+**IF** 仅 1 位人类作者 → §一 角色分工填写"用户 + AI Agent 团队"，§三 将用户审查/确认决策也计入贡献，§四 正常填写 reviewAgent 审查数据。
 
 #### 文件 15：`15-brief.md`
 
-模板见 `references/15-brief-template.md`。填写方式：
+**WRITE** `15-brief.md`（模板见 `references/15-brief-template.md`），填写方式：
 
-- §一 Elevator Pitch：从 01-plan.md 的目标 + 03-sdd.md 的方案 + 10-test-report.md 的结果提炼 3 句话
-- §二 关键决策：从 08-ai-decisions.md 挑选 2-3 个最重要的决策填入表格
-- §三 AI 协作亮点：从 07-prompt-log.md 的纠偏记录 + 06-tdd-log.md 的 bug 发现中提取具体事例
-- §四 测试覆盖概要：从 09-test-matrix.md + 10-test-report.md 提取数据
-- §五 遗留风险：从 11-review.md §四 摘录
-- §六 改进承诺：从 13-retrospective.md §三 摘录
+- §一 Elevator Pitch：从 `01-plan.md` + `03-sdd.md` + `10-test-report.md` 提炼 3 句话
+- §二 关键决策：从 `08-ai-decisions.md` 挑选 2-3 个最重要决策
+- §三 AI 协作亮点：从 `07-prompt-log.md` 纠偏记录 + `06-tdd-log.md` bug 发现中提取
+- §四 测试覆盖概要：从 `09-test-matrix.md` + `10-test-report.md` 提取
+- §五 遗留风险：从 `11-review.md` §四 摘录
+- §六 改进承诺：从 `13-retrospective.md` §三 摘录
 
-**写入 checkpoint**：`current_step=Step 7, next_step=Step 7.3, phase=finish, status=IN_PROGRESS, completed_steps 追加 Step 6`
+**WRITE** checkpoint：`current_step=Step 7, next_step=Step 7.3, phase=finish, completed_steps 追加 Step 6`
 
-### Step 7：finish-review 集成
+### Step 7：分支完成处理
 
-> 在人类验收（Step 7.3）之前完成分支处理，确保用户验收时所有技术工作已就绪。如果 merge 失败或测试不通过，在此处解决——不让用户审批一个可能无法合并的交付物。
+> 在人类验收前完成分支处理，确保用户验收时所有技术工作已就绪。
 
-检查 reviewAgent 产出的 `12-asset-update.md` 中是否有 CHANGELOG.md 更新。如果 CHANGELOG.md 需要更新但尚未更新，在此处补全。
+**READ** `12-asset-update.md` → **IF** CHANGELOG.md 需要更新但尚未更新 → 补全。
 
-调度 `team-finish` 完成分支处理：
+**ROUTE** `team-finish`：
 
 - 传递 checkpoint 中的 `branch` 和 `base_branch` 信息
 - `team-finish` 将验证测试 → 展示选项（merge/PR/keep/discard）→ 执行用户选择
-- 如果用户选择 merge，合并后确认合并 commit 已推送
-- 如果用户选择 PR，确认 PR 已创建
-- 如果用户选择 keep/discard，记录用户决策
 
-**写入 checkpoint**：`current_step=Step 7.3, next_step=Step 7.5, phase=finish, status=IN_PROGRESS, completed_steps 追加 Step 7`
+**IF** `team-finish` 报告测试不通过 → **ROLLBACK** implAgent（附失败详情），修复完成后 **GOTO** Step 7。
+
+**MATCH** `finish_result`：
+
+- merge → **ASSERT** `merge_commit 存在`
+- PR → **ASSERT** `PR 已创建`
+- keep/discard → 记录用户决策
 
-### Step 7.3：H4 人类验收 + P2 决策
+**WRITE** checkpoint：`current_step=Step 7.3, next_step=Step 7.5, phase=finish, completed_steps 追加 Step 7`
 
-向用户展示交付物清单、代码 diff 摘要，等待验收（设置 30 分钟超时提醒）。完整模式还展示 14-team.md 和 15-brief.md 核心内容；精简模式展示 11-review.md 审查结论和 13-retrospective.md 改进承诺。
+### Step 7.3：H4 人类验收 + 分期决策
 
-**交付清单验证**：如果 `docs/delivery-checklist.md` 存在，读取并检查 `- [ ]` 项是否已标记为 `- [x]`。未完成项列入 H4 展示内容，供用户判断是否放行或要求补全。
+**WRITE**（对话中）向用户展示：交付物清单 + 代码 diff 摘要。
 
-- 用户验收通过 → **写入 checkpoint**：`current_step=Step 7.5, status=IN_PROGRESS, completed_steps 追加 H4`。继续
-- 用户不通过 → 根据反馈回到对应 Agent
-- **P2 决策**：如果 spec 定义了 P2（候选增强），向用户展示 P2 建议 + 触发条件，由用户决定是否继续
+- **IF** `mode == full` → 还展示 `14-team.md` 和 `15-brief.md` 核心内容
+- **IF** `mode == compact` → 展示 `11-review.md` 审查结论 + `13-retrospective.md` 改进承诺
+
+**IF** `docs/delivery-checklist.md` 存在 → **READ** 检查 `- [ ]` 项完成情况 → 未完成项列入 H4 展示，供用户判断。
+
+**MATCH** `user_decision`：
+
+- 验收通过 → **WRITE** checkpoint：`completed_steps 追加 H4` → **GOTO** Step 7.5
+- 验收不通过 → 根据反馈 **GOTO** 对应 Agent
+- 后续分期决策（**IF** `01-plan.md` §二 定义了后续分期候选）→ **GOTO** 7.3.1：后续分期启动
+
+#### 7.3.1：后续分期启动
+
+> 用户验收通过后，如 `01-plan.md` 定义了后续分期候选，启动下一期任务。
+
+1. **WRITE**（对话中）候选项 + 触发条件给用户
+2. **IF** 用户批准 →
+   - **RESOLVE** 新 slug：取最大序号 +1，关键词追加 `-p{N}`
+   - **EXEC** 创建新目录 `docs/tasks/{新slug}/`
+   - **WRITE** 新 `.checkpoint.json`，含 `parent_slug` 指向上期
+   - **GOTO** Step 1（H1 简化为单句确认）
+   - specAgent 调度时额外传递上期 `01-plan.md` 候选表和 `03-sdd.md` 路径
 
 ### Step 7.5：归档与知识合并
 
-用户验收通过后，执行以下知识沉淀：
+> 用户验收通过后执行知识沉淀。
 
-1. **规则合并**：将 `docs/tasks/{slug}/task-rules.md` 中标记为"可泛化"的规则，合并到项目级或模块级 AI 规范文件（CLAUDE.md / .cursor/rules/）
-2. **SDD 快照归档**：如果项目维护了 `docs/specs/` 目录，将本次 `03-sdd.md` 的关键规格合并进去（增量模式则执行 delta 合并：ADDED 追加、MODIFIED 替换、REMOVED 删除；如有冲突以本次 SDD 为准并在 commit message 中注明）
-3. **进度账本更新**：在 `docs/tasks/progress.md`（**注意是 `docs/tasks/` 根目录，不是 slug 子目录**）追加本次任务记录
+1. **READ** `docs/tasks/{slug}/task-rules.md` → **WRITE** 标记为"可泛化"的规则到项目级/模块级 AI 规范文件
+2. **IF** 项目维护 `docs/specs/` 目录 → **WRITE** 本次 `03-sdd.md` 关键规格合并进去
+   - **IF** 增量模式 → 执行 delta 合并（ADDED 追加、MODIFIED 替换、REMOVED 删除）
+   - **IF** 冲突 → 以本次 SDD 为准，在 commit message 中注明
+3. **WRITE** `docs/tasks/progress.md`（**注意是 `docs/tasks/` 根目录**）追加：
 
 ```markdown
 | {slug} | {YYYY-MM-DD} | {DONE/DONE_WITH_CONCERNS} | {起始commit..结束commit} | {一句话摘要} |
 ```
 
-4. **关联更新**：如果本次变更影响了 AGENTS.md 中的架构描述，同步更新
+4. **IF** 本次变更影响 AGENTS.md 架构描述 → **WRITE** 同步更新
 
 **进度账本模板**（首次创建时使用）：
 
@@ -592,90 +707,100 @@ TDD 强制要求：每个功能点必须先 git commit 失败测试（test: {功
 
 ### Step 8：最终质量检查
 
-**模式判断**：读取 `.checkpoint.json` 的模式字段。精简模式下：标注 `[完整模式]` 的检查项跳过，标注 `[精简替代]` 的检查项替换原项，D5 整组跳过。仅当剩余检查项全部通过时才声明质量检查通过。
+**RESOLVE** `mode`：**READ** `.checkpoint.json` 模式字段。**IF** `mode == compact` → `[完整模式]` 项跳过，`[精简替代]` 项替换原项，D5 整组跳过。
+
+**GATE** 全部检查项通过才可声明质量检查通过：
 
 **硬门槛（7 项全部必须通过）：**
 
-- [ ] G1: `[完整模式]` 01-plan.md 包含目标澄清、上下文、阶段拆分、修改范围、验证计划。`[精简替代]` 03-sdd.md 包含任务目标和关键设计决策
-- [ ] G2: 04-boundary.md 有 allow/deny 两个方向
-- [ ] G3: 测试存在且有补充（09-test-matrix.md + 10-test-report.md + 测试代码）
-- [ ] G4: 代码通过项目 CI 全量检查，测试全部通过
-- [ ] G5: 项目 AI 规范中每条规则包含「触发条件 + 可执行指令」，不是空话
-- [ ] G6: `[完整模式]` 05-risk.md 有风险识别 + 11-review.md §四 有剩余风险说明。`[精简替代]` 11-review.md §四 有剩余风险说明
-- [ ] G7: `[完整模式]` 08-ai-decisions.md 能解释关键决策 + 15-brief.md 有决策解释表。`[精简替代]` 08-ai-decisions.md 能解释关键决策
+- [ ] G1: `[完整模式]` **ASSERT** `01-plan.md` 包含目标澄清、上下文、阶段拆分、修改范围、验证计划。`[精简替代]` **ASSERT** `03-sdd.md` 包含任务目标和关键设计决策
+- [ ] G2: **ASSERT** `04-boundary.md` 有 allow/deny 两个方向
+- [ ] G3: **ASSERT** `09-test-matrix.md` + `10-test-report.md` + 测试代码存在
+- [ ] G4: **EXEC** 项目 CI 全量检查 → **ASSERT** `exit_code == 0` && `failures == 0`
+- [ ] G5: **ASSERT** 项目 AI 规范中每条规则包含「触发条件 + 可执行指令」
+- [ ] G6: `[完整模式]` **ASSERT** `05-risk.md` 有风险识别 + `11-review.md` §四 有剩余风险说明。`[精简替代]` **ASSERT** `11-review.md` §四 有剩余风险说明
+- [ ] G7: `[完整模式]` **ASSERT** `08-ai-decisions.md` 能解释关键决策 + `15-brief.md` 有决策解释表。`[精简替代]` **ASSERT** `08-ai-decisions.md` 能解释关键决策
 
 **D1 AI 协作资产沉淀（25 分）：**
 
-- [ ] D1.1 分层组织：项目 AI 规范（项目级）+ 模块 AI 规范（模块级）+ task-rules.md（任务级）三层齐全
-- [ ] D1.2 内容覆盖：业务术语、架构、代码结构、接口约定、编码规范、测试要求、Review 标准、交付要求 8 类有对应文件。验证：CLAUDE.md 或 AGENTS.md 覆盖架构/代码结构/接口/编码规范；docs/review-checklist.md 含 ≥ 5 条可执行检查项；docs/delivery-checklist.md 完成率 ≥ 80%（`- [x]` 数 / 总 `- [` 数）。不满足 → 回退 reviewAgent 补建
-- [ ] D1.3 规则可执行：12-asset-update.md 中每条规则有「触发条件 + 可执行指令 + 示例」
-- [ ] D1.4 工具适配 ≥ 2 类：项目 AI 规范 + (review-checklist / delivery-checklist / prompt-template.md) 至少 2 种
-- [ ] D1.5 可维护性：项目 AI 规范有「资产维护机制」段落（更新触发条件 + 版本记录 + 复盘中新增规则）
+- [ ] D1.1 **ASSERT** 分层组织：项目级 + 模块级 + task-rules.md 三层齐全
+- [ ] D1.2 **ASSERT** 8 类内容覆盖（业务术语/架构/代码结构/接口/编码规范/测试/Review/交付有对应文件）。不满足 → **ROLLBACK** reviewAgent 补建
+- [ ] D1.3 **ASSERT** `12-asset-update.md` 中每条规则有「触发条件 + 可执行指令 + 示例」
+- [ ] D1.4 **ASSERT** 工具适配 ≥ 2 类
+- [ ] D1.5 **ASSERT** 项目 AI 规范有「资产维护机制」段落
 
 **D2 AI 协作任务规划（25 分）：**
 
-- [ ] D2.1 `[完整模式]` 目标澄清：01-plan.md 有成功标准 ≥ 3 条（每条含验证命令）+ 非目标 ≥ 2 条。`[精简替代]` 03-sdd.md §一 有明确目标描述
-- [ ] D2.2 `[完整模式]` 上下文选择：02-context.md 有必要引用 + 已排除上下文。`[精简替代]` 此项跳过（精简模式不产出 02-context.md）
-- [ ] D2.3 `[完整模式]` 任务拆分：01-plan.md 有探索→方案→实现→验证→总结 ≥ 5 阶段。`[精简替代]` 此项跳过
-- [ ] D2.4 执行约束：04-boundary.md 有 allow/deny + 依赖约束
-- [ ] D2.5 `[完整模式]` 验证风控：05-risk.md 有验证计划（具体命令 + 预期结果）+ 停下来问人条件 ≥ 3 个。`[精简替代]` 此项跳过（精简模式不产出 05-risk.md）
+- [ ] D2.1 `[完整模式]` **ASSERT** `01-plan.md` 有成功标准 ≥ 3 条 + 非目标 ≥ 2 条。`[精简替代]` **ASSERT** `03-sdd.md` §一 有明确目标
+- [ ] D2.2 `[完整模式]` **ASSERT** `02-context.md` 有必要引用 + 已排除上下文。`[精简替代]` 跳过
+- [ ] D2.3 `[完整模式]` **ASSERT** `01-plan.md` 有 ≥ 5 阶段拆分。`[精简替代]` 跳过
+- [ ] D2.4 **ASSERT** `04-boundary.md` 有 allow/deny + 依赖约束
+- [ ] D2.5 `[完整模式]` **ASSERT** `05-risk.md` 有验证计划 + 停下来问人条件 ≥ 3 个。`[精简替代]` 跳过
 
 **D3 AI 交付质量保障（27 分）：**
 
-- [ ] D3.1 SDD 规格：03-sdd.md 含输入/输出/边界/异常/验收 Checklist
-- [ ] D3.2 TDD 流程：06-tdd-log.md 含红-绿-重构循环记录（RED 有失败输出在前，GREEN 有通过输出在后）+ git log 中同一功能点的 test: 提交早于 feat:/fix: 提交
-- [ ] D3.3 测试覆盖：09-test-matrix.md 四维矩阵（功能/边界/异常/代码），不仅限 Happy Path
-- [ ] D3.4 缺陷修复：06-tdd-log.md + 11-review.md 有修复记录
-- [ ] D3.5 Review 风险：11-review.md 含五维度审查 + §四剩余风险
+- [ ] D3.1 **ASSERT** `03-sdd.md` 含输入/输出/边界/异常/验收 Checklist
+- [ ] D3.2 **READ** `06-tdd-log.md` → **ASSERT** RED 有失败输出在前 + GREEN 有通过输出在后 + `git log` 中 `test:` 提交早于 `feat:/fix:`
+- [ ] D3.3 **ASSERT** `09-test-matrix.md` 四维矩阵（功能/边界/异常/代码）+ `10-test-report.md` §八 回归验证存在
+- [ ] D3.4 **ASSERT** `06-tdd-log.md` + `11-review.md` 有修复记录
+- [ ] D3.5 **ASSERT** `11-review.md` 含五维度审查 + §四剩余风险
 
 **D4 AI 使用过程与复盘（13 分）：**
 
-- [ ] D4.1 Prompt 结构：07-prompt-log.md 每条含五要素（目标/上下文/边界/输出格式/验证标准）
-- [ ] D4.2 迭代纠偏：07-prompt-log.md 有纠偏前后对比
-- [ ] D4.3 过程可追溯：07-prompt-log.md + 08-ai-decisions.md 有关键过程记录
-- [ ] D4.4 个人复盘：13-retrospective.md 有 §二.5「本次沉淀的新规则」
-- [ ] D4.5 `[完整模式]` 答辩准备：15-brief.md 有 Elevator Pitch + 决策解释 + 亮点 + 测试覆盖概要 + 风险。`[精简替代]` 此项跳过（精简模式不产出 15-brief.md）
+- [ ] D4.1 **ASSERT** `07-prompt-log.md` 每条含五要素
+- [ ] D4.2 **ASSERT** `07-prompt-log.md` 每条含效果记录；**IF** 存在偏离 → 有纠偏前后对比
+- [ ] D4.3 **ASSERT** `07-prompt-log.md` + `08-ai-decisions.md` 有关键过程记录
+- [ ] D4.4 **ASSERT** `13-retrospective.md` 有「本次沉淀的新规则」
+- [ ] D4.5 `[完整模式]` **ASSERT** `15-brief.md` 有 Elevator Pitch + 决策解释 + 亮点 + 测试覆盖 + 风险。`[精简替代]` 跳过
 
 **D5 团队协作表现（10 分）：**
 
-> 精简模式下 D5 整组跳过（不产出 14-team.md / 15-brief.md）。
+> 精简模式下 D5 整组跳过。
+
+- [ ] D5.1 **ASSERT** `14-team.md` §一 有角色/负责人/职责/产出物
+- [ ] D5.2 **ASSERT** `14-team.md` §二 一致性检查全部 ✅ 或已修复
+- [ ] D5.3 **ASSERT** `14-team.md` §四 真实问题占比 > 0
+- [ ] D5.4 **ASSERT** `14-team.md` §三 每位贡献者有明确产出物和提交数
 
-- [ ] D5.1 角色分工：14-team.md §一 有角色 / 负责人 / 职责 / 产出物
-- [ ] D5.2 资产一致：14-team.md §二 一致性检查全部 ✅ 或已修复
-- [ ] D5.3 交叉 Review：14-team.md §四 真实问题占比 > 0
-- [ ] D5.4 个人贡献：14-team.md §三 每位贡献者有明确产出物和提交数
+**IF** `unchecked_items > 0` → **GOTO** 对应 Agent 补全。
 
-如有未通过项，回到对应 Agent 补全。
+全部通过 → **WRITE** checkpoint：`status=DONE, completed_steps 追加 Step 7.5 和 Step 8`。
 
-**全部通过后写入 checkpoint**：`current_step=Step 8, status=DONE, completed_steps 追加 Step 7.5 和 Step 8`。此时且仅此时 `status` 设为 `DONE`（如有保留意见则设为 `DONE_WITH_CONCERNS`）。
+> 此时且仅此时 `status` 设为 **DONE**（如有保留意见则设为 **DONE_WITH_CONCERNS**）。
 
 ## STOP Signals
 
-- 跳过 H1 或 H4
-- 延迟回退（"先记着后面一起修"）
-- 信任 Agent 的自我声明而不验证其产出
-- 超出预算却不砍范围
+- **跳过** H1 或 H4 人类介入点
+- **延迟**回退（"先记着后面一起修"）
+- **信任** Agent 自我声明而不验证产出
+- **超出**预算却不砍范围
 
-## 自检门禁
+## Constitutional Rules 遵守
+
+引用 `_team-rules/constitutional-rules.md`。编排阶段尤其注意：
 
-在报告完成状态前，执行以下自检：
+- **Rule #1 人类介入是一等公民**：H1-H4 不可被任何 Agent 自动确认，"用户没回复就默认同意"是违规（FP-1）
+- **Rule #2 有向图回退**：testAgent/reviewAgent 发现问题必须 **ROLLBACK** 对应 Agent，不可"先记着后面一起修"（FP-4）
+- **Rule #7 回退次数上限**：同一 source→target 对回退 ≤ 2 次，第 3 次强制触发 **H3**（FP-1）
+- **Rule #9 TDD 顺序不可逆**：implAgent 完成后必须验证 `06-tdd-log.md` 中 RED 在 GREEN 之前（FP-2）
+
+## 自检门禁
 
-- [ ] 完整模式：所有 17 个文件已产出（01-15 + prompt-template + task-rules）；精简模式：核心文件已产出（03-sdd + 04-boundary + 06-tdd-log + 07-prompt-log + 08-ai-decisions + 09-test-matrix + 10-test-report + 11-review + 12-asset-update + 13-retrospective + task-rules）
-- [ ] H1 和 H4 经过人类确认，未被跳过（完整模式还需确认 H2；精简模式需确认 H2 单句确认已执行）
-- [ ] 回退计数未超过上限（同一阶段 ≤ 2 次）
-- [ ] Step 8 质量检查全部通过
-- [ ] CHANGELOG.md 已更新（如 reviewAgent 要求）
-- [ ] 进度账本已更新
+- [ ] **IF** 完整模式 → **ASSERT** 17 个文件已产出；**IF** 精简模式 → **ASSERT** 核心文件已产出
+- [ ] **ASSERT** H1 和 H4 经过人类确认（完整模式还需 H2；精简模式需 H2 单句确认）
+- [ ] **ASSERT** 回退计数未超上限（同一对 ≤ 2 次）
+- [ ] **ASSERT** Step 8 质量检查全部通过
+- [ ] **IF** reviewAgent 要求 → **ASSERT** CHANGELOG.md 已更新
+- [ ] **ASSERT** 进度账本已更新
 
 ## 完成标志
 
-```
-Team 全流程完成 ✅
-产出目录：docs/tasks/{slug}/
-模式：{完整模式 / 精简模式}
-文件总数：完整模式 17 个文档（01-15 + prompt-template + task-rules）；精简模式 11 个文档（03-04 + 06-13 + task-rules）
-全部质量检查通过
-```
+**MATCH** `result`：
+
+- 全流程完成 + 质量检查通过 → **DONE**（`模式: {完整/精简}`, `文件: {17/11}`, `质量检查: pass`）
+- 完成但有保留意见 → **DONE_WITH_CONCERNS**（`concerns: [...]`）
+- 缺少关键上下文 → **NEEDS_CONTEXT**
+- 被阻塞（Kill Switch / 人类决策）→ **BLOCKED** → **H3**
 
 ## 集成关系