re: a menu/EXTRAS discriminator that failed its control, and the fix
sylpheed-port's BLOCKED.md ask #1 -- does (B) from EXTRAS also show no black interval, or is "(B) has no black" one screen pair -- needs the harness to know it is on EXTRAS. screen_id.py cannot tell: both are dark blue GP_TITLE screens and it reports `menu` for either. which_title_screen.py correlates a grab against our build 5 / build 6 renders. First version FAILED its control: it called live-main-menu.png "extras" and live-extras.png "main_menu", both backwards, margins under 1.1 on RMSE ~33. Cause: it applied the y=45 game-surface offset unconditionally, but only a full 1280x720 display frame has the menu bar -- a 1279x675 grab IS the surface, and two of the three reference captures are surface-sized. Offset made conditional; the control now passes 4/4 with margins 9.9-11.7 against ~18 within-class. The tool is a navigation aid for driving the emulator and says so: it identifies a screen by agreeing with our own renders, so nothing measured may rest on it. Also records the METHOD entry sylpheed-port offered from their own wedged check script: an absence of output is not a status. They reported "still running, two lines, both ok" for three iterations while the first attempt had died silently under its own timeout with block-buffered output -- zero information, reported as patience. An orphan from an older form of the same script was found running after 9.5 hours. Line-buffer and bound long jobs, and check the artifact rather than the exit code: the artifact reached its correct duration while the process never returned. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
This commit is contained in:
@@ -203,6 +203,19 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
|
||||
or `-` is that bug's signature. Grep the corpus for readers of a structure
|
||||
before calling its fix done.
|
||||
|
||||
* **An absence of output is not a status.** `sylpheed-port` reported "still
|
||||
running, two lines, both ok" for three consecutive iterations of a check script.
|
||||
The first attempt had already died silently under its own timeout with
|
||||
block-buffered output — so there had been *zero* information from it, and "still
|
||||
two lines" was being read as patience rather than as the alarm it was. The
|
||||
underlying process was wedged on an ffmpeg that finishes its work and never
|
||||
exits (an orphan from an older form of the same script was found still running
|
||||
after **9.5 hours**). Two rules fall out, and this corpus has now paid for both:
|
||||
a long-running job needs **line-buffered output and a bound**, and *"no new
|
||||
output"* must be treated as **no information**, never as progress. Check the
|
||||
artifact, not the exit code — the artifact reached its correct 8.0 s duration
|
||||
while the process it came from never returned.
|
||||
|
||||
## Runtime / emulator
|
||||
|
||||
* **Look at the PNG** — and check its dimensions.
|
||||
|
||||
Reference in New Issue
Block a user