feat(cli): account, rm -r and mkdir, Tab completion

account shows the account and does what the sign-up form and the Profile
page do: register (the passphrase floor and the hub's proof of work checked
here, the recovery key printed once), verify, change the passphrase, reset a
forgotten one, change the e-mail address, sign out everywhere, delete. A new
passphrase carries the copy of the account's keys each node keeps for
browsers first — opened under the old M, the same keys sealed under the new
one — and only then tells the hub; a refusal sets the copies back. A reset
restores them from the recovery copy. The connections that do it never make
keys nor ask for a device approval. This machine keeps the M it changed away
from, so a node out of reach is carried at its next connection; a copy under
an M it does not know is no longer rewritten, which locked the browsers out
after a passphrase changed elsewhere.

rm -r removes a folder and all it holds, from the node's operator key: the
files, then the folders deepest first, one confirmation that counts them.
mkdir makes folders, --parents the missing ones (not -p, the passphrase).

completion bash|powershell prints the script that makes Tab complete actions,
verbs, options and the paths of the groups this machine is signed in to,
cached two minutes; the deb and rpm packages install the bash one.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

1 files changed, 28 insertions, 4 deletions

diff --git a/docs/MESHBAY_DESIGN.md b/docs/MESHBAY_DESIGN.md
index ea1dab0..5325ac7 100644
--- a/docs/MESHBAY_DESIGN.md
+++ b/docs/MESHBAY_DESIGN.md
@@ -569,6 +569,13 @@ application needs no fallback: it holds its identities, keeps the new `M` aside
 until the hub has accepted the change, and re-seals a node's bundle the next time
 it connects to it — it records which key sealed each one. Every refresh-token
 family is revoked.
+The command-line client (`account passphrase`) carries each copy as a browser
+does — opened under the old `M`, the same keys sealed under the new one, never
+its own keys in their place — and sets them back if the hub then refuses. It
+keeps the `M` it changed away from, so a copy on a node that was out of reach is
+carried at its next connection there; a copy that opens under no `M` it knows is
+never rewritten, because it may be sealed under a passphrase set elsewhere and is
+then the one the browsers open.
 
 **Recovering a lost passphrase** splits into what each key can reach:
 
@@ -3024,9 +3031,9 @@ MSE string) fed to a source buffer, with the node holding one slot per viewer.
 ### 8.6 The command-line client
 
 `meshbay-cli` (`packages/meshbay-cli`) is a member's groups and files from a
-terminal: `login`, `logout`, `groups`, `invitations`, `join`, `decline`,
+terminal: `login`, `logout`, `account`, `groups`, `invitations`, `join`, `decline`,
 `leave`, `ls`, `search`, `get`, `stream`, `put`, `rm`, `chat`, `devices`, `trust`,
-`browser-access`, `help` (what `--help` prints), and with no argument an interactive two-pane view (Textual)
+`browser-access`, `mkdir`, `completion` (bash and PowerShell), `help` (what `--help` prints), and with no argument an interactive two-pane view (Textual)
 over the same library. It is not an operator tool — a node is administered
 through `meshbay-node` and its loopback API (§6.7) — and it plays nothing
 itself: `stream` hands a file to a media player. English only.
@@ -3103,7 +3110,24 @@ refusal by the node stops the stream (exit 5); Ctrl+C, or closing the player
 (§5.4): the node accepts the uploading account's devices and the operator's.
 The client checks the same rule against the index first (`uploader_id`, and the
 `role` the join result gives its key) and refuses the whole run, before asking
-anything, when one file falls outside it.
+anything, when one file falls outside it. `rm -r` takes a folder with all it
+holds: the files first, then the folders deepest first, each an empty
+`dir_delete` — the node never deletes recursively, and only its operator removes
+a folder — so the run is the operator's, a group's root is never in it, and the
+one confirmation counts every file and its size. `mkdir` is `dir_create`, which
+any member may send where the root is writable; `--parents`, not `-p`, which is
+the passphrase in every action.
+
+**Tab completion** asks `meshbay-cli __complete` for the word under the cursor:
+actions, verbs and options from the parser, and remote paths from the hub and
+the node for the account this machine remembers. It asks nothing — no
+passphrase, no device approval — and opens a node the way that never makes
+keys, as a passphrase change's connections do; what a group holds is cached two
+minutes, so Tab after Tab is instant. Anything that fails is no candidate.
+
+The join result names `operator` for a key whose account holds the node-wide
+operator row, whatever its row in the group says: the client offers what the
+node will accept, and the node still checks every admin operation's signature.
 
 **Browser access is the application's setting, kept per machine** (§3.7):
 `browser-access on` leaves a copy of the identity sealed under `M` on each node
@@ -3349,7 +3373,7 @@ each removable root. Entries from unavailable roots are filtered out.
 
 ### 9.6 Chat
 
-Messages, threads, attachments, and link previews (§6.5). The composer gates on the
+Messages, attachments, and link previews (§6.5). The composer gates on the
 connection having identified a device (§3.3) and on a writable root existing for
 attachments; the attachment directory is a single writable folder chosen by the
 operator, and the paperclip is disabled with a stated reason when it is not usable.