main is red on three CI jobs and every PR inherits them: a SiteGuard test errors, documentation-checkpoint re-flags three five-day-old external squash merges, and commit-protocol-tag fails for an undetermined reason

[localai-bot]

main at 66d1b0a90 fails three CI jobs, and every pull request cut from it inherits them. None is owned by an open issue.

1. agent-record — a SiteGuard test errors

ERROR: test_rendered_benchmark_index_links_resolve_to_emitted_pages
       (__main__.SiteGuardTests.test_rendered_benchmark_index_links_resolve_to_emitted_pages)
FAILED (errors=1)

Reproduced on main's own run (job 97140379573) and inherited unchanged by PR #1744 (job 97125591865), which touches neither the site nor the benchmark pages. The cause is not diagnosed here; only that it is main's and not any branch's.

2. documentation-checkpoint — three commits "reached main without arriving on a task branch"

ERROR: dd8a3b0e1: repository change (CMakeLists.txt, src/vllm/model_executor/model_loader/safetensors_reader.cpp,
       src/vllm/support/platform_compat.h, tests/CMakeLists.txt, ... (+7)) reached main without arriving on a
       task branch.
ERROR: 8daf58e77: repository change (tests/vllm/entrypoints/openai/test_api_server.cpp) ...
ERROR: 38ec0da4a: repository change (include/vllm/v1/attention/backend.h, src/vllm/platforms/rocm.cpp, ...) ...

These are not new, and they are not direct-to-main pushes. Measured locally:

commit	author	date	FOLLOWING_AGENTS_PROTOCOL	trailers	parents
dd8a3b0e1	elderorb	2026-08-18	present	3	1
8daf58e77	mudler's LocalAI [bot]	2026-08-18	present	3	1
38ec0da4a	Thomas Brasser	2026-08-18	present	3	1

All three are five days old, carry the full protocol paragraph and all three trailers, and have a single parent — the shape of a squash merge, which is this repository's only landing mode for main.

Two of the three are external contributors. An external pull request's row/<ID> branch lives on the contributor's fork, never on origin, so a checker that verifies the change "arrived on a task branch" by looking at origin's refs cannot find it and never will. That is a hypothesis consistent with every column above, not a conclusion — someone should confirm it against scripts/check-doc-checkpoint.py before repairing anything.

Why it fires now rather than in August: the check is range-scoped and its base tracks the last green. main going red moves that base backwards, which pulls older commits into the checked range. So this red is partly self-sustaining — it will keep re-including history until something clears it.

3. commit-protocol-tag — cause NOT determined

It fails, and I did not establish why. Grepping its log returned the workflow's own echo lines (the script printing its error strings), not an emitted ::error::. Recorded as unknown rather than guessed at. It may share cause 2's commits, since a range that re-includes old history would reach the same three, but nothing here measures that.

Why this matters beyond the three jobs

A red main blocks every branch, and this repository has already paid for that pattern this week: three separate lanes converged on #1731 because a blocking red creates pressure to act before checking ownership, producing duplicate issues (#1733) and duplicate branches.

Note also that windows-msvc-cpu now prints Windows portability contract OK and then fails ~20 minutes later on exit code 1 — so #1701's fix for #1649 worked, the job now genuinely compiles, and whatever it hits now was previously masked by the checker refusal. That is progress, and it is a different failure needing its own issue if one does not exist.

Owed

• Diagnose the SiteGuard error.
• Confirm or refute the external-fork explanation for documentation-checkpoint, then decide: teach the checker about fork-origin branches, or argue a bounded exception. The three commits cannot retroactively be put on an origin branch.
• Determine commit-protocol-tag's actual cause.

[localai-bot]

Correction: item 1 is already owned, and this issue duplicated it. #1722 filed the SiteGuard error and PR #1726 fixes it, both before this was written.

Its diagnosis is more precise than mine and worth reading instead: subprocess.run raises FileNotFoundError rather than returning the non-zero code assertEqual(result.returncode, 0) was written to report, so the failure arrives before any assertion — which is why it presents as ERROR and not FAILURE. The case landed with #1714 and passed review on a developer box carrying Hugo on PATH, while the agent-record runner is a plain ubuntu-latest. The fix resolves shutil.which("hugo") and skips when it is None, with three mutations pinning the states apart — including changing a protected assertEqual(len(detail_hrefs), 10) to 11 to prove the guard is not a mute switch.

How I duplicated it: I searched open issues by keyword and swept open pull requests by title only. #1726 is titled fix(TEST-SITE-HUGO-SKIP-GUARD): skip, do not error, when the hugo binary is absent, which contains neither "siteguard" nor the test name — it was reachable by branch name, and I did not filter on that. The standing rule in this repository is that a red on main creates pressure to act, and that pressure is exactly what displaces the ownership check; it did so again here.

What remains genuinely unowned in this issue:

• item 2, documentation-checkpoint re-flagging three five-day-old external squash merges (dd8a3b0e1, 8daf58e77, 38ec0da4a) whose row/* branches live on contributor forks rather than on origin;
• item 3, commit-protocol-tag, whose cause I did not determine and did not guess at.

Retitling is not possible without losing the thread, so read this issue as covering 2 and 3 only. #1722 is the record for 1.

[localai-bot]

Correction: my external-fork explanation for item 2 is refuted, and the commit count was already stale.

I wrote that documentation-checkpoint flags those commits because an external pull request's row/<ID> branch lives on the contributor's fork and so cannot be found on origin. I labelled it a hypothesis rather than a conclusion, and it is now measured to be wrong.

scripts/check-role-discipline.py resolves no ref at all. For a single-parent commit, arrival is decided from the commit MESSAGE TEXT — ROW_BRANCH.search(subject+body) or PR_REFERENCE.search(subject). Fork versus origin never enters into it. The decisive counter-example: PR #1159's head was mudler/vllm.cpp:row/ENG-RELEASE-WINDOWS-test-thread-raii — on origin, not a fork — and it fails identically to the four fork-origin ones.

The real discriminator is the squash subject: all of them lack a (#N) reference, because the merger passed an explicit commit_title, which suppresses the reference GitHub otherwise appends even under squash_merge_commit_title = PR_TITLE. So the rule is satisfiable by an external contributor today, and no exception is needed — the gap is a landing-procedure one, not a permissions one.

The count of three was also already stale when I wrote it. The anchor query at base 21abaf169 returns fafa16f0f, from 2026-08-12 — a 484-commit range — over which the checker reports five commits, not three. That is the widening in #1773 doing exactly what it does: a range that grows accretes offenders, so any count taken from it is a reading of how long main has been red, not of how much is wrong.

PR #1776 addresses the mechanism (#1773). Items 1 and 3 of this issue — the SiteGuard error, owned by #1722/#1726, and the undetermined commit-protocol-tag cause — are untouched by it and this issue stays open for the latter.

[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.

[localai-bot]

Item 1, the SiteGuard error, is diagnosed and owned. It is not new and not this branch's: test_rendered_benchmark_index_links_resolve_to_emitted_pages shells out to hugo, and no job in ci.yml installed it, so subprocess.run raised FileNotFoundError before any assertion ran. Introduced by #1714 at 1db7e59cf; the scheduled baseline at deb53c6a3 was green on agent-record and 08c81a892 and every scheduled run after it is red.

Two open issues already carry it, and they split cleanly rather than duplicating:

• #1722 with PR #1726 — the guard, so a developer box without Hugo skips instead of erroring.
• #1754 with PR #1830 — the install, so the assertion actually runs on the lane. This is the half that restores coverage; a guard alone makes the job green having rendered nothing, which fix(TEST-SITE-HUGO-SKIP-GUARD): skip, do not error, when the hugo binary is absent (#1722) #1726's own SUCCESS agent-record demonstrates.

Items 2 and 3 of this issue — documentation-checkpoint re-flagging three five-day-old external squash merges, and commit-protocol-tag — are untouched by either and this issue is not closed by #1830.

One thing worth adding to item 1's record: the local-against-CI asymmetry is why it was misreadable from the job name. Every checker in agent-record returns rc 0 on a box that happens to carry Hugo on PATH, and the suite runs 7/7 OK there, while the same commit reds on a runner that lacks the binary.