Summary
At story-close, bmad-loop reliably files new deferred-work.md entries but never marks an entry resolved: when a later story closes it. Over several epics run back-to-back, this creates a one-way ledger: filing is automated, resolution-marking is not, so closed-but-unmarked entries pile up and the traceability policy ("deferred-work.md is triaged at every epic retro") silently depends on a human remembering.
Observed across four consecutive epics driven by the loop: each epic's stories closed multiple origin ledger entries, but zero carried a resolved: block afterward. The retro then has to reconstruct which story closed which entry by hand. In one epic the net motion was +6 filed / 0 marked / 8 silently satisfied.
Proposed feature
Let a story spec declare the ledger entries it closes (e.g. a Closes-Deferred: frontmatter list or a ### Closes deferred-work section referencing entries by a stable id/anchor). On successful story-close (post-review, post-verify, pre/post-merge), the orchestrator appends a resolved: Story <id> (<date>). <one-line note from the story>. block to each referenced deferred-work.md entry, mirroring how it already appends new entries.
Guard rails:
- No-op if the referenced entry already has a
resolved: line (idempotent on re-run/resume).
- If a referenced entry can't be found, surface it as a warning rather than failing the story (the entry text may have been reworded).
- Keep it declarative — don't try to infer closure from diffs.
Why the loop and not just the retro
The retro-time sweep is the current stopgap (we added a deferred:audit script that lists all unresolved entries so the triage can't miss one by omission). But the loop is the only place that knows, per story, that the story finished cleanly and what it changed — so it's the natural place to write the annotation the moment it's true, instead of reconstructing it an epic later.
Context
Running bmad-loop unattended across a five-epic arc (RBAC, money, nav, data-integrity, and their retros). Version 0.8.1.
Summary
At story-close,
bmad-loopreliably files newdeferred-work.mdentries but never marks an entryresolved:when a later story closes it. Over several epics run back-to-back, this creates a one-way ledger: filing is automated, resolution-marking is not, so closed-but-unmarked entries pile up and the traceability policy ("deferred-work.md is triaged at every epic retro") silently depends on a human remembering.Observed across four consecutive epics driven by the loop: each epic's stories closed multiple origin ledger entries, but zero carried a
resolved:block afterward. The retro then has to reconstruct which story closed which entry by hand. In one epic the net motion was +6 filed / 0 marked / 8 silently satisfied.Proposed feature
Let a story spec declare the ledger entries it closes (e.g. a
Closes-Deferred:frontmatter list or a### Closes deferred-worksection referencing entries by a stable id/anchor). On successful story-close (post-review, post-verify, pre/post-merge), the orchestrator appends aresolved: Story <id> (<date>). <one-line note from the story>.block to each referenceddeferred-work.mdentry, mirroring how it already appends new entries.Guard rails:
resolved:line (idempotent on re-run/resume).Why the loop and not just the retro
The retro-time sweep is the current stopgap (we added a
deferred:auditscript that lists all unresolved entries so the triage can't miss one by omission). But the loop is the only place that knows, per story, that the story finished cleanly and what it changed — so it's the natural place to write the annotation the moment it's true, instead of reconstructing it an epic later.Context
Running
bmad-loopunattended across a five-epic arc (RBAC, money, nav, data-integrity, and their retros). Version 0.8.1.