# 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).