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

.wolf/buglog.json

@@ -16712,7 +16712,7 @@
       "error_message": "src/tools/xce-build.sh's setup_build() does an unconditional `rm -rf \"$BUILD_DIR\"` + fresh `meson setup` for EVERY component case (controller, worker, xceadmin, etc), not just when actually needed -- running `/xce-build xceadmin` (or any single-component target) after `/xce-build controller` in the SAME build dir silently deletes the already-built xce_controller/xce_test/etc binaries, leaving only that one component's fresh output. Discovered live while enhancing /xce-deploy-ha: a working xce_controller from an earlier turn vanished after an unrelated `/xce-build xceadmin` run in the same xce.build dir, breaking a live-deploy test with 'No such file or directory' for the controller binary.",
       "file": "src/tools/xce-build.sh (setup_build)",
       "root_cause": "setup_build() (xce-build.sh, called at the top of every component case branch) always does `rm -rf \"$BUILD_DIR\"; meson setup \"$BUILD_DIR\" ...` before compiling -- a full wipe-and-reconfigure regardless of which single component was requested. Since `meson compile -C \"$BUILD_DIR\" <component>` only rebuilds that one target afterward, every OTHER previously-built target in the same dir (e.g. xce_controller, when the requested component was xceadmin) is gone until something explicitly rebuilds it too. Not investigated further / not fixed -- out of scope for the /xce-deploy-ha enhancement session that found it; flagged here for whoever owns xce-build.sh next. A likely fix direction: only rm -rf+reconfigure when MESON_OPTS actually differ from the existing build dir's recorded options (or on first setup / explicit request), otherwise just `meson compile -C \"$BUILD_DIR\" <target>` against the existing configured dir.",
-      "fix": "NOT FIXED -- discovery only, flagged for follow-up. Workaround used this session: run `/xce-build all` (or rebuild every needed component together) instead of single-component invocations when multiple binaries in the same build dir are needed simultaneously.",
+      "fix": "FIXED (opt-in, not a default-behavior change). Added --incremental to xce-build.sh (parsed out of the argument list before the existing component/profile/build_dir positional parsing, so it can appear anywhere and never disturbs that parsing). When passed AND the target build dir already has a build.ninja (i.e. it's already configured), setup_build() runs `meson setup --reconfigure \"$BUILD_DIR\" \"${MESON_OPTS[@]}\"` in place instead of `rm -rf` + fresh `meson setup` -- preserving any other already-built component's binaries in that dir. First-ever build of a dir (no build.ninja yet) still does a normal fresh setup regardless of the flag, since there's nothing to reconfigure. Default (flag omitted) is completely unchanged -- still always wipes. Deliberately NOT made the default: the known missing-dependency-edge races in the capnp-generation custom_target (see recurring buglog entries on 'controller.capnp.h: No such file or directory') are papered over by always wiping (worst case: a loud, retry-fixable clean-build failure); without the wipe the same gap could instead cause SILENT staleness (a schema edit not triggering regeneration, build reports success against stale generated code) -- an --incremental caller is explicitly opting into that tradeoff. Live-validated: built controller (xce_controller present), then `xceadmin --incremental` (wheel built, xce_controller's mtime unchanged -- survived); confirmed the flag works regardless of argument position (`--incremental xceadmin` and `xceadmin --incremental` both work); confirmed the DEFAULT (no flag) still wipes as before (xce_controller correctly gone after a plain `xceadmin` rebuild). Also updated the /xce-build skill and build-deployment.md steering doc to document the new flag.",
       "tags": [
         "xce-build.sh",
         "build-tooling",
@@ -16755,6 +16755,54 @@
       "related_bugs": [],
       "occurrences": 1,
       "last_seen": "2026-08-17T08:03:27.006Z"
+    },
+    {
+      "id": "bug-938",
+      "timestamp": "2026-08-17T08:18:40.345Z",
+      "error_message": "Significant refactor of ",
+      "file": ".claude/skills/xce-build/SKILL.md",
+      "root_cause": "4 lines replaced/restructured",
+      "fix": "Rewrote 11→12 lines (4 removed)",
+      "tags": [
+        "auto-detected",
+        "refactor",
+        "md"
+      ],
+      "related_bugs": [],
+      "occurrences": 1,
+      "last_seen": "2026-08-17T08:18:40.345Z"
+    },
+    {
+      "id": "bug-939",
+      "timestamp": "2026-08-17T08:19:13.328Z",
+      "error_message": "Wrong operator: && should be <<",
+      "file": ".claude/skills/xce-build/SKILL.md",
+      "root_cause": "Used \"&&\" instead of \"<<\"",
+      "fix": "Changed operator && → <<",
+      "tags": [
+        "auto-detected",
+        "operator-fix",
+        "md"
+      ],
+      "related_bugs": [],
+      "occurrences": 1,
+      "last_seen": "2026-08-17T08:19:13.328Z"
+    },
+    {
+      "id": "bug-940",
+      "timestamp": "2026-08-17T08:19:30.812Z",
+      "error_message": "Incorrect value in code",
+      "file": ".kiro/steering/build-deployment.md",
+      "root_cause": "Had 're gone until something explicitly rebuilds them ",
+      "fix": "Changed to 're gone until something explicitly rebuilds them ",
+      "tags": [
+        "auto-detected",
+        "wrong-value",
+        "md"
+      ],
+      "related_bugs": [],
+      "occurrences": 1,
+      "last_seen": "2026-08-17T08:19:30.812Z"
     }
   ]
 }