fix(dd045): item 2 — a stable pointer to the run of record

[basquin-bot]

DD-045 item 2 — the cheapest structural fix on the thread, and the only one that removes the cause of citation rot rather than detecting the symptom.

The problem

Verification evidence lives in bench-results/verify-<UTC timestamp>/. Because the directory name changes every time evidence is regenerated, producing a new run of record stales every citation to the previous one at once. Four supersession commits had to repoint 10, 10, 13 and 18 occurrences (16da079, 865ba35, 1c3ce88, 572282a) — and one miscounted its own repoint: 16da079 records grep -c reporting eight where there were ten, because grep -c counts matching lines, not occurrences.

The fix

bench-results/RUN-OF-RECORD, a tracked pointer file naming the current run directory on its single non-comment line. check-citations.py's existing resolve() substitutes a cited bench-results/RUN-OF-RECORD/... prefix with that directory before matching against the tracked tree. A future supersession edits one line instead of hunting occurrences across the tree.

Not a symlink. This checkout has core.symlinks=false, so a tracked symlink materialises on a fresh clone as a plain text file containing its target path. The pointer has to be a real file whose content is read.

The harness deliberately does not write it. Promoting a run to run-of-record is a deliberate act; an automatic update would let any ad-hoc local run silently become the cited evidence. The pointer's own comment header states that moving it is manual and belongs in the same commit that adds the new run directory.

Proven able to fail

This edits check-citations.py — the repo's own citation gate — so a resolver that silently accepted an unresolvable pointer would be the exact "check that cannot fail" defect this thread exists to remove. All four failure modes were broken deliberately and measured:

Pointer state	check-citations.py
dangling (names an untracked directory)	exit 1
missing while RUN-OF-RECORD/ citations exist	exit 1
zero non-comment lines	exit 1
two non-comment lines	exit 1
restored	exit 0, output byte-identical to baseline

A broken pointer is emitted as a FAILED DEAD PATH like any other broken citation — never a guess, never a silent pass. I re-ran the dangling case independently of the implementer: 8 FAILED, exit 1, and exit 0 again once restored.

Scope

• 14 occurrences across 5 files repointed, counted with grep -o … | wc -l rather than grep -c, per the lesson above.
• One bare verify-20260730T215842Z remains in TODO.md, deliberately: it names the string that was repointed, in the entry describing this work. It is not a citation.
• scripts/check-citations-allowlist.txt loses an entry. bench-results/RUN-OF-RECORD had been exempted as "proposed, not yet built — forward-looking reference"; now that it exists the exemption is false, so removing it puts the path under real checking.

The @claude review found a real hole in the above, twice

The failure-mode table was true and still incomplete. resolve() short-circuited on path in tracked_set before reaching the pointer-substitution branch — and the pointer file is itself tracked. So a bare bench-results/RUN-OF-RECORD/ citation (trailing slash, nothing after it) stripped to the pointer's own path, matched as an exact file, and returned verified without ever validating the pointer. Confirmed empirically: with the pointer dangling, all eight FAILED lines named sub-path forms and not one of the bare sites was flagged.

That shape already existed in this PR's own tree. The docstring sentence promising a broken pointer "is never a silent pass" was therefore wider than the check it described — this thread's defect class, inside the sentence claiming it closed.

Fixed in 793c18e. Then, asked to hunt for the same shape rather than the same line, the fix surfaced a second instance: resolve()'s citing-dir-relative branch checked the normalised path against the tracked tree with no substitution either, so ../RUN-OF-RECORD/ written from a file under bench-results/ took the identical bypass — reachable, since bench-results/dd043-pr3-restvillains-2026-07-26/README.md already cites the run of record and sits one level down. Fixed in 4a65bb3, and deliberately not by patching the second branch: both candidates now go through one shared tracked_or_pointer() helper that checks pointer substitution first and tracked-tree membership second, so the ordering is expressed once instead of drifting across independently-patched branches. resolve() was then read in full to confirm no third site.

Both fixes measured, each against a citation form that was the only thing able to catch a broken pointer:

Citation form	pointer dangling	missing	0 lines	2 lines	restored
bare RUN-OF-RECORD/	exit 1	exit 1	exit 1	exit 1	exit 0
relative ../RUN-OF-RECORD/	exit 1	exit 1	exit 1	exit 1	exit 0

I re-ran both independently of the implementers. The first attempt at the relative-form test was invalid — the pre-existing sub-path citations in that README masked it, so the FAILED lines it produced were not the ones under test. Re-run with the scratch citation isolated at a known line, it reports FAIL ...README.md:226: DEAD PATH ../RUN-OF-RECORD/.

What this does not establish

• Only resolve() knows about the pointer. The separate pinned-row resolver that reads */citations.txt does not, so a RUN-OF-RECORD/... path written into a citations.txt would be reported DEAD rather than resolved. Moot as written — neither tracked citations.txt names the run of record — and it fails closed, not open. Recorded in the script's docstring rather than left in an implementer's report, because an undocumented gap in a gate reads as coverage.
• The pointer makes supersession cheap; it does not verify that the directory it names is a good run. RESULTS.md's own NON-CITABLE stamp remains the check for that.
• Nothing here mutation-tests the harness's own rows. That is DD-045 item 3, still open.

🤖 Generated with Claude Code

https://claude.ai/code/session_01LHBLwqfM1acog2bHRS8WCb

[basquin-bot]

@claude please review this PR.

This one edits scripts/check-citations.py — the repo's own citation gate — so the failure path matters far more than the happy path. Two ways this change could make things worse than the status quo, and both are what I'd like you to attack:

1. A resolver that silently accepts an unresolvable pointer. If bench-results/RUN-OF-RECORD is dangling, missing, empty or has multiple non-comment lines, the checker must FAIL, not guess and not pass. I measured all four as exit 1, but please verify the mechanism in the code rather than trusting that table — in particular whether there is any path through resolve() where a RUN-OF-RECORD/ prefix ends up classified as UNCHECKED, allowlisted, or a "guessed" match instead of FAILED. An unresolvable citation quietly reclassified as UNCHECKED would pass CI and is exactly the defect this thread exists to remove.
2. A repoint that broke live citations. 14 occurrences across 5 files were changed. If the substitution is wrong, citations that resolve today become dead.

Also worth your attention:

• Does anything else in the tree need to know about the pointer? I documented that the pinned-row resolver for */citations.txt does NOT resolve it. Please check whether that is the only such consumer, or whether I have missed one and understated the gap.
• The pointer is deliberately never written by scripts/verify-dd043-pr3.sh. Confirm nothing writes it automatically.
• Any carried value: a citation whose path moved but whose quoted figure was copied across rather than re-read.

Do not take the PR description at face value — I wrote it, and it argues for the change rather than evidencing it.

[claude]

Claude finished @basquin-bot[bot]'s task in 7m 15s —— View job

---

Review: PR #105 — DD-045 item 2 (RUN-OF-RECORD pointer)

• Gather context (diff, check-citations.py, RUN-OF-RECORD, allowlist)
• Attack v0.5–v0.8: availability oracle, JVMTI agent, iteration context, namespace-free valve, live status UI + JPetStore demo #1: trace resolve() for a silent-accept path
• Attack v0.9: exploration metrics in the live status UI #2: verify the 14 repointed occurrences
• Check for other pointer consumers
• Confirm nothing writes RUN-OF-RECORD automatically
• Post final review

Note on tooling: I could not execute python3 scripts/check-citations.py in this review sandbox (script execution isn't permitted for this session/agent), so the analysis below is a static trace of the code plus manual verification of file contents — not a live re-run of the PR's own failure-mode table. If you can grant script execution, I'd recommend re-running the specific repro in finding 1 below to confirm it live.

---

Finding 1 (blocking): a bare bench-results/RUN-OF-RECORD/ citation bypasses resolve_run_of_record() entirely

This is the exact class of defect you asked me to hunt for, and I believe it's real.

In scripts/check-citations.py, resolve() (line 407) checks the literal path against the tracked tree before it ever reaches the RUN_OF_RECORD_PREFIX branch (lines 409–417):

if path in tracked_set or path in tracked_dirs:
    return [path], "exact"
if path.startswith(RUN_OF_RECORD_PREFIX):
    target_dir, err = resolve_run_of_record()
    ...

The caller passes path.rstrip("/") (line 621). So a citation of exactly `bench-results/RUN-OF-RECORD/` — the pointer's own name, trailing slash, nothing after it — has its slash stripped down to bench-results/RUN-OF-RECORD. That string is itself a tracked file (the pointer), so it matches path in tracked_set on the very first line and returns ("exact", ...) immediately. resolve_run_of_record() is never called, so a dangling, missing, or malformed pointer is not detected for this citation shape — it's reported "verified (exact)" regardless of whether the pointer content is valid.

This isn't hypothetical for this PR — this exact bare shape already exists 3 times in the tree this PR introduces/repoints:

• TODO.md:1200 — ...to `bench-results/RUN-OF-RECORD/`; `python3...
• TODO.md:1293 — check `bench-results/RUN-OF-RECORD/` first.
• docs/ROADMAP.md:102 — ...directory: `bench-results/RUN-OF-RECORD/`

Right now this gap is masked: the same files also carry bench-results/RUN-OF-RECORD/RESULTS.md-style citations (with a sub-path), which correctly route through resolve_run_of_record() and would fail if the pointer broke — so the overall gate would still catch it today. But the guarantee stated in the docstring ("a missing pointer... is never a silent pass") is not true for this specific, already-used citation shape, and there's no structural reason a future citation couldn't be only the bare directory form.

There's a second-order effect too: because bench-results/RUN-OF-RECORD resolves as a file match here (not a directory), it lands in file_cands non-empty (unlike a normal directory citation, which correctly produces an empty file_cands since directories aren't in tracked_set). That means any nearby quoted value in the same unit gets checked against the pointer file's own one-line content instead of being correctly treated as "no content to check" — a latent source of spurious CARRIED VALUE findings or missed checks that I could not fully trace without running the tool (TODO.md's task-item units span multiple bullets without blank lines between them, so working out exactly which values land in which unit by hand is impractical).

Suggested fix: special-case path == RUN_OF_RECORD_FILE (bare, no trailing content) to also go through resolve_run_of_record(), e.g. move the RUN_OF_RECORD_PREFIX/bare-pointer check ahead of the generic tracked_set/tracked_dirs short-circuit, or explicitly exclude RUN_OF_RECORD_FILE from it.

Fix this →

---

Attack #1 — everything else checked out

Aside from finding 1, I could not find any other path where a broken pointer reaches UNCHECKED/ambiguous/guessed instead of FAILED:

• The RUN_OF_RECORD_PREFIX branch (for citations with a sub-path) only ever returns "exact" or "pointer-error" — it can never fall through to the basename/guess/ambiguous logic later in resolve(), since it always returns before reaching it.
• The three failure modes in resolve_run_of_record() (missing file, wrong non-comment-line count, dangling target) are each mapped to "pointer-error", which check_unit (line 633) always routes to cite_emit(...) → a DEAD PATH finding, same as any other broken citation.
• One caveat, not a new defect: cited_allowed(path) (the cited-path allowlist) is checked before resolve() is called, on the raw path. If someone later added an allowlist entry exempting bench-results/RUN-OF-RECORD/ as a prefix, that would bypass pointer validation — but this applies uniformly to every citation class already, requires an explicit human-authored, reasoned entry, and no such entry exists today (the PR correctly removes the one entry that referenced this path).
• The reported-allowlist suppression mechanism (emit()) could in principle suppress a pointer-error finding into "reported" (visible, non-failing) — again, this is the pre-existing generic mechanism for any finding, requires an explicit matching entry, and none exists for this path.

Other consumers of the pointer

Confirmed by search: only resolve()/resolve_run_of_record() in scripts/check-citations.py know about bench-results/RUN-OF-RECORD. No .sh script or .github/workflows/* file references it. The two tracked */citations.txt files (bench-results/dd043-pr3-r4-guard-measurement-2026-07-29/citations.txt, bench-results/dd043-pr3-r7-managed-scope-2026-07-30/citations.txt) contain zero references to it — matches the docstring's stated gap exactly, and I found no additional consumer beyond what's disclosed.

Confirmed: nothing writes the pointer automatically

scripts/verify-dd043-pr3.sh only ever writes OUT="bench-results/verify-$TS" — no reference to RUN-OF-RECORD anywhere in the script. .github/workflows/ci.yml and operator-ci.yml only run check-citations.py; neither writes the pointer file.

Attack #2 — the repoint itself

All 14 replaced occurrences previously named verify-20260730T215842Z directly, and the pointer's single non-comment line names exactly that same directory (bench-results/RUN-OF-RECORD:14), which is genuinely tracked (56 files under it). Since the pointer's target is the same directory that was already cited before this PR, the repoint is a pure mechanical substitution — no new evidence source, so no carried-value risk from the repoint itself. Spot-checked bench-results/verify-20260730T215842Z/suite-counts.txt — content is 390 0, matching the quoted figure at the repointed citations. The one bare verify-20260730T215842Z remaining in TODO.md:1199 is inside backticks with no extension and no slash, so it doesn't match either citation token regex (TOKEN_RE needs an extension, DIR_TOKEN_RE needs a /) — it's correctly inert, matching the PR's claim.

The two edits to frozen files (docs/superpowers/plans/2026-07-26-dd043-pr3-maven-injector.md, docs/superpowers/specs/2026-07-24-native-reactive-targets-design.md) are cosmetic-only: both are frozen in the allowlist and excluded from scanning entirely either way, so the repoint there has no functional effect on the gate.

[basquin-bot]

Confirmed and fixed — and the finding was better than one bug.

Verified before acting. With the pointer set to a nonexistent directory, all eight FAILED lines named sub-path forms (RUN-OF-RECORD/RESULTS.md, .../suite-counts.txt:1) and not one bare site was flagged. Your trace of the ordering was exactly right: path in tracked_set at line 407 fires before the RUN_OF_RECORD_PREFIX branch at 409, and the pointer file is itself tracked.

Worth naming what that means: the docstring sentence promising a broken pointer "is never a silent pass" was wider than the check it described. That is this thread's entire defect class, appearing inside the sentence claiming the class was closed.

Fixed in 793c18e, including the second-order effect you flagged — a bare citation now resolves to the target directory, so file_cands stays empty as it does for any other directory citation, rather than checking nearby quoted values against the pointer file's own one-line content.

Then your finding generalised. Asked to hunt the same shape rather than the same line, it turned up a second instance: resolve()'s citing-dir-relative branch also checks the normalised path against the tracked tree with no substitution, so ../RUN-OF-RECORD/ from a file under bench-results/ takes the identical bypass. Reachable — bench-results/dd043-pr3-restvillains-2026-07-26/README.md already cites the run of record and sits one level down. Fixed in 4a65bb3, deliberately not by patching the second branch: both candidates now go through one shared tracked_or_pointer() helper, pointer substitution first and tracked-tree membership second, so the ordering is stated once rather than drifting across independently-patched branches. resolve() was then read in full to confirm no third site; the basename/tail-guess branches cannot reach it, since a bare RUN-OF-RECORD token matches neither citation-extraction regex.

Both fixes measured against a citation form that was the only thing able to catch a broken pointer — dangling, missing, zero non-comment lines and two non-comment lines all exit 1; restored exits 0.

One correction to my own verification: my first relative-form test was invalid. The pre-existing sub-path citations in that README masked it, so the FAILED lines it produced were not the ones under test — the same masking you identified as hiding the original bug. Re-run with the scratch citation isolated at a known line, it reports FAIL ...README.md:226: DEAD PATH ''../RUN-OF-RECORD/'`'.

Your note about cited_allowed() being checked on the raw path before resolve() is accurate and I am leaving it as-is: it is the generic, human-authored allowlist mechanism that applies to every citation class, and no entry exists for this path — this PR removes the one that did.

[basquin-bot]

@claude re-review please — the code changed since your last pass.

You found that resolve() short-circuited on path in tracked_set before the RUN-OF-RECORD branch, so a bare bench-results/RUN-OF-RECORD/ citation bypassed pointer validation. That was real and is fixed in 793c18e. Hunting the same shape then surfaced a second instance — the citing-dir-relative branch had it too — fixed in 4a65bb3 by folding both candidates through one shared tracked_or_pointer() helper rather than patching each branch.

What I want from this pass, in priority order:

1. Attack the new helper the way you attacked the old ordering. tracked_or_pointer() is now the single place that decides "this citation resolves to something real." Is there any citation shape that reaches an "exact" verdict without going through it? Is there any input for which it returns a resolved candidate when the pointer is broken? I am specifically worried that consolidating two branches into one helper has moved the bug rather than removed it.
2. Check my claim that there is no third site. The fix reports that the basename and tail-guess branches cannot reach RUN-OF-RECORD because a bare token matches neither citation-extraction regex. Verify that against the regexes rather than taking it.
3. The second-order effect you raised. A bare pointer citation should now resolve to the target directory, leaving file_cands empty as for any other directory citation, so nearby quoted values are not checked against the pointer file's own text. Confirm that is what the code does now.
4. Anything the two fix commits broke that the previous pass had verified — particularly the 14 repointed citations and the four documented pointer failure modes.

Note one thing I got wrong, so you can judge the evidence accordingly: my first attempt to verify the relative-form fix was invalid, because pre-existing sub-path citations in that README masked it — the same masking that hid the original bug. I re-ran it with the scratch citation isolated at a known line and it reports FAIL correctly, but treat my verification claims as things to check rather than facts.

Do not take the PR description at face value — I wrote it.

[claude]

Claude finished @basquin-bot[bot]'s task in 4m 26s —— View job

---

Re-review: PR #105 — tracked_or_pointer() after 793c18e / 4a65bb3

• Attack v0.5–v0.8: availability oracle, JVMTI agent, iteration context, namespace-free valve, live status UI + JPetStore demo #1: any citation shape reaching "exact" without tracked_or_pointer(), or a resolved candidate when the pointer is broken
• Attack v0.9: exploration metrics in the live status UI #2: verify "no third site" against the actual regexes
• Attack v0.10: coverage over HTTP, grammar-driven exploration, k8s demo, and a standalone dashboard #3: bare pointer citation → directory, file_cands empty
• Attack coverage: union-merge coverage across replicas (DD-023) #4: nothing broken — 14 repointed citations, four failure modes
• Post final review

Tooling note (same limitation as the previous pass): python3 execution requires approval this session and none was grantable non-interactively, so this is again a static trace of scripts/check-citations.py plus manual verification of file contents, not a live re-run.

---

Attack #1 — no bypass found

resolve() (scripts/check-citations.py:429) now has exactly two call sites that can produce "exact": tracked_or_pointer(path) at line 509 and tracked_or_pointer(rel) at line 513. There is no third return ..., "exact" anywhere else in the function. Inside tracked_or_pointer (line 449), the pointer-prefix check (cand == RUN_OF_RECORD_FILE or cand.startswith(RUN_OF_RECORD_PREFIX)) is the first branch, unconditionally ahead of cand in tracked_set or cand in tracked_dirs. Any cand shaped like the pointer always calls resolve_run_of_record(); a non-None err returns "pointer-error" immediately — it can never fall through to the generic tracked-tree check. So: no citation shape reaches "exact" while skipping the helper, and no input reaches a resolved candidate through the helper while the pointer is broken. This closes both prior gaps (literal-path short-circuit and citing-dir-relative short-circuit) at the one place they can occur.

One thing worth confirming explicitly (not a bug, just the boundary of the guarantee): tracked_or_pointer is only invoked for the literal path and its rel normalisation. The later basename/tail-guess branches (lines 516–547) never call it — but per Attack #2 they're structurally unreachable for anything pointer-shaped anyway, so that's not a gap in practice.

Attack #2 — regex claim checked, holds

TOKEN_RE (line 236) requires a literal . followed by a listed extension — RUN-OF-RECORD has none, so it never matches regardless of slashes. DIR_TOKEN_RE (line 239) requires at least one /. A bare single-segment RUN-OF-RECORD has neither, so it's never extracted as a citation token at all — confirmed directly against both regex definitions, not just taken on assertion.

Worth noting one adjacent mechanism that makes the bare-pointer-file case doubly safe: even bench-results/RUN-OF-RECORD (multi-segment, matches DIR_TOKEN_RE) written without a trailing slash is rejected by parse_token's "extension-less multi-segment token needs a trailing slash" rule (line 598) and counted as a skipped prose pair. Only bench-results/RUN-OF-RECORD/ (trailing slash) survives as a citation — and that's unambiguously the directory-shorthand form the fix targets, never a way to cite the pointer file's own text. So there's no accidental collision between "cite the file" and "cite the directory via bare pointer" — they can't both be expressed as citations in the first place.

Attack #3 — confirmed

tracked_or_pointer, line 487: if cand == RUN_OF_RECORD_FILE: ... return [target_dir], "exact" — resolves to the target directory string, never RUN_OF_RECORD_FILE itself. In check_unit, file_cands = [c for c in cands if c in tracked_set] (line 766) — a directory is never in tracked_set, so file_cands is empty for a bare pointer citation, exactly as for any other directory citation. A quoted value in the same unit has nothing to check against rather than being matched against the pointer's own one-line text.

Attack #4 — spot-checked, nothing broken

• All four sub-paths cited via the pointer resolve to real tracked files: confirmed bench-results/verify-20260730T215842Z/{RESULTS.md,suite-counts.txt} and both guard-restore-junit/TEST-*.xml files are tracked.
• bench-results/RUN-OF-RECORD itself has exactly one non-comment line (verify-20260730T215842Z), matching resolve_run_of_record()'s single-line requirement.
• resolve_run_of_record()'s three failure branches (missing file, ≠1 non-comment line, dangling target) are unchanged by either fix commit and all still route to "pointer-error" → cite_emit(...) → FAILED, for both the literal and citing-dir-relative shapes now that both go through the same helper.
• scripts/check-citations-allowlist.txt has no RUN-OF-RECORD entry, consistent with the PR's claim that the exemption was removed.

Minor nit (non-blocking): a stale line citation inside the fix's own docstring

scripts/check-citations.py:94-95 (added in 793c18e, left untouched by 4a65bb3) says: "three citations (TODO.md:1200, TODO.md:1293, docs/ROADMAP.md:102) name only the bare form." TODO.md:1200 and docs/ROADMAP.md:102 still check out. TODO.md:1293 no longer does — that line now reads stamped 20260730T215842Zand made againstb980e1f..., no mention of RUN-OF-RECORD. The bare citation the docstring means ("check bench-results/RUN-OF-RECORD/ first.") is now at TODO.md:1309 — it shifted because 793c18e inserted ~17 lines of explanation earlier in the same TODO.md bullet. Zero functional impact (this docstring isn't .md/.sh/workflow, so it's outside check-citations.py's own scan scope and SELF_FILES-excluded either way — nothing in the gate ever validates it), but it's a citation going stale from a same-file edit inside the very commit fixing citation rot, and it's been carried through one more commit since. Cosmetic — fix whenever convenient, not worth blocking on.

Fix this →

---

Bottom line

No blocking issues. tracked_or_pointer() correctly consolidates the ordering fix — every candidate path that could name the pointer goes through pointer-substitution before tracked-tree membership, for both the literal and citing-dir-relative shapes, and the basename/tail-guess branches are structurally unreachable for anything RUN-OF-RECORD-shaped (verified against the regex definitions, not assumed). The bare-form second-order effect (empty file_cands) is implemented as described. The one nit found is a stale line-number reference in a docstring that the gate itself never checks — worth a follow-up edit, not a re-review.
· branch dd045-run-of-record

[basquin-bot]

Independent approver review of PR #105 (dd045-run-of-record, head 5fdcf9e). Reviewed the artifact directly — code, docstring, tracked files, and empirical behavior — not the PR description.

Decision: sound. Approving.

What I verified

1. All four pointer failure modes actually fail, with exit codes captured explicitly (echo "exit=$?"), not inferred:

Pointer state	exit	FAIL count
dangling (names untracked dir)	1	14
missing	1	14
0 non-comment lines	1	14
2 non-comment lines	1	14
restored	0	0 (byte-identical to baseline)

In every broken case, all 14 tracked citation sites go FAILED — critically including the bare-form sites (TODO.md:1200, TODO.md:1309, docs/ROADMAP.md:102) that the @claude review found bypassing validation before 793c18e/4a65bb3.

2. Masking-aware test of the citing-dir-relative branch. No ../RUN-OF-RECORD/ citation exists in the tree, so I added a scratch one to bench-results/dd043-pr3-restvillains-2026-07-26/README.md:226 — deliberately in a file that already carries two pre-existing bare-form citations of the same pointer, recreating the exact trap that invalidated the Programmer's own first attempt. Checked the specific added line in the output rather than the overall exit code: verified clean with the pointer intact, FAIL ...README.md:226: DEAD PATH \../RUN-OF-RECORD/RESULTS.md`with it dangling. Reverted; output byte-identical to baseline. The citing-dir-relative branch genuinely goes throughtracked_or_pointer()`, not riding on the bare sites' failures.

3. Repoint faithfulness. Recounted the 14 occurrences by diff hunk against 4efd7de independently: TODO.md 2, restvillains README 2, maven-injector plan 1, native-reactive-targets spec 3, ROADMAP.md 6 = 14, matching the claim. Every hunk is a pure path-token substitution — no figure added, removed, or altered near any of the 14 sites.

4. Scope boundary + no auto-write. Read main() directly: the */citations.txt pinned-row loop never references RUN_OF_RECORD_FILE/resolve_run_of_record — a RUN-OF-RECORD/... path there would report DEAD PATH, as the docstring claims. Extended the check beyond the docstring's own two example directories: no tracked citations.txt in the whole repo names the run of record. scripts/verify-dd043-pr3.sh and every other tracked .sh/workflow file have zero references to RUN-OF-RECORD — nothing writes the pointer automatically.

5. Claims vs. code. Traced TOKEN_RE/DIR_TOKEN_RE directly to confirm the docstring's claim that a bare RUN-OF-RECORD token (no bench-results/ prefix) can never be extracted as a citation. Ran the git grep command the final commit substituted for the two stale line-number citations it removed — it correctly finds the six bare-form sites. check-citations.py itself is excluded from its own scan (.py, not .md/.sh/pinned), confirming "nothing scans this file."

6. False debt. The removed allowlist entry (bench-results/RUN-OF-RECORD proposed...) had no trailing /, so it only ever exact-matched the bare form — left in place, it would have silently exempted exactly the bare-form sites from resolve() via cited_allowed(), which runs first in check_unit(). My dangling-pointer test showing those bare sites correctly FAILED is only possible because the removal is real, not decorative. Grepped for lingering present-tense claims that no stable pointer exists or that supersession requires bulk repointing — none found; all hits are past-tense narration of the fixed problem or an unrelated feature thread.

What I did not verify

Did not run the jvm/native stages of scripts/verify-dd043-pr3.sh (out of scope for this PR; CI already ran it green on this head). Did not re-derive the historical byte-identical-disposition-counts claim across the 4efd7de → this-branch repoint (accepted the diff-hunk read as sufficient evidence instead).

Full working notes: .superpowers/sdd/approver-pr105.md.