Round 33: the fill-and-blit probe does not reproduce; one of my readings was a menu row

Replicating round 17 exactly (332-byte fill-and-blit in slot 0, page-default taps) gave 485 -> 580 after F,7 -> 627 after MENU, and 627 held: the screen never left the app menu, so this run says nothing about the app. It did expose that 537/549/552/580/596/617/627 are one family -- the app menu, whose ink moves with the highlighted row -- while a genuinely all-lit panel would be ~1024 and has never been seen. At least one earlier 'it painted' reading was therefore a menu row.

Next: drive the launch with key.py's timing and confirm the handover by the 43-byte launcher box, then judge the app only by a signature no menu can produce.

AGENTS.md

@@ -1160,6 +1160,25 @@ compiled against a different layout, is wrong and is withdrawn. Reading the offs
 assembly confirms the calls are right as well: the member at offset 28 is print_tiny and the one at 8 is
 display_clear, exactly where this app's source expects them.
 
+**Round 33: the fill-and-blit probe does not reproduce, and one of my own readings has been lying to me.**
+
+The plan was to replicate round 17 exactly -- the 332-byte fill-every-byte-and-blit app in slot 0, launched
+with the page's default taps -- and read the panel before and after in one run. It did not reproduce. The
+readings went 485 (main screen) -> 580 after F and 7 -> 627 after MENU, and 627 then held for twenty seconds:
+the screen never left the app menu, so the app was never entered and this run says nothing about the app.
+
+The useful part is what that exposed. The values I have been reading as "the app painted" -- 537, 549, 552,
+580, 596, 617, 627 -- are one family: the app menu, whose ink moves with the highlighted row. A genuine
+all-lit panel would be about 1024 non-zero bytes and has never been observed, and the game's own frame in
+round 17 was a different signature entirely (390 non-zero bytes with ink 1275, legible in the dump). So at
+least one earlier "it painted" reading was a menu row, and every such claim in these notes should be read
+again against what the value actually is.
+
+What that leaves is narrower and better defined: the launch through synthetic keys is not reliable enough to
+carry a measurement, and the panel ink alone cannot tell a menu from an app. Both have to be fixed before the
+next attempt at the app itself: drive the launch with key.py's timing and verify the handover by the 43-byte
+launcher box, then judge the app only by a signature no menu can produce.
+
 That leaves the measurement those conclusions rested on in doubt. The claim was that draw() is never
 reached because the flash probe records no font read after the app's code load. But the session shows
 1446 reads of the font region early on, which is what caching the font in RAM looks like -- and if the

AGENTS.zh-CN.md

@@ -914,6 +914,21 @@ MENU 之后**一秒内**面板就落到 **43**（启动器的框）并停在那
 正是这份源码期待的位置。
 
 于是支撑那些结论的**测量本身**变得可疑。当时的说法是「blob 加载之后没有任何字库读取 ⇒ `draw()` 从未被到达」。
+
+**第 33 轮：填满+blit 的探针没有复现，而我自己的一个读数一直在骗我。**
+
+计划是精确复现第 17 轮 —— 332 字节的「填满每个字节再 blit」应用放进 slot 0、用页面默认点击启动 —— 并在同一次运行里
+读前后两次面板。**没有复现**。读数是 485（主画面）→ `F`、`7` 之后 580 → `MENU` 之后 **627**，然后 627 保持二十秒：
+屏幕**从未离开应用菜单**，所以应用根本没被进入，这次运行对应用本身什么也没说明。
+
+有价值的是它暴露出来的东西。我一直当作「应用画出来了」的那些数值 —— **537、549、552、580、596、617、627** —— 其实是
+**同一族：应用菜单**，它的 ink 随高亮行移动。真正的整片全亮（填满 1024 字节）**从未被观测到**；而第 17 轮游戏自己的那一帧
+是**另一种**特征（390 个非零字节、ink 1275，且在转储里可读）。所以至少有一次「它画出来了」其实是菜单的某一行 ——
+这些笔记里每一处此类断言，都应当拿数值的真实含义重新读一遍。
+
+剩下的东西更窄也更清楚：**用合成按键启动不够可靠，承载不了测量**；**而面板 ink 单独也无法把菜单和应用区分开**。
+在下次真正处理应用之前，这两件事都得先解决：用 `key.py` 的时序驱动启动、并用 **43 字节的启动器框**确认交接发生过；
+然后只用一个**菜单不可能产生**的特征来评判应用。
 但整个会话里早期有 **1446 次字库区读取** —— 那正是**把字库缓存进 RAM** 的样子；而**如果字库被缓存了**，
 `print_tiny` 就**根本不需要碰外部 flash** ✓ —— 那么「没有字库读取」对「`draw()` 有没有跑过」**什么也说明不了**。
 被量到的是**仪器**，不是应用。