memhouse 0.7.1 → 0.9.0

package/memhouse/per-member/SCHEMA.md

@@ -1,120 +0,0 @@
-# SCHEMA — rooms, keys, Merge rooms, the rollup
-The room shapes, keys and Merge rooms are
-unchanged. What changes is that v4's decision about `sessions_v` — *a saved query, not a
-room* — is now the implemented one, after a detour through a stored view that this
-version records rather than hides.
-
-## `sessions_v` is a saved query, not a room
-
-v4 said so. Round 1 of the review campaign implemented it as a **stored view** instead —
-reactively, to fix a finding that the read layer named the shared rooms — without going
-back to this file. Everything that followed was the cost of that override:
-
-- the view needed a name, and `sessions_v_<m>` sits inside the `^sessions_` pattern the
-  Merge rooms select on. `all_sessions` silently absorbed every member's aggregate view
-  alongside their base room: **161 sessions counted as 322**.
-- so the name moved to `v_sessions_<m>`, which then needed a reserved prefix so no member
-  handle could re-create the collision;
-- and a fourth grant per member, because a recipient given the three rooms could read rows
-  and use none of the product's read paths;
-- and a fourth object to create, roll forward, check in `doctor`, and eventually drop.
-
-None of that buys anything the query does not already do. Reverted.
-
-### What it is now
-
-`rooms.js` exposes `sessions_v` as **SQL text** — a parenthesised `SELECT` over the
-caller's own rooms. It drops into the same `FROM … AS c` position a view name would have
-occupied, so the read layer treats it as just another resolved room name and the
-substitution point is one function. (The shared layout, where this key resolved to a
-stored view's *name*, is gone; the text form is the only one now.)
-
-```sql
-FROM {{sessions_v}} AS c        -- resolves to:  FROM ( SELECT … FROM sessions_alice … ) AS c
-```
-
-It runs **under the caller's credential**, substituted with the caller's own room names,
-so it inherits their grants exactly and raises no view-ownership question at all.
-
-### The two properties that had to survive
-
-- the join is a **LEFT JOIN**, so a session with no messages still appears with zero
-  aggregates instead of vanishing from every count;
-- `join_use_nulls = 1` makes the unmatched message columns NULL, so `coalesce` yields true
-  zeros rather than counting the placeholder row.
-
-The view carried the second as a trailing `SETTINGS` clause. **A subquery cannot**, so it
-moved to the caller: `READ_SETTINGS = { final: 1, join_use_nulls: 1 }`, applied by the
-dashboard client, the shipper and the CLI's raw HTTP alike. A unit check asserts the text
-carries no `SETTINGS` of its own, because putting it back would break every read that uses
-the rollup.
-
-### The cost, stated plainly
-
-An agent writing ad-hoc SQL has no name to type. `memhouse sessions-query` prints the
-rollup resolved for whoever the configured credential is, and the three delivery skills
-point at it. That is a worse affordance than a name, and it is the price of the property
-that made v4 choose a query: nothing to own, nothing to grant, nothing in a namespace.
-
-## Room naming, keys, Merge rooms
-
-Unchanged from v4. Rooms are type-first — `sessions_<m>`, `messages_<m>`,
-`tool_calls_<m>` — so the Merge rooms anchor on a fixed room type and never match
-themselves. With the view gone, `^sessions_` now matches **only** base session rooms,
-which is what it was always supposed to mean.
-
-> **OPEN** (carried from v4): is `all_sessions` a Merge over the member `sessions_*`
-> rooms, or a saved query over `all_messages`? The first is cheaper; the second guarantees
-> the aggregates match the per-member rollup exactly.
-
-## Not yet written
-
-- the kernel capability that provisions a member
-- member removal: drop the three rooms, revoke, decide what happens to rooms shared outward
-
-## What a member can still learn about the others
-
-Isolation is a grant that is absent, so no member can read another's rows — verified by
-trying every read and write against another member's rooms, plus `system.parts`,
-`system.query_log`, `system.processes` and the rest, all of which refuse. Two things do
-leak, both structural rather than bugs in the code, and neither is fixed by tightening a
-grant:
-
-**The roster.** A member's handle is part of their table name, and ClickHouse distinguishes
-"forbidden" from "absent": `SELECT count() FROM messages_bob` returns `Code: 497
-ACCESS_DENIED` (HTTP 500) if bob exists and `Code: 60 UNKNOWN_TABLE` (HTTP 404) if he does
-not. So any member can enumerate the membership of the house by guessing handles.
-`system.tables` correctly hides the other rooms; this reopens it. `EXISTS TABLE` does not
-leak — it answers 497 either way — so it is specifically the natural probe that talks. If
-the membership of a house is itself sensitive, the per-member layout is the wrong shape for
-it.
-
-**Volume.** `system.tables.total_rows` and `total_bytes` are readable for the Merge rooms,
-and a Merge room spans every member:
-
-    name            total_rows   total_bytes
-    all_messages    87           42455        <- the whole house
-    messages_alice  33           25070        <- what alice can actually read
-
-So a member can see the house's combined row count and byte volume, and by polling it, when
-other members are shipping. Withholding `SELECT` on the Merge rooms is not the fix — it
-makes the team room deny rather than narrow, which is the property those rooms exist for.
-
-## Why members are not granted ALL on their own rooms
-
-`GRANT ALL ON <db>.messages_<m>` expands to 45 privileges on 26.7, and one of them is
-`CREATE TABLE` **on that name**. A member would then own the name rather than the data:
-
-    DROP TABLE messages_alice;
-    CREATE TABLE messages_alice AS all_messages ENGINE = Merge('<db>','^messages_');
-
-`all_messages` is `Merge(db,'^messages_')`, so it now 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.
-Confidentiality survives (the Merge still narrows by grants) but integrity does not, and a
-team-wide number is what the room is for. It is the same failure recorded above under the
-`sessions_v` rename, reached on purpose instead of by accident.
-
-Members therefore get exactly what the shipper uses — `SELECT, INSERT, ALTER UPDATE, ALTER
-DELETE, ALTER ADD COLUMN, OPTIMIZE` — and nothing that defines an object. Replacing a room
-is the admin's job.

package/memhouse/per-member/SHARING.md

@@ -1,149 +0,0 @@
-# SHARING — two tiers
-
-**A share is three grants**, one per room, and there is no fourth: the rollup is a saved
-query over exactly those rooms rather than a stored object, so a recipient who can read
-the rooms can run it.
-
-A share is also **read-only by construction**. `WITH GRANT OPTION` is attached to the
-member's `SELECT` grant and not to their `ALL` grant ([PROVISIONING](PROVISIONING.md)),
-so alice cannot hand bob mutation or drop rights on her room even by mistake.
-
-## Tier 1 — whole room, self-serve
-
-A member holds `WITH GRANT OPTION` on their own three rooms — there is no fourth object
-to hold anything on — so they share without an operator:
-
-```sql
-GRANT SELECT ON mem.messages_alice   TO bob;
-GRANT SELECT ON mem.sessions_alice   TO bob;
-GRANT SELECT ON mem.tool_calls_alice TO bob;
-```
-
-**Three statements.** The rollup every read path uses is a saved query over exactly these
-rooms, run under the recipient's own credential — so a recipient who can read the rooms
-can run it, and there is no fourth grant to forget. That is the concrete payoff of the
-query over the view, and it is why SCHEMA v4 chose it before the implementation briefly
-went the other way.
-
-`memhouse sessions-query` prints the rollup for whoever is connected, which is what a
-recipient pastes into a `FROM (...) AS c` when writing ad-hoc SQL.
-
-This is the tier per-member rooms exist to enable. Under a row policy the same act needs
-`CREATE ROW POLICY`, which members do not have and the kernel withholds from agency
-owners by default.
-
-Bob reading `messages_alice` sees `user_id = 'alice'` on every row. That stamp is
-unforgeable **by members**, since `EXECUTE AS` is a grantable privilege they do not hold,
-and forgeable by the owner or anyone granted it. Trust boundary is the owner, not the
-engine.
-
-The stamp is also pinned **server-side**: the member settings profile carries
-`async_insert = 0 CONST`. A MATERIALIZED column is computed during the insert, and an
-async insert flushes outside that context — measured on 25.11.9.34, `async_insert=1`
-stores `user_id` as the empty string while a sync insert on the same table stamps
-correctly. The shipper always passed `async_insert=0`, so memhouse was never the risk;
-anything else holding a member credential was. With the constraint in force a client that
-*asks* for `async_insert=1` is refused (`SETTING_CONSTRAINT_VIOLATION`), and one that
-simply does not mention the setting is held at 0 — so the insert still succeeds, stamped,
-rather than landing unowned. It is the override that is refused, not the write.
-
-Two limits worth stating plainly. The constraint binds the **ClickHouse user**, not the
-database — if you reuse a member's credential for unrelated high-throughput ingestion
-elsewhere on that server, async inserts are refused there too. And it only takes effect
-once the profile is applied: a house provisioned by an older memhouse keeps the old
-profile until any member is provisioned again, which now updates the shared profile for
-everyone at once. `doctor`'s blank-`user_id` check remains as the detector for rows
-written before that.
-
-## What the boundary does NOT hide: the roster
-
-**Members can discover which other members exist, and this is not fixable here.** A
-handle is a table name, and ClickHouse answers differently for a table you may not read
-than for one that is not there:
-
-```
-SELECT count() FROM mem.messages_alice    -- exists, not granted → Code 497, Not enough privileges
-SELECT count() FROM mem.messages_nobody   -- does not exist      → Code 60,  Unknown table
-```
-
-So probing names enumerates the membership. Measured on 26.7.3.19 that this is
-**ClickHouse's behaviour and not a consequence of our grant set**: a user holding *zero*
-grants anywhere in the database gets exactly the same 497/60 split. No grant, revoke or
-role arrangement changes it.
-
-It *is* closable, and the price is the reason it stays open. Suffixing rooms with a random
-token (`messages_alice_8f9b2a`) would still match the `^messages_` Merge selectors, and
-would still leave the share in this document working — alice grants on the room she owns
-and knows, and bob never needs its name. What it costs is that a room name stops being
-**derivable**: `roomNames(member)` is pure today, and every client — the shipper, the
-skills, `sessions-query`, a person typing SQL — would instead have to look its own name up
-first. A real trade, deliberately not taken; not an impossibility.
-
-What leaks is **membership, not content**: names and the fact of existence, never rows,
-counts or sizes. In the setting this is built for — a team who already know they are a
-team — that is not a secret. Say so out loud rather than implying the boundary is
-tighter than it is.
-
-Bob's Merge-room reads widen automatically once alice grants him a room — `Merge` reduces
-to the caller's actual grants, so nothing else needs changing. Measured end to end on
-25.11: alice's `GRANT` took what bob sees of her rows through `all_messages` from 0 to
-22,413, and her
-`REVOKE` returned it to 0, and his direct read was denied again.
-
-**A member must hold SELECT on the Merge rooms themselves** for any of that to work —
-provisioning issues it. Without that grant the team room does not narrow to what the
-caller can read, it denies outright, which looks identical to isolation and is not.
-
-### Grant-option covers the whole grant
-
-Alice's grant-option is over `SELECT, INSERT, ALTER UPDATE, ALTER DELETE`, so she *can*
-hand bob the mutation rights on her own rooms, not merely `SELECT`. Her data, her call —
-but a share is `SELECT`-only by convention, and nothing in the engine enforces the
-convention. A `share` verb should encode it.
-
-> **OPEN:** a `share` / `unshare` CLI verb wrapping the three grants, so a member never
-> types SQL. Mirrors memory-house's `mh-share`.
-
-## Tier 2 — some rows, owner-mediated
-
-Row policies remain the only way to share a *subset*. The member asks the owner, who
-holds house-scoped policy rights:
-
-```sql
-GRANT SELECT ON mem.messages_alice TO bob;                -- privilege
-CREATE ROW POLICY share_alice_to_bob ON mem.messages_alice
-  FOR SELECT USING <predicate> TO bob;                    -- restriction
-```
-
-Both halves are required: a policy filters, it never grants. Privilege without a policy
-shares everything; a policy without privilege shares nothing.
-
-> **OPEN:** which predicates — by project, by date range, by `source`? Free-form SQL from
-> a member is an injection surface, so this likely wants a small fixed vocabulary.
-
-> **OPEN:** what a partial recipient's rollup should show. The rollup is a saved query
-> over `sessions_alice` and `messages_alice`, so a policy on `messages_alice` filters the
-> rows it aggregates and the recipient sees totals computed over their own slice — which
-> is arguably right, and is untested. Nothing extra has to be shared for it to work,
-> which is one fewer moving part than the stored view had.
-
-## Why the tiers are asymmetric
-
-Deliberate. Whole-room sharing is the common case, is coarse, and is safe to self-serve —
-the worst outcome is oversharing your own data. Partial sharing writes a filter into the
-house's access model, so it goes through the owner.
-
-## What sharing does not do
-
-**It is not a boundary between agents sharing one credential.** A crew running under a
-single member credential reads and writes the same rooms; any per-agent tag is
-client-supplied. Enforced separation needs separate ClickHouse users, which means
-separate rooms — this design one level down. Deferred with `agent_id`.
-
-## Not yet written
-
-- `memhouse share <member>` / `unshare`
-- how the dashboard and skills list rooms a caller can read but does not own — filter
-  `system.tables` by grants (it *is* grant-filtered: alice sees exactly her own three
-  three rooms, measured), or read the Merge rooms and group by `_table`
-- revocation when a member is removed while their rooms are shared outward

package/memhouse/per-member/provision.js

@@ -1,297 +0,0 @@
-#!/usr/bin/env node
-// mem — provision one member's rooms and grants. Idempotent; also the schema-rollout hook.
-//
-//   provision.js --member <name> [--merge] [--owner-grants]
-//
-// Run as the OWNER. Steps, all IF NOT EXISTS / re-runnable:
-//   1. create the member's three rooms from schema-member.sql.tpl
-//   2. grant the member their own three rooms, TWO statements each: MEMBER_PRIVS (not
-//      re-grantable), then `SELECT WITH GRANT OPTION`. The split is the point —
-//      MEMBER_PRIVS is exactly what the shipper uses and nothing that DEFINES an object,
-//      and attaching grant-option to `SELECT` alone makes a share read-only by
-//      construction. It is deliberately NOT `ALL`: that includes CREATE TABLE on the
-//      member's own room name, which lets them replace the room with a Merge over every
-//      member's and double the others' rows in the team room. See rooms.js.
-//
-//      THREE ROOMS, not four objects: the session rollup is a saved query over these
-//      same rooms, not a stored view, so it needs no object and no grant of its own.
-//   3. --merge: create/refresh the three Merge rooms, borrowing this member's columns
-//   4. grant the member SELECT on whichever Merge rooms exist — a Merge reduces to the
-//      rooms the caller can already read, so this is what makes the team room fail
-//      CLOSED rather than deny outright
-//
-// Grants are explicit, per room, and NEVER `ON mem.*` — a member who can read the whole
-// house can read every other member's rooms, which would make this a shared house with
-// longer table names. No wildcards are used anywhere; the only pattern in the design is
-// the Merge regex, anchored on a fixed room type.
-//
-// Env: MEM_URL / MEM_USER / MEM_PASSWORD / MEM_DB, falling back to MEMHOUSE_*. URL and
-// USER are REQUIRED — see the note at cfg. MEM_DB defaults to 'mem'.
-
-const fs = require('fs');
-const crypto = require('crypto');
-const path = require('path');
-// Named, not thrown as a raw MODULE_NOT_FOUND with a require stack. This runs as a
-// SUBPROCESS of `memhouse install`, after the admin path has already created a ClickHouse
-// user — so its failure mode is a half-provisioned house, and "Cannot find module" plus a
-// stack trace is the least useful thing to print at that moment. Seen for real in a
-// checkout where `npm install` had not been run.
-let createClient, ClickHouseLogLevel;
-try { ({ createClient, ClickHouseLogLevel } = require('@clickhouse/client')); }
-catch {
-  console.error("provision.js: dependency '@clickhouse/client' is not installed.");
-  console.error(`  From a checkout:      npm install --prefix ${path.join(__dirname, '..', '..')}`);
-  console.error(`  From an npm install:  ${require('./rooms').installCommand()}`);
-  process.exit(2);
-}
-const { ROOM_TYPES, mergeRooms, assertUsableMember, MEMBER_PRIVS, MEMBER_PROFILE, MEMBER_PROFILE_SETTINGS } = require('./rooms');
-
-const args = process.argv.slice(2);
-const flag = (n) => args.includes(`--${n}`);
-const opt = (n, d = null) => { const i = args.indexOf(`--${n}`); return i >= 0 ? args[i + 1] : d; };
-
-// Defaults MUST match what the shipper and CLI use, or an operator who overrides only
-// the thing that differs — a password, say — silently provisions rooms in a house the
-// product never reads, or fails to authenticate as a user that does not exist.
-//
-// Which is why there is no default URL or user any more, here either. This file CREATES
-// USERS AND GRANTS; pointing it at a guessed http://localhost:8123 as memhouse_root aims
-// the most privileged operation in the product at whatever house happens to be listening.
-// Observed: running it with no env at all made an authentication attempt against the
-// pilot's own ClickHouse.
-const cfg = {
-  url: process.env.MEM_URL || process.env.MEMHOUSE_URL,
-  username: process.env.MEM_USER || process.env.MEMHOUSE_USER,
-  password: process.env.MEM_PASSWORD || process.env.MEMHOUSE_PASSWORD || '',
-  database: process.env.MEM_DB || process.env.MEMHOUSE_DB || 'mem',
-};
-if (!cfg.url || !cfg.username) {
-  console.error('provision.js: no house given. Set MEM_URL and MEM_USER (or MEMHOUSE_URL/MEMHOUSE_USER).');
-  console.error('  This creates users and grants — it will not guess http://localhost:8123 as memhouse_root.');
-  process.exit(2);
-}
-
-// Statements are split on ';' at end of line — the templates contain no ';' inside a
-// statement body, and keeping the splitter dumb keeps the templates readable.
-function statements(sql) {
-  return sql
-    .split(/;\s*$/m)
-    .map((s) => s.replace(/^\s*--.*$/gm, '').trim())
-    .filter(Boolean);
-}
-
-/** Which of the three Merge rooms actually exist — a member may be provisioned first. */
-async function mergeRoomsPresent(client, database) {
-  const names = Object.values(mergeRooms());
-  const rs = await client.query({
-    query: `SELECT name FROM system.tables WHERE database = {db:String} AND name IN ({names:Array(String)}) ORDER BY name`,
-    query_params: { db: database, names },
-    format: 'JSONEachRow',
-  });
-  return (await rs.json()).map((r) => r.name);
-}
-
-async function main() {
-  const member = opt('member');
-  if (!member) { console.error('usage: provision.js --member <name> [--merge]'); process.exit(2); }
-  assertUsableMember(member);
-
-  const here = __dirname;
-
-  // Create the house with a client that has NOT selected it — on a fresh server the
-  // database does not exist yet, and selecting it fails before it can be created.
-  // See the note in shipper/ship.js: the driver's ERROR-level dump buries every
-  // refusal this file prints. MEMHOUSE_DEBUG=1 restores it.
-  const quiet = { level: process.env.MEMHOUSE_DEBUG ? ClickHouseLogLevel.DEBUG : ClickHouseLogLevel.OFF };
-  const bootstrap = createClient({ ...cfg, database: '', log: quiet });
-  await bootstrap.command({ query: `CREATE DATABASE IF NOT EXISTS ${cfg.database}` });
-  await bootstrap.close();
-
-  console.log(`[mem] provisioning in ${cfg.url} database '${cfg.database}' as '${cfg.username}'`);
-  const client = createClient({ ...cfg, log: quiet, clickhouse_settings: { async_insert: 0 } });
-
-  // 0. the member themselves.
-  //
-  // This file never created the ClickHouse user, so the path `memhouse install` prints and
-  // INSTALL.md repeats — `provision.js --member <name> --merge` — created three rooms and
-  // then died on `There is no role \`<name>\` in \`user directories\``, leaving orphan rooms
-  // that nothing removes and that the --merge step then folded into all_sessions. It also
-  // ignored --member-password. The documented second-member path did not work at all.
-  const existing = await client.query({
-    query: `SELECT name FROM system.users WHERE name = {n:String}`,
-    query_params: { n: member }, format: 'JSONEachRow',
-  });
-  if ((await existing.json()).length === 0) {
-    const pw = opt('member-password') || crypto.randomBytes(24).toString('base64url');
-    await client.command({ query: `CREATE USER ${member} IDENTIFIED BY '${pw.replace(/'/g, "\\'")}'` });
-    console.log(`[mem] created ClickHouse user '${member}'`);
-    if (!opt('member-password')) {
-      console.log(`[mem] password for '${member}': ${pw}`);
-      console.log('[mem] shown once — hand it over, or pass --member-password next time');
-    }
-    console.log(`[mem] they finish with: memhouse install --url ${cfg.url} --db ${cfg.database} --user ${member} --password '…'`);
-  } else if (flag('user-just-created')) {
-    // The caller made it moments ago and has already said so. Saying "already exists"
-    // here contradicts the line above it, and does so using the exact phrase that
-    // elsewhere means "someone else owns this handle, refusing" — which reads as a
-    // warning in the middle of a successful first install.
-    console.log(`[mem] using the ClickHouse user '${member}' just created — provisioning rooms`);
-  } else {
-    // NOT "already exists". That phrase is what the identity-takeover REFUSAL says, so
-    // reading it here — during a successful provision, and especially while resuming a
-    // first install that failed after CREATE USER — reads as a warning that someone else
-    // owns the handle. Both branches of this if now describe a success, in plain words.
-    console.log(`[mem] using the existing ClickHouse user '${member}' — provisioning rooms`);
-  }
-
-  // 1. rooms
-  const tpl = fs.readFileSync(path.join(here, 'schema-member.sql.tpl'), 'utf-8');
-  const roomSql = statements(tpl.replaceAll('{{MEMBER}}', member));
-  for (const q of roomSql) {
-    // allow_experimental_full_text_index: a no-op on 26.x, required on 25.x for the
-    // messages text indexes.
-    await client.command({ query: q, clickhouse_settings: { allow_experimental_full_text_index: 1 } });
-  }
-  // CREATE TABLE IF NOT EXISTS is a no-op on an existing room, so re-running provision.js
-  // over a room that has DRIFTED left it lossy while printing "rooms ready". The owner's
-  // route has to heal as well as create — it is the one route that always holds the rights.
-  {
-    const { templateColumns } = require('../shipper/ship');
-    const want = templateColumns(tpl);
-    for (const ty of ROOM_TYPES) {
-      const room = `${ty}_${member}`;
-      const rs = await client.query({
-        query: 'SELECT name FROM system.columns WHERE database = {d:String} AND table = {n:String}',
-        query_params: { d: cfg.database, n: room }, format: 'JSONEachRow',
-      });
-      const have = new Set((await rs.json()).map((r) => r.name));
-      if (!have.size) continue;
-      for (const c of (want[ty] || [])) {
-        if (have.has(c.name)) continue;
-        await client.command({
-          query: `ALTER TABLE ${cfg.database}.${room} ADD COLUMN IF NOT EXISTS ${c.name} ${c.type}`,
-          clickhouse_settings: { allow_experimental_full_text_index: 1 },
-        });
-        console.log(`[mem] added missing column ${room}.${c.name}`);
-      }
-    }
-  }
-  console.log(`[mem] rooms ready for '${member}': ${ROOM_TYPES.map((t) => `${t}_${member}`).join(', ')}`);
-
-  // 2. grants — two statements per room, and the split is the point.
-  //
-  // ALL, NOT re-grantable: the member owns their room outright, DROP and TRUNCATE
-  // included, because it is their memory to destroy. It also covers the mutation
-  // privileges the shipper needs without naming them — the shipper clears a session's
-  // rows before re-inserting, and which of ALTER UPDATE / ALTER DELETE a server demands
-  // varies by version (`DELETE FROM` is a lightweight delete, implemented as
-  // `ALTER TABLE … UPDATE _row_exists = 0`, so 25.11 wants ALTER UPDATE where 26.7 wanted
-  // ALTER DELETE). Granting one and not the other produces a pass that fails elsewhere.
-  //
-  // SELECT, re-grantable: a share is READ-ONLY BY CONSTRUCTION rather than by convention.
-  // `GRANT ALL … WITH GRANT OPTION` expands to 45 privileges on 26.7 — DROP TABLE,
-  // TRUNCATE, CREATE ROW POLICY, SYSTEM DROP REPLICA among them — and every one of those
-  // would become something a member could hand to a colleague while meaning "let them
-  // read my sessions". Measured: with this split, `GRANT SELECT … TO bob` succeeds and
-  // `GRANT DROP TABLE … TO bob` is refused 497.
-  // NOT `GRANT ALL`. On 26.7 that expands to 45 privileges including CREATE TABLE **on
-  // the member's own room name** — which means a member owns the NAME, not just the data,
-  // and can put any engine behind it. Measured on both versions:
-  //
-  //     DROP TABLE messages_alice;                                      -- allowed
-  //     CREATE TABLE messages_alice AS all_messages
-  //       ENGINE = Merge('<db>','^messages_');                          -- allowed
-  //
-  // `all_messages` is Merge(db,'^messages_'), so it then contains a Merge over its own
-  // namespace and every OTHER member's rows are counted twice in the team room: a house
-  // reading alice 6030 / bob 2401 / carol 12 became bob 4802 / carol 24, silently, no
-  // error. Confidentiality survives — the Merge still narrows by grants, so alice reads
-  // nothing new — but integrity does not, and a team-wide number is the whole point of
-  // the room. SCHEMA.md already records the same failure reached by accident; this is the
-  // same failure reachable on purpose by any member.
-  //
-  // So: the privileges the shipper actually uses, and nothing that lets a member define
-  // an object. ALTER UPDATE and ALTER DELETE both, 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 UPDATE where 26.7 wanted DELETE).
-  // ALTER ADD COLUMN for ensureSchema's rollout. No CREATE TABLE, no DROP TABLE, no
-  // TRUNCATE: the admin who provisioned the room is the one who can replace it.
-  //
-  // SELECT is re-grantable so a share is READ-ONLY BY CONSTRUCTION rather than by
-  // convention — `GRANT SELECT … TO bob` succeeds, `GRANT DROP TABLE … TO bob` is 497.
-  for (const t of ROOM_TYPES) {
-    const room = `${cfg.database}.${t}_${member}`;
-    await client.command({ query: `GRANT ${MEMBER_PRIVS} ON ${room} TO ${member}` });
-    await client.command({ query: `GRANT SELECT ON ${room} TO ${member} WITH GRANT OPTION` });
-  }
-  console.log(`[mem] granted ${MEMBER_PRIVS} on 3 rooms to '${member}'; SELECT is the only re-grantable one`);
-
-  // 2b. A settings profile with CEILINGS, not just defaults.
-  //
-  // Every isolation test passed on confidentiality and none existed for availability: a
-  // member could `SETTINGS max_memory_usage=100000000000`, `max_execution_time=0` and
-  // `max_threads=64` on a shared house, and take the server down for everyone. The
-  // constraint form (`MAX`) is what makes it a ceiling — a plain default is advisory and a
-  // member simply overrides it, which is what they were doing.
-  //
-  // Generous on purpose: a full re-ship of a large house is a big INSERT, and the point is
-  // to stop one member exhausting the box, not to make honest work fail.
-  // CREATE ... OR REPLACE, which this used, DETACHES every user already assigned to the
-  // profile. One shared profile plus a replace on every provision meant that adding a
-  // second member silently stripped the first member's ceilings — measured: provision
-  // kyle, then provision lena, and `SHOW CREATE USER kyle` no longer carries the profile
-  // at all. In a three-member house only the most recently provisioned member had any
-  // limit, and nothing said so.
-  //
-  // CREATE IF NOT EXISTS + ALTER updates the same object in place and keeps every existing
-  // assignment, so one provision now brings ALL members up to the current settings —
-  // which is also what makes the async_insert pin reach members provisioned earlier.
-  // SETTINGS NONE first, because ALTER only upserts what it lists: a setting dropped from
-  // MEMBER_PROFILE_SETTINGS in a later version would otherwise stay enforced forever on
-  // every upgraded house, and anything an operator had added to a profile of the same name
-  // would survive too. Clearing then applying gives the same absolute state OR REPLACE had,
-  // without its detachment.
-  //
-  // The gap between the two statements is admin-only and sub-second — but it is not
-  // self-healing: a crash or a dropped connection between them leaves the profile EMPTY,
-  // so every member is unbounded until someone provisions again. Nothing here notices, and
-  // `doctor` does not check the profile. Re-run provision if one dies mid-way.
-  try {
-    await client.command({ query: `CREATE SETTINGS PROFILE IF NOT EXISTS ${MEMBER_PROFILE}` });
-    await client.command({ query: `ALTER SETTINGS PROFILE ${MEMBER_PROFILE} SETTINGS NONE` });
-    await client.command({ query: `ALTER SETTINGS PROFILE ${MEMBER_PROFILE} SETTINGS ${MEMBER_PROFILE_SETTINGS}` });
-    await client.command({ query: `ALTER USER ${member} SETTINGS PROFILE '${MEMBER_PROFILE}'` });
-    console.log(`[mem] settings profile '${MEMBER_PROFILE}' applied to '${member}' (memory, time and thread ceilings)`);
-  } catch (e) {
-    // A server where the admin cannot create profiles still gets a working member; say so
-    // rather than failing the provision.
-    console.log(`[mem] note: could not apply the '${MEMBER_PROFILE}' settings profile — ${e.message}`);
-    console.log('[mem] the member works, but nothing bounds their query resources on this server');
-  }
-
-  // 3. Merge rooms
-  if (flag('merge')) {
-    const mtpl = fs.readFileSync(path.join(here, 'schema-merge.sql.tpl'), 'utf-8');
-    for (const q of statements(mtpl.replaceAll('{{TEMPLATE_MEMBER}}', member))) {
-      await client.command({ query: q });
-    }
-    console.log('[mem] merge rooms ready: all_sessions, all_messages, all_tool_calls');
-  }
-
-  // 4. Merge-room grants. Broad on purpose, and safe for the reason the whole layout
-  // rests on: a Merge table reduces to the underlying rooms the CALLER holds grants for.
-  // Measured on 25.11 — bob with SELECT on all_messages and nothing on messages_alice
-  // reads his own row and none of alice's, with `_table` showing only messages_bob, and
-  // no error. Withholding this grant does not make anything safer; it makes the team
-  // room deny outright instead of failing closed, which is a different and worse thing.
-  const merged = await mergeRoomsPresent(client, cfg.database);
-  for (const room of merged) {
-    await client.command({ query: `GRANT SELECT ON ${cfg.database}.${room} TO ${member}` });
-  }
-  if (merged.length) console.log(`[mem] granted SELECT on ${merged.join(', ')} to '${member}'`);
-  else console.log('[mem] no merge rooms yet — run once with --merge to create them');
-
-  await client.close();
-}
-
-main().catch((e) => { console.error(`[mem] provision failed: ${e.message}`); process.exit(1); });