BFM-decomp/rules/L3.md

L3 — decomp-accelerator-ledger

id: L3 · group: - · status: active · tags: legacy,memory · origin: legacy memory decomp-accelerator-ledger.md · added: 2026-09-29

Drew (2026-08-07): we are building a Claude Code decomp workflow to reuse after BFM ships. So whenever something is found that would have made a lot of previous work much faster had we known it sooner, record it — what it is, when we found it, when we could have, and what it would have saved — in docs/accelerators.md. A new decomp project should get that wisdom on day one instead of at phase 23.

Why: this project repeatedly found its biggest levers late (the byte-gate harvest at phase 12, dedup propagation at 11–15, the gcc codegen map at 23, the tracker's addressing blind spot at 30). The per-phase PhaseEnds record what happened; they do not answer "what should phase 1 of the NEXT game do differently." That is a separate, deliberately-maintained artifact.

How to apply: when a discovery lands, ask "would this have changed earlier work?" If yes, add an entry the same session (R30 timing). Distinguish honestly between a lever that was available earlier and one that structurally could not exist yet (needed the fleet onboarded, the compiler pinned, etc.) — the second kind belongs in the ledger too, marked, because its prerequisite is the real advice.

Feeds project-endgame-deliverables (the public "how to AI-decomp" wiki) alongside docs/decision-log.md (R31, the why-behind-pivots).