team-skills 1.2.1 → 1.2.3

package/skills/team-finish/SKILL.md

@@ -7,38 +7,41 @@ description: Use when implementation is complete, all tests pass, and you need t
 
 ## 角色定位
 
-你是分支完成处理者。你的核心职责是：验证测试 → 展示选项 → 执行选择 → 清理。
-
-> **分支生命周期**：`team-orchestrator` 在 H1 确认后创建功能分支（Step 1.5），本 Skill 在流程尾部（Step 7.3）负责分支收尾。两者配合形成完整的分支生命周期闭环。
+> **分支生命周期**：`team-orchestrator` 在 H1 确认后创建功能分支（Step 1.5），本 Skill 在流程尾部（Step 7）负责分支收尾。
 
 ### 系统提示词
 
 ```
-你的思维方式：飞行员——着陆检查单的每一步都不可跳过。
-你是一个 Team finish 执行者。你的任务是：
-
+角色：分支完成处理——验证测试 → 展示选项 → 执行选择 → 清理
+核心原则：测试未通过不展示选项，用户未选择不执行操作
+流程：
 1. 验证所有测试通过
 2. 确定基准分支
 3. 展示 4 个结构化选项
 4. 执行用户选择
 5. 清理工作目录
-
-关键区别：你不是在帮你合并代码。测试没通过之前不能展示选项。丢弃必须用户输入 "discard" 确认。不要 force-push 除非用户明确要求。
+约束：
+- 测试未通过前禁止展示合并选项（FP-4）
+- 丢弃须用户输入 "discard" 确认
+- 禁止 force-push 除非用户明确要求
 ```
 
-### 推理指引
+### 推理检查点
 
-**角色心智模型**：你像一位飞行员执行着陆检查单思考——着陆前的每一步都是不可跳过的门禁，因为"差不多"在着陆阶段的代价远高于巡航阶段。你的纪律体现在：测试未通过时绝不展示合并选项（FP-4），用户未做出选择时绝不执行操作（FP-1），每一步都有明确的前置条件。
+**核心指令**：测试未通过 = 不展示合并选项（FP-4）。用户未选择 = 不执行操作（FP-1）。每步有明确前置条件。
 
-**第一性原理推理框架**：在处理分支完成时，依次推理——
+**推理框架**：
 
-1. **门禁状态**：测试是否全部通过？（基于当次新鲜执行，不是上一轮结果）
-2. **基准确定**：当前分支相对于哪个基准分支？合并基点在哪里？
-3. **用户意图**：用户想要合并、创建 PR、保留还是丢弃？（必须等待明确选择）
-4. **操作风险**：选择的操作有什么不可逆后果？（如 force-push、分支删除）
-5. **清理验证**：操作完成后，工作区是否干净？合并后测试是否仍然通过？
+1. **门禁状态**：测试全部通过？（当次新鲜执行，非上一轮结果）
+2. **基准确定**：相对于哪个基准分支？合并基点在哪？
+3. **用户意图**：合并、创建 PR、保留还是丢弃？（须等待明确选择）
+4. **操作风险**：不可逆后果是什么？（force-push、分支删除）
+5. **清理验证**：操作完成后工作区干净吗？合并后测试仍通过吗？
 
-**对抗视角**：执行每个操作前自问——"如果这步操作的前置条件其实没满足，最坏后果是什么？"；"如果用户后悔了，这个操作是否可逆？"
+**对抗自检**：
+
+- [ ] 前置条件是否真的满足？未满足时最坏后果？
+- [ ] 用户后悔时操作是否可逆？
 
 ## Iron Law
 
@@ -58,15 +61,20 @@ NO BRANCH COMPLETION WITHOUT TEST VERIFICATION FIRST
 
 ### Step 1：验证测试
 
-运行项目测试命令。如果测试失败：
+运行项目测试命令（声明"测试通过"前须执行 `_team-rules/verification-protocol.md` 的 5 个步骤）。如果测试失败：
 
 ```
-Tests failing (<N> failures). Must fix before completing:
-[Show failures]
-Cannot proceed with merge/PR until tests pass.
+测试失败（{N} 个失败）。完成前须修复：
+[展示失败详情]
+测试通过前不可执行 merge/PR。
 ```
 
-停止，不进入 Step 2。
+**失败处理**：停止，不进入 Step 2。根据失败类型采取行动：
+
+- **编排模式**：回退编排器，由编排器路由回 implAgent 修复（附上失败输出）
+- **独立使用**：向用户展示失败详情，推荐使用 `team-debug` 定位根因，修复后重新执行 Step 1
+
+不可忽略失败继续展示选项（FP-4）。
 
 ### Step 2：确定基准分支
 
@@ -76,39 +84,44 @@ Cannot proceed with merge/PR until tests pass.
 2. **从项目 AI 规范读取**：在 CLAUDE.md / .cursor/rules/ 中查找 `base_branch` 或 `default_branch` 配置项
 3. **从 Git 远程推断**：`git symbolic-ref refs/remotes/origin/HEAD | sed 's|refs/remotes/origin/||'`
 4. **常见分支名兜底**：按 `main` → `master` → `develop` 顺序检查本地是否存在
+5. **全部失败** → 触发 H3：向用户展示 `git branch --list` 和 `git remote -v` 输出，让用户指定基准分支（不可自动猜测）
 
 确定后运行 `git merge-base HEAD {base_branch}` 获取合并基点。
 
 ### Step 3：展示选项
 
 ```
-Implementation complete. What would you like to do?
+实现完成。请选择后续操作：
 
-1. Merge back to <base-branch> locally
-2. Push and create a Pull Request
-3. Keep the branch as-is (I'll handle it later)
-4. Discard this work
+1. 本地合并到 <base-branch>
+2. 推送并创建 Pull Request
+3. 保留当前分支（稍后处理）
+4. 丢弃本次工作
 
-Which option?
+请选择：
 ```
 
 ### Step 4：执行选择
 
 #### Option 1：本地合并
 
-1. 切换到基准分支并拉取最新
-2. 合并功能分支到基准分支
-3. 运行项目测试命令验证合并后无回归
-4. 删除功能分支
+1. 切换到基准分支并拉取最新（`git checkout {base} && git pull`）
+2. 合并功能分支（`git merge {branch} --no-ff`）
+3. **合并冲突处理**：如果 `git merge` 报告冲突，向用户展示冲突文件列表并暂停——由用户选择 (A) 手动解决冲突后继续、(B) 中止合并改为创建 PR、(C) 中止合并保留分支。不自动解决冲突
+4. 运行项目测试命令验证合并后无回归
+5. 删除功能分支
+
+> **验证协议**（步骤 4 声明"通过"前必须执行 `_team-rules/verification-protocol.md` 的 5 个步骤）
 
 #### Option 2：创建 PR
 
-1. 推送功能分支到远程
-2. 使用项目 PR 创建命令（如 `gh pr create`）创建 Pull Request
+1. 推送功能分支到远程（`git push -u origin {branch}`）。如果推送失败（auth 错误、远程未配置），向用户展示错误信息并暂停
+2. 使用项目 PR 创建命令创建 Pull Request（优先从 CLAUDE.md / .cursor/rules/ 获取 PR 命令；如未配置则使用 `gh pr create`）
+3. 向用户展示 PR URL，确认创建成功
 
 #### Option 3：保留分支
 
-报告：`Keeping branch <name>.`
+报告：`保留分支 <name>。`
 
 #### Option 4：丢弃
 
@@ -154,8 +167,6 @@ Which option?
 
 ## STOP Signals
 
-如果你发现自己即将做以下任何一件事——立即停止，重新审视：
-
 - 测试未通过就展示合并/PR 选项
 - 合并后没有重新运行测试就声明完成
 - 丢弃分支前没有要求用户输入 "discard" 确认
@@ -172,8 +183,3 @@ Which option?
 
 - `team-review` — 合并前确认审查已完成
 - `team-brainstorm` / `team-spec` — 下一个功能
-
-## 下一步
-
-- 分支处理完成后，继续下一个功能开发
-- 下一个功能开始时，推荐使用 `team-brainstorm` 或 `team-spec`

package/skills/team-impl/SKILL.md

@@ -5,41 +5,37 @@ description: Use when SDD exists and you need TDD implementation with 06-08 docs
 
 # Team Impl — 实现
 
-> **兼容工具**：Claude Code (`/team-impl`) · Cursor (Skill 自动发现)
-
 ## 角色定位
 
-你是 AI 协作团队中的 **实现专家**。你的核心职责是遵循 **TDD（测试驱动开发）** 红-绿-重构循环进行编码实现。
-
 ### 系统提示词
 
 ```
-你的思维方式：工匠——追求能工作的最简单方案，对过度设计保持警惕。
-
-你是一个 Team impl 专家。你的任务是：
-
-1. 理解规格：读取规格文件（完整模式 01-05；精简模式 03-04），理解任务目标、上下文、边界、风险
-2. 审计同步：对照 spec 分析当前代码基线，识别差距，显式列出困惑点
-3. TDD 开发：对每个功能点执行红-绿-重构循环（参考「为什么顺序很重要」和「硬重置规则」）
-4. 决策记录：记录技术选型、架构决策、回退决策
-5. 自检：测试、lint、CI、boundary、预算、Constitutional 合规
-
-关键区别：你不是机械地写代码。当发现 spec 有问题时必须回退到 specAgent；当遇到需要人类决策的问题时必须暂停等待人类介入。阅读 spec 或源码时产生的任何困惑必须显式记录，不可默默假设。如果发现先写了实现再写测试，必须删除代码重新从 RED 开始。
+角色：Team impl 实现专家
+核心原则：追求能工作的最简单方案，对过度设计保持警惕
+流程：TDD 红-绿-重构循环
+约束：
+- spec 有问题 → 回退 specAgent，不可自行决定
+- 需要人类决策 → 暂停等待人类介入
+- 阅读 spec/源码的困惑 → 显式记录，不可默默假设
+- 发现先写实现再写测试 → 删除代码，从 RED 重新开始
 ```
 
-### 推理指引
+### 推理检查点
 
-**角色心智模型**：你像一位工匠思考——"能工作的最简单方案是什么？"你天生对过度设计保持警惕。三行重复代码优于一个过早的抽象。你先让测试通过，再让代码漂亮——顺序不可逆，因为"漂亮"是主观判断而"通过"是客观事实（FP-2）。面对困惑时你停下来记录而非默默假设，因为假设是 bug 的温床。
+**核心指令**：优先让测试通过，再优化代码。三行重复代码优于过早抽象。测试通过是客观事实，代码美观是主观判断——顺序不可逆（FP-2）。困惑必须记录，不可默默假设。
 
-**第一性原理推理框架**：在每个 TDD 循环开始前，依次推理——
+**第一性原理推理框架**：首个功能点 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
 
@@ -86,31 +82,15 @@ NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
 1. 阅读 spec 中涉及的文件，确认当前实现状态
 2. 列出当前代码 vs spec 要求之间的差距
 3. 确认 spec 方案在当前基线上可行
-4. **环境验证**：运行项目构建/测试命令确认基线可编译、已有测试通过（避免在已损坏的基线上开发）
+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 红-绿-重构循环
 
-对每个功能点执行以下循环：
-
-```mermaid
-flowchart TD
-    RED["🔴 RED: 写测试"] --> VERIFY_RED{"测试失败？"}
-    VERIFY_RED -->|"是（预期）"| GREEN["🟢 GREEN: 最小实现"]
-    VERIFY_RED -->|"否（通过了）"| FIX_TEST["修复测试（测试可能太弱）"]
-    FIX_TEST --> RED
-    GREEN --> VERIFY_GREEN{"测试通过？"}
-    VERIFY_GREEN -->|"是"| REFACTOR["🔵 REFACTOR: 优化"]
-    VERIFY_GREEN -->|"否"| FIX_IMPL["修复实现"]
-    FIX_IMPL --> GREEN
-    REFACTOR --> VERIFY_REFACTOR{"仍然通过？"}
-    VERIFY_REFACTOR -->|"是"| COMMIT["提交"]
-    VERIFY_REFACTOR -->|"否"| ROLLBACK["回滚重构"]
-    ROLLBACK --> REFACTOR
-```
+对每个功能点执行循环：RED → GREEN → REFACTOR → COMMIT。
 
 #### 循环 1：红（Red）— 写测试
 
@@ -119,7 +99,7 @@ flowchart TD
    - 正常路径（Happy Path）
    - 边界条件（SDD §七 边界条件）
    - 异常场景（SDD §八 异常场景）
-3. 运行测试 → **预期失败**（因为还没有实现）
+3. 运行测试 → **预期失败**（尚无实现）
 4. **门禁产出**：必须先在 `06-tdd-log.md` 记录以下结构化条目，再进入 GREEN 阶段：
 
    ```
@@ -131,7 +111,7 @@ flowchart TD
    - 时间：{记录当前时间，格式 YYYY-MM-DD HH:MM}
    ```
 
-> **每步必须**：先写测试再写实现 → 覆盖 Happy Path + 边界 + 异常 → 确认测试输出含 FAIL 标识 → 在 06-tdd-log.md 记录 RED（含时间戳）后再进入 GREEN
+> **每步必须**：先写测试再写实现 → 覆盖 Happy Path + 边界 + 异常 → 确认测试输出含 FAIL 标识 → 在 06-tdd-log.md 记录 RED（含时间戳）→ `git commit -m "test: {功能点} (RED)"` → 然后才能进入 GREEN
 
 #### 循环 2：绿（Green）— 写实现
 
@@ -145,7 +125,7 @@ flowchart TD
    - 实现文件：{path}
    - 测试命令：{command}
    - 通过输出：{粘贴关键输出，含 PASS/OK 标识}
-   - 时间：{记录当前时间，格式 YYYY-MM-DD HH:MM，必须晚于 RED 时间}
+   - 时间：{记录当前时间，格式 YYYY-MM-DD HH:MM，不早于 RED 时间}
    ```
 
 > **每步必须**：只写让测试通过的最少代码 → 严格遵循规格范围 → 修改实现（非测试）让测试通过 → 优先简单直接方案（三行重复代码优于过早抽象）
@@ -162,14 +142,14 @@ flowchart TD
    - 重构内容：{简述改动}
    - 测试命令：{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** 立即执行 `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 修复验证模式
 
@@ -180,19 +160,19 @@ flowchart TD
 → 回滚修复 → 运行（必须失败）→ 恢复修复 → 运行（必须通过）
 ```
 
-如果"回滚修复后测试仍然通过"，说明回归测试没有覆盖修复的逻辑——测试太弱，需要重写。
+如果"回滚修复后测试仍通过"，说明回归测试未覆盖修复逻辑——测试太弱，需重写。
 
 #### 为什么顺序很重要
 
-以下借口不成立——TDD 先写测试不是仪式，而是有工程理由的：
+以下借口不成立——TDD 先写测试有明确的工程理由：
 
-| 借口 | 为什么不成立 |
-| ---- | ------------ |
-| "先实现再补测试，效果一样" | 后写测试 = "这段代码做了什么？"；先写测试 = "这段代码应该做什么？"。后写测试被实现偏见污染，你测试的是你构建的，不是需求的 |
-| "我已经手动测试过了" | 手动测试没有记录，无法重复运行。手动测试通过 ≠ 自动化测试通过 |
-| "删掉 X 小时的工作太浪费了" | 沉没成本谬误。保留未经验证的代码 = 技术债务。删掉重新 TDD 才是对的 |
-| "TDD 太教条了，实用主义意味着灵活" | TDD 就是实用主义——调试比写测试慢得多。先写测试 = 10 分钟；先写实现再调试 = 1 小时 |
-| "已有代码没测试" | 你在改进它。先给已有代码加测试，再改它 |
+| 借口 | 反驳 |
+| ---- | ---- |
+| "先实现再补测试，效果一样" | 后写测试被实现偏见污染（FP-2）：测的是已构建的行为，不是需求 |
+| "我已经手动测试过了" | 手动测试无记录、不可重复、不等于自动化测试通过 |
+| "删掉 X 小时的工作太浪费了" | 沉没成本谬误。未经验证的代码 = 技术债务 |
+| "TDD 太教条了" | TDD 是实用主义——调试耗时远超写测试 |
+| "已有代码没测试" | 先给已有代码加测试，再改它 |
 
 #### 硬重置规则
 
@@ -212,15 +192,15 @@ flowchart TD
 
 | 卡住场景 | 解决方案 |
 | -------- | -------- |
-| 不知道怎么写测试 | 先写你希望存在的 API。先写断言。问你的人类伙伴 |
-| 测试太难写 | 设计太复杂。简化接口。难测 = 难用 |
-| 必须 mock 一切 | 代码耦合太紧。使用依赖注入解耦 |
-| 测试 setup 太大 | 提取 helper。还是复杂？简化设计 |
-| 测试通过但感觉不对 | 检查是否只测了 Happy Path。加边界测试和异常测试 |
+| 不知道怎么写测试 | 先写期望的 API 调用和断言；仍不行则问人类 |
+| 测试太难写 | 设计太复杂，简化接口。难测 = 难用 |
+| 必须 mock 一切 | 耦合太紧，用依赖注入解耦 |
+| 测试 setup 太大 | 提取 helper；仍复杂则简化设计 |
+| 测试通过但感觉不对 | 检查是否只覆盖了 Happy Path，补边界和异常测试 |
 
-### Phase 2：决策记录
+### Phase 2：决策记录（与 Phase 1 同步进行）
 
-每次遇到以下情况时，记录到 `08-ai-decisions.md`（模板见 `references/08-ai-decisions-template.md`）：
+在 Phase 1 TDD 循环中，遇到以下情况时**实时**记录到 `08-ai-decisions.md`（模板见 `references/08-ai-decisions-template.md`），不可等编码完成后回忆补写：
 
 | 决策类型 | 必须记录的内容                   | 示例                                                                                   |
 | -------- | -------------------------------- | -------------------------------------------------------------------------------------- |
@@ -232,9 +212,9 @@ flowchart TD
 
 > 每条决策必须说明：选择了什么 + 为什么选择 + 拒绝了什么替代方案 + 为什么拒绝。
 
-### Phase 3：Prompt 记录
+### Phase 3：Prompt 记录（与 Phase 1 同步进行）
 
-在 `07-prompt-log.md` 中记录每次关键的 Prompt（模板见 `references/07-prompt-log-template.md`）。每条记录必须包含：
+在 Phase 1 TDD 循环中**实时**记录关键 Prompt 到 `07-prompt-log.md`（模板见 `references/07-prompt-log-template.md`）。每条记录必须包含：
 
 1. **五要素表格**：目标、上下文、边界、输出格式、验证标准（缺一不可）
 2. **效果评估**：成功/失败/部分成功 + 具体说明
@@ -250,11 +230,18 @@ flowchart TD
 
 > **验证协议**（步骤 1-3 每次声明"通过"前必须执行 `_team-rules/verification-protocol.md` 的 5 个步骤）
 
-4. **检查 boundary 遵守**：确认没有修改 `04-boundary.md` 禁止修改的文件
+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 检查失败：
+
+1. **定位失败原因**：完整阅读输出，不跳过 warning
+2. **修复问题**：对修复仍须遵循 TDD——先写（或确认已有）覆盖该失败场景的测试（RED），再修复代码（GREEN）
+3. **重新执行完整验证**：修复后从步骤 1 重新运行所有检查，不可只运行"刚才失败的那个"
+4. **更新文档**：将修复循环（问题描述 + RED/GREEN + 验证结果）追加到 `06-tdd-log.md`，修复决策记录到 `08-ai-decisions.md`
 
-如果 CI 全量检查失败，修复后再继续。如果预算超支，砍范围而不是放宽预算。
+不可跳过失败继续后续步骤（FP-4）。预算超支砍范围，不放宽预算。
 
 ### 回退路由
 
@@ -269,9 +256,9 @@ flowchart TD
 | 发现 testAgent 报告的 bug 是 impl 问题                | 自己修复       | 直接       | testAgent 的 bug 报告      |
 | 发现 reviewAgent 报告的 P0/P1 bug                     | 自己修复       | 直接       | reviewAgent 的 review 报告 |
 
-## 产出文件
+**回退修复要求**：自己修复时仍须遵循 TDD——先写回归测试复现问题（RED），再修复代码（GREEN），追加到 `06-tdd-log.md`，决策记录到 `08-ai-decisions.md`。修复后重新运行全量测试确认无回归。
 
-每个文件必须严格遵循模板格式（模板文件见 `references/` 目录）。
+## 产出文件
 
 | 文件 | 模板位置 | 说明 |
 | ---- | -------- | ---- |
@@ -281,21 +268,29 @@ flowchart TD
 
 ## STOP Signals
 
-如果你发现自己即将做以下任何一件事——立即停止，重新审视：
-
 - 没读 spec 就开始编码，或发现 spec 问题不回退而自己决定
 - 跳过 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
@@ -318,11 +313,6 @@ CI 检查：通过/失败
 → 编排器将调度 testAgent 进行测试验证
 ```
 
-## 下一步
-
-- 产出 06-08 文件后，推荐使用 `team-test` 进行测试审计
-- 如果发现 bug，使用 `team-debug` 系统调试
-
 ## 集成关系
 
 **被谁调用：**