diff --git a/AGENTS.md b/AGENTS.md
index 0f96d78..8c941b7 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -886,6 +886,26 @@ the last mile.
 Next: the same variant harness on the three pieces of draw() separately (the header text, the 81-cell loop, the
 cursor), each with the loop spin that the surviving apps have.
 
+**Round 16: draw()'s halves are each fine, and the app is running -- so the next suspect is the blit itself.**
+
+Using the validated shape (for(;;) { long spin; one piece; }) the header block (display_clear + four print_tiny
+calls, the long strings and x=122 included) scores 26.1% and the 81-cell loop plus the cursor, written with local
+variables only, also scores 26.1% -- both the same as the control, so both are alive.
+
+The full Minesweeper, measured the same way, is running: 116 samples inside it over fifteen seconds, spread over
+eight distinct addresses (its spin at 0x200002e8/0x200002ec, plus 0x2000035a, 0x20000400, 0x20000564, 0x20000488
+and others), with the firmware still serving it -- 1024 font-region reads appear during the launch. Yet the panel
+never leaves the launcher's title box over ninety seconds, and that box is drawn before the app is entered, so
+nothing the app paints has ever reached the glass. Removing the opening settle spin changed nothing, which also
+retires the earlier idea that the app was simply still inside that spin.
+
+So the app runs, calls into the firmware, and never completes a frame. That leaves two candidates and one of them
+has never been checked: the statics (draw() reads g_cursor, g_state, g_mine_left, g_open, g_flag and g_mine, the
+only inputs the two surviving variants did not touch), and **whether blit_full from an overlay app reaches the
+panel model at all** -- the gutted variant was only ever measured by its PC share, never by what its screen showed.
+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.
+
 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 7139702..b1c0876 100644
--- a/AGENTS.zh-CN.md
+++ b/AGENTS.zh-CN.md
@@ -724,6 +724,21 @@ print_tiny、帧缓冲写入与光标反相 —— 这就是最后一公里。
 
 下一步：用同一套变体装置分别测 draw() 的三块（标题文字、81 格循环、光标），每块都带上那些能活的应用所拥有的循环自旋。
 
+**第 16 轮：draw() 的两半各自都没问题，而应用确实在跑 —— 下一个嫌疑是 blit 本身。**
+
+用已验证的形状（for(;;) { 长自旋 ; 一块代码 }）测：标题区（display_clear + 四次 print_tiny，含长字符串与 x=122）
+得 26.1%；81 格循环加光标（只用局部变量写）也得 26.1% —— 都与对照组相同，即两者都活着。
+
+完整版扫雷用同样方式测，**它在跑**：十五秒里有 116 个样本落在它里面，分布在八个不同地址（自旋在 0x200002e8/
+0x200002ec，另有 0x2000035a、0x20000400、0x20000564、0x20000488 等），固件仍在为它服务 —— 启动期间出现 1024 次
+字体区读取。然而九十秒里面板始终没有离开启动器的标题框，而那个框是在应用被跳进去**之前**画的，所以应用画的东西
+从未到达玻璃。去掉开场自旋也没有任何变化，这同时否掉了先前那个「应用还卡在自旋里」的想法。
+
+结论：应用在跑、也在调用固件，却从未完成一帧。剩下两个候选，而其中一个**从未被检查过**：静态变量（draw() 会读
+g_cursor、g_state、g_mine_left、g_open、g_flag、g_mine —— 正是两个存活变体都没碰过的输入），以及
+**从叠加应用发出的 blit_full 到底有没有送到面板模型** —— 掏空版当初只量了 PC 占比，从没看它的屏幕显示了什么。
+第二个很便宜就能定论：一个只做 display_clear + blit_full 的应用，应当明显擦掉启动器的标题框。
+
 下一轮就从这里开始：同样的「自旋 + 单调用」形状，一次只放一个调用。
 进去、读同一份 trace。比起一开始那个模拟器悬案，这是好得多的处境。