re: the challenge LOD extras are meshes in that stage's own .xpr - 11 of 11

Perfect diagonal. Each of stg24_01..04, stg26_01..03, stg27_01..02 and
stg29_01..02 appears in Stage_S<NN>.xpr and in no other stage package. So a
challenge stage's bespoke LOD/model table exists to declare the handful of
scenery meshes packaged with that stage, consistent with xbg7-mesh's account of
a stage .xpr as a bag of XBG7 resources.

stg24_04 is a composite: 22 occurrences resolve as 1 bare + 1 _all + 20 _child.
Every other stg* name occurs exactly once.

rou_f004 is NOT in Stage_S28.xpr - it is in DeltaSaber_A.xpr. S28's LOD table
declares the craft but the mesh ships in the player-craft package, confirming
from the ISO side that _A is the f004 variant: the stage package carries
scenery, the craft comes from its own file. rot_n001_break resolves too, in
Tutorial.xpr and Stage_S28.xpr, matching exactly the tables that list it.

The orphan tables' unique effects only partly resolve: eff_e0033 is present in
Base.xpr, but eff_e0058 and eff_n0071 appear in NO .xpr on the disc. So the six
abandoned LOD tables name at least two effects that were never packaged - the
same "declared, never shipped" shape as S14's asteroid meshes, on a much smaller
scale.

Method caveats recorded in the doc: these are byte searches over .xpr files, not
parsed resource-table reads. They establish presence, not an enumeration, and
are acceptable only because the names are long and distinctive and the match was
expanded to the full trailing token. Also grep -c counts LINES, not occurrences;
the counts above come from grep -o | wc -l after that was caught.

All fifteen artefacts byte-identical.

docs/re/BACKLOG.md

@@ -6530,3 +6530,32 @@ family has **10 distinct keys**, and the unreferenced set is **S01, S02, S16 ×
 `rou_e106_*` boss parts (cf. `stage16-boss`). The live table is **not** a
 superset of the abandoned ones. `Tutorial` has the same shape: 66 fields, 3
 unique.
+
+---
+
+## ✅🟡 2026-08-28 — the challenge LOD extras are meshes in that stage's own `.xpr`
+
+Item (a).
+
+✅ **Perfect diagonal, 11 of 11.** Each `stg24_01…04`, `stg26_01…03`,
+`stg27_01…02`, `stg29_01…02` appears in `Stage_S<NN>.xpr` and **no other** stage
+package. A challenge stage's bespoke LOD/model table exists to declare the
+scenery meshes packaged with that stage.
+
+🔑 **`stg24_04` is a composite** — 22 occurrences resolve as **1 bare + 1 `_all` +
+20 `_child`**; every other `stg*` name occurs exactly once.
+
+🔑 **`rou_f004` is not in `Stage_S28.xpr` — it is in `DeltaSaber_A.xpr`.** S28's
+table declares the craft but the mesh ships in the player-craft package,
+confirming from the ISO side that `_A` is the `f004` variant. `rot_n001_break`
+resolves in `Tutorial.xpr` and `Stage_S28.xpr` — exactly the tables listing it.
+
+🟡 **The orphans' unique effects only partly resolve**: `eff_e0033` is in
+`Base.xpr`, but **`eff_e0058` and `eff_n0071` are in no `.xpr` on the disc** — the
+same "declared, never shipped" shape as S14's asteroid meshes, much smaller.
+
+⚠️ Method caveats recorded: these are **byte searches over `.xpr`**, not parsed
+resource enumerations — they show presence only, and are acceptable here because
+the names are long, distinctive, and matched to the full trailing token. Also
+**`grep -c` counts lines, not occurrences**; the counts come from
+`grep -o | wc -l` after that was caught.

docs/re/structures/stage-mission-tables.md

@@ -368,3 +368,40 @@ entries `_test` does not have**: `LOD_Effect_eff_e0033`, `_e0058`, `_e0059`,
 [[stage16-boss]]). So the live table is not a superset of the abandoned ones;
 whatever those effect entries were for, the shipped campaign table drops them.
 `Tutorial` is the same shape — 66 fields, 3 of them unique.
+
+### ✅ The challenge LOD extras name meshes in that stage's **own** `.xpr` — 11 of 11
+
+The five bespoke tables' extras (`stg24_01…04`, `stg26_01…03`, `stg27_01…02`,
+`stg29_01…02`) are model names. Searching the extracted ISO's stage packages for
+each gives a **perfect diagonal**: every one appears in `Stage_S<NN>.xpr` and in
+**no other** stage package.
+
+So a challenge stage's bespoke LOD/model table exists to declare the handful of
+**scenery meshes packaged with that stage** — consistent with
+[[xbg7-mesh]]'s account of a stage `.xpr` as a bag of `XBG7` resources.
+
+🔑 **`stg24_04` is a composite model.** Expanding the match to the full name
+(never a bare prefix) gives 22 occurrences that resolve into
+**1 × `stg24_04` + 1 × `stg24_04_all` + 20 × `stg24_04_child`** — a parent, an
+"all" aggregate and twenty children. Every other `stg*` name occurs exactly once.
+
+🔑 **`rou_f004` is *not* in `Stage_S28.xpr` — it lives in `DeltaSaber_A.xpr`.**
+S28's LOD table declares the craft, but the mesh ships in the player-craft
+package, confirming from the ISO side that `_A` is the `f004` variant. The stage
+package carries scenery; the craft comes from its own file.
+
+`rot_n001_break` resolves too, in `Tutorial.xpr` and `Stage_S28.xpr` — matching
+exactly the tables that list it.
+
+🟡 **The orphan tables' unique effects only partly resolve.** `eff_e0033` is
+present in `Base.xpr`, but **`eff_e0058` and `eff_n0071` appear in no `.xpr` on
+the disc**. So the six abandoned LOD tables name at least two effects that were
+never packaged — the same "declared, never shipped" shape as S14's asteroid
+meshes ([[unit-group-table]]), on a much smaller scale.
+
+⚠️ **Method caveats for this section.** These are **byte searches over `.xpr`
+files**, not parsed resource-table reads — acceptable only because the names are
+long and distinctive and the match was expanded to the full trailing token, and
+they establish **presence**, not a resource enumeration. Also `grep -c` counts
+*lines*, not occurrences; the counts above come from `grep -o | wc -l` after that
+was caught.