Egress hold: CLOSED (won-t-fix) -- floor lamps gone from surviving cockpits; findings preserved

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

emulator/EGRESS-HOLD-FIX-PLAN.md

@@ -1,6 +1,18 @@
-# Back-burner plan: honor the ~30s customer-egress hold
+# Egress-hold / floor-lighting — CLOSED (won't-fix), findings preserved
+
+Status: **CLOSED 2026-07-10 — WILL NOT FIX** (operator decision). The floor
+egress lights were a curiosity only: no surviving Tesla cockpit still has the
+floor lamps installed, so reproducing the ~30s hold has no restoration value.
+The investigation is fully documented here and in NET-NOTES.md for the record;
+we will likely not return to it. The Step 1 patch below is a COMPLETE, ready
+recipe if a future need ever arises — it is not planned work.
+
+Summary of the closed finding: the pod's post-mission egress window is a
+compiled ~3s (the game exits at its stage-1 timer; the deeper 30s timer is
+never reached). It is byte-identical across all four BTL4OPT builds
+(May-96..Rel410) = NOT a Rel410 regression. Effective behavior is authentic
+as-is; the ~3s is what the game does.
 
-Status: BACK BURNER. Step 0 DONE 2026-07-10 -> Step 1 is the confirmed fix.
 Context in NET-NOTES.md ("EGRESS DELAY = COMPILED IN, TWO-PHASE").
 
 ## Step 0 RESULT (2026-07-10, net_full.conf single-shot, RIO tap)

emulator/NET-NOTES.md

@@ -642,15 +642,24 @@ BTDAVE (@0x489a08/0x48a3c0), Rel410 (@0x47b864/0x47c2c4). So Rel410 did
 NOT cut a 30s hold; every build has both the 3.0 and 30.0 constants.
 
 **EFFECTIVE behavior = the 3s phase** (matches the measured 3.4s
-lamp-on->off exactly). The 30s phase-2 timer is scheduled AFTER cleanup
+lamp-on->off exactly). Step 0 diagnostic (net_full single-shot, no
-has begun tearing the exe down, so the process is recycled by netnub
+loop, 2026-07-10) PROVED this is the game's own behavior, not a
-before it fires -- true in every build, so the 30s is effectively dead
+GO.BAT-loop artifact: with only a DOS `pause` waiting, the floor lamp
-in the actual run. The operator's remembered ~20-30s "lights on" is the
+held 3.9s (mission-end 108.8s -> off 112.7s) and btl4opt EXITED itself
-ENTRY lighting (floor lamp on game-ready->drop, MEASURED 21s in our tap:
+to COMMAND. The process exits AT the stage-1 (3.0f) timer; the deeper
-1207s->1228s) plus the between-games boot/idle gap, NOT the post-mission
+30s timer is never reached. The operator's remembered ~20-30s "lights
-egress phase. Tools: scratchpad btdis2.py + stopmission_cmp3.py
+on" is the ENTRY lighting (floor lamp on game-ready->drop, measured
-(pefile+capstone, py -3.13). Supersedes the earlier "3.4s = print time"
+15.9-21s across runs) plus the between-games boot/idle gap, NOT the
-AND "authentic 30s hold" readings. Lamp
+post-mission egress phase. Tools: scratchpad btdis2.py +
+stopmission_cmp3.py + lamp_read.py (pefile+capstone, py -3.13).
+
+**ISSUE CLOSED 2026-07-10 (WON'T-FIX, operator decision):** the floor
+egress lights are a curiosity only -- no surviving Tesla cockpit still
+has the floor lamps installed, so reproducing the ~30s hold has no
+restoration value. The ~3s behavior is authentic and left as-is. Full
+findings + a ready (unplanned) Step 1 patch recipe in
+emulator/EGRESS-HOLD-FIX-PLAN.md. Supersedes the earlier "3.4s = print
+time" AND "authentic 30s hold" readings; not revisiting. Lamp
 state byte: flash bits0-1 (solid/slow/med/fast), ch1 bits2-3
 (off/dim/bright), ch2 bits4-5. Extraction tool: scratchpad
 lamp_read.py pattern (tap lines are one byte each).