@boyingliu01/xp-gate 0.7.0 → 0.7.1

package/skills/sprint-flow/references/components/skill-invocations.md

@@ -23,7 +23,7 @@
 | Skill | 来源 | 触发条件 | 条件分支 |
 |-------|------|---------|---------|
 | `autoplan` | gstack | 进入 Phase 1 自动调用 | 输出 AUTO_APPROVED 或 NEEDS_REVIEW |
-| `delphi-review` | xp-gate | autoplan NEEDS_REVIEW OR taste_decisions > 0 | 跳过如果 AUTO_APPROVED + 无 taste_decisions |
+| `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

package/skills/sprint-flow/references/components/tool-descriptions.md

@@ -28,7 +28,7 @@
 ### GITHOOKS-GATE (Phase 1→2 闸门)
 
 - 执行时机: Phase 1 完全通过、准备进入 Phase 2 BUILD 前
-- `githooks/verify.sh` 全部存在 → 直接进入 BUILD
+- `githooks/verify.sh` 全部存在 → 进入 BUILD 入口（仍必须先执行 DELPHI-GATE）
 - 缺失 → `githooks/install.sh` 安装（hooks + adapter 基础设施）
 - **核心原则**: 没有质量门禁的代码不可进入 BUILD。**失败 → 不可编码。**
 

package/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) — 多专家共识评审规范

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

@@ -69,13 +69,13 @@ autoplan_result:
 │                                                                    │
 │ IF autoplan_result.verdict == "AUTO_APPROVED"                      │
 │    AND autoplan_result.taste_decisions == []                       │
-│  → 跳过 delphi-review，直接进入 Step 3                            │
-│  → 场景: autoplan 所有决策自动通过，无关键分歧                     │
+│  → 调用 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                                  │
+│  → 用户确认后，调用标准 delphi-review                              │
 │  → 场景: 存在关键决策分歧或 autoplan 未完全自动通过                │
 │                                                                    │
 └───────────────────────────────────────────────────────────────────┘
@@ -105,7 +105,7 @@ Decision 2: [决策描述]
 
 ---
 
-### Step 2b: 调用 delphi-review（如需要）
+### Step 2b: 调用 delphi-review（强制）
 
 ```bash
 skill(name="delphi-review", user_message="[设计文档 + taste_decisions 确认结果]")

package/skills/sprint-flow/references/phase-minus-0-5-auto-estimate.md

@@ -182,10 +182,27 @@ find . -name "*{target}*.test.*" -o -name "*{target}*.spec.*" | grep -v node_mod
 
 | 流程级别 | 路由 |
 |---------|------|
-| **轻量** | → Phase 2 BUILD（跳过 Phase 0 brainstorming、Phase 1 delphi-review） |
+| **轻量** | → Phase 0 THINK（reduced-intensity 流程，见 references/force-levels.md） |
 | **标准** | → Phase 0 THINK（正常流程） |
 | **复杂** | → Phase 0 THINK（完整流程 + 风险警告提示） |
 
+**DELPHI-GATE invariant**: 所有流程级别（轻量/标准/复杂）的 Phase 2 BUILD 启动前，**必须**检查 `.sprint-state/delphi-reviewed.json` 的 verdict 为 `APPROVED`。未通过 delphi-review 直接路由到 BUILD 属于严重违规。
+
+**轻量级的正确理解**: 轻量级意味着 reduced-intensity 的 delphi-review（**2 专家、1 轮、2/2 APPROVED、较短上下文**），**不是**跳过 delphi-review，**不是** 1 专家评审。见 references/force-levels.md 的轻量级流程定义。
+
+**自动 escalation 规则**（检测到以下情况时，自动提升流程级别）:
+
+| 触发条件 | 原级别 | 提升级别 | 理由 |
+|---------|--------|---------|------|
+| 风险警告（循环依赖、Public API > 5） | 轻量 | 标准 | 技术风险需要标准流程 |
+| 多位专家 disagreement 或 REQUEST_CHANGES | 轻量/标准 | 复杂 | 意见分歧需要更全面评审 |
+| 涉及文件数 > 10 或 LOC > 500 | 轻量 | 标准 | 超出轻量级预算 |
+| 修改公共 API（export 接口） | 轻量/标准 | 复杂 | API 变更影响范围广 |
+| 检测到循环依赖 | 任何级别 | 复杂 | 架构风险强制复杂流程 |
+| 相关测试文件缺失或覆盖率 < 80% | 轻量/标准 | 标准 | 需要补充测试 |
+
+**跨参考**: 详见 references/force-levels.md 的各级别流程定义和强制规则。
+
 ---
 
 ## 特殊场景处理
@@ -199,6 +216,8 @@ git diff --stat HEAD 2>/dev/null  # 如果有局部修改
 
 **处理**: 如果预估改动 < 20 行且涉及 ≤ 2 个文件，自动判定为「轻量」并告知用户，不强制展示完整 AUTO-ESTIMATE 面板。
 
+**注意**: 轻量级仍需要完整的 Sprint Flow 流程（包括 delphi-review），只是 reduced-intensity。见 references/force-levels.md 的轻量级定义。**不会**绕过 DELPHI-GATE 直接路由到 BUILD。
+
 ### 场景 2: 无法提取目标关键词
 
 **处理**: 询问用户「无法自动识别目标模块，请指定要分析的关键词（函数名/类名/模块名）：」

package/skills/sprint-flow/templates/auto-estimate-output-template.md

@@ -41,7 +41,7 @@
 | `{circular_dep_status}` | 循环依赖状态 | ✅ 无 / ⚠️ 存在 (A ↔ B) |
 | `{public_api_count}` | Public API 暴露数 | 5 |
 | `{additional_metrics}` | 附加指标（可选行） | 测试文件：4 个 / 影响范围：3 层调用 |
-| `{recommended_flow}` | 建议流程描述 | 轻量流程 (Phase 2-3) |
+| `{recommended_flow}` | 建议流程描述 | 轻量流程 (Phase 0-3, reduced-intensity Delphi) |
 | `{risk_warning}` | 风险警告（可选块） | ⚠️ 此操作涉及循环依赖… |
 | 操作按钮 | 用户确认选项 | 接受建议 / 修改流程 / 取消 |
 
@@ -72,9 +72,9 @@
 +-------------------------------------------------------------+
 | 选择流程级别：                                                |
 |                                                             |
-| [1] 轻量流程 — 直接编码 + 基础验证 (Phase 2-3)               |
-| [2] 标准流程 — brainstorming + BUILD + REVIEW (Phase 0-4)    |
-| [3] 完整流程 — 完整 Sprint Flow (Phase 0-8)                  |
+| [1] 轻量流程 — minimal THINK + 简化 Delphi + BUILD/REVIEW (Phase 0-3) |
+| [2] 标准流程 — brainstorming + Delphi + BUILD + REVIEW (Phase 0-4)    |
+| [3] 完整流程 — 完整 Sprint Flow (Phase 0-8)                          |
 |                                                             |
 | 修改原因（必填）：____________________                        |
 |                                                             |
@@ -107,10 +107,12 @@
 
 | 评估结果 | 路由 | 说明 |
 |---------|------|------|
-| **轻量** (引用 ≤3, 同模块，无循环依赖) | Phase 2-3（跳过 brainstorming + delphi-review） | 直接编码 + 基础验证 |
+| **轻量** (引用 ≤3, 同模块，无循环依赖) | Phase 0-3（minimal THINK → 简化 Delphi 评审 → BUILD/REVIEW） | 低强度执行，仍需 DELPHI-GATE APPROVED |
 | **标准** (引用 4-10, 跨 1-2 模块) | Phase 0-4（完整 THINK → BUILD → REVIEW） | 标准 sprint |
 | **复杂** (引用 >10 或 循环依赖 或 跨 3+ 模块) | Phase 0-8（完整 sprint-flow） | 完整流程 + 风险警告 |
 
+**所有流程路线均需在 Phase 2 前获得 delphi-review APPROVED verdict。**
+
 ## 学习闭环
 
 当用户选择「修改流程」时，记录 override 数据：

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

@@ -0,0 +1,151 @@
+# Sprint Progress Template
+
+本模板定义了 Sprint 进度看板的标准显示格式。
+Orchestrator 在每个 Phase 完成后、以及响应用户 `--status` 查询时，使用此模板渲染进度。
+
+## 渲染规则
+
+1. 从 `.sprint-state/sprint-state.json` 读取 `id`, `task_description`, `phase`, `status`, `started_at`, `phase_history`, `outputs`, `isolation`
+2. 按下方模板渲染 ASCII 看板
+3. 状态图标映射：✅ completed | 🔄 running | ⏸️ paused | ⬜ pending | ⏭️ skipped | ❌ failed
+
+## 看板模板
+
+```
++============================================================+
+|  SPRINT PROGRESS                      {sprint_id}          |
++============================================================+
+|  需求: {task_description}                                   |
+|  分支: {branch}                                             |
+|  状态: {overall_status}        启动: {started_at}           |
++============================================================+
+|                                                             |
+|  {icon_-1} Phase -1   ISOLATE         {duration_-1}        |
+|  {icon_-0.5} Phase -0.5 AUTO-ESTIMATE  {duration_-0.5}     |
+|  {icon_0} Phase 0    THINK           {duration_0}          |
+|  {icon_1} Phase 1    PLAN            {duration_1}          |
+|  {icon_2} Phase 2    BUILD           {duration_2}          |
+|  {icon_3} Phase 3    REVIEW          {duration_3}          |
+|  {icon_4} Phase 4    USER ACCEPT     {duration_4}          |
+|  {icon_5} Phase 5    FEEDBACK        {duration_5}          |
+|  {icon_6} Phase 6    SHIP            {duration_6}          |
+|  {icon_7} Phase 7    LAND            {duration_7}          |
+|  {icon_8} Phase 8    CLEANUP         {duration_8}          |
+|                                                             |
+|  [{progress_bar}] {pct}%                                    |
++============================================================+
+|  > 当前: Phase {current_phase} {current_phase_name}         |
+|    状态: {current_phase_status}                              |
+|                                                             |
+|  下一步: {next_action}                                       |
+|    {next_action_detail}                                      |
++============================================================+
+|  输出物:                                                     |
+|    {output_list}                                             |
++============================================================+
+```
+
+## 字段说明
+
+| 字段 | 来源 | 说明 |
+|------|------|------|
+| `{sprint_id}` | `sprint-state.json → id` | Sprint 标识 |
+| `{task_description}` | `sprint-state.json → task_description` | 需求描述（缺失时显示 "-"） |
+| `{branch}` | `sprint-state.json → isolation.branch` | 工作分支 |
+| `{overall_status}` | `sprint-state.json → status` | running / paused / completed |
+| `{started_at}` | `sprint-state.json → started_at` | Sprint 启动时间（格式化: YYYY-MM-DD HH:MM） |
+| `{icon_N}` | `phase_history[N].status` | 状态图标（见上方映射） |
+| `{duration_N}` | `phase_history[N].duration_seconds` | 耗时（见下方格式化规则） |
+| `{current_phase}` | `sprint-state.json → phase` | 当前阶段编号 |
+| `{current_phase_name}` | Phase 名称映射 | ISOLATE / AUTO-ESTIMATE / THINK 等 |
+| `{current_phase_status}` | `phase_history` 中当前阶段的 status | running / paused / completed |
+| `{next_action}` | 下方"下一步行动表" | 用户需要执行的操作 |
+| `{next_action_detail}` | 操作细节 | 具体指令 |
+| `{output_list}` | `sprint-state.json → outputs` | 已生成的输出物路径列表（每项一行） |
+| `{progress_bar}` | 已完成阶段数 / 总阶段数 | 格式: `████▓░░░░░░` |
+| `{pct}` | 完成百分比 | 整数 |
+
+## 进度条生成规则
+
+```
+总阶段数 = 11（Phase -1, -0.5, 0, 1, 2, 3, 4, 5, 6, 7, 8）
+已完成数 = phase_history 中 status == "completed" 的数量
+每个阶段 = 1 个字符宽度
+填充: 已完成 = █ | 当前 = ▓ | 待做 = ░ | 跳过 = ▒
+```
+
+## 下一步行动表
+
+| 当前阶段 | 当前状态 | 下一步行动 | 行动细节 |
+|---------|---------|-----------|---------|
+| Phase -1 | completed | 确认环境 | 检查 worktree 路径，准备进入需求分析 |
+| Phase -0.5 | completed | 确认评估 | 查看 AUTO-ESTIMATE 结果，选择流程级别 |
+| Phase 0 | completed | 确认设计 | 审阅设计文档，确认后进入 Phase 1 |
+| Phase 0 | paused | 审阅设计 | 设计文档等待您的 APPROVED 确认 |
+| Phase 1 | completed | 确认评审 | delphi-review 已通过，检查 specification.yaml |
+| Phase 1 | paused | 等待评审 | delphi-review 进行中或等待 taste_decisions 确认 |
+| Phase 2 | completed | 审阅代码 | BUILD 完成，进入 Phase 3 REVIEW |
+| Phase 2 | running | 等待构建 | ralph-loop 迭代中，无需操作 |
+| Phase 3 | completed | 开始验收 | 进入 Phase 4 人工验收 |
+| Phase 4 | completed | 确认反馈 | 验收完成，Phase 5 自动进行 |
+| Phase 4 | paused | 执行验收 | 必须人工验收，请实际使用后确认 |
+| Phase 5 | completed | 确认发布 | 反馈已收集，准备进入 Phase 6 SHIP |
+| Phase 6 | completed | 确认合并 | PR 已创建，确认是否合并 |
+| Phase 7 | completed | 确认清理 | 合并成功，准备清理 worktree |
+| Phase 8 | completed | Sprint 完成 | 检查 Sprint Summary，如有 emergent issues 考虑 Sprint 2 |
+| 任意 | failed | 处理错误 | 查看错误信息，决定修复或放弃 |
+
+## 耗时格式化规则
+
+```
+< 60s     → "{N}s"
+< 60m     → "{N}m"
+< 24h     → "{X}h {Y}m"
+>= 24h    → "{X}d {Y}h"
+无数据    → "-"
+```
+
+## 向后兼容
+
+当 `sprint-state.json` 缺少以下字段时（旧版 sprint 创建的状态文件），渲染规则：
+- `task_description` 缺失 → 显示 "-"
+- `started_at` 缺失 → 显示 "-"
+- `phase_history` 缺失 → 从 `phase` 字段推断：小于等于 `phase` 的阶段标记为 ✅，当前阶段标记为 🔄，其余标记为 ⬜；所有耗时显示 "-"
+
+## 示例渲染
+
+```
++============================================================+
+|  SPRINT PROGRESS                      sprint-2026-06-04-01 |
++============================================================+
+|  需求: 为 sprint-flow 添加进度看板功能                       |
+|  分支: sprint/2026-06-04-01                                 |
+|  状态: running          启动: 2026-06-04 19:25              |
++============================================================+
+|                                                             |
+|  ✅ Phase -1   ISOLATE         3m                           |
+|  ✅ Phase -0.5 AUTO-ESTIMATE   1m                           |
+|  ✅ Phase 0    THINK           2m                           |
+|  ✅ Phase 1    PLAN            5m                           |
+|  🔄 Phase 2    BUILD           12m                          |
+|  ⬜ Phase 3    REVIEW          -                            |
+|  ⬜ Phase 4    USER ACCEPT     -                            |
+|  ⬜ Phase 5    FEEDBACK        -                            |
+|  ⬜ Phase 6    SHIP            -                            |
+|  ⬜ Phase 7    LAND            -                            |
+|  ⬜ Phase 8    CLEANUP         -                            |
+|                                                             |
+|  [████▓░░░░░░] 36%                                          |
++============================================================+
+|  > 当前: Phase 2 BUILD                                      |
+|    状态: running                                             |
+|                                                             |
+|  下一步: 等待构建完成                                        |
+|    ralph-loop 迭代中，完成后自动进入 Phase 3 REVIEW          |
++============================================================+
+|  输出物:                                                     |
+|    设计文档: .sprint-state/phase-outputs/design-doc.md       |
+|    评审报告: .sprint-state/delphi-reviewed.json              |
+|    规格说明: .sprint-state/phase-outputs/specification.yaml  |
++============================================================+
+```

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

@@ -1,10 +1,20 @@
 ---
 name: test-specification-alignment
-description: "测试与 Specification 对齐验证引擎。确保测试准确反映需求和设计。两阶段执行：Phase 1 验证对齐（可修改测试），Phase 2 执行测试（禁止修改测试）。MANDATORY before any release. TRIGGER: 'run tests', 'verify tests', before BUILD (TDD + review) Arbiter, before gstack-ship."
+description: "Use when asked to run tests, verify tests, align tests with specification.yaml, before BUILD verification, or before release/ship."
 ---
 
 # Test-Specification Alignment Engine
 
+## Workflow Steps
+
+1. **Load Phase 0** — Verify `specification.yaml` and `tests/` directory exist; BLOCK if missing with clear guidance to complete brainstorming → delphi-review → specification-generator flow first
+2. **Phase 1 Alignment (Modify Allowed)** — Parse specification.yaml (YAML) + test files (AST); validate alignment rules; generate alignment report; optionally fix tests to align with requirements; require score ≥80% to proceed
+3. **Coverage Mapping** — Map each REQ-* to at least one test case with `@test` annotation; map each AC-* to at least one assertion; verify test intent declarations (`@test`, `@intent`, `@covers` tags)
+4. **Pre-Phase 2 Freeze** — Invoke `/freeze` skill to lock test directories (`tests/`, `test/`, `__tests__/`, `*.test.ts`, `*.spec.ts`, `*_test.py`, etc.); return confirmation before proceeding
+5. **Phase 2 Execution (Frozen)** — Run all tests; Agent is BLOCKED from modifying/deleting/skipping tests; analyze failures into 4 categories: BUSINESS_CODE_ERROR, TEST_DATA_ERROR, SPECIFICATION_ERROR, ENVIRONMENT_ERROR; SPECIFICATION_ERROR requires ESCALATE_TO_HUMAN
+6. **Failure Classification** — For each failing test, output classification in mandatory format with Type, Test, Root Cause, Action fields; if SPECIFICATION_ERROR detected, offer user options (A: fix spec → re-Phase 1, B: confirm spec → modify code, C: clarify ambiguity)
+7. **JSON Report Output** — Generate alignment report as valid JSON with fields: `alignment_status` (PASS|FAIL|BLOCKED), `phase` (1|2), `score`, `misaligned_tests[]`, `anti_pattern_detected`, `errors[]`; Terminal State: ✅ ALL_TESTS_PASS
+
 ## 核心原则
 
 **测试是系统的防护网，也是系统的使用手册。测试必须准确反映原始需求和设计方案。**
@@ -37,6 +47,89 @@ Alignment report MUST be output as valid JSON:
 
 ---
 
+## Triggers
+
+### Automatic Triggers
+- BUILD (TDD + review) Round 1 after Driver outputs tests
+- Gate 1 verification before proceeding
+- gstack-ship release before deployment
+
+### Manual Triggers
+- `/test-specification-alignment` command
+- `/verify-tests` command
+- "run tests" phrase
+- "verify tests" phrase
+- before gstack-ship
+
+---
+
+## Scope
+
+### IN Scope
+- Validation of test alignment against `specification.yaml` (Requirements, User Stories, Acceptance Criteria)
+- Phase 1: Test modification to improve alignment (add missing tests, fix annotations, correct intent)
+- Phase 2: Test execution with frozen test files (no modifications allowed)
+- Failure classification into BUSINESS_CODE_ERROR, TEST_DATA_ERROR, SPECIFICATION_ERROR, ENVIRONMENT_ERROR
+- JSON report generation with alignment status, score, misaligned tests, and errors
+
+### OUT Scope
+- Modifying `specification.yaml` during Phase 2 (requires ESCALATE_TO_HUMAN)
+- Skipping or deleting tests to make tests pass
+- Modifying test assertions to force tests to pass
+- Business logic implementation (handled by BUILD phase)
+- Environment configuration issues (handled separately)
+
+### Boundaries
+- **Start**: After BUILD (TDD + review) Round 1 outputs tests
+- **End**: Terminal State ✅ ALL_TESTS_PASS or ESCALATE_TO_HUMAN for specification issues
+- **Inputs**: `specification.yaml`, `tests/` directory
+- **Outputs**: Alignment report (JSON), test execution report, failure classification
+
+---
+
+## Examples
+
+### Example 1: Normal Trigger (Should Execute)
+**User Input**: "run tests for login feature" or `/test-specification-alignment`
+
+**Expected Flow**:
+1. Load Phase 0: Check `specification.yaml` exists → ✅ Found
+2. Check `tests/` directory exists → ✅ Found
+3. Phase 1: Parse spec and tests → Alignment score 85% → ✅ Pass threshold
+4. Pre-Phase 2: Call `/freeze tests/` → ✅ Locked
+5. Phase 2: Run tests → 12 passed, 0 failed → ✅ ALL_TESTS_PASS
+6. Output JSON report with `alignment_status: "PASS"`, `phase: "2"`, `score: 85`
+7. Call `/unfreeze tests/` → ✅ Unlocked
+8. Terminal State: ✅ Test-specification-alignment complete
+
+---
+
+### Example 2: Should NOT Trigger (Missing Specification)
+**User Input**: "run tests" in a project without `specification.yaml`
+
+**Expected Flow**:
+1. Load Phase 0: Check `specification.yaml` exists → ❌ Not Found
+2. BLOCK with message:
+   ```
+   ❌ BLOCKED: specification.yaml 不存在
+
+   要生成 specification.yaml，请先完成需求流程：
+
+   流程步骤:
+   1. brainstorming      → 需求探索，生成设计文档
+   2. delphi-review      → 需求评审 (多轮直到 APPROVED)
+   3. spec 自动生成 (从 APPROVED 设计文档提取 specification.yaml)
+
+   为什么必须这样？
+   - 在 delphi-review APPROVED 后生成，避免设计文档修改时 spec 也需重新生成
+   - 遵循"问题发现越早修复成本越低"原则
+
+   请先完成上述流程，然后再运行 test-specification-alignment。
+   ```
+3. Terminal State: ❌ BLOCKED_MISSING_SPECIFICATION
+
+---
+
 ## 触发条件
 
 ### 自动触发
@@ -569,29 +662,6 @@ legacy_mode:
 
 ---
 
-## Qoder 平台适配
-
-### freeze 机制替代（替代 gstack/freeze skill）
-
-在 Qoder 环境中，freeze/unfreeze 通过 sprint-flow 的 **Pre-Edit Gate** 替代：
-- Phase 2 执行期间，orchestrator 禁止修改测试目录下的文件
-- 此约束通过 SKILL.md 指令强制执行（非物理阻断）
-- orchestrator 在每次文件编辑前检查：如果目标文件位于测试目录且当前处于 Phase 2 freeze 状态，则 **BLOCK**
-
-### Agent 配置适配
-
-| 原配置 | Qoder 替代 | 说明 |
-|---------|------------|------|
-| Phase 1 Agent (Qwen3.5-Plus) | **orchestrator 直接执行** | YAML 解析 + AST 解析由 orchestrator 内联完成 |
-| Phase 2 Agent (GLM-5) | **orchestrator 直接执行** | 测试执行由 orchestrator 通过 Bash 工具完成 |
-
-### Qoder 集成点
-
-- Phase 3 REVIEW 完成后，使用 genui `show_widget` 展示对齐报告摘要
-- 对齐分数记录通过 `UpdateMemory` 持久化（development_test_specification 类型）
-
----
-
 ## Anti-Patterns
 
 | 错误 | 正确 |
@@ -611,6 +681,10 @@ legacy_mode:
 |------|------|------|
 | V1.0 | 2026-04-06 | 初始设计 |
 | V2.0 | 2026-04-06 | Delphi Review 共识版本 |
+| V2.1 | 2026-06-02 | Added parser-friendly sections: Workflow Steps (7 steps), Triggers (5+ phrases), Scope (IN/OUT/Boundaries), Examples (2 scenarios) |
+
+---
+
 ## Output Format (MANDATORY)
 Alignment report MUST be output as valid JSON:
 ```json