fabi/Syplheed-Reborn
Archived
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source 
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
Download Patch File Download Diff File Expand all files Collapse all files

11
docs/re/BACKLOG.md
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

44
docs/re/mission-arrival-watch.md
View File

@@ -390,3 +390,47 @@ already did.
If that recovers most of the 100 s, the observation window grows from ~240 s to
~340 s — about **187 game-seconds**, which would finally reach the **t = 170**
route entry. Not yet run.
---
# 🚧 BLOCKER: two of the schedule's entries are unreachable in one turn (2026-08-24)
This should have been computed several iterations ago instead of being
approached one run at a time.
A turn's shell call is capped at 595 s. Boot costs ~220 s (a ~190 s title movie
that cannot be tapped through plus ~35 s to flight) and probe startup ~25 s,
leaving **~350 s of observation**. At the measured ~55 % of real-time, that is
**~193 game-seconds**.
| route entry | wall-clock needed | status |
|---|---|---|
| t = 90 | 164 s | ✅ reachable — observed, no arrival |
| t = 120 | 218 s | ✅ reachable — observed, no arrival |
| t = 170 | 309 s | ✅ reachable, but only on a run that does not freeze |
| **t = 210** | **382 s** | ❌ **out of reach in one turn** |
| **t = 240** | **436 s** | ❌ **out of reach in one turn** |
So the tail of Stage 02's phase-1 schedule cannot be tested under the current
harness at all, however many runs are attempted. Recorded as a blocker rather
than worked around.
**What would unblock it,** neither of which is mine to decide:
1. **Skip the title movie.** It is ~190 s of the 220 s boot — more than half the
budget — and `launch_mission.sh` waits it out because tapping breaks the
title. If there is a safe skip, the window roughly doubles to ~540 s ≈ 297
game-seconds, which covers every entry including t = 240.
2. **A longer shell timeout**, if the harness allows it.
## This run: discarded
Frozen at t = 90 s, 15 stalled samples, 3 losses. Correctly flagged and not
interpreted. Freeze tally is now **3 clean of 5** (210, 240, 300 clean; 60, 90
frozen), lower than the 3-of-4 quoted last iteration.
## What stands
**0 confirmed arrivals over 300 s of verified-live flight (~165 game-seconds)**,
covering the t = 90 and t = 120 route entries. That is unchanged, and it is the
strongest statement this harness can currently support.