Six repos require a PR but require nothing to be green; six carry a main-protection.json that was never applied

[sotashimozono]

What was measured

Every QAtlasHub package repo, 2026-09-01:

repo	enforce_admins	PR required	required status checks
QAtlas.jl	true	true	build, All tests passed, INVENTORY drift guard, format-check
TestShards.jl	true	true	version / check-version, format / format-check, test / All shards passed
ExperimentalAPI.jl	true	true	6 contexts (version, format, 3 julia legs, docs)
Pinax.jl	true	true	none
DataVault.jl	true	true	none
ParamIO.jl	true	true	none
Archeion.jl	true	true	none
AbstractQAtlas.jl	true	true	none
ParallelManager.jl	true	true	none

The gap

Six repos require a pull request and enforce it on admins — that part is right and already in
place. What they do not require is that anything be green.

A PR whose CI is fully red is mergeable in those six. The gate reads as protection and is only
half of one: it stops an unreviewed direct push, and stops nothing about correctness. QAtlas.jl
and TestShards.jl show the intended shape, so this is drift rather than a decision.

Fixing it is per-repo, because the context names differ: each repo's required set has to be read
off its own recent PR (gh api repos/OWNER/REPO/commits/SHA/check-runs) rather than copied, and
a required context that never runs leaves the branch permanently unmergeable — the failure mode
already documented for paths:-filtered required checks.

Worth deciding at the same time: required_linear_history is true only on TestShards.jl and
ExperimentalAPI.jl, false on the other seven.

Dead template files

Six repos carry .github/rulesets/main-protection.json:

• AbstractQAtlas.jl, DataVault.jl, ParallelManager.jl, ParamIO.jl, Pinax.jl, QAtlas.jl

None of them has a ruleset applied (all report zero), so the file has never been in effect. It
requires a status check named build, which exists in QAtlas.jl but not in the others — so
applying it as written would make five repos unmergeable.

Five of those also carry .github/scripts/setup_project.jl, which still renames MyModule and
is scaffolding from the template these repos were generated from.

Both read as configuration to anyone opening the directory. A file that looks like branch
protection and has never been applied is worse than no file, because it answers the question
"is this repo protected?" wrongly.

Proposal: delete both from all six, and keep protection where it is actually enforced — the
repository settings — rather than in a JSON nobody applies.

Note

This corrects an earlier reading in which these repos looked unprotected. They are protected;
gh api .../rulesets returns empty for them because the protection is classic branch protection,
not a ruleset, and checking only the ruleset endpoint answered a different question than the one
being asked.