diff --git a/AGENTS.md b/AGENTS.md
index bf409f3..6de25e0 100644
--- a/AGENTS.md
+++ b/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.
 
diff --git a/AGENTS.zh-CN.md b/AGENTS.zh-CN.md
index 7c27520..1fcc141 100644
--- a/AGENTS.zh-CN.md
+++ b/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。比起一开始那个模拟器悬案，这是好得多的处境。