Outcome
A stacked PR presents its own layer as the primary review diff and offers an explicit cumulative preview, so reviewers never see a surprise giant diff when a lower branch rewrites.
Context
docs/stacked-prs.md section 10 defines the two views. The layer view diffs the direct base against the head; for a healthy stack the merge base equals the parent head, which is why stored boundary OIDs — not branch names — define the range.
Acceptance criteria
- Layer diff computes from the entry's boundary OID to its observed head OID.
- Cumulative preview computes from the stack trunk tip to the head and labels itself as everything through this position.
- When a parent rewrite moves the merge base backward, the UI shows the stale-boundary explanation with a restack action instead of silently rendering lower layers inside the layer diff.
- Both views respect existing repository read authorization on the PR surface.
Verification
Controller or LiveView tests asserting each view's commit range, plus the stale-boundary state. Run mix precommit.
Dependencies
Stack schema (#47). Lands alongside or after the basic PR diff view (#1).
Outcome
A stacked PR presents its own layer as the primary review diff and offers an explicit cumulative preview, so reviewers never see a surprise giant diff when a lower branch rewrites.
Context
docs/stacked-prs.mdsection 10 defines the two views. The layer view diffs the direct base against the head; for a healthy stack the merge base equals the parent head, which is why stored boundary OIDs — not branch names — define the range.Acceptance criteria
Verification
Controller or LiveView tests asserting each view's commit range, plus the stale-boundary state. Run
mix precommit.Dependencies
Stack schema (#47). Lands alongside or after the basic PR diff view (#1).