Grind

3. Codegen-correctness mandate (non-negotiable)

Whistler emits code the BPF verifier must accept and the kernel must run correctly. Two disciplines protect that:

1. Preserve the pass invariants. Any op that modifies state must be in ir-insn-side-effect-p (stores, calls, tail-call, struct-alloc, branches) or DCE will silently delete it. Any call-like op (map-lookup, map-lookup-ptr, tail-call, …) must be in regalloc's call-positions list or R1–R5 clobbering corrupts live values. Peephole passes are order-dependent. A violation here is exactly a silent miscompile — treat it as the top-priority failure mode.
2. Keep the shared definitions single-source. Helpers, constants, builtins, and the kfunc registry live in compiler.lisp; lower.lisp, the bpftrace frontend, and the loader reference them, never copy. When you change a kfunc/helper/reloc, update the one registry and confirm both load paths still patch it (ELF loader patch-kfunc-relocations, session session-load-progs).

Prove it before committing on any codegen path you touched:

• Compile and inspect the output. Regenerate the affected example and read the disassembly (whistler::disassemble-cu on the compilation-unit from compile-to-elf). For codegen changes, compare instruction counts and disassembly against the prior output — a count that went up unexpectedly, or a changed instruction you can't explain, is a regression until proven otherwise.
• Run the suites (§5). A green make test plus a clean disassembly diff is the cheapest evidence a codegen change is correct.
• Load it into the kernel when the change can affect what the verifier sees — make test-torture actually loads compiled programs (needs CAP_BPF). Use /usr/bin/sbcl (it carries the BPF caps), not the Homebrew SBCL, for any kernel-load test.

An unexplained instruction-count change, a verifier rejection under torture, or a relocation the loader no longer patches means you broke something — find it before committing.

4. Reprioritize the queue

Make the decision legible by aligning priorities with the rubric — before you start coding:

• Raise correctness/miscompile bugs and critical-path/goal work that are currently underranked; lower speculative or off-goal items. bd update <id> --priority N.
• Leave a one-line bd comment on anything you re-rank, saying why (e.g. "raise: verifier-reject on the tail-call path" / "lower: cosmetic, off critical path"). Keep churn minimal — reprioritize to reflect the plan, not to reshuffle the whole board.
• File newly discovered work as Beads immediately (never a // TODO or a mental note): bd create "…" -t bug|task -p N. Model blockers with bd dep add.

5. Execute end-to-end

bd update <id> --claim

1. Implement the smallest correct change. Match surrounding code idiom; keep the shared definitions in compiler.lisp authoritative (§3).
2. Rebuild (make); drive the affected flow and observe the result (the /verify discipline) — compile the relevant example and read its disassembly, don't trust tests alone. Wrong-code bugs demand you see the right instructions now.
3. Run the suites:

   make test               # FiveAM (whistler/tests)
   make bpftrace-parse-test # when the bpftrace frontend is touched
   make test-torture       # kernel-load, needs CAP_BPF (use /usr/bin/sbcl)

   For codegen changes, also compare instruction counts and disassembly against the pre-change output (§3).
4. Commit with an imperative subject citing the bead id and a note on what codegen/verifier behavior you confirmed; end the message with: Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
5. bd close <id> with the commit hash and what was verified (tests green, disassembly diff, kernel-load result); bd sync. git push only when the user asks. If not on a branch and about to commit, branch first.

6. Loop or hand off

Report: what you picked and why (the rubric line it satisfied), the change, how you verified it (tests, instruction-count/disassembly diff, and any kernel-load evidence), what you re-ranked, and any new Beads filed. Then pick the next task (repeat) until told to stop or the queue has no tractable correctness/goal work left — at which point say so plainly rather than inventing busywork.