@boyingliu01/xp-gate 0.7.0 → 0.8.0

package/plugins/claude-code/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/plugins/claude-code/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/plugins/claude-code/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 | Phase 1 强制调用；AUTO_APPROVED + 无 taste_decisions 使用 lightweight delphi-review | 必须产生 `.sprint-state/delphi-reviewed.json` 且 verdict=APPROVED |
+| `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/plugins/claude-code/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/plugins/claude-code/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 入口（仍必须先执行 DELPHI-GATE）
+- 缺失 → `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/plugins/claude-code/skills/sprint-flow/references/force-levels.md

@@ -0,0 +1,203 @@
+# Sprint Flow 执行级别定义
+
+**执行时机**: Phase 0 THINK 之前，AUTO-ESTIMATE 完成后。
+
+**目的**: 根据需求规模匹配适度评审流程，平衡质量保障与效率。
+
+**核心原则**:
+- 所有级别**必须经过 Delphi 评审**，不可跳过
+- 轻量级采用**简化 Delphi**（2 专家、1 轮），仍需 2/2 批准
+- 标准/复杂采用**完整 Delphi**（2-3 专家、多轮）
+- 自动升级机制：当出现风险信号时强制升级级别
+
+---
+
+## 级别定义
+
+| 级别 | 适用场景 | 专家数 | 最多轮数 | 通过条件 | 预计耗时 |
+|------|---------|--------|---------|----------|---------|
+| **轻量** | 小改动、局部修改、删除代码 | 2 | 1 | 2/2 批准 | 10-20 分钟 |
+| **标准** | 常规功能开发、模块重构 | 2 | 2 | 2/2 批准 | 30-60 分钟 |
+| **复杂** | 核心模块、跨模块变更、新增架构 | 3 | 3 | 3/3 批准 | 1-2 小时 |
+
+---
+
+## Token 成本预算
+
+| 级别 | delphi-review 调用 | 预计 Token 消耗 | 成本说明 |
+|------|-------------------|--------------|---------|
+| **轻量** | 1 次（2 专家、1 轮） | ~8,000 | 简化流程，单轮评审 |
+| **标准** | 1-2 次（2 专家、1-2 轮） | ~15,000-25,000 | 可能需要 1 轮反馈 |
+| **复杂** | 1-3 次（3 专家、1-3 轮） | ~30,000-60,000 | 多轮深度评审 |
+
+> **成本计算依据**: 基于实际 Sprint 历史数据，假设每次 delphi-review 调用平均消耗 8,000-10,000 Token（含 3 位专家的输入输出）。
+
+---
+
+## 测试与验证要求
+
+| 级别 | 单元测试 | 测试覆盖率 | 验证方式 |
+|------|---------|-----------|---------|
+| **轻量** | 修改处必须有测试 | ≥75% | 自动运行 + 人工抽查 |
+| **标准** | 新增功能必须有测试 | ≥80% | 自动运行 + 人工复核 |
+| **复杂** | 全链路测试 + 边界用例 | ≥85% | 自动运行 + Delphi 验证 |
+
+**强制规则**:
+- 轻量级修改**不可跳过测试**，至少添加回归测试
+- 所有级别必须通过 `test-specification-alignment` 验证
+- 未添加测试 → 自动升级至标准级别
+
+---
+
+## 自动升级机制
+
+当出现以下任一情况时，**强制升级**至更高级别：
+
+| 触发条件 | 原级别 | 升级至 | 说明 |
+|---------|--------|--------|------|
+| Delphi 评审出现 REQUEST_CHANGES | 轻量 | 标准 | 需要第二轮评审 |
+| 专家意见分歧（1 票反对） | 轻量/标准 | 复杂 | 需要第 3 专家仲裁 |
+| 涉及公共 API 变更 | 轻量 | 标准 | 影响外部调用方 |
+| 修改文件数 > 5 或 LOC > 200 | 轻量 | 标准 | 改动规模超出轻量范围 |
+| 存在循环依赖 | 轻量/标准 | 复杂 | 架构风险高 |
+| 测试覆盖率 < 75% | 轻量 | 标准 | 质量不达标 |
+| 修改核心模块（core/handlers） | 轻量/标准 | 复杂 | 关键路径 |
+
+**升级流程**:
+1. 自动检测触发条件
+2. 输出升级警告：`[LEVEL_UPGRADE] 从 {原级别} 升级至 {新级别}，原因：{触发条件}`
+3. 保存升级记录到 `.sprint-state/level-upgrade-log.json`
+4. 重新执行对应级别的评审流程
+
+---
+
+## 与 AUTO-ESTIMATE 的关系
+
+AUTO-ESTIMATE 提供**初始级别建议**，Force Levels 定义**具体执行规则**：
+
+```
+AUTO-ESTIMATE 输出 → Force Levels 执行 → 自动升级机制（如触发）
+```
+
+| AUTO-ESTIMATE 指标 | 建议级别 | Force Levels 执行 |
+|-------------------|---------|------------------|
+| 引用计数 ≤ 3 + 跨模块 ≤ 1 | 轻量 | 2 专家、1 轮 Delphi |
+| 引用计数 4-10 或 跨模块 2 | 标准 | 2 专家、最多 2 轮 Delphi |
+| 引用计数 > 10 或 跨模块 ≥ 3 | 复杂 | 3 专家、最多 3 轮 Delphi |
+| 存在循环依赖 | 强制复杂 | 3 专家、最多 3 轮 + 架构评审 |
+
+**关键区别**:
+- AUTO-ESTIMATE: **客观指标分析**（代码结构、引用计数）
+- Force Levels: **执行规则定义**（评审流程、升级机制）
+
+---
+
+## 与 DELPHI-GATE 的关系
+
+**DELPHI-GATE** 是 Phase 2 的**强制门禁**，检查 `.sprint-state/delphi-reviewed.json` 的 `verdict=APPROVED`。Force Levels 定义**产生该门禁文件的评审强度**：
+
+| 场景 | DELPHI-GATE | Force Levels |
+|------|------------|-------------|
+| Phase 1 设计评审 | 3 专家、≥95% 共识、生成 specification.yaml | 不适用（设计阶段） |
+| Phase 2 BUILD 入口 | **必须检查** `.sprint-state/delphi-reviewed.json` 中 `verdict=APPROVED` | 轻量/标准/复杂：通过对应强度的 delphi-review 生成该门禁文件 |
+| 轻量级评审 | 生成 `delphi-reviewed.json`（2 专家、1 轮、2/2 批准） | 2 专家、1 轮、写入门禁文件 |
+| 标准级评审 | 生成 `delphi-reviewed.json`（2 专家、最多 2 轮、2/2 批准） | 2 专家、最多 2 轮、写入门禁文件 |
+| 复杂级评审 | 生成 `delphi-reviewed.json`（3 专家、最多 3 轮、3/3 批准） | 3 专家、最多 3 轮、写入门禁文件 |
+| Phase 3 代码走查 | 再次检查 `delphi-reviewed.json` 或重新评审 | 复用 Force Levels 规则 |
+
+**关键规则**:
+- **DELPHI-GATE 永不跳过**：Phase 2 BUILD 入口必须检查 `.sprint-state/delphi-reviewed.json` 中 `verdict=APPROVED`
+- **Force Levels 定义评审强度**：轻量/标准/复杂决定用 2 专家 1 轮还是 3 专家 3 轮来**产生**门禁文件
+- **轻量级不是跳过评审**：而是简化流程（2 专家、1 轮），但仍需生成门禁文件
+- **LIGHTWEIGHT ≠ ONE-EXPERT**: 1 专家违反 Delphi 核心原则，禁止
+
+---
+
+## 轻量级详细规则
+
+**适用场景**:
+- 删除已存在代码（如移除废弃模块）
+- 小规模修改（≤ 5 个文件、≤ 200 行改动）
+- 不涉及公共 API
+- 无循环依赖
+
+**执行流程**:
+1. 2 位专家独立评审（DeepSeek-v4-pro + Kimi-K2.6）
+2. 单轮评审，无需多轮迭代
+3. **2/2 批准**才通过（不允许 1/2 批准）
+4. 评审通过后写入 `.sprint-state/delphi-reviewed.json`
+
+**输出文件** (`.sprint-state/delphi-reviewed.json`):
+```json
+{
+  "sprint_id": "sprint-2026-06-05-01",
+  "level": "轻量",
+  "delphi_review": {
+    "experts": ["deepseek-v4-pro", "kimi-k2.6"],
+    "rounds": 1,
+    "votes": {
+      "expert_a": "APPROVED",
+      "expert_b": "APPROVED"
+    },
+    "consensus": "2/2 APPROVED",
+    "timestamp": "2026-06-05T10:30:00Z"
+  },
+  "status": "passed"
+}
+```
+
+**强制升级条件**（轻量级触发）:
+- 任一专家 REQUEST_CHANGES → 升级至标准级
+- 涉及公共 API → 升级至标准级
+- 修改文件 > 5 或 LOC > 200 → 升级至标准级
+
+---
+
+## 标准级详细规则
+
+**适用场景**:
+- 常规功能开发
+- 模块重构（不涉及架构变更）
+- 中等规模改动（5-15 个文件、200-500 行改动）
+
+**执行流程**:
+1. 2 位专家独立评审（Round 1）
+2. 如有 REQUEST_CHANGES，进入 Round 2（最多 2 轮）
+3. **2/2 批准**才通过
+4. 评审通过后写入 `.sprint-state/delphi-reviewed.json`
+
+**升级至复杂级条件**:
+- Round 2 仍有分歧（1 票反对）→ 升级至复杂级（第 3 专家仲裁）
+- 涉及核心模块（core/handlers）→ 升级至复杂级
+- 存在循环依赖 → 升级至复杂级
+
+---
+
+## 复杂级详细规则
+
+**适用场景**:
+- 核心模块开发
+- 跨模块变更（≥ 3 个目录）
+- 架构调整
+- 公共 API 重大变更
+
+**执行流程**:
+1. 3 位专家独立评审（DeepSeek-v4-pro + Kimi-K2.6 + Qwen3.6-Plus）
+2. 最多 3 轮评审（Round 1-3）
+3. **3/3 批准**才通过
+4. 评审通过后写入 `.sprint-state/delphi-reviewed.json`
+
+**仲裁机制**:
+- Round 2 仍有分歧 → 第 3 专家（Qwen3.6-Plus）加入仲裁
+- Round 3 必须达成一致，否则 BLOCK 进入 Phase 2
+
+---
+
+## 参见
+
+- [Phase -0.5: AUTO-ESTIMATE](../references/phase-minus-0-5-auto-estimate.md) — 规模评估与流程路由
+- [Phase 0: THINK](../references/phase-0-think.md) — 需求探索与设计
+- [Phase 1: PLAN](../references/phase-1-plan.md) — 计划与 Delphi 设计评审
+- [Phase 2: BUILD](../references/phase-2-build.md) — 编码与 Ralph Loop
+- [Phase 3: REVIEW](../references/phase-3-review.md) — 代码走查与验证
+- [Delphi Review Skill](../../../../skills/delphi-review/SKILL.md) — 多专家共识评审规范