fix(queue): re-check loop-escalation via .loopover.yml override (#8018)

[andriypolanski]

Summary

• loop-escalation-sweep was the only flag-gated cron in processJob that checked the env var alone, so a .loopover.yml disable could not stop an already-enqueued sweep.
• Added top-level loopEscalation: (same shape as ops:), resolveLoopEscalationManifestOverride, and wired it into isLoopEscalationSweepEnabled, job-dispatch, and the hourly enqueue path.

Closes #8018

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.

Validation

• git diff --check
• npm run actionlint
• npm run typecheck
• Scoped: vitest -t "loopEscalation|loop-escalation|#8018" across wire/queue/index/manifest/lint suites — 25 passed; config-templates yml sync checks passed.
• npm run test:workers
• npm run build:mcp
• npm run build:miner
• npm run test:mcp-pack
• npm run ui:openapi:check
• npm run ui:lint
• npm run ui:typecheck
• npm run ui:build
• npm audit --audit-level=moderate
• New or changed behavior has unit/integration tests for new branches, fallback paths, and sanitizer boundaries

If any required check was skipped, explain why:

• Focused on the loop-escalation manifest-override path and its focus-manifest plumbing. Full test:ci not re-run here. loop-escalation-wire.ts remains v8 ignore file (pre-existing); dispatch/cron coverage is via queue-5 + index tests.

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.
• API/OpenAPI/MCP behavior is updated and tested where needed.
• UI changes use live API data or real empty/error/loading states, not production mock/demo fallbacks.
• Visible UI changes include a UI Evidence section below with JPG/JPEG or PNG screenshots arranged as organized, captioned, clickable thumbnails. SVG screenshots are not used as review evidence. Review-only screenshots or recordings are not committed to the repository.
• Public docs/changelogs are updated where needed; changelogs are only edited for release-prep PRs.

UI Evidence

N/A — cron flag / config-as-code wiring; no UI.

Notes

• Required pattern: resolveOpsManifestOverride / isOpsEnabled / ops-alerts dispatch case.
• New .loopover.yml key: loopEscalation.enabled (documented in .loopover.yml.example + loopover.full.yml).

[superagent-security]

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

[loopover-orb]

Warning

⏸️ LoopOver review result - manual review recommended

_{Review updated: 2026-07-22 17:24:12 UTC}

17 files · 1 AI reviewer · no blockers · CI green · dirty

⏸️ Suggested Action - Manual Review

Review summary
This PR adds a `.loopover.yml`-based `loopEscalation:` config-as-code override for the LOOPOVER_LOOP_ESCALATION flag, mirroring the existing ops/prReconciliation/activeReviewReconciliation pattern exactly (same TTL cache shape, same present/enabled precedence, same fail-safe degrade-to-absent on manifest load error). It is wired at every required site: focus-manifest schema+parser+empty-defaults, config-lint recognized fields, both cron enqueue (src/index.ts) and queue dispatch (job-dispatch.ts) call sites, plus example yml docs and exhaustive tests for both directions of override (forcing on despite env off, forcing off despite env on) and TTL expiry. This closes the gap noted in #8018 where loop-escalation-sweep was the only flag-gated cron checking only the env var.

Nits — 3 non-blocking

• The `console.warn` in `resolveLoopEscalationManifestOverride` (src/review/loop-escalation-wire.ts:74) is intentional structured logging consistent with the mirrored ops-wire.ts pattern, not a debug leftover, but worth confirming log-volume expectations at 60s TTL under sustained failures.
• Issue numbers like loop-escalation-sweep is the only flag-gated cron job in job-dispatch's switch without a config-as-code manifest-override re-check #8018 embedded in comments (focus-manifest.ts:513, 2405; loop-escalation-wire.ts:59) are documentation references, not magic numbers needing extraction — no action needed here.
• None beyond what's already covered — the PR is a faithful structural mirror of resolvePrReconciliationManifestOverride/resolveOpsManifestOverride with full call-site and test parity.

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	#8018
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: 208 registered-repo PR(s), 130 merged, 22 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	andriypolanski; Gittensor profile; 208 PR(s), 22 issue(s).
Improvement	✅ Minor	risk: clean · value: minor

Linked issue satisfaction

Addressed
The diff adds resolveLoopEscalationManifestOverride to loop-escalation-wire.ts mirroring the sibling pattern (with focus-manifest schema, caching, and fail-safe error handling), and wires it into both isLoopEscalationSweepEnabled and the loop-escalation-sweep case in job-dispatch.ts's processJob exactly like the six siblings, plus the scheduled enqueue path.

Review context

• Author: andriypolanski
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: Python, TypeScript, JavaScript, Rust, Cuda, Kotlin, MDX, Scala
• Official Gittensor activity: 208 PR(s), 22 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Start here: Triage stale or unlinked PRs.

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.

[loopover-orb]

LoopOver is closing this pull request on the maintainer's behalf (conflicts with the base branch — resolve and open a fresh PR). This is an automated maintenance action — to pursue this change, please open a new pull request with the issues resolved. Closed PRs may be analyzed later to improve review accuracy, but they are not automatically reopened or re-reviewed.