Development record
Nothing tells you an open issue is already fixed. The ledger goes stale silently, and the cost of finding out lands on whoever plans the next piece of work.
Nothing tells you an open issue is already fixed. The ledger goes stale silently, and the cost of finding out lands on whoever plans the next piece of work.
Observed opening an autonomous sweep over a managed repository's ledger. Four open issues had been fixed on the default branch by merged pull requests whose commit subjects name the fix, but nobody ran abcd capture resolve, so the ledger still listed them as open. Sorting it out meant diffing the tree against each record by hand before any work could be assigned, roughly an hour before the sweep proper started. There is no marker anywhere that says "this was fixed"; the only evidence is in commit prose the ledger never reads.
This is the same failure mode the resolve-in-the-same-change convention exists to prevent, seen from the other side: the convention is a discipline, and a discipline that lapses leaves no trace. The tool holds both halves of the evidence — the record's id and the default branch's commit messages — and never puts them together.
Wanted: a lint (a capture lint, or a row in abcd lint) that flags an open issue whose id appears in a commit message on the default branch, or whose found_at file changed in a commit whose body cites the id, as "possibly resolved". capture resolve --commit already exists, so the lint could suggest the sha it found and the operator could accept it. False positives are cheap here — a mention is not a fix, and a human reads the row — while the current silence is not.
Grounds
- pursued: four fixed issues sat open in a managed repository's ledger because the only evidence of their fix was commit prose the ledger never reads; a mention that must declare itself turns that prose into a signal both the gate and the ledger can read, and a read-only listing over the default branch surfaces the backlog that predates the gate for a human to resolve. What would show it wrong: sessions writing Refs: to silence the gate on a change that fixes the issue, or the listing's rows proving mostly provenance noise rather than fixes
Frontmatter
| id | iss-2609100507421759 |
|---|---|
| type | issue |
| lifecycle | resolved |
| severity | major |
.abcd/work/issues/resolved/iss-2609100507421759-nothing-tells-you-an-open-issue-is.md
open on GitHub ↗ · commit history ↗
mentions2
- dcn-26091500000000062026-09-15 — A commit message or pull-request title or body that names an iss-N declares its relation to it, and a bare mention is refused in CI before the merge (product thinker, ruling on iss-2609100507421759, first asking whether a formal resolution trailer can be enforced and then choosing "enforce it, and also hint on the default branch"). `Resolves: iss-N` says the change fixes it and RS001 then requires the record to move in the same diff; `Refs: iss-N` says touched but not fixed and demands nothing of the ledger; the vocabulary is closed at those two words, a comma-separated list of ids is admitted on either, and a near-miss (`Ref:`, `See:`, `Related:`) reads as what it is. RS004 covers `iss-N` only, the family the trailer vocabulary owns; an id inside a record body is `prose_citation_resolves`'s question. The hint is `abcd capture mentions`, a read-only listing over the default branch of open records whose ids appear in commit history without a resolution, ranked resolves over tree over record, silent on the commit that added the record's own file; it lists and never moves a record. Rejected: any mention of the record's id as proof of a fix (a mention proves the author's attention, not a fix); a detector with no enforcement (a silent fix cannot be seen at all, so the gate has to force the mention into a declaration).
- iss-2609100509531349The record verbs are sound; the failures were all at the edges, where the tool knows something and does not say it.