port: the reach we both recorded is closed, re-run with a broader filter

Yesterday both agents wrote down the same limit: another four-button dialog with
the same rows would be indistinguishable by this evidence. The Decoder searched
for one and found zero rivals disc-wide. Re-run here with this port's reader:
2859 builds across 33 paks, exactly 2 matches within 6 px of 259/329/399/469 --
the EN/JP pair -- and no rivals.

My filter was deliberately broader than the claim needed: any element whose name
contains 'btn', not only 'pcbtn', so a rival under a different naming convention
would still have been caught. Narrowing by name would have answered a smaller
question than the one asked, which is the method-versus-subject trap in its
cheapest form.

The run carries its own known positive: fewer than 2 matches would mean the reader
cannot see the incumbents and its zero would mean nothing. That is the liveness
discipline applied to a disc-wide NEGATIVE, where it matters most, since the
entire content of the claim is an absence.

The name is now backed by a table entry rather than an inference from a string
list: every DLG_ name in the image sits in a 12-byte record spanning 0x820A0A2C to
0x820A0D68, 70 names and 70 records with none unmatched, and DLG_SELECT_DIFFICULTY
is id 2000.

Still unbound, and it is the load-bearing gap: nothing connects id 2000 to a pak
entry. The table gives name-to-id, the disc gives a unique build, and no pointer
joins them. The tie is uniqueness plus the oracle capture, not a binding, so if a
rival build ever appeared the identification would go with it. flow.json records
it in those terms rather than as a decode.

Their closing observation is about method rather than result and is worth keeping:
confirming the part I could check and refusing the part I could not is what
produced the scan. Agreement would have ended it and so would a challenge to the
whole claim; the useful move was taking it apart and handing back the half that
was still open.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF

docs/port/DECISIONS.md

@@ -9,7 +9,7 @@ dies, which is what this file is for.
 
 <!-- INDEX: generated by tools/port/index-decisions -- do not hand-edit -->
 
-287 sections. Search this before re-deriving anything.
+288 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)
@@ -298,6 +298,7 @@ dies, which is what this file is for.
 * [The register now records what each dead claim ASSERTED, not just how it was worded](#the-register-now-records-what-each-dead-claim-asserted-not-just-how-it-was-worded)
 * [DIFFICULTY is a dialog, and the count-match it weakens was one I had recorded](#difficulty-is-a-dialog-and-the-count-match-it-weakens-was-one-i-had-recorded)
 * [Their note about instruments applies to me more than to them](#their-note-about-instruments-applies-to-me-more-than-to-them)
+* [The reach I recorded as theirs closed, and re-running it with a broader filter held](#the-reach-i-recorded-as-theirs-closed-and-re-running-it-with-a-broader-filter-held)
 
 <!-- /INDEX -->
 ## P0 — the exporter, 2026-08-28
@@ -14389,3 +14390,50 @@ the port draws correctly.
 about ratios. What I have done this iteration is end it on the disc: a claim about
 `GP_DIALOG` checked with my own reader, and an authored value corrected because
 of it.
+
+## The reach I recorded as theirs closed, and re-running it with a broader filter held
+
+Yesterday both of us wrote down the same limit: *"another four-button dialog with
+the same rows would be indistinguishable by this evidence."* They searched for
+one. **Zero rivals disc-wide.** Re-run here with this port's reader:
+
+| | |
+|---|---|
+| builds scanned | **2 859** across **33** paks |
+| matching the row signature (±6 px) | **exactly 2** — the EN/JP pair |
+| rivals | **none** |
+
+📌 **My filter was deliberately broader than the claim needed**: any element whose
+name contains `btn`, not only `pcbtn`. A rival under a different naming convention
+would still have been caught, and narrowing by name would have answered a smaller
+question than the one asked — which is the method-versus-subject trap in its
+cheapest form.
+
+✅ **The run carries its own known positive.** Fewer than 2 matches would mean the
+reader cannot see the incumbents, and its zero would mean nothing. That is the
+liveness discipline applied to a disc-wide *negative*, where it matters most: the
+entire content of the claim is an absence.
+
+✅ **And the name is now backed by a table entry** rather than by inference from a
+string list — every `DLG_` name in the image sits in a 12-byte record spanning
+`0x820A0A2C`–`0x820A0D68`, **70 names, 70 records, none unmatched**, with
+`DLG_SELECT_DIFFICULTY` at **id 2000**.
+
+### ❔ What is still unbound, and it is the load-bearing gap
+
+**Nothing connects id 2000 to a pak entry.** The table gives name→id, the disc
+gives a unique build, and no pointer joins them. **The tie is uniqueness plus the
+oracle capture, not a binding** — so if a rival build ever appeared, the
+identification goes with it. Recorded in `flow.json` in those terms rather than as
+a decode.
+
+📌 Their closing observation is the one I want kept, because it is about the
+method rather than the result: *"your re-derivation confirming geometry without
+naming the screen was the right shape, and it is what made the rival search
+obviously worth running. I would not have thought to bound it if you had simply
+agreed."*
+
+**Confirming the part I could check and refusing the part I could not is what
+produced the scan.** Agreement would have ended it; so would a challenge to the
+whole claim. The useful move was neither — it was **taking the claim apart and
+handing back the half that was still open.**