Context
Concrete instance of #6227's shared-core question. loopover_check_slop_risk's canonical logic already lives in packages/loopover-engine/src/signals/slop.ts — src/mcp/server.ts:3396-3405 (remote) already calls it via buildSlopAssessment, and src/signals/slop.ts is itself a pure re-export shim over the engine copy. But packages/loopover-mcp/bin/loopover-mcp.js:803-810 (local) doesn't consume it directly — it proxies the request over HTTP (apiPost("/v1/lint/slop-risk", input)) even though packages/loopover-mcp already depends on @loopover/engine@^1.0.0. The only blocker is that @loopover/engine's package.json exports map exposes ., ./scoring/model, ./scoring/preview, ./scoring/pending-pr-scenarios, ./signals/test-evidence, ./signals/check-summary, ./signals/path-matchers — but not ./signals/slop.
Requirements
- Add a
./signals/slop entry to packages/loopover-engine/package.json's exports map, pointing at the same module src/signals/slop.ts re-exports.
- Update
packages/loopover-mcp/bin/loopover-mcp.js's loopover_check_slop_risk tool handler to call buildSlopAssessment directly from @loopover/engine instead of apiPost, for a fully offline-capable local invocation.
- Keep the remote server's behavior unchanged — it already calls the engine function directly.
- Do not change
@loopover/engine's actual slop-assessment logic.
Test Coverage Requirements
99%+ Codecov patch coverage on the changed handler; a regression test confirming the local tool now works without any network call (mock/stub the HTTP layer to prove it's unused for this path).
Deliverables
Expected Outcome
A user running the local MCP server can get a slop-risk assessment fully offline, matching the remote server's existing in-process behavior — and this repo's @loopover/engine convergence pattern is extended to one more tool.
Links & Resources
Context
Concrete instance of #6227's shared-core question.
loopover_check_slop_risk's canonical logic already lives inpackages/loopover-engine/src/signals/slop.ts—src/mcp/server.ts:3396-3405(remote) already calls it viabuildSlopAssessment, andsrc/signals/slop.tsis itself a pure re-export shim over the engine copy. Butpackages/loopover-mcp/bin/loopover-mcp.js:803-810(local) doesn't consume it directly — it proxies the request over HTTP (apiPost("/v1/lint/slop-risk", input)) even thoughpackages/loopover-mcpalready depends on@loopover/engine@^1.0.0. The only blocker is that@loopover/engine'spackage.jsonexportsmap exposes.,./scoring/model,./scoring/preview,./scoring/pending-pr-scenarios,./signals/test-evidence,./signals/check-summary,./signals/path-matchers— but not./signals/slop.Requirements
./signals/slopentry topackages/loopover-engine/package.json'sexportsmap, pointing at the same modulesrc/signals/slop.tsre-exports.packages/loopover-mcp/bin/loopover-mcp.js'sloopover_check_slop_risktool handler to callbuildSlopAssessmentdirectly from@loopover/engineinstead ofapiPost, for a fully offline-capable local invocation.@loopover/engine's actual slop-assessment logic.Test Coverage Requirements
99%+ Codecov patch coverage on the changed handler; a regression test confirming the local tool now works without any network call (mock/stub the HTTP layer to prove it's unused for this path).
Deliverables
@loopover/engineexports./signals/slop.loopover_check_slop_riskcomputes the result in-process, no HTTP round trip.Expected Outcome
A user running the local MCP server can get a slop-risk assessment fully offline, matching the remote server's existing in-process behavior — and this repo's
@loopover/engineconvergence pattern is extended to one more tool.Links & Resources
packages/loopover-mcp/bin/loopover-mcp.js:803-810,src/mcp/server.ts:3396-3405packages/loopover-engine/src/signals/slop.ts,src/signals/slop.ts(already a re-export shim),packages/loopover-engine/package.json(exports map to extend)