@boyingliu01/opencode-plugin 0.12.13 → 0.13.0

package/skills/sprint-flow/templates/sprint-summary-template.md

@@ -2,7 +2,7 @@
 
 ## 使用说明
 
-此模板用于 Phase 6 (SHIP) 结束时生成 Sprint 总结。
+此模板用于 Phase 6/6 CLOSE 结束时生成 Sprint 总结。
 
 ---
 
@@ -25,13 +25,12 @@ MVP 版本: v1.0
 
 | Phase | 耗时 | 状态 | 暂停次数 | 备注 |
 |-------|------|------|---------|------|
-| Phase 0: THINK | [X min] | ✅ 完成 | 0 | [备注] |
-| Phase 1: PLAN | [X min] | ✅ 完成 | [N] | [备注] |
-| Phase 2: BUILD | [X min] | ✅ 完成 | [N] | [备注] |
-| Phase 3: REVIEW | [X min] | ✅ 完成 | [N] | [备注] |
-| Phase 4: UAT | [X min] | ✅ 完成 | 1 (必须) | [备注] |
-| Phase 5: FEEDBACK | [X min] | ✅ 完成 | 0 | [备注] |
-| Phase 6: SHIP | [X min] | ✅ 完成 | [N] | [备注] |
+| 1/6: PREP | [X min] | ✅ 完成 | 0 | worktree + 规模评估 |
+| 2/6: DESIGN | [X min] | ✅ 完成 | [N] | brainstorming + delphi-review |
+| 3/6: BUILD | [X min] | ✅ 完成 | [N] | ralph-loop + TDD |
+| 4/6: VERIFY | [X min] | ✅ 完成 | [N] | code-walkthrough + QA + feedback |
+| 5/6: SHIP | [X min] | ✅ 完成 | [N] | PR + deploy + canary |
+| 6/6: CLOSE | [X min] | ✅ 完成 | 1 (UAT 必须) | 人工验收 + cleanup |
 
 ---
 
@@ -39,16 +38,18 @@ MVP 版本: v1.0
 
 | Skill | 调用次数 | 结果 | 备注 |
 |-------|---------|------|------|
-| office-hours | 1 | ✅ | Pain Document 生成 |
+| brainstorming | 1 | ✅ | design doc |
 | autoplan | 1 | ✅/⚠️ | [taste_decisions 数量] |
-| delphi-review | [N] rounds | ✅ APPROVED | [Round 数量] |
-| specification.yaml | 1 | ✅ | specification.yaml |
-| BUILD (TDD + review) | 1 | ✅ APPROVED | [Gate 1 失败次数] |
-| test-driven-development | [N] | ✅ | [BUILD (TDD + review) 内部调用] |
-| cross-model-review | [N] rounds | ✅ APPROVED | [Round 数量] |
+| delphi-review (design) | [N] rounds | ✅ APPROVED | [Round 数量] |
+| delphi-review (code-walkthrough) | [N] rounds | ✅ APPROVED | [Round 数量] |
+| to-issues | 1 | ✅ | slices-manifest.json |
+| test-driven-development | [N] | ✅ | BUILD 内部调用 |
 | test-specification-alignment | 1 | ✅ | [覆盖率] |
 | browse | 1 | ✅ | [QA 通过] |
+| qa (web) | 1 | ✅ | [health score] |
+| benchmark (web) | 1 | ✅ | [perf baseline] |
 | learn | 1 | ✅ | [记录数量] |
+| retro | 1 | ✅ | Sprint 回顾 |
 | ship | 1 | ✅ | [PR URL] |
 | land-and-deploy | 1 | ✅ | [部署 URL] |
 | canary | 1 | ✅ | [监控正常] |
@@ -117,4 +118,4 @@ Minor Issues (可选纳入):
 ---
 
 **Sprint 结束时间**: YYYY-MM-DD HH:MM:SS
-**报告生成人**: sprint-flow skill
+**报告生成人**: sprint-flow skill

package/skills/test-specification-alignment/AGENTS.md

@@ -1,9 +1,9 @@
 # SKILLS/TEST-SPECIFICATION-ALIGNMENT KNOWLEDGE BASE
 
-**Generated:** 2026-07-07
-**Commit:** 897f8eb
-**Branch:** main
-**Version:** 0.12.13.0
+**Generated:** 2026-07-08
+**Commit:** 6f868ee
+**Branch:** sprint/2026-07-07-01
+**Version:** 0.13.0.0
 
 ## OVERVIEW
 Test-Specification Alignment Engine — two-stage validation ensuring tests accurately reflect requirements and design specs.

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

@@ -1,115 +0,0 @@
-# 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 自动执行（使用设计文档作为输入）

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

@@ -1,178 +0,0 @@
-# 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 == []                       │
-│  → 调用 lightweight delphi-review（2 专家、1 轮、2/2 APPROVED）     │
-│  → 场景: 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（强制，orchestrator 直接执行）
-
-```bash
-skill(name="delphi-review", user_message="[设计文档 + taste_decisions 确认结果]")
-```
-
-delphi-review 执行：
-- Round 1: 3 专家匿名独立评审
-- Round 2+: 交换意见直到共识
-- 输出: APPROVED / REQUEST_CHANGES
-
-**如果 REQUEST_CHANGES**:
-- ⚠️ 暂停等待用户处理（orchestrator 直接执行，可交互确认）
-- 修复后重新评审（从 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-3-review.md

@@ -1,215 +0,0 @@
-# Phase 3: REVIEW + TEST（验证）
-
-## 目标
-
-多专家代码走查、测试对齐、浏览器测试。确保 MVP 符合 specification。
-
-**执行者**: orchestrator 直接执行全部步骤（非 subagent dispatch）— Issue #249。
-
-Web 前端项目额外增加：系统化 QA、视觉审计、性能基线。
-
----
-
-## 调用 Skills
-
-**所有项目**:
-- `delphi-review --mode code-walkthrough` — 多专家匿名代码走查（2-3 domestic models, ≥90% 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: 最终立场（如需）
-- ≥90% 共识 + APPROVED 才通过
-
-**如果 REQUEST_CHANGES**:
-- ⚠️ 暂停等待用户处理 Critical Issues + Major Concerns（orchestrator 直接执行，可交互）
-- 修复后回到 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

@@ -1,125 +0,0 @@
-# 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 自动执行（如果用户确认验收）