Rongsong Shen
d26ff8870d
The buglog was one 27K-line JSON file whose fields covered only symptom,
root cause and fix, as free text: 2% of entries named the code version a
bug was found on, 12% the build profile, 36% a way to reproduce, and 58% of
the file was OpenWolf hook auto-detections ("Missing guard clause",
"Function not marked async" on .md files).
- .claude/skills/buglog/bug-record.md: the record standard. Eight
sections (Summary as the title, Description, Environment, Reproduction;
Root cause, Fix, Verification, References once fixed), each with the
content it must contain -- e.g. Environment needs the OS, the libc the
failing binary loads (from its ELF interpreter: glibc 2.42 in the nix
shell vs 2.40 on the host), toolchain, build profile and commit.
- .wolf/bugs/<id>.md: 500 records migrated from buglog.json; every field
verified to round-trip. They carry legacy: true and an explicit "not
recorded" where the old log had no such field; component derived from
file paths, severity from keywords (else unknown), fix_commits from
hashes in status_note/fix that git resolves (91 of 463 fixed).
- .wolf/buglog-archive.json: the 710 hook auto-detections, verbatim.
- .wolf/buglog.json is now an index generated from the records, keeping
the fields OpenWolf's hooks and `openwolf bug search` read.
- scripts/buglog.py rewritten: new (template + Environment collected from
the machine and --binary), check, status (refuses a status the record
doesn't support; fixed needs Root cause, Fix, Verification and
--commit hashes git resolves), note, recur, set, show, list, triage,
env, index. 29 unittest cases in scripts/tests/test_buglog.py.
- scripts/git-hooks/pre-commit runs `check --staged`: incomplete staged
records, a legacy record hand-changed to fixed without the fix-time
sections, a new record claiming legacy: true, or a stale index refuse
the commit.
- scripts/gitea-sync.py reads the records: issue body = the record's
sections plus linked fix commits (origin remote, GITEA_COMMIT_REPO to
override), and a body hash so an issue's text is refreshed when the
record changes.
- bug-1866 rewritten to the full standard as the worked example.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
4 KiB
| id | status | status_updated | status_note | component | severity | timestamp | last_seen | occurrences | files | tags | related | legacy | ||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| bug-1565 | fixed | 2026-09-24 | build | unknown | 2026-08-17T07:16:00.000Z | 2026-09-19T09:00:00Z | 1 |
|
|
true |
bug-1565: src/tools/xce-build.sh's setup_build() does an unconditional rm -rf "$BUILD_DIR" + fresh `meson…
Description
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.
Environment
Not recorded (migrated from buglog.json).
Reproduction
Not recorded (migrated from buglog.json).
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
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.
Verification
Not recorded (migrated from buglog.json).
References
Not recorded (migrated from buglog.json).