memhouse 0.7.0 → 0.7.1

package/bin/memhouse.js

@@ -673,7 +673,12 @@ ${mergeGrants}
 -- CONST, not MAX: a plain default is advisory, and MAX is not enough either because 0 means
 -- UNLIMITED in ClickHouse and 0 satisfies any MAX. Measured — with a MAX ceiling in force,
 -- SETTINGS max_memory_usage = 0 was accepted and the ceiling was gone.
-CREATE SETTINGS PROFILE OR REPLACE ${MEMBER_PROFILE} SETTINGS ${MEMBER_PROFILE_SETTINGS};
+-- CREATE ... OR REPLACE, which this used, DETACHES every user already on the profile, so
+-- provisioning a second member silently stripped the first member's ceilings. IF NOT
+-- EXISTS + ALTER edits the same object in place and keeps every assignment.
+CREATE SETTINGS PROFILE IF NOT EXISTS ${MEMBER_PROFILE};
+ALTER SETTINGS PROFILE ${MEMBER_PROFILE} SETTINGS NONE;
+ALTER SETTINGS PROFILE ${MEMBER_PROFILE} SETTINGS ${MEMBER_PROFILE_SETTINGS};
 ALTER USER ${member} SETTINGS PROFILE '${MEMBER_PROFILE}';
 `;
 }
@@ -756,7 +761,16 @@ async function adminBootstrap(cfg, admin) {
   // 3. rooms, 4. grants, 5. Merge rooms + their grant — provision.js owns all of it, so
   // there is one implementation of the grant set rather than two that drift.
   const provision = path.join(REPO_ROOT, 'memhouse', 'per-member', 'provision.js');
-  const rc = spawnSync(process.execPath, [provision, '--member', admin.member, '--merge'], {
+  // Tell it who made the user. Without this the child finds a user that exists — because
+  // THIS command created it two lines ago — and says so, producing two consecutive lines
+  // of one command's output that contradict each other:
+  //     ✓ created ClickHouse user 'henry'
+  //     [mem] ClickHouse user 'henry' already exists — provisioning rooms only
+  // and "already exists" is the exact phrase memhouse uses for the identity-takeover
+  // REFUSAL, so a first-time installer reads a success as a warning about someone else.
+  const provisionArgs = [provision, '--member', admin.member, '--merge'];
+  if (createdUser) provisionArgs.push('--user-just-created');
+  const rc = spawnSync(process.execPath, provisionArgs, {
     stdio: 'inherit',
     env: { ...process.env, MEM_URL: cfg.url, MEM_USER: admin.user, MEM_PASSWORD: admin.password, MEM_DB: cfg.db },
   });

package/memhouse/per-member/SHARING.md

@@ -37,6 +37,53 @@ unforgeable **by members**, since `EXECUTE AS` is a grantable privilege they do
 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

package/memhouse/per-member/provision.js

@@ -130,8 +130,18 @@ async function main() {
       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 {
-    console.log(`[mem] ClickHouse user '${member}' already exists — provisioning rooms only`);
+    // 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
@@ -226,8 +236,30 @@ async function main() {
   //
   // 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 OR REPLACE ${MEMBER_PROFILE} SETTINGS ${MEMBER_PROFILE_SETTINGS}` });
+    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) {

package/memhouse/per-member/rooms.js

@@ -103,6 +103,23 @@ const MEMBER_PROFILE_SETTINGS = [
   'max_execution_time = 600 MIN 1 MAX 600',
   'max_threads = 16 MIN 1 MAX 16',
   'max_result_rows = 10000000 MIN 1 MAX 10000000',
+  // Provenance, pinned server-side rather than trusted to every client.
+  //
+  // `user_id MATERIALIZED currentUser()` is what records who wrote a row — but 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. An unattributed
+  // row is invisible to every identity-bound path at once, including its own owner's
+  // `reset`.
+  //
+  // The shipper already passes async_insert=0 on every insert, so memhouse itself was
+  // never the risk. The risk is everything ELSE holding a member credential — an agent
+  // following the /memhouse:sql skill, a migration script, a psql-habit one-liner. CONST
+  // makes the house refuse (SETTING_CONSTRAINT_VIOLATION) instead of silently accepting
+  // rows nobody owns, which is the difference between a guarantee and a convention.
+  // `doctor` still checks for blank user_id — that stays, as the detector for rows
+  // written before this profile existed.
+  'async_insert = 0 CONST',
 ].join(', ');
 
 // ClickHouse usernames are permissive; room names are not. Refuse anything that would

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "memhouse",
-  "version": "0.7.0",
+  "version": "0.7.1",
   "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": {