fix(asvs): anchor DRIFT is not claim INVALIDATION — stop failing the gate on it

[wshallwshall]

BRANCH ADOPTED, NOT AUTHORED. The base commit 3770380c (2026-08-08 18:49:46 -0500) is not
mine. I picked this branch up because the change was correct and the work needed finishing; my
commits sit on top of it and rewrite nothing. If you authored 3770380c, your history is intact.

Do not force-push this branch. An adopted branch is the one case where a force-push can destroy
someone else's only copy of their work.

How ownership was checked, and how half my check was wrong: I ran git worktree list (nothing held
the branch) and list_sessions (no running session). The second half is invalid -- isRunning:false
means PAUSED, not finished, so a paused owner is invisible to it. The durable rule, agreed with the
parallel session: branch ownership is answered by git worktree list plus
git log -1 --format='%an %ad', never by session liveness. Sessions are invisible; refs are not.

---

check_anchors fails on any evidence anchor whose token moved beyond ±ANCHOR_WINDOW, whether or not the claim is still true. That collapses two different assertions:

• the evidence still exists — what this gate is for
• the evidence still sits where it sat — a line number

Only the first is a claim about security posture.

Not a loosened threshold

Execution reaches the moved-token branch only past the occurrences > 1 guard, so the token provably occurs exactly once in the file. Its presence alone pins the evidence; the recorded line is a navigation aid.

Where the line is load-bearing — an ambiguous token, where a re-anchor to the wrong occurrence cannot be detected — it still hard-fails, unchanged.

Still fatal, i.e. the whole signal: a GONE token (the claim may now be false), an AMBIGUOUS token, a missing path, and every absence-claim failure. That narrows the gate to claim-invalidation — which ADR 0156 already describes as the intent: "Evidence anchors will break on refactors. That is the feature … a re-score becomes re-verify the cells whose anchors moved."

Why this repo never feels the problem it causes

Worth stating plainly, because it's the reason this hasn't surfaced here: no workflow in this repo runs scripts/asvs/scorecard.py. I checked all of them. The scorecard data, and the gate that consumes it, live in the private vault — which mirrors this file byte-for-byte and is where it actually gates anything.

So the repo that causes the drift never runs the tool, and the repo that runs it is the one blocked by it.

Measured downstream:

Date	Effect
2026-08-07	130 of 146 failures were one constant offset per file — +57 auth/service.py, +61 __main__.py, +47 store/base.py
same day	count went 67 → 146 in ten hours as this tree advanced
2026-08-08	recurred — +102 on .github/workflows/ci.yml

Every one of those was a line number, not a claim.

The cost isn't just noise

A gate that's red every morning for a reason nobody must act on is a gate whose next real finding gets waved through. There was one underneath that day: a cell asserting a security control was absent when it had since been built and merged. It sat in the same undifferentiated list as 130 line numbers.

Drift is still reported — as DRIFT plus a count — because letting the recorded line numbers rot silently is the failure mode on the other side.

Verification

3 tests added (57 pass, was 54). Mutation-checked: with the change reverted, test_a_unique_token_that_drifted_is_advisory_not_fatal fails behaviourally — the drift lands in problems. The other two are controls (ambiguous stays fatal; ordinary small movement stays silent) and fail on the missing attribute, which is a weaker signal — they assert unchanged behaviour by design.

ruff format --check and ruff check clean on both files.

Found while re-scoring ASVS cells against this tree; companion to #293.

🤖 Generated with Claude Code

[wshallwshall]

Post-merge assertion, run before any merge button is touched

#297 landed at 05:30Z, so this branch now carries it. Merged, not rebased — the two standing rulings conflicted: "rebase onto #297" requires a force-push, and "never force-push this adopted branch" is absolute. A merge satisfies both and preserves 3770380c.

The merge was CLEAN — no conflict. That is precisely the dangerous case: #297 carried all four ANCHOR_WINDOW occurrences forward as unchanged context, so a keep-both resolution would have reinstated the window inside the very function this PR strips it from, with nothing to flag. Hence the assertion:

$ grep -c ANCHOR_WINDOW scripts/asvs/scorecard.py
1

$ grep -n ANCHOR_WINDOW scripts/asvs/scorecard.py
70:#: RETIRED 2026-08-09. There was an ``ANCHOR_WINDOW = 40`` here: a token found within 40 lines of its

$ grep -c _headline_caveat scripts/asvs/scorecard.py
2          # confirms #297's content is actually present, not just claimed

4 → 1, and the survivor is the retirement comment. Any other number means the window came back.

Corpus re-measure, against engine main post-merge

731 of 1980 anchors (36.9%) carry a stale line number
0 fatal
exit 0

advisory 0 was the tell for a silent reinstatement; it reads 731, matching the parallel session's independent measurement. 60 scorecard tests green, ruff and mypy clean.

One addition since review

f4738ce3 corrects the summary line from "verified N evidence anchors" to "resolved N evidence anchors (token present and unique — NOT proof the control operates)". An anchor check proves presence and uniqueness; it cannot prove the statement still executes under the control flow the cell reasoned about, because expect is a substring match. 15.3.1 is the measured instance — pass, every anchor resolving, control had a hole, found only by executing. The line that IS the record's rendered face was stating a false premise about itself.