fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

re: the freeze blocked the control run; tally it as the dominant cost

Browse Source 
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.
This commit is contained in:
Sylpheed RE agent
2026-08-25 17:23:20 +00:00
parent 0c930f203a
commit cee5cffebf
1 changed files with 37 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

37
docs/re/mission-freeze-resume-spin.md
View File

@@ -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.