main cannot return to green by itself: diff-scoped gates anchor on the last SUCCESSFUL run, so a red main widens its own range and keeps re-flagging the commits blocking it

[localai-bot]

main cannot return to green on its own once it has been red across a commit that any diff-scoped gate flags. The range that decides those gates is anchored to the last successful run, and a successful run is what the gate is blocking.

The cycle, from .github/workflows/ci.yml

last-gated-commit resolves the anchor:

sha="$(gh api \
  "repos/$REPO/actions/workflows/ci.yml/runs?branch=$BRANCH&event=push&status=success&per_page=1" \
  --jq '.workflow_runs[0].head_sha')"

documentation-checkpoint consumes it on a push to main:

base="${LAST_GREEN:-}"
[ -n "$base" ] || base="$PUSH_BASE"
head="$PUSH_HEAD"
python3 scripts/check-now-current.py --base "$base" --head "$head"

So: main goes red → no successful run → LAST_GREEN stays put → every later push widens LAST_GREEN..HEAD → the widening range keeps re-including the commit that is being flagged → the job fails again → still no successful run. The exit condition requires the thing it blocks.

Observed now: documentation-checkpoint on main flags dd8a3b0e1, 8daf58e77 and 38ec0da4a — three commits from 2026-08-18, five days old, each carrying the full protocol paragraph and all three trailers, each with a single parent (the shape of a squash merge, this repository's only landing mode). Two are from external contributors, whose row/<ID> branches live on their forks and can never appear on origin. They cannot be retroactively re-landed, so under the present anchor they will be flagged on every push forever.

Two defects, and the repository already documents both

scripts/main-baseline.py (issue #274, spec .agents/specs/main-verifiability.md) was written to answer exactly "what is the last SHA where main was fully green", and its own header records the two reasons a naive query cannot:

1. Runs do not finish. "Every expensive job in ci.yml carries a job-level concurrency group keyed on github.ref with cancel-in-progress: true. For a push to main that ref is the constant refs/heads/main, so consecutive pushes cancel each other's long jobs — 26 of the last 40 main runs were cancelled." A cancelled run is not success, so on a busy day the anchor drifts back by many commits even with nothing broken. Confirmed live today: the three newest ci runs on main (15298f033, aa67130cc, 6991b78d2) are all cancelled.

2. Run-level success is not per-job success. "sanitize-cpu is continue-on-error: true, so its failure does not fail the run... A tool that trusted the run conclusion would publish that SHA as the known-good baseline. The verdict is computed from PER-JOB conclusions, always."

last-gated-commit queries status=success at the run level — precisely what main-baseline.py says must not be trusted — and does not use main-baseline.py at all. The tool built to answer this question is not wired to the job that asks it.

Why this is worth fixing rather than clearing by hand

Clearing it once (landing something that makes a run succeed) resets the anchor and hides the mechanism until the next red. The cost is paid repeatedly and by everyone: a red main blocks every branch, and this week three separate lanes converged on #1731 because a blocking red creates pressure to act before checking ownership, producing a duplicate issue (#1733) and duplicate branches.

Candidate directions, not a prescription

• Anchor last-gated-commit on scripts/main-baseline.py's per-job verdict rather than a run-level status=success query.
• Give the anchor a floor, so a range can never widen past a recorded baseline no matter how long main has been red.
• Decide what a diff-scoped gate should do with a squash merge whose branch is on a fork — teach the checker, or record a bounded exception. Note that whatever is decided must not weaken the rule for work that can use an origin branch.

Whoever takes this should confirm the cycle by construction (a red push, then a second push, and show the range widening) rather than only by reading, since the claim is about a feedback loop.

Refs #1764 (the three current reds), #274.

[localai-bot]

Correction to this issue's third bullet: the fork premise is refuted.

I wrote that a squash merge "whose branch lives on a fork cannot be found on origin" and listed teaching the checker or recording a bounded exception as the options. Measured since: scripts/check-role-discipline.py resolves no ref. Arrival for a single-parent commit is decided from commit MESSAGE TEXT — ROW_BRANCH.search(subject+body) or PR_REFERENCE.search(subject) — so fork versus origin is not part of the test.

PR #1159 settles it: its head was mudler/vllm.cpp:row/ENG-RELEASE-WINDOWS-test-thread-raii, on origin, and it fails exactly as the fork-origin ones do. The discriminator is the squash subject lacking a (#N), which happens when the merger passes an explicit commit_title — that suppresses the reference GitHub appends even under squash_merge_commit_title = PR_TITLE.

So no exception is needed and no rule needed weakening. The gap is in the landing procedure, not in what an external contributor is able to do.

Two things measured while confirming the cycle, both worse than this issue states:

The live range is 484 commits. At base 21abaf169 the anchor query returns fafa16f0f from 2026-08-12, and the checker over that range reports five commits rather than the three named in #1764. A widening range accretes offenders, so any such count measures how long main has been red rather than how much is wrong.

A second defect, sharper than the cycle itself. In run 32625264281 (push of 1fdd3e26d) the run concluded cancelled, but documentation-checkpoint inside it concluded success while last-gated-commit was cancelled. The gates carry if: always(), so they outlive their own resolver: LAST_GREEN rendered empty, the step fell back to PUSH_BASE, and the gate passed. main's diff gates were green when the resolver lost the cancellation race and red when it won — neither reading was about the tree.

PR #1776 is open against this issue.

[localai-bot]

Refinement to my correction above: the refutation stands, but the replacement mechanism I gave is inferred, not measured.

Independently confirmed by a fresh review: scripts/check-role-discipline.py:168 is exactly ROW_BRANCH.search(message) or PR_REFERENCE.search(subject), and a grep for ls-remote, for-each-ref and origin/ over that file returns nothing — it resolves no ref, so fork-versus-origin genuinely cannot be the discriminator. PR #1159, whose head was on origin, is flagged identically. Repository settings are squash_merge_commit_title=PR_TITLE and squash_merge_commit_message=PR_BODY, and PR #1752's title contains no # yet it landed as … (#1752).

What I stated as fact and should not have: that the offending squashes lack (#N) because the merger passed an explicit commit_title. The forge API does not record whether a commit_title was supplied, and all five were merged by the same account that appends (#N) correctly today. So that is the most plausible reading of the evidence, not an observation. Treat it as a hypothesis with an obvious test rather than the cause.

One count also corrected: four of the five offending pull requests carry a "Maintainer changes on top" section (#640, #1056, #1065, #945), not three.

Separately, and unrelated to this issue except that it surfaced in the same review: operator role records outlive their worktrees — two of three claims in .git/vllm-cpp-operators/ name gitdirs that no longer exist. Filed as #1781.