re: a third title->menu replicate, from a run that ran the wrong experiment

Set out to measure menu -> EXTRAS, the reverse of the pair measured at a 2-frame
gap, to test whether the black gap is a property of the screen pair or of the
direction. The run did not do that.

A three-part patch to fade_decompose.sh asserted two of its three replacements
and left the third -- the branch condition -- unchecked. It silently failed, so
WHERE=menu2extras fell through to the `title` branch. The capture is well-formed
and is of a different transition than intended, which is the build-ordinal error's
shape again: right-looking output for the wrong object. What caught it was the log
LACKING the navigation lines the intended branch prints; the data itself looked
entirely fine.

Salvaged, because the accidental transition is one already measured twice:

  run   outgoing ramp             black   incoming decay
  1     67-70: 63,127,191,255     3       73-77
  2     64-67: 63,127,191,255     3       70-74
  3     92-95: 63,127,191,255     3       98-103

Three independent runs, gap = 3 frames every time, outgoing ramp byte-identical
in all three. That takes "the black gap is not a load" from two replicates to
three, and makes the 4-frame outgoing ramp as solid as anything measured here.

menu -> EXTRAS remains open; the condition is fixed (with an assertion this time)
and the run has not been taken.

METHOD gains two entries. Assert every edit, not most of them -- and have each
branch announce itself in the log, so a run that took the wrong path says so
before its numbers are read. And: "appears nowhere in crates/" is a claim about a
TREE. sylpheed-port found SYLPHEED_KF_TIME_SHIFT live at ui_layout.rs:497 on their
branch, which carries the stale era; both statements are true of different trees.
With main 145 commits behind and each agent on a topic branch, any claim about
what the code contains needs its ref attached.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
This commit is contained in:
sylph-decoder
2026-08-30 18:21:20 +00:00
parent e8e036f317
commit 1b3a9e9086
3 changed files with 69 additions and 3 deletions

View File

@@ -532,6 +532,26 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
rule vocabulary. **That is a sample, not a sweep**, and older headings are the
likelier to be stale for having had more chances to be overturned.
* 🔴 **Assert EVERY edit, not most of them.** A three-part patch to a capture
script asserted two replacements and left the third unchecked. The third
silently failed, so `WHERE=menu2extras` fell through to the `title` branch and
the run produced a **well-formed capture of a different transition** — which I
came close to analysing as the intended one. Same family as the build-ordinal
error: right-looking output for the wrong object. ⚠️ **What caught it was the
instrument's own log lacking lines the intended branch prints**, not the data
looking wrong — the data looked fine. So: assert every replacement, and **have
each branch announce itself in the log**, so a run that took the wrong path says
so before its numbers are read.
* ⚠️ **"Appears nowhere in `crates/`" is a claim about a TREE, and I stated it
without one.** I reported `SYLPHEED_KF_TIME_SHIFT` as removed and absent from the
code; `sylpheed-port` found it **live at `ui_layout.rs:497` on their branch**,
which carries the stale era. Both true, of different trees. On a project where
`main` is 145 commits behind and each agent works from a topic branch, *any*
statement about what the code contains needs its ref attached — the same
discipline as "state what the number is a number of", applied to scope rather
than to units.
## Runtime / emulator
* **Look at the PNG** — and check its dimensions.

View File

@@ -110,3 +110,26 @@ frame untextured full-screen textured (distinct) draws tex
78 [64] [8, 96, 246, 255] 8 6
79 [64] [9, 192, 245, 255] 8 6
80 [64] [10, 244, 255] 8 6
################################################################################
# A THIRD title -> menu REPLICATE, 2026-08-30 -- from a run that executed the
# WRONG EXPERIMENT. The script was invoked as WHERE=menu2extras but a condition
# edit had silently failed to apply, so it took the `title` branch instead. The
# capture is well-formed and is of a different transition than intended -- the
# same shape as the build-ordinal error, caught only because the log lacked the
# navigation lines the intended branch prints.
#
# run outgoing ramp black frames incoming decay
# 1 (fadecap2) 67-70: 63,127,191,255 70,71,72 = 3 73-77
# 2 (fadecap4) 64-67: 63,127,191,255 67,68,69 = 3 70-74
# 3 (m2e) 92-95: 63,127,191,255 95,96,97 = 3 98-103
#
# ✅ THREE INDEPENDENT RUNS, gap = 3 frames every time, and the outgoing ramp is
# byte-identical in all three (63, 127, 191, 255 -- steps of exactly 64). That
# strengthens "the black gap is not a load" from two replicates to three, and the
# ramp's exactness across runs makes the 4-frame outgoing duration as solid as
# anything measured here.
#
# 🟡 STILL OPEN: menu -> EXTRAS, the reverse of the pair measured at a 2-frame
# gap. The instrument is fixed (WHERE=menu2extras now reaches its branch) and the
# run has not been taken.

View File

@@ -24,6 +24,10 @@
# WHERE=menu (default) arms on the main menu and presses (B) -> menu -> title.
# WHERE=title arms on the boot title and presses (A) -> title -> menu.
# WHERE=extras navigates to EXTRAS, arms there, presses (B) -> menu.
# WHERE=menu2extras navigates to EXTRAS, (B)s back to the menu with focus
# restored, arms there and presses (A) -> EXTRAS. The
# REVERSE pair, to test whether the black gap is a property
# of the screen pair or of the direction.
# Tests whether "(B) has no black interval" is a rule or
# one screen pair -- sylpheed-port's BLOCKED.md ask #1.
# The two transitions have DIFFERENT declared fade-ins for the incoming screen --
@@ -71,7 +75,7 @@ if [ "$WHERE" = "menu" ]; then
done
[ "$s" = "menu" ] || { echo "NO MENU (screen=$s)"; exit 2; }
BTN=B
elif [ "$WHERE" = "extras" ]; then
elif [ "$WHERE" = "extras" ] || [ "$WHERE" = "menu2extras" ]; then
python3 "$SD/pad.py" tap A 0.5
for _ in 1 2 3 4 5 6; do
sleep 4; s="$(screen)"; echo " after A: $s"
@@ -90,12 +94,31 @@ elif [ "$WHERE" = "extras" ]; then
shot "$OUT/try$try.png"
w="$(python3 "$SD/which_title_screen.py" "$OUT/try$try.png")"
echo " try $try: $w"
case "$w" in extras*) found=1; break;; esac
# ⚠️ REQUIRE A MARGIN. The first version accepted any line starting
# "extras", but which_title_screen.py returns a nearest-match even for a
# screen outside GP_TITLE entirely -- where the margin collapses to ~0.1.
# A bare prefix test would then accept a wrong screen on a coin flip. The
# control puts a true match at ~10-11; require > 5.
m=$(echo "$w" | sed -n 's/.*margin \([0-9.]*\).*/\1/p')
ok=$(awk -v m="${m:-0}" 'BEGIN{print (m>5)?1:0}')
case "$w" in extras*) [ "$ok" = 1 ] && { found=1; break; }
echo " (rejected: margin ${m:-?} <= 5)";; esac
python3 "$SD/pad.py" tap B 0.5; sleep 5
python3 "$SD/pad.py" dpad UP 0.3; sleep 2
done
[ -n "$found" ] || { echo "NEVER REACHED EXTRAS"; exit 3; }
BTN=B
if [ "$WHERE" = "menu2extras" ]; then
# We are ON extras. (B) returns to the menu with focus RESTORED on EXTRAS
# (measured 4/4, menu-navigation-semantics.md), so arming there and pressing
# (A) gives the menu -> EXTRAS transition: the exact reverse of the pair
# already measured at a 2-frame gap.
python3 "$SD/pad.py" tap B 0.5; sleep 6
shot "$OUT/back-on-menu.png"
echo " back on menu: $(python3 "$SD/which_title_screen.py" "$OUT/back-on-menu.png")"
BTN=A
else
BTN=B
fi
else
# arm on the title itself and press (A): the incoming screen is then build 5,
# whose declared fade-in is 12 units where build 4's is 16.