Required context CodeRabbit has never posted, so main stays closed even with the CI startup death fixed

[hyperpolymath]

The finding

The ruleset on main requires five status checks. One of them, CodeRabbit
(integration_id: 347564), has never been posted on this repository — zero
appearances across PRs #106–#113 inclusive.

A required context that no actor ever posts can never be satisfied. It is not a
failing check; it is an absent one, and absence never turns into a pass.

Why it is being raised now

PR #113 fixes a different deadlock: a duplicate with: key in
.github/workflows/ci.yml meant every run was created with zero jobs, so
Code Coverage could never report. That is fixed and measured — PR #113's ci.yml
run creates 11 jobs where main's creates 0.

The effect is that required contexts went from 0/5 to 4/5:

required context	integration_id	status on PR #113
Code Coverage	15368	✅ skipped (satisfies — a skip is a pass; an absence is not)
CodeQL	57789	✅ success
governance / Code quality + docs	15368	✅ success
SonarCloud Code Analysis	12526	✅ success
CodeRabbit	347564	❌ never posted, on any PR

So main is still closed to non-admin merges, now for this reason alone. Every
merge on this repository continues to be a silent admin bypass until it is resolved.

This needs an owner decision, not a code change

Two routes, and they are not equivalent:

1. Install / enable CodeRabbit on this repository so the context actually posts.
   Keeps the intended review gate.
2. Remove CodeRabbit from the ruleset's required_status_checks. Honest about
   what is enforced, but drops the gate.

I have deliberately not changed the ruleset. Editing branch protection is the
owner's call and is outside the scope of the CI fix in #113.

Acceptance criteria

1. A pull request on this repository shows all five required contexts in a terminal
   state — or the ruleset lists only contexts that actually post.
2. The proof is a real PR's posted check-runs
   (gh api repos/.../commits/<head_sha>/check-runs), not the ruleset JSON. A
   committed or configured ruleset is not evidence of what reports; only a real PR is.
3. A merge lands without an admin bypass.

Note for whoever picks this up

Check integration_id as well as the context name. The ruleset pins each context to
a specific app, so a check of the right name posted by the wrong app does not
satisfy the rule.

🤖 Generated with Claude Code

https://claude.ai/code/session_01X3hgXxWm6umMgZkjYyHnnm

[hyperpolymath]

Retracted — the finding was a measurement error, not a defect

This issue claimed CodeRabbit had never posted on this repo and that the required
context could therefore never be satisfied. That is wrong, and the error was in my probe.

I enumerated GET /repos/.../commits/<sha>/check-runs and found zero CodeRabbit entries.
But CodeRabbit posts a commit status, not a check-run — and the two live on different
API surfaces. /check-runs does not include statuses, so the probe was structurally
incapable of seeing it.

Measured on the correct surface, GET /repos/.../commits/<sha>/status:

PR	head	CodeRabbit status
#110	—	pending
#111	—	success
#112	—	pending
#113	ab6d85b	success

#113's combined status is success, and the PR merged normally at 2026-09-22T06:52Z.
There is no second deadlock. The startup-death fix in #113 was the whole of the problem.

One real residue, much smaller than the original claim: CodeRabbit sits at pending
on #110 and #112 rather than resolving. A context stuck pending does block a merge while
it lasts, but it is a per-PR stall, not a permanent structural deadlock, and neither PR is
open. Not worth an issue on today's evidence; reopen this if a live PR stalls on it.

Closing as not-a-defect.

🤖 Generated with Claude Code

https://claude.ai/code/session_01X3hgXxWm6umMgZkjYyHnnm