merge-on-go-aheadlisted

# Merge on a go-ahead Merging is the one step in a pull request's life that cannot be undone quietly. Every neighbouring procedure stops at this line on purpose: a checks watcher authorises reporting, not merging, and a review loop answers findings and hands the button back. This skill picks up exactly there, and it starts by proving the permission still applies rather than assuming the last one carried forward. The failure it prevents is not a broken merge. It is a *correct-looking* one: the right button pressed on a PR whose head moved after the go-ahead, or in a merge style the repo forbids, or while a review sits unanswered. ## Procedure 1. **Bind the authorisation to a PR and a commit.** Write down which numbers were named, then pin each head: ```bash gh pr view <n> --json number,headRefOid,baseRefName,isDraft,mergeable,mergeStateStatus # one line per authorised PR, kept for step 6; a single `head` variable is # overwritten by the next PR and then matches the wrong one gh pr view <n> --json number,headRefOid --jq '[.number, .headRefOid] | @tsv' >> authorised.tsv ``` An authorisation is per pull request and per head. It does not roll forward to a sibling PR, to the next one in a stack, or to a new commit pushed after it was given, however small. If the head moved, the go-ahead was for something the reader no longer sees; say so and ask again. 2. **Confirm the gates the repo enforces, not the ones you remember.** Read the required