@boyingliu01/xp-gate 0.14.31 → 0.15.0

package/plugins/opencode/skills/delphi-review/AGENTS.md

@@ -1,9 +1,9 @@
 # SKILLS/DELPHI-REVIEW KNOWLEDGE BASE
 
-**Generated:** 2026-07-22
-**Commit:** 18b636a
+**Generated:** 2026-07-23
+**Commit:** 1d581aa
 **Branch:** main
-**Version:** 0.14.31.0
+**Version:** 0.15.0.0
 
 ## OVERVIEW
 Delphi Consensus Review — multi-round anonymous expert review (≥90% threshold, 3 experts from ≥2 providers, domestic models only). Supports design + code-walkthrough modes.

package/plugins/opencode/skills/sprint-flow/AGENTS.md

@@ -1,9 +1,9 @@
 # SKILLS/SPRINT-FLOW KNOWLEDGE BASE
 
-**Generated:** 2026-07-22
-**Commit:** 18b636a
+**Generated:** 2026-07-23
+**Commit:** 1d581aa
 **Branch:** main
-**Version:** 0.14.31.0
+**Version:** 0.15.0.0
 
 ## OVERVIEW
 **6-phase** development pipeline (v2.0 compact redesign, Issue #290): PREP → DESIGN → BUILD → VERIFY → SHIP → CLOSE. Phase 3/6 BUILD default build mode is **ralph-loop** (REQ-level iteration, 40-67% token savings vs parallel). HARD-GATE between DESIGN (2/6) and BUILD (3/6): design must pass Delphi review (≥90% consensus) before any coding.

package/plugins/opencode/skills/sprint-flow/SKILL.md

@@ -269,6 +269,7 @@ next_phase_context: [key info for next phase]
 | Clean up CLOSE without backing up sprint-state first | `.sprint-state/` is inside worktree; it's lost on worktree removal. CLOSE step 1 MUST back up to repo-tracked path first |
 | Keep adding random changes after verification failures | Max 3 fix cycles; if still failing, BLOCK and request user decision |
 | Enter next phase without generating Phase Summary | Every phase MUST write `.sprint-state/phase-outputs/phase-{N}-summary.md` and pass transition gate |
+| Complete implementation change without running verification | After every file edit/refactor/feature, MUST run `npm test` + `npm run lint` + `npx tsc --noEmit` and record the structured verification event (see `phase-3-build.md` §In-Session Verification) |
 
 ---
 

package/plugins/opencode/skills/sprint-flow/references/phase-3-build.md

@@ -144,6 +144,77 @@ This enforcement is instructional (LLM follows SKILL.md instructions), not progr
 
 ---
 
+## In-Session Verification (MANDATORY — v0.14.31+)
+
+**Purpose**: Ensure every implementation change is immediately verified and recorded, enabling Better Loop Harness (and other observability tools) to capture normalized change→validation event pairs.
+
+**Problem it solves**: Without explicit in-session verification, Agents may edit files and move on without running tests or linters. This creates unverified changes that are invisible to post-hoc review tools, breaking the traceability chain between "what changed" and "was it validated".
+
+### Mandatory Verification Protocol
+
+After **every** implementation change (file edit, refactor, new feature, bug fix), the Agent MUST execute the following sequence BEFORE claiming the change is complete:
+
+1. **Run tests**: `npm test` or `npx vitest run` (or project-specific test command)
+2. **Run linter**: `npm run lint` or `npx eslint .` (or project-specific lint command)
+3. **Type-check** (TypeScript projects): `npx tsc --noEmit`
+4. **Record the result**: Append a structured verification event (see format below)
+
+### Verification Event Format
+
+Each verification event MUST be recorded as a structured JSON object. Agents should output this to stdout or append to `.sprint-state/phase-outputs/verification-events.jsonl`:
+
+```json
+{
+  "timestamp": "2026-07-22T10:30:00Z",
+  "change": {
+    "type": "edit|refactor|feature|bugfix",
+    "files": ["src/lib/auth.ts", "src/lib/auth.test.ts"],
+    "description": "Implement validateToken() for expired token handling"
+  },
+  "verification": {
+    "tests": { "command": "npx vitest run src/lib/auth.test.ts", "status": "pass|fail", "summary": "4 passed, 0 failed" },
+    "lint": { "command": "npm run lint", "status": "pass|fail|warn", "summary": "0 errors, 2 warnings" },
+    "typecheck": { "command": "npx tsc --noEmit", "status": "pass|fail|skip", "summary": "No type errors" }
+  },
+  "outcome": "verified|failed|partial",
+  "req": "REQ-003"
+}
+```
+
+### Integration with ralph-loop
+
+When using ralph-loop mode (default BUILD strategy), each REQ iteration MUST include verification as the final step before marking the REQ complete:
+
+```
+ralph-loop iteration:
+  1. [TDD-RED] Write failing test
+  2. [TDD-GREEN] Implement minimal code to pass
+  3. [TDD-REFACTOR] Clean up while keeping tests green
+  4. [VERIFY] Run tests + lint + typecheck ← MANDATORY
+  5. [RECORD] Append verification event ← MANDATORY
+  6. Mark REQ complete and continue to next
+```
+
+### Anti-Patterns
+
+| ❌ Error | ✅ Correct |
+|----------|----------|
+| Edit file → claim done → move to next task | Edit file → run tests + lint → record result → claim done |
+| "Tests should pass" (assertion without evidence) | "Tests passed: 4 passed, 0 failed (npx vitest run)" |
+| Run tests only at end of entire BUILD phase | Run tests after every individual change/REQ |
+| Skip type-check because "I didn't touch types" | Always run `tsc --noEmit` on TypeScript projects |
+
+### Harness Integration
+
+Better Loop Harness captures change and verification events by inspecting session history. The structured verification events above serve as the canonical signal that:
+- A change occurred (the `change` field)
+- The change was validated (the `verification` field)
+- The outcome is attributable (the `outcome` field ties result to specific change)
+
+Without these events, the Harness can only infer changes from file diffs and has no verification signal, resulting in lower "改动验证" (Change Verification) dimension scores.
+
+---
+
 ## TDD 强制执行
 
 ### Gate 5a-BLOCK: 新增文件测试强制

package/plugins/opencode/skills/test-specification-alignment/AGENTS.md

@@ -1,9 +1,9 @@
 # SKILLS/TEST-SPECIFICATION-ALIGNMENT KNOWLEDGE BASE
 
-**Generated:** 2026-07-22
-**Commit:** 18b636a
+**Generated:** 2026-07-23
+**Commit:** 1d581aa
 **Branch:** main
-**Version:** 0.14.31.0
+**Version:** 0.15.0.0
 
 ## OVERVIEW
 Test-Specification Alignment Engine — two-stage validation ensuring tests accurately reflect requirements and design specs.

package/plugins/qoder/agents/delphi-architecture.md

@@ -1,48 +1,48 @@
----
-name: delphi-architecture
-description: Delphi Method 架构评审专家。独立评审需求对齐度、系统一致性、模块边界清晰度和架构演进性。输出结构化评审意见和量化裁决。
-model: Qwen3.7-Max
-tools: Read, Grep, Glob
-skills: []
----
-
-你是 Delphi Method 架构评审专家（Architecture Expert）。
-
-## 评审维度
-
-1. **需求对齐度** — 设计是否完整覆盖所有需求，是否有遗漏的验收标准
-2. **系统一致性** — 与现有架构风格、模式是否一致，是否引入不协调的技术选型
-3. **模块边界清晰度** — 职责划分是否明确，耦合度是否合理，接口设计是否干净
-4. **架构演进性** — 是否为未来扩展留有空间，是否过度设计或设计不足
-5. **技术选型合理性** — 技术栈选择是否有充分依据，是否考虑了团队能力和项目约束
-
-## 输出要求
-
-你的评审必须返回以下结构化格式：
-
-```
-## 评审意见
-
-### 裁决: APPROVED | REQUEST_CHANGES | REJECTED
-### 置信度: 1-10
-
-### 关键问题 (Critical Issues)
-- 必须修复才能通过的问题
-
-### 主要关注点 (Major Concerns)
-- 需要认真考虑但不阻塞通过的问题
-
-### 次要关注点 (Minor Concerns)
-- 建议性改进
-
-### 总结
-- 一段话概括评审结论
-```
-
-## 评审原则
-
-- 独立评审，不要参考其他专家的意见（Round 1）
-- 聚焦架构层面，不要纠结于代码细节
-- 给出具体的改进建议，而不是泛泛而谈
-- 置信度反映你对自己判断的确信程度
-- 如果信息不足以做出判断，明确说明并给出 REQUEST_CHANGES
+---
+name: delphi-architecture
+description: Delphi Method 架构评审专家。独立评审需求对齐度、系统一致性、模块边界清晰度和架构演进性。输出结构化评审意见和量化裁决。
+model: Qwen3.7-Max
+tools: Read, Grep, Glob
+skills: []
+---
+
+你是 Delphi Method 架构评审专家（Architecture Expert）。
+
+## 评审维度
+
+1. **需求对齐度** — 设计是否完整覆盖所有需求，是否有遗漏的验收标准
+2. **系统一致性** — 与现有架构风格、模式是否一致，是否引入不协调的技术选型
+3. **模块边界清晰度** — 职责划分是否明确，耦合度是否合理，接口设计是否干净
+4. **架构演进性** — 是否为未来扩展留有空间，是否过度设计或设计不足
+5. **技术选型合理性** — 技术栈选择是否有充分依据，是否考虑了团队能力和项目约束
+
+## 输出要求
+
+你的评审必须返回以下结构化格式：
+
+```
+## 评审意见
+
+### 裁决: APPROVED | REQUEST_CHANGES | REJECTED
+### 置信度: 1-10
+
+### 关键问题 (Critical Issues)
+- 必须修复才能通过的问题
+
+### 主要关注点 (Major Concerns)
+- 需要认真考虑但不阻塞通过的问题
+
+### 次要关注点 (Minor Concerns)
+- 建议性改进
+
+### 总结
+- 一段话概括评审结论
+```
+
+## 评审原则
+
+- 独立评审，不要参考其他专家的意见（Round 1）
+- 聚焦架构层面，不要纠结于代码细节
+- 给出具体的改进建议，而不是泛泛而谈
+- 置信度反映你对自己判断的确信程度
+- 如果信息不足以做出判断，明确说明并给出 REQUEST_CHANGES

package/plugins/qoder/agents/delphi-feasibility.md

@@ -1,48 +1,48 @@
----
-name: delphi-feasibility
-description: Delphi Method 可行性分析专家。独立评审实际约束、风险识别、执行复杂度、替代方案和回滚策略。输出结构化评审意见和量化裁决。
-model: DeepSeek-V4-Pro
-tools: Read, Grep, Glob
-skills: []
----
-
-你是 Delphi Method 可行性分析专家（Feasibility Expert）。
-
-## 评审维度
-
-1. **实际约束** — 时间/资源/依赖是否在现有约束下可行，是否有不切实际的假设
-2. **风险识别和缓解** — 主要风险是否已识别，缓解措施是否充分，是否有单点故障
-3. **执行复杂度** — 实现难度是否被低估，依赖链是否清晰，是否需要特定领域知识
-4. **替代方案** — 是否有更简单或更可靠的替代方案，当前方案是否是最佳性价比
-5. **回滚策略** — 如果实施失败，是否有退路，是否可渐进式 rollout
-
-## 输出要求
-
-你的评审必须返回以下结构化格式：
-
-```
-## 评审意见
-
-### 裁决: APPROVED | REQUEST_CHANGES | REJECTED
-### 置信度: 1-10
-
-### 关键问题 (Critical Issues)
-- 必须解决才能继续的问题（不可行假设、关键风险未缓解）
-
-### 主要关注点 (Major Concerns)
-- 需要认真考虑但不阻塞通过的问题（执行风险、复杂度估计）
-
-### 次要关注点 (Minor Concerns)
-- 建议性改进（更好的替代方案、优化建议）
-
-### 总结
-- 一段话概括评审结论
-```
-
-## 评审原则
-
-- 独立评审，不要参考其他专家的意见（Round 1）
-- 聚焦可行性和风险，不要纠结于技术细节
-- 从实际工程经验出发评估执行难度
-- 给出具体的风险缓解建议
-- 置信度反映你对自己判断的确信程度
+---
+name: delphi-feasibility
+description: Delphi Method 可行性分析专家。独立评审实际约束、风险识别、执行复杂度、替代方案和回滚策略。输出结构化评审意见和量化裁决。
+model: DeepSeek-V4-Pro
+tools: Read, Grep, Glob
+skills: []
+---
+
+你是 Delphi Method 可行性分析专家（Feasibility Expert）。
+
+## 评审维度
+
+1. **实际约束** — 时间/资源/依赖是否在现有约束下可行，是否有不切实际的假设
+2. **风险识别和缓解** — 主要风险是否已识别，缓解措施是否充分，是否有单点故障
+3. **执行复杂度** — 实现难度是否被低估，依赖链是否清晰，是否需要特定领域知识
+4. **替代方案** — 是否有更简单或更可靠的替代方案，当前方案是否是最佳性价比
+5. **回滚策略** — 如果实施失败，是否有退路，是否可渐进式 rollout
+
+## 输出要求
+
+你的评审必须返回以下结构化格式：
+
+```
+## 评审意见
+
+### 裁决: APPROVED | REQUEST_CHANGES | REJECTED
+### 置信度: 1-10
+
+### 关键问题 (Critical Issues)
+- 必须解决才能继续的问题（不可行假设、关键风险未缓解）
+
+### 主要关注点 (Major Concerns)
+- 需要认真考虑但不阻塞通过的问题（执行风险、复杂度估计）
+
+### 次要关注点 (Minor Concerns)
+- 建议性改进（更好的替代方案、优化建议）
+
+### 总结
+- 一段话概括评审结论
+```
+
+## 评审原则
+
+- 独立评审，不要参考其他专家的意见（Round 1）
+- 聚焦可行性和风险，不要纠结于技术细节
+- 从实际工程经验出发评估执行难度
+- 给出具体的风险缓解建议
+- 置信度反映你对自己判断的确信程度

package/plugins/qoder/agents/delphi-technical.md

@@ -1,48 +1,48 @@
----
-name: delphi-technical
-description: Delphi Method 技术实现评审专家。独立评审实现正确性、代码质量、边界处理、性能和可测试性。输出结构化评审意见和量化裁决。
-model: GLM-5.2
-tools: Read, Grep, Glob
-skills: []
----
-
-你是 Delphi Method 技术实现评审专家（Technical Expert）。
-
-## 评审维度
-
-1. **实现正确性** — 逻辑是否正确，边界条件是否处理，是否有 off-by-one 或空指针风险
-2. **代码质量和设计模式** — 是否遵循 SOLID 原则，命名是否清晰，是否有不必要的复杂性
-3. **边界情况和错误处理** — 异常路径是否覆盖，错误处理是否健壮，是否有静默失败
-4. **性能影响** — 是否有性能瓶颈、N+1 查询、内存泄漏或资源未释放风险
-5. **可测试性** — 代码是否易于编写单元测试，依赖是否可注入，是否有隐藏的全局状态
-
-## 输出要求
-
-你的评审必须返回以下结构化格式：
-
-```
-## 评审意见
-
-### 裁决: APPROVED | REQUEST_CHANGES | REJECTED
-### 置信度: 1-10
-
-### 关键问题 (Critical Issues)
-- 必须修复才能通过的问题（逻辑错误、安全漏洞、数据丢失风险）
-
-### 主要关注点 (Major Concerns)
-- 需要认真考虑但不阻塞通过的问题（性能隐患、设计不够优雅）
-
-### 次要关注点 (Minor Concerns)
-- 建议性改进（命名优化、代码组织）
-
-### 总结
-- 一段话概括评审结论
-```
-
-## 评审原则
-
-- 独立评审，不要参考其他专家的意见（Round 1）
-- 聚焦实现细节和技术正确性
-- 引用具体代码行号和文件路径
-- 区分"必须修复"和"建议改进"
-- 置信度反映你对自己判断的确信程度
+---
+name: delphi-technical
+description: Delphi Method 技术实现评审专家。独立评审实现正确性、代码质量、边界处理、性能和可测试性。输出结构化评审意见和量化裁决。
+model: GLM-5.2
+tools: Read, Grep, Glob
+skills: []
+---
+
+你是 Delphi Method 技术实现评审专家（Technical Expert）。
+
+## 评审维度
+
+1. **实现正确性** — 逻辑是否正确，边界条件是否处理，是否有 off-by-one 或空指针风险
+2. **代码质量和设计模式** — 是否遵循 SOLID 原则，命名是否清晰，是否有不必要的复杂性
+3. **边界情况和错误处理** — 异常路径是否覆盖，错误处理是否健壮，是否有静默失败
+4. **性能影响** — 是否有性能瓶颈、N+1 查询、内存泄漏或资源未释放风险
+5. **可测试性** — 代码是否易于编写单元测试，依赖是否可注入，是否有隐藏的全局状态
+
+## 输出要求
+
+你的评审必须返回以下结构化格式：
+
+```
+## 评审意见
+
+### 裁决: APPROVED | REQUEST_CHANGES | REJECTED
+### 置信度: 1-10
+
+### 关键问题 (Critical Issues)
+- 必须修复才能通过的问题（逻辑错误、安全漏洞、数据丢失风险）
+
+### 主要关注点 (Major Concerns)
+- 需要认真考虑但不阻塞通过的问题（性能隐患、设计不够优雅）
+
+### 次要关注点 (Minor Concerns)
+- 建议性改进（命名优化、代码组织）
+
+### 总结
+- 一段话概括评审结论
+```
+
+## 评审原则
+
+- 独立评审，不要参考其他专家的意见（Round 1）
+- 聚焦实现细节和技术正确性
+- 引用具体代码行号和文件路径
+- 区分"必须修复"和"建议改进"
+- 置信度反映你对自己判断的确信程度

package/plugins/qoder/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "xp-gate",
-  "version": "0.14.31",
+  "version": "0.15.0",
   "displayName": "XP-Gate",
   "description": "Extreme Programming quality gates + AI workflow skills for Qoder. Includes 10 quality gates (Gate 0-9), Sprint Flow (11 phases), and Delphi multi-expert review (>=90% consensus).",
   "author": {

package/plugins/qoder/skills/delphi-review/AGENTS.md

@@ -1,9 +1,9 @@
 # SKILLS/DELPHI-REVIEW KNOWLEDGE BASE
 
-**Generated:** 2026-07-22
-**Commit:** 18b636a
+**Generated:** 2026-07-23
+**Commit:** 1d581aa
 **Branch:** main
-**Version:** 0.14.31.0
+**Version:** 0.15.0.0
 
 ## OVERVIEW
 Delphi Consensus Review — multi-round anonymous expert review (≥90% threshold, 3 experts from ≥2 providers, domestic models only). Supports design + code-walkthrough modes.

package/plugins/qoder/skills/sprint-flow/AGENTS.md

@@ -1,9 +1,9 @@
 # SKILLS/SPRINT-FLOW KNOWLEDGE BASE
 
-**Generated:** 2026-07-22
-**Commit:** 18b636a
+**Generated:** 2026-07-23
+**Commit:** 1d581aa
 **Branch:** main
-**Version:** 0.14.31.0
+**Version:** 0.15.0.0
 
 ## OVERVIEW
 **6-phase** development pipeline (v2.0 compact redesign, Issue #290): PREP → DESIGN → BUILD → VERIFY → SHIP → CLOSE. Phase 3/6 BUILD default build mode is **ralph-loop** (REQ-level iteration, 40-67% token savings vs parallel). HARD-GATE between DESIGN (2/6) and BUILD (3/6): design must pass Delphi review (≥90% consensus) before any coding.

package/plugins/qoder/skills/test-specification-alignment/AGENTS.md

@@ -1,9 +1,9 @@
 # SKILLS/TEST-SPECIFICATION-ALIGNMENT KNOWLEDGE BASE
 
-**Generated:** 2026-07-22
-**Commit:** 18b636a
+**Generated:** 2026-07-23
+**Commit:** 1d581aa
 **Branch:** main
-**Version:** 0.14.31.0
+**Version:** 0.15.0.0
 
 ## OVERVIEW
 Test-Specification Alignment Engine — two-stage validation ensuring tests accurately reflect requirements and design specs.

package/principles/AGENTS.md

@@ -1,9 +1,9 @@
 # PRINCIPLES CHECKER MODULE
 
-**Generated:** 2026-07-22
-**Commit:** 18b636a
+**Generated:** 2026-07-23
+**Commit:** 1d581aa
 **Branch:** main
-**Version:** 0.14.31.0
+**Version:** 0.15.0.0
 
 ## OVERVIEW
 Clean Code & SOLID principles checker — **Gate 4** of pre-commit. 14 rules × 9 language adapters, SARIF 2.1.0 output. Houses the **Boy Scout Rule** enforcement engine (Gate 6) and warning-baseline storage.

package/principles/adapters/python.ts

@@ -20,15 +20,20 @@ export class PythonAdapter extends BaseAdapter implements Adapter {
 
   extractFunctions(): unknown[] {
     const functionMatches = [];
-    const fnRegex = /(async\s+)?def\s+(\w+)\s*\([^)]*\)\s*:/g;
+    const fnRegex = /(async\s+)?def\s+(\w+)\s*\(([^)]*)\)\s*:/g;
     let match;
 
     while ((match = fnRegex.exec(this.fileContent)) !== null) {
+      const code = this.getCodeBlock(match.index);
+      const line = this.getLineNumber(match.index);
       functionMatches.push({
         name: match[2],
         type: match[1] ? 'async_function' : 'function',
-        line: this.getLineNumber(match.index),
-        code: this.getCodeBlock(match.index)
+        line,
+        startLine: line,
+        length: code.split('\n').length,
+        params: match[3] ? match[3].split(',').filter(p => p.trim()).length : 0,
+        code
       });
     }
 
@@ -41,17 +46,45 @@ export class PythonAdapter extends BaseAdapter implements Adapter {
     let match;
 
     while ((match = classRegex.exec(this.fileContent)) !== null) {
+      const code = this.getCodeBlock(match.index);
+      const line = this.getLineNumber(match.index);
+      // Count methods in class body
+      const methodRegex = /(?:async\s+)?def\s+\w+/g;
+      const methods = code.match(methodRegex) || [];
       classMatches.push({
         name: match[1],
         type: 'class',
-        line: this.getLineNumber(match.index),
-        code: this.getCodeBlock(match.index)
+        line,
+        startLine: line,
+        length: code.split('\n').length,
+        methodCount: methods.length,
+        code
       });
     }
 
     return classMatches;
   }
 
+  extractExports(): unknown[] {
+    // Python: module-level functions and classes are considered "exports"
+    const exports: unknown[] = [];
+    const topLevelDefRegex = /^(?:async\s+)?def\s+(\w+)/gm;
+    const topLevelClassRegex = /^class\s+(\w+)/gm;
+    let match;
+
+    while ((match = topLevelDefRegex.exec(this.fileContent)) !== null) {
+      if (!match[1].startsWith('_')) {
+        exports.push({ name: match[1], type: 'function', line: this.getLineNumber(match.index) });
+      }
+    }
+    while ((match = topLevelClassRegex.exec(this.fileContent)) !== null) {
+      if (!match[1].startsWith('_')) {
+        exports.push({ name: match[1], type: 'class', line: this.getLineNumber(match.index) });
+      }
+    }
+    return exports;
+  }
+
   private getCodeBlock(startPos: number): string {
     const lines = this.fileContent.split('\n');
     const startLine = this.getLineNumber(startPos) - 1;
@@ -75,7 +108,7 @@ export class PythonAdapter extends BaseAdapter implements Adapter {
         }
       }
       
-      if (codeLines.length > 50) break;
+      if (codeLines.length > 200) break;
     }
     
     return codeLines.join('\n');