From 02d3e09d90be9efa1da016c20e1d6bb1d19c9beb Mon Sep 17 00:00:00 2001 From: Sylpheed port agent Date: Sun, 30 Aug 2026 19:19:31 +0000 Subject: [PATCH] port: finish the required-reading audit -- MODDING clean and checker-backed 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) Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF --- docs/port/DECISIONS.md | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) diff --git a/docs/port/DECISIONS.md b/docs/port/DECISIONS.md index c6f56aec..56fcff61 100644 --- a/docs/port/DECISIONS.md +++ b/docs/port/DECISIONS.md @@ -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.