From 95b16a23fc65984e0af73f41d10ee68da07bc52c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Alejandro=20Guti=C3=A9rrez?=
 <35082514+alezmad@users.noreply.github.com>
Date: Sat, 2 May 2026 22:59:33 +0100
Subject: [PATCH] docs(roadmap): mark v0.3.0 phase 3.5 (web encryption) shipped

---
 docs/roadmap.md | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/docs/roadmap.md b/docs/roadmap.md
index 6536134..8b1b19e 100644
--- a/docs/roadmap.md
+++ b/docs/roadmap.md
@@ -218,11 +218,15 @@ level, or wire claudemesh to messaging surfaces beyond Claude Code.
   30s background re-seal loop. Wire format: `<32-byte sender x25519
   pubkey> || crypto_box(topic_key)` so re-sealed copies decode like
   creator-sealed copies. *Shipped 2026-05-02 in CLI v1.8.0.*
-- **Per-topic encryption — phase 3.5 (web)** — browser-side persistent
-  ed25519 identity in IndexedDB + `POST /v1/me/peer-pubkey` sync +
-  web chat encrypt-on-send / decrypt-on-render. Web stays on v1
-  plaintext until this lands; the existing CLI re-seal loop will pick
-  up web members the moment they have a real pubkey.
+- **Per-topic encryption — phase 3.5 (web)** — browser-side
+  persistent ed25519 identity in IndexedDB +
+  `POST /v1/me/peer-pubkey` sync + web chat encrypt-on-send /
+  decrypt-on-render. The dashboard's throwaway pubkey is replaced on
+  first chat-panel mount with one whose secret the browser actually
+  holds; the existing CLI re-seal loop seals the topic key against
+  it within 30s. Composer shows `🔒 v0.3.0` when keyed and "waiting
+  for a CLI peer to share the topic key" while `not_sealed`.
+  *Shipped 2026-05-02.*
 - **v0.3.1 — topic message threading (reply-to)** — `topic_message`
   gains a self-FK `reply_to_id` column (migration 0027); REST `POST
   /v1/messages` and the WS `send` envelope accept `replyToId`; broker