# UniFi SSID Cleanup Proposal — 2026-05-23

Purpose: turn the remaining SSID cleanup into an exact low-risk keep/retire proposal before any live Wi-Fi changes.

## Basis
Artifact-based planning only. No live SSID edits were made in this pass.

Artifacts used:
- `unifi-live-preflight-snapshot-2026-05-22.md`
- `unifi-readonly-recon-2026-05-22.md`
- `unifi-client-rehome-results-2026-05-22.md`
- `google-cast-pilot-result-2026-05-23.md`
- `unifi-legacy-cia-closeout-2026-05-23.md`
- `network-redesign-plan.md`
- `network-redesign-implementation-runbook.md`

## Current SSIDs seen in the last verified inventory
- `CIA Via` -> `Old IoT`
- `UNEF's Playhouse` -> `Camera`
- `Whiskey Neat Fuck Ice` -> `Trusted`
- `Yer a Wifi Harry` -> `Trusted`

## Steady-state target
Long-term, the network should converge on:
- one Trusted SSID
- one IoT SSID
- one Guest SSID
- one Security SSID
- no Legacy CIA SSID
- no duplicate Trusted SSIDs unless a real compatibility reason remains

## Exact keep / retire proposal

### 1) `Yer a Wifi Harry`
- Proposed role: `keep`
- Lane: `Trusted`
- Why:
  - already one of the two Trusted SSIDs
  - should become the single main human/operator SSID
  - keeping this as the surviving Trusted SSID lets the duplicate Trusted SSID be retired later without renaming everything at once
- Preconditions to call it final:
  - trusted phones/laptops are healthy here
  - no critical household endpoint still depends on the other Trusted SSID for compatibility

### 2) `Whiskey Neat Fuck Ice`
- Proposed role: `temporary keep, then retire`
- Lane: `Trusted`
- Why:
  - it is currently duplicate Trusted capacity, not a distinct policy lane
  - the Google/cast pilot device `dc:e5:5b:8f:57:d2` was previously on this SSID and successfully landed on `IoT` / `CIA Via` via override
  - duplicate Trusted SSIDs create policy ambiguity and make cleanup harder
- Retirement gate:
  - confirm all remaining clients on this SSID are either:
    - intentionally kept on Trusted and able to use `Yer a Wifi Harry`, or
    - moved off Trusted entirely
- Safe retirement method:
  1. inspect current client list on `Whiskey Neat Fuck Ice`
  2. migrate or test any stragglers onto `Yer a Wifi Harry`
  3. disable `Whiskey Neat Fuck Ice`
  4. verify admin path and key household endpoints still behave
  5. only then consider deletion later

### 3) `CIA Via`
- Proposed role: `temporary keep as quarantine/legacy bridge, then retire last`
- Lane: `Old IoT` / legacy quarantine
- Why:
  - recent verified artifacts still show it serving the remaining Google/discovery-sensitive devices and the unidentified quarantine leftovers
  - after the Google/cast pilot, the moved Google device reassociated and was seen on SSID `CIA Via` while logically landing on `IoT`; that means this SSID is still part of the current transition path and should not be yanked casually
  - the legacy closeout explicitly keeps six unidentified devices quarantined on `Old IoT`
- Retirement gate:
  - all intentionally kept devices have been moved to clean `IoT`, `Security`, or `Trusted` as appropriate
  - any unclaimed leftovers are either retired/killed or deliberately left for a later maintenance window
  - no household-critical Google/cast behavior still depends on this legacy SSID path
- Safe retirement method:
  1. complete human validation of the existing Google/cast pilot from a laptop
  2. decide whether more Google devices move to clean `IoT` now or stay deferred
  3. confirm the six quarantine leftovers are the only residents, or reduce further
  4. when `CIA Via` has no required clients left, disable it first
  5. observe for complaints / breakage
  6. delete only after a calm observation period

### 4) `UNEF's Playhouse`
- Proposed role: `keep`
- Lane: `Camera` / `Security`
- Why:
  - it is already mapped to the security lane
  - 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
  - no evidence that merging them into general IoT would be safer or simpler

### 5) Guest SSID
- Proposed role: `create or enable separately when ready`
- Why:
  - the target design calls for a true guest lane
  - the last verified enabled-SSID list did not show a guest Wi-Fi SSID even though the Guest network object exists
  - do not repurpose one of the current live SSIDs for Guest unless the live client list proves it is unused and the change window is calm
- Recommended approach:
  - treat Guest as a separate controlled add, not part of the first retirement move

## Recommended cleanup order
This is the safest order based on current evidence:

1. Keep `Yer a Wifi Harry` as the surviving main Trusted SSID
2. Keep `UNEF's Playhouse` as the Security SSID
3. Validate the existing Google/cast pilot from the laptop and decide whether more Google devices can leave legacy paths
4. Leave `CIA Via` alive until the legacy/quarantine path is truly drained
5. Retire `Whiskey Neat Fuck Ice` before retiring `CIA Via`
6. Only after `CIA Via` is empty and no longer required, disable and later delete it
7. Add/enable a proper Guest SSID as a separate tidy-up step if still missing

## Things not to do
- do not delete `CIA Via` just because the easy-value IoT devices already moved
- do not disable both Trusted SSIDs in the same change block
- 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

## Practical one-page operator version
If you want the shortest operator call:
- Keep now: `Yer a Wifi Harry`, `UNEF's Playhouse`, `CIA Via`
- Retire first: `Whiskey Neat Fuck Ice` once client list is clean
- Retire last: `CIA Via` only after Google/legacy drain is complete
- Add separately if needed: proper Guest SSID

## Resulting remaining live work
Before any actual SSID cleanup, still do:
- laptop-side Plex / cast / discovery validation for the existing Google pilot
- one last live SSID/client inventory pull from the controller
- a per-SSID client count check immediately before disable actions