From 1bada3ba4c6b99b58d0c2d3b44bcac6c860b3410 Mon Sep 17 00:00:00 2001
From: Sylpheed RE agent <agent@localhost>
Date: Wed, 26 Aug 2026 20:13:33 +0000
Subject: [PATCH] re: the working entity captures came from a SAVE SLOT, not
 mission select

Before deriving a new vtable I checked where gworld.py's constants came from.
They cite structures/unit-struct-runtime.md, which states its provenance:
"Captured 2026-07-29 ... all six tutorials and Stage 02 'Declaration of War'
loaded from save slot 01."

Loaded from a save slot -- not through MISSION SELECT, which is the route every
run this session has taken, and which needs the cleared-stage mask poke to offer
a stage at all.  So the constants may not be stale; they may just need the state
that route produces.  That is a cheaper question than writing a new vtable
finder, and it should be answered first.

First attempt inconclusive: driving the main menu's first item blind, five
presses deep, advanced the progress counter every time (3 -> 5 -> 6 -> 8 -> 10 ->
12, so the game responds) but left DEF_VTABLE / INST_VTABLE at 0/0 throughout.
Without a screen identity this is dead reckoning, and the first item may not be
the load-game entry -- newgame_path.sh documents it as NEW GAME with SELECT DATA
two screens further in.

Next: reach the save-slot screen deliberately rather than by counting presses,
and load slot 01.
---
 docs/re/mission-freeze-signin-dialog.md | 30 +++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/docs/re/mission-freeze-signin-dialog.md b/docs/re/mission-freeze-signin-dialog.md
index 51d1fd6..4e657d2 100644
--- a/docs/re/mission-freeze-signin-dialog.md
+++ b/docs/re/mission-freeze-signin-dialog.md
@@ -287,3 +287,33 @@ statement is:
 the constructor that writes a vtable pointer, via `sylpheed.db`'s `vptr_writes`
 table, which exists precisely for this); or find the entity list from the mission
 update function rather than from data.
+
+## ✅ The corpus records how the working entity captures were made — and it is a different route
+
+Before deriving a new vtable, I checked where `gworld.py`'s constants came from.
+They cite [`structures/unit-struct-runtime.md`](structures/unit-struct-runtime.md),
+which states its provenance plainly:
+
+> Captured 2026-07-29 from Xenia Canary running the retail disc in the sylph-re
+> container: **all six tutorials** and **Stage 02 "Declaration of War" loaded from
+> save slot 01.**
+
+**Loaded from a save slot** — not through `MISSION SELECT`, which is the route
+every run in this session has taken (and which needs the cleared-stage mask poke
+to offer a stage at all). So the constants are not necessarily stale: they may
+simply require the state that route produces.
+
+That reframes the entity hunt. Before writing a new vtable finder, the cheaper
+question is whether the *save* route reaches a state the *mission-select* route
+does not.
+
+🟡 First attempt inconclusive: driving the main menu's **first** item blind, five
+presses deep, advanced the progress counter every time (`3 → 5 → 6 → 8 → 10 →
+12`, so the game is responding) but left `DEF_VTABLE` / `INST_VTABLE` at **0 / 0**
+throughout. Without a screen identity the route is dead reckoning, and the first
+item may not be the load-game entry at all — `newgame_path.sh` documents it as
+NEW GAME, with `SELECT DATA` two screens further in.
+
+❔ Next: reach the save-slot screen deliberately rather than by counting presses,
+and load slot 01. `newgame_path.sh` already encodes NEW GAME → DIFFICULTY →
+SELECT DATA and is the closest existing script to that path.