docs(pfi): add lesson 7 — test a 'this will break X' premise before building on it

Seeded by the Site Magic / CGNAT premise, which justified a body of IPv6
work and turned out to be false the first time anything actually tested
it. The mechanism was discoverable in advance: Site Magic is WireGuard
and the far side has a public endpoint, so the NAT'd side dials out and
never needs inbound reachability. NAT breaks inbound; it does not break
outbound-initiated tunnels with keepalives.

Also fills the first row of the superseded-claims table, which is what
that table exists for -- the claim is corrected with a date rather than
quietly deleted, so older references to it resolve instead of misleading.

docs/pfi/ops-lessons-playbook.md

@@ -174,8 +174,37 @@ quietly stops being true."
 
 ---
 
+## 7. Verify a "this will break X" premise before building around it
+
+**Rule:** when a risk is asserted but never tested, test it — especially before it
+justifies a body of work.
+
+**Why:** fleet IPv6 work was justified largely by "ESH fiber behind CGNAT will
+break Site Magic on IPv4." The fiber cutover tested it for free: Cox was
+unplugged, ESH failed over to 5G on `192.168.200.111` — **RFC1918, double-NAT,
+no inbound path, strictly worse than CGNAT** — and the tunnel held, carrying real
+traffic to all four ESH hosts.
+
+The mechanism was discoverable in advance and made the outcome predictable:
+Site Magic is **WireGuard**, and the far side (NH3) has a public endpoint, so the
+NAT'd side dials out and never needs reachability. Ten minutes of reading the
+device config would have graded the risk correctly.
+
+**How to apply:** for any "X will break Y" belief, ask what protocol Y actually
+uses and which side must be reachable. NAT breaks *inbound* reachability; it does
+not break outbound-initiated tunnels with keepalives. Beliefs that gate real work
+deserve a test or an explicit "untested" label — and when they do get tested,
+record the result where the belief lived, not only where the test happened.
+
+**Related:** Site Magic has **no WAN binding** — `magic_site_to_site_vpn` on the
+gateway is just `enabled` plus a keypair, peers orchestrated in the UniFi cloud.
+It rides whichever uplink is active, so the only lever is failover priority, and
+that moves *all* site traffic rather than just the tunnel.
+
+---
+
 ## Superseded claims
 
 | date | claim | correction |
 |---|---|---|
-| — | _(none yet)_ | |
+| 2026-08-18 | "ESH behind CGNAT will break Site Magic (NH3↔ESH) on IPv4, so IPv6 is the escape hatch" | **False.** Tested live during the fiber cutover: ESH on RFC1918 double-NAT (`192.168.200.111`), tunnel held with full reachability to all ESH hosts. Site Magic is WireGuard dialing out to NH3's public edge, so the NAT'd side never needs an inbound path. IPv6 remains worthwhile but gates nothing. |