@boyingliu01/xp-gate 0.7.0 → 0.8.0

package/plugins/claude-code/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 自动执行（使用设计文档作为输入）

package/plugins/claude-code/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 == []                       │
+│  → 调用 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（强制）
+
+```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/plugins/claude-code/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/plugins/claude-code/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 ⚠️ **必须人工验收**