@boyingliu01/xp-gate 0.12.13 → 0.13.0

package/plugins/opencode/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/plugins/opencode/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/plugins/opencode/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 自动执行（如果用户确认验收）

package/plugins/opencode/skills/sprint-flow/references/phase-5-feedback.md

@@ -1,100 +0,0 @@
-# Phase 5: FEEDBACK CAPTURE（反馈捕获）
-
-## 目标
-
-记录 Emergent 发现，工程回顾（团队级），持续改进。为 Sprint 2 准备 Pain Document。
-
----
-
-## 调用 Skills
-
-- `learn` (gstack) — 模式记录（个人级）
-- `retro` (gstack) _(新增)_ — 周工程回顾：提交历史、工作模式、代码质量趋势（团队级）
-- `systematic-debugging` (superpowers) _(可选)_ — 根因调试：反馈中的 bug 做根因分析
-
----
-
-## 执行步骤
-
-### Step 1: 调用 learn skill
-
-```
-skill(name="learn", user_message="[Emergent Issues 内容 + Sprint 总结]")
-```
-
-learn 执行：
-- 记录本次 Sprint 的 emergent 发现
-- 转化为 CLAUDE.md 规则
-- 更新 institutional memory
-
-### Step 2: 工程回顾 — 调用 retro（新增 — ISSUE32）
-
-```
-skill(name="retro")
-```
-
-retro 执行：
-- **提交历史分析**: 本次 Sprint 的 commits、工作模式
-- **代码质量趋势**: 结合 Phase 3 的 benchmark 数据，展示质量变化
-- **团队贡献分解**: 每人贡献比例 + praise + growth areas
-- **改进建议**: 下次 Sprint 的改进点
-
-输出: Retro 报告（周级工程回顾）
-
-### Step 3: 根因调试（可选 — ISSUE32）
-
-**IF Phase 4 发现 bug 或 Phase 3 验证失败**:
-```
-skill(name="systematic-debugging", user_message="[具体 bug 描述]")
-```
-
-systematic-debugging 执行 4 阶段：
-1. Investigate（根因调查）
-2. Analyze（分析）
-3. Hypothesize（假设验证）
-4. Implement（修复）
-
-**Iron Law**: 无调查 → 不修复
-
-### Step 4: 转化 Emergent Issues 为 Sprint 2 Pain Document
-
-如果有 emergent issues，转化为新需求：
-```markdown
-# Sprint 2 Pain Document
-
-## 来源
-基于 Sprint 1 的 Emergent Issues
-
-## Critical Issues (自动进入 Sprint 2)
-| Issue | Sprint 1 描述 | Sprint 2 目标 |
-|-------|--------------|--------------|
-
-## Major Issues (询问用户是否纳入)
-| Issue | Sprint 1 描述 | Sprint 2 目标 |
-|-------|--------------|--------------|
-
-## Minor Issues (可选纳入)
-| Issue | Sprint 1 描述 | Sprint 2 目标 |
-|-------|--------------|--------------|
-```
-
-### Step 5: 保存 Feedback Log 和 Sprint 2 Pain Document
-
-保存到：
-- `<project-root>/.sprint-state/phase-outputs/feedback-log.md`
-- `<project-root>/.sprint-state/phase-outputs/sprint2-pain.md` (如有 emergent issues)
-
----
-
-## 暂停点
-
-**无** — Phase 5 完成后自动进入 Phase 6
-
----
-
-## 输出
-
-- Feedback Log (`feedback-log.md`)
-- Retro Report（retro 输出）
-- Sprint 2 Pain Document (`sprint2-pain.md`) — 如果有 emergent issues
-- 进入 Phase 6 自动执行

package/plugins/opencode/skills/sprint-flow/references/phase-6-ship.md

@@ -1,9 +0,0 @@
-# Phase 6: SHIP + DEPLOY（发布）
-
-**完整指令**: @see SKILL.md `## Phase 6: SHIP` section.
-
-**摘要**: 结构化分支完成决策, 创建 PR, 合并部署, 监控. 生成 Sprint Summary.
-
-**关键链**: PHASE5-GATE → verification → finishing-a-development-branch(4选项) → ship → land-and-deploy → canary → Sprint Summary
-
-**输出**: PR URL, Sprint Summary

package/plugins/opencode/skills/sprint-flow/references/phase-7-land.md

@@ -1,9 +0,0 @@
-# Phase 7: LAND（合并 + 部署）
-
-**完整指令**: @see SKILL.md `## Phase 7: LAND` section.
-
-**摘要**: 自动合并 PR, 等待 CI, 执行部署, Canary Health Check, 失败自动回滚.
-
-**关键链**: merge PR → wait CI(10min) → wait Deploy(10min) → Canary Health Check(5min) → auto-rollback on failure
-
-**输出**: 部署状态 (success/failure/skipped), Canary 报告

package/plugins/opencode/skills/sprint-flow/references/phase-8-cleanup.md

@@ -1,9 +0,0 @@
-# Phase 8: CLEANUP（清理 + 总结）
-
-**完整指令**: @see SKILL.md `## Phase 8: CLEANUP` section.
-
-**摘要**: 自动清理 worktree, 更新 sprint-state.json, 输出 Sprint Summary, 处理 emergent issues.
-
-**关键链**: worktree detection → remove(retry×3) → residual check → sprint-state update → Sprint Summary → emergent issues(→Sprint 2?)
-
-**输出**: Cleanup Report, Sprint Summary