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#175.

What changed

• aa7c9b9 Apply commit, apply.sh output alone: brings feat: Cap re-Apply PRs' reviews, and take review:claude off only after Claude's review dotfiles#175.
  • .github/scripts/tests/pr-automerge.test.mjs
  • .github/workflows/pr-automerge.yml
  • docs/PROCESS.md

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 aa7c9b9.

🤖 Generated with Claude Code

[github-actions]

Test Results Summary

485 tests  ±0   485 ✅ ±0   25s ⏱️ +3s
  9 suites ±0     0 💤 ±0 
  9 files   ±0     0 ❌ ±0 

Results for commit aa7c9b9. ± Comparison against base commit 806005f.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 85.63%. Comparing base (806005f) to head (aa7c9b9).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #252   +/-   ##
=======================================
  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. It changes pr-automerge.yml in two ways:

1. Re-Apply PRs are now capped (#174). The chore/reapply-baseline exemption (REAPPLY_BRANCH, headRefName) is gone, so a re-Apply PR now merges after three review rounds like any other PR.
2. review:claude comes off later. At the cap, the label is now removed only once Claude has reviewed since it was last added. This is checked by comparing each Claude review's submittedAt with the time of the latest labeled event. If the label events can't be read, any Claude review counts.

The new shared isOpenSameRepoPrIntoMain helper keeps the old checks, including the draft exclusion in isOpenSameRepoPr. The tests and docs/PROCESS.md are updated to match.

Paths checked, no problem found:

• No labeled event found: the cutoff becomes -Infinity, so any Claude review counts.
• Pending reviews: their submittedAt is null, Date.parse gives NaN, and the comparison is false, so they don't count.
• Two timestamps in the same second: the strict > treats a review that lands in the same second as the label as not after it, which errs on the side of keeping the label.
• Event lookup only when needed: label events are fetched only when the cap is reached, because capReached && short-circuits.
• Forks, other base branches, merged and closed PRs: the label is left alone, and there are tests for each.
• Event order: issue events come back oldest first, so findLast finds the most recent labeled event.

Policy change to accept knowingly. Once a re-Apply PR has had three review rounds, later re-Apply commits merge without any review of the head. Those commits typically rewrite workflows, including this merge gate. The change is deliberate and documented (#174).

What I relied on without checking. I assume GitHub doesn't trigger workflows for reviews posted with GITHUB_TOKEN. If so, the label is removed on the next PR Auto-Merge run (for example, the next push), not as soon as Claude's review lands.

Verdict: the logic looks correct. One test gap is listed below.