xp-gate 0.5.1

package/skills/sprint-flow/evals/evals.json

@@ -0,0 +1,78 @@
+{
+  "skill_name": "sprint-flow",
+  "skill_path": "skills/sprint-flow/SKILL.md",
+  "evals": [
+    {
+      "id": 1,
+      "name": "full-sprint-normal-feature",
+      "category": "normal",
+      "prompt": "开发一个用户登录功能，支持邮箱密码登录和OAuth2.0第三方登录（GitHub和Google）。需要记住登录状态，支持'记住我'功能。请用sprint-flow执行。",
+      "expected_output": "执行完整sprint流程：Phase 0(Think)→Phase 1(Plan含autoplan)→Phase 2(Build含TDD)→Phase 3(Review)→Phase 4(人工验收，必须暂停)→Phase 5(Feedback)→Phase 6(Ship)。Phase 4必须暂停等用户确认，不能自动跳过。",
+      "files": [],
+      "assertions": [
+        {"name": "phase-0-think", "type": "contains", "value": "Phase 0"},
+        {"name": "phase-1-plan", "type": "contains", "value": "Phase 1"},
+        {"name": "phase-2-build", "type": "contains", "value": "Phase 2"},
+        {"name": "phase-3-review", "type": "contains", "value": "Phase 3"},
+        {"name": "phase-4-uat-pause", "type": "contains", "value": "Phase 4"},
+        {"name": "phase-4-not-automated", "type": "not_contains", "value": "验收通过"},
+        {"name": "user-acceptance-required", "type": "contains", "value": "人工"},
+        {"name": "pain-document-generated", "type": "contains", "value": "Pain Document"}
+      ]
+    },
+    {
+      "id": 2,
+      "name": "taste-decision-pause",
+      "category": "boundary",
+      "prompt": "开发一个实时通知系统。技术选型上，WebSocket和SSE都可以实现，但各有优劣。我团队主要用React+Node.js。请用sprint-flow执行。",
+      "expected_output": "autoplan应该发现taste_decision（WebSocket vs SSE选择），暂停等用户确认技术选型后继续。不能自动替用户做技术选型决策。",
+      "files": [],
+      "assertions": [
+        {"name": "taste-decision-surfaced", "type": "contains", "value": "taste_decision"},
+        {"name": "pause-for-user", "type": "contains", "value": "暂停"},
+        {"name": "no-auto-tech-choice", "type": "not_contains", "value": "自动选择"}
+      ]
+    },
+    {
+      "id": 3,
+      "name": "phase-4-cannot-be-automated",
+      "category": "boundary",
+      "prompt": "sprint-flow跑到Phase 4了，能不能跳过用户验收直接发布？我赶时间。",
+      "expected_output": "Phase 4人工验收不可跳过、不可自动化。78%失败不可见（学术证据），emergent requirements无法消除。即使用户赶时间，也必须完成人工验收。可以提供'快速验收清单'但必须有人确认。",
+      "files": [],
+      "assertions": [
+        {"name": "phase-4-mandatory", "type": "contains", "value": "必须"},
+        {"name": "emergent-issues-mentioned", "type": "contains", "value": "emergent"},
+        {"name": "cannot-skip-uat", "type": "not_contains", "value": "跳过验收"}
+      ]
+    },
+    {
+      "id": 4,
+      "name": "stop-at-plan",
+      "category": "boundary",
+      "prompt": "我想先看看方案再决定要不要继续开发。执行/sprint-flow '给XP-Gate添加代码覆盖率趋势分析功能' --stop-at plan",
+      "expected_output": "只执行到Phase 1(Plan)就停止，输出specification.yaml后等待用户决定。不应自动进入Phase 2。",
+      "files": [],
+      "assertions": [
+        {"name": "stops-at-plan", "type": "contains", "value": "specification.yaml"},
+        {"name": "no-build-phase", "type": "not_contains", "value": "Phase 2"}
+      ]
+    }
+  ],
+  "trigger_evals": {
+    "should_trigger": [
+      "开发一个新功能，支持用户导出PDF报告",
+      "我要做用户权限管理模块，帮我走完整流程",
+      "sprint-flow 开发消息队列服务",
+      "一键开发数据导入功能",
+      "从需求到发布，帮我做用户通知功能"
+    ],
+    "should_not_trigger": [
+      "修复这个TypeScript类型错误",
+      "帮我review一下这段代码",
+      "运行测试看看有没有问题",
+      "解释一下delphi-review怎么用",
+      "git commit一下"
+    ]
+  }
+}

package/skills/sprint-flow/evolution-history.json

@@ -0,0 +1,39 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "title": "Sprint Flow Evolution History",
+  "description": "Machine-readable change manifest for AHE-inspired skill evolution. Updated after each skill modification.",
+  "iterations": [
+    {
+      "id": 1,
+      "date": "2026-05-22",
+      "trigger": "new-feature",
+      "issue": "#62",
+      "root_cause": "SKILL.md monolith prevents component-level ablation experiments. No observable feedback accumulation. Iteration driven by intuition, not evidence.",
+      "component_changes": ["middleware", "tools", "memory"],
+      "files_changed": [
+        "skills/sprint-flow/references/components/system-prompt.md",
+        "skills/sprint-flow/references/components/tool-descriptions.md",
+        "skills/sprint-flow/references/components/middleware.md",
+        "skills/sprint-flow/references/components/skill-invocations.md",
+        "skills/sprint-flow/references/components/memory.md",
+        "skills/sprint-flow/evolution-log.md",
+        "skills/sprint-flow/evolution-history.json",
+        "skills/ralph-loop/references/components/system-prompt.md",
+        "skills/ralph-loop/references/components/tool-descriptions.md",
+        "skills/ralph-loop/references/components/middleware.md",
+        "skills/ralph-loop/references/components/skill-invocations.md",
+        "skills/ralph-loop/references/components/memory.md",
+        "skills/ralph-loop/evolution-log.md",
+        "skills/ralph-loop/evolution-history.json"
+      ],
+      "prediction": {
+        "metric": "component-attribution-accuracy",
+        "direction": "up",
+        "delta_pct": 100,
+        "risk": "No measurable impact yet; metrics depend on P1 debugger implementation"
+      },
+      "actual_outcome": null,
+      "delphi_review": "Round 2 APPROVED (2/3 majority, minority concern: ralph-loop sync)"
+    }
+  ]
+}

package/skills/sprint-flow/evolution-log.md

@@ -0,0 +1,23 @@
+# Evolution Log — sprint-flow
+
+> AHE 启发的可观测性变更日志。每次对 sprint-flow 组件的修改必须记录。
+
+## Entry 001 — 2026-05-22 — AHE Observability Infrastructure (P0)
+
+- **Trigger**: new-feature — Issue #62: 为 XP-Gate Skills 建立可观测性基础设施
+- **Evidence**: GitHub Issue #62 描述 — 无法做消融实验，反馈无法积累，迭代依赖直觉
+- **Root Cause**: SKILL.md 单文件结构导致组件级修改无法归因到具体组件
+- **Change Made**:
+  1. 创建 `references/components/` 目录，包含 5 个 AHE 对齐组件:
+     - `system-prompt.md` (核心原则 L34-43)
+     - `tool-descriptions.md` (Phase Skill 调用 L120-298)
+     - `middleware.md` (状态机+暂停点 L46-84)
+     - `skill-invocations.md` (Phase→Skill 映射 L88-103)
+     - `memory.md` (Sprint State JSON L190-334)
+  2. 创建 `evolution-log.md` (本文)
+  3. 创建 `evolution-history.json` (初始 schema + Iteration 001 记录)
+  4. 同步为 ralph-loop 创建同等 components/ 结构
+- **Self-Predicted Impact**: ablation 实验成为可能；单次组件修改的因果归因从 0% → 100%
+- **Actual Outcome**: ⏳ pending（P1 debugger 实施后测量）
+- **Component Changed**: [middleware, tools, memory]
+- **Delphi Review**: Round 2 APPROVED (2/3, 记录少数派 ralph-loop 关切)

package/skills/sprint-flow/references/components/memory.md

@@ -0,0 +1,87 @@
+# memory.md — Sprint State JSON Schema 与长期记忆（AHE 组件分解）
+
+> **本文是 `skills/sprint-flow/SKILL.md` 中状态管理 JSON (L190-334) 的 AHE 对齐展开。**
+> 用于 ablation 实验：AHE 论文显示 Memory 组件单独恢复全局增幅的 95%+。
+
+## 组件职责
+
+定义 Sprint 状态持久化 Schema、Phase 输出合同、长期记忆（learnings）结构。是 AHE 中最关键组件（记忆单独恢复 95%+ 全局增益）。
+
+---
+
+## Sprint State Schema（`.sprint-state/sprint-state.json`）
+
+```json
+{
+  "id": "sprint-YYYY-MM-DD-NN",
+  "phase": 0,
+  "status": "running|paused|completed",
+  "outputs": {
+    "pain_document": "docs/pain-document.md",
+    "specification": "specification.yaml",
+    "mvp": "mvp-v1/",
+    "review_report": "review-report.md"
+  },
+  "metrics": {
+    "tests_passed": 15,
+    "tests_failed": 0,
+    "coverage_pct": 85
+  }
+}
+```
+
+### 状态枚举
+
+| 字段 | 允许值 | 说明 |
+|------|-------|------|
+| `phase` | 0-6 | 当前执行阶段 |
+| `status` | `pending` / `running` / `paused` / `completed` / `failed` | 统一状态 |
+| `pause_reason` | `none` / `wait_approved` / `wait_gate1` / `wait_uat` / `wait_ship` / `wait_user_confirm` | 暂停原因 |
+
+---
+
+## Phase Output 合同
+
+| Phase | 输出文件 | 存储路径 | 必需字段 |
+|-------|---------|---------|---------|
+| Phase 0 | `pain-document.md` | `phase-outputs/pain-document.md` | 结构化设计文档 |
+| Phase 1 | `specification.yaml` | `phase-outputs/specification.yaml` | user_stories[], requirements[], acceptance_criteria[] |
+| Phase 2 | `mvp-v1/` | `phase-outputs/mvp-v1/` | 功能代码 + 测试 |
+| Phase 3 | `review-report.md` | `phase-outputs/review-report.md` | delphi-review 共识报告 |
+| Phase 4 | `emergent-issues.md` | `phase-outputs/emergent-issues.md` | 用户发现的 emergent requirements |
+| Phase 5 | `feedback-log.md` | `phase-outputs/feedback-log.md` | 改进建议 + 调试记录 |
+| Phase 6 | `sprint-summary.md` | `phase-outputs/sprint-summary.md` | 发布记录 + Sprint 2 触发判断 |
+
+---
+
+## Sprint 2 自动触发规则
+
+```
+Phase 6 完成后:
+  IF emergent_issues_count == 0 → sprint_completed，结束
+  IF emergent_issues_count > 0 → sprint_2_needed:
+    ├─ IF 有 Critical → 自动启动 Sprint 2
+    ├─ IF 仅有 Major/Minor → 询问用户
+    └─ Sprint 2 Pain Document ← emergent-issues.md 转化
+```
+
+---
+
+## Learnings Schema（长期记忆）
+
+ralph-loop 内部分类:
+- `permanent`: 跨 REQ 持久化（通用约束、模式）
+- `contextual`: 当前 REQ 生命周期内有效
+
+gstack/learn 调用分类: permanent / contextual 通过 progress.log 持久化。
+
+---
+
+## AHE 分类
+
+| 字段 | 值 |
+|------|---|
+| 组件类型 | Long-Term Memory |
+| 修改频率预期 | 低（Schema 稳定） |
+| 消融实验假设 | 移除 memory → Sprint pass rate 下降 5-10% |
+| 参考证据 | AHE 论文: Memory 单独恢复 95%+ 全局增幅（事实性 > 策略性） |

package/skills/sprint-flow/references/components/middleware.md

@@ -0,0 +1,72 @@
+# middleware.md — Sprint Flow 状态机与暂停点逻辑（AHE 组件分解）
+
+> **本文是 `skills/sprint-flow/SKILL.md` 中完整流程 (L46-68) 和暂停点表 (L72-84) 的 AHE 对齐展开。**
+> 用于 ablation 实验：AHE 论文显示 Middleware 组件贡献占 37%，单独修改可显著影响性能。
+
+## 组件职责
+
+定义 Sprint Flow 的状态机转换逻辑、暂停点（pause-point）触发条件和自动恢复规则。是 phase 间的"胶水层"，负责在特定节点暂停等待用户决策。
+
+---
+
+## 完整状态机（7 Phase 流转）
+
+```
+Phase 0: THINK → brainstorming → HARD-GATE: 设计未 APPROVED → 不可编码
+Phase 1: PLAN  → autoplan → delphi-review → spec.yaml
+Phase 2: BUILD → GITHOOKS-GATE → ralph-loop/TDD → verification → MVP v1
+Phase 3: REVIEW → code-walkthrough → test-alignment → browse QA
+Phase 4: USER ACCEPTANCE → ⚠️ 必须人工 → Emergent Issues List
+Phase 5: FEEDBACK → learn + retro + systematic-debugging
+Phase 6: SHIP → finishing-a-development-branch → canary → Sprint Summary
+```
+
+## 暂停点矩阵
+
+| Phase | 暂停点标识 | 触发条件 | 用户操作 | 自动恢复条件 |
+|-------|-----------|---------|---------|-------------|
+| Phase 0 | **HARD-GATE** | 设计未 APPROVED | 修改设计文档 | 设计 APPROVED 后继续 |
+| Phase 1 | taste_decisions | autoplan 发现未决议事项 | 用户确认每个决策 | 确认后自动继续 |
+| Phase 1 | delphi-review | 未 APPROVED（REQUEST_CHANGES） | 修复并重新评审 | APPROVED 后自动继续 |
+| **Phase 2** | **DELPHI-GATE** | delphi-reviewed.json 不存在或 verdict != APPROVED | 返回 Phase 1 完成 delphi-review | APPROVED 后继续 |
+| Phase 2 | 验证失败 | 超过 max 3 次失败 | 用户决定修复或放弃 | 验证通过后自动继续 |
+| Phase 2 | 成本超阈值 | token 成本 > 阈值 | 用户决定继续或暂停 | 用户确认后自动继续 |
+| Phase 3 | browse 发现问题 | QA 失败 | 回退 Phase 2 | 验证通过后自动继续 |
+| **Phase 4** | **必须人工验收** | 进入 Phase 4 | 用户实际使用后确认 | **无法自动恢复** |
+| **Phase 5** | **FEEDBACK 硬门禁** | Phase 4 完成后进入 | 执行 learn + retro → 生成 feedback-log.md | feedback-log.md 存在后继续 |
+| **Phase 6** | **Phase 5 门禁验证** | Phase 5 未完成 | 验证 feedback-log.md → 不存在 → 返回 Phase 5 | feedback-log.md 存在后继续 |
+| Phase 6 | finishing-a-branch | 分支收尾 | 用户 4 选 1 | 确认后自动继续 |
+| Phase 6 | ship PR | PR 路径需要合并 | 用户确认合并 | 合并后自动继续 |
+
+## 状态转换规则
+
+| 当前状态 | 下一状态 | 条件 |
+|---------|---------|------|
+| Phase N 完成 | Phase N+1 | 无阻塞条件 |
+| Phase 0 HARD-GATE 未通过 | Phase 0 (重试) | 设计未 APPROVED |
+| Phase 2 DELPHI-GATE 未通过 | Phase 1 (回退) | delphi-review not APPROVED |
+| Phase 4 人工验收未完成 | Phase 4 (等待) | **永远不可自动跳过** |
+| Phase 4 确认完成 | Phase 5 | **必须执行，不可跳过** |
+| Phase 5 未完成 (feedback-log.md 不存在) | Phase 5 (等待) | **永远不可自动跳过** |
+| Phase 2 验证失败 > 3 次 | BLOCK (用户决策) | 熔断机制 |
+| Phase 2 成本超限 | BLOCK (用户决策) | 熔断机制 |
+
+## 熔断机制 (Circuit Breaker)
+
+| 原 xp-consensus 状态 | 新处理方案 |
+|---------------------|-----------|
+| `CIRCUIT_BREAKER_TRIGGERED` | sprint-flow 编排层监控成本，超阈值 BLOCK + 用户决策 |
+| `ROLLBACK_TO_ROUND1` | verification-before-completion 失败 → 修复 max 3 次 → 仍失败 BLOCK |
+| `GATE1_FAILED`/`GATE1_COMPLETE` | verification-before-completion 内置此区分 |
+| `GATE2_RUNNING` | `cso` (gstack) — Phase 1-6 安全审计 |
+
+---
+
+## AHE 分类
+
+| 字段 | 值 |
+|------|---|
+| 组件类型 | Middleware |
+| 修改频率预期 | 高（状态机调整频繁） |
+| 消融实验假设 | 修改暂停点逻辑 → Sprint 执行时间变化 ±15% |
+| 参考证据 | AHE 论文: Middleware 组件单独修改带来 +2.2% 总增益 |

package/skills/sprint-flow/references/components/skill-invocations.md

@@ -0,0 +1,104 @@
+# skill-invocations.md — Phase→Skill 调用链与参数路由（AHE 组件分解）
+
+> **本文是 `skills/sprint-flow/SKILL.md` 中各 Phase 调用 Skills (L88-103, L155-167) 的 AHE 对齐展开。**
+> 用于 ablation 实验：验证 phase→skill 映射完整性对 Sprint 成功率的影响。
+
+## 组件职责
+
+提供完整的 Phase→Skill 映射表，包括技能来源、参数路由规则、条件分支逻辑。确保每次 Skill 调用具有足够的上下文信息。
+
+---
+
+## 完整 Phase→Skill 映射矩阵
+
+### Phase 0: THINK
+
+| Skill | 来源 | 触发条件 | 输出 |
+|-------|------|---------|------|
+| `brainstorming` | superpowers | 无条件（首个 Skill） | 结构化设计文档 |
+| **硬闸门** | — | 设计未批准 → 停止 | 禁止进入 Plan |
+
+### Phase 1: PLAN
+
+| Skill | 来源 | 触发条件 | 条件分支 |
+|-------|------|---------|---------|
+| `autoplan` | gstack | 进入 Phase 1 自动调用 | 输出 AUTO_APPROVED 或 NEEDS_REVIEW |
+| `delphi-review` | xp-gate | autoplan NEEDS_REVIEW OR taste_decisions > 0 | 跳过如果 AUTO_APPROVED + 无 taste_decisions |
+| `to-issues` | xp-gate | delphi-review APPROVED 后 | 拆解为垂直切片 → slices-manifest.json |
+
+### Phase 2: BUILD
+
+| 步骤 | Skill | 来源 | 参数注入 |
+|------|-------|------|---------|
+| -1 | `hooks-install` | githooks | 无 |
+| 0 | `dispatching-parallel-agents` | superpowers | 仅分发 AFK 切片（dependency_graph 判定） |
+| 1 | `test-driven-development` | superpowers | `--lang` 注入对应 TDD skill |
+| 2 | `executing-plans` | superpowers | 隔离 session，review checkpoint |
+| 3 | `freeze` | gstack | 锁定业务代码 |
+| 4 | `requesting-code-review` | superpowers | 盲评 agent |
+| 5 | `unfreeze` | gstack | 解锁 |
+| 6 | `verification-before-completion` | superpowers | 运行测试 + lint |
+| 7 | 成本监控 | sprint-flow 编排层 | token 阈值 |
+
+### Phase 3: REVIEW
+
+| Skill | 模式 | 触发条件 |
+|-------|------|---------|
+| `delphi-review` | `--mode code-walkthrough` | 强制调用 |
+| `test-specification-alignment` | 默认 | 强制调用 |
+| `browse` | gstack | 强制调用 |
+| `k6`/`locust`/`gatling` | 性能测试 | `--with-performance` 或 `--type backend-*` |
+
+### Phase 4: USER ACCEPTANCE
+
+| Skill | 说明 |
+|-------|------|
+| **无 Skill** | 必须人工验收 |
+
+### Phase 5: FEEDBACK
+
+| Skill | 来源 | 说明 |
+|-------|------|------|
+| `learn` | gstack | 模式记录 |
+| `retro` | gstack | 工程回顾 |
+| `systematic-debugging` | superpowers | 根因调试 |
+
+### Phase 6: SHIP
+
+| Skill | 说明 |
+|-------|------|
+| `finishing-a-development-branch` | 4 选项 |
+| `ship` | 创建 PR（可选） |
+| `land-and-deploy` | 合并部署 |
+| `canary` | 监控告警 |
+
+---
+
+## 参数路由规则
+
+### `--lang` 路由
+
+| 值 | Phase 2 注入 | Phase 3 注入 |
+|---|-------------|-------------|
+| `springboot` | `springboot-tdd` | springboot-verification |
+| `django` | `django-tdd` | django-verification |
+| `golang` | `golang-testing` | golang-verification |
+
+### `--type` 路由
+
+| 值 | 检测依据 | 额外 Skill |
+|---|---------|-----------|
+| `web-nextjs` | `next.config.js` / `app/` | `design-shotgun` |
+| `backend-go` | `go.mod` | `k6` |
+| `backend-springboot` | `pom.xml` | `gatling` |
+| `backend-django` | `manage.py` | `locust` |
+
+---
+
+## AHE 分类
+
+| 字段 | 值 |
+|------|---|
+| 组件类型 | Skill Invocation Chain |
+| 修改频率预期 | 中（新 skill 注册时更新） |
+| 消融实验假设 | 调用链中断 → Sprint 执行失败率 ↑ |

package/skills/sprint-flow/references/components/system-prompt.md

@@ -0,0 +1,27 @@
+# system-prompt.md — Sprint Flow 行为定义（AHE 组件分解）
+
+> **本文是 `skills/sprint-flow/SKILL.md` 核心原则部分 (L34-43) 的 AHE 对齐展开。**
+> 用于 ablation 实验：单独修改本文件可观察核心原则对 Sprint pass rate 的影响。
+
+## 核心职责
+
+定义 Sprint Flow 的行为边界和全局约束。相当于 AHE 的 System Prompt 组件（虽 AHE 论文显示单独修改 System Prompt 不改善性能，但作为行为基准仍然必要）。
+
+## 核心原则 (AHE 对齐)
+
+| # | AHE 概念 | 原则 | 说明 | 硬闸门 |
+|---|---------|------|------|--------|
+| 1 | 单一入口 | `/sprint-flow` | 用户只需一个命令，自动串联全流程 | Phase 0 HARD-GATE |
+| 2 | 自动流水线 | Think → Ship | 类似 autoplan，自动执行多个阶段 | 无需用户手动调用中间技能 |
+| 3 | 关键节点暂停 | APPROVED / Gate 1 / Phase 4 / Ship | 明确暂停点，不是随时停 | Phase 0 设计未 APPROVED → 禁止编码 |
+| 4 | 承认 Emergent Requirements | 用户验收环节必须人工 | 78% 失败不可见，无法自动化 | Phase 4 MUST NOT 自动化 |
+| 5 | 复用现有 Skills | 不重新发明 | 整合 brainstorming + autoplan + delphi-review + TDD 等 | 不创建新 skill，复用现有体系 |
+
+## AHE 分类
+
+| 字段 | 值 |
+|------|---|
+| 组件类型 | System Prompt |
+| 修改频率预期 | 低（行为基线稳定后极少改变） |
+| 消融实验假设 | 修改核心原则 → Sprint pass rate 不变或下降（AHE 发现单独修改系统提示下降 2.3%） |
+| 关键约束 | 不得删除 Phase 4 人工验收硬闸 |

package/skills/sprint-flow/references/components/tool-descriptions.md

@@ -0,0 +1,96 @@
+# tool-descriptions.md — Sprint Flow 各 Phase 调用的 Skill 完整描述（AHE 组件分解）
+
+> **本文是 `skills/sprint-flow/SKILL.md` 中 Phase 2-6 Skill 调用 (L120-298) 的 AHE 对齐展开。**
+> 用于 ablation 实验：AHE 论文显示 Tool 组件贡献占 48%，单独修改可显著影响性能。
+
+## 组件职责
+
+完整描述 sprint-flow 在每个 Phase 中调用的 Skill，包括参数路由、`--lang`/`--type` 注入、条件分支逻辑。是 ablation 实验中**最可能产生显著增益**的组件。
+
+---
+
+## Phase 2: BUILD 工具链（核心贡献区 — 48%）
+
+### 默认模式: ralph-loop
+
+| 步骤 | Skill | 来源 | 说明 |
+|------|-------|------|------|
+| -1 | `hooks-install` | githooks | `githooks/verify.sh` → 缺失则 `githooks/install.sh` |
+| 0 | `dispatching-parallel-agents` | superpowers | 检测可并行任务 |
+| 1 | `test-driven-development` | superpowers | RED → GREEN → REFACTOR |
+| 2 | `executing-plans` | superpowers | 隔离 session，review checkpoint |
+| 3 | `freeze` | gstack | 盲评隔离 |
+| 4 | `requesting-code-review` | superpowers | 独立 agent 评审 |
+| 5 | `unfreeze` | gstack | 解锁 |
+| 6 | `verification-before-completion` | superpowers | 测试 + lint |
+| 7 | 成本监控 | sprint-flow 编排层 | 超阈值 BLOCK |
+
+### GITHOOKS-GATE (Phase 1→2 闸门)
+
+- 执行时机: Phase 1 完全通过、准备进入 Phase 2 BUILD 前
+- `githooks/verify.sh` 全部存在 → 直接进入 BUILD
+- 缺失 → `githooks/install.sh` 安装（hooks + adapter 基础设施）
+- **核心原则**: 没有质量门禁的代码不可进入 BUILD。**失败 → 不可编码。**
+
+### 语言特定 TDD
+
+通过 `--lang` 参数注入:
+- `springboot-tdd` → springboot-verification
+- `django-tdd` → django-verification
+- `golang-testing` → golang-verification
+
+---
+
+## Phase 3: REVIEW + TEST 工具链
+
+| Skill | 模式 | 说明 |
+|-------|------|------|
+| `delphi-review` | `--mode code-walkthrough` | 多专家匿名代码走查 |
+| `test-specification-alignment` | 默认 | 测试与 Spec 对齐验证 |
+| `browse` | gstack | 浏览器自动化测试 |
+| `k6` / `locust` / `gatling` | 可选 | 后端负载测试 |
+
+---
+
+## Phase 5: FEEDBACK 工具链
+
+| Skill | 说明 |
+|-------|------|
+| `learn` | gstack，模式记录 |
+| `retro` | gstack，工程回顾 |
+| `systematic-debugging` | superpowers，根因调试 |
+
+---
+
+## Phase 6: SHIP 工具链
+
+| Skill | 说明 |
+|-------|------|
+| `finishing-a-development-branch` | 4 选项: merge / PR / discard / keep |
+| `ship` | gstack，创建 PR |
+| `land-and-deploy` | 合并部署 |
+| `canary` | 监控告警 |
+
+---
+
+## 项目类型 → Skill 注入映射
+
+| Phase | Backend (default) | Web Frontend | Mobile |
+|-------|------------------|-------------|--------|
+| Phase 0 (THINK) | `brainstorming` | (同) | (同) |
+| Phase 1 (PLAN) | `autoplan` + `delphi-review` | + `design-shotgun` | (同 web) |
+| Phase 2 (BUILD) | TDD + blind-review | (同 backend) | + `vercel-react-native-skills` / `flutter-review` |
+| Phase 3 (REVIEW) | `delphi-review --mode code-walkthrough` | + `qa` + `design-review` + `benchmark` | `flutter-test` / `detox E2E` |
+| Phase 5 (FEEDBACK) | `learn` + `retro` | (同) | (同) |
+| Phase 6 (SHIP) | `finishing-a-development-branch` + `ship` | (同) | + platform deploy |
+
+---
+
+## AHE 分类
+
+| 字段 | 值 |
+|------|---|
+| 组件类型 | Tool Description |
+| 修改频率预期 | 高（Phase 2 BUILD 工具链频繁调整） |
+| 消融实验假设 | 增删 phase→skill 映射 → Sprint pass rate 变化 ±20%+ |
+| 参考证据 | AHE 论文: Tool 组件单独修改带来 +3.3% 总增益 |

package/skills/sprint-flow/references/phase-0-think.md

@@ -0,0 +1,115 @@
+# Phase 0: THINK（需求探索与设计）
+
+## 目标
+
+使用 brainstorming skill 进行结构化需求探索，输出经用户批准的设计文档。
+
+**关键变更（ISSUE30）**: 从 `office-hours` 切换到 `brainstorming`，原因:
+- brainstorming 有 **HARD-GATE**（设计未批准 → 不可进入实现），防止 "觉得已经理解了就直接开始写代码"
+- brainstorming 输出结构化设计文档，可直接作为 Phase 1 PLAN 的输入
+- office-hours 的 YC 六问适合新产品方向验证，brainstorming 更适合"具体功能实现前设计"的场景
+
+---
+
+## 调用 Skills
+
+- `brainstorming` (superpowers) — **HARD-GATE**: 设计未批准 → 不可进入实现
+- 可选补充：`office-hours` (gstack) — 当用户需求非常模糊、需要先验证产品方向时
+
+---
+
+## HARD-GATE 机制
+
+```
+DO NOT enter Phase 1 (PLAN) or do any implementation
+until the brainstorming design has been APPROVED by the user.
+```
+
+这是 sprint-flow 的关键安全门。brainstorming skill 内部会执行：
+
+1. **Explore project context** — 检查文件、文档、最近 commits
+2. **Ask clarifying questions** — 一次一个，理解目的/约束/成功标准
+3. **Propose approaches** — 2-3 个方案，含 trade-offs 和建议
+4. **Present design** — 分节展示，每节获得用户批准
+5. **Write design doc** — 保存到 `docs/plans/YYYY-MM-DD-<topic>-design.md`
+6. **Transition to implementation** — brainstorming 自动调用 writing-plans
+
+**sprint-flow 编排层行为**:
+- 收到 brainstorming APPROVED 设计文档后，自动进入 Phase 1
+- 如果 brainstorming 未完成（用户未 APPROVED），BLOCK 并等待
+
+---
+
+## 执行步骤
+
+### Step 1: 调用 brainstorming skill
+
+```
+skill(name="brainstorming", user_message="[需求描述]")
+```
+
+brainstorming 内部流程:
+
+```
+Explore project context → Ask clarifying questions → Propose 2-3 approaches
+→ Present design sections → User approves design? → YES → Write design doc
+→ Invoke writing-plans skill
+```
+
+**注意**: brainstorming 内部会自动调用 `writing-plans` 创建实现计划，该计划直接作为 Phase 1 的输入。
+
+### Step 2: 等待 HARD-GATE APPROVED
+
+```
+⚠️ HARD-GATE: 设计未 APPROVED → 不可进入 Phase 1
+
+等待用户审批 brainstorming 输出的设计文档。
+```
+
+sprint-flow 编排层检查:
+- [ ] 设计文档已保存 (`docs/plans/YYYY-MM-DD-<topic>-design.md`)
+- [ ] 用户已 APPROVED
+- [ ] 无未解决的 blocking questions
+
+如果任一条件不满足 → **BLOCK**，等待用户确认。
+
+### Step 3: 保存设计文档路径
+
+```
+设计文档路径写入 sprint-state，供 Phase 1 使用。
+```
+
+保存到 `<project-root>/.sprint-state/phase-outputs/design-doc.md`（内容为设计文档路径引用，或直接复制设计文档）。
+
+---
+
+## 可选补充: office-hours（方向验证）
+
+当用户输入非常模糊时（如 "我想做一个 AI 工具" 而不是 "开发用户登录功能"），可以先调用 `office-hours` 验证产品方向，再进入 brainstorming 详细设计：
+
+```
+skill(name="office-hours", user_message="[模糊需求描述]")
+// → Pain Document → 再进入 brainstorming 详细设计
+```
+
+**使用场景**:
+- 用户描述的是一个新产品/新功能方向，而非具体功能
+- 需要先验证"是否值得做"再进入"怎么做"
+
+**如果不满足以上条件**: 直接跳过 office-hours，只使用 brainstorming。
+
+---
+
+## 暂停点
+
+| 暂停点 | 触发条件 | 用户操作 | 自动恢复条件 |
+|--------|---------|---------|-------------|
+| **HARD-GATE** | brainstorming 设计未 APPROVED | 用户审批设计文档 | 设计 APPROVED 后自动进入 Phase 1 |
+
+---
+
+## 输出
+
+- Design Document (`docs/plans/YYYY-MM-DD-<topic>-design.md`)
+- Implementation Plan（brainstorming 内部 writing-plans 输出）
+- 进入 Phase 1 自动执行（使用设计文档作为输入）