The standing duplicate-check exits 126 and returns nothing at 3,000 files; it caused no duplicate ids, but the audit it should have been doing found two superseded entries that never name their successor - one of them a live safety verdict

Exit 126 rather than the more usual E2BIG/126-vs-127 distinction is what this shell reports; the precise errno was not captured, and the threshold file count at which it begins failing was not bisected - only that it fails at 3,000 and the corpus was smaller when the procedure was written. The behaviour is specific to this Git-Bash-on-Windows environment and may not reproduce on Linux.

• The guard being dead does not establish that it was ever load-bearing. Agents are given a beat folder and write ids scoped to it, and the validator enforces uniqueness independently, so it is entirely possible this command has never prevented a single duplicate even when it worked. Its measured contribution here is zero, and the honest claim is that a check was believed to be running when it was not - not that harm resulted.
• The four 'unwritten' symbols were caught before any agent was dispatched, by a different tool (scripts/is-symbol-covered.py) that contradicted the empty listing. So the corpus's redundancy worked. A single-instrument workflow would have failed; this one did not.

The 0.60 threshold is arbitrary and was not swept; a different cutoff returns a different candidate count, and the candidate list is a triage aid rather than a measurement. Token Jaccard on ids is a weak proxy for subject identity.

• 123 candidates were generated but NOT individually adjudicated - they were printed and scanned, not each opened and judged. So 'almost all are legitimate parallel series' is an impression from reading the list, not a verified per-pair verdict, and a genuine duplicate could be sitting in it. The only fully adjudicated subset is the 2 supersession pairs.
• The scan is blind by construction to duplication that is not visible in the id, which is plausibly where most real duplication lives - two beats reaching the same conclusion under unrelated names. A near-zero Jaccard is not evidence of distinctness, so this analysis cannot bound the true duplicate rate in either direction.

The suffix list tested is v2, v3, full, new, revised, 2, updated, rerun, redux and final. A successor named anything else - or named nothing version-like at all - is not found by this search, so 2 is a lower bound on supersession pairs and very likely a substantial underestimate.

• A missing forward pointer is not necessarily a defect. The -full scan pair turned out to be an extension reaching the same conclusion, where no warning was owed and only a convenience link was added. Generalising 'no pointer' to 'stale content' would have been wrong in 1 of the 2 cases found, i.e. half.
• Absence of the word 'superseded' in the JSON is a keyword test, not a semantic one. An entry could convey supersession in prose the search does not match - 'a later rerun found', 'this has since been revised' - and would score as unacknowledged here. The two hits were confirmed by reading both entries, but the search that found them could produce false positives at scale.

These are quotations from this corpus's own entries, read this cycle, not from primary literature. Whether v2's own gating rule is correct was not re-derived here - this analysis establishes that the two entries disagree and that only one of them is reachable from the other, not which is right. v2's gnomAD figures were not independently re-fetched.

• v2 is itself two cycles older than nothing in particular and has an 'amended' provenance record from cycle 22, so treating it as the current word is an assumption. It could in turn have been superseded by an entry with an unrelated id, which is exactly the blind spot E3 records. The correction applied to v1 points at v2 rather than at a verified current answer.
• CORRECTED within this cycle. I first left v1 at status 'verified', reasoning that 'superseded' would be a novel string invisible to every tool. That was wrong and I had not checked: the corpus already carries status 'superseded' on 6 entries, so it is the established convention, and v1 has now been set to it. The error is the same class this entry is about - I asserted what the corpus contained instead of querying it. The residual caveat stands: `status` is still not a validated enum, so nothing enforces the vocabulary and a reader filtering on it sees whatever each author chose.

The survey covered scripts/ and docs/*.md for the patterns nodes/*/*.json, nodes/**/*.json and edges/*.json. Shell commands embedded in king logs, in coverage.md, or typed ad hoc by a coordinator without being written down anywhere are not covered and cannot be, so 'the audit is complete' applies to committed callers only.

• The date the beat-inventory docstring was written was not established, so 'the warning existed first' is an inference from it being present now, not a verified ordering. If that note was added recently the narrative of a long-ignored warning is wrong, and the honest claim reduces to: both existed simultaneously in the same repository.
• Python's glob.glob has no argument-list limit, but that does not make those scripts correct - it makes them safe from THIS failure. Several of them apply their own filters and thresholds that were not reviewed here, and declaring them 'safe' on one axis risks being read as a general clearance.