Strategic Finding
Type: adoption-blocker
Horizon: near-term (blocking)
PR #18329 "add guardrails to prevent scanner merge loop" was merged at 10:59 UTC on 2026-06-13 and claimed to fix the build-break loop (issue #18218, now auto-closed).
It did not. Within 3 hours of the fix landing, 4 PRs merged in a 2.5-minute window (13:48:01, 13:48:10, 13:48:16, 13:50:34 UTC), all from app/kubestellar-hive, triggering 4 simultaneous open build breaks (#18343, #18344, #18345, #18346).
Root Cause
The guardrails PR wrote policy configuration files:
.github/policies/merge-policy.yaml — declares "max 3 merges/hour"
.github/scanner-config.yml — declares rate limits
.github/workflows/scanner-merge-guardrails.yml — a workflow that runs checks
These files describe policy but do not enforce it. The GitHub merge button is not blocked by them. Only GitHub repository settings can enforce merge gates:
- Settings → Branches → Branch protection rules for
main
- Enable: "Require status checks to pass before merging"
- Add specific checks:
build, lint, go-test
- Enable: "Require branches to be up to date before merging"
Until a human repository admin (e.g., @clubanderson) makes these changes in GitHub settings, any bot or human can merge to main regardless of CI status.
Rationale
Build breaks directly block community contributors: a new contributor opening a PR against a broken main cannot know if their changes caused the break or if it was pre-existing. PR #18264 (@bmvinay7, first external contribution) is currently open against a main branch with 4 active build breaks.
For CNCF incubation review, a main branch that is frequently broken is a negative signal about project health and governance maturity.
Proposed Next Step
@clubanderson: Enable required status checks on main via GitHub repository settings:
Filed by strategist agent (ACMM L6 — full mode)
Strategic Finding
Type: adoption-blocker
Horizon: near-term (blocking)
PR #18329 "add guardrails to prevent scanner merge loop" was merged at 10:59 UTC on 2026-06-13 and claimed to fix the build-break loop (issue #18218, now auto-closed).
It did not. Within 3 hours of the fix landing, 4 PRs merged in a 2.5-minute window (13:48:01, 13:48:10, 13:48:16, 13:50:34 UTC), all from
app/kubestellar-hive, triggering 4 simultaneous open build breaks (#18343, #18344, #18345, #18346).Root Cause
The guardrails PR wrote policy configuration files:
.github/policies/merge-policy.yaml— declares "max 3 merges/hour".github/scanner-config.yml— declares rate limits.github/workflows/scanner-merge-guardrails.yml— a workflow that runs checksThese files describe policy but do not enforce it. The GitHub merge button is not blocked by them. Only GitHub repository settings can enforce merge gates:
mainbuild,lint,go-testUntil a human repository admin (e.g.,
@clubanderson) makes these changes in GitHub settings, any bot or human can merge tomainregardless of CI status.Rationale
Build breaks directly block community contributors: a new contributor opening a PR against a broken
maincannot know if their changes caused the break or if it was pre-existing. PR #18264 (@bmvinay7, first external contribution) is currently open against a main branch with 4 active build breaks.For CNCF incubation review, a main branch that is frequently broken is a negative signal about project health and governance maturity.
Proposed Next Step
@clubanderson: Enable required status checks on
mainvia GitHub repository settings:mainwith required status checks:build / build,lint / lint,test / go-testFiled by strategist agent (ACMM L6 — full mode)