From fd5ab8b20d7e6585d6e6d6d243ed28c4580e8956 Mon Sep 17 00:00:00 2001
From: Rongsong Shen <rshen@shenrs.eu>
Date: Tue, 18 Aug 2026 00:46:50 +0000
Subject: [PATCH] chore(wolf): checkpoint buglog.json (952 bugs)

---
 .wolf/buglog.json | 25 ++++++++++++++++++++++---
 1 file changed, 22 insertions(+), 3 deletions(-)

diff --git a/.wolf/buglog.json b/.wolf/buglog.json
index daed4c55..ace4dc24 100644
--- a/.wolf/buglog.json
+++ b/.wolf/buglog.json
@@ -16211,8 +16211,8 @@
       "related_bugs": [
         "bug-1559"
       ],
-      "occurrences": 1,
-      "last_seen": "2026-08-15T22:54:35Z"
+      "occurrences": 2,
+      "last_seen": "2026-08-17T00:00:00.000Z"
     },
     {
       "id": "bug-909",
@@ -16316,7 +16316,7 @@
         "bug-1470",
         "bug-1553"
       ],
-      "occurrences": 3,
+      "occurrences": 4,
       "last_seen": "2026-08-17T00:00:00.000Z"
     },
     {
@@ -17018,6 +17018,25 @@
       ],
       "occurrences": 1,
       "last_seen": "2026-08-17T23:45:00Z"
+    },
+    {
+      "id": "bug-1571",
+      "timestamp": "2026-08-17T00:00:00.000Z",
+      "error_message": "apiserver logs \"Backend not configured -- running in stub mode\" and never calls RegisterToBackend, even though the generated app.yaml backend.peers list is fully populated with a valid HA candidate list.",
+      "file": "src/tools/deploy-ha.sh",
+      "root_cause": "resource-value-verification task 3.1 (xce-deploy-ha apiserver step): the new deploy-ha.sh Step-3 apiserver-config generation block initially wrote backend.address: \"\" and backend.port: 0 in the generated app.yaml, reasoning that backend.peers (non-empty) takes priority over address/port inside RegisterToBackend per backend/config.go's own doc comment. That reasoning only covers WHICH candidate RegisterToBackend picks once called -- it does not cover WHETHER it is called at all. apiserver/cmd/main.go:58 gates the entire RegisterToBackend call behind `BackendYamlConfig.Address != \"\"`, checked before Peers is ever consulted. A blank address left the apiserver permanently in stub mode regardless of a fully-populated peers list. Caught live during this task's own scenario-B verification run (grep of apiserver.log showed the stub-mode line instead of the expected \"Backend connection established\").",
+      "fix": "deploy-ha.sh's apiserver app.yaml generation now also populates backend.address/backend.port from the first --peers candidate (host/port split via bash parameter expansion) alongside the full backend.peers list, so main.go's gate passes and RegisterToBackend still uses the full peers candidate list for actual connection/failover. Re-verified live: apiserver.log now shows \"Attempting backend connection\" / \"Backend connection established\" / \"Backend connection registered!\".",
+      "tags": [
+        "apiserver",
+        "deploy-ha",
+        "xce-deploy-ha",
+        "backend-config",
+        "go",
+        "resource-value-verification"
+      ],
+      "related_bugs": [],
+      "occurrences": 1,
+      "last_seen": "2026-08-17T00:00:00.000Z"
     }
   ]
 }