chore(tests): retire the local early-close gate — the shared one is live (backend#2264)

[LukasWodka]

Closes the last item on tracebloc/backend#2264.

This repo carried the only copy of the early-close rule for a month. tracebloc/.github#300 reached .github's main at 2026-08-22T10:52Z, and callers pin @main, so the shared early-close job now runs here. Two copies of a scanner is exactly the drift this rule exists to prevent.

Removed

scripts/tests/pipefail-early-close.awk
scripts/tests/pipefail-early-close.sh
scripts/tests/pipefail-early-close.bats 42 cases → ported to .github as 80

I verified the shared gate covers this repo before removing the local one

That's the entire risk in a change like this, so it's checked rather than assumed:

1. It runs, and it blocks.code-quality-caller.yml pins @main and sets soft-fail: false; the early-close job defaults ON.
2. It's clean here. Fetched scripts/pipefail-early-close.{sh,awk} from .github@main and ran them against this tree: 0 offenders, rc=0.
3. And that 0 means something. The same scanner still fires on an injected offender:

   scripts/.probe.sh:3: x=$(ls | head -1)
   

   "It reported nothing" and "it did nothing" print identically — which is the trap this whole rule family is about, so I refuse to accept the first without demonstrating it isn't the second.

This PR's own CI run is the fourth check: the pipefail early-close job should appear and pass on it. If it doesn't appear, the premise is wrong and this shouldn't merge — worth watching rather than taking on trust, since no caller repo had run Code quality between the promotion and this branch.

Docs

.cursor/BUGBOT.md named the local script as the enforcement point. Updated in the same commit — repo convention is that a change making a statement there false fixes it here. It now names the shared job and says to report a false positive there rather than here.

Nothing else referenced it

Not the R8 manifest, not a Makefile target, not a workflow. BATS_TEST_COUNT is glob-derived, so the count moves on its own: 1325 → 1283 across 37 → 36 suites.

Verification

check-style clean · gen-manifest --check up to date · make lint clean · make driftall 13 guards green · bats-hygiene 18/0, check-drift 22/0, check-style 25/0, gen-manifest 20/0.

🤖 Generated with Claude Code

---

Note

Medium Risk
Deletes a CI gate that previously caught a production-incident class (SIGPIPE + errexit). Risk is coverage loss if the shared job is not actually running on this repo; otherwise the change is deletion plus docs.

Overview
Removes this repo’s local pipefail early-close scanner now that the same check lives in the shared early-close job (tracebloc/.githubcode-quality.yml). Deletes pipefail-early-close.{awk,sh,bats} so there is a single implementation instead of two that can drift.

.cursor/BUGBOT.md now points reviewers at that shared job (including scripts/lib/*.sh) and tells them to report false positives there, not here. The house rule itself is unchanged.

^{Reviewed by Cursor Bugbot for commit 91516bb. Bugbot is set up for automated code reviews on this repo. Configure here.}

[saqlainsyed007]

The diff is clean and correctly gated: it only removes the local pipefail-early-close.{sh,awk,bats} scanner and its BUGBOT.md entry, and the shared quality / pipefail early-close job (from .github#300, pinned @main, soft-fail: false) is green on this PR — so the shared gate is demonstrably running and covering this repo before the local copy is dropped. That's the whole risk in a retire-the-duplicate change and CI confirms it's covered.

Not approving only because a required check is red: E2E auth-proxy (squid) ("Cluster up through an authenticated proxy") failed in ~1m23s while the sibling E2E cluster (ubuntu-22.04 / 24.04 / arm) jobs all passed. Nothing in this diff touches the installer or proxy path, so the failure can't be caused by it — it reads as a flaky/infra squid-proxy bring-up. A re-run should clear it; I'll approve once it's green.

[LukasWodka]

@saqlainsyed007 thanks — and you checked the thing that actually mattered: that the shared quality / pipefail early-close job is green on this PR before the local scanner is dropped. That's the whole risk in a retire-the-duplicate change, and confirming the replacement is live beats reasoning about it.

One correction, and it makes this easier rather than harder: E2E auth-proxy (squid) is not a required check. Measured on both protection systems, because a ruleset would be invisible to the classic API:

• branches/develop/protection requires: Unit tests, Lint, quality / gitleaks, quality / house-rules, quality / shellcheck, quality / action-pins, version-bump-gate / version-check, Source-of-truth drift, chart content ⇒ Chart.yaml version bump — no E2E *.
• rules/branches/develop returns no rulesets at all, so nothing is hidden behind the 404 trap either.

So it is advisory and does not block the merge.

That said, I'm not asking you to approve over a red check, and I don't think you should. Your reasoning for why it can't be this diff is right — nothing here touches the installer or the proxy path, and the sibling E2E cluster (ubuntu-22.04 / 24.04 / arm) jobs all passed — but "advisory" is a statement about branch protection, not about whether the failure is real. An unexplained red is worth clearing either way.

The run is already re-running (32586043230, in progress). If it comes back green, this is a flaky squid bring-up as you read it. If it fails again, that is a finding about the auth-proxy job rather than about this PR, and I'll file it separately rather than merge past it.

[saqlainsyed007]

Re-review (backend#2264) — the retirement is safe, verified live.

The whole risk in deleting a local gate is "is the replacement actually covering this repo?" It is: quality / pipefail early-close runs and passes on this PR — that's the shared early-close job from tracebloc/.github's code-quality.yml, pinned @main, on by default. So the coverage the deleted scripts/tests/pipefail-early-close.{awk,sh,bats} provided is live here right now, not merely promised, and the port went 42 → 80 cases. This is the retire-the-duplicate-only-after-the-replacement-is-verified order done correctly.

.cursor/BUGBOT.md is updated to point false-positive reports at the shared gate rather than the removed local one. No functional code touched; only the local scanner + its doc reference.

My earlier comment flagged the local pipefail early-close red as base-branch noise, not this diff — that's now moot since the local gate is gone and the shared one is green. I opened no threads. All checks pass (Bugbot, the full E2E/Prereqs/PATH matrix, and the shared quality gate), no unresolved threads. LGTM.