diff --git a/.planning/phases/01-federation-mesh-hardening/01-04-SUMMARY.md b/.planning/phases/01-federation-mesh-hardening/01-04-SUMMARY.md
index b897a207..0c8af9a0 100644
--- a/.planning/phases/01-federation-mesh-hardening/01-04-SUMMARY.md
+++ b/.planning/phases/01-federation-mesh-hardening/01-04-SUMMARY.md
@@ -125,10 +125,29 @@ The mutation was reverted and its absence verified. This is stronger evidence th
 pre-implementation red run (which only shows the code is absent, not that the assertions bind),
 but it is a deviation from the ordering the plan asked for, and is recorded as one.
 
+## On-node verification (archi-dev-box, deployed 23:16)
+
+Deployed at commit `6b3693dc` off a clean tree and exercised over the real RPC surface:
+
+| Call | Result |
+|---|---|
+| `lnd.getinfo` | `identity_pubkey: 024a5fd7de13623aeec81095…` — a real key, deserialized by the field that did not exist before this plan. `alias: "Archipelago Node"` |
+| `mesh.lightning-peers` | `{"peers":[]}` — **success with an empty array**, not an error. The FED-05 empty edge, proven on hardware rather than only in a unit test |
+| `mesh.send-lightning-info` `{}` | refused: *"Missing contact_id: … requires an explicit target and has no broadcast form"* — T-01-13's mitigation observed live |
+| `mesh.send-lightning-info` with a target | refused: *"This node has no advertised Lightning URI to share — LND may be down, or configured with no externally reachable address"* |
+
+**A real finding from that last row:** this node's `lnd.getinfo` returns `uris: []`. Its LND has
+no externally reachable address configured, so it *cannot* advertise itself to a peer — the
+handler correctly refuses rather than sending an empty advertisement a peer would store as an
+undialable target. The receive and list halves work; the send half is inert on any node whose
+LND advertises no URI. **01-06 must not assume the local node can always share its own URI**,
+and the picker needs a sensible state for "you have nothing to share yet".
+
 ## Open / handed on
 
-- **Nothing here is exercised on hardware yet.** Two archy nodes with LND and a radio link are
-  needed to see a real advertisement traverse the mesh; every claim above is unit-level.
+- **The mesh leg is still unproven end to end.** Two archy nodes with LND and a radio link are
+  needed to watch a real advertisement traverse the air and land in a peer's `lightning_uri`.
+  Everything above is either unit-level or single-node RPC.
 - `mesh.lightning-peers` is a data source with no consumer until **01-06** builds the picker UI
   (which `depends_on` this plan).
 - `MeshPeer.lightning_uri`'s doc mentions federation seeding as a future source; this plan does