clearotron 0.2.0 → 0.2.2

package/driver/skills/knockout-assess/SKILL.md

@@ -162,9 +162,14 @@ your job. These two fields are how what you concluded reaches the reader instead
 every id against that store and refuses one it does not hold — so the report can state a filing's
 source as a fact rather than as a word you typed about your own sourcing.
 
-- **`registerReads`** — on the MARK. Rows of `{recordId, read}` for a filing you weighed that did **not**
-  become a `findings[]` record. `read` is what you concluded about *that* filing: whether it bears on the
-  rating, and why. It prints on that filing's card.
+- **`registerReads`** — on the MARK. Rows of `{recordId, read, band?}` for a filing you weighed that did
+  **not** become a `findings[]` record. `read` is what you concluded about *that* filing: whether it bears
+  on the rating, and why. It prints on that filing's card. `band` is **optional** and is how you rate that
+  filing on its own — in the framework's band words, the same vocabulary as the mark's rating. Send it
+  whenever you formed a view on the filing itself: a registered right is often the one hard legal fact on
+  the page, and with no band its card is the only one carrying no rating while softer uses around it carry
+  one, which reads as though the registration mattered least. Omit it and the read still prints, claiming
+  no rating.
 - **`weighedFilings`** — on a FINDING. The `recordId`s whose evidence your reasoning for that conflict
   actually used. The report derives the finding's source labelling from this, so list one only if you
   reasoned from it.
@@ -205,7 +210,8 @@ line, which describes the card and claims nothing about the rating. So:
                "classesDriving": [8], "bullets": ["..."], "purpleNotes": ["..."],
                "registerEstimate": "...", "parodyNote": null, "crowdedField": false,
                "registerReads": [ { "recordId": "<verbatim from the filings you were given>",
-                                    "read": "<what you concluded about THAT filing>" } ],
+                                    "read": "<what you concluded about THAT filing>",
+                                    "band": "<OPTIONAL — your rating of THAT filing, in the ladder's words>" } ],
                "basis": "<ONE sentence: why this band, for this name, in these classes>",
                "factors": ["<2-4 load-bearing observations, one line each>"],
                "counterFactors": ["<1-3: what holds it at this band rather than the next>"],

package/driver/skills/prelim-search/SKILL.md

@@ -26,7 +26,7 @@ description: Orchestrator for preliminary trademark search requests with registe
 
 ## Spawned session
 
-This file is the **driver's compute orchestration spec** — it lives in `driver/skills/` (co-located with the driver) and is read by the pipeline stages, NOT by the integrator agent. The integrator's prelim role is only **intake** (recognise the request, resolve the client, submit the job — `../../docs/INTAKE.md`) and **delivery** (courier the outbox packets — `../../docs/DELIVERY.md`); everything between is the driver's.
+This file is the **driver's compute orchestration spec** — it lives in `driver/skills/` (co-located with the driver) and is read by the pipeline stages, NOT by the integrator agent. The integrator's clearotron role is only **intake** (recognise the request, resolve the client, submit the job — `../../docs/INTAKE.md`) and **delivery** (courier the outbox packets — `../../docs/DELIVERY.md`); everything between is the driver's.
 
 This workflow is run by the **deterministic driver** (`driver/`): an intake path (the `enqueue` CLI or the ops-MCP `start_run` tool) enqueues a job and the driver invokes each stage as a standalone compute turn (the `anthropic-agent` engine — a headless `claude -p` process off the gateway; sequencing, fan-in, gating, retries all in code). The judgment content + companion files below are what the stages read; the driver passes each stage its run-dir paths + the job context (email message id, forwarder, instructions, mark names).
 
@@ -58,7 +58,7 @@ reads only their compact findings files. This is the workflow's primary cost con
 
 ## Trigger
 
-The requesting or reviewing lawyer forwards an email containing a **Trademark Search Request Form** to the intake mailbox. The forwarded email is typically structured as a request form ("Worldwide preliminary trademark search — TMP<n>", "Please run this through a preliminary search", or similar). When the request is recognisable as a prelim search ask, this skill invokes.
+The requesting or reviewing lawyer forwards an email containing a **Trademark Search Request Form** to the intake mailbox. The forwarded email is typically structured as a request form ("Worldwide preliminary trademark search — TMP<n>", "Please run this through a preliminary search", or similar). When the request is recognisable as a clearotron search ask, this skill invokes.
 
 ## Register sources — the vendor is the source of truth; EUIPO is a free EU cross-check
 

package/driver/skills/prelim-search/template-formatting.md

@@ -1,4 +1,4 @@
-# Prelim Template — HTML Formatting Spec
+# Clearotron Template — HTML Formatting Spec
 
 > **THIS FILE IS HALF LIVE, AND THE HALVES HAVE DIFFERENT READERS. Check which half you are in before
 > you trust a line.**

package/driver/skills/prelim-search/templates/email/generic.md

@@ -20,7 +20,7 @@ The email body has these blocks, in this order:
 
 > "Hi [first name from request],
 >
-> Prelim for [mark name] complete — findings below; full audit Excel attached."
+> Clearotron for [mark name] complete — findings below; full audit Excel attached."
 
 (For internal test runs, use "Hi [forwarder first name]" and add a one-line context note: "v[N] test run — replied to you only, not forwarded to [client].")
 

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

@@ -5,7 +5,7 @@
   synthesis-rules.md.
 -->
 
-# Prelim synthesis — gold-standard worked examples
+# Clearotron synthesis — gold-standard worked examples
 
 ## Contents
 

package/driver/skills/prelim-variants/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: prelim-variants
-description: Shared strategy + variant generation for the v3 preliminary trademark search workflow. **Invoked exclusively by the `prelim-search` orchestrator** as the first stage of any v3 prelim run — do not call directly. Classifies the proposed mark into one of six analytical archetypes, derives a risk theory from that classification, then generates the variant set whose axes are shaped by the archetype. Emits a markdown variant manifest consumed by both common-law (`prelim-common-law`) and register (`prelim-register`) execution skills.
+description: Shared strategy + variant generation for the v3 preliminary trademark search workflow. **Invoked exclusively by the `prelim-search` orchestrator** as the first stage of any v3 clearotron run — do not call directly. Classifies the proposed mark into one of six analytical archetypes, derives a risk theory from that classification, then generates the variant set whose axes are shaped by the archetype. Emits a markdown variant manifest consumed by both common-law (`prelim-common-law`) and register (`prelim-register`) execution skills.
 ---
 
 ## Contents
@@ -27,7 +27,7 @@ Companion files:
 
 ## Trigger
 
-Called by `prelim-search` at the start of any prelim run. Not invoked directly.
+Called by `prelim-search` at the start of any clearotron run. Not invoked directly.
 
 ## Model
 

package/driver/stage-context.mjs

@@ -92,7 +92,7 @@ const DECLARED_KIND = {
     // — the placement form is CONTEXT, and deliberately NOT a freshness input. The driver writes it
     // before dispatch and rewrites it after every judgement (the union runs on each one), so it is always
     // newer than the md the seat just wrote — and adding it to stageInputs would make the largest stage in
-    // the run read stale on every resume and re-dispatch itself. 's ruling exactly: the fix is a
+    // the run read stale on every resume and re-dispatch itself. That ruling exactly: the fix is a
     // second view, not a wider freshness list.
     placementForm: ["driver-side",
       "written by the driver before dispatch and re-unioned on every judgement; the prompt names the path because the seat writes its selections there"],

package/driver/stages-knockout.mjs

@@ -5,7 +5,7 @@
 // kept in its OWN table: the knockout lane is a different product shape (a 5–15 mark triage batch), and
 // its stages must never leak into the clearance STAGE_ORDER. New-named stages get [] MCP tool groups
 // automatically (gather-config prefix map — the matter-frame precedent), so frame/assess run lean.
-import { existsSync } from "node:fs";
+import { existsSync, readFileSync } from "node:fs";
 import { join } from "node:path";
 import { driverDir } from "../shared/driver-dir.mjs";   //
 import { validators as koValidators } from "./verify-knockout.mjs";
@@ -19,6 +19,30 @@ export { kebab };   // one definition (search-policy) — re-exported for the la
 const lines = (...xs) => xs.filter(Boolean).join("\n");
 const reads = (skillReads) => `First, read and follow exactly: ${skillReads.join(", ")}.`;
 
+/**
+ * One line per owner the driver looked up, for the assess dispatch (tracker issue 276).
+ *
+ * BOTH OUTCOMES ARE NAMED, and that is the point. A row whose search answered gets its payload path; a
+ * row whose search did NOT answer says so in the dispatch itself. Listing only the answered ones would
+ * leave the seat unable to tell "nobody searched this owner" from "the search found nothing", and those
+ * two license completely different reads — the second is a fact about the owner's visibility, the first
+ * is a gap the seat would fill by inferring from the name, which is the defect this whole issue is about.
+ *
+ * Returns [] when the lane did not run or the store is unreadable, so the dispatch simply omits the block
+ * rather than naming a path that is not there.
+ */
+export function ownerCheckLines(K) {
+  let doc = null;
+  try { doc = existsSync(K.ownerChecks) ? JSON.parse(readFileSync(K.ownerChecks, "utf8")) : null; } catch { doc = null; }
+  const checks = Array.isArray(doc?.checks) ? doc.checks : [];
+  return checks.map((c) => {
+    const who = `${c.owner} (proprietor of a filing for ${c.mark})`;
+    return c.ok && c.payloadFile
+      ? `- ${who}: ${join(K.runDir, "research", c.payloadFile)}`
+      : `- ${who}: THE SEARCH RETURNED NOTHING. Say so in the read; do not infer the trade from the name.`;
+  });
+}
+
 // ── Paths (knockout-own; beside the standard _driver sidecars) ───────────────────────────────────────
 export function koPaths(runDir) {
   return {
@@ -39,10 +63,15 @@ export function koPaths(runDir) {
     // rows were left exactly as they were rather than gaining a matching marker: their shape is pinned
     // byte-for-byte by register-count.test.mjs, and a discriminator only one side needs is enough.
     registerRecords: driverDir(runDir, "register-records.json"),
+    // The scoped owner lookups this run owes its promoted filings, and their receipts (tracker issue
+    // 276). Both under `_driver/` because both are the DRIVER's own measurement of a call it made — the
+    // rule stated fourteen lines above. The seat reads the payloads under research/, never these.
+    ownerChecks: driverDir(runDir, "owner-checks.json"),
+    ownerCheckLedger: driverDir(runDir, "owner-check.jsonl"),
     researchDir: join(runDir, "research"),
     research: (markKebab) => join(runDir, "research", `${markKebab}.md`),
     sweepLedger: driverDir(runDir, "knockout-sweep.jsonl"),
-    // 's SHAPE, APPLIED: the WORK MOVES OUT OF THE GUARDED TREE — the hook is never weakened.
+    // That SHAPE, APPLIED: the WORK MOVES OUT OF THE GUARDED TREE — the hook is never weakened.
     //
     // This chunk is a MODEL OUTPUT, and it sat under `_driver/` in flat contradiction of the rule stated
     // fourteen lines above: those files "are the driver's own measurements, NEVER a model's output". So
@@ -289,6 +318,28 @@ export const KO_STAGES = {
       existsSync(K.registerRecords)
         ? `THE REGISTER FILINGS THIS RUN ALREADY FETCHED — ${K.registerRecords}. Real records, retrieved before you started: owner, jurisdiction, status, classes, dates. Read them and WEIGH them for the marks you are rating. A registration on this list is evidence about the name it names — treat its owner, its scope and its vulnerability the way the firm-wide reasoning tells you to (revocability above the lowest band; an enforcer's portfolio profile; a crowd as a mitigant under its gating precondition). What you may NOT do is describe the lane that fetched them — see the coverage rule below.`
         : "",
+      // ── WHAT THE OWNER ACTUALLY SELLS, ALREADY SEARCHED (tracker issue 276) ────────────────────────
+      //
+      // The defect this closes is not that the seat lacked an instruction — it is that the seat had no
+      // way to know. It was handed an owner's NAME and its class numbers and nothing else, so a read
+      // about what that owner sells could only ever be an inference from the string. The driver now runs
+      // the scoped query before this stage and hands the answer over.
+      //
+      // ORDERED, NOT OFFERED. Naming a payload the seat may read is what produces "read and not applied,
+      // no refusal" — a rule that names a downstream effect rather than the field the seat writes. This
+      // names the field: the read on that filing's registerReads row.
+      //
+      // AND THE NEGATIVE CASE IS ORDERED TOO, because it is the one that produced the original defect:
+      // where the lookup did not answer, the honest sentence is that it did not, NOT a fresh inference
+      // from the owner's name dressed as a finding.
+      ownerCheckLines(K).length
+        ? [
+          `WHAT THESE OWNERS ACTUALLY SELL — the driver ran ONE scoped web search per promoted filing's proprietor BEFORE this stage, so you are not guessing from the company name. Payloads:`,
+          ...ownerCheckLines(K),
+          `USE THEM. When you write a registerReads row for one of these filings, your "read" must state what the owner actually sells ACCORDING TO THAT PAYLOAD, not what the company's name suggests and not what its class numbers imply. An owner's name is not evidence of its trade. A company name that reads as a line of business is a guess that happens to land sometimes, and the run where it lands is indistinguishable from the run where it does not — which is the reasoning this rule exists to stop.`,
+          `WHERE A PAYLOAD SAYS THE SEARCH FOUND NOTHING, say that plainly in the read — "a search for the proprietor's trade returned nothing" — and reason from the register record alone. Do NOT substitute an inference from the owner's name for the answer the search did not give. The report prints the source line itself, from the driver's own record of the call, so you never type a URL and never need to.`,
+        ].join("\n")
+        : "",
       // ── THE READ REACHES THE PAGE ────────────────────────────────────────────
       //
       // Until now nothing this seat concluded about an INDIVIDUAL filing could reach a reader. A filing
@@ -301,7 +352,7 @@ export const KO_STAGES = {
       // a finding with no register evidence. Omitting either field is always safe: the card keeps its
       // neutral line, which describes the card and is true.
       existsSync(K.registerRecords)
-        ? `WHEN YOU WEIGH ONE OF THOSE FILINGS, SAY SO BY ITS OWN ID — copy "recordId" verbatim from the file above. "registerReads" on the MARK: rows of {recordId, read} for a filing you weighed that did NOT become a findings[] record; "read" is what you concluded about THAT filing — whether it bears on the rating and why — and it prints on that filing's card in the reader's own report. "weighedFilings" on a FINDING: the recordIds whose evidence your reasoning for that conflict actually used, because the report derives that finding's source labelling from it. Both are optional and both are joined against the filings you were given, so an id we do not hold is refused by name. A filing you did not weigh simply gets no row: do not invent a read to fill one, and never write "not weighed" as a read.`
+        ? `WHEN YOU WEIGH ONE OF THOSE FILINGS, SAY SO BY ITS OWN ID — copy "recordId" verbatim from the file above. "registerReads" on the MARK: rows of {recordId, read, band?} for a filing you weighed that did NOT become a findings[] record; "read" is what you concluded about THAT filing — whether it bears on the rating and why — and it prints on that filing's card in the reader's own report. "band" is OPTIONAL and is your rating of THAT filing on its own, in the framework's band words: send it whenever you formed a view on the filing itself, because a registered right left unbanded is the only card on the page with no rating while softer uses beside it carry one, which reads as though the registration mattered least. Omit it and your read still prints, claiming no rating. "weighedFilings" on a FINDING: the recordIds whose evidence your reasoning for that conflict actually used, because the report derives that finding's source labelling from it. Both are optional and both are joined against the filings you were given, so an id we do not hold is refused by name. A filing you did not weigh simply gets no row: do not invent a read to fill one, and never write "not weighed" as a read.`
         : "",
       `A DEGRADED mark's row must carry degraded:true and the purple "Manual verification recommended"`,
       `note; a mark WITH a payload must never claim degraded (the validator joins both against the disk).`,
@@ -414,7 +465,7 @@ export const KO_STAGES = {
       `IT IS THE SHORTER DIGEST ABOVE THE PER-MARK ASSESSMENTS, not a rival to them. A reader opens this`,
       `to decide which name to read about; the mark's own page is where the full read lives. Keep it`,
       `tighter than any one mark's assessment.`,
-      // ── THE RETURN IS A CALL, NOT A FILE (, item B) ────────────────────────────
+      // ── THE RETURN IS A CALL, NOT A FILE (item B) ────────────────────────────
       //
       // THE DISPATCH NAMES NO PATH, and on this stage that is not merely the house pattern. This seat
       // spent 2026-08 writing its chunk through a Bash redirect because the Write tool was already