feat(review): same-rule repeat alarm — detection + alert, no autonomous action

[JSONbored]

Closes #7983.

Summary

• The existing self-correction system only detects a systematically-wrong rule via precision-over-time (auto-tune.ts), which needs a real, DECIDED sample (>= AUTOTUNE_MIN_DECIDED) accumulated over however long that takes — too slow for a bug that can mis-close 4 PRs within hours, as the 2026-07-21/22 metagraphed incident did. A much cheaper, ground-truth-free signal already exists: the SAME deterministic rule/blocker code rejecting several DIFFERENT PRs in a short window in the same repo is itself a strong "something's broken" signal, independent of whether any of those rejections is ever confirmed or reversed by a human.
• New packages/loopover-engine/src/calibration/signal-tracking.ts: evaluateRuleRepeatAlarm(ruleId, fired, threshold) — pure, no ground truth needed, mirrors src/orb/analytics.ts's gamingPatternFlags precedent ("Detection only — never an automatic action").
• New src/review/rule-repeat-alarm-wire.ts wires this into ORB for real: every gate block now records a Extract a shared, deployment-agnostic calibration/signal-tracking module for ORB + AMS #7982 rule-fired signal per blocker code (nothing called the ORB adapter until now — Extract a shared, deployment-agnostic calibration/signal-tracking module for ORB + AMS #7982 only wired AMS), scoped per-(repo, code) so an unrelated repo or code never contributes to another's count, and checks the repeat alarm inline, immediately after each block — not on a later cron tick, matching the "hours, not days" urgency the incident exposed. A triggered alarm logs a structured console.error (forwarded to Sentry, the same "detected an anomaly" channel src/review/ops-wire.ts's own runOpsAlerts already uses) and writes a cooldown marker so an ongoing incident doesn't re-alert on every subsequent PR.
• Note on the issue's own cited alert channel: notify-discord.ts/notify-slack turned out to be the wrong fit on inspection — that's a per-REPO, community-facing channel for PR action notifications, not an operator-facing "an ORB rule may be systematically broken" signal that can span any repo the instance reviews. Sentry (via the existing structured-log forwarder, forwardStructuredLogToSentry) is the channel actually already used for this class of alert; alerts.ts's runAnomalyAlerts (the other candidate) turned out to be dead code referencing a notification_deliveries schema shape that no longer matches the live table.
• Validated against a replay of the exact fix(review): paginate preview-url.ts's PR-comment and check-run GitHub reads #7469/Epic: dual-path repo provisioning — BYOR + APR #7589/Design spec: idea-completion determination + customer-facing status for APR (no GitHub UI exposure) #7591/fix(ui): give four app-panel form controls a programmatic accessible name #7594 incident shape: triggers on the 3rd distinct PR, matching the issue's own "should have alerted after the 2nd or 3rd occurrence" bar.

Test plan

• npm run typecheck, packages/loopover-engine's own npm test (613/613, including 7 new evaluateRuleRepeatAlarm cases)
• New test/unit/rule-repeat-alarm-wire.test.ts (12 cases, 100% line/branch/function coverage): incident replay, per-repo scoping, per-code scoping, alert cooldown, duplicate-code dedup within one call, multiple independent codes, store-failure resilience, alert-marker write failure resilience
• Full unsharded npm run test:coverage: 1092/1092 files, 20387 tests, 0 failures
• npm run engine-parity:drift-check: clean, no version bump needed

[superagent-security]

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

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	loopover-ui	1aa5b63	Commit Preview URL Branch Preview URL	Jul 22 2026, 09:40 PM

[codecov]

Codecov Report

❌ Patch coverage is 74.19355% with 8 lines in your changes missing coverage. Please review.
✅ Project coverage is 91.98%. Comparing base (ed9e296) to head (1aa5b63).
⚠️ Report is 1 commits behind head on main.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
...loopover-engine/src/calibration/signal-tracking.ts	0.00%	7 Missing ⚠️
src/queue/processors.ts	50.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #8092      +/-   ##
==========================================
- Coverage   91.99%   91.98%   -0.02%     
==========================================
  Files         752      753       +1     
  Lines       76979    77010      +31     
  Branches    23315    23321       +6     
==========================================
+ Hits        70820    70839      +19     
- Misses       5053     5061       +8     
- Partials     1106     1110       +4     

Flag	Coverage Δ
shard-1	55.09% <45.16%> (+0.17%)	⬆️
shard-2	51.14% <74.19%> (-3.00%)	⬇️
shard-3	56.20% <45.16%> (+2.18%)	⬆️

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

Files with missing lines	Coverage Δ
src/review/rule-repeat-alarm-wire.ts	100.00% <100.00%> (ø)
src/queue/processors.ts	95.76% <50.00%> (-0.03%)	⬇️
...loopover-engine/src/calibration/signal-tracking.ts	0.00% <0.00%> (ø)

... and 1 file with indirect coverage changes

[loopover-orb]

Caution

🛑 LoopOver review result - fixes required

_{Review updated: 2026-07-22 21:53:52 UTC}

5 files · 1 AI reviewer · no blockers · CI failing · unstable

🛑 Suggested Action - Manual Review

Review summary
This PR adds a pure, no-ground-truth 'same-rule repeat alarm' primitive (evaluateRuleRepeatAlarm) plus an ORB wiring module that records a rule-fired signal on every gate block and alerts via console.error/Sentry once a (repo, blockerCode) pair crosses a distinct-target threshold within a 24h window, with a 6h alert cooldown. The core logic is correct and well-tested: the distinct-target counting, per-repo/per-code scoping, dedup of repeated codes in one call, and cooldown suppression all have direct unit coverage that exercises the real code path, including the incident replay shape from the description. The wiring call site in processors.ts is scoped to the existing blockerCodes recording block and is fire-and-forget (`.catch(() => undefined)`), so it cannot affect the gate decision itself.

Nits — 5 non-blocking

• The codecov/patch failure (74.19% vs 99%) is a real coverage gap in the diff, notably around the `Env` import path and D1 store failure branch in rule-repeat-alarm-wire.ts — worth checking which lines are uncovered before merge, though this may partly stem from files already excluded/covered elsewhere.
• console.error is used directly for the Sentry-forwarded alert (rule-repeat-alarm-wire.ts:69) — confirm this matches the exact JSON shape `forwardStructuredLogToSentry` expects, since a shape mismatch would silently drop the alert.
• The magic numbers flagged in the external brief (date literals in a test-comment context, and `60*60*1000` conversions) are non-issues — the date is a comment/test fixture value and the ms-conversion is a standard, self-explanatory idiom.
• `repeatAlarmRuleId` folds repo+code into a single colon-joined string key; if a repo full name itself contains a colon (unlikely on GitHub but worth a comment) this could theoretically collide with a code containing one too — low risk but worth a one-line note.
• Add a test asserting the exact Sentry-forwarded log shape (or point to where forwardStructuredLogToSentry is itself tested) so the alert channel wiring is verified end-to-end, not just that console.error was called.

CI checks failing

• codecov/patch — 74.19% of diff hit (target 99.00%)

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	#7983
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: 14 registered-repo PR(s), 14 merged, 242 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	JSONbored; Gittensor profile; 14 PR(s), 242 issue(s).
Improvement	✅ Minor	risk: clean · value: minor · LLM: moderate

Linked issue satisfaction

Addressed
The PR implements the exact counter/threshold primitive requested (evaluateRuleRepeatAlarm keyed by rule+repo, distinct-target counting, configurable threshold/window), wires it into ORB's gate-blocker path with tests replaying the cited #7469/#7589/#7591/#7594 incident (alerting on the 3rd occurrence as required), and follows the detection-only boundary with no autonomous action.

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: 14 PR(s), 242 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