dd1da9b698230bdd9f4046492ebccbbcd3e152d2
29 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Sylpheed port agent
|
ac1371cda3 |
port: F6 FOUND -- the gate was declared data the renderer was discarding
The sweep starts early because ScreenView drew a leaf WITHOUT multiplying its
parent's alpha in. ptloop01/ptloop02 declare 0:0 70:0 100:255 238:255 250:0, so
the sweep is invisible until t=70 and full at t=100. The port has had that ramp
in its export the whole time and was throwing it away at the draw call.
Three changes:
1. Parent alpha multiplies into the leaf's. This file asserted the opposite,
arguing from the sweeps being drawn while their parent had expired -- but that
could not separate 'the leaf wins' from 'the parent is ignored because it
draws nothing', and its own comment said so and named the interval that would
settle it. Measured there: dividing the leaf's declared curve out of the drawn
alpha pins the implied parent at 255.0 (+/-1.5) over hundreds of frames while
the drawn alpha swings 242 -> 132 -> 145.
2. rate 0.5, calibrated against a DECLARED interval (ptloop01's own 30-unit ramp)
rather than captured frames: two runs differing 2x in frames give 0.4795 and
0.4667, 2.7% apart. This number was 0.514, withdrawn, now reinstated at 0.5 --
what failed the first time was quoting a rate in presents, and the ratio was
discarded along with the frames.
3. The 107-unit authored offset is DELETED, with its guard tool. It came from a
ratio measured against an element identified only by screen position; the
declared ramp needs no such identification. Deleting an authored value because
the data already says it is the outcome PORT-MISSION asks for.
Also reverted, same day I made it: removing the transparent-parent skip. I read
'the game submits the sweep ~950 frames past its parent's expiry' as the leaf
outliving the parent. It does not follow -- a draw submitted at alpha 0 is still
a draw, and submitted is not visible. With the multiply, skipping on a
transparent parent IS multiplying by zero.
VERIFIED, pre-registered before running, via --probe-leaf:
u= 60 -> no draw at all (predicted: parent alpha 0.00, gated off)
u=100 -> leaf_t 50.0, x -439 (predicted 50.0, -439)
u=236 -> leaf_t 118.0, x -167 (predicted 118.0, -167)
verify-capture: every row unchanged.
⚠️ BUILD-SENSITIVE: builds 5 and 6 of GP_TITLE declare these records as a single
flat a=255 with no ramp. This export reads the ramped build; if that changes the
gate disappears silently.
|
||
|
Sylpheed port agent
|
af10a2ec3c |
port: F6 -- adopt the sweep onset as a measured RATIO, and fix the guard that disabled it
Onset: 0.500 of (title first visible element -> plate onset), measured by the
Decoder as 0.489 and 0.507 across two independent captures, 3.7% apart. A RATIO,
which is the point -- it needs no clock, and every unit-valued figure from those
captures has been withdrawn: the rate because frames are presents (1168 vs 600
for the same animation), the '+40 units' because its conversion put
title-start->plate at 75 units where the declared data puts the plate at 238, a
3.2x conflict that is still open and is F4's.
Resolved against THIS export: 0.500 x (214 - 0) = 107.0 units.
tools/port/check-leaf-onset recomputes it and fails if a re-timing moves the
anchors; it has a selftest in both directions and is in check-all.
🔴 AND THE ADOPTION WAS A NO-OP UNTIL THIS COMMIT. leaf_clock() read
'if start < 0.0 OR rate <= 0.0: return screen_units', so when the withdrawn rate
went back to null the adopted OFFSET stopped applying too -- silently, while
authored/rendering.json still stated it. The two fields are independent now.
It was caught only because the offset was re-verified by PROBING THE RENDERER
instead of re-reading the file I had just edited. Both my earlier verifications
of this feature passed while it did nothing: one compared frames that were all
being forced to the same pose, the other ran when both fields happened to be set.
Verified, pre-registered before running, via --probe-leaf:
title u=236 -> leaf_t 129.0, x -123 (predicted 129, -123)
title u=400 -> leaf_t 293.0, x 533 (predicted 293, 533)
Effect: at the plate's arrival the sweep sits at x=-123, just entering the frame,
where before it was at x=305, well across it.
|
||
|
Sylpheed port agent
|
d7e4a7167e |
port: F6 -- adopt the measured leaf clock, and stop a parent killing its leaf
Two changes, both measured, neither invented.
1. LEAF CLOCK. authored/rendering.json leaf_clock.title = {start_units 40,
rate 0.514}, from the Decoder's f6-unit8, both numbers off ONE capture. The
title's own rate is measured rather than assumed there (ptcopyright ramps
0->255 over 22 declared units across 22 frames = 1.000 units/frame), which was
the assumption their unit 4 had flagged. Supersedes their earlier 0.463, which
divided by the end of MOTION -- the declared track is stationary from t=540 to
600, so that denominator was short; 0.514 anchors on the loop wrap.
Corroborated independently: the human reported the port looks FASTER than the
game, offered as an impression. 1.0x against 0.514x is exactly twice too fast.
2. A LEAF OUTLIVES ITS PARENT. _draw skipped any element whose PARENT posed
transparent, before _draw_leaf was reached, so ptloop01 expiring at t=250 took
the sweep with it -- while this file's own decode says the leaf runs on its own
timeline and the parent's alpha is not multiplied in. The two were inconsistent
and the silent gate won. The capture settles it: the game submits the sweep
across frames 746..1913 while the parent expires at 956, so it keeps drawing
~950 frames after the parent is gone.
VERIFIED by probing the running renderer at two PRE-REGISTERED instants:
title u=400 -> leaf t=185.0, pteff03 centre 301 (predicted 301),
pteff03a centre 1169 (predicted 1168)
title u=800 -> leaf t=390.6, pteff03 centre 1124 (predicted 1124),
pteff03a centre 333 (predicted 332)
All within 1 px.
Effect at the plate's arrival (title t=236): the sweep's centre moves from 505 --
halfway across the screen -- to -36, just entering at the left edge. The human's
report is that the game's glow begins when the plate appears.
|
||
|
Sylpheed port agent
|
4d533185e7 |
port: leaf clock mechanism -- origin and rate, both UNSET
F6 is a clock question, not an effect question: the human confirms the light animation itself looks like the game's and only starts earlier, and separately that the port may be running it faster (flagged by them as an impression). The port passed time_units straight to the leaf, which is an assumption -- offset 0, rate 1 -- that nobody measured and that the Decoder's capture contradicts: the game's leaf t=0 is its first drawn frame, 40 frames after the title's first element, at a rate measuring well below the title's. ScreenView.leaf_clock(screen_units) applies an origin and a rate; both default to -1.0 meaning unmeasured, in which case it is the identity and behaviour is unchanged. Fed from authored/rendering.json leaf_clock per screen, currently null with the provenance recorded. No placeholder values, per F1: an invented constant here is indistinguishable from a measured one later. Verified inert: title rendered at t=2/3/4 s, 0 differing pixels against captures taken before the change. Also corrected in the process: my earlier 'the sweep enters the viewport at t=61' used the UNROTATED sprite width. The leaf carries a 30 deg rest rotation, so its AABB is 886 px against a 399 px sprite -- matching the Decoder's measured ~890 to within 4 px. Port and game both put the quad on screen at leaf t~0, so the whole discrepancy is the leaf clock's origin and rate. |
||
|
Sylpheed port agent
|
08ed3dd17e |
port: the splash never animated -- pose_at ASSIGNED the settle instant instead of clamping to it
The 2026-09-02 play-test: "the logos just switch, I cannot discern any animation
at all." Reproduced, diagnosed, fixed, and gated by a film.
REPRODUCED FIRST, as instructed. tools/motion-census needed Pillow, which this
container has no pip for, so it got an ImageMagick fallback that shims only the
four Pillow calls it uses -- the census arithmetic, the MOVED floor and the GRID
are untouched. Its --selftest passes on that backend with the human's own
numbers: fade 97.4 %, switch 2.6 %, frozen 0.0 %. A shim that distorted pixels
would fail its own control.
publisher 0.30 s moving then 3.30 s FROZEN (human: 0.30 then 3.20)
developer 0.40 + 0.25 split then 2.45 FROZEN (human: 0.35 + 0.25 then 2.40)
Matched to within a frame.
THE CLOCK WAS NEVER THE PROBLEM. view_units advances 2.8-3.0 per frame, smooth,
~60 units/s, no stalls -- the play-test's candidate list can drop "the group
clock not integrating" and "advancing by keyframe index".
THE POSE WAS. Measuring the sharp logo's own rect frame by frame: 0.40549 flat
from unit 7.9 through 28.2 -- the same value it holds at 45 and beyond. It was
already FULL before its declared ramp (15 -> 30) began.
Cause, in ScreenView.pose_at:
t = settle_instant if settle_instant >= 0.0 else minf(t, settle_units(element))
The comment above it says "stop at the hold". The else-branch clamps. This half
ASSIGNS, so from a screen's first frame every element was posed at the settled
instant and no build-in was ever drawn. The asymmetry is the whole defect, and
`--time` sets `frozen`, which skips the clamp -- which is exactly why my frozen
sweep "proved" the companions were drawn and proved nothing about running.
Fix: `minf(t, settle_instant)`. One operator.
⚠️ AND THE HOLD IS NOT THE BUG. The Decoder measured the game holding one picture
for 3.34 s on this screen -- LONGER than the port's 3.30 -- because palogo_sqex
declares 205 of its 255 units as a flat plateau. The play-test's "a fade does not
hold one picture for 3.20 s" would have sent me to delete the one correct part.
Clamping keeps the plateau exactly.
GATED BY A FILM, not a still:
before after game (Decoder)
publisher build-in 0.30 s 0.60 s
developer build-in 0.40+0.25 0.95 s continuous
splash moving 12.0 % 24.8 % 21.2 % / 27.8 %
distinct luma states 120 152
longest frozen 3.30 s 3.30 s 3.34 s
🔴 AND IT LOOKED LIKE A 10x REGRESSION AGAINST THE ORACLE, WHICH IT WAS NOT.
verify-capture went publisher 2.17 -> 22.58, title 14.11 -> 67.07. Cause: it
shoots two frames after load and got the settled pose ONLY because pose_at
assigned it. Its own comment says so -- "the 0.01 % agreements on both splashes
were measured through that accident."
So the `--screen --capture` path now advances the clock to the settle instant
explicitly before shooting, which is what the tool was always asking for. Guarded
on `not _frozen`: `--time` means the caller wants THAT instant, and overriding it
would reintroduce the silent-ignore this replaces.
Every oracle row is back to its pre-fix value to the digit: publisher 2.17
(0.01 %), developer 3.05 (0.01 %), title 14.11, main_menu 13.02, extras 13.10,
title_plate 13.04. The port animates AND still matches the settled captures.
Not settled: motion-census is not yet wired into check-all -- next, and
deliberately not rushed at the end of a long iteration.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AHUQvXGyNcKonSEWsgWcX
|
||
|
Sylpheed port agent
|
70799488fe |
port: delete the authored blend map for the decoded field, and find a counter-example doing it
PORT-MISSION §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." This is that deletion. authored/rendering.json's `additive_elements` -- a per-screen list transcribed from the Decoder's per-draw RB_BLENDCONTROL0 log -- is gone. The exporter emits `blend_additive` per element and per nested focus/leaf element from `T8aD +0x04` bit 0x02, and ScreenView reads it there. Both accessor spellings are needed: `ptbtn00f.t32` is in build.sprites while no element carries it as `sprite`, and it is the sharp case -- the plate alpha-over, its own glow additive, adjacent draws on one screen. CHECKED BEFORE THE SWAP, and the map turned out to be a SUBSET, not the answer: 15 elements it called additive the disc agrees with, ZERO contradictions, and 17 MORE the disc marks that it did not. Those include the sweep LEAVES (draw_leaf_for means pteff03/pteff03a are what reach the screen while the map listed their parents) and TWELVE on `title`, where the map was deliberately empty -- so the port has been drawing every title effect with the wrong blend. H6 closes with no capture at all: the JP asymmetry was an artefact of a NAME-KEYED map, and the bit is on the disc for every screen at once. 🔴 AND IT INTRODUCED A REGRESSION, WHICH IS REPORTED, NOT HIDDEN. Against the oracle captures on the GPU: main_menu 10.88 -> 13.02, main_menu_options 11.56 -> 13.57. Deterministic to the digit over three runs, so not sampling noise. Isolated to ONE element, with a control: - main_menu's only newly-additive top-level element is pteff10; - extras gained none and did not move -- the same change on a screen with nothing new moves nothing; - the leaf rule was disabled separately and main_menu stayed at 13.02, so pteff03/pteff03a are NOT the cause. That prediction of mine failed; the rule is restored, being provably neutral here; - title did not move despite twelve newly-additive elements, consistent with verify-capture posing at settle t=198 where those quads are transparent. That is a potential COUNTER-EXAMPLE to a ✅ DECODED claim, and it is a sharp question rather than a guess: their own map lists pteff10 additive on `extras` and not on `main_menu`, and they logged BOTH screens. Asked in BLOCKED.md H6. Shipped anyway, for reasons stated rather than assumed: +2.14 is inside the harness's own ±3.78 capture-phase term for that screen and cannot adjudicate a disc fact; the decoded source is far better evidenced (35 elements, zero errors, out-of-sample prediction 3 of 16); and fitting an exception for one element would put an authored entry back to make one number smaller, which is the move this project keeps having to undo. It is a KNOWN regression, not an unnoticed one. Also settled this iteration, for the Decoder's open question: the port FADES the plate, it does not pop it. Frozen sweep of the plate region -- 210u 0.1457, 216u 0.1573, 222u 0.1727, 228u 0.1900, 236u 0.2142 -- a clean monotone ramp across the declared 214->236. So t=236 is the port's COMPLETION, not its onset, and the 0.367 s "late plus a pop" reading does not apply. Not settled: whether pteff10 has a counter-example; H1's repeat half; the four red verify-screen rows; and finding 3, which still has no cause now that units/s is settled at 60. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018AHUQvXGyNcKonSEWsgWcX |
||
|
Sylpheed port agent
|
d45b23ebbe |
port: draw the plate's highlight additive, and find my harness poses it where it cannot be seen
blend-bit-vs-oracle.txt entry 2: ptbtn00 alpha-over, ptbtn00f ADDITIVE -- the PRESS (A) plate and its own highlight, one bit apart. Entry 4, the whole title, is alpha-over throughout including ptlogo_back2/ptlogo_back2eff, which independently kills the "frame-shaped and mostly transparent means additive" rule I declined to adopt. Bands are now per DRAW OP rather than per paint-order entry: one band per element cannot express base alpha-over with its own focus record additive. The change reported zero three times and each zero had a different cause. First, additive_elements was assigned to `view` in three places and to `overlay` in none, and the plate is an overlay -- every other decoded rule on that page goes to both. Second, I then measured that the element is never drawn, suppressing its sprite at six times across the cycle for 0 px every time, and was one commit from filing "the port never draws the plate highlight" as a defect. That sweep was invalid: I varied --time while passing --loop-phase=0 in every run, and --loop-phase pins exactly the clock a looping record runs on. Six samples of one phase. Third, swept properly, ptbtn00f contributes 0 px at phase 0 and 22-29k px at phases 20-100 -- and verify-capture's title_plate row poses at loop-phase 0. The row that validates the plate is blind to the plate's pulse by construction. It correctly reports 13.03 / 0.09 % unchanged while the fix moves 26 319 px at phase 20. Stated in the tool next to the pose. Not verified against the oracle: every title-plate capture we hold is at the blind phase, so no capture here can confirm the port now draws it right. Asked. |
||
|
Sylpheed port agent
|
49a6333166 |
port: free the canvas items I leaked, and refute the blend measurement's reach sentence
The RenderingServer rewrite leaked 5 CanvasItem RIDs per run -- exactly the number of paint-order runs on the main menu. Items created through the server are not owned by the node; a child Node2D would have been collected for me, and the reason for not using one is the reason this had to be paid for. Freed in _exit_tree. Nothing failed. verify-capture was green on every screen and the pictures were right; the leak line sat next to "N ObjectDB instances were leaked at exit", which BLOCKED.md records as engine-side and not ours after releasing every reference the port owns moved the count not at all. A new leak line beside a known-benign one is close to perfect camouflage. What distinguished it was the number: 5 is a count of my bands. Refutation, and it lands. ui-blend-mode-measured.md closes "every element on the two screens the port ships is in the table except the two above and pteff10". Checked against my export, counting the summary table's prose rows as coverage: exactly right for main_menu, and on EXTRAS it misses four -- ptframe4, pteff21, pteff22, pteff23. Five, not one. They are not an arbitrary four. They are precisely the elements the port now measures as the worst on that screen, ptframe4 at 16.19x the frame mean. Every measured row still stands and the port has transcribed all of them; what is wrong is the reach, and it is the difference between "one loose end" and the open ask in BLOCKED.md, which now says so. Secondary, offered as such: "every button" in the summary row is a class generalisation in a document that warns its reader to take the table as per-element facts. No button appears in the EXTRAS draw log at all. Very likely right, nothing of mine depends on it. |
||
|
Sylpheed port agent
|
c453d8dade |
port: draw the measured additive blend -- main_menu 13.21 -> 10.67
The Decoder logged RB_BLENDCONTROL0 per draw in Canary on both screens. 0x01010101 is src=ONE dst=ONE, additive. That makes the blend a transcription rather than my proposal, and they withdrew the "any blend you choose is authored" instruction explicitly. Their control is what licenses the change: one pixel shader, 0xE59B2B3DA4AA9008, runs with BOTH blend states on the main menu -- 12 additive draws and 18 alpha-over. The frames and ptbase share a shader; only the blend register differs. authored/rendering.json gains additive_elements per screen. Every id is a measured draw and the reach is written beside it. verify-capture: main_menu 13.21 -> 10.67 (0.06 % -> 0.02 %), extras 13.38 -> 11.43, main menu with ptbtn04 focused 13.82 -> 11.36. Per element, ptframe1 22.72 -> 4.17 and ptframe2 13.09 -> 3.32. Neutrality control, free with the table: publisher_logo 2.17 and developer_logos 3.05 are unchanged to the digit. Those are the screens whose metric is absolute and they carry no additive element, so the rewrite that routed every draw through RenderingServer canvas items did not change the picture. The improvement is the blend, not the plumbing. RenderingServer rather than child Node2Ds because boot.gd calls view.queue_redraw() from nine places and none reaches a child node -- bands would paint the previous pose, which under --script=wait is a plausible wrong capture rather than an error. Runs are recomputed per frame: the additive elements are consecutive on both measured screens, and that is an accident of those two screens. And the change first ran with the material left at its default MIX, moving ptframe1 from 22.72 to 22.69. Nothing errored and a 0.03 move is a plausible negative result. It was caught only because the measurement predicted a large move. Not done: ptframe4 is now the worst element on EXTRAS at 16.19x the frame mean and additive would plainly help it. It is not in the measured table, so it is not in the file. Filed in BLOCKED.md with pteff21/22/23, which are also in no captured draw. Refuted, mine: "neither frame has a fully-opaque pixel" was true and was not the discriminator -- pteff10 has max alpha 130, no opaque pixel, and measures nearly exact. The direction survived; the reason for it did not. |
||
|
Sylpheed port agent
|
6a8b80faaa |
port: the contract I read is 3185 lines shorter than the contract
docs/port/HANDOFF.md on main is 926 lines, last touched |
||
|
Sylpheed port agent
|
66f0adce02 |
port: sweep instructions above descriptions -- the silent class is clean, two loud hits
Their sharpening: a stale instruction manufactures a false confirmation, strictly worse than a stale description that merely misleads. Applied to my instruction surface, the documented invocations in tool and script headers. All fifteen distinct flags across those examples are parsed, so nothing in my headers can produce their failure mode by being inert. But 'parsed' is a proxy and its gap is known -- --shots parses and does nothing on the --boot path -- so I ran two documented examples end to end rather than trusting the grep, and both produce a 1280x720 frame. Two hits, both loud rather than silent: 11 references to tools/verify-capture and tools/verify-screen, paths that do not exist since the tools are under tools/port/ (fixed in 4 files); and check-all claiming eleven tools where there are fourteen (now states both so the sentence dates itself). The distinction worth recording: mine fail loudly, theirs failed silently. A wrong path announces itself; an inert environment variable returns a clean wrong result. Both are stale instructions and only one manufactures evidence. Honest limit: I tested the flag surface plus two examples end to end, not all thirteen documented invocations -- the --boot ones take 156 s each. That is a judgement about cost, not a claim of coverage. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF |
||
|
Sylpheed port agent
|
dbd75bcc56 |
port: sweep for their tell -- two descriptions my own code had already refuted
Their sweep cleared my three quoted figures: the splash dwell spans were corrected today, and the gap and cold-boot intervals are capture-derived, which the record-layout fix cannot reach. Their sharpening -- the tell is not that a number changed but that a page hedges a quantity it should not need to -- made a sweep of my side possible. The marker is 'untimed', since there are 0 untimed keyframes in 866. Two hits, both worse than hedges: descriptions their own code had already refuted. Hit A: spin_period_units' doc stated the rule as 'the first timed and the second untimed', the pre-fix version, while the body directly below carries a block explaining that this rule silently stopped the ring and implements the span-based replacement. A function and its documentation disagreeing, with the documentation stating the refuted version. Hit B: exit_ramp_units' doc claimed the value is authored in timing.json and that the disc has no time slot on that keyframe. Both false -- the entry was deleted as progress and the corrected layout times every pose. And I wrote the correction myself, immediately below it, two iterations ago without looking up. Both are fixed code under an unfixed description, with the fix and the falsehood within twenty lines of each other -- not drift, but editing at the point of failure without re-reading the frame around it. Their practice of quoting the original sentence is adopted so the change is visible. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF |
||
|
Sylpheed port agent
|
cf8f001956 |
port: the oracle harness was nondeterministic and I quoted it for a dozen iterations
verify-capture's main_menu row reads 13.30 / 13.27 / 13.25 / 13.26 across runs this session while every other row is identical to the digit. I cited those numbers repeatedly, including in the rest() adjudication. Cause: the focus ring spins on time_units raw rather than the pose clamped by holding -- deliberate and correct, since the ring is the one thing on a settled screen that keeps moving -- so its angle at capture is set by the wall clock. extras is stable because nothing there spins. --loop-phase already existed and did not cover it: it pins the looping focus record phase, while the spin is a second free-running clock I guarded once and never connected. Extended loop_phase_units to pin the spin too, and verify-capture now passes --loop-phase=0 at all four render sites. The control matters because the drift was intermittent -- three unpinned runs gave 13.25, 13.26, 13.26, so three pinned runs agreeing would prove nothing. Phases 0/30/60/90 give 13.2583 / 13.1991 / 13.2637 / 13.2588: the pin is live and the 0.065 spread is the whole of the observed drift. Non-finding recorded so nobody mines it: phase 30 scoring lowest is not evidence about the ring's real phase -- 0.065 against a ~13.2 gamma floor is 200x too small. A margin only means something against the noise it sits on. No conclusion changes: the smallest margin any of them turned on was 0.14% differing area. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF |
||
|
Sylpheed port agent
|
0be8348a6f |
port: the refuted 24-unit constant was living in a default; make it loud instead
ScreenView.exit_ramp_units defaulted to 24.0 -- the constant HANDOFF ask 2 told this port to author and that it refused, since the file's own ramp is 10 units. The authored entry was deleted as progress when the corrected record layout removed the unknown, and the default plus boot.gd's timing.get(..., 24.0) made that deletion a no-op. Both use sites are unreachable on today's export (866 keyframes, 0 untimed), so the branch is kept for an older export but no longer invents: the default is -1.0 meaning not supplied, and an untimed group now raises an error naming the screen rather than fabricating a duration. My first verification accused the change: main_menu 641941 px and extras 226009 px changed, on a branch that cannot execute and with no error raised. The cause was --screen=X --capture= firing at an uncontrolled instant -- t=9.00 in the earlier run against t=8.00 in the later one, one unit apart mid-build-in. Three runs now are byte-identical, so it is not noise; the instant is stable within a session and moves between them. Re-run with --time=1.0 pinned, old against new is byte-identical on all four screens. Records the harness limitation: --screen=X --capture= cannot be used for before/after comparison on an unsettled screen, which also explains the earlier settle-vs-rest confound. Also corrects my overstatement that other tools call the CLI -- verify-screen is the only one, checked. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF |
||
|
Sylpheed port agent
|
955f5b0c02 |
port: the rest() flash defect reaches all four splashes I ship; the port survives it
The Decoder censused rest()'s dwell fallback from the file side: 2305 elements have no plateau, 1697 of those get a visible pose, and in GP_TITLE all four visible fires are on the splash screens this port ships. Confirmed in my export. Refinement to their description: they named the [0:a0 15:a255 30:a212 45:a0] shape, but palogo_gamearts_eff and palogo_seta_eff hold 255 through t=30, so their fallback lands on the flash PEAK rather than its decay. Same defect, worse pose. The port ships the right frame and there is now a number for it. Publisher splash against the committed oracle capture: timeline (shipped) RMSE 2.17 / 0.01% differing; --pose=rest 9.05 / 0.75% -- 75x the differing area on a screen I ship. So the rule added to verify-screen's header after the title_jp mistake generalises, and is demonstrated against an oracle rather than argued. What did need fixing: ScreenView logged '(transparent at rest)' for every skipped element whatever instant it posed, so it said that about palogo_sqex_eff, whose resting alpha is 212. That is the same rest-versus-posed-instant confusion that cost a wrong conclusion, pre-printed in the log. It now names the instant. Controlled both ways: timeline says 'at t=6' and skips the flash, --pose=rest still says 'at rest' and draws it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF |
||
|
Sylpheed port agent
|
8ae0ec2287 |
port: verify-screen was nondeterministic; pin the pulse phase in the harness
Running the full set after the plate fix, press_start returned over3 5021, 8919, 5021 on three identical runs. The plate's looping focus record takes its phase from time_units, which free-runs, so the captured frame lands wherever the grab fell -- while the reference renderer cannot pulse at all. The port is not the thing that is wrong: the pulse is measured and a thing that pulses does not stop because the screen arrived. ScreenView.loop_phase_units pins it, negative means free-running and stays the default everywhere, and only the harness passes --loop-phase=0. Controlled: pinned, 3 runs identical; free-running, 3 of 4 identical and one different. That 3-of-4 is why it survived -- it looks deterministic most of the time, and without the negative control a no-op flag would have been indistinguishable from a fix. With the phase pinned press_start reads max 1 / over3 0 OK -- the recorded baseline exactly. Fifteen of sixteen rows now match. The sixteenth, title_jp, has genuinely drifted: 155/20498 -> 233/61208, deterministic, on the Godot side, localized to one 350x396 block at (405,74). There is no capture of the Japanese title, so I can say the renderers moved apart but not which moved. Recorded as an ask, not resolved. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF |
||
|
Sylpheed port agent
|
8adae30d1a |
port: the plate pulses -- restore the looping record, over the base rather than instead of it
Ask #1 measured: held at the title with no input the plate oscillates ~23 cycles per window with no decay and NEVER goes off -- floor 159 thresholded pixels, pulse bottoming at 714. A glow alone cannot do that (0 -> 80 -> 0); a steady base plus a pulsing glow can, and 714/1520 are base-only and base-plus-glow. The port already had the base right: ptbtn00's fade to 0 at t=244 is its EXIT ramp, and while held the base sits at alpha 255. The glow was missing. The defect was in the renderer, not the entry I deleted on 2026-08-29. _draw treated a looping record like a focused one -- drawn INSTEAD of the base, which is right for a focused button and wrong here. I deleted the right thing for the wrong reason. A looping record now draws OVER the base and the entry is restored. Rendered: 95.68 base only, 115.52 at peak, period 1.980 s against a declared 120 units = 2.000 s, ratio 0.990. Visible on the boot path; not under --screen --overlay, where a static overlay poses at its arrival by design. Authored in UNITS on their instruction, with their three limits verbatim: one boot, does not distinguish boot from attract title, and 714/1520 is not an alpha ratio so no duty cycle is inferred. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF |
||
|
Sylpheed port agent
|
96fe0eac51 |
port: add --leaf-time, and the title's residual is the sweep phase (~400 units, not 357.7)
The Decoder's refined sweep fit had never been testable: verify-capture passed it as a whole-screen --time that pose_at discarded, and asking for it honestly poses past the title's group end. --leaf-time separates the leaf's clock from the screen's. Controls: the renderer is deterministic (3 runs bit-identical) and the sweeps move 0.40% of the frame between phases, so the comparison can see them. Sweeping the full 600-unit span gives a sharp basin at 390-415 units (0.0124%) against 0.2532% at t=357.7 -- 20x. So the title's 0.21% residual is the sweep phase, not structure: at the fitted phase it matches the capture as well as the splashes do. NOT adopted: the port loops the leaf freely and re-posing the harness to the fitted value would be tuning until they match. Filed instead, with the question of whether 357.7 and this are even the same quantity. Also verified last iteration's settle-window change was surgical: only press_start and its twin moved, 14 screens unchanged including title's Decoder-confirmed [160,236]. Settle-window ties exist on 4 screens but all sit under the 30-unit bar, so the arbitrary tie-break never reaches the runtime. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF |
||
|
Sylpheed port agent
|
3c71962698 |
port: the PRESS (A) plate could not be drawn at any instant -- four faults, and a misquoted number
1. --time= was silently ignored on any screen with a settle window >= 30 units: pose_at overwrote the requested instant with settle_instant. ScreenView.frozen now marks an explicit instant and skips both clamps. 2. press_start's settle window was [0,214] -- the dead stretch BEFORE the plate exists -- so its settle instant was t=107, where the element is alpha 0. The exporter now rejects intervals in which nothing is visible. title keeps [160,236], the interval the Decoder's draw stream confirmed. 3. My authored looping_focus_records entry for press_start/ptbtn00 drew a dim focus record INSTEAD of the plate's own sprite: max 0 vs max 252.5. Deleted -- an authored guess that overrides a decode with a worse answer is removed. 4. verify-capture passed --time=5.9617 for the title and it was never applied. Every title figure it has printed, including the 0.26% quoted to the Decoder, was measured at the settle instant under a note claiming t=357.7. Both rows now pose by omission and the note matches. title is 0.21% honestly; splashes unchanged at 0.01%. The boot's end artifact now contains the plate (region mean 95.7 vs 33.6). Corrects last iteration's BLOCKED row, which had the entry's effect backwards. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF |
||
|
Sylpheed port agent
|
e9073750ac |
port: make ScreenView say what it could not draw; refute 'first-declared paints first'
skipped[] has been tracked and read by nobody since P1, under a comment saying a silently missing element looks like art. _note_structural prints from inside ScreenView rather than returning a value for a caller -- routing it through a caller is exactly what did not happen. Structural skips only; transparent-at- rest is ordinary animation. Zero found today: a guard, not a fix. The first version of that scan was a FALSE PASS: screen_view.gd did not parse (a line inserted at three tabs inside a four-tab block -- the substring assert matched a shallower indent), so grep counted zero from a dead script. The scan now counts the summary line as a positive control. Refutes 'the first-declared element paints first', which would have made the forced-backdrop rule redundant since all six forced elements are index 0. False on 8 of 16 screens -- decisively on main_menu, where index 0 is pteff00, painted LAST, and pteff00 is a measured control. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF |
||
|
Sylpheed port agent
|
39209eab05 |
port: the title's sweeps loop, the black hold is 9 units, and one claim refuted
THREE THINGS FROM THE DECODER, one of which I am not taking. REFUTED: "the developer splash is one composited quad, the bounding box of the three logos". The observed quad is 525x259 at (378,155). The three logos' bounding box is 500x421 at (390,164) -- a 259-tall quad CANNOT contain them, and palogo_anima alone starts at y=449, thirty-five pixels below that quad's bottom edge. The observed quad matches the union of gamearts_eff and seta_eff, 521x261 at (379,154), to about four pixels in every dimension -- and both of those are TRANSIENTS my own census flagged, dark by t=45, so a frame containing that quad is a build-in frame rather than the settled screen. I cannot see their draw stream, so I sent the arithmetic rather than a verdict, and the port keeps drawing three: I will not stop drawing an element on a claim whose stated identification excludes that element from its own bounding box. THE BLACK HOLD IS 9 UNITS, NOT 12. I authored 12 from Q7's luminance plateau of 0.17-0.23 s, supported by the menus' transition quad. The Decoder counted SUBMITTED QUADS instead -- luminance cannot separate the outgoing fade's tail from true black. Four frames with no sprite quad at all, at 2.284 units/frame derived from the disc as its own clock, gives 9.1 units = 0.152 s (6.9-11.4). That overlaps the luminance figure only at the top, and the true black is SHORTER still since both boundary frames carry picture. My 12 was supported by analogy -- a different screen's quad on a different path -- and a number that fits by analogy loses to one measured in place. verify-dwell's bound moved with it; both screens still agree. THE TITLE'S SWEEPS LOOP. The oracle shows the quad oscillating over its whole x range and resetting hard, one reset in the first title dwell and two in the second. The loop-length field could NOT have settled it, correcting a hope I had stated: both records declare exactly their last keyframe time, slack zero, and "loops at 600" and "runs once for 600 and stops" write the identical header. Verified on the two sweeps' LCM, since their periods differ: 600 and 720 realign at 3600 units, mean diff 0, against 0.438 at half that. Scoped to the title. The menus declare the same lengths but the oracle measurement is of the title, and my own weak evidence points the other way there -- best match with the sweeps off-screen, three times worse mid-screen, against a 73% on-screen duty cycle if they looped. Two weak signals in opposite directions is a reason to scope, not to pick. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF |
||
|
Sylpheed port agent
|
4226505222 |
port: pose a settled screen at ONE instant -- title 1.81% -> 0.26%, splashes to 0.01%
The Decoder's finding, applied. `rest()` returns each element's last hold keyframe chosen independently of every other element: right for anything that ends the screen settled, exactly wrong for a transient. The title's ptlogo_back2eff1 is a two-frame flash (0 until t52, 255 at t54-56, 0 by t58), so its last hold IS the flash peak and rest() left it burning -- five of them, drawn at once. The settled instant is the longest interval containing no keyframe time, over a bundle's TOP-LEVEL elements. Reproduced here before adopting: title [160, 236], midpoint 198, the Decoder's number to the unit. The top-level restriction is what makes it match -- including the ptloop leaves gives [269, 540]. AGAINST THE ORACLE: title 20.92 RMSE 1.81% -> 14.61 RMSE 0.26% publisher_logo 9.05 0.75% -> 2.17 0.01% developer_logos 8.86 0.33% -> 3.05 0.01% main_menu 0.08% -> 0.08% window too narrow extras 0.19% -> 0.19% window too narrow Seven times fewer differing pixels on the title, seventy-five times fewer on the publisher splash, whose differing region is now a 13x18 box. The largest correctness gain this port has had, and none of it is mine -- it is a decode computed from the keyframe table with no reference to any capture. APPLIED ONLY WHERE THE WINDOW IS WIDE, and the bar is not invented. This export's widths split with nothing in between: 214, 190, 145, 76, then 12, 12, 8, 4. The bar is 30 units -- the Decoder's disc-wide census puts the knee there (30% of bundles >= 30, 42% under 10, the latter mostly loop* fragments meant to be in motion) and this export's screens sit 4x either side with nothing between 12 and 46. Two independent populations agreeing on where to cut. Checked unbroken: boot pacing unmoved, scripted walk runs end to end with focus restored. Also recorded: my "34 focus-record elements, only 2 varying" is right for GP_TITLE and reads as a fact about the format -- disc-wide it is 210 varying, 202 with rest() at the peak, concentrated in the paks a wider port reaches next. And their sharper framing, which I have adopted: a pulsing element has no resting pose at all, so rest() is MALFORMED rather than mis-answered on one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF |
||
|
Sylpheed port agent
|
d57366a35f |
port: the focus ring had silently stopped, and the plate's period is now the disc's
BLOCKED said the record-layout change touches five things: pose_at, settle_units, spin_period_units, exit_ramp_units and the plate. I checked two, reported that, and did not work the rest of the list. `spin_period_units` required "the first timed and the second untimed". Under the corrected layout the ring reads t=0 rot=0 and t=120 rot=360 -- both timed -- so the rule returned 0 and THE FOCUS RING STOPPED SPINNING. Nothing reported it: a period of 0 is a legal "this element does not spin". Rewritten to take the SPAN between the two poses: 120 - 0 = 120 units, the same number the old rule produced, which is evidence the corrected layout is self-consistent rather than merely different. Verified the way P5 verified it, by bit-identity one period apart on the ring's own 60x60 box so the ptloop sweeps cannot confound it: 0 at +120 units (twice), 8.61 at a quarter period, 8.88 at half. Three wrong instruments on the way, and the sequence is the lesson. A whole-frame `max` saturates on one rotating edge (adjacent frames scored 131 with a mean of 0.022). A live --menu filmstrip jitters by up to a frame, which is ~3 degrees of ring. And a whole-frame comparison is dominated by the sweeps, which move 480 px over one ring period. `--focus=<id>` was added so a --screen run can draw a focus record deterministically, which is what made the check reproducible. THE PLATE'S PERIOD IS NOW 105, THE DISC'S OWN GROUP LENGTH, and it disagrees with the measurement. The ambiguity the entry carried is gone -- it used to say the cycle might restart at t=6 rather than 0 and that nothing separated them; the group now runs t=0 to t=105, both at alpha 0, and there is one reading. But 105 units is 1.750 s, or 1.906 s scaled by the factor the ring shows between its declared 120 and its measured 2.177 s -- about 17% below all four corpus timings (2.12 / 2.19 / 2.34 / 2.31). The old 129 gave 2.34 s, at the top of the range, which is why it looked right. 129 was the last timed keyframe plus exit_ramp_units, and that constant is deleted. A period built on a constant that no longer exists cannot stay even though it fitted better, so the port ships the disc's number and says it is wrong. Verified bit-identical 105 units apart, 0.83 at 30 units. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF |
||
|
Sylpheed port agent
|
5dbc9aeac0 |
port: delete exit_ramp_units, invert the format's own rule, and guard a scale-0 leaf
FOUR THINGS, and the first is what MISSION section 3 calls the measure of
progress.
DELETED `exit_ramp_units` AND `exit_ramp_seconds`. They 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 that keyframe
does not exist -- a group is an 8-byte header then frames x {u32 time; 36-byte
pose} and every pose is timed. VERIFIED DEAD BEFORE DELETING: setting it to 9999
(166 s) moved the boot's transitions by 0.04 s, which is wall-clock jitter, and
both uses in ScreenView are gated on a condition that no longer fires on any of
the export's 866 keyframes.
INVERTED THE FORMAT'S OWN RULE. `check.rs` enforced "the final keyframe has no
`t`; the disc has no time slot there" and FORMAT.md stated it. Both are now
backwards, and the validator fired 150 times on a re-export. I had not run
`check` between pinning the tag and measuring against the oracle -- the pixel
harness was green while the format validator was failing on every screen with a
multi-keyframe group. A correctness harness does not replace a format one; they
fail at different layers.
GUARDED A SCALE-0 LEAF, which the Decoder hit in its own renderer: its leaf
branch marked the element drawn unconditionally while the blit returned early on
zero scale, so a scale-0 leaf suppressed its parent and blanked the element --
live on all four loading screens. This port did not have the bug only because
authored/rendering.json happens not to list pgloading_loop5. That is an accident
of a gate written for another reason, not a defence, so `_draw_leaf` now reports
whether it drew and `_draw` falls back to the parent.
ISOLATED THE PACING QUESTION rather than leaving it as a suspected regression.
Legacy association: publisher 4.70 agrees, developer 3.92 DIFFERS. Corrected:
publisher 4.26 DIFFERS, developer 3.62 agrees. Both misses are ~0.03 s outside a
composite bound. The association traded which screen is marginally out; it did
not regress the pacing.
Bumped the pin c -> d for the parser and audio changes. Its headline renderer
change does not reach this port: sylpheed-cli builds from the workspace crate.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
|
||
|
Sylpheed port agent
|
9f6959c7ca |
port: implement the decoded leaf composition -- and it does not close the 1.82%
The Decoder decoded the rule I refused to guess: draw the leaf on its own timeline, do NOT multiply the parent's alpha in. Multiplying is refuted rather than unsupported -- at the fitted time the parent has expired, so leaf x parent predicts zero for both quads and the sweeps would be invisible. They are drawn. Implemented: `_draw_leaf` runs the leaf unclamped, like the spinning ring and for the same reason -- held at its own rest.t the leaf sits at x=1521, entirely off the right edge, so `holding` would delete the sweeps rather than settle them. AND IT CHANGES NOTHING MEASURABLE. The title is still 1.82% against the oracle: 1.82 at t=261, 1.81 at t=355, 1.79 at t=420. At t=355 my interpolation puts the leaf's top-left at x ~ -324, off-screen left, where the Decoder's model puts the quad's CENTRE at 981. Those cannot both be right, and it is not something to tune away -- it is a disagreement about how the leaf's keyframes become a placed quad, most likely in the pivot and the rotation about it. Handed back with both numbers. So: the exporter no longer drops the data, the composition rule is implemented as decoded, and the port's largest oracle gap is exactly where it was. Fixing the export was necessary and not sufficient. TWO FLAGGED ELEMENTS DELIBERATELY NOT DRAWN, in authored/rendering.json with reasons. title_jp/ptlogo_eff2 (parent 125%, leaf 100%) is the same shape and is the element DECISIONS has recorded since P1 as the largest render disagreement -- but the Decoder said plainly "I have not tested it", and drawing it would extend a decode past the case it was fitted on. pgloading_loop5's leaf is scale (0,0), and scale-0 is one of the three historical failures this corpus names. Neither can be adjudicated here: title_jp has no oracle capture, and verify-screen compares against a renderer that draws no leaves at all, so ANY leaf drawing increases that divergence whether right or wrong. Its max went 155 -> 232 when they were drawn, and that number is not evidence in either direction. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF |
||
|
Sylpheed port agent
|
7c918006e8 |
port: the PRESS (A) plate pulses -- authored per element, because 82 of 212 share its shape
The human listed pulsation as first-class and the port drew nothing: the plate's focus record `ptbtn00f` was never reached, because press_start has no `buttons` and nothing is focused. That it LOOPS is measured -- the corpus timed the period four times (2.12 / 2.19 / 2.34 / 2.31 s) and you cannot measure a period unless the thing repeats. THE RULE I WAS GOING TO WRITE DIED IN THE CENSUS. The spinning ring is a rule in the renderer because it has a disc-wide check: 16 of 212 elements match its shape and all 16 are focus rings. The analogous shape for a pulse -- keyframes varying only in alpha, first alpha equal to last -- matches 82 OF 212, including ptcopyright, palogo_sqex, ptmsg and every _eff fade. A renderer rule on it would make the copyright notice pulse. Narrowed to focus records it matches exactly one distinct element, and a rule justified by n=1 is a special case wearing a rule's clothes. So it is a LOOKUP in authored/timing.json keyed <screen>/<element>, with the census recorded beside it so nobody widens it later. The period is 129 units -- the element's own group under the port's existing model: last timed keyframe t=105 plus the authored exit_ramp_units of 24. No new constant. 2.150 s at 60 units/s, 2.295 s at the ~28.1 fps the emulator presents, against measurements of 2.12-2.34. IT IS A CHOICE AND THE ALTERNATIVE IS STATED: restarting at the group's first keyframe (t=6) instead of 0 gives 123 units = 2.050 / 2.189 s, also inside the measured spread. Nothing separates them. t=0 is taken because it is where every other group starts -- consistency, not evidence. Verified the way the ring was, by bit-identity one period apart. 20 periods is 43.00 s = exactly 172 film frames: frames N and N+172 differ by 0-1/255, while the control a quarter-second off (43.25 s) differs by 58.7/255. On the held boot title the glow-box mean swings 26.0 <-> 37.7. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF |
||
|
Sylpheed port agent
|
f8a8d17327 |
port: the ring spins, the plate needs no constant, and rest.t was never the settle
Two milestones' known-wrong bits, both now answered by the RE agent, both taken. P5 -- the focus ring. It was drawn at 0 with a comment saying so. The period is now measured (continuous spin, eight evenly spaced autocorrelation peaks over nine revolutions, no angle estimated anywhere) and it needs NO authored constant: the period is the element's own declared t=120, and what the measurement adds is only that the turn repeats rather than stopping -- which "groups hold" could not decide, because 0 and 360 are the same pose. `spin_period_units` is structural and narrow on purpose: two keyframes, differing in nothing but rotation_deg, by a full 360, first timed and second untimed. 16 of 212 elements in this export match and all 16 are focus rings, zero false positives. That check is the point -- the measurement was taken on ONE button of ONE screen, and a rule that caught anything else would be extrapolating it to elements nobody watched. Verified on the port's own render with the RE agent's own control: bit-identical one period apart across the whole frame, 3.6/255 inside the ring's box at quarter-period steps, and box luminance conserved to 0.027 % over eight phases -- which is the observable they used to separate rotation from a pulse. Not claimed: direction (no signed angle was ever measured) and phase across a focus change (their run held focus throughout). P3 -- the plate. Last iteration I refuted their authoring instruction and shipped it anyway rather than pick between two of their numbers. The refutation held and the answer came back better than either option I offered: AUTHOR NOTHING. Both builds run on one clock started together and the plate arrives at its own declared t=238. The 2.13 s constant is deleted. The premise that failed was mine: rest.t IS NOT WHEN A SCREEN SETTLES. It is the last hold keyframe before the exit. ptlogo1 stops MOVING at t=42 and then creeps 5 px and 31 alpha steps to t=251. Reading rest.t put build 4's arrival at 4.350 s instead of 1.967 s, and the "2.51 s, which is not a landmark of anything" I sent them is that error wearing a decimal point. 238 - 118 = 120 units = 2.000 s against a measured 2.135 s at 28.1 fps presentation. Checked against my own export before touching anything. `ScreenView.settle_time()` still uses rest.t, and so the boot sequencer paces every screen off the wrong landmark. NOT changed here: "visible arrival" is a heuristic and getting it wrong re-paces everything. Filed, and asked for a timed boot instead now that their oracle is live. REFUTATION: two of their pages measure the same declared 120 units of wall clock during a static hold and disagree by 2 % -- plate 2.135 s (28.10 fps implied), ring 2.177 s (27.56 fps). That is seven times the plate page's own 6 ms run-to-run agreement, and it lands on the argument that page uses to justify itself: "the build-in is where frames are dropped; the static hold is not". Also the ring page's band, 27.6-28.8 fps, does not contain its own measurement -- the mean needs 27.56 and four of seven spacings are outside. Filed, not worked around: my port uses the declared 120 units either way. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WM5XL4HfrHuxz8RiMWdCMC |
||
|
Sylpheed port agent
|
eef45ecfd6 |
port: P5 -- the menus navigate, and the focus ring is drawn wrong on purpose
P5's gate is "a human clicks through it". The artifact is a scripted walk that
proves the wiring rather than the intent -- up (wraps 01->05), five down, (A)
into EXTRAS, down, (B) back, landing on the main menu with focus RESTORED to
EXTRAS, ten PNGs one per settled step:
xvfb-run -a godot --path port -- --menu \
--script=up,down,down,down,down,down,accept,down,cancel --shots=/tmp/p5
--script posts InputEventAction through Input.parse_input_event so the presses
arrive at _unhandled_input exactly as a d-pad's would. Calling MenuFlow directly
would have been shorter and would have proved nothing: the wiring between a
press and the cursor is the part most likely to be broken, and a direct call is
exactly the part that skips it.
Derived vs authored, which P5 is the easiest place to blur:
* DERIVED -- the ORDER of the items, from each screen file's `buttons`, which
the exporter already fills from button-role elements sorted by resting Y.
* AUTHORED -- destinations, initial focus, what (B) does, and left/right being
a no-op. All measured off the running game (HANDOFF Q4/Q5) or chosen, none
on the disc, all in authored/flow.json with a why.
Four of five main-menu destinations are `goto: null` with a `blocked` note. That
is a MILESTONE BOUNDARY, not an unknown -- DIFFICULTY, the save list, the lesson
list and OPTIONS were all measured and live in archives this export does not
carry. `blocked` and `none` are kept apart so nobody later "discovers" the gap.
--headless CANNOT DRAW, and the port hung instead of saying so.
Measured, not assumed: under --headless Godot's dummy renderer never emits
RenderingServer.frame_post_draw, so every capture path awaited it forever --
--capture since P1, --film since P3, --shots as of now. With stdout block-
buffered the observable behaviour was SILENCE, FOREVER, which in a loop reads as
a job still working. Isolated by `--quit` (prints, exits 0) vs `--capture` (zero
bytes, killed at 40 s). Now those three flags refuse at STARTUP naming the
xvfb-run line that works, and --script no longer waits for a frame it is not
going to photograph -- so headless walks the menus in 4.5 s as a cheap
regression check needing no X server.
REFUTATION ATTEMPT, against the Decoder's
|
||
|
MechaCat02
|
65cefa74c3 |
monorepo: one repository for the decoders, the port and the corpus
Some checks failed
Merges the Godot port into the reverse-engineering repository, preserving both
histories -- 1019 commits of corpus plus the port's 31, brought in by subtree
merge and then moved into place so git can follow each file across the rename.
The reason is not tidiness. The two-repo split forced the exporter to depend on
the decoders by pinned revision, and that created a whole class of failure that
now disappears: a sha reachable only from a topic branch, orphaned by a
squash-merge, breaking a fresh checkout silently at build time. It also forced a
live read-only mount of one agent's working tree into another's container, which
is why a contract file could move mid-iteration. With a path dependency, a
decoder change and the exporter change it requires land in the same commit or
not at all.
Canary stays separate: it is a fork tracking upstream.
New structure for the long term:
docs/game/ how the game is NAVIGATED -- menus, modals, prompts, alerts,
and in-game flight. Written so nobody rediscovers it. Mostly
open questions on purpose; the in-game tutorials are the
resource for the flight half.
docs/port/MODDING.md
modding as a constraint on the exporter TODAY, not a later
feature: one logical asset in one file (the disc splits nearly
everything, and resolving that is the exporter's job), names a
person recognises, PNG/OGG/OGV/JSON only, base-and-overrides so
re-exporting is always safe, provenance in every file.
data/base + data/mods
generated tree and drop-in overrides, both gitignored
exchange/ transient inter-agent files, deliberately outside history
docs/agents/ the team protocol
Both the README and the navigation doc lead with the correction that cost the
most: the oracle is the real game under Xenia Canary. Reborn's renderer is a
hypothesis under test, it has been wrong, and treating it as ground truth
propagated into three documents and both agents before a human caught it.
Scripted modding stays possible without being built: no screen name is hardcoded
in GDScript and there is no native code in port/, which is what Godot Mod Loader
needs to be able to substitute behaviour later.
|