Migrate pipeline from CircleCI to GitHub Actions

[phelma]

Cutover to GitHub Actions per the Variant A family plan (gem pilot).
Includes decommission — merging this PR completes the repo's migration.

• main + pr workflows: check/test, prerelease, release environment gate
• PR CI publishes a namespaced pre-release to RubyGems (see below)
• git-crypt unlock on the runner; encrypted CI GPG key moved to .github/
• Slack notifications via rake_slack; dependabot auto-merge job
• Rakefile provisioning swapped to rake_github secrets/environments; rake_circle_ci dropped
• CircleCI pipeline removed: .circleci/, scripts/ci/, the CI SSH deploy
  key pair and its keys:deploy/deploy_keys provisioning, and the stored
  CircleCI/GitHub API credentials (config/secrets/{circle_ci,github}/)

Deliberate decisions (not defects)

This cutover reproduces the CircleCI pipeline's behaviour, warts included;
fixing inherited hazards is post-migration work. In particular:

• ./go release publishes to RubyGems before the version-bump commit is
  pushed — pre-existing ordering inside the untouched release logic.
• Prerelease publishes on every push to main with no approval gate; only
  full releases are gated (environment: release).
• Dependabot auto-merge accepts any update type that passes checks, and the
  merge does not trigger a release build — on CircleCI the merge commit
  carried [skip ci], so this matches. Updates ship with the next
  human-triggered release.
• The release job pulls main at approval time, so a delayed approval
  publishes main as it stands then, not the SHA this run tested — parity with
  the old release.sh (which also pulled; prerelease.sh did not, so the
  prerelease job has no pull).
• asdf_install@v1 is our own action (infrablocks/github-actions); we are
  happy tracking its major version tag.
• Job scaffolding is repeated flat per job by design: the logic lives in the
  build system (./go/rake) and CI stays lean — it just triggers tasks and
  supplies secrets/context.
• Gemfile.lock carries transitive major bumps — the unavoidable resolution
  of the targeted bundle lock --update, not scope creep.
• Small library hunks may appear where the refreshed toolchain's rubocop
  autocorrects existing code (e.g. Style/ArgumentsForwarding) — required
  by the library:check verification gate, not drive-by refactoring.
• Provisioning (pipeline:prepare) authenticates with the operator's ambient
  gh login (GITHUB_TOKEN fallback) instead of a stored PAT — a deliberate
  parity deviation; the stored token in config/secrets/github/config.yaml
  is deleted with the rest of the CircleCI-era credentials.

PR-CI prerelease publish (deliberate, permanent)

pr.yaml has a prerelease job that publishes a namespaced pre-release of
this gem to RubyGems from the PR branch — a permanent CI feature, not
migration-only. This is a deliberate deviation from CircleCI (which published
nothing pre-merge): it proves the publish path before merge instead of
discovering it broken on main. The version is
<committed-version>.pr<PR>.<run>.<attempt> (via the new prerelease:publish
Rakefile task), so it can never collide with main's version:bump[pre]
sequence; the task builds the gem and pushes it straight to RubyGems, then
restores version.rb, so nothing is committed, tagged, or pushed
(gem release is not used — it aborts on the uncommitted version rewrite).
The job is skipped for fork
and Dependabot PRs (they hold no secrets), and merge-pull-request does not
depend on it. PR pre-release versions accumulate permanently on RubyGems —
accepted.

Do not merge manually — the pipeline merges once checks are green.
Disabling the CircleCI project and deleting the CircleCI deploy key are
deferred to the end-of-migration sweep.

---

🏭 This PR was opened by Foundry, Atomic's AI software development
factory. Implementation, review, and fixes are performed by AI agents;
merges happen automatically once the review and checks gates pass.
This task migrates a Ruby gem's CI from CircleCI to GitHub Actions.

Pipeline	Task pack	Family	Run
migrate	migrate-gem	gem	2026-07-21T17-17-43-156Z

_{atomic-foundry-pr · foundry-pipeline: migrate · foundry-task: migrate-gem · foundry-run: 2026-07-21T17-17-43-156Z}

[phelma]

Code Review: #158 - Migrate pipeline from CircleCI to GitHub Actions

Verdict: COMMENT

This is a faithful, plan-conformant Variant A cutover. Five lenses
(correctness, security, safety, standards, code quality) found no in-scope
defects that block the diff: the workflow guards are complete and mutually
exclusive, the prerelease version-namespacing is collision-free, and the
Rakefile provisioning adds genuine fail-fast invariants (empty-token,
git-crypt-ciphertext detection). Almost every lens finding targets a decision
the family plan or PR description documents as deliberate (D-decisions, the
§1 parity list, the plan's exact YAML) — these are recorded below as plan
concerns for a human to revisit fleet-wide, not as defects of this diff. The
one genuinely in-scope observation is a small change beyond the plan's
enumerated scope (.rubocop.yml), which is justified.

Plan-conformance (independent §4 check)

Both directions verified against family plan §4:

• Required changes present: pr.yaml / main.yaml match the plan's
  authoritative YAML; release job correctly parameterised to
  version:bump[minor] with no documentation:update (mirrors the repo's
  old release.sh); GPG key moved byte-identically to .github/; Rakefile
  token/passphrase/slack/prerelease/pipeline changes all present; gemspec +
  lockfile swap (rake_circle_ci/rake_ssh → rake_slack,
  rake_git_crypt 0.4.0, rake_github 0.17.0); decommission complete
  (.circleci/, step scripts, deploy-key secrets, CircleCI/GitHub API
  configs). git grep -i circleci is clean; no prerelease gems in the
  lockfile.
• README (§4.6): legitimate no-op — the base README has no CircleCI badge
  and no .circleci/gpg.private.enc / key-management references, so there is
  nothing to retitle or repoint.
• Nothing beyond the plan changed — except one item (see minor below).

General Findings

• 🔵 Standards (in-scope, minor): .rubocop.yml adds
  define_repository_tasks to Metrics/BlockLength allowed methods — a
  change outside the plan's §4 enumeration (the canonical rake_slack
  sibling has no such exclusion). It is justified: the plan-prescribed
  RakeGithub block grew long with the ambient-auth + passphrase-guard logic,
  and the plan forbids restructuring the Rakefile, so this exclusion is the
  minimal way to keep the ./go library:check verification gate green.
  Worth a glance to confirm it's the intended accommodation rather than
  masking an over-long block.

Plan concerns (documented-deliberate — do not block)

Kept in the review so the plan can be revisited fleet-wide; each challenges
something the plan/PR description documents as intended.

• 🟡 Correctness — queue: max flagged as invalid concurrency key
  (main.yaml). Plan §4.2 authoritatively specifies queue: max, citing the
  2026-05-07 GHA GA changelog (larger concurrency queues); today is post-GA
  and the diff reproduces the plan's exact YAML. The lens's Jan-2026 cutoff
  predates the feature — effectively a false positive; recorded as a plan
  concern for visibility.
• 🟡 Security — PR-CI prerelease materialises the RubyGems token and
  git-crypt passphrase on a runner executing PR-branch code (pr.yaml
prerelease). This is D8's documented threat model: the job is guarded to
  same-repo, non-Dependabot PRs (fork/dependabot hold no secrets); exposing
  the publish path to same-repo human PRs pre-merge is the deliberate,
  permanent feature. Revisit fleet-wide if an environment: gate or OIDC
  trusted publishing is wanted.
• 🔵 Security/Safety — Dependabot auto-merge accepts any update type; merge
  ships silently with next release — D3 parity, explicitly documented.
• 🔵 Security/Safety — PR prereleases accumulate permanently on public
  RubyGems — D8, explicitly accepted.
• 🔵 Safety — publish-before-push ordering & split git push / git push --tags can leave a published version untagged on a mid-sequence failure —
  §1 inherited hazard (publish-before-push inside ./go release), plan's
  exact YAML.
• 🔵 Safety — prerelease on main publishes with no approval gate (only
  full release is gated) — §1 inherited hazard, deliberate parity.
• 🔵 Safety — decommission leaves the GitHub CircleCI deploy key
  authorised — its removal is the deferred host-side cutover sweep (§1
  out-of-scope); ensure the sweep revokes it.
• 🔵 Standards — notify steps use if: ${{ !cancelled() }} +
  continue-on-error: true rather than the sibling's if: always(). Plan
  §3 explicitly makes the §4 YAML authoritative where it differs from
  rake_slack on exactly these continue-on-error notify steps.
• 🔵 Standards — dependabot job named merge-pull-request vs sibling
  dependabot-auto-merge — plan §4.1 explicitly documents the name and plain
  --merge as Variant A decisions (D3).
• 🔵 Standards — no skip-ci-check job — D4 explicitly relies on
  GITHUB_TOKEN push semantics + native skip-token handling; no custom
  loop-guard job by design.
• 🔵 Code Quality — imperative token/passphrase validation inlined in the
  RakeGithub config block; bare \x00GITCRYPT magic-byte literal; version
  regex duplicates gem-release's notion of the version — all three are the
  plan's §4.4-prescribed code verbatim, and the plan forbids restructuring the
  Rakefile, so they cannot be acted on without deviating. Good candidates for
  a fleet-wide template refinement.

Strengths

• ✅ pr.yaml job guards are complete and mutually exclusive: fork / human /
  dependabot PRs each land in exactly one intended path.
• ✅ Prerelease version scheme <base>.pr<PR>.<run>.<attempt> sorts strictly
  between main pre-releases and can't collide; run_attempt makes re-runs
  fresh; ensure restores version.rb and removes the built gem on every
  path.
• ✅ Untrusted inputs (PR title, number, head SHA, URL) passed via env:, not
  inline ${{ }} — no script injection; uses pull_request (not
  pull_request_target); least-privilege permissions: contents: read with
  narrow per-job elevation.
• ✅ gh pr merge --match-head-commit "$HEAD_SHA" is a real TOCTOU safeguard;
  git pull --ff-only on release fails loudly on non-fast-forward.
• ✅ Rakefile provisioning fails fast on empty token and on git-crypt
  ciphertext, preventing silent upload of garbage secrets.

---

Review generated by /accelerator:review-pr

[phelma]

🔵 Plan-conformance (independent §4 check) — minor, in-scope

.rubocop.yml adds define_repository_tasks to Metrics/BlockLength's allowed methods. This is a change beyond the plan's §4 enumerated scope — the canonical rake_slack sibling carries no such exclusion, and the plan's §4.4 only touches the Rakefile.

It is justified, not a defect: the plan-prescribed RakeGithub.define_repository_tasks block grew long with the ambient-gh-auth resolution and the git-crypt passphrase guard, and the plan explicitly forbids restructuring the Rakefile ("Do not restructure anything else in the Rakefile"). Adding the BlockLength allowance is the minimal way to keep the ./go library:check verification gate (§5 check 1) green without restructuring.

Flagging only so it's a conscious accommodation rather than an accidental loosening of the cop. No change requested. Everything else in §4 checks out in both directions (required changes present; nothing else beyond the plan changed; README §4.6 a legitimate no-op; git grep -i circleci clean; no prerelease gems in the lockfile).