Problem
bmad-build records a plan's baseline_revision as the HEAD of the branch the build runs on. When the story's PR is squash-merged, that commit is not an ancestor of main any more, and once the branch is deleted it can leave the clone entirely.
bmad-retrospective reads each ticket's diff range from these baselines and orders them. After squash merges, that ordering cannot run.
Seen
An epic of eleven stories, each merged by squash. In its retrospective:
- three baselines were no longer in the clone;
- five more were on no
main ancestor.
The retrospective fell back on each story's squash commit on main and recorded the narrowing.
Proposal
Either of these would work:
bmad-build records a baseline that survives the merge: the merge base of the build's branch with the default branch at the start of the build, rather than the branch's HEAD. Or it records both.bmad-retrospective reads a ticket's range from the squash commit on the default branch that carries the ticket's change, when the baseline is not an ancestor. For example, it can find that commit by the plan path the commit touches.
The first keeps the plan the single source of the range. The second needs no change to past plans.
Problem
bmad-buildrecords a plan'sbaseline_revisionas the HEAD of the branch the build runs on. When the story's PR is squash-merged, that commit is not an ancestor ofmainany more, and once the branch is deleted it can leave the clone entirely.bmad-retrospectivereads each ticket's diff range from these baselines and orders them. After squash merges, that ordering cannot run.Seen
An epic of eleven stories, each merged by squash. In its retrospective:
mainancestor.The retrospective fell back on each story's squash commit on
mainand recorded the narrowing.Proposal
Either of these would work:
bmad-buildrecords a baseline that survives the merge: the merge base of the build's branch with the default branch at the start of the build, rather than the branch's HEAD. Or it records both.bmad-retrospectivereads a ticket's range from the squash commit on the default branch that carries the ticket's change, when the baseline is not an ancestor. For example, it can find that commit by the plan path the commit touches.The first keeps the plan the single source of the range. The second needs no change to past plans.