From 88d7656f5092d44763940647adecefb8f0822ef8 Mon Sep 17 00:00:00 2001 From: Sylpheed port agent Date: Wed, 2 Sep 2026 18:28:12 +0000 Subject: [PATCH] port: the sweep identification resolved -- and my proposed repair was wrong MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Travel direction settled it: both rows travel LEFT->RIGHT, so both are pteff03 split across two keys by per-frame rounding. pteff03a is not in the capture. So my 'the finding may still be correct via the OTHER row' does not apply -- there is no other row. I was right that size could not carry the assignment and wrong about what the assignment was. The larger half was not visible from here: the quoted low alphas were the nine lowest DISTINCT values, not a series -- 14 sub-floor samples out of 1754. The bound survives in shape and collapses in weight. Status 🟡. Renderer still unchanged. --- docs/port/f6-what-starts-the-sweep.md | 31 +++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) diff --git a/docs/port/f6-what-starts-the-sweep.md b/docs/port/f6-what-starts-the-sweep.md index 7571462c..19d9afe7 100644 --- a/docs/port/f6-what-starts-the-sweep.md +++ b/docs/port/f6-what-starts-the-sweep.md @@ -155,6 +155,37 @@ The two leaves travel in **opposite directions**: `pteff03` left→right, `pteff03a` right→left, separated by ~1 000 px for most of their run. One frame pair settles it. Nothing needs re-capturing. +## ✅ Resolved: the discriminator worked, and MY proposed repair was wrong + +The Decoder ran the travel-direction check on the capture they already had: + +``` +1.38x3.15 n=1140 x centre -1.690 -> +0.500 LEFT->RIGHT +1.39x3.15 n= 614 x centre -1.685 -> +0.495 LEFT->RIGHT +``` + +**Both rows travel the same way, so both are `pteff03`** — the 0.7 % size +difference is per-frame rounding splitting **one** element across two keys. +`pteff03a` is not in the capture at all. + +🔴 **So my "the finding may still be correct via the OTHER row" does not apply — +there is no other row.** The identification was broken a third way that neither +of us named: not two elements confused for each other, but one element counted +twice. I was right that size could not carry the assignment and wrong about what +the assignment actually was. + +⚠️ And the part I could not see from here, which is the larger one: the quoted +`8 24 33 50 58 …` were the nine **lowest distinct** values, not a series — a +tail, presented in a shape that reads as a ramp. **14 sub-floor samples out of +1754.** The bound survives in shape and collapses in weight: one sample below 128 +is still unexplainable by a leaf flooring at 128, but 14 of 1754 is where a +grouping slip or a partial frame would show up. + +**Status: 🟡 not refuted, not established.** The next unit is a re-read of data +already on disk — the same capture as a *series* across t=70…100, where a +multiplying parent must ramp on nearly every frame rather than in 14 stragglers. +That unit is the Decoder's and has not been run. + ## What the port does about it: nothing yet Adopting a decode whose element assignment is unresolved is how this project has