clearotron 0.2.2 → 0.2.4

package/shared/withheld-paths-access.mjs

@@ -8,33 +8,50 @@
 // private." `shared/withheld-paths.mjs` STAYS BEHIND. The reading where it ships with a rewritten
 // header is dead and must not be revived.
 //
-// Five files read that record and are wanted on the public tree: `scripts/citation-line-check.mjs`,
-// `scripts/mint-suite-census.mjs`, and the arms `no-caveat-repair`,
-// `signa-mock-lane-is-unreachable-from-a-run` and `the-providers-suite-is-censused`. A static import of
-// a module that is not there throws before anything runs — for a test that means its cases VANISH FROM
-// THE COUNT rather than failing, which is the 354-to-279 shape already records. This
-// module is how they degrade on purpose instead.
+// THREE files read that record, and all three are in this repository:
+// `scripts/citation-line-check.mjs`, `scripts/mint-suite-census.mjs` and
+// `shared/reference-guard-classes.mjs`. A static import of a module that is not there throws before
+// anything runs, and for a test that means its cases VANISH FROM THE COUNT rather than failing. This
+// module is how those three degrade on purpose instead.
+//
+// The list above was wrong in both directions and is corrected here (measured 2026-09-09): it said
+// five, naming three tests that exist in this repository under no path, and it omitted
+// `shared/reference-guard-classes.mjs`, which had already recorded itself as a reader in its own file.
 //
 // ── WHY DEGRADING IS SAFE HERE, WHICH IS THE WHOLE ARGUMENT ──────────────────────────────────────
 //
-// Every one of the five asks the record ONE question: is this file absent because it was deliberately
+// Every one of the three asks the record ONE question: is this file absent because it was deliberately
 // withheld, or absent because something broke? On the public tree nothing was withheld FROM that tree,
 // so the honest answer is "nothing is withheld" — and each caller then becomes STRICTER, never weaker:
 //
 //   citation-line-check   every file crosses the cut, so every citation must resolve
 //   mint-suite-census     no exemption, so a removed test file is a LOSS
-//   the three arms        an absence is damage, never a stated consequence
+//   reference-guard-classes  nothing is skipped, so the whole tree is counted
+//
+// MEASURED, not argued (2026-09-09): `censusOf` was run twice over one file list. With no record it
+// counted four files and skipped none; with a record naming two of them it counted two and skipped
+// two. Absent, the record cannot hide a defect.
 //
 // A fallback that can only tighten is one that cannot hide a defect. That is the property that makes
 // this safe to do without a flag, and it is the property to re-check before adding a sixth caller: if a
 // new caller would be LOOSER without the record, it does not belong here.
 //
-// ── AND IT ANNOUNCES, SO IT CANNOT FIRE UNNOTICED WHERE IT MUST NOT ──────────────────────────────
+// ── NO TREE CARRIES THE RECORD TODAY, AND THE MODE LINE SAYS WHICH WAY THAT LEANS ───────────────
+//
+// This block used to say the record exists here and that losing it "would quietly relax five checks".
+// Both halves were false, and the second contradicted the paragraph above it. Measured 2026-09-09:
+// `CUT_RECORD_PRESENT` is false here and false in the larger tree the suite is also run against — the
+// record exists in neither, so every reader has always run in fallback, and fallback is the strict side.
+//
+// The mode is still announced once to stderr, the way `announceBlocklistMode` does for the identifier
+// roster. What the line may NOT do is call itself an alarm: this module can see whether the record is
+// present, and cannot see whether it ought to be. So it states the mode and what that means for the
+// three readers, and leaves the judgement to a reader who knows which tree they are looking at.
 //
-// On our tree the record exists and behaviour is unchanged. If it ever went missing here, the fallback
-// would quietly relax five checks — the exact silent-pass this repository keeps paying for. So the mode
-// is announced once to stderr, the way `announceBlocklistMode` does for the identifier roster, and an
-// arm pins that the announcement happens.
+// NOTHING PINS THIS ANNOUNCEMENT, and this block used to claim something did. Measured 2026-09-09: no
+// test in either repository imports `announceWithheldMode` or asserts its line, so the wording above is
+// held by nothing and a silent removal of it would pass. That gap is filed rather than fixed here,
+// because closing it adds a test file and this change is comment text only.
 
 let record = null;
 try {
@@ -59,15 +76,16 @@ export const isWithheld = (relPath) => (record ? record.isWithheld(relPath) : fa
 
 let announced = false;
 /**
- * Say which mode this process is in, once, to stderr. A green run in fallback mode on a tree that
- * SHOULD carry the record is five checks quietly relaxed, and the only thing standing between that and
- * silence is this line.
+ * Say which mode this process is in, once, to stderr. Fallback is the strict side, so this line is a
+ * statement of fact rather than a warning: it reports what the three readers will do, and whether that
+ * is right depends on the tree, which this module cannot see.
  */
 export function announceWithheldMode() {
   const line = CUT_RECORD_PRESENT
     ? `[repo-guard] cut record present — ${WITHHELD.length} withheld entry/entries; absences they cover are stated consequences`
-    : "[repo-guard] NO cut record in this tree — nothing counts as withheld, so every absence is damage "
-      + "and every citation must resolve. This is correct on the published tree and an ALARM anywhere else.";
+    : "[repo-guard] no cut record in this tree — nothing counts as withheld, so every absence is damage "
+      + "and every citation must resolve. This is the STRICTER of the two modes: it cannot hide a defect, "
+      + "and it is the expected mode wherever nothing was withheld from the tree in hand.";
   if (!announced) { announced = true; console.error(line); }
   return line;
 }

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.