Development record

a resolve or wontfix replaces the grounds scalar so the conjecture a promote recorded is silently destroyed

issueresolvedmajoriss-2608301657354776

Found by the round-5 ruthless review, which executed the sequence rather than inferring it. Branch-introduced: the field is new here.

The ledger's grounds frontmatter scalar is single-valued, and setScalarField REPLACES. So Promote records a conjecture, and a later Resolve or Wontfix on the same issue overwrites it. The promote conjecture is then gone from the record and from everywhere: promote writes grounds nowhere else, and the minted draft carries promoted_from and a seed body but no grounds entry.

Nothing warns, no count changes, the result reports success. And the loss is unavoidable rather than accidental, because capture resolve now REQUIRES --grounds. Fourteen records already in resolved/ carry promoted_to, so this is the ledger's mainline sequence and not a corner.

What makes it a defect rather than a tradeoff is that the sibling writer argues the opposite at length for the same data. intent/grounds.go states that recording is APPEND-ONLY, because the earlier conjecture is precisely what a later reader checks the outcome against, and that rewriting it would leave the record saying only what was believed last. The ledger half performs exactly the rewrite the intent half declares unacceptable. spc-57's Ledger-side bullet is silent, and Issue.Grounds's doc says only that promote, resolve and wontfix stamp it.

Remedy, either way but explicitly: refuse a transition that would overwrite a non-empty grounds, matching the double-promote refusal already inside the same locked section; or, if last-write-wins is intended, say so in Issue.Grounds and in spc-57 so the loss is a chosen tradeoff. An append-only list here is a schema decision and is not to be added on this branch without one.

Grounds

pursued: we expect one shared record form to be what makes the overwrite unrepresentable rather than merely refused, and a promote-then-resolve sequence that keeps both conjectures in order is what would show it wrong

Frontmatter

id	iss-2608301657354776
type	issue
lifecycle	resolved
severity	major

.abcd/work/issues/resolved/iss-2608301657354776-a-resolve-or-wontfix-replaces-the.md
open on GitHub ↗ · commit history ↗

mentions2

dcn-26083000000000162026-08-30 — itd-179 round-5: the ISSUE ledger's grounds become APPEND-ONLY, as a `## Grounds` body section mirroring the intent half, and the frontmatter `grounds:` scalar is retired (16 committed records migrated in the same change). A scalar is SET, so a resolve or wontfix silently destroyed the conjecture a promote recorded — on the ledger's mainline sequence, since fourteen resolved records carry `promoted_to` — and the result still reported success (iss-2608301657354776). Rejected: refusing a transition that would overwrite a non-empty grounds, as the record proposed; promote, resolve AND wontfix all REQUIRE grounds, so the refusal would make a promoted issue impossible to resolve. Rejected: last-write-wins declared as a chosen tradeoff, because `intent/grounds.go` already argues the opposite for the same data — the earlier conjecture is precisely what a later reader checks the outcome against. One-canonical-primitive: the record form (heading, section reader, append, readability check) moved to `core/grounds`, and the generic markdown-body machinery under it to a new leaf `core/mdrecord`, so both record families share ONE definition rather than holding two. Rejected: leaving the form in `core/intent` and having capture call it, which is one implementation but puts an issue-record body parser behind the intent package's door. The retired key is TOLERATED in `issueschema.Known`, not refused: a refusal makes capture SKIP the record, and a record invisible to every surface while it still sits in the ledger is worse than a value nothing reads — the record lint's `record_schema` blocks the misplacement and names the section instead.
spc-57Grounds at conjecture granularity