docs: clarify current unifi protect chime state

docs/troubleshooting/KNOWN_QUIRKS.md

@@ -59,6 +59,12 @@ Per-service gotchas that aren't bugs but will bite you if you forget them.
 - `docker restart` or `docker compose restart` will NOT fix missing network attachments
 - Must use `docker compose --env-file .env down <service> && docker compose --env-file .env up -d <service>`
 
+### UniFi Protect WiFi chimes after doorbell/network changes
+- A UniFi Protect WiFi chime can look healthy in UniFi Network while still showing offline in Protect if a per-client Camera virtual-network override puts it on a lane that does not preserve the required Protect path.
+- In John's current environment, the known-good fallback for the two Wi-Fi chimes is Management/default `UniFi Wireless`, not the Camera-lane override that was tried on 2026-05-22.
+- After a doorbell is re-adopted, also verify each chime's `ringSettings.cameraId` still points at the current doorbell object; a stale camera binding can break ringing even when the network path is healthy.
+- Treat "device online in UniFi Network" and "device healthy in Protect / rings for the current doorbell" as separate checks.
+
 ---
 
 ## Serenity

home/doris-dashboard/docs/legacy-cia-triage-worksheet.md

@@ -2,6 +2,11 @@
 
 > For Doris: this worksheet exists so tomorrow does not devolve into vibes and guessing. Every device on Legacy CIA gets one label: migrate, quarantine, or kill.
 
+Historical status note:
+- this is a 2026-05-22 migration worksheet, not the current remaining-work checklist
+- do not treat its "tomorrow" language as active backlog without checking later result docs
+- current truth for Protect accessories lives in `unifi-protect-doorbell-chime-current-state-2026-05-26.md`
+
 Goal: classify every remaining device on the legacy CIA Via VLAN/SSID so we can make deliberate decisions during and after the cutover.
 
 Rules:
@@ -47,8 +52,8 @@ Use `kill` when all or most are true:
 - MyQ -> IoT VLAN 40
 - Samsung FamilyHub -> IoT VLAN 40
 - LG dryer -> IoT VLAN 40
-- doorbell -> Cameras VLAN 60
-- Protect chimes -> Cameras VLAN 60
+- doorbell -> Cameras VLAN 60 only if immediate validation is available
+- Protect chimes -> Cameras VLAN 60 only after explicit Protect-path validation; current known-good live state keeps them on Management/default `UniFi Wireless`
 
 ### Migrate later / careful handling
 - Google Home Mini -> IoT VLAN 40 after discovery testing
@@ -114,7 +119,7 @@ If answers are bad, it does not earn migration tomorrow.
 
 ### Protect chimes / doorbell
 - These are not Legacy CIA end-state residents.
-- Move to Cameras/Security as early cleanup.
+- Treat Cameras/Security as the target design, not an automatic next action. The Wi-Fi chimes currently have a documented Management/default-SSID exception because the Camera override broke Protect health.
 
 ### old bulbs / old plugs
 - If still useful but irrecoverable, quarantine.

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
 

home/doris-dashboard/docs/network-cutover-minute-checklist.md

@@ -2,6 +2,11 @@
 
 > For Doris: this is the live change-window script. Use it like a pilot checklist, not a brainstorming prompt.
 
+Historical status note:
+- this file is a 2026-05-22 cutover script, not the current remaining-work checklist
+- do not treat unchecked boxes or "tomorrow" phrasing here 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 redesign tomorrow with deliberate pauses, validation after every block of changes, and clean rollback points.
 
 Assumptions:
@@ -83,7 +88,7 @@ Stop/go check:
 - [ ] Confirm UDM, switches, and APs are mapped to Management intent.
 - [ ] Remove obvious non-infrastructure devices from Management.
 - [ ] Identify any stragglers remaining in Management and list them.
-- [ ] If Security lane is ready, prepare to move chimes immediately.
+- [ ] If revisiting Protect accessory placement, first confirm the documented chime Management exception and only move them during explicit Protect validation.
 
 Validation:
 - [ ] UniFi still sees gateway, switches, APs.
@@ -97,9 +102,9 @@ Rollback trigger:
 
 - [ ] Activate/validate Cameras VLAN 60.
 - [ ] Activate Security SSID if needed.
-- [ ] Move Protect chimes.
-- [ ] Move doorbell if ready.
-- [ ] Confirm no security devices remain polluting Management.
+- [ ] Move Protect chimes only if Protect health is validated during the move.
+- [ ] Move doorbell only if immediate post-move validation is available.
+- [ ] Confirm any remaining security-device Management exception is documented explicitly.
 
 Validation:
 - [ ] device rejoins expected lane
@@ -107,7 +112,7 @@ Validation:
 - [ ] no broad emergency rules added yet
 
 Rollback trigger:
-- [ ] If doorbell/chimes become unrecoverable fast, revert that device only.
+- [ ] If doorbell/chimes become unrecoverable fast, revert that device only; for the Wi-Fi chimes, clearing the Camera override and returning to Management/default `UniFi Wireless` is the known-good rollback.
 
 ## Minute 50-75: move core servers to Servers VLAN 30
 

home/doris-dashboard/docs/network-cutover-red-team-card.md

@@ -2,6 +2,10 @@
 
 Use this during the live window when your brain gets dumb.
 
+Historical status note:
+- this card belongs to the 2026-05-22 cutover-planning wave
+- keep it as operator evidence, but do not treat it as the current backlog without checking later migration result docs
+
 Goal:
 - make one clean change
 - validate it

home/doris-dashboard/docs/network-migration-remaining-checklist-2026-05-22.md

@@ -2,10 +2,14 @@
 
 Current intent: only safe, low-drama follow-up work remains. The easy-value client cleanup already completed should not be re-run.
 
+Current truth note:
+- use this file plus `unifi-protect-doorbell-chime-current-state-2026-05-26.md` as the source of truth for what is actually still pending
+- treat earlier cutover-prep docs with "tomorrow" language as historical planning artifacts unless they were explicitly updated later
+
 ## Already completed
 - Servers network/profile exists in UniFi
-- Protect WiFi Chime `upstairs landing` moved from Management -> Camera
-- Protect WiFi Chime `Living Room` moved from Management -> Camera
+- Historical attempt moved both Protect WiFi chimes from Management -> Camera, but that change was later reversed after Protect health failed on the Camera-lane override
+- Current known-good state keeps both Protect WiFi chimes on Management / default `UniFi Wireless`; see `unifi-protect-doorbell-chime-current-state-2026-05-26.md`
 - `LG_Smart_Laundry2_open` moved from Trusted -> IoT
 - `MyQ-29B` moved from Old IoT -> IoT
 - `LG_Smart_Dryer2_open` moved from Old IoT -> IoT
@@ -28,6 +32,7 @@ Current intent: only safe, low-drama follow-up work remains. The easy-value clie
    - keep unknown Legacy CIA devices explicitly quarantine-first
    - Trusted-lane Intellirocks cleanup is now resolved separately; see `intellirocks-triage-result-2026-05-23.md`
    - Legacy CIA leftovers are now dispositioned separately; see `unifi-legacy-cia-closeout-2026-05-23.md`
+   - Protect chime lane cleanup is intentionally deferred until Protect connectivity is explicitly re-validated on a non-Management lane
 
 3. Non-disruptive firewall planning cleanup
    - compare staged firewall objects/policies against desired rule order
@@ -96,6 +101,7 @@ Important distinction:
 - final validation sweep
 - confirm no temporary panic exceptions remain
 - document any intentionally deferred weird devices
+- keep the Protect doorbell/chime exception documented until a future validated lane migration replaces it
 
 ## Suggested execution order from here
 1. Wait for laptop session

home/doris-dashboard/docs/network-redesign-implementation-runbook.md

@@ -2,6 +2,11 @@
 
 > For Doris: use this during the live UniFi change window. Goal is a controlled cutover with explicit validation and rollback at each boundary.
 
+Historical status note:
+- this runbook came from the 2026-05-22 cutover-planning wave
+- preserve it as the detailed plan, but do not treat every "tomorrow" step as still pending without checking later result docs
+- current remaining-work truth lives in `network-migration-remaining-checklist-2026-05-22.md` and `unifi-protect-doorbell-chime-current-state-2026-05-26.md`
+
 Goal: deploy the target VLAN/SSID/firewall design with minimum drama, keep legacy CIA Via as a quarantine lane for devices that cannot yet be migrated, and finish the window with an understandable, supportable network.
 
 Architecture summary:
@@ -258,7 +263,7 @@ Exit criteria:
 ### Phase C: Management cleanup first
 1. Ensure UDM, switches, and AP management surfaces are on VLAN 10 intent.
 2. Remove obvious non-infrastructure devices from Management.
-3. Move Protect chimes out of Management as top cleanup item if Security lane is ready.
+3. Treat Protect chimes as a documented temporary Management exception unless you are explicitly re-validating their Protect health on a non-Management lane.
 4. Re-validate UniFi visibility of gateway, switches, APs.
 
 Rollback if:
@@ -272,14 +277,14 @@ Exit criteria:
 ### Phase D: Build/activate Cameras lane
 1. Activate/validate `NET-CAMERAS`.
 2. Activate `Security` SSID if used.
-3. Move doorbell and Protect chimes to Cameras/Security.
+3. Move doorbell and Protect chimes to Cameras/Security only if Protect health is explicitly validated during the move.
 4. Validate app/admin behavior.
 
 Rollback if:
 - security devices fall offline and cannot be recovered quickly
 
 Exit criteria:
-- doorbell/chimes are no longer polluting Management
+- either doorbell/chimes are healthy on Cameras/Security, or the documented Management exception is preserved intentionally
 - Camera lane exists for future growth
 
 ### Phase E: Move core servers to Servers VLAN 30
@@ -353,8 +358,8 @@ Exit criteria:
 ## 9. Explicit Device Triage
 
 Move tomorrow if practical:
-- Protect chimes
-- doorbell
+- Protect chimes only during an explicit Protect-validation test
+- doorbell only if healthy-state validation is immediate and reversible
 - PD
 - Serenity
 - Nomad
@@ -403,6 +408,7 @@ Minimum successful tomorrow outcome:
 - IoT lane exists and at least easy-value devices are moved
 - Legacy CIA is converted into explicit quarantine/sunset lane
 - no broad insecure exceptions were added out of fatigue
+- any documented temporary Protect chime exception is written down instead of being rediscovered later
 
 Nice-to-have, not mandatory tomorrow:
 - U6 LR restored and tuned

home/doris-dashboard/docs/network-redesign-plan.md

@@ -49,6 +49,11 @@ Architecture summary:
 - Contains: doorbell, Protect chimes, future cameras, NVR-adjacent accessories, security-specific Wi-Fi endpoints
 - Policy: no broad access to LAN; only specific flows to Protect/NVR services and operator/admin clients
 
+Current live exception:
+- this is still the target design, not the currently proven-safe lane for every Protect accessory
+- a 2026-05-22 client-override attempt put the Wi-Fi chimes on the Camera lane, but they later had to be returned to Management/default `UniFi Wireless` because Protect health failed there
+- future camera/security-lane work must preserve this documented exception until Protect connectivity is explicitly re-validated
+
 ## SSID Plan
 
 Preferred steady-state SSIDs:
@@ -107,7 +112,7 @@ IoT / Smart Home:
 
 Cameras / Security:
 - front-doorbell
-- Protect chimes
+- Protect chimes (target design; current live exception keeps the Wi-Fi chimes on Management/default `UniFi Wireless` until Protect validation exists on the security lane)
 - future wired/PoE cameras
 - future Wi-Fi security accessories
 
@@ -176,7 +181,7 @@ Phase 2: servers
 - update DNS/static mappings/firewall rules
 
 Phase 3: cameras/security
-- move doorbell and chimes to VLAN 60
+- move doorbell and chimes to VLAN 60 only after explicit Protect-path validation proves that the Wi-Fi chimes stay healthy there
 - prepare room for future camera growth
 
 Phase 4: IoT migration

home/doris-dashboard/docs/old-iot-tomorrow-disposition-list.md

@@ -2,6 +2,10 @@
 
 > For Doris: this is the concrete disposition call for every current live Old IoT client seen during read-only recon. This is the list to use tomorrow unless live validation proves otherwise.
 
+Historical status note:
+- this is a 2026-05-22 planning artifact
+- several "tomorrow" items here were completed later; do not use this file as the current backlog without checking `network-migration-remaining-checklist-2026-05-22.md`
+
 Source basis:
 - live UniFi read-only recon on 2026-05-22
 - all devices listed were active on SSID `CIA Via` through the `U7 Pro`

home/doris-dashboard/docs/unifi-client-cleanup-shortlist-2026-05-22.md

@@ -1,5 +1,7 @@
 # UniFi Client Cleanup Shortlist
 
+Status note: this file started as a live shortlist on 2026-05-22. Most of the appliance/thermostat cleanup in here is completed. For the current Protect doorbell/chime truth, do not rely on the original chime recommendation below without also reading `unifi-protect-doorbell-chime-current-state-2026-05-26.md`.
+
 Live basis:
 - Captured from PD with `python3 automation/bin/unifi_network.py --raw`
 - Capture time: 2026-05-22 21:45:20 UTC
@@ -40,8 +42,8 @@ These are the clearest remaining misclassifications, and the smart-appliance tar
   - Why: vendor-family clustering strongly suggests it belongs with the other low-trust embedded devices, not with human/operator endpoints.
   - Caution: identify before moving if possible; if unknown, do not promote it by leaving it in Trusted.
 
-## Management offenders
-These are now identified and should not remain on Management.
+## Management offenders (historical identification, but not current next-step guidance)
+These were correctly identified on 2026-05-22, but the original recommendation to re-home them immediately to `Camera` / security is no longer the standing advice.
 
 - `58:d6:1f:54:e5:6d` (`10.5.0.123`, hostname `espressif`)
   - Identified as: UniFi Protect WiFi Chime
@@ -56,7 +58,9 @@ These are now identified and should not remain on Management.
 Notes:
 - Both are Wi-Fi clients on `UniFi Wireless`.
 - UniFi fingerprint metadata reports `product_line=unifi-protect` and `product_model=Protect WiFi Chime`.
-- This means they are not mystery ESP junk anymore; they are known Protect accessories that should be treated like camera/security estate, not management-plane clients.
+- This means they are not mystery ESP junk anymore; they are known Protect accessories.
+- Current known-good live state keeps them on Management/default `UniFi Wireless` because the Camera-lane override caused them to show offline in Protect.
+- Do not re-home these two chimes again unless Protect connectivity is explicitly validated during the move.
 
 ## Old IoT move-now set
 These still look like the cleanest deliberate moves from `CIA Via` into `IoT`.
@@ -88,7 +92,7 @@ Leave these in legacy quarantine unless/until they are identified better.
 If doing a low-drama cleanup pass, use this order:
 
 1. Move `LG_Smart_Laundry2_open` out of `Trusted` into `IoT`
-2. Re-home the two identified Protect chimes out of `Management` into `Camera` / security
+2. Leave the two identified Protect chimes on their current known-good Management/default-SSID path unless you are doing an explicit Protect-validation test
 3. Migrate the approved Old IoT move-now set into `IoT`, one app-validated batch at a time
 4. Leave Google/cast-class gear for later unless everything else is stable
 5. Keep unknown leftovers quarantined; do not “clean them up” by granting `Trusted`
@@ -98,5 +102,5 @@ The clearest remaining lane problems are now:
 - one approved LG appliance still sitting in `Trusted`
 - one likely Google cast/display-class client in `Trusted`
 - one likely Intellirocks smart-home client in `Trusted`
-- two now-identified Protect chimes still sitting in `Management`
+- the Protect chimes are a documented temporary exception, not a rediscovery task
 - the approved appliance/thermostat/MyQ devices still lingering in `Old IoT`

home/doris-dashboard/docs/unifi-client-rehome-results-2026-05-22.md

@@ -1,13 +1,15 @@
 # UniFi Client Rehome Results
 
+Historical execution note: this file records what was applied on 2026-05-22, not the final lasting truth for every device. For the current known-good Protect doorbell/chime state, see `unifi-protect-doorbell-chime-current-state-2026-05-26.md`.
+
 Executed from PD against the live UniFi controller using per-client virtual network overrides plus targeted `kick-sta` reconnects.
 
-## Requested changes completed
+## Requested changes applied on 2026-05-22
 
 ### Trusted -> IoT
 - `LG_Smart_Laundry2_open` (`60:ab:14:5f:b4:ba`) -> `IoT` -> `10.5.10.141`
 
-### Management -> Camera
+### Management -> Camera (historical attempt; later reverted for the chimes)
 - Protect WiFi Chime `upstairs landing` (`58:d6:1f:54:e5:6d`) -> `Camera` -> `10.5.20.191`
 - Protect WiFi Chime `Living Room` (`58:d6:1f:54:e5:af`) -> `Camera` -> `10.5.20.8`
 
@@ -18,11 +20,23 @@ Executed from PD against the live UniFi controller using per-client virtual netw
 - `Main-Floor` ecobee (`44:61:32:1d:ee:8f`) -> `IoT` -> `10.5.10.160`
 - `Upstairs` ecobee (`44:61:32:3f:0b:4c`) -> `IoT` -> `10.5.10.64`
 
-## Validation result
-All 8 targeted clients were re-read live from `stat/sta` and matched their intended target lanes.
+## Validation result at the time
+All 8 targeted clients were re-read live from `stat/sta` and matched their intended target lanes during the 2026-05-22 apply window.
+
+Important caveat:
+- lane placement success in UniFi Network did not prove Protect health for the chimes
+- a later follow-up showed the two chimes could appear associated in UniFi Network while still showing offline in Protect
+
+## Follow-up result that supersedes the chime portion
+
+Later known-good state:
+- Protect WiFi Chime `upstairs landing` was returned to `Management` / default `UniFi Wireless` -> `10.5.0.123`
+- Protect WiFi Chime `Living Room` was returned to `Management` / default `UniFi Wireless` -> `10.5.0.189`
+- the Camera-lane virtual-network override for the chimes should now be treated as a failed experiment in this environment, not as the standing recommendation
 
 ## Notes
 - Rehome mechanism used: `PUT /rest/user/<id>` with `network_id`, `virtual_network_override_enabled=true`, and `virtual_network_override_id=<target_network_id>`
 - Reconnect mechanism used: `POST /cmd/stamgr` with `cmd=kick-sta`
 - `LG_Smart_Laundry2_open` had a temporary probe note during discovery; it was cleared during the live apply
 - Some clients still show their original SSID names in UniFi telemetry even after landing on the target virtual network override; the authoritative validation point for this pass was the live `network` / `network_id` state
+- The Protect lesson learned here is specific and important: a client can look correctly placed in UniFi Network while still being unhealthy in Protect.

home/doris-dashboard/docs/unifi-live-preflight-snapshot-2026-05-22.md

@@ -1,5 +1,10 @@
 # UniFi Live Preflight Snapshot
 
+Historical snapshot note:
+- this file is a dated preflight capture from 2026-05-22
+- preserve it as evidence, but do not treat it as the current source of truth for remaining work or final device placement
+- later results and reversals are documented in `network-migration-remaining-checklist-2026-05-22.md` and `unifi-protect-doorbell-chime-current-state-2026-05-26.md`
+
 Date: 2026-05-22
 Mode: read-only live pull from PD using the Doris UniFi operator account
 Controller: `https://10.5.0.1`
@@ -82,7 +87,7 @@ Interpretation:
 - `58:d6:1f:54:e5:6d` -> `10.5.0.123`
 - `58:d6:1f:54:e5:af` -> `10.5.0.189`
 
-These are still the two management-lane ESP-class offenders to identify or evict.
+Historical interpretation only: these were later identified as the two Protect WiFi chimes, so this section is evidence of the pre-identification state, not an open rediscovery task.
 
 ## Fresh anomalies vs the earlier planning assumptions
 

home/doris-dashboard/docs/unifi-protect-doorbell-chime-current-state-2026-05-26.md

@@ -0,0 +1,60 @@
+# UniFi Protect Doorbell / Chime Current State — 2026-05-26
+
+Purpose: capture the current known-good state for the adopted doorbell and the two Protect WiFi chimes so future cleanup work does not accidentally re-run a reverted change.
+
+## Status summary
+
+Current known-good state:
+- `front-doorbell` remains the Protect doorbell endpoint
+- Protect WiFi Chime `upstairs landing` is intentionally on `Management` / default `UniFi Wireless`
+- Protect WiFi Chime `Living Room` is intentionally on `Management` / default `UniFi Wireless`
+- per-client Camera virtual-network overrides for the chimes should remain disabled unless a later validation proves a safe Protect path on the Camera/Security lane
+
+Current chime IPs from the last known-good state:
+- `upstairs landing` -> `10.5.0.123`
+- `Living Room` -> `10.5.0.189`
+
+## What changed from the earlier migration notes
+
+Historical 2026-05-22 action:
+- both chimes were moved from `Management` to `Camera` using per-client virtual network overrides
+- UniFi Network showed them associated on the target lane
+
+Why that is not the source of truth anymore:
+- in this environment, the Camera-lane override made the chimes show offline in Protect even though UniFi Network still showed them connected
+- the working fix was to remove the Camera override and let the chimes return to the known-good Management/default-SSID path
+
+Operational conclusion:
+- treat the 2026-05-22 chime move as a historical experiment, not a standing recommendation
+- do not re-home the chimes to `Camera` / `Security` as routine cleanup without fresh Protect validation
+
+## Doorbell adoption note
+
+After a doorbell is re-adopted:
+- verify the chimes are still logically bound to the current adopted doorbell object
+- if chime ringing breaks even though the devices are online, check whether each chime's `ringSettings.cameraId` still points at the old doorbell object instead of the current adopted one
+
+This is separate from the network-lane issue:
+- network-lane failure symptom: chime looks connected in UniFi Network but offline in Protect
+- adoption-binding failure symptom: doorbell is adopted and devices are online, but the chimes do not ring for the current doorbell object
+
+## Future-state intent versus current safe state
+
+Long-term design intent still favors a dedicated Camera/Security lane and SSID for Protect accessories.
+
+Current safe live state is narrower:
+- doorbell can stay where it is if healthy
+- chimes stay on Management/default `UniFi Wireless` until Protect connectivity is explicitly re-validated on the Camera/Security lane
+- future migration is blocked on proving the required Protect path, not on re-discovering the device identities
+
+## Files that were updated to reflect this
+
+Key current-truth docs:
+- `network-migration-remaining-checklist-2026-05-22.md`
+- `unifi-client-cleanup-shortlist-2026-05-22.md`
+- `unifi-client-rehome-results-2026-05-22.md`
+- `unifi-ssid-cleanup-proposal-2026-05-23.md`
+- `network-redesign-plan.md`
+- `network-redesign-implementation-runbook.md`
+
+Historical planning/snapshot docs were also marked so they are not mistaken for current next-step instructions.

home/doris-dashboard/docs/unifi-readonly-recon-2026-05-22.md

@@ -1,5 +1,10 @@
 # UniFi Read-Only Recon Notes
 
+Historical snapshot note:
+- this file records the 2026-05-22 read-only discovery pass
+- preserve it as evidence, but do not use it as the current next-step checklist without checking later outcome docs
+- later results and reversals are documented in `network-migration-remaining-checklist-2026-05-22.md` and `unifi-protect-doorbell-chime-current-state-2026-05-26.md`
+
 Date: 2026-05-22
 Mode: read-only only
 Auth status: verified working with upgraded Doris admin login
@@ -79,9 +84,9 @@ Likely quarantine until identified better:
 ### 6. Camera lane live state
 - `front-doorbell` is already on Camera network at `10.5.20.217`
 
-Interpretation:
-- the doorbell is already where it belongs logically
-- tomorrow’s security cleanup work is mainly about chimes and future policy tightening
+Interpretation at the time:
+- the doorbell was already in the expected camera lane during this snapshot
+- later follow-up changed the chime guidance, so do not treat this paragraph as the final remaining-work instruction set
 
 ### 7. Trusted lane still carrying infrastructure-class hosts
 Trusted currently includes:
@@ -131,8 +136,8 @@ Interpretation:
 - Rocinante needs a quick extra look because the client is live on port 2 but that port did not show an explicit profile name in the returned record
 
 ## Recommended next actions for tomorrow
-1. identify the two Management `espressif` devices before or during the window
+1. historical note: the two Management `espressif` devices were later identified as Protect WiFi chimes; do not treat this as an open rediscovery task
 2. move/changeprofile for server ports on the USW Pro HD 24 one at a time
 3. treat Google devices as late-batch or defer
 4. treat unknown Old IoT clients as quarantine by default, not migration by default
-5. keep Camera cleanup focused on chimes and policy, because the doorbell is already in the correct lane
+5. keep Camera cleanup focused on validated policy and documented exceptions; the doorbell was already in the correct lane during this snapshot, but later chime guidance changed

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:

home/doris-dashboard/docs/usw-pro-hd-24-cutover-port-sheet.md

@@ -2,6 +2,10 @@
 
 > For Doris: this is the mechanical switch-port sheet for tomorrow. Do not freestyle. Change one thing, validate, then continue.
 
+Historical status note:
+- this is a 2026-05-22 cutover sheet, preserved as evidence of the original plan
+- do not treat its "tomorrow" wording as active backlog without checking later migration result docs
+
 Source basis:
 - live UniFi read-only recon on 2026-05-22
 - /home/fizzlepoof/repos/truenas-stacks/home/doris-dashboard/docs/unifi-readonly-recon-2026-05-22.md