@boyingliu01/xp-gate 0.35.22 → 0.35.23

package/adapters/kotlin.sh

@@ -14,30 +14,75 @@ run_static_analysis() {
   local build_system
   build_system=$(_detect_kotlin_build)
 
+  # (#706) A failed BUILD must not swallow a lint tool that works on its own.
+  #
+  # This used to `return 1` the moment Gradle/Maven failed to compile, so detekt
+  # -- which reads .kt sources directly and needs no build at all -- never ran.
+  # Measured on a machine whose Gradle cannot resolve the Kotlin plugin
+  # (`Failed to query the value of property 'buildFlowServiceProperty'`): the
+  # hook reported "SKIPPED - Code quality (tools unavailable or failed)" while
+  # `detekt --input .` on the same file reported two real findings. The gate
+  # blamed the toolchain for a verdict the toolchain never got to deliver.
+  #
+  # So: record the compilation failure, still run the standalone lint tool, and
+  # let the caller decide. The failure is reported, never hidden.
+  local build_failed=0
   if [ "$build_system" = "maven" ]; then
     mvn compile -q 2>&1 | grep -i "error\|fail" | sed -n '1,5p; 5q'
     if [ ${PIPESTATUS[0]} -ne 0 ]; then
       echo "❌ Maven compilation failed"
-      return 1
+      build_failed=1
     fi
   elif [ "$build_system" = "gradle" ]; then
     gradle compileKotlin --quiet 2>&1 | grep -i "error\|fail" | sed -n '1,5p; 5q'
     if [ ${PIPESTATUS[0]} -ne 0 ]; then
       echo "❌ Gradle compilation failed"
-      return 1
+      build_failed=1
     fi
   fi
 
+  # Standalone analyzers run regardless of the build outcome: their verdict does
+  # not depend on the build having succeeded.
+  #
+  # ktlint and detekt are tried in preference order, but a tool that is PRESENT
+  # and produces NOTHING is not the same as a tool that reached a verdict. An
+  # `elif` chain made the first present tool authoritative: a broken ktlint (or a
+  # shim on PATH, or ktlint 1.x refusing a `**/*.kt` glob) reported "No files
+  # matched" and detekt -- which works -- was never consulted. Measured here:
+  # `command -v ktlint` succeeded while `ktlint **/*.kt` matched zero files, so
+  # the real analyzer never ran.
+  local lint_rc=0 linted=0 ktlint_out=""
   if command -v ktlint &>/dev/null; then
-    ktlint "**/*.kt" 2>&1 | sed -n '1,20p; 20q'
-    return $?
-  elif command -v detekt &>/dev/null; then
+    ktlint_out=$(ktlint "**/*.kt" 2>&1)
+    lint_rc=$?
+    printf '%s\n' "$ktlint_out" | sed -n '1,20p'
+    # Only an EXECUTED ktlint counts as having delivered a verdict. Three ways it
+    # can fail to: the binary cannot run (127/126), it reports "No files matched"
+    # (ktlint 1.8.0 no longer resolves `**/*.kt`), or it printed nothing at all.
+    # In every one of those cases detekt should speak instead of ktlint's silence
+    # being read as "clean".
+    if [ "$lint_rc" -ne 127 ] && [ "$lint_rc" -ne 126 ] \
+       && [ -n "$ktlint_out" ] \
+       && ! printf '%s\n' "$ktlint_out" | grep -q 'No files matched'; then
+      linted=1
+    fi
+  fi
+  if [ "$linted" -eq 0 ] && command -v detekt &>/dev/null; then
     detekt --input . 2>&1 | sed -n '1,20p; 20q'
-    return $?
-  else
+    lint_rc=${PIPESTATUS[0]}
+    linted=1
+  fi
+  if [ "$linted" -eq 0 ]; then
     echo "No Kotlin lint tools (ktlint/detekt)"
-    return 0
+    # A missing lint tool is a SKIP, not a pass -- but it must not manufacture a
+    # failure either. Only the build result decides in that case.
+    [ "$build_failed" -eq 0 ] && return 0
+    return 1
   fi
+
+  # A lint finding is a finding whether or not the build also failed.
+  [ "$lint_rc" -ne 0 ] && return "$lint_rc"
+  return "$build_failed"
 }
 
 run_lint() {

package/gate-13-compiler-strictness.sh

@@ -525,7 +525,21 @@ gate13_javac_args() {
 gate13_count_lint_findings() {
   local src="${1:-}"
   [ -n "$src" ] || src=$(cat)
-  printf '%s\n' "$src" | awk '
+  # (#701) Pin the locale to C for this awk, on purpose. In a UTF-8 locale gawk
+  # refuses to let `.` span bytes that are not valid UTF-8, and a Maven build on a
+  # zh_CN Windows box writes its reactor summary in GBK (stdout.encoding=GBK), so a
+  # module name such as "验证程序" arrives as d1 e9 d6 a4 b3 cc d0 f2 -- invalid
+  # UTF-8. The #673 exclusion rule (`/^\[INFO\].*\[jar\].../`) then fails to match
+  # and the line falls through to the open-category rule as a phantom finding.
+  # Measured (#701): the same input counts 0 under LC_ALL=C and 1 under
+  # LC_ALL=C.UTF-8, i.e. the verdict depended on the caller's environment rather
+  # than on the build. C locale makes `.` byte-oriented, so the match no longer
+  # depends on whether the module name happens to be ASCII.
+  #
+  # This costs nothing in matching power: every marker below (packaging types,
+  # `[category]`, `warning:`) is ASCII, and the localised unchecked/unsafe
+  # wordings are matched as byte sequences, which C locale handles exactly.
+  printf '%s\n' "$src" | LC_ALL=C awk '
     BEGIN { n = 0 }
     # (#673) Maven 3.9.7+ reactor summary appends the packaging type per module:
     #     [INFO] whaleaudit-core  [jar]

package/hooks/gate-13-compiler-strictness.sh

@@ -525,7 +525,21 @@ gate13_javac_args() {
 gate13_count_lint_findings() {
   local src="${1:-}"
   [ -n "$src" ] || src=$(cat)
-  printf '%s\n' "$src" | awk '
+  # (#701) Pin the locale to C for this awk, on purpose. In a UTF-8 locale gawk
+  # refuses to let `.` span bytes that are not valid UTF-8, and a Maven build on a
+  # zh_CN Windows box writes its reactor summary in GBK (stdout.encoding=GBK), so a
+  # module name such as "验证程序" arrives as d1 e9 d6 a4 b3 cc d0 f2 -- invalid
+  # UTF-8. The #673 exclusion rule (`/^\[INFO\].*\[jar\].../`) then fails to match
+  # and the line falls through to the open-category rule as a phantom finding.
+  # Measured (#701): the same input counts 0 under LC_ALL=C and 1 under
+  # LC_ALL=C.UTF-8, i.e. the verdict depended on the caller's environment rather
+  # than on the build. C locale makes `.` byte-oriented, so the match no longer
+  # depends on whether the module name happens to be ASCII.
+  #
+  # This costs nothing in matching power: every marker below (packaging types,
+  # `[category]`, `warning:`) is ASCII, and the localised unchecked/unsafe
+  # wordings are matched as byte sequences, which C locale handles exactly.
+  printf '%s\n' "$src" | LC_ALL=C awk '
     BEGIN { n = 0 }
     # (#673) Maven 3.9.7+ reactor summary appends the packaging type per module:
     #     [INFO] whaleaudit-core  [jar]

package/hooks/pre-commit

@@ -2237,15 +2237,22 @@ else
       ADAPTER_FILE=$(resolve_adapter_path "$CURRENT_LANG")
       if [ -n "$ADAPTER_FILE" ] && source "$ADAPTER_FILE" 2>/dev/null; then
         echo "Running static analysis for $CURRENT_LANG..."
+        # (#706) Capture the ADAPTER's verdict, not `head`'s.
+        #
+        # `run_static_analysis | head -30` makes `$?` the exit status of `head`,
+        # which is 0 whenever it manages to read anything -- so ANALYSIS_EXIT was
+        # always 0 and the "tools unavailable or failed" branch below was dead
+        # code. Measured: an adapter returning 1 through this pipe still produced
+        # PASSED. PIPESTATUS[0] carries the adapter's real status.
         run_static_analysis | head -30 2>/dev/null
-        ANALYSIS_EXIT=$?
+        ANALYSIS_EXIT=${PIPESTATUS[0]}
         if [ "$ANALYSIS_EXIT" -ne 0 ]; then
           echo "⚠️  Static analysis had issues (may be non-blocking)"
         fi
-    
+
         echo "Running lint check for $CURRENT_LANG..."
         run_lint | head -30 2>/dev/null
-        LINT_EXIT=$?
+        LINT_EXIT=${PIPESTATUS[0]}
         if [ "$LINT_EXIT" -ne 0 ]; then
           echo "ℹ️  Lint check had issues (may be non-blocking)"
         fi
@@ -3692,10 +3699,40 @@ else
         if [ "${PARTIAL_TEST_RUN:-false}" = "true" ]; then
           echo "⚠️  No JaCoCo report found (subset test run) — not blocking."
         else
+          # (#703) Diagnose BEFORE advising. The old message sent every user to
+          # `mvn verify`; on a build path containing non-ASCII characters that
+          # command is a dead end. Measured on a zh_CN Windows box at
+          # D:\projects\SQL审计工具: the JaCoCo agent never writes jacoco.exec, it
+          # does not throw, and Maven reports BUILD SUCCESS with
+          #   [INFO] Skipping JaCoCo execution due to missing execution data file.
+          # so `mvn verify` "fixes" nothing and the user loops. Splitting the
+          # diagnosis out lets each case get an action that can actually work.
           echo "❌ BLOCKED - No JaCoCo report found, so the ${COVERAGE_THRESHOLD:-80}% Java coverage"
-          echo "   floor cannot be verified. Run 'mvn verify' or 'gradle jacocoTestReport'"
-          echo "   so that target/site/jacoco/jacoco.csv exists (see also: JaCoCo detection"
-          echo "   in adapters/java.sh)."
+          echo "   floor cannot be verified."
+          # The distinguishing symptom is the jacoco.exec execution data file, not
+          # a missing report: a report that failed to be GENERATED and an agent
+          # that never WROTE are different problems with different fixes.
+          echo "   Likely cause: the JaCoCo agent did not write its execution data file"
+          echo "   (target/jacoco.exec), which is what 'Skipping JaCoCo execution due to"
+          echo "   missing execution data file' in the Maven log means."
+          # A non-ASCII working directory is the one common cause where the usual
+          # advice actively does not work, so it must be called out by name rather
+          # than left for the user to discover by trying.
+          case "$PWD" in
+            *[!-~]*)
+              echo "   ⚠️  This build path contains non-ASCII characters: ${PWD}"
+              echo "   ⚠️  Re-running 'mvn verify' will NOT help on this path — JaCoCo"
+              echo "       silently skips writing execution data there. Build through an"
+              echo "       ASCII-only directory instead (e.g. a junction to the same tree,"
+              echo "       entered with cmd's 'pushd'/'cd /d' — Git Bash's cd resolves the"
+              echo "       junction back to the non-ASCII path, so it does not help)."
+              ;;
+            *)
+              echo "   To produce it, run 'mvn verify' or 'gradle jacocoTestReport' so that"
+              echo "   target/site/jacoco/jacoco.csv exists (see also: JaCoCo detection"
+              echo "   in adapters/java.sh)."
+              ;;
+          esac
           exit 1
         fi
       fi
@@ -4539,6 +4576,91 @@ resolve_build_integrity_timeout() {
   esac
 }
 
+# (#708) A Java build failure has one overwhelmingly common cause that the gate
+# used to say nothing about: the wrong JDK. The real reason is buried in the last
+# 20 lines of Maven output, while the gate's own verdict line was only
+# "❌ Java build failed (exit 1)".
+#
+# Measured: a pom with <maven.compiler.release>8</maven.compiler.release> built
+# with JDK 8 fails with "无效的标记: --release" (invalid flag: --release) — a
+# message that points at the compiler ARGUMENTS and at the project CONFIG while
+# actually pointing at the JDK on PATH. Getting from that message to "change the
+# JDK" takes one inference, and the gate's verdict line supplied no premise for
+# it. The person debugging this suspected the release setting, then the plugin
+# version, then .mvn/jvm.config — all wrong; the fix was a different JDK.
+#
+# So: on failure, print what JDK actually ran, what the project asks for, and —
+# when the output carries the tell — state the conclusion instead of the symptom.
+# Diagnostics must never change the verdict; this only adds lines.
+java_bi_report_jdk_context() {
+  local build_out="$1"
+  local java_version="" java_home_val="${JAVA_HOME:-}"
+  # `java -version` writes to stderr on every JDK. Take the version line verbatim
+  # rather than parsing it: this is a diagnostic, and the raw line is what a
+  # person would paste into a bug report.
+  if command -v java >/dev/null 2>&1; then
+    java_version=$(java -version 2>&1 | sed -n '1p')
+  fi
+  if [ -n "$java_version" ]; then
+    echo "     JDK in use: ${java_version}"
+  else
+    echo "     JDK in use: (java not on PATH)"
+  fi
+  if [ -n "$java_home_val" ]; then
+    echo "     JAVA_HOME: ${java_home_val}"
+  else
+    echo "     JAVA_HOME: (unset)"
+  fi
+
+  # What the project requires. Maven declares it three ways; Gradle declares it in
+  # its build script. Report whichever exists — the comparison is the user's, but
+  # only if both halves are visible.
+  local declared=""
+  if [ -f "pom.xml" ]; then
+    local mvn_release mvn_source
+    mvn_release=$(grep -o '<maven\.compiler\.release>[[:space:]]*[0-9][0-9]*' pom.xml 2>/dev/null \
+      | sed 's/.*>[[:space:]]*//' | head -1)
+    mvn_source=$(grep -o '<maven\.compiler\.source>[[:space:]]*[0-9][0-9]*' pom.xml 2>/dev/null \
+      | sed 's/.*>[[:space:]]*//' | head -1)
+    if [ -n "$mvn_release" ]; then
+      declared="maven.compiler.release=${mvn_release}"
+    elif [ -n "$mvn_source" ]; then
+      declared="maven.compiler.source=${mvn_source}"
+    fi
+  fi
+  if [ -z "$declared" ] && [ -f "build.gradle" ]; then
+    local g_compat
+    g_compat=$(grep -o "sourceCompatibility[[:space:]]*=[[:space:]]*['\"]\{0,1\}[0-9][0-9]*" build.gradle 2>/dev/null \
+      | sed "s/.*[=][[:space:]]*['\"]\{0,1\}//" | head -1)
+    [ -n "$g_compat" ] && declared="sourceCompatibility=${g_compat}"
+  fi
+  if [ -z "$declared" ] && [ -f "build.gradle.kts" ]; then
+    local k_compat
+    k_compat=$(grep -o 'sourceCompatibility[[:space:]]*=[[:space:]]*JavaVersion\.VERSION_[0-9_]*' build.gradle.kts 2>/dev/null \
+      | sed 's/.*VERSION_//' | tr '_' '.' | head -1)
+    [ -n "$k_compat" ] && declared="sourceCompatibility=${k_compat}"
+  fi
+
+  if [ -n "$declared" ]; then
+    echo "     Project requires: ${declared}"
+  else
+    echo "     Project requires: (no JDK floor declared in pom.xml/build.gradle)"
+  fi
+
+  # The tell. `--release` only exists from JDK 9, so its rejection is a direct
+  # statement about the JDK, not about the pom. Saying so converts a search into
+  # a fix.
+  case "$build_out" in
+    *--release*)
+      if printf '%s' "$build_out" | grep -qiE 'invalid flag|无效的标记|illegal option|unrecognized|unknown option'; then
+        echo "     💡 The build passed '--release' to javac and the JDK rejected it."
+        echo "        '--release' requires JDK 9 or newer; the JDK above is older than that."
+        echo "        Switch to a JDK >= 9 (or remove the release/source setting if it is not intended)."
+      fi
+      ;;
+  esac
+}
+
 run_java_build_integrity() {
   local timeout_s build_bin
   # Wrapper first: mvnw pins the project's own Maven version.
@@ -4553,12 +4675,17 @@ run_java_build_integrity() {
   fi
 
   timeout_s=$(resolve_build_integrity_timeout)
+  # (#708) Keep the output: the failure branch has to read it to tell a wrong-JDK
+  # failure from any other one. Displayed through `tail -20` exactly as before, so
+  # the visible build log is unchanged.
+  local bi_out
   if command -v timeout >/dev/null 2>&1; then
-    timeout "$timeout_s" "$build_bin" -q -DskipTests compile 2>&1 | tail -20
+    bi_out=$(timeout "$timeout_s" "$build_bin" -q -DskipTests compile 2>&1)
   else
-    "$build_bin" -q -DskipTests compile 2>&1 | tail -20
+    bi_out=$("$build_bin" -q -DskipTests compile 2>&1)
   fi
-  local rc="${PIPESTATUS[0]}"
+  local rc=$?
+  printf '%s\n' "$bi_out" | tail -20
   if [ "$rc" -eq 0 ]; then
     echo "     ✅ Java build integrity verified (mvn -q -DskipTests compile)."
     return 0
@@ -4569,6 +4696,7 @@ run_java_build_integrity() {
     return 3
   fi
   echo "     ❌ Java build failed (exit $rc)"
+  java_bi_report_jdk_context "$bi_out"
   return 2
 }
 

package/lib/mattpocock-license-verdict.json

@@ -2,6 +2,6 @@
   "verdict": "PASS",
   "license_type": "MIT",
   "sha256": "0e7ac423bf2c6e223b7c5b156f8cf72da49d748e56a1641402c31f22ad07dbb5",
-  "checked_at": "2026-11-02T06:58:08.096Z",
+  "checked_at": "2026-11-02T15:52:57.140Z",
   "source": "network"
 }

package/mock-policy/AGENTS.md

@@ -1,9 +1,9 @@
 # SRC/MOCK-POLICY KNOWLEDGE BASE
 
 **Generated:** 2026-11-02
-**Commit:** 57ef51ed
+**Commit:** 8a968080
 **Branch:** main
-**Version:** 0.35.22.0
+**Version:** 0.35.23.0
 
 ## OVERVIEW
 Mock layering policy enforcement — Gate M3 of pre-push hook. Ensures integration tests use real implementations for internal dependencies, mock external dependencies, and annotate pending mocks with removal plans. Combines project scope scanning, mock decision engine, and per-file validation into a single pipeline.

package/mutation/AGENTS.md

@@ -1,9 +1,9 @@
 # SRC/MUTATION KNOWLEDGE BASE
 
 **Generated:** 2026-11-02
-**Commit:** 57ef51ed
+**Commit:** 8a968080
 **Branch:** main
-**Version:** 0.35.22.0
+**Version:** 0.35.23.0
 
 ## OVERVIEW
 **Gate M** (incremental mutation testing) + **Gate M2** helpers (test-layer detection used by `src/mock-policy/`). Pre-push quality gate. TypeScript-only; uses Stryker.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@boyingliu01/xp-gate",
-  "version": "0.35.22",
+  "version": "0.35.23",
   "description": "AI-driven development workflow: 6 quality gates + Delphi review + Sprint Flow",
   "bin": {
     "xp-gate": "bin/xp-gate.js"

package/plugins/claude-code/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "xp-gate",
-  "version": "0.35.22",
+  "version": "0.35.23",
   "displayName": "XP-Gate",
   "description": "Extreme Programming quality gates + AI workflow skills for Claude Code. Includes 12 pre-commit gates (Gate 0-11), 8 pre-push gates, Sprint Flow (6 phases), and Delphi multi-expert review (>=90% consensus).",
   "author": {

package/plugins/claude-code/skills/delphi-review/AGENTS.md

@@ -1,9 +1,9 @@
 # SKILLS/DELPHI-REVIEW KNOWLEDGE BASE
 
 **Generated:** 2026-11-02
-**Commit:** 57ef51ed
+**Commit:** 8a968080
 **Branch:** main
-**Version:** 0.35.22.0
+**Version:** 0.35.23.0
 
 ## OVERVIEW
 Delphi Consensus Review — multi-round anonymous expert review (≥90% threshold, exactly 3 experts with distinct executable model IDs). Supports design, requirements, and code-walkthrough modes.

package/plugins/claude-code/skills/sprint-flow/AGENTS.md

@@ -1,9 +1,9 @@
 # SKILLS/SPRINT-FLOW KNOWLEDGE BASE
 
 **Generated:** 2026-11-02
-**Commit:** 57ef51ed
+**Commit:** 8a968080
 **Branch:** main
-**Version:** 0.35.22.0
+**Version:** 0.35.23.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/claude-code/skills/test-specification-alignment/AGENTS.md

@@ -1,9 +1,9 @@
 # SKILLS/TEST-SPECIFICATION-ALIGNMENT KNOWLEDGE BASE
 
 **Generated:** 2026-11-02
-**Commit:** 57ef51ed
+**Commit:** 8a968080
 **Branch:** main
-**Version:** 0.35.22.0
+**Version:** 0.35.23.0
 
 ## OVERVIEW
 Test-Specification Alignment Engine — two-stage validation ensuring tests accurately reflect requirements and design specs.

package/plugins/dsh/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@boyingliu01/dsh-plugin-xp-gate",
-  "version": "0.35.22",
+  "version": "0.35.23",
   "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",

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

@@ -1,9 +1,9 @@
 # SKILLS/DELPHI-REVIEW KNOWLEDGE BASE
 
 **Generated:** 2026-11-02
-**Commit:** 57ef51ed
+**Commit:** 8a968080
 **Branch:** main
-**Version:** 0.35.22.0
+**Version:** 0.35.23.0
 
 ## OVERVIEW
 Delphi Consensus Review — multi-round anonymous expert review (≥90% threshold, exactly 3 experts with distinct executable model IDs). Supports design, requirements, and code-walkthrough modes.

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

@@ -1,9 +1,9 @@
 # SKILLS/SPRINT-FLOW KNOWLEDGE BASE
 
 **Generated:** 2026-11-02
-**Commit:** 57ef51ed
+**Commit:** 8a968080
 **Branch:** main
-**Version:** 0.35.22.0
+**Version:** 0.35.23.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/dsh/skills/test-specification-alignment/AGENTS.md

@@ -1,9 +1,9 @@
 # SKILLS/TEST-SPECIFICATION-ALIGNMENT KNOWLEDGE BASE
 
 **Generated:** 2026-11-02
-**Commit:** 57ef51ed
+**Commit:** 8a968080
 **Branch:** main
-**Version:** 0.35.22.0
+**Version:** 0.35.23.0
 
 ## OVERVIEW
 Test-Specification Alignment Engine — two-stage validation ensuring tests accurately reflect requirements and design specs.

package/plugins/opencode/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@boyingliu01/opencode-plugin",
-  "version": "0.35.22",
+  "version": "0.35.23",
   "type": "module",
   "main": "index.ts",
   "description": "XP-Gate quality gates + AI workflow skills for OpenCode",

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

@@ -1,9 +1,9 @@
 # SKILLS/DELPHI-REVIEW KNOWLEDGE BASE
 
 **Generated:** 2026-11-02
-**Commit:** 57ef51ed
+**Commit:** 8a968080
 **Branch:** main
-**Version:** 0.35.22.0
+**Version:** 0.35.23.0
 
 ## OVERVIEW
 Delphi Consensus Review — multi-round anonymous expert review (≥90% threshold, exactly 3 experts with distinct executable model IDs). Supports design, requirements, and code-walkthrough modes.

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

@@ -1,9 +1,9 @@
 # SKILLS/SPRINT-FLOW KNOWLEDGE BASE
 
 **Generated:** 2026-11-02
-**Commit:** 57ef51ed
+**Commit:** 8a968080
 **Branch:** main
-**Version:** 0.35.22.0
+**Version:** 0.35.23.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/test-specification-alignment/AGENTS.md

@@ -1,9 +1,9 @@
 # SKILLS/TEST-SPECIFICATION-ALIGNMENT KNOWLEDGE BASE
 
 **Generated:** 2026-11-02
-**Commit:** 57ef51ed
+**Commit:** 8a968080
 **Branch:** main
-**Version:** 0.35.22.0
+**Version:** 0.35.23.0
 
 ## OVERVIEW
 Test-Specification Alignment Engine — two-stage validation ensuring tests accurately reflect requirements and design specs.

package/plugins/qoder/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "xp-gate",
-  "version": "0.35.22",
+  "version": "0.35.23",
   "displayName": "XP-Gate",
   "description": "Extreme Programming quality gates + AI workflow skills for Qoder. Includes 12 pre-commit gates (Gate 0-11), 8 pre-push gates, Sprint Flow (6 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-11-02
-**Commit:** 57ef51ed
+**Commit:** 8a968080
 **Branch:** main
-**Version:** 0.35.22.0
+**Version:** 0.35.23.0
 
 ## OVERVIEW
 Delphi Consensus Review — multi-round anonymous expert review (≥90% threshold, exactly 3 experts with distinct executable model IDs). Supports design, requirements, and code-walkthrough modes.

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

@@ -1,9 +1,9 @@
 # SKILLS/SPRINT-FLOW KNOWLEDGE BASE
 
 **Generated:** 2026-11-02
-**Commit:** 57ef51ed
+**Commit:** 8a968080
 **Branch:** main
-**Version:** 0.35.22.0
+**Version:** 0.35.23.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-11-02
-**Commit:** 57ef51ed
+**Commit:** 8a968080
 **Branch:** main
-**Version:** 0.35.22.0
+**Version:** 0.35.23.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-11-02
-**Commit:** 57ef51ed
+**Commit:** 8a968080
 **Branch:** main
-**Version:** 0.35.22.0
+**Version:** 0.35.23.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/scripts/delphi-external-review.cjs

@@ -199,6 +199,28 @@ function readConfig(configPath, profileOverride) {
         process.exit(1);
       }
     }
+
+    // (#707) base_url supports ${VAR} for the same reason api_key does: writing a
+    // gateway address as a placeholder is the natural way to keep an internal
+    // endpoint out of version control. Without expansion the placeholder is a
+    // perfectly valid non-empty string, so validation passed and the literal text
+    // `${PG_GATEWAY}/v1/chat/completions` went out as a URL — failing at the
+    // NETWORK layer with a DNS/connection error while the config looked correct.
+    // A caller (whale-sql-audit) had to hardcode its gateway into a distributed
+    // repo because of this.
+    //
+    // Failing here, at config load, names the variable; falling back to the
+    // literal is exactly what caused the original misdiagnosis, so it does not.
+    if (typeof prov.base_url === 'string'
+        && prov.base_url.startsWith('${') && prov.base_url.endsWith('}')) {
+      const envName = prov.base_url.slice(2, -1);
+      const envVal = process.env[envName];
+      if (!envVal) {
+        console.error(`[delphi-review] ERROR: Environment variable ${envName} is not set (profiles.${profileName}.providers.${name}.base_url). Export it or point that provider at a literal URL.`);
+        process.exit(1);
+      }
+      prov.base_url = envVal;
+    }
   }
 
   const experts = Object.fromEntries(Object.entries(profile.experts || {}).map(([role, expert]) => [
@@ -701,7 +723,52 @@ async function callModelAPI(providerConfig, model, systemPrompt, userPrompt, opt
     }
 
     if (response.status >= 500) {
-      return { error: true, retryable: true, message: `Server error (${response.status}).` };
+      // (#705) Read the provider's structured error body, the same way the 429
+      // branch above does, instead of discarding it.
+      //
+      // Measured on the whalecloud gateway: a prompt containing
+      // `new ProcessBuilder(args).start()` makes the gateway fail in its
+      // response-processing stage and return 500 with
+      //   {"error":{"type":"response_processing_error",
+      //             "param":"non_stream_chat_response","code":"500"}}
+      // The old code threw that away and reported "Server error (500).", which
+      // reads as a transient outage. `type`/`param` are what tell an operator
+      // apart gateway flapping vs. upstream timeout vs. content-triggered
+      // processing failure — three problems with three different responses.
+      //
+      // Retryability is the other half: a content-dependent failure cannot clear
+      // by retrying (the content did not change), so marking it retryable burns
+      // the orchestrator's retry budget on a guaranteed repeat. Only an
+      // explicitly recognised response_processing_error is demoted; every other
+      // 5xx keeps the previous retryable=true, and an unparseable body keeps the
+      // previous behaviour entirely — reading the body must not change the
+      // verdict on its own.
+      let detail = '';
+      let processingError = false;
+      try {
+        const body = await response.json();
+        if (body && body.error && typeof body.error === 'object') {
+          const type = typeof body.error.type === 'string' ? body.error.type : '';
+          const param = typeof body.error.param === 'string' ? body.error.param : '';
+          if (type === 'response_processing_error') {
+            processingError = true;
+          }
+          const parts = [type, param].filter(Boolean);
+          if (parts.length > 0) {
+            detail = ` Provider reported: ${parts.join('/')}.`;
+          }
+        }
+      } catch {
+        // body is not JSON; keep the previous behaviour untouched
+      }
+      if (processingError) {
+        return {
+          error: true,
+          retryable: false,
+          message: `Server error (${response.status}).${detail} This is a content-dependent upstream processing failure, so retrying the same prompt will fail the same way.`,
+        };
+      }
+      return { error: true, retryable: true, message: `Server error (${response.status}).${detail}` };
     }
 
     if (!response.ok) {

package/skills/delphi-review/AGENTS.md

@@ -1,9 +1,9 @@
 # SKILLS/DELPHI-REVIEW KNOWLEDGE BASE
 
 **Generated:** 2026-11-02
-**Commit:** 57ef51ed
+**Commit:** 8a968080
 **Branch:** main
-**Version:** 0.35.22.0
+**Version:** 0.35.23.0
 
 ## OVERVIEW
 Delphi Consensus Review — multi-round anonymous expert review (≥90% threshold, exactly 3 experts with distinct executable model IDs). Supports design, requirements, and code-walkthrough modes.

package/skills/sprint-flow/AGENTS.md

@@ -1,9 +1,9 @@
 # SKILLS/SPRINT-FLOW KNOWLEDGE BASE
 
 **Generated:** 2026-11-02
-**Commit:** 57ef51ed
+**Commit:** 8a968080
 **Branch:** main
-**Version:** 0.35.22.0
+**Version:** 0.35.23.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/skills/test-specification-alignment/AGENTS.md

@@ -1,9 +1,9 @@
 # SKILLS/TEST-SPECIFICATION-ALIGNMENT KNOWLEDGE BASE
 
 **Generated:** 2026-11-02
-**Commit:** 57ef51ed
+**Commit:** 8a968080
 **Branch:** main
-**Version:** 0.35.22.0
+**Version:** 0.35.23.0
 
 ## OVERVIEW
 Test-Specification Alignment Engine — two-stage validation ensuring tests accurately reflect requirements and design specs.