memhouse 0.17.0 → 0.18.0

package/memhouse/delivery/PROMPT.md

@@ -36,11 +36,12 @@ FIRST. Only say you don't know after a search comes back empty.
 
 Without skills, query directly.
 
-**Table names.** The house's rooms are three plain, shared tables — `messages`,
-`sessions`, `tool_calls` — in the connection's database. Everyone in the house writes
-into the same tables; `user_id` (server-stamped) says whose row it is and `host` says
-which machine. Query the whole house by default; add `WHERE user_id = '<name>'` for one
-person. **There is no `sessions_v` object** — the rollup is a saved query, and
+**Table names.** The rooms are `messages`, `sessions`, `tool_calls` in the connection's
+database — unless this is a shared house, where they carry the member's own prefix
+(`alice_messages`). `memhouse rooms` prints what yours are actually called; a bare
+`FROM messages` is not a table you have in a shared house. `user_id` (server-stamped)
+says whose row it is and `host` says which machine. To read across several members, UNION ALL over the rooms you hold — naming a room
+you do not hold is an error rather than a silent omission. **There is no `sessions_v` object** — the rollup is a saved query, and
 `memhouse sessions-query` prints it ready to drop into a `FROM (...) AS c`.
 
 **One session can be stored more than once.** The shipper never deletes: when an editor

package/memhouse/delivery/kernel-install.md

@@ -80,8 +80,10 @@ user so the stamp cannot be skipped). Her machines are told apart by `host`.
 **A house is shared by its housemates.** The tables are common; `user_id` and `host` say
 who wrote what, and `WHERE user_id = 'alice'` is one person. The boundary is the
 DATABASE: a member of `mem` holds nothing on any other database, so two agencies on one
-kernel ClickHouse cannot read each other. The model is collaborative — housemates trust
-each other with the house; a separate house is the isolation mechanism.
+kernel ClickHouse cannot read each other. WITHIN a house, members hold their own rooms
+and nothing else — housemates are isolated from each other by grant, not by trust, and
+each can verify it with `SHOW GRANTS`. A separate house remains the boundary between
+groups that should not know of each other at all.
 
 Row policies are still the only way to share a *subset* of rows, which is owner-mediated
 and documented in `SHARING.md` — they are not how isolation works.

package/memhouse/delivery/plugin/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "mem",
   "description": "Conversation memory for AI agents over the memhouse typed ClickHouse store: recall past sessions and answer from them, run analytics, check the house, bring people in, and administer the server. Skills install as /mem:recall, /mem:sql, /mem:house, /mem:access, and /mem:admin.",
-  "version": "0.17.0",
+  "version": "0.18.0",
   "author": {
     "name": "Ramazan Polat"
   },

package/memhouse/delivery/plugin/reference/HOUSE.md

@@ -8,13 +8,20 @@ or wrong everywhere.
 
 ## What this is
 
-A **house** is a ClickHouse **database**. Its **rooms** are three shared tables:
-`sessions`, `messages`, `tool_calls`. Everyone granted on the database writes into the
-same tables; the server stamps who. There is no per-user table and no cloud — the
-database *is* the boundary, and a house's grants reach nothing outside it.
+A **house** is a ClickHouse **database** — on the user's machine, their server, or a
+hosted ClickHouse; memhouse runs no service of its own. Its **rooms** are tables —
+`sessions`, `messages`, `tool_calls` — and the server stamps who wrote every row. A
+house's grants reach nothing outside it.
 
-A **member** owns one house. An **administrator** owns the ClickHouse. `memhouse whoami`
-says which you are holding.
+Every member's rooms are named for them — `mem.alice_messages`, `mem.alice_sessions`,
+`mem.alice_tool_calls` — and one grant covers exactly those: `ON mem.alice_*`. Housemates
+keep their own rooms beside yours and cannot read them, list them, or grant them onward;
+you cannot read theirs. `SHOW GRANTS` shows you the one line you hold. **A bare
+`FROM messages` names nothing you have** — the `q()` below prefixes room names with your
+member name for you, and `memhouse rooms` prints what yours are called.
+
+An **operator** owns the ClickHouse itself; an **admin credential** is what proves it.
+`memhouse whoami` says which you are holding.
 
 Rows arrive from a **shipper** that parses local transcripts from 17 editors. It only
 ever inserts. Nothing in memhouse runs an LLM over your data — these skills retrieve
@@ -45,7 +52,8 @@ if [ -z "${MEMHOUSE_URL:-}" ] || [ -z "${MEMHOUSE_USER:-}" ]; then
 fi
 
 q() {  # read-only by construction; every read path should use this
-  curl -sS --fail-with-body --user "$MEMHOUSE_USER:${MEMHOUSE_PASSWORD:-}" \
+  sed -E "s/([[:space:](]|^)(FROM|JOIN)[[:space:]]+(sessions|messages|tool_calls|meta|events)([[:space:];,)]|\$)/\1\2 ${MEMHOUSE_USER}_\3\4/g" \
+  | curl -sS --fail-with-body --user "$MEMHOUSE_USER:${MEMHOUSE_PASSWORD:-}" \
     --data-binary @- "$MEMHOUSE_URL/?database=${MEMHOUSE_DB:-$MEMHOUSE_USER}&readonly=1"
 }
 q <<'SQL'
@@ -56,11 +64,22 @@ SQL
 `readonly=1` is a ClickHouse-side setting: even a mis-generated `DROP` is refused by the
 server, not by discipline.
 
-**Reading someone else's house.** A share is a read-only `GRANT SELECT` on their
-database. `SHOW DATABASES` lists what your credential may read; anything that is not
-`system`, `information_schema`, `default` or your own `$MEMHOUSE_DB` was shared with you.
-To read it, change `database=` in the URL and leave the table names bare. Say whose house
-an answer came from.
+**The `sed` is what makes every query below work in both layouts** — write room names
+bare and it supplies the prefix when there is one. It rewrites only after `FROM`/`JOIN`,
+so a needle like `LIKE '%messages%'` is untouched, and `FROM yigit_messages` is left
+alone — the room name must follow whitespace, and there is none inside `yigit_messages`.
+With no prefix set it expands to nothing and the query passes through verbatim.
+
+It is spelled with `[[:space:]]` classes rather than `\b` because **BSD `sed` does not
+support `\b`**: on macOS the `\b` form matched nothing and sent the query through
+unprefixed. That fails loudly as `UNKNOWN_TABLE` rather than quietly reading wrong rows,
+which is the right way round — but it fails.
+
+**Reading a housemate's memory.** A share is `GRANT SELECT ON mem.<them>_*` — their
+rooms, not the database. `SHOW TABLES` lists exactly what you may read: your own rooms plus
+any shared with you. Name a housemate's rooms in full (`FROM yigit_messages`); the `q()`
+rewrite leaves an already-prefixed name alone, since applying yours would point at the
+wrong rooms. Say whose memory an answer came from.
 
 ---
 

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

@@ -84,13 +84,13 @@ into a transcript on disk. The CLI passes it to one process and never echoes it.
 5. **Say whether the house was fresh** — `SELECT count() FROM <db>.messages` reads 0 for a
    new one. Second line of defence behind step 3's refusal.
 
-6. **Write the message the user will send.** They are handing over a file plus an
-   explanation; compose it rather than making them. Cover: what memhouse is in a sentence
-   or two; that the attached file IS a password (do not forward, do not paste in chat);
-   `npm install -g memhouse` (Node 24+) then `memhouse install --env invite-<name>.env`;
-   that install offers to change the password to one only they know and then deletes the
-   file, so they should say yes; `memhouse onboard` to start shipping and `memhouse status`
-   to check; and that their house is theirs alone unless they run `/mem:access share`.
+6. **Write the message the user will send.** `invite` wrote TWO files beside each other:
+   `invite-<name>.env` (the credential, one-time) and `MEMHOUSE-INVITATION.md` (the steps,
+   nothing secret — install, verify, what they own, things to try). The guide does the
+   explaining, so the message is short: what memhouse is in a sentence; that the `.env` IS a
+   password (do not forward, do not paste in chat); open `MEMHOUSE-INVITATION.md` and follow
+   it. If `memhouse --version` shows a pre-release (a `-` in it), the invitee also needs the
+   tarball this build came from (`memhouse nightly --out …`); the guide says so and names it.
 
    If they are REPLACING an existing credential, add `memhouse ship --full` — a plain
    incremental pass skips sessions the new house has no record of, so their history would
@@ -105,7 +105,7 @@ for this** — partial sharing has four ways to go wrong quietly, and the comman
 each one:
 
 ```
-memhouse share <user>                          the whole house
+memhouse share <user>                          everything you own
 memhouse share <user> --only project=memhouse  just one project
 memhouse share <user> --only session=<id>      just one conversation
 memhouse share --list                          who can read it, and how much

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

@@ -8,7 +8,7 @@ allowed-tools: Bash
 
 # /mem:admin — operate the house as its administrator
 
-A member owns one database. An **administrator** owns the ClickHouse: every house, every
+A member owns a house, or rooms in one. An **administrator** owns the ClickHouse: every house, every
 account, every grant. This skill is the second one, and it is the only skill allowed to
 act outside the caller's own house.
 

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

@@ -83,12 +83,12 @@ thin. Say what could not be seen rather than guessing.
 SHOW DATABASES
 -- who you have granted (memhouse's own record of it)
 SELECT substring(key, 7) AS user, value AS state
-FROM house_meta FINAL WHERE key LIKE 'share:%' ORDER BY key
+FROM meta FINAL WHERE key LIKE 'share:%' ORDER BY key
 -- everyone on the server (names only — every member holds SHOW USERS)
 SELECT name FROM system.users ORDER BY name
 ```
 
-That `house_meta` list is memhouse's own note-keeping, not ClickHouse's grant table —
+That `meta` list is memhouse's own note-keeping, not ClickHouse's grant table —
 a member cannot read `system.grants`. Present it as "what memhouse recorded", and say
 that a grant made by hand would not appear.
 

package/memhouse/flags.js

@@ -16,16 +16,17 @@ const COMMAND_FLAGS = {
   null: [], help: [], version: [],
   whoami: ['admin'],
   share: ['only', 'revoke', 'list'],
-  discover: [], stats: [], stop: [], doctor: [], 'sessions-query': [],
+  discover: [], stats: [], stop: [], doctor: [], 'sessions-query': [], rooms: [], members: ['db','admin-user','admin-password'],
   status: [], start: [],
   onboard: ['url', 'user', 'password', 'db', 'port', 'no-ship', 'target', 'house-port', 'tag', 'local'],
   install: ['url', 'user', 'password', 'db', 'port', 'no-ship', 'env', 'print-sql', 'member',
-    'member-password', 'admin-user', 'admin-password', 'ensure-schema', 'rotate-password', 'force'],
-  setup: ['url', 'user', 'password', 'db', 'port'],
+    'member-password', 'admin-user', 'admin-password', 'ensure-schema', 'rotate-password', 'force',
+    'editors', 'claude-roots', 'channel'],
+  setup: ['url', 'user', 'password', 'db', 'port', 'admin-user', 'admin-password', 'editors', 'claude-roots', 'channel'],
   ship: ['full', 'loop', 'ensure-schema'],
   search: ['limit'],
   resume: [],
-  update: ['check', 'migrate', 'no-install'],
+  update: ['check', 'migrate', 'no-install', 'channel'],
   reset: ['all-origins'],
   invite: ['url', 'db', 'out', 'admin-user', 'admin-password', 'adopt', 'print-sql',
     'allow-local', 'member-password'],

package/memhouse/house/HOUSE.md

@@ -1,12 +1,18 @@
-# The house — a database, three shared rooms
+# The house — a database, and the rooms in it
 
 **A house is a ClickHouse database.** Any database, named whatever its people name it —
-`polat`, `team_a`, even `default`. Its rooms are three plain tables: `sessions`,
-`messages`, `tool_calls`. There is nothing else to provision: no per-member tables, no
-Merge rooms, no views, no settings profile.
+`polat`, `team_a`, even `default`. Its rooms are tables: `sessions`, `messages`,
+`tool_calls`. No views, no Merge rooms, no settings profile.
 
-**Everyone in the house writes into the same tables**, each with their own credential,
-and two columns say where every row came from:
+**Every member's rooms are named for them, and one grant covers them.** `mem.polat_*`
+for polat, `mem.alice_*` for alice, in the same database — `mem` unless somebody has a
+reason. The grant is `GRANT … ON mem.polat_* TO polat WITH GRANT OPTION`: it lets the
+member create and rebuild their own rooms, share them, and reach nothing else. Nobody is
+granted the database itself. A house with one member is a house of one, not a different
+kind of house — a colleague joins as one more member and nothing about the first changes.
+`roomNames()` in `house.js` is the only place a table name is produced.
+
+Two columns say where every row came from:
 
 | Column | Meaning | Comes from |
 |---|---|---|
@@ -31,9 +37,17 @@ shipper create and evolve the rooms (`ship.js --ensure-schema`) — no admin has
 memhouse code. Joining a ClickHouse that happens to run a kernel is the same three
 statements: a database and a credential, nothing else.
 
-The model is **collaborative**: housemates trust each other with the house. Narrower
-grants can be layered on later if a team wants them; the isolation mechanism between
-groups that do NOT trust each other is a separate house.
+**Housemates do not have to trust each other with the house.** They used to: everyone
+held `ALL` on the database, and the isolation mechanism between parties who should not
+see each other was a separate house. That shape leaked — one member could `GRANT SELECT
+ON db.* TO <outsider>` and hand over a housemate's transcripts, with no admin and no
+notification.
+
+In a shared house each member is granted their own rooms and nothing else, so isolation
+lives INSIDE one house and is checkable: `SHOW GRANTS` lists what you hold, and `SHOW
+TABLES` does not list what you do not. A separate house is still the boundary between
+groups that should not even know of each other — names leak across a shared house even
+when content does not.
 
 ## One user on two machines, same session id
 
@@ -91,9 +105,9 @@ for writes and DDL.
 
 Two tables that are not rooms:
 
-- `house_meta` — house-wide key/value, latest-wins: `schema_version`, and the memhouse
+- `meta` — house-wide key/value, latest-wins: `schema_version`, and the memhouse
   version each member last shipped with.
-- `house_events` — append-only: migrations (`pending` → `applied` | `failed`), version
+- `events` — append-only: migrations (`pending` → `applied` | `failed`), version
   changes, schema observations, each with actor, host and row counts. Nothing is updated
   in place, so a migration that failed and was retried reads as exactly that.
 

package/memhouse/house/house.js

@@ -1,9 +1,8 @@
 // The house.
 //
-// A house is a ClickHouse DATABASE — any database, named whatever its people name it
-// (`polat`, `team_a`, even `default`). Its rooms are three plain tables: `sessions`,
-// `messages`, `tool_calls`. Everyone in the house writes into the SAME tables, each with
-// their own credential, and two columns say who and where every row came from:
+// A house is a ClickHouse DATABASE, `mem` by default. Its rooms are tables — `sessions`,
+// `messages`, `tool_calls` — one set per member, named for them, and two columns say who
+// and where every row came from:
 //
 //   user_id  String MATERIALIZED currentUser()   — stamped by the server, unforgeable by
 //                                                  clients (async_insert is pinned to 0
@@ -12,19 +11,30 @@
 //   host     LowCardinality(String)              — the machine's fingerprint, minted once
 //                                                  per install (../host.js)
 //
-// That pair IS the provenance model. Alice and Bob point their shippers at `team_a` and
-// both write; `WHERE user_id = 'alice'` is one person, `WHERE host = '…'` is one machine.
-// The model is collaborative — housemates trust each other with the house — and the
-// boundary between houses is the database: joining someone's ClickHouse takes a database
-// and a credential (`GRANT ALL ON team_a.* TO alice`), nothing else, because ALL on your
-// own database reaches nothing outside it.
+// That pair IS the provenance model.
 //
-// THIS REPLACES THE PER-MEMBER LAYOUT. Rooms were `sessions_<member>` with per-member
-// grants, Merge rooms for team reads, and isolation between members of one database.
-// All of it is gone: suffixed names made every client resolve its room names first (and
-// `FROM messages` a documented trap), the Merge rooms existed only to undo the
-// splitting, and per-member isolation inside a shared house solved an adversarial
-// problem the product does not have. Separate houses isolate; one house shares.
+// ONE LAYOUT. A house is a database — `mem` unless somebody has a reason — and every
+// member's rooms in it carry the member's name: `mem.alice_messages`, `mem.polat_messages`.
+// A member holds one grant, on the wildcard `mem.<name>_*`, and nothing else in the
+// database. That is the whole access model, and roomNames() below is the only place a
+// table name is produced.
+//
+//   alone on a laptop        mem.polat_*            a house of one
+//   a team on one server     mem.polat_*, mem.alice_*
+//   an agency on a kernel    the same, in the kernel's `mem`
+//
+// Nobody ever holds ALL ON <db>.*. That grant is dynamic — it covers rooms created later —
+// and it is what turned two members in one database into a leak: either could read and
+// re-grant the other's transcripts, measured. The wildcard reaches nothing outside the
+// member's own name: measured, a member cannot create, read, list or re-grant a
+// housemate's rooms, and can read their own grant back with SHOW GRANTS in one line.
+//
+// THIS FILE HAS SAID THREE OTHER THINGS. Shared tables with row policies (0.4.0: policies
+// are permissive and OR'd, a catch-all fails open). Suffixed per-member rooms with Merge
+// rooms over them (0.8.0: removed because clients had to resolve names first and
+// isolation "solved a problem the product did not have" — the second half was wrong).
+// Then a house per member with `ALL ON db.*`, plus a prefixed variant beside it, plus the
+// machinery to keep the two from meeting. All three were special cases of this one.
 //
 // `sessions_v` IS A SAVED QUERY, NOT AN OBJECT — substituted into the same `FROM … AS c`
 // position a view name would occupy, running under the caller's own credential. It was
@@ -38,7 +48,11 @@ const ROOM_TYPES = ['sessions', 'messages', 'tool_calls'];
  * them, the shipper's guards do not require them, and a member who cannot create them
  * still ships normally.
  */
-const META_TYPES = ['house_meta', 'house_events'];
+// `<member>_meta` / `<member>_events` since the one-layout: every row in them is about ONE
+// member (their schema version, their machines, their last ship, their shares), so the old
+// `house_` prefix named the wrong unit. A pre-one-layout house still has `house_meta` /
+// `house_events`; the shipper's legacy guard names the rename.
+const META_TYPES = ['meta', 'events'];
 
 /**
  * What generation of the schema a house is at. Bumped only when existing rooms have to be
@@ -75,7 +89,7 @@ const SUPPORTED_SCHEMAS = [2];
 
 /**
  * The floor a house may set under its writers, recorded by `memhouse migrate` in
- * house_meta['min_writer_schema']. Today it equals SCHEMA_VERSION; a future
+ * meta['min_writer_schema']. Today it equals SCHEMA_VERSION; a future
  * back-compatible generation can hold it one step lower for a grace window.
  */
 const MIN_WRITER_SCHEMA = 2;
@@ -233,15 +247,19 @@ const ROOM_MATERIALIZED = {
   tool_calls: ['user_id'],
 };
 
-function currentParse(table, epochSource = table) {
+function currentParse(table, epochSource = table, physical = null) {
+  // `table` names the ROOM (for the materialized-column lookup); `physical` is what goes
+  // into the FROM, which differs whenever a prefix is in play.
   const extra = (ROOM_MATERIALIZED[table] || ['user_id']).join(', ');
+  const from = physical || table;
+  const epochFrom = physical ? physical.replace(new RegExp(`${table}$`), epochSource) : epochSource;
   return `(
     SELECT *, ${extra}
-    FROM ${table} FINAL
+    FROM ${from} FINAL
     WHERE origin != 'ship'
        OR (session_id, user_id, epoch) IN (
             SELECT session_id, user_id, max(epoch)
-            FROM ${epochSource}
+            FROM ${epochFrom}
             WHERE origin = 'ship'
             GROUP BY session_id, user_id)
   )`;
@@ -302,24 +320,54 @@ const READ_SETTINGS = { final: 1, join_use_nulls: 1 };
  * name it produces. See ship.js's delete, which must BIND the user rather than call
  * currentUser() inside a mutation, where it is not evaluated in the caller's context.
  */
+/**
+ * The table a room type lands in. THE naming rule, and the only copy of it.
+ *
+ * ONE LAYOUT. Every member's rooms carry the member's own name: `mem.alice_messages`,
+ * and `mem.polat_messages` even when polat is the only one in there. A house with one
+ * member is a house of one, not a different kind of house — so there is no second case
+ * here, no prefix to configure, and nothing for an invite file to carry.
+ *
+ * Depends on nothing but the member, so a caller holding only a config can name a table
+ * without a server round-trip. That matters: when the rule lived only inside roomNames(),
+ * callers that could not afford `SELECT currentUser()` spelled tables by hand instead —
+ * eight of them, all swallowing the error — and a house silently had no metadata plane.
+ */
+function physicalRoom(type, user) {
+  if (!user) throw new Error(`physicalRoom(${type}): a room belongs to a member, and none was given`);
+  return `${user}_${type}`;
+}
+
+/** The wildcard every grant to a member is scoped to: `<member>_*`. */
+function roomPattern(user) {
+  if (!user) throw new Error('roomPattern: a member is required');
+  return `${user}_*`;
+}
+
 function roomNames(user) {
-  const out = { member: user, user };
+  if (!user) throw new Error('roomNames: a member is required');
+  const out = { member: user, user, pattern: roomPattern(user) };
+  // Every room name in the codebase comes from physicalRoom() above — through this
+  // function where a caller has the rooms, directly where it has only a member name.
+  const phys = (t) => physicalRoom(t, user);
+  out.physical = {};
+  for (const t of [...ROOM_TYPES, ...META_TYPES]) out.physical[t] = phys(t);
   // The raw table names — for INSERT, for DDL, and for the shipper's own bookkeeping
   // reads, which have to see every epoch to decide which one to write next.
-  for (const t of ROOM_TYPES) out[`${t}_raw`] = t;
+  for (const t of ROOM_TYPES) out[`${t}_raw`] = phys(t);
   // What everything else gets. `sessions` is unfiltered: it is one metadata row per
   // session by construction, latest-wins, and carries no epoch anyone may read.
-  out.sessions = 'sessions';
-  out.messages = currentParse('messages');
+  out.sessions = phys('sessions');
+  out.messages = currentParse('messages', 'messages', phys('messages'));
   // tool_calls takes its epoch from MESSAGES, not from itself. A parse that produces
   // messages but NO tool calls is ordinary — a compaction can remove every assistant turn
   // that called something — and it writes zero rows into this room at the new epoch. Asked
   // for its own max(epoch), the room would answer with the SUPERSEDED epoch and serve the
   // old parse's tool calls beside the new parse's messages. Both rooms are written by the
   // same pass at the same epoch, so messages is the authority for both.
-  out.tool_calls = currentParse('tool_calls', 'messages');
+  out.tool_calls = currentParse('tool_calls', 'messages', phys('tool_calls'));
   // The house's own record of itself — plain names, nothing to filter.
-  for (const t of META_TYPES) { out[t] = t; out[`${t}_raw`] = t; }
+  for (const t of META_TYPES) { out[t] = phys(t); out[`${t}_raw`] = phys(t); }
   out.sessions_v = sessionsRollup(out);
   return out;
 }
@@ -337,7 +385,42 @@ async function resolveRooms(client) {
   return roomNames(await currentUser(client));
 }
 
+/**
+ * The text-index DDL for servers before the tokenizer grammar changed. 25.8 spells a
+ * tokenizer as a quoted name with options — `text(tokenizer = 'ngram', ngram_size = 3)`,
+ * `text(tokenizer = 'default')` — and rejects the function form with "Expected literal";
+ * 26.x spells it as a function — `ngrams(3)`, `splitByNonAlpha` — and rejects the quoted
+ * names as "Unknown tokenizer". Neither parses the other. The template carries the
+ * current grammar; this rewrites a statement to the older one when a server refuses it.
+ * `default` in the old grammar is the non-alphanumeric splitter, which is what
+ * `splitByNonAlpha` names in the new one, so the indexes built are the same.
+ */
+function legacyTextIndexDialect(sql) {
+  return sql
+    .replace(/TYPE text\(tokenizer = ngrams\((\d+)\)\)/g, "TYPE text(tokenizer = 'ngram', ngram_size = $1)")
+    .replace(/TYPE text\(tokenizer = splitByNonAlpha\)/g, "TYPE text(tokenizer = 'default')");
+}
+
+/**
+ * Which text-index grammar a server speaks, from `SELECT version()`. Measured on real
+ * builds: 25.8 and 25.9 want the quoted-name form, 25.10 onwards the function form, and
+ * each rejects the other. Anything unparseable is treated as current; the shipper still
+ * falls back on a grammar refusal, so a wrong guess costs one round-trip, not the install.
+ */
+function textIndexDialectFor(version) {
+  const m = /^(\d+)\.(\d+)/.exec(String(version || '').trim());
+  if (!m) return 'modern';
+  const major = Number(m[1]); const minor = Number(m[2]);
+  return (major < 25 || (major === 25 && minor < 10)) ? 'legacy' : 'modern';
+}
+
+/** True when a server's refusal is the grammar, not a privilege or a real mistake. */
+function isTextIndexGrammarRefusal(message) {
+  return /Expected literal|supports only 'default'|Unknown tokenizer/.test(String(message || ''));
+}
+
 module.exports = {
+  physicalRoom, roomPattern, legacyTextIndexDialect, isTextIndexGrammarRefusal, textIndexDialectFor,
   ROOM_TYPES, META_TYPES, SCHEMA_VERSION, SUPPORTED_SCHEMAS, MIN_WRITER_SCHEMA,
   MIGRATIONS, ROOM_KEYS, keyProblem,
   READ_SETTINGS, MEMBER_PIN,

package/memhouse/house/migrate.js

@@ -39,8 +39,8 @@
 //   the old table until the rename; a late-writes pass copies anything newer than the
 //   snapshot, and ReplacingMergeTree makes that idempotent.
 //
-//   EVERYTHING IS RECORDED. One house_events pending row before work, applied/failed
-//   after, per object; schema_version in house_meta only after a migration completes.
+//   EVERYTHING IS RECORDED. One events pending row before work, applied/failed
+//   after, per object; schema_version in meta only after a migration completes.
 
 const fs = require('fs');
 const path = require('path');
@@ -59,7 +59,7 @@ const { ROOM_TYPES, keyProblem, createStatement } = require('./house');
  *   toVersion  the SCHEMA_VERSION a house is at once this has run
  *   detect(q, ctx)        -> what still needs doing (any truthy non-empty value), or
  *                            null/[] when the house is already past this migration.
- *                            THE ROOMS ARE THE TRUTH, never house_meta: a hand-migrated
+ *                            THE ROOMS ARE THE TRUTH, never meta: a hand-migrated
  *                            house has no record, and a restored backup can carry a
  *                            record newer than its tables.
  *   plan(found)           -> lines of human text for the confirm prompt
@@ -81,7 +81,7 @@ function listMigrations() {
   const seen = new Set();
   let lastVersion = 0;
   for (const m of out) {
-    // The id is spliced into SQL (house_events predicates) and into kept-table suffixes.
+    // The id is spliced into SQL (events predicates) and into kept-table suffixes.
     // It is repo-controlled, but "repo-controlled" is one compromised dependency away
     // from "attacker-controlled" — validate like any other identifier.
     if (!/^[a-z0-9][a-z0-9-]*$/.test(m.id)) throw new Error(`migration id '${m.id}' must match [a-z0-9-]+`);
@@ -116,7 +116,7 @@ async function detectPending(q, ctx, { component = null } = {}) {
  * Refuse when another actor's run is unfinished. An `applied` newer than the last
  * `pending` means done; a dangling `pending` means someone is (or was) mid-copy, and two
  * concurrent rebuilds of one room end with one of them renaming the other's work.
- * Best-effort: a house without house_events cannot answer, and that is not a reason to
+ * Best-effort: a house without events cannot answer, and that is not a reason to
  * block the migration that will create it.
  */
 async function unfinishedBy(q, ctx, migrationId) {
@@ -124,7 +124,8 @@ async function unfinishedBy(q, ctx, migrationId) {
     const rows = await q.rows(
       `SELECT argMax(status, event_at) AS status, argMax(actor, event_at) AS actor,
               formatDateTime(max(event_at), '%Y-%m-%d %H:%i') AS at
-       FROM house_events WHERE kind = 'migration' AND id = '${migrationId}'`);
+       FROM ${(ctx.rooms && ctx.rooms.physical && ctx.rooms.physical.events) || 'events'}
+       WHERE kind = 'migration' AND id = '${migrationId}'`);
     const r = rows[0];
     if (r && r.status === 'pending' && r.actor && r.actor !== ctx.member) return r;
   } catch { /* no events table yet */ }

package/memhouse/house/relocate.js

@@ -12,8 +12,8 @@
 // not insertable even with insert_allow_materialized_columns.
 const DERIVED = ['text_ngram', 'text_word'];
 
-// house_meta keys that are DURABLE facts of the house — worth carrying to the new host.
-// Everything else in house_meta is a per-host heartbeat (client_version, client_schema,
+// meta keys that are DURABLE facts of the house — worth carrying to the new host.
+// Everything else in meta is a per-host heartbeat (client_version, client_schema,
 // last_ship:<writer>) that the new shipper rewrites for itself on its first run; carrying
 // a stale one would misreport which machine last shipped until that run lands.
 function isDurableMetaKey(key) {

package/memhouse/house/schema.sql.tpl

@@ -154,10 +154,10 @@ ORDER BY (session_id, user_id, origin, epoch, idx);
 -- authoritative and always current, and a mirror of them would be a second truth that
 -- goes stale. What is recorded is what those cannot say: intent, sequence, outcome.
 
-CREATE TABLE IF NOT EXISTS house_meta
+CREATE TABLE IF NOT EXISTS meta
 (
     -- House-wide keys only ('schema_version', 'house_created_at'). Anything per-member
-    -- or per-machine belongs in house_events, which is append-only — this room is
+    -- or per-machine belongs in events, which is append-only — this room is
     -- latest-wins, so two members writing one key would overwrite each other.
     key String,
     value String,
@@ -168,7 +168,7 @@ CREATE TABLE IF NOT EXISTS house_meta
 ENGINE = ReplacingMergeTree(updated_at)
 ORDER BY (key);
 
-CREATE TABLE IF NOT EXISTS house_events
+CREATE TABLE IF NOT EXISTS events
 (
     event_at DateTime64(3, 'UTC') DEFAULT now64(3),
     -- 'migration' — a room rebuild, one row per transition (pending → applied|failed)