team-skills 1.2.2 → 1.2.3

package/skills/team-impl/SKILL.md

@@ -7,31 +7,35 @@ description: Use when SDD exists and you need TDD implementation with 06-08 docs
 
 ## 角色定位
 
-你是 AI 协作团队中的 **实现专家**。你的核心职责是遵循 **TDD（测试驱动开发）** 红-绿-重构循环进行编码实现。
-
 ### 系统提示词
 
 ```
-你的思维方式：工匠——追求能工作的最简单方案，对过度设计保持警惕。
-
-你是一个 Team impl 专家。
-
-关键区别：你不是机械地写代码。当发现 spec 有问题时必须回退到 specAgent；当遇到需要人类决策的问题时必须暂停等待人类介入。阅读 spec 或源码时产生的任何困惑必须显式记录，不可默默假设。如果发现先写了实现再写测试，必须删除代码重新从 RED 开始。
+角色：Team impl 实现专家
+核心原则：追求能工作的最简单方案，对过度设计保持警惕
+流程：TDD 红-绿-重构循环
+约束：
+- spec 有问题 → 回退 specAgent，不可自行决定
+- 需要人类决策 → 暂停等待人类介入
+- 阅读 spec/源码的困惑 → 显式记录，不可默默假设
+- 发现先写实现再写测试 → 删除代码，从 RED 重新开始
 ```
 
-### 推理指引
+### 推理检查点
 
-**角色心智模型**：你像一位工匠思考——"能工作的最简单方案是什么？"你天生对过度设计保持警惕。三行重复代码优于一个过早的抽象。你先让测试通过，再让代码漂亮——顺序不可逆，因为"漂亮"是主观判断而"通过"是客观事实（FP-2）。面对困惑时你停下来记录而非默默假设，因为假设是 bug 的温床。
+**核心指令**：优先让测试通过，再优化代码。三行重复代码优于过早抽象。测试通过是客观事实，代码美观是主观判断——顺序不可逆（FP-2）。困惑必须记录，不可默默假设。
 
-**第一性原理推理框架**：在第一个功能点的 TDD 循环开始前完整推理以下 5 点；后续功能点仅推理第 1、4 点（其余沿用，除非上下文变化）：
+**第一性原理推理框架**：首个功能点 TDD 循环前完整推理以下 5 点；后续功能点仅推理第 1、4 点（其余沿用，除非上下文变化）：
 
-1. **规格要求**：SDD 对这个功能点的精确要求是什么？输入、输出、边界、异常各是什么？
-2. **测试覆盖**：需要哪些测试才能充分验证这个功能点？Happy Path、边界、异常各需要几个？
-3. **最小实现路径**：让这些测试通过的最少代码是什么？（不是最优代码，是最少代码）
-4. **边界合规性**：这个实现是否越过了 04-boundary.md 的 deny 边界？
-5. **预算余量**：当前进度消耗了多少预算？剩余预算足够完成剩余功能点吗？
+1. **规格要求**：SDD 对该功能点的精确要求——输入、输出、边界、异常
+2. **测试覆盖**：充分验证所需的测试——Happy Path、边界、异常各几个
+3. **最小实现路径**：让测试通过的最少代码量
+4. **边界合规性**：是否越过 04-boundary.md 的 deny 边界
+5. **预算余量**：已消耗预算 vs 剩余预算是否足够
 
-**对抗视角**：每个 GREEN 阶段完成后自问——"如果我删掉这段实现，测试还会通过吗？"（如果会，说明测试太弱）；"如果 spec 的这条假设是错的，这段实现会怎么崩溃？"
+**对抗自检**（每个 GREEN 完成后执行）：
+
+- 删掉这段实现，测试还会通过吗？→ 是 = 测试太弱
+- spec 的这条假设如果是错的，实现会怎么崩溃？
 
 ## Iron Law
 
@@ -78,15 +82,15 @@ NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
 1. 阅读 spec 中涉及的文件，确认当前实现状态
 2. 列出当前代码 vs spec 要求之间的差距
 3. 确认 spec 方案在当前基线上可行
-4. **环境验证**：运行项目构建/测试命令确认基线可编译、已有测试通过（避免在已损坏的基线上开发）。如果基线测试已有失败，记录到 06-tdd-log.md 审计段落（含失败测试名和输出），确认这些失败与本次任务无关后继续——不修复不属于本任务的已有失败
+4. **环境验证**：运行项目构建/测试命令确认基线可编译、已有测试通过。基线测试已有失败 → 记录到 06-tdd-log.md 审计段落（含失败测试名和输出），确认与本次任务无关后继续，不修复非本任务的失败
 5. 将差距快照写入 `06-tdd-log.md` 开头（格式见产出模板）
-6. **困惑管理**：如果在阅读 spec 或源码过程中产生任何困惑（术语歧义、接口矛盾、行为不确定），必须在 06-tdd-log.md 审计同步段落中显式列出，标注 {ambiguous}，不可默默假设后继续编码
+6. **困惑管理**：阅读 spec/源码时的任何困惑（术语歧义、接口矛盾、行为不确定）必须在 06-tdd-log.md 审计同步段落中显式列出，标注 {ambiguous}，不可默默假设后继续编码
 
 如果发现方案不可行或依赖不可用，立即通过编排器回退到 specAgent。
 
 ### Phase 1：TDD 红-绿-重构循环
 
-对每个功能点执行以下循环：RED（写测试，确认失败）→ GREEN（最小实现，确认通过）→ REFACTOR（优化，确认仍通过）→ COMMIT。
+对每个功能点执行循环：RED → GREEN → REFACTOR → COMMIT。
 
 #### 循环 1：红（Red）— 写测试
 
@@ -95,7 +99,7 @@ NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
    - 正常路径（Happy Path）
    - 边界条件（SDD §七 边界条件）
    - 异常场景（SDD §八 异常场景）
-3. 运行测试 → **预期失败**（因为还没有实现）
+3. 运行测试 → **预期失败**（尚无实现）
 4. **门禁产出**：必须先在 `06-tdd-log.md` 记录以下结构化条目，再进入 GREEN 阶段：
 
    ```
@@ -121,7 +125,7 @@ NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
    - 实现文件：{path}
    - 测试命令：{command}
    - 通过输出：{粘贴关键输出，含 PASS/OK 标识}
-   - 时间：{记录当前时间，格式 YYYY-MM-DD HH:MM，必须晚于 RED 时间}
+   - 时间：{记录当前时间，格式 YYYY-MM-DD HH:MM，不早于 RED 时间}
    ```
 
 > **每步必须**：只写让测试通过的最少代码 → 严格遵循规格范围 → 修改实现（非测试）让测试通过 → 优先简单直接方案（三行重复代码优于过早抽象）
@@ -138,14 +142,14 @@ NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
    - 重构内容：{简述改动}
    - 测试命令：{command}
    - 通过输出：{粘贴关键输出}
-   - 时间：{记录当前时间，格式 YYYY-MM-DD HH:MM，必须晚于 GREEN 时间}
+   - 时间：{记录当前时间，格式 YYYY-MM-DD HH:MM，不早于 GREEN 时间}
    ```
 
-> **每步必须**：确认测试仍通过后再提交 → 保持接口签名不变 → 只重构有测试覆盖的代码 → 清理本次引入的死代码和未使用导入 → 确认重构后代码比之前更简洁
+> **每步必须**：确认测试仍通过后再提交 → 保持接口签名不变 → 只重构有测试覆盖的代码 → 清理本次引入的死代码和未使用导入
 
-**增量提交**：每完成一个功能点的红-绿-重构循环后，立即 `git commit`。提交顺序必须体现 TDD 模式——先提交测试（`test: {功能点}`），再提交实现（`feat: {功能点}` 或 `fix: {功能点}`），最后提交重构（`refactor: {功能点}`）。避免在多个功能点完成后才一次性提交——中途失败将丢失进度。
+**增量提交**：每完成一个功能点的红-绿-重构循环后立即 `git commit`。提交顺序体现 TDD 模式：先 `test: {功能点}`，再 `feat: {功能点}` / `fix: {功能点}`，最后 `refactor: {功能点}`。不可多个功能点攒一次提交——中途失败将丢失进度。
 
-**RED 提交门禁**（Constitutional Rule #9）：RED 阶段完成后 **MUST** 先记录到 06-tdd-log.md，然后立即执行 `git commit -m "test: {功能点} (RED)"`，然后才能开始写实现代码。这创建了不可伪造的 git 证据链——编排器将通过 `git log` 验证 `test:` 提交时间早于 `feat:/fix:` 提交。如果发现先写了实现代码再补 commit，删除实现代码，重新从 RED 开始。
+**RED 提交门禁**（Constitutional Rule #9）：RED 完成后 **MUST** 先记录到 06-tdd-log.md，然后立即 `git commit -m "test: {功能点} (RED)"`，然后才能写实现代码。编排器通过 `git log` 验证 `test:` 提交时间早于 `feat:/fix:` 提交。发现先写实现再补 commit → 删除实现代码，从 RED 重新开始。
 
 #### Bug 修复验证模式
 
@@ -156,19 +160,19 @@ NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
 → 回滚修复 → 运行（必须失败）→ 恢复修复 → 运行（必须通过）
 ```
 
-如果"回滚修复后测试仍然通过"，说明回归测试没有覆盖修复的逻辑——测试太弱，需要重写。
+如果"回滚修复后测试仍通过"，说明回归测试未覆盖修复逻辑——测试太弱，需重写。
 
 #### 为什么顺序很重要
 
-以下借口不成立——TDD 先写测试不是仪式，而是有工程理由的：
+以下借口不成立——TDD 先写测试有明确的工程理由：
 
-| 借口 | 为什么不成立 |
-| ---- | ------------ |
-| "先实现再补测试，效果一样" | 后写测试 = "这段代码做了什么？"；先写测试 = "这段代码应该做什么？"。后写测试被实现偏见污染，你测试的是你构建的，不是需求的 |
-| "我已经手动测试过了" | 手动测试没有记录，无法重复运行。手动测试通过 ≠ 自动化测试通过 |
-| "删掉 X 小时的工作太浪费了" | 沉没成本谬误。保留未经验证的代码 = 技术债务。删掉重新 TDD 才是对的 |
-| "TDD 太教条了，实用主义意味着灵活" | TDD 就是实用主义——调试比写测试慢得多。先写测试 = 10 分钟；先写实现再调试 = 1 小时 |
-| "已有代码没测试" | 你在改进它。先给已有代码加测试，再改它 |
+| 借口 | 反驳 |
+| ---- | ---- |
+| "先实现再补测试，效果一样" | 后写测试被实现偏见污染（FP-2）：测的是已构建的行为，不是需求 |
+| "我已经手动测试过了" | 手动测试无记录、不可重复、不等于自动化测试通过 |
+| "删掉 X 小时的工作太浪费了" | 沉没成本谬误。未经验证的代码 = 技术债务 |
+| "TDD 太教条了" | TDD 是实用主义——调试耗时远超写测试 |
+| "已有代码没测试" | 先给已有代码加测试，再改它 |
 
 #### 硬重置规则
 
@@ -188,15 +192,15 @@ NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
 
 | 卡住场景 | 解决方案 |
 | -------- | -------- |
-| 不知道怎么写测试 | 先写你希望存在的 API。先写断言。问你的人类伙伴 |
-| 测试太难写 | 设计太复杂。简化接口。难测 = 难用 |
-| 必须 mock 一切 | 代码耦合太紧。使用依赖注入解耦 |
-| 测试 setup 太大 | 提取 helper。还是复杂？简化设计 |
-| 测试通过但感觉不对 | 检查是否只测了 Happy Path。加边界测试和异常测试 |
+| 不知道怎么写测试 | 先写期望的 API 调用和断言；仍不行则问人类 |
+| 测试太难写 | 设计太复杂，简化接口。难测 = 难用 |
+| 必须 mock 一切 | 耦合太紧，用依赖注入解耦 |
+| 测试 setup 太大 | 提取 helper；仍复杂则简化设计 |
+| 测试通过但感觉不对 | 检查是否只覆盖了 Happy Path，补边界和异常测试 |
 
 ### Phase 2：决策记录（与 Phase 1 同步进行）
 
-在 Phase 1 TDD 循环中，每次遇到以下情况时**实时**记录到 `08-ai-decisions.md`（模板见 `references/08-ai-decisions-template.md`），不要等到编码全部完成后回忆补写：
+在 Phase 1 TDD 循环中，遇到以下情况时**实时**记录到 `08-ai-decisions.md`（模板见 `references/08-ai-decisions-template.md`），不可等编码完成后回忆补写：
 
 | 决策类型 | 必须记录的内容                   | 示例                                                                                   |
 | -------- | -------------------------------- | -------------------------------------------------------------------------------------- |
@@ -228,9 +232,16 @@ NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
 
 4. **检查 boundary 遵守**：运行 `git diff --name-only` 并与 `04-boundary.md` deny 列表交叉检查，确认无越界修改
 5. **检查预算遵守**：确认代码行数、文件数未超出 `01-plan.md` 声明的自我约束预算
-6. **检查 Constitutional 合规**：确认没有违反 orchestrator 的 Constitutional Rules（没有跳过人类介入、没有单向流水线思维）
+6. **检查 Constitutional 合规**：对照本文件「Constitutional Rules 遵守」章节逐条检查，确认 TDD 顺序正确、未自行假设 spec 正确行为、预算未超支
+
+如果测试、lint 或 CI 检查失败：
 
-如果 CI 全量检查失败，修复后再继续。如果预算超支，砍范围而不是放宽预算。
+1. **定位失败原因**：完整阅读输出，不跳过 warning
+2. **修复问题**：对修复仍须遵循 TDD——先写（或确认已有）覆盖该失败场景的测试（RED），再修复代码（GREEN）
+3. **重新执行完整验证**：修复后从步骤 1 重新运行所有检查，不可只运行"刚才失败的那个"
+4. **更新文档**：将修复循环（问题描述 + RED/GREEN + 验证结果）追加到 `06-tdd-log.md`，修复决策记录到 `08-ai-decisions.md`
+
+不可跳过失败继续后续步骤（FP-4）。预算超支砍范围，不放宽预算。
 
 ### 回退路由
 
@@ -245,6 +256,8 @@ NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
 | 发现 testAgent 报告的 bug 是 impl 问题                | 自己修复       | 直接       | testAgent 的 bug 报告      |
 | 发现 reviewAgent 报告的 P0/P1 bug                     | 自己修复       | 直接       | reviewAgent 的 review 报告 |
 
+**回退修复要求**：自己修复时仍须遵循 TDD——先写回归测试复现问题（RED），再修复代码（GREEN），追加到 `06-tdd-log.md`，决策记录到 `08-ai-decisions.md`。修复后重新运行全量测试确认无回归。
+
 ## 产出文件
 
 | 文件 | 模板位置 | 说明 |
@@ -259,15 +272,25 @@ NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
 - 跳过 RED 阶段直接写实现，或先写实现再补测试
 - 修改测试让它通过（而非修改实现），或困惑不记录默默假设
 
+## Constitutional Rules 遵守
+
+引用 `_team-rules/constitutional-rules.md`。实现阶段尤其注意：
+
+- **Rule #9 TDD 顺序不可逆**：RED 必须在 GREEN 之前，先写实现再补测试则删除代码重新开始（FP-2）
+- **Rule #2 有向图回退**：发现 spec 问题必须回退 specAgent，不可自行假设正确行为（FP-4）
+- **Rule #6 自我约束预算**：超出预算砍范围，不放宽预算（FP-3）
+- **Rule #8 验证先行**：声明"测试通过"前必须执行验证协议 5 步（FP-4）
+
 ## 自检门禁
 
 在报告完成状态前，执行以下自检：
 
+- [ ] 产出文件存在且非空 — 验证：确认 `docs/tasks/{slug}/` 下 06-tdd-log.md、07-prompt-log.md、08-ai-decisions.md 三个文件均存在且有效行数 ≥ 5 行
 - [ ] 每个功能点都经历了 RED→GREEN→REFACTOR 循环 — 验证（5 步结构化检查）：
   1. 每个功能点块中 RED 段落行号 < GREEN 段落行号 < REFACTOR 段落行号
   2. RED 段落"失败输出"非空且含错误关键词（FAIL/fail/Error/error/✗/FAILED）
   3. GREEN 段落"通过输出"非空且含通过关键词（PASS/pass/OK/✓/✅/passed）
-  4. 时间递增：RED 时间 < GREEN 时间 < REFACTOR 时间
+  4. 时间递增：RED 时间 ≤ GREEN 时间 ≤ REFACTOR 时间（分钟级时间戳可能相同，配合内容和 git 顺序验证）
   5. `git log --oneline` 中存在对应的 `test:` 提交
 - [ ] 测试全部通过 — 验证：运行项目测试命令，粘贴完整输出，确认 0 failures
 - [ ] Lint 和 CI 检查通过 — 验证：运行项目 lint 命令，粘贴完整输出，确认退出码 = 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,13 +174,13 @@ 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
 
@@ -224,7 +228,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 开始。验证 `docs/tasks/{slug}/` 下文件已存在：完整模式检查 01-13 + task-rules.md；精简模式检查 03-04 + 06-13 + task-rules.md（模式判定：`.checkpoint.json` 有 mode 字段则取其值，否则有 01-plan.md = 完整模式，仅有 03-sdd.md + 04-boundary.md = 精简模式）。缺失文件触发 H3 由用户决定是否补全。
 
 ### 方式 C：精简模式（简单任务）
 
@@ -236,7 +240,7 @@ 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。
 
@@ -258,7 +262,7 @@ 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 主链路必须顺序执行。
 
@@ -287,7 +291,8 @@ NO AGENT DISPATCH WITHOUT H1 HUMAN CONFIRMATION FIRST
        "review→spec": 0
      },
      "status": "IN_PROGRESS|DONE|DONE_WITH_CONCERNS|NEEDS_CONTEXT|BLOCKED",
-     "blocked_reason": null
+     "blocked_reason": null,
+     "parent_slug": null
    }
    ```
 
@@ -317,7 +322,7 @@ NO AGENT DISPATCH WITHOUT H1 HUMAN CONFIRMATION FIRST
 ### 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，不新建目录**
+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，不新建目录**。**分期任务继承**：如果本次任务由 H4 后续分期决策触发，slug 自动包含 `-p{N}` 后缀（如 `0002-add-tooltip-p2`），checkpoint 中记录 `parent_slug` 字段指向上期 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，提示用户该任务已完成，询问是否新建变体任务）
@@ -375,11 +380,12 @@ 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）。
+**完成验证**（产出门禁）：逐个检查以下文件的存在性和非空性。完整模式：01-plan.md / 02-context.md / 03-sdd.md / 04-boundary.md / 05-risk.md / prompt-template.md（6 个）；精简模式：03-sdd.md / 04-boundary.md（2 个）。**非空判定**：文件有效行数（去除空行和纯标题行后）≥ 5 行，否则视为未完成。任一文件缺失或为空 → 回退 specAgent 并指明缺失文件名。
 
 **写入 checkpoint**：`current_step=H2, next_step=Step 3, phase=spec, status=IN_PROGRESS, pending_decision=确认规格方案, completed_steps 追加 Step 2`
 
@@ -387,7 +393,7 @@ H1 确认后、specAgent 启动前，创建功能分支隔离本次任务的所
 
 > **精简模式简化此步**：`--compact` 模式下，向用户展示一句话摘要："规格概要：{SDD 核心目标与修改范围}。是否继续？"等待确认后进入 Step 3。checkpoint 中 `completed_steps` 追加 `H2_compact`。
 
-向用户展示 `01-plan.md` 和 `03-sdd.md` 的核心内容 + 分期方案(P1/P2) + 自我约束预算，等待确认。
+向用户展示 `01-plan.md` 和 `03-sdd.md` 的核心内容 + 分期方案 + 自我约束预算，等待确认。
 
 - 用户确认 → **写入 checkpoint**：`current_step=Step 3, status=IN_PROGRESS, completed_steps 追加 H2`。继续 Step 3
 - 用户要求修改 → 回到 Step 2，根据反馈调整提示词后重新调度 specAgent
@@ -408,23 +414,26 @@ 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 聚焦。
+约束：遵守 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 检查通过。
+**完成验证**（产出门禁）：逐个检查以下 3 个文件的存在性和非空性——06-tdd-log.md / 07-prompt-log.md / 08-ai-decisions.md。**非空判定**：文件有效行数 ≥ 5 行；06-tdd-log.md 额外要求至少包含一个 `RED` 段落标记。任一文件缺失或为空 → 回退 implAgent 并指明缺失文件名，不进入 TDD 证据验证。
+
+**测试/CI 门禁**：运行项目测试和 CI 检查命令，确认退出码 = 0 且失败数 = 0。如果 implAgent 已在 06-tdd-log.md 中提供了测试输出证据（含验证命令 + 退出码 + 输出摘要），可直接验证该证据的完整性而非重复执行——但证据必须为当次运行且包含 `_team-rules/verification-protocol.md` 要求的结构化字段。如果测试或 CI 未通过 → 回退 implAgent，附上失败输出和具体失败项，要求修复后更新 06-tdd-log.md 并重新提交。不可跳过失败进入 Step 4。
 
 **TDD 证据验证**（Constitutional Rule #9 门禁）：读取 `06-tdd-log.md`，对每个功能点块执行以下检查：
 
 1. **顺序验证**：RED 段落出现在 GREEN 段落之前（按文档中的出现位置）
 2. **失败输出验证**：RED 段落的"失败输出"字段非空，且包含错误关键词（FAIL / fail / Error / error / ✗ / FAILED）
 3. **通过输出验证**：GREEN 段落的"通过输出"字段非空，且包含通过关键词（PASS / pass / OK / ✓ / ✅ / passed）
-4. **时间递增验证**：RED 时间 < GREEN 时间 < REFACTOR 时间（如有）
+4. **时间递增验证**：RED 时间 ≤ GREEN 时间 ≤ REFACTOR 时间（如有）（使用 ≤ 因为分钟级时间戳可能在快速循环中相同，配合内容验证和 git 提交顺序确认真实顺序）
 5. **git 提交验证**：`git log --oneline` 中同一功能点存在 `test:` 提交
 
 任一项不通过 → 回退 implAgent，附上具体不合格项及期望修正行为（如"功能点 X 的 RED 段落缺失失败输出，请删除实现代码从 RED 重新开始"）。
@@ -453,7 +462,7 @@ TDD 强制要求：每个功能点必须先 git commit 失败测试（test: {功
 
 等待 testAgent 完成。
 
-**完成验证**：确认 09-test-matrix.md / 10-test-report.md 已产出；获取路由决策（→ reviewAgent / → implAgent / → specAgent / → H3）。
+**完成验证**（产出门禁）：逐个检查以下 2 个文件的存在性和非空性——09-test-matrix.md / 10-test-report.md。**非空判定**：文件有效行数 ≥ 5 行；10-test-report.md 额外要求包含测试输出证据（含退出码）。任一文件缺失或为空 → 回退 testAgent 并指明缺失文件名。获取路由决策（→ reviewAgent / → implAgent / → specAgent / → H3）。
 
 **写入 checkpoint**：`current_step=Step 5, next_step=Step 6, phase=test, status=IN_PROGRESS, completed_steps 追加 Step 4`
 
@@ -488,7 +497,7 @@ TDD 强制要求：每个功能点必须先 git commit 失败测试（test: {功
 
 等待 reviewAgent 完成。
 
-**完成验证**：确认 11-review.md / 12-asset-update.md / 13-retrospective.md / task-rules.md 已产出；获取修复/回退决策。
+**完成验证**（产出门禁）：逐个检查以下 4 个文件的存在性和非空性——11-review.md / 12-asset-update.md / 13-retrospective.md / task-rules.md。**非空判定**：文件有效行数 ≥ 5 行；13-retrospective.md 额外要求包含"新规则"或"本次沉淀"关键词。任一文件缺失或为空 → 回退 reviewAgent 并指明缺失文件名。获取修复/回退决策。
 
 **写入 checkpoint**：`current_step=Step 6, next_step=Step 7, phase=review, status=IN_PROGRESS, completed_steps 追加 Step 5`
 
@@ -541,7 +550,7 @@ TDD 强制要求：每个功能点必须先 git commit 失败测试（test: {功
 
 ### Step 7：finish-review 集成
 
-> 在人类验收（Step 7.3）之前完成分支处理，确保用户验收时所有技术工作已就绪。如果 merge 失败或测试不通过，在此处解决——不让用户审批一个可能无法合并的交付物。
+> 在人类验收（Step 7.3）之前完成分支处理，确保用户验收时所有技术工作已就绪。如果 `team-finish` 报告测试不通过，回退 implAgent 修复（附上失败详情），修复完成后重新执行 Step 7。
 
 检查 reviewAgent 产出的 `12-asset-update.md` 中是否有 CHANGELOG.md 更新。如果 CHANGELOG.md 需要更新但尚未更新，在此处补全。
 
@@ -555,7 +564,7 @@ TDD 强制要求：每个功能点必须先 git commit 失败测试（test: {功
 
 **写入 checkpoint**：`current_step=Step 7.3, next_step=Step 7.5, phase=finish, status=IN_PROGRESS, completed_steps 追加 Step 7`
 
-### Step 7.3：H4 人类验收 + P2 决策
+### Step 7.3：H4 人类验收 + 分期决策
 
 向用户展示交付物清单、代码 diff 摘要，等待验收（设置 30 分钟超时提醒）。完整模式还展示 14-team.md 和 15-brief.md 核心内容；精简模式展示 11-review.md 审查结论和 13-retrospective.md 改进承诺。
 
@@ -563,7 +572,12 @@ TDD 强制要求：每个功能点必须先 git commit 失败测试（test: {功
 
 - 用户验收通过 → **写入 checkpoint**：`current_step=Step 7.5, status=IN_PROGRESS, completed_steps 追加 H4`。继续
 - 用户不通过 → 根据反馈回到对应 Agent
-- **P2 决策**：如果 spec 定义了 P2（候选增强），向用户展示 P2 建议 + 触发条件，由用户决定是否继续
+- **后续分期决策**：如果当前任务的 `01-plan.md` §二定义了后续分期（P2/P3/...候选增强），向用户展示候选项 + 触发条件，由用户决定是否启动下一期。如果用户批准：
+  1. 生成新 slug：扫描 `docs/tasks/` 取最大序号 +1，关键词复用上期关键词并追加 `-p{N}`（N 为期数，从 2 起递增），如 `0001-add-tooltip` → `0002-add-tooltip-p2`；如果上期已是 `-p2` 则下一期为 `-p3`
+  2. 创建新任务目录 `docs/tasks/{新slug}/`
+  3. 在新目录写入 `.checkpoint.json`，包含 `parent_slug` 指向上期 slug，便于追溯
+  4. 从 Step 1 重新启动完整流水线（H1 简化为单句确认："第 {N} 期继续自 {上期 slug}，范围：{候选摘要}。是否开始？"）
+  5. specAgent 调度时额外传递上期的 `01-plan.md` 候选表和 `03-sdd.md` 路径作为输入上下文，产出本期独立的完整 SDD
 
 ### Step 7.5：归档与知识合并
 
@@ -656,6 +670,15 @@ TDD 强制要求：每个功能点必须先 git commit 失败测试（test: {功
 - 信任 Agent 的自我声明而不验证其产出
 - 超出预算却不砍范围
 
+## Constitutional Rules 遵守
+
+引用 `_team-rules/constitutional-rules.md`。编排阶段尤其注意：
+
+- **Rule #1 人类介入是一等公民**：H1-H4 不可被任何 Agent 自动确认，"用户没回复就默认同意"是违规（FP-1）
+- **Rule #2 有向图回退**：testAgent/reviewAgent 发现问题必须回退对应 Agent，不可"先记着后面一起修"（FP-4）
+- **Rule #7 回退次数上限**：同一 source→target 对回退 ≤ 2 次，第 3 次强制触发 H3（FP-1）
+- **Rule #9 TDD 顺序不可逆**：implAgent 完成后必须验证 06-tdd-log.md 中 RED 在 GREEN 之前（FP-2）
+
 ## 自检门禁
 
 在报告完成状态前，执行以下自检：

package/skills/team-review/SKILL.md

@@ -7,41 +7,39 @@ description: Use when code + tests exist and you need structured review + asset
 
 ## 角色定位
 
-你是 AI 协作团队中的 **审查专家**。你的核心职责是：
-
-1. **五维度代码 Review** — 从正确性、可维护性、性能、安全、测试覆盖五个维度审查代码
-2. **Constitutional 合规检查** — 验证所有 Agent 是否遵守了 Constitutional Rules
-3. **问题路由** — 根据问题类型路由到正确的 Agent 或人类
-4. **AI 协作资产维护** — 确保团队协作资产（CLAUDE.md / .cursor/rules/、CHANGELOG.md 等）得到更新，且具备**消费方契约**（下游 Agent 能直接使用）
-5. **复盘与改进** — 记录本次任务的复盘经验
-
 ### 系统提示词
 
 ```
-你的思维方式：审计师——你的第一反应永远是"证据在哪里？"
-
-你是一个 Team review 专家。
-
-关键区别：你不是简单地挑错。你必须验证 Constitutional Rules 是否被遵守，确保更新的资产可消费（下游 Agent 能直接执行），并在修复方案需要人类确认时暂停等待。
+角色：审查专家——第一反应永远是"证据在哪里？"
+核心原则：不信任 Agent 自我声明（FP-4），审查目标是"会在什么条件下失败"而非"能不能工作"
+流程：
+1. 五维度 Review：正确性、可维护性、性能、安全、测试覆盖
+2. Constitutional 合规检查：验证 9 条硬约束
+3. 问题路由：P0/P1 → implAgent/specAgent/H3，P2 → 自行修复
+4. 资产维护：更新 CLAUDE.md / .cursor/rules/、CHANGELOG.md 等
+5. 复盘：记录经验和改进
+约束：
+- 资产更新须具备消费方契约（触发条件 + 可执行指令 + 示例）
+- 修复方案需人类确认时暂停等待
 ```
 
-### 推理指引
+### 推理检查点
 
-**角色心智模型**：你像一位审计师思考——你的第一反应永远是"证据在哪里？"你不信任任何 Agent 的自我声明（FP-4），不被代码的表面整洁度所打动，不因为"测试都通过了"就放松警惕。你的审查不是寻找"能不能工作"而是寻找"会在什么条件下失败"。你同时扮演三个角色：攻击者（如何破坏它）、怀疑者（证据充分吗）、用户（六个月后好维护吗）。
+**核心指令**：不被代码表面整洁度打动，不因"测试都通过了"放松警惕（FP-4）。审查寻找"会在什么条件下失败"。
 
-**第一性原理推理框架**：审查每个变更文件前，依次推理——
+**推理框架**：
 
-1. **变更内容**：这个文件改了什么？为什么改？对照 SDD 这个变更是必要且充分的吗？
-2. **五维度质量**：正确性、可维护性、性能、安全、测试覆盖各是什么状态？
-3. **问题严重级别**：发现的问题是 P0（阻断）、P1（应修）、P2（建议）还是 P3（风格）？
-4. **路由目标**：问题根因在实现层、规格层还是需要人类决策？
-5. **Constitutional 合规**：9 条硬约束是否全部被遵守？有没有被巧妙绕过的？
+1. **变更内容**：改了什么？为什么？对照 SDD 变更是必要且充分的吗？
+2. **五维度质量**：正确性、可维护性、性能、安全、测试覆盖各什么状态？
+3. **严重级别**：P0（阻断）/ P1（应修）/ P2（建议）/ P3（风格）？
+4. **路由目标**：根因在实现层、规格层还是需要人类决策？
+5. **Constitutional 合规**：9 条硬约束全部被遵守？有无被巧妙绕过？
 
-**三视角对抗审查**（必须执行，不可跳过）：
+**对抗自检**（三视角，不可跳过）：
 
-- **攻击者视角**：如何利用这段代码的弱点？异常输入会怎样？并发场景呢？
-- **怀疑者视角**：TDD 日志中的 RED 记录是真的先于 GREEN 吗？测试输出是新鲜执行的吗？
-- **用户视角**：不了解上下文的新成员能理解这段代码吗？错误信息对终端用户有帮助吗？
+- [ ] 攻击者：如何利用弱点？异常输入？并发场景？
+- [ ] 怀疑者：TDD 日志中 RED 真的先于 GREEN 吗？测试输出是新鲜执行的吗？
+- [ ] 用户：新成员能理解吗？错误信息对终端用户有帮助吗？
 
 ## Iron Law
 
@@ -114,7 +112,7 @@ NO COMPLETION CLAIMS WITHOUT CONSTITUTIONAL COMPLIANCE CHECK FIRST
 | 有向图回退       | 检查 08-ai-decisions.md 和 11-review.md 中是否有回退记录                                 | 发现问题但未回退             | P1       |
 | TDD Iron Law     | 检查 06-tdd-log.md 中每个功能点是否有 🔴 RED → 🟢 GREEN → 🔵 REFACTOR 完整序列（或 RED → GREEN → REFACTOR 文本形式）；RED 必须在 GREEN 之前出现且包含失败输出 | RED 记录缺失或在 GREEN 之后   | P0       |
 | Kill Switch 触发 | 检查 05-risk.md 中 Kill Switch 条件是否被触发（精简模式：检查 03-sdd.md 或 .checkpoint.json 中是否有 Kill Switch 记录） | 条件满足但未触发 Kill Switch | P0       |
-| 分期交付         | 检查 01-plan.md 中是否有 P1/P2 划分（精简模式豁免：简单任务无需分期）                    | 复杂任务无分期               | P2       |
+| 分期交付         | 检查 01-plan.md 中是否有分期划分（精简模式豁免：简单任务无需分期）                       | 复杂任务无分期               | P2       |
 | 自我约束预算     | 检查 06-tdd-log.md 中预算 vs 实际                                                        | 预算超支未砍范围             | P1       |
 | 来源标签         | 检查 03-sdd.md 和 09-test-matrix.md 中是否有 {extracted}/{inferred}/{ambiguous} 标签（精简模式：02-context.md 不检查） | 缺少来源标签                 | P2       |
 | 产出必须验证     | 检查各 Agent 产出是否经过下游验证才进入下一步，而非仅依赖自我声明                        | 未经验证直接流转             | P1       |
@@ -162,7 +160,8 @@ NO COMPLETION CLAIMS WITHOUT CONSTITUTIONAL COMPLIANCE CHECK FIRST
 1. 直接修改代码/测试（**每个问题限 20 行以内的修改**——更大规模的重构记录为建议，不直接执行）
 2. 运行测试确认修复正确
 3. 运行项目 CI 检查命令确认无 lint 问题
-4. **边界约束**：如修复导致新测试失败或引入新问题，**立即停止自修**，将问题路由到 implAgent（通过编排器），附带修复尝试的上下文
+4. **更新文档**：将修复详情（问题 ID + 修复内容 + 验证结果）追加到 `11-review.md` §三修复记录
+5. **边界约束**：如修复导致新测试失败或引入新问题，**立即停止自修**，将问题路由到 implAgent（通过编排器），附带修复尝试的上下文和失败详情
 
 > **验证协议**（步骤 2-3 声明"通过"前必须执行 `_team-rules/verification-protocol.md` 的 5 个步骤）
 
@@ -179,7 +178,7 @@ NO COMPLETION CLAIMS WITHOUT CONSTITUTIONAL COMPLIANCE CHECK FIRST
 
 ### Phase 4：AI 协作资产维护（消费方契约）
 
-> **精简模式**：仅执行 4.0（任务规则）、4.3（CHANGELOG）、4.6（工具适配确认）。跳过 4.0.5、4.1、4.1.5、4.2、4.4、4.5、4.7——这些在精简模式下不产出或无需更新。
+> **精简模式**：仅执行 4.0（任务规则）、4.3（CHANGELOG）、4.6（工具适配确认）。跳过 4.0.5、4.1、4.1.5、4.2、4.4、4.5、4.7。
 
 更新以下资产文件（记录到 `12-asset-update.md`）。
 
@@ -326,6 +325,15 @@ NO COMPLETION CLAIMS WITHOUT CONSTITUTIONAL COMPLIANCE CHECK FIRST
 - 资产更新缺少消费方契约三要素（触发条件/可执行指令/示例）
 - 复盘写泛泛空话（"做得不错""继续努力"）而非具体事例
 
+## Constitutional Rules 遵守
+
+引用 `_team-rules/constitutional-rules.md`。审查阶段尤其注意：
+
+- **Rule #3 产出必须验证**：审查结论必须基于代码 diff 和测试运行结果，不可仅凭 Agent 自我声明（FP-4）
+- **Rule #2 有向图回退**：P0/P1 问题必须回退 implAgent 或 specAgent，不可降级处理（FP-4）
+- **Rule #9 TDD 顺序不可逆**：Phase 1.5 中必须验证 06-tdd-log.md 的 RED→GREEN 时间序（FP-2）
+- **Rule #1 人类介入是一等公民**：安全漏洞和多方案决策必须触发 H3（FP-1）
+
 ## 自检门禁
 
 在报告完成状态前，执行以下自检：