diff --git a/docs/PRODUCTION-MASTER-PLAN.md b/docs/PRODUCTION-MASTER-PLAN.md
index a2ac39f4..4f81e4e1 100644
--- a/docs/PRODUCTION-MASTER-PLAN.md
+++ b/docs/PRODUCTION-MASTER-PLAN.md
@@ -886,3 +886,21 @@ this match.
   generic failure. Pairs with workstream F's honest-progress/blocker UX.
 - Reference: the existing `package-install-prune-check` dependency descriptor (dependencies.rs:208)
   is the seam to make data-driven.
+
+## 10d. Mesh — Meshtastic MeshCore-parity (in the fleet binary; one open bug) (2026-06-26)
+
+**Status: shipped as commit `8fdb45e8` and now riding in the rolled fleet binary** (built into the
+#9 deploy from HEAD, sha `0060dcd6…`). The Meshtastic driver auto-provisions LoRa **region (EU_868)**
+and a shared **channel "archipelago"** via the official admin API (`set_config`=field34,
+`set_channel`=field33) — discovery, bidirectional RF, and **sending** are all verified on **.116 + .228**.
+Detail + history: [[project_meshtastic_parity]].
+
+**Open work (slot after WS-F #9–11, before/with multinode):**
+- **RECEIVED-message surfacing bug** — the running driver does **not** surface received messages
+  (`mesh.messages` stays `[]`) even though the radio physically receives them. An instrumentation
+  build was in flight to locate where the inbound packet is dropped between the radio serial/BLE read
+  and the `mesh.messages` store. This is the one blocker to closing MeshCore parity.
+- **.198 radio is bad** — won't persist config (needs a reflash) so it's not a usable mesh test node;
+  use .116/.228 for mesh verification.
+- Definition of done: a message sent from a MeshCore/Meshtastic peer on channel "archipelago" appears
+  in `mesh.messages` on the receiving archipelago node, end-to-end, on ≥2 LAN nodes.