clearotron 0.3.0-beta.10 → 0.3.0-beta.2

package/.env.example

@@ -399,15 +399,6 @@ CLEAROTRON_DEMO=
 # effect: deployment
 # CLEAROTRON_INVOKED_AS=
 
-# Marks an install that has already moved itself out of npm's npx cache. `npx clearotron install` first
-# installs the same version under ~/.local and then runs that copy's install, with this set to 1, so the
-# copy does not try to move itself a second time. Unset, an install running from npx's cache moves.
-# Set by bin/onboard.mjs on the one process it starts, never by an operator, so the row is left
-# commented. It is listed for the reason CLEAROTRON_DEMO is: the catalogue is about what an operator can
-# FIND. Read by bin/onboard.mjs.
-# effect: deployment
-# CLEAROTRON_RELOCATED=
-
 # How many client what-ifs the runner drains at once (default 1). A what-if re-runs ONE stage of a run
 # that already exists, in a sandbox, at a client's request — the owner opened it to clients on
 # 2026-08-27 and ruled SPEND controls out with it ("ignore the call spend"). This is not one.
@@ -561,9 +552,8 @@ CLEAROTRON_DEMO_PROFILES=
 # Your organisation's name. `npm run setup` asks for it (and, on a local install, not for a sign-in
 # address) and writes it here, quoted, so a name holding a `#` survives. The first `clearotron start` files it as the first
 # organisation in the grants file (CLEAROTRON_ACCESS_FILE) when that file holds none; from then on the
-# grants file holds the name and renaming is an edit there. The portal also reads it, to name the
-# organisation on its top bar and on its sign-in refusal page. Unset or empty, no organisation is
-# invented. `clearotron start --organisation <name>` supplies it for one start, and a demo never reads
-# it. Read by bin/start.mjs and shared/brand.mjs.
+# grants file holds the name, renaming is an edit there, and this is not read. Unset or empty, no
+# organisation is invented. `clearotron start --organisation <name>` supplies it for one start, and a
+# demo never reads it. Read by bin/start.mjs.
 # effect: deployment
 CLEAROTRON_ORGANISATION_NAME=

package/INSTALL.md

@@ -64,15 +64,6 @@ run is [mcp-server/CONNECT.md](mcp-server/CONNECT.md), and why something is the
   npx clearotron install
   ```
 
-  Run from `npx`, the install first installs Clearotron under `~/.local`, as `npm install -g --prefix
-  ~/.local` would, and finishes from there. That way the `clearotron` command and your assistant's connection
-  do not point into npm's temporary cache, which npm replaces on an update and deletes when it cleans up.
-  Later, the `update` command updates that copy in place.
-
-  On WSL, a program on the Windows side can hold a port that WSL reports as free, and the browser reaches
-  it first. VS Code's Remote-SSH port forwarding is the common case. If the page that opens is not this
-  install's sign-in, run the same command again with `--port 28802`, or any free number.
-
   A *hosted* deployment needs Linux for one further thing, the systemd outbox trigger —
   [driver/systemd/README.md](driver/systemd/README.md).
 - **A reasoning CLI on your `PATH`, signed in.** This is the prerequisite people miss. Every stage runs
@@ -295,71 +286,6 @@ keeps working throughout.
 provider, so it is safe to run on any machine that has the repository. "Safe anywhere" is about spend,
 not about where it will run — on a packaged tree it refuses, as above.
 
-## 2a. Removing it
-
-An install is not one directory, so removing it is not one command. Everything it writes is listed here.
-Read the list before you delete anything: one of these directories holds your reports.
-
-**Stop it first.** If the product is running in a terminal, Ctrl-C in that terminal. If you installed the
-background services, `clearotron stop` stops them and removes their unit files. `clearotron status` says
-which of the two you have.
-
-**The program.** Installed globally, `npm rm -g clearotron` removes it. Installed by `clearotron install`
-(which is also what a demo run from `npx` leaves behind), it lives in two places under `~/.local`:
-
-```
-~/.local/lib/node_modules/clearotron
-~/.local/bin/clearotron
-```
-
-**The settings, and the keys.** `~/.config/clearotron/.env` holds this install's signing secrets, so
-deleting it invalidates every key it ever issued. Beside it: `~/.config/clearotron/token-denylist`, the
-list of keys you revoked, and `~/.config/clearotron/running`, which records a product running in a
-terminal and is rewritten on every start.
-
-**Your work.** The install keeps it all under one directory, `~/trademark` by default — wherever
-`CLEAROTRON_REPORTS_DIR`'s parent points if you moved it:
-
-```
-~/trademark/pool                              THE REPORTS. Every clearance this install delivered.
-~/trademark/workspace                         the working files of each run, including unfinished ones
-~/trademark/queue                             work ordered and not yet run
-~/trademark/outbox                            what the product prepared to send
-~/trademark/locks                             which runs are in flight
-~/trademark/config                            your companies, their projects and your saved searches
-~/trademark/config/recipes                    the saved searches themselves
-~/trademark/config/profiles                   the company profiles
-~/trademark/grants.json                       who may use this install
-~/trademark/portal-audit.log                  what the portal was asked to do
-~/trademark/portal-local-credential.json      the sign-in this install minted for you
-```
-
-**Keep the pool if you want the reports.** They are finished documents and nothing else reads them: move
-`~/trademark/pool` somewhere of your own and delete the rest. Deleting the pool deletes the clearances.
-
-**The demo, if you ran one.** `~/trademark-demo` holds the demo's own copy of everything above, including
-its own copy of the program under `~/trademark-demo/program`. It is one directory to remove and it shares
-nothing with an install.
-
-**The background services, if you installed them.** `clearotron stop` removes the four unit files; if you
-would rather see them, they are in `~/.config/systemd/user`:
-
-```
-clearotron-portal.service
-clearotron-mcp-face.service
-clearotron-worker.service
-clearotron-client-mcp.service
-```
-
-**And `~/.env`, which only a background install writes.** A service inherits nothing from the terminal
-that installed it, so `clearotron start --background` writes everything those services need into `~/.env`,
-mode 600 — your register credential, your research key and the engine's settings among it. It is not the
-same file as `~/.config/clearotron/.env`, which configures the product when you run it yourself. Delete
-both, or you leave a file of credentials in your home for services that no longer exist.
-
-Nothing else on the machine is ours: no system-wide files, no services outside your own user, and nothing
-in `/etc`, `/usr` or `/var`.
-
 ## 3. Configuration (environment)
 
 Runtime configuration is by environment variable, and there are two ways to supply them.
@@ -565,25 +491,6 @@ matches, the neutral Generic default applies.
 - **Your real customers live outside the repo.** Point `CLEAROTRON_CUSTOMERS_DIR` at your own private
   config store and the engine loads *those* accounts instead. **Same engine, different config path** —
   the code carries no customer identities.
-
-  Two things go with it, and both are refusals rather than preferences:
-
-  - **`PROFILE_REPO_ROOT` moves too.** The customer directory has to sit inside the repository that
-    variable names, because editing a profile is a commit. Point one somewhere new and leave the other
-    behind and the portal and the profile service both refuse to start, naming both variables.
-  - **That repository needs a `user.name` and a `user.email` of its own.** Saves are committed under
-    the name of whoever asked for them, but git also records who *made* the commit, and it will not
-    commit at all without one. A service account usually has no global git identity, so a store created
-    by hand needs its own:
-
-    ```bash
-    git init -b main /srv/clearotron-store
-    git -C /srv/clearotron-store config user.name  "clearotron local install"
-    git -C /srv/clearotron-store config user.email "clearotron@example.com"
-    ```
-
-    `clearotron start` does this for the store it creates. A store you make yourself does not get it,
-    and the symptom is the first save failing at a commit rather than anything about profiles.
 - **Run data is external too.** Published reports, audits, and per-run state go to the archive pool at
   `CLEAROTRON_REPORTS_DIR`. Nothing customer-specific is committed to the repository.
 
@@ -823,13 +730,9 @@ Use the demo to see what this system produces. Use `npx clearotron start` to run
 
 - Generates `PORTAL_SECRET` and `TRADEMARK_MCP_TOKEN_SECRET` and **appends** them to `~/.config/clearotron/.env` at
   mode 600. Append, never rewrite: that file also holds the credentials `npx clearotron install` collected.
-  It also records where saved searches are kept, `CLEAROTRON_RECIPES_DIR` and `RECIPE_REPO_ROOT`, so
-  `clearotron doctor` and a connected assistant read the same saved searches as the portal.
 - Creates `~/trademark/` — `pool/`, `workspace/`, `queue/`, `outbox/`, `locks/`, an empty grants file,
   and a small git repository for saved searches. Same base directory `npx clearotron install` uses, so whichever
   of the two you ran first, the other finds the same install. Move it with `npx clearotron start --base <dir>`.
-  That does not move anything the env file already names: the saved-search lines above, and the data
-  directories `npx clearotron install` wrote, keep pointing at the old place until you edit them.
 - Mints your sign-in passphrase and **prints it once**. Write it down. It is stored as a scrypt digest in
   `~/trademark/portal-local-credential.json`, nothing can read it back, and no later start reprints it. To
   get a new one, run `clearotron passphrase --reset`. An install that has been signing in with
@@ -1000,19 +903,12 @@ their own integration work.
 **Two shapes, and the line between them is what your assistant can do — not where it runs.** Ruling
 2026-09-03, on the vendor's own documented behaviour:
 
-1. **Clearotron is installed on the machine the assistant runs on** — Claude's desktop app, Claude Code,
-   Codex, the ChatGPT desktop app, an agent that runs commands. The assistant spawns the server over
-   stdio. No address, no key, no network, no ingress. `npx clearotron start` prints the one line to
-   paste, and `npx clearotron connect --where here` hands it over per assistant.
-2. **Clearotron is running somewhere else** — a server, a cloud machine, anywhere the assistant is
-   not. These need **a publicly reachable HTTPS address**, plus a key made for the person connecting.
-   Always. Claude (app, web, Cowork and mobile), ChatGPT on the web, Perplexity and other agents only
-   ever connect this way; Claude Code and Codex can connect either way. `npx clearotron connect
-   --where elsewhere` makes the key and prints the steps for the assistant you name.
-
-Without `--where`, `connect` asks when both answers are possible, and `--client <name>` on its own keeps
-the answer that assistant had before: a key for Claude, the local line for Claude Code and Codex.
-`npx clearotron disconnect` takes the same `--where`.
+1. **An assistant that can launch a local process** — Claude Code, Claude Desktop's local config,
+   Codex CLI, an agent that runs commands. It spawns the server over stdio. No address, no key, no
+   network, no ingress. `npx clearotron start` prints the one line to paste, and `npx clearotron
+   connect` hands it over per assistant.
+2. **Everything else, wherever it appears to run** — Cowork, ChatGPT, claude.ai, Perplexity, the mobile
+   apps. These need **a publicly reachable HTTPS address**, plus a key. Always.
 
 **A loopback address is never an answer for shape 2, and that is not about your network.** A remote MCP
 connector is reached **from the vendor's cloud**, never from the reader's device. Anthropic's own help

package/README.md

@@ -19,62 +19,51 @@ no gateway, no platform, and nothing about your matters reaches us.
 
 ## Install
 
-**See it work first, with nothing installed.**
+**See it work first, with nothing checked out.**
 
 ```bash
 npx clearotron demo
 ```
 
-That fetches the published package — it will ask once before downloading — then replays finished
-clearances into a local portal and prints the portal's address and the passphrase to sign in with. Open
-the address in your browser. No account, no credentials, no network calls to us.
+That fetches the published package — it will ask once before downloading — then replays a finished
+clearance into a local pool and opens the report in your browser. No account, no credentials, no network
+calls to us.
 
 **Then install it.**
 
 ```bash
-npx clearotron install
+npm install -g clearotron
 ```
 
-Node 22.13 or newer, on macOS or Linux. It needs no root: it puts the program under `~/.local`, with the
-`clearotron` command in `~/.local/bin`, then asks one question at a time and checks each credential
-before it saves it. With `~/.local/bin` on your `PATH`, every command below works in the short form;
-otherwise use the full path `install` prints at the end. **On Windows the demo above runs natively; a
-real clearance needs WSL2.** Native Windows clearances are planned for a later release. Until then the
-engine does not run on native Windows: it resolves the reasoning CLI the POSIX way, and a clearance
-started there refuses at preflight.
-
-`npm install -g clearotron` also works where npm's global directory is yours to write. On a Linux Node
-from the distribution or NodeSource that directory is `/usr`, owned by root, and npm refuses with
-`EACCES`. Do not answer that with `sudo`; install under your home instead:
-`npm install -g clearotron --prefix ~/.local`.
+Node 22.13 or newer, on macOS or Linux. That puts `clearotron` on your `PATH`; every command below
+works in that short form. **On Windows the demo above runs natively; a real clearance needs WSL2.**
+Native Windows clearances are planned for a later release. Until then the engine does not run on native
+Windows: it resolves the reasoning CLI the POSIX way, and a clearance started there refuses at preflight.
 
-`npx clearotron install` gives you the **stable** release — the one that has run a real clearance end to
-end before it was published. If you want the newest code instead, a beta is published whenever there is
-something worth testing — deliberately, days apart, not on every merge:
+That command gives you the **stable** release — the one that has run a real clearance end to end before it
+was published. If you want the newest code instead, a beta is published whenever there is something worth
+testing — deliberately, days apart, not on every merge:
 
 ```bash
-npx clearotron@beta install
+npm install -g clearotron@beta
 ```
 
 What each channel promises, and when a stable is cut: [docs/RELEASES.md](docs/RELEASES.md). If you are not
 sure, the first command is the one you want.
 
-Removing it later: **[INSTALL.md §2a](INSTALL.md#2a-removing-it)** lists every path an install writes, and
-says which one holds your reports so you can keep them deliberately.
-
 ## Quick start
 
-With it installed, check what it found before it does anything. `doctor` only reads — it writes nothing,
-calls nobody, and names whatever is still missing:
+Check the install before it does anything. `doctor` only reads — it writes nothing, calls nobody, and
+names whatever is still missing:
 
 ```bash
-clearotron doctor
+npx clearotron doctor
 ```
 
-Then start the product and open the portal address it prints:
+Then start the product and open the portal it prints:
 
 ```bash
-clearotron start
+npx clearotron start
 ```
 
 That is the portal a brand owner uses. Ordering a clearance is the same screen — describe it in a
@@ -93,10 +82,11 @@ rights-holders behind them by jurisdiction:
 
 ![The conflict landscape, with rights-holders grouped by jurisdiction](docs/assets/portal-conflict-landscape.jpg)
 
-Then run your own: order it in the portal, or hand the engine a job file:
+Then run your own. `install` asks one question at a time and checks each credential before it saves it:
 
 ```bash
-clearotron run --job my-job.json
+npx clearotron install
+npx clearotron run --job my-job.json
 ```
 
 ## How it fits together

package/bin/connect.mjs

@@ -45,9 +45,8 @@ import { homedir, userInfo } from "node:os";
 import { fileURLToPath } from "node:url";
 import { execFileSync } from "node:child_process";
 import { createServer } from "node:net";
-import { CONNECT_CLIENTS, WHERE_FLAG, clientById, leadRouteFor, plainStep, whatItNeeds } from "../shared/connect-clients.mjs";
+import { CONNECT_CLIENTS, clientById, whatItNeeds } from "../shared/connect-clients.mjs";
 import { stdioConnectFor, STDIO_SHAPES } from "../shared/stdio-connect.mjs";
-import { isWsl } from "../shared/wsl.mjs";
 import { defaultDenylistPath, clientDoorAddress, clientDoorPort, clientDoorState, enablePlan, applyEnablePlan, describeChange, recordConnectKey, CLIENT_DOOR_UNIT } from "../shared/client-door.mjs";
 import { mintToken, tokenId, resolvePerson, loadGrants } from "../shared/scope.mjs";
 import { envFrom } from "../shared/env-aliases.mjs";
@@ -206,8 +205,7 @@ function deploymentHas(env = process.env) {
   return {
     // EVERY SHAPE, RESOLVED ONCE. A row picks its own; nothing here knows a client's name.
     stdioRoutes: Object.fromEntries(Object.keys(STDIO_SHAPES).map((shape) =>
-      [shape, stdioConnectFor(shape, { workDir: env.CLEAROTRON_WORK_DIR || null, reportsDir: env.CLEAROTRON_REPORTS_DIR || null })])),
-    wsl: isWsl({ env }),
+      [shape, stdioConnectFor(shape, { workDir: env.CLEAROTRON_WORK_DIR || null })])),
     // WHERE THE DOOR BINDS — not an address handed to any assistant. It is the loopback address the
     // unit listens on, and `enablePlan` needs it to write the unit. It used to be passed to the
     // resolver as `localAddress` and served to Cowork as somewhere to connect, which is the false
@@ -557,12 +555,17 @@ async function render(offer, have, { dryRun, running, allowMove = false }) {
     return 1;
   }
 
-  if (offer.route === "disk") {
-    // THE ROW'S OWN STEPS, and nothing written here. A command and a settings block are not the same
-    // instruction — saying "run this" over a TOML block is how a reader pastes four lines into a shell —
-    // and the steps already say which each one is and where it goes.
-    printSteps(offer, null);
+  if (offer.route === "disk" || (offer.route === "either" && offer.command)) {
+    // A COMMAND AND A CONFIG BLOCK ARE NOT THE SAME INSTRUCTION, and saying "run this" over a TOML
+    // block is how a reader pastes four lines into a shell. The shape says which it is.
+    const s = offer.stdio;
+    say(s?.kind === "config"
+      ? `  Add this to ${s.where}:`
+      : "  Run this once, on this machine:");
     say("");
+    for (const line of String(offer.command).split("\n")) say(`    ${line}`);
+    say("");
+    if (s?.after) { say(`  ${s.after}`); say(""); }
     say(`  ${offer.note}`);
     return 0;
   }
@@ -618,40 +621,22 @@ async function render(offer, have, { dryRun, running, allowMove = false }) {
   }
 
   say(`  Address:  ${offer.address}`);
-  // Printed once, stored nowhere — and only here when no step hands it over. A step whose copy carries
-  // the key prints it inside the line the reader pastes, which is the one place it is needed.
-  const keyInSteps = (offer.steps ?? []).some((s) => s.copy?.kind === "secret");
-  if (key && !keyInSteps) say(`  Key:      ${key}`);
-  printSteps(offer, key);
-  say("");
-  say(`  ${offer.note}`);
-  return 0;
-}
-
-/**
- * The offer's own steps, numbered, with each copy printed under the step that hands it over.
- *
- * ── AND WHERE TO PUT THEM ( — F35) ───────────────────────────────────────
- *
- * The owner was left with two strings and no destination: *"I don't know how to connect it in Claude
- * Cowork with those details."* The steps were DEFINED IN THE PRODUCT the whole time and this verb simply
- * never printed them. Nothing is authored here; a second set of instructions written at the CLI would
- * drift from the page's, which is the defect connect-clients-are-data exists against. A secret copy is
- * printed with the key this press minted put in its slot — the page does the same substitution into the
- * clipboard — and with no key (a dry run) the step prints and its copy does not.
- */
-function printSteps(offer, key) {
+  if (key) say(`  Key:      ${key}`);          // printed once, stored nowhere
+  // ── AND WHERE TO PUT THEM ( — F35) ───────────────────────────────────────
+  //
+  // The owner was left with two strings and no destination: *"I don't know how to connect it in Claude
+  // Cowork with those details."* The steps were DEFINED IN THE PRODUCT the whole time — `withSteps`
+  // computes them for every offer, interpolating this install's own address and operator — and this
+  // verb simply never printed them. Nothing new is authored here; a second set of instructions written
+  // at the CLI would drift from the page's, which is the defect connect-clients-are-data exists against.
   if (offer.steps?.length) {
     say("");
     say(`  In ${offer.client?.name ?? "your assistant"}:`);
-    offer.steps.forEach((step, n) => {
-      say(`    ${n + 1}. ${plainStep(step.text)}`);
-      const c = step.copy;
-      const text = !c ? null : c.kind === "secret" ? (key ? c.template.split(c.slot).join(key) : null) : c.text;
-      if (text) { say(""); for (const line of text.split("\n")) say(`         ${line}`); say(""); }
-      if (step.hint) say(`       ${plainStep(step.hint)}`);
-    });
+    offer.steps.forEach((step, n) => say(`    ${n + 1}. ${step}`));
   }
+  say("");
+  say(`  ${offer.note}`);
+  return 0;
 }
 
 async function main() {
@@ -669,9 +654,6 @@ async function main() {
     say("  not about you.");
     say("");
     say("    --client <name>   skip the question (see --list for the names)");
-    say("    --where here      your assistant runs on this machine: it starts the software itself");
-    say("    --where elsewhere your assistant runs somewhere else and reaches this install over the");
-    say("                      internet, with a key made for you now");
     say("    --list            the assistants this build knows");
     say("    --dry-run         say what would change, change nothing");
     say("    --allow-checkout-move");
@@ -681,7 +663,7 @@ async function main() {
     say("");
     return 0;
   }
-  const known = new Set(["--client", "--where", "--list", "--dry-run", "--allow-checkout-move", "--help", "-h"]);
+  const known = new Set(["--client", "--list", "--dry-run", "--allow-checkout-move", "--help", "-h"]);
   const unknown = argv.filter((a) => a.startsWith("--") && !known.has(a));
   if (unknown.length) {
     console.error(`connect: unrecognised flag(s): ${unknown.join(", ")}`);
@@ -689,12 +671,6 @@ async function main() {
     process.exit(2);
   }
   const dryRun = argv.includes("--dry-run");
-  const w = argv.indexOf("--where");
-  if (w >= 0 && !Object.hasOwn(WHERE_FLAG, argv[w + 1] ?? "")) {
-    console.error(`connect: --where takes one of: ${Object.keys(WHERE_FLAG).join(", ")}`);
-    process.exit(2);
-  }
-  let route = w >= 0 ? WHERE_FLAG[argv[w + 1]] : null;
   // F40 — reason about the RUNNING product from the units' own environment, not this CLI's env file.
   const running = runningEnv();
   const have = deploymentHas(running.env);
@@ -736,30 +712,9 @@ async function main() {
       chosen = CONNECT_CLIENTS[Number(answer) - 1] ?? clientById(answer);
     } finally { rl.close(); }
     if (!chosen) { console.error("connect: not one of the listed assistants."); process.exit(2); }
-    // THE SECOND QUESTION, ASKED ONLY WHEN IT HAS TWO ANSWERS — the page's own, in the terminal's words.
-    // Where only one route is served here, asking would offer a choice whose other half cannot work.
-    const both = ["disk", "public-http"].filter((r) => whatItNeeds(chosen, have, r)?.served);
-    if (!route && both.length > 1) {
-      say("");
-      say("  Where does it run?");
-      say("");
-      say("    1) On this machine — it starts the software itself, nothing to open up");
-      say("    2) Somewhere else — it reaches this install over the internet, with a key made for you now");
-      say("");
-      const rl2 = createInterface({ input: stdin, output: stdout });
-      try {
-        const answer = (await rl2.question("  1-2: ")).trim();
-        route = answer === "1" ? "disk" : answer === "2" ? "public-http" : null;
-      } finally { rl2.close(); }
-      if (!route) { console.error("connect: answer 1 or 2."); process.exit(2); }
-    }
-    route ??= both[0] ?? chosen.lead;
   }
 
-  // NAMED WITHOUT --where: the route this id had before every row took both, so a scripted
-  // `--client cowork` still mints a key and `--client codex` still prints a settings block.
-  route ??= leadRouteFor(argv[i + 1]);
-  return await render(whatItNeeds(chosen, have, route), have, { dryRun, running, allowMove: argv.includes("--allow-checkout-move") });
+  return await render(whatItNeeds(chosen, have), have, { dryRun, running, allowMove: argv.includes("--allow-checkout-move") });
 }
 
 // THE DISPATCH RUNS ONLY WHEN THIS FILE IS THE COMMAND. Without the guard, importing

package/bin/disconnect.mjs

@@ -57,7 +57,7 @@ import { stdin, stdout } from "node:process";
 import { readFileSync, writeFileSync, existsSync, mkdirSync, appendFileSync } from "node:fs";
 import { join, dirname } from "node:path";
 import { homedir, userInfo } from "node:os";
-import { CONNECT_CLIENTS, WHERE_FLAG, clientById, leadRouteFor } from "../shared/connect-clients.mjs";
+import { CONNECT_CLIENTS, clientById } from "../shared/connect-clients.mjs";
 import { defaultDenylistPath, disablePlan, revokeEveryonePlan, applyDisablePlan, describeClosure, recordedKeysFor, removeRecordedKeys } from "../shared/client-door.mjs";
 import { loadGrants } from "../shared/scope.mjs";
 import { envFrom } from "../shared/env-aliases.mjs";
@@ -83,8 +83,6 @@ async function main() {
     say("  `clearotron grant` manages that.");
     say("");
     say("    --client <name>   which assistant you connected (see --list for the names)");
-    say("    --where here|elsewhere");
-    say("                      how you connected it: on this machine, or over the internet with a key");
     say("    --list            the assistants this build knows");
     say("    --everyone        the admin act: revoke EVERY issued key on this install. It says");
     say("                      how many keys and how many people that is before doing it.");
@@ -92,7 +90,7 @@ async function main() {
     say("");
     return 0;
   }
-  const known = new Set(["--client", "--where", "--list", "--dry-run", "--everyone", "--help", "-h"]);
+  const known = new Set(["--client", "--list", "--dry-run", "--everyone", "--help", "-h"]);
   const unknown = argv.filter((a) => a.startsWith("--") && !known.has(a));
   if (unknown.length) {
     console.error(`disconnect: unrecognised flag(s): ${unknown.join(", ")}`);
@@ -139,21 +137,18 @@ async function main() {
   say(`  ${chosen.name}`);
   say("");
 
-  // THE ROUTE DECIDES THE SIDE, not the assistant: every row takes both now. Connected on this machine,
-  // it never touched this install; connected over the internet, it holds a key and the key is what goes.
-  // Unnamed, the route is the one `connect` gives the same id unnamed, so the two verbs pair up.
-  const w = argv.indexOf("--where");
-  if (w >= 0 && !Object.hasOwn(WHERE_FLAG, argv[w + 1] ?? "")) {
-    console.error(`disconnect: --where takes one of: ${Object.keys(WHERE_FLAG).join(", ")}`);
-    process.exit(2);
-  }
-  const route = w >= 0 ? WHERE_FLAG[argv[w + 1]] : (i >= 0 ? leadRouteFor(argv[i + 1]) : chosen.lead);
-  if (route === "disk") {
+  // The row's own property decides the side. `accepts: "stdio"` never touched this install; "either"
+  // only opens the door when its stdio route was missing, and on THIS box (the one disconnect runs on)
+  // the stdio route resolves, so its connect handed over a command too.
+  if (chosen.accepts === "stdio" || chosen.accepts === "either") {
     say("  Connecting this assistant changed nothing on this install — it runs the software itself,");
     say("  from the configuration you added on its side. To disconnect it, remove that entry in the");
     say("  assistant's own settings.");
-    say("");
-    say("  If you connected it over the internet instead, run this again with --where elsewhere.");
+    if (chosen.accepts === "either") {
+      say("");
+      say("  If you connected it by address instead, the door and key are shared — disconnect the");
+      say("  assistant you named when the door was opened, and the closure covers this one too.");
+    }
     return 0;
   }
 

package/bin/example.mjs

@@ -47,7 +47,6 @@ import { spawn } from "node:child_process";
 import { BRAND } from "../shared/brand.mjs";   // — the installer's own name, from the tenant seam
 import { envFrom } from "../shared/env-aliases.mjs";   // — resolves EITHER spelling; names the retired one because that is the live-writable half
 import { isFrozen, demoChildren, publishSource } from "../driver/demo-container.mjs";   // — one definition of what a frozen demo is, for the player AND the gate
-import { ensureDemoProgram, demoProgramEnv } from "../shared/permanent-install.mjs";
 
 const REPO = join(dirname(fileURLToPath(import.meta.url)), "..");
 
@@ -370,19 +369,8 @@ console.log(`  Removing this demo later is one directory:  ${removeDirectory(dem
 strayFromAnOlderDemo();
 console.log("");
 
-// ── RUN FROM NPX, THE SERVICES RUN FROM THE DEMO'S OWN COPY ─────────────────────────────────────────
-//
-// Started from npm's cache, the supervisor printed every command it gives the reader as `cd <npm's cache>
-// && npx clearotron …`: the passphrase reset, the key, the free-port hint, `start --background`. Each one
-// failed once npm cleaned that cache (measured on a published beta, 2026-09-11). So the copy the demo
-// keeps in `<base>/program` is laid down first and the supervisor is started from it, which also puts the
-// portal and the doors on a program that outlives the cache. Everywhere else, and when the copy cannot be
-// made, it starts from here as before.
-const programRoot = ensureDemoProgram({ base: demoBase, say: (line) => console.log(line) });
-const startFrom = programRoot ?? REPO;
-const child = spawn(process.execPath, [join(startFrom, "bin", "start.mjs"), ...startArgs], {
-  cwd: startFrom, stdio: ["ignore", "inherit", "inherit"],
-  env: programRoot ? demoProgramEnv(process.env) : process.env,
+const child = spawn(process.execPath, [join(REPO, "bin", "start.mjs"), ...startArgs], {
+  cwd: REPO, stdio: ["ignore", "inherit", "inherit"],
 });
 child.on("error", (e) => die(`demo: could not start the portal: ${String(e?.message ?? e)}`));
 // Its exit code is the demo's. A supervisor that swallowed a child's refusal would report a demo that

package/bin/key.mjs

@@ -29,9 +29,7 @@
 import "../shared/env-local.mjs";   // side effect: apply the install's .env — FIRST, before anything reads process.env
 import { invocationPrefix } from "../shared/invocation.mjs";
 import { existsSync, readFileSync } from "node:fs";
-import { defaultGrantsPath, installPaths } from "./start.mjs";
-import { demoTokenSecretPath } from "../shared/client-door.mjs";
-import { resolvePerson } from "../shared/scope.mjs";   // the door's own reading of the guest list, so one answer serves both
+import { defaultGrantsPath } from "./start.mjs";
 import { mintFromOptions } from "../mcp-server/mint-token.mjs";
 
 const argv = process.argv.slice(2);
@@ -46,7 +44,6 @@ const USAGE = `usage: ${p}clearotron key issue <email> [options]
 
     --accounts a,b     cap the key to these account keys as well (omit = whatever their grant allows)
     --ttl-days <n>     how long it is valid (default 90)
-    --base <dir>       the install or demo to issue for, when it is not the one set up in ~/trademark
 
 The token is printed ONCE on stdout and stored nowhere — possession is the credential. Everything
 else goes to stderr, including the jti that revokes it.`;
@@ -68,17 +65,6 @@ const email = positional[0];
 if (!email) die(`who is the key for? Give the person's email.\n\n${USAGE}`);
 if (!email.includes("@")) die(`"${email}" is not an email address — the subject of an account key is the identity their assistant presents, and the grants file is keyed on it.`);
 
-// `--base` NAMES THE INSTALL, as it does for `start` and `passphrase`: its guest list, and — for a demo,
-// which keeps its signing secret in its own base rather than in any settings file — that secret. Without
-// it the verb read the install's settings and refused to issue a key for a running demo.
-const baseAt = rest.indexOf("--base");
-const base = baseAt >= 0 ? rest[baseAt + 1] : null;
-if (baseAt >= 0 && (!base || base.startsWith("--"))) die(`--base needs a directory.\n\n${USAGE}`);
-if (base) {
-  const secretFile = demoTokenSecretPath(base);
-  if (existsSync(secretFile)) process.env.TRADEMARK_MCP_TOKEN_SECRET = readFileSync(secretFile, "utf8").trim();
-}
-
 const ttlDays = Number(flag("--ttl-days") ?? 90);
 const accounts = flag("--accounts") ? flag("--accounts").split(",").map((s) => s.trim()).filter(Boolean) : null;
 
@@ -107,19 +93,15 @@ for (const line of minted.notes) console.error(line);
 // inert. STDERR, so the token stays alone on stdout and `key issue ... > token.txt` keeps working —
 // that split is deliberate and this must not undo it.
 try {
-  const rosterPath = base ? installPaths(base).grants : defaultGrantsPath();
+  const rosterPath = defaultGrantsPath();
   if (!existsSync(rosterPath)) {
     console.error(`\nNOTE: no guest list at ${rosterPath} yet, so nothing grants ${email} anything and this key will be refused at the door. \`clearotron start\` writes the list; then: clearotron grant add ${email} --tenant <name> --accounts <brand-owner-key>`);
   } else {
-    // THE DOOR'S OWN RESOLVER DECIDES, not a second reading of the file. This walked `tenants[].users`
-    // alone, and the demo's guest list grants its account through the top-level `people` map — so the
-    // demo's own key came with a note saying the door would refuse it, over a key the door accepts
-    // (driven 2026-09-11). One reader for one question.
     const roster = JSON.parse(readFileSync(rosterPath, "utf8"));
-    const person = resolvePerson(email, roster);
-    const listed = Boolean(person && (person.everything || person.accounts?.length || person.organisations?.length));
+    const tenants = roster?.tenants && typeof roster.tenants === "object" ? roster.tenants : {};
+    const listed = Object.values(tenants).some((t) => t?.users && Object.prototype.hasOwnProperty.call(t.users, email));
     if (!listed)
-      console.error(`\nNOTE: ${email} is granted nothing in ${rosterPath}, so this key resolves to no accounts and the door will refuse it. Grant them access with: clearotron grant add ${email} --tenant <name> --accounts <brand-owner-key>`);
+      console.error(`\nNOTE: ${email} is on no tenant in ${rosterPath}, so this key resolves to no accounts and the door will refuse it. Grant them access with: clearotron grant add ${email} --tenant <name> --accounts <brand-owner-key>`);
   }
 } catch (e) {
   // A ROSTER THIS COMMAND CANNOT READ IS NOT A ROSTER SAYING THE SUBJECT IS ABSENT. Said as what it is,