Imagine a migration branch passes CI. A minute later, another commit lands on that branch. The pull request still displays recent green activity, but the code a reviewer sees is no longer the code that produced the result.
This is not a theoretical edge case. Any asynchronous automation that edits branches and polls CI must decide what its green verdict actually refers to.
Bind the verdict to the head SHA
PatchFlow reads the pull request's immutable head SHA before evaluating required GitHub Checks. The stored result includes that SHA. If the branch moves, the old result is stale and cannot make the run ready.
The core rule is small:
required checks passed on head A ≠ required checks passed on head B
Named checks matter too. An unpinned system may see a quick lint job finish before a slower integration workflow even registers. Production policies should name the checks that exercise the affected integration. Missing named checks fail closed.
Base branches move as well
Longer-running pull requests introduce another relationship. The repository's base branch may advance after the migration was inspected.
Blindly accepting the latest base weakens the original authorization boundary. Requiring the base to remain byte-for-byte identical forever makes a safe recheck impossible after normal repository work.
The narrow solution is ancestry:
- the current base must descend from the originally inspected commit;
- the pull-request head must contain the current base; and
- required checks must pass on that exact head.
GitHub's commit comparison API can prove both relationships. A diverged base or stale head is rejected.
Keep merge authority separate
A passing verification record should never bypass branch protection or human review. PatchFlow opens draft pull requests and stops.
This separation produces a cleaner security model:
- PatchFlow can propose and verify.
- Customer-owned GitHub Actions can test.
- Branch protection and reviewers can authorize merge.
No single component gets to write the change, define the test, and merge the result.
What to record
A useful audit record for an automated migration includes:
- repository and pull-request number;
- original inspected commit;
- current base and verified head SHA;
- required check names and conclusions;
- provider attempt and model;
- settled execution cost; and
- the human-controlled merge outcome.
That record turns “the bot said it passed” into a claim another engineer can inspect.