A pull-request stack is an ordered, same-repository delivery unit. Warestack shows the stack while still evaluating every PR layer on its own evidence.
Two identity sources
| Source | Meaning |
|---|---|
| Confirmed GitHub stack | GitHub’s native stack identity and order are authoritative |
| Warestack-detected | A same-repository branch graph forms a safe linear chain and GitHub has not supplied native stack metadata |
Warestack does not silently conflate the two. If GitHub’s native stack and a branch graph disagree, GitHub wins and the disagreement remains diagnostic evidence.
What you can see
- Stable stack identity and lifecycle.
- Position such as
2 of 4. - Parent and child relationships.
- Each layer’s branch, checks, reviews, ticket evidence, and rule findings.
- Aggregate readiness without hiding a blocked layer.
- Freshness and stale-topology status when reconciliation needs attention.
Readiness is evidence, not a shortcut
A stack is not “ready” because its top PR is green. Each layer keeps its own ticket, review, checks, and findings. Merge readiness also stays separate from deployment readiness.
Duplicate open heads, forks, cycles, or incomplete provider state are unsafe to guess. Warestack preserves the last known-good projection and reports the diagnostic condition.
Repository boundary
Every branch in a stack belongs to one repository. Fork-origin and cross-repository PRs cannot join a stack.
A change spanning database, API, and frontend repos is a different problem. See Cross-repository guards, which are not generally available rather than a shipped cross-repository stack.
Where stacks appear
- The Events feed.
- Pull-request event headers and detail.
- Stack-aware timeline and readiness context.
This lets a reviewer understand the delivery order without flattening several PRs into one pass/fail result.