Apple Home: room edits fail on accessories from a previous pairing (SOLVED — document the remedy)

[simons-plugins]

Symptom

Exported accessories work (control fine, both directions) but Apple Home refuses to change their room. Reproduced across a plugin upgrade and a bridge-node upgrade; a newly exported device could be roomed normally, but once removed and re-added it too became stuck, landing in the bridge's own room.

Cause

Stale Apple-side accessory records. Room assignment lives entirely in the HomeKit/iCloud home database and never crosses Matter — no bridge-side change can cause or cure it. Apple matches returning accessories by UniqueID, which is derived from the Indigo device ID and is deliberately stable (that stability is what protects names/rooms across restarts — see XAC5).

Remedy (verified 2026-08-06)

1. Apple Home → the bridge → Remove Accessory.
2. Check the fabric count. Apple removes only one of its two fabrics this way — the iCloud Keychain one survives. matter.js documents this. Clear the leftover with Plugins ▸ Matter ▸ Unpair an Ecosystem… (it is also the last fabric, so the node factory-resets itself and clears its commissioning witness — expected).
3. Re-pair via Pair Matter Bridge…. The pairing code is unchanged (the identity file persists the passcode).
4. Rooms are editable again.

Cost: names, rooms, scenes and automations for exported accessories are lost, and a post-reset endpoint-number drift report is expected (matter.js's allocation is wiped while our map survives — the map is the witness, and Rebuild Matter Endpoint Map… adopts the live numbers).

To do

Replace docs/INSTALL.md's current "Observed and unexplained" troubleshooting row with this remedy, including the leftover-fabric step (the one people will miss) and the expected post-reset drift.

[simons-plugins]

XAC5 — reboot leg PASSED (2026-08-06)

Full jarvis reboot. The bridge LaunchAgent auto-started (pid 663, no plugin
intervention), the node came up on its persisted identity, and all four endpoints
returned at their exact numbers:

Client attached (plugin 2026.8.3), reconciling 4 endpoint(s)
Endpoint 287885105  (onOffLight)    added as number 3
Endpoint 459564566  (dimmableLight) added as number 2
Endpoint 1664427354 (onOffLight)    added as number 6
Endpoint 1736047509 (onOffLight)    added as number 4
Reconciled endpoints: 4 created, 0 updated, 0 recreated, 0 removed (4 live)

Out of creation order — the proof they were restored from persisted identity
rather than freshly allocated. The next attach reported 0 created, 4 updated,
i.e. recognised as existing.

XAC5 is therefore complete: identity survives a plugin reload, a bridge-node
restart, and a full Mac reboot.

Remaining on this tracker: the second admin (ADR-0007) and the IWS auth
posture decision.

Note the reboot also re-fired the known stale-entry drift line (indigo-459564566 expected 5, got 2), which will now appear on every attach until #140 is fixed —
that raises #140's priority.

[simons-plugins]

Second admin — ACHIEVED 2026-08-06 (Alexa)

The bridge was commissioned by Alexa alongside the existing Apple pairing. Three fabrics live simultaneously:

Fabric added: index 3 (3 total)     <- Alexa, b65d1100015d3e34
   existing: index 1 Apple Home — Clark Castle, index 2 Apple Keychain

Alexa established CASE sessions, discovered the bridged accessories and issued real commands against them. Multi-admin operation is therefore demonstrated — this is ADR-0007's requirement and it is met by a genuine third-party ecosystem rather than a second admin we own, which is stronger than the bar the ADR sets.

Caveat, tracked separately as #143: Alexa's commands reached the node and were accepted but did not reach the Indigo devices, and Alexa showed them as not responding. That is a control-path bug, not a commissioning or multi-fabric one. The pairing has since been removed by the user (removeFabric fabricIndex: 3).

Remaining on this tracker: the IWS auth posture decision for the pairing page. XAC5 (reboot) and the second admin are both now done.