mirror of
https://github.com/Druthulu/BFM-decomp
synced 2026-10-05 00:47:54 -04:00
Drew T
21 lines
1.5 KiB
Markdown
21 lines
1.5 KiB
Markdown
# 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).
|