docs: clarify current unifi protect chime state

home/doris-dashboard/docs/unifi-ssid-cleanup-proposal-2026-05-23.md

@@ -2,6 +2,10 @@
 
 Purpose: turn the remaining SSID cleanup into an exact low-risk keep/retire proposal before any live Wi-Fi changes.
 
+Status note:
+- this remains useful as a keep/retire proposal, but the Protect chime portion must now be read together with `unifi-protect-doorbell-chime-current-state-2026-05-26.md`
+- current known-good chime behavior is on Management/default `UniFi Wireless`, not on the Camera/Security lane
+
 ## Basis
 Artifact-based planning only. No live SSID edits were made in this pass.
 
@@ -87,8 +91,11 @@ Long-term, the network should converge on:
   - doorbell and Protect-chime estate justify a distinct security SSID
   - keeping security separate from generic IoT matches the redesign intent and future camera growth plan
 - Preconditions to call it final:
-  - doorbell/chimes remain healthy
+  - doorbell/chimes remain healthy after explicit Protect validation on that lane
   - no evidence that merging them into general IoT would be safer or simpler
+- Current caution:
+  - treat the Security SSID as future-state design intent, not proof that the Wi-Fi chimes are safe there today
+  - the current known-good live path for the chimes is still Management/default `UniFi Wireless`
 
 ### 5) Guest SSID
 - Proposed role: `create or enable separately when ready`
@@ -116,6 +123,7 @@ This is the safest order based on current evidence:
 - do not rename and repurpose a live SSID in one step if disabling/creating separately would be clearer
 - do not infer that Google/cast is solved globally from one successful pilot reassociation
 - do not collapse Security into generic IoT unless there is a deliberate design change
+- do not assume that because `UNEF's Playhouse` exists, the Protect chimes are already proven safe on it
 
 ## Practical one-page operator version
 If you want the shortest operator call: