From fcfd05dd268ab83c7fbb485df3dd6fcdd2b7c60b Mon Sep 17 00:00:00 2001 From: sylph-decoder Date: Sun, 30 Aug 2026 18:00:38 +0000 Subject: [PATCH] re: a false HEADING standing 78 lines above its own correction MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit sylpheed-port diagnosed their four instances of fixed-code-under-unfixed- description as a habit rather than inattention: corrections are ADDITIVE. They append a correction block and leave the original standing above it -- right for a record, wrong for a statement, because a reader takes the first assertion. Their fix is to keep the quote but demote it grammatically. Applied their diagnosis here and found a worse instance than theirs. screen-transitions.md carried the heading "### ❔ The fade-OUT duration is not in this field", with a section beneath it that is false in every sentence: "The fourth block has no time -- a group's last block stops 4 bytes short and that word is already the next group's element index. So the disc gives the ramp's target (black) and not its length. That duration is measured below, and the port is authoring it." All pre-fix. The record-layout fix times a group's final pose, so block 4 carries t=80 (menu), 74 (EXTRAS) and 269 (title), and the fade-out ramp is DECODED at 70->80 = 10 units, 64->74 = 10, 261->269 = 8. The section told the port to author a value that is decoded, and its correction sat 78 lines below. It also carried the dead rule's exact vocabulary -- "stops 4 bytes short" -- which is the grep I built for code last iteration and never ran against docs. Rewritten leading with the correction, the original quoted and demoted beneath it. METHOD: corrections are additive by default and that is wrong for a statement; the worst form is a HEADING, which asserts with maximum reach and minimum context, and a reader scanning headings never reaches the retraction. Audit headings first. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v --- docs/re/METHOD.md | 16 ++++++++++++++++ docs/re/screen-transitions.md | 23 +++++++++++++++++------ 2 files changed, 33 insertions(+), 6 deletions(-) diff --git a/docs/re/METHOD.md b/docs/re/METHOD.md index 5a0719d1..136409ae 100644 --- a/docs/re/METHOD.md +++ b/docs/re/METHOD.md @@ -469,6 +469,22 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the document is a hedge around something the current reader states exactly**: a `~0` or an "approximately" marks where the old reader could not see. +* **Corrections are ADDITIVE by default, and that is wrong for a statement.** + `sylpheed-port` diagnosed this in their own tree after four instances: they + append a `🔴 CORRECTION` block and leave the original sentence standing above + it. Right for a *record* — quoting the original is how a change stays visible — + and wrong for a *statement*, because **a reader takes the first assertion and + the retraction three lines later has already lost.** ⚠️ Their fix, adopted here: + keep the quote but **demote it grammatically** — lead with *"what this used to + say"*, so the false sentence cannot be read as the live one. + 🔴 **The worst form is a HEADING**, which asserts with maximum reach and minimum + context: `screen-transitions.md` carried `### ❔ The fade-OUT duration is not in + this field` — false in every sentence beneath it, including an instruction to the + port to author a value that is **decoded** — standing 78 lines above its own + correction. A reader scanning headings never reaches the retraction. + 📌 **So audit headings first**: they are the assertions most likely to be read + and least likely to carry the qualification that would save them. + ## Runtime / emulator * **Look at the PNG** — and check its dimensions. diff --git a/docs/re/screen-transitions.md b/docs/re/screen-transitions.md index 9aae6334..fca6dc38 100644 --- a/docs/re/screen-transitions.md +++ b/docs/re/screen-transitions.md @@ -55,13 +55,24 @@ fully visible and *not* fading at all. Read correctly the screen starts black at units (0.27 s)** on the title. A port pacing its menu fade-in off the old number would have run it **5× too slow**. -### ❔ The fade-OUT duration is not in this field +### ✅ The fade-OUT duration IS in this field — 10 units on the menu, 8 on the title -The fourth block has **no time** — a group's last block stops 4 bytes short and -that word is already the next group's element index -([`ui_layout.rs`](../../crates/sylpheed-formats/src/ui_layout.rs) documents the -packing). So the disc gives the ramp's *target* (black) and not its length. That -duration is **measured** below, and the port is authoring it. +**What this section used to say, and it was wrong in every sentence:** *"The +fade-OUT duration is not in this field. The fourth block has no time — a group's +last block stops 4 bytes short and that word is already the next group's element +index. So the disc gives the ramp's target (black) and not its length. That +duration is measured below, and the port is authoring it."* + +🔴 **All of that is the pre-fix reading.** The +[record-layout fix](ui-keyframe-record-layout.md) times a group's **final** pose, +so block 4 carries `t = 80` (menu), `74` (`EXTRAS`) and `269` (title). The fade-out +ramp is therefore **decoded**: `70 → 80` = **10 units**, `64 → 74` = 10, and +`261 → 269` = **8**. ⚠️ **The port should NOT author it** — this section told them +to, which is the most expensive kind of stale sentence: an instruction, stated +affirmatively, in a heading, a hundred lines above its own retraction. + +⚠️ Kept as a record of what changed, but demoted below the correction so the false +sentence cannot be read as the live one. ### The disc-wide check, and what it shows about overlays