decomp-tu-slicinglisted
Install: claude install-skill tangosdev/sm64ds-decomp
# Translation-unit slicing
The linker erased the original `.cpp` boundaries; `tools/tu_map.py` reads them back
out. Full derivation and limits: `notes/tu-boundaries.md`. **To execute a merge and
verify it, use `decomp-tu-build`** — this skill is about reading the map, not acting
on it.
## 0. Regenerate the map, in this order
```sh
python tools/rtti_extract.py # -> build/rtti.json
python tools/rtti_vtables.py # -> build/rtti_vtables.json
python tools/tu_map.py # -> build/tu_map.json
```
`build/` is gitignored, so a fresh worktree has none of this.
**Nothing enforces that order, and skipping it fails silently.** `vtable_labels()`
returns `{}` when `build/rtti_vtables.json` is absent, and `tu_map.py` then writes a
complete, self-consistent, **wrong** map and exits **0**. Measured on `main` from an
empty `build/`:
| | full chain | `rtti_vtables.json` absent |
|---|---|---|
| whole-ROM TUs | 532 | 516 |
| boundaries | `{low: 68, medium: 110, high: 280}` | `{low: 72, medium: 124, high: 246}` |
| TUs with a class | 400/532 | 370/516 |
| under-segmented | ov007, main, ov075, ov084 | ov007, main, **ov005**, ov084 |
| ov080 | 5 TUs, 4 classed | **6 TUs**, 4 classed |
| `--check` | all gates PASS, exit 0 | **all gates PASS**, exit 0 |
The known-answer gate asserts ov080's *classed* TU count, which is 4 either way, so it
passes for the wrong reason. The under-segmented list is itself a casualty, so you
cannot use it to detect the problem either. The one visible t