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

port: finish the required-reading audit -- MODDING clean and checker-backed

Browse Source 
Finished the second half rather than leaving it named. MODDING.md carries no
status markers at all, so nothing of the stale-blocker shape. But their finding
was about claims, not markers: it states five rules, and tools/port/check-modding
asserts all five by name, one section each, and passes in check-all. Those claims
are mechanically verified on every suite run rather than merely unstaled.

Of the five documents the brief names, three are mine: BLOCKED.md (five rows
struck earlier), PORT-MISSION.md (two stale blockers corrected), MODDING.md
(clean, checker-backed). PROTOCOL.md and HANDOFF.md are not mine to correct, and
HANDOFF as I read it is the stale main copy, which is its own recorded problem.

Also checks their 'a ranked list always has a winner' against my own matching. My
GP_TUTORIAL identification ran the control first -- my own title capture over
seven builds with a known answer, picking build 4 at +0.2792 -- and the submenu
then scored +0.4962, above the calibrated true-match score rather than merely top
of a list. No other nearest-match report exists in the tree.

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 19:19:31 +00:00
parent b16d98ec41
commit 33ab07ff2e
1 changed files with 35 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

35
docs/port/DECISIONS.md
View File

@@ -11725,3 +11725,38 @@ changing what it asks would be overstepping.**
⚠️ `MODDING.md` is still unaudited. I am naming that rather than quietly finishing
one of two.
### `MODDING.md` — audited, clean, and mechanically so
Finished the second half rather than leaving it named. `MODDING.md` carries **no
status markers at all** — no 🔴, no "not yet", no "planned" — so there is nothing
of the stale-blocker shape in it. But their finding was about *claims*, not
markers, so the real question is whether its assertions still hold.
✅ It states **five rules**, and `tools/port/check-modding` asserts **all five by
name** — one section per rule — and passes in `check-all`. So those claims are not
merely *unstaled*, they are **mechanically verified on every suite run**, which is
a stronger result than reading them and finding nothing wrong.
📌 So of the five documents the brief names, three are mine to audit:
`BLOCKED.md` (five rows struck, earlier), `PORT-MISSION.md` (**two stale blockers,
corrected above**), `MODDING.md` (clean, checker-backed). `PROTOCOL.md` and
`HANDOFF.md` are not mine to correct — and `HANDOFF.md` as I read it is the stale
`main` copy, which is its own recorded problem.
### Their "ranked list always has a winner" — checked against my own matching
They tried to identify the ninth pair's destination and **rejected their own
result**: best fits 43.30 (margin 5.88) and 45.74 (margin 2.28) against a
calibration putting a true match at ~18–20 with margin ~10. The general form is
worth keeping: **a ranked list always has a winner, and nothing in the ranking
says whether the winner is good enough — any nearest-match report needs a
known-good score beside it or it will name something every time it is asked.**
✅ Checked my own instance. When I identified their submenu capture as
`GP_TUTORIAL` by edge correlation, I ran the control **first**: my own `title`
capture over seven builds with a known answer, picking build 4 at **+0.2792**,
1.4× over second. The submenu then scored **+0.4962** with a 1.58× margin —
*above* the calibrated true-match score, not merely top of a list. That
identification carries its known-good; I have no other nearest-match report in the
tree.