8dfce96b79
Two runs, neither answering whether a .tbm draws pixels. Run 1 TIMED the title->menu transition and was still on the title 8 s later (glyph 714, the plate's pulse trough), so the second tap did the transition and the 'submenu' capture is the menu. Void. Run 2 DETECTED the menu instead -- glyph 327, matching live-main-menu.png exactly -- tapped 0.8 s later, and 12 s after that was still on the menu. The log says why: 2 file-pad vk=5800 lines, i.e. ONE press, and one RE-INPUT delivery. The second tap was never delivered, with zero swallow lines so it is not the sign-in path. A 0.12 s press issued while the guest is still loading a screen is missed outright. So 'the press did nothing' and 'there was no press' look identical from the screen, and only the log separates them. Worth more than the run: this is the third time in one iteration that timing was used where detection was required -- the title->menu wait, the menu->submenu wait, and the press itself. Each fix is the same substitution, and each was written only after the timed version had produced a confident wrong answer. Also records that no focus detector is needed for this question, since every main-menu destination except EXTRAS carries a .tbm decider. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
36 lines
1.8 KiB
Plaintext
36 lines
1.8 KiB
Plaintext
# Attempt to reach a .tbm-bearing submenu -- NOT REACHED, and why.
|
|
#
|
|
# 2026-08-30. The open question is ui-forced-backdrop.md's 24 .tbm deciders:
|
|
# our compose draws NOTHING for a .tbm, so their verdicts are 'correct or
|
|
# inert' and indistinguishable. Every main-menu destination except EXTRAS
|
|
# lands on an archive holding one, so no focus detector is needed -- press A
|
|
# on whatever is focused and identify the screen from the capture.
|
|
#
|
|
# RUN 1 -- the title->menu transition was TIMED (tap, wait 8 s, assume).
|
|
# 8 s later the screen was still the TITLE: glyph 714, the plate pulse's
|
|
# trough. So the second tap performed the transition and the 'submenu'
|
|
# capture is the main menu. Void for the question asked.
|
|
#
|
|
# RUN 2 -- menu DETECTED instead of timed (glyph in 250..420 for 6
|
|
# consecutive samples; the main menu is 327 and the plate is 714..1520).
|
|
# [351.3s] tapped A
|
|
# [357.2s] MENU detected (glyph 327) -- pressing A into a submenu
|
|
# [358.0s] tapped A
|
|
# [369.8s] submenu captured (glyph 327, mean 44.4)
|
|
# -> still the main menu. 2.4 % of pixels differ from the menu capture.
|
|
#
|
|
# 🔴 WHY: the second tap was NEVER DELIVERED.
|
|
# [file-pad] vk=5800 lines: 2 -- that is ONE press (down + up)
|
|
# [RE-INPUT] -> user=0 vk=5800: one down, one up
|
|
# swallowed by IsUIActive: 0 (so NOT the sign-in dialog path)
|
|
#
|
|
# The tap at 358.0 s came 0.8 s after the menu appeared, while the guest was
|
|
# still loading it. A 0.12 s press is missed entirely if the guest does not
|
|
# poll during that window -- the pad driver reports what it emitted, and the
|
|
# guest simply never asked.
|
|
#
|
|
# WHAT WORKS AND IS NOW VALIDATED:
|
|
# * the plate-pulse title detector (three runs)
|
|
# * the MENU detector: glyph 327, matching live-main-menu.png exactly
|
|
# * delivery is checkable in-log: [RE-INPUT] ... -> user=0 vk=5800
|