memory: planned 2026-09-18 dragonfireacoustics move to Namecheap/Cloudflare — DNS-first ordering and the wildcard-masking trap

persistent-memory.md

@@ -117,6 +117,28 @@ no longer deployed sidecars here. See Recent decisions.)
 
 _As of 2026-09-17 ~09:00 PT._
 
+### PLANNED 2026-09-18 (operator) — move `dragonfireacoustics.com` to Namecheap, DNS to Cloudflare
+
+Operator holds the **TAC/EPP** already. TAC is **single-use and dies 14 days after issue**, so the
+clock is running; domain itself expires **2026-10-30** and a transfer adds a year, so the transfer
+IS the renewal if it lands in time.
+
+⚠ **Recommended order is DNS FIRST, transfer second** — stand the Cloudflare zone up, repoint the
+nameservers at eNom (NS is a registrar function he already has access to), verify mail and the site,
+THEN burn the TAC. The registry keeps the NS delegation across a transfer and Namecheap does not
+overwrite it, so nothing has to be redone; and if DNS goes wrong you still have a working registrar
+account to revert at instead of discovering it mid-transfer with a spent code.
+
+⚠⚠ **The zone's `*` wildcard MASKS what is really there.** Everything — apex, mail, webmail, admin,
+ftp — answers 199.250.192.76 (dead) purely because of that one record. Cloudflare's add-a-zone scan
+will happily import the dead wildcard and may not surface what is genuinely configured, so the
+**7 Google Workspace MX records must be checked by hand after the import** or mail stops. The only
+records that actually matter: `www A 38.120.12.45` and those MX.
+
+Open sub-decisions carried into the move: point the apex at 38.120.12.45 too (makes the bare domain
+work for the first time and lets a replacement cert cover it), and add SPF/DMARC — the domain runs
+Google Workspace with **neither**.
+
 ### DONE: lv-mccarthy D4 pairs built — NEXT is `train_pairs_lora.py`
 
 `~/lv-mccarthy/pairs/` on gx10, 2026-09-17 11:55 PT via `run-pairs.sh` (committed at