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>
3.2 KiB
| id | status | status_updated | status_note | component | severity | timestamp | last_seen | occurrences | files | tags | related | legacy | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| bug-1576 | fixed | 2026-09-24 | unknown | unknown | 2026-08-18T03:15:00Z | 2026-09-19T09:00:00Z | 1 |
|
|
|
true |
bug-1576: Multiple interactive diagnostic Bash calls (pgrep -af "<pattern>", pkill -9 -f -- "<pattern>"…
Description
Multiple interactive diagnostic Bash calls (pgrep -af "<pattern>", pkill -9 -f -- "<pattern>", ps -eo pid,args | grep "<pattern>") unexpectedly matched -- and in one case SIGKILLed -- the CURRENTLY-RUNNING Bash tool call's own wrapper shell process, not just the intended target process(es). One instance: pkill -9 -f -- "rrv_dummy_marker_TEST1|..." killed the invoking Bash call itself mid-script, truncating all output after the pkill line with no further commands executing (looked like a mysterious 'exit code 1, script just stops' failure).
Environment
Not recorded (migrated from buglog.json).
Reproduction
Not recorded (migrated from buglog.json).
Root cause
This harness wraps every Bash tool invocation as roughly bash -c "... && eval '<the submitted script text>' < /dev/null && ...". The wrapper's own process argv (visible via /proc//cmdline and matched by pgrep -f/pkill -f/ps ... | grep) therefore contains the FULL LITERAL TEXT of the submitted script -- including any pattern string typed directly into that same script (e.g. inside the pgrep/pkill command's own quoted argument, or in an unrelated echo/comment). Any pgrep -f/pkill -f search run from within a Bash tool call will self-match (and, for pkill, potentially self-kill) that call's own wrapper process whenever the search pattern also appears as literal text anywhere else in the SAME submitted command block -- which is nearly unavoidable, since typing the pattern to search for IS typing it into the submitted script.
Fix
Not a code fix (methodology only). When diagnosing process state from an interactive Bash tool call: (1) prefer reading /proc//cmdline directly via a for p in /proc/[0-9]*; do ...; done scan and filtering in a way that doesn't require typing the exact search substring inline where it could also match the wrapper's own transcript (e.g. write the pattern to a variable/file first, or accept that the wrapper itself will show up as one extra line and visually distinguish it by its distinctive bash -c "source .../shell-snapshots/... && eval '...'" shape); (2) never assume a pgrep -f/pkill -f result of exactly 1 match confirms a target is unique -- it may be exactly 1 SELF-match with zero real matches; (3) for any pkill run interactively for diagnostic purposes (not from inside a dedicated script/process whose own argv doesn't contain the pattern), sanity-check the matched PID's ps -o cmd BEFORE trusting the pkill's effect, since a self-kill silently truncates the rest of that same Bash call with no distinguishing error message beyond a generic nonzero/truncated-output exit.
Verification
Not recorded (migrated from buglog.json).
References
- Related: bug-1575