method: the refuted register and a good correction pull against each other

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 20:19:54 +00:00
parent b4c6095c47
commit 390cdef5db

View File

@@ -2277,3 +2277,36 @@ train the check to be ignored. Mine avoids that collision only by accident — a
25-character minimum excludes bare numbers by construction, which is the same limit 25-character minimum excludes bare numbers by construction, which is the same limit
from the other side. A short claim cannot be enforced by substring; say so instead from the other side. A short claim cannot be enforced by substring; say so instead
of forcing a row in. of forcing a row in.
## The register and a good correction pull against each other
`sylpheed-port` surfaced this from their hook and it applies to `check_refuted.py`
unchanged, so it is recorded here as ours too.
**A substring register can only find a revival of a claim it holds verbatim. A
well-written correction paraphrases the dead claim away.** Their corrected heading
reads *"does **NOT go** against the port"*, which no longer contains the registered
phrase *"goes against the port"* — so the better the prose, the weaker the
enforcement. Mine has the same shape from the other side: it matches exact wording,
so a restatement is invisible to it.
⚠️ **These do not reconcile, and pretending otherwise produces a register that is
trusted more than it earns.** The workable posture is to keep the dead phrase
quoted *somewhere* — a `~~"…"~~` line in `REFUTED.md` is exactly that, and costs
the correcting prose nothing, because the register entry and the correction are
different documents. Quote verbatim in the register; paraphrase freely everywhere
else.
📌 Same family as the unregistrable-claim limit: **some enforcement is structurally
unavailable, and the honest move is to name which**, not to add a row that
generates noise and trains the check to be ignored.
## An independent confirmation of the capture-phase term, from the render side
The port pinned `--leaf-time=0` at their render sites and two *published* oracle
rows moved in **opposite** directions (`title_plate` 0.00 → 0.09 %, `title_band`
0.35 → 0.00 %). Opposite directions is the signature of a phase change rather than
a regression, and it is the same term I measured from the capture side as a
phase-locked shutter — arrived at independently, from the other end of the
pipeline. A row containing a sweeping leaf has a **phase-dependent value**, so
quoting one without the term attached is an error whichever side produces it.