re: blocker — the schedule's later entries cannot be reached in one turn

Computed the observation ceiling, which should have been done several iterations
ago instead of being approached one run at a time. A turn's shell call is capped
at 595 s; boot costs about 220 s, of which roughly 190 s is a title movie the
launch script waits out because tapping breaks the title; probe startup is about
25 s. That leaves roughly 350 s of observation, and at the measured 55 % of
real-time that is about 193 game-seconds.

Against the phase-1 route schedule: t=90 needs 164 s of wall-clock and t=120
needs 218 s, both already observed with no arrival. t=170 needs 309 s and is
reachable but only on a run that does not freeze. t=210 needs 382 s and t=240
needs 436 s, and neither fits in a turn at all.

So the tail of Stage 02's phase-1 schedule cannot be tested under this harness
however many runs are attempted. Recorded as a blocker rather than improvised
around. Two things would unblock it and neither is mine to decide: a safe way to
skip the title movie, which is more than half the budget and would roughly
double the window to about 297 game-seconds covering every entry, or a longer
shell timeout if the harness permits one.

This run is discarded: frozen at t=90 with 15 stalled samples and 3 losses,
correctly flagged and not interpreted. The freeze tally is now three clean of
five, lower than the three-of-four quoted last iteration.

What stands is unchanged: zero confirmed arrivals over 300 s of verified-live
flight, about 165 game-seconds, covering the t=90 and t=120 entries. That is the
strongest statement this harness can currently support.
This commit is contained in:
Sylpheed RE agent
2026-08-24 19:28:53 +00:00
parent d4f6b7bf03
commit 8cc05692d6
2 changed files with 54 additions and 1 deletions

View File

@@ -459,7 +459,16 @@ search cannot find a *schedule*.
clean at 210/240/300 s but **frozen at 60 s** on a fourth. Tally — heavy probe
froze at 27/45/83/183/255 s; cheap+rescan at 183 s; cheap, no rescan: 3 of 4
clean past 200 s. A large probability improvement, **not a fix**. Practical
rule: run, check the witness, discard frozen runs (~3 in 4 usable). The rescan
rule: run, check the witness, discard frozen runs (**3 clean of 5** now: clean
210/240/300, frozen 60/90).
* 🚧 **BLOCKER (2026-08-24): route entries t=210 and t=240 are UNREACHABLE in one
turn.** 595 s shell cap − ~220 s boot (a ~190 s title movie that cannot be
tapped through) − ~25 s startup = **~350 s observation ≈ 193 game-seconds**.
t=90 needs 164 s wall ✅, t=120 → 218 s ✅, t=170 → 309 s ✅ (only on a
non-frozen run), **t=210 → 382 s ❌, t=240 → 436 s ❌**. No number of runs fixes
this. **Unblocking needs a decision I should not make alone:** (1) a safe way to
skip the title movie — it is >half the budget, and would roughly double the
window to ~297 game-s, covering everything; or (2) a longer shell timeout. The rescan
existed only to catch newly-allocated craft, which the roster work showed never
happens.
* ✅ **Run 16: the first TRUSTWORTHY negative.** Validated witness, no stall on