clearotron 0.2.2 → 0.2.4

package/driver/engine/probe.mjs

@@ -123,7 +123,13 @@ export function classifyProbe({ engine, tuple = null, error = null, timeoutSec =
   if (!tuple) return v("failed", "none", `${id} returned nothing`, "The adapter settled no tuple — this is a driver bug, not a configuration one.");
   const s = tuple.signals ?? {};
   const text = `${tuple.stderr ?? ""}\n${tuple.stdout ?? ""}`;
-  const detail = tail(tuple.stderr);
+  // READ FROM THE SAME STREAMS THE CLASSIFICATION IS. Every branch below matches over `text`, which is
+  // stderr AND stdout, while this carried stderr alone — so a CLI that reports its failure on stdout
+  // produced a verdict with its evidence dropped, and the reader got a headline with nothing under it.
+  // stderr stays FIRST because that is where a diagnostic belongs and where these CLIs put theirs; the
+  // fallback exists so that "the engine said nothing" is a claim about the engine rather than about
+  // which pipe this happened to look at.
+  const detail = tail(tuple.stderr) ?? tail(tuple.stdout);
 
   if (tuple.code === 0) return { ok: true, engine: id, mode: "ok", basis: "completed-turn", headline: `${id} completed a turn`, fix: null, detail: null };
 
@@ -249,13 +255,47 @@ export function probeWeatherWarning(verdict) {
  * whatever the operator's shell happens to have set and report a pass for the wrong engine — the same
  * frozen-provider trap `preflightCandidate` works around one file over.
  *
- * ONLY the engine-selection keys are applied. Credentials and billing-mode variables are deliberately
- * NOT copied: the probe must bill exactly the way a run on this box would, and moving a spend variable
- * to make a probe pass is the one thing this must never do.
+ * THE SPEND VARIABLES ARE APPLIED TOO, and the rule this replaces had it backwards. It said they were
+ * deliberately not copied, so that "the probe must bill exactly the way a run on this machine would" —
+ * the aim is right and withholding them defeated it. The caller supplies the lane and the credential
+ * precisely because they are not in the environment yet; not copying them left the probe billing the
+ * way the operator's shell happened to be set, while the run that followed billed the way the reader
+ * had just chosen. The probe proved a lane nobody was going to use. Measured: an API-key install failed
+ * as "not signed in" because the adapter removes the key under any mode that is not the API-key one,
+ * and the mode it read was the unset one.
+ *
+ * WHAT IS STILL NEVER DONE, which is the sentence that was worth keeping: nothing here defaults,
+ * repairs, invents or falls back. It copies what the caller passed and nothing else, so a probe cannot
+ * pass on a credential a run would not have — the caller is the wizard about to write these very values
+ * to disk, or a command reading the values already there.
+ *
+ * AND IT PUTS EVERYTHING BACK. Widening what this writes onto the process widens what it must remove
+ * again; a credential outliving the check that borrowed it would be a worse defect than the one this
+ * fixed, and a check drives the restore rather than trusting it.
  */
 function applyEngineEnv(env) {
   if (!env || env === process.env) return () => {};
-  const keys = ["CLEAROTRON_AI", ...Object.values(ENGINE_BINARIES).map((s) => s.env)];
+  // EVERY VARIABLE THAT DECIDES WHAT THE SPAWN IS, not only the ones that decide WHICH BINARY.
+  //
+  // This list used to carry CLEAROTRON_AI and the binary paths. It did not carry the billing mode or
+  // the API key — so a caller could hand this function a correct api-key environment, watch
+  // `resolveAuthMode` accept it, and then have `runTurn` read `process.env`, where neither had arrived.
+  // `anthropic-agent.spawnEnv` deletes ANTHROPIC_API_KEY under any mode that is not api-key, and the
+  // mode it read was unset, so it deleted the key the reader had just typed. The turn then failed as
+  // "not signed in" — correctly, about an environment nobody had asked for.
+  //
+  // Reported from a real WSL2 install, 2026-09-09: the setup wizard's api-key lane, a valid key, and a
+  // sign-in failure the reader could only get past by exporting the key into their own shell.
+  //
+  // A SET, AND THE DUPLICATE IS NOT HYPOTHETICAL. Both engines name the same billing variable, so this
+  // list contains CLEAROTRON_AI_BILLING twice — and the save below is `saved.set(k, process.env[k])`
+  // inside the same loop that writes. On the second visit it saved the value the FIRST visit had just
+  // written, so the restore put that back instead of deleting it, and the mode leaked into the rest of
+  // the process. Caught by the arm that exists to prove the restore, which is the only reason widening
+  // this list was safe to do at all.
+  const keys = [...new Set(["CLEAROTRON_AI", ...Object.values(ENGINE_BINARIES)
+    .flatMap((s) => [s.env, s.authEnv, s.apiKeyEnv, s.headless?.tokenEnv])
+    .filter(Boolean)])];
   const saved = new Map();
   for (const k of keys) {
     saved.set(k, process.env[k]);

package/driver/enqueue-schema.mjs

@@ -237,7 +237,7 @@ function niceClassErrors(list, label) {
 //   and reaches the report body, where it REVERSES THE DISPLAY of everything after it. The report is a
 //   legal deliverable that goes to a client.
 //
-//   A zero-width joiner makes "AUR\u200DORA" render as AURORA and compare unequal to it, so
+//   A zero-width joiner makes "IRON\u200DWHISK" render as IRONWHISK and compare unequal to it, so
 //   `selfExclusionOwners` and dedup both miss a mark a human reads as the account's own.
 //
 //   NFD "SIRÈNE" !== NFC "SIRÈNE", so one mark submitted two ways is two matters, two searches, two bills.
@@ -285,7 +285,7 @@ const markNameSites = (job) => {
   for (const f of ["markName", "name"]) if (job?.[f] != null) sites.push([f, () => job[f], (v) => { job[f] = v; }]);
   if (Array.isArray(job?.marks)) job.marks.forEach((m, i) => {
     // A BARE STRING IS A MARK NAME, and this shape reaches validateJob unconverted. `assembleFromFlags`
-    // turns `marks: ["AURORA"]` into `[{ name: "AURORA" }]`, so every door that assembles is already
+    // turns `marks: ["IRONWHISK"]` into `[{ name: "IRONWHISK" }]`, so every door that assembles is already
     // covered — but the runner's wall calls validateJob({ atClaim: true }) on the MANIFEST AS IT SITS ON
     // DISK, which nothing re-assembles. The kebab-collision check below reads the same shape for exactly
     // that reason. Walking only `m.name` would leave this guard covering every door except the one it
@@ -778,16 +778,16 @@ export function validateJob(job, { atClaim = false } = {}) {
   // that would drop the customer's platforms, self-exclusion seed and the framework that RATES the matter".
   // A MISSING key returns generic in silence. Both produce the same wrong deliverable, and only one says so.
   //
-  // It has already happened: a paid Zephyr Beverages clearance was rated on the Generic default scale because the
-  // request named the customer in prose and left the account field empty. Nothing objected. A person
-  // noticed hours later and re-ran it.
+  // It has already happened: a paid clearance for a test account was rated on the Generic default scale
+  // because the request named the customer in prose and left the account field empty. Nothing objected.
+  // A person noticed hours later and re-ran it.
   //
   // WHY THIS IS NOT SIMPLY "customer present, key absent". That shape is byte-identical to a LEGITIMATE
   // third-party search — a firm asking us to clear a mark for their own client, who is not our account —
   // and the applicant deliberately never selects a profile, because a third-party search must never inherit
   // a customer's exclusions. Clarifying on that shape alone would bounce real work every day.
   //
-  // The discriminator is the ROSTER. The Zephyr Beverages request differed in one way that matters: we hold an
+  // The discriminator is the ROSTER. That request differed in one way that matters: we hold an
   // account by that name. A named applicant we have no account for is a third-party search and runs
   // untouched; a named applicant who IS one of our customers, with no key, is ambiguous in a way only a
   // person can settle — did intake forget to tag it, or is this genuinely a search against a name that
@@ -965,7 +965,7 @@ export const EXAMPLE_JOB = {
   rawRequest: "<the verbatim forwarded email text, untouched — archived as inbound-request.txt (§A5)>",
   brief: "<the confirmation brief exactly as sent to the requester — archived as confirmation-brief.md>",
   deadline: "2026-06-20T17:00:00Z",     // optional; drives the §A3 deadline-envelope arithmetic
-  profileKey: "aurora",              // D4.1: the customer ACCOUNT the intake AI resolved → selects the
+  profileKey: "demo-brand-owner",    // D4.1: the customer ACCOUNT the intake AI resolved → selects the
                                         // profile (marketplaces/classes/delivery/appetite); omit ⇒ generic
   product: "multi-country-focus-search",// WHICH OF THE FOUR (OPTIONAL): one of products.mjs PRODUCT_IDS.
                                         // Omit ⇒ the project/customer defaultProduct, else the product
@@ -987,7 +987,7 @@ export const EXAMPLE_JOB = {
   projectKey: "console-ecosystem",      // spec 62 (OPTIONAL): the PROJECT/engagement under the customer whose
                                         // overlay (its own marketplaces/classes/sector/posture) rates this
                                         // matter; omit ⇒ runs on the customer profile. Unknown key ⇒ clarify.
-  customer: "Aurora Interactive",                // applicant/owner → affiliate self-exclusion set (§B3.2)
+  customer: "Demo Brand Owner",                  // applicant/owner → affiliate self-exclusion set (§B3.2)
   customerUnknown: false,               // B5: true when the applicant is neither stated nor forwarder-implied —
                                         // arms candidate-self classification + the late-bind watch (NEVER inferred from the mark)
   // caseLaw — NOT A FIELD. The case-law and opposition reading is what a Full country search IS

package/driver/feedback-store.mjs

@@ -19,7 +19,7 @@
 // come from report-data.json; the disposition comes from findings.json beside it in the same run dir,
 // because report-data.json is the CLIENT cut and stopped serving the engine's placement key. A
 // reader who finds the ordinal now points at `KURENA / Manageable / rebuttable` when the flag says
-// `PETCARY / Medium / conceded` knows the run was republished, which is exactly the thing a bare id
+// `BURROWELL / Medium / conceded` knows the run was republished, which is exactly the thing a bare id
 // would have hidden.
 
 import { randomUUID } from "node:crypto";

package/driver/findings-model.mjs

@@ -168,8 +168,8 @@ export const ACTION_KINDS = [...CONDITION_KINDS, ...ADVISORY_KINDS];
 export const CLIENT_TIER_BY_COMPOSITE = { 1: "LOW", 2: "MANAGEABLE", 3: "MEDIUM", 4: "HIGH", 5: "VERY HIGH" };
 
 // ── doc 50 — band mode (schema_version 4): the framework in force rates the matter ────────────────────
-// A v4 finding carries `band` — one of the frozen framework manifest's ordered band words (zephyr says
-// "Medium", the Generic default says "Moderate", aurora has a "Low") — and NO composite/level/
+// A v4 finding carries `band` — one of the frozen framework manifest's ordered band words (one ladder
+// says "Medium", the Generic default says "Moderate", another has a "Low") — and NO composite/level/
 // dispute_type (one rating authority; the retired scale is FORBIDDEN, not just optional). Presentation
 // joins on the band's TONE (a closed enum in the manifest) so 4-band and 5-band ladders both land on the
 // existing badge/gauge ramps without any per-framework code.
@@ -2441,6 +2441,56 @@ export function knockoutFindingViews(mark, { manifest = null } = {}) {
  * Derived through knockoutFindingViews rather than re-deriving that fallback here — one projection
  * decides what a finding's number is, and this cell cannot disagree with the sheet it points into.
  */
+// ── THE REVIEWER'S NOTES: WHAT EACH ONE IS ABOUT (tracker issues 331 A.4, 333 rule 5) ───────────────
+//
+// The knockout page prints a note about the REQUEST at the top, above the conflicts, and a note about
+// the NAME under that name's cards. A note saying the screen may have been scoped to the wrong market
+// is the most consequential line on the page and it used to sit under roughly 1,900 words.
+//
+// THE READER LIVES HERE BECAUSE TWO MODULES NEED THE SAME ANSWER. The renderer sorts the notes; the
+// predelivery lint warns a writer whose note will sort the way they did not intend. Two copies of this
+// regex would drift, and the drift would be silent — the page would file a note one way while the
+// reviewer told the writer it went the other.
+//
+// IT SORTS ON WHAT THE NOTE TALKS ABOUT, and the doctrine is written to match: a note about the request
+// NAMES the request. The word set spans both vocabularies deliberately — "dispatch" and "instructed"
+// are what runs written before tracker issue 333 say, "the request" and "was asked" are what runs
+// written after it say — so one reader serves the archive and the new doctrine at once.
+export const REQUEST_NOTE_WORDS = /\b(?:dispatch|the request|the requester|instructed|was asked)\b/i;
+
+// Subjects that belong to the ASKING rather than to the name. A note on one of these that never names
+// the request will be filed under the name, which is why the lint flags it rather than the page
+// guessing: the fix is one clause in the note, and only its writer can add it.
+export const REQUEST_SUBJECT_WORDS =
+  /\b(?:customer industry|client(?:'s)? (?:own )?(?:prior|earlier) use|prior use|intended goods|the goods we|wrong market|described as an? )/i;
+
+/** One note, in either shape, as { text, about }. `about` is null when nothing has classified it. */
+export function knockoutNoteView(n) {
+  if (n && typeof n === "object" && !Array.isArray(n)) {
+    const about = String(n.about ?? "").trim().toLowerCase();
+    return { text: String(n.text ?? n.note ?? "").trim(), about: about === "request" || about === "name" ? about : null };
+  }
+  return { text: String(n ?? "").trim(), about: null };
+}
+
+/**
+ * A mark's notes, split into the two places the page prints them.
+ *
+ * The rater's own `about` wins outright where one is given; only an unclassified note meets the word
+ * reader. That precedence is the whole design: it means a run written under a doctrine that no longer
+ * uses these words is answered without them.
+ */
+export function splitKnockoutNotes(mark) {
+  const all = (Array.isArray(mark?.purpleNotes) ? mark.purpleNotes : []).map(knockoutNoteView).filter((v) => v.text);
+  const request = [];
+  const name = [];
+  for (const v of all) {
+    const isRequest = v.about ? v.about === "request" : REQUEST_NOTE_WORDS.test(v.text);
+    (isRequest ? request : name).push(v.text);
+  }
+  return { request, name, all: all.map((v) => v.text) };
+}
+
 export function knockoutFindingRange(mark) {
   const ords = knockoutFindingViews(mark).map((v) => v.ordinal).sort((a, b) => a - b);
   const markName = String(mark?.name ?? "").trim();

package/driver/flag-snapshot.mjs

@@ -318,6 +318,26 @@ export function postureDisagreement(snapshot, live) {
     "silent-output-change — a different engine answers differently and nobody is told");
   differ("billing mode", snapshot.engine?.billing?.mode ?? null, live.engine?.billing?.mode ?? null,
     "what a run costs, and who it is billed to");
+  // THE FIELD THAT DECIDES WHETHER A SEARCH CAN START, and the one this comparison could not see.
+  //
+  // The configuration page reads the LIVE posture and the New clearance screen reads this capture, so a
+  // box where they differ on this one boolean draws a green Engine row on one screen while the other
+  // replaces its start button with "no search engine is attached". That is not a hypothetical: it is
+  // what an outside user photographed, and he gave up on the product because the greener screen looked
+  // more authoritative. Both readings were correct about their own question and nothing compared them.
+  //
+  // Worse than silence, before this line: `disagrees` came back `[]` — which this page renders as "the
+  // last run ran under this same configuration". The one field they actually disagreed on was not in the
+  // comparison, so the page positively affirmed agreement while the two surfaces contradicted each other.
+  // STRINGS, NOT THE BOOLEANS THEMSELVES. Every other row here compares names and modes, so the browser
+  // contract parses `capture` and `live` with `asString` — handed `false` it yields null, and the row
+  // would reach the page with its two values blank and only the effect sentence left. The words are also
+  // the better answer for a reader: "found" against "not found" says it without a legend.
+  const found = (v) => (v === true ? "found" : v === false ? "not found" : null);
+  differ("engine program", found(snapshot.engine?.binaryPresent), found(live.engine?.binaryPresent),
+    "whether a NEW search can start — the engine that last ran and this deployment do not agree that the "
+    + "engine program can be found, so one screen offers a search the other refuses. Restart the engine "
+    + "service so it re-reads its PATH, or install the CLI where the service can see it");
 
   // Flags: compare only names BOTH sides declare, for the same reason `differ` skips absent values —
   // a build that adds a flag must not read as every older capture disagreeing with it.

package/driver/framework.mjs

@@ -102,7 +102,7 @@ export function parseFrameworkManifest(raw) {
 // `rootDir` may be a string (legacy: join against it) OR a resolver function taking the manifest's
 // skills-relative path and returning an absolute one — the layered overlay-over-base lookup
 // (driver.config.resolveSkillPath). The driver MUST resolve a framework exactly as the agent does, or the
-// two read different files: that divergence is what killed the first Aurora Interactive run (framework_manifest_missing
+// two read different files: that divergence is what killed a test account's first run (framework_manifest_missing
 // against the bundled tree while the agent was pointed at the config store).
 export function loadFrameworkManifest(rootDir, fwPath) {
   const rel = manifestPathFor(fwPath);

package/driver/gateway.mjs

@@ -13,7 +13,8 @@ import { existsSync, mkdirSync, mkdtempSync, readFileSync, rmSync, statSync, wri
 import { join, dirname, basename } from "node:path";
 import { driverDir } from "../shared/driver-dir.mjs";   //
 import { tmpdir } from "node:os";
-import { config, resolveModel, modelFamily, modelSnapshotKind, envOn, envGateOn } from "./driver.config.mjs";
+import { config, resolveModel, modelFamily, modelSnapshotKind, envOn, envGateOn, preflightEngineBinary } from "./driver.config.mjs";
+import { probeCliVersion } from "./engine/cli-version.mjs";
 import { stageLog, runLog, note, outputMeta } from "./log.mjs";
 // — the closed disposition set has ONE author; this file dictates it and must not retype it.
 import { DISPOSITIONS, POSITION_REQUIRED_DISPOSITIONS } from "./findings-model.mjs";
@@ -908,8 +909,8 @@ async function runStageLadder(name, opts, stageCodexHome = null) {
   // until the wall. ONE free rung per ladder is the concession; a second zero-usage warm turn in the
   // same ladder is charged, and the record says so rather than leaving the difference to be inferred.
   //
-  // PROVISIONAL, and deliberately one line to change: the number below is a routed parameter (2026-08-22,
-  // overwatch), not a measured optimum. Nobody has yet counted how often a second free rung would have
+  // PROVISIONAL, and deliberately one line to change: the number below is a routed parameter (2026-08-22),
+  // not a measured optimum. Nobody has yet counted how often a second free rung would have
   // converted, and until someone does, 1 is the smallest concession that closes the defect.
   //
   // THE CHARGING BRANCH CANNOT FIRE TODAY, and that is stated rather than left to be discovered. `warm`
@@ -1147,6 +1148,20 @@ async function runStageLadder(name, opts, stageCodexHome = null) {
     // may repoint, and recorded beside a dated one they read identically. null when there is nothing to
     // judge, never collapsed into "alias".
     const modelSnapshot = modelSnapshotKind(modelActual);
+    // WHICH BUILD OF THE TOOL SERVED THIS TURN. `modelSnapshot` above answers "did the model move";
+    // this answers "did the tool move", and the two have one symptom — a run whose judgment differs from
+    // last week's. Captured at dispatch rather than read back afterwards, because the binary a reader
+    // could probe later is not necessarily the one that ran.
+    //
+    // Written as an object with its own `probe` field, so an unreadable version is a RECORDED state
+    // rather than a missing one. Omitting it on failure would collapse "asked and could not say" into
+    // "written before anybody asked", which is the distinction the field exists for. One spawn per
+    // binary per process; a probe never throws, because taking down a dispatch to record a version
+    // would be a worse defect than the gap it closes.
+    const cli = (() => {
+      try { return probeCliVersion(preflightEngineBinary(process.env)?.resolved ?? null); }
+      catch (e) { return { version: null, probe: "unreadable", why: String(e?.message ?? e).slice(0, 160) }; }
+    })();
     if (modelActual) lastModelWire = modelActual;                       // — never overwritten with null
     // The comparison is by FAMILY (driver.config modelFamily), because `--model haiku` legitimately comes
     // back as `claude-haiku-4-5-20251001`. THREE-VALUED: null when either side names no family this
@@ -1576,6 +1591,7 @@ async function runStageLadder(name, opts, stageCodexHome = null) {
         // Written even on the rows where they are null, so "this engine cannot report" stays visibly
         // different from "this record predates the gauge".
         modelActual, modelBasis, modelSnapshot, modelMismatch,
+        cliVersion: cli.version, cliVersionProbe: cli.probe, ...(cli.why ? { cliVersionWhy: cli.why } : {}),
         // W3 billing telemetry: which engine ran + the RESOLVED billing mode (subscription vs api-key). This
         // records INTENT (the mode the engine was configured to bill under), not independent billing evidence
         // — the actual proof is the provider console (claude's stream also reports apiKeySource; codex does
@@ -1711,6 +1727,7 @@ async function runStageLadder(name, opts, stageCodexHome = null) {
           //: the spine carries the same pair as the per-stage log, or the two disagree about what
           // ran. `model` stays the requested resolution (its existing readers); `modelActual` is the wire.
           model: modelRequested, modelActual, modelBasis, modelSnapshot, modelMismatch,
+          cliVersion: cli.version, cliVersionProbe: cli.probe, ...(cli.why ? { cliVersionWhy: cli.why } : {}),
           wrote, warm: warm || undefined, warmEscalated: attempt === warmEscalatedAt || undefined,
           rescued: rescued ?? undefined, killed: killed || undefined,
           quiescentMs: Number.isFinite(quiescentMs) ? Math.round(quiescentMs) : undefined,   // — see the per-stage row

package/driver/outbox-backoff.mjs

@@ -274,7 +274,7 @@ export function settleProgress(agent, now = Date.now()) {
 // disposed of on the box.
 //
 // **Owner ruling, 2026-08-24, SUPERSEDING THIS SWEEP'S HALF OF IT: failed runs' notification packets get
-// the same re-drop cover as delivered ones.** (Relayed by role-overwatch.)
+// the same re-drop cover as delivered ones.**
 //
 // BOTH ARE KEPT BECAUSE BOTH ARE STILL TRUE, and reading them as a reversal is the mistake to avoid. A
 // failed run owes the CLIENT no report — that is 2026-08-22, and `scripts/e2e.mjs`'s delivery assertion

package/driver/package.json

@@ -2,11 +2,11 @@
   "name": "clearotron-driver",
   "private": true,
   "type": "module",
-  "version": "0.2.2",
+  "version": "0.2.4",
   "license": "AGPL-3.0-only",
   "description": "Deterministic driver for the trademark clearance workflow: orchestration in code (fan-out, fan-in barrier, gating, retries); the model does judgment leaves only, through a reasoning CLI spawned per stage.",
   "engines": {
-    "node": ">=22.19.0"
+    "node": ">=22.13.0"
   },
   "scripts": {
     "test": "node ../scripts/test-run.mjs node ../scripts/test-fast.mjs test/*.test.mjs",
@@ -14,6 +14,6 @@
   },
   "dependencies": {
     "exceljs": "^4.4.0",
-    "undici": "^8.10.1"
+    "undici": "^7.29.1"
   }
 }

package/driver/party-facts.mjs

@@ -226,8 +226,8 @@ const corpusHasKind = (set, kind) => {
 /**
  * The form of a party's name to match ENTRIES against.
  *
- * Register owners carry legal forms ("Aurora Therapeutics SA"); web candidate titles carry whatever the
- * web uses ("Aurora Therapeutics"). That asymmetry is systematic — one corpus is the register, the other
+ * Register owners carry legal forms ("Foxglade Therapeutics SA"); web candidate titles carry whatever the
+ * web uses ("Foxglade Therapeutics"). That asymmetry is systematic — one corpus is the register, the other
  * is search results — so requiring the full string admits SOME entries about a party and excludes others
  * purely by name form. A half-scoped corpus is the failure this scoping was built to avoid, inverted: it
  * still reports a contradiction, now against a source the run plainly holds.

package/driver/phase0.mjs

@@ -87,7 +87,7 @@ export function todayISO(now = new Date()) {
 }
 
 // The resolved customer = the profile key (profiles.mjs resolveProfile, forwarder-domain only). This was
-// a aurora-interactive.example-vs-generic HARDCODE (D4.1); the engine is already profile-driven, so resolveProfile is
+// a customer-vs-generic HARDCODE (D4.1); the engine is already profile-driven, so resolveProfile is
 // the single source of truth. ctx.customer is telemetry-only (the run-start log line); per-customer
 // DELIVERY reads the FROZEN sidecar ctx.profile.profileKey (which wins on resume) — never read
 // ctx.customer for a delivery decision, or a profiles/ edit between run and resume would diverge.