@@ -145,7 +145,7 @@ else, and it never touches the corpus:
 | `decompose.mjs` | Phase 0 coordination: recipe parsing, docs-host discovery, material gathering (scrape-budget accounting via the corpus's `cacheDecision` — a cache hit is not an attempt), draft MAP writing. Contains **no judgment** — it seeds the checklist and gathers material; it never writes a status. | — |
 | `dimensions.mjs` | The universal, domain-agnostic subtopic checklist and its mechanical presence-matching (`coverageOfUniversals`). Recipes add on top of it; nothing replaces it. | — |
 | `provenance.mjs` | The tamper-evident fetch ledger: `appendFetch`, `verifyLedger`, `rebuildLedger` (the one metadata-migration path — guarded, per-entry `migrations` records, chained `op: 'migration'` boundary), and the overrides log writer. Also **the collector's exclusive section** (`withLock`), acquired with `O_EXCL` (`flag: 'wx'`) so the kernel refuses a second creator instead of letting it overwrite; staleness is judged only *after* EEXIST proves someone holds the file, and a fresh lock that names no pid — the window `O_EXCL` leaves between create and write — is waited for, never broken. Reentrant in-process, so `appendFetch` can serialize its own read-modify-write inside a run that already holds the lock, and release removes only the acquisition it made (pid + nonce). Every writer of the chain — append, tail repair, rebuild — goes through that one lock. `verifyLedger` also **classifies** a body hash that does not recompute (`isLineEndingRewrite`, `hashText`): folding CRLF back to LF either restores the recorded hash or it does not, so `body-unmodified` problems carry `kind: 'line-endings' | 'modified'` and the consumer can name the right cause instead of guessing (ADR-0020). | ADR-0003 (corpus-adjacent), ADR-0020 | **Release is ownership-positive (fixed 2026-09-21):** the lock is unlinked only when the nonce POSITIVELY matches. An unreadable lock is left alone — while a collector works its lock can be truncated, recovered as stale by a second collector and replaced by that collector's own, and unlinking then would delete a lock this process does not hold and admit a third writer to the section. Failing to release is recoverable by the staleness path; deleting someone else's is not.
-| `checks.mjs` | The **ordered contract-check registry**: discovery-contract, citations, provenance, transport-provenance, gate-integrity, unknown-closure, subtopic-coverage, capture-completeness, **evidence-supersession**, collection-attempts, hygiene, corpus-shape — twelve, in a pinned order. Every check is a pure function of the corpus snapshot + options; none reads the filesystem. **`supersededRows(corpus)`** is the one shared answer to "which rows have been replaced by a fresher capture of the same URL": `evidence-supersession` refuses an unknown still resting on a replaced row, `transport-provenance` goes quiet about a replaced row nothing relies on (but not about one still cited), and `hygiene` stops calling a refresh a duplicate while still catching two rows of one URL fetched the same day. Those last two are ADR-0026-aware: they warn about the state that ADR requires. | ADR-0004, ADR-0026 |
+| `checks.mjs` | The **ordered contract-check registry**: discovery-contract, citations, provenance, transport-provenance, gate-integrity, unknown-closure, subtopic-coverage, capture-completeness, **evidence-supersession**, collection-attempts, hygiene, corpus-shape, **corroboration** — thirteen, in a pinned order. Every check is a pure function of the corpus snapshot + options; none reads the filesystem. A check that **instructs** the reviewer owns the accuracy of the instruction, not just of the verdict: `capture-completeness/partial-render` names the EVIDENCE row and the `[render-reviewed: ...]` syntax because it used to name a `renderReview:` front-matter line, and a reviewer who obeyed it edited a hashed capture and got a blocking `provenance/body-unmodified` failure instead of a closed warning. The wording is pinned by test for that reason. **`supersededRows(corpus)`** is the one shared answer to "which rows have been replaced by a fresher capture of the same URL": `evidence-supersession` refuses an unknown still resting on a replaced row, `transport-provenance` goes quiet about a replaced row nothing relies on (but not about one still cited), and `hygiene` stops calling a refresh a duplicate while still catching two rows of one URL fetched the same day. Those last two are ADR-0026-aware: they warn about the state that ADR requires. | ADR-0004, ADR-0026 |
 | `similarity.mjs` | **Near-duplicate detection between two captured pages**, and nothing else. Word shingles (5-word, case- and punctuation-folded, URLs stripped) reduced to a 128-hash MinHash `sketch`; `similarity` estimates Jaccard, `isMirror` compares it to `MIRROR_THRESHOLD`, and `documentGroups` single-link-clusters rows into distinct DOCUMENTS. Exists because `corroboration` counted HOSTS and therefore **inverted** on a mirror: a republished copy on an unrelated host scored `independent` - the registry's best grade - while carrying one witness plus a staleness `freshness` cannot see, since that check grades when a page was FETCHED. `MIRROR_THRESHOLD = 0.25` is **chosen from measurement, not taste**: all 1081 capture pairs in this repository were compared on 2026-09-21, the known stale mirror (`nodejs.org` x `lira.epac.to`, six majors apart) scored 0.3879 and the highest-scoring genuinely different cross-host pair scored 0.0275 - a fourteen-fold gap, so the line is not delicate. `sketch` returns **null** below `MIN_SHINGLES`, and every caller must read null as "cannot tell" rather than "different", which is why two unjudgeable rows stay two documents instead of merging into an invented mirror. Hashing is seeded FNV-1a so a sketch is identical across runs and platforms - a fingerprint that decides a gate finding must grade the same corpus the same way everywhere. Judges no meaning and cannot tell a correct page from a wrong one (ADR-0013). | ADR-0036 |
 | `preflight.mjs` | **The verdict** and the **verdict context**. Assembles findings from CHECKS into pass/fail; one function, three callers (commit gate, edit gate, CLI) so they cannot disagree. Owns the verdict's input unit: `verdictContext(root)` reads the corpus, the gate state (`readGateState`), and the operator's `evidencePolicy` together — same snapshot, same verdict, by construction. | ADR-0004 |
 | `gate.mjs` | Gate policy: `isGated` (the four markers), `evaluate` (commit/edit), the GATE_OFF override recording, and the architecture-map rule (`architectureMapBreach` over `loadGateConfig` — guarded paths are project configuration, `research/kit.json`, defaults `src/lib/bin/scripts/app`). Contains no repo-specific path. **One deliberate exception to "no CLI parsing"**: the commit gate's staged-path list arrives as *data on a pipe* (`stagedPathsFromStdin` / `splitPathList`), because argv was O(n²) to build and bounded besides. It returns **null for "stdin could not be read" and `[]` for "read, and empty"** — conflating them would hand the verdict an empty staged set, which it allows, i.e. a gate that silently stops gating. `stdinIsReadable()` asks `isatty(0)` rather than inferring from the file type, which gets two cases wrong in opposite directions (a socketpair is not a FIFO; `/dev/null` is a character device but reads as immediate EOF). | ADR-0002, ADR-0007, ADR-0008, ADR-0020 | **An unreadable index BLOCKS (fixed 2026-09-21).** The commit gate judges staged bytes (ADR-0024); when `git checkout-index` fails it used to judge the working tree and note that it had. Noting is not enough — the two differ exactly when it matters, so an environmental git failure silently reinstated the defect ADR-0024 exists to prevent. It now blocks with `judged: 'nothing'` and names `--no-verify` as the recorded override. A project that is not a git repository still judges the tree: there is no index to fail to read. Index materialisation is also **chunked** (250 paths per call) rather than spreading every tracked path into one argv, which on Windows hit the ~32k command-line cap for a large corpus and produced exactly that git failure.
 
@@ -395,7 +395,7 @@ node research-kit/bin/selftest.mjs            # all of it
 node research-kit/bin/selftest.mjs gate hook  # just these files
 ```
 
-872 tests, offline, no key and no network. The runner **awaits** every test, so `ok` means
+874 tests, offline, no key and no network. The runner **awaits** every test, so `ok` means
 the assertions settled (ADR-0021), and each test is raced against a watchdog
 (`RESEARCH_KIT_TEST_TIMEOUT`, default 60s).
 
 
@@ -117,7 +117,8 @@ depth      ${run.depth} (budget ${run.budget} scrapes)
 collected  ${run.collected}
 cached     ${run.cached}
 failed     ${run.failed}
-spent      ${run.spent} (budget consumed: collected + failed)`);
+spent      ${run.spent} (budget consumed: collected + failed)
+`);
 
 // The topic signal, printed at the one moment it helps: the pages are on disk and nobody
 // has read them yet. It decides nothing - see `topicMatch` for the two thresholds that were
 
@@ -373,11 +373,19 @@ function captureCompleteness(corpus) {
         { file: capture.file }));
       continue;
     }
+    // The instruction names the EVIDENCE row on purpose. It used to say "a `renderReview:`
+    // front-matter line", which is the one place the note must NOT go - the paragraph above
+    // explains why, and the message contradicted it. A reviewer who followed it literally
+    // got a BLOCKING `provenance/body-unmodified` failure and kept this warning, because
+    // editing a capture breaks the hash recorded at fetch. Measured, not reasoned: doing
+    // exactly what the old text said turned a 1-warning PASS into a 1-blocking FAIL.
     out.push(finding('warn', 'capture-completeness', 'partial-render',
       `${capture.file} contains ${hits} render-failure notice(s) from the page itself - `
       + 'it arrived whole, so `completeness` cannot see this. Confirm the text cited from it is '
-      + `present, then record what you checked in a \`renderReview:\` front-matter line of at least ${MIN_RENDER_REVIEW} characters`
-      + (reviewed ? ` (the current one gives only "${reviewed}")` : ''),
+      + `present, then write \`[render-reviewed: what you checked]\` (at least ${MIN_RENDER_REVIEW} `
+      + 'characters) into the Finding cell of an EVIDENCE row that cites this capture. Do not edit '
+      + 'the capture: the ledger hashes it whole, front-matter included'
+      + (reviewed ? ` (the current note gives only "${reviewed}")` : ''),
       { file: capture.file }));
   }
   if (!out.length) out.push(finding('pass', 'capture-completeness', 'completeness', 'no closed unknown rests on a partial capture alone'));
 
@@ -470,6 +470,20 @@ export function searchUsage(root, { now = new Date(), provider = '' } = {}) {
  * moment it helps - right after collecting, before anyone has read the pages - and decides
  * nothing. A reviewer seeing 0.25 on a fresh collection knows to check the URLs; on the EUDR
  * run that is precisely the step that caught it, performed by hand.
+ *
+ * A HIGH SCORE MEANS NOTHING WHEN THE TOPIC IS MADE OF COMMON WORDS, and that is not
+ * hypothetical either. The first real use after shipping was a collection on Tavily's terms,
+ * topic "...data retention training on inputs outputs zero retention enterprise tier opt
+ * out". It reported **0.92, eight of eight above threshold** - on a corpus where SEVEN OF
+ * EIGHT captures were generic "zero data retention" marketing from unrelated vendors and
+ * only `tavily.com/terms` was on topic. Every one of those pages genuinely contains "data",
+ * "retention", "training", "zero" and "enterprise", so the arithmetic was right and the
+ * signal was useless.
+ *
+ * So the number is informative in ONE direction only: a low score is worth investigating,
+ * and a high score is worth nothing unless the topic carried distinctive terms. `deforestation`
+ * and `2023/1115` are distinctive; `data` and `service` are not, and this function cannot
+ * tell the difference without a corpus-wide notion of rarity it does not have.
  */
 const TOPIC_STOPWORDS = new Set(['the', 'a', 'an', 'of', 'for', 'and', 'or', 'to', 'in', 'on',
   'at', 'by', 'after', 'before', 'current', 'date', 'with', 'from', 'is', 'are', 'as', 'eu',
 
@@ -567,6 +567,26 @@ test('capture-completeness: the render review is read from the ROW, never the ca
     'a note in the capture front-matter must NOT satisfy the review - the ledger hashes it');
 });
 
+test('partial-render tells the reviewer where the note goes, and it is not front-matter', () => {
+  // The test above pins that front-matter does not satisfy the review. This pins that the
+  // MESSAGE does not send the reviewer there - which it did, for as long as the check
+  // existed. Found by following it on a real corpus: adding the `renderReview:` front-matter
+  // line it named turned a 1-warning PASS into a blocking `provenance/body-unmodified`
+  // failure, and left this warning standing. An instruction that breaks the gate when
+  // obeyed is worse than no instruction, so the wording is load-bearing and pinned here.
+  const dir = makePassingProject();
+  const capture = readCorpus(dir).captures.entries[0];
+  corrupt(dir, capture.file, (text) => `${text}\n\nThere was an error while loading.\n`);
+
+  const hit = runCheck('capture-completeness', snapshot(dir)).find((f) => f.rule === 'partial-render');
+  assert.equal(hit.severity, 'warn');
+  assert.match(hit.detail, /\[render-reviewed: /, 'must name the syntax the check actually parses');
+  assert.match(hit.detail, /EVIDENCE row/, 'must name where the note goes');
+  assert.match(hit.detail, /Do not edit the capture/, 'must say why it cannot go in the capture');
+  assert.ok(!/front-matter line/.test(hit.detail),
+    'must not direct the reviewer to edit front-matter - the ledger hashes the capture whole');
+});
+
 test('a row named INSIDE a single-witness note is not thereby cited', () => {
   // The footgun this removes. `citedIds` returns every E-## mention in the cell, and the
   // reason a reviewer writes lives in that same cell - so explaining why no second witness
 
@@ -385,3 +385,27 @@ test('topicMatch REPORTS and never decides - the thresholds that were rejected',
   assert.equal(m.pass, undefined, 'a pass/fail field would make this a gate');
   assert.equal(m.severity, undefined);
 });
+
+test('topicMatch scores high on a generic topic even when the corpus is off-topic', () => {
+  // The limitation, pinned so the number is never read as a quality score. The first real
+  // use after shipping reported 0.92 with eight of eight above threshold, on a corpus where
+  // seven of eight captures were generic "zero data retention" marketing from unrelated
+  // vendors and only one was the document being researched.
+  //
+  // The arithmetic was right. Every one of those pages genuinely contains "data",
+  // "retention", "training" and "zero" - so a topic built from common words matches
+  // anything, and this function cannot tell a distinctive term from a common one.
+  const genericTopic = 'terms of service data retention training on inputs outputs zero retention enterprise';
+  const unrelated = [
+    'Zero data retention explained: how enterprise AI vendors handle training data and service inputs and outputs.',
+    'What is zero data retention? A glossary entry about training, retention and enterprise service terms.',
+  ];
+  const m = topicMatch(genericTopic, unrelated);
+  assert.ok(m.best >= 0.5, `a generic topic matches unrelated pages: got ${m.best}`);
+  assert.ok(m.strong > 0, 'and they clear the threshold, which is exactly the problem');
+
+  // The contrast: distinctive terms behave the way the signal is useful for.
+  const distinctive = 'EU Deforestation Regulation 2023/1115 operators SMEs';
+  assert.equal(topicMatch(distinctive, unrelated).strong, 0,
+    'a distinctive topic does NOT match unrelated pages');
+});