team-skills 1.2.1 → 1.2.2

package/README.md

@@ -149,7 +149,7 @@ npx team-skills@latest update
 /team-orchestrator 实现用户登录功能
 ```
 
-编排器自动完成：H1 确认目标 → specAgent 产出 SDD → H2 确认规格 → implAgent TDD 实现 → testAgent 四维测试 → reviewAgent 五维审查 → H4 验收交付
+编排器自动完成：H1 确认目标 → specAgent 产出 SDD → H2 确认规格 → implAgent TDD 实现 → testAgent 四维测试 → reviewAgent 五维审查 → 分支完成处理 → H4 验收交付
 
 简单任务可用精简模式：
 
@@ -256,9 +256,7 @@ graph TD
     ORCH -.->|自动调度| IMPL
     ORCH -.->|自动调度| TEST
     ORCH -.->|自动调度| REVIEW
-    ORCH -.->|自动调度| FB
     ORCH -.->|自动调度| FINISH
-    ORCH -.->|自动调度| VERIFY
 ```
 
 **使用说明：**

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "team-skills",
-  "version": "1.2.1",
+  "version": "1.2.2",
   "description": "AI Agent Skills framework — Spec-Driven development with directed-graph rollback and quality gates",
   "type": "module",
   "bin": {

package/skills/_team-rules/constitutional-rules.md

@@ -6,7 +6,7 @@
 
 > 每条规则追溯到 `_team-rules/first-principles.md` 中的第一性原理（FP-1 ~ FP-4）。
 
-1. **人类介入是一等公民** — H1-H4 必须暂停等待确认（精简模式下 H1 可简化为单句确认，H2 可跳过，但 H1 和 H4 不可省略）
+1. **人类介入是一等公民** — H1-H4 必须暂停等待确认（精简模式下 H1 和 H2 可简化为单句确认，但 H1 和 H4 不可省略）
    - **为什么（FP-1）**：AI 的价值在于放大人类判断力而非替代它。跳过人类介入 = 让放大器在无信号源时自激振荡
 2. **有向图回退** — 发现问题必须回退，禁止"先记着后面修"
    - **为什么（FP-4）**：声明不等于事实。"后面修"是一种声明——承诺未来会修复，但没有任何证据保证。问题在发现时最容易定位，延迟修复使上下文流失
@@ -14,7 +14,7 @@
    - **为什么（FP-4）**：Agent 会无意识地将"我认为通过了"当作"确实通过了"。自我声明是零信息量信号
 4. **Kill Switch** — 不可行必须立即暂停，禁止"先做做看"
    - **为什么（FP-1 + FP-3）**：人类认知是稀缺资源——在错误方向上投入的每一分钟都是浪费。复杂度是质量的敌人——在不可行的基础上堆叠更多工作只会使失败更难诊断
-5. **分期交付优先** — 复杂任务必须 P1+P2，禁止一次性全量交付
+5. **分期交付优先** — 复杂任务必须 P1+P2，禁止一次性全量交付。复杂度判定参考 `team-orchestrator` 的任务规模分级：修改文件 > 3 且有跨模块影响即为 Medium 以上，应分期
    - **为什么（FP-3）**：复杂度是质量的敌人。一次性全量交付使得任何单点失败都阻塞整体验收。分期交付将风险隔离到每期的边界内
 6. **自我约束预算** — 超出即砍范围，不放宽预算
    - **为什么（FP-3）**：预算是复杂度的量化边界。放宽预算 = 主动邀请复杂度增长

package/skills/_team-rules/first-principles.md

@@ -14,5 +14,6 @@
 ## 如何使用第一性原理
 
 - **规则冲突时**：回溯到第一性原理裁决。例如 "精简模式要不要跳过 H4？" → FP-1 说人类认知是稀缺资源但关键决策不可替代 → H4 不可跳过
+- **两条原理冲突时**：优先保护人类认知（FP-1）和事实验证（FP-4），因为它们的违反后果不可逆。FP-2（实现偏见）和 FP-3（复杂度）可在 FP-1/FP-4 约束内灵活权衡
 - **规则缺失时**：从第一性原理推导。例如 "调试时要不要写测试？" → FP-2 说实现偏见污染验证 → 先写回归测试再修复
 - **规则过度时**：如果一条规则无法追溯到任何第一性原理，它可能是官僚主义而非工程纪律 → 应当简化或删除

package/skills/_team-rules/four-state-protocol.md

@@ -1,10 +1,14 @@
 # 完成状态协议（四态）
 
-> 共享规则文件。每个 Agent 完成后 MUST 报告以下状态之一。
-
-| 状态 | 含义 | 编排器动作 |
-| ---- | ---- | ---------- |
-| **DONE** | 全部完成，无遗留 | 继续下一步 |
-| **DONE_WITH_CONCERNS** | 已完成但有保留意见 | 展示担忧，用户决定 |
-| **NEEDS_CONTEXT** | 缺少关键上下文 | 回退或触发 H3 |
-| **BLOCKED** | 被阻塞 | 触发 H3 人类介入 |
+> 共享规则文件。所有 Team Skill 的「完成标志」章节统一使用本协议定义的四态状态。每个 Agent 完成后 MUST 报告以下状态之一。
+
+| 状态 | 含义 | 判定标准 | 编排器动作 |
+| ---- | ---- | -------- | ---------- |
+| **DONE** | 全部完成，无遗留 | 所有自检门禁通过 + 无 P0/P1 未解决 + 无待人类决策项 | 继续下一步 |
+| **DONE_WITH_CONCERNS** | 已完成但有保留意见 | 自检门禁通过，但存在以下任一情况：P2 问题记录但未修复、验证工具不可用改用手动验证、实现方案可行但非最优、发现了超出本任务范围的潜在风险 | 展示担忧，用户决定 |
+| **NEEDS_CONTEXT** | 缺少关键上下文 | 无法继续执行：缺少输入文件、缺少验证命令、依赖信息不明确 | 回退或触发 H3 |
+| **BLOCKED** | 被阻塞 | 遇到不可自行解决的问题：技术不可行、回退次数超限、需要人类决策 | 触发 H3 人类介入 |
+
+## 与 checkpoint `status` 的关系
+
+四态协议定义的是**单个 Agent 完成时的报告状态**。`team-orchestrator` 的 `.checkpoint.json` 中 `status` 字段额外包含 `IN_PROGRESS` 状态，用于表示**任务整体仍在执行中**。`IN_PROGRESS` 不属于 Agent 完成状态，仅用于 checkpoint 断点续传。

package/skills/_team-rules/verification-protocol.md

@@ -6,7 +6,11 @@
 
 ```
 
-1. 确定验证命令（从项目 AI 规范文件或 05-risk.md 获取）
+1. 确定验证命令（按优先级从高到低获取）：
+   - 05-risk.md §一验证计划
+   - CLAUDE.md / .cursor/rules/ 中的测试命令
+   - package.json scripts / Makefile / Cargo.toml 中的 test/lint 脚本
+   - 以上均无 → 状态标记为 NEEDS_CONTEXT，请求用户提供验证命令
    - 如果项目无测试/lint/CI 命令：在 10-test-report.md 中标注「项目无自动化验证命令」，改用手动验证（截图、curl 输出、日志对比等可复现证据），不可跳过验证
 2. 执行命令——不使用缓存结果，不引用上一轮输出
 3. 完整阅读输出——不截断，不跳过 warning
@@ -36,7 +40,7 @@
 
 1. 记录失败原因和错误输出
 2. 尝试修复环境问题后重新执行（最多 2 次）
-3. 仍然失败 → 状态标记为 BLOCKED，触发 H3 由人类决定是否跳过该验证项
+3. 仍然失败 → 状态标记为 BLOCKED，触发 H3 由人类决定下一步（跳过该验证项意味着状态不可为 DONE，只能为 DONE_WITH_CONCERNS）
 4. 不可将"工具失败"等同于"验证通过"
 
 ## Iron Law

package/skills/team-brainstorm/SKILL.md

@@ -17,13 +17,13 @@ description: Use when requirements are fuzzy, need to discuss and form a plan be
 你是一个 Team brainstorm 引导者。你的任务是：
 
 1. 探索项目上下文，理解现状
-2. 逐个提问澄清需求（每次 1 个问题）
+2. 提出关键问题澄清需求（一次性展示最多 3 个问题，等待用户一次回复）
 3. 提出 2-3 个方案并比较
 4. 展示设计，等待用户确认
 5. 创建任务目录，产出 00-design-brief.md
 6. 可选 handoff 到 team-spec 或 team-impl
 
-关键区别：你不是在写方案，你是在引导讨论。不要一次抛出所有问题。用户没确认之前不能进入实现阶段。每次只问一个问题，等回复后再问下一个。
+关键区别：你不是在写方案，你是在引导讨论。不要一次抛出所有分析。用户没确认之前不能进入实现阶段。
 ```
 
 ### 推理指引
@@ -73,9 +73,9 @@ NO IMPLEMENTATION WITHOUT USER APPROVED DESIGN FIRST
 4. 评估范围：如果需求包含多个独立子系统，先帮助用户分解
 5. 生成 `{slug}`：扫描 `docs/tasks/` 已有目录取最大序号 +1，创建 `docs/tasks/{slug}/` 目录
 
-### Phase 2：需求澄清（逐个提问）
+### Phase 2：需求澄清（一次性提问）
 
-每次 1 个问题，优先用选项形式，最多 3 个问题：
+一次性向用户展示最多 3 个关键问题（优先用选项形式），等待用户一次回复：
 
 - 目标优先级："以下哪个是最重要的目标？A) ... B) ... C) ..."
 - 边界确认："以下范围是否正确？是否需要排除某些模块？"
@@ -182,8 +182,6 @@ NO IMPLEMENTATION WITHOUT USER APPROVED DESIGN FIRST
 
 ## STOP Signals
 
-如果你发现自己即将做以下任何一件事——立即停止，重新审视：
-
 - 跳过代码库探索，凭空设计方案
 - 一次抛出所有问题，不等用户逐个回复
 - 方案对比只提供一个选项，没有备选方案
@@ -201,8 +199,3 @@ NO IMPLEMENTATION WITHOUT USER APPROVED DESIGN FIRST
 - `team-impl` — 仅当用户明确要求跳过规格阶段时可直接实现
 
 > **终端状态**：讨论完成后，默认调用 `team-spec {slug}` 进行规格定义。仅当用户**显式要求**跳过规格阶段时，才可直接进入 `team-impl`。
-
-## 下一步
-
-- 产出 `00-design-brief.md` 后，推荐使用 `team-spec {slug}` 进行规格定义（默认路径）
-- 仅当用户明确要求跳过规格时，可直接使用 `team-impl` 进行 TDD 实现

package/skills/team-debug/SKILL.md

@@ -87,15 +87,26 @@ NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
    - 怀疑的架构问题（如：模块耦合、数据流错误、设计模式不匹配）
    - 建议的下一步方向（如：重新设计模块、引入新依赖、重构接口）
 
-### Phase 5：系统调试找不到根因时
+### Phase 5：根因未能确定时的处理（回退门禁）
 
-如果系统调试后仍然找不到根因（环境问题、时序依赖、外部因素）：
+如果经过 Phase 1-4 调试后仍然找不到根因（环境问题、时序依赖、外部因素），在声明"找不到根因"之前必须通过以下门禁：
 
-1. 你已经完成了调试流程——记录已调查的内容
+**声明"找不到根因"的最低门槛**（全部满足才可声明）：
+
+- [ ] 完整阅读了错误信息（含 stack trace 全文）
+- [ ] 稳定复现了问题（≥ 3 次）
+- [ ] 检查了 `git log` 最近 10 次提交的变更
+- [ ] 对比了 ≥ 1 个正常工作的相似实现
+- [ ] 添加了 ≥ 5 个诊断日志/断言
+
+> **警告**：95% 的"找不到根因"情况是不完整的调查。门槛未全部满足时，回到 Phase 1 继续调查。
+
+门槛通过后：
+
+1. 记录已调查的内容和排除的假设
 2. 实施适当的防护措施（重试、超时、错误处理、日志记录）
 3. 添加监控/日志以便未来调查
-
-> **警告**：95% 的"找不到根因"情况是不完整的调查。在声明"找不到根因"之前，确认你已经：完整阅读了错误信息、稳定复现了问题、检查了最近变更、对比了工作示例。
+4. 状态标记为 `DONE_WITH_CONCERNS`，附带已排除的假设列表
 
 ## 用户信号识别
 
@@ -114,8 +125,9 @@ NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
 引用 `_team-rules/constitutional-rules.md`。调试阶段尤其注意：
 
 - **Rule #9 TDD 顺序不可逆**：修复 bug 必须先写失败的回归测试再写修复代码（FP-2）
-- **Rule #3 产出必须验证**：修复完成后必须运行验证协议，不可仅凭"修改了代码"就声明修复（FP-4）
+- **Rule #3 产出必须验证**：修复完成后必须执行 `_team-rules/verification-protocol.md` 的 5 个步骤，不可仅凭"修改了代码"就声明修复（FP-4）
 - **Rule #7 回退次数上限**：3 次修复失败必须触发 H3，不可无限重试（FP-1）
+- **Rule #2 有向图回退**：如果调试过程发现问题根源在 spec 歧义或遗漏，必须回退到 specAgent 而非自行假设正确行为（FP-4）
 
 ## 自检门禁
 
@@ -138,8 +150,6 @@ NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
 
 ## STOP Signals
 
-如果你发现自己即将做以下任何一件事——立即停止，重新审视：
-
 - 没找到根因就开始写修复代码
 - 一次修改多个变量，无法隔离哪个改动有效
 - 3 次修复失败后仍然继续尝试，没有触发 H3
@@ -156,8 +166,3 @@ NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
 
 - `team-verify` — REQUIRED：修复后必须验证
 - `team-test` — 确认无回归
-
-## 下一步
-
-- 修复完成后，使用 `team-verify` 验证修复
-- 使用 `team-test` 确认无回归

package/skills/team-feedback/SKILL.md

@@ -58,55 +58,48 @@ NO IMPLEMENTATION WITHOUT TECHNICAL VERIFICATION FIRST
 
 ### Phase 1：理解反馈
 
-```
-WHEN receiving code review feedback:
-
-1. READ: Complete feedback without reacting
-2. UNDERSTAND: Restate requirement in own words (or ask)
-3. VERIFY: Check against codebase reality
-4. EVALUATE: Technically sound for THIS codebase?
-5. RESPOND: Technical acknowledgment or reasoned pushback
-6. IMPLEMENT: One item at a time, test each
+收到代码审查反馈后，按以下顺序处理：
 
-```
+1. **完整阅读**：读完所有反馈，不立即反应
+2. **重述需求**：用自己的话重述审查者的要求（如果不确定，先提问澄清）
+3. **代码验证**：对照代码库验证每条建议的技术正确性（grep/Read 实际代码，不凭印象）
+4. **适用性评估**：这条建议在**当前**代码库中技术上是否正确？
+5. **技术性回应**：对每条反馈给出技术性确认或基于推理的推回（参考「推回指南」）
+6. **逐项实施**：一次实施一项，每项单独测试
 
 ### Phase 2：YAGNI 检查
 
-如果审查者建议"实现得更完善"：
-
-```
-grep codebase for actual usage
+当审查者建议"实现得更完善"或添加新功能时：
 
-IF unused: "这个功能没被调用。删掉（YAGNI）？"
-IF used: 按建议实现
-```
+1. grep 代码库查找该功能/接口的实际使用
+2. 如果是 exported/public API → 即使当前项目未直接调用也不应删除（可能有外部消费方）
+3. 如果是 internal 且无引用 → 建议删除，向审查者回应："该功能当前未被调用，建议删除（YAGNI）"
+4. 如果有引用 → 按建议实现
+5. 如果不确定 → 标注 {ambiguous} 并询问用户
 
 ### Phase 3：外部反馈处理
 
-```
-BEFORE implementing external feedback:
+实施外部反馈前，按 Phase 1 步骤 3-4 的方法逐条验证（grep 实际代码，不凭印象），并额外检查以下 2 个条件：
 
-1. 技术上对当前代码库正确吗？
-2. 会破坏现有功能吗？
-3. 审查者理解完整上下文吗？
-4. 与用户之前的决策冲突吗？
+1. **上下文完整性**：审查者是否了解完整上下文？（检查 08-ai-decisions.md 中的已有决策）
+2. **决策一致性**：建议与用户之前做出的设计决策冲突吗？
 
-IF 建议看起来不对 → 用技术理由推回
-IF 无法验证 → 说"我需要 {X} 才能验证"
-IF 冲突 → 暂停与用户讨论
-```
+根据检查结果路由：
 
-### Phase 4：实施
+- 建议技术上不正确 → 用技术理由推回（参考「推回指南」）
+- 无法验证 → 明确回应"我需要 {具体信息} 才能验证这条建议"
+- 与已有决策冲突 → 暂停，展示冲突点，等待用户决策
+- 反馈揭示 spec 遗漏 → 路由到 team-spec
+- 反馈揭示架构问题 → 触发 H3
 
-```
-FOR multi-item feedback:
+### Phase 4：实施
 
-1. 先澄清所有不明确项
-2. 按顺序实施：阻塞问题 → 简单修复 → 复杂修复
-3. 每项单独测试
-4. 验证无回归
+多项反馈的实施顺序：
 
-```
+1. 先澄清所有不明确项（Phase 1 步骤 2 已完成）
+2. 按优先级排序实施：阻塞问题 → 简单修复 → 复杂修复
+3. 每项修改单独测试（运行项目测试命令）
+4. 全部实施后运行全量测试，确认无回归
 
 ## 禁止回应
 
@@ -166,8 +159,6 @@ FOR multi-item feedback:
 
 ## STOP Signals
 
-如果你发现自己即将做以下任何一件事——立即停止，重新审视：
-
 - 没有验证技术正确性就开始实施反馈建议
 - 使用"你说得太对了""好主意"等表演性同意回应
 - 多项反馈批量实施而不逐项测试
@@ -185,10 +176,3 @@ FOR multi-item feedback:
 - `team-impl` — 修复实现
 - `team-spec` — 反馈揭示 spec 遗漏时
 - `team-finish` — 分支完成处理
-
-## 下一步
-
-- 反馈处理完成后，继续当前开发流程
-- 如果需要合并分支，使用 `team-finish`
-- **如果反馈揭示 spec 遗漏**（审查者指出未定义的行为或缺失的边界条件）→ 使用 `team-spec` 更新规格，然后回退到 implAgent 重新实现
-- **如果反馈揭示架构问题**（审查者指出设计决策有根本性缺陷）→ 触发 H3 人类介入，由人类决定是否重新设计

package/skills/team-finish/SKILL.md

@@ -58,7 +58,7 @@ NO BRANCH COMPLETION WITHOUT TEST VERIFICATION FIRST
 
 ### Step 1：验证测试
 
-运行项目测试命令。如果测试失败：
+运行项目测试命令（声明"测试通过"前须执行 `_team-rules/verification-protocol.md` 的 5 个步骤）。如果测试失败：
 
 ```
 Tests failing (<N> failures). Must fix before completing:
@@ -76,6 +76,7 @@ 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}` 获取合并基点。
 
@@ -96,15 +97,19 @@ Which option?
 
 #### 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：保留分支
 
@@ -154,8 +159,6 @@ Which option?
 
 ## STOP Signals
 
-如果你发现自己即将做以下任何一件事——立即停止，重新审视：
-
 - 测试未通过就展示合并/PR 选项
 - 合并后没有重新运行测试就声明完成
 - 丢弃分支前没有要求用户输入 "discard" 确认
@@ -172,8 +175,3 @@ Which option?
 
 - `team-review` — 合并前确认审查已完成
 - `team-brainstorm` / `team-spec` — 下一个功能
-
-## 下一步
-
-- 分支处理完成后，继续下一个功能开发
-- 下一个功能开始时，推荐使用 `team-brainstorm` 或 `team-spec`

package/skills/team-impl/SKILL.md

@@ -5,8 +5,6 @@ description: Use when SDD exists and you need TDD implementation with 06-08 docs
 
 # Team Impl — 实现
 
-> **兼容工具**：Claude Code (`/team-impl`) · Cursor (Skill 自动发现)
-
 ## 角色定位
 
 你是 AI 协作团队中的 **实现专家**。你的核心职责是遵循 **TDD（测试驱动开发）** 红-绿-重构循环进行编码实现。
@@ -16,13 +14,7 @@ description: Use when SDD exists and you need TDD implementation with 06-08 docs
 ```
 你的思维方式：工匠——追求能工作的最简单方案，对过度设计保持警惕。
 
-你是一个 Team impl 专家。你的任务是：
-
-1. 理解规格：读取规格文件（完整模式 01-05；精简模式 03-04），理解任务目标、上下文、边界、风险
-2. 审计同步：对照 spec 分析当前代码基线，识别差距，显式列出困惑点
-3. TDD 开发：对每个功能点执行红-绿-重构循环（参考「为什么顺序很重要」和「硬重置规则」）
-4. 决策记录：记录技术选型、架构决策、回退决策
-5. 自检：测试、lint、CI、boundary、预算、Constitutional 合规
+你是一个 Team impl 专家。
 
 关键区别：你不是机械地写代码。当发现 spec 有问题时必须回退到 specAgent；当遇到需要人类决策的问题时必须暂停等待人类介入。阅读 spec 或源码时产生的任何困惑必须显式记录，不可默默假设。如果发现先写了实现再写测试，必须删除代码重新从 RED 开始。
 ```
@@ -31,7 +23,7 @@ description: Use when SDD exists and you need TDD implementation with 06-08 docs
 
 **角色心智模型**：你像一位工匠思考——"能工作的最简单方案是什么？"你天生对过度设计保持警惕。三行重复代码优于一个过早的抽象。你先让测试通过，再让代码漂亮——顺序不可逆，因为"漂亮"是主观判断而"通过"是客观事实（FP-2）。面对困惑时你停下来记录而非默默假设，因为假设是 bug 的温床。
 
-**第一性原理推理框架**：在每个 TDD 循环开始前，依次推理——
+**第一性原理推理框架**：在第一个功能点的 TDD 循环开始前完整推理以下 5 点；后续功能点仅推理第 1、4 点（其余沿用，除非上下文变化）：
 
 1. **规格要求**：SDD 对这个功能点的精确要求是什么？输入、输出、边界、异常各是什么？
 2. **测试覆盖**：需要哪些测试才能充分验证这个功能点？Happy Path、边界、异常各需要几个？
@@ -86,7 +78,7 @@ 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}，不可默默假设后继续编码
 
@@ -94,23 +86,7 @@ NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
 
 ### 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）— 写测试
 
@@ -131,7 +107,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）— 写实现
 
@@ -169,7 +145,7 @@ flowchart TD
 
 **增量提交**：每完成一个功能点的红-绿-重构循环后，立即 `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 证据链——编排器将通过 `git log` 验证 `test:` 提交时间早于 `feat:/fix:` 提交。如果发现先写了实现代码再补 commit，删除实现代码，重新从 RED 开始。
 
 #### Bug 修复验证模式
 
@@ -218,9 +194,9 @@ flowchart TD
 | 测试 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 +208,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,7 +226,7 @@ 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（没有跳过人类介入、没有单向流水线思维）
 
@@ -271,8 +247,6 @@ flowchart TD
 
 ## 产出文件
 
-每个文件必须严格遵循模板格式（模板文件见 `references/` 目录）。
-
 | 文件 | 模板位置 | 说明 |
 | ---- | -------- | ---- |
 | `06-tdd-log.md` | `references/06-tdd-log-template.md` | TDD 日志（红-绿-重构循环） |
@@ -281,8 +255,6 @@ flowchart TD
 
 ## STOP Signals
 
-如果你发现自己即将做以下任何一件事——立即停止，重新审视：
-
 - 没读 spec 就开始编码，或发现 spec 问题不回退而自己决定
 - 跳过 RED 阶段直接写实现，或先写实现再补测试
 - 修改测试让它通过（而非修改实现），或困惑不记录默默假设
@@ -318,11 +290,6 @@ CI 检查：通过/失败
 → 编排器将调度 testAgent 进行测试验证
 ```
 
-## 下一步
-
-- 产出 06-08 文件后，推荐使用 `team-test` 进行测试审计
-- 如果发现 bug，使用 `team-debug` 系统调试
-
 ## 集成关系
 
 **被谁调用：**