feat(buglog): one Markdown record per bug, checked against a record standard

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>

2026-09-28 03:40:11 +00:00

4.3 KiB

Raw Blame History

id status status_updated status_note component severity timestamp last_seen occurrences files tags related repro_attempts legacy gitea_issue gitea_synced_status

bug-1830

cannot-reproduce

2026-09-24

downgraded 07b5c989; user's own retest showed mem limit usage correctly

scheduler

unknown

2026-09-20T09:00:00Z

2026-09-20T09:30:00Z

src/scheduler/src/plugins/limit.c

scheduler

sim-mode

repl

limit-plugin

limit-matching

mem-resource

live-verification-finding

related-to-bug-1825

related-to-bug-1826

discovered-during-scheduler-sim-diagnostics-requirement-6-live-test

corrected

not-reproduced-by-user

needs-better-repro

bug-1825

bug-1826

user retest 2026-09-20, not reproduced

true

cannot-reproduce

bug-1830: CORRECTED 2026-09-20 (user's own independent retest) -- original framing was too strong

Description

CORRECTED 2026-09-20 (user's own independent retest) -- original framing was too strong. A mem-based limit (limits2, from the real src/configs/limits.yaml) DID correctly populate a live usage instance in a user-run retest: info limit limits2 against a real replay showed usage limit=limits2/u=rshen/q=xce/p= host=pc13v: accounted=18022400.000000 (17.19 MB) capacity=4635344384.000000 (4.32 GB) -- fully populated and correctly human-formatted on both accounted and capacity. This directly contradicts this entry's original claim that mem-based limits 'never' populate a usage instance via replay. ORIGINAL FINDING (retained for context, now understood to be narrower than stated): an earlier live-verification session (agent-run, single short-lived deploy+capture cycle) saw every mem-based limit show 'no active usage instance yet' while a slots-based limit in the same replay populated correctly. Given the user's retest succeeded, the real condition is likely session-shape/timing-dependent (e.g. elapsed replay rounds, WORKERS_PUSH arrival timing relative to job dispatch, or how long the recording ran) rather than a categorical mem-vs-slots failure.

Environment

Not recorded (migrated from buglog.json).

Reproduction

Attempts: user retest 2026-09-20, not reproduced

Root cause

Suspected, not confirmed: match_job_global_limit_()/match_job_host_limit_() (plugins/limit.c) key_find() the limit's constrained resource by name against core->resmgr at match time. For slots, this resource is always already present in core->resmgr from session start. For mem, the resource may only become known to core->resmgr via a WORKERS_PUSH replay event reporting the worker's live mem value -- if that push event is decoded/applied AFTER the job's own dispatch decision is replayed (or never lands in the resmgr in a way key_find() can see before the match attempt), the mem-based limit's match silently misses, leaving no xce_vres_t/usage instance ever created for it. test_sim_e2e_limit_visibility.c's own acceptance test (scheduler-sim-live-allocation task 5.2) only proves this works when the mem resource is hand-baked directly into the snapshot's resmgr BEFORE any replay event is processed -- it does not cover the ordinary real-deployment shape (resource known only via a live WORKERS_PUSH event that arrives as part of the replay stream itself, not pre-seeded in the snapshot). This needs direct tracing of match timing vs. WORKERS_PUSH application order in sim_loop.c's real round sequence to confirm.

Fix

STATUS DOWNGRADED to investigation-needed, not a confirmed defect. The original agent-run live test's single short capture window may not be representative -- the user's own longer/different retest shows mem-based limit usage population DOES work under real replay conditions. If this is ever seen to fail again, the reproduction needs to capture the SPECIFIC session shape that fails (replay round count, elapsed time between record-start and the job's dispatch, WORKERS_PUSH cadence) since a bare 'mem-based limits don't populate' framing has now been shown to be incorrect as a categorical claim. Not fixed because there is no longer a confirmed, reproducible defect to fix -- downgrading rather than closing, since the ORIGINAL single agent-run observation was real and unexplained, just not reproduced by the user's own retest.

Verification