chore: Re-apply the repo-ci-baseline Template

[mpaulosky]

Why

Re-Apply the repo-ci-baseline Template so this repo carries the Template changes from mpaulosky/dotfiles#176, mpaulosky/dotfiles#178 and mpaulosky/dotfiles#180.

What changed

• 58619ee Apply commit, apply.sh output alone: brings fix: Update one BEHIND PR per sweep, and pin mode changes in clean merges dotfiles#176, fix: Make a sweep's one update after its merges, and only if it merged none dotfiles#178 and fix: End a sweep on an error that holds for the whole run dotfiles#180.
  • .github/scripts/tests/pr-automerge.test.mjs
  • .github/workflows/pr-automerge.yml

Verification

• The Apply commit is exactly apply.sh's output on a branch up to date with main.
• The pre-push gate (scripts/gate.sh) passed on 58619ee.

🤖 Generated with Claude Code

[github-actions]

Test Results Summary

485 tests  ±0   485 ✅ ±0   26s ⏱️ +2s
  9 suites ±0     0 💤 ±0 
  9 files   ±0     0 ❌ ±0 

Results for commit 58619ee. ± Comparison against base commit de8d87a.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 85.63%. Comparing base (de8d87a) to head (58619ee).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #254   +/-   ##
=======================================
  Coverage   85.63%   85.63%           
=======================================
  Files          75       75           
  Lines        1566     1566           
  Branches      186      186           
=======================================
  Hits         1341     1341           
  Misses        190      190           
  Partials       35       35           

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[github-actions]

Claude Review

What the PR changes: .github/workflows/pr-automerge.yml changes how a sweep works. A sweep is a push, schedule or manual run, and it now lists open PRs oldest first. On the first pass it only notes which PRs are ready but BEHIND main. If the sweep merges anything, it updates nothing and leaves that to the merge's push. If it merges nothing, it reads each noted PR again and brings only the first one still ready and BEHIND up to date. A Dependabot rebase request counts as that one update, unless Dependabot was already asked for the same head; then the sweep moves on to the next PR.

Error handling: a PR whose evaluation throws is logged as a warning, the sweep carries on and makes its update, and the run is failed at the end. Errors that last for the whole run end it at once: a 401, a 429, a 403 that is a rate limit, or a GraphQL RATE_LIMITED error. PR events still bring their own PR up to date. The header comment also gains a note about re-Apply PRs and ADR 0002.

Tests: .github/scripts/tests/pr-automerge.test.mjs extends the mock. Each PR number can now have its own GraphQL snapshots or read errors, list requests are recorded, and tree entries can carry a file mode. New tests cover:

• the one-update rule, including both Dependabot cases
• re-reading a noted PR before updating it
• a 422 on one PR moving the update to the next
• a merge in the sweep holding back the update
• how errors are handled, and which ones end the run
• measuring the review:claude cap from the label's last addition
• merges from main that only change a file's mode

Checks I made:

• sweeping is consistent with how pullNumbers is chosen: everything that isn't a pull_request_target or workflow_run payload already took the list-all branch.
• Candidates are cleared from the second pass correctly in each case: merged, already updated, a 422, an error, or no longer ready.
• sort: "created", direction: "asc" is valid for pulls.list; the default direction for created is desc, so it is needed.
• Octokit's response headers are lowercase, so the x-ratelimit-remaining and retry-after checks work.
• Run-ending errors still escape from both passes.
• failed can't hold a PR twice, because a PR that failed on the first pass never becomes a candidate.

What I'm relying on: "whose push sweeps again" holds only if the script's token isn't the default GITHUB_TOKEN, since pushes made with it don't start new workflow runs. I couldn't check the token here. But updateBranch already depends on the same thing for CI to re-run on the updated branch, so this is consistent with the existing design. If a re-run notices a PR but its update fails, that PR now waits for the next schedule or push. That's a deliberate trade the comment explains, not a bug.

Minor, not filed: when the one update is a Dependabot rebase request, the log for the PRs after it says "already brought PR #N up to date", though Dependabot was only asked. The test asserts this wording.

Coverage: the only piece, 001.diff (pr-automerge.yml and pr-automerge.test.mjs), was read in full. I didn't open the unchanged parts of mergeIfReady in the checked-out workflow. So I'm assuming the rest of a ready PR's evaluation does no harm when it runs a second time (for example removing review:claude, which a fresh read would show is already gone). That assumption isn't verified.

Verdict: no problems found; OK to merge.

No findings.