Files
Sylpheed/authored/timing.json
MechaCat02 c3758e3850 port: land the play-tested work, and only that
Takes the port branch up to 77320d5e -- the state the human play-tested on
2026-09-02 -- for SOURCE paths only. Not a branch merge: `auto/port-p6-audio`
is 366 commits and 938 files, and most of that must not land.

WHAT COMES IN (76 files, all human-confirmed working):
  * the logo splash animation. 08ed3dd1 found it: `pose_at` ASSIGNED the settle
    instant instead of clamping to it, so the splash never animated at all --
    and the same bug manufactured a passing harness result, because the harness
    photographed t past the settle. Confirmed by play-test: "cannot notice any
    obvious difference from the actual game."
  * gamepad input -- (A)/(B) bound additively (`ui_accept` ships with NO joypad
    binding), stick latched with hysteresis at the game's own 61% digitise
    threshold. This is what made (A), video-skip and Extras work at all.
  * menu navigation and flow, menu audio, the exporter, the authored
    declarations, and 23 verification tools under tools/port/.

WHAT IS DELIBERATELY LEFT ON THE BRANCH:
  * everything after c0ae460a -- the F5/F6 title-timing investigation, whose own
    tip commit calls itself a "hand-off for one-minute human checks". Unchecked
    by definition; it goes through the new review gate like anything else.
  * the OPTIONS menu work of 2026-09-03. Real, probably good, NOT play-tested.
  * the F1 repeat mechanism, which its own commit calls "deliberately inert".

WHAT MUST NOT LAND, AND WHY THE .gitignore CHANGED:
  545 MB of extracted game content was committed on that branch -- 850 sprite,
  audio and transcoded video files under `export-probe/` and `export-probe2/`,
  plus 246 MB of loose .wav and .tsv at the repo root. This repository's own
  rule, in this file, is "never game content".

  The rule was not missing. It was written, and it was tightened on that very
  branch, with a careful comment explaining why BOTH `export/` and `data/base/`
  had to be listed -- while the exporter was writing to a third name that
  nobody had thought to list. Enumerating names is the thing that failed. So
  the ignore rules now describe the SHAPE: any top-level `export*/`, game media
  by extension, and loose capture output at the root. Verified both ways -- it
  catches all four offenders and ignores nothing currently tracked.

Verified: `cargo check --workspace` clean; all nine GDScript files parse in
project context, with a positive control (an injected syntax error is detected,
3 lines) so the clean result means something. `tools/port/check-all` was NOT
run -- it needs the container, the export tree and a display.
2026-09-04 16:17:14 +02:00

605 lines
36 KiB
JSON

{
"format": "sylpheed.timing/1",
"keyframe_units_per_second": 60,
"why": [
"HANDOFF Q1. The disc says a keyframe is at `t=30`; it does not say what a",
"`t` is. The unit was MEASURED off the running game, not decoded: a declared",
"15-unit fade lands on round(255*k/15) for all seven of its samples with k",
"stepping 2,4,6,8,10,12,14 on seven consecutive submitted frames -- so 2",
"units per rendered frame -- and the idle title presents at 28.3-28.8 fps,",
"a 30 Hz game, giving 60 units per second. A second line agrees: the",
"transition quad is declared black for 12 units, and a capture measured the",
"pure-black plateau at 0.17-0.23 s, where 12/60 = 0.20 s.",
"",
"Expressed as units-per-second rather than seconds-per-unit so the value is",
"exact rather than a repeating decimal a reader has to recognise.",
"",
"DELETE THIS FILE when a field on the disc is found that states the unit.",
"Nothing here is on the disc.",
"",
"🔴 DO NOT 'CORRECT' THIS AGAINST AN EMULATOR FRAME RATE. A draw-stream",
"measurement on 2026-08-29 found the presented units-per-frame rising 33 % over",
"a single boot (1.765 early, 2.357 late) and three independent readings of one",
"container's rate disagreeing with each other. That is the EMULATOR's",
"presentation pacing drifting, and no single units-per-frame figure describes a",
"run there.",
"",
"60 is a different quantity: the GAME's logical unit rate, measured off the",
"running game as HANDOFF Q1 (a declared t=30 landing on the linear value at",
"every one of seven sampled frames). The port renders at its own frame rate and",
"converts through this constant, so guest pacing cannot reach it. The two",
"numbers are not comparable and one is not evidence about the other.",
"",
"🔴 2026-09-01 — THE FIRST LEG ABOVE IS RETIRED. THE VALUE IS NOT.",
"",
"'2 units per rendered frame ... a 30 Hz game, giving 60 units per second' is a",
"FRAME-COUNT derivation, and the Decoder retired that mechanism the same day",
"(docs/re/units-per-second-measured.md): the same animation takes 21 frame",
"labels in one capture and 33 in another, and one splash logo steps +136,+34 in",
"one run and +17,+51,+34,+34,+17,+17 in the other. A fixed per-frame increment",
"cannot do that. The clock is TIME-INTEGRATED, not frame-counted, so `units =",
"2 x frames` computes an emulator artefact. The 2 was that run's frame pacing.",
"",
"✅ The port's RUNTIME was already right: `boot.gd` advances",
"`time_units += delta * units_per_second`, off delta time. Nothing in this port",
"derives a unit from a frame count. Audited 2026-09-01, and it is why the",
"retirement cost a justification and not a behaviour.",
"",
"✅ AND THE SECOND LEG NEVER TOUCHED A FRAME COUNT, which is why 60 survives:",
"the transition quad is declared black for 12 units and the capture bracketed",
"the pure-black plateau at 0.14-0.30 s (title-plate-delay-measured.md, at a",
"0.125 s sampling resolution). 12 units in 0.14-0.30 s is 40-86 units/s. That",
"is a declared unit count against a wall-clock duration, with no frames in the",
"chain -- and it EXCLUDES 120 units/s, which would need 0.10 s.",
"",
"✅ MEASURED DIRECTLY 2026-09-01: 56.8 units per guest second, control passing",
"at 1.15 %, from two elements agreeing at one clock (`ptbtn00` 657.9 alpha/s,",
"`ptcopyright` 650.4 alpha/s, which puts ptcopyright's segment at T = 22.25 --",
"a rate agreement AND a round declared length). 30 and 120 are both excluded.",
"",
"60 IS KEPT. 56.8 is 5.6 % away against a ~5 % quantisation resolution, so it",
"does not refute 60, and the Decoder explicitly did not ask for a change. The",
"reach is the TITLE: the splashes are a different GamePart and nothing yet shows",
"they tick at the same rate.",
"",
"⚠️ If anyone re-fits this from alpha: DROP THE LAST STEP of a ramp. It clamps",
"at 255 and reports more elapsed time than it consumed -- worth 4 % on the plate.",
"",
"🔴 2026-09-01 (later) — A PER-SCREEN RATE WAS PROPOSED AND NOT ADOPTED.",
"",
"docs/re/splash-declared-vs-captured.md proposes ~57 units/s for the title and",
"~35-40 for the splashes, i.e. that one constant cannot be right and that a",
"splash at 60 runs 1.5-1.7x too fast. THE PORT DID NOT MOVE, and the reason is",
"arithmetic on a measurement already cited in this file:",
"",
" the 160-unit hold is the DEVELOPER splash's a=255 plateau, t=30..190, and it",
" is measured at 4.514 s. The 210-unit group CONTAINING it is measured at",
" 3.37/3.50/3.51 s over three cold boots (the dwell_why block below). A",
" sub-interval cannot outlast the interval containing it.",
"",
"The same three boots put the splashes at 57.7 and 60.7 units/s -- corroborating",
"60 on exactly the two screens the new figure puts at 35-39. At 35.4 the declared",
"groups would run 5.93 s and 7.20 s against corpus dwells of 3.37-3.51 and",
"4.30-4.60, i.e. each splash ~70 % longer than measured.",
"",
"⚠️ DO NOT ADOPT EITHER NUMBER UNTIL THAT IS RESOLVED, and do not split the",
"difference -- averaging two measurements that cannot both be true is not a",
"third measurement. docs/port/splash-rate-contradiction.md, asked as BLOCKED H7.",
"",
"⚠️ AND THE STRUCTURAL CLAIM MAY STILL BE RIGHT. 'One rate cannot cover every",
"screen' is a claim about the format, and the title's 56.8 does sit ~5 % off the",
"splashes' 58-61. If a per-screen rate is real this file should carry a MECHANISM",
"-- a field or a GamePart constant -- not two authored numbers. The Decoder has",
"'where the per-GamePart rate comes from' as its next item.",
"",
"🔴 2026-09-01 (later still) — RECLASSIFIED measured -> authored. THE VALUE DOES",
"NOT MOVE; THE LABEL WAS FALSE.",
"",
"The Decoder withdrew their guest-frame-rate finding the same day they published",
"it. ⚠️ THAT DOCUMENT IS NOT IN THIS CHECKOUT -- it is `guest-frame-rate-WITHDRAWN.md`",
"on their branch, named here in prose deliberately rather than in `source`:",
"`audit-kinds` flagged the first version of this entry DANGLING because I cited",
"a file I cannot read, which is exactly the check doing its job. The reading",
"below is from their message and is labelled as such.",
"It read the guest's presentation as 30 fps from a movie-frame ruler and",
"concluded 2 x 30 = 60. This file carried `kind: measured` on that strength.",
"`kind: measured` on the strength of it. It cannot any more.",
"",
"Three routes now disagree and at most one can be right:",
"",
" withdrawn movie cadence 60 units/s",
" vblank cadence (Xenia, 60 Hz) ~120",
" title-plate-delay, 120 units ~56 -- two runs agreeing to 6 ms",
"",
"⚠️ 60 IS KEPT ANYWAY, and it is not a coin toss between the three. The one leg",
"of this file's own reasoning that never touched a frame count still stands and",
"still brackets it: the transition quad is declared black for 12 units and the",
"capture measured the plateau at 0.14-0.30 s, i.e. 40-86 units/s. 60 sits inside",
"that; 120 does not. And ~56 is 7 % from 60, inside the same bracket.",
"",
"So the honest statement is: 60 is AUTHORED, bracketed by one surviving",
"frame-free measurement, and consistent with the nearest of the three live",
"routes. It is no longer 'measured', and anything that cited it as measured is",
"citing a withdrawal.",
"",
"📌 THE METHOD NOTE IS WORTH MORE THAN THE NUMBER, and it is the Decoder's: their",
"pre-registration named three ways the ruler could lie and guarded two. The third",
"occurred, and a PERFECT 1.0000 is exactly what it produces -- a triple buffer",
"rotating once per present gives run-length 1 at any frame rate. Both guards",
"tested how the buffer was READ, neither tested whether a change meant a decode.",
"",
" A clean result on an instrument whose key assumption is unguarded is not",
" confirmation. The cleanness may be the failure mode's own signature.",
"",
"Same family as this port's non-inverting latch check, which passed for the wrong",
"reason until its control failed.",
"",
"🔴 2026-09-01 — THE 12-UNIT BRACKET ABOVE IS WITHDRAWN. IT EXCLUDES NOTHING.",
"",
"I kept 60 on the ground that '12 declared units measured at 0.14-0.30 s gives",
"40-86 units/s, so 120 is excluded'. The Decoder refuted it and the refutation",
"holds on arithmetic I checked myself:",
"",
" the source doc says of that number, in its own words, 'at a sampling",
" resolution (0.125 s) that cannot do better'. 120 units/s predicts 12 units in",
" 0.100 s -- BELOW one sample interval. A 0.125 s sampler cannot resolve it and",
" reports about one sample, ~0.125-0.14 s. The 0.14 s low end is the",
" INSTRUMENT'S FLOOR, and 12/0.14 = 85.7 is an upper bound produced by dividing",
" by a floored duration. It is the value 120 predicts once the sampler is",
" accounted for.",
"",
"🔴 AND THE DEEPER ERROR IS MINE, NOT THE ARITHMETIC. I argued the leg survived",
"because it 'never touched a frame count'. True, and INSUFFICIENT: every",
"wall-clock duration off Canary is true/speed_factor, so apparent units/s =",
"true x speed -- and the speed factor is precisely what makes the three routes",
"disagree. I checked the leg for the WRONG CONTAMINANT. Frame-free is not",
"clock-free, and on this emulator clock-free is the property that matters.",
"",
"What actually survives from that leg, and it is the half I did not lead with:",
"the declared 12 units are independently confirmed as SIX FRAMES by",
"screen-transitions.md's 255/6-per-frame ramp. No wall clock in it at all. That",
"is evidence about units per FRAME -- which was never in dispute -- and silent",
"about units per second.",
"",
"SO 60 HAS NO SURVIVING BRACKET. It stays because nothing supports 120 either and",
"moving a shipped timeline on no evidence is worse than leaving it. That is a",
"default, not a derivation, and this entry now says so. `kind` is already",
"`authored`, which is the honest label for a default.",
"",
"🟡 2026-09-01 — 120 units/s IS NOW MEASURED, AND THIS PORT HAS NOT MOVED.",
"",
"The Decoder's content-hash experiment gives 120 (2 units/present x 60",
"presents/s), with the controls the withdrawn version lacked -- a static texture",
"hashing constant, 1 change in 403 samples, and movie luma not constant, 102",
"distinct hashes. Pre-registered bands, and the observed 0.5739 falls inside",
"them. It is a better experiment than either of the two it replaces.",
"",
"IT IS ALSO THEIR THIRD POSITION ON THIS NUMBER IN ONE DAY, reach is one boot,",
"and they said themselves that a second independent boot before a timeline is",
"rewritten is the defensible call. Agreed. 60 stays for now.",
"",
"⚠️ 60 IS NOT DEFENDED EITHER -- its bracket was withdrawn this morning. Both",
"numbers are undefended; the port keeps the one it ships because switching on a",
"single capture is a worse failure than holding on none. That is the whole",
"reasoning and it is not evidence about the game.",
"",
"✅ AUDITED, SO THE SWITCH IS CHEAP WHEN IT COMES: no seconds are baked into the",
"timeline anywhere. Every second this port prints or acts on is computed as",
"units / keyframe_units_per_second at the point of use. audio.json's loop_start_s",
"and loop_end_s ARE seconds and correctly do NOT follow this constant -- they are",
"positions in an audio file with no keyframe unit in them.",
"",
"🔴 One exception found and fixed: tools/port/verify-dwell read black_hold_units",
"from this file 'so it cannot drift again' and then divided by a literal 60.0.",
"The value could not drift; the conversion could.",
"",
"📌 THE FALSIFIER IS PRE-REGISTERED in docs/port/units-per-second-switch-readiness.md:",
"at 120 the publisher splash runs 2.13 s and the developer 1.75 s, against three",
"cold boots measuring 4.30/4.60/4.37 and 3.51/3.50/3.37. 120 and the dwell corpus",
"cannot both be right in wall-clock seconds -- the same collision that killed the",
"35 units/s proposal from the other direction.",
"",
"✅ 2026-09-01 (final position of the day) — 120 IS WITHDRAWN BY ITS AUTHOR AND 60",
"IS POSITIVELY SUPPORTED. The port never moved, so nothing has to be undone.",
"",
"The mechanism is worth more than the number: `units per present` HALVED when the",
"present rate doubled (Δα +34 at 27.2 presents/s, +17 at 51.4) while units per",
"second did not move (54.4 vs 51.4). The UI clock advances by elapsed TIME, not",
"by frame count -- so '2 units per frame' was never a property of the game, only",
"of a capture that happened to run at 27 fps. The 120 was 2 units/present x 60",
"presents/s, and the first factor is not a constant, so the product was not a",
"rate.",
"",
"Their write-up is `units-per-frame-is-not-a-constant.md`, under docs/re/ on",
"their branch. 🔴 NOT IN THIS CHECKOUT, so it is named WITHOUT a resolvable",
"path -- `tools/port/check-citations` flagged the first version of this very",
"paragraph as DANGLING, in the entry where I was recording the lesson about",
"dangling citations. The check does not care about a disclaimer, which is",
"correct: a path that does not resolve does not resolve.",
"",
"✅ 2026-09-01 (settled) — THE GAME'S CLOCK IS FRAME-BASED, 1 UNIT PER PRESENT.",
"Measured by the Decoder with a DESIGNED experiment rather than an inference:",
"`--framerate_limit=30` halved units/second to 30.2, doubled the publisher dwell",
"to 8.450 s, and left the modal alpha step at 17 where a time-based clock",
"predicts 34. Both controls passed first -- the limiter demonstrably took effect,",
"and all 8 splash quad rects were identical, so nothing but the frame rate",
"differed. `255 x 1 / 15 = 17` at 28.4, 51.4 and 54.8 presents/s alike.",
"",
"⚠️ THIS CHANGES WHAT 60 MEANS HERE, AND MAKES IT MORE FALSIFIABLE. If the game",
"advances 1 unit per present, its units/second IS its present rate. So",
"`keyframe_units_per_second = 60` is now equivalent to the claim:",
"",
" the game presented these screens at 60 Hz on the console.",
"",
"That is a sharper statement than 'the unit is 1/60 s' and it is checkable.",
"",
"✅ AND IT IS SUPPORTED, which the constant has not been until now. Canary",
"unlimited presents at 51-55 Hz and the splash dwell is 4.30/4.60/4.37 s over",
"three cold boots. A natively 30 Hz game would present at ~30 in Canary too --",
"which the framerate_limit run confirms, since forcing 30 made the same splash",
"take 8.45 s. It does not take 8.45 s unforced. So the game asks for ~60, not 30.",
"",
"🔴 AND THAT CLOSES THE CONSTANT AS A CAUSE OF 'THE PLATE IS LATE', for a NEW",
"reason and in the direction that matters. Under the frame-based model the only",
"alternative console rate is 30 Hz, which puts the plate at 236/30 = 7.87 s --",
"LATER than the 3.93 s the port ships, not earlier. There is no console present",
"rate that makes the plate arrive sooner than it already does here.",
"",
"⚠️ KEPT AS `authored`, NOT PROMOTED TO `measured`. The chain is inference over",
"three measurements (frame-based clock; Canary's unlimited present rate; the",
"dwell corpus) rather than a measurement of units per second. It becomes",
"`measured` the day someone reads the console's present rate for these screens",
"directly.",
"",
"📌 AND THE PORT'S OWN DESIGN IS DELIBERATELY NOT THE GAME'S, which is worth",
"stating so nobody 'fixes' it. The game is frame-based; this port is time-based",
"(`time_units += delta * units_per_second`). They agree at 60 fps, which is the",
"only rate the console ever asked the game to be right at. A time-based port",
"reproduces a 60 Hz console on hardware that is not 60 Hz; a frame-based port",
"would drift on every machine that is not -- and this port has measured itself at",
"9.7 to 69.4 fps depending on the renderer. DO NOT make the port frame-based to",
"match the game.",
"",
"✅ 2026-09-02 — 60 NOW STANDS ON A THIRD INDEPENDENT ROUTE, and the REASON",
"changed again while the value did not.",
"",
"The Decoder reconciled three of their own pages that held incompatible",
"positions -- 2 units per guest frame, time-integrated at 56.8, and 1 unit per",
"present -- with one mechanism: THE CLOCK ADVANCES ONE UNIT PER VBLANK, and",
"presents may be dropped without the clock caring. That explains steps that are",
"always multiples of 17 (1, 2 or 3 vblanks between two logged presents), and the",
"same animation spanning 21 labels in one capture and 33 in another, which a",
"strict per-present clock cannot produce.",
"",
"Their rate result is a MANIPULATION rather than an observation: 255 declared",
"units take 4.263/4.162 s at a 60 Hz vblank and 8.450 s at --framerate_limit=30",
"-- 59.8/61.3 against 30.2 units/s. So the vblank rate sets the unit rate, and a",
"console vblanks at 60.",
"",
"So the justification for 60 has now been: '2 units per rendered frame' (retired),",
"'the game presents at 60 Hz' (superseded), and now 'one unit per 60 Hz vblank'.",
"THE NUMBER HAS NEVER MOVED. That is worth noticing rather than celebrating -- a",
"value whose reason changes three times while it survives is either robust or",
"under-constrained, and the honest label is still `authored`.",
"",
"📌 THIS PORT INSTANTIATES THEIR NULL MODEL, which is the one thing this side can",
"contribute to that argument. Their reasoning turns on 'a time-integrated clock",
"predicts 4.25 s in BOTH conditions'. This port IS a working time-integrated",
"clock at 60 units/s, and its splash dwell across a 4.0x change in its own",
"rendering rate is 4.28 / 4.26 / 4.27 / 4.26 s -- flat to 0.5 %. So their",
"counterfactual is demonstrated rather than assumed. ⚠️ It is evidence about the",
"NULL, not about the game; it says what a time-integrated clock does, not what",
"the game's clock is.",
"",
"🟡 PER-VBLANK VS PER-PRESENT IS STILL OPEN, and they name the discriminating",
"experiment (log Xenia's vblank counter beside each present). ⚠️ IT IS",
"IMMATERIAL TO THIS PORT AND THEY SHOULD NOT RUN IT ON THE PORT'S ACCOUNT. The",
"two models differ only when the console DROPS a present: per-vblank keeps",
"real-time pace through a drop, per-present slows. This port is time-based, so",
"it matches per-vblank exactly and would run marginally ahead of per-present",
"during drops only. On a console presenting every vblank the two coincide, and",
"the screens in question are a handful of quads.",
"",
"🔴 2026-09-02 (later) — 'A THIRD INDEPENDENT ROUTE' IS WITHDRAWN BY ITS AUTHOR.",
"The paragraph above says 60 now stands three ways. It does not, and I recorded",
"the claim before challenging it hard enough.",
"",
"I raised that three routes to one number are weaker than they look if they share",
"an upstream assumption -- vblank rate, present rate and declared dwell are not",
"obviously independent. The Decoder audited it and agreed: route B needs 'the",
"guest presents 60x/s', which comes from the vblank histogram UNDER XENIA'S 60 Hz",
"LIMITER; route C needs 'the vblank is 60 Hz', which is that limiter's cvar; route",
"D is a wall-clock duration that lands on 60 only BECAUSE the vblank is 60 Hz.",
"All three reduce to one upstream fact: the display refreshes 60 times a second",
"on that emulator. One witness in three coats.",
"",
"✅ WHAT SURVIVES IS CONDITIONAL AND BETTER, and it is established by MANIPULATION",
"rather than agreement -- forcing 30 Hz gave 30.2 units/s, 60 Hz gives 59.8/61.3:",
"",
" units per second = THE DISPLAY REFRESH RATE.",
"",
"It becomes '60' only through a fact this corpus has never measured: an Xbox 360",
"outputs 60 Hz. That is a hardware specification. It is solid, and it belongs",
"CITED as a spec rather than folded in as a third measurement.",
"",
"📌 And the conditional form is the one that justifies this port's construction",
"rather than excusing it. 'units/s = refresh rate' says what to do on hardware",
"that is NOT 60 Hz, which is exactly why a time-based clock at a fixed 60 units/s",
"is right and a frame-based one would drift. `kind` stays `authored`: nothing",
"here promotes it, and the reason it is not `measured` is now sharper -- the",
"measurement is of a RELATIONSHIP, and the constant that closes it comes from a",
"datasheet."
],
"kind": "authored",
"source": "docs/re/ui-keyframe-time-unit.md, docs/port/HANDOFF.md",
"ramp": "linear",
"ramp_why": [
"Also HANDOFF Q1, and part of the same measurement: the fade lands on the",
"linear value at every one of the seven sampled frames, so there is no ease."
],
"ramp_kind": "measured",
"dwell_seconds": null,
"dwell_why": [
"NOT SET -- because the dwell is DECLARED, and the port already plays it.",
"",
"This key has now been wrong in two opposite directions, and the second was",
"mine, so both are recorded.",
"",
"It first said 'a screen's dwell is its OWN keyframe group'. Then GP_TITLE",
"build 4 was measured dwelling ~1100 presented frames against a declared ~120,",
"and I generalised that into 'the boot is KNOWN TOO FAST [refuted] on both splashes'.",
"🔴 THAT WAS AN OVER-CORRECTION and it is withdrawn. Build 4 is the title: its",
"exit is caused by something outside its timeline, so it holds. A splash's exit",
"is caused by nothing, so it plays its declared timeline and leaves. The title",
"is the exception, not the rule, and one screen was never enough to overturn",
"the other two.",
"",
"MEASURED 2026-08-29 by the Decoder over 3 cold boots",
"(docs/re/structures/boot-splash-dwells-are-declared.md):",
"",
" publisher declared t=0..255 = 4.250 s corpus 4.30 / 4.60 / 4.37",
" developer declared t=0..210 = 3.500 s corpus 3.51 / 3.50 / 3.37",
"",
"The developer agrees to 1.1 %, two of its three runs to 0.3 %.",
"",
"🔴 CORRECTED 2026-09-01. This said: 'The port emits 4.400 s and 3.650 s -- each",
"declared value plus the 9-unit black hold, exactly. So the pacing was right all",
"along and nothing changes in the code.' THE PORT DOES NOT DO THAT, and this",
"file is what stops it: `black_hold_units` is 0, set deliberately (see",
"black_hold_why -- a uniform value is positively excluded and only an",
"ordered-pair key survives). There is no 9-unit hold to add, so the sentence",
"described a behaviour asserted three keys above it and refused one key below.",
"",
"MEASURED off the shipping boot, three runs, 2026-09-01:",
"",
" publisher declared 255 units = 4.250 s 4.28 / 4.26 / 4.27 mean 4.270 s",
" developer declared 210 units = 3.500 s 3.50 / 3.57 / 3.51 mean 3.527 s",
"",
"Residuals +1.2 and +1.6 units -- frame granularity on the exit check, not a",
"hold. The claimed 4.400 and 3.650 are each ~0.13 s longer than what has been",
"shipping since P3. Against the corpus (4.42 and 3.46 means) neither the claimed",
"nor the measured figure dominates: the port is 3.4 % short on the publisher and",
"2.0 % long on the developer, the claim would be 0.5 % short and 5.5 % long. So",
"this corrects a false statement about our own behaviour; it does not settle",
"whether a hold belongs there. That is still black_hold_why's ordered-pair ask.",
"",
"🔴 AND THE UNIT STAYS UNITS, NOT SECONDS. The same two dwells timed in the",
"Decoder's own container came out 15-20 % LONGER than both the declared values",
"and the corpus -- same disc, same timeline -- and three independent readings",
"of that container's rate disagree with each other. A seconds figure records",
"one emulator's pacing on one run. The units are on the disc. If anything ever",
"goes in `dwell` it is an extra hold in UNITS, and only for a screen that is",
"measured to wait beyond its group.",
"",
"🔴 2026-09-01 (later) — 'So the pacing was right all along and nothing changes in",
"the code' IS CONDITIONAL, AND MAY BE A COINCIDENCE OF TWO CANCELLING ERRORS.",
"",
"That sentence rests on the port's total screen time matching the corpus dwells.",
"It does: 4.270 s against 4.30/4.60/4.37 and 3.527 s against 3.51/3.50/3.37.",
"",
"But a TOTAL cannot see two errors of opposite sign inside it. Measured:",
"",
" the port's screen time IS its animation time. publisher 4.270 s against a",
" 4.250 s animation -- a hold of +0.020 s, i.e. none. The port does not hold",
" after a splash timeline at all.",
"",
" the GAME does: the Decoder counts the publisher on screen for 219 presents and",
" animating for ~128 of them, about 42 % hold.",
"",
"So IF keyframe_units_per_second is 120 rather than 60, this port animates every",
"splash 2x too slow AND omits the hold entirely, and the two sum to almost exactly",
"the right total. The agreement above would then be evidence of nothing.",
"",
"⚠️ THE HOLD AND THE CONSTANT ARE COUPLED. At 60 the port must NOT gain a hold --",
"the animation already fills the screen time and a hold would overshoot by ~40 %.",
"The missing hold is a defect only if 120 is right. They stand or fall together,",
"which is another reason not to move on one capture.",
"",
"📌 And when it does move it is TWO changes, not one: the constant, and a hold",
"measured as (screen presents - animation presents). It must NOT be inferred from",
"the total, because the total is precisely the quantity that cannot distinguish",
"the two errors. docs/port/units-per-second-switch-readiness.md.",
"",
"✅ 2026-09-01 (later still) — THE PARAGRAPH ABOVE IS WITHDRAWN. 'The pacing was",
"right all along' WAS right all along.",
"",
"I claimed the dwell agreement might be a coincidence of two cancelling errors --",
"a 2x-slow animation plus a missing hold. There is no missing hold. I misread a",
"presents split from the Decoder's instrument ('219 on screen, ~128 animating')",
"as a hold OUTSIDE the declared timeline. It is a split WITHIN it: the publisher",
"ramps 0-30, HOLDS 30-235 (205 units, 80.4 % of the screen) and fades 235-255,",
"and this port plays all three.",
"",
"Measured rather than read -- frozen samples of the logo region across the",
"publisher splash: 0.405488 at t=60, 120, 180 and 228 units, identical to six",
"decimals across 168 units, with 0.391 at t=15 (mid-ramp) and 0.038 at t=252",
"(in the exit fade). The hold is there and it is played.",
"",
"⚠️ The failure was not a mis-measurement. I took a two-part split from someone",
"else's instrument and assumed its boundary sat where my own model put it.",
"Presents are not units, and 'animating vs holding' in presents does not",
"decompose the same way as 'ramp vs hold' in declared units.",
"",
"AND THE DWELL FIGURES HERE ARE NOW POSITIVE EVIDENCE, not merely survivors. A",
"time-based clock is immune to dropped frames, so a dwell measured in seconds is",
"stable across runs at different frame rates. This port's own splash dwell across",
"a 4.0x change in its rendering rate: 4.28 s at 17.3 fps, 4.26 at 19.6, 4.27 at",
"25.0, 4.26 at 69.4 -- a 0.5 % spread, putting 255 units at 59.6-59.9 units/s",
"every time. That establishes these dwells are frame-rate-independent",
"MEASUREMENTS rather than artefacts of whatever rate a run hit, which is the",
"property the Decoder's argument needs of them.",
"",
"✅ 2026-09-02 — THE +1.2 / +1.6 UNIT RESIDUAL WAS FRAME GRANULARITY, and that is",
"now measured rather than inferred.",
"",
"The dwells were recorded as 4.270 s and 3.527 s against declared 4.250 and 3.500",
"-- residuals of +1.2 and +1.6 units -- and I attributed them to the granularity",
"of the exit check without testing it. A hardware GPU makes that testable: same",
"boot, same declared groups, three runs at 65-66 fps instead of 17-25.",
"",
"Pre-registered: if the residual is frame granularity it should shrink roughly",
"with the frame rate, so <= 0.5 units at 65 fps. Measured:",
"",
" publisher 4.27 / 4.26 / 4.27 mean 4.253 s residual +0.20 units",
" developer 3.50 / 3.52 / 3.50 mean 3.500 s residual +0.00 units",
"",
"From +1.2 and +1.6 down to +0.20 and +0.00. The prediction held and the",
"attribution is no longer an assumption. ⚠️ It also means the figures quoted",
"elsewhere in this corpus as 4.270 / 3.527 carry a rendering-rate term; the",
"declared values are what the port actually targets and 4.250 / 3.500 is what it",
"hits when the renderer keeps up."
],
"dwell_kind": "measured",
"looping_focus_records": {
"_": [
"WHICH focus records the port draws, unconditionally and on a loop, OVER the",
"element's own sprite rather than instead of it.",
"",
"RESTORED 2026-08-30 on a MEASUREMENT, having been deleted on 2026-08-29 for",
"a real defect that was in the RENDERER, not in this table. The old entry made",
"`_draw` substitute the glow for the plate's own bright sprite, so the plate",
"was invisible at every instant (max 0 against max 252.5). `ScreenView` now",
"draws the base and the record over it, and the entry comes back."
],
"press_start/ptbtn00": {
"record_element": "ptbtn00f",
"period_units": 120,
"kind": "measured",
"source": "docs/re/structures/plate-pulse-measured.md, RE agent 2026-08-30",
"why": [
"MEASURED off the running game, held at the title with NO INPUT: the plate",
"oscillates continuously -- two windows in one boot of 58 s and 57 s, about",
"23 cycles each, with no decay and no settling.",
"",
"🔴 IT NEVER GOES OFF. The plate-absent floor is 159 thresholded green",
"pixels -- the title art's own, measured on live-title-build4-no-plate.png --",
"and the pulse bottoms at 714, four and a half times that. So `ptbtn00`",
"going transparent at t=244 is not the end of the plate; that is its EXIT",
"ramp, which plays when the screen leaves. While the screen is held the base",
"sits at its own hold (alpha 255 at t=238) and `ptbtn00f`'s cycle runs over",
"it. Base-only and base-plus-glow are what the 714 and the 1520 are.",
"",
"⚠️ 120 UNITS, NOT SECONDS, and that is the RE agent's own instruction. Their",
"run measured 2.530 and 2.540 s; an earlier corpus run measured 2.24 s. Same",
"declared number, different emulator pacing -- x1.27 and x1.12 against a",
"nominal 2.000 s, which IS 120 units at 60 units/s. Hardcoding 2.5 s would",
"author one loaded container's clock."
],
"limits": [
"ONE BOOT. Two windows inside it are not two boots.",
"It does NOT distinguish the boot title from an attract-loop title: run 1",
"opens at t~255 s against Q9's ~193 s no-input baseline, so it may already",
"be the attract title. Both are 'the title, held, no input' -- which is what",
"was asked -- but it is not proof about the first appearance.",
"🔴 714/1520 IS NOT AN ALPHA RATIO. The counter is thresholded pixels, so dim",
"pixels drop out first. No duty cycle and no ramp shape may be read off it;",
"the port draws the record's own declared alpha ramp and infers nothing."
]
}
},
"exit_ramp_deleted_why": [
"DELETED 2026-08-29, and the deletion is the point.",
"",
"`exit_ramp_seconds` (~0.4 s) and `exit_ramp_units` (24) were AUTHORED because",
"the disc had no time slot on a group's final keyframe, so the ramp into it was",
"the one unknown duration per screen. Under the corrected record layout",
"(formats-pin-2026-08-29c onward) there IS no untimed keyframe -- a group is an",
"8-byte header then frames x {u32 time; 36-byte pose}, so every pose is timed",
"including the last. The unknown the constant stood in for does not exist.",
"",
"MISSION section 3: 'When the RE agent later decodes something you had",
"authored, delete the authored entry and let the exporter emit it. That",
"deletion is the measure of progress.'",
"",
"VERIFIED DEAD BEFORE DELETING, not assumed: setting it to 9999 (166 seconds)",
"changed the boot's transitions by 0.04 s -- wall-clock jitter, not a 166 s",
"ramp. Both of its uses in ScreenView were gated on `not last_frame.has('t')`,",
"which no longer fires on any of the export's 866 keyframes.",
"",
"The measurement it recorded is not lost: HANDOFF Q7's ~0.4 s fade-out and the",
"0.17-0.23 s black hold are still measured facts, and the hold is still used --",
"`tools/port/verify-dwell` compares a transition INTERVAL against the oracle's",
"visible SPAN plus that hold. What is deleted is the port's need to invent a",
"duration the disc now states."
],
"black_hold_units": 0,
"black_hold_why": [
"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.",
"",
"UPDATE: TWO candidate models are now excluded, not one. The Decoder has five",
"replicates with NO variation -- title->menu 3,3,3 and EXTRAS->menu 2,2 -- and",
"every differing value comes from a different ORDERED PAIR. The same origin",
"gives different values to different destinations (menu 0 vs 1, EXTRAS 2 vs 3).",
"So a constant is excluded AND keying on the outgoing screen is excluded; only",
"an ordered-pair key survives, with a measured value needed per pair.",
"",
"I checked independently whether anything DECLARED predicts it, from the",
"quantities in my export. None does: outgoing close (15,10,10,10), incoming",
"clear (12,12,16,12), outgoing span (269,74,80,80) and incoming span",
"(80,80,269,74) each have two rows sharing a value with different gaps.",
"",
"I did NOT search combinations of them. Four intra-archive pairs against many",
"candidate two-screen functions fits by construction -- that is the error this",
"corpus has catalogued five times, and finding a formula here would be",
"indistinguishable from finding one in noise.",
"",
"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.",
"",
"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.",
"",
"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.",
"",
"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.",
"",
"📌 CITATION ADDED 2026-09-01, and its absence propagated from the delivery.",
"This why carried over a thousand characters and NOTHING OPENABLE. The Decoder",
"sent the `(B)`-from-EXTRAS leg as an inline frame table with no file cited,",
"while docs/re/data/fade-four-transitions.txt -- which carries that leg and",
"eight others -- had been committed the whole time. They found it in their own",
"audit and cited it; it had already landed here uncited.",
"",
"⚠️ An uncited measurement propagates as an uncited value. The receiving end",
"cannot tell a summarised measurement from a recalled one, and both read as",
"prose.",
"",
"✅ AUDITED 2026-09-01 and this one needed nothing: it was already an EXCLUSION argument rather than a count. It excludes a constant, excludes keying on the outgoing screen, and excludes every declared quantity in the export as a predictor -- four of them named, each shown not to separate the pairs. That is the form the week's other claims were found to be missing."
],
"black_hold_kind": "measured"
}