[BUG] bmad-loop resume requests rollback of already-committed work when orchestrator dies after successful dev session

[guilherme-argentino]

Description

bmad-loop resume requests rollback of already-committed work when orchestrator dies after successful dev session

Steps to reproduce

1. Run bmad-loop — let it drive a dev story to completion
2. Dev session finishes: commit pushed, sprint-status.yaml updated to done
3. Orchestrator process is killed before it processes the Stop event (crash, OOM, or
   signal)
4. Run bmad-loop resume
5. Resume emits rollback instruction and treats the session as a failed attempt

Expected behavior

Resume should check sprint-status.yaml before issuing any rollback. If the story status is
done, treat the session as complete and advance — skip rollback entirely.

Actual behavior

Resume reads only state.json (stale — reflects pre-crash state), ignores
sprint-status.yaml, and instructs git reset --hard <baseline>, which would undo
already-pushed commits.

Screenshots

No response

Which area is this for?

Orchestrator / control loop

bmad-loop Version

0.8.1

Which coding CLI are you using?

Claude (claude)

Operating System

Linux

Relevant log output

Diagnostic dump (bmad-loop diagnose)

No response

Confirm

• I've searched for existing issues
• If I attached a diagnose dump, I reviewed it and confirmed it contains no PII, secrets, or project-specific information
• I'm using the latest version

[coderabbitai]

⚠️ Possible Duplicate Issue(s)

• bmad-loop resume requests rollback of already-committed work when orchestrator dies after successful dev session #99

🔗 Related PRs

#63 - fix(engine): close resume-replay edges from #62 (final-cycle replay, stale result_json, record bloat) [merged]
#69 - chore(release): 0.8.1 [merged]
#78 - fix(runs): advance the re-arm baseline so a resolved re-drive cannot orphan resolution commits [merged]
#86 - feat(resolve): intent-gap patch-restore re-drive + inline-review-layer preflight (re-cut) [merged]
#93 - feat(sweep): extend intent-gap patch-restore re-drive to deferred-work bundles [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[guilherme-argentino]

Diagnostic data from a live reproduction

Reproduced on 0.8.1 / Linux / Claude adapter.

What state.json showed on resume

The session had completed successfully (result_json.status: "done"), but commit_sha was
null:

  "phase": "dev-verify",
  "baseline_commit": "9d59b70a3f6846f1b5d42ac06753df32f4f0c3d7",
  "commit_sha": null,
  "sessions": [{
    "status": "completed",
    "result_json": {
      "status": "done",
      "baseline_commit": "",
      ...
    }
  }]

The paused_reason asked to git reset --hard 9d59b70 — the baseline before the story's work.
Git HEAD was already 3 commits ahead of that, all pushed to origin.

Root cause (narrowed down)

Stop and SessionEnd events fired 0.2 ms apart:

...395074 — Stop
...395269 — SessionEnd

The orchestrator read the Stop event, extracted result_json (status: done), then died before
computing commit_sha (HEAD − baseline_commit) and writing it back to state.json. On resume,
it saw commit_sha: null + phase dev-verify and interpreted it as a stopped-without-result
attempt.

The custom workflow (git-jira-dod called inside the session before Stop) is not the cause —
commits were already pushed before the Stop event fired.

More precise fix suggestion

In the resume path, before issuing rollback, verify the assumption that commit_sha: null
means the attempt failed:

  if commit_sha is None and session.result_json.status == "done":
      # Attempt to recover: check if HEAD moved past baseline
      head = git_rev_parse("HEAD")
      if head != task.baseline_commit:
          task.commit_sha = head  # infer from current HEAD
          # advance normally, skip rollback

This is safer than checking sprint-status.yaml alone (which is user-defined), since it relies
on git state that the orchestrator already owns.