Correct pod integration: AutoHotkey scripts scrape PQS, not direct polling

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docs/ARCHITECTURE.md

@@ -46,8 +46,11 @@ lives in `includes/`.
                  │                        smallcombinedqueue │
                  │                        genconqueue.php    │
                  │                                           │
-  Game pods ────▶│  Poll  getFSgame.php  (mission settings)  │
-  (FS sim)       │  Poll  getFSplayers.php (roster/pods CSV) │
+  Console  ─────▶│  AutoHotkey scripts (NOT YET RECOVERED)   │
+  operator PC    │    read getFSgame.php  (mission settings) │
+                 │    read getFSplayers.php (roster/pods CSV)│
+                 │    → keyboard-inject into the game console│
+                 │      which then configures the FS pods    │
                  │                                           │
   Pi video  ────▶│  Poll  playFSTrainer.php  (missing file)  │
                  │         → triggers omxplayer intro video   │
@@ -78,6 +81,17 @@ with **players**, then get **committed** (launched) one at a time.
 5. **Display** — `ctime` of the last commit + `timepergame + timetoreset`
    drives every "ETD" (estimated departure) and countdown on the display walls.
 
+### How the mission reaches the pods
+
+PQS does **not** talk to the game/pods directly. The console operator runs a set
+of **AutoHotkey scripts** (currently **not recovered** — a gap to close) on the
+game-console PC. Those scripts read the plain-text output of `getFSgame.php`
+(mission settings) and `getFSplayers.php` (per-pod roster) and **keyboard-inject
+those values into the game console UI**, which in turn configures the physical
+pods. So the `getFS*.php` files are a *data source scraped by AHK*, not an
+endpoint the pods poll. Their output layout is dictated by whatever those AHK
+scripts expect — recovering the scripts is required to know the exact contract.
+
 ### Group registration (squads)
 
 `callsign.php` supports **Group Leader / Group Member** flows: a leader reserves
@@ -140,9 +154,11 @@ Notes:
 - **`combinedqueue2.php`** — mid-range wall showing missions 6–10 + current pods
   + clock + info panel, 10s refresh.
 
-### Pod / hardware integration (plain-text output, no HTML)
+### Game-console integration (plain-text output, no HTML)
+Consumed by the operator's **AutoHotkey scripts** (not the pods directly — see
+§4 "How the mission reaches the pods"). The AHK scripts are **not yet recovered**.
 - **`getFSgame.php`** — emits the next mission's settings as newline-delimited
-  values (gametype, map, visibility, weather, … cameraship) for the sim to read.
+  values (gametype, map, visibility, weather, … cameraship) for AHK to read.
 - **`getFSplayers.php`** — emits 16 CSV lines (one per pod slot):
   `active,callsign,rosterNum,team,unit` — the pod loadout for the next mission.
 - **`playFSTrainer.php`** — *referenced by `docs/get.py` but missing from the
@@ -226,7 +242,10 @@ If **improving in place**, the highest-value, lowest-risk fixes first:
 4. Make pod count and timezone configuration-driven, not hard-coded.
 
 If **rewriting from scratch**, preserve section 4's lifecycle and section 5's
-tables as the spec, and treat `getFSgame.php` / `getFSplayers.php` output
-formats as a **hard contract** the physical pods depend on — document those
-byte-for-byte before changing anything on the sim side.
+tables as the spec. Treat `getFSgame.php` / `getFSplayers.php` output formats as
+a **hard contract**, but note the real contract is defined by the **unrecovered
+AutoHotkey scripts** that scrape them and keyboard-inject into the game console.
+**Recovering those AHK scripts is a prerequisite** to safely changing anything
+about how missions reach the pods — without them the exact expected output
+layout (field order, line count, delimiters) can only be inferred from the PHP.
 ```