port: escalation resolved -- a uniform black hold is positively excluded

Their measurement orders the four gaps by the screen being LEFT: menu 0 and 1
frames, EXTRAS 2, title 3. Direction, button and incoming screen are each
positively ruled out -- the same pair both ways differs, (B) gives 0 and 2 while
(A) gives 1 and 3, and an incoming menu takes 3 from the title and 2 from EXTRAS.

That resolves the escalation I raised: a uniform value is not merely unsupported
but excluded, so 0 is no longer one option among several. It is the only honest
uniform choice, because it models the gap as absent rather than as constant.
black_hold_units is unchanged at 0; its justification is replaced.

And my own rule is now refuted rather than unadopted. Gap plus the incoming
screen's opening black-clear held at 16/16/18 on three transitions; their fourth
gives 16, 14, 16, 18, and decisively the two transitions with the same incoming
screen have different gaps, so the incoming screen cannot determine it. A fourth
point did to a three-point fit exactly what it should.

Not keying per outgoing screen: three screens with one value each restates the
data, which is the objection I raised against my own 16/16/18. BLOCKED row
rewritten to ask for a second value on any one outgoing screen.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF

authored/timing.json

@@ -145,38 +145,30 @@
   ],
   "black_hold_units": 0,
   "black_hold_why": [
-    "0, RE-DERIVED against FOUR measurements, not inherited from three.",
+    "0 = NOT MODELLED. The escalation is resolved: a uniform value is positively",
+    "EXCLUDED, so 0 is no longer one option among several -- it is the only honest",
+    "uniform choice, because it is the one that does not claim a constant exists.",
     "",
-    "The Decoder's measured black gaps are now 0, 6, 4, 6 units across four",
-    "transitions. When this was set to 0 the multiset was (0, 4, 6), and they held",
-    "me to re-stating the choice against the new data rather than carrying it --",
-    "the same standard I applied to check-all's stale allowance.",
+    "The Decoder ordered the gaps by the screen being LEFT (frames): menu 0 and 1,",
+    "EXTRAS 2, title 3. Three hypotheses are positively ruled out, not merely",
+    "unsupported. DIRECTION: EXTRAS->menu (2) and menu->EXTRAS (1) are the same",
+    "pair both ways and differ. BUTTON: (B) gives 0 and 2, (A) gives 1 and 3.",
+    "INCOMING SCREEN: an incoming menu takes 3 from the title and 2 from EXTRAS.",
     "",
-    "The arithmetic moved AGAINST 0 and it is worth writing down rather than",
-    "burying: a uniform 6 is wrong on 2 of 4 transitions for a total error of 8;",
-    "0 is wrong on 3 of 4 for a total of 16. Choosing 0 cost 1.7x the best fit on",
-    "three measurements and costs 2.0x on four. 0 is now the MINORITY outcome --",
-    "three of four transitions do have a gap.",
+    "So the quantity varies 0-3 frames by outgoing screen, and any uniform non-zero",
+    "value is wrong as a MODEL rather than merely off in magnitude. 0 models the",
+    "gap as absent; 6 would model it as constant, which the data excludes.",
     "",
-    "IT IS STILL 0, and the reason is unchanged because it was never the fit: 0",
-    "adds no black the game does not have, which is the tie-breaker",
-    "input_during_transition already uses in this file, and it is measured-correct",
-    "for a real transition rather than for an average of them. Picking 6 because",
-    "it appears twice is choosing a mode from four samples with no rule behind it.",
+    "MY OWN RULE IS REFUTED, not just unadopted. It was gap + the incoming",
+    "screen's opening black-clear = a constant, holding at 16/16/18 on three",
+    "transitions. Their fourth gives 16, 14, 16, 18 -- and decisively, the two",
+    "transitions with the SAME incoming screen (main_menu) have different gaps,",
+    "so the incoming screen cannot determine it. A fourth point did to a",
+    "three-point fit exactly what it should.",
     "",
-    "ALSO CHANGED: the gap is NOT machine-dependent. It was defensible to hold 0",
-    "partly because the quantity might be a load and therefore unauthorable; the",
-    "Decoder has now shown it is deterministic to the frame -- bundle size runs the",
-    "wrong way, and a repeat run moved press-to-first-change by ~12 frames while",
-    "the gap did not move at all. So this is a real game quantity with a rule",
-    "nobody has found, not noise. That REMOVES an excuse for 0 without supplying a",
-    "value.",
-    "",
-    "TRIPWIRE, because 'invent nothing' can stop being conservative: if the gap is",
-    "non-zero in most transitions and no rule emerges, systematically omitting a",
-    "real quantity is no longer the cautious choice -- it is a different invention.",
-    "Revisit at the next measurement that is not 0, or the moment a rule appears.",
-    "The port is currently wrong by 4-6 units on three of four known transitions",
-    "and says so here rather than in a number that looks decided."
+    "DO NOT key this per outgoing screen yet. Three outgoing screens with one",
+    "value each restates the data rather than predicting it -- the same objection",
+    "I raised against my own 16/16/18. Key it when a screen has more than one",
+    "measured value, and key it on the screen being LEFT."
   ]
 }