diff --git a/AGENTS.md b/AGENTS.md
index 1c1e8ff..0683627 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -999,6 +999,29 @@ the deliberate correction above it: the earlier attempt at this round blamed the
 removed the instrumentation and rebuilt the round-17 source did not bring the frame back, which is what moved
 the suspicion to the launcher and the image rather than the app.
 
+**Round 24: the launch sequence, key by key, and proof that the app really is loaded and entered.**
+
+Reading the panel after each single press from a fresh power-on gives the sequence the launcher actually
+wants, and it is not the one this file said before: F, then 7, then **DOWN opens the app menu** (the panel
+goes 489 -> 552), then DOWN again moves the selection (552 -> 526, ink 1799 -> 1677), then MENU hands the
+screen over (ink 210, the launcher's own box). Earlier notes that say F then 7 opens the menu are wrong,
+and that error is what made several rounds of MENU presses look inert: on the freshly opened menu the first
+press only sets the selection, exactly as the round-21 entry says.
+
+With the handover reached, the flash probe shows the load itself as the session's **last two transactions**:
+
+    addr=108000 len=64   first=46415031 01000101   <- the FAP1 header of slot 3
+    addr=109000 len=2444 first=f0b599b0 fd490860   <- the app's code, exactly code_size bytes
+
+and the PC probe (2 ms) catches four samples inside the 4 KiB overlay in a three-second window, so the
+loader copies and the CPU really does enter the app. It then disappears, and the launcher's box stays on
+the glass -- the same shape round 8 described, and the opposite of what round 17 measured from this very
+same artifact.
+
+So the open question is now precise: with the launcher reached and the app entered, what ends it at the
+handover. The next instrument is the 2 ms PC trace across the handover rather than after it, sampled from
+the moment MENU is pressed.
+
 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 9a99488..47e685e 100644
--- a/AGENTS.zh-CN.md
+++ b/AGENTS.zh-CN.md
@@ -811,6 +811,24 @@ MENU** 量到游戏自己那一帧的，所以问题不在应用；变的是**
 顺便记下与上面那条更正在一起：这一轮早先我怀疑过应用，而「去掉插桩、重建第 17 轮那份源码」的对照并没有把那一帧找回来，
 正是这个对照把嫌疑从应用移到了启动器与镜像上。
 
+**第 24 轮：逐键测出的启动序列，以及「应用确实被加载并进入」的证据。**
+
+从干净上电开始、每次只按一个键并读屏，得到的才是启动器真正要的序列，而且与本文件以前写的不同：
+F → 7 → **DOWN 才是打开应用菜单**（面板从 489 变成 552 ✓）→ 再按 DOWN 移动选中项（552 → 526，ink 1799 → 1677 ✓）
+→ MENU 交出屏幕（ink 210 ✓ 启动器自己的框 ✓）。以前写「F 加 7 打开菜单」是**错的**，而这个错误正是好几轮里
+「按 MENU 没反应」的来源：在刚打开的菜单上，第一次按键只是设定选中项，正与第 21 轮那条记录一致。
+
+走到交接点之后，flash 探针把加载动作显示为**整个会话的最后两条事务**：
+
+    addr=108000 len=64   first=46415031 01000101   ← slot 3 的 FAP1 头
+    addr=109000 len=2444 first=f0b599b0 fd490860   ← 应用代码，长度恰好是 code_size
+
+而 PC 探针（2 ms）在三秒窗口里抓到四个落在 4 KiB 叠加区内的样本 ✓ —— 所以加载器确实拷贝了、CPU 确实进入了应用。
+随后它消失，玻璃上留下启动器的框 —— 与第 8 轮描述的形状相同，而与第 17 轮用**同一份产物**量到的结果相反。
+
+于是未决问题变得精确了：启动器走到了、应用也被进入了，那么**在交接这一刻是什么结束了它**。下一个仪器是把 2 ms 的
+PC 追踪**跨过交接点**采样，而不是在它之后。
+
 下一轮就从这里开始：同样的「自旋 + 单调用」形状，一次只放一个调用。
 进去、读同一份 trace。比起一开始那个模拟器悬案，这是好得多的处境。