npm - clearotron - Versions diffs - 0.2.1 → 0.3.0-beta.0 - Mend

clearotron 0.2.1 → 0.3.0-beta.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (45) hide show

package/INSTALL.md +5 -4
package/bin/example.mjs +9 -5
package/bin/onboard.mjs +19 -19
package/bin/stop.mjs +65 -3
package/build-info.json +2 -2
package/driver/CHANGELOG.md +21 -0
package/driver/declination-call.mjs +32 -0
package/driver/driver.config.mjs +20 -0
package/driver/engine/mcp/recording-server.mjs +4 -0
package/driver/gateway.mjs +8 -3
package/driver/knockout-assess-record.mjs +5 -1
package/driver/package.json +1 -1
package/driver/pipeline.mjs +83 -2
package/driver/predelivery-lint.mjs +22 -4
package/driver/publish/knockout.mjs +12 -6
package/driver/publish/render-knockout.mjs +133 -23
package/driver/publish/report-data.mjs +13 -3
package/driver/record-carry.mjs +2 -2
package/driver/reference-score.mjs +1 -1
package/driver/result-noun-fields.mjs +7 -0
package/driver/skills/knockout-assess/SKILL.md +10 -4
package/driver/stages-knockout.mjs +1 -1
package/driver/stages.mjs +1 -1
package/driver/suite-census.json +66 -18
package/driver/unit-inventory.mjs +47 -0
package/driver/unit-state-verdict.mjs +8 -8
package/driver/verify-knockout.mjs +9 -1
package/driver/whatif-memo-run.mjs +45 -4
package/mcp-server/CHANGELOG.md +2 -0
package/mcp-server/lib/brief.mjs +15 -0
package/mcp-server/lib/driver.mjs +6 -0
package/mcp-server/lib/knockout.mjs +435 -0
package/mcp-server/lib/scrub.mjs +1 -1
package/mcp-server/package.json +1 -1
package/mcp-server/server.mjs +69 -4
package/package.json +1 -1
package/portal-ui/package.json +1 -1
package/providers/oauth-mcp-bridge/CHANGELOG.md +2 -0
package/providers/oauth-mcp-bridge/package.json +1 -1
package/scripts/drain-preflight.mjs +2 -2
package/scripts/freeze-example-run.mjs +3 -3
package/scripts/headless-page.mjs +51 -2
package/scripts/live-surface-check.mjs +86 -17
package/scripts/render-check.mjs +61 -2
package/scripts/deploy-test.sh +0 -309

package/driver/predelivery-lint.mjs CHANGED Viewed

@@ -2454,6 +2454,13 @@ export function flagLines(failures) {
 // vendor vocabulary, no ids, no paths, no field names, no instructions to whoever regenerates the run,
 // never "certified"/"signed". deliveryVocabViolations() below enforces that mechanically.
 const DELIVERY_LINES = {
+  // Keyed on the FULL check id, which deliveryFlagLines resolves before the base — see the note there.
+  // The sentence states the CONSEQUENCE, in the receipt's own terms: not "a check failed" but "the rule
+  // was applied to nothing". Eleven graded runs delivered carrying this, two of them orderable product
+  // demos, and the only place it was written was one row of a fifty-odd-row receipt nobody routes.
+  "narrative-write-ups:could-not-read":
+    "The depth rules for the written-up findings were applied to nothing on this run — the narrative "
+    + "carries no block this check can read, so neither the ranking cut nor the length cap was verified.",
   // template — the summary table against the names actually searched
   "names-cell-populated": "The summary table does not name the mark that was searched.",
   "assessment-row": "A searched name has no assessment of its own in the summary table.",
@@ -2555,15 +2562,26 @@ export function deliveryVocabViolations(line) {
 export function deliveryFlagLines(failures) {
   const groups = new Map();
   for (const f of failures ?? []) {
-    const base = String(f?.id ?? "").split(":")[0];
+    const id = String(f?.id ?? "");
+    const base = id.split(":")[0];
     const family = String(f?.family ?? "");
-    const key = base || `family/${family}`;
-    const g = groups.get(key) ?? { base, family, n: 0 };
+    // A CHECK WHOSE DISTINCTION LIVES IN ITS SUFFIX COULD NOT BE SAID HERE (tracker issue 267).
+    //
+    // Grouping on `base` alone is right for the common case — a word-cap violation on nine write-ups is
+    // one delivery line, not nine. But it also collapsed `narrative-write-ups:could-not-read` into the
+    // same bucket as an ordinary depth violation, and those are different facts: one says a rule was
+    // broken, the other says the rule was ENFORCED ON NOTHING. The second had no sentence of its own to
+    // reach, so it degraded to the generic "a machine check did not pass" and became invisible.
+    //
+    // So: an entry keyed on the FULL id wins where one exists, and everything else groups by base
+    // exactly as before. This adds no line to any run that did not already produce one.
+    const key = DELIVERY_LINES[id] ? id : (base || `family/${family}`);
+    const g = groups.get(key) ?? { base, family, id: DELIVERY_LINES[id] ? id : null, n: 0 };
     g.n += 1;
     groups.set(key, g);
   }
   return [...groups.values()].map((g) => {
-    const sentence = DELIVERY_LINES[g.base] ?? DELIVERY_FAMILY_LINES[g.family] ?? DELIVERY_GENERIC;
+    const sentence = (g.id && DELIVERY_LINES[g.id]) ?? DELIVERY_LINES[g.base] ?? DELIVERY_FAMILY_LINES[g.family] ?? DELIVERY_GENERIC;
     // Belt and braces: a table entry that trips the house rules degrades to the generic instead of
     // shipping. This is what makes "no engine vocabulary reaches a reader" structural rather than a
     // matter of everyone remembering the rule when they add a check.

package/driver/publish/knockout.mjs CHANGED Viewed

@@ -68,9 +68,13 @@ export const knockoutStatement = (framework, marks) =>
 // 11pt, no <!DOCTYPE>, no <head>, no <meta charset> — and they rendered a Depth 2 report as a grey
 // spreadsheet with the register hit-counts the customer paid for buried in a table cell. The report now
 // renders through publish/render-knockout.mjs in the product's own design language, off the same shared
-// stylesheet and brand tokens as the clearance report. Internal working material (the purple staff notes,
-// the model's registerEstimate) is not stripped from the report — it is not IN the report; it lives in
-// the audit workbook, which is what an internal artifact is for.
+// stylesheet and brand tokens as the clearance report.
+//
+// THE REVIEWER'S NOTES ARE ON THE REPORT SINCE 2026-09-07 (owner ruling, tracker issue 274). This
+// paragraph used to end "internal working material (the purple staff notes, the model's registerEstimate)
+// is not IN the report; it lives in the audit workbook". That is now true of `registerEstimate` only: the
+// notes render on the page, labelled, and the workbook keeps its copy. See render-knockout.mjs's header
+// for the ruling and reviewerNotesBlock for the shape.
 // ── The workbook: the skill's three sheet names + columns, plus the conditional sheets below ────────
 // ── ONE DRILL-THROUGH KEY: `<MARK> #<ordinal>`, per mark ──────────────────────────────────────
@@ -250,9 +254,11 @@ export async function buildKnockoutWorkbook(findings, receipts, outPath, registe
 // ── The email: a COVER NOTE. Headline band, one line per mark, the report link. Nothing else. ────────
 // The report is the deliverable and the email points at it — the same doctrine the clearance lane
 // follows. The old `delivery.email === 'table'` overlay inlined the full review table into the mail
-// body, and it inlined the INTERNAL variant: purple staff notes and the model's register estimate went
-// out over the wire to whoever the mail reached. A second rendering of the findings in a second dialect
-// is also a second thing to keep true. Per-lawyer client formatting is drafted by the assistant from the
+// body, which put the findings in front of whoever the mail reached rather than whoever opened the
+// report, and made a second rendering of them in a second dialect — a second thing to keep true.
+// (That overlay's other charge, that it shipped an INTERNAL variant, no longer describes anything: the
+// 2026-09-07 ruling put the reviewer's notes on the one report. The reason above is the load-bearing one
+// and it is unaffected — the mail stays a cover note.) Per-lawyer client formatting is drafted by the assistant from the
 // run's report-data.json, not by a template knob in here.
 // `reports` is publishKnockout's own list — `[{mark, url}]`, one per published document — and
 // `auditUrl` is composed by the publisher from the pool URL it already holds. Neither is derived here.

package/driver/publish/render-knockout.mjs CHANGED Viewed

@@ -21,10 +21,20 @@
 // ~60 lines of duplicated document shell, and it is the right price: the alternative is exporting the
 // shell out of the frozen file, which is a bigger break than the duplication saves.
 //
-// ONE report. There is no client variant and no internal variant. What used
-// to render purple — the staff notes and the model's register estimate — is not stripped here, it is
-// simply NOT PART OF THE REPORT; it lives in the audit workbook, which is where internal working material
-// belongs. That removes the whole class of "the wrong link got sent".
+// ONE report. There is no client variant and no internal variant, and that is
+// still the rule — it is what removes the whole class of "the wrong link got sent".
+//
+// WHAT CHANGED, 2026-09-07 (owner ruling, tracker issue 274): the one report now CARRIES the reviewer's
+// notes rather than routing them to the audit workbook alone. The earlier reading of "one report" was
+// that internal working material is simply not part of it; the ruling is that there is one report and the
+// person who ran Clearotron reads it, so holding material back "just adds confusion for where data is
+// lost". Six notes written for the reviewing lawyer on a delivered run reached the spreadsheet and
+// nothing else, which is the measurement behind the ruling.
+//
+// So: the notes render, LABELLED, in report.css's existing `.internal` purple convention (see
+// reviewerNotesBlock) — never merged into the client-voiced body. The workbook keeps them as well; this
+// added a surface and moved none. The model's `registerEstimate` is NOT covered by the ruling and stays
+// off the page.
 import { readFileSync } from 'node:fs';
 import { join, dirname } from 'node:path';
 import { fileURLToPath } from 'node:url';
@@ -176,6 +186,14 @@ const KO_CSS = `
   .ko-findev{margin:0;font-size:12.5px;line-height:1.6;word-break:break-word}
   .ko-count{font-family:var(--mono);font-size:13px;color:var(--ink);margin:0}
   .ko-degraded{font-size:13px;color:var(--med-tx,#82550A);margin:8px 0 0;font-style:italic}
+  /* The reviewer-notes legend. NOT .ko-legend — that name is taken by the framework attribution row
+     above, and reusing it would restyle the caption. It names the purple convention report.css already
+     draws for .internal, so the colour is stated once and never re-specified. */
+  .ko-refnote{margin:0;padding:11px 24px 0;font-size:12px;color:#6a2b6e;font-style:italic}
+  /* The notes sit inside a mark's column, so the shared .internal block's bullets keep the column's
+     own list indent and do not fight the paragraph above them. */
+  .ko-row .internal .ko-bul{margin:0 0 4px}
+  .ko-row .internal .ko-bul:last-child{margin-bottom:0}
   .ko-counts table{width:100%;border-collapse:collapse;font-size:14px}
   .ko-counts th{text-align:left;font-size:10.5px;letter-spacing:.06em;text-transform:uppercase;color:var(--faint);
     font-weight:700;padding:14px 24px 8px;border-bottom:1px solid var(--line)}
@@ -728,9 +746,13 @@ function registerCardViews(mark, framework, registerRecords) {
  * is gone; what tells the two apart on the page is where the finding came from, which is the vocabulary
  * the clearance reports already use for exactly this.
  *
- * NO BAND CHIP AND NO `bandStop`, still, and for the reason the old note gave: a rung of the run's ladder
- * here would be a rating nobody performed. The rail takes --faint so the card reads off the risk ramp
- * rather than on it.
+ * THE BAND CHIP IS DRAWN ONLY WHEN THE RATER SENT ONE, and that condition is the whole rule. The old note
+ * here said "no band chip and no `bandStop`, ever: a rung of the run's ladder would be a rating nobody
+ * performed" — which was true for as long as nothing could carry the rater's rating of an individual
+ * filing. `registerReads[].band` now can (tracker issue 274), so the objection is answered where it was
+ * raised: with a band, the rating WAS performed, by the seat, in the framework's own words, and the chip
+ * states it. With no band the old rule stands unchanged — --faint rail, no chip, nothing claimed — and
+ * that is still what every archived run renders.
  *
  * THE LINE UNDER THE STATEMENT DESCRIBES THE CARD, NOT THE RATING. It used to deny
  * that the rating turned on this filing, which this function has no way to know and which a delivered
@@ -759,24 +781,56 @@ function sourceChips(v) {
   return `${commonLaw ? '<span class="src cl">Common law</span>' : ''}${register ? '<span class="src reg">Register</span>' : ''}`;
 }
-function registerFindingBlock(v, markIndex, reads = null) {
+// ── THE REVIEWER'S NOTES, ON THE REPORT ─────────────────────────────────────────────────
+//
+// OWNER RULING, 2026-09-07: there is one report and the person who ran Clearotron reads it — keeping
+// this material off the page "just adds confusion for where data is lost". This replaces the earlier
+// split under which the notes went to the audit workbook alone (the header of this file and
+// publish/knockout.mjs carried that rule; both now say what replaced it). The workbook keeps them too:
+// this adds a surface, it does not move one.
+//
+// LABELLED, NEVER MERGED. They render in the established `.internal` purple convention report.css
+// already defines — the same one the clearance report uses for this material — so a reader can see whose
+// voice a line is in. Merging them into the client-voiced body would make the reviewer's asides read as
+// findings about the mark, which is the one way this ruling could produce a worse document.
+const REVIEWER_NOTES_LEGEND = 'Information for your reference/context that likely does not need to be shared with the business is shown in purple.';
+function reviewerNotesBlock(m) {
+  const notes = (Array.isArray(m?.purpleNotes) ? m.purpleNotes : [])
+    .map((n) => String(n ?? '').trim()).filter(Boolean);
+  if (!notes.length) return '';
+  return `<div class="internal">
+            <span class="tag">For your reference</span>
+            ${notes.map((n) => `<p class="ko-bul">${inlineMd(n)}</p>`).join('')}
+          </div>`;
+}
+function registerFindingBlock(v, markIndex, reads = null, framework = null) {
   const r = v.record;
   // — THE RATER'S OWN READ OF THIS FILING, when it recorded one. `registerReads` is
   // joined to the record store by the validator, so a row that reaches here names a filing this run
   // actually holds. With no row the neutral line stands, and the neutral line is TRUE: it describes the
   // card. That is why the field can be optional without the page ever asserting something false.
-  const read = (Array.isArray(reads) ? reads : [])
-    .map((x) => ({ id: String(x?.recordId ?? '').trim(), text: String(x?.read ?? '').trim() }))
-    .find((x) => x.id && x.id === String(r?.recordId ?? '').trim())?.text;
+  const row = (Array.isArray(reads) ? reads : [])
+    .map((x) => ({ id: String(x?.recordId ?? '').trim(), text: String(x?.read ?? '').trim(), band: String(x?.band ?? '').trim() }))
+    .find((x) => x.id && x.id === String(r?.recordId ?? '').trim());
+  const read = row?.text;
+  // The band rides the SAME row as the read and is independently optional: a read with no band prints
+  // exactly as it did before this field existed. The validator has already checked the word against the
+  // frozen ladder, so `bandStop` resolves a real stop rather than falling through to a default that would
+  // colour an unknown word as though it were rated.
+  const band = row?.band || null;
+  const stop = band ? bandStop(framework, band) : null;
   const meta = [r.owner ? esc(r.owner) : 'proprietor not stated', r.territory ? esc(r.territory) : null]
     .filter(Boolean).join(' · ');
   const receipt = isHttpUrl(r.url) ? linkOrText(r.url) : esc(r.recordId ?? 'no record address supplied');
   return `<div class="card ko-find" data-ko-mark="${Number(markIndex)}" data-ko-ord="${Number(v.ordinal)}">
         <div class="top">
-          <div class="rail" style="background:var(--faint)"></div>
+          <div class="rail" style="background:var(${stop ?? '--faint'})"></div>
           <div class="body">
             <div class="cardhead">
-              <span class="fnum">${esc(v.ref)}</span><span class="who">${esc(r.mark ?? 'Unnamed filing')}</span><span class="src reg">Register</span>
+              <span class="fnum">${esc(v.ref)}</span><span class="who">${esc(r.mark ?? 'Unnamed filing')}</span>${
+    band ? `<span class="ko-findband" style="background:var(${stop})">${esc(band)}</span>` : ''}<span class="src reg">Register</span>
             </div>
             <p class="ko-findmeta">${meta}</p>
             <p class="ko-findnet">${esc(v.statement)}</p>
@@ -925,7 +979,7 @@ function analysisSection(marks, framework, { registerCounts = null, probeRan = f
     // under compareKnockoutBlockingPower, so appending them is the ladder's own rule applied to a row
     // that has no rung, not a new one invented for the register.
     const reg = registerCardViews(m, framework, registerRecords);
-    const regBlocks = reg.cards.map((v) => registerFindingBlock(v, markIndex, m?.registerReads)).join('');
+    const regBlocks = reg.cards.map((v) => registerFindingBlock(v, markIndex, m?.registerReads, framework)).join('');
     const overflow = reg.promoted > reg.cards.length
       ? `<p class="ko-bul">${esc(`${reg.promoted - reg.cards.length} further filing${reg.promoted - reg.cards.length === 1 ? '' : 's'} for this name met the same test — every one of them is in the filings section below.`)}</p>`
       : '';
@@ -950,11 +1004,17 @@ function analysisSection(marks, framework, { registerCounts = null, probeRan = f
       <div>
         ${body || '<p class="ko-bul">No adverse signals recorded for this name on this screen.</p>'}
         ${m.degraded ? `<p class="ko-degraded">${esc(DEGRADED_NOTE)}</p>` : ''}
+        ${reviewerNotesBlock(m)}
         <p class="ko-reg">${esc(registerLine(m, registerCounts, probeRan, registerRecords, reg.cards))}</p>
       </div>
     </div>`;
   }).join('');
-  return `<div class="panel ko-glance">${cards}</div>`;
+  // The legend rides the panel and only when a note is actually on it — a standing sentence explaining a
+  // colour no reader can see would be the report describing a convention it did not use.
+  const anyNotes = marks.some((m) => (Array.isArray(m?.purpleNotes) ? m.purpleNotes : [])
+    .some((n) => String(n ?? '').trim()));
+  const legend = anyNotes ? `<p class="ko-refnote">${esc(REVIEWER_NOTES_LEGEND)}</p>` : '';
+  return `<div class="panel ko-glance">${legend}${cards}</div>`;
 }
 // The method line names EXACTLY what ran, and its wording is doctrine — with counts on the page, "register
@@ -1324,6 +1384,39 @@ export function knockoutReportData(findings, framework, { runId, codename, overa
         classesDriving: m.classesDriving ?? [],
         degraded: Boolean(m.degraded),
         points: m.bullets ?? [],
+        // ── THE ASSESSMENT THE RUN ALREADY WROTE (tracker issue 274) ──────────────────────────────
+        //
+        // Seven keys the assess stage writes into knockout-findings.json reached this file as nothing.
+        // They were not withheld by a rule — no code decided against them; this projection is an explicit
+        // whitelist and nobody had added them, so an assistant drafting from this file could not see the
+        // reasoning behind a rating it was drafting about.
+        //
+        // `assessment` is the sharpest case: publish substitutes it into `batch.executiveSummary` ONLY on
+        // a multi-mark batch, so on a single-mark run — the common knockout — the mark's own opening read
+        // was written, validated, and then dropped by both surfaces at once.
+        //
+        // `purpleNotes` is the reviewer's notes, and it is here by the owner's ruling of 2026-09-07: one
+        // report, read by the person who ran Clearotron, because keeping material off it "just adds
+        // confusion for where data is lost". They are LABELLED on the page rather than merged into the
+        // client-voiced body — see reviewerNotesBlock — so a reader can tell whose voice they are in.
+        assessment: (() => { const t = String(m.assessment ?? '').trim(); return t || null; })(),
+        counterFactors: m.counterFactors ?? [],
+        mitigation: (() => { const t = String(m.mitigation ?? '').trim(); return t || null; })(),
+        // `null`, not `false`, when the rater said nothing: a crowded field is a mitigant the reasoning
+        // turns on, and an unstated one must not read as a stated "no".
+        crowdedField: typeof m.crowdedField === 'boolean' ? m.crowdedField : null,
+        reviewerNotes: m.purpleNotes ?? [],
+        // The proof-of-search rows — the same defensibility record list_searches answers from.
+        negatives: (m.negatives ?? []).map((n) => ({
+          term: n?.term ?? null, source: n?.source ?? null, note: n?.note ?? null,
+        })),
+        // The rater's read of a filing it weighed, keyed by the record id the card prints, so a consumer
+        // can join a read to its filing without matching on prose.
+        registerReads: (m.registerReads ?? []).map((x) => ({
+          recordId: x?.recordId ?? null,
+          read: x?.read ?? null,
+          band: String(x?.band ?? '').trim() || null,
+        })),
         // — the typed finding, ranked, with the reference the report prints. The old key was
         // `evidence[]` and it was `(m.findings ?? []).filter((f) => f?.url)`: a typed finding has no
         // `url`, so this file — the one the assistant drafts client mail from — silently carried zero
@@ -1345,14 +1438,31 @@ export function knockoutReportData(findings, framework, { runId, codename, overa
           //     A promoted filing the brief omitted would be the report and the brief disagreeing about
           //     what the run found.
           //
-          // `band: null` and `shape: 'register'` are the load-bearing fields: a consumer can tell a
-          // weighed conflict from a pointed-at filing without parsing prose, and `net` carries the
-          // not-weighed sentence so a consumer that reads only `net` still cannot overstate it.
-          ...registerCardViews(m, framework, registerRecords).cards.map((v) => ({
-            ref: v.ref, ordinal: v.ordinal, name: v.record.mark, owner: v.record.owner, band: null,
-            type: 'Register filing', net: `${v.statement} It was ${NOT_WEIGHED}.`, basis: NOT_WEIGHED,
-            evidence: v.evidence, shape: 'register',
-          })),
+          // `shape: 'register'` is the load-bearing field: a consumer can tell a weighed conflict from a
+          // pointed-at filing without parsing prose.
+          //
+          // `band` AND `basis` NOW CARRY THE RATER'S READ WHEN IT SENT ONE (tracker issue 274). Before
+          // this, both were constants — `band: null` and the not-weighed sentence — on every filing of
+          // every run, including runs where the seat had written a full read of that exact filing and the
+          // HTML card was already printing it. The page and this file disagreed, and this file is the one
+          // the MCP brief answers from, so the surface a reader asks "what did you make of that
+          // registration?" was the surface that had dropped the answer.
+          //
+          // The unmatched case is unchanged and must stay that way: no row for this recordId ⇒ `band:
+          // null` and the not-weighed line, which describes the card and claims nothing.
+          ...registerCardViews(m, framework, registerRecords).cards.map((v) => {
+            const row = (Array.isArray(m?.registerReads) ? m.registerReads : [])
+              .find((x) => String(x?.recordId ?? '').trim() && String(x?.recordId ?? '').trim() === String(v.record?.recordId ?? '').trim());
+            const read = String(row?.read ?? '').trim() || null;
+            const band = String(row?.band ?? '').trim() || null;
+            return {
+              ref: v.ref, ordinal: v.ordinal, name: v.record.mark, owner: v.record.owner, band,
+              type: 'Register filing',
+              net: read ? v.statement : `${v.statement} It was ${NOT_WEIGHED}.`,
+              basis: read ?? NOT_WEIGHED,
+              evidence: v.evidence, shape: 'register',
+            };
+          }),
         ],
         registerCounts: counted?.counts
           ? {

package/driver/publish/report-data.mjs CHANGED Viewed

@@ -4,9 +4,19 @@
 // report-data.json since the one-report collapse; the clearance lane's native-render branch existed in
 // the portal with NO producer anywhere (B3's "the aspirational path") — this is that producer.
 //
-// Two readers, one file (the knockout doctrine, verbatim): the assistant drafts client-facing mail from
-// it, and the portal's native-render path reads it instead of iframing baked HTML. It is the CLIENT CUT
-// by construction, not by serve-time stripping:
+// Two readers, one file (the knockout doctrine, as it stood): the assistant drafts client-facing mail
+// from it, and the portal's native-render path reads it instead of iframing baked HTML.
+//
+// THE TWO LANES DIVERGED ON 2026-09-07 AND THIS FILE DID NOT MOVE. The owner ruled (tracker issue 274)
+// that the KNOCKOUT report carries the reviewer's notes, on the ground that one report is read by the
+// person who ran Clearotron and holding material back confuses where data went; render-knockout.mjs
+// projects them under `reviewerNotes`. That ruling was about those notes on that lane. It did not touch
+// what this producer strips — withdrawn findings, verification receipts, `::p::` tails, `[internal]`
+// labels and engine-internal narration are all still cut here, and the guard test still polices them.
+// Do not read the knockout change as licence to relax this list; if the ruling is meant to extend, it
+// extends by being asked, not by inference.
+//
+// It remains the CLIENT CUT by construction, not by serve-time stripping:
 //   • only LIVE findings (a withdrawn finding renders nowhere — it does not exist here either);
 //   • no verification receipts (use_check / own_rights / bears_on — those are the reviewer's evidence
 //     trail and live in the audit workbook), no withdrawn_reason, no quarantine records;

package/driver/record-carry.mjs CHANGED Viewed

@@ -840,7 +840,7 @@ export function silentlyLostFindings({ reconciliation = null, carryRows = null,
  * It also anticipated this gap in writing: "nine divergences from a digest finding-ending, every one of
  * them `step-stated`". Nine of the shape nothing checked.
  *
- * MEASURED ON R2 `russet-kestrel`, delivered 2026-09-06. The sibling ran and reported
+ * MEASURED ON A DELIVERED R2 RUN, 2026-09-06. The sibling ran and reported
  * `{checked:5, matched:5, lost:0}` — correctly. On that same delivery two marks from the lawyer's final
  * list, `OSLER DELPHI` and `DELFITY`, one rated HIGH, are absent from `findings.json`. They were dropped
  * WITH a reason, so they sat outside the sibling's population by design:
@@ -880,7 +880,7 @@ export function statedDivergenceFindings({ reconciliation = null, carryRows = nu
   //
   // The first cut of this function gated on the reconciliation's finding-ended positions, mirroring the
   // sibling. That inherited the sibling's BLIND SPOT along with its shape, and the check was inert on
-  // the very delivery it was written for. Replayed against R2 `russet-kestrel`:
+  // the very delivery it was written for. Replayed against that delivery:
   //
   //   silentlyLostFindings       checked=5 matched=5 lost=0
   //   statedDivergenceFindings   checked=5 matched=5 diverged=0   ← should have named two marks

package/driver/reference-score.mjs CHANGED Viewed

@@ -674,7 +674,7 @@ export function scoreRecall({ reference, findings = [], retrieved = [], scopeCla
   // proprietor with more than one mark. A large filer can perfectly well have one mark the run withheld
   // and a DIFFERENT mark, not in the reference, that it surfaced. Both rows are true.
   //
-  // It fired on R2 russet-kestrel: `Novartis AG: reference "DELFITY" is withheld, surfaced "DELPHINA"
+  // It fired on a delivered R2 run: `<large filer>: reference "DELFITY" is withheld, surfaced "DELPHINA"
   // is noise`. Different marks, different records, one proprietor that files a great many. And because
   // score.mjs prints a collision as "do not read the recall numbers above", ONE such proprietor
   // suppressed the whole run's recall measurement — a real 88% → 63% movement went unquoted on the

package/driver/result-noun-fields.mjs CHANGED Viewed

@@ -95,6 +95,13 @@ export const RESULT_NOUN_FIELDS = Object.freeze([
   { file: "driver/skills-store-provenance.mjs", noun: "outcome", sites: 6, atWriteSite: 0, verdict: "out-of-scope" },
   { file: "driver/status-snapshot.mjs", noun: "outcome", sites: 1, atWriteSite: 0, verdict: "out-of-scope" },
   { file: "mcp-server/lib/events.mjs", noun: "recovered", sites: 1, atWriteSite: 0, verdict: "out-of-scope" },
+  // Read at the writing site, as this table requires. All three sites are in `knockoutSearches`, a
+  // READ-ONLY projection that composes the rows `list_searches` answers with: it opens no artifact and
+  // writes nothing, so nothing here can reach `_driver/*.json` or `run.jsonl`. Each value is a literal
+  // chosen from the run's own stored record — "found" or "no-hit" from whether the mark has findings,
+  // and "recorded" for a register term whose stored row says it did NOT answer. None is a call's return
+  // read back as a verdict, which is the defect this table exists to find.
+  { file: "mcp-server/lib/knockout.mjs", noun: "outcome", sites: 3, atWriteSite: 0, verdict: "out-of-scope" },
   { file: "mcp-server/lib/ops.mjs", noun: "settled", sites: 1, atWriteSite: 0, verdict: "out-of-scope" },
   { file: "mcp-server/server.mjs", noun: "outcome", sites: 1, atWriteSite: 0, verdict: "out-of-scope" },
   { file: "scripts/backfill-started-at.mjs", noun: "outcome", sites: 5, atWriteSite: 0, verdict: "out-of-scope" },

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

@@ -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/stages-knockout.mjs CHANGED Viewed

@@ -301,7 +301,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).`,

package/driver/stages.mjs CHANGED Viewed

@@ -3267,7 +3267,7 @@ export const STAGES = {
       `DECLINATIONS: what you do not deliver, you decline BY NAME through the \`record_declination\` tool. A record that reached your findings surface leaves this stage as a finding in ${P.findings} or as a declination, and there is no third way out.`,
       ...(Array.isArray(findingsSurface) && findingsSurface.length ? [
         `DECLINATIONS (MANDATORY): the register digest carried ${findingsSurface.length} record(s) onto your findings surface. Each one leaves this stage by one of two routes and there is no third: it becomes a finding in ${P.findings}, or you decline it BY NAME with a reason and a ground. A record you simply do not mention is reported as a defect of this run, named individually in its trace and shipped as an open doubt, so silence costs you more than a declination ever will.`,
-        `Decline by calling the \`record_declination\` tool. Its schema names the fields it takes and what each is for — read them there, not here. The one thing to know before you call: you cite a record by its POSITION in the list below — there is no field for a mark name or a uri, so a record you were not handed cannot be expressed at all. The reason vocabulary is closed: ${DECLINATION_REASON_TOKENS.join(" / ")}, each an omission synthesis-rules.md already authorises, and if your ground is none of them the rules do not let you omit the record. The grounds you write are one or two lines in your OWN words on why THIS record does not earn a line — never machine-parsed, and what the reviewing lawyer reads. Send them in one batch where you can; a refused row never voids its neighbours, and the answer names what is still undecided so you can finish in this turn.`,
+        `Decline by calling the \`record_declination\` tool. Its schema names the fields it takes and what each is for — read them there, not here. The one thing to know before you call: you cite a record by its POSITION in the list below — there is no field for a mark name or a uri, so a record you were not handed cannot be expressed at all. The reason vocabulary is closed: ${DECLINATION_REASON_TOKENS.join(" / ")}, each an omission synthesis-rules.md already authorises, and if your ground is none of them the rules do not let you omit the record. ONE OF THEM IS NOT AVAILABLE ON A LIVE RECORD IN AN INSTRUCTED CLASS: \`not-worth-the-line\` is a statement about the report's budget rather than about the mark, and a live registration inside one of the matter's own classes is never omitted for want of room — carry it, or decline it on something true of THAT MARK. The call is refused if you try, so it costs you a turn. The grounds you write are one or two lines in your OWN words on why THIS record does not earn a line — never machine-parsed, and what the reviewing lawyer reads. Send them in one batch where you can; a refused row never voids its neighbours, and the answer names what is still undecided so you can finish in this turn.`,
         `A REFUSAL FROM THAT TOOL IS ABOUT BOOKKEEPING, NEVER ABOUT YOUR LEGAL JUDGMENT. There is exactly ONE case: declining a mark IDENTICAL to the applied-for mark, live, in one of the matter's own filed classes, on a discretionary ground — because synthesis-rules.md orders that an on-point identical mark in the relevant class is never dropped, "regardless of filer profile", so such a declination contradicts the instruction you are already following. Nothing else is refused. If that record really is the applicant's own, or already delivered under another record, say exactly that with own-right or duplicate-of-delivered and it is accepted. Whether goods are related, whether a name is off-field, whether a conflict is worth the line — those are your calls and the tool does not have an opinion about any of them.`,
         `The records on your findings surface, by position:`,
         ...findingsSurface.map((r, i) => `  ${i}. ${r.mark ?? "(unnamed)"}${r.owner ? ` — ${r.owner}` : ""}${r.tier ? ` [${r.tier}]` : ""}${r.uri ? ` ${r.uri}` : ""}`),