Skip to content

stacked-prs-strand-main

A stack of PRs merged bottom-up collapses one level per merge — and unless someone opens the final PR to trunk, everything lands perfectly and ships nowhere.

What happened (2026-07-10)

The first-thaw milestone used stacked per-slice PRs: each slice branched off the previous, each PR targeting the slice below it. The maintainer merged all six bottom-up. Every merge was correct. Result:

  • main contained nothing but the seed docs.
  • The old milestone branch contained only the bottom slice — it was the base of PR #2, which merged before the upper slices cascaded down, so later content never reached it.
  • The full game had silently accumulated in slice/lights-on (base of the topmost PR), a branch nobody thought of as an integration branch.

Nothing was lost — git graphs don't lose things — but "the graph is correct and yet nothing shipped" required an archaeology session to even diagnose. The missing piece was one closing PR (slice/lights-on → main), a manual convention no tooling enforced.

The taxonomy of ways a stack goes wrong

  1. The stranded base (our case): the bottom PR's target stops receiving content the moment it merges early.
  2. The rebase cascade: a review change at the bottom forces re-rebasing every branch above it.
  3. The phantom finish: all PRs show MERGED, so the work feels shipped; no dashboard shows that trunk never moved.

The rule it produced

Trunk-based by default (recorded in AGENTS.md → Branching): slices are short branches off main, PR to main, merge fast, delete. A stack is a bounded exception that must name its closing PR at setup time, because by merge time everyone believes the work already landed. See trunk-based-won for why the industry evidence points the same way.