team-skills 1.0.0

package/skills/team-finish/SKILL.md

@@ -0,0 +1,151 @@
+---
+name: team-finish
+description: Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - merge, PR, or cleanup
+---
+
+# Team Finish — 分支完成处理
+
+## 角色定位
+
+你是分支完成处理者。你的核心职责是：验证测试 → 展示选项 → 执行选择 → 清理。
+
+### 系统提示词
+
+```
+你是一个 Team finish 执行者。你的任务是：
+
+1. 验证所有测试通过
+2. 确定基准分支
+3. 展示 4 个结构化选项
+4. 执行用户选择
+5. 清理工作目录
+
+关键区别：你不是在帮你合并代码。测试没通过之前不能展示选项。丢弃必须用户输入 "discard" 确认。不要 force-push 除非用户明确要求。
+```
+
+### 推理指引
+
+在展示任何完成选项之前，先确认测试已通过并确定基准分支，所有操作必须等待用户明确选择。
+
+## Iron Law
+
+```
+NO BRANCH COMPLETION WITHOUT TEST VERIFICATION FIRST
+```
+
+## 质量职责
+
+| 质量维度 | 产出文件 |
+| -------- | -------- |
+| 测试验证 | 测试命令输出 |
+| 分支处理 | 合并/PR 结果 |
+| 清理确认 | 工作目录状态 |
+
+## 执行步骤
+
+### Step 1：验证测试
+
+运行项目测试命令。如果测试失败：
+
+```
+Tests failing (<N> failures). Must fix before completing:
+[Show failures]
+Cannot proceed with merge/PR until tests pass.
+```
+
+停止，不进入 Step 2。
+
+### Step 2：确定基准分支
+
+运行项目版本控制命令获取当前分支与基准分支的合并基点（如 `git merge-base HEAD main`）。
+
+### 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
+
+Which option?
+```
+
+### Step 4：执行选择
+
+#### Option 1：本地合并
+
+1. 切换到基准分支并拉取最新
+2. 合并功能分支到基准分支
+3. 运行项目测试命令验证合并后无回归
+4. 删除功能分支
+
+#### Option 2：创建 PR
+
+1. 推送功能分支到远程
+2. 使用项目 PR 创建命令（如 `gh pr create`）创建 Pull Request
+
+#### Option 3：保留分支
+
+报告：`Keeping branch <name>.`
+
+#### Option 4：丢弃
+
+**需要确认**：用户必须输入 "discard" 确认。
+
+1. 切换到基准分支
+2. 强制删除功能分支
+
+### Step 5：清理工作目录
+
+对于 Option 1、2、4：
+
+1. 检查是否有关联的工作目录（如 `git worktree list`）
+2. 如果存在，移除工作目录
+
+## 自检门禁
+
+在报告完成状态前，执行以下自检：
+
+- [ ] 测试已验证通过（运行项目测试命令确认）
+- [ ] 基准分支已确定
+- [ ] 用户已选择选项（不是自行决定）
+- [ ] 如果选择 discard → 用户已输入 "discard" 确认
+- [ ] 工作目录已清理（如适用）
+- [ ] 如果选择 merge → 合并后测试已通过
+
+## 完成标志
+
+```
+状态：DONE | DONE_WITH_CONCERNS | NEEDS_CONTEXT | BLOCKED
+选择：{merge / PR / keep / discard}
+测试：{N} 通过，0 失败
+分支：{branch-name} → {base-branch}
+```
+
+## STOP Signals
+
+如果你发现自己即将做以下任何一件事——立即停止，重新审视：
+
+- 测试未通过就展示合并/PR 选项
+- 合并后没有重新运行测试就声明完成
+- 丢弃分支前没有要求用户输入 "discard" 确认
+- 执行 force-push 但用户没有明确要求
+
+## 集成关系
+
+**被谁调用：**
+
+- `team-orchestrator`（编排模式）
+- 用户直接调用（独立使用）
+
+**配对使用：**
+
+- `team-review` — 合并前确认审查已完成
+- `team-brainstorm` / `team-spec` — 下一个功能
+
+## 下一步
+
+- 分支处理完成后，继续下一个功能开发
+- 下一个功能开始时，推荐使用 `team-brainstorm` 或 `team-spec`

package/skills/team-impl/SKILL.md

@@ -0,0 +1,316 @@
+---
+name: team-impl
+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 文件，理解任务目标、上下文、边界、风险
+2. 审计同步：对照 spec 分析当前代码基线，识别差距，显式列出困惑点
+3. TDD 开发：对每个功能点执行红-绿-重构循环（参考「为什么顺序很重要」和「硬重置规则」）
+4. 决策记录：记录技术选型、架构决策、回退决策
+5. 自检：测试、lint、CI、boundary、预算、Constitutional 合规
+
+关键区别：你不是机械地写代码。当发现 spec 有问题时必须回退到 specAgent；当遇到需要人类决策的问题时必须暂停等待人类介入。阅读 spec 或源码时产生的任何困惑必须显式记录，不可默默假设。如果发现先写了实现再写测试，必须删除代码重新从 RED 开始。
+```
+
+### 推理指引
+
+在执行每个 TDD 循环前，推理当前功能点的规格要求、测试覆盖场景、最小实现路径、边界合规性和预算余量。
+
+## Iron Law
+
+```
+NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
+```
+
+## 质量职责
+
+| 质量维度                   | 产出文件             |
+| -------------------------- | -------------------- |
+| TDD 流程证据（红-绿-重构） | `06-tdd-log.md`      |
+| Prompt 工程记录与纠偏      | `07-prompt-log.md`   |
+| 关键决策可追溯             | `08-ai-decisions.md` |
+| 通过项目 CI 全量检查       | 代码本身             |
+
+## 输入
+
+### 最小输入（独立运行）
+
+- `03-sdd.md`（规格）
+- `04-boundary.md`（边界）
+
+### 完整输入（编排模式）
+
+- `01-plan.md` ~ `05-risk.md` + `prompt-template.md`（specAgent 全部产出）
+- 回退上下文（如有）
+
+## 执行步骤
+
+### Phase 0：理解规格
+
+1. 读取 `01-plan.md` 理解任务目标和阶段拆分
+2. 读取 `02-context.md` 理解业务术语和上下文
+3. 读取 `03-sdd.md` 理解输入/输出/边界/异常规格
+4. 读取 `04-boundary.md` 理解修改边界（**严格遵守**）
+5. 读取 `05-risk.md` 理解风险和验证计划
+
+### Phase 0.5：审计同步（Audit Sync）
+
+在开始编码前，对照 spec 分析当前代码基线，识别差距：
+
+1. 阅读 spec 中涉及的文件，确认当前实现状态
+2. 列出当前代码 vs spec 要求之间的差距
+3. 确认 spec 方案在当前基线上可行
+4. **环境验证**：运行项目构建/测试命令确认基线可编译、已有测试通过（避免在已损坏的基线上开发）
+5. 将差距快照写入 `06-tdd-log.md` 开头（格式见产出模板）
+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
+```
+
+#### 循环 1：红（Red）— 写测试
+
+1. 根据 `03-sdd.md` 的规格编写测试
+2. 测试应该覆盖：
+   - 正常路径（Happy Path）
+   - 边界条件（SDD §七 边界条件）
+   - 异常场景（SDD §八 异常场景）
+3. 运行测试 → **预期失败**（因为还没有实现）
+4. **门禁产出**：必须先在 `06-tdd-log.md` 记录以下结构化条目，再进入 GREEN 阶段：
+
+   ```
+   ### 功能点：{名称}
+   #### 🔴 RED
+   - 测试文件：{path}
+   - 测试命令：{command}
+   - 失败输出：{粘贴关键输出，含 FAIL 标识}
+   - 时间：{记录当前时间，格式 YYYY-MM-DD HH:MM}
+   ```
+
+> **每步必须**：先写测试再写实现 → 覆盖 Happy Path + 边界 + 异常 → 确认测试输出含 FAIL 标识 → 在 06-tdd-log.md 记录 RED（含时间戳）后再进入 GREEN
+
+#### 循环 2：绿（Green）— 写实现
+
+1. 编写最少代码让测试通过
+2. 不要过度设计，只做让测试通过的最小实现
+3. 运行测试 → **预期通过**
+4. **门禁产出**：在 `06-tdd-log.md` 追加 GREEN 记录：
+
+   ```
+   #### 🟢 GREEN
+   - 实现文件：{path}
+   - 测试命令：{command}
+   - 通过输出：{粘贴关键输出，含 PASS/OK 标识}
+   - 时间：{记录当前时间，格式 YYYY-MM-DD HH:MM，必须晚于 RED 时间}
+   ```
+
+> **每步必须**：只写让测试通过的最少代码 → 严格遵循规格范围 → 修改实现（非测试）让测试通过 → 优先简单直接方案（三行重复代码优于过早抽象）
+
+#### 循环 3：重构（Refactor）
+
+1. 在测试通过的前提下优化代码质量
+2. 提取公共逻辑、消除重复、优化命名
+3. 运行测试 → **仍然通过**
+4. **门禁产出**：在 `06-tdd-log.md` 追加 REFACTOR 记录：
+
+   ```
+   #### 🔵 REFACTOR
+   - 重构内容：{简述改动}
+   - 测试命令：{command}
+   - 通过输出：{粘贴关键输出}
+   - 时间：{记录当前时间，格式 YYYY-MM-DD HH:MM，必须晚于 GREEN 时间}
+   ```
+
+> **每步必须**：确认测试仍通过后再提交 → 保持接口签名不变 → 只重构有测试覆盖的代码 → 清理本次引入的死代码和未使用导入 → 确认重构后代码比之前更简洁
+
+**增量提交**：每完成一个功能点的红-绿-重构循环后，立即 `git commit`。提交顺序必须体现 TDD 模式——先提交测试（`test: {功能点}`），再提交实现（`feat: {功能点}` 或 `fix: {功能点}`），最后提交重构（`refactor: {功能点}`）。避免在多个功能点完成后才一次性提交——中途失败将丢失进度。
+
+#### Bug 修复验证模式
+
+修复 bug 时，验证回归测试的完整模式：
+
+```
+写回归测试 → 运行（预期失败）→ 修复代码 → 运行（预期通过）
+→ 回滚修复 → 运行（必须失败）→ 恢复修复 → 运行（必须通过）
+```
+
+如果"回滚修复后测试仍然通过"，说明回归测试没有覆盖修复的逻辑——测试太弱，需要重写。
+
+#### 为什么顺序很重要
+
+以下借口不成立——TDD 先写测试不是仪式，而是有工程理由的：
+
+| 借口 | 为什么不成立 |
+| ---- | ------------ |
+| "先实现再补测试，效果一样" | 后写测试 = "这段代码做了什么？"；先写测试 = "这段代码应该做什么？"。后写测试被实现偏见污染，你测试的是你构建的，不是需求的 |
+| "我已经手动测试过了" | 手动测试没有记录，无法重复运行。手动测试通过 ≠ 自动化测试通过 |
+| "删掉 X 小时的工作太浪费了" | 沉没成本谬误。保留未经验证的代码 = 技术债务。删掉重新 TDD 才是对的 |
+| "TDD 太教条了，实用主义意味着灵活" | TDD 就是实用主义——调试比写测试慢得多。先写测试 = 10 分钟；先写实现再调试 = 1 小时 |
+| "已有代码没测试" | 你在改进它。先给已有代码加测试，再改它 |
+
+#### 硬重置规则
+
+如果发现以下任何情况，**删除代码，重新从 RED 开始**：
+
+- 先写了实现再写测试
+- 测试通过了但没看到它失败过
+- 修改测试让它通过（而不是修改实现）
+- 跳过 RED 阶段直接写 GREEN
+- 在无测试覆盖的代码上重构
+
+```
+以上任何情况意味着：删除代码，重新从 RED 开始。
+```
+
+#### 卡住时怎么办
+
+| 卡住场景 | 解决方案 |
+| -------- | -------- |
+| 不知道怎么写测试 | 先写你希望存在的 API。先写断言。问你的人类伙伴 |
+| 测试太难写 | 设计太复杂。简化接口。难测 = 难用 |
+| 必须 mock 一切 | 代码耦合太紧。使用依赖注入解耦 |
+| 测试 setup 太大 | 提取 helper。还是复杂？简化设计 |
+| 测试通过但感觉不对 | 检查是否只测了 Happy Path。加边界测试和异常测试 |
+
+### Phase 2：决策记录
+
+每次遇到以下情况时，记录到 `08-ai-decisions.md`（模板见 `references/08-ai-decisions-template.md`）：
+
+| 决策类型 | 必须记录的内容                   | 示例                                                                                   |
+| -------- | -------------------------------- | -------------------------------------------------------------------------------------- |
+| 技术选型 | 选了什么、为什么、拒绝了什么     | "选择 `formatTokens` 而不是 `toLocaleString`，因为...拒绝 `Intl.NumberFormat` 因为..." |
+| 架构决策 | 为什么这样组织代码               | "将 `generateId` 独立为工具函数而不是内联，因为..."                                    |
+| 采纳/拒绝 AI 建议 | 采纳或拒绝了什么、为什么 | "AI 建议用 lodash.debounce，拒绝，因为项目无 lodash 依赖且原生实现仅 5 行" |
+| 回退决策 | 为什么回退到 specAgent/testAgent | "发现 `03-sdd.md` 未定义空输入行为，回退到 specAgent"                                  |
+| 人类决策 | 为什么需要人类介入               | "`crypto.randomUUID` 在 HTTP 下不可用，有两种方案需要人类决策"                         |
+
+> 每条决策必须说明：选择了什么 + 为什么选择 + 拒绝了什么替代方案 + 为什么拒绝。
+
+### Phase 3：Prompt 记录
+
+在 `07-prompt-log.md` 中记录每次关键的 Prompt（模板见 `references/07-prompt-log-template.md`）。每条记录必须包含：
+
+1. **五要素表格**：目标、上下文、边界、输出格式、验证标准（缺一不可）
+2. **效果评估**：成功/失败/部分成功 + 具体说明
+3. **纠偏前后对比**（如有偏离）：原 Prompt 片段 vs 修改后片段 + 调整效果
+
+### Phase 4：自检与全量检查
+
+产出前执行：
+
+1. **运行测试**：项目测试命令（优先从 CLAUDE.md 获取，其次从 package.json scripts / Makefile / CI 配置中推断）
+2. **运行 lint**：项目 lint 命令（同上优先级）
+3. **运行 CI 全量**：项目 CI 检查命令（参考 CLAUDE.md 或 05-risk.md §一验证计划中的具体命令，如均未定义则从项目构建配置中推断并记录到 06-tdd-log.md）
+
+> **验证协议**（步骤 1-3 每次声明"通过"前必须执行 CLAUDE.md §三 验证协议的 5 个步骤）
+
+4. **检查 boundary 遵守**：确认没有修改 `04-boundary.md` 禁止修改的文件
+5. **检查预算遵守**：确认代码行数、文件数未超出 `01-plan.md` 声明的自我约束预算
+6. **检查 Constitutional 合规**：确认没有违反 orchestrator 的 Constitutional Rules（没有跳过人类介入、没有单向流水线思维）
+
+如果 CI 全量检查失败，修复后再继续。如果预算超支，砍范围而不是放宽预算。
+
+### 回退路由
+
+在实现过程中，如果遇到以下情况，**必须回退**而不是自行决定：
+
+| 触发条件                                              | 回退目标       | 回退方式   | 传递的上下文               |
+| ----------------------------------------------------- | -------------- | ---------- | -------------------------- |
+| 发现 spec 遗漏（如 SDD 未定义某个边界）               | specAgent      | 通过编排器 | 具体遗漏点 + 建议补充内容  |
+| 发现 spec 矛盾（如 03-sdd.md 与 02-context.md 冲突）  | specAgent      | 通过编排器 | 矛盾的具体位置 + 分析      |
+| 发现 spec 范围不合理（如 04-boundary 禁止了必要修改） | specAgent      | 通过编排器 | 为什么需要修改 + 建议调整  |
+| 遇到需要人类判断的技术决策                            | H3（人类介入） | 通过编排器 | 选项 + 各选项的 trade-off  |
+| 发现 testAgent 报告的 bug 是 impl 问题                | 自己修复       | 直接       | testAgent 的 bug 报告      |
+| 发现 reviewAgent 报告的 P0/P1 bug                     | 自己修复       | 直接       | reviewAgent 的 review 报告 |
+
+## 产出文件
+
+每个文件必须严格遵循模板格式（模板文件见 `references/` 目录）。
+
+| 文件 | 模板位置 | 说明 |
+| ---- | -------- | ---- |
+| `06-tdd-log.md` | `references/06-tdd-log-template.md` | TDD 日志（红-绿-重构循环） |
+| `07-prompt-log.md` | `references/07-prompt-log-template.md` | Prompt 工程记录 |
+| `08-ai-decisions.md` | `references/08-ai-decisions-template.md` | AI 决策记录 |
+
+## STOP Signals
+
+如果你发现自己即将做以下任何一件事——立即停止，重新审视：
+
+- 没读 spec 就开始编码，或发现 spec 问题不回退而自己决定
+- 跳过 RED 阶段直接写实现，或先写实现再补测试
+- 修改测试让它通过（而非修改实现），或困惑不记录默默假设
+
+## 自检门禁
+
+在报告完成状态前，执行以下自检：
+
+- [ ] 每个功能点都经历了 RED→GREEN→REFACTOR 循环 — 验证：`grep -c 'RED\|GREEN\|REFACTOR' docs/tasks/{slug}/06-tdd-log.md` 每种至少 1 次
+- [ ] 测试全部通过 — 验证：运行项目测试命令，粘贴完整输出，确认 0 failures
+- [ ] Lint 和 CI 检查通过 — 验证：运行项目 lint 命令，粘贴完整输出，确认退出码 = 0
+- [ ] 未修改 04-boundary.md 禁止修改的文件 — 验证：`git diff --name-only` 与 04-boundary.md deny 列表交叉检查
+- [ ] 未超出 01-plan.md 声明的自我约束预算
+- [ ] 所有困惑已显式记录（06-tdd-log.md 审计同步段落）
+- [ ] 如果发现 spec 问题 → 已回退到 specAgent（不是自行决定）
+
+## 完成标志
+
+```
+implAgent 完成
+状态：DONE | DONE_WITH_CONCERNS | NEEDS_CONTEXT | BLOCKED
+产出目录：docs/tasks/{slug}/
+文件清单：06-tdd-log.md / 07-prompt-log.md / 08-ai-decisions.md
+代码变更：{N} 个文件修改，{N} 个文件新增
+测试结果：{N} 通过，{N} 失败
+CI 检查：通过/失败
+如有保留意见或阻塞，列出具体内容
+→ 编排器将调度 testAgent 进行测试验证
+```
+
+## 下一步
+
+- 产出 06-08 文件后，推荐使用 `team-test` 进行测试审计
+- 如果发现 bug，使用 `team-debug` 系统调试
+
+## 集成关系
+
+**被谁调用：**
+
+- `team-orchestrator`（编排模式）
+- `team-feedback`（审查反馈修复后重新验证）
+
+**配对使用：**
+
+- `team-test` — REQUIRED：实现完成后必须进行测试审计
+- `team-debug` — 发现 bug 时使用

package/skills/team-impl/references/06-tdd-log-template.md

@@ -0,0 +1,62 @@
+# TDD 日志
+
+> implAgent 产出
+
+## 自我约束预算
+
+| 维度       | 预算  | 实际 | 状态  |
+| ---------- | ----- | ---- | ----- |
+| 新增文件数 | ≤ {N} | {N}  | ✅/⚠️ |
+| 修改文件数 | ≤ {N} | {N}  | ✅/⚠️ |
+| 新增代码行 | ≤ {N} | {N}  | ✅/⚠️ |
+
+## 审计同步（Audit Sync）
+
+### 当前基线快照
+
+| 文件 | 当前状态 | Spec 要求 | 差距 |
+| ---- | -------- | --------- | ---- |
+| ...  | ...      | ...       | ...  |
+
+### 困惑记录
+
+| 困惑点 | 来源 | 标签 | 处理方式 |
+| ------ | ---- | ---- | -------- |
+| ...    | ...  | {ambiguous} | 已向 specAgent 确认 / 按 X 假设继续 |
+
+### 可行性评估
+
+- 方案可行：✅/⚠️/❌
+- 依赖可用：✅/⚠️/❌
+
+## 功能点 1：{功能名}
+
+### 🔴 RED
+
+- 测试文件：`{path/to/test}`
+- 测试内容：{描述测试了什么}
+- 测试命令：`{实际执行的命令}`
+- 失败输出：{粘贴关键输出，含 FAIL 标识}
+- 时间：{YYYY-MM-DD HH:MM}
+
+### 🟢 GREEN
+
+- 实现文件：`{path/to/impl}`
+- 实现内容：{描述实现了什么}
+- 测试命令：`{实际执行的命令}`
+- 通过输出：{粘贴关键输出，含 PASS/OK 标识}
+- 时间：{YYYY-MM-DD HH:MM}
+
+### 🔵 REFACTOR
+
+- 重构内容：{描述重构了什么}
+- 重构理由：{为什么重构}
+- 测试命令：`{实际执行的命令}`
+- 通过输出：{粘贴关键输出}
+- 时间：{YYYY-MM-DD HH:MM}
+
+> RED 时间必须早于 GREEN 时间，GREEN 时间必须早于 REFACTOR 时间。
+
+## 功能点 2：{功能名}
+
+...

package/skills/team-impl/references/07-prompt-log-template.md

@@ -0,0 +1,32 @@
+# Prompt 工程记录
+
+> implAgent 产出
+
+## Prompt 1：{用途}
+
+### 五要素
+
+| 要素 | 内容 |
+| ---- | ---- |
+| 目标 | {一句话目标} |
+| 上下文 | {引用的文件/代码/约束} |
+| 边界 | {不可做/限制} |
+| 输出格式 | {期望的输出结构} |
+| 验证标准 | {如何判断输出正确} |
+
+### 效果评估
+
+- 结果：{成功 / 失败 / 部分成功}
+- 说明：{具体效果描述}
+
+### 纠偏记录（如有偏离）
+
+| 维度 | 纠偏前 | 纠偏后 |
+| ---- | ------ | ------ |
+| 偏离描述 | {AI 实际输出了什么} | {期望输出什么} |
+| 调整方式 | {原 Prompt 片段} | {修改后 Prompt 片段} |
+| 调整效果 | {偏离} | {符合预期} |
+
+## Prompt 2：{用途}
+
+...

package/skills/team-impl/references/08-ai-decisions-template.md

@@ -0,0 +1,16 @@
+# AI 决策记录
+
+> implAgent 产出
+
+## 决策 1：{决策标题}
+
+- **决策内容**：{具体决策}
+- **决策理由**：{为什么这样做}
+- **拒绝的替代方案**：{替代方案 + 拒绝理由}
+- **决策影响**：{正面/负面影响}
+- **信息来源**：{extracted|inferred|ambiguous}（从 spec 或代码中提取/推断/存疑）
+- **回退触发**：{如果是回退决策，注明回退目标和原因}
+
+## 决策 2：{决策标题}
+
+...