diff --git a/AGENTS.md b/AGENTS.md
index fcf248b..bf409f3 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -923,6 +923,24 @@ path that treats a key as EXIT. So get_key() is not returning the APP_KEY_* valu
 or the keys are not reaching it as sent. The cheap way to find out is to have the app draw the raw key code
 it receives and read it off the panel, rather than guessing at the mapping.
 
+**Round 18-19: the raw-key probe never ran, and the contrast narrows input to one call.**
+
+Two font-free probes were built to draw the raw key code they receive (a marker bar on row 2, five bits on
+row 20) and both left the panel byte-identical across seven key presses -- 26 lit pixels on row 2 and a
+constant pattern on row 20, which is the launcher's own frame. So neither probe painted at all.
+
+The useful part is the contrast: an app of the same shape that fills the framebuffer through api->fb and
+blits (FillFb, round 17) does paint -- 43 non-zero bytes to 596 -- and the only substantive difference
+between it and these probes is that the probes call api->get_key() every pass. Put beside the round-17
+result, where the full Minesweeper painted a complete frame and then vanished the moment a key was pressed
+(the panel returned to the launcher's title box, which happens on the path that treats a key as EXIT), the
+picture is that the app runs and draws, and the key path is what ends it.
+
+That is where input stands, and it is one call wide: get_key() in an overlay app. The sector-cache question
+comes back with it -- the key path is a plausible place for the firmware to reach the external flash -- but
+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.
+
 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 3cbb49d..7c27520 100644
--- a/AGENTS.zh-CN.md
+++ b/AGENTS.zh-CN.md
@@ -753,6 +753,21 @@ g_cursor、g_state、g_mine_left、g_open、g_flag、g_mine —— 正是两个
 那些 APP_KEY_* 值，或者按键没有按发送的那样到达它。最便宜的查法是**让应用把它收到的原始键码画出来**、从面板上
 读它，而不是猜映射。
 
+**第 18-19 轮：原始键码探针从未跑起来，而对照把「输入」收窄到一个调用。**
+
+做了两个不依赖字库的探针，用来画出它收到的原始键码（第 2 行一条标记横杠、第 20 行五个位），而在七次按键前后
+面板都是**逐字节相同**的 —— 第 2 行 26 个亮点、第 20 行一个恒定图案，那正是启动器自己的画面。也就是说两个探针
+**都没有画**。
+
+有价值的是这组对照：形状相同、通过 api->fb 填满帧缓冲再 blit 的应用（FillFb，第 17 轮）**是能画的** —— 43 个
+非零字节变成 596 —— 而它与这两个探针**唯一的实质差别**就是探针每轮都调用 api->get_key()。再结合第 17 轮的结果
+（完整版扫雷画出了完整一帧，然后在**按下键的瞬间**消失，面板回到启动器的标题框 —— 而那只会发生在把某个键当成
+EXIT 的路上），图景就是：**应用能跑、能画，是按键这条路结束了它。**
+
+这就是输入目前的状况，而它只有**一个调用宽**：叠加应用里的 get_key()。扇区缓存那个问题也跟着回来了 —— 按键路径
+是固件去读外部 flash 的一个可疑位置 —— 但 print_tiny 引发的那些字库读取并不会杀死应用，所以这是**按键路径特有**
+的，而不是普遍的 flash 读取问题。
+
 下一轮就从这里开始：同样的「自旋 + 单调用」形状，一次只放一个调用。
 进去、读同一份 trace。比起一开始那个模拟器悬案，这是好得多的处境。