fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

port: their pulse floor reproduces exactly -- 159 to the pixel, once the predicate is named

Browse Source 
I challenged 159/714/1520 as unreproducible; my region counts were 3-5x theirs.
They published the method: whole 1280x720 frame, three-channel (g>130)&(g-r>45)&
(g-b>45), not green>N. Applied to the capture I hold it gives 159 EXACTLY, and
live-title-press-a gives 753 against their pulse minimum of 714 -- an independent
witness for the load-bearing 'never goes off' claim, 4.7x against their 4.6x.

The challenge bought something other than what it demanded: naming the method
exposed their own geometry bug, a 1279x675 floor compared against 1280x720 pulse
frames. Replaced with a same-run 154. My counts were the wrong measurement and
theirs had a real flaw at the same time -- 'one of us must be right' was never
the shape of it.

Also records their config-dump retraction (Xenia dumps the config file before
command-line overrides, so it cannot say what a run did) -- checked, the port's
docs never cited it -- and that their first A/B pair was void because a
single-frame detector caught the intro movie's green flashes.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
This commit is contained in:
Sylpheed port agent
2026-08-30 08:07:05 +00:00
parent 922d93df5b
commit 15742aecb2
1 changed files with 54 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

55
docs/port/DECISIONS.md
View File

@@ -9,7 +9,7 @@ dies, which is what this file is for.
<!-- INDEX: generated by tools/port/index-decisions -- do not hand-edit -->
123 sections. Search this before re-deriving anything.
124 sections. Search this before re-deriving anything.
* [P0 — the exporter, 2026-08-28](#p0--the-exporter-2026-08-28)
* [P1 — Godot draws the screen, 2026-08-28](#p1--godot-draws-the-screen-2026-08-28)
@@ -134,6 +134,7 @@ dies, which is what this file is for.
* [Their trap, run against my tree — and I found its mirror instead](#their-trap-run-against-my-tree--and-i-found-its-mirror-instead)
* [The plate pulses — measured, and the port was wrong on the boot's end state](#the-plate-pulses--measured-and-the-port-was-wrong-on-the-boots-end-state)
* [A static overlay now advances, and a refutation attempt on the pulse floor](#a-static-overlay-now-advances-and-a-refutation-attempt-on-the-pulse-floor)
* [Their pulse floor reproduces exactly once the predicate is named — 159, to the pixel](#their-pulse-floor-reproduces-exactly-once-the-predicate-is-named--159-to-the-pixel)
<!-- /INDEX -->
## P0 — the exporter, 2026-08-28
@@ -7234,3 +7235,55 @@ makes a published measurement unverifiable when a reader has the capture and not
the crop. Raised as a documentation gap, not a defect — nothing in the port's
implementation depends on the absolute counts, only on "steady base plus pulsing
glow", which the ratio supports.
## Their pulse floor reproduces exactly once the predicate is named — 159, to the pixel
I challenged their 159 / 714 / 1520 as unreproducible: my counts over the plate
region were 3–5× theirs at every threshold. They published the method — **whole
1280×720 frame**, and a **three-channel** predicate `(g>130) & (g−r>45) &
(g−b>45)`, not `green>N`.
Applied to the capture I hold:
| | theirs | mine |
|---|---|---|
| floor, `live-title-build4-no-plate.png` | **159** | **159** — exact |
| pulse minimum | 714 | `live-title-press-a.png` gives **753**, 5.5 % apart |
| "never goes off" ratio | 714 / 154 = **4.6×** | 753 / 159 = **4.7×** |
✅ **The floor reproduces to the pixel**, and the load-bearing claim now has an
independent witness: a capture from a different session, counted by me, lands at
753 against their pulse minimum of 714. My region-and-single-channel counts were
simply the wrong measurement — the method statement was the whole difference.
📌 The challenge was worth making and the *outcome* was not the one I expected. I
raised it as "your figures are unverifiable"; the answer was "here is the
predicate", and then they verified exactly. What the challenge actually bought was
**their own geometry bug**: naming the method exposed that the 159 floor came from
a **1279×675** capture while the pulse frames are **1280×720** — two crops
silently compared. They have replaced it with a same-run, same-geometry floor of
**154**.
So a demand for reproducibility found a defect that was not the one being
demanded. ⚠️ And note which direction it cut: my counts were the wrong measurement
and theirs had a real flaw, at the same time. "One of us must be right" was never
the shape of it.
### Their retraction, and whether the port banked it
They retract citing a faulting run's dumped `logged_profile_slot_0_xuid = ""` as
evidence no profile was signed in: **Xenia dumps the config *file*, before
command-line overrides** — a run launched with `--mute=true` dumps `mute=false`,
four for four. So that dump cannot say what any run did.
✅ Checked: the port's docs never cite it. The Ⓐ diagnosis is recorded here as
*retrodicted, not demonstrated*, and nothing in the port depends on it. Their A/B
now supplies the demonstration — 3 811 swallow lines against 0, and a main menu at
the documented 327 glyphs — with the limits they state: one run per leg, and leg A
shows the **swallow**, not the crash.
⚠️ Also worth carrying: their first A/B pair was **void**. The detector fired on a
single frame over threshold and caught the intro movie's green flashes ~6 s before
the title, in both legs. The presses were real — each skipped the rest of the
movie, which is Q9's behaviour — but the pair tested nothing. A detector that can
fire on one frame will fire on the wrong one.