diff --git a/AGENTS.md b/AGENTS.md
index 7ab75b6..055119a 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -1151,6 +1151,25 @@ Breakout, Cube3D, Beam), every field lines up -- entry_off 0, flags 0x0001 for B
 name at offset 20, version at 36, link_vma 0x20000280 byte-for-byte identical -- so pack_app.py is right and
 the refusal theory is dead. The entry point: the assembly listing's first function is app_main, its prologue
 push.w {r4-r11, lr} matches the blob's first bytes f0 b5 exactly, and the linker script pins .text.entry to
+
+**Round 32: the header is byte-identical to the firmware's own, and the font-read inference is suspect.**
+
+The working copy's app_api.h and the firmware's own, fetched from armel/uv-k1-k5v3-firmware-custom over
+HTTPS, are the same 14403 bytes with the same sha256 -- so round 31's prime suspect, that the app was
+compiled against a different layout, is wrong and is withdrawn. Reading the offsets back out of the
+assembly confirms the calls are right as well: the member at offset 28 is print_tiny and the one at 8 is
+display_clear, exactly where this app's source expects them.
+
+That leaves the measurement those conclusions rested on in doubt. The claim was that draw() is never
+reached because the flash probe records no font read after the app's code load. But the session shows
+1446 reads of the font region early on, which is what caching the font in RAM looks like -- and if the
+font is cached, print_tiny never touches the external flash at all, so "no font read" says nothing about
+whether draw() ran. The instrument, not the app, is what was measured.
+
+So the next oracle has to be one that cannot be confused this way: something visible in the panel and in
+nothing else. The sharpest unexplained fact is still that fill-every-byte-and-blit as the app's very first
+statement leaves the panel untouched, while the same act from a 320-byte app lights it; that contrast needs
+re-measuring with the app doing nothing else at all, and with the panel read before and after in one run.
 offset 0. And the acceptance: the firmware answers status 0 for the app over 0x0730.
 
 What is left is sharper than anything so far. The listing shows the app doing exactly what it was written to
diff --git a/AGENTS.zh-CN.md b/AGENTS.zh-CN.md
index 233d38e..94369f0 100644
--- a/AGENTS.zh-CN.md
+++ b/AGENTS.zh-CN.md
@@ -906,6 +906,22 @@ MENU 之后**一秒内**面板就落到 **43**（启动器的框）并停在那
 `push.w {r4-r11, lr}` 与 blob 开头 `f0 b5` 完全一致，而链接脚本把 `.text.entry` 钉在偏移 0。**接受**：固件对
 `0x0730` 回答 `status 0`。
 
+**第 32 轮：头文件与固件自己的那份逐字节相同，而「字库读取」这条判据本身可疑。**
+
+把固件自己的 `app_api.h`（从 `armel/uv-k1-k5v3-firmware-custom` 经 HTTPS 取回 ✓）与本仓库这份对比：同样是
+**14403 字节、同样的 sha256** —— 所以第 31 轮的首要嫌疑「应用是按另一份布局编译的」是**错的**，撤回。
+从汇编清单反读偏移也确认调用是对的：偏移 28 上的成员是 `print_tiny`、偏移 8 上的是 `display_clear`，
+正是这份源码期待的位置。
+
+于是支撑那些结论的**测量本身**变得可疑。当时的说法是「blob 加载之后没有任何字库读取 ⇒ `draw()` 从未被到达」。
+但整个会话里早期有 **1446 次字库区读取** —— 那正是**把字库缓存进 RAM** 的样子；而**如果字库被缓存了**，
+`print_tiny` 就**根本不需要碰外部 flash** ✓ —— 那么「没有字库读取」对「`draw()` 有没有跑过」**什么也说明不了**。
+被量到的是**仪器**，不是应用。
+
+所以下一个判据必须是**不可能这样被混淆**的那种：只体现在面板上、别处看不见的东西。目前最锋利、仍未解释的事实依旧是：
+**把应用的第一条语句写成「填满每个字节再 blit」，面板纹丝不动**；而一个 320 字节的应用做同一件事却能点亮它。
+这个对照需要用「应用除此之外什么都不做」重测一次，并在**同一次运行**里读前后两次面板。
+
 剩下的事实比此前任何一次都锋利。清单显示应用**确实按写的那样在做**：装载 `A`、取 api 里偏移 28 的成员、调用它
 （第一条 `print_tiny`）、然后内联展开 `new_game()`、进入主循环，而那个自旋正是 PC 直方图里最热的偏移。**应用在跑** ——
 417800 个样本落在叠加区内，集中在 0x18/0x8a/0x8c/0x9c/0xae，也就是它自己的前 180 字节。**而偏移 8 与 28 上的调用**