memhouse 0.16.0 → 0.17.1

package/memhouse/share.js

@@ -0,0 +1,64 @@
+/**
+ * `memhouse share <user> [--only <scope>] [--revoke]` / `memhouse share --list`
+ *
+ * Full share is one statement: GRANT SELECT on the house. Partial share adds a ROW
+ * POLICY per room, so the grantee reads only the rows the scope allows.
+ *
+ * Why no permissive catch-all policy for everyone else, which is the obvious design:
+ * row policies are OR'd, so a `USING 1 TO ALL EXCEPT alice` policy silently overrides
+ * the NEXT scoped grantee's filter — measured, bob saw all 22,500 rows instead of his
+ * 1,860. It fails OPEN and it fails quietly. ClickHouse already answers this correctly
+ * through `users_without_row_policies_can_read_rows`: a reader with no policy on a table
+ * still sees every row. Verified against a non-superuser member owning its own house —
+ * owner and full-share grantees were both unaffected while a third user was scoped.
+ *
+ * That setting is server config, not a query setting, and its default has moved between
+ * versions. So `probePermissive()` measures the behaviour before the first policy is
+ * created rather than assuming it, and refuses when the server would blindfold everyone.
+ */
+
+/** Columns a scope may filter on, and the column each room spells time with. */
+const SCOPE_COLUMNS = {
+  session: { column: () => 'session_id', quote: true },
+  project: { column: () => 'project', quote: true },
+  folder: { column: () => 'folder', quote: true },
+  host: { column: () => 'host', quote: true },
+  source: { column: () => 'source', quote: true },
+  // `sessions` has no `ts`; its clock is `created_at`. One literal predicate cannot span
+  // the rooms, so time scopes render per room.
+  since: { column: (room) => (room === 'sessions' ? 'created_at' : 'ts'), op: '>=' },
+  until: { column: (room) => (room === 'sessions' ? 'created_at' : 'ts'), op: '<' },
+};
+
+/** `project=memhouse,since=2026-01-01` -> [{key, value}], rejecting anything unknown. */
+function parseScope(raw) {
+  const out = [];
+  for (const part of String(raw).split(',').map((s) => s.trim()).filter(Boolean)) {
+    const m = /^([a-z_]+)\s*=\s*(.+)$/.exec(part);
+    if (!m) throw new Error(`scope "${part}" is not <key>=<value>`);
+    const key = m[1].toLowerCase();
+    if (!SCOPE_COLUMNS[key]) {
+      throw new Error(`unknown scope key "${key}" — try: ${Object.keys(SCOPE_COLUMNS).join(', ')}`);
+    }
+    out.push({ key, value: m[2].trim() });
+  }
+  if (!out.length) throw new Error('--only was given nothing to scope on');
+  return out;
+}
+
+/** The WHERE-shaped predicate for one room. Values are escaped, never interpolated raw. */
+function scopePredicate(scope, room, sqlStr) {
+  return scope.map(({ key, value }) => {
+    const spec = SCOPE_COLUMNS[key];
+    const col = spec.column(room);
+    if (spec.op) return `${col} ${spec.op} parseDateTimeBestEffort(${sqlStr(value)})`;
+    return `${col} = ${sqlStr(value)}`;
+  }).join(' AND ');
+}
+
+/** Policy name for a grantee's room — predictable, so revoke can find every one. */
+function policyName(user, room) {
+  return `mh_share_${user}_${room}`;
+}
+
+module.exports = { SCOPE_COLUMNS, parseScope, scopePredicate, policyName };

package/memhouse/shipper/ship.js

@@ -63,6 +63,8 @@ const selfSnap = selfUpdate.snapshot(__filename);
 const {
   resolveRooms, READ_SETTINGS, ROOM_TYPES, META_TYPES, SCHEMA_VERSION, MEMBER_PIN,
   SUPPORTED_SCHEMAS, keyProblem,
+  sessionStatsStatements, sessionModelStatsStatements, sessionToolStatsStatements,
+  SESSION_STATS, MODEL_STATS, TOOL_STATS,
 } = require('../house/house');
 // Rooms plus the house's own record of itself. Every table the template declares, which
 // is what the column healer and the drift warning have to cover — a column added to
@@ -448,6 +450,36 @@ async function ensureSchema(client) {
       throw e;
     }
   }
+  // The precomputed rollups — additive, so they belong here and not in a migration (see
+  // migrate.js's rule). Three plain tables plus the refreshable views that fill them;
+  // the read layer probes for them at startup and falls back to the inline rollup when
+  // they are absent, so a denied CREATE here degrades to slow, never to wrong. Built from
+  // the SAME rollup text the read layer would otherwise run, so the two cannot drift.
+  const statStmts = [
+    ...sessionStatsStatements(rooms), ...sessionModelStatsStatements(rooms), ...sessionToolStatsStatements(rooms),
+  ];
+  for (const q of statStmts) {
+    try {
+      await client.command({
+        query: q,
+        // 26.x defaults the flag on; 25.x wants it stated. Query-scoped, like the
+        // text-index flag above.
+        clickhouse_settings: { async_insert: 0, allow_experimental_refreshable_materialized_view: 1 },
+      });
+    } catch (e) {
+      const m = e && e.message ? e.message : String(e);
+      if (/Not enough privileges|ACCESS_DENIED/i.test(m)) { denied++; continue; }
+      if (/ALREADY_EXISTS|already exists/i.test(m)) { continue; }
+      throw e;
+    }
+  }
+  // Kick the first population now rather than waiting for the schedule: a refreshable
+  // view's first refresh lands at its next interval boundary, and until then the read
+  // layer (correctly) ignores the empty table and runs the slow rollup. Best effort —
+  // the schedule gets there on its own, this just makes install/update fast at once.
+  for (const mv of [`${SESSION_STATS}_mv`, `${MODEL_STATS}_mv`, `${TOOL_STATS}_mv`]) {
+    try { await client.command({ query: `SYSTEM REFRESH VIEW ${mv}` }); } catch { /* no grant, or not there */ }
+  }
   if (denied) {
     console.error(`[memhouse] ${denied} schema statement(s) needed rights you do not hold — continuing with what you can do.`);
     console.error('[memhouse] creating or replacing a ROOM is the house owner\'s job; adding a missing COLUMN is not.');

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "memhouse",
-  "version": "0.16.0",
+  "version": "0.17.1",
   "description": "memhouse \u2014 agent conversation memory across 17 editors: parse-on-client shippers, a typed ClickHouse store with one set of rooms per member, kernel-agency install, and the agentlytics dashboard",
   "main": "bin/memhouse.js",
   "bin": {

package/memhouse/delivery/plugin/skills/ask/SKILL.md

@@ -1,131 +0,0 @@
----
-name: ask
-description: Answer a question FROM conversation memory — retrieve the relevant past sessions out of the memhouse ClickHouse store, read the actual transcripts, and synthesize an answer with citations. Use when the user asks something their past work already answered, e.g. "how did I fix X last time", "what approach did we settle on for Y", "why did we choose Z", "have I solved this error before", "what did the reviewer say about W". Also answers from a friend's house shared with you when they name it ("how did yigit fix X", "ask yigit's memory"). This is the retrieve-and-answer skill; /mem:search is find-the-session, /mem:sql is run-a-query.
-user-invocable: true
-argument-hint: "<question about past work>"
-allowed-tools: Bash
----
-
-# /mem:ask — answer from conversation memory
-
-Answer the user's question from what the house holds, not from what you assume. The
-house is the archive that OUTLIVES the transcripts on disk — Claude Code compacts and
-deletes local session files, so for anything older than ~30 days memhouse is the only
-place the answer still exists.
-
-The synthesis is yours; the store is not. memhouse itself runs no LLM anywhere in its
-write or read path — this skill retrieves rows and YOU read them. Never present a guess
-as a retrieval: if the house has nothing on the question, say so.
-
-## Connection
-
-**Never print this file or the variables in it.** No `cat "$MH_ENV"`, no `env | grep
-MEMHOUSE`, no `set -x` around these commands. Anything you print becomes part of a
-transcript that memhouse itself ships into the house.
-
-Credentials resolve as **flags > exported `MEMHOUSE_*` > `$MEMHOUSE_HOME/env`**
-(default `~/.memhouse/env`) — the same order the `memhouse` CLI uses:
-
-```bash
-MH_ENV="${MEMHOUSE_HOME:-$HOME/.memhouse}/env"
-_u=${MEMHOUSE_URL-}; _s=${MEMHOUSE_USER-}; _p=${MEMHOUSE_PASSWORD-}; _d=${MEMHOUSE_DB-}
-set -a; [ -f "$MH_ENV" ] && . "$MH_ENV"; set +a
-[ -n "$_u" ] && MEMHOUSE_URL=$_u; [ -n "$_s" ] && MEMHOUSE_USER=$_s
-[ -n "$_p" ] && MEMHOUSE_PASSWORD=$_p; [ -n "$_d" ] && MEMHOUSE_DB=$_d
-if [ -z "${MEMHOUSE_URL:-}" ] || [ -z "${MEMHOUSE_USER:-}" ]; then
-  echo "no memhouse house configured — nothing in $MH_ENV and no MEMHOUSE_URL/MEMHOUSE_USER set." >&2
-  echo "Run: memhouse install" >&2
-  exit 1
-fi
-
-curl -sS --fail-with-body --user "$MEMHOUSE_USER:${MEMHOUSE_PASSWORD:-}" \
-  --data-binary @- "$MEMHOUSE_URL/?database=${MEMHOUSE_DB:-$MEMHOUSE_USER}&final=1&join_use_nulls=1&readonly=1" <<'SQL'
-<the query>
-FORMAT JSONEachRow
-SQL
-```
-
-`readonly=1` is pinned on every request: this skill never writes.
-
-## Answering from another person's house (shared with you)
-
-The house is a ClickHouse database; a share is a read-only GRANT on it. When the user asks
-about a FRIEND's memory — "how did yigit fix X", "in yigit's house", "ask yigit's memory",
-"from yigit" — answer from THEIR house without changing your credentials:
-
-1. **Resolve the house.** `SHOW DATABASES` returns what your credential may read; a name
-   that is not `system` / `information_schema` / `default` and not your own `$MEMHOUSE_DB`
-   is a house shared with you. Match the named person to one; set `HOUSE=yigit`. With no
-   house named, `HOUSE=$MEMHOUSE_DB`.
-2. **Point the connection at it:** replace `database=${MEMHOUSE_DB:-$MEMHOUSE_USER}` with
-   `database=<HOUSE>` in the recipe above. The rooms (`messages`, `sessions`) resolve by
-   the connection's database, so retrieval, the transcript read, and the citation all run
-   against that house — leave the table names bare.
-3. **Cite the house.** Say whose memory the answer came from ("from yigit's house") so the
-   user never mistakes a friend's session for their own.
-4. **Read-only, thin by design.** A refused SELECT means the house was not shared with you
-   (or the share was revoked) — say so; never guess another database.
-
-## The method — retrieve, read, answer, cite
-
-**Escaping, before anything touches SQL.** Search terms, session ids and user ids are
-arbitrary text going inside single-quoted literals: escape backslashes then single
-quotes (`\` → `\\`, `'` → `\'`) in every value you splice in. A term like `O'Reilly`
-otherwise breaks the query — and crafted text could reshape it.
-
-**1. Extract search terms from the question.** Not the question verbatim — the terms
-that would appear in the ANSWER. "How did I fix the ClickHouse auth error?" → search
-`ClickHouse auth`, `Authentication failed`, `ACCESS_DENIED` — error strings beat
-paraphrases, identifiers beat prose. Run 2–3 term variants; the FTS columns are
-lowercased, so lowercase your needle.
-
-```sql
-SELECT session_id, any(folder) AS folder,
-       formatDateTime(max(ts), '%Y-%m-%d') AS day, count() AS hits,
-       substring(anyIf(text, positionCaseInsensitive(text, 'NEEDLE') > 0), 1, 300) AS sample
-FROM messages
-WHERE text_ngram LIKE '%needle%'
-GROUP BY session_id ORDER BY max(ts) DESC LIMIT 8
-```
-
-**2. Read the strongest sessions — the actual turns, not just the hit line.** Pull a
-window around the hits so you see the resolution, not the complaint:
-
-```sql
-SELECT seq, role, substring(text, 1, 2000) AS text
-FROM messages
-WHERE session_id = '<sid>' AND user_id = '<uid>'
-  AND seq BETWEEN <hit_seq - 3> AND <hit_seq + 12>
-ORDER BY seq
-```
-
-Join on `(session_id, user_id)` always — two housemates can collide on an
-adapter-local session id.
-
-**3. Answer, then cite.** Lead with the answer; under it list the sessions it came
-from — `session_id`, date, project — so the user can reopen one (`memhouse resume
-<session_id>` prints the command). Quote the decisive lines verbatim where the exact
-wording matters (error text, a command, a config value).
-
-**4. Nothing found is an answer too.** Say what you searched and where the house's
-coverage ends (`SELECT min(ts), max(ts), count() FROM messages`) rather than padding.
-
-## What can bite
-
-- **Rows can hold more than one PARSE of a session** (`origin`/`epoch` are in the key —
-  the house retains superseded parses instead of deleting them). Counts and rollups must
-  filter to the current epoch:
-  ```sql
-  WHERE origin != 'ship'
-     OR (session_id, user_id, epoch) IN (
-          SELECT session_id, user_id, max(epoch) FROM messages
-          WHERE origin = 'ship' GROUP BY session_id, user_id)
-  ```
-  For step 2's transcript reads, PREFER the filter as well — an unfiltered read of a
-  compacted session interleaves two parses. Drop it deliberately only when the question
-  is about what a session said BEFORE it was compacted; the superseded epochs are the
-  one place that content still exists.
-- **`text` is truncated at 50,000 chars** and tool args at 20,000 — a missing tail is
-  truncation, not absence.
-- The rollup (`sessions_v`) is a saved query, not a table — get it with
-  `memhouse sessions-query` if you need per-session totals.

package/memhouse/delivery/plugin/skills/hello/SKILL.md

@@ -1,121 +0,0 @@
----
-name: hello
-description: Introduce memhouse — what it is, what it remembers, and how to use it from here. Use when the user asks "what is memhouse", "what can my memory do", "how do I use this", invokes /mem:hello, or seems new to the memory system. Also the right first answer when another /mem skill fails because nothing is configured yet.
-user-invocable: true
-argument-hint: ""
-allowed-tools: Bash
----
-
-# /mem:hello — welcome to your memory
-
-**Invoking this skill IS the request. Give the introduction immediately — grounded in
-this machine's actual state, not hypotheticals. Nothing to clarify first.**
-
-## First: find out what state this machine is in
-
-RUN this yourself with the Bash tool — do not print it for the user to run, and do not
-show the env values it sources. Read its output, then write the introduction using the
-ACTUAL numbers it returns (interpolate them; never emit the literal "N sessions").
-
-```bash
-MH_ENV="${MEMHOUSE_HOME:-$HOME/.memhouse}/env"
-_u=${MEMHOUSE_URL-}; _s=${MEMHOUSE_USER-}; _p=${MEMHOUSE_PASSWORD-}; _d=${MEMHOUSE_DB-}
-set -a; [ -f "$MH_ENV" ] && . "$MH_ENV"; set +a
-[ -n "$_u" ] && MEMHOUSE_URL=$_u; [ -n "$_s" ] && MEMHOUSE_USER=$_s
-[ -n "$_p" ] && MEMHOUSE_PASSWORD=$_p; [ -n "$_d" ] && MEMHOUSE_DB=$_d
-if [ -n "${MEMHOUSE_URL:-}" ] && [ -n "${MEMHOUSE_USER:-}" ]; then
-  curl -sS -m 5 --user "$MEMHOUSE_USER:${MEMHOUSE_PASSWORD:-}" \
-    --data-binary "SELECT uniqExact(session_id), count(), formatDateTime(min(ts),'%Y-%m-%d') FROM messages" \
-    "$MEMHOUSE_URL/?database=${MEMHOUSE_DB:-$MEMHOUSE_USER}&final=1&readonly=1" 2>&1
-else
-  echo "NOT_CONFIGURED"
-fi
-```
-
-(Do not print the env values, and do not narrate that you are withholding them — just use them.)
-
-## What memhouse is — the overview (give this in every state, before the tour)
-
-One paragraph, grounded not sold: **memhouse is your personal, permanent archive of every
-AI coding session.** A background shipper reads the session files your editors write —
-Claude Code, Codex, Cursor, VS Code, Zed, OpenCode, Gemini CLI and 10 more, 17 in all —
-and ships them into a ClickHouse database you own, called a **house**. YOU choose that
-ClickHouse: a local one on your laptop, one on your own VM, or any ClickHouse server you
-control — managed or remote. memhouse itself is not a hosted service and phones nothing
-home; your sessions go only to the house you point it at, and it runs no LLM in its write
-or read path — it stores rows, the agent reading them (this chat) does the thinking. It
-outlives the transcripts on disk: editors compact and delete their local session files
-after weeks, so for anything older than ~30 days the house is the only place it still
-exists. One archive spans every editor, every project, every machine you ship from.
-
-What it gives you, in one breath: **ask** your own history a question and get a cited
-answer, **search** for the session you half-remember, **query** the raw data for numbers,
-browse a **dashboard**, and **invite** other people onto your ClickHouse so memories can be
-**shared** read-only. The tour below names each.
-
-## Then introduce it — three states, three openings
-
-**Configured and answering** — open with the numbers: "Your memory holds N sessions
-(M messages) going back to <date> — every conversation you've had with coding agents
-(Claude Code, Codex, Cursor, Gemini CLI and 13 more), across all your machines. It
-outlives the transcripts on disk: editors delete their session files after weeks; this
-doesn't." Then the tour below.
-
-**Not configured** — say what memhouse IS (one paragraph: a personal, permanent archive
-of every AI coding session, stored in a ClickHouse "house" you own), then how to start:
-`memhouse onboard` (wizard) or `memhouse install --env <file>` if someone invited them
-(the file came from `/mem:invite` on the inviter's side).
-
-**Configured but unreachable** — say which URL refused, point at `memhouse doctor`,
-stop. Never guess another endpoint.
-
-## The tour (keep it to one screen)
-
-What you can DO from this chat:
-
-- `/mem:ask <question>` — answer from your past work, with citations ("how did I fix X
-  last time?")
-- `/mem:search <terms>` — find the session ("that conversation about Y")
-- `/mem:sessions` — browse and filter what's stored
-- `/mem:sql <question or SQL>` — ad-hoc analytics (tokens, costs, rankings)
-- `/mem:status` — is it healthy, how much is stored, which machines ship into it
-
-The first three overlap — same words work in each — so give the reader the rule that
-separates them: **want a session → search. Want an answer → ask. Want a number → sql.**
-`ask` runs a `search` first, then reads the turns it finds and writes you a cited answer;
-`search` stops at the ranked list of sessions; `sql` counts and aggregates the columns
-rather than hunting text.
-
-And around other people — **inviting comes before sharing**:
-
-- `/mem:invite <name>` — mint a friend's account + their own house on your ClickHouse,
-  hand them one env file; they install with it and have their own memory
-- `/mem:share <name>` — once they exist, open a read-only window into YOUR memory
-  (`/mem:share revoke <name>` closes it); `/mem:users` shows who's around
-- **Read a friend's shared memory** — once they've shared theirs with you, name their
-  house right in the question: `/mem:ask <question> in <their-house>`, or
-  `/mem:search <terms> in <their-house>` / `/mem:sql … on <their-house>`. It reads THEIR
-  house read-only, with your own credentials; `/mem:users` lists the houses shared with
-  you. (A house is a whole ClickHouse database — sharing grants read on it, not on single
-  sessions.)
-
-Also worth naming: `memhouse start` serves a dashboard at http://localhost:4640 for
-browsing and analytics outside the chat, and everything here is read-only for agents —
-only the shipper writes.
-
-**Freshness check** — quietly compare the installed client to the latest release; mention
-it ONLY if there's a real gap (don't clutter the welcome otherwise):
-
-```bash
-INSTALLED=$(memhouse version 2>/dev/null | head -1 | tr -d '[:space:]')
-LATEST=$(curl -sS -m 5 https://registry.npmjs.org/memhouse/latest 2>/dev/null | sed -n 's/.*"version":"\([^"]*\)".*/\1/p')
-echo "installed=${INSTALLED:-unknown} latest=${LATEST:-unknown}"
-```
-
-If the installed version is a MINOR or MAJOR behind (or many patches), add one line:
-"heads-up — you're on 0.A.B, 0.C.D is out; `memhouse update` upgrades it and refreshes
-these `/mem:*` skills." A patch or two behind isn't worth mentioning here. Never run the
-update yourself.
-
-End by offering one concrete action: a search for something they mentioned recently, or
-`/mem:status` if they seem unsure it's working. One offer, not a menu.

package/memhouse/delivery/plugin/skills/invite/SKILL.md

@@ -1,130 +0,0 @@
----
-name: invite
-description: Invite another person onto this memhouse ClickHouse — mint their user and their own house (database) with the right grants, producing the one env file their install needs. Use when the user says "invite X", "add X to memhouse", "get my friend set up". Inviting comes BEFORE sharing — /mem:share can only grant a user who exists.
-user-invocable: true
-argument-hint: "<name> [into <db>]"
-allowed-tools: Bash
----
-
-# /mem:invite — mint a member and hand them one file
-
-This runs the `memhouse invite` CLI and nothing else. Inviting mints a ClickHouse user
-and a house, which takes an ADMIN credential — and an admin password must never enter
-this conversation, because memhouse ships the transcript into the house it just
-provisioned. The CLI is the only safe path: the admin password is passed to one process
-and never echoed. **Do not hand-run `CREATE USER` / `GRANT` with an admin password
-substituted into a command — that burns the credential into the transcript on disk.**
-
-## Do this
-
-1. Confirm the `memhouse` binary is present: `command -v memhouse`. If it is not, tell
-   the user to install it first (`npm install -g memhouse`) — there is no in-skill
-   fallback, on purpose (see above).
-
-2. Gather ONLY two things by asking:
-   - the invitee's **name** (validate `[A-Za-z][A-Za-z0-9_]*`; refuse otherwise)
-   - the **URL the invitee will reach the house at** — NOT localhost (that is the
-     invitee's own machine). A LAN IP, hostname, or tunnel.
-
-   Do NOT ask for an admin user or password yet — the next step usually needs neither.
-   Only ask about a **shared house** if the user brings one up; default is the invitee's
-   own house (omit --db; never pass `--db default` for "the default house").
-
-3. TRY IT BARE FIRST — run this via the Bash tool, from the directory the file should
-   land in (step 4). `memhouse invite` uses the caller's OWN configured credential when
-   it can manage users, which is the common case for whoever set the house up, so no
-   admin is needed:
-
-   ```
-   memhouse invite <name> --url <url> [--db <shared-house>]
-   ```
-
-   If it prints `invite written: …`, go to step 4 — you are done, and no admin secret
-   ever touched this conversation.
-
-   Otherwise read WHICH refusal came back; they need different answers.
-
-   **"cannot reach `<url>` …"** — nothing to do with privileges. The address is wrong,
-   or the house is bound to loopback (`memhouse deploy --local` binds to 127.0.0.1 on
-   purpose, so no LAN address reaches it and no invitee could either). Ask the user for
-   the address the invitee will actually use; do not retry with a guess.
-
-   **"`<user>` is a MEMBER of this ClickHouse, not an administrator"** — inviting needs
-   CREATE USER and CREATE DATABASE, which a member deliberately does not hold. Two cases,
-   and you must ask which one applies rather than assuming:
-
-   - **They run the ClickHouse.** They have the admin credential; memhouse never stores
-     it. Do NOT take that password in chat — memhouse archives this transcript. Hand them
-     the line to run THEMSELVES, and leave `--admin-password` OFF so it is prompted for,
-     keeping it out of both the process list and shell history:
-
-     ```
-     memhouse invite <name> --url <url> [--db <shared-house>] --admin-user <admin>
-     ```
-
-     **You cannot run that line yourself.** The prompt needs a TTY and your Bash tool has
-     none, so it refuses with "no TTY to prompt on" — and the fix is NOT to add
-     `--admin-password`, which would put the credential in this transcript. The user runs
-     it in their own terminal; you wait for them to say it is done.
-
-   - **Somebody else runs it.** They cannot invite, and no flag changes that. Print the
-     statements for whoever administers the server — this contacts nothing and needs no
-     credential:
-
-     ```
-     memhouse invite <name> --url <url> [--db <shared-house>] --print-sql
-     ```
-
-     The output ends with the four `MEMHOUSE_*` lines the invitee needs. Those lines are
-     a credential: tell the user to send them over a trusted channel, and **never print
-     them into the conversation yourself**.
-
-   **If it refuses with "house `<db>` already exists and holds N messages", STOP.** That
-   house is somebody's memory, and inviting into it would hand the invitee someone else's
-   sessions. Do not pass `--adopt` on your own initiative — report the row count and the
-   writer count to the user and let them choose: a different handle, a different `--db`,
-   or `--adopt` if sharing that house is genuinely what they want.
-
-4. **Put the file where the user can attach it.** The CLI writes `invite-<name>.env`
-   into the CURRENT directory, and the user has to send it by hand — so run the command
-   from their downloads directory (on macOS and most Linux desktops `~/Downloads`), or
-   move it there afterwards. Never leave it in a git repo: it is a password, and
-   `invite-*.env` is only gitignored in this repo, not in whatever checkout the user
-   happened to be standing in.
-
-   Confirm it is there and still mode `600`, and say the full path. **Never print the
-   file's contents** — the password inside would land in a transcript memhouse ships.
-
-5. **Say whether the house was fresh.** Run
-   `memhouse stats` or query `SELECT count() FROM <db>.messages` and tell the user
-   plainly: a brand-new house reads 0. This is a second line of defence behind step 3's
-   refusal, and it is how the user learns the invitee is starting clean.
-
-6. **Write the message the user will send.** They are about to hand over a file plus an
-   explanation, so compose it for them rather than making them write it. Put it in a
-   fenced block they can copy whole, and cover:
-   - what memhouse is, in a sentence or two — the invitee may never have heard of it
-   - that the attached `invite-<name>.env` IS a password: don't forward it, don't paste
-     it into chat
-   - `npm install -g memhouse` (Node 24+, no flags, nothing compiles), then
-     `memhouse install --env invite-<name>.env`
-   - that install OFFERS to change the password to one only they know, then deletes the
-     file — so they should say yes, because the inviter knows the current one
-   - `memhouse onboard` to start shipping, `memhouse status` to check it worked
-   - that their house is theirs alone; the inviter cannot read it unless they run
-     `/mem:share <inviter>`
-
-   If the invitee is REPLACING an existing setup (they were shipping under another
-   credential), add `memhouse ship --full` after the install — a plain incremental pass
-   skips sessions the new house has no record of, so their history would not follow them.
-
-   Then: once installed, sharing works both ways — `/mem:share <name>`.
-
-## Never
-
-Never create a ClickHouse user by running raw SQL with an admin password you were given
-in chat. Never invent an admin credential. Never suggest granting beyond what `memhouse
-invite` does. If the binary is absent, stop and say so — do not improvise the SQL.
-
-Never print the invite file's contents, and never pass `--adopt` unless the user asked
-for it after being told what is already in that house.