re: clean run reproduces; startup was eating a third of the window

Second consecutive run with no stall flag on any sample, which confirms that
disabling the periodic rescan is what fixed the freezes. Nine losses, four
flicker increases all correctly rejected, and zero confirmed arrivals. The
trustworthy negative now extends to 240 s of verified-live flight, roughly 132
game-seconds, so nothing arrives past the route table's t=90 or t=120 entries
either.

The flicker rate is worth noting: about one spurious increase per minute. That
is the rate at which the old rule would have been manufacturing arrivals.

The arithmetic of the run exposed a waste. Boot finished at 249 s, the probe ran
240 s, and the turn's 595 s cap fired, leaving about 100 s unaccounted for
between them -- the witness calibration and the initial craft enumeration.

enumerate_craft was iterating every 4-byte word of 32 MB in Python, eight
million steps, to find fourteen fixed needles. Replaced with bytes.find() per
definition VA, which is the same search at C speed and is what the vtable scan
already did. Not yet run.

If that recovers most of the hundred seconds the observation window grows from
about 240 s to about 340 s, roughly 187 game-seconds, which would finally reach
the t=170 route entry -- the first of the schedule's later arrivals that no run
has yet been able to observe.
This commit is contained in:
Sylpheed RE agent
2026-08-24 18:31:51 +00:00
parent d674fee457
commit 14385ae170
3 changed files with 66 additions and 13 deletions

View File

@@ -464,7 +464,15 @@ search cannot find a *schedule*.
210 s of verified-live flight** ≈115 game-seconds. Establishes that nothing
arrives in the first ~115 game-s of Stage 02 phase 1 while the player kills 8
craft. Does NOT settle the question — t=170/210/240 route entries are still out
of reach. Also: the 42-record anomaly recurred and the discard rule
of reach.
***Run 17 reproduces it (n=2)**: no stalls through **t=240 s** (~132 game-s),
9 losses, 0 confirmed arrivals — so nothing arrives past the t=90 and t=120
route entries either. 4 flicker `up`s correctly rejected (~1/min, which is why
the persistence rule matters). 🔴 **Startup eats ~100 s of a ~350 s budget**:
`enumerate_craft` iterated every 4-byte word of 32 MB in Python (8M steps) to
find 14 fixed needles. **Replaced with `bytes.find()` per definition VA — not
yet run**; if it recovers that time the window reaches ~340 s ≈ 187 game-s,
finally covering the **t=170** entry. Also: the 42-record anomaly recurred and the discard rule
correctly refused the run; a rescan-until-baseline retry is now in place to
test whether it climbs. All three witness
failures share one pattern: a shortcut in *selecting* the witness, each caught