diff --git a/AGENTS.md b/AGENTS.md
index 8c941b7..fcf248b 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -906,6 +906,23 @@ panel model at all** -- the gutted variant was only ever measured by its PC shar
 The second is cheap to settle: an app that does nothing but display_clear plus blit_full should visibly erase the
 launcher's title box.
 
+**Round 17: the game paints. What was missing was a per-frame delay, and the display path was never broken.**
+
+Three measurements settled it. A clear-and-blit app left the panel byte-identical, and filling the whole
+framebuffer through api->fb and blitting turned it from 43 non-zero bytes to 596 -- so an overlay app's
+framebuffer writes and blit_full do reach the panel, and the earlier reading of "the panel never changes"
+was about content, not plumbing. What actually blocked the frame was Minesweeper's own delay_ms(40) on the
+invalid-key path: in this emulator 40 ms of guest time is seconds of wall time, and a frame already spends
+roughly twenty seconds inside the firmware's font reads, so the frames were minutes apart. Removing that
+delay -- the loop redraws every pass anyway -- produced a complete frame within 24 s: the panel went from 43
+to 390 non-zero bytes, ink 1275, with the title, the counters and the field all legible in the dump.
+
+**Input is the remaining gap.** Pressing MENU changed nothing (596 -> 596) and pressing DOWN sent the app out
+of its loop altogether: the panel went back to the launcher's 43-byte title box, which happens only on the
+path that treats a key as EXIT. So get_key() is not returning the APP_KEY_* values this app compares against,
+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.
+
 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 b1c0876..3cbb49d 100644
--- a/AGENTS.zh-CN.md
+++ b/AGENTS.zh-CN.md
@@ -739,6 +739,20 @@ g_cursor、g_state、g_mine_left、g_open、g_flag、g_mine —— 正是两个
 **从叠加应用发出的 blit_full 到底有没有送到面板模型** —— 掏空版当初只量了 PC 占比，从没看它的屏幕显示了什么。
 第二个很便宜就能定论：一个只做 display_clear + blit_full 的应用，应当明显擦掉启动器的标题框。
 
+**第 17 轮：游戏画出来了。缺的只是每帧那个延时，而显示通路从头到尾都是好的。**
+
+三个测量把它定死了。一个只做清屏加 blit 的应用让面板逐字节未变；而通过 api->fb 把整个帧缓冲填满再 blit，面板
+从 43 个非零字节变成 596 个 —— 也就是说**叠加应用的帧缓冲写入与 blit_full 确实能到达面板**，而此前"面板从不
+变化"的读数说的是**内容**，不是**通路**。真正挡住那一帧的是扫雷自己在无效按键分支上的 delay_ms(40)：在这个
+模拟器里 40 ms 的客户机时间是若干秒的真实时间，而一帧本来就已经要在固件的字库读取里花掉大约二十秒，于是帧与帧
+之间隔了几分钟。把那个延时去掉之后（这个循环本来每轮都重画），**24 秒内就出现了完整的一帧**：面板从 43 变到
+390 个非零字节、ink 1275，标题、计数器和场地在转储里都清晰可读。
+
+**剩下的是输入。** 按 MENU 没有任何变化（596 → 596），按 DOWN 则让应用**直接退出了循环**：面板回到启动器那个
+43 字节的标题框，而那只会在"把某个键当成 EXIT"的那条路上发生。也就是说 get_key() 并没有返回这个应用在比较的
+那些 APP_KEY_* 值，或者按键没有按发送的那样到达它。最便宜的查法是**让应用把它收到的原始键码画出来**、从面板上
+读它，而不是猜映射。
+
 下一轮就从这里开始：同样的「自旋 + 单调用」形状，一次只放一个调用。
 进去、读同一份 trace。比起一开始那个模拟器悬案，这是好得多的处境。