re: correction -- the naming sweep already covered the 24; it just never said so

archive_naming.py already harvests 6027 candidate names under 16 prefixes, and
testing its candidate set directly shows it names all 24 StageParameter_S<NN>
objects, 24/24.  The previous entry presented that naming as new -- it is not.
What was new was the identification (which object is which stage, the shared
_Tutorial table, IsBoss16Enable = S16), not the method.

The real gap, now closed: the sweep reported only per-archive percentages and
never emitted WHICH entry got which name, which is exactly why nobody could say
the settings objects were StageParameter_*.  It now prints the resolved name
families per archive -- 6573 named entries, 1631 families disc-wide.

Determinism caught again by the verify loop: the resolved map was built by
iterating a set, so collided hashes picked a different winner each run.  Now
iterated sorted().  Second time in two iterations -- any map built from a set
needs a sort.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE

docs/re/structures/archive-naming.md

@@ -39,6 +39,34 @@ these archives are outside it.
 Not previously noted anywhere in `docs/re/`; it is the largest UI pak on the
 disc and its names are as unreachable as the 2D paks'.
 
+## ✅ The sweep now says WHICH entry, not just how many (2026-08-27)
+
+The percentages above were the whole output for a long time, and that hid
+something: the sweep had **already named** the 24 `StageParameter_S<NN>.tbl`
+objects that a later iteration "discovered" — they were in the 6 027-candidate
+set from the start. Nobody could tell, because the artefact only reported
+`GP_MAIN_GAME_E … 751 named, 67.1 %`.
+
+`archive_naming.py` now also emits, per archive, the **resolved name families**
+(digits collapsed to `#`) with counts — **6 573 named entries, 1 631 families
+across the disc**. That turns the statistic into a content index; the
+`GP_MAIN_GAME_E` head is
+
+```
+   x28   EnumUnit_S#.tbl        x28   StageResource_S#.tbl
+   x28   FormationSet_S#.tbl    x28   UnitGroup_S#.tbl
+   x28   Route_S#.tbl           x22   AIParams_S#.tbl
+   x22   StageParameter_S#.tbl  x22   UnitMessageSet_S#.tbl        …212 families
+```
+
+**Method lesson, paid for twice now:** a coverage percentage is not a name table.
+If a sweep can name a thing, make it *say* the name, or the next reader will
+redo the work.
+
+⚠️ Determinism: the resolved map is built by iterating the candidate set, so it
+is now iterated **sorted** — a plain `set` gave a different winner for collided
+hashes on each run and the artefact failed its own byte-identical check.
+
 ## What that means for the 419
 
 The in-game HUD's asset paths are not "missing". **Nothing in the 2D paks is

docs/re/structures/stage-settings-table.md

@@ -19,9 +19,18 @@ nothing.
 
 ## ✅ Every settings object is named — `stage\StageParameter_S<NN>.tbl`
 
-**Settled 2026-08-27, 24/24.** Hashing **every string that appears anywhere in
-any IDXD object on the disc** (rather than guessing filenames) resolves all
-twenty-four:
+**Settled 2026-08-27, 24/24.** Hashing every string that appears on the disc
+resolves all twenty-four:
+
+> ❌ **Correction (same day).** The first write-up of this presented the naming
+> *method* as new. It is not: `archive_naming.py` — the sweep behind
+> [`archive-naming.md`](archive-naming.md) — already harvests 6 027 candidate
+> names under 16 prefixes and **already covered all 24 of these hashes**. What
+> was new here is the **identification** (which object is which stage, and what
+> follows from it), not the ability to name them. The reason nobody could say
+> so before is that the sweep reported only per-archive *percentages* and never
+> emitted **which** entry got which name — now fixed, see that document.
+
 
 | name | count |
 |---|---|