feat(api): add a REST route + CLI mirror for loopover_evaluate_escalation#6805
Conversation
…tion loopover_evaluate_escalation had neither a REST route nor a CLI mirror, unlike its same-tier sibling loopover_check_slop_risk, which already has full parity (POST /v1/lint/slop-risk + an in-process stdio tool). Both are pure, source-free evaluators over caller-supplied data gated only by a tool rate limit, so the asymmetry was arbitrary. Adds POST /v1/loop/evaluate-escalation directly beside /v1/lint/slop-risk and structured identically: parse with a schema mirroring the MCP tool's own evaluateEscalationShape, then delegate to the pure evaluateEscalation. The route adds no logic -- it decides; the caller wires the action. Adds the loopover_evaluate_escalation stdio tool, computed IN-PROCESS from @loopover/engine exactly like the check_slop_risk sibling rather than proxying over HTTP, so escalation checks work fully offline with no API round-trip. Descriptor added under the "agent" category, matching the server's own MCP_TOOL_CATEGORIES. Tests assert cross-surface PARITY per the issue's requirement: for every precedence arm (killRequested > error/critical > abandoned/customerFlagged > degraded > none) both the route and the stdio tool return exactly what the pure evaluator returns for identical input. The CLI test runs against a black-holed API URL, proving the tool never round-trips. Plus zod/400 rejection on both surfaces. 100% line and branch coverage on the new route lines. Closes JSONbored#6754
|
Superagent didn't find any vulnerabilities or security issues in this PR. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #6805 +/- ##
=======================================
Coverage 93.63% 93.63%
=======================================
Files 683 683
Lines 68148 68154 +6
Branches 18703 18704 +1
=======================================
+ Hits 63812 63818 +6
Misses 3350 3350
Partials 986 986
Flags with carried forward coverage won't be shown. Click here to find out more.
|
loopover-orb
Bot
added
the
gittensor:feature
|
Tip ✅ LoopOver review result - approve/merge recommendedReview updated: 2026-07-17 07:31:28 UTC
Review summary Nits — 5 non-blocking
Decision drivers
Context & advisory signals — never blocks the verdict
Linked issue satisfactionAddressed Review context
Contributor next steps
Signal definitions
🧪 Chat with LoopOverAsk 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.
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.
|
![loopover-orb[bot]](https://avatars.githubusercontent.com/in/4139483?s=60&v=4){kind=small}
1 participant
What & why
loopover_evaluate_escalationhad neither a REST route nor a CLI mirror — unlike its same-tier siblingloopover_check_slop_risk, which already has full parity (POST /v1/lint/slop-risk+ an in-process stdio tool). Both are pure, source-free evaluators over caller-supplied data gated only by a tool rate limit, so the asymmetry was arbitrary.Changes
POST /v1/loop/evaluate-escalation— placed directly beside/v1/lint/slop-riskand structured identically: parse with a schema mirroring the MCP tool's ownevaluateEscalationShape, then delegate to the pureevaluateEscalation. The route adds no logic of its own — it decides; the caller wires the action.loopover_evaluate_escalationstdio tool — computed in-process from@loopover/engine, exactly like thecheck_slop_risksibling, rather than proxying over HTTP. Escalation checks therefore work fully offline with no API round-trip. Descriptor under"agent", matching the server's ownMCP_TOOL_CATEGORIES.Tests — cross-surface parity
The issue asks for "a test asserting output parity between the mirrored surfaces for identical input", so that's the backbone of both suites: for every precedence arm (
killRequested>error/critical>abandoned/customerFlagged>degraded> none), the route and the stdio tool each return exactly what the pure evaluator returns. Parity holds by construction — all three surfaces call the same function — and these tests pin it against regression.The CLI test runs against a black-holed API URL (
http://127.0.0.1:1), which proves the in-process claim: a residual round-trip would fail every case. Plus zod/400 rejection on both surfaces.100% line and branch coverage on the new route lines, measured against the changed-line set. No OpenAPI entry — consistent with its
/v1/lint/slop-risksibling, which has none.Closes #6754