memhouse 0.18.10 → 0.18.12

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

@@ -3,7 +3,7 @@ name: access
 description: Bring someone onto this memhouse ClickHouse, or let them read your house — mint a new member with their own house and the env file their install needs, grant a housemate read-only access to yours, list who can currently read it, or revoke. Use when the user says "invite X", "add X to memhouse", "get my friend set up", "share my memory with X", "let X see my sessions", "who can read my memory", "stop sharing with X". Inviting comes BEFORE sharing — you can only grant a user who already exists. Read-only by construction on the sharing side: a share can never let anyone write to or delete your memory.
 user-invocable: true
 argument-hint: "invite <name> | share <name> | list | revoke <name>"
-allowed-tools: Bash
+allowed-tools: Bash(memhouse whoami *), Bash(memhouse status *), Bash(memhouse share --list), Bash(memhouse share --list --json)
 ---
 
 # /mem:access — who exists, and who may read
@@ -13,7 +13,7 @@ Two things that look alike and are not:
 - **Invite** mints a ClickHouse *user* and their own *house*. Needs an administrator.
 - **Share** grants an existing user `SELECT` on *your* house. You can do this yourself.
 
-**Read `../reference/HOUSE.md` first** for the connection block. One rule dominates
+**Read `../../reference/HOUSE.md` first** for the connection block. One rule dominates
 everything here: **a password must never enter this conversation.** memhouse ships this
 transcript into the house, and the archive is insert-only — a credential pasted here
 cannot be withdrawn.

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

@@ -3,7 +3,7 @@ name: admin
 description: Operate the memhouse ClickHouse as its administrator — list and inspect every user and house, provision or remove members, grant and revoke access, and read server-wide health (disk, parts, mutations, running queries). Use when the user asks to "do X as admin", "manage users", "drop a house", "see disk usage", "who is on this server", or when a member-scoped skill refused for want of privileges. Requires an administrator credential in the environment; says so plainly, and how to supply one, when there is not.
 user-invocable: true
 argument-hint: "<what you want done>"
-allowed-tools: Bash
+allowed-tools: Bash(memhouse whoami *), Bash(memhouse status *), Bash(memhouse instance *)
 ---
 
 # /mem:admin — operate the house as its administrator
@@ -12,7 +12,7 @@ A member owns a house, or rooms in one. An **administrator** owns the ClickHouse
 account, every grant. This skill is the second one, and it is the only skill allowed to
 act outside the caller's own house.
 
-**Read `../reference/HOUSE.md` first** — connection, schema, and the traps every query
+**Read `../../reference/HOUSE.md` first** — connection, schema, and the traps every query
 here inherits.
 
 **An admin password must never enter this conversation.** memhouse ships this transcript
@@ -128,7 +128,7 @@ Before any of them:
 
 1. **Look at the target and report what is really there** — row counts per room, who
    wrote them, the date span, which machines. A house you expected to be empty may not
-   be: one `ege` house looked disposable and held 3,733 messages belonging to somebody
+   be: one `carol` house looked disposable and held 3,733 messages belonging to somebody
    else entirely.
 2. **Name the collateral.** Dropping a user stops that account's shipper on every machine
    it runs on. Revoking a grant closes a share someone may be mid-query on. Rotating a

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

@@ -3,7 +3,7 @@ name: house
 description: The state of your memory and who is around it — what memhouse is and how to use it, whether shipping is working, what the house holds (sessions, messages, tokens per editor), how fresh it is, which machines write into it, which houses you can read, and who can read yours. Use for "what is memhouse", "how do I use this", "is my memory working", "how much is stored", "when did it last ship", "which machines are shipping", "who can see my memory", "whose memory can I see", "who else is on this server" — and as the first answer when another /mem skill fails because nothing is configured yet, or before debugging why a search found nothing.
 user-invocable: true
 argument-hint: ""
-allowed-tools: Bash
+allowed-tools: Bash(memhouse instance *), Bash(memhouse whoami *), Bash(memhouse status *), Bash(memhouse stats *), Bash(memhouse doctor *), Bash(memhouse share --list), Bash(memhouse share --list --json)
 ---
 
 # /mem:house — what this is, whether it works, and who is around it
@@ -11,7 +11,7 @@ allowed-tools: Bash
 **Invoking this IS the request. Run the report and present it; there is nothing to
 clarify.** Read-only throughout.
 
-**Read `../reference/HOUSE.md` first** — connection, schema, and the epoch filter every
+**Read `../../reference/HOUSE.md` first** — connection, schema, and the epoch filter every
 count below depends on.
 
 ## Nothing configured yet? Answer that instead

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

@@ -1,9 +1,9 @@
 ---
 name: recall
-description: Retrieve from past agent conversations and answer from them — search every session ever shipped from all 17 editors (Claude Code, Codex, Cursor, VS Code, Zed, Gemini CLI, …) across every project and machine, read the actual transcripts, and answer with citations. Use whenever the user refers to something not in the current context - "how did I fix X last time", "what approach did we settle on", "why did we choose Z", "find that conversation about Y", "did I ever try W", "what was I working on", "show my recent sessions", "sessions from last week", "remind me how I did it". Reach for this BEFORE saying you do not know about prior work. Also reads a housemate's memory when they name it ("how did yigit fix X"). For numbers rather than transcripts — spend, model mix, tool rankings — use /mem:sql.
+description: Retrieve from past agent conversations and answer from them — search every session ever shipped from all 17 editors (Claude Code, Codex, Cursor, VS Code, Zed, Gemini CLI, …) across every project and machine, read the actual transcripts, and answer with citations. Use whenever the user refers to something not in the current context - "how did I fix X last time", "what approach did we settle on", "why did we choose Z", "find that conversation about Y", "did I ever try W", "what was I working on", "show my recent sessions", "sessions from last week", "remind me how I did it". Reach for this BEFORE saying you do not know about prior work. Also reads a housemate's memory when they name it ("how did bob fix X"). For numbers rather than transcripts — spend, model mix, tool rankings — use /mem:sql.
 user-invocable: true
 argument-hint: "<question, terms, or 'recent sessions'>"
-allowed-tools: Bash
+allowed-tools: Bash(memhouse search *), Bash(memhouse resume *), Bash(memhouse sessions-query *), Bash(memhouse status *), Bash(memhouse whoami *)
 ---
 
 # /mem:recall — find it, read it, answer from it
@@ -16,7 +16,7 @@ answer still exists.
 path — this skill retrieves rows and YOU read them. Never present a guess as a retrieval:
 if the house has nothing, say so.
 
-**Read `../reference/HOUSE.md` first** — connection, schema, and the three traps
+**Read `../../reference/HOUSE.md` first** — connection, schema, and the three traps
 (epoch filtering, `(session_id, user_id)` joins, escaping). Every query below assumes it.
 
 ## Which shape is being asked for
@@ -43,7 +43,8 @@ found 8 messages where `%clickhouse%` AND `%ttl%` found 1,461.
 ```sql
 SELECT session_id, user_id, any(folder) AS folder,
        formatDateTime(max(ts), '%Y-%m-%d') AS day, count() AS hits,
-       substring(anyIf(text, positionCaseInsensitive(text, 'NEEDLE') > 0), 1, 300) AS sample
+       min(seq) AS hit_seq,
+       substring(argMin(text, seq), 1, 300) AS sample
 FROM messages
 WHERE text_ngram LIKE '%needle%'
   AND (origin != 'ship'
@@ -55,8 +56,8 @@ ORDER BY hits DESC, max(ts) DESC
 LIMIT 8
 ```
 
-`anyIf(...)` so the sample is a line that actually matched — `any(text)` returns an
-arbitrary message from the session and misled two readers in three. **Order by `hits`,
+Every row counted here matched, so `sample` is a line that actually matched: the
+session's first hit, at `hit_seq`. Step 2 reads around that position. **Order by `hits`,
 not just recency**: a session mentioning the term 197 times outranks yesterday's passing
 reference.
 
@@ -64,15 +65,27 @@ reference.
 the match so you see the resolution, not the complaint:
 
 ```sql
-SELECT seq, role, substring(text, 1, 2000) AS text
-FROM messages
-WHERE session_id = '<sid>' AND user_id = '<uid>'
-  AND seq BETWEEN <hit_seq - 3> AND <hit_seq + 12>
+SELECT seq, role, is_subagent, substring(text, 1, 2000) AS text FROM (
+    (SELECT seq, role, is_subagent, text FROM messages FINAL
+     WHERE session_id = '<sid>' AND user_id = '<uid>' AND seq < <hit_seq>
+       AND (origin != 'ship' OR epoch = (SELECT max(epoch) FROM messages
+            WHERE session_id = '<sid>' AND user_id = '<uid>' AND origin = 'ship'))
+     ORDER BY seq DESC LIMIT 3)
+    UNION ALL
+    (SELECT seq, role, is_subagent, text FROM messages FINAL
+     WHERE session_id = '<sid>' AND user_id = '<uid>' AND seq >= <hit_seq>
+       AND (origin != 'ship' OR epoch = (SELECT max(epoch) FROM messages
+            WHERE session_id = '<sid>' AND user_id = '<uid>' AND origin = 'ship'))
+     ORDER BY seq LIMIT 13))
 ORDER BY seq
 ```
 
-Apply the epoch filter here too — an unfiltered read of a compacted session interleaves
-two parses of the same conversation.
+`<sid>`, `<uid>` and `<hit_seq>` come from step 1's row. The window is counted in rows,
+not in `seq` values: three turns before the hit and twelve after. `seq` has gaps. A
+subagent's turns are numbered in a block of their own, far above the parent's, so
+`seq BETWEEN hit_seq - 3 AND hit_seq + 12` could return the hit alone. The epoch filter
+keeps one parse: an unfiltered read of a compacted session interleaves two versions of
+the same conversation. `FINAL` collapses row versions the server has not merged yet.
 
 **3. Answer, then cite.** Lead with the answer. Under it list the sessions it came from —
 `session_id`, date, project — so the user can reopen one (`memhouse resume <session_id>`
@@ -95,13 +108,20 @@ one representative line each. Offer to read the strongest. Do not dump ten rows
 prefer it over hand-joining. For a plain list:
 
 ```sql
-SELECT session_id, name, source, host, project,
-       formatDateTime(started_at, '%Y-%m-%d %H:%i') AS started, message_count
-FROM sessions
-ORDER BY started_at DESC
+SELECT session_id, user_id, name, source, host, project,
+       formatDateTime(created_at, '%Y-%m-%d %H:%i') AS started,
+       formatDateTime(coalesce(last_updated_at, created_at), '%Y-%m-%d %H:%i') AS last_active,
+       message_count
+FROM sessions FINAL
+ORDER BY coalesce(last_updated_at, created_at) DESC
 LIMIT 20
 ```
 
+`sessions` keeps one row per session and the newest write wins, so read it `FINAL`.
+"Recent" means recently active (`last_updated_at`): a session started last month and
+worked on today is recent. The room has no `started_at`; `created_at` is when the
+session began.
+
 Narrow with `WHERE project = '…'`, `source = 'cursor'`, `host = '…'`, or a date range as
 asked. In a shared house every member's sessions are here — add `AND user_id = '<name>'`
 only when the user asks for one person's.

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

@@ -3,7 +3,7 @@ name: sql
 description: Run read-only SQL over memhouse conversation memory for numbers rather than transcripts — token spend, cost by model or editor or project, tool-call rankings, activity over time, busiest days, cache-hit ratios, session length distributions, or any custom aggregate across the typed sessions/messages/tool_calls tables. Use when the user wants a figure, a ranking, a trend or a breakdown - "what did I spend on Opus", "which tools do I use most", "how many sessions per project", "my busiest week", "compare editors". For finding or answering FROM past conversations, use /mem:recall instead. Works over your own house, or a housemate's when they name it.
 user-invocable: true
 argument-hint: "<the question, or the SQL>"
-allowed-tools: Bash
+allowed-tools: Bash(memhouse sessions-query *), Bash(memhouse stats *), Bash(memhouse status *), Bash(memhouse whoami *)
 ---
 
 # /mem:sql — analytics over the rooms
@@ -11,7 +11,7 @@ allowed-tools: Bash
 For **numbers**. When the answer is a passage from a past conversation, that is
 `/mem:recall` — this skill counts, groups and ranks.
 
-**Read `../reference/HOUSE.md` first.** Schema, connection, and the three traps. The epoch
+**Read `../../reference/HOUSE.md` first.** Schema, connection, and the three traps. The epoch
 filter in particular is not optional here: this is the skill most likely to produce a
 figure someone acts on, and omitting it over-counted a real house by **34%**.
 

package/memhouse/flags.js

@@ -75,4 +75,31 @@ function allowedFlags(cmd) {
   return new Set([...GLOBAL_FLAGS, ...known]);
 }
 
-module.exports = { GLOBAL_FLAGS, COMMAND_FLAGS, unknownFlags, allowedFlags, suggestFlag, editDistance };
+// Options that never take a value. The parser used to read `--x y` as x = "y" for every
+// option, so a switch swallowed the word after it: `update --no-install yes` set
+// no-install to "yes" (not true) and ran the npm install it was asked to skip, and
+// `share --revoke bob` revoked nobody. A switch is true when present, and the next word
+// stays a positional.
+const BOOLEAN_FLAGS = new Set([
+  'json', 'yes', 'help', 'version', 'full', 'check', 'migrate', 'no-install', 'all-origins',
+  'dry-run', 'print-sql', 'no-ship', 'keep-admin', 'ensure-schema', 'rotate-password', 'force',
+  'adopt', 'allow-local', 'local', 'down', 'credentials', 'full-removal', 'insecure-native',
+  'keep-shipper', 'guides', 'revoke', 'list', 'admin', 'install', 'all',
+]);
+
+/** argv (after the command) -> { flags, positional }. */
+function parseArgv(rest) {
+  const flags = {}; const positional = [];
+  for (let i = 0; i < rest.length; i++) {
+    const a = rest[i];
+    if (a.startsWith('--')) {
+      const key = a.slice(2);
+      const next = rest[i + 1];
+      if (!BOOLEAN_FLAGS.has(key) && next !== undefined && !next.startsWith('--')) { flags[key] = next; i++; }
+      else flags[key] = true;
+    } else positional.push(a);
+  }
+  return { flags, positional };
+}
+
+module.exports = { GLOBAL_FLAGS, COMMAND_FLAGS, BOOLEAN_FLAGS, parseArgv, unknownFlags, allowedFlags, suggestFlag, editDistance };

package/memhouse/host.js

@@ -14,13 +14,18 @@
 //   * One machine splits. Rename the box and every row shipped afterwards lands under a
 //     new host, so the machine's own history appears to end and a stranger's to begin.
 //
-// A random fingerprint, written once and kept, fixes both: nothing derives it, so nothing
-// can collide with it, and nothing about the machine changing can move it.
+// So the fingerprint comes from the OS's own machine id (IOPlatformUUID, /etc/machine-id,
+// MachineGuid), hashed with a fixed salt (machineFingerprint), never from the hostname: two
+// machines cannot share it and a rename cannot move it. Since 0.18.6. Before that it was
+// random, which fixed both of the above but split a machine whenever MEMHOUSE_HOME was
+// wiped: a re-imaged laptop came back as a stranger. Where no machine id can be read it is
+// still random.
 //
-// It lives in MEMHOUSE_HOME and is deliberately NOT removed by a plain `memhouse
-// uninstall` — reinstalling on the same machine should continue that machine's history,
-// not start a second one beside it. `uninstall --full-removal` drops it, and then the
-// machine genuinely is a new host next time; that is the honest meaning of full removal.
+// It is written once to MEMHOUSE_HOME/host.json and an existing file always wins, so no
+// install changes identity under it. `uninstall --full-removal` drops the file, and the
+// next install derives the same fingerprint again from the same machine. The id also
+// carries the hostname the machine had at first install, so it comes back the same unless
+// the machine was renamed in between, or has no readable machine id.
 
 const fs = require('fs');
 const os = require('os');

package/memhouse/house/HOUSE.md

@@ -1,12 +1,12 @@
 # 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 tables: `sessions`, `messages`,
+`sam`, `team_a`, even `default`. Its rooms are tables: `sessions`, `messages`,
 `tool_calls`. No views, no Merge rooms, no settings profile.
 
-**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
+**Every member's rooms are named for them, and one grant covers them.** `mem.sam_*`
+for sam, `mem.alice_*` for alice, in the same database — `mem` unless somebody has a
+reason. The grant is `GRANT … ON mem.sam_* TO sam 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.
@@ -17,9 +17,9 @@ 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 |
+| `host` | which machine | the machine's fingerprint (`../host.js`) — derived from the OS machine id (random only where none can be read), 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
+`WHERE user_id = 'alice'` is one person. `WHERE host = 'my-laptop-1f2e3d4c'` is one
 machine. No filter is the whole house — which is what a team dashboard wants.
 
 ## Joining a house

package/memhouse/house/house.js

@@ -8,19 +8,19 @@
 //                                                  clients (async_insert is pinned to 0
 //                                                  on the user so the stamp cannot be
 //                                                  skipped)
-//   host     LowCardinality(String)              — the machine's fingerprint, minted once
+//   host     LowCardinality(String)              — the machine's fingerprint, derived from its OS machine id
 //                                                  per install (../host.js)
 //
 // That pair IS the provenance model.
 //
 // 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`.
+// member's rooms in it carry the member's name: `mem.alice_messages`, `mem.sam_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_*
+//   alone on a laptop        mem.sam_*              a house of one
+//   a team on one server     mem.sam_*, 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 —
@@ -412,6 +412,31 @@ function statRefreshStatements(rooms, at = 'now64(3)') {
     `INSERT INTO ${names[k]} SELECT ${at} AS refreshed_at, * FROM (${bodies[k].body})`);
 }
 
+/**
+ * When the shipper refreshes the stat tables (G11). After every pass that shipped something,
+ * as before — and ALSO when the newest generation is older than STATS_MAX_AGE_MS, even if
+ * nothing shipped. The tables carry a one-day TTL, so a house whose machines went quiet for
+ * a day used to lose every generation and the dashboard went empty while the rooms still
+ * held everything. `ageMs` null means "could not tell" (no table, no rights): do not refresh
+ * on age then; the read layer is already on the inline rollup.
+ */
+const STATS_MAX_AGE_MS = 60 * 60 * 1000;
+function statsNeedRefresh({ shipped, ageMs, maxAgeMs = STATS_MAX_AGE_MS }) {
+  if (shipped > 0) return true;
+  return ageMs !== null && ageMs !== undefined && ageMs > maxAgeMs;
+}
+
+/**
+ * How long a reader may keep its resolved rooms (G11). resolveRooms() decides once whether
+ * the stat tables are usable or the inline rollup must answer; a long-running dashboard that
+ * never asked again kept reading a stat table after its TTL had emptied it. Re-resolving
+ * every few minutes costs one small round trip and lets it follow the house either way.
+ */
+const ROOMS_TTL_MS = 5 * 60 * 1000;
+function roomsCacheStale(resolvedAt, now = Date.now(), ttlMs = ROOMS_TTL_MS) {
+  return !resolvedAt || now - resolvedAt > ttlMs;
+}
+
 /** The read-side source for one stat table: its newest generation, and nothing else. */
 function latestGeneration(table) {
   return `(SELECT * FROM ${table} WHERE refreshed_at = (SELECT max(refreshed_at) FROM ${table}))`;
@@ -435,7 +460,7 @@ const READ_SETTINGS = { final: 1, join_use_nulls: 1 };
  * 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
+ * and `mem.sam_messages` even when sam 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.
  *
@@ -598,4 +623,5 @@ module.exports = {
   sessionsRollup, currentParse, createStatement, roomNames, currentUser, resolveRooms,
   SESSION_STATS, MODEL_STATS, TOOL_STATS, statTableNames, hasSessionStats, statTables,
   statCreateStatements, statRefreshStatements, latestGeneration,
+  STATS_MAX_AGE_MS, statsNeedRefresh, ROOMS_TTL_MS, roomsCacheStale,
 };

package/memhouse/invite-target.js

@@ -0,0 +1,37 @@
+// Where `invite` may send a credential — and the one place that decides it (G4).
+//
+// `--url` is the address the INVITEE will reach the house at. It goes into the invite file;
+// it is typed on a command line, so it can be a typo, a tunnel, or somebody else's server.
+// A credential this install KEEPS — the member's own, or an admin saved with --keep-admin —
+// belongs to the house it was saved for, and is only ever sent there. Before 0.18.11 the
+// stored credential was sent to `--url`: resolveConfig() lets the flag outrank the env file,
+// so `cfg.url` WAS `--url`, and the reachability probe, the grants read and the provisioning
+// all authenticated against whatever `--url` named.
+//
+// A credential given for THIS command — `--admin-user`, or an exported MEMHOUSE_ADMIN_USER,
+// with a password from a file, stdin, the environment or a prompt — was chosen by the person
+// who also typed `--url`, so it provisions there, as it always has.
+//
+// Pure, so it is unit tested.
+
+/**
+ * @param {object} o
+ * @param {string} o.url              the invitee-facing --url
+ * @param {string|null} o.storedUrl   the house this install is configured for (env or env file)
+ * @param {'flag'|'env'|'file'|'member'} o.adminUserSource
+ *        where the credential's USER came from: --admin-user, an exported MEMHOUSE_ADMIN_USER,
+ *        the env file's MEMHOUSE_ADMIN_USER, or (no admin at all) the member credential
+ * @param {string|null} [o.passwordSource]  resolveAdminPassword's `source` ('stored' = the env file)
+ * @returns {{ url: string, stored: boolean } | { error: string }}
+ */
+function provisionTarget({ url, storedUrl, adminUserSource, passwordSource = null }) {
+  const stored = adminUserSource === 'file' || adminUserSource === 'member' || passwordSource === 'stored';
+  if (!stored) return { url, stored: false };
+  if (!storedUrl) {
+    return { error: 'this install keeps no house URL to send its stored credential to — '
+      + 'give the admin for this command instead (--admin-user, password from MEMHOUSE_ADMIN_PASSWORD or --admin-password-file)' };
+  }
+  return { url: storedUrl, stored: true };
+}
+
+module.exports = { provisionTarget };

package/memhouse/self-update.js

@@ -3,7 +3,7 @@
 // `npm i -g memhouse@latest` replaces the files under the global prefix and does not touch
 // the running processes, so the shipper keeps parsing with the old adapters and the
 // dashboard keeps serving the old bundle. Nothing reports it: `status` prints the version
-// of the CLI you just typed, not the version the daemon is running. On macminim a shipper
+// of the CLI you just typed, not the version the daemon is running. On one machine a shipper
 // ran 1d16h out of a directory that had been MOVED — the fix was live, the machine was not.
 //
 // npm's own `postinstall` is the obvious hook and the wrong one. npm >= 12 blocks install

package/memhouse/server/queries.js

@@ -18,7 +18,7 @@
 
 const { createClient, ClickHouseLogLevel } = require('@clickhouse/client');
 const { calculateCost, normalizeModelName } = require('../../pricing');
-const { resolveRooms, READ_SETTINGS } = require('../house/house');
+const { resolveRooms, READ_SETTINGS, roomsCacheStale } = require('../house/house');
 
 const config = {
   url: process.env.MEMHOUSE_URL || 'http://localhost:8123',
@@ -90,11 +90,16 @@ const TZ = Intl.DateTimeFormat().resolvedOptions().timeZone || 'UTC';
 // braces, no type.
 const ROOM_TOKEN = /\{\{([a-z_]+)\}\}/g;
 let roomsPromise = null;
+let roomsAt = 0;
 
 function rooms() {
-  // Resolved once per process. resolveRooms asks the server for currentUser(), so it is a
-  // round trip, and every dashboard request would otherwise pay for it.
-  if (!roomsPromise) {
+  // Cached, because resolveRooms asks the server for currentUser() and which stat tables
+  // are usable, and every dashboard request would otherwise pay that round trip. But not
+  // for the life of the process: whether the stat tables can answer changes — their TTL
+  // empties them on a quiet house, a refresh fills them again — and a dashboard that
+  // decided once kept reading an emptied table and showed nothing (G11).
+  if (!roomsPromise || roomsCacheStale(roomsAt)) {
+    roomsAt = Date.now();
     roomsPromise = resolveRooms(getClient()).catch((e) => { roomsPromise = null; throw e; });
   }
   return roomsPromise;
@@ -473,8 +478,8 @@ async function getChats(opts = {}) {
   // per call, three endpoints calling it — and getChats used ~4% of what it asked for.
     // In CHUNKS. The scope travels as `{scopeIds:Array(String)}` query parameters, and the
     // driver puts query parameters in the REQUEST URI — so a page of N sessions builds a URI
-    // of roughly 60 bytes per id, twice (ids and users). Zeo is reached through a Cloudflare
-    // tunnel, which rejects a URI far below ClickHouse's own 1 MiB `http_max_uri_size`: at
+    // of roughly 60 bytes per id, twice (ids and users). A house reached through a Cloudflare
+    // tunnel sits behind a proxy that rejects a URI far below ClickHouse's own 1 MiB `http_max_uri_size`: at
     // 925 sessions the request came back 500 with an EMPTY message (the driver reports a
     // transport-level refusal as `new Error('')`), so `/api/chats?limit=1000` — exactly what
     // the Sessions page asks for — returned 500 and the page rendered blank. 900 worked,