Round 20: the key-path conclusion is contradicted, and the probes' failure is unexplained

Round 15 measured get_key() repeated in an app loop at 27.1%, the same as the control, so calling it every pass is not what kills an overlay app; the previous section's use of the two key probes as evidence for that is wrong. Four probe builds (with and without an opening spin, with a short and with a 2M-iteration per-pass spin) all left the panel byte-identical at the launcher's own frame, so they did not run, and why is not established.

What that is not: not the shape other apps survived in, not get_key, not the framebuffer writes -- an app in the same slot that fills every framebuffer byte through api->fb and blits does paint (43 -> 596 non-zero bytes). The probes differ by zeroing the framebuffer and drawing with their own helper before blitting, which is the sort of difference that has to be isolated one change at a time rather than reasoned about.

AGENTS.md

@@ -941,6 +941,28 @@ comes back with it -- the key path is a plausible place for the firmware to reac
 the font reads that print_tiny provokes do not kill the app, so this is specific to the key path rather
 than to flash reads in general.
 
+**Round 20: the key-path conclusion is contradicted, and the probes' own failure is unexplained.**
+
+Round 15 measured get_key() repeated in an app loop at 27.1% -- the same as the control -- so calling it
+every pass is not what kills an overlay app, and the previous section's reading of the two key probes as
+evidence for that is wrong. Four probe builds (with and without an opening spin, with a short and with a
+2M-iteration per-pass spin) all left the panel byte-identical: 26 lit pixels on row 2 and a constant row-20
+pattern, which is the launcher's screen, drawn before the app is entered. So the probes did not run, and why
+is not established.
+
+What that failure is not: it is not the shape that other apps survived in, it is not get_key, and it is not
+the framebuffer writes -- an app in the same slot that fills every framebuffer byte through api->fb and
+blits does paint (43 -> 596 non-zero bytes). The probes differ from it in that they zero the framebuffer and
+then draw with a helper of their own before blitting, which is exactly the sort of difference that has to be
+isolated one change at a time rather than reasoned about, which is the discipline this file keeps preaching
+and which the probes ignored.
+
+Where the goal stands: the blank screen is fixed and understood; the Labs firmware displays; the app builds,
+installs through the page, runs, and paints a complete frame (title, counters and field all legible); the
+docs are bilingual and every step is committed and pushed. Input is the one item left, and it is not yet
+narrowed to a call -- a key press ends the running game, which is the part that is measured, and the probes
+meant to read the raw key codes never painted.
+
 That is where the next round starts: the same alternating-spin shape, one call at a time.
 trace. That is a much better place to be than the emulator mystery this started as.
 

AGENTS.zh-CN.md

@@ -768,6 +768,22 @@ EXIT 的路上），图景就是：**应用能跑、能画，是按键这条路
 是固件去读外部 flash 的一个可疑位置 —— 但 print_tiny 引发的那些字库读取并不会杀死应用，所以这是**按键路径特有**
 的，而不是普遍的 flash 读取问题。
 
+**第 20 轮：上一轮关于「按键路径」的结论被证伪，而探针自身的失败仍未查明。**
+
+第 15 轮测过在应用循环里反复调用 get_key()，得 27.1% —— 与对照组相同 —— 所以「每轮都调用它」并不是杀死叠加
+应用的原因，而上一节把两个键码探针当作这件事的证据是**错的**。四个探针构建（有／无开场自旋、每轮 3000 次／2M 次
+自旋）都让面板**逐字节相同**：第 2 行 26 个亮点、第 20 行一个恒定图案，而那正是启动器的画面 —— 是在应用被跳进去
+**之前**画的。也就是说探针没有运行，而**原因我并未查明**。
+
+这不是什么：不是那些应用赖以存活的形状，不是 get_key，也不是帧缓冲写入 —— 同一个槽里、通过 api->fb 把每个
+帧缓冲字节填满再 blit 的应用**是能画的**（43 → 596 个非零字节）。探针与它的差别在于：探针先把帧缓冲清零、再用
+自己的辅助函数画、然后才 blit —— 而这类差别**必须一次只改一处去隔离**，不能靠推理，这正是本文件反复讲的纪律，
+也是这四个探针所违背的。
+
+目标当前状态：白屏已修复且已查明；Labs 固件正常显示；应用能构建、能从页面安装、能运行，并且**画出了完整一帧**
+（标题、计数器与场地都清晰可读）；文档双语文，每一步都 commit 并 push。**只剩「输入」这一项**，而它还没有被
+收窄到某个调用 —— 已测得的部分是「按下键会结束正在运行的游戏」，而用来读原始键码的探针从未画出任何东西。
+
 下一轮就从这里开始：同样的「自旋 + 单调用」形状，一次只放一个调用。
 进去、读同一份 trace。比起一开始那个模拟器悬案，这是好得多的处境。