98d02e7c24bc5eb6f4641db0936ac4a51c866de0
5 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Sylpheed port agent
|
98d02e7c24 |
port: my triage under-counted, and three uncited measurements surfaced behind it
Their audit found 9 of 57 HANDOFF sections asserting measured or undecodable-with-reach citing nothing openable, 84%, including one they had sent me: '(B) from EXTRAS DOES go black', delivered as an inline frame table while data/fade-four-transitions.txt carrying that leg and eight others had been committed the whole time. It had already landed here uncited. timing.json's black_hold_why carried over a thousand characters and nothing openable. 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. And my triage had missed it along with seven others. Last iteration I reported 13 provenance claims among the 52 and labelled them; the count was wrong because my sibling match was literal, so black_hold_why did not match black_hold_units, nor loop_start_why to loop_start_s, dwell_why to dwell_seconds, loop_leaf_why to loop_leaf_on_screens. Eight more, all hidden by a suffix. It was 21 and I stated 13 confidently. All eight now labelled from their own text; coverage 16 to 38. Three uncited MEASURED fields in one file -- loop_why at 1400 chars, loop_start_why at 1041, voice/presentation_why at 1402 and authored -- and all three were detailed rather than sloppy. The detail is what made them look sourced: a why that recounts a measurement carefully reads as well-evidenced because it is careful. That is the quality-correlated blind spot one level down -- not 'well-evidenced values never declared themselves' but 'well-argued prose never cited anything'. The authored one now cites the open question it stands in for. A false positive in my own extractor surfaced in the same pass: presentation_why was reported DANGLING on 1118268 and 1171516, byte counts read as commit shas because they are seven digits of valid hex characters. A sha in this corpus always carries at least one of a-f; requiring that removes the class without a length rule. A wrong verdict for a fabricated reason, the fourth of that family and this time in the auditor. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF |
||
|
Sylpheed port agent
|
f06be84be6 |
port: a withholding reason was false -- the hidden leaf is a visible expanding ring
authored/rendering.json justified not drawing build_12,15/pgloading_loop5 with 'leaf scale (0,0)'. That describes t=0 and t=30 and nothing after. The leaf holds pgloading_ring, scale ramping 0 -> 250 -> 800 -> 1000 with alpha full at t=55 -- an expanding fading ring, visible at scale 140 alpha 143 at the port's own pose instant near t=44. Withholding it declines to draw SOMETHING. Still withheld, on the reason already in the file: no oracle capture for a loading screen and verify-screen's reference draws no leaves, so the content is unadjudicable. Behaviour unchanged at 59530 px. The two entries in that list were written to different standards -- ptlogo_eff2 gets four paragraphs working through both readings, pgloading_loop5 got one false line. The difference is that one was interesting and one was a loading screen. Also verifies the measurement in the same paragraph: 'max went 155 -> 232 when drawn' reproduces at 231, differing pixels 20498 -> 58313. The file's numbers were sound and its reasoning was not, in adjacent sentences. 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
|
8994ca7c59 |
port: the 11.5 px was the fit's resolution -- and the lesson inverts
The Decoder closed it by ADDING OBSERVABLES, not by tuning. The vertex buffer carries positions and colours at the same instant, so all four quantities must agree on one t: quad A x solves to 357.88 and quad B x to 357.58, both +/-0.12 units, against 355.75 +/-1.54 and 354.09 +/-1.89 from the alphas. Alpha moves only 0.27-0.33 levels per unit, so one byte of quantisation is worth 1.5-1.9 units -- 6-8 px of sweep at 4 px/unit. That is the whole of the 11.5 px. At t=357.7 the centres land within 0.70 px and both alphas inside one level. THE LESSON IS THE EARLIER ONE INVERTED AND IT IS THE HALF WORTH KEEPING. Checking a wrong rule against alpha made it look confirmed; here the same insensitivity MANUFACTURED a residual that did not exist. An insensitive quantity does not merely fail to falsify -- it invents error. Solve on the fastest-moving field, check the slow one, never the reverse. I was already looking for a pivot rule to explain 11.5 px when they wrote; there was nothing to find. REFUTATION ATTEMPT, survived with a nuance: they state the leaf pivot is (200,90) on a 399x180 sprite, "the pivot is the centre, so rotation displaces it by nothing". Checked against my export -- pivot [200,90], sprite 399x180, true centre 199.5,90. It survives, but the sprite is ODD-WIDTH so the pivot is the centre to within half a pixel rather than exactly. No consequence against their 0.70 px agreement; worth stating because "displaces it by nothing" is the kind of sentence that later gets leaned on for a sub-pixel claim. verify-capture now poses the title at t=357.7 rather than 355: RMSE 21.07 -> 20.92, differing 1.82% -> 1.81%. Marginal, and it is the right pose for a stated reason rather than a better number. AND ptlogo_eff2 IS WITHHELD FOR A BETTER REASON THAN MINE. I had it on caution about untested generalisation; the Decoder points out it is on title_jp and MISSION section 7 scopes out "localisation beyond English", so it is not a question this port has to answer and the parked Japanese capture does not need reviving for it. authored/rendering.json now gives scope first and undecidability second. Widening scope to close a residual would have been the wrong trade. 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 |