re: message tables searched — phases are pervasive, the trigger is not in data

StageMessageSet_S02.tbl is resolved. stage-mission-tables.md had recorded it as
absent from the pak; it is present, and the archive prefix is message\ rather
than stage\ like its siblings. Sweeping prefix candidates over the full 16630
entry TOC found it immediately. It holds a voice mapping, a unit message set
pointer, and a list of 31 message tables including ScriptMessage_S02_msg.tbl and
the per-character PresetMessage sets.

message\UnitMessageSet_S02.tbl then gives an independent confirmation of the
phase structure. Its 26 records have exactly four named fields: CrewCount and
PresetMessage_Phase1, Phase2 and Phase3. Every message set carries a different
preset table per phase, so phases now appear in three unrelated table families --
the stage record, the route names, and the message sets. They are not a quirk of
one file.

The promising lead did not survive. ScriptMessage_S02_msg.tbl has 149 records
whose third positional field takes values like Killed and None, which looked
like a trigger. Enumerated across S01 and S02 it is a small closed vocabulary of
None, Emergency, Killed and Noise -- delivery categories for radio chatter,
meaning how a line is played rather than mission control flow -- and the fourth
field is 1 in every record, so it is not an argument either. Rejected.

That leaves no table anywhere carrying a phase-advance condition. Everything
found is a consequence of the phase and never its cause, which points at the
advance logic living in code. The only place left is the executable, and
default.xex is encrypted on disc, so the decrypted image exists only in guest
RAM and reaching it needs a run plus function-level work. Recorded as the honest
end of the static search rather than continuing to guess at table names.

docs/re/BACKLOG.md

@@ -519,6 +519,18 @@ search cannot find a *schedule*.
   directly observable (deployed would jump), did not happen in 435 s with 42
   kills, and `SUBObjectiveSettings` names 9 objectives but carries no trigger.
   Unsearched: `StageMessageSet_S02.tbl` (never resolved) and the PE in guest RAM.
+* ✅🔴 **(2026-08-24) Message tables searched; trigger NOT there.**
+  ✅ `StageMessageSet_S02.tbl` **resolved — prefix is `message\`**, not `stage\`
+  (closes a long-standing ❔). ✅ `message\UnitMessageSet_S02.tbl` has
+  `CrewCount` + **`PresetMessage_Phase1/2/3`** — a THIRD independent table family
+  organised around phases, after the stage record and route names.
+  🔴 **Refuted:** `ScriptMessage_S02_msg.tbl`'s promising third field is a radio
+  *delivery category* (`None` 105, `Emergency` 33, `Killed` 5, `Noise` 5; arg is
+  `1` in every record), not mission control flow.
+  ❔ **No table anywhere carries a phase-advance condition** — everything found is
+  a consequence of the phase, never its cause. ⇒ the logic is in **code**, and
+  `default.xex` is encrypted on disc, so the decrypted image exists only in guest
+  RAM. That is the honest end of the static search.
   🔴 `SYLPH_HZ=3` refuted as a lever: it gave the LOWEST frame rate (8/s) with the
   most kills, so pilot polling is not the throttle.
 * ~~🚧 BLOCKER: t=210/240 unreachable in one turn~~ — **superseded, see above**;

docs/re/mission-phase-deployment.md

@@ -74,3 +74,61 @@ What is now known that was not then:
 Places not yet looked: `StageMessageSet_S02.tbl` (never resolved in
 `GP_MAIN_GAME_E.pak`), and the executable, whose decrypted image is only
 available in guest RAM.
+
+---
+
+# Hunting the phase trigger in the message tables (2026-08-24)
+
+## ✅ `StageMessageSet_S<NN>.tbl` resolved — the prefix is `message\`
+
+[structures/stage-mission-tables.md](structures/stage-mission-tables.md) recorded
+this table as ❔, "not in `GP_MAIN_GAME_E.pak` under that name". It is there; the
+archive prefix is **`message\`**, not `stage\` like its siblings. Sweeping the
+prefix candidates over the full 16 630-entry TOC found it immediately.
+
+It holds three records — `VoiceID2SndID`, `UnitMessageSetTable`, and a `Files`
+list of 31 message tables: `ScriptMessage_S02_msg.tbl`,
+`ScriptMessage_S02guide_msg.tbl`, `DemoMessage_S02_msg.tbl`, and per-character
+`PresetMessage_*` sets.
+
+## ✅ Phases are a first-class runtime concept, confirmed independently
+
+`message\UnitMessageSet_S02.tbl` (26 records) has exactly four named fields:
+
+```
+CrewCount, PresetMessage_Phase1, PresetMessage_Phase2, PresetMessage_Phase3
+```
+
+Every message set carries a **different preset message table per phase**. That is
+a third, independent table family organised around `Phase_1..3`, after the stage
+record and the route names. Phases are not a quirk of one file.
+
+## 🔴 Refuted: the script-message trigger field is not a phase trigger
+
+`ScriptMessage_S02_msg.tbl` has 149 records whose third positional field looked
+promising — values like `Killed` alongside `None`. Enumerated across the corpus
+it is a small closed vocabulary:
+
+| value | S02 | S01 |
+|---|---|---|
+| `None` | 105 | 72 |
+| `Emergency` | 33 | 5 |
+| `Killed` | 5 | 2 |
+| `Noise` | 5 | 8 |
+
+These are **delivery categories for radio chatter** — how a line is played
+(urgent, over static, on a death) — not mission control flow. The fourth field is
+`1` in every single record, so it is not an argument either. Rejected.
+
+## ❔ No table carries a phase-advance condition
+
+Phases now appear in the stage record, in route names, and in message sets, and
+**not one of those files says what ends a phase.** Everything found is a
+*consequence* of the phase, never its cause.
+
+That points at the advance logic living in code rather than data. The only place
+left is the executable, and `default.xex` is encrypted on disc — the decrypted
+image exists only in guest RAM, which means a run plus function-level work.
+
+Recorded as the honest end of the static search rather than continuing to guess
+at table names.