memhouse 0.18.12 → 0.20.1

package/docs/releases/v0.20.1.md

@@ -0,0 +1,114 @@
+# memhouse 0.20.1 — 2026-11-02
+
+A patch release on 0.20.0, with no schema change. Install it with `memhouse update`, or
+`npm install -g memhouse`.
+
+- **An invite's password expires.** It stops working 7 days after the invite unless it is
+  installed first. A file that sits unused, or that was read where it should not have been,
+  stops working on its own.
+- **Codex gets memhouse on request.** `memhouse plugins install codex` adds a short rules block
+  to Codex's `AGENTS.md` and a `memhouse` skill with the read recipes. `plugins remove codex`
+  takes out exactly those.
+- **Clearer answers from the CLI:**
+  - `memhouse <command> --help` prints that command's help;
+  - a refused credential is named before anything is written;
+  - `share --list` also shows the shares you received;
+  - `members` tells a share from a member's own tables;
+  - `discover` and `update` stop reporting problems that belong to nobody.
+- **A new minor version's first run says so,** and names the release notes to read.
+
+## Read this before upgrading
+
+Nothing in the house changes, and there is no migration. Three things behave differently:
+
+- **Inviting: the password now expires.** `memhouse invite` sets the expiry on the new account
+  using the server's clock. The default is 7 days; `--expires <days>` takes 1 to 365. The
+  output, the invite file and `MEMHOUSE-INVITATION.md` all give the date. An invitee who
+  installs after that date is refused with "this invite expired at … ask whoever invited you
+  for a new one". To invite them again under the same name, remove the unused account first
+  with `DROP USER <name>`, as the administrator; their tables are kept and reused. Invites
+  made by 0.20.0 or earlier carry no expiry and keep working as before.
+- **The first command after moving to a new minor version prints one line** to stderr. It
+  names the version it replaces and the release notes. Patch releases, downgrades and fresh
+  installs print nothing.
+- **Codex is opt-in.** Nothing is written under `~/.codex` (or `CODEX_HOME`) unless you run
+  `memhouse plugins install codex`.
+
+```bash
+memhouse update        # then: memhouse status — every line a check mark
+```
+
+## Invites
+
+- **The expiry is set by the server**, as `VALID UNTIL` on the new account, so it holds no
+  matter what the file says. `install --env` also checks the date in the file and refuses
+  before contacting the server.
+- **Installing lifts it.** A password change removes the expiry, and so does
+  `--keep-password`, which keeps the invited password.
+- **`invite --print-sql`** prints the same `ALTER USER … VALID UNTIL` statement for an
+  administrator who runs the plan by hand. The date is left as a placeholder, so the
+  statement does not parse until a real date is put in.
+- **Re-inviting an unused name** used to fail with the install message, "give their
+  password". It now says the invite was never installed, gives its expiry, and names the
+  remedy.
+
+## Codex
+
+Codex puts `AGENTS.md` into every prompt and lists each skill by its name and description,
+reading the body only when the skill is used. memhouse uses both, and only when asked:
+
+- **The block** in `AGENTS.md` holds what must always apply:
+  - never read or print the env file or a `MEMHOUSE_*` value;
+  - `MEMHOUSE_URL` is the house and `MEMHOUSE_PORT` the dashboard;
+  - questions about past sessions go to the skill.
+
+  It sits between `<!-- memhouse:begin … -->` and `<!-- memhouse:end -->` markers. A reinstall
+  replaces it where it stands. Remove takes it out and leaves the rest of the file
+  byte-identical. A file that held only the block is deleted, unless it is a symlink: then its
+  target is emptied and the link kept.
+- **The skill**, `skills/memhouse/`, carries the read recipes:
+  - `memhouse q` for search, sessions, activity by hour, spend, models, tools and machines;
+  - `--member` for a housemate's shared sessions;
+  - `memhouse room-sql` for anything else.
+
+  It is memhouse's only if it holds `.memhouse.json`. A `skills/memhouse` without that file is
+  never replaced or removed.
+- **An instance with its own home or binary** is named in both, as `MEMHOUSE_HOME=<home>
+  <binary>`.
+- **After an upgrade,** the first command refreshes an installed copy, as it does the `/mem`
+  copies. A block you took out by hand stays out.
+- **The `/mem` skills are still for Claude Code.**
+
+## Smaller changes
+
+- **`memhouse <command> --help`** prints that command's entry. A command with no entry of its
+  own still gets the whole page. `memhouse q --help` lists the named queries.
+- **A refused credential is named up front.** When ClickHouse refuses the credential (code
+  516, or 194 for a missing password), `install`, `invite` and `deploy --local` stop before
+  writing anything, with "could not authenticate as '<user>' at <url>".
+- **`share --list` also lists the shares you received,** with the command that reads each
+  one. `--json` adds `received`.
+- **`members` tells a share from a member's own tables:**
+  - own tables;
+  - each member whose sessions this account reads, scoped or full;
+  - any other grant.
+
+  `--json` adds `own`, `shares` and `other`.
+- **`discover`** shows an unreachable `http://localhost:8123` as a plain line when nothing is
+  configured to use it, instead of a ✗.
+- **`update` on a machine with no member install** (an administrator's machine) skips the
+  schema heal and migration check, instead of printing the default member's authentication
+  failures.
+- **`doctor`** names the release channel when it says a release is the latest. Offline, it no
+  longer says the install is current.
+- **Dashboard:** a browser that refuses sessionStorage keeps the access token in memory for
+  that page load, instead of showing the "open it with `memhouse dashboard`" page.
+- **/mem skills:** the schema-2 raw-SQL recipe runs `memhouse room-sql <<'SQL'` directly. It
+  used to wrap the call in a shell function, so every call asked for approval.
+
+## Deprecated
+
+Unchanged from 0.20.0: passwords on the command line (`--password`, `--member-password`,
+`--to-password`), and `MEMHOUSE_USER` / `MEMHOUSE_PASSWORD` as the admin for `migrate --v3-*`,
+still work with a warning and are refused from the next minor release. See
+[0.20.0's Deprecated](v0.20.0.md#deprecated).

package/docs/tutorials/01-first-house.md

@@ -41,9 +41,10 @@ This does four things:
 1. It starts ClickHouse in a container bound to `127.0.0.1:8123`, so only this machine
    can reach it. The data lives in a named volume.
 2. It creates two users. `memhouse_root` administers the house. A **member** named after
-   your OS user (`sam`, say) ships your sessions, and holds one grant: `mem.sam_*`.
-   Your rooms are `mem.sam_sessions`, `mem.sam_messages`, `mem.sam_tool_calls`, and
-   so on.
+   your OS user (`sam`, say) ships your sessions. It holds `mem.sam_*`, where your
+   sessions live (`mem.sam_session_parts`, `mem.sam_sessions` and four more), and its
+   own two tables in the capture archive (`mem_archive.sam_session_units`,
+   `_session_sources`), which keep every transcript byte as captured.
 3. It writes both credentials to `~/.memhouse/env`, mode 600. A local house is the one
    case where the admin credential is kept, so that `memhouse invite` works later with
    no flags.
@@ -58,7 +59,7 @@ it. See [the install guide](../guides/install.md).
 memhouse status
 ```
 
-Look for a connection check mark, row counts in your rooms, and a recent "last shipped"
+Look for a connection check mark, row counts in your tables, and a recent "last shipped"
 time. `memhouse doctor` goes further. It checks the whole pipeline and names anything
 skipped.
 
@@ -66,11 +67,13 @@ skipped.
 
 ```bash
 memhouse start
+memhouse dashboard
 ```
 
-This starts two background daemons. The shipper runs an incremental pass every five
-minutes. The dashboard runs at **http://localhost:4640**: sessions, cost by model and
-editor, tool calls, and which machine wrote what.
+`start` runs two background daemons. The shipper runs an incremental pass every five
+minutes. The dashboard shows sessions, cost by model and editor, tool calls, and which
+machine wrote what. `memhouse dashboard` opens it in your browser; the dashboard requires a
+token only your account can read, and that command hands it to the page.
 
 Those daemons do not survive a reboot. To make them permanent:
 

package/docs/tutorials/02-join-a-house.md

@@ -1,7 +1,7 @@
 # Tutorial 2: join a team's house
 
 Someone runs a house and invited you. They gave you a file named `invite-<you>.env`. At the
-end of this tutorial your sessions ship into your own rooms in their house, under a
+end of this tutorial your sessions ship into your own tables in their house, under a
 password only you know.
 
 **You need:**
@@ -26,16 +26,25 @@ memhouse install --env invite-<you>.env
 ```
 
 This reads the house's address, your member name and a starting password from the file.
-It then connects, checks that you can write to your rooms, and ships every session on
-this machine. Your rooms already exist and are named for you: `mem.<you>_messages`,
-`mem.<you>_sessions`, and so on. You hold one grant, on `mem.<you>_*`, and nothing else in
-the database.
-
-Then it **offers to change the password** to one only this machine knows. Say yes. The
-person who invited you set the starting password, and once you rotate it, theirs stops
-working. Then it deletes the invite file, which is spent.
-
-Scripted, with no terminal: `--yes` rotates without asking.
+It then connects, checks that you can write to your tables, and ships every session on
+this machine. Your tables are named for you: `mem.<you>_session_parts`, `mem.<you>_sessions`
+and four more conversation tables in `mem`, and your two in the capture archive, `mem_archive.<you>_session_units`
+and `_session_sources`. You hold `mem.<you>_*` and those two, and nothing else on the server.
+
+If the house is still on the 0.18 rooms (its admin has not converted it yet), the install
+follows the house and ships into `mem.<you>_messages` and the other 0.18 rooms. On
+schema 3 it prints `schema 3 tables for '<you>'`, and `~/.memhouse/env` holds
+`MEMHOUSE_SCHEMA=3`.
+
+Then it **changes the password** to a new one only this machine knows, and saves it in
+`~/.memhouse/env`. In a terminal it asks first; say yes. The person who invited you set the
+starting password, and once it is changed, theirs stops working. Then it deletes the invite
+file, which is spent.
+
+Scripted, or run by an agent with no terminal, it changes the password without asking.
+`--keep-password` keeps the invited one, and then the person who invited you still knows it.
+If the change fails, the install still completes, keeps the invite file, and tells you to
+run `memhouse passwd`.
 
 ## 3. Check who you are
 
@@ -54,12 +63,12 @@ memhouse start                # shipper + dashboard, until the next reboot
 memhouse service install      # or: survive reboots (systemd --user / LaunchAgent)
 ```
 
-Your dashboard is at http://localhost:4640. It reads the house, so it shows your
-sessions from every machine you install on, not just this one.
+`memhouse dashboard` opens your dashboard in the browser. It reads the house, so it shows
+your sessions from every machine you install on, not just this one.
 
 ## 5. More machines
 
-Every machine you own ships into the same rooms, and the `host` column tells them apart.
+Every machine you own ships into the same tables, and the `host` column tells them apart.
 The invite file is spent, so set up the next machine from this one's env file:
 
 1. Copy `~/.memhouse/env` to the new machine over a trusted channel, to any path, say
@@ -78,7 +87,7 @@ mints its own.
 
 ## 6. Read your teammates' memory
 
-Not yet. Nobody can read your rooms, and you cannot read theirs, until someone runs
+Not yet. Nobody can read your tables, and you cannot read theirs, until someone runs
 `memhouse share`. [Tutorial 3](03-share-your-memory.md) covers it from both sides.
 
 ## When something goes wrong

package/docs/tutorials/03-share-your-memory.md

@@ -1,11 +1,13 @@
 # Tutorial 3: share your memory
 
-Two members of one house: `alice` and `bob`. Each owns their rooms, and neither can read
-the other's. In this tutorial, alice lets bob read one project's history, then everything,
+Two members of one house: `alice` and `bob`. Each owns their tables, and neither can read
+the other's. In this tutorial, alice lets bob read one project's history, then all of it,
 then takes it back. Bob reads it from his own agent.
 
-**You need:** two members of the same house. If you have one house of your own, see
-[Invite members](../guides/invite.md) to add a second.
+**You need:** two members of the same house, on memhouse 0.20. If you have one house of
+your own, see [Invite members](../guides/invite.md) to add a second. On a house still on
+the 0.18 rooms, `share` works the 0.18 way; see
+[Share and revoke](../guides/share.md#a-house-on-the-018-rooms).
 
 ## 1. Alice shares one project
 
@@ -15,57 +17,64 @@ On alice's machine:
 memhouse share bob --only project=memhouse
 ```
 
-What this does:
+What this does, in this order:
 
-- grants bob `SELECT` on exactly three of alice's rooms: `alice_sessions`,
-  `alice_messages` and `alice_tool_calls`;
-- adds row policies so that, in those rooms, bob sees only rows where
-  `project = 'memhouse'`.
+1. adds a row policy to each of alice's six conversation tables, so bob sees only rows
+   where `project = 'memhouse'`. The three tables with a `project` column
+   (`alice_session_parts`, `alice_calls`, `alice_sessions`) pass those rows; the usage, link
+   and lifecycle tables have none, so they pass nothing, and the `sessions` row carries the
+   totals;
+2. grants bob `SELECT` on exactly those six tables.
 
-Bob gets nothing else. Alice's stats tables, `meta` and `events` stay closed to him, as
-does any room alice gains later.
+The filters go in before the grant, so bob never holds an unfiltered moment. He gets
+nothing else: not alice's capture archive (`mem_archive`), not `alice_meta` or
+`alice_events`, and no table alice gains later.
 
 Other scopes work the same way:
 
-- `session=…`
-- `host=…`
-- `source=…` (an editor, as stored: `claude-code`, `codex`, …)
+- `session=…`: a session ref as `memhouse q recent` prints it (`<harness>:<id>~…`), or a
+  bare id
+- `harness=…`: an editor, as stored (`claude-code`, `codex`, `opencode`, …); `source=`
+  means the same
+- `host=…`: one machine, by the id `memhouse doctor` lists under "host identity"
 - `folder=…`
-- `since=…` and `until=…` (dates)
+- `since=…` and `until=…`: dates; message parts, usage, calls and lifecycle records by their
+  own time, sessions by their start. A row with no time never matches, and neither does a
+  link
 
 Before it creates the first policy, `share` checks how the server treats readers that
 have no policy of their own: alice, and anyone with a full share. On some server
 configurations, a table's first row policy blinds those readers to every row. On such a
-server, `share` refuses rather than lock alice out of her own rooms.
+server, `share` refuses rather than lock alice out of her own tables.
 
 ## 2. Bob reads it
 
-Bob's credential can now see three of alice's rooms. From any ClickHouse client, or
-`/mem:sql` in bob's agent:
+Bob's credential can now see six of alice's tables. From any ClickHouse client, or by
+asking his agent (`/mem:sql`):
 
 ```sql
-SELECT project, count() FROM mem.alice_messages GROUP BY project
+SELECT project, count() FROM mem.alice_session_parts FINAL WHERE removed = 0 GROUP BY project
 -- one row: memhouse
 
-SELECT count() FROM mem.alice_session_stats
+SELECT count() FROM mem.alice_meta
 -- refused: bob holds no grant on it
 ```
 
-A query that strays outside the scope returns nothing, or is refused for the tables bob
-was never granted. It never returns more than the scope.
+A query that strays outside the scope returns nothing, or is refused for a table bob was
+never granted. It never returns more than the scope.
 
-## 3. Alice widens it to everything
+## 3. Alice widens it to all her sessions
 
 ```bash
 memhouse share bob
 ```
 
-A **full share** with no `--only`. Bob can now read all of `mem.alice_*`, including the
-stats, `meta` (alice's other share records among it) and `events`. The command says so
-when it runs. Use a full share for someone you would hand your laptop to.
+A **full share**, with no `--only`. Bob keeps `SELECT` on the same six tables, and the
+row policies are dropped once the grant is confirmed, so he now reads every session.
+That is all a full share reaches: the archive, `meta` and `events` stay closed.
 
-Going back from full to scoped is the same `--only` command. It takes the wildcard grant
-back first, so a failure part-way leaves bob with less access, never more.
+Going back from full to scoped is the same `--only` command. The filters are written first,
+so bob's view narrows before anything else changes.
 
 ## 4. See who can read what
 
@@ -88,9 +97,9 @@ part-way, the policies stay, so bob never ends up with an unfiltered share.
 ## What sharing cannot do
 
 - **Recall what was already read.** Bob may have copied rows while he could read them.
-- **Write.** A share is read-only. Only alice writes into alice's rooms.
+- **Write.** A share is read-only. Only alice writes into alice's tables.
 - **End with a password change.** Grants belong to the user, not the password. To cut
   bob off, revoke.
 
-More detail, including what a full share exposes and why scoped shares are table by
-table: [Share and revoke](../guides/share.md).
+More detail, including how a 0.18 share moves when a house is converted:
+[Share and revoke](../guides/share.md).

package/editors/antigravity.js

@@ -882,85 +882,6 @@ function getMessages(chat) {
   return messages;
 }
 
-// ============================================================
-// Usage / quota data from language server RPC
-// ============================================================
-
-function getUsage() {
-  const { isSubscriptionAccessAllowed } = require('./base');
-  if (!isSubscriptionAccessAllowed()) return null;
-  const resp = callRpc('GetUserStatus', {});
-  if (!resp || !resp.userStatus) return null;
-
-  const us = resp.userStatus;
-  const ps = us.planStatus || {};
-  const pi = ps.planInfo || {};
-  const modelConfigs = (us.cascadeModelConfigData || {}).clientModelConfigs || [];
-
-  const models = modelConfigs.map((m) => {
-    const qi = m.quotaInfo || {};
-    return {
-      label: m.label || null,
-      model: m.modelOrAlias?.model || null,
-      remainingFraction: qi.remainingFraction != null ? qi.remainingFraction : null,
-      resetTime: qi.resetTime || null,
-      supportsImages: m.supportsImages || false,
-    };
-  });
-
-  // Antigravity returns credits already in display units (no ÷100 needed)
-  const promptAlloc = ps.availablePromptCredits || 0;
-  const promptUsed = ps.usedPromptCredits || 0;
-  const flexAlloc = ps.availableFlexCredits || 0;
-  const flexUsed = ps.usedFlexCredits || 0;
-  const flowAlloc = ps.availableFlowCredits || 0;
-
-  const remainingPrompt = Math.max(0, promptAlloc - promptUsed);
-  const remainingFlex = Math.max(0, flexAlloc - flexUsed);
-  const totalRemaining = remainingPrompt + remainingFlex;
-
-  // Credit multipliers per model
-  const creditMultipliers = (pi.creditMultiplierOverrides || []).reduce((acc, entry) => {
-    const model = entry.modelOrAlias?.model;
-    if (model && entry.creditMultiplier != null) acc[model] = entry.creditMultiplier;
-    return acc;
-  }, {});
-
-  return {
-    source: 'antigravity',
-    plan: {
-      name: pi.planName || null,
-      tier: pi.teamsTier || null,
-      monthlyPromptCredits: (pi.monthlyPromptCredits || 0) / 100,
-      monthlyFlowCredits: (pi.monthlyFlowCredits || 0) / 100,
-      canBuyMoreCredits: pi.canBuyMoreCredits || false,
-    },
-    usage: {
-      promptCredits: { allocated: promptAlloc, used: promptUsed, remaining: remainingPrompt },
-      flexCredits: { allocated: flexAlloc, used: flexUsed, remaining: remainingFlex },
-      flowCredits: { allocated: flowAlloc },
-      totalRemainingCredits: totalRemaining,
-    },
-    billingCycle: {
-      start: ps.planStart || null,
-      end: ps.planEnd || null,
-    },
-    features: {
-      webSearch: pi.cascadeWebSearchEnabled || false,
-      browser: pi.browserEnabled || false,
-      knowledgeBase: pi.knowledgeBaseEnabled || false,
-      autoRunCommands: pi.cascadeCanAutoRunCommands || false,
-      commitMessages: pi.canGenerateCommitMessages || false,
-    },
-    models,
-    creditMultipliers,
-    user: {
-      name: us.name || null,
-      email: us.email || null,
-    },
-  };
-}
-
 function resetCache() { _lsCache = null; _lsCacheCheckedAt = 0; _modelMap = null; _sessionFolderMap = null; }
 
 const labels = { 'antigravity': 'Antigravity' };
@@ -1048,4 +969,4 @@ function getMCPServers() {
   ];
 }
 
-module.exports = { name, labels, getChats, getMessages, resetCache, getUsage, getArtifacts, getMCPServers };
+module.exports = { name, labels, getChats, getMessages, resetCache, getArtifacts, getMCPServers };