@dogfood-lab/ingest 1.9.0 → 1.10.0

package/lib/integrity.js

@@ -62,13 +62,27 @@ export function canonicalize(value) {
 /**
  * Deep clone with object keys sorted ascending at every depth. Arrays keep
  * order (only their element objects are key-sorted). Primitives pass through.
+ *
+ * F-755d0f3f: the accumulator MUST be null-prototype. On a plain `{}` the
+ * assignment below would hit the inherited `Object.prototype.__proto__` setter
+ * for an own `__proto__` key and retarget the accumulator's prototype instead of
+ * creating an own key — dropping that field, and everything under it, from the
+ * canonical string and therefore from the record digest. `JSON.parse` creates a
+ * real own `__proto__` data property (CreateDataProperty, not Set), so any
+ * record file on disk can carry one, and verify-chain.js reaches this via a bare
+ * `JSON.parse` with no schema gate. That made two materially different records
+ * hash identically and let a tampered record re-verify clean.
+ *
+ * `JSON.stringify` serializes a null-prototype object identically to a plain
+ * one, so this is byte-for-byte compatible with every already-persisted record
+ * and the committed chain is unaffected.
  */
 function sortDeep(value) {
   if (Array.isArray(value)) {
     return value.map(sortDeep);
   }
   if (value !== null && typeof value === 'object') {
-    const sorted = {};
+    const sorted = Object.create(null);
     for (const key of Object.keys(value).sort()) {
       sorted[key] = sortDeep(value[key]);
     }

package/load-context.js

@@ -180,24 +180,6 @@ export function loadRepoPolicy(repoSlug, repoRoot) {
   return parsed;
 }
 
-/**
- * Default scenario fetcher that reads from the local filesystem.
- * Used when dogfood-labs is dogfooding itself.
- *
- * @param {string} repoRoot - Root of the source repo
- * @returns {object} Scenario fetch adapter
- */
-export function localScenarioFetcher(repoRoot) {
-  return {
-    async fetch(scenarioId) {
-      if (!/^[\w-]+$/.test(scenarioId)) return null;
-      const path = join(repoRoot, 'dogfood', 'scenarios', `${scenarioId}.yaml`);
-      if (!existsSync(path)) return null;
-      return yaml.load(readFileSync(path, 'utf-8'));
-    }
-  };
-}
-
 /**
  * Default per-request timeout for the GitHub scenario fetch. Mirrors the
  * sibling `GITHUB_PROVENANCE_TIMEOUT_MS` constant at
@@ -271,6 +253,64 @@ function defaultSleep(ms) {
   return new Promise((r) => setTimeout(r, ms));
 }
 
+/**
+ * COORD-001: parse a scenario body fetched from a consumer's source repo —
+ * the one `yaml.load` call site in this file that sees content a hostile or
+ * compromised submitter controls end to end. js-yaml 4.1.1 (the workspace
+ * floor; see package.json `"js-yaml": "^4.1.0"`) carries
+ * GHSA-h67p-54hq-rp68: chained `<<` merge keys cost O(depth) per level,
+ * because `mergeMappings()` (js-yaml lib/loader.js:304-321) re-copies
+ * `Object.keys(source)` for the FULL accumulated mapping at every level —
+ * so an n-level merge chain costs O(n^2) total. The attack is small BY
+ * CONSTRUCTION (each level adds only a couple of YAML lines), so
+ * GITHUB_SCENARIO_MAX_BYTES (a 1 MiB cap on the wire size) does not defend
+ * it: measured on the reference rig, a chain sized right at that 1 MiB cap
+ * costs ~61s of CPU, and scaling is ~quadratic (68 KB -> 127ms, 145 KB ->
+ * 656ms). Bumping js-yaml to v5 (which drops merge-key support outright)
+ * is blocked — Dependabot #50 is held open because v5 breaks two scripts/
+ * gates — so the mitigation lives here instead of in the dependency.
+ *
+ * CORE_SCHEMA is DEFAULT_SCHEMA minus exactly the YAML-1.1 extras
+ * (`timestamp`, `merge`, `binary`, `omap`, `pairs`, `set` — see js-yaml
+ * lib/schema/default.js). Without the registered `merge` type, the
+ * loader's `keyTag === 'tag:yaml.org,2002:merge'` branch in
+ * storeMappingPair() never matches a `<<` key, so `mergeMappings()` is
+ * never invoked and the O(depth) copy loop simply cannot run — `<<`
+ * resolves as an ordinary (and, against scenario.schema.json, rejected —
+ * `additionalProperties: false`) string key instead. This is verified
+ * behaviourally, not assumed from the option name, in
+ * coord-001-scenario-merge-bomb.test.js: a probe document proves the
+ * merge-key never fires, and a second probe proves the real fetch path
+ * (not just this helper in isolation) stays protected. Every field
+ * scenario.schema.json declares is a plain string/object/array/boolean —
+ * none relies on the dropped timestamp/binary/omap/pairs/set types — so
+ * this is a pure security hardening with no behavioural cost to a
+ * conforming scenario document.
+ *
+ * Scoped deliberately to THIS call site only. The other two `yaml.load`
+ * calls in this file (loadGlobalPolicy, loadRepoPolicy) both read
+ * maintainer-committed local files — the attacker does not control their
+ * content, only (in loadRepoPolicy's case) which existing file gets
+ * selected, and that selection is already segment-validated above.
+ * Widening this schema change to those sites is unnecessary risk for zero
+ * additional coverage.
+ *
+ * F-3be85850: this comment previously also named a THIRD "local files"
+ * call site, localScenarioFetcher — removed as dead code (zero callers
+ * anywhere in the repo, and not reachable even as an external package hook:
+ * load-context.js is not in @dogfood-lab/ingest's package.json `exports`
+ * map). Its own doc comment claimed it was "Used when dogfood-labs is
+ * dogfooding itself," but the real self-dogfood path (self-dogfood.yml)
+ * routes through the SAME public ingest.yml repository_dispatch pipeline
+ * every consumer uses, via githubScenarioFetcher below — never a local-disk
+ * reader. dogfood/scenarios/*.yaml remain the canonical scenario
+ * definitions; they are simply fetched over the GitHub Contents API rather
+ * than off local disk, even for this repo's own CI.
+ */
+export function parseUntrustedScenarioYaml(text) {
+  return yaml.load(text, { schema: yaml.CORE_SCHEMA });
+}
+
 /**
  * GitHub scenario fetcher. Loads scenario definitions from a source repo
  * via the GitHub API at a specific commit SHA.
@@ -458,7 +498,10 @@ export function githubScenarioFetcher(token, repoSlug, commitSha, opts = {}) {
 
     let scenario;
     try {
-      scenario = yaml.load(text);
+      // COORD-001: merge-key DoS defense — see parseUntrustedScenarioYaml's
+      // doc comment. `text` is untrusted (fetched from the submitter's
+      // source repo), so it must never reach plain yaml.load().
+      scenario = parseUntrustedScenarioYaml(text);
     } catch {
       return { scenario: null, reason: 'parse_error', retryable: false };
     }
@@ -488,7 +531,22 @@ export function githubScenarioFetcher(token, repoSlug, commitSha, opts = {}) {
     for (let i = 0; i < attempts; i++) {
       last = await attemptOnce(scenarioId);
       if (last.scenario || !last.retryable || i === attempts - 1) break;
-      await sleep(Math.min(RETRY_BASE_MS * (1 << i), RETRY_MAX_MS));
+      const waitMs = Math.min(RETRY_BASE_MS * (1 << i), RETRY_MAX_MS);
+      // F-2a5ddafa: this loop was completely silent on every retry but the
+      // last — an operator had zero early-warning signal that the source
+      // repo's API was degrading until the retry budget fully exhausted and
+      // threw (see the sibling fix in
+      // packages/verify/validators/provenance.js's confirm() loops, same
+      // finding). 'warn' (not 'error') since the fetch may still succeed on
+      // the next attempt.
+      logStage('warn', {
+        kind: 'scenario_fetch_retry',
+        scenario_id: scenarioId,
+        attempt: i + 1,
+        status_or_reason: last.reason || (last.fault ? last.fault.message : 'unknown'),
+        next_backoff_ms: waitMs,
+      });
+      await sleep(waitMs);
     }
     // V2-CROSS-BO-001: a transient fault that survived every retry is an
     // outage — throw the classified operational error instead of returning a

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@dogfood-lab/ingest",
-  "version": "1.9.0",
+  "version": "1.10.0",
   "type": "module",
   "description": "Ingestion pipeline for testing-os. Thin glue: dispatch → verifier → persist → indexes.",
   "main": "run.js",

package/persist.js

@@ -6,7 +6,7 @@
  * duplicate detection by run_id, directory creation.
  */
 
-import { existsSync, mkdirSync, writeFileSync, renameSync, openSync, closeSync, unlinkSync } from 'node:fs';
+import { existsSync, mkdirSync, writeFileSync, renameSync, openSync, closeSync, unlinkSync, readFileSync } from 'node:fs';
 import { join, dirname, relative, sep } from 'node:path';
 import { randomBytes } from 'node:crypto';
 
@@ -14,6 +14,8 @@ import { validateRecord } from './validate-record.js';
 import { isUnsafeSegment } from './lib/unsafe-segment.js';
 import { submissionDigest } from './lib/integrity.js';
 import { readChainHead, appendChainEntry } from './lib/chain-manifest.js';
+import { parseRejectionReason } from '@dogfood-lab/verify';
+import { SUPPORTED_SCHEMA_VERSIONS } from '@dogfood-lab/schemas';
 
 /**
  * Error thrown when writeRecord loses a TOCTOU race for the same canonical path.
@@ -29,6 +31,40 @@ export class DuplicateRunIdError extends Error {
   }
 }
 
+/**
+ * Error thrown when writeRecord's SECOND computeRecordPath() call — the one
+ * that computes the real write target, reached only AFTER validateRecord()
+ * has already confirmed the record is schema-valid — still cannot produce a
+ * safe path.
+ *
+ * F-bbbe2e1f: computeRecordPath()'s isUnsafeSegment check (lib/unsafe-segment.js)
+ * is STRICTER than the record schema's own repo pattern
+ * (`^[a-zA-Z0-9_.-]+/[a-zA-Z0-9_.-]+$`), which permits an embedded `..` or a
+ * lone `.` segment (e.g. `../etc`). A record can therefore pass
+ * validateRecord() above and still fail here — this is never a schema
+ * problem, it is the traversal backstop firing on schema-valid input. Pre-fix
+ * that let a bare, unclassified computeRecordPath Error (no `.code`) escape
+ * uncaught — the exact shape F-a37d36f5 eliminated at the FIRST
+ * computeRecordPath call (the isDuplicate probe below) but not this second
+ * one, three lines after validateRecord(). Classifying it here matches
+ * RecordValidationError's discipline and stays fail-closed: nothing below
+ * this point has touched the filesystem yet (mkdirSync/openSync/writeFileSync
+ * all come after), so no partial write is possible either way.
+ */
+export class UnsafeRecordPathError extends Error {
+  constructor(record, cause) {
+    super(
+      `record passed schema validation but its path could not be safely computed ` +
+      `(repo: ${record.repo}, run_id: ${record.run_id}): ${cause.message}`,
+      { cause }
+    );
+    this.name = 'UnsafeRecordPathError';
+    this.code = 'UNSAFE_RECORD_PATH';
+    this.repo = record.repo;
+    this.runId = record.run_id;
+  }
+}
+
 /**
  * Compute the canonical file path for a persisted record.
  *
@@ -88,9 +124,180 @@ export function computeRecordPath(record, repoRoot) {
   return join(repoRoot, base, org, repo, year, month, day, filename);
 }
 
+/**
+ * F-4036ae25: a prior `_rejected` record whose rejection_reasons are ALL
+ * retryable-class is "the submitter can fix this and resubmit", not an
+ * unappealable verdict about the run — the same doctrine that already exempts
+ * an unfilable (`_skipPersist`) rejection from consuming its run_id. Narrowing
+ * `_skipPersist` in verify/index.js means a filable-but-rejected submission
+ * now DOES persist (the fleet-wide audit trail F-4036ae25 restores), so this
+ * is the other half of that fix: persisting the evidence must not resurrect
+ * the exact run_id-poisoning pathology F-82429f90 eliminated for
+ * validator-crash faults.
+ *
+ * F-f8952a50 (wave 10): this used to check `parseRejectionReason(r).prefix
+ * === 'schema:'` — ONE of the ten prefixes parse-rejection.js's own "Prefix
+ * taxonomy" documents under `class: 'submission-bad'` ("the submitter fixes
+ * the payload and resubmits"). Proven live with `repo:mismatch` (a pure
+ * identity/addressing mistake — the run happened, only the repo/run_url
+ * pairing was mis-stated): a corrected resubmission's payload never even
+ * reached verify() a second time, because both isDuplicate() call sites
+ * treated the stale `repo:` rejection as an unconditional block — see
+ * f-0f9e4077-retry-collision-duplicate-rejection.test.js's 'F-f8952a50'
+ * describe block for the end-to-end proof.
+ *
+ * The fix reads `parseRejectionReason(r).retryable` — the classifier's OWN
+ * per-prefix routing decision (see parse-rejection.js's file header for the
+ * full split) — instead of re-deriving a prefix allowlist here. A future
+ * prefix parse-rejection.js adds is automatically retryable or not with no
+ * edit to this file. This is intentionally NARROWER than "every submission-bad
+ * class": `retryable` is false for `policy:` and `provenance:` even though
+ * both are class `submission-bad` — those two prefixes are a rendered VERDICT
+ * on the run's own reported content (see parse-rejection.js), and letting a
+ * resubmission retry past one would let a submitter launder a genuinely-bad
+ * run into an accepted one by resubmitting different self-reported content
+ * under the same run_id. That boundary is independently pinned end-to-end by
+ * schema-invalid-skip-persist.test.js's "REGRESSION GUARD" test and the
+ * "persist-a-verdict doctrine is preserved" describe block — this fix must
+ * not (and, via the per-prefix flag, does not) touch it.
+ *
+ * `'operational'` / `'ingest'` / `'unknown'`-class reasons are always
+ * `retryable: false` too (see parse-rejection.js). Most `'operational'`-class
+ * reasons are not actually reachable here in production (F-82429f90 and its
+ * provenance-fault:/scenario-fetch-fault: siblings THROW instead of
+ * persisting a `_rejected` record — see runValidator in verify/index.js).
+ *
+ * F-51780da9 (wave 22, confirming audit of F-be0deacd): `CONTRACT_SCHEMA_TOO_NEW:`
+ * is the one documented exception where the frozen `retryable: false` is NOT
+ * the whole story. `validators/schema-version.js` RETURNS it as an ordinary
+ * rejection string rather than throwing, so a too-new-major submission
+ * genuinely does persist to `_rejected/` and IS read by this function.
+ * `retryable` is a STATIC per-prefix classification stamped at parse time —
+ * it has no way to observe that testing-os has SINCE been upgraded past the
+ * declared major, so trusting it alone lets one stale TOO_NEW rejection
+ * permanently poison a run_id even after the exact condition it was
+ * rejecting no longer holds (proven live: seed a `_rejected` record with a
+ * TOO_NEW reason declaring a major the CURRENT build already understands —
+ * pre-fix this function still returns `false` forever, because it never asks
+ * whether the stored major is still actually too new). `reevaluateTooNewRetry`
+ * below is the correction: for this ONE prefix, re-derive whether the STORED
+ * rejection's declared major is still above the CURRENT build's
+ * `SUPPORTED_SCHEMA_VERSIONS.<contract>.maxMajor`, instead of trusting the
+ * frozen boolean. The other nine prefixes were swept for the same trap (any
+ * retryable semantics that depend on mutable environment rather than the
+ * submission itself) and none qualify: schema:/policy-config:/repo:/
+ * submission-contains-verifier-field:/unsafe-record-path:/steps[<id>]:/
+ * CONTRACT_SCHEMA_TOO_OLD: are already retryable:true (an already-permissive
+ * prefix has no "stuck forever" direction to fix); policy:/provenance: are a
+ * DELIBERATE, permanent anti-gaming verdict on the run's own reported
+ * content, not an environment-dependent snapshot that goes stale;
+ * provenance-fault:/scenario-fetch-fault:/submission-malformed:/
+ * VALIDATOR_FAULT_*: all throw rather than persist (never reach this
+ * function); scenario-load: is evaluated against an immutable git
+ * commit_sha, not a build-version boundary, so the same committed content at
+ * the same ref parses the same way forever — there is no analogous integer
+ * ceiling to re-derive the way TOO_NEW's `maxMajor` comparison allows.
+ *
+ * Any read/parse failure fails closed (blocking): a corrupted or unreadable
+ * evidence file must never silently unblock a path collision. The same
+ * failure mode covers a CONTRACT_SCHEMA_TOO_NEW: reason whose shape
+ * `reevaluateTooNewRetry` cannot parse, or whose contract key is no longer
+ * registered in `SUPPORTED_SCHEMA_VERSIONS` — both fail closed to "still
+ * blocking" rather than guessing.
+ *
+ * @param {string} rejectedPath - Absolute path already confirmed to exist.
+ * @returns {boolean} true when every rejection reason is individually
+ *   retryable (see parseRejectionReason's `retryable` field), OR — for
+ *   CONTRACT_SCHEMA_TOO_NEW: specifically — no longer applicable because
+ *   testing-os has since been upgraded past the declared major.
+ */
+
+/**
+ * F-51780da9: matches a `CONTRACT_SCHEMA_TOO_NEW:` reason string emitted by
+ * `validators/schema-version.js` — `CONTRACT_SCHEMA_TOO_NEW: <contract>
+ * schema v<major>.<minor>.<patch> ...` — capturing the contract key and the
+ * declared MAJOR, the two pieces of information needed to re-ask, against
+ * the CURRENT build, the exact question the stored rejection answered
+ * against a possibly-older one. Anchored to the literal TOO_NEW prefix only
+ * (never TOO_OLD:, a distinct literal) and requires a trailing space after
+ * the three-part version so it matches both the full production message
+ * (`... but this build supports v...`) and a shortened test fixture
+ * (`... — upgrade testing-os`) without over-matching a malformed variant.
+ */
+const TOO_NEW_DECLARED_VERSION = /^CONTRACT_SCHEMA_TOO_NEW: (\S+) schema v(\d+)\.\d+\.\d+ /;
+
+/**
+ * F-51780da9: re-evaluate a single STORED `CONTRACT_SCHEMA_TOO_NEW:` reason
+ * against the CURRENT build's `SUPPORTED_SCHEMA_VERSIONS`, instead of
+ * trusting the frozen `retryable: false` parse-rejection.js stamps on this
+ * prefix. `validators/schema-version.js` emits this prefix precisely when
+ * `declaredMajor > supported.maxMajor`; this re-runs that identical
+ * comparison against whatever `maxMajor` is TODAY, which a testing-os
+ * upgrade may have since raised past the stored declared major.
+ *
+ * @param {string} reason - a single rejection_reasons[] entry.
+ * @returns {boolean} `true` when the declared major is no longer above the
+ *   current build's supported ceiling (the rejection has been resolved by a
+ *   since-applied upgrade); `false` when it is still genuinely too new, the
+ *   contract key is unrecognized, or `reason` is not a
+ *   CONTRACT_SCHEMA_TOO_NEW: reason at all — every non-match fails closed to
+ *   "still blocking" rather than guessing.
+ */
+function reevaluateTooNewRetry(reason) {
+  const match = typeof reason === 'string' ? reason.match(TOO_NEW_DECLARED_VERSION) : null;
+  if (!match) return false;
+  const [, contract, declaredMajorStr] = match;
+  const supported = SUPPORTED_SCHEMA_VERSIONS[contract];
+  if (!supported) return false;
+  return Number(declaredMajorStr) <= supported.maxMajor;
+}
+
+function isRetryableRejection(rejectedPath) {
+  let parsed;
+  try {
+    parsed = JSON.parse(readFileSync(rejectedPath, 'utf-8'));
+  } catch {
+    return false;
+  }
+  const reasons = parsed?.verification?.rejection_reasons;
+  if (parsed?.verification?.status !== 'rejected' || !Array.isArray(reasons) || reasons.length === 0) {
+    return false;
+  }
+  // F-51780da9: a reason counts as retryable either via the classifier's own
+  // static per-prefix flag, or — for CONTRACT_SCHEMA_TOO_NEW: specifically —
+  // via the re-derived, current-environment check above. Every other prefix
+  // is unaffected: reevaluateTooNewRetry returns false for any reason it
+  // does not recognize, so `.every()`'s existing behavior is unchanged for
+  // schema:/policy:/repo:/provenance:/etc.
+  return reasons.every(r => parseRejectionReason(r).retryable === true || reevaluateTooNewRetry(r));
+}
+
 /**
  * Check if a record with this run_id already exists (accepted or rejected).
  *
+ * F-0f9e4077 (wave-6 regression, fixed wave-8): computeRecordPath() is keyed
+ * on (run_id, date, accepted|rejected) — never on rejection_reasons content.
+ * So once a `_rejected` record occupies a path, ANY new record whose OWN
+ * status is STILL 'rejected' is headed to that exact same path no matter
+ * which violation it reports (an unexpected field with a different name, a
+ * different value, even a byte-identical resubmission all collide
+ * identically — computeRecordPath never looks at content). The
+ * isRetryableRejection carve-out below exists so a stale retryable-class
+ * rejection (F-f8952a50: any prefix parse-rejection.js's taxonomy flags
+ * `retryable: true` — shape/addressing mistakes, not just schema:) does not
+ * block a DIFFERENT-status (now accepted) record from reaching ITS OWN,
+ * different path — it was never a promise that the
+ * REJECTED path specifically is free. Pre-fix, skipping the status check let
+ * an uncorrected retry fall through as "not a duplicate," reach
+ * writeRecord()'s exclusive-create, and throw DuplicateRunIdError — a
+ * purely sequential, single-writer collision masquerading as the two-writer
+ * TOCTOU race that error class exists for. Gating on
+ * `record.verification.status === 'accepted'` restores the carve-out to
+ * exactly the case it can actually help (a record now headed elsewhere)
+ * while making a still-rejected collision an unconditional, ordinary
+ * duplicate — so writeRecord() short-circuits before ever attempting the
+ * write, and no throw is reachable for this class anymore.
+ *
  * @param {string} runId
  * @param {object} record - The record (used for repo/timing to compute path)
  * @param {string} repoRoot
@@ -105,7 +312,14 @@ export function isDuplicate(runId, record, repoRoot) {
   // Check rejected path
   const rejectedRecord = { ...record, verification: { ...record.verification, status: 'rejected' } };
   const rejectedPath = computeRecordPath(rejectedRecord, repoRoot);
-  if (existsSync(rejectedPath)) return true;
+  if (existsSync(rejectedPath)) {
+    // A record that is itself still rejected can only ever land at THIS
+    // path — asking whether the OLD occupant is retryable is moot when the
+    // NEW attempt has nowhere else to go. Only a record now bound for the
+    // accepted path (real forward progress) gets to ask that question.
+    if (record.verification?.status !== 'accepted') return true;
+    return !isRetryableRejection(rejectedPath);
+  }
 
   return false;
 }
@@ -130,7 +344,21 @@ export function isDuplicate(runId, record, repoRoot) {
  * @throws {DuplicateRunIdError} when a concurrent writer won the race
  */
 export function writeRecord(record, repoRoot) {
-  if (isDuplicate(record.run_id, record, repoRoot)) {
+  // F-a37d36f5: family sibling of the ingest.js pre-check fix — writeRecord
+  // carries its OWN premature isDuplicate call, reached even when the
+  // caller's own duplicate check was skipped or already cleared. A record
+  // whose repo/run_id computeRecordPath rejects (invalid format, unsafe
+  // segment) cannot possibly collide with an existing file, so treating the
+  // throw as "not a duplicate" here is the same semantically-free
+  // short-circuit as the run.js fix — it lets validateRecord() below be the
+  // authoritative judge instead of a raw path-computation throw.
+  let duplicate;
+  try {
+    duplicate = isDuplicate(record.run_id, record, repoRoot);
+  } catch {
+    duplicate = false;
+  }
+  if (duplicate) {
     const path = computeRecordPath(record, repoRoot);
     return { path, written: false };
   }
@@ -160,7 +388,16 @@ export function writeRecord(record, repoRoot) {
   // schema is the contract every downstream consumer relies on.
   validateRecord(record);
 
-  const path = computeRecordPath(record, repoRoot);
+  // F-bbbe2e1f: see UnsafeRecordPathError's doc comment. Wrap this SECOND
+  // computeRecordPath() call — the first is inside isDuplicate() above,
+  // already guarded by F-a37d36f5 — so a schema-valid-but-unsafe repo (e.g.
+  // `../etc`) throws a classified error instead of a bare one.
+  let path;
+  try {
+    path = computeRecordPath(record, repoRoot);
+  } catch (err) {
+    throw new UnsafeRecordPathError(record, err);
+  }
   const dir = dirname(path);
 
   mkdirSync(dir, { recursive: true });

package/rebuild-indexes.js

@@ -281,13 +281,29 @@ export function rebuildIndexes(repoRoot, options = {}) {
 
   // --- latest-by-repo.json ---
   // Keyed by repo, then product_surface. Only accepted records count.
-  const latestByRepo = {};
+  //
+  // F-89b7dcd5: `record.repo` and `sr.product_surface` come from loadRecord()
+  // (JSON.parse only, no schema gate — see its JSDoc) rather than validated
+  // submission input, so a hand-committed record with repo: '__proto__' would
+  // otherwise resolve `latestByRepo['__proto__']` to Object.prototype itself
+  // (truthy, on a plain `{}`), skip the init branch below, and land the
+  // surface write ON Object.prototype — real global prototype pollution for
+  // the rest of this process. Object.create(null) removes the prototype
+  // chain entirely: `latestByRepo['__proto__']` is a plain (absent) data
+  // property, not the special accessor. JSON.stringify (below, at the
+  // commitGroupRename call) serializes a null-prototype object identically
+  // to a plain one, so this costs nothing on the write side. Not reachable
+  // from the ingest write path today (writeRecord's validateRecord() gate
+  // constrains repo's shape before persist.js ever writes a file), so this
+  // is defense-in-depth against a hand-committed or otherwise out-of-band
+  // record file, not a live vulnerability.
+  const latestByRepo = Object.create(null);
 
   for (const record of allRecords) {
     if (record.verification?.status !== 'accepted') continue;
 
     const repo = record.repo;
-    if (!latestByRepo[repo]) latestByRepo[repo] = {};
+    if (!latestByRepo[repo]) latestByRepo[repo] = Object.create(null);
 
     for (const sr of record.scenario_results || []) {
       const surface = sr.product_surface;

package/run.js

@@ -25,7 +25,8 @@ import { verify } from '@dogfood-lab/verify';
 import { stubProvenance, provenanceForProvider } from '@dogfood-lab/verify/validators/provenance.js';
 import { logStage as sharedLogStage } from '@dogfood-lab/dogfood-swarm/lib/log-stage.js';
 import { loadGlobalPolicy, loadRepoPolicy, loadScenarios, githubScenarioFetcher } from './load-context.js';
-import { isDuplicate, writeRecord, computeRecordPath } from './persist.js';
+import { isDuplicate, writeRecord, computeRecordPath, UnsafeRecordPathError } from './persist.js';
+import { RecordValidationError } from './validate-record.js';
 import { rebuildIndexes } from './rebuild-indexes.js';
 import { verifyChain, formatChainResult } from './verify-chain.js';
 import { handleAnchorCompute, handleAnchorPost, handleAnchorVerify } from './anchor/cli.js';
@@ -350,7 +351,40 @@ export async function ingest(submission, options) {
       timing: submission.timing,
       verification: { status: 'accepted' }
     };
-    if (isDuplicate(submission.run_id, probeRecord, repoRoot)) {
+    // F-f8952a50 (wave 10): this probe's hardcoded `status: 'accepted'` is
+    // ALSO the site the finding proved a corrected repo:mismatch resubmission
+    // was swallowed at — isDuplicate() only asks isRetryableRejection() when
+    // the record it's handed claims 'accepted' (see isDuplicate's own
+    // comment), so this probe is the FIRST place a stale non-schema rejection
+    // could mask a genuine correction, before verify() ever runs. No separate
+    // fix belongs HERE, though: this probe and writeRecord()'s own internal
+    // isDuplicate() call (persist.js) share the exact same isDuplicate() /
+    // isRetryableRejection() code path, so persist.js's per-prefix
+    // `retryable` fix (parse-rejection.js) already reaches both call sites —
+    // widening retryability there is what unblocks this probe too, with
+    // nothing probe-specific to change.
+    // F-a37d36f5: isDuplicate -> computeRecordPath runs against RAW untrusted
+    // submission.repo/run_id, three steps BEFORE verify()'s schema gate. A
+    // malformed repo ('a/b/c', a path-traversal attempt, etc.) makes
+    // computeRecordPath THROW ('invalid repo format' / 'unsafe repo segment'
+    // / 'unsafe run_id') — good, the traversal guards hold — but letting that
+    // throw escape here inverts this repo's submission-bad vs operational
+    // doctrine: it propagates as an uncaught fault (exit 2, "operator error"
+    // per the CLI's own USAGE block) for input that is squarely the
+    // SUBMITTER's to fix, and no `_rejected` evidence record is ever
+    // written. A malformed repo/run_id can never collide with an existing
+    // record anyway, so treating an unpathable submission as "not a
+    // duplicate" is semantically free — verify()'s schema gate is the
+    // authoritative judge of bad input, and writeRecord's own
+    // computeRecordPath (which runs AFTER validateRecord, on the SCHEMA-
+    // VALIDATED persisted record) remains the real enforcement point.
+    let duplicate;
+    try {
+      duplicate = isDuplicate(submission.run_id, probeRecord, repoRoot);
+    } catch {
+      duplicate = false;
+    }
+    if (duplicate) {
       logStage('rejected_pre_persist', {
         submission_id: submissionId,
         correlation_id,
@@ -463,7 +497,72 @@ export async function ingest(submission, options) {
     return { record, path: null, written: false, duplicate: false };
   }
   const persistStart = Date.now();
-  const { path, written } = writeRecord(record, repoRoot);
+  let path, written;
+  try {
+    ({ path, written } = writeRecord(record, repoRoot));
+  } catch (err) {
+    // F-4acd28d8: computeRecordPath()'s traversal guard (isUnsafeSegment) is
+    // STRICTER than the submission schema's repo pattern (F-bbbe2e1f — e.g.
+    // `../etc` is schema-valid but traversal-unsafe), so a record can reach
+    // here without `_skipPersist` ever having been set. The record's own
+    // identifier is what's unfilable — submission-bad, not an operator
+    // incident — so route it like `_skipPersist` above instead of letting the
+    // throw reach the outer CLI catch, which would misreport it as
+    // failed_stage:'cli_parse_payload' and exit 2 ("operator error") for
+    // content that is squarely the submitter's to fix.
+    //
+    // RecordValidationError is the SIBLING gap F-4036ae25's _skipPersist
+    // narrowing opens: dogfood-record.schema.json mirrors the submission
+    // schema's constraints on every source-authored field verify() copies
+    // verbatim (ref, source, timing, scenario_results, overall_verdict.proposed),
+    // so a submission that is schema-invalid on one of THOSE fields (not just
+    // repo/run_id/timing.finished_at) reaches writeRecord() filable-by-identity
+    // and still fails validateRecord() here. Only catch it when the submission
+    // was ALREADY schema-invalid (record.verification.schema_valid === false)
+    // — that is the authoritative signal this is submission-bad fallout, not a
+    // genuine internal defect in what verify() assembled for an
+    // otherwise-valid submission, which must keep crashing loudly.
+    const isUnfilableRecordPath = err instanceof UnsafeRecordPathError;
+    const isSubmissionBadRecordShape =
+      err instanceof RecordValidationError && record.verification.schema_valid === false;
+    if (!isUnfilableRecordPath && !isSubmissionBadRecordShape) {
+      throw err;
+    }
+
+    // verify() already rejected this submission for a real reason whenever
+    // one exists (e.g. repo:mismatch, or the schema violation itself) — those
+    // reasons survive untouched. When verify() had no reason to reject (an
+    // otherwise-accepted record whose ONLY problem is storage-unsafety),
+    // downgrade the verdict here — the same shape used below for a late
+    // scenario-load rejection.
+    if (isUnfilableRecordPath) {
+      record.verification.rejection_reasons.push(`unsafe-record-path: ${err.message}`);
+      if (record.verification.status === 'accepted') {
+        record.verification.status = 'rejected';
+        record.verification.policy_valid = false;
+        if (record.overall_verdict.verified === 'pass') {
+          record.overall_verdict.verified = 'fail';
+          record.overall_verdict.downgraded = true;
+          if (!record.overall_verdict.downgrade_reasons) {
+            record.overall_verdict.downgrade_reasons = [];
+          }
+          record.overall_verdict.downgrade_reasons.push('record path could not be safely computed');
+        }
+      }
+    }
+
+    logStage('rejected_pre_persist', {
+      submission_id: submissionId,
+      correlation_id,
+      reason: isUnfilableRecordPath ? 'unsafe_record_path' : 'record_schema_invalid_from_submission',
+      rejection_reasons: record.verification.rejection_reasons ?? [],
+      // Operator-debug only: validateRecord()'s OWN structured errors, distinct
+      // from (and not merged into) the submitter-facing rejection_reasons above,
+      // which stay exactly as verify() computed them against the submission schema.
+      ...(isSubmissionBadRecordShape ? { record_validation_errors: err.errors } : {})
+    });
+    return { record, path: null, written: false, duplicate: false };
+  }
   logStage('persist_complete', {
     submission_id: submissionId,
     correlation_id,
@@ -525,7 +624,20 @@ export async function ingest(submission, options) {
     }
   }
 
-  return { record, path, written, duplicate: false };
+  // F-7b97fbd4 (wave 10): mirror persist_complete's OWN `duplicate: !written`
+  // (logged a few lines above, off the same `written`) instead of a bare
+  // `false` that silently disagreed with it. By this point `written` can be
+  // `false` for exactly one reason — writeRecord()'s internal isDuplicate()
+  // blocked the write as a collision (persist.js) — every OTHER
+  // non-persisting outcome in this function (record._skipPersist above; the
+  // UnsafeRecordPathError / RecordValidationError catch above that) already
+  // returns its own honest `duplicate: false` earlier and never reaches this
+  // line. The CLI wrapper's `if (result.duplicate)` branch depends on this
+  // being accurate: a blocked resubmission must take the terse exit-0
+  // `{status:'duplicate'}` path, the same one an early-detected duplicate
+  // (the pre-verify probe above) already takes, not fall through to the
+  // full rejected-record exit-1 shape.
+  return { record, path, written, duplicate: !written };
 }
 
 /**
@@ -664,10 +776,12 @@ export async function verifyOnly(submission, options) {
       would_persist_to = computeRecordPath(record, repoRoot);
     } catch {
       // Defensive: if a record passes verify() but still trips path
-      // computation (e.g., a future schema with looser constraints), keep
-      // verify-only side-effect-free. Real ingest would surface the throw
-      // via writeRecord; verify-only just returns null and lets the operator
-      // see the rejection in record.verification.rejection_reasons.
+      // computation (e.g. F-bbbe2e1f's `../etc` — schema-valid but
+      // traversal-unsafe), keep verify-only side-effect-free. Real ingest
+      // hits the SAME underlying computeRecordPath failure inside
+      // writeRecord() but now catches it too (F-4acd28d8, UnsafeRecordPathError)
+      // rather than letting it escape; verify-only just returns null here and
+      // lets the operator see the rejection in record.verification.rejection_reasons.
       would_persist_to = null;
     }
   }
@@ -719,27 +833,30 @@ function emitCliErrorEvent({ failedStage, correlationId, submissionId = null, er
 // to live IN the tool, not scattered across docs.
 const USAGE = `ingest — persist a dogfood submission (verify → policy → provenance → write)
 
-USAGE:
+Usage:
   node packages/ingest/run.js --file <path>   --provenance=github|stub
   node packages/ingest/run.js --payload '<json>' --provenance=github|stub
   echo '<json>' | node packages/ingest/run.js --provenance=github|stub
 
-INPUT (exactly one; stdin used when neither flag is given):
+Input (exactly one; stdin used when neither flag is given):
   --file <path>        Read the submission JSON from a file.
   --payload <json>     Pass the submission JSON inline.
   (stdin)              Pipe the submission JSON on stdin.
 
-PROVENANCE (required for an ingest):
+Provenance (required for an ingest):
   --provenance=github  Confirm the source run via the GitHub API.
   --provenance=stub    No-network local confirm (dry-run / dev only).
 
-MODES:
+Modes:
   --verify-only        Run the full pipeline WITHOUT writing or rebuilding
                        indexes; report where a real ingest WOULD have landed.
 
-STANDALONE AUDIT VERBS (no submission, no stdin, no --provenance):
+Standalone audit verbs (no submission, no stdin, no --provenance):
   --verify-chain       Verify the append-only integrity ledger (offline).
-    --reconcile        Also fail on on-disk records missing from the ledger.
+    --reconcile        Also fail on genuine torn-write orphans (on-disk records
+                       missing from the ledger). Records that predate the
+                       integrity chain itself are reported separately and do
+                       not fail the audit.
     --all              Report every independent break instead of the first.
   --anchor-compute     Compute + write the next XRPL anchor manifest (offline).
   --anchor-post        Compute if needed + post the anchor to XRPL (needs XRPL_SEED).
@@ -747,7 +864,7 @@ STANDALONE AUDIT VERBS (no submission, no stdin, no --provenance):
 
   -h, --help           Show this help.
 
-EXIT CODES:
+Exit codes:
   0  success     1  integrity/audit break     2  operator error (flags / IO / JSON)`;
 
 const isMain = process.argv[1] && resolve(process.argv[1]) === resolve(__dirname, 'run.js');
@@ -820,9 +937,38 @@ if (isMain) {
     const hasValue = inlineValue !== null || nextIsValue;
     const takeValue = () => (inlineValue !== null ? inlineValue : args[++i]);
 
-    if (arg === '--provenance' && hasValue) {
+    // F-e0bcbc47 (amended wave 29, after the first attempt regressed
+    // F-INGEST-003): `flagIs(name)` both TESTS the token and RECORDS that
+    // `name` is a flag this chain knows about, so the catch-all below can tell
+    // "unknown flag" (no branch knows this name) apart from "known flag, no
+    // value" (a branch knows the name but its `&& hasValue` guard failed —
+    // exactly what F-INGEST-003 causes for `--anchor-network --anchor-compute`).
+    // The first attempt at this fix had a bare `else if (arg.startsWith('--'))`
+    // catch-all that could not distinguish the two and so reported a KNOWN flag
+    // as "unknown argument: --anchor-network" — a claim wider than what it
+    // actually checked, which is the exact class this repo keeps paying for.
+    //
+    // `knownFlagName` is DERIVED from the chain itself rather than duplicated
+    // into a second list of flag names: the only way a name enters the known
+    // set is for the chain to literally test for it one line below. A parallel
+    // `KNOWN_FLAGS` enumeration would be a second population to keep in sync
+    // (the same enumeration-vs-property class as CONTROL_CLASS / ZALGO_RUN /
+    // DASH_CONFUSABLES), and it would drift the first time someone adds a flag
+    // and forgets the list. Adding a branch here cannot desync it — the branch
+    // IS the registration. The one residual shape is a future branch written as
+    // a bare `arg === '--new'` instead of `flagIs('--new')`; that would make the
+    // new flag report as unknown when dangling, and is guarded by
+    // f-e0bcbc47-unknown-flag-rejection.test.js's chain-shape assertion.
+    let knownFlagName = false;
+    const flagIs = (name) => {
+      if (arg !== name) return false;
+      knownFlagName = true;
+      return true;
+    };
+
+    if (flagIs('--provenance') && hasValue) {
       provenanceMode = takeValue();
-    } else if (arg === '--file' && hasValue) {
+    } else if (flagIs('--file') && hasValue) {
       const { readFileSync } = await import('node:fs');
       // D1B-001 family (operator-legibility): a --file read failure
       // (ENOENT/EACCES) routes through the structured error event and exits 2
@@ -842,53 +988,103 @@ if (isMain) {
         });
         process.exit(2);
       }
-    } else if (arg === '--payload' && hasValue) {
+    } else if (flagIs('--payload') && hasValue) {
       submissionJson = takeValue();
-    } else if (arg === '--verify-only') {
+    } else if (flagIs('--verify-only')) {
       // F-252714-058: dry-run the pipeline without writing or rebuilding
       // indexes. CI / operators preview what WOULD have been persisted.
       verifyOnlyFlag = true;
-    } else if (arg === '--verify-chain') {
+    } else if (flagIs('--verify-chain')) {
       // Integrity chain v1: verify the append-only tamper-evident ledger at
       // indexes/integrity/chain.jsonl, fully offline. No submission, no stdin,
       // no provenance — a standalone audit command.
       verifyChainFlag = true;
-    } else if (arg === '--reconcile') {
+    } else if (flagIs('--reconcile')) {
       // Modifier for --verify-chain: also reconcile on-disk records against the
       // ledger and fail on any orphan (INGEST-PROACT-001).
       reconcileFlag = true;
-    } else if (arg === '--all') {
+    } else if (flagIs('--all')) {
       // Modifier for --verify-chain: report every per-record-independent break
       // instead of stopping at the first (INGEST-PROACT-004).
       allBreaksFlag = true;
-    } else if (arg === '--anchor-compute') {
+    } else if (flagIs('--anchor-compute')) {
       // Optional XRPL anchor: compute + write the next anchor manifest. Offline.
       anchorComputeFlag = true;
-    } else if (arg === '--anchor-post') {
+    } else if (flagIs('--anchor-post')) {
       // Optional XRPL anchor: compute if needed + post to XRPL. Needs the
       // optional xrpl package (lazily loaded) and XRPL_SEED.
       anchorPostFlag = true;
-    } else if (arg === '--anchor-verify') {
+    } else if (flagIs('--anchor-verify')) {
       // Optional XRPL anchor: verify local manifests + run the truncation check.
       // Offline reports honest NOT-verified for the on-chain leg.
       anchorVerifyFlag = true;
-    } else if (arg === '--anchor-all') {
+    } else if (flagIs('--anchor-all')) {
       // Genesis snapshot mode for compute/post (covers the whole chain).
       anchorMode = 'all';
-    } else if (arg === '--anchor-algo' && hasValue) {
+    } else if (flagIs('--anchor-algo') && hasValue) {
       anchorAlgo = takeValue();
-    } else if (arg === '--anchor-network' && hasValue) {
+    } else if (flagIs('--anchor-network') && hasValue) {
       anchorNetwork = takeValue();
-    } else if (arg === '--anchor-tx' && hasValue) {
+    } else if (flagIs('--anchor-tx') && hasValue) {
       // Path to a JSON file containing a fetched XRPL tx (with Memos) for the
       // on-chain leg of --anchor-verify. Offline-honest: omit it to run the
       // truncation check only.
       anchorTxFile = takeValue();
-    } else if (arg === '--anchor-trusted' && hasValue) {
+    } else if (flagIs('--anchor-trusted') && hasValue) {
       // Comma-separated trusted anchor accounts (UNIONed with the bundled list).
       anchorTrustedAccounts = takeValue().split(',').map((s) => s.trim()).filter(Boolean);
-    } else if (arg === '-h' || arg === '--help' || arg === '--usage') {
+    } else if (flagIs('-h') || flagIs('--help') || flagIs('--usage')) {
       helpFlag = true;
+    } else if (arg.startsWith('--') && knownFlagName) {
+      // F-e0bcbc47 / F-INGEST-003 boundary: a KNOWN flag whose `&& hasValue`
+      // guard failed — i.e. a value flag given no value, because the next
+      // token was itself a flag (`--anchor-network --anchor-compute`) or it
+      // ended argv. F-INGEST-003 pins that the FOLLOWING flag is still parsed
+      // on its own rather than swallowed as this one's value, so this token
+      // keeps its historical path (fall through to positionalArgs, continue)
+      // and `--anchor-compute` runs. Rejecting here instead would break that
+      // pinned contract.
+      //
+      // RESIDUAL, STATED (not fixed here): the dangling flag is still
+      // IGNORED — `--anchor-network` with no value does not set the network
+      // and does not fail the run. That is pre-existing behavior and this
+      // amend does not change it. What changes is that it is no longer
+      // SILENT: an operator gets a structured warn naming the flag instead of
+      // the value vanishing with no trace. Making it a hard error is a real
+      // contract change (it would stop `--anchor-compute` from running and
+      // rewrite F-INGEST-003's pin), which is a bigger claim than a Stage C
+      // humanization amend should make unilaterally — filed as a follow-up
+      // rather than landed here.
+      logStage('warn', {
+        kind: 'cli_flag_missing_value',
+        flag: arg,
+        correlation_id: synthCorrelationId(),
+        message: `${arg} was given no value and is being ignored (the next token is a flag, not a value)`
+      });
+      positionalArgs.push(args[i]);
+    } else if (arg.startsWith('--')) {
+      // F-e0bcbc47 (Stage C humanization): a genuinely unrecognized `--flag`
+      // — no branch above knows this name at all. It used to fall through to
+      // the dead `positionalArgs` sink (declared, pushed to, and never read
+      // anywhere else in this file — confirmed by grep) and the CLI proceeded
+      // to read stdin, hit EOF, and crashed with a raw 'Unexpected end of
+      // JSON input' stack that misattributed the failure to the submission
+      // payload rather than the misspelled flag (live-proven trigger:
+      // `--provenance=stub --fiel <path>`, a one-character typo of --file).
+      // Reject at the point of the typo instead — matches the sibling pattern
+      // already correct in this same domain (packages/verify/cli.js:
+      // `unknown argument: --version` -> exit 2, no stack, no fallthrough).
+      // Scoped to `--`-prefixed tokens only (a bare positional stays in the
+      // historical positionalArgs sink) because that is exactly the shape a
+      // mistyped flag takes, and it is the shape the reachable repro above
+      // hits BEFORE any value token is even read.
+      emitCliErrorEvent({
+        failedStage: 'cli_parse_args',
+        correlationId: synthCorrelationId(),
+        err: new Error(`unknown argument: ${arg}`),
+        humanPrefix: 'invalid CLI invocation'
+      });
+      process.exit(2);
     } else {
       positionalArgs.push(args[i]);
     }
@@ -923,7 +1119,12 @@ if (isMain) {
       // operator asked for it, so a grep of the NDJSON shows how many breaks and
       // orphans were found, not just the first break.
       ...(Array.isArray(result.breaks) ? { break_count: result.breaks.length } : {}),
-      ...(Array.isArray(result.orphans) ? { orphan_count: result.orphans.length } : {})
+      ...(Array.isArray(result.orphans) ? { orphan_count: result.orphans.length } : {}),
+      // F-29134790: pre-adoption records are excluded from chain_ok but still
+      // worth a grep-able count — an operator diffing orphan_count over time
+      // should see the pre-chain figure hold steady while orphan_count reflects
+      // only genuine torn writes.
+      ...(Array.isArray(result.pre_adoption) ? { pre_adoption_count: result.pre_adoption.length } : {})
     });
     const lines = formatChainResult(result);
     if (result.ok) {

package/verify-chain.js

@@ -27,6 +27,17 @@
  * push that touched a record but not the chain), and it catches middle-deletion,
  * reorder, and forged-insertion (they break the seq run or the prev-link).
  *
+ * The `pre_adoption` exemption inside collectOrphanRecords (below) narrows the
+ * "push that touched a record but not the chain" promise one step further: it
+ * excuses an un-ledgered, no-integrity record from `ok` only when the record's
+ * OWN claimed timing.finished_at/verification.verified_at predates
+ * CHAIN_ADOPTION_DATE (F-1907b2bc, wave 14), so dropping a record with a
+ * fabricated RECENT date is still caught as a genuine orphan. Dropping one with
+ * a fabricated OLD date is not caught — that record is indistinguishable from
+ * genuine history, because both are self-reported fields the same privileged
+ * writer controls. That residual is the SAME already-disclosed ingest-write-
+ * credential trust boundary named two paragraphs up, not a new one.
+ *
  * KNOWN LIMITATION — tail truncation. Removing the most-recent entries (and
  * their record files) leaves a SHORTER but internally-consistent chain, which
  * verifies OK: the offline verifier has no external record of the expected head
@@ -72,7 +83,16 @@ import { findJsonFiles } from './rebuild-indexes.js';
  * @property {ChainBreak[]} [breaks] - All independent breaks (only present when
  *   `collectAllBreaks` is set). The first element equals `break`.
  * @property {ChainOrphan[]} [orphans] - Records on disk but absent from the
- *   ledger (only present when `collectOrphans` is set).
+ *   ledger AND written by chain-aware code (only present when `collectOrphans`
+ *   is set). These are genuine torn writes — persist-succeeded, ledger-append-
+ *   missed — and they make `ok` false.
+ * @property {ChainOrphan[]} [pre_adoption] - Records on disk but absent from
+ *   the ledger that predate the chain's adoption: no `integrity` block AND a
+ *   self-reported timing.finished_at/verification.verified_at before
+ *   CHAIN_ADOPTION_DATE (F-1907b2bc — a no-integrity record whose own claimed
+ *   timestamp is on/after that date is a genuine `orphans` entry instead;
+ *   only present when `collectOrphans` is set). Visible for operator
+ *   awareness; does NOT make `ok` false.
  */
 
 /**
@@ -93,6 +113,10 @@ import { findJsonFiles } from './rebuild-indexes.js';
  *   ledger (a torn write between record-write and ledger-append). An orphan
  *   makes the result `ok: false` — the audit DETECTS the orphan instead of
  *   silently passing while a real record lives outside the tamper-evident chain.
+ *   F-29134790 (wave 12): also returns `pre_adoption[]` — records absent from
+ *   the ledger that predate the chain's existence entirely (see
+ *   collectOrphanRecords's adoption-boundary doc below). Pre-adoption records
+ *   are visible for operator awareness but do NOT affect `ok`.
  * @returns {ChainVerifyResult}
  */
 export function verifyChain(repoRoot, opts = {}) {
@@ -112,7 +136,10 @@ export function verifyChain(repoRoot, opts = {}) {
       head_digest: GENESIS_DIGEST,
       break: brk,
       ...(collectAllBreaks ? { breaks: [brk] } : {}),
-      ...(collectOrphans ? { orphans: [] } : {}),
+      // pre_adoption included alongside orphans (both empty here) so the
+      // result shape is consistent whenever collectOrphans is set, regardless
+      // of which early-return path produced it.
+      ...(collectOrphans ? { orphans: [], pre_adoption: [] } : {}),
     };
   }
 
@@ -191,8 +218,12 @@ export function verifyChain(repoRoot, opts = {}) {
     prevDigest = entry.submission_digest;
   }
 
-  const orphans = collectOrphans ? collectOrphanRecords(repoRoot, entries) : null;
+  const reconciled = collectOrphans ? collectOrphanRecords(repoRoot, entries) : null;
+  const orphans = reconciled ? reconciled.orphans : null;
+  const preAdoption = reconciled ? reconciled.preAdoption : null;
 
+  // Only genuine orphans (post-adoption, ledger-eligible records) affect ok.
+  // pre_adoption is informational — see collectOrphanRecords's doc comment.
   const ok = breaks.length === 0 && (orphans === null || orphans.length === 0);
   return {
     ok,
@@ -200,36 +231,168 @@ export function verifyChain(repoRoot, opts = {}) {
     head_digest: headDigest,
     break: breaks.length > 0 ? breaks[0] : null,
     ...(collectAllBreaks ? { breaks } : {}),
-    ...(collectOrphans ? { orphans } : {}),
+    ...(collectOrphans ? { orphans, pre_adoption: preAdoption } : {}),
   };
 }
 
+/**
+ * The commit that gave persist.js's writeRecord its UNCONDITIONAL
+ * integrity-stamping logic — f4ca987 "feat(integrity): tamper-evident hash
+ * chain over records/", 2026-06-21T18:35:36-04:00 (2026-06-21T22:35:36Z).
+ * Every record genuinely written by writeRecord() from this date onward
+ * carries a fully-formed `integrity` block; a record with none at all can
+ * only predate it — see collectOrphanRecords' F-1907b2bc doc paragraph below.
+ *
+ * Set to the START of the commit's UTC calendar day, not its exact
+ * timestamp, so the boundary errs toward NOT excusing a borderline record
+ * (the fail-loud direction) rather than toward hair-splitting a commit
+ * second no real record is anywhere near — the actual gap in this repo's own
+ * history is five weeks wide (last genuine pre-chain record 2026-05-26,
+ * first genuine ledgered record 2026-07-03; see F-29134790's doc paragraph
+ * below), so this constant has a wide margin on both sides.
+ */
+export const CHAIN_ADOPTION_DATE = new Date('2026-06-21T00:00:00Z');
+
+/**
+ * The later of a record's own self-reported `timing.finished_at` /
+ * `verification.verified_at`, or `null` when neither is present and
+ * parseable. F-1907b2bc: used only to sanity-check a would-be `preAdoption`
+ * bucketing — this is NOT a trust boundary (the same privileged writer that
+ * can drop a record with no `integrity` block can also forge these fields;
+ * see the top-of-file threat-model paragraph). It only stops the tool from
+ * asserting "predates the chain" when the record's own data already
+ * contradicts that claim, or supports no claim at all.
+ *
+ * F-a85b7e84 (wave 16, LOW): a candidate must be a `string` before it is
+ * handed to `new Date()`. JSON has no Date type — every field a real
+ * writeRecord() call ever produces here is a string (Date.prototype.toJSON
+ * always serializes to one) or absent — so `typeof value === 'string'` costs
+ * nothing against genuine records. Without it, `new Date()`'s permissive
+ * ToPrimitive coercion accepts non-date JSON values that a bare falsy check
+ * (`if (!value) continue`) does not filter out: `new Date(true)` coerces the
+ * boolean to the number 1 (1970-01-01T00:00:00.001Z), a bare integer is read
+ * as an epoch-millisecond offset, and an array's comma-joined
+ * `toString()` (e.g. `[2026, 3, 1]` -> `'2026,3,1'`) fallback-parses as a
+ * real date — all landing well before CHAIN_ADOPTION_DATE with none of the
+ * "type a plausible fake ISO string" effort the surviving forgery residual
+ * (this function's own doc paragraph above) assumes. A non-string value now
+ * falls through to the same "no readable timestamp" orphan branch as an
+ * absent field, exactly like an unparseable string already did.
+ *
+ * @param {object} record
+ * @returns {Date|null}
+ */
+function latestClaimedTimestamp(record) {
+  const candidates = [record.timing?.finished_at, record.verification?.verified_at];
+  let latest = null;
+  for (const value of candidates) {
+    if (typeof value !== 'string') continue;
+    const parsed = new Date(value);
+    if (isNaN(parsed.getTime())) continue;
+    if (latest === null || parsed.getTime() > latest.getTime()) latest = parsed;
+  }
+  return latest;
+}
+
 /**
  * INGEST-PROACT-001 — reconcile on-disk records against the ledger.
  *
  * Walks every `*.json` under `records/` (accepted AND `_rejected/`) and flags
- * any record file whose `(run_id, seq)` identity is absent from the ledger.
- * Such a file is an ORPHAN: persist wrote the record but the ledger append did
- * not happen (a crash in the torn window between the two steps), so the record
+ * any record file whose repo-relative PATH is absent from the ledger. Such a
+ * file is an ORPHAN: persist wrote the record but the ledger append did not
+ * happen (a crash in the torn window between the two steps), so the record
  * exists OUTSIDE the tamper-evident chain and the plain chain-walk is blind to
  * it. The chain-manifest's own ledger lines are NOT under `records/`, so they
  * are never mistaken for orphans.
  *
+ * F-d4bcf5d0 (wave 10, HIGH): this used to ALSO fall back to a run_id-only
+ * match — "a record is accounted for if EITHER its path OR its run_id is
+ * ledgered anywhere". That fallback was unsound: a single run_id can
+ * legitimately own TWO on-disk records at TWO different paths (the
+ * accepted-after-a-prior-rejection resubmission flow persist.js's
+ * isRetryableRejection carve-out exists for — see
+ * F-0f9e4077/F-4036ae25/F-f8952a50), each needing its OWN ledger line. Once
+ * ANY entry for a run_id was ledgered, the fallback treated EVERY later
+ * record sharing that run_id as accounted for — including one at a
+ * genuinely un-ledgered path, exactly the torn-write shape this
+ * reconciliation pass exists to catch (proven live: a ledgered `_rejected`
+ * record followed by an accepted record for the SAME run_id whose OWN
+ * ledger line was then lost — the plain run_id match hid the orphan).
+ * Path identity is both the necessary AND the sufficient check: every ledger
+ * line carries an exact `path` field (lib/chain-manifest.js's documented
+ * line shape, always populated by persist.js's appendChainEntry call), and
+ * this function's own `relPath` computation (`relative(repoRoot,
+ * absPath).split(sep).join('/')`) is the identical normalization persist.js
+ * uses to produce that field. Dropping the run_id fallback removes the
+ * unsound generalization without weakening real coverage — see
+ * ingest-proact-001-004-verify-chain-reconcile-allbreaks.test.js's
+ * 'shared run_id, different paths' regression test.
+ *
+ * F-29134790 (wave 12, HIGH): path-identity membership is correct for records
+ * the chain COULD have ledgered, but on its own it has no ADOPTION BOUNDARY —
+ * every un-ledgered path reads identically, so a record that predates the
+ * chain feature's existence is indistinguishable from a genuine crash-window
+ * torn write. Proven live against this repo's own `records/` tree: 53 files
+ * with no ledger line, every one dated 2026-03-19 through 2026-05-26 — all
+ * BEFORE persist.js gained its integrity-stamping logic (f4ca987,
+ * 2026-06-21) — versus the 7 real ledgered records, all dated 2026-07-03
+ * onward. Pre-fix, `verifyChain({ collectOrphans: true })` reported all 53 as
+ * indistinguishable "torn persist" orphans (a 53:0 signal-to-noise ratio; a
+ * genuine orphan today would be the 54th unlabeled line).
+ *
+ * The fix needs no new marker file or backfill tool: persist.js's writeRecord
+ * already stamps `record.integrity = { submission_digest, prev_digest, seq }`
+ * UNCONDITIONALLY, in memory, BEFORE it writes the record file and BEFORE it
+ * appends the ledger line (see persist.js — the stamp happens ahead of
+ * validateRecord() and the atomic file write). That ordering guarantees a
+ * genuine post-adoption torn write (file landed, ledger append lost) still
+ * carries a fully-formed `integrity` block on disk; only a record written
+ * before persist.js gained this stamping logic can lack one entirely. So
+ * "does this record carry an `integrity` block" is not a proxy for the
+ * adoption boundary — it IS the adoption boundary, already recorded per-record
+ * by the exact code change that introduced the chain, for free. A record
+ * missing `integrity` is bucketed into the returned `preAdoption` array
+ * (visible, does not fail `ok`); a record WITH an `integrity` block that is
+ * still un-ledgered remains a genuine `orphans` entry exactly as before.
+ *
+ * F-1907b2bc (wave 14, MEDIUM): the paragraph above treats "does this record
+ * carry an `integrity` block" as the WHOLE adoption boundary, but that
+ * equivalence only holds for records that actually passed through the real
+ * writeRecord(). A record dropped directly onto disk — bypassing writeRecord
+ * entirely — also has no `integrity` block, and pre-fix was silently
+ * absorbed into `preAdoption` with a "predates the chain" reason string that
+ * is provably FALSE whenever the dropped record's own claimed timestamp is on
+ * or after CHAIN_ADOPTION_DATE (persist.js has stamped `integrity`
+ * UNCONDITIONALLY on every record it writes since that date — see the
+ * constant's doc comment above — so a record genuinely written from then on
+ * could not lack one). The fix cross-checks a would-be `preAdoption` record's
+ * own `timing.finished_at`/`verification.verified_at` (the later of the two
+ * — see `latestClaimedTimestamp`) against CHAIN_ADOPTION_DATE before
+ * accepting the "predates the chain" narrative; a record with no verifiable
+ * timestamp of its own, or one on/after the cutoff, is bucketed into
+ * `orphans` instead, with a reason string honest about why. This closes the
+ * LOW-effort version of dropping a forged record (not bothering to fake a
+ * plausible pre-adoption date) but not a DILIGENT one that also forges an old
+ * timing/verification block — no purely offline, record-content-based check
+ * can tell a forged old date from a genuine one; see the threat-model
+ * paragraph at the top of this file.
+ *
  * @param {string} repoRoot
  * @param {Array<object>} entries - The ledger entries (already read).
- * @returns {ChainOrphan[]}
+ * @returns {{ orphans: ChainOrphan[], preAdoption: ChainOrphan[] }} `orphans`
+ *   are un-ledgered records stamped by chain-aware code — genuine torn
+ *   writes. `preAdoption` are un-ledgered records with no `integrity` block —
+ *   they predate the chain and were never ledgerable. Only `orphans` affects
+ *   verifyChain's `ok`.
  */
 function collectOrphanRecords(repoRoot, entries) {
-  // Index the ledger by run_id and by repo-relative path so a record matches if
-  // EITHER identity is present — a record is ledgered as long as its line exists.
-  const ledgerRunIds = new Set();
   const ledgerPaths = new Set();
   for (const e of entries) {
-    if (e.run_id) ledgerRunIds.add(e.run_id);
     if (e.path) ledgerPaths.add(e.path);
   }
 
   const orphans = [];
+  const preAdoption = [];
   const recordsDir = join(repoRoot, 'records');
   for (const absPath of findJsonFiles(recordsDir)) {
     const relPath = relative(repoRoot, absPath).split(sep).join('/');
@@ -240,7 +403,9 @@ function collectOrphanRecords(repoRoot, entries) {
       record = JSON.parse(readFileSync(absPath, 'utf-8'));
     } catch {
       // A record file we cannot even parse, that is also absent from the ledger,
-      // is still an orphan — report it with what little identity we have.
+      // is still an orphan — report it with what little identity we have. We
+      // cannot read `.integrity` to classify it as pre-adoption either, so this
+      // fails loud rather than being silently excused.
       orphans.push({
         run_id: null,
         seq: null,
@@ -250,11 +415,67 @@ function collectOrphanRecords(repoRoot, entries) {
       continue;
     }
 
-    const runId = record.run_id ?? null;
-    if (runId && ledgerRunIds.has(runId)) continue;
+    // A value that parses but is not a plain record object (null, an array, a
+    // bare primitive) is not something we can read `.integrity` off to
+    // classify as pre-adoption. Mirroring the not-valid-JSON branch above:
+    // when we cannot positively identify what the record actually IS, fail
+    // loud as a genuine orphan rather than silently excusing it into
+    // preAdoption — the adoption boundary is a claim we can only make about
+    // something shaped like a record.
+    if (record === null || typeof record !== 'object' || Array.isArray(record)) {
+      orphans.push({
+        run_id: null,
+        seq: null,
+        path: relPath,
+        reason: `record file present on disk but absent from the ledger, and its JSON content is not a record object`,
+      });
+      continue;
+    }
+
+    // Adoption boundary — see the F-29134790 doc paragraph above. "No
+    // integrity block" is NECESSARY for pre-adoption but, on its own, not
+    // SUFFICIENT — see the F-1907b2bc doc paragraph above. Cross-check the
+    // record's own claimed timestamp against CHAIN_ADOPTION_DATE before
+    // accepting the "predates the chain" narrative.
+    if (record.integrity == null) {
+      const claimedAt = latestClaimedTimestamp(record);
+      const isPreAdoption = claimedAt !== null && claimedAt.getTime() < CHAIN_ADOPTION_DATE.getTime();
+
+      if (isPreAdoption) {
+        preAdoption.push({
+          run_id: record.run_id ?? null,
+          seq: null,
+          path: relPath,
+          reason:
+            `record predates the integrity chain (no integrity block — written ` +
+            `before tamper-evident chaining was introduced); expected for ` +
+            `historical records, not counted as an audit failure.`,
+        });
+        continue;
+      }
+
+      orphans.push({
+        run_id: record.run_id ?? null,
+        seq: null,
+        path: relPath,
+        reason: claimedAt === null
+          ? `record has no integrity block, and no readable timing.finished_at ` +
+            `or verification.verified_at either — its "predates the chain" claim ` +
+            `cannot be supported by anything on the record itself, so it is ` +
+            `treated as a genuine orphan rather than silently excused as historical.`
+          : `record has no integrity block, but its own timing.finished_at / ` +
+            `verification.verified_at (latest: ${claimedAt.toISOString()}) is on or ` +
+            `after the chain-adoption date (${CHAIN_ADOPTION_DATE.toISOString()}) — ` +
+            `a record genuinely written by writeRecord() from that date onward ` +
+            `always carries an integrity block, so this one cannot genuinely ` +
+            `predate the chain. Re-run ingest for this record or investigate how ` +
+            `it reached disk without one.`,
+      });
+      continue;
+    }
 
     orphans.push({
-      run_id: runId,
+      run_id: record.run_id ?? null,
       seq: record.integrity?.seq ?? null,
       path: relPath,
       reason:
@@ -264,7 +485,7 @@ function collectOrphanRecords(repoRoot, entries) {
     });
   }
 
-  return orphans;
+  return { orphans, preAdoption };
 }
 
 /**
@@ -282,6 +503,13 @@ export function formatChainResult(result) {
     ];
     if (Array.isArray(result.orphans)) {
       lines.push(`reconciliation: 0 orphan record(s) on disk`);
+      // F-29134790: ok:true only guarantees zero GENUINE orphans — pre-adoption
+      // records (no integrity block) are excused from ok but still worth
+      // surfacing so an operator isn't left wondering why the disk record
+      // count exceeds the ledgered count.
+      if (Array.isArray(result.pre_adoption) && result.pre_adoption.length > 0) {
+        lines.push(`  (${result.pre_adoption.length} pre-chain record(s) predate the integrity ledger and are excluded from reconciliation)`);
+      }
     }
     return lines;
   }
@@ -312,5 +540,13 @@ export function formatChainResult(result) {
     }
   }
 
+  // F-29134790: pre-adoption records never make ok false, but when the result
+  // IS not-ok for some other reason (a break, or a genuine orphan), still name
+  // the excluded count so an operator triaging the failure isn't misled into
+  // thinking every un-ledgered record on disk is part of the break.
+  if (Array.isArray(result.pre_adoption) && result.pre_adoption.length > 0) {
+    lines.push(`reconciliation: ${result.pre_adoption.length} pre-chain record(s) predate the integrity ledger (excluded from reconciliation, not an audit failure)`);
+  }
+
   return lines;
 }