Development record
Nothing ties a merged implementation to closing its spec, so twelve specs stayed open and twelve intents stayed planned after the code that realises them landed on main: abcd spec close is the verb that advances the intent planned to shipped, closes the spec open to closed, and emits the fidelity-audit receipt, but no gate, lint rule or CI step notices that a spec is still open while its acceptance criteria are demonstrably delivered. The consequence is not cosmetic: the changelog composer reads the shipped-intent and resolved-issue folders, so a release cut derived while the intents sit in planned announces the resolved issues and omits every intent the release actually delivers. Found after the itd-150..162 implementation merged with all fourteen issues resolved but all twelve specs left open. Wants a detector for the shape 'spec open, linked intent planned, and the spec's own scope files changed since the spec was written', which is the same reference-graph the dangling-supersedes ratchet already walks.
Nothing ties a merged implementation to closing its spec, so twelve specs stayed open and twelve intents stayed planned after the code that realises them landed on main: abcd spec close is the verb that advances the intent planned to shipped, closes the spec open to closed, and emits the fidelity-audit receipt, but no gate, lint rule or CI step notices that a spec is still open while its acceptance criteria are demonstrably delivered. The consequence is not cosmetic: the changelog composer reads the shipped-intent and resolved-issue folders, so a release cut derived while the intents sit in planned announces the resolved issues and omits every intent the release actually delivers. Found after the itd-150..162 implementation merged with all fourteen issues resolved but all twelve specs left open. Wants a detector for the shape 'spec open, linked intent planned, and the spec's own scope files changed since the spec was written', which is the same reference-graph the dangling-supersedes ratchet already walks.
Reframed 2026-08-29 under adr-55: this is not a decision waiting for anyone. Closing a specification once its implementation has landed is a step in the loop, and the loop stops only to obtain a verdict. It is performed, with the gate as the safety net. The earlier objection, that shipping an intent is a maintainer decision, rested on collapsing the product thinker and the facilitator into one word.
Grounds
- pursued: a change that declares a delivery cannot merge with its spec open and its intent planned; shown wrong if a Delivers trailer passes lint-issues while its intent stays in planned/
Frontmatter
| id | iss-2608290808193471 |
|---|---|
| type | issue |
| lifecycle | resolved |
| severity | major |
.abcd/work/issues/resolved/iss-2608290808193471-nothing-ties-a-merged-implementation-to.md
open on GitHub ↗ · commit history ↗
mentions4
- adr-55The construal stands in the record; its history does not
- iss-2609181121522692No lint rule checks that an intent's bucket agrees with its specs' buckets, so a mis-merge that files a new planned intent's spec into closed/ (or the intent into shipped/ with its spec still open) lands silently. Observed in the Gropius managed repo on 2026-09-18 at v0.9.0: after a pull request had moved many records planned/ to shipped/ and open/ to closed/, a git merge of a branch adding one NEW planned intent and its open spec ran rename detection against those moves and offered to place the newcomers in shipped/ and closed/. The record gates read each record on its own: spec_lifecycle refuses a status key, intent_lifecycle checks ids and frontmatter placement, and neither reads the linked record's folder, so the pair "intent planned, its spec closed" passes every gate. Relayed from session gropiusllm-56, which called it a process observation rather than an abcd defect; recorded because the detector is cheap and the shape recurs wherever bucket moves and new records meet in one merge. Wanted: a record-lint rule that refuses a planned intent any of whose specs is in closed/ when no open spec remains, and a shipped intent any of whose specs is in open/. This is the inverse of itd-2609111003026787 (the gate for an intent whose work is live while its spec stays open), which reads the tree rather than the buckets, and a sibling of iss-2608290808193471; the bucket-agreement half is mechanical and needs no reading of the code.
- itd-150Agent worktrees commit without the private name-guard: .abcd/.work.local/ is per-worktree, so every isolated-worktree agent commit runs with the banlist layer absent — loudly warned, per design, but the isolated-agent pattern now systematically bypasses a protection the main checkout has. Candidate remedies: the worktree-creation path seeds a pointer to the primary checkout's store, or the hook falls back to reading the primary worktree's local tier
- spc-2609120450289528A gate catches the intent whose work is live while its spec is still open