# What each phase asks for — from the game's own objective text

Status: ✅ pinned by a disc test (`crates/sylpheed-formats/tests/phase_objectives_disc.rs`).

`TextIndex` in `sylpheed-formats::localization` already indexes per-phase objective
text under `S<NN>_P<n>_Objective_<i>`, with hints and lose conditions alongside.
Querying it settles what the wave work spent many iterations circling.

## Stage 02

| phase | objective | lose condition |
|---|---|---|
| 1 | **"Shoot down all invading enemy fighters while watching out for attacks on the ACROPOLIS."** | The ACROPOLIS is sunk |
| 2 | **"Protect the Admiral's ship the CALIBAN until it has entered the safe zone."** | The CALIBAN is sunk |
| 3 | **"Destroy the interstellar cruise missiles headed for Schlos Base."** | Schlos Base is destroyed |

Stage 01 phase 1 is *"Repel the enemy's surprise attack."*, phase 2 *"Cooperate
with your allies to repel the enemy units."*

## ✅ This explains the phase advances, and they are not all the same kind

* **Phase 1 is a kill-all-marked-fighters gate.** Not turrets — *fighters*. Every
  run in [mission-arrival-watch.md](mission-arrival-watch.md) killed turrets
  almost exclusively, so no run came close to satisfying it.
* **Phase 2 is positional, not a kill count** — it ends when the CALIBAN reaches
  a safe zone. That is a completely different trigger type, and it means "what
  advances a phase" never had one answer.
* **Phase 3 is destroy-the-missiles**, matching phase 3's roster of exactly nine
  `UN_e201_ADAN_ISCMissile` and `SUBOBJ_013`.

## ✅ `[OB]` is the objective marker — closing a loop to the first session

The hints name the mechanic outright:

> *"Red mission markers **[OB]** indicate your targets."*
> *"Take out these enemy units."*

**`REMAINING OB`** — the HUD counter hunted in the earliest iterations of this
work and located at `0xbdb59668` — is therefore the count of **remaining marked
objective targets**, i.e. phase-1 progress itself. The reframing recorded back
then ("the counter is not a roster") was right, and this names what it *is*.

That also makes it the correct signal to watch for a phase advance: not
`deployed`, which only changes when the next phase deploys, but `REMAINING OB`
reaching zero, which is the cause.

## 🔴 Method lesson: the crate already knew this

`localization.rs` has had `objectives(stage, phase)`, `hints` and
`lose_conditions` for some time. Several iterations were spent reconstructing
the same information the hard way — decoding `SUBObjective_local_string.tbl` by
hand, reading the guide script, inferring the phase-1 goal from
*"the attackers with the orange markers"*.

The reconstruction was not wrong, and it produced the IXUD/UTF-16BE and
`language\` prefix findings independently. But **the corpus should have been
searched before the disc was**: `grep -rl TextIndex crates/` would have saved
the detour. Recorded because the same reflex will apply to the next unknown.

Note also a discrepancy worth resolving: `ixud.rs` documents the pool as
UTF-16**BE** and `localization.rs` as UTF-16**LE**. Both work on their own
inputs, so one comment is wrong, or the two consumers genuinely differ. Not
investigated.

## What is still not observed

The phase-1 advance itself. The objective is now known exactly, and
[mission-objectives-text.md](mission-objectives-text.md) quantifies the cost:
the marked fighters are ~16 craft and the pilot manages about two per five
minutes. Nothing here changes that arithmetic — it only means the target list is
now certain rather than guessed.