diff --git a/AGENTS.md b/AGENTS.md
index 06fc666..54f5609 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -2820,3 +2820,27 @@ six-byte and CRC chasing of earlier rounds was standing on top of.
 One cell is still missing, and it separates the call from the act: replace display_clear() with the app's own
 memset of api->fb to zero and then blit. If that paints, the problem is the call itself and its side effects;
 if it does not, clearing and blitting in that order is the problem, and the game can be written to avoid it.
+
+**Round 80: the app runs and blits, and the panel stays at 43 -- the metric may be the thing that is wrong.**
+
+Zero the framebuffer with the app's own loop and blit once, which is the two effects MsDraw gets from
+display_clear() plus blit_full() without the call:
+
+    MsZero.app code 68 B, crc32 0x85057463
+    boot panel 485, framebuffer 485 nonzero
+    after F 7 DOWN panel 525, framebuffer 525 nonzero
+    after MENU  panel 43, framebuffer 0 nonzero, and it stays there
+
+The framebuffer going to zero is proof the app ran and its loop wrote where it meant to. The panel not
+changing is the puzzle, and fillff already answered half of it: filling with 0xFF and blitting takes the panel
+to 939. So a blit of 0xFF reaches the glass and a blit of 0x00 does not.
+
+The likely reason is ordinary driver behaviour: ST7565_BlitFullScreen need not send pages that are all zero,
+so a black frame sends nothing and the panel keeps whatever it had. That makes ink 43 a coincidence -- it is
+also the number of non-zero bytes in the launcher's title box -- and it means the metric has been lying about
+what these apps do. An app whose frame is black looks exactly like an app that never drew.
+
+That reinterpretation is cheap to test and it changes the shape of the remaining work. Fill the framebuffer
+with a pattern rather than a constant and blit: if the panel shows the pattern, the whole display path from an
+overlay app works, MsZero and MsOnce and MsDraw and the game have all been running, and what remains is the
+game's own drawing. If the panel stays at 43 even then, the driver is skipping more than zero pages.
diff --git a/AGENTS.zh-CN.md b/AGENTS.zh-CN.md
index dd556c6..ff3e145 100644
--- a/AGENTS.zh-CN.md
+++ b/AGENTS.zh-CN.md
@@ -2491,3 +2491,27 @@ boot ink 485 → F 7 DOWN 525 → MENU → 43，此后不动
 
 **还有一格是空的，而它能把「那次调用」与「那件事」分开** ✓：**把 `display_clear()` 换成应用自己对 `api->fb` 的清零 `memset`、然后 blit** ✓。
 **若那样能画 ✓，问题就在那次调用本身及其副作用 ✓；若同样不能 ✓，那么「先清零、再 blit」这个顺序就是问题 ✓，而游戏可以绕开它来写** ✓。
+
+**第 80 轮：应用在跑、也 blit 了，而面板停在 43 —— 也许错的是那个判据本身。**
+
+**让应用自己的循环把帧缓冲清零、再 blit 一次** ✓ —— **这正是 `MsDraw` 从「`display_clear()` + `blit_full()`」得到的那两个效果 ✓，只是去掉了那次调用** ✓：
+
+```
+MsZero.app 代码 68 B，crc32 0x85057463
+boot 面板 485，帧缓冲 485 个非零
+F、7、DOWN 之后 面板 525，帧缓冲 525 个非零
+MENU 之后  面板 43，帧缓冲 0 个非零，此后不动
+```
+
+**帧缓冲归零证明应用确实跑了 ✓、而且它的循环写到了它想写的地方** ✓。**面板没变才是谜题 ✓；
+而 `fillff` 已经回答了它一半** ✓：**填 `0xFF` 再 blit，面板会到 939** ✓。
+**所以：blit 出去的是 `0xFF` 时能到玻璃上 ✓，是 `0x00` 时不能** ✓。
+
+**最可能的原因是驱动程序的寻常行为** ✓：**`ST7565_BlitFullScreen` 不必发送全零的页** ✓，
+**于是一帧全黑什么都不发 ✓，面板保留它原来的内容** ✓。
+**这让 ink 43 变成了一个巧合** ✗ —— **它同时也是启动器那个标题框里非零字节的个数** ✓ ——
+**而它意味着：这个判据一直在骗我** ✗。**一个画面全黑的应用，看起来与一个从未作画的应用一模一样** ✓。
+
+**这个重新解释测起来很便宜，而且它会改变剩下工作的形状** ✓：**把帧缓冲填成一个图案（而不是一个常数）再 blit** ✓。
+**若面板显示出那个图案 ✓，那么从覆盖区应用出发的整条显示路径都是通的 ✓，`MsZero`、`MsOnce`、`MsDraw` 和那个游戏一直都在跑 ✓，
+剩下的只是游戏自己的画法** ✓。**若面板那时仍是 43 ✓，那么驱动程序跳过的东西不止全零页** ✓。