team-skills 1.2.3 → 1.3.0

package/skills/team-debug/SKILL.md

@@ -12,23 +12,13 @@ description: Use when encountering any bug, test failure, or unexpected behavior
 ```
 角色：调试专家——找到根因再修复，症状修复是失败
 核心原则：跟着证据走，每条假设必须有物证支撑
-流程：
-1. 根因调查：收集证据，定位问题源头
-2. 模式分析：对比工作示例，识别差异
-3. 假设验证：形成单一假设，最小化验证
-4. 修复实现：先写失败测试，再修复代码
-5. 3 次修复失败 → STOP，质疑架构，触发 H3
-约束：
-- 未找到根因前不提修复方案
-- 用户说"别猜了""那个不是发生了吗" → 正在假设而非验证，回到证据收集
-- 调试后仍找不到根因 → 记录已调查内容，实施防护措施
 ```
 
 ### 推理检查点
 
-**核心指令**：每次修复必须能解释"为什么之前坏了"。"应该能修好"是无效声明（FP-4）。95% 的"找不到根因"是调查不充分。
+> 每次修复必须能解释"为什么之前坏了"。"应该能修好"是无效声明（FP-4）。95% 的"找不到根因"是调查不充分。
 
-**第一性原理推理框架**：
+**推理框架**：
 
 1. **证据收集**：完整错误信息、stack trace 指向、错误码含义
 2. **变更追溯**：最后一次正常时间点 → 之间的变更（git log、依赖更新、环境变化）
@@ -59,111 +49,110 @@ NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
 
 ### Phase 1：根因调查
 
-1. **完整阅读错误信息** — 不跳过 stack trace、行号、错误码
-2. **稳定复现** — 确认触发条件和频率
-3. **检查最近变更** — `git diff`、最近 commits、依赖变更
-4. **多组件系统** — 在每层边界添加诊断埋点，定位故障层
+1. **READ** 完整错误信息 — 不跳过 stack trace、行号、错误码
+2. **EXEC** 稳定复现 — 确认触发条件和频率
+3. **READ** `git diff` + 最近 commits + 依赖变更 — 检查最近变更
+4. **IF** 多组件系统 → 在每层边界添加诊断埋点，定位故障层
 
 ### Phase 2：模式分析
 
-1. 找到代码库中相似的工作示例
-2. 完整阅读参考实现（不 skim）
-3. 列出工作与失败之间的每个差异
-4. 不假设"那个差异不重要"
+1. **READ** 代码库中相似的工作示例（完整阅读，不 skim）
+2. **WRITE**（对话中）工作与失败之间的每个差异
+3. **ASSERT** `每个差异已解释`（不可假设"那个差异不重要"）
 
 ### Phase 3：假设验证
 
-1. 形成单一假设："我认为 X 是根因，因为 Y"
-2. 做最小变更验证假设
-3. 一次只变一个变量
-4. 验证通过 → Phase 4；不通过 → 新假设
+1. **WRITE**（对话中）单一假设："根因是 `{X}`，因为 `{Y}`"
+2. **EXEC** 最小变更验证假设 — 一次只变一个变量
+3. **MATCH** `verify_result`：
+   - 假设成立 → **GOTO** Phase 4
+   - 假设不成立 → 新假设 → **GOTO** Phase 3.1
+   - *default*（证据不足以判断）→ 补充诊断埋点 → **GOTO** Phase 1.4
 
 ### Phase 4：修复实现
 
-1. **先写失败测试** — 最小复现用例
-2. 修复根因（不是症状）
-3. **验证修复** — 运行项目测试命令确认修复通过且无回归。如果修复引入新的测试失败，立即回到步骤 2 定位新问题，不可忽略
-4. **更新文档** — 如果在编排模式下（任务目录存在），将修复循环（问题描述 + 根因 + 修复内容 + 回归测试结果）追加到 `06-tdd-log.md`，修复决策记录到 `08-ai-decisions.md`
-5. 如果 3 次修复失败 → STOP，质疑架构设计 → 触发 H3 人类介入，提交以下信息：
-   - 已尝试的 3 种修复方案
-   - 每种方案的失败原因
-   - 怀疑的架构问题（如：模块耦合、数据流错误、设计模式不匹配）
-   - 建议的下一步方向（如：重新设计模块、引入新依赖、重构接口）
+1. **WRITE** 失败测试到测试文件（最小复现用例）
+2. **EXEC** 修复根因（不是症状）
+3. **EXEC** 项目测试命令 — 确认修复通过且无回归
+   - 修复引入新的测试失败 → 立即回到步骤 2 定位新问题
+4. **IF** 编排模式（任务目录存在）→ **WRITE** 修复循环到 `06-tdd-log.md` + 决策到 `08-ai-decisions.md`
 
-### Phase 5：根因未能确定时的处理（回退门禁）
+**REPEAT** max=3（修复尝试，当前第 `attempt_count`/3 次）：
 
-如果经过 Phase 1-4 仍找不到根因（环境问题、时序依赖、外部因素），必须先通过以下门禁：
+- 修复成功 → **GOTO** 自检门禁
+- *repeat exhausted* → **BLOCKED**，触发 **H3**，提交以下信息：
+  - 已尝试的 3 种修复方案 + 每种的失败原因
+  - 怀疑的架构问题
+  - 建议的下一步方向
 
-**声明"找不到根因"的最低门槛**（全部满足才可声明）：
+### Phase 5：根因未能确定时的处理
 
-- [ ] 完整阅读了错误信息（含 stack trace 全文）
-- [ ] 稳定复现了问题（≥ 3 次）
+> Phase 1-4 完成后仍无根因时适用。门槛用于确认调查充分性，防止过早放弃。
+
+**GATE** "找不到根因"的最低门槛（全部满足才可声明）：
+
+- [ ] 完整 **READ** 了错误信息（含 stack trace 全文）
+- [ ] 稳定复现了问题（≥ 3 次独立复现，非 Phase 1 的首次复现）
 - [ ] 检查了 `git log` 最近 10 次提交的变更
 - [ ] 对比了 ≥ 1 个正常工作的相似实现
 - [ ] 添加了 ≥ 5 个诊断日志/断言
 
-> 95% 的"找不到根因"是调查不充分。门槛未全部满足时，回到 Phase 1。
+95% 的"找不到根因"是调查不充分。门槛未全部满足时，**GOTO** Phase 1。
 
-门槛通过后：
+**MATCH** `gate_result`：
 
-1. 记录已调查的内容和排除的假设
-2. 实施适当的防护措施（重试、超时、错误处理、日志记录）
-3. 添加监控/日志以便未来调查
-4. 状态标记为 `DONE_WITH_CONCERNS`，附带已排除的假设列表
+- 门槛通过 → **WRITE**（对话中）已调查内容和排除的假设 → 实施防护措施（重试、超时、错误处理）→ **DONE_WITH_CONCERNS**
+- 门槛未通过 → **GOTO** Phase 1
 
 ## 用户信号识别
 
-以下用户反馈表明调试方向偏离：
-
 | 用户说 | 意味着 | 你应该 |
 | ------ | ------ | ------ |
-| "那个不是发生了吗？" | 你假设了但没有验证 | 回到 Phase 1，用证据验证假设 |
+| "那个不是发生了吗？" | 你假设了但没有验证 | **GOTO** Phase 1，用证据验证假设 |
 | "它能给我们展示...吗？" | 你应该收集了证据但没有 | 添加诊断埋点或日志 |
-| "别猜了" | 你在没理解根因的情况下提修复方案 | 回到 Phase 1，先找根因 |
-| "想想根本原因" | 你在修症状不是根因 | 质疑你的假设，不是症状 |
+| "别猜了" | 你在没理解根因的情况下提修复方案 | **GOTO** Phase 1，先找根因 |
+| "想想根本原因" | 你在修症状不是根因 | 质疑你的假设，回到根因分析 |
 | "我们卡住了？"（沮丧） | 你的方法不对 | 暂停，重新评估策略 |
 
+## STOP Signals
+
+- **跳过**根因调查直接写修复代码
+- **同时**修改多个变量，无法隔离有效改动
+- **继续**尝试 3 次修复失败后仍不触发 **H3**
+- **绕过**调查流程（"先快速修一下，后面再查根因"）
+
 ## Constitutional Rules 遵守
 
 引用 `_team-rules/constitutional-rules.md`。调试阶段尤其注意：
 
 - **Rule #9 TDD 顺序不可逆**：修复 bug 必须先写失败的回归测试再写修复代码（FP-2）
-- **Rule #3 产出必须验证**：修复完成后必须执行 `_team-rules/verification-protocol.md` 的 5 个步骤，不可仅凭"修改了代码"就声明修复（FP-4）
-- **Rule #7 回退次数上限**：3 次修复失败必须触发 H3，不可无限重试（FP-1）
-- **Rule #2 有向图回退**：如果调试过程发现问题根源在 spec 歧义或遗漏，必须回退到 specAgent 而非自行假设正确行为（FP-4）
+- **Rule #3 产出必须验证**：修复完成后必须执行 `_team-rules/verification-protocol.md` 的 5 个步骤（FP-4）
+- **Rule #7 回退次数上限**：3 次修复失败必须触发 **H3**，不可无限重试（FP-1）
+- **Rule #2 有向图回退**：调试发现根源在 spec 歧义/遗漏 → **ROLLBACK** specAgent（FP-4）
 
 ## 自检门禁
 
-在报告完成状态前，执行以下自检：
-
-- [ ] 根因已明确描述（不是"可能是 X"而是"根因是 X"）
-- [ ] 修复前写了失败测试
-- [ ] 修复后验证通过（运行项目测试命令确认）
-- [ ] 如果 3 次修复失败 → 已触发 H3
-- [ ] 没有同时修改多个变量
+- [ ] 根因已明确描述（不是"可能是 X"而是"根因是 `{X}`"）
+- [ ] 修复前 **WRITE** 了失败测试
+- [ ] 修复后 **EXEC** 验证通过（项目测试命令确认）
+- [ ] **IF** 3 次修复失败 → 已触发 **H3**
+- [ ] **ASSERT** 没有同时修改多个变量
 
 ## 完成标志
 
-```
-状态：DONE | DONE_WITH_CONCERNS | NEEDS_CONTEXT | BLOCKED
-根因：{根因描述}
-修复：{修复内容}
-验证：{测试命令输出}
-```
-
-## STOP Signals
+**MATCH** `result`：
 
-- 没找到根因就开始写修复代码
-- 一次修改多个变量，无法隔离哪个改动有效
-- 3 次修复失败后仍然继续尝试，没有触发 H3
-- 用"先快速修一下，后面再查根因"来跳过调查流程
+- 根因确定 + 修复验证通过 → **DONE**
+- 根因未确定但已实施防护措施 → **DONE_WITH_CONCERNS**
+- 需要更多上下文信息 → **NEEDS_CONTEXT**
+- 3 次修复失败 → **BLOCKED**
 
 ## 集成关系
 
 **被谁调用：**
 
 - 用户直接调用（独立使用）
-- `team-test`（测试失败时路由）
+- `team-finish`（独立模式测试失败时推荐）
 
 **配对使用：**
 

package/skills/team-feedback/SKILL.md

@@ -54,55 +54,86 @@ NO IMPLEMENTATION WITHOUT TECHNICAL VERIFICATION FIRST
 | 技术验证记录 | 验证结果（对话中） |
 | 修改实施记录 | 代码 diff + 测试结果 |
 
+## 输入
+
+- **required**：代码审查反馈内容
+- **required**：项目测试/构建命令
+- **RESOLVE**：`verify_cmd`（从 `CLAUDE.md` / `.cursor/rules/` 或 `05-risk.md` 获取）
+
 ## 执行步骤
 
 ### Phase 1：理解反馈
 
-收到代码审查反馈后，按以下顺序处理：
+> 收到反馈后先理解、再验证、最后回应。禁止跳过验证直接实施。
 
-1. **完整阅读**：读完所有反馈，不立即反应
-2. **重述需求**：用自己的话重述审查者的要求（如果不确定，先提问澄清）
-3. **代码验证**：对照代码库验证每条建议的技术正确性（grep/Read 实际代码，不凭印象）
-4. **适用性评估**：这条建议在**当前**代码库中技术上是否正确？
-5. **技术性回应**：对每条反馈给出技术性确认或基于推理的推回（参考「推回指南」）
-6. 分析完成后进入 Phase 4 实施
+1. **READ** 所有反馈项 — 不立即反应
+2. **FOR** each `feedback_item`：
+   - 用自己的话重述审查者的要求
+   - **IF** 含义不确定 → 先提问澄清，暂不处理该项
+3. **FOR** each `feedback_item`：
+   - **EXEC** `grep` / **READ** 实际代码 — 验证该建议在当前代码库中的技术正确性
+   - **ASSERT** `验证基于代码证据`（不凭印象）
+4. **FOR** each `feedback_item`：
+   - **IF** 技术正确 → 记录确认，标记待实施
+   - **ELSE** → 用技术理由推回（参考「推回指南」）
+5. 分析完成 → **IF** 存在「增加功能/完善」建议 → Phase 2 YAGNI 检查；**IF** 存在外部反馈 → Phase 3 验证。最终 → **GOTO** Phase 4 实施
 
 ### Phase 2：YAGNI 检查
 
-当审查者建议"实现得更完善"或添加新功能时：
+> 当审查者建议"实现得更完善"或添加新功能时，用代码证据判断是否真正需要。
 
-1. grep 代码库查找该功能/接口的实际使用
-2. 如果是 exported/public API → 即使当前项目未直接调用也不应删除（可能有外部消费方）
-3. 如果是 internal 且无引用 → 建议删除，向审查者回应："该功能当前未被调用，建议删除（YAGNI）"
-4. 如果有引用 → 按建议实现
-5. 如果不确定 → 标注 {ambiguous} 并询问用户
+1. **EXEC** `grep` 在代码库中查找该功能/接口的实际使用
 
-### Phase 3：外部反馈处理
+2. **MATCH** `usage_result`：
+   - exported / public API 且有外部消费方可能 → 保留，即使当前项目未直接调用
+   - internal 且无引用 → 建议删除，向审查者回应："该功能当前未被调用，建议删除（YAGNI）"
+   - 有引用 → 按建议实现
+   - *not found* 且无法确定 → 标注 `{ambiguous}` → **NEEDS_CONTEXT**：询问用户
 
-实施外部反馈前，按 Phase 1 步骤 3-4 的方法逐条验证（grep 实际代码，不凭印象），并额外检查以下 2 个条件：
+### Phase 3：外部反馈处理
 
-1. **上下文完整性**：审查者是否了解完整上下文？（检查 08-ai-decisions.md 中的已有决策）
-2. **决策一致性**：建议与用户之前做出的设计决策冲突吗？
+> 外部反馈可能基于不完整上下文。验证技术正确性之外，还需检查上下文和决策一致性。
 
-根据检查结果路由：
+1. **FOR** each `external_feedback_item`：
+   - **EXEC** `grep` / **READ** 实际代码 — 验证技术正确性（同 Phase 1 步骤 3）
+   - **READ** `08-ai-decisions.md` — 检查与已有决策是否冲突
+   - **ASSERT** `验证基于代码证据`（不凭印象）
 
-- 建议技术上不正确 → 用技术理由推回（参考「推回指南」）
-- 无法验证 → 明确回应"我需要 {具体信息} 才能验证这条建议"
-- 与已有决策冲突 → 暂停，展示冲突点，等待用户决策
-- 反馈揭示 spec 遗漏 → 路由到 team-spec
-- 反馈揭示架构问题 → 触发 H3
+2. **MATCH** `check_result`：
+   - 技术正确 + 无冲突 → 标记待实施（**GOTO** Phase 4）
+   - 技术上不正确 → 用技术理由推回（参考「推回指南」）
+   - 无法验证 → **NEEDS_CONTEXT**：明确回应"我需要 `{具体信息}` 才能验证这条建议"
+   - 与已有决策冲突 → **H3**：暂停，展示冲突点，等待用户决策
+   - 反馈揭示 spec 遗漏 → **ROUTE** `team-spec`
+   - 反馈揭示架构问题 → **H3**
 
 ### Phase 4：实施
 
-多项反馈的实施顺序：
+> 逐项实施、逐项测试。不可批量实施后再测试（FP-2 实现偏见污染验证）。全部单项通过后再跑全量测试确认无交叉回归。
 
-1. 先澄清所有不明确项（Phase 1 步骤 2 已完成）
-2. 按优先级排序实施：阻塞问题 → 简单修复 → 复杂修复
-3. 每项修改单独测试（运行项目测试命令）。如果测试失败 → 立即定位原因并修复，不可跳过失败继续下一项
-4. 全部实施后运行全量测试，确认无回归。如果全量测试发现回归 → 定位是哪项修改引入的问题，回退该修改，重新实施
-5. **更新文档**：如果在编排模式下（任务目录存在），将每项修改的实施结果（反馈项 + 修改内容 + 测试结果）记录到 `08-ai-decisions.md`
+**RESOLVE** `verify_cmd`（首个命中即停）：
 
-> **验证协议**（步骤 3-4 声明"通过"前必须执行 `_team-rules/verification-protocol.md` 的 5 个步骤）
+1. `READ("05-risk.md", "§一验证计划")`
+2. `READ("CLAUDE.md").test_cmd` / `READ(".cursor/rules/")`
+3. `READ("package.json").scripts.test` / `READ("Makefile")` / `READ("Cargo.toml")`
+4. *none* → **NEEDS_CONTEXT**：请用户提供验证命令
+
+实施顺序：
+
+1. **ASSERT** `不明确项 == 0`（所有不明确项已在 Phase 1 步骤 2 中澄清）
+2. 按优先级排序：阻塞问题 → 简单修复 → 复杂修复
+3. **FOR** each `impl_item`（按排序顺序）：
+   - 实施修改
+   - **EXEC** `verify_cmd` — 单独测试该项修改
+   - **ASSERT** `exit_code == 0` && `failures == 0`
+     - **IF** `tests_fail` → 立即定位原因并修复 → **GOTO** Step 3 当前项重新测试
+4. **EXEC** `verify_cmd` — 全量测试，确认无回归
+   - **ASSERT** `exit_code == 0` && `failures == 0`
+   - **IF** `regression_detected` → 定位引入问题的修改 → **ROLLBACK** 该修改 → 重新实施 → **GOTO** Step 3 该项
+5. **IF** 任务目录存在（编排模式）：
+   - **WRITE** 每项修改的实施结果（反馈项 + 修改内容 + 测试结果）到 `08-ai-decisions.md`
+
+**验证协议**（步骤 3-4 声明"通过"前必须执行 `_team-rules/verification-protocol.md` 的 5 个步骤）
 
 ## 禁止回应
 
@@ -132,40 +163,38 @@ NO IMPLEMENTATION WITHOUT TECHNICAL VERIFICATION FIRST
 6. 建议修复了不存在的 bug
 7. 建议的方案比现有代码更复杂
 
+## STOP Signals
+
+- **实施**反馈建议前没有验证技术正确性
+- **回应**"你说得太对了""好主意"等表演性同意
+- **批量**实施多项反馈而不逐项测试
+- **忽略**外部反馈与代码库现实的冲突而不推回
+
 ## Constitutional Rules 遵守
 
 引用 `_team-rules/constitutional-rules.md`。反馈处理阶段尤其注意：
 
 - **Rule #9 TDD 顺序不可逆**：每项修改必须单独测试，不可批量实施后再测试（FP-2）
-- **Rule #2 有向图回退**：如果反馈揭示 spec 遗漏，必须回退到 specAgent 而非自行决定（FP-4）
-- **Rule #1 人类介入是一等公民**：如果反馈揭示架构问题，必须触发 H3（FP-1）
+- **Rule #2 有向图回退**：反馈揭示 spec 遗漏 → 回退 specAgent，不可自行决定（FP-4）
+- **Rule #1 人类介入是一等公民**：反馈揭示架构问题 → 触发 H3（FP-1）
 
 ## 自检门禁
 
-在报告完成状态前，执行以下自检：
-
-- [ ] 每项反馈都经过技术验证（不是表演性同意）
-- [ ] 不明确项已澄清后才实施
-- [ ] 每项修改单独测试过
-- [ ] 无回归（运行项目测试命令确认）
-- [ ] 如果反馈揭示 spec 遗漏 → 已路由到 team-spec
-- [ ] 如果反馈揭示架构问题 → 已触发 H3
+- [ ] **ASSERT** 每项反馈都经过技术验证（不是表演性同意）
+- [ ] **ASSERT** 不明确项已澄清后才实施
+- [ ] **ASSERT** 每项修改单独 **EXEC** `verify_cmd` 测试过
+- [ ] **ASSERT** 无回归（**EXEC** 全量测试确认）
+- [ ] **IF** 反馈揭示 spec 遗漏 → 已 **ROUTE** `team-spec`
+- [ ] **IF** 反馈揭示架构问题 → 已触发 **H3**
 
 ## 完成标志
 
-```
-状态：DONE | DONE_WITH_CONCERNS | NEEDS_CONTEXT | BLOCKED
-反馈项：{N} 项
-已实施：{N} 项
-已推回：{N} 项（含理由）
-```
-
-## STOP Signals
+**MATCH** `result`：
 
-- 没有验证技术正确性就开始实施反馈建议
-- 使用"你说得太对了""好主意"等表演性同意回应
-- 多项反馈批量实施而不逐项测试
-- 外部反馈与代码库现实冲突但不推回
+- 全部实施且测试通过 → **DONE**（`反馈项: {N}`, `已实施: {N}`, `已推回: {N}`）
+- 已实施但有保留意见 → **DONE_WITH_CONCERNS**（`concerns: [...]`）
+- 缺少关键信息无法验证 → **NEEDS_CONTEXT**（`missing: [...]`）
+- 被阻塞 → **BLOCKED** → **H3**
 
 ## 集成关系
 

package/skills/team-finish/SKILL.md

@@ -14,21 +14,11 @@ description: Use when implementation is complete, all tests pass, and you need t
 ```
 角色：分支完成处理——验证测试 → 展示选项 → 执行选择 → 清理
 核心原则：测试未通过不展示选项，用户未选择不执行操作
-流程：
-1. 验证所有测试通过
-2. 确定基准分支
-3. 展示 4 个结构化选项
-4. 执行用户选择
-5. 清理工作目录
-约束：
-- 测试未通过前禁止展示合并选项（FP-4）
-- 丢弃须用户输入 "discard" 确认
-- 禁止 force-push 除非用户明确要求
 ```
 
 ### 推理检查点
 
-**核心指令**：测试未通过 = 不展示合并选项（FP-4）。用户未选择 = 不执行操作（FP-1）。每步有明确前置条件。
+> 测试未通过 = 不展示合并选项（FP-4）。用户未选择 = 不执行操作（FP-1）。每步有明确前置条件。
 
 **推理框架**：
 
@@ -61,39 +51,39 @@ NO BRANCH COMPLETION WITHOUT TEST VERIFICATION FIRST
 
 ### Step 1：验证测试
 
-运行项目测试命令（声明"测试通过"前须执行 `_team-rules/verification-protocol.md` 的 5 个步骤）。如果测试失败：
+**EXEC** 项目测试命令（声明"通过"前须执行 `_team-rules/verification-protocol.md` 的 5 个步骤）
 
-```
-测试失败（{N} 个失败）。完成前须修复：
-[展示失败详情]
-测试通过前不可执行 merge/PR。
-```
+**ASSERT** `exit_code == 0` && `failures == 0`
 
-**失败处理**：停止，不进入 Step 2。根据失败类型采取行动：
+- 通过 → **GOTO** Step 2
+- 失败 → **MATCH** `mode`：
+  - 编排模式 → **ROLLBACK** 编排器，由编排器 **ROUTE** implAgent（附上失败输出）
+  - 独立使用 → **WRITE** 失败详情给用户，推荐 `team-debug`，修复后 **GOTO** Step 1
 
-- **编排模式**：回退编排器，由编排器路由回 implAgent 修复（附上失败输出）
-- **独立使用**：向用户展示失败详情，推荐使用 `team-debug` 定位根因，修复后重新执行 Step 1
-
-不可忽略失败继续展示选项（FP-4）。
+> 不可忽略失败继续展示选项（FP-4）。
 
 ### Step 2：确定基准分支
 
-按以下优先级确定基准分支：
+**RESOLVE** `base_branch`（首个命中即停）：
+
+1. `READ("docs/tasks/{slug}/.checkpoint.json").base_branch`
+2. `READ("CLAUDE.md").base_branch` / `READ(".cursor/rules/").default_branch`
+3. `EXEC("git symbolic-ref refs/remotes/origin/HEAD")` → 解析分支名
+4. **FOR** `name` in [`main`, `master`, `develop`] → `EXEC("git show-ref --verify refs/heads/{name}")` 首个存在即停
+5. *none* → **H3**：向用户展示 `git branch --list` 和 `git remote -v`，让用户指定
 
-1. **从 checkpoint 读取**：如果 `docs/tasks/{slug}/.checkpoint.json` 存在且包含 `base_branch` 字段，直接使用（orchestrator Step 1.5 已确定）
-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` 输出，让用户指定基准分支（不可自动猜测）
+**EXEC** `git merge-base HEAD {base_branch}` → 获取合并基点
 
-确定后运行 `git merge-base HEAD {base_branch}` 获取合并基点。
+- **ASSERT** `exit_code == 0`（分支无公共祖先 → **BLOCKED**，触发 **H3**）
 
 ### Step 3：展示选项
 
+**WRITE** 选项列表（对话中）：
+
 ```
 实现完成。请选择后续操作：
 
-1. 本地合并到 <base-branch>
+1. 本地合并到 {base_branch}
 2. 推送并创建 Pull Request
 3. 保留当前分支（稍后处理）
 4. 丢弃本次工作
@@ -103,39 +93,53 @@ NO BRANCH COMPLETION WITHOUT TEST VERIFICATION FIRST
 
 ### Step 4：执行选择
 
-#### Option 1：本地合并
-
-1. 切换到基准分支并拉取最新（`git checkout {base} && git pull`）
-2. 合并功能分支（`git merge {branch} --no-ff`）
-3. **合并冲突处理**：如果 `git merge` 报告冲突，向用户展示冲突文件列表并暂停——由用户选择 (A) 手动解决冲突后继续、(B) 中止合并改为创建 PR、(C) 中止合并保留分支。不自动解决冲突
-4. 运行项目测试命令验证合并后无回归
-5. 删除功能分支
+**MATCH** `user_choice`：
 
-> **验证协议**（步骤 4 声明"通过"前必须执行 `_team-rules/verification-protocol.md` 的 5 个步骤）
+- **Option 1**（本地合并）：
+  1. **EXEC** `git checkout {base_branch} && git pull`
+  2. **EXEC** `git merge {branch} --no-ff`
+     - 合并冲突 → **WRITE**（对话中）冲突文件列表，**MATCH** `user_choice`：
+       - (A) 手动解决冲突后继续
+       - (B) 中止合并，改为创建 PR
+       - (C) 中止合并，保留分支
+     - 不自动解决冲突
+  3. **EXEC** 项目测试命令 → **ASSERT** 合并后无回归
+  4. **EXEC** `git branch -d {branch}`
+     - **IF** `exit_code != 0` → **WRITE**（对话中）"分支未完全合并，需 -D 强制删除？"，等待用户确认
 
-#### Option 2：创建 PR
+  **验证协议**（步骤 3 声明"通过"前须执行 `_team-rules/verification-protocol.md` 的 5 个步骤）
 
-1. 推送功能分支到远程（`git push -u origin {branch}`）。如果推送失败（auth 错误、远程未配置），向用户展示错误信息并暂停
-2. 使用项目 PR 创建命令创建 Pull Request（优先从 CLAUDE.md / .cursor/rules/ 获取 PR 命令；如未配置则使用 `gh pr create`）
-3. 向用户展示 PR URL，确认创建成功
+- **Option 2**（创建 PR）：
+  1. **EXEC** `git push -u origin {branch}`
+     - 推送失败（auth 错误、远程未配置）→ **WRITE**（对话中）错误信息给用户，暂停
+  2. **RESOLVE** `pr_cmd`：`READ("CLAUDE.md").pr_cmd` / *default* `gh pr create`
+  3. **EXEC** `{pr_cmd}`
+     - **ASSERT** `exit_code == 0` → **WRITE** PR URL 给用户
+     - `exit_code != 0` → **WRITE**（对话中）错误信息，暂停
 
-#### Option 3：保留分支
+- **Option 3**（保留分支）：
+  **WRITE** `保留分支 {branch}。`
 
-报告：`保留分支 <name>。`
+- **Option 4**（丢弃）：
+  **ASSERT** 用户已输入 "discard" 确认
+  1. **EXEC** `git checkout {base_branch}`
+  2. **EXEC** `git branch -D {branch}`
 
-#### Option 4：丢弃
+- *default*（无效输入）→ **WRITE**（对话中）"请选择 1-4"，重新展示选项
 
-**需要确认**：用户必须输入 "discard" 确认。
+### Step 5：清理工作目录
 
-1. 切换到基准分支
-2. 强制删除功能分支
+**IF** `user_choice` in [Option 1, Option 2, Option 4]：
 
-### Step 5：清理工作目录
+1. **EXEC** `git worktree list` → 检查关联工作目录
+2. **IF** `worktree` 存在 → 移除工作目录
 
-对于 Option 1、2、4：
+## STOP Signals
 
-1. 检查是否有关联的工作目录（如 `git worktree list`）
-2. 如果存在，移除工作目录
+- **展示**选项在测试未通过时
+- **声明**完成在合并后未重新测试时
+- **丢弃**分支前未要求用户输入 "discard"
+- **执行** force-push 前未获用户明确授权
 
 ## Constitutional Rules 遵守
 
@@ -147,30 +151,21 @@ NO BRANCH COMPLETION WITHOUT TEST VERIFICATION FIRST
 
 ## 自检门禁
 
-在报告完成状态前，执行以下自检：
-
-- [ ] 测试已验证通过（运行项目测试命令确认）
-- [ ] 基准分支已确定
+- [ ] **EXEC** 测试已验证通过（运行项目测试命令确认）
+- [ ] `base_branch` 已 **RESOLVE**
 - [ ] 用户已选择选项（不是自行决定）
-- [ ] 如果选择 discard → 用户已输入 "discard" 确认
+- [ ] **IF** 选择 discard → **ASSERT** 用户已输入 "discard" 确认
 - [ ] 工作目录已清理（如适用）
-- [ ] 如果选择 merge → 合并后测试已通过
+- [ ] **IF** 选择 merge → 合并后测试已通过
 
 ## 完成标志
 
-```
-状态：DONE | DONE_WITH_CONCERNS | NEEDS_CONTEXT | BLOCKED
-选择：{merge / PR / keep / discard}
-测试：{N} 通过，0 失败
-分支：{branch-name} → {base-branch}
-```
-
-## STOP Signals
+**MATCH** `result`：
 
-- 测试未通过就展示合并/PR 选项
-- 合并后没有重新运行测试就声明完成
-- 丢弃分支前没有要求用户输入 "discard" 确认
-- 执行 force-push 但用户没有明确要求
+- 操作成功执行 → **DONE**
+- 操作成功但有 warning → **DONE_WITH_CONCERNS**
+- 无法确定基准分支 → **NEEDS_CONTEXT**
+- 测试失败或合并冲突 → **BLOCKED**
 
 ## 集成关系