fix(review): gate_check_run's byte-identical no-op closes #6724's remaining gap

[JSONbored]

Summary

The self-monitoring "review burst" anomaly detector has repeatedly flagged the same PRs (JSONbored/loopover, /metagraphed, /awesome-claude) for publishing 6+ review surfaces within 2 hours with no real state change (Sentry ops_anomaly, LOOPOVER-21/22/23/1W). #6724 added byte-identical no-op detection for the comment and label outputs, but its own test file explicitly flagged gate_check_run as "a separate, not-yet-implemented scope" for any repo with the gate check enabled — the common case. This closes that gap.

Scope

• The PR title follows type(scope): short summary Conventional Commit format, for example fix(api): restore profile access checks.
• This PR is focused and does not mix unrelated backend, UI, MCP, docs, dependency, and deploy changes.
• This follows CONTRIBUTING.md and does not reintroduce GitHub Pages, VitePress, site/, or CNAME.
• I linked a currently open issue this PR resolves (e.g. Closes #123) — a linked open issue is required for every contributor PR.

Closes #7514

Validation

• git diff --check
• npm run typecheck
• npm run test:coverage locally — 2 new end-to-end tests in test/unit/queue.test.ts cover the no-op suppression (identical gate conclusion, same head SHA, across two full processJob passes) and the critical safety property (a genuinely new commit — different head SHA — is never suppressed, even with an identical AI verdict); the full queue.test.ts file (176 tests) passes
• New or changed behavior has unit/integration tests for new branches, fallback paths, and sanitizer boundaries

If any required check was skipped, explain why:

• Same pre-existing, local-environment-only failures noted in fix(orb): index orb_relay_pending.created_at to stop full table scans #7510/fix(selfhost): distinguish stale codex-reviewer env var, cool down its circuit breaker #7513 (Node version mismatch, 2 unrelated miner-CLI test files) — confirmed unrelated, not present in real CI.

Safety

• No secrets, wallet details, hotkeys, coldkeys, user PATs, private keys, raw trust scores, private rankings, or private maintainer evidence are exposed.
• Public GitHub text stays sanitized, low-noise, and does not imply compensation guarantees or optimization tactics.
• Auth, cookie, CORS, GitHub App, Cloudflare, or session changes include negative-path tests. (N/A.)
• API/OpenAPI/MCP behavior is updated and tested where needed. (N/A.)
• UI changes use live API data or real empty/error/loading states, not production mock/demo fallbacks. (N/A — no UI changes.)
• Visible UI changes include a UI Evidence section. (N/A — no visible UI change.)
• Public docs/changelogs are updated where needed; changelogs are only edited for release-prep PRs. (N/A.)

Notes

Design, matching #6724's own conservative philosophy ("this guard is only ever allowed to skip a PROVABLE no-op, never to guess one"):

• recordPublishedGateCheckSummary already upserts the gate-check summary keyed on [repoFullName, headSha, name] — so a prior row for the exact current head SHA only exists if this SAME commit was already gate-checked before. A genuinely new commit has no prior row and always falls through to "changed."
• The prior conclusion is read before this pass writes anything (priorGateCheckConclusion, near the top of maybePublishPrPublicSurface), and compared against whichever conclusion this pass actually recorded (finalGateCheckConclusion, captured at each of the 3 gate-check publish call sites) — not re-derived, avoiding any risk of the comparison drifting from what was really written.
• check_run (the separate advisory check, distinct from the gate one) has no equivalent persisted "prior state" today, so its presence is left unconditionally counted as a change, same as before — extending that is a larger, separate change (would need new persistent storage) and is out of scope here.
• One existing #6724 test ("a comment-unchanged pass that newly applies a previously-missing label...") turned out to rely on an unrelated type-label mechanism's own activity (confirmed via direct instrumentation: decision.willLabel was false throughout; every label POST in that test came from the separate resolvePrTypeLabel path, which runs unconditionally and was never part of surfaceContentChanged's tracked outputs, before or after this change). Renamed and corrected that test's expectations to reflect the more accurate behavior; the type-label mechanism's own actions still happen exactly as before, this only affects the internal "did the tracked review surface change" bookkeeping.

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 88.46%. Comparing base (6ead9f3) to head (e9d1cba).
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7517      +/-   ##
==========================================
- Coverage   88.48%   88.46%   -0.02%     
==========================================
  Files         720      720              
  Lines       75710    75718       +8     
  Branches    22537    22540       +3     
==========================================
- Hits        66989    66986       -3     
- Misses       7677     7684       +7     
- Partials     1044     1048       +4     

Flag	Coverage Δ
shard-1	32.93% <55.55%> (-0.11%)	⬇️
shard-2	36.85% <55.55%> (+<0.01%)	⬆️
shard-3	25.64% <0.00%> (-0.02%)	⬇️
shard-4	38.89% <33.33%> (-0.01%)	⬇️
shard-5	34.21% <66.66%> (+<0.01%)	⬆️
shard-6	36.23% <66.66%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
src/queue/processors.ts	95.61% <100.00%> (+0.01%)	⬆️

... and 2 files with indirect coverage changes

[loopover-orb]

Tip

✅ LoopOver review result - approve/merge recommended

_{Review updated: 2026-07-20 20:08:58 UTC}

2 files · 1 AI reviewer · no blockers · readiness 100/100 · CI green · clean

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This PR extends the #6724 byte-identical no-op detection to gate_check_run by capturing the prior completed gate-check conclusion for the current head SHA before this pass writes anything, then comparing it against the conclusion this pass actually records at whichever of the three gate-check publish sites fires. The design is conservative by construction: an undefined prior conclusion (new commit, no prior row, or a lookup error) always falls through to 'changed', so the no-op suppression can only ever activate when there's a proven identical conclusion for the exact same head SHA. Test coverage is strong — it includes both the no-op suppression case and, critically, the safety property that a genuinely new head SHA with an identical AI verdict is never suppressed.

Nits — 5 non-blocking

• src/queue/processors.ts: the new `listCheckSummaries(...).catch(() => undefined)` silently swallows any lookup error and treats it as 'no prior row' (safe, since that forces `changed`), but it would be worth a one-line comment noting the catch is intentional fail-open rather than an oversight.
• src/queue/processors.ts: `priorGateCheckConclusion` is now fetched via a DB round trip on every gate-enabled pass even when the pass ultimately doesn't publish gate_check_run at all — minor, but worth confirming `listCheckSummaries` is cheap/indexed on (repoFullName, headSha, name).
• test/unit/queue.test.ts: `let headSha = "b75a";` in the new head-SHA-change test is a slightly unusual literal (looks like a typo for a hex-ish sha) — doesn't affect correctness but a cleaner fixture value would read better.
• Consider asserting `priorGateCheckConclusion` explicitly in a test where a completed row exists but with `conclusion: null` (as opposed to a string), to lock in that null-vs-null is correctly treated as unchanged and null-vs-undefined as changed.
• The `finalGateCheckConclusion` variable is set at three separate call sites with duplicated `finalGateCheckConclusion = "neutral"` assignments for the two fallback paths — a small shared helper or constant could reduce the chance of the two fallback sites drifting apart if only one is edited later.

Decision drivers

• ✅ Code review — No blockers (1 reviewer)
• ✅ Gate result — Passing (No configured blocker found.)

Context & advisory signals — never blocks the verdict

Signal	Result	Evidence
Linked issue	✅ Linked	#7514
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	✅ 20/20	Low review scope from cached public metadata (1 linked issue).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 28 registered-repo PR(s), 21 merged, 369 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	JSONbored; Gittensor profile; 28 PR(s), 369 issue(s).
Improvement	✅ Minor	risk: clean · value: minor · LLM: moderate

Linked issue satisfaction

Addressed
The diff implements exactly what the issue asks: it captures the prior completed gate-check conclusion for the same head SHA before the pass runs, tracks the newly published conclusion, and folds a gateCheckRunContentChanged comparison into surfaceContentChanged so a byte-identical gate re-publish on an unchanged head no longer counts as a fresh surface change, while any new commit or differing co

Review context

• Author: JSONbored
• Role context: owner (maintainer lane)
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: Python, TypeScript, Ruby, Go, JavaScript, MDX, Shell, Solidity
• Official Gittensor activity: 28 PR(s), 369 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Start here: Treat this as maintainer-lane context rather than normal contributor-lane activity.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

🧪 Chat with LoopOver

Ask LoopOver a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

• @loopover ask <question> answers contribution-quality Q&A with source citations and freshness.
• @loopover chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
• A plain-language @loopover mention with a real question is routed to the closest matching read-only command automatically — no exact syntax required.

Full command reference: https://loopover.ai/docs/loopover-commands

🧪 Experimental — new and may change.

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by LoopOver, a quiet PR intelligence layer for OSS maintainers.

• Re-run LoopOver review

[loopover-orb]

LoopOver approves — the gate is satisfied and CI is green.