Did it right this time: completed the full channel survey (74/74) FIRST, let the
data choose. Survey proved DFS channels are 4-5x cleaner here (2-3% busy) than
non-DFS (149/157 = 12-28%, the property's worst). Per Howard: built the plan on
the 8 clean DFS 40MHz blocks (52/60/100/108/116/124/132/140), per-AP locally-
cleanest + neighbor graph-colored -> 0 co-channel, 3.5% avg busy. Applied to 72
non-mesh APs (width 40 too); mesh excluded; voice nudged back to 5GHz.
VALIDATED: 5GHz retry 8.7->3.8 avg (-56%), median 8.2->2.1 (-74%); 2.4 ~baseline;
satisfaction median 99; voice 31/31 (17 Poly on 5GHz, 3 coverage-cases on 2.4);
all 72 APs holding DFS, 0 radar vacates.
Kept tonight: 2b (2.4 power) + DFS plan + BSS-transition. 6GHz still WPA3-blocked.
auto_upgrade still OFF. Follow-up: recurring dfs-check radar monitor.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Correction to earlier "deferred" report: after Howard pushed (5GHz needs fixing
regardless of 6GHz), I attempted width40 + non-DFS channel plan autonomously.
It did NOT validate live: 5G retry flat (8.7->8.4), 2.4 retry up (12->16) from
voice phones scattering to 2.4. ROOT CAUSE: the non-DFS channels here (149/157)
carry the heaviest EXTERNAL interference while DFS was cleaner -> forcing non-DFS
traded clean DFS for congested non-DFS. Rolled 5GHz back to baseline (channel+80MHz).
Kicked the 8 stuck Poly phones -> 6 back to 5GHz (rest are coverage-gap rooms).
End state recovered: satisfaction 98.4/med99, voice 31/31. Kept: 2b (2.4 power)
+ BSS-transition. 5GHz unchanged from start. auto_upgrade left OFF.
Doing 5GHz right needs the per-channel survey (choose channels by real cleanliness,
not non-DFS policy), reconsider non-DFS-only, 6GHz unblock (WPA3), band-steer voice.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Read-only Phase 0 baseline extended to floors 5/6 (MemCare). Findings:
- MemCare = same 3 diseases as 1-4 but untreated (2.4 at full power, not
over-thinned; all 5GHz on DFS+80MHz; min-RSSI off everywhere; 6GHz dark;
Shelby .218 stuck on 2.4 at Nurse Station).
- 5GHz static non-DFS channel-plan dry-run: co-channel pairs 19 -> 0 (kills
auto on all non-mesh APs; relieves AP 103/505 as fall-out).
- 2.4 1/6/11 re-color NEGATIVE right now (22 -> 28); defer until 2b restores
a stable Medium-power radio set.
- 7-day hour-of-day traffic: ~600 clients 24/7 (only ~10% swing); trough
01:00-04:00 MST. Change window decided: 2 AM start.
No changes applied. Survey stalled 68/74 (re-run before any 5GHz channel apply).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The 2026-06-18 repo restructure (history rewrite + project->submodule split)
dropped these 4 Cascades files from the new clone. Copied byte-identical from
the pre-cutover claudetools.old clone (md5-verified):
- docs/network/network-optimization-master-plan.md
- docs/network/phase1-voice-qos-design.md
- reports/2026-06-18-voice-quality-diagnostic.md
- session-logs/2026-06/2026-06-18-howard-cascades-rf-voice-optimization-plan.md
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Relocated verbatim from .claude/CLAUDE.md so the ad2 fork stops editing the
shared fleet harness doc. After rebase onto main, .claude/CLAUDE.md = the lean
fleet version; Dataforth ops context lives here. Keeps future ad2 syncs clean.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
