@boyingliu01/xp-gate 0.18.4 → 0.19.0

package/plugins/claude-code/skills/sprint-flow/references/force-levels.md

@@ -2,12 +2,13 @@
 
 **执行时机**: Phase 2/6 DESIGN 之前，PREP AUTO-ESTIMATE 完成后。
 
-**目的**: 根据需求规模匹配适度评审流程，平衡质量保障与效率。
+**目的**: 根据需求规模调整上下文深度与迭代预算，平衡质量保障与效率。Force level 永远不改变专家数量或批准语义。
 
 **核心原则**:
 - 所有级别**必须经过 Delphi 评审**，不可跳过
-- 轻量级采用**简化 Delphi**（2 专家、1 轮），仍需 2/2 批准
-- 标准/复杂采用**完整 Delphi**（2-3 专家、多轮）
+- 所有级别都采用 architecture、technical、feasibility 三专家 Delphi；Round 1 独立执行并验证三份成功结果
+- 模型 ID、provider、vendor、gateway 和国籍不受限制；`requested_model` trimmed 后必须 distinct
+- 评审达到 ≥90% 共识，最多 5 轮；失败或无法验证时阻断
 - 自动升级机制：当出现风险信号时强制升级级别
 
 ---
@@ -16,9 +17,9 @@
 
 | 级别 | 适用场景 | 专家数 | 最多轮数 | 通过条件 | 预计耗时 |
 |------|---------|--------|---------|----------|---------|
-| **轻量** | 小改动、局部修改、删除代码 | 2 | 1 | 2/2 批准 | 10-20 分钟 |
-| **标准** | 常规功能开发、模块重构 | 2 | 2 | 2/2 批准 | 30-60 分钟 |
-| **复杂** | 核心模块、跨模块变更、新增架构 | 3 | 3 | 3/3 批准 | 1-2 小时 |
+| **轻量** | 小改动、局部修改、删除代码 | 3 | 1-5 | ≥90% 聚合共识 | 10-20 分钟 |
+| **标准** | 常规功能开发、模块重构 | 3 | 1-5 | ≥90% 聚合共识 | 30-60 分钟 |
+| **复杂** | 核心模块、跨模块变更、新增架构 | 3 | 1-5 | ≥90% 聚合共识 | 1-2 小时 |
 
 ---
 
@@ -26,9 +27,9 @@
 
 | 级别 | 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 | 多轮深度评审 |
+| **轻量** | 1 次（3 专家、最多 5 轮） | ~8,000 | 简化上下文，仍需完整执行 |
+| **标准** | 1-2 次（3 专家、最多 5 轮） | ~15,000-25,000 | 可能需要反馈轮次 |
+| **复杂** | 1-3 次（3 专家、最多 5 轮） | ~30,000-60,000 | 多轮深度评审 |
 
 > **成本计算依据**: 基于实际 Sprint 历史数据，假设每次 delphi-review 调用平均消耗 8,000-10,000 Token（含 3 位专家的输入输出）。
 
@@ -56,7 +57,7 @@
 | 触发条件 | 原级别 | 升级至 | 说明 |
 |---------|--------|--------|------|
 | Delphi 评审出现 REQUEST_CHANGES | 轻量 | 标准 | 需要第二轮评审 |
-| 专家意见分歧（1 票反对） | 轻量/标准 | 复杂 | 需要第 3 专家仲裁 |
+| 专家意见分歧 | 轻量/标准 | 复杂 | 增加上下文深度与后续轮次预算，不增加或替换专家 |
 | 涉及公共 API 变更 | 轻量 | 标准 | 影响外部调用方 |
 | 修改文件数 > 5 或 LOC > 200 | 轻量 | 标准 | 改动规模超出轻量范围 |
 | 存在循环依赖 | 轻量/标准 | 复杂 | 架构风险高 |
@@ -81,10 +82,10 @@ 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 轮 + 架构评审 |
+| 引用计数 ≤ 3 + 跨模块 ≤ 1 | 轻量 | 3 专家、最多 5 轮 Delphi |
+| 引用计数 4-10 或 跨模块 2 | 标准 | 3 专家、最多 5 轮 Delphi |
+| 引用计数 > 10 或 跨模块 ≥ 3 | 复杂 | 3 专家、最多 5 轮 Delphi |
+| 存在循环依赖 | 强制复杂 | 3 专家、最多 5 轮 + 架构评审 |
 
 **关键区别**:
 - AUTO-ESTIMATE: **客观指标分析**（代码结构、引用计数）
@@ -100,15 +101,15 @@ AUTO-ESTIMATE 输出 → Force Levels 执行 → 自动升级机制（如触发
 |------|------------|-------------|
 | Phase 2/6 DESIGN 设计评审 | 3 专家、≥90% 共识、生成 specification.yaml | 不适用（设计阶段） |
 | Phase 3/6 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 轮、写入门禁文件 |
+| 轻量级评审 | 生成 `delphi-reviewed.json`（3 专家、最多 5 轮、≥90% 聚合共识） | 3 专家、最多 5 轮、写入门禁文件 |
+| 标准级评审 | 生成 `delphi-reviewed.json`（3 专家、最多 5 轮、≥90% 聚合共识） | 3 专家、最多 5 轮、写入门禁文件 |
+| 复杂级评审 | 生成 `delphi-reviewed.json`（3 专家、最多 5 轮、≥90% 聚合共识） | 3 专家、最多 5 轮、写入门禁文件 |
 | Phase 4/6 VERIFY 代码走查 | 再次检查 `delphi-reviewed.json` 或重新评审 | 复用 Force Levels 规则 |
 
 **关键规则**:
 - **DELPHI-GATE 永不跳过**：Phase 3/6 BUILD 入口必须检查 `.sprint-state/delphi-reviewed.json` 中 `verdict=APPROVED`
-- **Force Levels 定义评审强度**：轻量/标准/复杂决定用 2 专家 1 轮还是 3 专家 3 轮来**产生**门禁文件
-- **轻量级不是跳过评审**：而是简化流程（2 专家、1 轮），但仍需生成门禁文件
+- **Force Levels 定义上下文强度**：所有级别都用三专家、distinct model IDs 和最多 5 轮来**产生**门禁文件
+- **轻量级不是跳过评审**：只缩短上下文，不减少专家或共识验证
 - **LIGHTWEIGHT ≠ ONE-EXPERT**: 1 专家违反 Delphi 核心原则，禁止
 
 ---
@@ -122,9 +123,9 @@ AUTO-ESTIMATE 输出 → Force Levels 执行 → 自动升级机制（如触发
 - 无循环依赖
 
 **执行流程**:
-1. 2 位专家独立评审（DeepSeek-v4-pro + Kimi-K2.6）
-2. 单轮评审，无需多轮迭代
-3. **2/2 批准**才通过（不允许 1/2 批准）
+1. 三位专家独立评审并验证 distinct requested_model
+2. 最多 5 轮迭代，直到达到 ≥90% 聚合共识
+3. 三份成功结果且 APPROVED 才通过
 4. 评审通过后写入 `.sprint-state/delphi-reviewed.json`
 
 **输出文件** (`.sprint-state/delphi-reviewed.json`):
@@ -133,13 +134,14 @@ AUTO-ESTIMATE 输出 → Force Levels 执行 → 自动升级机制（如触发
   "sprint_id": "sprint-2026-06-05-01",
   "level": "轻量",
   "delphi_review": {
-    "experts": ["deepseek-v4-pro", "kimi-k2.6"],
+    "experts": ["architecture-model", "technical-model", "feasibility-model"],
     "rounds": 1,
     "votes": {
       "expert_a": "APPROVED",
-      "expert_b": "APPROVED"
+      "expert_b": "APPROVED",
+      "expert_c": "APPROVED"
     },
-    "consensus": "2/2 APPROVED",
+    "consensus": ">=90% APPROVED",
     "timestamp": "2026-06-05T10:30:00Z"
   },
   "status": "passed"
@@ -161,13 +163,13 @@ AUTO-ESTIMATE 输出 → Force Levels 执行 → 自动升级机制（如触发
 - 中等规模改动（5-15 个文件、200-500 行改动）
 
 **执行流程**:
-1. 2 位专家独立评审（Round 1）
-2. 如有 REQUEST_CHANGES，进入 Round 2（最多 2 轮）
-3. **2/2 批准**才通过
+1. 三位专家独立评审（Round 1）
+2. 如有 REQUEST_CHANGES，继续后续轮次（最多 5 轮）
+3. 三份成功结果聚合达到 ≥90% 才通过
 4. 评审通过后写入 `.sprint-state/delphi-reviewed.json`
 
 **升级至复杂级条件**:
-- Round 2 仍有分歧（1 票反对）→ 升级至复杂级（第 3 专家仲裁）
+- Round 5 仍未达到共识 → BLOCK，不能以仲裁或多数票绕过
 - 涉及核心模块（core/handlers）→ 升级至复杂级
 - 存在循环依赖 → 升级至复杂级
 
@@ -182,14 +184,14 @@ AUTO-ESTIMATE 输出 → Force Levels 执行 → 自动升级机制（如触发
 - 公共 API 重大变更
 
 **执行流程**:
-1. 3 位专家独立评审（DeepSeek-v4-pro + Kimi-K2.6 + Qwen3.6-Plus）
-2. 最多 3 轮评审（Round 1-3）
-3. **3/3 批准**才通过
+1. architecture、technical、feasibility 三位专家使用用户配置的任意可执行模型独立评审
+2. 最多 5 轮评审
+3. 三份成功结果聚合达到 ≥90% 且全部 APPROVED 才通过
 4. 评审通过后写入 `.sprint-state/delphi-reviewed.json`
 
-**仲裁机制**:
-- Round 2 仍有分歧 → 第 3 专家（Qwen3.6-Plus）加入仲裁
-- Round 3 必须达成一致，否则 BLOCK 进入 Phase 3/6 BUILD
+**分歧处理**:
+- 每轮都保持同一组 architecture、technical、feasibility 三个角色，不新增仲裁者，也不减少执行
+- Round 5 仍未达到批准共识时 BLOCK 进入 Phase 3/6 BUILD
 
 ---
 

package/plugins/claude-code/skills/sprint-flow/references/orchestration-rules.md

@@ -50,7 +50,7 @@
 
 **Phase 2/6 DESIGN 执行模式（全部 orchestrator 直接执行）**：
 1. **Orchestrator 直接执行 grill-with-docs**：`skill(name="grill-with-docs")` → 访谈 + CONTEXT.md/ADR
-2. **Orchestrator 执行 R1 需求评审**：`npx xp-gate delphi-review --mode requirements` → requirements-reviewed.json
+2. **Orchestrator 调用 R1 Agent skill**：`/delphi-review --mode requirements`，分别执行 architecture、technical、feasibility 三个 per-expert runner → requirements-reviewed.json
 3. **Orchestrator 生成设计文档** → 等待用户 APPROVED
 4. **Orchestrator 直接执行 batch-grill-me**：`skill(name="batch-grill-me")` → 批量决策确认
 5. **Orchestrator 直接执行 R2 delphi-review**：`skill(name="delphi-review")` → 等待 APPROVED

package/plugins/claude-code/skills/sprint-flow/references/phase-1-prep.md

@@ -216,7 +216,7 @@ find . -name "*{target}*.test.*" -o -name "*{target}*.spec.*" | grep -v node_mod
 
 **DELPHI-GATE invariant**: 所有流程级别（轻量/标准/复杂）的 Phase 3/6 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 的轻量级流程定义。
+**轻量级的正确理解**: 轻量级意味着 reduced-intensity 的 delphi-review（**3 专家、最多 5 轮、≥90% 聚合共识、较短上下文**），**不是**跳过 delphi-review，**不是**减少专家或模型执行。见 references/force-levels.md 的轻量级流程定义。
 
 **自动 escalation 规则**（检测到以下情况时，自动提升流程级别）:
 

package/plugins/claude-code/skills/sprint-flow/references/phase-2-design.md

@@ -59,13 +59,15 @@ grill-with-docs 执行：
 grill 访谈达成共享理解后（或 CONTEXT.md 快速路径下读取已有上下文后）、设计文档生成前，调用需求评审：
 
 ```
-npx xp-gate delphi-review --mode requirements
+/delphi-review --mode requirements
 ```
 
-**评审配置**（轻量）：
+这是 Agent skill 调用，不是 `xp-gate` npm CLI 子命令。Skill orchestrator 必须分别调用 per-expert runner 三次，每次保留 `--expert <architecture|technical|feasibility> --mode requirements`，再聚合三份结果；禁止用一个 runner 进程执行全部模型。
+
+**评审配置**：
 - 复用现有 3 专家（architecture/feasibility/technical），`--mode requirements` 切换评审焦点提示词
-- 轻量配置：2 专家、1 轮
-- lightweight sprint（`change_type == "修改已存在代码"`）：跳过 R1，需求评审合并入 R2
+- 所有路径固定使用 3 专家，Round 1 独立执行并验证 distinct model IDs，最多 5 轮
+- force level 只调整上下文深度与迭代预算；所有路径都执行 R1，不减少专家数
 
 **评审焦点**：
 - 用户场景遗漏
@@ -81,8 +83,16 @@ npx xp-gate delphi-review --mode requirements
 {
   "verdict": "APPROVED | GAPS_FOUND",
   "timestamp": "<ISO 8601>",
-  "requirements_hash": "<SHA-256 of 需求陈述 + CONTEXT.md 内容>",
-  "experts": 2,
+  "requirements_statement": "<被评审的原始需求陈述>",
+  "context_file_used": "CONTEXT.md | null",
+  "requirements_hash": "<SHA-256 of requirements_statement + context file exact UTF-8 content if used + timestamp YYYY-MM-DD>",
+  "head_commit": "<git rev-parse HEAD>",
+  "consensus_ratio": 1.0,
+  "expert_verdicts": [
+    { "role": "architecture", "verdict": "APPROVED", "result_type": "delphi_expert_result", "requested_model": "provider/model-a" },
+    { "role": "technical", "verdict": "APPROVED", "result_type": "delphi_expert_result", "requested_model": "provider/model-b" },
+    { "role": "feasibility", "verdict": "APPROVED", "result_type": "delphi_expert_result", "requested_model": "provider/model-c" }
+  ],
   "rounds": 1,
   "gaps": []
 }
@@ -90,10 +100,10 @@ npx xp-gate delphi-review --mode requirements
 
 **GAPS_FOUND 处理**：
 - 回到 Step 1 补充访谈（或补充 CONTEXT.md 内容）
-- 最多 2 轮循环后升级给用户决策
+- 最多 5 轮循环后升级给用户决策
 
 **程序化校验**：
-- `phase-transition 2 completed` 校验该文件存在、`verdict=APPROVED` 且 `requirements_hash` 匹配当前需求内容
+- `phase-transition 2 completed` 校验 schema-v2 必填字段、`verdict=APPROVED`、三份专家证据、`consensus_ratio`、当前 HEAD，并从需求陈述、可选 context 文件和 timestamp 日期重新计算 `requirements_hash`
 - 不匹配 → BLOCK（防陈旧绑定）
 
 ### Step 3: 原生设计文档生成
@@ -125,7 +135,7 @@ orchestrator 基于访谈记录 + CONTEXT.md + R1 评审结论生成设计文档
 
 | 暂停点 | 触发条件 | 用户操作 | 自动恢复条件 |
 |--------|---------|---------|-------------|
-| R1 GAPS_FOUND | 需求评审发现缺口 | 补充访谈/上下文 | 重新 R1 评审（最多 2 轮） |
+| R1 GAPS_FOUND | 需求评审发现缺口 | 补充访谈/上下文 | 重新 R1 评审（最多 5 轮） |
 | **HARD-GATE** | 设计文档未 APPROVED | 用户审批设计文档 | 设计 APPROVED 后自动进入 Part B |
 
 ### 输出
@@ -149,7 +159,7 @@ orchestrator 基于访谈记录 + CONTEXT.md + R1 评审结论生成设计文档
 
 IF change_type == "修改已存在代码":
   → 增量优化路径: SKIP batch-grill-me
-  → 直接进入 Step 7: lightweight R2 delphi-review (2 专家, 1 轮)
+   → 直接进入 Step 7: R2 delphi-review（3 专家，最多 5 轮）
 ELSE (change_type == "新增功能" 或 未定义):
   → 标准路径: 继续 Step 6 (batch-grill-me) → Step 7
 ```
@@ -158,7 +168,7 @@ ELSE (change_type == "新增功能" 或 未定义):
 
 | change_type | batch-grill-me | R2 delphi-review |
 |------------|----------------|------------------|
-| `修改已存在代码` | ❌ SKIP | lightweight (2 专家, 1 轮) |
+| `修改已存在代码` | ❌ SKIP | 3 专家，最多 5 轮 |
 | `新增功能` | ✅ 执行 | 标准 (3 专家) |
 | `undefined` / 缺失 | ✅ 执行 | 标准 (3 专家) |
 
@@ -183,12 +193,12 @@ batch-grill-me 替代 autoplan 的 taste_decisions 功能：
 # 标准路径（3 专家）
 skill(name="delphi-review", user_message="[设计文档 + batch-grill-me 决策结果]")
 
-# 增量优化路径（2 专家, 1 轮 — 来自 Step 5 路由）
-skill(name="delphi-review", user_message="[设计文档]", experts=2, max_rounds=1)
+# 增量优化路径（3 专家，最多 5 轮）
+skill(name="delphi-review", user_message="[设计文档]", experts=3, max_rounds=5)
 ```
 
 - **标准路径**: Round 1: 3 专家匿名独立评审 → Round 2+: 交换意见直到共识
-- **增量优化路径**: 2 专家, 1 轮
+- **增量优化路径**: 3 专家，最多 5 轮
 - ≥90% 共识 + APPROVED 才通过
 - 输出: APPROVED / REQUEST_CHANGES
 

package/plugins/claude-code/skills/sprint-flow/references/phase-4-verify.md

@@ -18,7 +18,7 @@ Web 前端项目额外增加：原生 UI 审查 + 可选增强。
 ### 调用 Skills
 
 **所有项目（原生 HARD-GATE 链）**:
-- `delphi-review --mode code-walkthrough` — 多专家匿名代码走查（2-3 domestic models, ≥90% consensus）
+- `delphi-review --mode code-walkthrough` — 三位专家匿名代码走查，验证三个 distinct requested_model 并聚合 ≥90% consensus
 - `test-specification-alignment` — 测试与 Spec 对齐验证（#367 程序化 HARD-GATE）
 - `xp-gate check --all` — 全量质量门禁（Gate 0–9，含安全审计）
 
@@ -50,11 +50,11 @@ ELSE → SKIP 并记录 "[sprint-flow] 浏览器验证 SKIP（无可用浏览器
 skill(name="delphi-review", user_message="--mode code-walkthrough")
 ```
 
-- 2-3 位国内模型专家匿名独立评审（DeepSeek-v4-pro + Kimi-K2.6 + Qwen3.6-Plus）
-- Round 1: 匿名独立评审（防止 anchoring bias）
-- Round 2: 交换意见，响应关切
-- Round 3: 最终立场（如需）
-- ≥90% 共识 + APPROVED 才通过
+- architecture、technical、feasibility 三位专家匿名独立评审，模型 ID 必须 distinct
+- Round 1: 三位专家独立执行，输出 `result_type=delphi_expert_result`
+- 验证三份成功结果和三个 distinct requested_model 后再聚合
+- 后续轮次最多到 Round 5，≥90% 共识 + APPROVED 才通过
+- 任一失败或模型重复都阻断，不降级为少数专家
 
 **如果 REQUEST_CHANGES**: 暂停等待用户处理 → 修复后重新评审。**如果 APPROVED**: 写入 `.code-walkthrough-result.json`（1 小时有效期）→ 进入 Step 2。
 

package/plugins/claude-code/skills/sprint-flow/references/phase-overview.md

@@ -36,7 +36,7 @@ Sprint Flow is NOT just a sequential launcher of existing skills. Here's what ma
 
 1. **40-67% Token Savings via Ralph Loop**: Phase 3 BUILD default (`ralph-loop`) processes one REQ at a time with clean context, avoiding the linear context accumulation that costs 150K+ tokens in parallel mode.
 
-2. **HARD-GATE Discipline**: Design must pass Delphi review (≥90% consensus, ≥2 model providers, domestic models only) before Phase 3 BUILD can start. This is enforced both in SKILL.md instructions and via the Claude Code plugin's PreToolUse hook.
+2. **HARD-GATE Discipline**: Design must pass Delphi review with all three expert roles executed successfully, three distinct requested model IDs verified, and ≥90% aggregate consensus within five rounds before Phase 3 BUILD can start. This is enforced both in SKILL.md instructions and via the Claude Code plugin's PreToolUse hook.
 
 3. **Emergent Requirements Acknowledgment**: Based on research showing 78% of failures are invisible to AI (arXiv study), Phase 6 CLOSE includes mandatory manual UAT verification — cannot be automated, skipped, or bypassed.
 
@@ -155,7 +155,7 @@ Sprint Flow: PREP → DESIGN → BUILD → VERIFY → SHIP → CLOSE
 **快速参考**:
 - **Step 0: CONTEXT.md 预检 (#322)**: 存在则 SKIP grill 访谈，但 R1 需求评审仍执行（CONTEXT.md 可能陈旧）
 - **Step 1: grill-with-docs** — `skill(name="grill-with-docs")` — 逐个追问 + CONTEXT.md/ADR 沉淀。**HARD-GATE**: 设计未批准 → 不可进入实现
-- **Step 2: R1 需求评审 (#368)** — `npx xp-gate delphi-review --mode requirements` — 轻量 2 专家 1 轮，输出 requirements-reviewed.json（含 requirements_hash 防陈旧绑定）。lightweight sprint 跳过 R1 合并入 R2
+- **Step 2: R1 需求评审 (#368)** — `/delphi-review --mode requirements` Agent skill — 所有路径都由三专家独立执行，验证 distinct model IDs 后聚合 ≥90% 共识，输出 requirements-reviewed.json（含可重新计算的 requirements_hash 与 exact-HEAD 防陈旧绑定）
 - **Step 3: 原生设计文档生成** — `docs/plans/YYYY-MM-DD-<topic>-design.md`（需求摘要、2-3 方案、推荐、成功标准）
 - **Step 4: HARD-GATE APPROVAL** — 用户审批设计文档
 - **Step 5: 路由分叉** — `change_type == "修改已存在代码"` → SKIP batch-grill-me, lightweight R2

package/plugins/claude-code/skills/test-specification-alignment/AGENTS.md

@@ -1,9 +1,9 @@
 # SKILLS/TEST-SPECIFICATION-ALIGNMENT KNOWLEDGE BASE
 
-**Generated:** 2026-07-29
-**Commit:** 527fca8
-**Branch:** main
-**Version:** 0.18.3.0
+**Generated:** 2026-08-24
+**Commit:** a1a4683
+**Branch:** dsh-plugin
+**Version:** 0.19.0.0
 
 ## OVERVIEW
 Test-Specification Alignment Engine — two-stage validation ensuring tests accurately reflect requirements and design specs.

package/plugins/dsh/README.md

@@ -0,0 +1,25 @@
+# @boyingliu01/dsh-plugin-xp-gate
+
+XP-Gate deterministic quality gates + AI workflow skills as a **DeepSeek Harness (DSH)** native plugin.
+
+## Tools
+
+| Tool | Purpose |
+|------|---------|
+| `gate-check` | Run XP-Gate quality gates (`xp-gate check`) on a file or directory |
+| `gate-principles` | Run the 14 Clean Code/SOLID rules (`xp-gate principles`, Gate 4) |
+| `gate-arch` | Run architecture validation (`xp-gate arch`, Gate 6) |
+
+## Install
+
+```bash
+dsh plugin --profile <name> add @boyingliu01/dsh-plugin-xp-gate
+```
+
+The tools require a global `xp-gate` CLI:
+
+```bash
+npm install -g @boyingliu01/xp-gate
+```
+
+When `xp-gate` is missing the tools degrade gracefully (tool-missing → SKIP-style message) rather than erroring.

package/plugins/dsh/cordis.patch.yml

@@ -0,0 +1,7 @@
+# XP-Gate DSH bundle patch: mounts the xp-gate tool plugin into a dsh profile.
+# Applied as ONE insert over the empty profile root; reconciled by
+# `dsh plugin add @boyingliu01/dsh-plugin-xp-gate`.
+
+- insert:
+    - id: tool-xp-gate
+      name: '@boyingliu01/dsh-plugin-xp-gate'

package/plugins/dsh/package.json

@@ -0,0 +1,70 @@
+{
+  "name": "@boyingliu01/dsh-plugin-xp-gate",
+  "version": "0.19.0",
+  "description": "XP-Gate deterministic quality gates + AI workflow skills as a DeepSeek Harness (DSH) native plugin: gate-check / gate-principles / gate-arch tools + 12 SKILL.md skills",
+  "type": "module",
+  "main": "./lib/index.js",
+  "types": "./lib/index.d.ts",
+  "exports": {
+    ".": {
+      "types": "./lib/index.d.ts",
+      "import": "./lib/index.js",
+      "default": "./lib/index.js"
+    },
+    "./package.json": "./package.json"
+  },
+  "repository": {
+    "type": "git",
+    "url": "https://github.com/boyingliu01/xp-gate",
+    "directory": "plugins/dsh"
+  },
+  "dsh": {
+    "bundle": {
+      "patch": "./cordis.patch.yml"
+    }
+  },
+  "publishConfig": {
+    "registry": "https://registry.npmjs.org",
+    "access": "public"
+  },
+  "files": [
+    "lib/",
+    "cordis.patch.yml",
+    "skills/",
+    "README.md"
+  ],
+  "scripts": {
+    "build": "tsc -p tsconfig.build.json",
+    "check": "tsc -p tsconfig.json",
+    "test": "vitest run",
+    "prepare-skills": "node scripts/prepack.cjs",
+    "prepack": "npm run build && npm run prepare-skills"
+  },
+  "peerDependencies": {
+    "@deepseek-ai/cordis": "^4.0.1",
+    "@deepseek-ai/dsh-llm": "^0.1.1-rc.2",
+    "@deepseek-ai/dsh-shell": "^0.1.1-rc.2",
+    "@deepseek-ai/dsh-tools": "^0.1.1-rc.2"
+  },
+  "devDependencies": {
+    "@deepseek-ai/cordis": "4.0.1",
+    "@deepseek-ai/dsh-llm": "0.1.1-rc.2",
+    "@deepseek-ai/dsh-shell": "0.1.1-rc.2",
+    "@deepseek-ai/dsh-tools": "0.1.1-rc.2",
+    "@types/node": "^25.6.0",
+    "typescript": "^5.9.3",
+    "vitest": "^1.6.1",
+    "yaml": "^2.9.0"
+  },
+  "keywords": [
+    "dsh",
+    "deepseek-harness",
+    "plugin",
+    "xp-gate",
+    "quality-gates",
+    "code-review",
+    "sprint-flow"
+  ],
+  "author": "boyingliu01",
+  "license": "MIT"
+}

package/plugins/dsh/scripts/prepack.cjs

@@ -0,0 +1,82 @@
+#!/usr/bin/env node
+'use strict';
+
+/**
+ * prepack.cjs — Bundle the 12 repo skills into @boyingliu01/dsh-plugin-xp-gate
+ * before npm publish.
+ *
+ * Skills live in repo-root `skills/`; `plugins/dsh/skills/` is gitignored and
+ * populated here so the published tarball is self-contained (mirrors
+ * plugins/opencode/scripts/prepack.cjs).
+ */
+
+const fs = require('fs');
+const path = require('path');
+
+const PLUGIN_ROOT = path.resolve(__dirname, '..');
+const REPO_ROOT = path.resolve(PLUGIN_ROOT, '..', '..');
+
+const SKILLS = [
+  'admin-template-guidelines',
+  'batch-grill-me',
+  'delphi-review',
+  'domain-modeling',
+  'grilling',
+  'grill-with-docs',
+  'improve-codebase-architecture',
+  'ralph-loop',
+  'sprint-flow',
+  'test-driven-development',
+  'test-specification-alignment',
+  'to-issues',
+];
+
+const SKIP_DIRS = new Set(['node_modules', '.git', 'dist', 'coverage']);
+const SKIP_FILE_SUFFIXES = ['.lock', '.js.map'];
+
+function shouldSkipFile(name) {
+  return SKIP_FILE_SUFFIXES.some((suffix) => name.endsWith(suffix));
+}
+
+function copyDir(src, dest) {
+  if (!fs.existsSync(src)) {
+    console.error(`[prepack] SKIP (missing): ${src}`);
+    return false;
+  }
+  fs.mkdirSync(dest, { recursive: true });
+  for (const entry of fs.readdirSync(src, { withFileTypes: true })) {
+    if (SKIP_DIRS.has(entry.name)) continue;
+    const srcPath = path.join(src, entry.name);
+    const destPath = path.join(dest, entry.name);
+    if (entry.isDirectory()) {
+      copyDir(srcPath, destPath);
+    } else if (entry.isFile()) {
+      if (shouldSkipFile(entry.name)) continue;
+      fs.copyFileSync(srcPath, destPath);
+    }
+  }
+  return true;
+}
+
+function main() {
+  const skillsDest = path.join(PLUGIN_ROOT, 'skills');
+  fs.rmSync(skillsDest, { recursive: true, force: true });
+  fs.mkdirSync(skillsDest, { recursive: true });
+
+  let copied = 0;
+  for (const name of SKILLS) {
+    if (copyDir(path.join(REPO_ROOT, 'skills', name), path.join(skillsDest, name))) {
+      copied += 1;
+      console.error(`[prepack] skills/${name}`);
+    }
+  }
+
+  if (copied !== SKILLS.length) {
+    console.error(`[prepack] ERROR: expected ${SKILLS.length} skills, copied ${copied}`);
+    process.exit(1);
+  }
+
+  console.error(`[prepack] done: ${copied} skills bundled`);
+}
+
+main();

package/plugins/dsh/skills/admin-template-guidelines/SKILL.md

@@ -0,0 +1,113 @@
+---
+name: admin-template-guidelines
+description: "6 maintainability rules for AI-generated admin interfaces (Fastify + Nunjucks + HTMX + Alpine.js). Prevents route bloat, test inconsistency, Nunjucks traps, repeated data logic, auth blind spots, and HTMX/Alpine confusion."
+maturity: alpha
+---
+
+# Admin Template Guidelines
+
+6 maintainability rules distilled from real rework patterns in interview-bot admin interface development. These constraints MUST be enforced during sprint-flow BUILD phase when generating admin routes, views, or tests.
+
+## 核心原则
+
+| 原则 | 说明 |
+|------|------|
+| **路由拆分** | Admin routes 按模块拆分，禁止单文件膨胀 |
+| **测试一致性** | 所有测试使用共享 `createAdminTestApp()` helper |
+| **Nunjucks 括号** | 比较表达式与 filter 混用时必须加括号 |
+| **View Model Mapper** | 重复数据转换提取为独立函数 |
+| **Auth 保护** | 所有 Admin 路由（含 GET）必须认证 |
+| **HTMX+Alpine 分离** | HTMX 管服务端交互，Alpine 管客户端状态 |
+
+---
+
+## 规则 1: 路由拆分（Route Splitting）
+
+**Constraint:** Admin routes MUST be split by module — never a single monolithic file.
+
+### 模块划分
+
+| 文件 | 职责 |
+|------|------|
+| `admin/routes/templates.ts` | 模板 CRUD（列表/创建/编辑/删除） |
+| `admin/routes/plans.ts` | 访谈计划管理（创建/启动/暂停/完结） |
+| `admin/routes/reports.ts` | 报告生成与导出 |
+| `admin/routes/analytics.ts` | 数据统计与看板 |
+| `admin/routes/tree.ts` | 技能树/目录管理 |
+| `admin/routes/admin-shared.ts` | 共享中间件、通用 helper、布局渲染 |
+
+**Examples:** → see `references/rule-1.md`
+
+---
+
+## 规则 2: 测试一致性（Test Consistency）
+
+**Constraint:** All admin route tests MUST use a shared `createAdminTestApp()` helper — never hand-roll mini Fastify instances per test file.
+
+**Examples:** → see `references/rule-2.md`
+
+---
+
+## 规则 3: Nunjucks 括号陷阱（Nunjucks Parentheses）
+
+**Constraint:** Comparison expressions in Nunjucks MUST be wrapped in parentheses when used with filters. The Nunjucks filter operator (`|`) has **higher precedence** than comparison operators, causing silent incorrect output.
+
+**Examples & Checklist:** → see `references/rule-3.md`
+
+---
+
+## 规则 4: View Model Mapper
+
+**Constraint:** Repeated data transformation patterns MUST be extracted into dedicated functions. Any data mapping, filtering, or calculation that appears in 3+ route handlers must live in a shared `view-models.ts` module.
+
+### 常见重复模式
+
+| 模式 | 出现位置 | 提取函数 |
+|------|----------|----------|
+| `_count` → `totalCount` 映射 | templates.ts, plans.ts, reports.ts | `mapCountFields()` |
+| COMPLETED 状态过滤 | plans.ts, reports.ts, analytics.ts | `filterCompletedPlans()` |
+| 完成率计算 | plans.ts, analytics.ts, tree.ts | `calculateCompletionRate()` |
+| 完整 ViewModel 转换 | 所有列表页路由 | `mapTemplateToViewModel()` |
+
+**Examples:** → see `references/rule-4.md`
+
+---
+
+## 规则 5: Auth 保护（Auth Protection）
+
+**Constraint:** ALL Admin routes MUST be protected by authentication — including GET routes. No admin endpoint is exempt. Prefer cookie/session validation over API key headers.
+
+### 路由豁免规则
+
+| 路由类型 | 需要 Auth | 说明 |
+|----------|-----------|------|
+| Admin GET | ✅ 必须 | 管理页面包含敏感数据 |
+| Admin POST/PUT/DELETE | ✅ 必须 | 数据变更操作 |
+| Admin API (HTMX endpoints) | ✅ 必须 | 部分更新接口 |
+| Public GET | ❌ 不需要 | 面向用户的公开页面 |
+
+**Examples:** → see `references/rule-5.md`
+
+---
+
+## 规则 6: HTMX + Alpine 分离
+
+**Constraint:** Clear separation of concerns between HTMX (server-driven content replacement) and Alpine.js (client-side UI state). HTMX handles server interactions; Alpine handles local component state.
+
+### 职责矩阵
+
+| 功能 | HTMX | Alpine.js |
+|------|------|-----------|
+| 页面导航 / URL 变更 | ✅ | ❌ |
+| 表单提交到服务端 | ✅ | ❌ |
+| 列表分页/搜索/排序 | ✅ | ❌ |
+| 局部内容替换（`hx-target`） | ✅ | ❌ |
+| 下拉菜单开关 | ❌ | ✅ |
+| Modal 显示/隐藏 | ❌ | ✅ |
+| 表单字段即时验证 | ❌ | ✅ |
+| Toast 通知本地状态 | ❌ | ✅ |
+| 按钮 loading 状态切换 | ❌ | ✅ |
+
+**Examples & Principles:** → see `references/rule-6.md`
+
+