A bot merge goes through a pull request, because a push cannot be checked (T-1501)

[MongLong0214]

Closes T-1501 with ADR-0036. Advances #719; does not schedule it.

The question

F15 left one open: what verifies a commit the App assembles? "The source PR was green" is a statement about a different tree, so the naive privileged merge moves the gate from blocking before to reporting after — the limitation #723 records for preserve, adopted voluntarily.

The answer came from counting the required contexts

main requires eleven. Ten are the release gate's REQUIRED_CHECKS. The eleventh is lint, and demo-lint.yml says why it cannot be anywhere else:

lint:
  # The action's own range derivation works for PRs. On push events there is
  # no base_ref, so this job only runs for pull requests.
  if: github.event_name == 'pull_request'

A direct push produces no lint context, ever. Protection evaluates required contexts on the commit being pushed, so no push to main can satisfy protection on its merits — the App's or anyone's. Every push-shaped option needs a bypass, and a bypass is not "the check passed"; it is "the check did not have to".

Two numbers agreeing is what makes this decisive rather than a guess: protection requires eleven including lint, and REQUIRED_CHECKS is ten and excludes it — for exactly this reason, already documented in that file.

Decision

The App opens a pull request instead of pushing. It carries the source change plus a canonical rebuild, all eleven contexts run on it, and it merges like anything else. No bypass is requested, and none should be granted for this purpose.

It also kills the option that looked safest

A staging ref whose commit carries its own green checks appears to make a fast-forward stand on its merits. It does not — lint does not run on a branch push either, so the staging commit is missing the same context and needs the same bypass it appears to avoid. Recorded in the ADR because it is the shape a reader reaches for first.

Cost, and what it fixes

One extra pull request and one extra CI cycle per change — worse than today for a change that would not have conflicted, better for one that would.

What it fixes is what #719 is actually about: a contributor never needs build:canonical, on any platform. #720 arrived from Windows with src/ and test/ only and waited on a maintainer twice.

Scope

This answers how a bot merge is verified, not whether to build one. T-1502 onward stay unscheduled and #719's reopening conditions are unchanged.

Two assumptions are named as unmeasured, and T-1502 verifies them first. The load-bearing one: does an App-opened pull request trigger the checks at all? If on: pull_request does not fire for it, the rebuild PR is green with nothing having run — #722's empty runner in a new place.

[github-actions]

CommitLore — record lint

Trailers: clean — 2 commits in origin/main..aec23ef3b0b651deaefe09acdbd05c958803c385
Active constraints: not read — commitlore: git log --follow accepts exactly one pathspec, so renames are not followed for 3 paths; query one path at a time to follow its rename chain (3 changed paths)

_{Trailer violations fail this check. Active constraints are informational — they are what the repository already decided, not a verdict on this PR.}