From 2bf93916bb9a0d723e7a6897bb69d5f8f5271dd4 Mon Sep 17 00:00:00 2001 From: Sylpheed port agent Date: Thu, 3 Sep 2026 19:38:37 +0000 Subject: [PATCH] port: the two sweep leaves DO run on their own periods -- refutation not landed MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The Decoder raised it and could not test it: if the port ran both leaves on one rate they would stay locked and drift ~118 units per cycle. The leaves declare 600 and 720. Pre-registered, then measured on a real boot. At raw leaf clock 4873: pteff03 span 600 -> measured 72.6 (fposmod 73) pteff03a span 720 -> measured 552.6 (fposmod 553) The port takes each span from that leaf's OWN keyframes, so they were never locked. 17748 samples, title clock reaching 9745 -- the sweep loops 162 s in. šŸ”“ Two false alarms of mine on the way, both the same mistake: - used --time (which sets frozen and bypasses the holding clamp BY DESIGN) to ask about RUNNING behaviour, and nearly reported the whole title vanishing past t=250. On a real boot settle_window [160,236,198] clamps to t=198 and a filmed frame at view_units 6733 shows the complete title. - read a probe going quiet as the feature stopping. Two runs ended at u~236; that was the RUN ending, not the sweep. With a film attached the same probe reaches 9745. Both are the frozen-sweep lesson again: the diagnostic that pins the clock cannot answer a question about the clock running, and an instrument going quiet is not the subject going quiet -- the same shape as a count of zero meaning only that nothing reached the reader. --- docs/port/f6-what-starts-the-sweep.md | 39 +++++++++++++++++++++++++++ 1 file changed, 39 insertions(+) diff --git a/docs/port/f6-what-starts-the-sweep.md b/docs/port/f6-what-starts-the-sweep.md index 10294c36..3d02c00f 100644 --- a/docs/port/f6-what-starts-the-sweep.md +++ b/docs/port/f6-what-starts-the-sweep.md @@ -520,3 +520,42 @@ both cases the argument was valid and the *inputs to the summary* were wrong. No amount of re-reading the claim finds that; only re-running it does. It is the argument for re-running over re-checking, and it is why the two findings flagged as unverified above were re-run rather than defended. + +--- + +# āŒ A refutation aimed at this renderer, measured and NOT landed + +The Decoder raised it and could not test it from their side: *"if your renderer +runs both leaves on a single rate, the two strips stay locked together and drift +from the game by ~118 units per cycle, growing without bound."* The two leaves +declare **600** and **720** unit loops. + +**Pre-registered, then measured on a real boot** via `--probe-leaf`. At a raw leaf +clock of 4873: + +| leaf | span | measured `leaf_t` | `fposmod(4873, span)` | +|---|---|---|---| +| `pteff03` | 600 | **72.6** | 73 | +| `pteff03a` | 720 | **552.6** | 553 | + +The port takes each leaf's span from **its own keyframes** ā€” `span = max(k.t)` +over `fe.keyframes` ā€” so the two were never locked. **17 748 probe samples, title +clock reaching 9 745**, i.e. the sweep is still looping 162 seconds in. + +## šŸ”“ Two false alarms of my own on the way there, both from the same mistake + +1. **I used `--time` to ask a question about running behaviour.** It sets + `frozen`, which by design bypasses the `holding` clamp, so the title read as + *empty* past t=250 and I nearly reported the whole title vanishing. On a real + boot it does not: `settle_window` is `[160, 236, 198]`, the elements clamp to + t=198, and a filmed frame at `view_units 6733` shows the complete title. +2. **I read a probe stopping as the feature stopping.** Two runs ended at + uā‰ˆ236 and I took that as the sweep dying at settle. It was the run ending ā€” + without `--film` the boot exits sooner. With a film attached the same probe + reaches 9 745. + +šŸ“Œ Both are the frozen-sweep lesson wearing new clothes: *the diagnostic that +pins the clock cannot answer a question about the clock running*, and *an +instrument going quiet is not the subject going quiet*. The second is the same +shape as the Decoder's own absence-of-a-quad bug ā€” a count of zero says only that +nothing reached the reader.