clearotron 0.3.2-beta.6 → 0.3.2-beta.8

package/driver/CHANGELOG.md

@@ -1,5 +1,88 @@
 # clearotron-driver
 
+## 0.3.2-beta.8
+
+### Patch Changes
+
+- d194d41: Fixed: A knockout search now covers the territories the form is showing you, rather than searching the whole world instead of them.
+  
+  Fixed: A new clearance recommends and preselects a search when the form is showing your company's own territories. It previously offered none and said no search was picked, beside a summary naming those same countries.
+- d194d41: Fixed: A report opened on a phone fits the screen instead of scrolling sideways.
+- d194d41: Fixed: A knockout search that is running says it usually takes 5 to 10 minutes. It previously showed 1.5 to 2.5 hours, which is how long a full clearance takes.
+- d194d41: Fixed: A running search says which step it is on, such as "Register sweeps", rather than "Register sweeps · 3 of 9". How many steps a search has varies with what it needs to do, so the number did not mean what it looked like.
+- d194d41: New: Each search in your list now says which of the four searches it was.
+- d194d41: Fixed: A new clearance now offers only the territories your register can search. Before, it offered countries your register cannot reach, and choosing one stopped the search from starting.
+  
+  Fixed: You can now remove one of your company's default territories on the clearance form. Before, if your register could not search one of them, nothing on that screen let you take it off and carry on.
+- d194d41: Fixed: A report now gives the specific reason each name was set aside. Before, every such name carried the same general sentence, and the reason the search actually recorded for it was not shown.
+- d194d41: Fixed: A search naming a territory your trademark register does not cover is now refused before it starts, and says which territory to remove. Before, the search ran and that territory was reported as not searched at the end.
+- d194d41: New: Pay for Claude through your own Google Cloud, Microsoft Azure or Amazon Bedrock account with `CLEAROTRON_AI_BILLING=cloud`. Tested on Microsoft Azure; Google Cloud and Amazon Bedrock use the Claude program's own settings.
+  
+  New: Each run records which cloud account paid for it, and `clearotron doctor` names the cloud account it charges.
+  
+  New: Setup asks how Claude is paid for, and for a cloud account asks which cloud and checks it with one turn.
+  
+  New: `clearotron start`, when no billing is set, names a cloud account for Claude beside a subscription and an API key.
+  
+  New: `clearotron start --background` carries the cloud account's settings to the background services.
+  
+  New: `clearotron doctor` says how the background services pay, and warns when your own configuration sets a different way of paying.
+  
+  New: Global config's Engine row names the cloud account that pays, and turns red, naming the setting to change, when searches would be refused.
+  
+  Fixed: An install that pays with an API key and runs as background services now hands the services its key. Before, every search stopped after it was ordered.
+  
+  Fixed: A subscription install signed in with a long-lived token from `claude setup-token` now hands that token to its background services.
+  
+  Fixed: `clearotron start` now reports a billing setting that would stop every search, such as an API key that is not set. `clearotron doctor` also checks the settings the background services read.
+  
+  For operators: `clearotron start --background` names each setting on which `~/.env` and Clearotron's settings disagree, such as a rotated key, without printing values. It adds only settings `~/.env` lacks and never replaces one, so change a setting in both files.
+  
+  Before you upgrade: A billing setting Clearotron does not recognise now stops a search before it starts, where it used to bill the subscription. Run `clearotron doctor` after upgrading.
+  
+  Before you upgrade: On a Claude install, a cloud's own switch left on, such as `CLAUDE_CODE_USE_FOUNDRY`, now stops a search unless `CLEAROTRON_AI_BILLING=cloud`.
+- d194d41: Fixed: Connect your AI now sits last in the sidebar, under Company settings. It used to sit second, directly under Home.
+- d194d41: Fixed: `clearotron doctor` and `clearotron start --background` look for Claude Code or the Codex CLI on the PATH the background services use. They used to say every search would be refused on a machine whose searches found the program and ran.
+- d194d41: Fixed: When a background service's unit and its settings file set the same value, `clearotron doctor` and `clearotron connect` take the file's, as systemd does.
+  
+  Fixed: `clearotron doctor` and `clearotron connect` read a doubled percent sign (`%%`) in a background service's unit as one, as systemd does.
+- d194d41: Fixed: When the background services found the reasoning program and this machine cannot, `clearotron doctor` now suggests installing it here with setup. It used to suggest installing it where the services could already see it.
+  
+  New: If a restart does not help the background services find the reasoning program, `clearotron doctor` says how to point them at it.
+- d194d41: New: `clearotron doctor --probe-engine` tries Claude with the cloud settings in Clearotron's settings file, the Amazon keys included, as a search does.
+- d194d41: Fixed: A search on a short or common word could return so many unrelated marks that one query filled most of the results. Any single query now contributes at most a fixed number of records. Anything beyond that is reported as a crowd, with its full count, rather than left out silently.
+- d194d41: Fixed: A report made before this summer, reopened today, states its conditions in the same words as a new one.
+- d194d41: New: The sign-in command from setup, `clearotron doctor` and a starting search names the copy setup installed, which is not on the PATH.
+- d194d41: New: Setup's test turn tries Claude with the cloud settings in Clearotron's settings file, the Amazon keys included, as a search does.
+- 6c7c7f1: For operators: the offline test suite runs in four parallel shards, so a change is checked in about a quarter of the time it used to take.
+- d194d41: Fixed: A search covering a very large number of register records could finish with no findings document at all. Those records are now accounted for in fixed batches instead of all at once. An interrupted attempt resumes from the records still outstanding, rather than starting again.
+- d194d41: New: A knockout report has an Export button, so anyone who opens the file can save it as a PDF.
+- d194d41: New: Claude steps run on the newest Opus and Sonnet as soon as they ship, unless a setting holds a tier at one model.
+- d194d41: New: Setup offers to install the reasoning program your engine uses. Before it asks, it says how much space the program takes and how to remove it.
+  
+  New: Setup asks which AI should run your searches, Claude or Codex, and says what it found on this computer.
+  
+  New: Claude Code or the Codex CLI already on the machine is still used first. `clearotron update` keeps the installed one current, and `clearotron doctor` says which copy runs, and its version when the program reports one.
+  
+  New: Outside Windows, in demo mode, `clearotron doctor` points to setup to install the reasoning program.
+  
+  New: When the reasoning program cannot be found, Global config's Engine row and the search screen name the setup command that installs it.
+- d194d41: New: Each report names the models that did the work, including those behind the Chinese, Japanese and Korean language steps.
+  
+  New: Through a cloud account, a report names the Claude model or its tier, never your organisation's own name for its deployment.
+- d194d41: New: When a cloud account refuses the credentials, setup, `clearotron doctor` and a starting search name that cloud and the settings to check.
+  
+  Fixed: When an API key is refused, setup, `clearotron doctor` and a starting search name the key to check, rather than asking for a sign-in.
+- d194d41: Fixed: When you have used all of today's searches, the screen names the person to ask for another. On an installation with no name set it read "ask your the operator contact to run this one for you".
+- d194d41: Fixed: A report's verdict now lists every condition it is conditional on. It used to name the first and close with "(and 2 more)". The rest sat in a separate list below it, so a reader could see that conditions existed without reading them.
+
+## 0.3.2-beta.7
+
+### Patch Changes
+
+- 4bde529: Fixed: A clearance that completed all but one or two of its local-language searches now delivers the report. Before, a single search that did not complete threw the whole clearance away, including the fifty-nine that had run. The report says which term's search was short.
+- b5b789c: Fixed: The exported PDF no longer prints a collapsed arrow above sections that are already fully open.
+
 ## 0.3.2-beta.6
 
 ### Patch Changes

package/driver/band-size.mjs

@@ -64,3 +64,62 @@ export function bandSizeForStage(stage, paths, io) {
   if (!BAND_READING_STAGES.has(stage)) return undefined;
   return bandSizeAtDispatch(paths, io);
 }
+
+// ── A STAGE'S TIME LIMIT IS DERIVED FROM WHAT IT IS HANDED, NEVER A FIXED CONSTANT ────────────────
+//
+// THE DEFECT. The two stages that read the register band carried per-stage constants — numbers chosen
+// once, against a band nobody recorded beside them. On a dense matter both died at their wall having
+// written nothing: the placement attempt at 2,765s against a 2,700s budget, the digest at 2,470s
+// against 2,400s. Both sat exactly AT the ceiling, so what ended them was the budget expiring rather
+// than any guard firing; the stall guards had half an hour of quiet to fire in and could not, because
+// tokens were still moving. Nothing malfunctioned. The number was simply sized for a different matter.
+//
+// THE TWO MEASUREMENTS THESE CONSTANTS ARE SET AGAINST, named here because a budget without the band
+// it was measured at is the thing being fixed:
+//   · 2026-09-16, the dense matter: an 8 MB merged band; the placement attempt needed more than 2,765s
+//     and was killed at 2,700s. The derived limit at that size must exceed what the attempt took.
+//   · Every ordinary matter before it: a band at or under REFERENCE_MB, where 2,700s was sufficient and
+//     is what those runs are verified at. At or below that size the derivation must return the base
+//     unchanged, so no existing run's budget moves and no archived verdict is re-decided.
+export const LIMIT_REFERENCE_MB = 2;
+export const LIMIT_GROWTH_PER_MB = 0.03;
+// The band size above which a stage is refused at dispatch rather than started. A limit past this is
+// not a budget, it is a prediction that the stage will die: the 177 MB band measured on an earlier
+// round would derive past an hour and a half, and starting it spends that hour and a half to arrive
+// where the refusal already is. Refusing NAMES the size, which is the finding; being killed does not.
+export const LIMIT_CEILING_SEC = 5400;
+
+/**
+ * The time limit for this dispatch, derived from the band it is handed. PURE.
+ *
+ * ABOVE THE REFERENCE SIZE ONLY. A band at or under the reference returns the stage's own base
+ * unchanged — that is what every run before this is verified at, and a derivation that moved those
+ * numbers would re-decide archived verdicts to fix a defect they never had.
+ *
+ * AN UNMEASURABLE BAND RETURNS THE BASE, and says so through `basis`. The alternatives are worse in
+ * both directions: guessing a bigger number spends a client's money on an input nobody measured, and
+ * guessing a smaller one kills a stage for a band that might have been ordinary. The base is what the
+ * run would have used anyway, so an absent measurement changes nothing rather than changing something
+ * arbitrary.
+ */
+export function derivedLimitSec(baseSec, bandSize) {
+  const base = Number.isFinite(baseSec) && baseSec > 0 ? baseSec : null;
+  if (base === null) return { sec: null, inputBytes: null, basis: "no base for this stage" };
+  const bytes = Number.isFinite(bandSize?.bytes) ? bandSize.bytes : null;
+  if (bytes === null) return { sec: base, inputBytes: null, basis: bandSize?.absent ? `band unmeasured: ${bandSize.absent}` : "no band for this stage" };
+  const mb = bytes / (1024 * 1024);
+  const over = Math.max(0, mb - LIMIT_REFERENCE_MB);
+  const sec = Math.round(base * (1 + LIMIT_GROWTH_PER_MB * over));
+  return { sec, inputBytes: bytes, basis: over > 0 ? `derived from ${mb.toFixed(1)} MB` : `at or under the ${LIMIT_REFERENCE_MB} MB reference` };
+}
+
+/** Is this derived limit past the point where starting the stage only buys a later kill? PURE. */
+export function limitExceedsCeiling(sec) {
+  return Number.isFinite(sec) && sec > LIMIT_CEILING_SEC;
+}
+
+/** The refusal a dispatch past the ceiling carries — it NAMES the size, which is the finding. PURE. */
+export function ceilingRefusal(stage, derived) {
+  const mb = Number.isFinite(derived?.inputBytes) ? (derived.inputBytes / (1024 * 1024)).toFixed(1) : "an unmeasured";
+  return `stage_input_over_ceiling:${stage} was handed a ${mb} MB band, which derives a ${derived?.sec}s limit against a ${LIMIT_CEILING_SEC}s ceiling — the stage is refused at dispatch rather than started, because a limit past the ceiling is a prediction that it will be killed and starting it spends the whole budget to arrive at the same place. The band size is the finding: a band this size is the defect, not the budget`;
+}

package/driver/config-inventory.mjs

@@ -42,7 +42,10 @@ import {
   DEFAULT_ENGINE_ID, ENGINE_BINARIES, PROVIDERS, RESEARCH_PROVIDERS, SERP_PROVIDERS,
   missingCredentials, preflightEngineBinary, providerIdFrom,
 } from "./driver.config.mjs";
-import { resolveAuthMode } from "./engine/auth.mjs";
+import {
+  resolveAuthMode, billingMode, cloudsSwitchedOn, BILLING_MODES, CLOUD_SWITCH, CLOUD_CREDENTIAL_CHECK,
+} from "./engine/auth.mjs";
+import { billingRefusalWords } from "./run-requirements.mjs";   // — a refusal that quotes the billing word says it by name
 import { CASELAW_BRIDGES } from "./engine/mcp/gather-config.mjs";   // — the list that decides what is spawned
 import { existsSync, readFileSync, statSync } from "node:fs";
 import { join } from "node:path";
@@ -60,7 +63,9 @@ const shown = (names) => names.map((n) => n);
  * absent, because the alternative is silently billing a subscription the operator thought they had
  * stopped using (engine/auth.mjs's opening argument). A writer that caught that and recorded "unknown"
  * would erase precisely the misconfiguration a staff config page exists to surface, so it is caught and
- * recorded AS ITSELF: mode `api-key`, `apiBilled: false`, and a fault naming the variable to set.
+ * recorded AS ITSELF: mode `api-key`, `apiBilled: false`, and a fault naming the variable to set. The
+ * cloud mode's refusals, and a word that is not a mode at all, are recorded as themselves too, by the
+ * refusal's own sentence.
  *
  * `apiBilled` is what the page should believe over `mode` — the two come apart in exactly this case,
  * and only one of them describes who gets the invoice.
@@ -77,14 +82,38 @@ export function engineInventory(env = process.env) {
   const billing = (() => {
     try {
       const a = resolveAuthMode({ engineName: id, env });
-      return { mode: a.mode, apiBilled: a.apiBilled === true, missing: [] };
-    } catch {
-      // The one state resolveAuthMode throws for. The message carries no value, but it is not copied
-      // either — the two variable names are reconstructed from the table so this cannot drift from it.
+      // `cloud` is the resolver's own answer, never re-derived here: the account a run bills is whatever
+      // the run door resolves, and a page that worked it out a second way could name another.
+      const cloud = a.cloud ?? null;
+      return { mode: a.mode, apiBilled: a.apiBilled === true, missing: [], cloud, cloudName: cloudName(cloud) };
+    } catch (e) {
+      // Recorded AS ITSELF, whichever refusal it was. An API-key mode with no key names the variable to
+      // set, reconstructed from the table so it cannot drift from it. Every other refusal (a cloud mode with
+      // no cloud switched on or with two, a cloud switch beside a mode it contradicts, a word that is not a
+      // mode) leaves `missing` empty, because the page reads `missing` as "set this key" and a key that is
+      // set is not missing, and carries a `reason` the page words itself (billingRefusalReason, below).
+      const mode = billingMode(env);
+      const keyAbsent = Boolean(spec?.apiKeyEnv) && String(env[spec.apiKeyEnv] ?? "") === "";
+      if (mode === "api-key" && keyAbsent) {
+        return { mode, apiBilled: false, missing: shown([spec.apiKeyEnv]), cloud: null, cloudName: null };
+      }
+      const reason = billingRefusalReason(id, env);
+      const notAMode = reason.kind === "not-a-mode";
       return {
-        mode: "api-key",
-        apiBilled: false,
-        missing: spec?.apiKeyEnv ? shown([spec.apiKeyEnv]) : [],
+        // A WORD THAT IS NOT A MODE IS NOT RECORDED. It is whatever was typed into the setting that decides
+        // who pays, and a key pasted there by mistake is that word; this inventory is written to a file and
+        // served to a browser. So the mode reads `unknown`, and the refusal says the setting by name.
+        mode: notAMode ? "unknown" : mode,
+        apiBilled: false, missing: [], cloud: null, cloudName: null,
+        // THAT REFUSAL IS WRITTEN HERE, NOT CLEANED FROM THE RESOLVER'S. The resolver's sentence quotes the
+        // typed word, and removing it by pattern depends on how the word is spelled: a word that itself
+        // contains " is not a billing mode" left its tail behind. Built from names alone, nothing typed can
+        // reach it. Every other refusal quotes only setting names and the three mode words.
+        refusal: notAMode
+          ? `${reason.setting} is set to a word that is not a billing mode — refusing to guess, because the guess `
+            + `would bill the subscription. One of: ${reason.modes.join(", ")}.`
+          : billingRefusalWords(String(e?.message ?? e)),
+        reason,
       };
     }
   })();
@@ -104,6 +133,80 @@ export function engineInventory(env = process.env) {
   return { id, vendor: spec?.vendor ?? null, known: Boolean(spec), billing, binaryPresent };
 }
 
+/**
+ * What a reader calls the account a cloud mode bills: "Google Cloud", "Microsoft Azure", "Amazon Bedrock"
+ * or "Gateway". Null for no cloud.
+ *
+ * ONE TABLE OF CLOUD NAMES, NOT TWO. `CLOUD_CREDENTIAL_CHECK` in engine/auth.mjs already names each cloud
+ * the way a reader knows it, for the advice a refused sign-in prints, and this reads it rather than keeping
+ * a second list that could name a cloud differently on the page. It writes the gateway "the gateway", for
+ * use inside a sentence; a label on a page drops the article and starts with a capital, and that one
+ * adjustment is the whole of what this adds.
+ */
+export function cloudName(cloud) {
+  const who = CLOUD_CREDENTIAL_CHECK[cloud]?.who;
+  if (!who) return null;
+  const bare = who.replace(/^the /, "");
+  return bare.charAt(0).toUpperCase() + bare.slice(1);
+}
+
+/**
+ * WHY A BILLING SETTING REFUSES EVERY SEARCH, as data: which refusal it is and the names involved, so the
+ * config page words it once, in plain English, without reading the resolver's sentence apart.
+ *
+ * `kind` is one of:
+ *   switch-beside-mode  subscription or api-key, and a cloud's switch on beside it (`clouds`)
+ *   two-clouds          cloud, and more than one cloud switched on (`clouds`)
+ *   no-cloud            cloud, and no cloud switched on and no gateway address (`clouds` lists every
+ *                       switch, and `gateway` the gateway's setting, as the choices to make)
+ *   not-a-mode          a word that is not a billing mode (`modes` are the ones this engine takes)
+ *   cloud-on-codex      cloud, on the Codex engine, which a cloud account cannot pay for (`engineSetting`
+ *                       and `engineChoice` name the Claude engine only where it would pay: one cloud
+ *                       switched on, or none and a gateway address; otherwise that move is one more refusal)
+ *   unclassified        a refusal this list does not name; the page says only that searches are refused.
+ *                       Not "other": that is an assistant's id in connect-clients.mjs, and a surface may
+ *                       not name one in code
+ *
+ * `defaulted` says the billing setting is blank, so `subscription` is the default and not a word anybody
+ * wrote: a page that said "payment is set to subscription" would send a reader looking for a line their
+ * settings file does not have. It is the state measured on Foundry, a switch on and the word unset.
+ *
+ * THE SAME PREDICATES AS THE RESOLVER, IN ITS ORDER. `resolveAuthMode` refuses by throwing a sentence and
+ * nothing else, so the kind is read back from the same environment through the same functions it uses
+ * (`billingMode`, `cloudsSwitchedOn`), in the order it checks them. Called only once it has thrown.
+ *
+ * NAMES, NEVER A VALUE. `mode` is sent only when it is one of the three modes; the word in a `not-a-mode`
+ * refusal is whatever was typed, and it is not sent at all.
+ */
+export function billingRefusalReason(id, env = process.env) {
+  const mode = billingMode(env);
+  const setting = "CLEAROTRON_AI_BILLING";
+  const clouds = (ids) => ids.map((c) => ({ name: cloudName(c), setting: CLOUD_SWITCH[c] }));
+  const defaulted = String(env[setting] ?? "").trim() === "";
+  const base = { setting, mode: null, defaulted, clouds: [], modes: [], gateway: null, engineSetting: null, engineChoice: null };
+  if (id === "openai-agent") {
+    if (mode === "cloud") {
+      // The resolver's own test for a cloud the Claude engine would pay through, in its words: one switch,
+      // or no switch and a gateway address.
+      const on = cloudsSwitchedOn(env);
+      const claudeWouldPay = on.length === 1 || (!on.length && Boolean(env.ANTHROPIC_BASE_URL));
+      return { ...base, kind: "cloud-on-codex", mode, modes: ["subscription", "api-key"],
+        ...(claudeWouldPay ? { engineSetting: "CLEAROTRON_AI", engineChoice: "anthropic-agent" } : {}) };
+    }
+    if (mode !== "subscription" && mode !== "api-key") return { ...base, kind: "not-a-mode", modes: ["subscription", "api-key"] };
+  }
+  if (id === "anthropic-agent") {
+    const on = cloudsSwitchedOn(env);
+    if ((mode === "subscription" || mode === "api-key") && on.length) return { ...base, kind: "switch-beside-mode", mode, clouds: clouds(on) };
+    if (mode === "cloud" && on.length > 1) return { ...base, kind: "two-clouds", mode, clouds: clouds(on) };
+    if (mode === "cloud" && !on.length) {
+      return { ...base, kind: "no-cloud", mode, clouds: clouds(Object.keys(CLOUD_SWITCH)), gateway: "ANTHROPIC_BASE_URL" };
+    }
+    if (!BILLING_MODES.includes(mode)) return { ...base, kind: "not-a-mode", modes: [...BILLING_MODES] };
+  }
+  return { ...base, kind: "unclassified", mode: BILLING_MODES.includes(mode) ? mode : null };
+}
+
 /**
  * The three states an install can be in, as far as running a search goes..
  *

package/driver/connotation-search.mjs

@@ -276,6 +276,51 @@ export const queryKey = (s) => String(s ?? "")
   .trim()
   .toLowerCase();
 
+/**
+ * The POPULATION behind `parsePrRiskResults`, because that reader reduces its input and nothing at a
+ * call site said so.
+ *
+ * `parsePrRiskResults` folds rows into a map keyed on the raw query text, so two rows carrying the same
+ * query become one and its output is smaller than the ledger it read. Every count taken during one
+ * evening's diagnosis was post-fold, by two people, and neither had named the raw population — so "the
+ * seat wrote 59 rows" and "59 rows survived the fold" were indistinguishable, and they are different
+ * facts with different causes. A seat that recorded one query twice and skipped another looks identical
+ * to a seat that simply skipped one, from the folded count alone.
+ *
+ * Returns both counts so a caller can say which it means. `rows` is what the ledger carries; `distinct`
+ * is what the fold leaves; the difference is rows that repeat a query already counted.
+ */
+/**
+ * THE TWO LABELS THE MEANING GATE PUTS ON A QUERY IT COULD NOT JOIN, and they are a CONTRACT rather
+ * than prose: `gateway.mjs` reads them back to choose which repair a seat is offered, and the two
+ * repairs are opposite. Re-wording either one in the validator, with the reader matching on its own
+ * copy of the old text, silently collapses that choice — the hint keeps being sent and stops being
+ * the right one. Both sides now build and detect from here, so a wording change is one edit.
+ *
+ * Anything a gate wants to ADD — which file it searched, what a neighbour is evidence of — goes
+ * OUTSIDE these markers, so the sentence can grow without moving the contract.
+ */
+export const CONNOTATION_UNMATCHED_MARK = "[unmatched; nearest recorded:";
+export const CONNOTATION_NO_RESEMBLANCE_MARK = "[no recorded query resembles this one]";
+
+export function prRiskPopulation(ledgerRaw) {
+  let parsed;
+  try { parsed = JSON.parse(ledgerRaw); } catch { return { rows: 0, distinct: 0, repeated: 0 }; }
+  const batches = Array.isArray(parsed) ? parsed : [parsed];
+  let rows = 0;
+  const seen = new Set();
+  for (const b of batches) {
+    const pr = b?.extras?.pr_risk;
+    if (!Array.isArray(pr)) continue;
+    for (const e of pr) {
+      if (!e || typeof e.query !== "string" || !e.query.trim()) continue;
+      rows += 1;
+      seen.add(e.query.trim());
+    }
+  }
+  return { rows, distinct: seen.size, repeated: rows - seen.size };
+}
+
 export function parsePrRiskResults(ledgerRaw) {
   let parsed;
   try { parsed = JSON.parse(ledgerRaw); } catch { return []; }

package/driver/contract-arm2-baseline.json

@@ -11,7 +11,7 @@
     "the baseline tracks named elements, and a rename is a new name. Regenerate rather than work around it.",
     "Measured 139 of 287 declared elements."
   ],
-  "total": 107,
+  "total": 105,
   "byStage": {
     "matter-frame": [
       "### Intake asks line shape — rendered by the driver from intake_asks[]",
@@ -94,8 +94,6 @@
     "register-digest": [
       "## Summary counts — total queries executed (search + detail-fetch), enumerated records across N axes, crowd-descriptor count, candidates past the gate, surfaced count, open-verification-flag count",
       "Audit trail — per-unit search/detail-fetch counts, per-jurisdiction `_query` attribution",
-      "INSTRUCTED CHECKS — the answer to each requester ask the register owns",
-      "adopt-or-override each placement by engaging its reason, and the `### Disagreement resolutions` rows (one per surfaced disagreement and per borderline:true, each ADOPTED/OVERRODE in writing)",
       "return payload — the absolute output path plus a 2-3 line summary (counts + the path of the file written)",
       "rolled-up coverage judgment — `sufficient: <true|false>`",
       "source attribution — the register name tagged on each record, plus the EUIPO `environment` word",