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>
2.3 KiB
| id | status | status_updated | status_note | component | severity | timestamp | last_seen | occurrences | files | tags | related | legacy | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| bug-1628 | fixed | 2026-09-24 | unknown | unknown | 2026-08-23T08:03:59 | 2026-09-19T09:00:00Z | 1 |
|
|
|
true |
bug-1628: date: invalid date '-6 days' / date: invalid date '2026-06-29 +5 days' -- relative date arithmetic…
Description
date: invalid date '-6 days' / date: invalid date '2026-06-29 +5 days' -- relative date arithmetic silently yields EMPTY shell variables, and the empty values then flow into git log --since="" --until="", which git treats as NO time filter (unbounded history) instead of erroring.
Environment
Not recorded (migrated from buglog.json).
Reproduction
Not recorded (migrated from buglog.json).
Root cause
date first on PATH in this harness is BusyBox v1.36.1 (/nix/store/...busybox-1.36.1/bin/busybox), NOT GNU coreutils, even though /bin/date IS coreutils 9.8 -- the nix profile bin dir precedes /bin. BusyBox date supports absolute parsing (date -d 2026-06-29 +%A works, which is what masked the problem during initial probing) but has no GNU relative-expression support ('-7 days', 'last monday', '+5 days'). Because command substitution captures only stdout and BusyBox writes 'invalid date' to stderr, $START/$END come back as empty strings and the failure is invisible to a non -e script. Same BusyBox-shadows-GNU family as bug-1606 (grep -P) and bug-1617 (mktemp template).
Fix
Do all date arithmetic in python3 (/bin/python3, always present) instead of date -d: compute week start via today - timedelta(days=today.weekday()) - timedelta(weeks=offset) and emit START=/END=/SLUG= lines consumed by eval "$(python3 - ... <<'PY' ... PY )". General rule: never use date -d with a relative expression in this environment; use python3 datetime, or call /bin/date by absolute path if GNU date is genuinely required. Also validate that computed date vars are non-empty before feeding them to git log --since/--until, since git silently ignores empty range args rather than failing.
Verification
Not recorded (migrated from buglog.json).
References
- Related: bug-1606, bug-1617