memhouse 0.7.1 → 0.8.0

package/memhouse/delivery/PROMPT.md

@@ -26,22 +26,20 @@ FIRST. Only say you don't know after a search comes back empty.
 (full-text over messages), `/memhouse:sessions` (list/filter sessions),
 `/memhouse:sql` (free-form read-only SQL). Without skills, query directly.
 
-**Table names first.** Every member owns their rooms, so every table below takes your
-username as a suffix — `messages_<you>`, `sessions_<you>`, `tool_calls_<you>`. There
-are no unsuffixed rooms; the plain names fail with `UNKNOWN_TABLE` rather than
-returning nothing. Get the suffix from `SELECT currentUser()`. **There is no
-`sessions_v` object** — the rollup is a saved query over those same rooms, and
+**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
 `memhouse sessions-query` prints it ready to drop into a `FROM (...) AS c`.
-`all_messages` / `all_sessions` / `all_tool_calls` read across every member you hold a
-grant for.
 
 - Find sessions about a topic (FTS, lowercase your terms):
-  `SELECT DISTINCT session_id, any(project), min(ts) FROM messages_<you>
+  `SELECT DISTINCT session_id, any(project), min(ts) FROM messages
    WHERE hasToken(text_word, 'clickhouse') GROUP BY session_id
    ORDER BY 3 DESC LIMIT 10 SETTINGS final=1, join_use_nulls=1 FORMAT PrettyCompact`
 - Recent sessions: `SELECT session_id, source, project, started, first_prompt
    FROM $(memhouse sessions-query) AS c ORDER BY started DESC LIMIT 20 SETTINGS final=1, join_use_nulls=1`
-- Replay one session: `SELECT role, text FROM messages_<you>
+- Replay one session: `SELECT role, text FROM messages
    WHERE session_id = '<id>' ORDER BY seq SETTINGS final=1, join_use_nulls=1`
 
 **Rules.**

package/memhouse/delivery/kernel-install.md

@@ -15,7 +15,7 @@ absent grant rather than a row policy — it fails closed. There is no shared
 `sessions`/`messages`/`tool_calls` layout and no row policy in the default path; 0.4.0
 removed both. Team-wide reads are the `Merge` rooms plus a `GRANT`. The session rollup
 is a **saved query**, not a stored view — `memhouse sessions-query` prints it.
-Design and measurements: `../per-member/`.
+Design and measurements: `../house/HOUSE.md`.
 
 This is an operator runbook, so it speaks machine vocabulary throughout — ClickHouse,
 `GRANT`, `currentUser()`. That is correct for this audience.
@@ -63,40 +63,25 @@ For each person joining, split across the two authorities:
 python3 executor/executor.py submit register-member '{"handle":"alice"}'
 python3 executor/executor.py approve <call_id> && python3 executor/executor.py drain
 
-# OWNER mints that member's three rooms and their grants (memhouse_root has
-# grant-option on mem.*). One idempotent step — see ../per-member/PROVISIONING.md:
-MEM_URL=https://<kernel-host>:8443 MEM_USER=memhouse_root \
-MEM_PASSWORD=<credential> MEM_DB=mem \
-  node memhouse/per-member/provision.js --member alice --merge
+# OWNER admits the member to the house — two statements, any DBA knows them:
+#   CREATE USER alice IDENTIFIED BY '…';
+#   GRANT ALL ON mem.* TO alice;
+# (memhouse can run them: memhouse install --admin-user … --member alice)
 ```
 
-**Never `GRANT … ON mem.*` to a member.** A member who can read `mem.*` can read every
-other member's rooms, and then this is a shared house with longer table names.
-`provision.js` grants per room: `ALL` on each of alice's three, plus a re-grantable
-`SELECT` on each (that split is what makes a share read-only by construction), plus
-`SELECT` on the `Merge` rooms.
-
 Each member then runs the shipper with **their own** credential
-(`MEMHOUSE_USER=alice`) — it writes to `sessions_alice` / `messages_alice` /
-`tool_calls_alice`, resolved from `SELECT currentUser()` rather than from config, and
-the house stamps `user_id='alice'` on their rows, un-spoofably
-(`MATERIALIZED currentUser()`, `async_insert=0`).
+(`MEMHOUSE_USER=alice`) — everyone writes into the SAME three tables (`sessions`,
+`messages`, `tool_calls`), and the house stamps `user_id='alice'` on her rows,
+un-spoofably (`MATERIALIZED currentUser()`, with `async_insert = 0 CONST` pinned on the
+user so the stamp cannot be skipped). Her machines are told apart by `host`.
 
 ## 4. Visibility
 
-**Own-only is the default and needs no policy.** Alice is granted her own three rooms
-and nobody else's, so bob's rooms are not hidden from her — they are simply not hers to
-read, and the failure mode of a missing grant is a denial rather than a leak.
-
-**Team-wide reads are the `Merge` rooms** (`all_sessions`, `all_messages`,
-`all_tool_calls`) plus a `GRANT SELECT` on them, which `provision.js --merge` issues. A
-`Merge` room narrows to whatever underlying rooms the caller already holds grants for —
-measured on 26.7.1: no leak, no error — so it can be granted broadly. It also
-auto-discovers rooms created after it, so onboarding a member needs no DDL there.
-
-A member widens what a colleague sees by granting their own rooms directly
-(`GRANT SELECT ON mem.messages_alice TO bob`) — self-serve, no operator, because the
-member holds grant-option on their own `SELECT`. See `../per-member/SHARING.md`.
+**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.
 
 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/skills/search/SKILL.md

@@ -9,7 +9,7 @@ allowed-tools: Bash
 # /memhouse:search — search conversation memory
 
 Search the full message history in the memhouse house. Every room is named for your
-ClickHouse user — `messages_<you>`, `sessions_<you>` — see **Room names** below.
+ClickHouse user — `messages`, `sessions` — see **Room names** below.
 
 ## Connection
 
@@ -59,35 +59,25 @@ SQL
 `FORMAT PrettyCompact` for display; `FORMAT JSONEachRow` when you want to parse
 the rows yourself.
 
-## Room names — always suffixed
+## Room names — plain, shared tables
 
-Every member owns their own rooms, named for their ClickHouse user:
-`messages_<you>`, `sessions_<you>`, `tool_calls_<you>`. There are no unsuffixed rooms;
-the bare names fail with `UNKNOWN_TABLE` rather than returning nothing. You hold no grant
-on anyone else's rooms, so isolation is not something a query can work around.
+The house's rooms are three plain tables: `messages`, `sessions`, `tool_calls` — resolved
+by the connection's database (`MEMHOUSE_DB`), not by who is asking. Everyone in the house
+writes into the same tables; `user_id` (stamped by the server) says whose row it is and
+`host` says which machine shipped it. Search the whole house by default; add
+`AND user_id = '<name>'` only when the user asks for one person's sessions.
 
-Ask the server your name once, then **type the literal room name into your SQL** — do not
-reference a shell variable inside the query:
-
-```bash
-curl -sS --fail-with-body --user "$MEMHOUSE_USER:${MEMHOUSE_PASSWORD:-}" \
-  --data-binary "SELECT currentUser() FORMAT TabSeparated" \
-  "$MEMHOUSE_URL/?readonly=1"
-# prints e.g. alice  →  your rooms are messages_alice, sessions_alice, tool_calls_alice
-```
-
-**Keep the SQL heredoc quoted (`<<'SQL'`) and put the real name in the text.** This used to
-say "substitute it into every table name below" and show `messages_$MEM_ME`, which cannot
-expand inside a quoted heredoc — so the agent unquotes it, and then the SEARCH TERMS expand
-too. Both instances driving this skill did exactly that, unprompted, on the first attempt.
-Measured consequences, from `system.query_log`:
+**Keep the SQL heredoc quoted (`<<'SQL'`).** This skill once told the agent to substitute
+a shell variable into the table names, which cannot expand inside a quoted heredoc — so
+the agent unquotes it, and then the SEARCH TERMS expand too. Both instances driving this
+skill did exactly that, unprompted, on the first attempt. Measured consequences, from
+`system.query_log`:
 
 - a term containing `$home` became the empty string, so `LIKE '%%'` matched **every row**
   and reported hits with exit 0 — silently wrong, not an error;
 - a term containing a backtick **executed the command inside it**.
 
-A user's search term is arbitrary text. With the heredoc quoted and the room name written
-out, neither can happen.
+A user's search term is arbitrary text. With the heredoc quoted, neither can happen.
 
 **There is no `sessions_v` object.** The session rollup is a saved query over those same
 rooms — `memhouse sessions-query` prints it for whoever you are connected as, ready to
@@ -98,13 +88,10 @@ both rooms and a trailing `SETTINGS join_use_nulls = 1`, so it is correct wherev
 paste it. `final=1` on the connection still matters for reads of the rooms THEMSELVES,
 which carry no FINAL of their own.
 
-If you hold `SELECT` on them, `all_messages` / `all_sessions` / `all_tool_calls` read
-across every member at once, narrowed to whatever grants you actually have — a Merge room
-reduces to the rooms the caller can read, so it fails closed rather than denying outright.
 
 ## How to search (the FTS columns)
 
-`messages_<you>` carries two MATERIALIZED lowercase copies of `text`, each with a
+`messages` carries two MATERIALIZED lowercase copies of `text`, each with a
 text index — search those, display `text`:
 
 - `text_ngram` (ngram index) → substring match: `text_ngram LIKE '%term%'`
@@ -120,8 +107,8 @@ phrase → one `LIKE` clause for the whole phrase.
 SELECT m.ts, m.source, m.project, m.role, m.session_id,
        s.name AS session,
        substring(m.text, 1, 300) AS snippet
-FROM messages_<you> AS m
-LEFT JOIN sessions_<you> AS s USING (session_id)
+FROM messages AS m
+LEFT JOIN sessions AS s USING (session_id, user_id)
 WHERE m.text_ngram LIKE '%postgres%' AND m.text_ngram LIKE '%migration%'
 ORDER BY m.ts DESC
 LIMIT 30
@@ -132,7 +119,7 @@ FORMAT PrettyCompact
 
 ```sql
 SELECT ts, project, session_id, substring(text, 1, 200) AS snippet
-FROM messages_<you>
+FROM messages
 WHERE hasToken(text_word, 'rls')
   AND source = 'claude-code'
   AND ts > now() - INTERVAL 14 DAY
@@ -144,12 +131,12 @@ FORMAT PrettyCompact
 ### Example 3 — which sessions mention it most (then drill in)
 
 ```sql
-SELECT m.session_id, any(s.name) AS session, any(m.project) AS project,
+SELECT m.session_id, m.user_id, any(s.name) AS session, any(m.project) AS project,
        count() AS hits, max(m.ts) AS last_hit
-FROM messages_<you> AS m
-LEFT JOIN sessions_<you> AS s USING (session_id)
+FROM messages AS m
+LEFT JOIN sessions AS s USING (session_id, user_id)
 WHERE m.text_ngram LIKE '%clickhouse cache%'
-GROUP BY m.session_id
+GROUP BY m.session_id, m.user_id
 ORDER BY hits DESC
 LIMIT 10
 FORMAT PrettyCompact
@@ -163,14 +150,14 @@ FORMAT PrettyCompact
   `cursor`, `cursor-agent`, `vscode`, `zed`, `opencode`, `gemini-cli`,
   `windsurf`, `antigravity`, `copilot-cli`, `goose`, `kiro`, …)
 - Skip subagent noise → `AND NOT m.is_subagent`
-- Only user/assistant text lives in `messages_<you>`; tool invocations are in
-  `tool_calls_<you>` (`tool_name`, `args`) — search `args ILIKE '%term%'` there
+- Only user/assistant text lives in `messages`; tool invocations are in
+  `tool_calls` (`tool_name`, `args`) — search `args ILIKE '%term%'` there
   only if the user explicitly wants tool calls searched.
 
 ## Output
 
 Summarize hits grouped by session (name, source, project, date, 1–2 best
 snippets each) and give the total hit count. Offer to pull the full transcript
-of the best session (`SELECT role, text FROM messages_<you> WHERE session_id = '…'
+of the best session (`SELECT role, text FROM messages WHERE session_id = '…'
 ORDER BY seq`). If zero hits, retry with broader/fewer terms and report the
-corpus size (`SELECT count() FROM messages_<you>`).
+corpus size (`SELECT count() FROM messages`).

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

@@ -63,35 +63,25 @@ FORMAT PrettyCompact
 SQL
 ```
 
-## Room names — always suffixed
+## Room names — plain, shared tables
 
-Every member owns their own rooms, named for their ClickHouse user:
-`messages_<you>`, `sessions_<you>`, `tool_calls_<you>`. There are no unsuffixed rooms;
-the bare names fail with `UNKNOWN_TABLE` rather than returning nothing. You hold no grant
-on anyone else's rooms, so isolation is not something a query can work around.
+The house's rooms are three plain tables: `messages`, `sessions`, `tool_calls` — resolved
+by the connection's database (`MEMHOUSE_DB`), not by who is asking. Everyone in the house
+writes into the same tables; `user_id` (stamped by the server) says whose row it is and
+`host` says which machine shipped it. Search the whole house by default; add
+`AND user_id = '<name>'` only when the user asks for one person's sessions.
 
-Ask the server your name once, then **type the literal room name into your SQL** — do not
-reference a shell variable inside the query:
-
-```bash
-curl -sS --fail-with-body --user "$MEMHOUSE_USER:${MEMHOUSE_PASSWORD:-}" \
-  --data-binary "SELECT currentUser() FORMAT TabSeparated" \
-  "$MEMHOUSE_URL/?readonly=1"
-# prints e.g. alice  →  your rooms are messages_alice, sessions_alice, tool_calls_alice
-```
-
-**Keep the SQL heredoc quoted (`<<'SQL'`) and put the real name in the text.** This used to
-say "substitute it into every table name below" and show `messages_$MEM_ME`, which cannot
-expand inside a quoted heredoc — so the agent unquotes it, and then the SEARCH TERMS expand
-too. Both instances driving this skill did exactly that, unprompted, on the first attempt.
-Measured consequences, from `system.query_log`:
+**Keep the SQL heredoc quoted (`<<'SQL'`).** This skill once told the agent to substitute
+a shell variable into the table names, which cannot expand inside a quoted heredoc — so
+the agent unquotes it, and then the SEARCH TERMS expand too. Both instances driving this
+skill did exactly that, unprompted, on the first attempt. Measured consequences, from
+`system.query_log`:
 
 - a term containing `$home` became the empty string, so `LIKE '%%'` matched **every row**
   and reported hits with exit 0 — silently wrong, not an error;
 - a term containing a backtick **executed the command inside it**.
 
-A user's search term is arbitrary text. With the heredoc quoted and the room name written
-out, neither can happen.
+A user's search term is arbitrary text. With the heredoc quoted, neither can happen.
 
 **There is no `sessions_v` object.** The session rollup is a saved query over those same
 rooms — `memhouse sessions-query` prints it for whoever you are connected as, ready to
@@ -105,14 +95,11 @@ grows); without `join_use_nulls` a session with no messages reports `total_msgs
 rather than 0.
 
 **If the `memhouse` binary is not on PATH**, you cannot print the rollup — the skills are
-installable on their own. Query the rooms directly instead: `sessions_<you>` for metadata
-and `messages_<you>` for counts, each read `FINAL`, joined on `session_id` and `user_id`.
+installable on their own. Query the rooms directly instead: `sessions` for metadata
+and `messages` for counts, each read `FINAL`, joined on `session_id` and `user_id`.
 Prefer the binary when it is there; a rollup you assemble by hand and one printed by a
 DIFFERENT memhouse version are the two ways this goes quietly wrong.
 
-If you hold `SELECT` on them, `all_messages` / `all_sessions` / `all_tool_calls` read
-across every member at once, narrowed to whatever grants you actually have — a Merge room
-reduces to the rooms the caller can read, so it fails closed rather than denying outright.
 
 ## Default listing
 
@@ -173,5 +160,5 @@ FORMAT PrettyCompact
 
 A compact table: when, name (or first prompt), source, host, project, msgs,
 tokens. Offer to pull a full transcript next
-(`SELECT role, text FROM messages_<you> WHERE session_id = '…' ORDER BY seq`) or to
+(`SELECT role, text FROM messages WHERE session_id = '…' ORDER BY seq`) or to
 run /memhouse:search for a specific quote.

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

@@ -1,6 +1,6 @@
 ---
 name: sql
-description: Run free-form read-only SQL against memhouse conversation memory (typed sessions/messages/tool_calls rooms on ClickHouse, one set per member). Use for ad-hoc analytics the other memhouse skills don't cover — token spend, model/editor usage, tool rankings, activity heatmaps, busiest days/projects, cache-hit ratios, or any custom question over conversation data.
+description: Run free-form read-only SQL against memhouse conversation memory (typed sessions/messages/tool_calls tables on ClickHouse, shared by the house). Use for ad-hoc analytics the other memhouse skills don't cover — token spend, model/editor usage, tool rankings, activity heatmaps, busiest days/projects, cache-hit ratios, or any custom question over conversation data.
 user-invocable: true
 argument-hint: "<question or SQL>"
 allowed-tools: Bash
@@ -73,35 +73,25 @@ SQL
 
 `FORMAT PrettyCompact` for display, `FORMAT JSONEachRow` to parse.
 
-## Room names — always suffixed
+## Room names — plain, shared tables
 
-Every member owns their own rooms, named for their ClickHouse user:
-`messages_<you>`, `sessions_<you>`, `tool_calls_<you>`. There are no unsuffixed rooms;
-the bare names fail with `UNKNOWN_TABLE` rather than returning nothing. You hold no grant
-on anyone else's rooms, so isolation is not something a query can work around.
+The house's rooms are three plain tables: `messages`, `sessions`, `tool_calls` — resolved
+by the connection's database (`MEMHOUSE_DB`), not by who is asking. Everyone in the house
+writes into the same tables; `user_id` (stamped by the server) says whose row it is and
+`host` says which machine shipped it. Filter with `WHERE user_id = '<name>'` when you want
+one person, or leave it off for the whole house.
 
-Ask the server your name once, then **type the literal room name into your SQL** — do not
-reference a shell variable inside the query:
-
-```bash
-curl -sS --fail-with-body --user "$MEMHOUSE_USER:${MEMHOUSE_PASSWORD:-}" \
-  --data-binary "SELECT currentUser() FORMAT TabSeparated" \
-  "$MEMHOUSE_URL/?readonly=1"
-# prints e.g. alice  →  your rooms are messages_alice, sessions_alice, tool_calls_alice
-```
-
-**Keep the SQL heredoc quoted (`<<'SQL'`) and put the real name in the text.** This used to
-say "substitute it into every table name below" and show `messages_$MEM_ME`, which cannot
-expand inside a quoted heredoc — so the agent unquotes it, and then the SEARCH TERMS expand
-too. Both instances driving this skill did exactly that, unprompted, on the first attempt.
-Measured consequences, from `system.query_log`:
+**Keep the SQL heredoc quoted (`<<'SQL'`).** This skill once told the agent to substitute
+a shell variable into the table names, which cannot expand inside a quoted heredoc — so
+the agent unquotes it, and then the SEARCH TERMS expand too. Both instances driving this
+skill did exactly that, unprompted, on the first attempt. Measured consequences, from
+`system.query_log`:
 
 - a term containing `$home` became the empty string, so `LIKE '%%'` matched **every row**
   and reported hits with exit 0 — silently wrong, not an error;
 - a term containing a backtick **executed the command inside it**.
 
-A user's search term is arbitrary text. With the heredoc quoted and the room name written
-out, neither can happen.
+A user's search term is arbitrary text. With the heredoc quoted, neither can happen.
 
 **There is no `sessions_v` object.** The session rollup is a saved query over those same
 rooms — `memhouse sessions-query` prints it for whoever you are connected as, ready to
@@ -115,22 +105,19 @@ grows); without `join_use_nulls` a session with no messages reports `total_msgs
 rather than 0.
 
 **If the `memhouse` binary is not on PATH**, you cannot print the rollup — the skills are
-installable on their own. Query the rooms directly instead: `sessions_<you>` for metadata
-and `messages_<you>` for counts, each read `FINAL`, joined on `session_id` and `user_id`.
+installable on their own. Query the rooms directly instead: `sessions` for metadata and
+`messages` for counts, each read `FINAL`, joined on `session_id` **and `user_id`** — the
+tables are shared, and joining on `session_id` alone can merge two housemates' rows.
 Prefer the binary when it is there; a rollup you assemble by hand and one printed by a
 DIFFERENT memhouse version are the two ways this goes quietly wrong.
 
-If you hold `SELECT` on them, `all_messages` / `all_sessions` / `all_tool_calls` read
-across every member at once, narrowed to whatever grants you actually have — a Merge room
-reduces to the rooms the caller can read, so it fails closed rather than denying outright.
-
 ## Schema (the house)
 
 | Object | Kind | Columns |
 |---|---|---|
-| `sessions_<you>` | table, 1 row/session | `session_id, source, host, name, mode, folder, project, git_branch, created_at, last_updated_at, message_count, path, extra JSON, user_id, ingested_at` |
-| `messages_<you>` | table, 1 row/message | `session_id, seq, source, host, ts, role, model, input_tokens, output_tokens, cache_read_tokens, cache_write_tokens, text, project, folder, is_subagent, extra JSON, line_hash, user_id, ingested_at` + FTS columns `text_ngram`/`text_word` (lowercased; see /memhouse:search) |
-| `tool_calls_<you>` | table, 1 row/tool call | `session_id, seq, idx, source, host, tool_name, args, ts, project, folder, user_id, ingested_at` |
+| `sessions` | table, 1 row/session | `session_id, source, host, name, mode, folder, project, git_branch, created_at, last_updated_at, message_count, path, extra JSON, user_id, ingested_at` |
+| `messages` | table, 1 row/message | `session_id, seq, source, host, ts, role, model, input_tokens, output_tokens, cache_read_tokens, cache_write_tokens, text, project, folder, is_subagent, extra JSON, line_hash, user_id, ingested_at` + FTS columns `text_ngram`/`text_word` (lowercased; see /memhouse:search) |
+| `tool_calls` | table, 1 row/tool call | `session_id, seq, idx, source, host, tool_name, args, ts, project, folder, user_id, ingested_at` |
 | the rollup | **saved query**, not an object — `memhouse sessions-query` prints it | `session_id, source, host, name, mode, folder, project, git_branch, user_id, created_at, last_updated_at, started, ended, duration_sec, total_msgs, user_msgs, assistant_msgs, subagent_msgs, models, input_tokens, output_tokens, cache_read_tokens, cache_write_tokens, user_chars, assistant_chars, first_prompt` |
 
 Notes: `source` = editor id (`claude-code`, `codex`, `cursor`, `cursor-agent`,
@@ -147,7 +134,7 @@ Token spend by model:
 ```sql
 SELECT model, sum(input_tokens) AS in_tok, sum(output_tokens) AS out_tok,
        sum(cache_read_tokens) AS cache_read
-FROM messages_<you>
+FROM messages
 WHERE model NOT IN ('', '<synthetic>')
 GROUP BY model
 ORDER BY out_tok DESC
@@ -158,7 +145,7 @@ Which tools do I use most (memhouse exclusive — memory-house has no tool table
 
 ```sql
 SELECT tool_name, count() AS calls, uniqExact(session_id) AS sessions
-FROM tool_calls_<you>
+FROM tool_calls
 GROUP BY tool_name
 ORDER BY calls DESC
 LIMIT 20
@@ -169,7 +156,7 @@ Busiest days, last two weeks:
 
 ```sql
 SELECT toDate(ts) AS day, uniqExact(session_id) AS sessions, count() AS msgs
-FROM messages_<you>
+FROM messages
 WHERE ts > now() - INTERVAL 14 DAY
 GROUP BY day
 ORDER BY day DESC
@@ -180,7 +167,7 @@ Activity by editor this week / subagent share:
 
 ```sql
 SELECT source, count() AS msgs, countIf(is_subagent) AS subagent_msgs
-FROM messages_<you>
+FROM messages
 WHERE ts > now() - INTERVAL 7 DAY
 GROUP BY source
 ORDER BY msgs DESC

package/memhouse/host.js

@@ -1,7 +1,7 @@
 // Which machine shipped this row.
 //
 // All of one member's machines ship into that member's rooms — that is the point of the
-// per-member layout — and the `host` column is the only thing telling them apart. So the
+// shared-house layout — and the `host` column is the only thing telling them apart. So the
 // value has to be BOTH unique per machine and stable across that machine's lifetime.
 //
 // It used to be derived, `sha256(hostname|platform|arch)`, and that fails in both

package/memhouse/house/HOUSE.md

@@ -0,0 +1,74 @@
+# The house — a database, three shared rooms
+
+**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.
+
+**Everyone in the house writes into the same tables**, each with their own credential,
+and two columns say where every row came from:
+
+| Column | Meaning | Comes from |
+|---|---|---|
+| `user_id` | who wrote it | `String MATERIALIZED currentUser()` — stamped by the server, unforgeable by clients. `async_insert = 0 CONST` is pinned on each user (`ADD SETTING`, which merges — a bare `SETTINGS` clause replaces the user's whole list) because an async flush stores the stamp as the empty string (measured on 25.11.9.34) |
+| `host` | which machine | the install's fingerprint (`../host.js`) — random, minted once, so two machines with the same hostname cannot collide and renaming one cannot split its history |
+
+`WHERE user_id = 'alice'` is one person. `WHERE host = 'macbook-4127a95b'` is one
+machine. No filter is the whole house — which is what a team dashboard wants.
+
+## Joining a house
+
+The whole tenancy model is the database boundary:
+
+```sql
+CREATE USER alice IDENTIFIED BY '…';
+GRANT ALL ON team_a.* TO alice;
+ALTER USER alice ADD SETTING async_insert = 0 CONST;
+```
+
+`ALL` on your own house reaches nothing outside it, and it is what lets alice's own
+shipper create and evolve the rooms (`ship.js --ensure-schema`) — no admin has to run
+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.
+
+## One user on two machines, same session id
+
+Session ids are minted per machine, so this needs a synced home directory to happen at
+all — but when it does (the same `~/.claude` on two synced machines), both shippers ship
+the same `(session_id, user_id)`. The keys deliberately do NOT include `host`, so the
+rows collapse to the LAST shipper's copy: one logical session stays one session, with
+`host` recording who shipped it most recently. Keying on host instead would duplicate
+every such session and double what the rollup counts. An interleaved clear+insert
+between the two shippers can transiently drop rows; the next pass's skip predicate sees
+the count mismatch and re-ships — self-healing, at the price of churn. Truly parallel
+shippers per user are the deferred "ephemeral fingerprint" expert feature, not today's.
+
+## The rollup is a saved query, not an object
+
+`sessions_v` is SQL text (house.js `sessionsRollup`), substituted into the same
+`FROM … AS c` position a view name would occupy and run under the caller's own
+credential. It groups by `(session_id, user_id)` — two housemates' rows never merge,
+even on a colliding session_id — and carries its own `FINAL` and
+`SETTINGS join_use_nulls = 1`, so it is correct wherever it is pasted.
+
+## What this replaced, and why
+
+The per-member layout: rooms named `sessions_<member>` with a narrowed per-member grant
+set, Merge rooms (`all_sessions`…) for team reads, and isolation between members of one
+database. Retired because every piece of it was cost paid for an adversarial model the
+product does not have:
+
+- suffixed names made every client resolve its room names before writing SQL, and
+  `FROM messages` a documented trap the acceptance suite had to test for;
+- the Merge rooms existed only to undo the splitting the suffixes created;
+- the narrowed grant set existed to stop housemates attacking each other — but
+  housemates are collaborators, and groups that are not do not share a database.
+
+The origin story that survives: rows carry `origin` (in the messages/tool_calls sorting
+keys, deliberately NOT in sessions'), the shipper's clear binds
+`(session_id, user_id, origin='ship')`, and imported history survives every re-ship.
+See the comments in `schema.sql.tpl` — they are the authority on the keys.