Solutions
See the whole code delivery chain.
Connect required pull requests to the work and keep merge distinct from delivery.
The work to improve
A feature can span several pull requests. Closing the work after the first merge can leave essential changes, deployment checks or acceptance unfinished.
The delivery chain stays with the work record, including closed or merged PRs. A primary link makes the main PR easy to open without changing the repository.
Vision can show current policy evidence and recorded events, but unavailable or stale evidence remains explicit. The final delivery conversation can include the exact release and the acceptance observation.
What changes for your team
- Inspect multiple PRs from the source work item.
- Make required versus supporting scope explicit.
- Keep repository controls authoritative.
What you can explore in Vision
- Multi-PR delivery chains and stack relationships
- Checks, review and blocker observations
- Verified outcome by default, with explicit On merge policy
Questions worth asking
Can one task have several PRs?
Yes. The delivery chain can retain multiple PRs and classify them as required or supporting.
Does every merge close the task?
No. Verified outcome is the default. Explicit On merge requires every required PR to be merged before eligible completion.
Where does code review happen?
GitHub retains code review, checks, branch protection and merge controls.
Scope and availability
- GitHub identity, installation and repository authorization are required.
- Readiness is a snapshot; merge does not prove deployment or customer acceptance.