mirror of
https://github.com/Druthulu/BFM-decomp
synced 2026-10-01 23:52:03 -04:00
Drew T
12631df74a
Drew asked whether the x133 sweep blocker warrants a gcc-2.7.2 source read. It does not, and the distinction is worth pinning down because it routes every future residual: - The sweep blocker is a C FRONT-END diagnostic (conflicting types: two incompatible file-scope decls of one identifier in one TU). gcc is correctly rejecting plain C89. The bug is in reconcile_decls (fleet-majority oracle vs the TU's visible decl). Reading cse.c/loop.c/global.c would tell you nothing. - func_8017BEBC (close=2) is the opposite: it compiles fine and emits the wrong bytes, and the cause is localized to global.c's allocno-priority tie. THAT is the R17/§45-B target (gdb-on-cc1 read of allocno_live_length) — 2 instructions from a 107K-ins bank. Rule: 'wrong BYTES' -> read the compiler (R17). 'won't COMPILE' -> read our Python. cookbook §31-triage + the CURRENT_PHASE NEXT block annotated with the routing.
phase-ends/ — the living record
PhaseEnd_Phase[N].md— written at each phase boundary (format defined inPROJECT_CONTEXT.md). Append-only history: build log, deviations, commit message, rules added, changelog. Never deleted.CURRENT_PHASE.md— the in-phase autonomous log: approved phase plan, per-task checkboxes, current task pointer, blockers. Created at phase start, updated after every task, absorbed into the PhaseEnd file and deleted at phase close. This is the crash/compaction recovery point.- Sessions read
PROJECT_CONTEXT.md, then everyPhaseEnd_*.mdin numeric order, thenCURRENT_PHASE.md(if present) — in that order, every session.