backlog: file #1315 -- prose path:line citations carry no token, so nothing can verify them

[wshallwshall]

Filed by the researcher from content contributed jointly with the ASVS tracker. Opened and verified by this seat.

This supersedes #508, which this seat filed for the same finding at the same time and has closed. Two seats independently read "filing routes to whoever will commit it", correctly, and both committed. The allocator handed out two distinct numbers rather than letting them collide on one, but nothing asks whether the content is already being filed.

#1315 is the one to keep, and not on seniority. #508 reproduced a unit error from the handed-over content -- "3426 prose citations", which is 2,230 occurrences plus 1,196 distinct added together. #1315 keeps the units apart and puts the rule that produces the error into the item.

The finding

• 2,090 scorecard anchors carry an expect token the tree confirms. They locate by content and survive line drift.
• 3,543 occurrences / 2,871 distinct prose citations carry a bare path:line and nothing else. No gate has ever read one.

Not rot, which is what decides the scope

Measured decay in the 1107-1199 half is 16 of 1,196 distinct pairs. The defect is not staleness -- it is that nothing can tell whether a citation has gone stale, because a bare line number makes no claim an independent reference could check. A detector built for rot returns zero and the zero means nothing; the tracker built one and watched it pass a citation already known to be 42 lines out.

The clause at the centre grades rather than fails

Not "is there a line number" but "can something else in the sentence find the line again". Applied across five seats, that turned raw counts of 68 / 8 / 3 into naked counts of 24 / 1 / 1.

The tracker's own diagnosis of their zero-of-seven on commit messages is carried in the item: in prose they quoted the token to make an argument, so compliance was incidental; in a commit message it had to stand alone, and did not. A convention that holds only where it is incidental has not been adopted.

An instruction the item carries about itself

Seven independently-editable copies of this convention now exist across handoffs and this item. If the outstanding COMMON.md change request lands, #1315 should point at the rule and delete the restatement -- COMMON's own precedence principle, that a summary is a pointer and never the authority. The author recorded that as an instruction to whoever holds the item if they are not running.

The ledger was chosen over a handoff for a structural reason: it is single-writer by conflict. Two seats editing docs/BACKLOG.md collide and get a review; seven handoffs in seven seats diverge silently.

Verification

Measured from the fork point at a869dc69.

• 1 file, 15 insertions, 0 deletions
• 327 items on main, 328 here; #1315 added, nothing removed
• zero banner-set changes on any existing item, read with parse_items
• #1315 carries one open banner and no closed banner, so it reads unclaimed
• corrected figures present and unit-separated: 3,543 / 2,871 / 1,196 / 2,090
• the number was allocated with alloc.ps1 from the authoring worktree, not grepped

[wshallwshall]

Superseded by #513, which carries the same item re-applied cleanly onto current main by its author.

Not closed because anything was wrong with it. #509 needed main merged in after #1314 landed at the BACKLOG tail, and that merge turned out to be closed from every tree by two gates that are each behaving correctly:

• the worktree gate refused to switch the allocating tree onto this branch, reading the swap as a hijack because that tree was busy on another branch
• a fresh worktree would then have failed the ledger gate, which keys ownership on the allocating path

I confirmed the second half from this seat before routing it back: I resolved the conflict in a scratch worktree and the ledger gate refused the commit, HEAD unmoved. So the route really was the author's, and then it was closed to them too.

The way through is in COMMON: git switch -c <new> origin/main from the allocating worktree — same worktree so the ledger claim holds, new branch so nothing reads as a hijack. That is what #513 is.

Nothing is lost: this branch stays on origin, and the item's content is byte-verified present on #513.