chore(wolf): checkpoint buglog.json (989 bugs)

.wolf/buglog.json

@@ -17848,6 +17848,68 @@
       ],
       "occurrences": 1,
       "last_seen": "2026-08-20T10:27:00.000Z"
+    },
+    {
+      "id": "bug-1606",
+      "timestamp": "2026-08-20T16:00:00Z",
+      "error_message": "grep: invalid option -- 'P' (BusyBox usage dump) when a standalone .sh script (run via `bash script.sh`, not typed as an inline Bash-tool command) calls `grep -oP '...\\K...'`",
+      "file": "src/tools/test-version-startup-consistency.sh",
+      "root_cause": "This coding-agent harness's interactive shell shadows plain `grep` with a `.bashrc`-sourced shell FUNCTION that shells out to a PCRE-capable (ugrep-backed) binary -- but that function is interactive-shell-only and is NOT inherited by a script invoked as `bash script.sh` (a separate, non-interactive process), which falls back to the real `grep` on PATH: BusyBox in this environment, with no -P/PCRE support at all. `grep -oP '(?<=x)y'` typed directly as a Bash-tool command therefore worked fine, masking the incompatibility until the same call was placed inside a committed script file and run standalone.",
+      "fix": "Replaced the grep -oP '\"gitCommit\":\\s*\"\\K[^\"]*' style extraction with POSIX BRE `sed -n 's/.*\"gitCommit\":[[:space:]]*\"\\([^\"]*\\)\".*/\\1/p'`, which BusyBox sed supports. General rule: any shell script meant to be run standalone (not just typed inline) must assume POSIX-only grep/sed (BRE, -E, -F, -o) -- no -P/PCRE, no lookbehind/\\K.",
+      "tags": [
+        "bash",
+        "grep",
+        "busybox",
+        "sandbox",
+        "portability",
+        "sed",
+        "build-time-versioning"
+      ],
+      "related_bugs": [],
+      "occurrences": 1,
+      "last_seen": "2026-08-20T16:00:00Z"
+    },
+    {
+      "id": "bug-1607",
+      "timestamp": "2026-08-20T16:15:00Z",
+      "error_message": "`git status` showed src/frontend/apiserver/go.sum modified (+65 lines) after a direct `go build ./cmd/main.go` invocation that never touched go.mod and produced a successful, working binary -- no warning or error printed by the build itself",
+      "file": "src/frontend/apiserver/go.sum",
+      "root_cause": "A plain `go build` (default `-mod` setting, `go env GOFLAGS` confirmed empty) blocks go.mod EDITS under Go 1.16+'s readonly-by-default policy, but does NOT by itself block go.sum EXTENSION for modules already implied by go.mod's requirements -- resolving the full module graph for cgo-enabled apiserver added ~65 unrelated indirect-dependency /go.mod-hash-only lines to the committed go.sum as a silent side effect.",
+      "fix": "Pass `-mod=readonly` explicitly on every direct `go build` invocation against this repo (src/tools/test-version-startup-consistency.sh's apiserver build step). Confirmed live: the identical build still succeeds under explicit -mod=readonly with zero go.sum diff, so nothing was genuinely missing -- the extra entries were pure side effect of the laxer default. Reverted the accidental go.sum change via `git checkout -- src/frontend/apiserver/go.sum` before re-running with the fix.",
+      "tags": [
+        "go",
+        "go.sum",
+        "go-modules",
+        "build",
+        "side-effect",
+        "build-time-versioning"
+      ],
+      "related_bugs": [],
+      "occurrences": 1,
+      "last_seen": "2026-08-20T16:15:00Z"
+    },
+    {
+      "id": "bug-1608",
+      "timestamp": "2026-08-20T15:57:00Z",
+      "error_message": "`xce-build.sh apiserver <profile> <dir>` (meson -> go_build custom_target) hung indefinitely (8-10+ minutes, zero progress) building xcecli's Go dependencies; no error, no timeout, just stuck",
+      "file": "src/tools/go_build",
+      "root_cause": "go_build hardcodes `GOPROXY=https://goproxy.cn` plus a FRESH, per-invocation GOCACHE/GOPATH under meson's own $TMPDIR sandbox, bypassing the shell's already-populated default $GOPATH/pkg/mod module cache entirely. Confirmed via `ss -tnp` that the resulting `go` process had an ESTABLISHED (not refused/reset) TCP connection to 8.45.176.179:443 (=goproxy.cn, independently reachable fine via plain curl/`/dev/tcp` from the same shell) sitting in futex_do_wait with near-zero CPU time -- a genuinely stuck data path in this sandbox's networking for that specific fresh-cache+custom-GOPROXY combination, not mere slowness (never progressed no matter how long left running across 3 separate attempts). A plain `go list -m all` from an ordinary `nix develop` shell (no wrapper, default cache) resolved the identical apiserver module graph in under a second.",
+      "fix": "Workaround only (go_build/Makefile NOT modified -- this is a sandbox-specific networking quirk, not a real defect in those files, and out of this task's scope to fix): for a standalone real apiserver/xcecli build in this sandbox, invoke `go build` directly against the default (already-populated) module cache with `GOPROXY=off` plus the same CGO_CFLAGS/CGO_LDFLAGS pkg-config derivation apiserver's own meson.build/test-backend already use (see bug-1597's documented fix for the exact derivation), instead of routing through xce-build.sh apiserver / go_build / make build-server. Diagnose a suspected hang via `ss -tnp` + `/proc/<pid>/wchan` before assuming it just needs more time.",
+      "tags": [
+        "go",
+        "go_build",
+        "goproxy",
+        "network",
+        "hang",
+        "sandbox",
+        "meson",
+        "build-time-versioning"
+      ],
+      "related_bugs": [
+        "bug-1597"
+      ],
+      "occurrences": 1,
+      "last_seen": "2026-08-20T15:57:00Z"
     }
   ]
 }