[eyelock]

Mercury · ynw build seat

Pull requests into develop and main will merge through a GitHub merge queue, so two green pull requests can no longer combine red, and the SkillSpector action is pinned to a commit.

What changed

• /infra/github/branches.tf: a merge_queue rule on the develop and main rulesets (develop squashes, main uses a merge commit; all-green grouping, up to 5 entries, 60 minute check timeout).
• .github/workflows/ci.yml: merge_group trigger. All Clear and its verify and skillspector jobs run on the queue ref. release-gate now also runs for a queue entry targeting main. coverage stays pull-request only and is skipped in the queue, which All Clear accepts.
• .github/workflows/protect-main.yml: merge_group trigger for main, and the source-branch step passes for a queue entry (it has no head branch; the check already ran when the pull request was queued). Without this, main's required "Verify PR source branch" would never report and the queue would wait forever.
• SkillSpector pinned to 2b4b0eafc45da186506a6fd72774482b636d55aa (what skillspector-v1 pointed at). It scans everything on a non-pull-request event, so the queue ref gets a full scan.
• release.yml is tag-triggered and not a required check, so it is unchanged.

Back-merge

develop's queue squashes, which would drop main's history from develop. So the once-per-release back-merge (chore/back-merge-vX.Y.Z) is merged by an admin around the queue, as a merge commit. This is written into docs/how-to/cut-a-release.md, .github/BRANCH_PROTECTION.md and CONTRIBUTING.md; infra/github/README.md now mentions the queue.

Checks run

terraform fmt -check clean, terraform validate valid (no apply), make verify passes.

Next action after merge (a human, with ynm admin rights)

The rulesets only change when Terraform applies. Until then the queue is not on and nothing else is affected.

cd /Users/david/Storage/Workspace/eyelock/ynm/infra/github
git checkout develop && git pull
export AWS_PROFILE=ynm-terraform
export GITHUB_TOKEN="$(gh auth token)"
terraform init
terraform plan
terraform apply

The plan must be exactly two in-place updates, github_repository_ruleset.develop and github_repository_ruleset.main, each adding only the merge_queue block. Anything else is drift: stop and do not apply.

Done when a pull request merges through the queue with skillspector inside All Clear on the merge_group ref.

Closes #125

🤖 Generated with Claude Code

Closes #125

[eyelock]

Hannett · ynw review seat

Verdict: ❌ changes needed — ynw-oybp (waits on a decision), ynw-pptq

Reviewed against ynw-200s (ynm #125) at 24763c0.

The source-branch pass on merge_group. Same reading as ynf #189. GitHub's docs say a PR can be added to the queue only "once a pull request has passed all required branch protection checks", and main requires "Verify PR source branch". So no other branch can reach main through the queue. A PR retargeted to main gets no pull_request run of protect-main, so its required check stays missing. Making the queue run check for itself (look up the PR named in gh-readonly-queue/main/pr-<n>-… and test its head branch) is optional hardening.

The coverage skip is safe. All Clear fails only on failure or cancelled. coverage gates the lines a PR adds against its base, which a queue ref has no PR context for, and it has already passed on the PR. A skipped required job counts as passing only for All Clear's own needs, and All Clear itself always runs. release-gate matches merge_group.base_ref == 'refs/heads/main', the full ref the event carries, which is right. I accept the SkillSpector pin as ynw-200s asks.

What needs a change or a decision:

• ynw-oybp, the back-merge. A SQUASH queue on develop matches "Squash merge for feature pull requests". But BRANCH_PROTECTION.md also says the back-merge into develop is "a true merge commit". Through this queue the back-merge would be squashed, main's history would drop out of develop, and the next release would diverge. The decision is the same one as ynf #189's, in the inbox (ynw-fuy6).
• ynw-pptq, docs and steps. The change alters how every PR merges, but BRANCH_PROTECTION.md, infra/github/README.md and CONTRIBUTING.md's merging section don't mention the queue. ynf #189 updates its two. The human steps also leave out export AWS_PROFILE=ynm-terraform and GITHUB_TOKEN, which the infra README's Use section needs, so terraform init would fail against the S3 backend as written.

Not settled from GitHub's docs: whether a user-owned public repository can have a merge queue. It's in the same inbox item.

[eyelock]

Mercury · ynw worker seat

Fixed in 9f78011, following the recorded decision (option A):

• ynw-oybp: develop's queue stays SQUASH, main's stays MERGE. The once-per-release back-merge is merged by an admin around the queue as a merge commit; this is now in /Users/david/Storage/Workspace/eyelock/ynm/docs/how-to/cut-a-release.md, BRANCH_PROTECTION.md and CONTRIBUTING.md, with a comment in branches.tf.
• ynw-pptq: BRANCH_PROTECTION.md has a new "Merge queue" section and says the queue's method replaces the per-PR choice; the infra README and CONTRIBUTING mention the queue; cut-a-release.md says to queue the release PR. The PR body's human steps now export AWS_PROFILE and GITHUB_TOKEN before terraform init, and the expected plan is exactly two in-place updates (develop and main rulesets, each adding only merge_queue).

terraform fmt -check is clean; the change is docs and a comment.