watch-what-the-merge-triggeredlisted

# Watch what the merge triggered A pull request's checks run on a merge *preview*, with pull-request-scoped secrets. The merge produces a different commit, and `on: push` workflows run against it holding credentials a pull request was deliberately denied — so the first run after a merge is not a repeat of the PR's checks but the first execution of a configuration nothing could have tested. The failure it catches is specific: **code that only runs after a merge, and tooling that only runs after a failure.** Both are invisible until they are the only thing left working. ## Procedure ### 1. Get the merge commit, and hold it ```bash mc=$(gh pr view <n> --json mergeCommit --jq .mergeCommit.oid) base=$(gh pr view <n> --json baseRefName --jq .baseRefName) case "$mc" in [0-9a-f]*[0-9a-f]) [ ${#mc} -eq 40 ] || exit 1;; *) exit 1;; esac ``` **Check the shape before using it.** An unmerged pull request, a wrong number, or a merge queue still holding the merge all give an empty string or the literal `null`, and every step below interpolates `$mc` into a filter that then matches nothing. Step 3 reads "no run for `$mc`" as a legitimate answer, so without this guard a typo produces a confident all-clear. Every read below is pinned to `$mc`. A run for the branch tip is the PR's run, and a run for "the latest push to base" may be somebody else's merge a minute later — which is not a hypothetical on a repo with more than one session working. ### 2. Work out what SHOULD have started, be