sync: auto-sync from HOWARD-HOME at 2026-06-16 13:43:14

Author: Howard Enos
Machine: HOWARD-HOME
Timestamp: 2026-06-16 13:43:14

clients/cascades-tucson/session-logs/2026-06/2026-06-15-howard-cascades-wifi-rf-audit.md

@@ -575,3 +575,40 @@ when the VPN started flapping (don't tie home gateway IP to an unstable tunnel).
 VPN FLAP: OpenVPN Connect DCO instability (DCO adapter Disconnected, TAP up, 4 OpenVPNConnect procs) -
 the same DCO/TAP issue seen earlier. Fix: disable DCO in OpenVPN Connect (force TAP datapath) OR switch to
 community OpenVPN GUI; also check duplicate-CN (cert connected from 2 devices = connect/disconnect loop).
+
+## Update: 13:42 PT (2026-06-16) — pfSense compat layer: started, backed out, aligned to Mike's design
+
+Picked up "start the pfSense compat layer." Began a REST-API-backed `pfsense-audit.sh` **sibling**
+scaffold + a `references/pfsense-driver.md` design doc. On re-reading the repo, corrected course:
+
+- **What Mike actually built vs proposed.** `gw-control.sh` (commit `eb87710`) is **UniFi** gateway
+  control — it calls `/proxy/network/api/...` (the UniFi controller REST), validated on Grabb's
+  **USG-3P**. It does NOT touch pfSense. Commit `6998719` is a **roadmap entry** — ROADMAP §E
+  "pfSense gateway compatibility layer," a design with explicit **OPEN DECISIONS**, not built code.
+  So Mike *designed* the pfSense layer (with questions to resolve first); he did not build it.
+- **I had pre-empted his open decisions.** §E leaves two open: (1) backend = REST API package vs
+  stock SSH `easyrule`/`pfSsh.php`; (2) where the abstraction lives = dispatch **inside**
+  `gw-audit.sh`/`gw-control.sh` (keyed on `num_gw=0`) vs sibling `pf-*` scripts — Mike leans "inside."
+  My scaffold unilaterally picked REST + a sibling script (the opposite structure).
+- **Backed it out.** Removed `pfsense-audit.sh` + `pfsense-driver.md` (never committed/pushed) rather
+  than fork Mike's design. Released coord lock `a34360aa`. Messaged Mike (GURU-5070, id `e402e783`)
+  with the two open decisions and my lean.
+- **Howard's decision:** "let us try what mike wanted and go that way unless we run into a real
+  roadblock we can't work past." → **REST API package backend, dispatched INSIDE
+  `gw-audit.sh`/`gw-control.sh`** (Mike's option 1 + his structural lean). Build to that next.
+
+**Net for this update:** no code shipped; design alignment + coordination only. The WiFi/RF work
+(Floor-4 pilot applied + held, Phase-C disables held, steering/min-rate/channel-plan dry-run-validated)
+is unchanged from earlier in this log.
+
+### Next steps (pfSense layer, per Howard + Mike)
+1. Per-site setup helper: install `pfSense-pkg-RESTAPI` + create a read-only key + vault at
+   `clients/<slug>/pfsense-api` (url+apikey). Cascades + ACG office have pfSense web creds vaulted
+   already (`clients/cascades-tucson/pfsense-firewall`, `infrastructure/pfsense-firewall`) — need the
+   API key added.
+2. Add a pfSense backend **inside** `gw-audit.sh` (dispatch on `num_gw=0`): WAN/gateway status via
+   `/api/v2/status/gateways`, system, DHCP pool pressure. Then `gw-control.sh` verbs (pf-list/disable/
+   enable/set-ports, fw-disable/enable, block-ips) onto `firewall/nat/port_forward` + `firewall/rule`
+   + `easyrule`-equivalent.
+3. Live validation pending a reachable pfSense (stable site VPN; mind the home-LAN .0.x shadow that
+   currently masks Cascades pfSense from Howard-Home). Coordinate the build with Mike (his §E).