xp-gate 0.5.1

package/skills/sprint-flow/references/phase-1-plan.md

@@ -0,0 +1,178 @@
+# Phase 1: PLAN（共识评审）
+
+## 目标
+
+多模型评审，达成 APPROVED 共识。后续步骤自动从 APPROVED 设计文档提取 specification.yaml。
+
+---
+
+## 调用 Skills
+
+- `autoplan` (gstack) — CEO → Design → Eng 自动流水线
+- `delphi-review` — 多轮匿名评审直到共识
+- specification.yaml 从 APPROVED 设计文档自动生成（无需独立 skill）
+
+**Web 前端项目额外注入**:
+- `design-shotgun` (gstack) — 生成多版 UI 设计变体，用于探索不同的设计方案
+
+**Mobile 项目额外注入** (`--type mobile-flutter` / `mobile-react-native`):
+- `design-shotgun` (gstack) — 移动端 UI 设计探索（Web 项目相同，适用 Flutter Web / RN 项目）
+
+---
+
+## 执行步骤
+
+### Step 0: Web 前端项目 — 调用 design-shotgun（如适用）
+
+**IF project_type is web-nextjs / web-react / web-vue / mobile-flutter / mobile-react-native:**
+
+```bash
+skill(name="design-shotgun", user_message="[Pain Document 内容 + 需求描述]")
+```
+
+design-shotgun 执行：
+- 生成多个 AI 设计变体
+- 打开比较板展示不同设计方案
+- 收集结构化反馈并迭代
+
+输出: 多个设计方案（用于 autoplan 的 plan-design-review）
+
+**IF backend project:** 跳过此步骤，直接进入 Step 1。
+
+### Step 1: 调用 autoplan skill
+
+```bash
+skill(name="autoplan", user_message="[Pain Document 内容]")
+```
+
+autoplan 自动执行：
+- `plan-ceo-review` — CEO 视角评审
+- `plan-design-review` — Design 视角评审  
+- `plan-eng-review` — Eng 视角评审
+
+使用 6 个决策原则自动决策，输出：
+
+```yaml
+autoplan_result:
+  taste_decisions: [] | [decision1, decision2, ...]
+  verdict: "AUTO_APPROVED" | "NEEDS_REVIEW"
+```
+
+---
+
+### Step 2: 条件分支（关键设计）
+
+```
+┌───────────────────────────────────────────────────────────────────┐
+│ Phase 1: 条件分支逻辑                                             │
+├───────────────────────────────────────────────────────────────────┤
+│                                                                    │
+│ IF autoplan_result.verdict == "AUTO_APPROVED"                      │
+│    AND autoplan_result.taste_decisions == []                       │
+│  → 跳过 delphi-review，直接进入 Step 3                            │
+│  → 场景: autoplan 所有决策自动通过，无关键分歧                     │
+│                                                                    │
+│ IF autoplan_result.verdict == "NEEDS_REVIEW"                       │
+│    OR autoplan_result.taste_decisions.length > 0                   │
+│  → ⚠️ 暂停等待用户确认 taste_decisions                             │
+│  → 用户确认后，调用 delphi-review                                  │
+│  → 场景: 存在关键决策分歧或 autoplan 未完全自动通过                │
+│                                                                    │
+└───────────────────────────────────────────────────────────────────┘
+```
+
+---
+
+### Step 2a: 如果需要用户确认 taste_decisions
+
+暂停并提示用户：
+
+```
+⚠️ autoplan 发现以下关键决策无法自动决定，请确认：
+
+Decision 1: [决策描述]
+  Option A: [选项A] - [优缺点]
+  Option B: [选项B] - [优缺点]
+  
+Decision 2: [决策描述]
+  Option A: [...]
+  Option B: [...]
+
+请选择每个决策的选项，或提供您的观点。
+```
+
+用户确认后，继续 Step 2b。
+
+---
+
+### Step 2b: 调用 delphi-review（如需要）
+
+```bash
+skill(name="delphi-review", user_message="[设计文档 + taste_decisions 确认结果]")
+```
+
+delphi-review 执行：
+- Round 1: 3 专家匿名独立评审
+- Round 2+: 交换意见直到共识
+- 输出: APPROVED / REQUEST_CHANGES
+
+**如果 REQUEST_CHANGES**:
+- ⚠️ 暂停等待用户修复
+- 修复后重新评审（从 Round 2 起步）
+- 直到 APPROVED
+
+**如果 APPROVED**:
+- 自动进入 Step 3
+
+---
+
+### Step 3: 从 APPROVED 设计文档提取 specification.yaml
+
+设计文档 APPROVED 后，自动提取需求 + AC 生成轻量 specification.yaml（无需独立 skill）：
+
+```
+# 自动完成: 读取设计文档 → 提取 requirements → 生成 specification.yaml
+# specification.yaml 用于 test-spec-alignment 验证
+```
+
+```yaml
+specification:
+  requirements:
+    - id: REQ-001
+      description: [需求描述]
+      priority: [critical/high/medium/low]
+    
+  acceptance_criteria:
+    - id: AC-001
+      requirement: REQ-001
+      criteria: [验收标准]
+      test_type: [unit/integration/e2e]
+    
+  design_decisions:
+    - id: DD-001
+      decision: [设计决策]
+      rationale: [理由]
+      alternatives_considered: [备选方案]
+```
+
+---
+
+### Step 4: 保存 specification.yaml
+
+保存到 `<project-root>/.sprint-state/phase-outputs/specification.yaml`
+
+---
+
+## 暂停点
+
+| 暂停点 | 触发条件 | 用户操作 |
+|--------|---------|---------|
+| taste_decisions 确认 | autoplan 无法自动决策 | 用户确认每个决策 |
+| delphi-review APPROVED | Round 结果 REQUEST_CHANGES | 用户修复并重新评审 |
+
+---
+
+## 输出
+
+- specification.yaml
+- 进入 Phase 2 自动执行（除非 `--stop-at plan`）

package/skills/sprint-flow/references/phase-2-build.md

@@ -0,0 +1,198 @@
+# Phase 2: BUILD（TDD + 并行执行 + 盲评 + 验证）
+
+## 目标
+
+TDD 执行，多 Agent 并行加速，盲评验证，Gate 1 验证通过。生成 MVP v1。
+
+---
+
+## 调用 Skills
+
+| 步骤 | Skill | 来源 | 说明 |
+|------|-------|------|------|
+| 0 | **`dispatching-parallel-agents`** _(新增)_ | superpowers | 检测可并行任务，并行分发独立子任务 |
+| 0 | **`executing-plans`** _(新增)_ | superpowers | 在隔离 session 中执行计划，有 review checkpoint |
+| 1 | `test-driven-development` | superpowers | RED → GREEN → REFACTOR 铁律 |
+| 1.5 | `vercel-react-native-skills` | gstack | React Native 特定测试框架引用（如适用） |
+| 2 | `freeze` | gstack | 锁定业务代码，盲评隔离 |
+| 3 | `requesting-code-review` | superpowers | 独立 agent 盲评（隔离状态） |
+| 4 | `unfreeze` | gstack | 解锁业务代码 |
+| 5 | `verification-before-completion` | superpowers | 测试 + lint 证据优先 |
+| 6 | 成本监控 | sprint-flow 编排层 | 超阈值 BLOCK + 用户决策 |
+
+---
+
+## 执行步骤
+
+### Step 0: 并行检测与任务分发（新增 — ISSUE29）
+
+**检测可并行任务**:
+从 specification.yaml 或 Phase 1 输出中提取独立任务。并行条件:
+- 无共享状态依赖（不读写同一文件）
+- 无文件冲突风险（不同模块/组件）
+- 2+ 独立任务存在
+
+**IF 检测到可并行任务 → dispatching-parallel-agents 模式**:
+
+```
+Phase 2: 
+  ├── task: [独立A] ──┐
+  ├── task: [独立B] ──┼── dispatching-parallel-agents (并行)
+  ├── task: [独立C] ──┘
+  └── merge → freeze → review → verification
+```
+
+每个独立任务调用:
+```
+skill(name="executing-plans", user_message="[计划内容] + review checkpoint")
+```
+
+**IF 无并行机会 → 串行模式**（保持现有行为）:
+```
+Phase 2: test-driven-development → freeze → review → verification
+```
+
+### Step 1: TDD 执行（test-driven-development）
+
+```
+skill(name="test-driven-development", user_message="[需求描述]，基于 specification.yaml")
+```
+
+**TDD 铁律**:
+1. 🔴 **RED**: 先写测试（根据 specification.yaml 的 acceptance_criteria）
+2. 🟢 **GREEN**: 写最小实现代码让测试通过
+3. 🔵 **REFACTOR**: 重构代码，保持测试通过
+
+**语言特定 TDD**（通过 `--lang` 参数选择）：
+
+| 语言 | 调用的 TDD skill |
+|------|-----------------|
+| Spring Boot | `springboot-tdd` |
+| Django | `django-tdd` |
+| Go | `golang-testing` |
+
+**输出**: tests + code
+
+### Step 1.5: React Native 特定 TDD（如适用）
+
+**移动端项目特定测试策略**：
+
+对于 mobile-react-native 项目:
+- 检测 `--type mobile-react-native` 或 `package.json` 中包含 react-native 依赖
+- 使用 Jest 进行单元测试 (RN 默认)
+- 使用 Detox 进行端到端测试
+- 使用 React Native Testing Library 进行组件测试
+- TDD 流程: 先写组件测试 → 极简组件实现 → 通过测试 → 重构
+
+配置文件:
+- `jest.config.js` 用于测试环境设置
+- `.detoxrc.js` 包含 Detox 配置
+- iOS/Android 模拟器/真机测试支持
+
+**执行顺序**:
+- `npx jest` 运行单元测试
+- `npx detox build && npx detox test` 运行 E2E 测试
+- `npx jest --coverage` 检查测试覆盖率
+
+**Flutter 项目**（作为补充）:
+- 对于 mobile-flutter 项目: `flutter test --coverage` 运行单元和 widget 测试
+
+### Step 2: 盲评隔离（freeze）
+
+```
+skill(name="freeze", user_message="[业务代码文件路径]")
+```
+
+锁定所有业务代码文件，排除测试文件。
+Navigator agent 在盲评阶段将无法访问业务代码。
+
+### Step 3: 独立盲评（requesting-code-review）
+
+```
+skill(name="requesting-code-review", user_message="[需求] + 测试文件 + 测试结果")
+```
+
+**关键**: 盲评 agent 只接收需求 + 测试 + 测试结果，**不传业务代码**（freeze 锁定中）。
+
+**输出**: review findings（问题清单 + 建议）
+
+### Step 4: 解锁业务代码（unfreeze）
+
+```
+skill(name="unfreeze", user_message="[业务代码文件路径]")
+```
+
+解锁业务代码文件，允许后续步骤访问。
+
+### Step 5: 验证（verification-before-completion）
+
+```
+skill(name="verification-before-completion", user_message="验证实现完整性")
+```
+
+**验证内容**：
+- 测试全部通过
+- Lint 无错误
+- 覆盖率 ≥ 80%
+- 证据优先：必须运行命令并确认输出
+
+**失败处理**：
+- 自动修复 max 3 次
+- 每次失败后修复代码，重新运行验证
+- max 3 次失败 → ⚠️ BLOCK，暂停等待用户决定
+
+### Step 6: 成本监控（sprint-flow 编排层）
+
+sprint-flow 编排层监控本次 Phase 2 的成本：
+
+| 阈值 | 值 | 处理 |
+|------|-----|------|
+| 单任务阈值 | $0.15 | BLOCK + 提示用户决定 |
+| 日阈值 | $1.00 | BLOCK + 提示用户决定 |
+
+**零降级原则**: 成本超阈值时，必须 BLOCK 并通知用户，由用户决定是否继续。AI 不能自动跳过验证步骤。
+
+---
+
+## 关键行为保留（原 xp-consensus 17 状态机）
+
+| 原状态 | 含义 | 新处理方案 |
+|--------|------|-----------|
+| `CIRCUIT_BREAKER_TRIGGERED` | 成本/资源超阈值 | sprint-flow 编排层监控成本，超阈值 BLOCK + 用户决策 |
+| `ROLLBACK_TO_ROUND1` | Gate 1 失败自动修复 → 回退 | verification-before-completion 失败 → 修复 max 3 次 → 仍失败 BLOCK |
+| `GATE1_FAILED`/`GATE1_COMPLETE` | 区分可修复 vs 致命失败 | verification-before-completion 内置此区分 |
+| `GATE2_RUNNING` | Security Scan 集成 | `cso` (gstack) Phase 1-6 安全审计替代 |
+| `SEALED_CODE_ISOLATION` | freeze 技术隔离 | **保留 freeze skill 调用** |
+| `MOBILE_TDD_EXECUTION` | React Native/Flutter 特定 TDD 执行 | 根据 `--type` 参数选择: mobile-react-native → RN TDD, mobile-flutter → Flutter TDD |
+
+---
+
+## Skill 间数据流契约
+
+| 步骤 | Skill | 输入 | 输出 | 失败回退 |
+|------|-------|------|------|----------|
+| 0a | dispatching-parallel-agents | specification.yaml + 任务分解 | 并行子任务分发 | 降级为串行 |
+| 0b | executing-plans | 子任务计划 | 实现 + review checkpoint | BLOCK |
+| 1 | test-driven-development | 需求描述 + 现有代码上下文 | 测试 + 代码 (RED→GREEN→REFACTOR) | 修复 max 3 次 → BLOCK |
+| 1.5 | vercel-react-native-skills | 项目类型 (mobile-react-native 或 mobile-flutter), package.json | RN/Flutter 测试执行结果 | RN/Flutter 测试失败 → 修复 max 3 次 → BLOCK |
+| 2 | freeze | 业务代码文件路径 | 锁定状态确认 | ❌ BLOCK |
+| 3 | requesting-code-review | 需求 + 测试 + 测试结果（**不传业务代码**） | review findings | 继续（记录 findings） |
+| 4 | unfreeze | 业务代码文件路径 | 解锁状态确认 | ❌ BLOCK |
+| 5 | verification-before-completion | 测试执行结果 | pass/fail 证据 | 修复 max 3 次 → BLOCK |
+
+---
+
+## 暂停点
+
+| 暂停点 | 触发条件 | 用户操作 |
+|--------|---------|---------|
+| 验证 max 3 失败 | verification-before-completion 失败超过 3 次 | 用户决定修复或放弃 |
+| 成本超阈值 | 单任务 >$0.15 或日 >$1.00 | 用户决定继续或暂停 |
+| RN/Flutter 测试失败 | mobile-react-native 或 mobile-flutter 项目的测试执行失败且自动修复 max 3 次后仍未通过 | 用户决定继续修复或调整方案 |
+
+---
+
+## 输出
+
+- MVP v1 (`mvp-v1/` 目录)
+- 进入 Phase 3 自动执行

package/skills/sprint-flow/references/phase-3-review.md

@@ -0,0 +1,213 @@
+# Phase 3: REVIEW + TEST（验证）
+
+## 目标
+
+多专家代码走查、测试对齐、浏览器测试。确保 MVP 符合 specification。
+
+Web 前端项目额外增加：系统化 QA、视觉审计、性能基线。
+
+---
+
+## 调用 Skills
+
+**所有项目**:
+- `delphi-review --mode code-walkthrough` — 多专家匿名代码走查（2-3 domestic models, >=95% consensus）
+- `test-specification-alignment` — 测试与 Spec 对齐验证
+- `browse` (gstack) — 浏览器自动化测试
+
+**Web 前端项目额外注入** (`--type web-nextjs` / `web-react` / `web-vue`):
+- `qa` (gstack) — 三层 QA（Quick/Standard/Exhaustive）系统化测试
+- `design-review` (gstack) — 线上 UI 视觉审计（间距、层级、AI slop 检测）
+- `benchmark` (gstack) — Core Web Vitals 性能基线
+
+**Mobile 项目额外注入** (`--type mobile-flutter` / `mobile-react-native`):
+- `flutter-test` — Flutter 单元测试 + widget 测试 (Flutter only)
+- Detox E2E — React Native 端到端测试 (RN only)
+- `flutter-review` (user) — Flutter 代码审查 (Flutter only)
+
+**Backend 项目额外注入** (`--type backend-go` / `backend-springboot` / `backend-django`):
+- API Testing — 后端 API 自动化测试
+
+---
+
+## 执行步骤
+
+### Step 1: 调用 delphi-review --mode code-walkthrough
+
+```
+skill(name="delphi-review", user_message="--mode code-walkthrough")
+```
+
+delphi code-walkthrough 执行：
+- 2-3 位国内模型专家匿名独立评审（DeepSeek-v4-pro + Kimi-K2.6 + Qwen3.6-Plus）
+- Round 1: 匿名独立评审（防止 anchoring bias）
+- Round 2: 交换意见，响应关切
+- Round 3: 最终立场（如需）
+- >=95% 共识 + APPROVED 才通过
+
+**如果 REQUEST_CHANGES**:
+- ⚠️ 暂停等待用户修复 Critical Issues + 处理 Major Concerns
+- 修复后回到 Round 2 重新评审
+
+**如果 APPROVED**:
+- 写入 `.code-walkthrough-result.json`（1 小时有效期）
+- 进入 Step 2
+
+### Step 2: 调用 test-specification-alignment
+
+```
+skill(name="test-specification-alignment", user_message="--spec specification.yaml --tests mvp-v1/tests")
+```
+
+Phase 1: 验证对齐（可修改测试） → Phase 2: 执行测试（禁止修改测试）
+
+失败 → 回退 Phase 2 自动修复。通过 → 进入 Step 3。
+
+### Step 2.5: Web 前端 — 调用 qa（如适用）
+
+**IF project_type is web-nextjs / web-react / web-vue:**
+
+```
+skill(name="qa", user_message="Standard: [部署 URL 或 localhost:3000]")
+```
+
+qa 三层可选：
+- Quick: 只测 critical + high 问题
+- Standard (推荐): critical + high + medium
+- Exhaustive: 包括 cosmetic
+
+输出: before/after health scores + fix evidence + ship-readiness summary
+
+### Step 2.6: Web 前端 — 调用 design-review（如适用）
+
+**IF project_type is web-nextjs / web-react / web-vue:**
+
+```
+skill(name="design-review", user_message="审计 [部署 URL] 的视觉设计")
+```
+
+design-review 检查：
+- 视觉一致性（间距、颜色、字体）
+- 层级问题（信息架构、布局）
+- AI slop 模式（重复布局、过度设计）
+- 交互响应（动画、加载状态）
+
+迭代修复，每次提交原子化。
+
+### Step 2.7: Web 前端 — 调用 benchmark（如适用）
+
+**IF project_type is web-nextjs / web-react / web-vue:**
+
+```
+skill(name="benchmark", user_message="建立 [部署 URL] 的性能基线")
+```
+
+benchmark 测量：
+- 页面加载时间
+- Core Web Vitals (LCP, FID, CLS)
+- 资源大小
+- 与上次部署对比
+
+### Step 2.8: Mobile — Flutter 测试（如适用）
+
+**IF project_type is mobile-flutter:**
+
+```bash
+flutter test --coverage 2>&1 | tail -20
+```
+
+flutter-test 输出:
+- 测试通过率
+- 覆盖率统计
+- Widget 测试结果
+
+### Step 2.9: Mobile — React Native 测试（如适用）
+
+**IF project_type is mobile-react-native:**
+
+```bash
+npx detox test 2>&1 | tail -20
+```
+
+RN E2E 输出:
+- Detox 测试结果
+- 模拟器/真机行为验证
+
+### Step 2.10: API 自动化测试（后端项目如适用）
+
+**IF project_type is backend-go/backend-springboot/backend-django:**
+
+```bash
+skill(name="api-test", user_message="针对 [API endpoint] 运行自动化测试")
+```
+
+**Backend 类型支持**:
+- **Go (backend-go)**: 使用 httpbakery 或原生 net/http 测试
+- **Spring Boot (backend-springboot)**: 使用 RestAssured 或 TestRestTemplate  
+- **Django (backend-django)**: 使用 Django REST framework 测试客户端或 pytest-django
+
+**API 测试覆盖**:
+- 所有 API 端点测试 (GET, POST, PUT, DELETE)
+- 响应状态码验证
+- 响应数据结构验证（符合 Spec）
+- 认证端点测试
+- 错误处理测试 (400, 401, 403, 404, 500)
+
+API 测试失败 → 自动回退 Phase 2 修复。
+
+### Step 3: 调用 browse skill
+
+```
+skill(name="browse", user_message="--url [URL] --test-ui")
+```
+
+**默认**: `localhost:3000`
+
+**Web 前端扩展支持**:
+- 部署环境 URL 测试（如 Vercel/Render/Netlify）
+- 响应式布局测试（mobile/tablet/desktop）
+- 表单交互测试（提交、验证）
+- 认证页面测试（login/register）
+
+browse 执行：
+- 启动 Chromium
+- 测试 UI/UX
+- 截图验证
+
+发现问题 → 回退 Phase 2 修复。通过 → 进入 Step 4。
+
+### Step 4: 保存 Review Report
+
+保存到 `<project-root>/.sprint-state/phase-outputs/review-report.md`
+
+包含：
+- delphi code-walkthrough result
+- test-specification-alignment result
+- qa report (web only)
+- design-review report (web only)
+- benchmark baseline (web only)
+- browse screenshots
+
+---
+
+## 暂停点
+
+| 暂停点 | 触发条件 | 用户操作 |
+|--------|---------|---------|
+| delphi code-walkthrough REQUEST_CHANGES | Critical Issues 未修复 | 用户修复 → 重新评审 → APPROVED → 继续 |
+| test-alignment 失败 | 自动回退 Phase 2（不暂停） | 自动迭代 |
+| qa 发现问题 (web) | 自动回退修复（不暂停） | 自动迭代 |
+| design-review 发现问题 (web) | 自动回退修复（不暂停） | 自动迭代 |
+| api-test 失败 (backend) | 自动回退 Phase 2（不暂停） | 自动迭代 |
+| browse 发现问题 | 自动回退 Phase 2（不暂停） | 自动迭代 |
+
+---
+
+## 输出
+
+- `.code-walkthrough-result.json`（pre-push hook 验证）
+- Review Report (`review-report.md`)
+- Web 前端附加: QA report + design-review report + benchmark baseline
+- Backend 附加: API test report
+- 验证通过的 MVP
+- 进入 Phase 4 ⚠️ **必须人工验收**

package/skills/sprint-flow/references/phase-4-uat.md

@@ -0,0 +1,125 @@
+# Phase 4: USER ACCEPTANCE（⚠️ 人工验收）
+
+## 目标
+
+用户实际使用 MVP，发现 Emergent 问题。这是 AI 无法预测的环节。
+
+---
+
+## ⚠️ 关键说明
+
+**这是 Emergent Requirements 发现环节。**
+
+- AI 无法预测用户看到产品后才发现的问题
+- 78% 的软件失败是用户使用时发现的，不是开发阶段发现的
+- 必须由用户实际使用验收
+
+---
+
+## 调用 Skills
+
+**无** — 必须人工
+
+---
+
+## 执行步骤
+
+### Step 1: 提示用户开始验收
+
+```
+⚠️ Phase 4: USER ACCEPTANCE
+
+MVP 已通过自动化验证，现在需要您实际使用验收。
+
+请按照以下步骤：
+1. 启动应用（或访问部署地址）
+2. 使用 Emergent Issues 检查清单进行验收
+3. 记录发现的问题
+4. 完成后确认是否继续
+
+验收完成后，请回复：
+- "验收通过" → 进入 Phase 5
+- "发现问题" → 填写 emergent-issues.md
+```
+
+---
+
+### Step 2: 用户实际使用 MVP
+
+用户按照 Emergent Issues 检查清单验收：
+
+使用模板：`@templates/emergent-issues-template.md`
+
+检查维度：
+1. **核心功能体验** (Core Functionality UX)
+2. **多轮交互体验** (Multi-turn Interaction UX)
+3. **视觉/交互体验** (Visual/Interaction UX)
+4. **用户认知负担** (Cognitive Load)
+5. **意外发现** (Unexpected Observations)
+
+---
+
+### Step 3: 记录 Emergent Issues
+
+用户填写 `emergent-issues.md`：
+
+```markdown
+# Emergent Issues - [需求名称]
+
+## 验收日期
+YYYY-MM-DD
+
+## 发现的问题
+
+### Critical
+| 问题描述 | 影响范围 | 发现场景 |
+|---------|---------|---------|
+
+### Major
+| 问题描述 | 影响范围 | 发现场景 |
+|---------|---------|---------|
+
+### Minor
+| 问题描述 | 影响范围 | 发现场景 |
+|---------|---------|---------|
+
+## 验收结论
+- [ ] ✅ 验收通过，进入 Phase 5
+- [ ] ⚠️ 发现问题需 Sprint 2 迭代
+```
+
+---
+
+### Step 4: 保存 Emergent Issues
+
+保存到 `<project-root>/.sprint-state/phase-outputs/emergent-issues.md`
+
+---
+
+## 暂停点
+
+**⚠️ 必须等待用户验收完成**
+
+- 用户确认验收结果后才能继续
+- 如果发现重大问题 → Sprint 2 回到 Phase 0
+
+---
+
+## Sprint 2 触发逻辑
+
+```
+Sprint 结束时 (Phase 6 完成):
+  IF emergent_issues_count == 0 → sprint_completed，结束流程
+  
+  IF emergent_issues_count > 0:
+    ├─ IF emergent_issues 有 Critical → 自动启动 Sprint 2
+    ├─ IF emergent_issues 仅 Major/Minor → 询问用户
+    └─ Sprint 2 Pain Document 从 emergent-issues.md 转化
+```
+
+---
+
+## 输出
+
+- Emergent Issues List (`emergent-issues.md`)
+- 进入 Phase 5 自动执行（如果用户确认验收）