Red PRs keep landing on main: enforce_admins is off and the pre-push gate is routinely --no-verify'd

[macanderson]

Problem

main has been red for most of 2026-08-05, twice, because red PRs are being merged —
not because of merge skew, and not because anyone disabled a check. Both halves of the
latest breakage were merged with their required check already failing:

PR	merged	fmt + clippy + test at merge
#1632	22:25:24Z	fail
#1623	22:26:06Z	fail

gh pr checks 1632 and gh pr checks 1623 still show it. #1623 was even titled
"Unbreak main" — the repair PR itself went in red, so main went from 13 compile errors
to a different set rather than to zero. Repairing that took a third PR (#1641).

Why nothing stopped it

There are two gates and both are bypassed by the normal workflow here:

1. Server side. main genuinely requires fmt + clippy + test,
   cargo deny + cargo audit, and harbor_adapter + analyzer pytest
   (gh api repos/macanderson/stella/branches/main/protection). But:

   "enforce_admins": { "enabled": false },
   "required_pull_request_reviews": { "required_approving_review_count": 0 }

   With enforce_admins off, an admin merge ignores the required checks entirely, and
   with zero required approvals nothing else is in the way.

2. Client side. make hooks installs a pre-push hook that runs make gate, and
   AGENTS.md names it as the thing that "catches that on the author's push" precisely
   when enforce_admins is off. It is bypassed with SKIP_GATE=1 or --no-verify — and
   --no-verify is the standing convention for agent pushes in this repo, because the
   full gate is minutes of local compute on a laptop.

So the documented backstop for enforce_admins: false is the one that routine practice
turns off. There is no net.

What "done" could look like

This is a judgement call for the repo owner, not an obvious code change — hence an issue
rather than a PR. Options, roughly in increasing order of friction:

• Flip enforce_admins to true. One API call. Makes the three required checks
  actually required for everyone. The cost is that a genuine emergency merge now needs the
  setting toggled off and back on deliberately, which is arguably the point.

  gh api -X POST repos/macanderson/stella/branches/main/protection/enforce_admins

• Keep admin bypass but make merging red loud. A scheduled or push-triggered job on
  main that opens (or reopens) a tracking issue the moment main's head is red, so a
  broken default branch cannot sit unnoticed between sessions.
• Make the local gate cheap enough not to skip. CARGO_SCOPE/make impacted already
  narrow it (Pre-push gate and CI run the full workspace for a single-crate diff #1135); GATE=fast exists. If --no-verify is being reached for because
  even the fast path is too slow, that is worth measuring — the escape hatch is being used
  as the default, which is the real signal.

Verify

After whatever change: attempt to merge a PR whose fmt + clippy + test is failing. It
must be refused, or must produce an immediate, visible alarm.

Context

This is the second pileup on the same day (#1634 was the first — 13 compile errors at
23d306a5). Related but distinct: #1527 covers auto-merge PRs deadlocking at BEHIND
under strict up-to-date protection, which is the opposite failure — protection being
too strict to make progress rather than too loose to stop a regression. Both point at the
same settings block.

Refs #1632, #1623, #1634, #1641, #1527

[macanderson]

Another instance, with data — and one correction to the record.

Incident. 4bcee7e6 (#1646, itself an "unbreak main" PR) left the required ci job red on four counts. Fixed on main in af97c36a:

Break	File	Class
let-else missing its ;, then Metadata::assume_init	crates/stella-cli/src/daemon.rs:945	2 compile errors
manual_clamp	crates/stella-tui/src/views/scope_dialog.rs:69	clippy -D warnings
public doc links a crate-private module	crates/stella-tui/src/views/session.rs:10	rustdoc -D warnings
unused run.pgid binding	crates/stella-cli/src/daemon/tests.rs:246	-D warnings under --all-targets

The correction. My commit message for af97c36a claims these are Linux-only breaks a macOS make gate cannot see. That is wrong, and it understates this issue's case rather than supporting it. All four reproduce on every platform: Metadata has no assume_init anywhere, a missing ; is a parse error anywhere, and the other three are platform-independent lints. cargo fmt --check alone — the second-cheapest gate step — rejects the daemon.rs hunk. Nobody ran anything.

Why this issue matters more than the count suggests. #1646 did not introduce novel breakage; it reverted a fix. #1641 had already rewritten inherited_lock_fd to read fd identity through MetadataExt (dev()/ino() are u64 on every Unix, which is the entire reason that rewrite exists — dev_t is unsigned on Linux, signed on macOS). #1646 resolved a conflict by restoring the superseded raw libc::stat body underneath the comment that explicitly says the identity is not read that way. The comment and the code contradicted each other in the merged result, which is the signature of a conflict resolved without compiling.

That failure mode is specific and repeatable: an "unbreak main" PR is authored against a red tree, so its author has no green baseline to compare against and the bypass feels justified. crates/stella-cli/src/daemon.rs shows the cost — 4 of the last 9 commits touching it are unbreak commits (#1610, #1641, #1646, af97c36a):

af97c36a unbreak (this one)
4bcee7e6 Unbreak main ... (#1646)   <- reverted 780af9db's fix
b3c22aa3 feat ... (#1587) (#1640)
780af9db Unbreak main ... (#1641)
bfb3833b fix(stella-cli) ... (#1632)
542c1673 feat(stella-cli) ... (#1603)
0e97224d Unbreak main ... (#1610)
3c3e19a7 feat(stella-cli) ... (#1594)
097a93f5 feat(stella-cli) ... (#1591)

Suggested addition to whatever this issue lands. Whatever gate is enforced, exempting unbreak PRs is the wrong instinct — they are the ones empirically most likely to merge red, and their conflict resolutions are the ones most likely to resurrect superseded code. If a full gate is too slow for an emergency unbreak, GATE=fast (guards + fmt + clippy, no tests) would have caught all four of these.

[macanderson]

Status confirmed accurate during an issue-status sweep, with fresh evidence.

The protection settings are unchanged. Straight from the API today:

{
  "checks": ["fmt + clippy + test", "cargo deny + cargo audit",
             "harbor_adapter + analyzer pytest"],
  "enforce_admins": false,
  "reviews": 0,
  "strict": true
}

Two things there beyond the enforce_admins this issue is named for:

• reviews: 0 — required_approving_review_count is zero, so nothing but the
  status checks stands between a push and main, and enforce_admins: false lets an
  admin past those. Worth stating explicitly in this issue, because "review required"
  is a reasonable assumption a reader would otherwise carry in.
• strict: true — the up-to-date requirement that Armed auto-merge PRs deadlock at BEHIND under strict up-to-date protection — nothing updates their branches #1527 reports armed auto-merge
  PRs deadlocking against. The two issues are reading the same setting from opposite
  sides; whatever changes here should be checked against Armed auto-merge PRs deadlock at BEHIND under strict up-to-date protection — nothing updates their branches #1527 before landing.

It happened again today. PR #1736 merged from a stale base and left main not
compiling — E0433 on an unimported fleet_verbs in cli.rs:674, E0308 on a
duplicated Command::Fullauto match arm at main.rs:809. Fix is PR #1747.

The detail that makes this one a clean example for this issue: #1736's PR body is
the unmodified template. Literal Closes #N, every gate checkbox unticked
(cargo fmt --check, cargo clippy, cargo test), the "Nothing left behind"
section untouched, and the HTML instruction comments still in place. It merged
anyway. Whatever guard comes out of this issue, "the template was never filled in"
is a signal available before any code is even read, and it is currently unused.

Related recurrences catalogued in #1722 (no duplicate-PR or stale-base detection) and
#1725 (#1616 implemented twice — five consecutive red-main events from one cause).