9d28bebb58
ptcopyright goes absent -> 255 in one frame at the snap, skipping its declared 138->160 ramp, so t>=160; the sweeps are still at 255 so t<238. Its identification is measured: in the control it first draws at t~143 and reaches 255 at t~164 against a declared 138->160. It stops there for a reason worth recording. Every build-4 element with a key past t=100 holds a constant pose across [160,238) -- their intersection is exactly that window -- so the game draws a bit-identical frame at t=160 and t=236. Refutation attempt on the port's 236.0: not merely survives, it can never be confirmed or refuted by capture. Every value in the window is observationally identical, and it stays that way because the clock freezes at settle and the exit ramp plays on leave rather than on a timer. Classified undecodable-with-reach so nobody spends another run on it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2.7 KiB
F5 — the snap target is [160,238) and cannot be pinned from any capture
Question: what title time does Ⓐ jump the clock to?
What the human looks at: nothing — this is a negative, and its value is that it stops anyone spending another run on it.
What this does NOT cover: the per-cycle phase fit, F6.
Classification: ❔ undecodable, with reach. ⟨capture⟩ + ⟨disc⟩.
The bound tightened to [160,238)
ptcopyright.t32 declares 0(α0) · 138(α0) · 160(α255) · 238(α255) · 244(α0),
and in the press run it goes absent at f435 → α255 at f436, skipping its
whole 22-unit ramp. So t ≥ 160.
Its identification is measured, not assumed: in the no-input control it first draws at t≈143 and reaches α255 at t≈164, against a declared 138→160.
The sweeps are at α255 at the same frame, and their parents' exit runs 238→250, so t < 238.
Why it stops there — nothing on the screen changes inside that window
Every element in build 4 with a keyframe past t=100, and where it is static:
| element | keys | static across |
|---|---|---|
ptlogo1 / ptlogo2 |
0,26,34,38,40,42,251,264 | 42→251 |
ptlogo_tm |
0,98,116,242,248 | 116→242 |
pteff00.prm |
0,16,261,269 | 16→261 |
ptloop01 / ptloop02 |
0,70,100,238,250 | 100→238 |
pteff02.prm |
0,46,61,76,118,236 | 118→236 (α0 both ends) |
ptlogo_back2 |
0,66,80,243,249 | 80→243 |
ptlogo_back2eff |
0,62,66,238,244 | 66→238 |
ptcopyright |
0,138,160,238,244 | 160→238 |
pteff01, ptlogo_back2eff5, ptlogoall_eff, ptlogoall_eff2 |
last key ≤118 | — |
Their intersection is exactly [160,238). The game draws a bit-identical
frame at t=160 and at t=236. No capture can separate them, because there is
nothing left that moves.
Refutation attempt — the port's 236.0
I tried to refute it and cannot, but the finding is stronger than "survives":
236.0 can never be confirmed or refuted by a capture. Every value in
[160,238) is observationally identical, so their choice is free.
Nor does it become observable later: the clock freezes at settle
(ui-clock-freezes-at-settle.md), and
the 238…250 exit plays when the screen leaves, not on a timer — so a
different starting t inside the window produces no difference at any point.
Not settled
- The exact value, permanently, from this route. Only guest memory or the code that performs the assignment could give it, and that is a different instrument than any capture.
- The per-cycle phase fit for the post-wrap decomposition.