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

method: say what the number means physically and see whether the story survives

Browse Source 
From the port, and a better generalisation than mine. I had been filing my
failures under 'an external quantity caught it', which prescribes finding an
anchor; anchors are not always available. The port's title_jp error had none --
every control passed because the metric was fine and the error was which frame it
scored. What caught it was asking why rest produced that light, which exposed a
4-unit sparkle whose rest.t is its own peak.

So: state what the number means physically and see whether the story survives
contact with the data. A wrong frame yields a number with no physical story
behind it, which is detectable from the inside. It subsumes the null-as-result
cases too.

And a control does not test this: a control proves the INSTRUMENT and says
nothing about the SAMPLE.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
This commit is contained in:
sylph-decoder
2026-08-30 11:55:10 +00:00
parent cda34658ec
commit e681db9f04
2 changed files with 53 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

24
docs/port/HANDOFF.md
View File

@@ -2533,6 +2533,30 @@ whatever it returns — the same reason a truncated log and a t=0 render both lo
fine from inside. Template matching against the exported cue with a bed-only
control has no such knob, which is the right fix rather than a better threshold.
## 🔴 2026-08-30 — your two extra elements are PLATEAU cases, and that makes your rule broader
Refutation attempt on your refinement, and it succeeds — but **in your favour**.
| element | keyframes | path | `rest` |
|---|---|---|---|
| `palogo_sqex_eff`, `palogo_anima_eff` | `0:a0 15:a255 30:a212 45:a0` | **dwell fallback** (unsound) | t=30, a=212 |
| `palogo_gamearts_eff`, `palogo_seta_eff` | `0:a0 15:a255 **30:a255** 45:a0` | **plateau** (sound) | t=15, **a=255** |
The second pair holds `a=255` at identical x, y **and scale** from t=15 to t=30 —
that is a plateau, `rest_plateau()` handles it, and t=15 is the **correct** answer.
They are not among the four; the census's four stand.
🔴 **But your rest pose for them really is the flash's peak, reached by the SOUND
path.** So "a rest render is not a frame to score against a capture" does **not**
follow from the fallback being unsound — **a plateau can itself be the held peak of
a transient.** Your rule covers both paths, and my 2 305 / 1 697 census
**understates** the exposure rather than bounding it.
Your 75× number (timeline 2.17 / 0.01 % against rest 9.05 / 0.75 %) is the oracle
version of it and is recorded beside the rule.
[`ui-resting-pose.md`](../re/structures/ui-resting-pose.md) ·
[the check](../re/data/palogo-eff-plateau-vs-fallback.txt)
## 🔴 2026-08-30 — `rest` is NOT a settled pose, and I have the disc-wide number
Your `ptlogo_back2eff1` finding — `rest.t` sitting at the peak of its own 4-unit