Multi-bridge: master tracking epic

[tashda]

Context

A user runs more than one Zigbee2MQTT instance (separate coordinators, separate networks) and wants Shellbee to manage both from a single app. Today the entire app is hard-wired to a single bridge: one WebSocket client, one AppStore keyed only by friendly-name/IEEE, one ConnectionConfig slot, one Live Activity per coordinator, and ~50 UI surfaces that read environment.store.* with no concept of "which bridge".

This epic tracks the work, split into two phases. The full plan with file-level analysis lives at /Users/k/.claude/plans/please-make-detailed-github-zesty-umbrella.md (local-only) and is mirrored into the sub-issue bodies.

Two-phase rollout

Phase 1 — Saved Bridges + Switcher (milestone v1.6.0, ~2 weeks)

Reuse the existing single-bridge UI verbatim. Add a list of saved bridges, a switcher, one-tap reconnect. No store changes. Solves ~60% of user intent with no architectural surgery.

• Multi-bridge Phase 1.1: Promote ConnectionHistory into SavedBridges model #62 — 1.1: Promote ConnectionHistory into SavedBridges model
• Multi-bridge Phase 1.2: Saved Bridges screen in Settings #63 — 1.2: Saved Bridges screen in Settings
• Multi-bridge Phase 1.3: Bridge switcher in toolbar #64 — 1.3: Bridge switcher in toolbar
• Multi-bridge Phase 1.4: Audit AppStore.reset for cross-bridge leakage #65 — 1.4: Audit AppStore.reset for cross-bridge leakage
• Multi-bridge Phase 1.5: Connection Live Activity carries bridge name #66 — 1.5: Connection Live Activity carries bridge name
• Multi-bridge Phase 1.6: Test-center extension for dual-bridge fixtures #67 — 1.6: Test-center extension for dual-bridge fixtures
• Multi-bridge Phase 1.7: Polish — empty states, connect-failure UX, Keychain edges #68 — 1.7: Polish — empty states, connect-failure UX, Keychain edges

Phase 2 — True Simultaneous Multi-Bridge (milestone v2.0.0, ~4–6 weeks)

Re-key the entire store by BridgeID. Run N concurrent connections. Surface a per-bridge dimension in every UI screen. Multi Live Activities. Gated on Phase 1 ship + user demand confirmation.

• Multi-bridge Phase 2.1: Introduce BridgeID type and BridgeConnectionRegistry #69 — 2.1: Introduce BridgeID type and BridgeConnectionRegistry
• Multi-bridge Phase 2.2: Re-key AppStore by BridgeID #70 — 2.2: Re-key AppStore by BridgeID
• Multi-bridge Phase 2.3: Update every UI consumer to specify bridge #71 — 2.3: Update every UI consumer to specify bridge
• Multi-bridge Phase 2.4: Merged Home with per-bridge sections #72 — 2.4: Merged Home with per-bridge sections
• Multi-bridge Phase 2.5: Per-bridge Live Activities #73 — 2.5: Per-bridge Live Activities
• Multi-bridge Phase 2.6: Per-bridge OTABulkOperationQueue #74 — 2.6: Per-bridge OTABulkOperationQueue
• Notifications: per-bridge enable + mute toggle #75 — 2.7: Notifications — per-bridge enable + mute
• Multi-bridge Phase 2.8: Sentry/diagnostics enrichment with bridge name #76 — 2.8: Sentry/diagnostics enrichment with bridge name
• Multi-bridge Phase 2.9: Polish — filter chips, color picker, iPad, perf #77 — 2.9: Polish — filter chips, color picker, iPad, perf

Recommendation

Ship Phase 1, ship it on its own, and observe whether users actually need simultaneous (Phase 2) or whether fast-switching is sufficient. Phase 2 is a deep architectural change that should only be picked up if Phase 1 demand confirms it.

Critical files (master list)

See individual issues for per-issue file lists. High-level:

• Phase 1 touches: AppEnvironment.swift, ConnectionSessionController.swift, ConnectionConfig.swift, ConnectionHistory.swift, AppStore.swift (audit only), Connection Live Activity, new SavedBridgesView.swift, new BridgeSwitcherToolbarItem.swift, toolbars in HomeView/DeviceListView/GroupListView/LogsView, docker-compose.yml.
• Phase 2 touches: all of Phase 1 plus new BridgeConnectionRegistry.swift, full re-key of AppStore and all AppStore+*.swift, ~50 view files, all Live Activity coordinators/widgets, OTABulkOperationQueue, NotificationPreferences, Z2MEvent, Sentry/log layer.

[tashda]

Phase 1 (#62–#68) and most of Phase 2 (#69–#73, #76, #77, #81) shipped on dev as of f40a68a.

Remaining open: #74 (per-bridge OTABulkOperationQueue), #75 (per-bridge notification mute) — both deferred.

[tashda]

Both Phase 1 (saved bridges + switcher) and Phase 2 (concurrent multi-bridge) shipped in v1.6.0 (#82). Closing the epic. Two low-priority follow-ups remain open in v2.0.0: #74 (per-bridge OTABulkOperationQueue), #75 (per-bridge notification mute).