ci: add ci aggregator job to unblock branch-protection required check

[IgorShevchik]

Unblocks PR #20 (release v0.1.0) without needing branch-protection edits.

The problem

Branch protection on main requires a status check named ci. GitHub reports check statuses per job, not per workflow — so a required check ci (likely typed expecting it to match ci.yml) has no matching job and sits as "Expected — Waiting for status to be reported" forever. Every PR's Merge button is greyed out because of this single ghost check.

PR #20 (release-please's v0.1.0 PR) is currently in exactly this state: 7 successful checks, 1 pending ci that will never resolve.

The fix

Add a tiny aggregator job named ci at the bottom of .github/workflows/ci.yml. It needs: every other gate and reports a single pass/fail status based on their combined results. Branch protection's required ci check now has a real source.

  ci:
    name: ci
    runs-on: ubuntu-latest
    if: always()
    needs: [lint, typecheck, test, build, docs]
    steps:
      - name: Aggregate required-gate results
        env:
          LINT: ${{ needs.lint.result }}
          TYPECHECK: ${{ needs.typecheck.result }}
          TEST: ${{ needs.test.result }}
          BUILD: ${{ needs.build.result }}
          DOCS: ${{ needs.docs.result }}
        run: |
          # … bash check; exit 1 if any !=success

if: always() is load-bearing — without it, a failed dependency causes the aggregator to be skipped, which leaves the required check perma-pending and reproduces the exact bug we're fixing.

Why this works without admin access

Workflows on a PR are read from the PR's head branch, not from main. So this PR's own CI run will execute the new aggregator job, the required ci check will report a real status, and the merge unblocks. Once merged, every subsequent PR (including PR #20 after rebase) gets the same treatment.

What's NOT in the aggregator

Commit messages (commitlint) is intentionally excluded from needs: — it only runs on pull_request events and would mark the aggregator as failed on direct pushes to main. Branch protection can require Commit messages separately alongside ci, or just require ci and accept that commit discipline is enforced PR-side only.

CONTRIBUTING.md update

"One-time maintainer setup" step #2 rewritten to document two equivalent options:

• Single aggregator (recommended): require just ci (+ optionally Commit messages).
• Explicit list: require every CI job by its name: field — with an explicit warning that adding the workflow filename (ci / ci.yml) instead silently blocks every PR (the exact bug this PR fixes).

After this PR merges

1. PR chore(main): release b24rabbitmq 0.1.0 #20 (release-please v0.1.0) needs to pick up the new ci.yml. Two options:
   • I can locally merge main into the release-please branch and push — pulls the change in.
   • Or the release-please bot picks it up on next push to main (but that requires another push first; simpler to do option 1).
2. PR chore(main): release b24rabbitmq 0.1.0 #20's CI runs include the ci aggregator → required check satisfied → merge unblocks.
3. release-please creates tag v0.1.0 + GitHub Release → triggers npm-publish.yml → OIDC publish.

Gates

Gate	Result
pnpm lint	green
pnpm typecheck	green
pnpm test	66/66
pnpm test:coverage	100/100/100/100
pnpm build	green
pnpm docs:build	green

Behavioural change

None in src/. New job runs only in CI. No public exports affected.

---

Generated by Claude Code