clearotron 0.2.2 → 0.2.3

package/shared/node-floor.mjs

@@ -0,0 +1,97 @@
+// SPDX-License-Identifier: AGPL-3.0-only
+// Copyright 2026 Cordillera Sàrl. Additional terms under section 7 of the AGPL-3.0 apply — see ADDITIONAL-TERMS.md
+//
+// THE MINIMUM NODE VERSION, READ FROM THE ONE PLACE THAT DECLARES IT.
+//
+// `package.json` says `engines: { node: ">=22.13.0" }`. npm reads that field, and so does everything
+// here. Nothing restates the number.
+//
+// WHY THIS FILE EXISTS RATHER THAN A CONSTANT. There was a constant: `NODE_FLOOR = 22` in bin/onboard.mjs,
+// compared as `Number(process.versions.node.split(".")[0]) >= NODE_FLOOR`. A major-only comparison
+// STRUCTURALLY CANNOT SEE A MINOR FLOOR, so 22.9.0 passed a check written for a 22.13.0 floor — the check said
+// `node 22.9.0` and a tick while npm, reading the same requirement from the same repository, printed
+// EBADENGINE for it. One requirement, two spellings, already disagreeing.
+//
+// The cost was a first-run failure nobody could diagnose: an engine door exited 1 on a machine below the
+// floor, and every check the product offers said the runtime was fine.
+
+import { readFileSync } from "node:fs";
+import { fileURLToPath } from "node:url";
+import { join, dirname } from "node:path";
+
+const HERE = dirname(fileURLToPath(import.meta.url));
+
+/** The declared range, verbatim, e.g. `">=22.13.0"`. Throws if the field is gone — an absent floor is a
+ *  packaging fault, not a licence to run on anything. */
+export function declaredRange(root = join(HERE, "..")) {
+  const range = JSON.parse(readFileSync(join(root, "package.json"), "utf8"))?.engines?.node;
+  if (!range) throw new Error("package.json declares no engines.node — the runtime floor has no source");
+  return String(range);
+}
+
+/**
+ * `">=22.13.0"` → [22, 13, 0]. `">=22"` and `">=22.13"` are accepted too, with the absent parts read as
+ * zero, because that is what they mean and not a guess — and because the field is edited by whoever
+ * changes the floor, who should not have to know which spelling this reader was written against. A
+ * coordination failure between two people editing one number is the defect this whole file exists for.
+ *
+ * ONLY the `>=` family. A caret or tilde range, or an `||` union, THROWS rather than being interpreted:
+ * a floor read wrongly is worse than one not read at all, because it would silently pass every version
+ * and take every check built on it with it.
+ */
+export function floorOf(range) {
+  const m = /^>=\s*(\d+)(?:\.(\d+))?(?:\.(\d+))?\s*$/.exec(String(range).trim());
+  if (!m) throw new Error(`engines.node is ${range}, which this reader does not understand — expected ">=x", ">=x.y" or ">=x.y.z"`);
+  return [Number(m[1]), Number(m[2] ?? 0), Number(m[3] ?? 0)];
+}
+
+/**
+ * `"22.16.0"` → [22, 16, 0], ignoring any pre-release or build suffix. NULL when it cannot be read.
+ *
+ * Null rather than zeroes, and the difference is the whole of it: `[0, 0, 0]` compares as below every
+ * floor, so a version string this reader did not understand would REFUSE — and this file would become
+ * the reason an install fails on a Node that is probably fine. A parser gap must not become an outage.
+ * Found in review, 2026-09-08.
+ */
+export const partsOf = (v) => {
+  // THE `v` IS OPTIONAL AND MUST BE, because both spellings are in reach: `process.versions.node` has
+  // no prefix and `process.version` does. Without it a caller handed the prefixed form gets null,
+  // null passes, and an out-of-date runtime is waved through by the guard written to stop it — the
+  // permissive half of the same asymmetry, which is the direction that fails silently.
+  const m = /^v?(\d+)\.(\d+)\.(\d+)/.exec(String(v).trim());
+  return m ? [Number(m[1]), Number(m[2]), Number(m[3])] : null;
+};
+
+/** Is `current` at or above `floor`? ALL THREE PARTS, in order — the defect this replaces compared one. */
+export function meetsFloor(current, floor) {
+  const c = partsOf(current);
+  // AN UNREADABLE RUNNING VERSION PASSES, and that asymmetry is deliberate. The DECLARED range is our
+  // own manifest and throws loudly when it cannot be read, because that is a packaging fault we own.
+  // The running version is whatever the runtime reports, and refusing one we failed to parse would
+  // stop a working install over our own gap. Refuse only what we can show is below the floor.
+  if (!c) return true;
+  for (let i = 0; i < 3; i += 1) {
+    if (c[i] > floor[i]) return true;
+    if (c[i] < floor[i]) return false;
+  }
+  return true;
+}
+
+/**
+ * The whole answer, for a caller that wants to refuse.
+ *
+ * `current` and `root` are injected so a check can drive every side of this without a second Node
+ * installation — a floor guard that can only be exercised by running on an old runtime is one nobody
+ * ever sees fail.
+ */
+export function nodeFloorVerdict({ current = process.versions.node, root } = {}) {
+  const range = declaredRange(root);
+  const floor = floorOf(range);
+  return { ok: meetsFloor(current, floor), current, required: floor.join("."), range };
+}
+
+/** What a person is told, in one sentence, naming both versions. No stack, no advice they cannot act on. */
+export function nodeFloorRefusal(v) {
+  return `This needs Node ${v.required} or newer, and this is Node ${v.current}. `
+    + "Upgrade Node and run the command again — nothing else here will work until you do.";
+}

package/shared/staff-domain.mjs

@@ -0,0 +1,154 @@
+// SPDX-License-Identifier: AGPL-3.0-only
+// Copyright 2026 Cordillera Sàrl. Additional terms under section 7 of the AGPL-3.0 apply — see ADDITIONAL-TERMS.md
+// staff-domain.mjs — what a staff-domain rule ADMITS, decided before one is written.
+//
+// `PORTAL_STAFF_DOMAINS` is a list of email domains, and every address at a listed domain that gets
+// past this instance's sign-in door is staff: it sees every brand owner on the instance
+// (driver/portal-access.mjs). That is a rule about a set of people, not about one person.
+//
+// The install used to build that rule by taking everything after the last `@` of the one address it
+// was given. On a laptop that address is `<account>@localhost` and the rule admits the one identity
+// that can sign in, which is why it was safe and why nobody looked at it again. Given a real address
+// the same line turns a person into their whole employer, or into every customer of a webmail
+// provider, with nothing said to the operator and nothing to undo. A stranger's install granted a
+// documentation domain that way, read its own settings page back, and reported it as a back door.
+//
+// So the derivation is classified before it is used, and there are three answers:
+//
+//   "narrow"    the domain cannot name a second person on this machine — `localhost`, or any bare
+//               hostname with no dot. Deriving a rule from it is what it always was: safe, silent.
+//   "public"    a webmail or shared provider. Never a staff rule: it would admit strangers, and no
+//               deployment can want it. Refused outright, and the refusal names the domain.
+//   "reserved"  a domain reserved for documentation and testing (RFC 2606). Nobody's real mail lives
+//               there, so a rule built from one is always an address somebody typed as a placeholder.
+//               Refused for the same reason, with a different sentence, because the remedy differs.
+//   "wide"      an ordinary routable domain. It may well be the right rule — it is how a firm admits
+//               its own lawyers — but it admits people the operator has not met, so it is stated in
+//               the words the settings page will use and confirmed before it is written. It is never
+//               derived silently from one address.
+//
+// FAIL-CLOSED, in the direction of a smaller grant. A domain wrongly classified `public` refuses, and
+// the operator sets `PORTAL_STAFF_DOMAINS` themselves in one line — an explicit decision, recorded
+// where the settings page can name it. A domain wrongly classified `wide` asks a question. Neither
+// outcome grants anything, which is why the lists below are allowed to be short and stay short: the
+// `wide` branch is what actually protects an operator, and the lists only decide whether the product
+// asks a question or refuses to ask one.
+
+/** Last-@ semantics, matching driver/portal-access.mjs and shared/scope.mjs `isFirmDomain`. */
+export function domainOfEmail(email) {
+  const e = String(email ?? "").trim().toLowerCase();
+  const at = e.lastIndexOf("@");
+  return at > 0 ? e.slice(at + 1) : "";
+}
+
+/**
+ * Webmail and shared mailbox providers, exactly.
+ *
+ * Not a census of the internet, and deliberately not growing into one: an unlisted provider still
+ * lands in `wide`, where it is stated and confirmed rather than written silently. What this list buys
+ * is that the commonest addresses a person types — their own personal mail — are refused with a
+ * sentence about why, instead of being offered as a rule somebody might say yes to.
+ */
+export const PUBLIC_EMAIL_DOMAINS = Object.freeze(new Set([
+  "gmail.com", "googlemail.com", "icloud.com", "me.com", "mac.com",
+  "aol.com", "mail.com", "gmx.com", "gmx.de", "gmx.net", "web.de", "t-online.de",
+  "proton.me", "protonmail.com", "protonmail.ch", "pm.me", "tuta.io", "tutanota.com",
+  "fastmail.com", "fastmail.fm", "hey.com", "zoho.com", "hushmail.com",
+  "mail.ru", "inbox.ru", "list.ru", "bk.ru", "rambler.ru",
+  "qq.com", "163.com", "126.com", "sina.com", "naver.com", "daum.net",
+  "seznam.cz", "wp.pl", "o2.pl", "interia.pl", "libero.it", "virgilio.it", "tiscali.it",
+  "free.fr", "orange.fr", "wanadoo.fr", "laposte.net", "sfr.fr", "bbox.fr",
+  "comcast.net", "verizon.net", "att.net", "sbcglobal.net", "bellsouth.net", "cox.net",
+  "btinternet.com", "sky.com", "virginmedia.com", "ntlworld.com", "talktalk.net",
+  "bigpond.com", "optusnet.com.au", "shaw.ca", "sympatico.ca", "rogers.com",
+  "xs4all.nl", "ziggo.nl", "telenet.be", "uol.com.br", "bol.com.br", "terra.com.br",
+  "rediffmail.com", "yandex.com", "yandex.ru", "ya.ru",
+]));
+
+/**
+ * Providers that sell the same mailbox under a per-country domain.
+ *
+ * Matched on the FIRST label, so `yahoo.co.uk` and `yahoo.fr` are covered without listing every
+ * country. Kept to names that are a provider and nothing else — a first label like `free` or `orange`
+ * is a real company's name somewhere, so those stay in the exact list above.
+ */
+export const PUBLIC_EMAIL_FAMILIES = Object.freeze(new Set([
+  "yahoo", "ymail", "rocketmail", "hotmail", "outlook", "live", "msn", "gmx", "yandex", "googlemail",
+]));
+
+/**
+ * Reserved for documentation and testing — RFC 2606 §2 and §3.
+ *
+ * `example.com`, `example.net`, `example.org` and everything under them, plus the whole of the
+ * `.example`, `.invalid`, `.test` and `.localhost` top-level names. Real mail is never delivered to
+ * any of them, so an address at one is a placeholder somebody typed — which is exactly what happened.
+ *
+ * `localhost` ITSELF IS NOT HERE. A bare `localhost` is the local-account default and is classified
+ * `narrow` below; only `something.localhost` reaches this test.
+ */
+function isReservedDomain(domain) {
+  if (/^example\.(com|net|org)$/.test(domain)) return true;
+  if (/\.example\.(com|net|org)$/.test(domain)) return true;
+  const tld = domain.slice(domain.lastIndexOf(".") + 1);
+  return domain.includes(".") && ["example", "invalid", "test", "localhost"].includes(tld);
+}
+
+/** A domain that cannot name a second person on this machine: `localhost`, or any dotless hostname. */
+function isNarrowDomain(domain) {
+  return domain === "localhost" || domain === "localhost.localdomain" || !domain.includes(".");
+}
+
+/**
+ * What a staff rule built from this domain would admit.
+ *
+ * @param {string} domain a bare domain, already lowercased — `domainOfEmail` produces one.
+ * @returns {"narrow"|"public"|"reserved"|"wide"|""}  "" only when there is no domain to classify.
+ */
+export function classifyStaffDomain(domain) {
+  const d = String(domain ?? "").trim().toLowerCase();
+  if (!d) return "";
+  if (isNarrowDomain(d)) return "narrow";
+  if (isReservedDomain(d)) return "reserved";
+  if (PUBLIC_EMAIL_DOMAINS.has(d)) return "public";
+  if (PUBLIC_EMAIL_FAMILIES.has(d.slice(0, d.indexOf(".")))) return "public";
+  return "wide";
+}
+
+/**
+ * The rule in the words the settings page uses, so the operator recognises what they agreed to.
+ *
+ * ONE COMPOSER FOR BOTH SURFACES. The People & access screen renders "Anyone at <domain>" under a
+ * heading that calls it a config rule rather than a person, and describes staff as capable of seeing
+ * every brand owner. A consent prompt phrased any other way asks about one thing and shows another.
+ */
+export function staffGrantSentence(domain, { staffLabel = "Staff" } = {}) {
+  return `Anyone at ${domain} — a rule, not a person. ${staffLabel}: capable to see every brand owner `
+    + "on this instance.";
+}
+
+/**
+ * Why this domain cannot become a staff rule, and what to do instead.
+ *
+ * Returns null for a domain that CAN — `narrow` and `wide` are not refusals, and `wide` is answered by
+ * the confirmation the caller runs, not by this function.
+ */
+export function staffDomainRefusal(domain, { variable = "PORTAL_STAFF_DOMAINS" } = {}) {
+  const d = String(domain ?? "").trim().toLowerCase();
+  const verdict = classifyStaffDomain(d);
+  if (verdict === "public") {
+    return `${d} is a public email provider, so a staff rule built from it would admit anyone with an `
+      + `address there — not your colleagues. Refusing to write one.\n`
+      + `  Use an address at a domain your organisation controls, or set ${variable} yourself to the `
+      + "domain you mean.\n"
+      + "  If this machine is only yours, the local-account form takes no rule at all: leave the "
+      + "address as <account>@localhost.";
+  }
+  if (verdict === "reserved") {
+    return `${d} is reserved for documentation and receives no real mail (RFC 2606), so it is an `
+      + "address somebody typed as a placeholder rather than one that signs in. Refusing to build a "
+      + "staff rule from it.\n"
+      + "  Use the address you actually sign in with, or the local-account form <account>@localhost "
+      + "if this machine is only yours.";
+  }
+  return null;
+}

package/shared/store-in-repo.mjs

@@ -38,13 +38,34 @@
 // that does not exist yet is still misconfigured if it names another tree — the service would create it
 // and then fail every commit — so the lexical judgment stands where the filesystem cannot overturn it.
 
-import { resolve, dirname } from "node:path";
+import { resolve, dirname, relative, isAbsolute } from "node:path";
 import { realpathSync } from "node:fs";
 
 /** `resolve`, then the symlink-resolved form when the path exists — null when it cannot be read. */
 const real = (p) => { try { return realpathSync(resolve(p)); } catch { return null; } };
 
-const within = (dir, root) => dir === root || dir.startsWith(root.endsWith("/") ? root : root + "/");
+// CONTAINMENT IS ASKED OF THE PATH LIBRARY, NOT OF THE STRING.
+//
+// This was `dir.startsWith(root + "/")`, with the separator written in. On Windows `resolve()` returns
+// backslashes, so `C:\…\config\recipes` does not start with `C:\…\config/` and a folder plainly inside
+// its parent read as OUTSIDE — an operator on a correct install was told their recipe store was outside
+// the repository root, and the saved-search door refused. Measured on his paths.
+//
+// The posix control passed throughout, which is why it survived: the string test is right on the platform
+// it was written on and wrong on the one nobody here runs.
+//
+// `relative` also settles two cases a prefix test gets wrong on Windows even with the separator fixed: a
+// different drive letter yields an absolute path rather than a `..` walk, and path comparison there is
+// case-insensitive in a way `startsWith` is not. A sibling directory whose name merely begins with the
+// root's — `config` and `configXX` — is still outside, which the old `+ "/"` also got right and any
+// replacement had to keep.
+// `impl` is the path module to ask, injected ONLY so a check can drive the Windows behaviour from a
+// Linux runner. That matters here more than usual: this defect was invisible on the platform every one
+// of us runs, and a guard that can only be exercised on Windows is a guard nobody will ever see fail.
+export const within = (dir, root, impl = { relative, isAbsolute }) => {
+  const rel = impl.relative(root, dir);
+  return rel === "" || (!rel.startsWith("..") && !impl.isAbsolute(rel));
+};
 
 /**
  * Is `storeDir` somewhere `git -C repoRoot add` could stage it?

package/skills/clearotron-ops/SKILL.md

@@ -41,7 +41,7 @@ Extract from the request, faithfully (verbatim beats paraphrase):
 - **`forwarder`** (+ `forwarderEmail`) — the requester/reply route. REQUIRED, no default: this is
   where the report goes; a wrong route misdelivers a confidential document.
 - **`profileKey`** — call **`list_profiles`** and resolve by JUDGMENT: an explicit name, a
-  misspelling ("Zefyr" → zephyr), or an implicit reference ("our functional-beverage client") all
+  misspelling (a name typed as it sounds), or an implicit reference ("our functional-beverage client") all
   map to a key. OMIT it for a new/unknown customer (the neutral generic profile applies — this is
   non-blocking by design). Ask the requester only when you genuinely cannot tell. **Never pick a
   profile from the sender's email domain.**

package/driver/recipes/README.md

@@ -1,49 +0,0 @@
-# Saved searches ("recipes")
-
-One subdirectory per customer — `aurora/` and `zephyr/` — each holding one JSON file per saved search at
-`<customer>/<slug>.json`; the loader walks directories only, so nothing else here is a store. A recipe is a
-small named bundle: a base product, optional component toggles, an optional `scope` block (where the
-machinery points: `jurisdictions`, `platforms`, `classes`), and instruction-shaped `extras`.
-The display field is `label`, deliberately not `name` — `name` is a profile key, and the two key sets are
-disjoint by design, so a saved search can never carry rating config.
-
-## What reads it
-
-`loadRecipes()` in `../search-policy.mjs` walks `<dir>/<customer>/<slug>.json` into a
-`Map("customer/slug" → recipe)`, validating each file with `validateRecipe` — the same validator the write
-door uses, so the UI cannot persist a recipe the driver would later reject. `resolveSearchPolicy` then
-turns a job's `recipeKey` into the product, components, extras and scope the run uses; a recipe only runs
-for its own customer, and an `archived` one refuses with a clarify.
-
-The write side is `../recipe-service.mjs` (loopback, CF Access JWT, git auto-commit as the verified
-identity). The portal mounts those routes through `../portal-upstream.mjs`, which rebuilds the customer
-path segment from the resolved account; `../dev-portal.mjs` proxies `/recipes/*` for dev.
-
-**The store is named, never guessed.** `CLEAROTRON_RECIPES_DIR` unset means the deployment has no saved
-searches — not that it falls back to this directory. That fallback existed and was removed: production is
-exactly where the variable is unset, so it would have surfaced invented customers inside the product.
-
-## These are synthetic demos
-
-`aurora` and `zephyr` are fictional customers (`../profiles/aurora.json`, `../profiles/zephyr.json`) that
-exist so the dev cockpit and the test suite have something to render. A real deployment's recipes live
-outside the repo, in the customer-config store beside the profiles — no client data in git.
-
-| File | Base product, and any extras it carries |
-|---|---|
-| `aurora/quarterly-screen.json` | `knockout-search`, `extras.emailTable` |
-| `aurora/screen-with-register-counts.json` | `knockout-search` |
-| `zephyr/standard-clearance.json` | `multi-country-focus-search`, `extras.standingInstructions` + `extras.defaultDeadlineDays` |
-
-Two of them carry settings the product no longer offers, which is not an oversight: `emailTable` is inert
-but still validated so recipes written while it worked keep loading, and `defaultDeadlineDays` is a retired
-extra that `loadRecipes` drops on read and `validateRecipe` refuses on save. A stored recipe must not brick
-on a change it never asked for.
-
-## Where to start
-
-`zephyr/standard-clearance.json` — twelve lines, and the one whose `extras` show both what an
-instruction-shaped setting looks like (`standingInstructions`) and what a retired one looks like still
-sitting in a stored file. Then the recipe block in `../search-policy.mjs` (`RECIPE_KEYS`,
-`RECIPE_SCOPE_KEYS`, `RECIPE_EXTRA_KEYS`, `validateRecipe`), which is where every rule above is enforced
-and commented.

package/driver/skills/prelim-search/risk-framework-aurora.manifest.json

@@ -1,19 +0,0 @@
-{
-  "schema_version": 1,
-  "framework_key": "aurora",
-  "title": "Aurora Interactive risk framework (synthetic demo)",
-  "source_deck": "Synthetic demo transposition of a customer risk deck (structure faithful, content invented), doc 50 shape",
-  "entity_label": "Aurora Interactive",
-  "bands": [
-    { "label": "Very High", "tone": "severe" },
-    { "label": "High", "tone": "high" },
-    { "label": "Medium", "tone": "medium" },
-    { "label": "Manageable", "tone": "low" },
-    { "label": "Low", "tone": "minimal" }
-  ],
-  "structure": {
-    "kind": "matrix",
-    "axes": ["Legal Risk Level (A–E)", "Dispute Type"],
-    "display_note": "The band is read off this framework's Level × Dispute Type matrix; the matrix ceilings are stated in the deck and honoured as written."
-  }
-}

package/driver/skills/prelim-search/risk-framework-aurora.md

@@ -1,77 +0,0 @@
-# Risk framework — Aurora Interactive (SYNTHETIC demo customer)
-
-- **Applies to:** Aurora Interactive matters (`profileKey: aurora`).
-- **Source:** house-authored demonstration framework. Matrix-shaped, to exercise the two-input path.
-- **Bands, highest to lowest:** Very High · High · **Medium** · Manageable · **Low** (this framework, unlike the house default, has a Low band — its Level A output).
-- **Entity in prose:** **Aurora Interactive** (name the company; acquired studios are self-exclusions, not the entity).
-- **Customer emphasis:** defensibility-first and conservative — lead with a clear go / no-go and the practical "would they actually enforce" read; surface an alternative-name track early on a headline conflict.
-
-*A rubric to be reasoned with — not paraphrased away and not reduced to a lookup.* This framework RATES Aurora Interactive matters (doc 50). It is **matrix-shaped**: reason the two inputs below in order — the Legal Risk Level, then the Dispute Type — and read the band off the matrix. **State the rating as the band word** (Very High / High / Medium / Manageable / Low); the numerals beside the bands are internal indices, never the output. The engine applies this framework on an advisory basis; the senior lawyer makes the final determination. The firm-wide reasoning discipline — the consumer-confusion gate, the dominant-element rule, crowded-field handling, G&S discipline — lives in [`synthesis-rules.md`](synthesis-rules.md) and applies under every framework; Aurora calibration examples live in [`worked-examples-aurora.md`](worked-examples-aurora.md).
-
-## Legal Risk Levels (probability adverse party prevails)
-
-| Level | Probability | Description |
-|-------|------------|-------------|
-| **A** | 0–24% | Weak claim, negligible risk, strong defences available |
-| **B** | 25–49% | Some credible claims but more likely to prevail; manageable |
-| **C** | 51–60% | Better than even chance of adverse outcome; material risk, may need settlement |
-| **D** | 61–74% | Likely adverse outcome; some credible defences but unsuccessful result expected |
-| **E** | 75%+ | Strong claim / slam dunk against us; no or only weak defences |
-
-> **The letter follows the words (consistency rule — apply to every rated finding).** State the likelihood of confusion in plain words *first* — "more likely than not they'd win", "better-than-even is not reached", "confusion is unlikely", "distinguishable as wholes" — **then pick the letter those words require**: better-than-even reached → **C–E**; not reached → **A or B** (B = 25–49%, "credible claim but we have the better of it"). The prose read and the A–E letter are **one judgment and may not disagree.**
-
-## Dispute Types
-
-| Type | Characteristics |
-|------|----------------|
-| **Classic** | Actual confusion anticipated, well-known/famous mark, aggressive brand owner, direct industry competitor |
-| **Horse Trade** | Market overlap, settlement likely with payment or use restrictions |
-| **Paper Conflict** | Material register risk but no obvious market overlap in practice |
-| **Descriptive Terms** | Descriptiveness defence available, or extensive unregistered use weakens distinctiveness |
-| **Nuisance Claim** | Weak claim but party may still complain (trolls, squatters, speculative filings) |
-
-## The band matrix — reason the two inputs, then read the band off the matrix
-
-The band is **derived from two reasoned inputs, in this order — it is not chosen freely, and no practical /
-optics factor moves the band directly:**
-
-1. **Legal Risk Level (A–E) — first.** Answers one question: *"if this third party sued Aurora Interactive,
-   would they win?"* Set it from the likelihood-of-confusion comparison (marks-as-wholes × goods/services; see
-   `synthesis-rules.md` → *The consumer confusion test*), net of merits defences. (50% is not allowed — take a
-   view.) Applies to registered AND common-law rights.
-2. **Dispute Type — second.** Classic / Horse Trade / Paper Conflict / Descriptive (or extensive-use) / Nuisance.
-
-Then read the **band off the matrix** — this is the *output*; you do not adjust it afterwards:
-
-| Band | Requires |
-|---|---|
-| **Very High** *(5)* | Level **D or E** AND **Classic** |
-| **High** *(4)* | Level **D or E** AND (**Horse Trade** or **Nuisance**) |
-| **Medium** *(3)* | Level **C / D / E** AND (**Paper** or **Descriptive**) — OR — Level **C** AND (**Horse Trade** / **Classic** / **Nuisance**) |
-| **Manageable** *(2)* | Level **B** (routinely accepted; still alert on a troll/squatter, a known competitor / major brand owner, or heavy clean-up cost) |
-| **Low** *(1)* | Level **A** |
-
-**The ceilings are hard — and they ARE this framework's anti-escalation mechanism:**
-- **High and Very High REQUIRE Legal Level D or E.** A **Level-C finding tops out at Medium**, whatever the
-  dispute type or the practical factors. **Level A → Low and Level B → Manageable are fixed.**
-- **Elevate / mitigate considerations move the INPUTS — the Legal Level or the Dispute Type — never the output
-  band** (the factor lists live in `synthesis-rules.md`). A "confirmed aggressive enforcer", owner size, PR
-  sensitivity, or an Aurora Interactive partnership cannot lift a finding past its level's ceiling: they only
-  change *whether they'd win* (the Level) or the *character* of the dispute (the Type), and the matrix then
-  produces the band. This is exactly the optics-escalation error the ceilings prevent — a Level-C read does NOT
-  become High because the owner enforces aggressively; a house-mark-distinguished Level-B mark does NOT become
-  Very High because the owner is large or a partner.
-
-**Calibration anchors (structure-faithful; the mark names are invented, the anchor companies are real and named only as public examples of scale):** VELARIS / POLARIS-class famous-mark conflicts = Level
-**E** + **Classic** = **Very High**; TerraForge / TerraFlex = Level **E** + **Horse Trade** = **High**;
-Northgate / NorthData = Level **D** + **Horse Trade** = **High**.
-
-## Band meanings
-
-| Band | Meaning | Typical Response |
-|-------|---------|-----------------|
-| **Very High** | Generally not accepted | Run alternative name in parallel |
-| **High** | May accept with strong mitigation | Requires active risk management plan |
-| **Medium** | May accept with settlement/clean-up plan | Proceed with awareness and contingency |
-| **Manageable** | Routinely accepted | Note and monitor |
-| **Low** | Target outcome | Proceed with confidence |

package/driver/skills/prelim-search/risk-framework-zephyr.manifest.json

@@ -1,14 +0,0 @@
-{
-  "schema_version": 1,
-  "framework_key": "zephyr",
-  "title": "Zephyr Beverages risk framework (synthetic demo)",
-  "source_deck": "Synthetic demo transposition of a customer risk deck (structure faithful, content invented), doc 50 shape",
-  "entity_label": "Zephyr/Volt/Kaskade",
-  "bands": [
-    { "label": "Very High", "tone": "severe" },
-    { "label": "High", "tone": "high" },
-    { "label": "Medium", "tone": "medium" },
-    { "label": "Manageable", "tone": "low" }
-  ],
-  "structure": { "kind": "bands" }
-}

package/driver/skills/prelim-search/risk-framework-zephyr.md

@@ -1,33 +0,0 @@
-# Risk framework — Zephyr Beverages (SYNTHETIC demo customer)
-
-- **Applies to:** Zephyr matters (`profileKey: zephyr`).
-- **Source:** house-authored demonstration framework. The house default with a different entity family and one band relabelled.
-- **Bands, highest to lowest:** Very High · High · **Medium** · Manageable. There is no "Low"; Manageable is the lowest band.
-- **Entity in prose:** **Zephyr/Volt/Kaskade** — name the brand family, not "the company".
-- **Customer emphasis:** pragmatic and launch-oriented — a clear go / no-go and the facts that condition each real blocker, rather than exhaustive caveats. (Express this emphasis in the product voice: facts that condition, never a recommended "path" — retired voice, 2026-07-28.)
-
-*This is the house default with exactly two differences: the entity family, and band 3 is labelled **Medium** (not "Moderate"). A rubric to be reasoned with, not paraphrased.* This framework RATES the matter (doc 50): reason each conflict through the band definitions below — Legal position first, then Practical position, then Potential outcomes — and the band follows the words. A conflict Zephyr/Volt/Kaskade clearly wins with no material risk is **not a rated conflict** (there is no "Low" band; see `synthesis-rules.md`). The engine applies this framework on an advisory basis; the senior lawyer makes the final determination. The firm-wide reasoning discipline lives in [`synthesis-rules.md`](synthesis-rules.md) and applies under every framework; Zephyr calibration examples live in [`worked-examples-zephyr.md`](worked-examples-zephyr.md).
-
-## VERY HIGH RISK
-
-- **Legal position.** Prior rights owner is **very likely to win** and there are **no** credible defences or risk-mitigation strategies available to **Zephyr/Volt/Kaskade**.
-- **Practical position (one or more).** There is an obvious market overlap or risk of actual confusion — coexistence does not appear possible, even with payment of money, use restrictions or other exchange; **or** the prior mark is famous, owned by a known aggressor, or an industry competitor.
-- **Potential outcomes.** Name change likely required, possibly on an urgent basis · monetary exposure **more than $10 million** · severe PR consequences · highly unlikely to mitigate risk irrespective of time and money.
-
-## HIGH RISK
-
-- **Legal position.** Prior rights owner is **likely to win**, although some credible defences are available to **Zephyr/Volt/Kaskade**.
-- **Practical position.** There is possible market overlap, but co-existence appears possible with settlement involving payment of money, use restrictions, and/or other exchange.
-- **Potential outcomes.** Name change may be required, possibly on an urgent basis · high business disruption possible · monetary exposure **up to $10 million** · PR consequences · cleanup or mitigation may be possible depending on time and budget.
-
-## MEDIUM RISK
-
-- **Legal position.** Prior rights owner is **more likely than not to win**, although reasonable defences or risk-mitigation steps are available to **Zephyr/Volt/Kaskade**.
-- **Practical position (one or more).** There is no obvious market overlap; **or** risk-mitigation strategies are available to Zephyr/Volt/Kaskade (e.g. the prior mark is arguably weak or vulnerable to attack); **or** there are practical factors which suggest the prior rights owner may not object (e.g. settlement discussions are underway).
-- **Potential outcomes.** Name change may be required, possibly on an urgent basis · business disruption possible · monetary exposure **$5 to 7 figures** · PR consequences possible · cleanup or mitigation may be possible depending on time and budget.
-
-## MANAGEABLE RISK *(lowest band)*
-
-- **Legal position.** **Zephyr/Volt/Kaskade** is **more likely than not to win**, although there is still material risk and uncertainty.
-- **Practical position.** This level of risk includes nuisance claims, strategic (but weak) complaints by a competitor, and registration obstacles.
-- **Potential outcomes.** Budget potentially required for prosecution hurdles and nuisance claims.

package/driver/skills/prelim-search/worked-examples-aurora.md

@@ -1,10 +0,0 @@
-# Example per-customer worked examples — aurora (synthetic)
-
-Synthetic placeholder demonstrating a profile's `workedExamplesPath` hook. Real per-customer worked
-examples are a customer-config-store artifact, not repo code.
-
-**Convention (P6):** a per-customer file ADDS CALIBRATION and never replaces the voice. The before/after
-voice pairs live in [`worked-examples.md`](worked-examples.md) → *Voice — worked before / after pairs*, and
-a customer artifact that omits them leaves this customer's runs without the examples the house voice is
-learned from. The house prose contract itself is carried unconditionally by the stage message, so the RULES
-reach every run regardless of profile — it is the worked pairs that a replacement file can silently drop.

package/driver/skills/prelim-search/worked-examples-zephyr.md

@@ -1,10 +0,0 @@
-# Example per-customer worked examples — zephyr (synthetic)
-
-Synthetic placeholder demonstrating a profile's `workedExamplesPath` hook. Real per-customer worked
-examples are a customer-config-store artifact, not repo code.
-
-**Convention (P6):** a per-customer file ADDS CALIBRATION and never replaces the voice. The before/after
-voice pairs live in [`worked-examples.md`](worked-examples.md) → *Voice — worked before / after pairs*, and
-a customer artifact that omits them leaves this customer's runs without the examples the house voice is
-learned from. The house prose contract itself is carried unconditionally by the stage message, so the RULES
-reach every run regardless of profile — it is the worked pairs that a replacement file can silently drop.