@skyramp/mcp 0.2.150-rc.ldw- → 0.2.150-rc.ldw

package/build/commands/commandLibrary.js

@@ -1,4 +1,4 @@
-import { isLocalDevEnabled } from "../utils/featureFlags.js";
+import { isLocalDevEnabled, isOneClickEnabled } from "../utils/featureFlags.js";
 import { TEST_GIVEN_ENDPOINT_COMPREHENSIVELY_COMMAND } from "./testThisEndpointCommand.js";
 import { FULLREPO_RECOMMEND_GENERATE_EXECUTE_TOPN_TESTS_COMMAND } from "./recommendTestsAndExecuteCommand.js";
 import { LOCAL_DEV_TEST_CHANGES_COMMAND } from "./localDevTestChangesCommand.js";
@@ -9,7 +9,10 @@ const BASE_COMMAND_LIBRARY = {
 };
 /** All enabled predefined one-click commands */
 function getCommandLibrary() {
-    const commands = { ...BASE_COMMAND_LIBRARY };
+    const commands = {};
+    if (isOneClickEnabled()) {
+        Object.assign(commands, BASE_COMMAND_LIBRARY);
+    }
     if (isLocalDevEnabled()) {
         commands.local_dev_test_changes = LOCAL_DEV_TEST_CHANGES_COMMAND;
     }

package/build/commands/commandLibrary.test.d.ts

@@ -0,0 +1 @@
+export {};

package/build/commands/commandLibrary.test.js

@@ -0,0 +1,59 @@
+import { afterEach, describe, expect, it } from "@jest/globals";
+import { getCommandIds, lookupCommand } from "./commandLibrary.js";
+const originalOneClick = process.env.SKYRAMP_FEATURE_ONE_CLICK;
+const originalLocalDev = process.env.SKYRAMP_FEATURE_LOCAL_DEV;
+function setFlags(oneClick, localDev) {
+    if (oneClick === undefined) {
+        delete process.env.SKYRAMP_FEATURE_ONE_CLICK;
+    }
+    else {
+        process.env.SKYRAMP_FEATURE_ONE_CLICK = oneClick;
+    }
+    if (localDev === undefined) {
+        delete process.env.SKYRAMP_FEATURE_LOCAL_DEV;
+    }
+    else {
+        process.env.SKYRAMP_FEATURE_LOCAL_DEV = localDev;
+    }
+}
+afterEach(() => {
+    if (originalOneClick === undefined) {
+        delete process.env.SKYRAMP_FEATURE_ONE_CLICK;
+    }
+    else {
+        process.env.SKYRAMP_FEATURE_ONE_CLICK = originalOneClick;
+    }
+    if (originalLocalDev === undefined) {
+        delete process.env.SKYRAMP_FEATURE_LOCAL_DEV;
+    }
+    else {
+        process.env.SKYRAMP_FEATURE_LOCAL_DEV = originalLocalDev;
+    }
+});
+describe("command library feature gates", () => {
+    it("exposes no one-click workflows when both one-click and local-dev are disabled", () => {
+        setFlags(undefined, undefined);
+        expect(getCommandIds()).toEqual([]);
+    });
+    it("exposes only base one-click workflows when one-click is enabled", () => {
+        setFlags("1", undefined);
+        expect(getCommandIds().sort()).toEqual([
+            "full_repo_scan_recommend_generate_and_execute_top_n_tests",
+            "test_given_endpoint_comprehensively",
+        ]);
+    });
+    it("exposes only local-dev when local-dev is enabled without general one-click", () => {
+        setFlags(undefined, "1");
+        expect(getCommandIds()).toEqual(["local_dev_test_changes"]);
+        expect(lookupCommand("local_dev_test_changes").id).toBe("local_dev_test_changes");
+        expect(() => lookupCommand("test_given_endpoint_comprehensively")).toThrow(/Unknown workflow/);
+    });
+    it("exposes base and local-dev workflows when both flags are enabled", () => {
+        setFlags("1", "1");
+        expect(getCommandIds().sort()).toEqual([
+            "full_repo_scan_recommend_generate_and_execute_top_n_tests",
+            "local_dev_test_changes",
+            "test_given_endpoint_comprehensively",
+        ]);
+    });
+});

package/build/index.js

@@ -52,13 +52,16 @@ const localDevInstructions = `\n- When the user asks to test local changes, vali
 const fullOneClickInstructions = `\n- When the user asks to comprehensively, thoroughly, or deeply test a specific endpoint: MUST call \`skyramp_one_click_tool\` with workflow \`test_given_endpoint_comprehensively\` first. Do NOT self-orchestrate the steps manually.\n- When the user asks to scan the full repo, recommend, generate, and execute top N tests: MUST call \`skyramp_one_click_tool\` with workflow \`full_repo_scan_recommend_generate_and_execute_top_n_tests\`.${localDevEnabled ? localDevInstructions : ""}`;
 // Testbot suppresses one-click workflows (it has its own orchestration via testbot prompt),
 // but local-dev routing is always active when the flag is set — they serve different use cases.
-const oneClickInstructions = isTestbotEnabled()
-    ? (localDevEnabled ? localDevInstructions : "")
-    : oneClickEnabled
-        ? fullOneClickInstructions
-        : localDevEnabled
-            ? localDevInstructions
-            : "";
+let oneClickInstructions = "";
+if (isTestbotEnabled()) {
+    oneClickInstructions = localDevEnabled ? localDevInstructions : "";
+}
+else if (oneClickEnabled) {
+    oneClickInstructions = fullOneClickInstructions;
+}
+else if (localDevEnabled) {
+    oneClickInstructions = localDevInstructions;
+}
 const server = new McpServer({
     name: "Skyramp MCP Server",
     version: "1.0.0",

package/build/prompts/initialize-workspace/initializeWorkspacePrompt.js

@@ -68,7 +68,7 @@ API schemas (look inside the service directory and check known framework default
 <runtime_config>
 Inspect the repo root (and subdirectories like .devcontainer/) for shared runtime configuration:
 1. CLAUDE.md or AGENTS.md: if either file exists at the repo root, check it for dev/test/CI setup instructions including how to start services, required environment variables, and runtime configuration.
-2. Docker Compose files: scan for ALL compose files including docker-compose.yml, docker-compose.yaml, docker-compose.*.yml (such as docker-compose.testbot.yml or docker-compose.dev.yml), compose.yml, and compose.*.yaml in the repo root and subdirectories. Distinguish between application compose files and infrastructure-only compose files. Infrastructure compose files contain only supporting services like databases, Redis, Minio, mail servers, or message queues and do NOT run the application itself. Application compose files contain the actual application services that build from the repo source code (look for "build:" directives pointing to the repo, or services that map to discovered application directories). Only use application compose files for determining runtime, serverStartCommand, and serverStopCommand. When a non-default compose file is found, the serverStartCommand and serverStopCommand must reference it explicitly (such as "docker compose -f docker-compose.testbot.yml up -d <service-name>" and "docker compose -f docker-compose.testbot.yml stop <service-name>"). Docker Compose ALWAYS prefixes the network name with the project name. If compose has "networks: { my-net: ... }", the actual network name is "<project-name>_my-net". If there is no explicit networks section, the default network is "<project-name>_default". The project name is the basename of the working directory where docker compose runs.
+2. Docker Compose files: scan for ALL compose files including docker-compose.yml, docker-compose.yaml, docker-compose.*.yml (such as docker-compose.testbot.yml or docker-compose.dev.yml), compose.yml, and compose.*.yaml in the repo root and subdirectories. Distinguish between application compose files and infrastructure-only compose files. Infrastructure compose files contain only supporting services like databases, Redis, Minio, mail servers, or message queues and do NOT run the application itself. Application compose files contain the actual application services that build from the repo source code (look for "build:" directives pointing to the repo, or services that map to discovered application directories). Only use application compose files for determining runtime, serverStartCommand, and serverStopCommand. When a non-default compose file is found, the serverStartCommand and serverStopCommand must reference it explicitly (such as "docker compose -f docker-compose.testbot.yml up -d --build <service-name>" and "docker compose -f docker-compose.testbot.yml stop <service-name>"). Docker Compose ALWAYS prefixes the network name with the project name. If compose has "networks: { my-net: ... }", the actual network name is "<project-name>_my-net". If there is no explicit networks section, the default network is "<project-name>_default". The project name is the basename of the working directory where docker compose runs.
 3. Makefile: extract start and dev targets.
 4. Root package.json scripts: extract workspace-level commands.
 </runtime_config>
@@ -139,7 +139,7 @@ Create one service entry per deployable unit. You MUST include every backend/API
    A repo may have MIXED runtimes. A backend in docker-compose.yml uses "docker" while a frontend run with pnpm or npm locally uses "local". Include ALL services regardless of runtime.
    If the frontend is bundled inside the API Docker container (no separate frontend service in the compose file), both frontend and backend services should use runtime "docker", share the same baseUrl (the container's exposed URL), and use the same serverStartCommand since they run in the same container.
 2. runtimeDetails.serverStartCommand: The command to start or deploy the service. It MUST match the runtime:
-   - For "docker" runtime: Use a Docker command such as "docker compose up -d <service-name>" for the default docker-compose.yml, or "docker compose -f <compose-file> up -d <service-name>" when using a non-default compose file. This is always derivable from the application docker compose file and service name.
+   - For "docker" runtime: Use a Docker command that rebuilds application services from the working tree before starting them, such as "docker compose up -d --build <service-name>" for the default docker-compose.yml, or "docker compose -f <compose-file> up -d --build <service-name>" when using a non-default compose file. This is always derivable from the application docker compose file and service name. If the compose service has no build context and only references an image, note that the command cannot rebuild local code.
    - For "k8s" runtime: Use a deploy command such as "kubectl apply -f deploy/", "helm install myrelease .", or "skaffold run". This is always derivable from the manifests or charts present in the repo.
    - For "local" runtime: Use an application command such as "uvicorn main:app", "npm run dev", or "java -jar app.jar". Derive from Makefile, package.json scripts, or README. If no start command is discoverable, omit this field entirely.
    NEVER mix runtime types with incompatible commands (for example, using "uvicorn" with runtime "docker" will cause errors). For "local" runtime, NEVER fabricate a command. Only use commands found in Makefile, package.json scripts, or README.
@@ -160,7 +160,7 @@ Before calling skyramp_init_workspace, confirm all of the following:
 6. framework matches language (python uses pytest or robot, typescript or javascript uses playwright, java uses junit).
 7. testDirectory follows the stable resolution rules above: framework config file when present (Playwright testDir in playwright.config.ts, pytest testpaths in pytest.ini or pyproject.toml, JUnit test source dir in pom.xml or build.gradle); otherwise the deterministic default (tests/skyramp for a single service, tests/skyramp/<serviceDirName> for multiple services).
 8. If serverStartCommand is provided, it matches the runtime. If serverStopCommand is provided, runtime is "docker" and the command is a Docker command.
-9. For services in docker-compose.yml: runtime MUST be "docker" and the command MUST be a docker command such as "docker compose up -d <service-name>". Always include it since it is derivable from the service name.
+9. For services in docker-compose.yml: runtime MUST be "docker" and the command MUST be a docker command such as "docker compose up -d --build <service-name>" when the service has a build context. Always include it since it is derivable from the service name.
 10. NEVER use application-level commands (uvicorn, npm, node, python, java, etc.) with runtime "docker".
 11. For "local" runtime: if no start command is discoverable from Makefile, package.json scripts, or README, omit serverStartCommand rather than guessing.
 12. dockerNetwork is set only when runtime is "docker".

package/build/prompts/local-dev/local-dev-plan.d.ts

@@ -4,11 +4,11 @@
  * Phases: ANALYZE → RECOMMEND → GENERATE → VERIFY → DEPLOY → EXECUTE
  *
  * Key design decisions:
- * - Mock files are generated in the same language as tests (from workspace config) with get_all_mocks()
- * - Tests import get_all_mocks from each mock file, collect into MOCK_SERVICES, deploy collectively
+ * - Mock files are generated in the same language as tests (from workspace config) with get_all_mocks()/getAllMocks()
+ * - Tests import get_all_mocks()/getAllMocks() from each mock file, collect into MOCK_SERVICES, deploy collectively
  * - NO YAML mock files, NO CLI commands — ONLY MCP tools
  * - Execution uses skyramp_execute_test MCP tool exclusively
- * - The executor handles mock deployment from the test file automatically
+ * - Enriched tests apply mocks at runtime through their language-specific Skyramp client helper
  */
 import { PromptPlan } from "../test-recommendation/promptPlan.js";
 export interface LocalDevPlanCtx {

package/build/prompts/local-dev/local-dev-plan.js

@@ -4,11 +4,11 @@
  * Phases: ANALYZE → RECOMMEND → GENERATE → VERIFY → DEPLOY → EXECUTE
  *
  * Key design decisions:
- * - Mock files are generated in the same language as tests (from workspace config) with get_all_mocks()
- * - Tests import get_all_mocks from each mock file, collect into MOCK_SERVICES, deploy collectively
+ * - Mock files are generated in the same language as tests (from workspace config) with get_all_mocks()/getAllMocks()
+ * - Tests import get_all_mocks()/getAllMocks() from each mock file, collect into MOCK_SERVICES, deploy collectively
  * - NO YAML mock files, NO CLI commands — ONLY MCP tools
  * - Execution uses skyramp_execute_test MCP tool exclusively
- * - The executor handles mock deployment from the test file automatically
+ * - Enriched tests apply mocks at runtime through their language-specific Skyramp client helper
  */
 import { PromptPlan } from "../test-recommendation/promptPlan.js";
 // ── The Plan ─────────────────────────────────────────────────────────────────
@@ -34,11 +34,7 @@ If 0 endpoints detected but changed files contain application code: manually tra
 
 If \`skyramp_analyze_changes\` returns an error: retry once for transient errors. If it fails again, report the error and stop.
 
-**If the output file is too large to read** (the Read tool returns a token-limit error): extract only the fields you need with a targeted Bash command, for example:
-\`\`\`bash
-python3 -c "import json,sys; d=json.load(open('<output_file>')); print(json.dumps({'endpoints': d.get('endpoints',[]), 'recommendations': d.get('recommendations',[])[:${ctx.maxRecommendations}]}, indent=2))"
-\`\`\`
-Do not retry the Read tool with progressively smaller limits — use the extraction approach on the first failure.`)
+**If the analysis output is too large to inspect**: do not switch to direct shell commands. Use the inline recommendations returned by \`skyramp_analyze_changes\`, fetch the focused MCP resources for this session (summary, endpoints, scenarios, and diff), or rerun with a smaller \`topN\` / \`maxGenerate\` budget so the workflow remains MCP-driven.`)
     .step("DISCOVER_DEPS", "Discover downstream dependencies", (_ctx) => `For each changed endpoint, read the implementation code and identify ALL outbound service calls:
 
 **HTTP/REST** — look for: \`HTTParty\`, \`fetch\`, \`axios\`, \`http.NewRequestWithContext\`, SDK client calls
@@ -103,7 +99,7 @@ For each endpoint under test:
 
 5. **For API and downstream contracts**, include scenarios only when they catch a realistic bug:
    - Provider contract: response field added/renamed/removed, type/nullable mismatch, status-code semantic drift.
-   - Consumer contract: our code sends the wrong downstream request shape/header/path, or parses a response field that may be missing/renamed.
+   - Consumer contract: our code sends the wrong downstream request body/header/path, or parses a response field that may be missing/renamed.
 
 6. **For full API flows**, treat API E2E coverage as integration coverage:
    - **API full-flow coverage is integration coverage** in this workflow. Do NOT label API-only workflows as E2E.
@@ -121,7 +117,7 @@ For each endpoint under test:
 
 9. **Output a unified scenario table** (do NOT generate code yet):
 
-| # | Bug-Catching Target | Best Test Type | Scenario Name | Mock Config | Expected Response | Priority |
+| # | What this verifies | Best Test Type | Scenario Name | Mock Config | Expected Response | Priority |
 |---|---------------------|----------------|---------------|-------------|-------------------|----------|
 | 1 | Order creation applies downstream pricing rules | integration | happy-path-with-pricing | All required downstream success | 201 + calculated totals | high |
 | 2 | Payment rejection rolls back order creation | integration | payment-rejects | Payment service → 422 | expected error + no persisted order | high |
@@ -140,7 +136,7 @@ For each endpoint under test:
 })
     .step("GENERATE_MOCKS_AND_TESTS", "Generate highest-value tests", (ctx) => `**Preferred: Use batch tools when available.**
 - Call \`skyramp_batch_mock_generation\` with all mock specs in one array instead of individual \`skyramp_mock_generation\` calls.
-- Call \`skyramp_generate_enriched_integration_test\` instead of separate generate + enrich calls.
+- For Python, TypeScript, JavaScript, and Java integration tests, call \`skyramp_generate_enriched_integration_test\` instead of separate generate + enrich calls when generated mocks must be wired into the test.
 - Call \`skyramp_enhance_assertions\` with \`autoApply: true\` for compact output format — the returned instructions must still be applied by you to the test file.
 
 **Run \`skyramp_preflight_mock_check\` FIRST, before reading any .proto files or constructing any mock spec.**
@@ -156,9 +152,11 @@ Work through the scenario list from Phase 2 in **bug-catching priority order**.
 
 **Side-effect rule:** Integration scenarios must account for all downstream side effects discovered for that scenario. Generate mocks only for side-effect dependencies selected for mocking by service routing, protocol routing, or the default third-party policy. If a Kafka-compatible broker is a real local infrastructure service, keep it real and document that decision instead of generating Kafka mocks. Full-scenario integration tests should cover the complete API workflow from trigger request through downstream calls and final observable result.
 
+**Outbound assertion rule:** If the behavior being tested depends on what the service under test sends to a mocked dependency, the test must prove the outbound interaction, not just the final SUT response. For REST mocks, provide \`requestData\` for the expected body and \`requestAware: true\`; for gRPC, include the expected request fields in the scenario's verification notes when the mock/test API can assert them; for Kafka producers, use \`requestData\` and include the Kafka mock in \`MOCK_SERVICES\`. If Skyramp cannot assert the outbound body/header/path/event payload for the selected protocol, mark that scenario **Blocked — outbound assertion unsupported** instead of reporting a green pass.
+
 **REST mock routing rule:** Generated REST mock files may contain a fallback like \`URL = skyramp.get_base_url(..., "http://localhost:8080")\`. Do not manually edit the generated mock file for local-dev routing. The enrichment step parses the mock generation \`# Command\` line and overwrites each deployable REST mock's \`mock.url\` with the original service origin from \`endpointURL\` (for example, \`http://ams:4000\` or \`http://billing:5001\`). If the command target itself is loopback, regenerate the mock with the original Docker service hostname.
 
-**Mock semantics rule:** Kafka mock generation must use \`kafkaTopic\` for the topic name; do not pass \`method: "produce"\` or \`method: "consume"\`. Use exactly one of \`requestData\` for producer validation or \`responseData\` for consumer messages. Core Skyramp infers Kafka \`produce\` from \`request_body\` and \`consume\` from \`response_body\`; passing both or neither is invalid. Kafka mock files are generated, included in \`MOCK_SERVICES\`, included in \`MOCK_TARGET_URLS\`, and applied by \`apply_all_mocks(client)\` after enrichment sets \`mock.url\` to the original broker \`host:port\` from the generation command. If a gRPC failure scenario depends on \`GRPC::Unavailable\`, \`DeadlineExceeded\`, \`NOT_FOUND\`, or another status error, gRPC status errors cannot be represented as normal responseData. Use a supported failure mechanism if available; otherwise record the scenario as blocked instead of generating a mock body like \`{ "error": "UNAVAILABLE" }\`.
+**Mock semantics rule:** Kafka mock generation must use \`kafkaTopic\` for the topic name; do not pass \`method: "produce"\` or \`method: "consume"\`. Use exactly one of \`requestData\` for producer validation or \`responseData\` for consumer messages. Core Skyramp infers Kafka \`produce\` from \`request_body\` and \`consume\` from \`response_body\`; passing both or neither is invalid. Kafka mock files are generated, included in \`MOCK_SERVICES\`, included in \`MOCK_TARGET_URLS\`, and applied by the language-specific apply helper after enrichment sets \`mock.url\` to the original broker \`host:port\` from the generation command. If a gRPC failure scenario depends on \`GRPC::Unavailable\`, \`DeadlineExceeded\`, \`NOT_FOUND\`, or another status error, gRPC status errors cannot be represented as normal responseData. Use a supported failure mechanism if available; otherwise record the scenario as blocked instead of generating a mock body like \`{ "error": "UNAVAILABLE" }\`.
 
 For each selected scenario, follow the workflow matching its best test type:
 
@@ -176,6 +174,7 @@ REST spec fields:
 - \`method\`: HTTP method
 - \`responseData\`: realistic JSON response for THIS scenario
 - \`requestAware\`: true
+- \`requestData\`: required when this scenario's bug-catching value depends on outbound request-body correctness. It must contain the exact fields the service under test should send to the downstream service (for example, \`billing_email\`, not an adjacent field such as \`adverse_action_email\`). For response-only downstream scenarios where body correctness is not what "What this verifies" covers, omit \`requestData\` unless it is needed for request-aware routing. If required request-body matching cannot be generated for the mock, record the scenario as blocked instead of producing a status-only test.
 
 gRPC spec fields:
 - \`protocol\`: "grpc"
@@ -241,7 +240,9 @@ Call \`skyramp_contract_test_generation\` with:
 
 Consumer contract tests have mocks wired **inline by default** — the generated test file includes \`MockV2\` creation and \`client.apply_mock(mock)\` directly in the test function. **No separate \`skyramp_enrich_test_with_mocks\` call is needed for contract tests.** The mock defines the expected downstream response shape and the test validates the contract against it.
 
-Consumer contracts catch: field renamed downstream, new required header added, response shape changed, status code semantics changed.
+Consumer contract tests are incomplete until they invoke real consumer/SUT code that triggers the outbound request. A generated stub that calls \`client.send_request\` directly against the mock only proves the mock responds; it does not prove the application sends the right body/header/path. If you cannot wire real consumer code, do not execute or report the contract as PASS — mark the scenario **Blocked — consumer wiring unavailable**.
+
+Consumer contracts catch: wrong outbound request body/header/path, field renamed downstream, new required header added, response shape changed, status code semantics changed.
 
 ---
 
@@ -266,7 +267,8 @@ Generate UI tests only when the diff includes frontend changes, a changed UI rou
 - **Idempotent test data** — use unique values that won't collide on re-run (UUID suffixes for emails, random names, timestamps). Do NOT use static emails like "test@example.com" that will hit uniqueness constraints.
 - **Auth headers** — generated tests should read auth from \`SKYRAMP_TEST_TOKEN\` only. Do not add literal token fallbacks to test files; pass the discovered token via \`skyramp_execute_test.token\` or the MCP server environment before execution. A 401 caused by an unset token is an execution setup bug, not a reason to hardcode credentials.
 - **Contract responseData** — always provide the FULL expected shape so the test asserts on field presence, types, and values — not just status codes.
-- **Assertion depth (integration tests)** — every integration test must assert the specific fields that prove the scenario's Bug-Catching Target, not just the HTTP status code. Use \`skyramp.get_response_value(response, "field.path")\` to assert field values from the Expected Response column of the scenario table. Example: for a "customer config applied" scenario, assert \`skyramp.get_response_value(response, "tax_exempt") == True\` and \`skyramp.get_response_value(response, "default_compliance_state") == "<expected_value>"\` where \`<expected_value>\` is the actual value the mock returns for that scenario (e.g., a jurisdiction code like \`"CA"\`, a status string, or a numeric value — derive it from the mock's responseData, not from a guess). Status-code-only assertions never satisfy this rule.
+- **Assertion depth (integration tests)** — every integration test must assert the specific fields that prove the scenario's "What this verifies" column, not just the HTTP status code. Use \`skyramp.get_response_value(response, "field.path")\` to assert field values from the Expected Response column of the scenario table. Example: for a "customer config applied" scenario, assert \`skyramp.get_response_value(response, "tax_exempt") == True\` and \`skyramp.get_response_value(response, "default_compliance_state") == "<expected_value>"\` where \`<expected_value>\` is the actual value the mock returns for that scenario (e.g., a jurisdiction code like \`"CA"\`, a status string, or a numeric value — derive it from the mock's responseData, not from a guess). Status-code-only assertions never satisfy this rule.
+- **No hollow tests** — never execute or report a generated test as PASS if it contains unresolved placeholders such as \`TODO\`, a standalone \`pass\` statement in a test body, \`NotImplemented\`, "replace with real consumer code", or an executable consumer-contract stub that directly calls the mocked endpoint instead of application/consumer code. A direct-mock stub may remain only when it is explicitly skipped or strict xfail and a separate executable real consumer/SUT test exists. Implement the missing check or mark the scenario blocked.
 - Failure recovery: retry once, then skip and log in issuesFound.
 
 Keep advancing in bug-catching priority order until the highest-value scenarios have test files (up to ${ctx.maxGenerate} total).`)
@@ -285,12 +287,14 @@ This injects import statements from the generated mock files — no data duplica
     .step("VALIDATE_MOCKS", "Confirm test setup is complete", (ctx) => `Verify:
 
 1. Every scenario from Phase 2 has a corresponding test file in \`${ctx.repositoryPath}/tests/skyramp/\`
-2. For integration tests with selected downstream mocks: mock files exist in \`mocks/\` for each selected service/protocol and test files import them via a non-empty \`MOCK_SERVICES\` plus \`apply_all_mocks(client)\`; if \`MOCK_SERVICES = {}\` or any expected mock import is missing for a mocked dependency, return to \`GENERATE_MOCKS_AND_TESTS\` or \`ENRICH_TESTS\` before any edits or execution
+2. For integration tests with selected downstream mocks: mock files exist in \`mocks/\` for each selected service/protocol and test files import them via a non-empty \`MOCK_SERVICES\` plus the language-specific apply helper (\`apply_all_mocks(client)\` for Python or \`applyAllMocks(client)\` for TypeScript/JavaScript/Java); if \`MOCK_SERVICES = {}\` or any expected mock import is missing for a mocked dependency, return to \`GENERATE_MOCKS_AND_TESTS\` or \`ENRICH_TESTS\` before any edits or execution
 3. For consumer contract tests: mocks are wired inline (\`client.apply_mock(mock)\` present in the test function) — no separate mock files needed
 4. For provider contract tests: no mocks — test hits the real endpoint directly
 5. Test files use idempotent data (UUID-suffixed emails, random values — not hardcoded strings)
 6. Auth headers are present in all test requests
-7. **Integration tests have scenario-driven assertions** — each test asserts the specific response fields that prove the Bug-Catching Target from the scenario table, not only the status code. If a test only asserts \`response.status_code == 201\` (or equivalent) without any field-level assertion on the behavior being tested, it is incomplete. Add \`skyramp.get_response_value()\` assertions for the key fields before executing.
+7. **Integration tests have scenario-driven assertions** — each test asserts the specific response fields that prove the "What this verifies" column from the scenario table, not only the status code. If a test only asserts \`response.status_code == 201\` (or equivalent) without any field-level assertion on the behavior being tested, it is incomplete. Add \`skyramp.get_response_value()\` assertions for the key fields before executing.
+8. **Outbound side effects are verified** — for every selected REST/gRPC/Kafka mock whose request body/header/path/event payload is the behavior under test, the mock spec or test includes a request/event assertion. If the toolchain cannot express that assertion, mark the scenario blocked instead of treating a response-only test as coverage.
+9. **No unresolved stubs** — no generated test file contains \`TODO\`, a standalone \`pass\` statement in a test body, \`NotImplemented\`, "replace with real consumer code", or an executable consumer-contract test that only calls the mock directly. A skipped or strict xfail direct-mock reference is allowed only when the file also contains a separate executable real consumer/SUT test. These are blocking defects, not passing tests.
 
 **If any mock file is missing for integration tests:** re-run \`skyramp_mock_generation\` for that service/endpoint.`)
     .step("ENHANCE_ASSERTIONS", "Enhance assertions for each test file", (ctx) => `For each test file in \`${ctx.repositoryPath}/tests/skyramp/\`, call \`skyramp_enhance_assertions\` with:
@@ -323,12 +327,12 @@ Steps:
 2. Identify which docker-compose service names correspond to services selected for mocking (e.g., if \`ams\` is selected for mocking, do not start the \`ams\` container).
 3. Stop any mocked service containers that are already running:
    \`docker compose stop <mocked-service-1> <mocked-service-2> ...\`
-4. Bring up only the SUT and its real dependencies — start selectively:
-   \`docker compose up -d <sut-service> <db> <cache> <broker> <real-first-party-services>\`
-   Do **not** run plain \`docker compose up -d\` when it would start mocked downstream services. If the compose file cannot start selectively, start the minimum required profile/services and then re-check that mocked service containers are stopped before executing tests.
+4. Rebuild and bring up only the SUT and its real dependencies — start selectively:
+   \`docker compose up -d --build <sut-service> <db> <cache> <broker> <real-first-party-services>\`
+   Do **not** run plain \`docker compose up -d\` when it would start mocked downstream services or reuse a stale SUT image. If the compose file cannot start selectively, start the minimum required profile/services and then re-check that mocked service containers are stopped before executing tests. If the SUT service has no compose \`build\` context, record that local code cannot be rebuilt by compose before execution.
 5. Wait for health checks to pass and verify the service under test responds (e.g., curl the health endpoint or send a minimal request).
 
-The \`skyramp_execute_test\` tool handles mock deployment automatically — it reads \`MOCK_SERVICES\` from the enriched test file, deploys selected mocks to the Skyramp worker, then runs the test.
+The \`skyramp_execute_test\` tool runs the enriched test in the language runner. The enriched test applies selected mocks at runtime through its language-specific helper before exercising the service.
 
 **Do NOT proceed to Execute until: (a) the service under test responds, and (b) all mocked service containers are confirmed stopped.**`)
     .subStep("DEPLOY_GRPC", "Handle gRPC dependencies", (_ctx) => `If the dependency map from Phase 1 includes gRPC services selected for mocking:
@@ -364,9 +368,11 @@ To regenerate a single missing Kafka mock, call \`skyramp_mock_generation\` with
 
 **If \`skyramp_execute_test\` is unavailable** (tool not found, MCP disconnected, or context compaction removed it): do NOT fall back to any direct runtime. Stop execution immediately, list the test files that could not be executed, and tell the user: "The skyramp_execute_test tool is unavailable. Please reconnect the Skyramp MCP server and re-run. Do not use pytest or any direct runtime — doing so bypasses mock deployment and Skyramp telemetry."
 
-The \`skyramp_execute_test\` MCP tool handles execution. For enriched integration tests, it reads \`MOCK_SERVICES\`, deploys selected mocks to the Skyramp worker, then runs the test in a container. Contract tests run without \`MOCK_SERVICES\`.
+The \`skyramp_execute_test\` MCP tool handles execution. For enriched integration tests, it runs the test in a container; the test's generated helper reads \`MOCK_SERVICES\`, clears stale mocks, and applies selected mocks before requests execute. Contract tests run without \`MOCK_SERVICES\`.
+
+**Pre-execution gate:** Before every integration test execution, inspect the test file. If it does not contain \`MOCK_SERVICES\` and the language-specific apply helper (\`apply_all_mocks(client)\` for Python or \`applyAllMocks(client)\` for TypeScript/JavaScript/Java), or if it contains an empty \`MOCK_SERVICES\` collection for a scenario with downstream mocks, do NOT execute it. Call \`skyramp_enrich_test_with_mocks\` first and re-check the file. If \`MOCK_SERVICES\` is non-empty, execution is invalid until every real service selected for mocking is stopped.
 
-**Pre-execution gate:** Before every integration test execution, inspect the test file. If it does not contain both \`MOCK_SERVICES\` and \`apply_all_mocks(client)\`, or if it contains \`MOCK_SERVICES = {}\` for a scenario with downstream mocks, do NOT execute it. Call \`skyramp_enrich_test_with_mocks\` first and re-check the file. If \`MOCK_SERVICES\` is non-empty, execution is invalid until every real service selected for mocking is stopped.
+**No-hollow-pass gate:** Before executing any generated test, inspect it for unresolved placeholders or stub-only behavior. Do NOT execute or report PASS for files containing \`TODO\`, a standalone \`pass\` statement in a test body, \`NotImplemented\`, "replace with real consumer code", or executable consumer-contract code that calls the mocked endpoint directly without invoking application/consumer code. Skipped or strict xfail direct-mock reference stubs may remain only when a separate executable real consumer/SUT test exists; the skipped or strict xfail stub never counts as PASS. Strict xfail must fail the run on XPASS (for pytest, \`@pytest.mark.xfail(strict=True)\`). Fix the test or report the scenario as blocked.
 
 **Execution — one call per test file:**
 \`\`\`
@@ -379,7 +385,7 @@ skyramp_execute_test({
 })
 \`\`\`
 
-That's it. Pass \`token: ""\` so the executor injects \`SKYRAMP_TEST_TOKEN\` from the environment when auth is configured. For provider contract tests, omit \`contractMode\` or pass \`contractMode: "provider"\` so \`SKYRAMP_TEST_BASE_URL\` is injected. For consumer contract tests with inline mocks, pass \`contractMode: "consumer"\`. For integration tests, mock deployment is automatic — the tool reads \`MOCK_SERVICES\` from the enriched test file and deploys before execution. Provider contract tests hit the service under test directly; consumer contract tests use any inline mocks generated in the contract test itself; UI tests replay the generated browser workflow.
+That's it. Pass \`token: ""\` so the executor injects \`SKYRAMP_TEST_TOKEN\` from the environment when auth is configured. For provider contract tests, omit \`contractMode\` or pass \`contractMode: "provider"\` so \`SKYRAMP_TEST_BASE_URL\` is injected. For consumer contract tests with inline mocks, pass \`contractMode: "consumer"\`. For integration tests, mock deployment is automatic because the enriched test helper reads \`MOCK_SERVICES\`, clears stale mocks, and applies them before exercising the service. Provider contract tests hit the service under test directly; consumer contract tests use any inline mocks generated in the contract test itself; UI tests replay the generated browser workflow.
 
 **On failure:**
 1. Read the error output to diagnose the root cause.
@@ -393,7 +399,7 @@ That's it. Pass \`token: ""\` so the executor injects \`SKYRAMP_TEST_TOKEN\` fro
 
 **IMPORTANT: Execute tests SEQUENTIALLY (one at a time).** Do NOT send multiple \`skyramp_execute_test\` calls in parallel — concurrent execution overwhelms the stdio transport and causes MCP disconnection. Wait for each test to complete before starting the next.
 
-**Completion gate:** Do not report success after only one passing test if more generated test files or high-priority scenario rows remain. A passing integration test with selected mocked downstreams is not valid if the test has empty \`MOCK_SERVICES\` or if required selected mocks were removed and replaced by live Compose stubs. Execute every generated test file and report any high-priority scenarios that could not be generated or executed, including the reason.`)
+**Completion gate:** Do not report success after only one passing test if more generated test files or high-priority scenario rows remain. A passing integration test with selected mocked downstreams is not valid if the test has empty \`MOCK_SERVICES\`, if required selected mocks were removed and replaced by live Compose stubs, or if the scenario's value depends on an outbound request/event that was not asserted. Execute every generated test file and report any high-priority scenarios that could not be generated or executed, including the reason.`)
     .step("REPORT_RESULTS", "Report results to user", (_ctx) => `Present a summary to the user covering:
 
 - **What changed**: 2-3 sentence summary of the diff

package/build/prompts/local-dev/local-dev-prompts.js

@@ -55,12 +55,12 @@ ${sandboxWorkerBlock ? sandboxWorkerBlock + "\n" : ""}${serviceContext ? service
 - Always generate NEW tests targeting the behavior introduced in this diff — do not skip generation because an existing test file covers the same endpoint.
 - For every endpoint under test, discover ALL downstream dependencies (HTTP, gRPC, Kafka) by reading the implementation code. Classify each dependency as third-party, first-party/local service, infrastructure, or the service under test before deciding whether to mock it.
 - **Default mock scope** — mock only true third-party downstream services by default. Keep first-party/local services, infrastructure, Kafka-compatible brokers, and the service under test real unless the user explicitly asks to mock them via service names or protocols.
-- **Mock files are code in the same language as tests** — \`skyramp_mock_generation\` produces mock files (language from workspace config) in \`tests/skyramp/mocks/\` with \`get_all_mocks()\` functions that return MockV2 objects. The enrichment tool imports these, builds a collective \`MOCK_SERVICES\` dict, reuses the integration test client, clears stale mocks, and applies the full mock set in one atomic call. Do NOT create YAML mock files.
+- **Mock files are code in the same language as tests** — \`skyramp_mock_generation\` produces mock files (language from workspace config) in \`tests/skyramp/mocks/\` with language-native mock factory functions (\`get_all_mocks()\` for Python, \`getAllMocks()\` for TypeScript/JavaScript/Java) that return MockV2 objects. The enrichment tool imports these, builds a collective \`MOCK_SERVICES\` collection, reuses the integration test client, clears stale mocks, and applies the full mock set in one atomic call. Do NOT create YAML mock files.
 - **NO Skyramp CLI** — do NOT use \`skyramp mocker apply\`, \`skyramp mocker generate\`, or any other Skyramp CLI command. Use ONLY MCP tools for Skyramp operations.
 - **NO duplicate mock data** — the generated mock files are the single source of truth. Do NOT duplicate response bodies or status codes in the test file. The test references mock files, not copies of them.
 - **Mock generation → enrich flow (integration tests only)** — use \`skyramp_mock_generation\` to generate mock files, then call \`skyramp_enrich_test_with_mocks\` to wire mock references into the test. The enrichment uses the same data from generation — never invent different values. Consumer contract tests do NOT need enrichment — mocks are wired inline by the generation tool.
 - **MANDATORY enrichment gate** — after every \`skyramp_integration_test_generation\` call for a scenario with any generated mock files, immediately call \`skyramp_enrich_test_with_mocks\` before reading, editing, enhancing, or executing that test. Do not batch all enrichment for later.
-- **Enrichment validation** — an integration test that has downstream mocks but lacks \`MOCK_SERVICES\` and \`apply_all_mocks(client)\` is incomplete. Stop and enrich it; never call \`skyramp_execute_test\` on an incomplete integration test.
+- **Enrichment validation** — an integration test that has downstream mocks but lacks \`MOCK_SERVICES\` and the language-specific apply helper (\`apply_all_mocks(client)\` for Python or \`applyAllMocks(client)\` for TypeScript/JavaScript/Java) is incomplete. Stop and enrich it; never call \`skyramp_execute_test\` on an incomplete integration test.
 - **Do not delete mocks to pass** — if mock deployment fails, do NOT remove mock imports, empty \`MOCK_SERVICES\`, switch mocked downstreams to live Compose stubs, or report the resulting test as passed. Fix the mock wiring once; if still blocked, report the scenario as failed/blocked with the mock deployment error.
 - **Mocked services must not be running** — before execution, stop every Docker container for a service selected for mocking (\`docker compose stop <mocked-service>\`). The Skyramp worker takes over that service's DNS alias on the Docker network; a real container running on the same hostname and port will conflict, causing traffic to reach the real service instead of the mock or causing port binding failure. Bring up only the SUT and its real infrastructure (DB, cache, real broker, real first-party services); do NOT run \`docker compose up -d\` without immediately stopping mocked service containers.
 - **Mock URL format** — the \`endpointURL\` in \`skyramp_mock_generation\` MUST use the original Docker service hostname (e.g., \`http://identity-service:4000\`, \`http://profile-service:50052\`). The Skyramp executor uses DNS alias hijacking — it takes over the service's DNS name on the Docker network so the service under test's requests are intercepted transparently. NEVER use \`localhost\`, \`127.0.0.1\`, \`0.0.0.0\`, \`host.docker.internal\`, or the worker address as the mock URL. For REST mocks, \`skyramp_preflight_mock_check\` returns blocking \`REST_LOOPBACK_URL\` when a deployable mock uses these hosts.
@@ -68,6 +68,8 @@ ${sandboxWorkerBlock ? sandboxWorkerBlock + "\n" : ""}${serviceContext ? service
 - **gRPC mock routing** — gRPC mocks may target the real downstream service port (e.g., \`partner-accounts:50051\`). Apply gRPC mocks before the SUT starts or restart the SUT after applying them, and verify the Skyramp worker has the original endpoint host alias from \`endpointURL\` (\`partner-accounts\`, not the protobuf service name like \`PartnerAccountsService\`).
 - **Execution** — ALWAYS use \`skyramp_execute_test\` MCP tool to run tests. NEVER use direct language runtimes (\`python3\`, \`pytest\`, \`node\`, \`npx jest\`, etc.) or Skyramp CLI commands.
 - **Generated test hardening** — before execution, make generated tests rerunnable and assertion-rich: use \`int(os.getenv("SKYRAMP_WORKER_PORT", "35142"))\` instead of a hardcoded worker port, keep auth token lookup environment-only (\`os.getenv("SKYRAMP_TEST_TOKEN")\`) with no literal fallback token in test source; pass the discovered token via \`skyramp_execute_test.token\` or the MCP server \`SKYRAMP_TEST_TOKEN\` environment before execution, use \`json.dumps({...})\` for JSON request bodies instead of f-string triple-quoted strings, use unique data for persistent DBs (UUID-suffixed emails/names), access \`ResponseV2\` via \`.status_code\` and \`skyramp.get_response_value(...)\` (never \`.json()\`), remember \`check_schema\` validates concrete field values (not just shape — a wrong value fails the assertion), and assert the changed behavior rather than status code alone.
+- **Outbound side-effect proof** — when a scenario is meant to verify what the service under test sends to a mocked dependency, require a REST request body/header/path assertion, a Kafka producer payload assertion, or a documented gRPC request assertion. If Skyramp cannot express the outbound assertion, mark the scenario blocked instead of reporting a response-only test as passing.
+- **No hollow green tests** — unresolved placeholders (\`TODO\`, a standalone \`pass\` statement in a test body, \`NotImplemented\`, or "replace with real consumer code") and executable consumer-contract stubs that call only the mock are blocking defects. Skipped or strict xfail direct-mock reference stubs are allowed only when paired with a separate executable real consumer/SUT test. Implement the missing application/consumer call or report the scenario blocked; do not execute or report it as PASS.
 - **Downstream dependency handling is explicit** — HTTP/REST, gRPC, and Kafka dependencies can be mocked with Skyramp when selected for mocking. For gRPC, call \`skyramp_mock_generation\` with \`protocol: "grpc"\`, \`endpointURL\` as \`host:port\`, plus \`protoPath\` and \`grpcServiceName\`. For Kafka, call \`skyramp_mock_generation\` with \`protocol: "kafka"\`, \`endpointURL\` as broker \`host:port\`, and \`kafkaTopic\` as the topic name.
 - **Service routing** — if a \`<SERVICE_ROUTING>\` block is provided above, respect it strictly. Resolve routing in this order:
   1. \`REAL_SERVICES\` wins over every other rule. A real service should receive real traffic even if its service name or protocol is also listed for mocking.

package/build/services/AnalyticsService.d.ts

@@ -1,7 +1,7 @@
 import { CallToolResult } from "@modelcontextprotocol/sdk/types.js";
 export declare class AnalyticsService {
     static pushTestGenerationToolEvent(toolName: string, result: CallToolResult, params: Record<string, any>): Promise<void>;
-    static pushMCPToolEvent(toolName: string, result: CallToolResult | undefined, params: Record<string, string>): Promise<void>;
+    static pushMCPToolEvent(toolName: string, result: CallToolResult | undefined, params: Record<string, any>): Promise<void>;
     /**
      * Track server crash events
      */

package/build/services/TestExecutionService.js

@@ -470,10 +470,15 @@ export class TestExecutionService {
             testFilePath,
             options.testType,
         ];
+        const networkMode = options.dockerNetwork?.trim()
+            ? options.dockerNetwork.trim()
+            : options.useHostNetwork && process.platform === "linux"
+                ? "host"
+                : undefined;
         // Prepare host config with mounts
         const hostConfig = {
             ExtraHosts: ["host.docker.internal:host-gateway"],
-            ...(options.useHostNetwork && process.platform === "linux" ? { NetworkMode: "host" } : {}),
+            ...(networkMode ? { NetworkMode: networkMode } : {}),
             Mounts: [
                 {
                     Type: "bind",

package/build/services/TestExecutionService.test.js

@@ -303,6 +303,23 @@ describe("TestExecutionService.executeTest - Docker env forwarding", () => {
         delete process.env.SKYRAMP_TEST_SERVICE_URL_BACKEND;
         delete process.env.SKYRAMP_TEST_SERVICE_URL_FRONTEND;
     });
+    it.each(["python", "typescript", "javascript", "java"])("passes %s integration tests through to runner.sh", async (language) => {
+        const mockContainer = { remove: jest.fn().mockResolvedValue(undefined) };
+        mockRun.mockResolvedValue([{ StatusCode: 0 }, mockContainer]);
+        const service = new TestExecutionService();
+        await service.executeTest({
+            testFile: `/workspace/${language}_integration_test.txt`,
+            workspacePath: "/workspace",
+            language,
+            testType: "integration",
+        });
+        const command = mockRun.mock.calls[0][1];
+        expect(command[0]).toBe("/root/runner.sh");
+        expect(command[1]).toBe(language);
+        expect(command[2]).toBe(`/home/user/${language}_integration_test.txt`);
+        expect(command[3]).toBe("integration");
+        mockRun.mockClear();
+    });
     it("passes SKYRAMP_TEST_BASE_URL to Docker container Env", async () => {
         process.env.SKYRAMP_TEST_BASE_URL = "http://external-host:8000";
         const mockContainer = { remove: jest.fn().mockResolvedValue(undefined) };
@@ -349,6 +366,22 @@ describe("TestExecutionService.executeTest - Docker env forwarding", () => {
             e.startsWith("SKYRAMP_TEST_SERVICE_URL_"));
         expect(envWithBaseUrl).toHaveLength(0);
     });
+    it("attaches executor to dockerNetwork without treating it as host networking", async () => {
+        process.env.SKYRAMP_TEST_BASE_URL = "http://localhost:3000";
+        const mockContainer = { remove: jest.fn().mockResolvedValue(undefined) };
+        mockRun.mockResolvedValue([{ StatusCode: 0 }, mockContainer]);
+        const service = new TestExecutionService();
+        await service.executeTest({
+            testFile: "/workspace/test_file.py",
+            workspacePath: "/workspace",
+            language: "python",
+            testType: "smoke",
+            dockerNetwork: "checkr-demo_checkr_default",
+        });
+        const dockerOptions = mockRun.mock.calls[0][3];
+        expect(dockerOptions.HostConfig.NetworkMode).toBe("checkr-demo_checkr_default");
+        expect(dockerOptions.Env).toContain("SKYRAMP_TEST_BASE_URL=http://host.docker.internal:3000");
+    });
     // Approach B: every workspace mount is mirrored at the host-absolute path so
     // tests that embed absolute references (storageState, fixtures, snapshots)
     // resolve correctly inside the executor regardless of which path-shape the

package/build/tools/code-refactor/enhanceAssertionsTool.js

@@ -87,7 +87,12 @@ export function registerEnhanceAssertionsTool(server) {
             ],
             isError: false,
         };
-        AnalyticsService.pushMCPToolEvent(TOOL_NAME, undefined, { testFile: params.testFile, testType: params.testType, enhanceType: params.enhanceType, autoApply: String(params.autoApply) }).catch(() => { });
+        AnalyticsService.pushMCPToolEvent(TOOL_NAME, undefined, {
+            testFile: params.testFile,
+            testType: params.testType,
+            enhanceType: params.enhanceType,
+            autoApply: params.autoApply,
+        }).catch(() => { });
         return result;
     });
 }

package/build/tools/enrichTestWithMocksTool.d.ts

@@ -1,5 +1,5 @@
 import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
-import { ProgrammingLanguage } from "../types/TestTypes.js";
+import { ProgrammingLanguage, MockProtocol } from "../types/TestTypes.js";
 /**
  * skyramp_enrich_test_with_mocks
  *
@@ -11,5 +11,18 @@ import { ProgrammingLanguage } from "../types/TestTypes.js";
  */
 export declare function registerEnrichTestWithMocksTool(server: McpServer): void;
 declare function injectMockImports(original: string, testFile: string, scenarioName: string, mockFiles: string[], traceComments?: string[], language?: ProgrammingLanguage): string;
-declare function buildMockImportBlock(testFile: string, scenarioName: string, mockFiles: string[], traceComments?: string[], language?: ProgrammingLanguage): string;
-export { injectMockImports, buildMockImportBlock };
+declare function isSupportedMockEnrichmentLanguage(language: ProgrammingLanguage | string): language is ProgrammingLanguage;
+type MockEntry = {
+    serviceName: string;
+    moduleName: string;
+    relativePath: string;
+    importPath: string;
+    importLabel: string;
+    mockFile: string;
+    className: string;
+    classReference: string;
+    targetUrl?: string;
+    protocol: MockProtocol;
+};
+declare function buildMockImportBlock(testFile: string, scenarioName: string, mockFiles: string[], traceComments?: string[], language?: ProgrammingLanguage, mockEntries?: MockEntry[]): string;
+export { injectMockImports, buildMockImportBlock, isSupportedMockEnrichmentLanguage };