The workflow prefers one execution issue, one ticket-derived branch, and one PR because it makes the project narrative easier to inspect.
If a branch mixes several unrelated goals, the proof becomes harder to interpret, the PR discussion loses focus, and the final merge no longer explains one clear change.
What this makes easier
- understanding why a branch exists
- checking whether the proof matches the scope
- closing the right issue from the merge
- cleaning up branches instead of letting them linger
This is less about rigid process and more about preserving trust. A branch should tell a coherent story from issue to proof to merge.