backlog: file #1330, and close #1321 as a duplicate of #1322

[wshallwshall]

Two ledger-only changes, batched into one PR on purpose.

Batched because PR count is the queue's rate limit, not diff size. A ledger-only PR still costs a full CI slot: the required CI gate needs the harness job, which the PR path-gate runs on docs/ deliberately, so a BACKLOG rewrite must face the ledger tests. Two of these as separate PRs would be two sequential cycles, each knocking the other behind under strict: true.

1. Files #1330

PR 487's five-file resolver conflict is a judgment merge whose obvious resolution re-arms a fixed defect. Filed by the previous lander, carried here unchanged.

2. Closes #1321 as a duplicate of #1322

#1321 and #1322 record one root cause: the serverdb path alternation does not list messagefoundry/api/, so an api-only change deselects the SQL Server and Postgres legs on the very pull request that would catch it. Two seats filed it within minutes. #1322 landed first; #1321 arrived by merge, so neither the ledger gate nor either author could see the collision.

#1321's own row declared itself the duplicate and handed the closure over, because a filer may not close their own row. This discharges that hand-over.

Verified before flipping rather than relayed: #1322 carries every point #1321 does, including the tests/test_api.py:587 substring-versus-equality half, and adds a fired-in-practice case and a severity bound that #1321 lacks.

The glyph is a deliberate choice with no precedent to follow. The live ledger carried no prior close-as-duplicate-of-an-open item, so the alphabet had to be read rather than copied. The other two closed banners would each assert something false: one that the gate hole is fixed, which it is not and remains open at #1322; the other that an owner declined the work, which none did. The banner says so in words, so no reader has to infer it from a pictograph.

Verification

• parse_items: 342 items, 246 open. Main is 341/246, so the arithmetic is one item filed and one item closed.
• Status gate: 578 items across both ledger files, each declaring exactly one status.
• Leak screen over main..HEAD rather than the tip, with its positive control run first: zero matches, control fires 1.

Auto-merge is deliberately NOT armed.

🤖 Generated with Claude Code

[wshallwshall]

DO NOT MERGE THIS YET. It is green and it is held deliberately, and without this note it reads as simply un-merged.

I am the lander who rebased it, batched a second ledger change onto it, and drove it to green. I am not merging it, for a reason that has nothing to do with CI.

What is wrong with it

One line added by the #1330 filing names an ASVS requirement id paired with its coverage grade transition, and characterises that transition as a re-open. The repository's guidance keeps the pairing of a requirement with an item and a coverage state out of the public ledger — the id list itself is published by OWASP, but the pairing is the coverage manifest, and it discloses what is not covered by subtraction.

I am deliberately not quoting the token here. A note that republishes the thing it is about defeats itself.

Severity is bounded, and I would rather state the bound than let this read as bigger than it is

That same id already appears four times on origin/main independently, so nothing here is secret. This is about not adding a new grade-paired occurrence, which is a different and much narrower claim.

It was found only by a corpus-backed screen — checking each dotted triple against the 345 real requirement ids — because the id appears with no adjacent keyword. Two earlier keyword-based screens returned clean on this exact line. A screen that cannot fire and a clean branch look identical.

Why I could not just fix it

I rebuilt the commit on current main with the id and grade removed and the sentence's meaning intact. The pre-commit ledger gate refused it: the item was allocated to a different worktree, and the gate's documented trigger is adding a number not allocated to yours. My rebuilt commit still adds it.

The gate is behaving exactly as specified. I checked, after initially reporting it as a gate defect, and I was wrong about that. What is missing is a transfer path in the allocation tool — the sibling claims tool already has one, with an audit trail and a refusal condition, so the asymmetry is the argument rather than the loosening being novel.

That is with the owner as an item. Do not route around the gate to land this.

What a taker should do

1. Wait for the allocation question, or get the redaction made from the worktree that allocated the item.
2. The #1321 closure batched onto this branch is separable and clean under the corpus screen, added lines and commit message both. It can land alone.

Its remote is untouched at aff06772; I detached in a scratch tree and pushed nothing.