2026-09-23 — The resolution field of a resolved issue gets two detectors, in order (product thinker, ruling on iss-2608250844259345): first a co-edit rule, under which a body change on a resolved record requires a resolution change in the same commit; later, as a second layer, a detector for a resolution that contradicts its body. Both belong to one intent, planned next cycle, for the three unwatched edges of issue resolution, with the inverse open-record detector (iss-2608241612007530) and audit verdicts that never reach resolved issues (iss-2608261635558358).

Frontmatter

.abcd/work/decisions/dcn-2609230000000006-the-resolution-field-of-a-resolved-issue.md
open on GitHub ↗ · commit history ↗

mentions3

• iss-2608241612007530the issue-resolution gate is triggered by the trailer, so a fix that lands without one is invisible to it. RS001 fires only on a commit carrying a Resolves trailer, and RS002/RS003 only on stamps that already exist, so a merged fix whose commit names no issue passes all three rules and leaves its record in open/ — the exact backlog iss-2608241347321757 was built to stop, reached from the other direction. Measured 2026-08-24: 1315 commits name an iss- id somewhere in the message and 3 carry the trailer. iss-202 is the standing instance: its fix merged on 2026-08-24 in a commit ending with a bare 'iss-202' line rather than the trailer form, and its record sits in open/ with the fix shipped. The missing detector is the inverse direction — a change touching code an open record describes, declaring no resolution.
• iss-2608250844259345a record's resolution frontmatter is user-reachable and nothing checks it against the record body it sits on. The resolution field is emitted verbatim by 'abcd capture list --resolved --json', which commands/capture.md dispatches, so it is a shipped surface rather than an internal note — but the rendered site pages carry the record BODY, so a resolution that contradicts its own body is invisible on the site and visible on the CLI. Demonstrated in the v0.6.6 cut: iss-2608250743421381's body was corrected to say identity-check is deliberately NOT added to the ahoy hint, while its resolution field still said the hint advertises it and describes 'adding the identity-check it registers'. The docs-currency gate caught it by running the command rather than by reading the file, after the body had already been fixed. Same class as iss-2608242043243131 (the preflight gate list restated by hand in five places with no test deriving it) in a different field: a claim with more than one representation and no check that the representations agree. Candidate detector: a record-lint rule asserting the resolution field does not contradict the body, or more tractably that a record edited in a commit has its resolution field edited in the same commit whenever the body's claims change.
• iss-2608261635558358Audit verdicts do not propagate to the resolved issues that rode the audited spec. An issue fixed inside a spec resolves at the fixing change (Resolves trailer, watched-fail test, RS001-RS003 provenance), which is correct and deliberate — but when the intent's audit later returns NOT_MET or MET_WITH_CONCERNS on a criterion, nothing walks back from the verdict to the resolved issues whose resolved_by points into that spec: they stay resolved while the audit says the delivery fell short. The design-consistent remedy is audit back-propagation, not a pending-verification state (a candidate queue is the forgotten post-merge step the close-with-the-act rule exists to avoid): the auditor's verdict names the resolved issues riding the failed criterion and files the recurrence treatment for each — a new issue citing the old disposition, per recurrence-is-signal — so a hollow fix is surfaced by the audit rather than waiting for the defect to bite. Kin: iss-2608241612007530 (a trailerless fix is invisible to the gate) and iss-2608250844259345 (resolution frontmatter unchecked against the body) — the three together are the closure loop's three unwatched edges.