memhouse 0.7.0 → 0.8.0

package/memhouse/{per-member/schema-member.sql.tpl → house/schema.sql.tpl}

@@ -1,16 +1,13 @@
--- mem — one member's rooms. Applied per member — {{MEMBER}} is the ClickHouse username.
---
--- Room naming is TYPE-FIRST (sessions_<m>, not <m>_sessions) so the Merge rooms
--- can anchor on a fixed room type and never match themselves.
---
--- user_id MATERIALIZED currentUser() is retained even though the room names the member:
--- it keeps provenance across a share and keeps the Merge rooms meaningful. Writers must
--- use async_insert=0 or the stamp does not happen.
+-- The house's three rooms — plain, shared tables. Everyone in the house writes into
+-- these same tables with their own credential; `user_id MATERIALIZED currentUser()`
+-- (server-stamped, async_insert pinned to 0 on the user) says who, and `host` says
+-- which machine. There is no per-member table and no Merge room: the database IS the
+-- boundary, and a housemate is anyone granted on it.
 --
 -- ClickHouse >= 26.2 natively — 25.11 works because the shipper passes
 -- allow_experimental_full_text_index=1 per-query when applying this file.
 
-CREATE TABLE IF NOT EXISTS sessions_{{MEMBER}}
+CREATE TABLE IF NOT EXISTS sessions
 (
     session_id String,
     source LowCardinality(String),
@@ -47,7 +44,7 @@ CREATE TABLE IF NOT EXISTS sessions_{{MEMBER}}
 ENGINE = ReplacingMergeTree(ingested_at)
 ORDER BY (session_id, user_id);
 
-CREATE TABLE IF NOT EXISTS messages_{{MEMBER}}
+CREATE TABLE IF NOT EXISTS messages
 (
     session_id String,
     seq UInt32,
@@ -88,7 +85,7 @@ CREATE TABLE IF NOT EXISTS messages_{{MEMBER}}
 ENGINE = ReplacingMergeTree(ingested_at)
 ORDER BY (session_id, user_id, origin, seq);
 
-CREATE TABLE IF NOT EXISTS tool_calls_{{MEMBER}}
+CREATE TABLE IF NOT EXISTS tool_calls
 (
     session_id String,
     seq UInt32,

package/memhouse/resume.js

@@ -26,7 +26,7 @@
 // `source: 'claude-code'` on every chat it returns. This table was written against the
 // module names first and would have refused to resume a single Claude Code session — 508 of
 // them on the machine it was tested on. Read the values out of a real house
-// (`SELECT DISTINCT source FROM sessions_<you>`), never off the adapter's name.
+// (`SELECT DISTINCT source FROM sessions`), never off the adapter's name.
 const RESUMERS = {
   // claude --help, 2026-08-12: "-r, --resume [value]  Resume a conversation by session ID"
   'claude-code': {

package/memhouse/server/queries.js

@@ -18,13 +18,13 @@
 
 const { createClient, ClickHouseLogLevel } = require('@clickhouse/client');
 const { calculateCost, normalizeModelName } = require('../../pricing');
-const { resolveRooms, READ_SETTINGS } = require('../per-member/rooms');
+const { resolveRooms, READ_SETTINGS } = require('../house/house');
 
 const config = {
   url: process.env.MEMHOUSE_URL || 'http://localhost:8123',
   username: process.env.MEMHOUSE_USER || 'memhouse_root',
   password: process.env.MEMHOUSE_PASSWORD || '',
-  database: process.env.MEMHOUSE_DB || 'mem',
+  database: process.env.MEMHOUSE_DB || process.env.MEMHOUSE_USER, // house defaults to the user's own name
 };
 
 let _client = null;
@@ -925,6 +925,12 @@ async function rawQuery(sql) {
     // Cut the result off rather than failing a query that was legitimately large.
     result_overflow_mode: 'break',
     max_execution_time: 30,
+    // Result caps bound what LEAVES the server; this bounds what the query does inside
+    // it — a huge GROUP BY hits none of the caps above while eating the box's memory.
+    // Used to come from the member settings profile; that object is gone (it detached
+    // members on replace and its name was server-global), so the one caller that pipes
+    // arbitrary SQL carries its own ceiling.
+    max_memory_usage: 8000000000,
   });
   const columns = rows.length > 0 ? Object.keys(rows[0]) : [];
   return { columns, rows, count: rows.length, truncated: rows.length >= RAW_MAX_ROWS };

package/memhouse/shipper/ship.js

@@ -1,8 +1,8 @@
 #!/usr/bin/env node
 // memhouse SHIPPER — parse-on-client (bet #1 in ../DESIGN.md). Runs the 17 editor
-// adapters locally and ships TYPED rows into THE CALLER'S OWN rooms — sessions_<m> /
+// adapters locally and ships TYPED rows into the house's shared rooms — sessions /
 // messages_<m> / tool_calls_<m>, where <m> is `SELECT currentUser()` and never config
-// (../per-member/schema-member.sql.tpl, ../per-member/rooms.js). All of one member's
+// (../house/schema.sql.tpl, ../house/house.js). All of one member's
 // machines land in that member's rooms, told apart by the `host` column; no member
 // writes into another's. The typed evolution of agency/ingest.js: same host id,
 // same ts interpolation, same batching discipline — but rows land in physical
@@ -43,7 +43,7 @@ try { ({ createClient, ClickHouseLogLevel } = require('@clickhouse/client')); }
 catch {
   console.error("[memhouse] dependency '@clickhouse/client' is not installed.");
   console.error(`[memhouse] from a checkout:     npm install --prefix ${require('path').join(__dirname, '..', '..')}`);
-  console.error(`[memhouse] from an npm install: ${require('../per-member/rooms').installCommand()}`);
+  console.error(`[memhouse] from an npm install: ${require('../house/house').installCommand()}`);
   process.exit(2);
 }
 const { getAllChats, getAdapterErrors, getMessages, resetCaches } = require('../../editors');
@@ -52,7 +52,7 @@ const selfUpdate = require('../self-update');
 // Captured at require time, which is as close to "what this process booted with" as it
 // gets. Taking it later would record whatever an upgrade had already replaced.
 const selfSnap = selfUpdate.snapshot(__filename);
-const { resolveRooms, READ_SETTINGS, ROOM_TYPES } = require('../per-member/rooms');
+const { resolveRooms, READ_SETTINGS, ROOM_TYPES } = require('../house/house');
 
 const BATCH_ROWS = 2000;   // insert batch ceiling (binding)
 const TEXT_MAX = 50000;    // messages.text truncation
@@ -203,7 +203,7 @@ function makeClient() {
     url: process.env.MEMHOUSE_URL,
     username: process.env.MEMHOUSE_USER,
     password: process.env.MEMHOUSE_PASSWORD || '',
-    database: process.env.MEMHOUSE_DB || 'mem',
+    database: process.env.MEMHOUSE_DB || process.env.MEMHOUSE_USER, // house defaults to the user's own name
     request_timeout: 300000, // full re-ships move tens of MB; don't cut inserts short
     clickhouse_settings: {
       // Int64/UInt64 back as JSON numbers — our values (counts, tokens) are < 2^53.
@@ -221,7 +221,7 @@ function makeClient() {
   });
 }
 
-// Create the CALLER'S OWN rooms, from ../per-member/schema-member.sql.tpl. Comments are
+// Create the house's rooms, from ../house/schema.sql.tpl. Comments are
 // stripped BEFORE the ';' split — schema comments legitimately contain semicolons.
 //
 // This is the solo path: on a house you own, `memhouse install` mints your three rooms and
@@ -229,9 +229,8 @@ function makeClient() {
 // same identity the rooms' user_id is stamped with, so a client cannot name its way into
 // someone else's rooms.
 //
-// It does NOT issue grants or create the Merge rooms. A solo owner needs neither. Adding a
-// SECOND member — grants, Merge rooms, sharing — is owner work and lives in
-// ../per-member/provision.js.
+// It issues no grants: joining a house is the admin's two statements (CREATE USER +
+// GRANT ALL ON the house), and once granted, each member's own shipper runs this.
 /**
  * Refuse to write into rooms whose sorting key is wrong for `origin` — in EITHER
  * direction. Two different houses are broken in two opposite ways:
@@ -251,7 +250,7 @@ function makeClient() {
  * Refuse, legibly, when the caller's rooms are not there.
  *
  * Without this the first thing to touch a roomless house is loadExisting's SELECT, and the
- * user gets `Unknown table expression identifier 'sessions_x' in scope SELECT session_id,
+ * user gets `Unknown table expression identifier 'sessions' in scope SELECT session_id,
  * last_updated_at, message_count, extra FROM ...` — a raw ClickHouse identifier error with
  * no next step, from a command that may be running inside a service loop. `install` and
  * `doctor` both handle the identical situation properly; ship was the one that did not.
@@ -305,7 +304,7 @@ function templateColumns(tpl) {
  */
 async function warnMissingColumns(client, rooms) {
   let tpl;
-  try { tpl = fs.readFileSync(path.join(__dirname, '..', 'per-member', 'schema-member.sql.tpl'), 'utf-8'); }
+  try { tpl = fs.readFileSync(path.join(__dirname, '..', 'house', 'schema.sql.tpl'), 'utf-8'); }
   catch { return; }
   const want = templateColumns(tpl);
   const missing = [];
@@ -375,7 +374,7 @@ async function assertOriginKeyed(client, rooms) {
       + wrong.map((s) => `    ${s}`).join('\n')
       + '\n  ORDER BY cannot be altered in place. Rebuild each room, then re-ship:'
       + '\n    RENAME TABLE <room> TO <room>_old;'
-      + `\n    -- recreate from ${path.join(__dirname, '..', 'per-member', 'schema-member.sql.tpl')}`
+      + `\n    -- recreate from ${path.join(__dirname, '..', 'house', 'schema.sql.tpl')}`
       + '\n    INSERT INTO <room> SELECT * FROM <room>_old;'
       + '\n  (add `, \'ship\' AS origin` to the SELECT only if <room>_old has no origin column)'
       + '\n  A house with no imported rows can also just be re-shipped from scratch.');
@@ -384,18 +383,19 @@ async function assertOriginKeyed(client, rooms) {
 
 async function ensureSchema(client) {
   const rooms = await resolveRooms(client);
-  const { member } = rooms;
-  const tpl = fs.readFileSync(path.join(__dirname, '..', 'per-member', 'schema-member.sql.tpl'), 'utf-8');
-  const sql = tpl.replaceAll('{{MEMBER}}', member);
+  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);
-  // A MEMBER holds no CREATE TABLE — that is the point of the narrowed grant set — and
-  // ClickHouse checks the grant BEFORE it checks existence, so `IF NOT EXISTS` does not
-  // save these. Running the CREATEs in a bare loop meant `--ensure-schema` died on the
-  // FIRST statement for the very user who is told to run it, and never reached the ADD
-  // COLUMN rollout that is the whole reason to run it. Skip what we may not do and carry
-  // on; the rooms either already exist (assertRoomsExist says so) or an owner has to
-  // create them, which install already explains.
+  // 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
+  //     its ADD COLUMN rollout; ClickHouse checks the grant BEFORE existence, so IF NOT
+  //     EXISTS does not save the CREATEs. Skip what we may not do and carry on.
+  //   - a create RACE. Two housemates' first-ever ships can run these CREATEs
+  //     concurrently, and IF NOT EXISTS is not atomic against a simultaneous creator —
+  //     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) {
     try {
@@ -410,6 +410,7 @@ async function ensureSchema(client) {
     } 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; } // lost a create race — the winner made it
       throw e;
     }
   }
@@ -422,13 +423,6 @@ async function ensureSchema(client) {
   // would error. Add it in place; ReplacingMergeTree backfills the DEFAULT, so every
   // pre-existing row reads as 'ship', which is what it was.
   //
-  // Deliberately NOT applied to the Merge rooms — but not for the reason this comment used
-  // to give. It claimed they "reject ALTER"; they do not, on either 26.7 or 25.11, where
-  // `ALTER TABLE all_messages ADD COLUMN …` succeeds. The real reason is that a Merge room
-  // is a VIEW over whatever `^messages_` matches: a column added to it is cosmetic, is not
-  // backed by the underlying rooms, and drifts from them the moment a member is added. It
-  // takes its structure from a member room at CREATE time, so recreating it is the only
-  // correct way to change it — and nothing reads `origin` through it anyway.
   // EVERY column the template declares, not just `origin`.
   //
   // This used to add exactly one column, which meant any OTHER column missing from a room
@@ -807,7 +801,7 @@ function reportAdapterErrors(warned) {
   const noBinding = errors.filter((e) => e.missingBinding).map((e) => e.source);
   if (noBinding.length) {
     console.log(`[memhouse] WARNING: ${noBinding.length} adapter(s) skipped, sessions NOT shipped — better-sqlite3 has no native binding: ${noBinding.join(', ')}`);
-    console.log(`[memhouse]          fix: ${require('../per-member/rooms').installCommand()}`);
+    console.log(`[memhouse]          fix: ${require('../house/house').installCommand()}`);
   }
   for (const e of errors.filter((x) => !x.missingBinding)) {
     console.log(`[memhouse] WARNING: ${e.source} skipped — ${e.message}`);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "memhouse",
-  "version": "0.7.0",
+  "version": "0.8.0",
   "description": "memhouse — 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/per-member/INSTALL.md

@@ -1,228 +0,0 @@
-# INSTALL — how a house gets a member
-
-Three options. The first two are finished and measured; the third is not.
-
-| | you hold admin | who runs the SQL | admin credential |
-|---|---|---|---|
-| **1. print the SQL** | yes | you | never leaves your terminal |
-| **2. hand it over** | yes | the installer | used, then discarded |
-| **3. kernel** | no — the realm does | not finalized | — |
-
-## The identity rule, first — everything else follows from it
-
-**The ClickHouse user is the identity.** Rooms are `sessions_<member>`,
-`messages_<member>`, `tool_calls_<member>`, and `<member>` is whatever the server answers
-to `SELECT currentUser()` — never what the config file says, never what the OS says.
-
-The home directory produces a **suggestion**:
-
-```
-/Users/polat          -> polat
-/Users/ramazan.polat  -> ramazan_polat     (sanitized, and the change is printed)
-/home/JohnSmith       -> JohnSmith         (case preserved; ClickHouse is case-sensitive)
-/root                 -> refused           (a container artefact, not a person)
-```
-
-Sanitization is `[A-Za-z][A-Za-z0-9_]*`. It can collide — `ramazan.polat` and
-`ramazan-polat` both land on `ramazan_polat` — so a changed suggestion is printed, and
-`--member` overrides it.
-
-## Option 1 — print the SQL, run it yourself
-
-The common case: you installed ClickHouse, you have `default` with
-`access_management = 1`, and you would rather run four kinds of statement than hand a
-superuser credential to an installer.
-
-```
-memhouse install --print-sql [--member polat] [--db mem]
-```
-
-Prints the whole install as SQL and exits. Nothing is contacted, nothing is written. It
-generates a password and prints it inside the `CREATE USER`, or takes `--member-password`.
-The last line is the command to run afterwards, with the credential filled in.
-
-Two properties that make the block safe to paste anywhere:
-
-- **Every name is qualified and there is no `USE`.** It runs in `clickhouse-client`, the
-  play UI, `curl`, or a GUI, in any database context.
-- **The Merge engine gets the literal house name, not `currentDatabase()`.** That call is
-  evaluated at CREATE time, not read time, so a block run without the house selected would
-  otherwise build Merge rooms pointing at `default` that return zero rows forever, with no
-  error at any point.
-
-Measured: 18 statements (the 17 objects plus a leading `SET
-allow_experimental_full_text_index = 1`), run over HTTP with no database selected, 18
-succeeded on both 26.7.2.59 and 25.11.9.34, and the
-Merge rooms came out bound to `Merge('mem', '^sessions_')`.
-
-## Option 2 — give the installer admin, it runs the SQL
-
-```
-memhouse install --admin-user … --admin-password … [--member polat]
-```
-
-The same statements, applied by `provision.js` so there is one implementation of the grant
-set rather than two that drift. Then the step that makes the mode trustworthy:
-**disconnect from admin, reconnect as the member, and prove that credential reaches all
-three rooms before writing anything.** A mode that only proves the admin could do it has
-proven nothing about the credential it is about to persist.
-
-**The admin credential is never persisted** — not to the env file, not to a unit file, not
-to a log. A shipper running as the house owner would make per-member rooms decoration.
-
-## Option 3 — the kernel
-
-**Not finalized.** The realm holds the privileged credential and mints members; what the
-installer asks it for, and what it gets back, is not designed yet. Everything above about
-the room layout, the grant set and the identity rule holds regardless — what is open is
-who plays admin and how the handle is chosen.
-
-## The grant set — two statements per room, and the split is the point
-
-```sql
-GRANT SELECT, INSERT, ALTER UPDATE, ALTER DELETE, ALTER ADD COLUMN, OPTIMIZE
-             ON mem.sessions_polat TO polat;
-GRANT SELECT ON mem.sessions_polat TO polat WITH GRANT OPTION;
-```
-
-**Exactly what the shipper uses, not `ALL`.** `ALL` expands to 45 privileges on 26.7 and
-one of them is `CREATE TABLE` **on the member's own room name** — so the member owns the
-NAME, not just the data, and can do this:
-
-```sql
-DROP TABLE messages_polat;
-CREATE TABLE messages_polat AS all_messages ENGINE = Merge('mem','^messages_');
-```
-
-`all_messages` is `Merge(mem,'^messages_')`, so it then contains a Merge over its own
-namespace and **every other member's rows are counted twice in the team room**. Measured:
-a house reading alice 6030 / bob 2401 / carol 12 became bob 4802 / carol 24, with no error
-on either ClickHouse version. Confidentiality survives — the Merge still narrows by grants,
-so nothing new becomes readable — but a team-wide number is what that room is for.
-
-`ALTER UPDATE` and `ALTER DELETE` are both named because `DELETE FROM` is a lightweight
-delete implemented as `ALTER TABLE … UPDATE _row_exists = 0`, and which of the two a server
-demands varies by version (25.11 wants one where 26.7 wanted the other). `ALTER ADD COLUMN`
-is for `ensureSchema`'s rollout. Replacing a room is the admin's job, not the member's.
-
-**`SELECT`, re-grantable.** A share is read-only **by construction**, not by convention:
-the member can hand a colleague `SELECT` and nothing else, because they hold nothing else
-to hand over.
-
-Measured on 26.7.2 and 25.11.9:
-
-```
-polat grants SELECT to bob      ok
-polat grants DROP TABLE to bob  497 Not enough privileges
-polat drops their own room      497 Not enough privileges
-polat creates any table         497 Not enough privileges
-polat installs, ships, resets   ok
-bob ends up with                GRANT SELECT ON mem.sessions_polat
-```
-
-One definition, in `rooms.js` as `MEMBER_PRIVS`, used by both `provision.js` and
-`install --print-sql`. They drifted once — the first was narrowed and the second went on
-emitting `GRANT ALL` for a release, so the attack above stayed reachable through the path
-this document calls the common case.
-
-Never `ON mem.*`. A member who can read `mem.*` can read every other member's rooms, and
-then this is a shared house with longer table names.
-
-`SELECT` on the three Merge rooms is granted broadly and is safe: a Merge table reduces to
-the underlying rooms the *caller* holds grants for, so it narrows rather than denies, and
-picks up members added later with no DDL.
-
-## Refusals — the complete list
-
-Install refuses, names both sides, and creates nothing:
-
-| Case | Why |
-|---|---|
-| handle does not match `[A-Za-z][A-Za-z0-9_]*` after sanitization | it would need quoting, and a quoted room name breaks the Merge selectors |
-| handle would be `root`, or the home directory is `/root` | a container artefact, not a person |
-| **option 2: the ClickHouse user already exists** | the second human would take over the first's identity and rooms, and `user_id MATERIALIZED currentUser()` would stamp them identically. Requires `--adopt-user` AND `--member-password`, verified by reconnecting before anything is written |
-| option 2: `mem` absent and admin cannot `CREATE DATABASE` | nothing downstream can work |
-| an env file already points at a different url/db | it would orphan a running shipper. `memhouse setup` is the deliberate way to move; `--force` overrides |
-| rooms missing and you cannot create them | you are not the owner — both other options are printed |
-
-`--adopt-user` is legitimate — the same person on a new laptop — but it is
-indistinguishable from a takeover without the password, so the password is the proof.
-
-## After install — when admin is needed again
-
-- **a second member** — `provision.js --member <name> --merge`, or `--print-sql --member <name>`
-- **schema rollout** — `ADD COLUMN` on the **Merge room first**, then the member rooms;
-  Merge rejects mutations and tolerates drift, which is what makes a progressive rollout
-  possible
-- **offboarding** — `DROP USER <member>`. The rooms are deliberately left: they hold that
-  person's transcripts, and deleting someone's memory is a decision, not a cleanup step
-
-## Upgrading from 0.3.x — read this before you do
-
-**0.4.0 cannot read a 0.3.x house.** An earlier version of this document said an existing
-house "keeps working untouched". That was wrong, and it was wrong in the release notes and
-the `v0.4.0` tag message too.
-
-What is true: the DATABASE NAME survives. `MEMHOUSE_DB` sits in `~/.memhouse/env` and
-explicit config outranks the new `mem` default, so nothing repoints you at a different
-house. What does not survive is the TABLES. 0.3.x kept `sessions`, `messages`,
-`tool_calls` and a stored `sessions_v`; 0.4.0 looks for `sessions_<you>` and finds nothing.
-Measured against a real 0.3.2 house:
-
-```
-memhouse status  ->  not connected: Code: 60 ... Unknown table expression
-                     identifier 'sessions_memhouse_root'
-memhouse doctor  ->  schema: 0/3 rooms in 'memhouse'
-memhouse ship    ->  pass failed: UNKNOWN_TABLE
-```
-
-`install` and `doctor` now detect this and name it, rather than telling you to run an
-install you already ran.
-
-**Your transcripts are not lost.** memhouse ships FROM your local session stores, so the
-new rooms rebuild from disk and the old tables are left untouched:
-
-```
-memhouse install --admin-user <user> --admin-password <pw> --member <you>
-memhouse ship --full
-```
-
-The one thing that does not come back that way is a session whose transcript you have
-since deleted locally — it exists only in the old tables. Read those before dropping
-anything: `SELECT * FROM <db>.sessions`.
-
-## Where the credential lives
-
-`~/.memhouse/env`, mode 0600, `MEMHOUSE_*` keys. **Not** a `.env` in a working directory:
-the skills and docs source this path (`. ~/.memhouse/env`), and a `.env` beside a checkout
-gets committed eventually.
-
-The env file is written **last**, after everything above has proved out. Written first, a
-failed install leaves a config behind that the next command reads as truth.
-
-`memhouse service install` inlines the same values into the unit file, because a service
-must not depend on a shell-quoted file it does not parse the same way. That is a second
-copy, also 0600, removed by `memhouse service uninstall`.
-
-## `--adopt-user` needs house admin — it is not the new-machine path
-
-`--adopt-user` is read only on the `--admin-user` branch, so it provisions a member and
-requires admin on the house. Passing it without `--admin-user` used to be ignored silently;
-it is refused now.
-
-The actual "same person, new machine" path needs no admin at all — you already have a
-member credential, so just use it:
-
-    memhouse install --url https://… --user <member> --password …
-
-That finds the existing rooms and writes the config. `--adopt-user` is for the case where
-an admin is *creating or re-attaching* a member and wants the existing password verified
-before anything is written.
-
-## Offboarding, from the member's side
-
-`DROP USER <member>` leaves their rooms and revokes everything (verified: no orphan grants
-survive). From that member's machine every command then fails with `AUTHENTICATION_FAILED`
-and advises reinstalling — which cannot work, and is indistinguishable from a wrong
-password. There is no signal that says "you were offboarded"; ClickHouse does not
-distinguish the two either. Worth knowing before you use it on someone.

package/memhouse/per-member/PLAN.md

@@ -1,174 +0,0 @@
-# per-member rooms
-**v6 reverts one decision v5 made under review pressure.** v5 gave every member a stored
-`sessions_v`. SCHEMA v4 had already decided that the rollup is a *saved query*, and
-overriding that reactively — inside a review round, to fix a read-layer finding — cost a
-name inside the Merge selector's namespace (161 sessions counted as 322), a rename, a
-reserved prefix, a fourth grant and a fourth object to provision and roll forward. The
-query is back. SCHEMA v5 records the detour in full.
-
-**v5 corrects the grant set, adds the member's own view, and stops calling this a
-skeleton.** Four changes:
-
-1. The grant set was `SELECT, INSERT`, which is insufficient — the shipper clears a
-   session's rows before re-inserting, so every incremental pass needs both
-   `ALTER UPDATE` and `ALTER DELETE` (which of the two is demanded varies by server
-   version). The error surfaced only on the *second* ship of a *changed* session, which is
-   why four document versions carried it. See PROVISIONING v5.
-2. The delete predicate **must bind the user** rather than call `currentUser()`. A mutation
-   does not evaluate it in the caller's context, so the delete matched nothing and removed
-   nothing, silently. Measured on 25.11 and on chdb; it affected the shared layout too.
-3. The read layer resolves the rollup as **SQL text** rather than a name: the stored view
-   in the shared layout, a subquery over the caller's rooms in the per-member one. Without
-   that resolution a per-member house ships fine and reads back nothing.
-4. v1–v4 were design skeletons. This one is implemented and measured: `rooms.js`,
-   `provision.js`, the two DDL templates, and room routing through the read layer.
-
-## The model
-
-House **`mem`**. Three rooms per member:
-
-```
-mem.sessions_<member>
-mem.messages_<member>
-mem.tool_calls_<member>
-```
-
-Owner-managed Merge rooms for team-wide reads:
-
-```sql
-mem.all_sessions    = Merge('mem', '^sessions_')
-mem.all_messages    = Merge('mem', '^messages_')
-mem.all_tool_calls  = Merge('mem', '^tool_calls_')
-```
-
-Canon: house = database, room = table, member = a registered user with grants.
-
-## Why
-
-**Isolation is structural.** A grant that is absent exposes nothing; a row policy has to
-be correct on every room for every role, and one wrong predicate exposes everything. It
-fails closed.
-
-**Sharing is self-serve.** A member holding grant-option on their own rooms shares with a
-colleague directly. Under row policies the same act needs `CREATE ROW POLICY`, which the
-kernel withholds from agency owners.
-
-**Personal reads stop paying for everyone else.** The shared rooms order
-`(session_id, user_id, seq)`, so filtering by member cannot prefix-scan. At a hundred
-members every personal query and full-text lookup scans roughly 100× what it needs.
-
-**Per-member lifecycle is atomic** — delete, export, retention, and quota are per-room
-operations rather than mutations across a shared table.
-
-## Grants
-
-Two statements per room, six per member, explicit — plus SELECT on the Merge rooms.
-`PROVISIONING.md` is the authority; this is the shape:
-
-```sql
-GRANT ALL    ON mem.sessions_<m>   TO <m>;
-GRANT SELECT ON mem.sessions_<m>   TO <m> WITH GRANT OPTION;
--- and the same pair for messages_<m> and tool_calls_<m>
-```
-
-**The split is the point.** `ALL` covers the mutation privileges the shipper's re-ship
-needs without naming them — clear-then-insert, so a growing transcript cannot leave a
-stale `seq` tail when a re-parse yields fewer rows, and which of `ALTER UPDATE` /
-`ALTER DELETE` a server demands varies by version. Grant-option is attached to the
-`SELECT` statement and **not** to the `ALL` one, so a share is read-only by construction:
-a member cannot hand a colleague `DROP TABLE` while meaning "let them read my sessions".
-Never `ON mem.*` — see PROVISIONING.
-
-## What stays
-
-- `user_id MATERIALIZED currentUser()` on every room; `async_insert=0` on writers.
-- Typed columns, `extra JSON`, `ReplacingMergeTree(ingested_at)`, `final=1` reads, both
-  full-text layers on messages.
-- Parse-on-client; the shipper runs the 17 adapters and writes typed rows.
-- `sessions_v` as a **saved query** run under the caller, not a stored view — the v1–v4
-  decision, restored. The read layer resolves it as text in the same place it resolves a
-  room name, so the rollup and the rooms travel through one substitution point.
-- The REST contract and the borrowed dashboard.
-
-## Measured facts (ClickHouse 26.7.1)
-
-1. Members **self-provision** inside their own prefix and are denied outside it.
-2. `Merge` **fails closed on permissions** — a caller sees only the underlying rooms they
-   hold grants for, with no leak and no error. This requires SELECT on the Merge room
-   ITSELF: without it the team room denies outright instead of narrowing, which is a
-   different and worse behaviour. Provisioning grants it (re-measured on 25.11).
-3. `Merge` **auto-discovers** rooms created after it exists.
-4. `Merge` **tolerates schema drift**, returning a column's default for rooms lacking it —
-   so schema rollout is progressive, not lock-step. It **rejects mutations**; use
-   `ADD COLUMN`, Merge room first.
-5. Row-policy rights are **house-scopeable** (`GRANT ACCESS MANAGEMENT ON mem.*`). Owner
-   only — the scope is the house, not a room.
-6. **`EXECUTE AS` exists**, changes `currentUser()`, and is a grantable privilege denied to
-   members by default.
-7. **The shipper needs both mutation grants** on its own rooms, or incremental passes
-   fail — 26.7 named `ALTER DELETE`, 25.11 named `ALTER UPDATE(_row_exists)`. New in v5.
-8. **`currentUser()` in a mutation predicate matches nothing.** A `DELETE` filtered on
-   `user_id = currentUser()` removed 0 rows where the same predicate with the bound value
-   removed 2000 — on ClickHouse 25.11 and on chdb alike, with no error either time. New
-   in v5.
-
-## Measured end-to-end (the implementation, not the design)
-
-On ClickHouse 25.11, two members, real local session stores:
-
-- alice ships 161 sessions / 22,413 message rows / 16,197 tool rows into her own rooms;
-  bob's rooms are untouched.
-- alice reading **or writing** bob's rooms is denied, and so is reading bob's view.
-- the whole read layer resolves: 13 of 14 dashboard query functions run green against
-  per-member rooms (the fourteenth needs a SQL argument), and `status`, `search`, `doctor`,
-  `stats` all report alice's own data. The same queries against the shared names fail with
-  `UNKNOWN_TABLE`, which is what they did before this change.
-- a planted stale `seq` tail is cleared by the next re-ship, which is what the two ALTER
-  grants exist for.
-- the whole gauntlet scenario's SQL assertions pass when run by hand against a two-member
-  house: 22,413 rows in alice's room, none unstamped, none in bob's, bob reading the team
-  Merge room sees zero of alice's, alice sees her own. Sharing round-trips: alice's
-  `GRANT` widens bob's Merge view to 22,413 and her `REVOKE` returns it to zero, with the
-  direct read denied again.
-- the shared-room layout has been removed; this is the only layout.
-
-## `user_id` — what it guarantees
-
-Unforgeable **by a member**, since members do not hold `EXECUTE AS`. Forgeable by the
-owner or any grantee. The trust boundary is the owner, not the engine — the normal
-arrangement, but do not overstate it anywhere user-facing. **Members must never hold
-`EXECUTE AS`.**
-
-## Phases
-
-1. Schema + naming — room DDL template, key order, Merge rooms. **Done.**
-2. Provisioning — kernel capability and standalone path. **Standalone done**
-   (`provision.js`); the kernel capability is not written.
-3. Query layer — the member view and room-name resolution. **Done** — `rooms.js` plus
-   templated room names through `queries.js`, `ship.js` and the CLI.
-4. Sharing — room-level self-serve; row-level via the owner. **Room-level proven**;
-   row-level not implemented.
-
-Migration is not a phase and must not shape MVP decisions.
-
-## Open questions
-
-- **May members create and drop their own rooms?** Works, safely scoped; but a member
-  could drop their own memory and schema rollout stops being central. Deferred with the
-  uninstall/drop work.
-- **Key order** — is `user_id` still worth an `ORDER BY` slot now the room is the tenant?
-- **Standalone path** — a user with no kernel is both owner and member; one credential or
-  two?
-- **Is `EXECUTE AS` scopeable** to `mem.*` rather than `*.*`? Bounds what an owner
-  credential can impersonate.
-- ~~**Should a share be `SELECT`-only?**~~ **RESOLVED.** Grant-option is attached to the
-  member's `SELECT` grant and not to their `ALL` grant, so a share can only ever be
-  read-only. Measured on 26.7.2: `GRANT SELECT … TO bob` succeeds,
-  `GRANT DROP TABLE … TO bob` is refused 497.
-
-## Out of scope
-
-- Migration. Deferred; unblocked in principle by `EXECUTE AS`.
-- `agent_id` / crew identity. Within a crew sharing one credential an agent tag is
-  client-supplied and is not a security boundary.
-- Adapters, REST contract, dashboard.