feat(api): add a REST route + CLI mirror for loopover_suggest_boundary_tests#6872
Conversation
…y_tests loopover_suggest_boundary_tests had neither a REST route nor a CLI mirror, unlike its same-tier advisory-lint sibling loopover_check_slop_risk, which already has full parity (POST /v1/lint/slop-risk + a stdio tool). Both are deterministic, advisory-only, no-repo-access evaluators over caller-supplied metadata, so the asymmetry was arbitrary. Adds POST /v1/lint/boundary-tests beside /v1/lint/slop-risk, reproducing the MCP tool's handler exactly: keep only boundary touches whose path is in the changed set, build the finding, and build the spec only when the finding fired. It reuses buildBoundaryTestGenerationFinding/Spec as-is. Advisory only -- never blocks, never writes, and returns criteria/hints only, never generated test code, so the review/execution boundary stays intact. Adds the loopover_suggest_boundary_tests stdio tool. Unlike the check_slop_risk sibling this one PROXIES to the route rather than computing in-process: the builders live app-side (src/signals/boundary-test-generation.ts depends on the app's AdvisoryFinding type), not in @loopover/engine, so extracting them to compute locally would drag an app type into the engine. The route therefore stays the single source of truth for the filtering + finding/spec logic. Both new input schemas mirror the MCP tool's suggestBoundaryTestsShape VERBATIM -- same bounds, same .strict() objects, same optionality -- so no surface can accept an input another would reject (including an empty changedFiles, which the tool accepts). Route tests pin the handler's filtering (an out-of-diff touch is dropped), the finding/spec pairing, the no-gap cases (test evidence present, no touches), schema parity, and 400s. The CLI test asserts the proxied POST and that zod rejects bad input before any API call. 100% line and branch coverage on the new route lines. Closes JSONbored#6750
|
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 #6872 +/- ##
=======================================
Coverage 93.70% 93.70%
=======================================
Files 685 685
Lines 68247 68256 +9
Branches 18707 18709 +2
=======================================
+ Hits 63948 63957 +9
Misses 3302 3302
Partials 997 997
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 09:58:28 UTC
Review summary Nits — 4 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.
|
2 participants
What & why
loopover_suggest_boundary_testshad neither a REST route nor a CLI mirror — unlike its same-tier advisory-lint siblingloopover_check_slop_risk, which already has full parity (POST /v1/lint/slop-risk+ a stdio tool). Both are deterministic, advisory-only, no-repo-access evaluators over caller-supplied metadata, so the asymmetry was arbitrary.The route
POST /v1/lint/boundary-tests, beside/v1/lint/slop-risk, reproducing the MCP tool's handler exactly: keep only boundary touches whose path is in the changed set, build the finding, and build the spec only when the finding fired. ReusesbuildBoundaryTestGenerationFinding/Specas-is. Advisory-only — never blocks, never writes, and returns criteria/hints only, never generated test code, so the review/execution boundary stays intact (a test asserts no scaffolded test code crosses it).Why this CLI mirror proxies (unlike its sibling)
Worth flagging, since it deviates from the two mirrors I shipped before:
check_slop_riskcomputes in-process becausebuildSlopAssessmentis engine-side. Here the builders live app-side —src/signals/boundary-test-generation.tsdepends on the app'sAdvisoryFindingtype, and there's no engine copy. Computing locally would mean dragging an app type into@loopover/engine.So this tool proxies to the route, which stays the single source of truth for the filtering + finding/spec logic. The issue asks for "a CLI subcommand", not an in-process one — this satisfies it without an unrequested engine cascade.
Schema parity
Both new schemas mirror the tool's
suggestBoundaryTestsShapeverbatim — same bounds, same.strict()objects, same optionality, including accepting an emptychangedFilesexactly as the tool does. (Read fromserver.ts, not inferred — the lesson from #6807.)Tests
Route: the handler's filtering (an out-of-diff touch is dropped → no gap), the finding/spec pairing, the no-gap cases (test evidence present via
testFilesor free-texttests; no touches at all), schema parity, and 400s including a malformed body. CLI: the proxied POST, and that zod rejects bad input before any API call.100% line and branch coverage on the new route lines, measured against the changed-line set.
tsc --noEmitclean.Closes #6750