No status check is required to merge into development — measured across 10 repos, all zero

[rubenvdlinde]

The measurement

GET /repos/{repo}/rules/branches/development returns the effective rules, org-inherited included. Across ten repos — nextcloud-vue, openregister, opencatalogi, integriq, shillinq, pipelinq, dossiq, launchpad, hermiq, filinq — the answer is identical:

deletion            source=Organization:ConductionNL
non_fast_forward    source=Organization:ConductionNL
pull_request        source=Organization:ConductionNL

Zero required_status_checks. The entire 20+ check pipeline is advisory on the branch everyone works on: a PR with every check red merges on one approval.

main is the control that proves the instrument works — it does return required_status_checks, so the zero on development is a real zero and not a scope or endpoint problem.

⚠️ GET /branches/{b}/protection answers 404 "Branch protection has been disabled" here and tells you nothing. Rulesets are invisible to it.
⚠️ /orgs/ConductionNL/rulesets needs admin:org. The per-repo rules/branches/ endpoint needs no such scope and gives the effective answer.

Why this matters more than it looks

Each of the last three CI gaps closed on nextcloud-vue (#814 Playwright, #820 vue3-compile + public-safe, #823 dist-sideeffects) was invisible for the same reason: nothing forced anyone to look. Adding gates raises the ceiling; it does not raise the floor while every gate is advisory.

Per-repo aggregator state, latest COMPLETED Code Quality run on development

repo	quality / Quality Report
openregister	success
opencatalogi	success
shillinq	success
pipelinq	success
dossiq	success
launchpad	success
hermiq	success
filinq	success
integriq	🔴 failure

integriq would become unmergeable the moment checks are required. That is the single most important number here: the rollout is blocked on fixing integriq, not on the ruleset edit.

Proposed rollout

1. nextcloud-vue first (doing now) — shared library, a regression reaches all 21 apps.
2. Fix integriq's aggregator before it is included.
3. Then the rest, per repo, with the required contexts read from that repo's own completed run rather than assumed — check names differ (PHP apps emit jobs nextcloud-vue does not).

Also found: main requires a check that does not exist

nextcloud-vue's repository-level ruleset requires a context named Frontend Quality. No job by that name exists in any of its seven workflows, nor in the shared quality.yml, and it appears on no completed run. Release PRs into main merge anyway (#821, #817, #805) — so it is being bypassed, not satisfied. Worth auditing the other repos' main rulesets for the same shape.

Caveats on these numbers

• Aggregator verdicts are the latest completed Code Quality push run per repo; several repos had one queued at measurement time (the fleet queue was ~150 deep).
• ?event=push&branch=X&status=completed&per_page=N needs a large N: repos with many workflows crowd Code Quality out of a small page and the query then reports "no run" for a repo that has plenty. First pass with per_page=5 wrongly reported six repos as having none.
• 10 of 21 repos sampled, not all 21.

/cc @Rubenlinde