re: in-flight HUD — independent confirmation of the ammo mapping

The tutorials need no save and are ~1 min from a cold boot, so they are the
cheapest route into a live flight scene. The HUD prints the equipped weapons as
NOSE BM 06000 / MAIN MPM 00300 — matching wep_01's LoadingCount 6000 and wep_02's
300, with the weapons identified from the HANGAR loadout rather than from the
ammo number. That makes it a genuinely independent confirmation of
Ammo Capacity == LoadingCount, from a different renderer in a different mode.

Also inventories the HUD elements (heat gauges, shield/armor pools, target armor
gauge, per-weapon RANGE markers) and notes that the RANGE gauge draws each
weapon's MaximumRange on a scale — a route to a real number where the Arsenal
panel only gives a letter class.

Adds autopilot.py (waypoint-arrow chaser). It detects reliably but oscillates;
recorded as such rather than as a working tool.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/re/weapon-datasheet-runtime.md

@@ -170,3 +170,63 @@ Screenshots for every row above: `/sylph-home/re/caps/` in the container.
 
 Evidence PNGs are committed under [`captures/weapon-datasheet/`](captures/weapon-datasheet/)
 (64-colour quantized for size; the numbers stay legible).
+
+---
+
+# Addendum — the in-flight HUD (2026-07-28)
+
+Reached via **TUTORIAL → BASIC CONTROLS / HEADS-UP DISPLAY** from the title menu (no
+save needed). Evidence: [`captures/hud-runtime/`](captures/hud-runtime/).
+
+## The HUD corroborates the ammo mapping, independently
+
+The Delta Saber's HUD prints its two equipped weapons as `NOSE <TYPE> <AMMO>` and
+`MAIN <TYPE> <AMMO>`. With the loadout known from the HANGAR (nose = STILETTO BG I, main =
+FALCON 9AM) the HUD reads **`NOSE BM 06000`** and **`MAIN MPM 00300`** — exactly
+`wep_01_Beam`'s `LoadingCount = 6000` and `wep_02_Missile`'s `300`.
+
+This matters because it is **not** the Arsenal panel: the weapons were identified from the
+HANGAR loadout, and the numbers come from a different renderer in a different game mode. It
+is a genuinely independent confirmation of `Ammo Capacity == LoadingCount`.
+
+The type tags (`BM`, `MPM`) are the same short codes as the Arsenal type tabs.
+
+## HUD element inventory
+
+| HUD element | Backing data | Conf. |
+|---|---|---|
+| `NOSE` / `MAIN` + type tag + 5-digit ammo | equipped weapon, `LoadingCount` | ✅ |
+| `HEAT` / `L.HEAT` bar under each weapon | the `Heating` / `Cooling` pair | 🟡 |
+| Speed readout + throttle scale (`0`, `100`, `A/B`) | craft velocity | ✅ |
+| `SHIELD` and `ARMOR` bars (two separate pools) | craft `HP` + a shield pool | 🟡 |
+| Target reticle: name / type / distance + ring **Armor Gauge** | target unit record | 🟡 |
+| `RANGE` gauge with `MAIN` and `NOSE` tick markers | each equipped weapon's `MaximumRange`, plotted against target distance | 🟡 |
+| `YOU KILLED: WARSHIPS nnnn` + a second counter | score / `ScorePoint` | ❔ |
+
+The `RANGE` gauge is the interesting one for future work: it draws a **per-weapon marker on
+a distance scale**, so a weapon whose `MaximumRange` is defaulted on disc (`wep_25`,
+`wep_58`, `wep_82`) would have its value *drawn* rather than bucketed into a letter — if the
+scale can be calibrated against two weapons with known ranges, that recovers a real number
+where the Arsenal panel only gives a class.
+
+## Craft velocity
+
+Full afterburner (RT) peaked at **1193** against `UN_f001_TCAF_DeltaSaber_T`'s on-disc
+`MaximumVelocity = 1200`. 🟡 PROBABLE — one observation, and the readout may have been
+still climbing. Cruise sat at 350, which is *not* the record's `CruisingVelocity` (700), so
+the number is the current throttle setting, not a named constant; don't read more into it.
+
+## Notes for the next session
+
+- The tutorials need **no save game** and are reachable in ~1 min from a cold boot, which
+  makes them the cheapest way back into a live flight scene.
+- `tools/re-capture/autopilot.py` chases the yellow off-screen waypoint arrow (colour +
+  shape, `-sample` not `-resize`, ~0.65 s per detection). It **finds the arrow reliably but
+  oscillates** — the proportional gain is too high for the craft's turn rate. It needs a
+  damping/derivative term before it can actually fly a waypoint.
+- The HEADS-UP DISPLAY tutorial reaches a scripted targeting segment where the ship stops
+  moving (target distance pinned) and the on-screen controller highlights **A**; tapping and
+  holding A did not advance it. **NEEDS-HUMAN**: what input that segment wants.
+- Canary is unstable here: it died twice mid-session (once loading BEAM `Resource3D`, once
+  hanging on tutorial teardown) with no crash dump. Re-launch is cheap; just don't assume a
+  long session survives.