Identify the container the class tables point into: core_data itself

assets_compressed_size and assets_decompressed_size at index offsets
0x88 and 0x8c are 9,738,678 and 16,969,296 on level 0 -- exactly the
sizes of core_data before and after decompression. There is no separate
asset container. The "asset WAD" is core_data, and offset_in_asset_wad
indexes the decompressed form directly.

Checked rather than assumed, on all 27 levels: the decompressed size
equals core_data's exact length, every class offset is either 0 or inside
it, and the moby, tie and shrub spans do not overlap each other.

An offset of 0 means the slot has no geometry, not the start of the
lump; level 0's ninth moby class is 4909 at offset 0. Two assumptions
worth discarding while here -- the tables are not sorted by class number
(level 0's run 0, 1, 2, 14 ... 4909) and the offsets within a table are
not monotonic. Neither is needed, but both look true from the first few
entries.

The chunk descriptors after the named extents are not it: they exist on
only 3 of 27 levels, because level 0's four named extents tile the
container exactly. An asset blob there would be missing almost
everywhere.

What sits at the offsets is raw GS/VIF packet data rather than a further
container -- moby[0] begins 00 00 00 00 3f 16 02 55 6f 6f and tie[0]
00 01 00 00 70 50 00 00, which read as packet headers rather than a
magic number.

None of the three is decoded yet and this does not start that. Moby is
skeletal and is the largest single piece left before the rest of a level
can draw.

Also: the pipeline now writes each level's chunk descriptors where they
exist, and LevelCoreHeader decodes the asset lump's two sizes.

docs/plan/level-assets.md

@@ -562,6 +562,37 @@ tfrag record framing was "unrecoverable" because the entry size was never
 known. Both looked like properties of the format and were properties of the
 question.
 
+### Where the class tables point
+
+`assets_compressed_size` and `assets_decompressed_size` at index offsets 0x88
+and 0x8c are 9,738,678 and 16,969,296 on level 0 -- exactly the sizes of
+`core_data` before and after decompression. There is no separate asset
+container: the "asset WAD" *is* `core_data`, and `offset_in_asset_wad` indexes
+the decompressed form directly.
+
+That is checkable rather than merely plausible, and a test checks it on all 27
+levels:
+
+* `assets_decompressed_size` equals `core_data`'s exact length;
+* every class offset is either 0 or inside `core_data`;
+* the moby, tie and shrub spans do not overlap each other.
+
+An offset of **0 means the slot has no geometry**, not the start of the lump.
+On level 0 the moby table's ninth entry is class 4909 at offset 0.
+
+Two assumptions worth discarding: the tables are **not** sorted by class number
+(level 0's moby classes run 0, 1, 2, 14, ... 4909), and the offsets within a
+table are **not** monotonic. Neither is needed, but both look true from the
+first few entries.
+
+The chunk descriptors after the named extents are not it. They exist on only
+3 of 27 levels -- level 0's four named extents tile the container exactly --
+so an asset blob there would be missing almost everywhere.
+
+At the offsets sit raw GS/VIF packet data, not a further container: moby[0]
+begins `00 00 00 00 3f 16 02 55 6f 6f`, tie[0] `00 01 00 00 70 50 00 00`,
+which read as packet headers rather than a magic number.
+
 ### Why the frame is still dark: the light bank does not parse on RAC2
 
 The reference frames the bank as "a u32 offset at +0x04, then an `i32` count
@@ -659,9 +690,11 @@ the fidelity rule.
 - **Lighting magnitudes.** The pass runs and the output is plausible; whether
   it matches the game needs comparison against reference frames, which needs
   the PCSX2 loop that is still to come. Nothing in this file establishes it.
-- **tie, moby and shrub geometry.** The class tables now parse (below), but
-  nothing reads the geometry they name yet. `offset_in_asset_wad` points into
-  the level's asset WAD, which is a separate container.
+- **tie, moby and shrub geometry.** The class tables parse and the container
+  they point into is identified (below), but none of the three is decoded yet.
+  Moby is the largest of the three and is skeletal, with an animation evaluator
+  in the microcode; it is the single biggest piece left before the rest of a
+  level can draw.
 - **Point lights** are spawned by gameplay at runtime and are absent from the
   disc -- every one of the 18,102 patches has `point_lights == 0xffff` -- so
   there is nothing for them to light until the game runs.

docs/roadmap.md

@@ -14,8 +14,9 @@ early, while they are still cheap to retire.
 - [x] Repository hygiene in place (pre-commit guard, `.gitignore`, licence
       record)
 - [x] **Phase 1 complete.** The disc pipeline runs end to end and is verified
-      against a committed hash table: 5,213 files, 5,795,847,447 bytes, every
-      one of the 92 asset containers parsing.
+      against a committed hash table, every one of the 92 asset containers
+      parsing. The pipeline now also writes each level's chunk descriptors
+      where they exist (3 of 27 levels).
 - [x] **Phase 2 in progress.** Level containers are parsed through their typed
       header, and the `data` extent is parsed as a container of byte ranges. The
       geometry decompresses: level 0 yields 16,969,296 bytes of level content