claudemesh-cli 1.8.0 → 1.9.2

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "claudemesh-cli",
-  "version": "1.8.0",
+  "version": "1.9.2",
   "description": "Peer mesh for Claude Code sessions — CLI + MCP server.",
   "keywords": [
     "claude-code",

package/skills/claudemesh/SKILL.md

@@ -13,6 +13,34 @@ description: Use when the user asks to send a message to a peer Claude session,
 
 Respond IMMEDIATELY. Pause your current task, reply via `claudemesh send`, then resume. Read `from_name`, `mesh_slug`, and `priority` from the channel attributes. Reply by setting `<to>` to the sender's `from_name`. Do not ignore low-priority messages — acknowledge them briefly even if you defer action. If the channel meta contains `subtype: reminder`, this is a scheduled reminder you set yourself — act on it.
 
+### Channel attributes (everything you need to reply is in the push)
+
+The `<channel>` interrupt carries these attributes — no lookup needed:
+
+| Attribute | What it is |
+|---|---|
+| `from_name` | Sender's display name. **Use as `to` in your reply** for DMs. |
+| `from_pubkey` | Sender's session pubkey (hex). Stable per-session. |
+| `from_member_id` | Sender's stable mesh.member id. Survives display-name changes — the canonical id. |
+| `mesh_slug` | Mesh the message arrived on. Pass via `--mesh <slug>` if the parent isn't on the same mesh. |
+| `priority` | `now` / `next` / `low`. |
+| `message_id` | Server-side id of THIS message. **Pass to `--reply-to <id>` to thread your reply** in topic posts. |
+| `topic` | Set when the source is a topic post. Reply via `topic post <topic> --reply-to <message_id>`. |
+| `reply_to_id` | Set when the message itself is a reply to a previous one — render thread context. |
+
+**Reply patterns:**
+
+```bash
+# DM → use from_name as the target
+claudemesh send "<from_name>" "ack — looking now"
+
+# Topic reply → thread it onto the message you got
+claudemesh topic post "<topic>" "yep, looks good" --reply-to <message_id>
+
+# When the sender is on a different mesh you've joined
+claudemesh send "<from_name>" "..." --mesh "<mesh_slug>"
+```
+
 ## Performance model (warm vs cold path)
 
 If the parent Claude session was launched via `claudemesh launch`, an MCP push-pipe is running and holds the per-mesh WS connection. CLI invocations dial `~/.claudemesh/sockets/<mesh-slug>.sock` and reuse that warm connection (~200ms total round-trip including Node.js startup). If no push-pipe is running (cron, scripts, hooks fired outside a session), the CLI opens its own WS, which takes ~500-700ms cold. **You don't manage this** — every verb auto-detects and falls through.
@@ -52,15 +80,57 @@ claudemesh topic history deploys --limit 50              # fetch back-scroll
 claudemesh topic history deploys --before <msg-id>       # paginate older
 claudemesh topic read deploys                            # mark all as read
 
-# Send to a topic — same `send` verb, target starts with #
+# Send to a topic — same `send` verb, target starts with # (WS, v1 plaintext)
 claudemesh send "#deploys" "rolling out 1.5.1 to staging"
+
+# v1.7.0+: live tail in the terminal — backfill last N + then SSE forward.
+# Decrypts v2 messages on render. Runs a 30s re-seal loop while held.
+claudemesh topic tail deploys --limit 50
+
+# v1.8.0+: encrypted REST send (body_version 2). Falls back to v1
+# automatically for legacy unencrypted topics. --plaintext forces v1.
+claudemesh topic post deploys "rolling out, cc @Alexis stay around"
+
+# v1.9.0+: thread a reply onto a previous topic message. Accepts the
+# full id or an 8+ char prefix; resolved against recent history.
+claudemesh topic post deploys "yes — same here" --reply-to 7XtIeF7o
 ```
 
+In `topic tail` output, replies render with a `↳ in reply to <name>: "<snippet>"` line above the message and every row shows a short id tag (`#xxxxxxxx`) so you can copy-paste into `--reply-to`.
+
 When to use topics vs groups vs DM:
 - **DM** (`send <peer>`) — 1:1, ephemeral.
 - **Group** (`send "@frontend"`) — addresses everyone in a group; ephemeral; for coordinating teams.
 - **Topic** (`send "#deploys"`) — durable conversation room; for ongoing work threads, incident channels, build-status feeds.
 
+### `member` — mesh roster + online state (v1.7.0)
+
+Distinct from `peer list`: members shows the static roster (every joined member of a mesh, online or not), peers shows the live WS-connected sessions plus REST-active humans.
+
+```bash
+claudemesh member list                                   # everyone, with status dots
+claudemesh member list --online                          # only online
+claudemesh member list --mesh deploys --json
+```
+
+Status glyphs: `●` emerald = idle, `●` clay = working, `●` red = dnd, `○` dim = offline. `bot` tag appears on non-human members.
+
+### `notification` — recent @-mentions (v1.7.0)
+
+Server-side write-time fan-out from `mesh.notification` — one row per recipient per matching `@-mention`. Works for both v1 plaintext and v2 ciphertext (clients send the mention list explicitly on v2).
+
+```bash
+claudemesh notification list                             # last 24h, all mentions of you
+claudemesh notification list --since 2026-05-01T00:00Z   # incremental for polling
+claudemesh notification list --json                      # parseable
+```
+
+### Per-topic encryption (v0.3.0 / CLI 1.8.0)
+
+Topics created on or after CLI 1.8.0 generate a 32-byte XSalsa20-Poly1305 symmetric key sealed for each member via `crypto_box`. The broker holds ciphertext only. `topic post` encrypts; `topic tail` decrypts. The `🔒 v2` glyph in tail output marks ciphertext rounds. v1 plaintext topics keep working unchanged.
+
+When a new member joins an encrypted topic, they get a 404 from `GET /v1/topics/:name/key` until any holder re-seals for them. `topic tail` runs a 30s background loop that does the re-seal automatically while the tail is open. Otherwise the joiner waits for someone with the key to log in.
+
 ### `peer` — read connected peers + admin (kick / ban / verify)
 
 ```bash