memhouse 0.16.0 → 0.18.0

package/memhouse/shipper/ship.js

@@ -61,12 +61,11 @@ const selfUpdate = require('../self-update');
 // gets. Taking it later would record whatever an upgrade had already replaced.
 const selfSnap = selfUpdate.snapshot(__filename);
 const {
-  resolveRooms, READ_SETTINGS, ROOM_TYPES, META_TYPES, SCHEMA_VERSION, MEMBER_PIN,
-  SUPPORTED_SCHEMAS, keyProblem,
-} = require('../house/house');
+  resolveRooms, READ_SETTINGS, ROOM_TYPES, META_TYPES, SCHEMA_VERSION, MEMBER_PIN, createStatement,
+  SUPPORTED_SCHEMAS, keyProblem, legacyTextIndexDialect, isTextIndexGrammarRefusal, textIndexDialectFor } = 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
-// house_events would otherwise roll out to nobody.
+// events would otherwise roll out to nobody.
 const ALL_TABLES = [...ROOM_TYPES, ...META_TYPES];
 
 const BATCH_ROWS = 2000;   // insert batch ceiling by ROW COUNT
@@ -410,17 +409,25 @@ async function assertRoomKeys(client, rooms) {
   }
 }
 
+// The shipper reads the prefix straight from its environment: it is spawned with the
+// resolved MEMHOUSE_* env by the CLI, and every room name it touches comes from
+// resolveRooms, so this is the only line that needs to know.
+
 async function ensureSchema(client) {
   const rooms = await resolveRooms(client);
   // BEFORE the CREATEs and ALTERs, not beside the end-of-function asserts. A house whose
   // record says a newer release moved it forward may have columns this template does not
   // know; running this template's DDL first could add back what that release removed —
   // the exact write the guard exists to prevent.
+  await assertNotLegacyLayout(client, rooms);
   await assertWriterSupported(client, rooms);
   const tpl = fs.readFileSync(path.join(__dirname, '..', 'house', 'schema.sql.tpl'), 'utf-8');
-  const sql = tpl; // plain shared tables — nothing to render
-  const stripped = sql.split('\n').map((l) => l.replace(/--.*$/, '')).join('\n');
-  const stmts = stripped.split(';').map((s) => s.trim()).filter(Boolean);
+  // Rendered per room rather than taken as one blob, because a prefixed house names its
+  // rooms `<prefix>_messages` and the template says `messages`. With no prefix the two
+  // are identical, so this is the same statements in the same order as before.
+  const stmts = [...ROOM_TYPES, ...META_TYPES]
+    .map((t) => createStatement(tpl, t, rooms.physical ? rooms.physical[t] : t)
+      .replace('CREATE TABLE ', 'CREATE TABLE IF NOT EXISTS '));
   // Two failure shapes are survivable here and both are skipped rather than fatal:
   //
   //   - a permission denial. A read-only credential can still run --ensure-schema for
@@ -431,16 +438,24 @@ async function ensureSchema(client) {
   //     the loser can get TABLE_ALREADY_EXISTS or a metadata-file collision. The table
   //     exists either way, which is the outcome this function wants.
   let denied = 0;
-  for (const q of stmts) {
+  // The text-index grammar changed at 25.10 and neither side parses the other (measured:
+  // 25.8/25.9 take the quoted form, 25.10+ the function form). Pick by the server's own
+  // version, then keep one fallback: if the chosen form is refused on grammar alone —
+  // never on privilege — send the other. A wrong guess costs a round-trip, not the install.
+  const version = await serverVersion(client);
+  const dialect = textIndexDialectFor(version);
+  if (dialect === 'legacy') console.error(`[memhouse] ClickHouse ${version}: text indexes in the pre-25.10 grammar`);
+  const create = (q) => client.command({ query: q, clickhouse_settings: { async_insert: 0, allow_experimental_full_text_index: 1 } });
+  for (const modern of stmts) {
+    const legacy = legacyTextIndexDialect(modern);
+    const [first, second] = dialect === 'legacy' ? [legacy, modern] : [modern, legacy];
     try {
-      await client.command({
-        query: q,
-        // allow_experimental_full_text_index: on 25.x the messages text indexes
-        // are gated behind this flag (SUPPORT_IS_DISABLED without it); 26.x+
-        // accepts it as a no-op. Query-scoped, so no server config or admin
-        // rights are needed. Verified on 25.11 and 26.7.
-        clickhouse_settings: { async_insert: 0, allow_experimental_full_text_index: 1 },
-      });
+      try { await create(first); }
+      catch (e) {
+        const m = e && e.message ? e.message : String(e);
+        if (!(first !== second && isTextIndexGrammarRefusal(m))) throw e;
+        await create(second);
+      }
     } catch (e) {
       const m = e && e.message ? e.message : String(e);
       if (/Not enough privileges|ACCESS_DENIED/i.test(m)) { denied++; continue; }
@@ -449,8 +464,16 @@ async function ensureSchema(client) {
     }
   }
   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.');
+    // In a SHARED house this is the designed state, not a shortfall: the operator creates
+    // each member's rooms during `invite` precisely so the member cannot — a member who
+    // could CREATE TABLE here could add tables beside every housemate's. Saying "you do
+    // not hold these rights" and then "schema ensured" about the same statements reads as
+    // a contradiction on every routine ship, which is how often a member sees it.
+    // A member holds CREATE TABLE on their own name pattern, so this is no longer the
+    // ordinary path — it is a credential provisioned outside memhouse with less than the
+    // plan gives. Say what to ask for rather than whose job it is.
+    console.error(`[memhouse] ${denied} schema statement(s) needed rights this credential does not hold — continuing with what it can do.`);
+    console.error('[memhouse] the memhouse grant is one line — `memhouse install --print-sql` shows it; ask whoever administers the house to run it.');
   }
   // A house created before origin existed has no such column, and every read and write
   // scopes by it. Add it in place; ReplacingMergeTree backfills the DEFAULT, so every
@@ -503,7 +526,7 @@ async function ensureSchema(client) {
   // There used to be a second, hardcoded `ADD COLUMN … origin` here, from when the healer
   // above could only add that one column. It is redundant now that the generic loop reads
   // the template correctly — and it would have been actively wrong once this loop covered
-  // house_meta and house_events, which have no origin and want none.
+  // meta and events, which have no origin and want none.
 
   await assertRoomsExist(client, rooms);
   await assertRoomKeys(client, rooms);
@@ -534,7 +557,7 @@ async function ensureSchema(client) {
  * Keep the house's record of itself current: which schema generation it is at, and which
  * memhouse version is writing into it.
  *
- * Written only when something CHANGED. A row per pass would turn house_events into a
+ * Written only when something CHANGED. A row per pass would turn events into a
  * heartbeat log — under `--loop` at the default interval that is 288 rows a day per
  * machine, and the one question the table exists to answer ("when did this house move,
  * and who moved it") would be buried in noise.
@@ -548,7 +571,7 @@ async function recordHouseState(client, rooms, host) {
   const writer = `${rooms.user}@${host}`;
   try {
     const rs = await client.query({
-      query: `SELECT key, value FROM ${rooms.house_meta} FINAL WHERE key IN ('schema_version', {ck:String}, {cs:String})`,
+      query: `SELECT key, value FROM ${rooms.meta} FINAL WHERE key IN ('schema_version', {ck:String}, {cs:String})`,
       // Keyed per member AND host. Keyed by member alone, two machines of one member
       // overwrote each other's entry on every pass, so the fleet view could only ever
       // show the machine that shipped last — the exact machine that needs no attention.
@@ -588,15 +611,15 @@ async function recordHouseState(client, rooms, host) {
     }
     // The heartbeat, EVERY pass — the fleet view's health column. Latest-wins on the key,
     // so it is one live row per writer however often it fires; version/schema above stay
-    // change-only so house_events remains a record of moves, not a pulse trace.
+    // change-only so events remains a record of moves, not a pulse trace.
     metas.push({ key: `last_ship:${writer}`, value: new Date().toISOString(), host });
     await client.insert({
-      table: rooms.house_meta_raw, values: metas, format: 'JSONEachRow',
+      table: rooms.meta_raw, values: metas, format: 'JSONEachRow',
       clickhouse_settings: { async_insert: 0 },
     });
     if (events.length) {
       await client.insert({
-        table: rooms.house_events_raw, values: events, format: 'JSONEachRow',
+        table: rooms.events_raw, values: events, format: 'JSONEachRow',
         clickhouse_settings: { async_insert: 0 },
       });
     }
@@ -609,8 +632,8 @@ async function recordHouseState(client, rooms, host) {
  *
  * Distinct from assertRoomKeys, which inspects key SHAPES — a future generation could be
  * a data transform the keys do not show. This reads what the house says about itself:
- * house_meta['schema_version'] (what generation the rooms are at) and
- * house_meta['min_writer_schema'] (the floor `memhouse migrate` sets under writers).
+ * meta['schema_version'] (what generation the rooms are at) and
+ * meta['min_writer_schema'] (the floor `memhouse migrate` sets under writers).
  * Too new -> the fix is on THIS machine: memhouse update. Below the floor -> same.
  * (A house OLDER than this release is not an error here — the room checks catch it and
  * name `memhouse migrate`; this guard must not fire on a pre-0.10 house that has no
@@ -619,17 +642,52 @@ async function recordHouseState(client, rooms, host) {
  * Releases before 0.10.0 never read this — for them the floor is enforced by the
  * pilot's GRANTs, not by code.
  */
+/**
+ * A house from before the one-layout holds plain rooms — `messages`, not `<member>_messages`.
+ * Shipping into it would quietly create a second, empty set of rooms beside the full ones
+ * and write there: every past session invisible to the member's own reads, the dashboard
+ * and the skills, with nothing anywhere saying why. Refuse, and say exactly what moves the
+ * old rooms across — a RENAME, instant, nothing copied.
+ *
+ * Trips only when the member's rooms are ABSENT and the plain ones PRESENT; a house holding
+ * both is mid-conversion and is left alone.
+ */
+async function serverVersion(client) {
+  try {
+    const rs = await client.query({ query: 'SELECT version() AS v', format: 'JSONEachRow' });
+    return String(((await rs.json())[0] || {}).v || '');
+  } catch { return ''; }
+}
+
+async function assertNotLegacyLayout(client, rooms) {
+  const rs = await client.query({
+    query: `SELECT name FROM system.tables WHERE database = currentDatabase() AND name IN ('messages', '${rooms.physical.messages}')`,
+    format: 'JSONEachRow',
+  });
+  const names = new Set((await rs.json()).map((r) => r.name));
+  if (names.has(rooms.physical.messages) || !names.has('messages')) return;
+  // The plain rooms of a pre-one-layout house: the transcript rooms by type name, and the
+  // two bookkeeping rooms under the names they had then.
+  const legacyName = { meta: 'house_meta', events: 'house_events' };
+  const moves = [...ROOM_TYPES, ...META_TYPES].map((t) => `RENAME TABLE ${legacyName[t] || t} TO ${rooms.physical[t]};`).join('\n     ');
+  throw new Error(
+    'this house holds plain rooms (messages, sessions, tool_calls) — the layout before rooms were named for their member.\n'
+    + `  Shipping now would create empty ${rooms.pattern} rooms beside them and write there, hiding every past session.\n`
+    + `  Move the old rooms across (a rename — instant, nothing copied), then ship again:\n     ${moves}\n`
+    + `  Then replace the database-wide grant with the one-layout grant:  memhouse install --print-sql --member ${rooms.member}`);
+}
+
 async function assertWriterSupported(client, rooms) {
   let have;
   try {
     const rs = await client.query({
-      query: `SELECT key, value FROM ${rooms.house_meta} FINAL WHERE key IN ('schema_version', 'min_writer_schema')`,
+      query: `SELECT key, value FROM ${rooms.meta} FINAL WHERE key IN ('schema_version', 'min_writer_schema')`,
       format: 'JSONEachRow',
     });
     have = new Map((await rs.json()).map((r) => [r.key, toInt(r.value)]));
   } catch (e) {
     // ONLY a missing table means a pre-0.10 house (the room checks own that case). Any
-    // other failure — an ACCESS_DENIED on house_meta, a timeout — used to fall through
+    // other failure — an ACCESS_DENIED on meta, a timeout — used to fall through
     // here too, and a writer that merely could not READ the record was treated as if the
     // record did not exist: on a newer-schema house whose key shapes happen to match,
     // that bypassed the whole compatibility guard. Not being able to check is a reason
@@ -1004,6 +1062,7 @@ async function runShip(client, opts = {}) {
   // shape: writing at the wrong epoch either forks a session that did not change, or
   // overwrites a stored parse that did.
   const rooms = await resolveRooms(client);
+  await assertNotLegacyLayout(client, rooms);
   await assertWriterSupported(client, rooms);
   await assertRoomsExist(client, rooms);
   await assertRoomKeys(client, rooms);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "memhouse",
-  "version": "0.16.0",
+  "version": "0.18.0",
   "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.