commands/launch.md:647-648 says deleting a record to clear the gate is refused under deleted-finding, but deletedRecords (internal/core/changelog/findings.go:353-385) judges only records the anchor held in open/; a record captured this cycle and deleted in a commit is caught by neither half (residual named in resolved iss-2609091143455568; 04-launch.md:616-618 states it)

Frontmatter

.abcd/work/issues/open/iss-2610252214292202-commands-launch-md-647-648-says-deleting.md
open on GitHub ↗ · commit history ↗

mentions1

• iss-2609091143455568GuardFindings decides whether a finding has been answered by asking only whether its id is still under the open bucket at HEAD, so deleting the record clears the gate as effectively as resolving it. Every legitimate route leaves a trace the next reader can follow, a resolution, a wontfix, or a deferral with its reason, and the illegitimate one leaves nothing at all, which makes it both the cheapest way past the gate and the only way that destroys the finding rather than answering it. The issue-resolution gate refuses exactly this shape already, RS001 holding that a bare delete of an open record satisfies no trailer, so the two gates disagree about what counts as an answer while sitting in the same release path. The fix is to ask the question the sibling gate asks: a record present at the anchor and absent at HEAD is a deletion rather than a disposition, and the gate should refuse it and name it, since a record that entered the ledger and left it without reaching a terminal folder is the one case nobody can audit afterwards. Detector: a cut whose only change to a blocking record is its deletion must refuse, naming the record and the deletion, while a resolution, a wontfix and a deferral each continue to clear it. Found by adversarial review of the gate's own release; deferred rather than fixed in that cut because the fix belongs with the gate's own hardening and the release it would have blocked is the one that introduced it.