Context
Upstream BMAD-METHOD PR #2612 (evaluated at 861cff8b) makes retro action items machine-consumable. sprint_status.py update now appends each action_items entry with:
- a stable
id — epic-<N>-retro-item-<n>-<slug> (explicit override honored), letting a consumer dedupe items across retro re-runs;
- a
ref — the path of the retro document holding the full, sourced finding behind the one-line action.
The id grammar is exactly bmad-loop's reserved RETRO_ITEM_RE (src/bmad_loop/sprintstatus.py:20), which until now was a dead-letter (it only kept epic-N-retro-item-* development_status keys out of unknown_keys; no upstream ever wrote them). The contract now lives in the action_items list instead — no key collision, same grammar.
bmad-loop currently ignores action_items entirely: load() reads only development_status (sprintstatus.py:79-123). Probe-verified: the new fields are inert to today's parser, and RETRO_ITEM_RE.match(item["id"]) succeeds on real upstream output.
Proposal
Make retro action items visible to the orchestrator as deferred work:
- Parse the top-level
action_items list in sprintstatus.load() (tolerant: unknown fields ignored, missing id/ref degrade gracefully for files written before the upstream rework).
- Surface open items (
status: open) to the sweep flow as ledger candidates, deduped by id; carry ref so triage can read the sourced finding in the retro document rather than judging from the one-line action text.
- Roadmap alignment: this is the "retro-item automation" the
RetroItem docstring (sprintstatus.py:50-56) already points at.
Out of scope: automatically flipping status: open → done in action_items (write-back to the list is a separate decision; advance()'s line-edit writer doesn't handle sequence entries).
Related: upstream bmad-code-org/BMAD-METHOD#2612; sibling issues for gates.retrospective="auto" and journal-override customization.
Context
Upstream BMAD-METHOD PR #2612 (evaluated at
861cff8b) makes retro action items machine-consumable.sprint_status.py updatenow appends eachaction_itemsentry with:id—epic-<N>-retro-item-<n>-<slug>(explicit override honored), letting a consumer dedupe items across retro re-runs;ref— the path of the retro document holding the full, sourced finding behind the one-line action.The
idgrammar is exactly bmad-loop's reservedRETRO_ITEM_RE(src/bmad_loop/sprintstatus.py:20), which until now was a dead-letter (it only keptepic-N-retro-item-*development_status keys out ofunknown_keys; no upstream ever wrote them). The contract now lives in theaction_itemslist instead — no key collision, same grammar.bmad-loop currently ignores
action_itemsentirely:load()reads onlydevelopment_status(sprintstatus.py:79-123). Probe-verified: the new fields are inert to today's parser, andRETRO_ITEM_RE.match(item["id"])succeeds on real upstream output.Proposal
Make retro action items visible to the orchestrator as deferred work:
action_itemslist insprintstatus.load()(tolerant: unknown fields ignored, missingid/refdegrade gracefully for files written before the upstream rework).status: open) to the sweep flow as ledger candidates, deduped byid; carryrefso triage can read the sourced finding in the retro document rather than judging from the one-lineactiontext.RetroItemdocstring (sprintstatus.py:50-56) already points at.Out of scope: automatically flipping
status: open → doneinaction_items(write-back to the list is a separate decision;advance()'s line-edit writer doesn't handle sequence entries).Related: upstream bmad-code-org/BMAD-METHOD#2612; sibling issues for
gates.retrospective="auto"and journal-override customization.