From 15b609dbc7975e62c6c053405c9d9c0ebeee4a0a Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Tue, 25 Aug 2026 17:23:20 +0000 Subject: [PATCH] re: the freeze blocked the control run; tally it as the dominant cost This iteration set out to run the positive control the poke results need -- poke the player's hull, which the pilot logs every sample, and confirm the guest sees it. It did not run: the bind took two attempts (first fwd_cos -0.94, second 1.0) and by the time the player was being located the guest had frozen, with entities2 reporting '0 moving triples' and frozen.py confirming max_pixel_delta=0. Session tally: froze at ~70/126/150/253/610-682s and this run; ran clean at 694s (ended by the game), 936s and 1064s. Roughly two in three freeze, each costing a ~5min boot plus the window. The freeze has now truncated more experiments than every other cause combined. Restates that it is probably not ours: the mission-end freeze is recorded as pre-existing in both our build and the official AppImage, and this session produced a pilot-only freeze at 150s with no probe attached. The probe-correlation lead is real but never became a clean split. Consequence: experiments needing more than ~2 minutes of live mission should checkpoint and resume, or detect the freeze and re-run themselves. Every tool here witnesses the freeze; none survives it. --- docs/re/mission-freeze-resume-spin.md | 37 +++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/docs/re/mission-freeze-resume-spin.md b/docs/re/mission-freeze-resume-spin.md index c07ea234..5a51557e 100644 --- a/docs/re/mission-freeze-resume-spin.md +++ b/docs/re/mission-freeze-resume-spin.md @@ -1255,3 +1255,40 @@ The sweeps still need replacing to run the experiment; the cheaper version is a **bounded** pointer scan — every ScriptMission seen so far sat in `0xBC79xxxx–0xBC7Axxxx`, so scanning ~32 MB instead of the full ~371 MB would cut the cost roughly tenfold while still finding it. Not yet implemented. + +## 🔴 2026-08-25 — the freeze is now the dominant cost, and it blocked the control run + +This iteration set out to run the **positive control** the poke experiments +need — poke the player's hull (`position + 0x154`, which the pilot logs every +sample) and confirm the guest sees it. **It did not run.** The bind needed two +attempts (the first returned `fwd_cos = -0.94`, a bad orientation; the second +`1.0`), and by the time the player's entity was being located the guest had +frozen: `entities2 self` reported **"0 moving triples"** and `frozen.py` +confirmed `max_pixel_delta = 0`. + +### The session's freeze tally + +| outcome | observed | +|---|---| +| froze | ~70 s, ~126 s, ~150 s, ~253 s, ~610–682 s, and this run | +| ran clean | 694 s (ended by the game), 936 s, 1064 s | + +Roughly **two runs in three freeze**, and each costs a ~5-minute boot plus the +observation window. Across this session the freeze has truncated more +experiments than every other cause combined: three phase-advance attempts, one +distribution capture, and now the control. + +### 🟡 It is probably not ours + +Worth restating against the temptation to keep hunting our own tooling: the +mission-end freeze is recorded as **pre-existing in both our Canary build and the +official AppImage** ([canary-build-verified-env-confound](canary-build-verified-env-confound.md)), +and this session produced a **pilot-only** freeze at 150 s with no probe attached +at all. The probe-correlation lead (3-of-3 with, 1-of-3 without) is real but has +not survived as a clean split, and the bounded scan improved it without removing +it. + +**Consequence for planning:** any experiment needing more than ~2 minutes of +live mission should be built to **checkpoint and resume**, or to detect the +freeze and re-run itself, rather than assuming a run completes. Every tool in +this line now witnesses the freeze; none of them yet *survives* it.