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

tools/docs: the second-capital-ship blocker is stale; retry boots, not presses

Browse Source 
BACKLOG said the per-class ship generalisation needs "the capture-ship-placement
build of Canary". Checked: the ship capture is in the CURRENT build —
RequestShipCaptureFrame and CaptureShipDrawForRE are in command_processor.cc on
auto/re-ui-draw-order, and F10 wrote a 2.9 MB ship capture from this session's
binary. No separate build is needed.

What actually blocks it is navigation: a mission is behind the main menu, and (A)
at the title is accepted on about half of boots with nothing observable
predicting which. tutorial_launch.sh drives boot -> title -> menu -> TUTORIAL and
retries the WHOLE BOOT on refusal, because re-pressing the same title never
works — measured, not assumed.

First run of it: (A) refused, so it rebooted. That is the expected shape rather
than a failure of the harness.
This commit is contained in:
Sylpheed RE agent
2026-08-19 03:24:40 +00:00
parent 343864cc2f
commit 0b4dcc6e8f
2 changed files with 75 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
docs/re/BACKLOG.md
View File

@@ -590,5 +590,17 @@ declaring `e106_bdy_01` twice makes it fail, with the real multiset on the left.
**Not closed by this**, and worth keeping separate: the multiset is `e106`'s
alone. The generalisation this entry originally asked for — a per-ship table so
a regression in one class cannot hide behind `e106` passing — still needs a
runtime capture of a *second* capital ship, which needs the
`capture-ship-placement` build of Canary.
runtime capture of a *second* capital ship.
**That entry's stated blocker is stale** (checked 2026-08-19): the ship capture
is in the current build — `RequestShipCaptureFrame` / `CaptureShipDrawForRE` are
in `command_processor.cc` on `auto/re-ui-draw-order`, and F10 wrote a 2.9 MB
`xenia_ship_capture_01.log` from this session's binary. No separate
`capture-ship-placement` build is needed.
What blocks it now is **navigation**: a mission is behind the main menu, and Ⓐ at
the title is accepted on roughly half of boots with nothing observable predicting
which ([`canary-scripted-input-traps.md`](canary-scripted-input-traps.md)).
`tools/re-capture/tutorial_launch.sh` therefore retries whole boots rather than
re-pressing — re-pressing the same title never works — and drives menu → TUTORIAL
from there.