From 7e9fb55a7972c1439ff3a9d9ef63385909d69466 Mon Sep 17 00:00:00 2001 From: sylph-decoder Date: Thu, 3 Sep 2026 19:54:21 +0000 Subject: [PATCH] handoff: F5 code route attempted and not settled; no literal snap target Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t --- docs/port/HANDOFF.md | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/docs/port/HANDOFF.md b/docs/port/HANDOFF.md index 9848e86e..0c414fe4 100644 --- a/docs/port/HANDOFF.md +++ b/docs/port/HANDOFF.md @@ -6346,3 +6346,24 @@ measured, not read off the leaf table. per capture". Both leaves give a complete boundary-to-boundary cycle in **both existing logs** — no new capture. The truncating reader saw one quad, so it could only ever see one of the four cycles already on disk. + +## ❔ F5's code route — not settled, and saying so (`a274eb0`) + +`docs/re/f5-code-route-no-literal-target.md`. **Nothing here changes what you +ship**; the capture route already answered F5 and is unaffected. + +The brief asks for two routes that should agree. I had run only the capture. The +code route is now attempted and **I did not find the instruction** — `GamePart_Title`'s +phases 2 and 3 dispatch through vtables on nearly every branch, so tracing the +clock write statically needs indirect-call resolution this container lacks. + +One bounded negative is worth having: over `0x821C4000–0x821CD000` there is **no +`li rN,` for any v in 160…250**, against a control of 684 `li` instructions in +the same range. **So the snap target is computed or read from the bundle, not a +literal.** That independently supports the capture result — a data-derived target +has no constant to name it, which is why it sits in a window where nothing +observable changes. + +Next instrument, when it is worth it: a **write-watch on the UI group's clock +field** in Canary. It would name every writer including the snap, and close the +standing "which function advances the clock" question at the same time.