Resolve the storage mode for V1 ("user maintains the flow") API tests on this app.
═══════════════════════════════════════════════════════════════════
**MUST BE YOUR FIRST MCP CALL** for ANY of these dev verbs/intents:
═══════════════════════════════════════════════════════════════════
* "run the sandbox tests" / "run the API tests" / "test sandbox" / "run keploy tests"
* "record the sandbox" / "rerecord" / "refresh the mocks" / "capture mocks"
* "replay the sandbox" / "replay the tests" / "show me the report" / "what failed in the last run"
* "generate keploy tests" / "add a keploy test for <endpoint>"
* "set up keploy in this repo" / "onboard this service to keploy"
* any other reference to keploy/api-tests/, sandbox tests, integration tests, mocks, suites
REASON: this is the gate that determines whether the app is on the V1 (repo-mode) code path
or the legacy cloud-mode code path. **The two paths use entirely different MCP tool surfaces**:
┌───────────────────────┬─────────────────────────────────────────────────────────┐
│ Storage mode │ Tools to use │
├───────────────────────┼─────────────────────────────────────────────────────────┤
│ "repo" │ devloop_* tools only. NO cloud-mode tools. │
│ │ (record_sandbox_test, replay_sandbox_test, │
│ │ replay_test_suite, create_test_suite, list_branches, │
│ │ get_app_testing_context, listTestSuites etc. will │
│ │ REFUSE with a redirect to the V1 surface.) │
├───────────────────────┼─────────────────────────────────────────────────────────┤
│ "cloud" or "" (unset) │ Cloud-mode tools (record_sandbox_test, │
│ │ replay_sandbox_test, replay_test_suite, │
│ │ create_test_suite, list_branches, get_app_testing_ │
│ │ context, listTestSuites, etc.). devloop_* tools may │
│ │ also be called for the V1 cloud-mode path. │
└───────────────────────┴─────────────────────────────────────────────────────────┘
DO NOT SKIP THIS. If you reach for cloud-mode tools first (replay_sandbox_test, list_branches,
listTestSuites, etc.) without calling devloop_resolve_storage, you WILL misroute repo-mode apps
and tell the dev to "upload local tests as suites and record into the cloud" — the EXACT
regression that prompted these MCP-side guardrails. The cloud-mode tools server-side gate on
devloop_storage_mode == "repo" and will refuse the call with a redirect message; devloop_resolve_
storage front-runs that refusal cleanly.
Resolution order:
1. If app.devloop_storage_mode is set → return {mode, source: "persisted"}; do NOT re-ask.
2. Else if the dev's repo (app_dir) already contains keploy/api-tests/ → ATEMPT to infer repo mode. This tool returns source="asked" with a hint asking you to check the dev's filesystem; if you confirm keploy/api-tests/ exists, call devloop_set_storage_mode({app_id, mode:"repo", reason:"inferred_local_tests_exist"}) and proceed silently.
3. Else → return {source: "asked"} with the trade-off text in `message`; surface that to the dev, get yes/no, persist via devloop_set_storage_mode.
The AI is responsible for inspecting the repo (this MCP server does not have filesystem access). Use your native filesystem tools (read/grep) to check whether keploy/api-tests/ exists under app_dir.
APP RESOLUTION — the dev should NEVER have to type an app_id. Pass EITHER:
* app_id (UUID) — exact, fast path. Use this once you've resolved it earlier in the conversation.
* app_name_hint — a case-insensitive substring of the app name (typically the cwd basename). The tool calls listApps(q=hint) and resolves to a unique match.
If neither is set, the tool errors with the candidate list so you can ask the dev. If app_name_hint matches multiple apps, the error names them and asks you to disambiguate. If no app matches, you propose creating one (call createApp) BEFORE re-running this tool.