clearotron 0.2.2 → 0.2.3

package/.env.example

@@ -508,3 +508,31 @@ CLEAROTRON_REQUESTER_WHATSAPP=
 # requester notice reaches. Read by driver/stages.mjs (whatsappRouting).
 # effect: deployment
 CLEAROTRON_WHATSAPP_OPERATOR_COPY=
+
+# ── The two switches that reveal accounts an install deliberately does not offer ──────────────────
+#
+# NEITHER IS FOR AN OPERATOR. Both are set by the product's own commands, and a row here exists because
+# product code reads them, not because copying this file should set them. Leave both unset. Setting
+# either on a real deployment puts accounts in a picker that a clean install is meant not to have.
+#
+# `1` makes the profile loader return the three test-suite fixture accounts in the roster
+# it resolves. They are marked `testFixture` and are refused otherwise on every install route, because a
+# packaging exclusion protects only the tarball and `git clone && npm install` is a documented way in.
+# Set by scripts/test-run.mjs, once, for every child — most checks that need a fixture do not call the
+# loader directly, so there is no argument to pass. An explicit `includeTestFixtures` argument beats
+# this, distinguished on `undefined`, so a check asking what a customer's install resolves is never
+# handed the suite's answer instead. Read by driver/profiles.mjs.
+# effect: harness
+CLEAROTRON_TEST_FIXTURE_PROFILES=
+
+# `1` makes the profile loader return the BUNDLED demo account (demo-brand-owner, marked `demoData`).
+# A fresh install resolves `generic` alone — owner ruling 2026-09-08, so nobody has to clean demo
+# material out of an environment they just made — and the demo brings its own account when it runs.
+# Set by `clearotron demo`, by `clearotron start --demo`, and by scripts/test-run.mjs.
+#
+# The gate is on the LAYER, not the flag: a `demoData` account in a deployment's OWN configured store is
+# that deployment's choice and stays offered whatever this is set to, and the admission wall still
+# refuses a real clearance under it. An explicit `includeDemo` argument beats this, on the same rule.
+# Read by driver/profiles.mjs.
+# effect: harness
+CLEAROTRON_DEMO_PROFILES=

package/.nvmrc

@@ -1 +1 @@
-22
+22.13

package/INSTALL.md

@@ -38,13 +38,15 @@ run is [mcp-server/CONNECT.md](mcp-server/CONNECT.md), and why something is the
   ```
 
   Skip this on any machine that already builds software.
-- **Node.js >= 22**, and npm. A hard floor: `package.json` declares it, `.nvmrc` pins it, and the free
-  US register runs on `node:sqlite`, which ships with FTS5 from Node 22. Node 20 installs and then fails
-  at the first US search. `nvm use` picks the pin up.
-- **macOS, Linux, or native Windows for the demo; WSL2 with Node 22 for a clearance.** `npx clearotron
+- **Node.js >= 22.13**, and npm. A hard floor, and the minor matters: the free US register runs on
+  `node:sqlite`, which is not a built-in module before 22.13 — measured across releases, 2026-09-08. On
+  Node 20, or on 22.0 through 22.12, the install succeeds and the first US search fails with
+  `ERR_UNKNOWN_BUILTIN_MODULE`, saying nothing about Node. `package.json` declares the floor, the
+  install refuses below it before writing anything, and `nvm use` picks the pin up.
+- **macOS, Linux, or native Windows for the demo; WSL2 for a clearance.** `npx clearotron
   demo` runs anywhere Node does, native Windows included. A real clearance does not: the engine resolves
   the reasoning CLI the POSIX way, so a native-Windows clearance refuses at preflight even with the CLI
-  on `PATH`. On Windows, `wsl --install`, then install Node 22 **inside** the Linux distribution and work
+  on `PATH`. On Windows, `wsl --install`, then install Node 22.13 or newer **inside** the Linux distribution and work
   through this page from there. A *hosted*
   deployment needs Linux for one further thing, the systemd outbox trigger —
   [driver/systemd/README.md](driver/systemd/README.md).
@@ -459,9 +461,9 @@ matches, the neutral Generic default applies.
 
 - **Bundled with the package** (`driver/profiles/`): `generic.json` (the Generic default) and
   `demo-brand-owner.json`, the account the demo runs as, so you can run and read the machinery
-  immediately. `driver/profiles/README.md` documents every field. (A clone carries three more —
-  `aurora`, `zephyr`, `petcary` — which are fixtures the test suite reads, not accounts to run
-  clearances for. They are excluded from the published package for exactly that reason.)
+  immediately. `driver/profiles/README.md` documents every field. (A clone of the repository carries
+  three more, marked `testFixture` in their own files: the test suite reads them, no install offers
+  them, and they are excluded from the published package as well.)
 - **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.
@@ -480,8 +482,8 @@ working examples in `driver/profiles/`:
   the engine attaches to the profile it loads. One ships beside a bundled demo customer.
 - **Project overlays** — `projects/<customer-key>/<slug>.json`. A project is one engagement under a
   customer: a launch screening, a flagship clearance, a regional push. Each may carry its own
-  `<slug>.context.md` beside it. `projects/aurora/console-ecosystem.json` and
-  `projects/demo-brand-owner/japan-and-korea-app-launch.json` are the shipped examples.
+  `<slug>.context.md` beside it. `projects/demo-brand-owner/japan-and-korea-app-launch.json` is the
+  shipped example.
 
 ### What a project may and may not change
 
@@ -536,7 +538,7 @@ Copy or author the customers, context packs and project overlays you want; assum
      "forwarder": "alex",
      "forwarderEmail": "alex@example.com",
      "forwarderDomain": "example.com",
-     "marks": [{ "ref": "TM-0001", "name": "AURORA SKY", "classes": [9, 42] }],
+     "marks": [{ "ref": "TM-0001", "name": "IRONWHISK", "classes": [9, 42] }],
      "goods": "cloud software for weather analytics",
      "jurisdictions": ["US"],
      "product": "knockout-search"

package/README.md

@@ -7,7 +7,7 @@
 
 <p align="center">
   <a href="LICENSE"><img src="https://img.shields.io/badge/licence-AGPL--3.0--only-860F09?style=flat-square" alt="Licence: AGPL-3.0-only"></a>
-  <a href=".nvmrc"><img src="https://img.shields.io/badge/node-%E2%89%A5%2022-250902?style=flat-square" alt="Node 22+"></a>
+  <a href=".nvmrc"><img src="https://img.shields.io/badge/node-%E2%89%A5%2022.13-250902?style=flat-square" alt="Node 22.13+"></a>
 </p>
 
 Give it a mark, its classes and a territory. Clearotron searches the trademark registers and the open
@@ -35,8 +35,9 @@ calls to us.
 npm install -g clearotron
 ```
 
-Node 22 or newer, on macOS, Linux, or Windows via WSL2. That puts `clearotron` on your `PATH`; every
-command below works in that short form.
+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** —
+the engine resolves the reasoning CLI the POSIX way and refuses at preflight otherwise.
 
 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
@@ -49,17 +50,6 @@ 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.
 
-**Or run it from source**, which is what you want if you intend to change it:
-
-```bash
-git clone https://github.com/CordilleraSarl/Clearotron
-cd clearotron
-npm install                    # every workspace
-npm run build -w portal-ui     # the browser bundle is not committed — build it once
-```
-
-From a clone the commands are `npx clearotron …`, run from that directory.
-
 ## Quick start
 
 Check the install before it does anything. `doctor` only reads — it writes nothing, calls nobody, and
@@ -135,13 +125,18 @@ credential.
 
 ## Development
 
+A clone is the working tree, not a way to install the product — install it from the package above.
+
 ```bash
 git clone https://github.com/CordilleraSarl/Clearotron
 cd Clearotron
-npm install
-npm test          # the offline suite — no credentials, no network
+npm install                    # every workspace
+npm run build -w portal-ui     # the browser bundle is not committed — build it once
+npm test                       # the offline suite — no credentials, no network
 ```
 
+From a clone the commands are `npx clearotron …`, run from that directory.
+
 `npm test` is the whole verification story for someone with no credentials, and it is the first thing
 [CONTRIBUTING.md](CONTRIBUTING.md) asks of a contributor.
 

package/THIRD-PARTY-NOTICES.md

@@ -6193,7 +6193,7 @@ TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
 SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
 ```
 
-## undici@8.10.2
+## undici@7.29.1
 
 - **Licence declared:** `MIT`
 - **Repository:** https://github.com/nodejs/undici

package/bin/clearotron.mjs

@@ -22,6 +22,7 @@ import { dirname, join } from "node:path";
 import { fileURLToPath } from "node:url";
 import { constants as SIG } from "node:os";
 import { isEntrypoint } from "../shared/is-entrypoint.mjs";
+import { nodeFloorVerdict, nodeFloorRefusal } from "../shared/node-floor.mjs";   // — one floor, read from package.json
 import { invocationPrefix } from "../shared/invocation.mjs";   // — print a command the reader can type
 
 export const ROOT = join(dirname(fileURLToPath(import.meta.url)), "..");
@@ -133,6 +134,27 @@ const [verb, ...rest] = process.argv.slice(2);
     process.exit(2);
   }
 
+  // — THE RUNTIME FLOOR, REFUSED HERE, AND THE ONE THING THIS DISPATCHER LOOKS AT.
+  //
+  // This file's header says it implements nothing and does not inspect what it forwards, and that rule
+  // is right: a second, weaker copy of a check that already exists is worse than no copy. This is not
+  // that. It is not about the verb — it is about whether ANY verb can run, which is prior to dispatch
+  // and cannot live inside a child that will not start.
+  //
+  // It exists because the checks we had were in `doctor` and `setup`, which are things you run AFTER
+  // `npm install` succeeds. A reader whose runtime is too old meets a failure inside a command instead,
+  // and on one report it was an engine door exiting 1 with its message lost. `npx clearotron demo` and
+  // `clearotron start` never reached the sentence written for them.
+  //
+  // `--version` and `--help` above are DELIBERATELY on the near side of this. They are the two things a
+  // person runs while writing a bug report, and refusing them would take away the answer to the first
+  // question we ask.
+  const floor = nodeFloorVerdict();
+  if (!floor.ok) {
+    console.error(`clearotron: ${nodeFloorRefusal(floor)}`);
+    process.exit(1);
+  }
+
   // — EVERY VERB ANSWERS --help, INCLUDING THE TWO WHOSE CHILDREN REFUSE IT.
   //
   // `run` and `run-queue` dispatch to driver/pipeline.mjs and driver/runner.mjs, orchestrator entry points

package/bin/example.mjs

@@ -95,6 +95,10 @@ const die = (...lines) => { console.error(`\n${lines.join("\n")}\n`); process.ex
 // already walked a container — every child holding a meta.json and a run/ — and `bin/start.mjs` seeds the
 // portal's archive from it. A bare run directory here would have left that call finding nothing and the
 // installed portal serving an empty archive, silently. Same directory, both readers, no second mechanism.
+// THE PLAYER IS THE DEMO, so it asks for the demo account the same way `start --demo` does. Without
+// this the roster it resolves is a fresh install's — `generic` alone — and the account whose reports
+// it is about would not be there to name.
+process.env.CLEAROTRON_DEMO_PROFILES ??= "1";
 const DEMO_ROOT = join(REPO, "demo");
 // The rule lives in `driver/demo-container.mjs` — ONE definition, because it used to be three and they
 // disagreed. That file records what a knockout demo carries instead of a report.md, and why this line

package/bin/onboard.mjs

@@ -64,11 +64,16 @@ import { stdin as input, stdout as output } from "node:process";
 import { accessSync, constants, copyFileSync, existsSync, mkdirSync, readdirSync, readFileSync, renameSync, statSync, unlinkSync, writeFileSync, chmodSync } from "node:fs";   // read the process table here; moved that to shared/process-table.mjs
 import { homedir, userInfo } from "node:os";
 import { invocationPrefix } from "../shared/invocation.mjs";   // — one rule for how the reader invokes us
+import { nodeFloorVerdict } from "../shared/node-floor.mjs";   // — the floor is package.json engines, not a constant here
 import { invocationForm } from "../shared/invocation.mjs";   // — and WHY that form
 import { standFrom } from "../shared/invocation.mjs";   // is this tree one npm replaces?
 import { installShim } from "../shared/verb-shim.mjs";   // — the verb goes on PATH
 import { styleFor, banner } from "../shared/tty-style.mjs";   // — weight where the meaning is
-import { bracketAsciiCells } from "../shared/brand.mjs";      // F18 — the mark, from the geometry the SVG already uses
+import { bracketAsciiCells, BRAND } from "../shared/brand.mjs";      // F18 — the mark, from the geometry the SVG already uses
+// ONE CLASSIFIER, shared with `bin/start.mjs`. The wizard asks the question; the launcher enforces the
+// answer. Two copies of "what does this domain admit" is a wizard that consents to one rule and a
+// launcher that builds another.
+import { classifyStaffDomain, domainOfEmail, staffDomainRefusal, staffGrantSentence } from "../shared/staff-domain.mjs";
 import { join, dirname, isAbsolute, resolve } from "node:path";
 import { fileURLToPath, pathToFileURL } from "node:url";
 import { delimiter } from "node:path";
@@ -121,7 +126,6 @@ const ENV_PATH = envLocalPath({ repoRoot: REPO });   // resolved, never composed
 // command is applying. Writes stay on ENV_PATH: a writer that followed the file backwards would keep an
 // install in the directory npm replaces forever.
 const READ_ENV_PATH = () => activeEnvPath({ repoRoot: REPO });
-const NODE_FLOOR = 22;
 
 const argv = process.argv.slice(2);
 const has = (n) => argv.includes(n);
@@ -587,6 +591,80 @@ export const AMBIENT_KEYS = [
 // ── helpers ──────────────────────────────────────────────────────────────────────────────────────────
 const present = (v) => typeof v === "string" && v.trim() !== "";
 
+/**
+ * Ask who signs in, and take a real yes for the access rule that address implies.
+ *
+ * ── WHY THIS QUESTION EXISTS AT ALL ─────────────────────────────────────────────────────────────────
+ *
+ * Setup never asked for an address. `clearotron start` therefore took one from `--user`, from
+ * `PORTAL_LOCAL_USER`, or from the local account as `<account>@localhost` — and derived a STAFF RULE
+ * from everything after its `@`. On the local-account default that rule is `localhost`: one machine,
+ * one identity, nothing granted to anyone. Given a real address it is that address's whole domain, and
+ * the settings page then reports it back as "Anyone at <domain> — a rule, not a person".
+ *
+ * An outside install reached exactly that state. Nobody typed the address into this wizard, because
+ * this wizard had no prompt for it; an assistant filled one into the environment file on the operator's
+ * behalf, and the install granted a documentation domain. They read their own settings page and
+ * reported it as a back door. They were right to: a grant to a group had been made, by nobody.
+ *
+ * So the address is asked for here, where a person is definitionally present, and the grant it implies
+ * is shown in the words the settings page uses BEFORE it is written. `start` no longer guesses: it
+ * refuses a rule wider than one machine unless `PORTAL_STAFF_DOMAINS` says so in writing, which is what
+ * a yes here writes.
+ *
+ * THE DEFAULT IS THE LOCAL ACCOUNT AND NOTHING ELSE — not the git author, not the hostname, not a shell
+ * variable. An identity that becomes an access rule comes from the person, or from the one source that
+ * cannot name a second person.
+ *
+ * `io` IS INJECTED for the reason `offerUsptoSync`'s is: the branch that matters is the one where a
+ * reader pressed Enter at the grant question and NOTHING must be granted, and closed over a terminal
+ * that branch is asserted nowhere. Returns the `.env` keys to write and nothing else.
+ */
+export async function askSignIn(io, { localAccount = "user", staffLabel = "Staff", envPath = "" } = {}) {
+  const { askValue, confirm, say = () => {}, ok = () => {}, info = () => {},
+          warn = () => {}, problem = () => {} } = io;
+  const localDefault = `${localAccount}@localhost`;
+  prose("The portal admits one address on this install, and that address is also what decides who is an",
+        "administrator. Enter accepts the local-account form, which is this machine and nobody else.");
+  for (;;) {
+    const typed = String(await askValue("Sign-in address:", { def: localDefault })).trim().toLowerCase();
+    if (!typed.includes("@") || typed.indexOf("@") !== typed.lastIndexOf("@")) {
+      problem(`"${typed}" is not a single email address. The portal refuses a multi-@ identity outright, `
+        + "so this would sign in and then be denied at the door.");
+      continue;
+    }
+    const domain = domainOfEmail(typed);
+    const verdict = classifyStaffDomain(domain);
+    if (verdict === "public" || verdict === "reserved") {
+      // The classifier's own sentence, never a second copy: `clearotron start` prints these same words
+      // when it meets the same domain, and two wordings of one refusal is how a reader comes to believe
+      // they have met two different problems.
+      problem(staffDomainRefusal(domain));
+      continue;
+    }
+    if (verdict === "narrow") {
+      ok(`${typed} — this machine only. No domain rule is written, and nobody else is granted anything.`);
+      return { PORTAL_LOCAL_USER: typed };
+    }
+    // `wide`: a real domain, so the grant is a grant. Stated first, in the settings page's own words,
+    // and Enter is NOT a yes — the default is no, because this is the one answer in the wizard that
+    // admits people the reader has never met.
+    say("");
+    warn(`${typed} makes this a rule about ${domain}, not about you.`);
+    say(`    ${staffGrantSentence(domain, { staffLabel })}`);
+    say("");
+    say(`  Everyone at ${domain} who gets past this install's sign-in door would see every brand owner`);
+    say("  on it — every clearance, every report, every configuration. On a laptop that is only you,");
+    say("  because only one address can sign in. Behind a company login it is the whole domain.");
+    say("");
+    if (await confirm(`Grant ${domain} that, and write it down as PORTAL_STAFF_DOMAINS?`, false))
+      return { PORTAL_LOCAL_USER: typed, PORTAL_STAFF_DOMAINS: domain };
+    info(`nothing granted${envPath ? `, and nothing written to ${envPath}` : ""}. ${typed} would sign in `
+      + "and every page would refuse it, because signing in is not being enrolled — so choose the "
+      + "local-account form, or answer yes above.");
+  }
+}
+
 /**
  * An engine binary, resolved the way the engine resolves it — and the trap that resolution carries.
  *
@@ -998,9 +1076,9 @@ export async function runCheck() {
   }
 
   say("\n  Node");
-  const major = Number(process.versions.node.split(".")[0]);
-  if (major >= NODE_FLOOR) ok(`node ${process.versions.node}`);
-  else problem(`node ${process.versions.node} — this engine needs >= ${NODE_FLOOR} (node:sqlite and TS type-stripping are load-bearing)`);
+  const nodeV = nodeFloorVerdict();
+  if (nodeV.ok) ok(`node ${nodeV.current}`);
+  else problem(`node ${nodeV.current} — this engine needs ${nodeV.required} or newer; node:sqlite is not a built-in module before then`);
 
   // Read the file up here rather than at the `.env` heading below: the engine section is the first that
   // needs `effective()`, and which ENGINE is configured decides which binary variable to check. Reading
@@ -1170,6 +1248,46 @@ export async function runCheck() {
         + "clearotron doctor --probe-engine to find out.");
     }
 
+    // AND WHETHER THE ENGINE AGREES, which is a different question from the one above and the reason an
+    // outside user gave up on this product. This command reads its OWN environment; the portal's New
+    // clearance screen reads what the engine recorded when it last started. Both were right and they
+    // said opposite things, so a reader who checked the confident-looking one first was told the engine
+    // was fine while no search would start. Reported here in the same words the configuration page uses,
+    // because a doctor that cannot see a contradiction the product ships with is the wrong doctor.
+    try {
+      const { readFlagSnapshot, postureDisagreement } = await import("../driver/flag-snapshot.mjs");
+      // THE READ-SIDE ACCESSOR, because this is a read: `config.poolRoot` throws on a box with no pool
+      // configured, and `readFlagSnapshot(null)` already answers "no capture" for exactly that case.
+      const snap = readFlagSnapshot(config.poolRootOrNull);
+      const rows = snap
+        ? postureDisagreement(snap, { flags: {}, engine: engineInventory(invEnv) })
+        : null;
+      // NULL IS NOT AGREEMENT and neither is an empty pool — a box with no capture has nothing to
+      // disagree with, and saying so beats printing a clean bill nobody measured.
+      const clash = (rows ?? []).find((r) => r.what === "engine program");
+      if (clash) {
+        problem(`The engine that last ran and this machine disagree about the engine program: the last run `
+          + `recorded it as ${clash.capture}, this machine reads it as ${clash.live}. A NEW search will `
+          + `refuse while that is true. Restart the engine service so it re-reads its PATH, or install the `
+          + `CLI where the service can see it.`);
+      }
+    } catch (e) {
+      // WHAT ACTUALLY REACHES THIS CATCH, established by driving it rather than by reading it.
+      //
+      // Not a box with no pool: `poolRootOrNull` answers null and `readFlagSnapshot(null)` answers null,
+      // neither throwing. And NOT an unreadable capture either — `readFlagSnapshot` has its own try and
+      // returns null for a corrupt file, so a damaged capture is already indistinguishable from an absent
+      // one by the time this code sees it. That is worth knowing and is not this change's to fix.
+      //
+      // So this catch covers an import that has broken or an unexpected throw out of the comparison —
+      // the check having stopped running. A doctor silent about its own failure is the defect the rest of
+      // this change is about, an absence rendered as a clean bill, so it says so. A caution rather than a
+      // problem: the engine may be perfectly fine and it is this check that is broken.
+      info(`Could not compare this machine against what the engine last recorded (${e?.message ?? e}). `
+        + `That comparison is what catches a settings page reading healthy while a search will not start, `
+        + `so this run has not checked it either way.`);
+    }
+
     // item 5 — WHICH BILLING LANE, reported rather than left to be inferred from a variable's
     // absence. `--check` named the engine and its binary and never said how the box pays, so the two
     // states that matter — metered per token, or drawn against a subscription — were indistinguishable
@@ -1366,7 +1484,7 @@ export async function runCheck() {
       // Both lines were honest about their own source and neither said what it was. The first reads this
       // command's env file; the second reads THIS PROCESS's resolution, and a CLI is started by a login
       // shell that carries none of the units' `EnvironmentFile`. The deployment was correct and served
-      // zephyr, aurora and generic throughout.
+      // the configured roster throughout.
       //
       // THE UNITS' ENV IS NOT PASSED INTO `profileStoreResolution`, deliberately. `PROFILES_OVERLAY_DIR`
       // is captured when profiles.mjs LOADS, so handing it the units' value would set `live` with no
@@ -1418,17 +1536,38 @@ export async function runCheck() {
         const demo = keys.filter((k) => roster.get(k)?.demoData === true);
         // `generic` is the universal fallback the module requires by name, not a brand owner somebody
         // onboarded — counting it would tell an operator with an empty store that they have one.
-        const owners = keys.filter((k) => k !== "generic");
+        //
+        // A DEMO ACCOUNT IS NOT AN ONBOARDED OWNER EITHER, and until this line it was counted as one. A
+        // fresh install used to ship the demo account into every roster, so `doctor` reported "1 brand
+        // owner(s) resolve here: demo-brand-owner (DEMO DATA)" on a machine where nobody had onboarded
+        // anything — and never named `generic`, which is the account that actually rates a run there.
+        // The reader is told they have a customer and not told what they are running on. Both halves
+        // wrong from one list.
+        //
+        // SINCE 2026-09-08 A FRESH INSTALL RESOLVES `generic` ALONE (owner ruling): nobody should have to
+        // clean demo material out of an environment they just created. So the demo branch below no longer
+        // fires on a plain install — it fires inside the demo, which asks for its own account. It is kept
+        // rather than deleted because it is still reachable, and a reader who meets the demo account
+        // there is owed the same two facts: it is fiction, and a real clearance under it is refused at
+        // the admission wall.
+        //
+        // Three states, told apart, because they mean three different things to whoever is reading:
+        // an onboarded roster, the house default alone, and the house default beside what the demo
+        // brought with it.
+        const owners = keys.filter((k) => k !== "generic" && !demo.includes(k));
         if (!owners.length) {
-          info(`no brand owners resolve here — only the \`generic\` fallback. An empty store is a working `
-            + `install on Generic defaults; it is also what a store pointed at the wrong directory looks like`);
+          const base = "`generic` is the account this install rates under — the house default, and the "
+            + "only one a clean install has";
+          if (demo.length) {
+            info(`${base}. The demo brought one with it, marked DEMO DATA: ${demo.join(", ")} — fiction `
+              + "rather than an account anybody onboarded, and a real clearance under one is refused");
+          } else {
+            info(`${base}. An empty store is a working install on Generic defaults; it is also what a `
+              + "store pointed at the wrong directory looks like");
+          }
         } else {
-          const marked = owners.map((k) => (demo.includes(k) ? `${k} (DEMO DATA)` : k)).join(", ");
-          const line = `${owners.length} brand owner(s) resolve here: ${marked}`;
-          // The demo marker is the member-level half: naming the store is not the
-          // same as saying the accounts in it are fiction, and a real clearance under one is refused at
-          // the admission wall — which an operator should learn here rather than from that refusal.
-          if (demo.length) info(`${line} — accounts marked DEMO DATA cannot start a real clearance`);
+          const line = `${owners.length} brand owner(s) resolve here: ${owners.join(", ")}`;
+          if (demo.length) info(`${line}. The demo brought one with it, marked DEMO DATA: ${demo.join(", ")} — not counted above, and a real clearance under one is refused`);
           else ok(line);
         }
         try {
@@ -2310,6 +2449,27 @@ export async function runCheck() {
         // unreachable; repeating it as a second failure teaches the reader that this section
         // double-counts. It still states what was NOT established, which is the whole job.
         else if (v.kind === "could-not-look") info(v.message);
+        // NO ACCESS IN FRONT OF THE CLIENT DOOR IS A POSTURE, NOT A FAULT (owner ruling 2026-09-08).
+        //
+        // This is the CLIENT connector's address, and how a client reaches it is the client's decision:
+        // "client access sitting behind OAuth is totally up to a client — plenty might just run it token
+        // based on their own laptop." A door answering with its own Bearer challenge and no Access front
+        // is a supported shape, not a misconfiguration, so raising it made `doctor` exit 1 on a healthy
+        // deployment and taught its reader to skim the one command that must never be skimmed.
+        //
+        // It is still SAID rather than dropped, and it still states what was not established: an
+        // audience that was never compared is not an audience that agreed. What changed is that the
+        // sentence no longer calls a client's own arrangement a finding about this install.
+        //
+        // Scoped deliberately to `not-fronted` on THIS address. A configured audience that DISAGREES
+        // with the one the edge issues is still a fault, and the portal and ops surfaces are untouched —
+        // they are checked elsewhere and Access in front of them is not optional.
+        else if (v.kind === "not-fronted") {
+          info(`nothing is fronting this hostname with Access — ${read.why}. That is this client door's `
+            + "posture rather than a fault: a client may reach it with its own token and no Access in "
+            + "front, which is a supported shape. The configured audience was not compared against this "
+            + "address, so nothing here says the two agree.");
+        }
         else problem(v.message);
       }
     }
@@ -2534,13 +2694,13 @@ try {
 
   // 1 ── Node
   say("  Node");
-  const major = Number(process.versions.node.split(".")[0]);
-  if (major < NODE_FLOOR) {
-    problem(`node ${process.versions.node} — this engine needs >= ${NODE_FLOOR}. Upgrade Node and run setup again.`);
+  const nodeV = nodeFloorVerdict();
+  if (!nodeV.ok) {
+    problem(`node ${nodeV.current} — this engine needs ${nodeV.required} or newer. Upgrade Node and run setup again.`);
     aborted = "node";
     throw new Error("node floor");
   }
-  ok(`node ${process.versions.node}`);
+  ok(`node ${nodeV.current}`);
 
   // 2 ── the engine: which one, which binary, and PROOF that it can run a turn
   //
@@ -3175,6 +3335,22 @@ try {
   say("  fallback — falls through by name, so an empty store is a working install. Your own customers");
   say("  are added here by name; the bundled demo customers never show through into your roster.");
 
+  // 7c ── WHO SIGNS IN, AND WHAT THAT ADDRESS GRANTS
+  //
+  // Setup never asked for an address, so `clearotron start` derived one — and derived a staff-domain
+  // rule from everything after its `@`. The whole reasoning, and the install that granted a
+  // documentation domain to a reader who had never been asked, is on `askSignIn` above.
+  section("Who signs in");
+  const localAccount = (() => {
+    try { return userInfo().username || "user"; } catch { return "user"; }
+  })();
+  // ONE CALL SITE. The loop itself lives in `askSignIn` so that the branch that matters — a reader who
+  // pressed Enter at the grant question, and a staff rule that must therefore NOT be written — is
+  // reachable without a terminal. The same seam and the same reason as `offerUsptoSync`.
+  Object.assign(candidate, await askSignIn(
+    { askValue, confirm, say, ok, info, warn, problem },
+    { localAccount, staffLabel: `${BRAND.name} staff`, envPath: ENV_PATH }));
+
   // 8 ── the engine's own preflight over the whole candidate
   //
   // — THIS STEP CHECKS THE REGISTER PROVIDER AND NOTHING ELSE. `preflightCandidate` pins