docs: remove private-ADR references from the public repo

CLAUDE.md

@@ -27,7 +27,7 @@ Domio (iOS, MatterSupport) ──commission+handoff──▶ indigo-matter ─
 ## Related projects
 
 - [`../domio-code/`](../domio-code/) — iOS app; owns commissioning. The Domio↔plugin HTTP contract is **`docs/API.md`** (mirrored in both repos; keep in sync).
-- Workspace **ADR-0006** (`domio-code/docs/adr/`, = workspace `docs/adr/0004`) — the Matter architecture decision (Apple TV TBR + matter-server + multi-admin handoff).
+- The Matter architecture decision (the **share model**: the user's existing ecosystem commissions as admin 1, the plugin joins as a second admin over IP, the ecosystem's hub is the Thread border router) is explained for users in [`docs/MATTER.md`](./docs/MATTER.md).
 
 ## Architecture (this plugin)
 

README.md

@@ -11,7 +11,7 @@ Indigo-owned Matter fabric, and translates Matter clusters ↔ Indigo device typ
 Domio (iOS) ──share code──▶ indigo-matter ──WebSocket──▶ matter-server ──IP──▶ Wi-Fi Matter devices
 ```
 
-Commissioning uses the **share model** (ADR-0006, "C4"): Apple Home commissions the
+Commissioning uses the **share model**: Apple Home commissions the
 device first, Domio relays a share/pairing code to the plugin, and the plugin joins the
 device's fabric as a second admin over IP. The plugin owns runtime control for the
 device's lifetime.

docs/HANDOVER.md

@@ -254,7 +254,7 @@ rsync -c "$SRC/Info.plist" "$DST/Info.plist"
 ### Read-only probe (run ON jarvis): `~/matter-probe.js`
 Dumps `server_info` + `get_nodes`/`get_node` + toggles. Run: `source ~/.nvm/nvm.sh; nvm use 22 >/dev/null; node ~/matter-probe.js`.
 
-## 5. Domio integration (share model — ADR-0006 C4) — CONFIRMED this session
+## 5. Domio integration (share model) — CONFIRMED this session
 
 Domio no longer commissions; it relays a **share code** (Apple Home is admin 1; the plugin joins as admin 2 over IP).
 

docs/INSTALL.md

@@ -27,7 +27,7 @@ A few things to know before you start:
 - **Domio drives commissioning.** You add devices from the **Domio iOS app**, not from
   Indigo. Apple Home commissions the device first; Domio relays a share/pairing code to
   the plugin, and the plugin joins the device's fabric as a second admin over IP (the
-  "share model", ADR-0006). The plugin owns runtime control for the device's lifetime.
+  "share model"). The plugin owns runtime control for the device's lifetime.
 - **matter-server is Alpha software.** Pin the version, back up the fabric, and expect
   occasional rough edges.
 

docs/MATTER.md

@@ -89,8 +89,8 @@ have BLE radios and (for Thread) the network credentials. A headless Mac
 running Indigo is a poor first commissioner: matter-server runs without BLE on
 macOS, and macOS has no Thread credential store.
 
-This plugin sidesteps the problem entirely with the **share model** (the
-architecture decision recorded as ADR-0006, option "C4"):
+This plugin sidesteps the problem entirely with the **share model** — the
+plugin's founding architecture decision:
 
 > An ecosystem you already own — Apple Home, or equally Alexa / Google Home —
 > commissions the device first: it owns the BLE step and gets the device onto
@@ -103,8 +103,9 @@ That's only possible because of Matter's best feature: multi-admin.
 
 A Matter **fabric** is a controller's trust domain — a set of cryptographic
 credentials a controller installs on a device. The crucial design choice in
-Matter is that **a device can belong to several fabrics at once** (typically
-5+). Each controller talks to the device directly and locally; none of them
+Matter is that **a device can belong to several fabrics at once**. The spec
+floor is five — and since each fabric slot costs the device persistent storage,
+the floor is also what most devices ship. Treat five as your planning number. Each controller talks to the device directly and locally; none of them
 knows or cares about the others.
 
 A single plug in this house happily serves four admins simultaneously: Apple
@@ -270,9 +271,12 @@ energy metering and battery merge into the primary device's states.
 
 ## Firmware updates (and why they matter more than usual)
 
-Matter devices typically receive firmware through their **vendor's app**, and
-vendors are still actively *adding Matter features* via firmware. Real
-example from this house: a Tapo P110M energy plug shipped exposing only on/off
+Matter firmware arrives by two routes: the device **vendor's app**, and the
+ecosystems themselves — those that act as Matter OTA providers push updates
+too (**Apple Home auto-updates Matter accessory firmware**; observed on this
+house's Tapo plug). The vendor app typically gets releases first, so check
+there when you're waiting on a feature. And vendors are still actively
+*adding Matter features* via firmware. Real example from this house: a Tapo P110M energy plug shipped exposing only on/off
 over Matter — the energy-measurement clusters (a Matter 1.3 feature) appeared
 only after a firmware update via the Tapo app. The plugin re-reads a node's
 capabilities whenever it rejoins, so the existing Indigo device **gained its
@@ -322,6 +326,5 @@ reversible.
 *Further reading:* [INSTALL.md](./INSTALL.md) (setup) ·
 [API.md](./API.md) (Domio ↔ plugin contract) ·
 [IMPLEMENTATION.md](./IMPLEMENTATION.md) (internals) ·
-ADR-0006 in the Domio repo (the architecture decision behind the share model) ·
 [Home Assistant's Matter docs](https://www.home-assistant.io/integrations/matter/)
 (an excellent ecosystem-neutral primer that inspired this page).

docs/PRD-indigo-matter-plugin.md

@@ -11,17 +11,17 @@
 > are stale — e.g. decommission is now `POST …?nodeId=`, not `DELETE`),
 > [`MATTER.md`](./MATTER.md) for architecture/landscape (incl. the corrected
 > Thread position), [`INSTALL.md`](./INSTALL.md) for setup, and
-> [`HANDOVER.md`](./HANDOVER.md) for current state. The ADR is **ADR-0006**
-> in the Domio repo (mirrored as workspace ADR-0004), not the 0001 path below.
+> [`HANDOVER.md`](./HANDOVER.md) for current state. The architecture decision
+> (the share model) is summarised in [`MATTER.md`](./MATTER.md), not the 0001 path below.
 >
 > Still genuinely pending from this PRD: **M11 — Plugin Store submission**,
 > and OQ4's "Indigo admin removed externally" detection beyond basic
 > availability tracking.
 
 **Status:** Historical — shipped (see banner)
 **Owner:** Simon
-**Related ADR:** ADR-0006 in the Domio repo (= workspace ADR-0004)
-**Companion PRD:** Domio Matter Commissioning (in Domio repo) — also shipped
+**Related ADR:** maintained privately; the decision is summarised in [`MATTER.md`](./MATTER.md)
+**Companion PRD:** Domio Matter Commissioning — also shipped
 **Last updated:** 2026-05-15 (content); 2026-06-10 (status banner)
 
 ## 1. Summary

docs/matter.html

@@ -117,12 +117,11 @@ <h2>Bluetooth, commissioning, and why this plugin needs neither</h2>
     BLE radios and, for Thread, the network credentials. A headless Mac running Indigo is a
     poor first commissioner — matter-server runs without BLE on macOS, and macOS has no Thread
     credential store.</p>
-    <p>This plugin sidesteps the problem entirely with the <strong>share model</strong> (the
-    architecture decision recorded as ADR-0006):</p>
+    <p>This plugin sidesteps the problem entirely with the <strong>share model</strong> —
+    the plugin’s founding architecture decision:</p>
     <div class="pull">An ecosystem you already own commissions the device first — it owns the
     Bluetooth step. Then the device is <em>shared</em> to Indigo over plain IP. Indigo never
-    needs BLE, Thread credentials, or proximity to the device.<small>ADR-0006 · the share
-    model</small></div>
+    needs BLE, Thread credentials, or proximity to the device.<small>The share model</small></div>
     <p>That’s only possible because of Matter’s best feature: multi-admin.</p>
   </div>
 </section>
@@ -133,7 +132,9 @@ <h2>Bluetooth, commissioning, and why this plugin needs neither</h2>
     <h2>Fabrics &amp; multi-admin: one device, many controllers</h2>
     <p>A Matter <strong>fabric</strong> is a controller’s trust domain — a set of cryptographic
     credentials a controller installs on a device. The crucial design choice in Matter is that
-    <strong>a device can belong to several fabrics at once</strong> (typically five or more).
+    <strong>a device can belong to several fabrics at once</strong>. The spec floor is
+    five — and since each fabric slot costs the device persistent storage, the floor is
+    also what most devices ship. Treat five as your planning number.
     Each controller talks to the device directly and locally; none of them knows or cares
     about the others.</p>
     <p>A single plug in this house happily serves four admins simultaneously:</p>
@@ -315,8 +316,12 @@ <h2>What’s supported</h2>
   <div class="sec-no">§ 10</div>
   <div class="sec-body">
     <h2>Firmware updates — they matter more than usual</h2>
-    <p>Matter devices typically receive firmware through their <strong>vendor’s app</strong>,
-    and vendors are still actively <em>adding Matter features</em> via firmware.</p>
+    <p>Matter firmware arrives by two routes: the device <strong>vendor’s app</strong>, and
+    the ecosystems themselves — those that act as Matter OTA providers push updates too
+    (<strong>Apple Home auto-updates Matter accessory firmware</strong>; observed on this
+    house’s Tapo plug). The vendor app typically gets releases first, so check there when
+    you’re waiting on a feature. And vendors are still actively <em>adding Matter
+    features</em> via firmware.</p>
     <div class="pull">A Tapo P110M shipped exposing only on/off over Matter. The energy
     clusters appeared after a firmware update — and the existing Indigo device gained its
     energy states automatically. No restart, no re-pairing.<small>Field note, this house,

indigo-matter.indigoPlugin/Contents/Info.plist

@@ -20,7 +20,7 @@
 	<key>IwsApiVersion</key>
 	<string>1.0.0</string>
 	<key>PluginVersion</key>
-	<string>2026.2.23</string>
+	<string>2026.2.24</string>
 	<key>ServerApiVersion</key>
 	<string>3.6</string>
 </dict>