Files

T

arcattackandClaude Opus 4.8 f914fc040a context-system: complete migration -> CLAUDE.md is now a 160-line router (zero context lost)

Full migration of the 2236-line monolithic CLAUDE.md into the progressive-context
knowledge graph (per spark-lesson / expert-seed.md), so the deep RE knowledge loads
on-demand instead of every session.

ZERO CONTEXT LOST:
- docs/PROGRESS_LOG.md = the complete old CLAUDE.md, VERBATIM (byte-identical) -- the
  lossless safety net + the "full detail" quick-lookup fallback.
- 18 context/*.md topic files (1343 lines) digest every section (§1-3 -> project-overview,
  §4 -> content-archives, §5 -> asset-formats/bgf-format, §5a -> source-completeness,
  §5b/§8 -> wintesla-port, §7/§10 -> locomotion, §10a -> build-and-run, §10b ->
  reconstruction-method, §10c -> combat-damage + reconstruction-gotchas, §10d -> subsystems,
  render notes -> rendering, gauges -> gauges-hud, MP -> multiplayer, §9 -> open-questions).
- reference/glossary.yaml (53 terms). decomp-reference.md = the offsets/ClassIDs/addresses hub.

CLAUDE.md (160 lines) = router: identity, answer/reason protocols, quick-lookup table,
evidence tiers (T0 engine-truth / T1 decompiled+verified / T2 reconstructed+runtime /
T3 guarded / T4 hypothesis), conventions + DO-NOT (the systemic bug classes), structure.
Retains the load-bearing work directives (build recipe pointer, "keep current" mandate).

Knowledge graph validates CLEAN (scratchpad/checkctx.py -- all [[links]] + quick-lookup +
docs refs resolve; [[name]] -> topic file or glossary term). docs/*.md ledgers stay as the
detailed logs; context/*.md are the curated digests that route into them.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

2026-07-07 22:19:50 -05:00

3.5 KiB

Raw Blame History

id, title, status, source_sections, related_topics, key_terms

title

status

source_sections

related_topics

key_terms

reconstruction-method

Reconstruction Method — the loop, the no-stand-ins rule, decomp technique

established

PROGRESS_LOG.md §10b, §5a (decompilation), §10c

reconstruction-gotchas

decomp-reference

source-completeness

decomp

oracle

bridge

BTL4OPT

WinTesla

Reconstruction Method

How the missing BT game logic is rebuilt from the binary. The governing rule: no stand-ins. Full detail: docs/PROGRESS_LOG.md §10b; the systemic bug classes are reconstruction-gotchas.

The loop (per feature)

Read the RAW decomp reference/decomp/all/part_*.c for the relevant FUN_xxxx.
Map FUN_/DAT_/this+0xNN to engine symbols using: the BT headers + the WinTesla MUNGA source + game/reconstructed/CLASSMAP.md + RP's parallel code (VTV≈mech, WEAPSYS≈weapons).
Write the real reconstruction into game/reconstructed/*.cpp.
Build; run env-gated; read btl4.log (grep [anim]/[drive]/[target]/[fire]/[damage] markers).
cdb on any crash. static_assert-lock the layout against the binary's offsets. [T2]

RULE: no stand-ins

The full game logic IS in the pseudocode (the binary ran the game); a "gap" is a reconstruction stub not yet filled, not a hole in the original. Never write stand-in/placeholder logic for an apparent gap — read the decomp. (User: "there are no gaps, just work to be done.") Bring-up scaffolding (env-var paths, explosion-for-beam, a player-gated drive) is clearly MARKED and meant to be REPLACED by the real reconstructed system, never to substitute for reading the decomp. [T2]

Decompilation stack (Plan B — in progress)

Ghidra 12.1.2 + JDK21 installed under tools/ (portable). ExportBTSource.java run headless on BTL4OPT.EXE → real decompiled C in reference/decomp/recovered/. The pass is assert-anchored (few funcs/file — anchored on the asserts that carry source paths). [T2]
For a FUN_ the assert-anchored exporter skipped: tools/disas2.py <VA> [len] (capstone disassembly of BTL4OPT.EXE — recovers x87 math Ghidra drops, folds known calls + float constants). Or DecompVSS.java (headless address-list decompiler). [T2]
Resolving a .data fn-pointer (a PTR_LAB_xxxx callback/vtable slot the decomp didn't export): PE-parse the DWORD at its VA, then capstone-disassemble the target. Used for the gait callbacks (@0x4a6d8c), the valve handler (@0x4ae464), gauge widget slots. [T2]
.data float constants are the biggest "couldn't recover" bucket (tuning values); read them as the x87 80-bit float10 the decomp uses, not 32-bit float (scratchpad/rdtbyte.py). [T2]

Effort model (honest)

~0.5-1.5 hr/module → ~30-50 agent-hours + human review for ~40 modules, with a long tail (modules with no surviving .HPP fragment, or split across decomp windows, cost more). Process upgrades: per-class function lists (not address clusters), complete vtable rows, recover .data constants. [T3]

Workflows (for scale)

For exhaustive multi-function decomp analysis, fan out a read-only Workflow (understanding phase — one agent per function/class produces an offset map + findings, + an adversarial verify), THEN implement hands-on so each change is visible + consistent. This is the §10c pattern; used for the ground-model decode (10 agents), the alarm-unification (8), the gauge-widget decode (6). [T2]

Key Relationships

Bug classes: reconstruction-gotchas (check FIRST). Reference data: decomp-reference.
Why it's needed: source-completeness.

3.5 KiB Raw Blame History