CI: ci.yml does not run on a push to main, so main goes red and stays red (twice by the same boot.rs doc link)

[macanderson]

Problem

main's required fmt + clippy + test job has been failing for five
consecutive merges (2a142b26 #1951, dcb9859b #1952, 1bdf2daf #1953,
b5ab7f84 #1955, 43402ae4 #1965). Because a red main is inherited by every
branch, every open PR shows a red gate that is not its own — which trains
reviewers to ignore the signal, and hides the PR's real failures underneath.

The mechanism is stated in #1927's own description and has not been addressed:

ci.yml does not run on a push to main.

So a PR can be green at review time and still red main on merge, and nothing
re-runs to notice. With enforce_admins and auto-merge in play, the window is
routinely exercised rather than theoretical.

Evidence that this recurs, not just happens

crates/stella-cli/src/daemon/boot.rs's module doc has broken main's
rustdoc twice within two days, by the same mechanism:

1. fix(stella-cli): stop a parked run stalling the whole boot resume sweep (#1698) #1920 left [`supervised::APPROVAL_REQUEST`] unresolvable → fixed by
   fix(stella-cli): unbreak main — resolve the boot.rs doc link #1920 left dangling #1927, whose title is literally "unbreak main — resolve the boot.rs doc link
   fix(stella-cli): stop a parked run stalling the whole boot resume sweep (#1698) #1920 left dangling".
2. fix(stella-cli): resume a crash that recorded an error at boot (#1696) #1939 left [`SkipReason::NoResumePoint`] unresolvable → fixed by
   PR fix(stella-pipeline,stella-cli): unbreak main — clippy arg count and a dangling boot.rs doc link #1985.

Both are rustdoc::broken_intra_doc_links in the same file's //! block. Both
merged green as PRs. Neither was caught until a later, unrelated PR paid for
it.

The current pile-up has four independent errors from three PRs:

Error	Introduced by	Fixed by
plan_stage 8 args (clippy::too_many_arguments)	#1953	PR #1985
[SkipReason::NoResumePoint] unresolved (rustdoc)	#1939	PR #1985
PassingShell / shell_call_result undefined	#1945 (test file without its helpers)	PR #1964
ModelCallRole::Research match arm missing	#1953	PR #1964

Note #1945: it merged a new test file whose helpers were in a different PR.
A green PR check could not have caught that either, because the helpers existed
on that PR's branch.

Files

• .github/workflows/ci.yml — the trigger block; today it runs on
  pull_request (and ignores docs/**, *.md).
• AGENTS.md § "The gate — run before every push" — documents the three-workflow
  split and would need updating with whatever lands.
• .githooks/pre-push — the advisory local gate, currently the only thing that
  runs the full suite for a direct push.

Suggested direction (not prescriptive)

Add a push: branches: [main] trigger to ci.yml's required job so a broken
main is visible within minutes of the merge that caused it, and decide what
should happen when it fires (issue, revert, or just a red badge). Consider
whether docs-guards.yml and wire-schema.yml need the same, since the
paths-ignore split means each covers what the others do not.

Weigh the cost: main merges are frequent, and the job is ~10 minutes of
runner time each. A cheaper variant is a scheduled run plus a
merge_group/post-merge check.

Verify

1. gh run list --branch main --workflow ci.yml --limit 10 — today every recent
   entry is failure, and no run is triggered by the merge commits themselves.
2. After the change, merge something to main and confirm a run appears for the
   merge commit within a minute.

Done when

A merge to main triggers the required CI job on the merge commit, main's
status is observable without opening a PR, and AGENTS.md describes the trigger
matrix accurately.

Constraints

• AGENTS.md's gate-parity guard (scripts/check-gate-parity.sh) fails if the
  documented gate stops matching GATE_STEPS; update prose in the same PR.
• Workflow actions must stay pinned to commit SHAs (action-pins guard).

Noticed while repairing PR #1962's CI. Refs #1927, #1945, #1953, #1939.

[macanderson]

Further evidence, from the sixth consecutive unbreak (PR #2000, on top of
e0fbbe02).

The mechanism this issue names has a compounding effect worth recording: each
unbreak PR can only ever reveal the next layer, because both compile-tier
gates report one unit at a time.

• clippy stops at the first hard error in a crate, so every later lint in
  that crate is invisible.
• cargo doc --workspace stops at the first crate that fails to document, so
  every later crate's docs are invisible.

main at e0fbbe02 was red on five distinct breaks stacked behind one
another. Only the first was visible in CI's log:

1. pipeline/scope_stage.rs:34 — dead spend local (unused_mut +
   unused_variables). The only one CI reported.
2. management_prompt/tests.rs — ModelCallRole::Research listed twice in one
   match arm (unreachable_patterns). Behind feat(brand): Stella logo assets + README logo #1 in the same crate.
3. pipeline/tests/verification_hardening.rs — SHELL_TOOL,
   shell_call_result, PassingShell shadowed by the child module's own
   copies (dead_code ×3). Behind fix(zai): don't misreport an insufficient-balance 429 as a rate limit #2.
4. stella-protocol/src/event.rs:516 — unresolved intra-doc link to
   CompactionRewrite. A different gate step (doc-warnings), invisible
   while clippy was red.
5. file-size — driver.rs at 2572/2571 and pipeline/tests.rs at 2537/2536,
   both grown on main by merges that did not regenerate the baseline. Tracked
   separately as gate: the file-size baseline is a shared cell — two correct PRs compose into a red main (3rd occurrence) #2004.

Two further notes for whoever picks this up:

• fix(zai): don't misreport an insufficient-balance 429 as a rate limit #2 and feat: port Phase 3/4/5 crates (context/fleet/graph/mcp/media/pipeline/tui) from the monorepo #3 are the same shape: a merge landed the same addition twice.
  Neither side conflicts textually, so review sees nothing, and the resulting
  unreachable_patterns / dead_code is precisely the class of diagnostic that
  sits behind an earlier hard error. A main that were linted on push would
  have caught both at merge.
• The release-build step stayed green throughout. feat(brand): Stella logo assets + README logo #1–feat: port Phase 3/4/5 crates (context/fleet/graph/mcp/media/pipeline/tui) from the monorepo #3 are warnings under a
  plain cargo build and only become errors under -D warnings, so "it builds"
  was never evidence the required job would pass.

This is the argument for fixing the trigger rather than continuing to fix
instances: at one layer per PR, the queue drains at the rate someone notices.