docs: clarify current unifi protect chime state

home/doris-dashboard/docs/network-cutover-master-operator-sheet.md

@@ -2,6 +2,11 @@
 
 > For Doris: this is the one-page live operator sheet for tomorrow. Use this instead of bouncing between five docs while tired.
 
+Historical status note:
+- this file is a 2026-05-22 live cutover sheet, not the current remaining-work source of truth
+- do not treat its open checkboxes or "tomorrow" language as active backlog
+- current truth lives in `network-migration-remaining-checklist-2026-05-22.md` and `unifi-protect-doorbell-chime-current-state-2026-05-26.md`
+
 Goal: execute the UniFi network redesign with minimal improvisation, explicit stop/go gates, per-port actions, per-device dispositions, and fast rollback discipline.
 
 Architecture:
@@ -43,7 +48,7 @@ Current client counts:
 - Trusted: 14
 
 Current hazards:
-- two unnamed `espressif` devices are on Management via `UniFi Wireless` on the U7 Pro
+- the two historical `espressif` Management hazards are now known Protect WiFi chimes, not unidentified junk
 - almost all Wi‑Fi clients are on the U7 Pro
 - there are no custom firewall rules/groups yet, so tomorrow’s segmentation policy is basically greenfield
 
@@ -110,7 +115,7 @@ Stop/go gate:
 - [ ] Trusted admin path still fine
 
 ### Minute 20-35: management cleanup first
-- [ ] identify/address the 2 Management `espressif` devices
+- [ ] confirm the two former Management `espressif` devices are still understood as the documented Protect-chime exception
 - [ ] ensure infra devices remain on Management intent
 - [ ] remove obvious non-infra junk from Management
 
@@ -120,7 +125,7 @@ Stop/go gate:
 
 ### Minute 35-50: security cleanup
 - [ ] validate Camera lane
-- [ ] move Protect chimes if ready
+- [ ] move Protect chimes only if Protect health is explicitly validated during the move
 - [ ] confirm doorbell remains healthy
 
 ### Minute 50-85: core server move wave
@@ -160,22 +165,22 @@ Stop/go gate:
 
 ## 5. Management Offender Sheet
 
-These two devices are currently on Management and need identification or removal from that lane:
+These two devices were the historical Management offenders that needed identification. They are no longer mystery devices, and they are not a rediscovery task:
 
 1. `espressif`
 - IP: `10.5.0.123`
 - AP: `U7 Pro`
 - SSID: `UniFi Wireless`
-- Default call: identify first; if it is smart-junk, move/quarantine off Management
+- Current call: known Protect WiFi chime; keep on the documented Management/default-SSID exception unless doing an explicit Protect-validation move
 
 2. `espressif`
 - IP: `10.5.0.189`
 - AP: `U7 Pro`
 - SSID: `UniFi Wireless`
-- Default call: identify first; if it is smart-junk, move/quarantine off Management
+- Current call: known Protect WiFi chime; keep on the documented Management/default-SSID exception unless doing an explicit Protect-validation move
 
 Operator note:
-- these are almost certainly exactly the sort of device that should not live on your infrastructure lane
+- target architecture still says these belong with security estate, but the current known-good live state keeps them on Management/default `UniFi Wireless` because the Camera override failed in Protect
 
 ## 6. Exact Core Port Move Sheet
 
@@ -272,10 +277,14 @@ Rule:
 Already true:
 - `front-doorbell` is already on Camera at `10.5.20.217`
 
-Tomorrow’s security work is therefore mainly:
-- move/clean up chimes
-- tighten policy
+Current known-good chime exception:
+- Protect WiFi Chime `upstairs landing` is intentionally on Management/default `UniFi Wireless` at `10.5.0.123`
+- Protect WiFi Chime `Living Room` is intentionally on Management/default `UniFi Wireless` at `10.5.0.189`
+
+If revisiting security work, the goal is therefore:
 - preserve the doorbell’s healthy state
+- tighten policy carefully
+- only revisit chime placement during an explicit Protect-validation test
 
 ## 9. Firewall Build Priorities