From e9f27c09877eb604dbb1dd1afebb4dafc4b03154 Mon Sep 17 00:00:00 2001
From: Drew T <50529377+Druthulu@users.noreply.github.com>
Date: Fri, 24 Jul 2026 21:39:12 -0600
Subject: [PATCH] =?UTF-8?q?docs(phase-29):=20correct=20=C2=A767=20?=
 =?UTF-8?q?=E2=80=94=20the=20a2=20$7=20pin=20is=20still=20load-bearing,=20?=
 =?UTF-8?q?not=20pin-free?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 docs/matching-cookbook.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/matching-cookbook.md b/docs/matching-cookbook.md
index e8570930f..23e4dfdcb 100644
--- a/docs/matching-cookbook.md
+++ b/docs/matching-cookbook.md
@@ -5362,7 +5362,7 @@ Drop it: same bytes, simpler C, one less thing to explain to the next session.
 
 **This is a PATTERN, not a one-off — it fired twice on the same function.** The `t` pin (`$3`) went
 redundant after the launder, and later the `u` pin (`$2`) went redundant too (identical 9 either way),
-leaving the banked seed **pin-free**. A register pin is a *crutch for a mis-scheduled value*; once the
+leaving only the `a2` `$7` pin, which stays genuinely load-bearing (dropping it costs 9 → 29). A register pin is a *crutch for a mis-scheduled value*; once the
 value is scheduled correctly the pin is dead weight — and a stale pin actively costs you, because it
 reserves a hard register the allocator then cannot use where the target does. **After any structural
 fix, re-test every pin you inherited and drop the ones that are inert.** (Corollary, byte-measured: