@skyramp/mcp 0.1.4 → 0.1.5

package/build/prompts/test-recommendation/test-recommendation-prompt.test.js

@@ -459,7 +459,7 @@ describe("buildRecommendationPrompt — maxGenerateOverride", () => {
         expect(prompt).toContain("Test type mix — MANDATORY");
         expect(prompt).toContain("Present up to 6 recommendations.");
     });
-    it("full_repo mode includes E2E/UI guidance for full-stack repos via Budget Plan", () => {
+    it("full_repo mode pre-allocates E2E and UI sections for full-stack repos", () => {
         const fullStackAnalysis = minimalAnalysis({
             projectClassification: {
                 projectType: "full-stack",
@@ -476,11 +476,11 @@ describe("buildRecommendationPrompt — maxGenerateOverride", () => {
             },
         });
         const prompt = buildRecommendationPrompt(fullStackAnalysis, AnalysisScope.FullRepo, 10);
-        // E2E/UI split is now driven by LLM's Budget Plan, not hardcoded pre-allocation.
-        // The prompt must still reference the tools and provide guidance.
+        // E2E and UI sections must be present even though scenarioDrafting only produces backend types
+        expect(prompt).toContain("### E2E");
+        expect(prompt).toContain("### UI");
         expect(prompt).toContain("skyramp_e2e_test_generation");
         expect(prompt).toContain("skyramp_ui_test_generation");
-        expect(prompt).toContain("Budget Plan");
         // Backend sections should still be present
         expect(prompt).toContain("### Integration");
     });
@@ -689,7 +689,7 @@ describe("buildRecommendationPrompt — GENERATE slot allocation", () => {
     function makeScenario(name) {
         return minimalScenario({ scenarioName: name, category: "new_endpoint" });
     }
-    it("UI-only PR: provides UI guidance with tool workflow (LLM derives scenarios)", () => {
+    it("UI-only PR: all GENERATE slots are UI placeholders (no backend)", () => {
         const analysis = minimalAnalysis({
             businessContext: { mainPurpose: "Test", userFlows: [], dataFlows: [], integrationPatterns: [], draftedScenarios: [] },
             branchDiffContext: {
@@ -702,14 +702,15 @@ describe("buildRecommendationPrompt — GENERATE slot allocation", () => {
             },
         });
         const prompt = buildRecommendationPrompt(analysis, AnalysisScope.CurrentBranchDiff, 10);
-        // UI-only PR: guidance tells LLM to derive UI tests from changed files
-        expect(prompt).toContain("UI-only PR");
+        // The GENERATE slots are the UI placeholder blocks — check their specific scenario names
+        expect(prompt).toContain("#1 — GENERATE** | ui | workflow | new");
+        expect(prompt).toContain("ui-test-for-changed-component-1");
+        expect(prompt).toContain("ui_test_1_trace.zip");
         expect(prompt).toContain("skyramp_ui_test_generation");
-        expect(prompt).toContain("skyramp_export_zip");
-        // Each item must be distinct
+        // Each slot targets a distinct changed component/flow
         expect(prompt).toContain("distinct changed component or user flow");
     });
-    it("mixed PR: all GENERATE slots are backend; UI/E2E added per Budget Plan", () => {
+    it("mixed PR: last GENERATE slot is UI, preceding slots are backend scenarios", () => {
         const scenarios = [
             makeScenario("orders-create"),
             makeScenario("orders-update"),
@@ -727,12 +728,14 @@ describe("buildRecommendationPrompt — GENERATE slot allocation", () => {
             },
         });
         const prompt = buildRecommendationPrompt(analysis, AnalysisScope.CurrentBranchDiff, 10);
-        // Backend scenarios fill GENERATE slots (no hardcoded UI placeholder)
+        // Last GENERATE slot is UI (not E2E)
+        expect(prompt).toContain("— GENERATE** | ui");
+        expect(prompt).toContain("skyramp_ui_test_generation");
+        expect(prompt).not.toContain("— GENERATE** | e2e");
+        // At least one backend scenario in GENERATE (#1 or #2)
         expect(prompt).toContain("#1 — GENERATE** | integration");
+        // Scenario name from the pre-ranked list (orders-create or orders-update)
         expect(prompt).toContain("orders-create");
-        // UI/E2E guidance is present for the LLM to add per its Budget Plan
-        expect(prompt).toContain("UI/E2E tests (add per your Budget Plan)");
-        expect(prompt).toContain("skyramp_ui_test_generation");
     });
     it("backend-only PR: all GENERATE slots are backend scenarios (no E2E injection)", () => {
         const scenarios = [makeScenario("items-create"), makeScenario("items-get"), makeScenario("items-delete")];
@@ -839,21 +842,12 @@ describe("buildRecommendationPrompt — Mandatory Reasoning Protocol", () => {
         expect(protocol).toContain("requestBody");
         expect(protocol).toContain("endpointURL");
         expect(protocol).toContain("authHeader");
-        expect(protocol).toContain("Foreign Key path params");
+        expect(protocol).toContain("FK path params");
     });
     it("reasoning protocol instructs to read source file when value cannot be sourced", () => {
         const protocol = buildReasoningProtocol();
         expect(protocol).toContain("read the relevant source file");
     });
-    it("reasoning protocol includes Coverage Reasoning Block for all 3 PR types", () => {
-        const protocol = buildReasoningProtocol();
-        expect(protocol).toContain("Coverage Reasoning Block");
-        expect(protocol).toContain("backend-only PRs");
-        expect(protocol).toContain("frontend-only PRs");
-        expect(protocol).toContain("mixed (frontend + backend) PRs");
-        expect(protocol).toContain("All HTTP methods affected");
-        expect(protocol).toContain("Testable surfaces:");
-    });
 });
 // ---------------------------------------------------------------------------
 // Tests — Context Fetching Guidance
@@ -1518,90 +1512,3 @@ describe("externalDedupKey", () => {
         expect(externalDedupKey(scenario)).toBe("POST::orders::contract");
     });
 });
-// ---------------------------------------------------------------------------
-// Tests — UI-only PR classification fix
-// ---------------------------------------------------------------------------
-describe("buildRecommendationPrompt — isUIOnlyPR classification", () => {
-    it("does not classify as UI-only when backend service files changed but no endpoints detected", () => {
-        const analysis = minimalAnalysis({
-            branchDiffContext: {
-                baseBranch: "main",
-                currentBranch: "feature/field-rbac",
-                changedFiles: [
-                    "api/src/services/items.ts",
-                    "api/src/services/permissions.ts",
-                    "api/src/middleware/validate-access.ts",
-                    "app/src/components/fields.vue",
-                ],
-                newEndpoints: [],
-                modifiedEndpoints: [],
-                affectedServices: ["items", "permissions"],
-            },
-        });
-        const prompt = buildRecommendationPrompt(analysis, AnalysisScope.CurrentBranchDiff, 6);
-        expect(prompt).toContain("Endpoint Discovery Required");
-        expect(prompt).not.toContain("UI-only PR");
-        expect(prompt).not.toContain("frontend-only PR — set **100% UI/E2E**");
-    });
-    it("correctly classifies as UI-only when only frontend files changed", () => {
-        const analysis = minimalAnalysis({
-            branchDiffContext: {
-                baseBranch: "main",
-                currentBranch: "feature/ui-tweak",
-                changedFiles: [
-                    "app/src/components/fields.vue",
-                    "app/src/views/settings.vue",
-                ],
-                newEndpoints: [],
-                modifiedEndpoints: [],
-                affectedServices: [],
-            },
-        });
-        const prompt = buildRecommendationPrompt(analysis, AnalysisScope.CurrentBranchDiff, 6);
-        expect(prompt).toContain("UI-only PR");
-        expect(prompt).not.toContain("Endpoint Discovery Required");
-    });
-    it("does not classify as UI-only when endpoints are directly detected", () => {
-        const analysis = minimalAnalysis({
-            branchDiffContext: {
-                baseBranch: "main",
-                currentBranch: "feature/new-route",
-                changedFiles: [
-                    "api/src/routes/items.ts",
-                    "app/src/components/fields.vue",
-                ],
-                newEndpoints: [{
-                        path: "/api/items",
-                        methods: [{ method: "POST", sourceFile: "api/src/routes/items.ts", interactionCount: 1 }],
-                    }],
-                modifiedEndpoints: [],
-                affectedServices: ["items"],
-            },
-        });
-        const prompt = buildRecommendationPrompt(analysis, AnalysisScope.CurrentBranchDiff, 6);
-        expect(prompt).not.toContain("UI-only PR");
-        expect(prompt).toContain("Mixed PR");
-    });
-    it("backend-only PR: no UI-only or Mixed classification in mode preamble", () => {
-        const analysis = minimalAnalysis({
-            branchDiffContext: {
-                baseBranch: "main",
-                currentBranch: "feature/add-endpoint",
-                changedFiles: [
-                    "api/src/routes/orders.ts",
-                    "api/src/services/orders.ts",
-                ],
-                newEndpoints: [{
-                        path: "/api/orders",
-                        methods: [{ method: "POST", sourceFile: "api/src/routes/orders.ts", interactionCount: 2 }],
-                    }],
-                modifiedEndpoints: [],
-                affectedServices: ["orders"],
-            },
-        });
-        const prompt = buildRecommendationPrompt(analysis, AnalysisScope.CurrentBranchDiff, 6);
-        // Mode preamble should NOT label this as UI-only or Mixed
-        expect(prompt).not.toContain("**UI-only PR**");
-        expect(prompt).not.toContain("**Mixed PR**");
-    });
-});

package/build/prompts/testbot/testbot-prompts.js

@@ -4,7 +4,7 @@ import { AnalyticsService } from "../../services/AnalyticsService.js";
 import { MAX_TESTS_TO_GENERATE, MAX_RECOMMENDATIONS, MAX_CRITICAL_TESTS, PATH_PARAM_UUID_GUIDANCE, AUTH_CONFLICT_ERROR_MSG, } from "../test-recommendation/recommendationSections.js";
 import { buildDriftAnalysisPrompt } from "../test-maintenance/drift-analysis-prompt.js";
 import { getTraceRecordingPromptText } from "../../playwright/traceRecordingPrompt.js";
-import { isContractConsumerModeEnabled, resolveServiceDetailsRef } from "../../utils/featureFlags.js";
+import { isContractConsumerModeEnabled } from "../../utils/featureFlags.js";
 import { readWorkspaceConfigRaw } from "../../utils/workspaceAuth.js";
 // Cached at module-load — the flag is process-wide and cannot change per call.
 const CONSUMER_MODE_ENABLED = isContractConsumerModeEnabled();
@@ -100,23 +100,16 @@ ${userPrompt ? "Generate only the tests that the user requested from the Additio
   Keep advancing until you have created exactly ${maxGenerate} new test files OR exhausted all candidates.
 - Example: If enrichment reveals that sending \`discount_value\` without \`discount_type\` silently orphans the value (a concrete bug), complete all planned GENERATE items first, then generate this discovered scenario as an extra test and report it in \`newTestsCreated\`.
 - Total generated: Follow the "Budget: N generate" line in the Execution Plan. Process every GENERATE-tagged item in order. Backfill from ADDITIONAL candidates (highest-ranked first) until \`newTestsCreated\` reaches ${maxGenerate} or all candidates are exhausted.
-- **Backend tests come first (MANDATORY):** All pre-ranked GENERATE items are backend tests (contract/integration). You MUST generate them before spending budget on UI tests. UI/E2E tests fill the Budget Plan's UI% allocation AFTER backend GENERATE items are complete — they do NOT replace backend tests.
-- **Backfill priority (MANDATORY):** When filling budget slots beyond the pre-ranked GENERATE items, follow this order strictly:
-  1. PR-endpoint edge cases — error paths (404, 422), auth boundary (401/403), validation for endpoints changed in this PR
-  2. Same-resource alternative flows — different HTTP methods or state variations on the same resource
-  3. Cross-resource workflows involving a PR endpoint
-  4. UI/E2E tests per your Budget Plan's UI% allocation
-  5. Unrelated endpoint coverage — NEVER backfill with tests for endpoints or pages not touched by this PR unless ALL options 1–4 are exhausted
-- **UI test generation** (only when Budget Plan allocates UI% > 0): Use \`browser_navigate\` to the app's base URL — if the app responds, record a trace and generate the test.
-  **Skip UI only if one of these conditions is met:**
+- **UI test priority**: If the diff contains frontend/UI changes (e.g. \`.tsx\`, \`.jsx\`, \`.vue\`, \`.svelte\` files), you MUST attempt to generate at least one UI test. Use \`browser_navigate\` to the app's base URL — if the app responds, record a trace and generate the test.
+  **Skip only if one of these conditions is met:**
   - **(a) App is unreachable** — \`browser_navigate\` fails or connection is refused.
-  - **(b) Budget Plan allocates 0% UI/E2E** (backend-only PR with no frontend files changed).
-  - **(c) Unintegrated non-route component** — the changed file is a leaf component (not a framework route/entrypoint) that has no integration point in the running app. To confirm:
+  - **(b) Unintegrated non-route component** — the changed file is a leaf component (not a framework route/entrypoint) that has no integration point in the running app. To confirm:
     1. Grep for the component's exported name AND its module path/filename across all production source files (excluding \`*.test.*\`, \`*.spec.*\`, \`*.stories.*\`, \`__tests__/\` directories — only production code imports count).
     2. If no production file imports, re-exports, or renders it, the component has no DOM node in the running app → unintegrated.
     3. **Exception**: if the same PR also adds a route/page file (e.g. under Next.js \`pages/\` or \`app/\`) that imports the component, the route IS the integration point — test through it.
   **Never** apply the unintegrated heuristic to framework route/entrypoint files themselves — those are always reachable by convention.
   **Never** generate tests for unrelated pages as a substitute for an unintegrated component.
+  This rule takes priority over generating additional backend-only tests.
 - **Always generate a test for critical bugs, even if it will fail.** When a GENERATE-tagged item targets a page or endpoint with a known bug, do NOT skip it because you expect the test to fail — a failing test that documents a bug is more valuable than a text-only description. This applies within the existing GENERATE budget; do not add extra tests beyond the plan.
    - For UI rendering bugs: navigate to the broken page and add a \`browser_assert\` that verifies the page rendered its expected content (e.g. assert the page heading is visible). The assertion will fail on the broken page, which is the correct outcome — it documents the bug as a failing test.
    - The assertion MUST target the broken page itself, not a different page that works. If \`/orders/{id}/edit\` crashes, assert on \`/orders/{id}/edit\` (e.g. "Edit Order" heading visible), NOT on \`/orders\`.
@@ -128,8 +121,8 @@ ${userPrompt ? "Generate only the tests that the user requested from the Additio
 - Critical-category tests are already ranked first by the pre-computed scores — follow the plan order.
 
 **Auth — determine ONCE, apply to EVERY tool call:**
-1. Read auth params from the Execution Plan returned by \`skyramp_analyze_changes\` — they are pre-resolved from ${resolveServiceDetailsRef().authSourceRef}. **Use these as-is; do not infer or override.**
-2. If workspace shows \`authType: none\` or \`authHeader: ""\` → proceed with no auth (\`authHeader: ""\`). If tests fail due to 401/403, add to \`issuesFound\`: "Auth may be required — update \`api.authType\` in ${resolveServiceDetailsRef().authSourceRef}."
+1. Read auth params from the Execution Plan returned by \`skyramp_analyze_changes\` — they are resolved directly from workspace.yml. **Use these as-is; do not infer or override.**
+2. If workspace shows \`authType: none\` or \`authHeader: ""\` → proceed with no auth (\`authHeader: ""\`). If tests fail due to 401/403, add to \`issuesFound\`: "Auth may be required — update \`api.authType\` in workspace.yml."
 3. **Auth params by header type — quick reference:**
 
    | \`authHeader\` | \`authType\` examples | \`skyramp_batch_scenario_*\` / \`skyramp_contract_*\` | \`skyramp_integration_test_generation\` (scenarioFile) |
@@ -140,7 +133,7 @@ ${userPrompt ? "Generate only the tests that the user requested from the Additio
    | none / \`""\` | \`none\` | \`authHeader: ""\` only when endpoint confirmed unauthenticated | \`authHeader: ""\` |
 
    **Omit \`authToken\` entirely** — \`SKYRAMP_PLACEHOLDER_TOKEN\` is auto-inserted at execution time.
-   The \`authScheme\` for \`Authorization\` headers is pre-resolved in the Execution Plan — use it exactly (e.g. \`"Bearer"\`, \`"Token"\`, or a custom scheme from ${resolveServiceDetailsRef().authSourceRef}).
+   The \`authScheme\` for \`Authorization\` headers is pre-resolved in the Execution Plan — use it exactly (e.g. \`"Bearer"\`, \`"Token"\`, or a custom scheme from \`api.authScheme\` in workspace.yml).
 
    Passing auth alongside workspace \`authType\` on \`skyramp_integration_test_generation\` causes "${AUTH_CONFLICT_ERROR_MSG}" — follow the table.
 4. Only pass \`authHeader: ""\` if you can confirm the endpoint is truly unauthenticated.
@@ -148,7 +141,7 @@ ${userPrompt ? "Generate only the tests that the user requested from the Additio
 **How to generate each type (for ADD):**
 - **Integration**: call \`skyramp_batch_scenario_test_generation\` with ALL steps in a single call (pass the \`steps\` array with method, path, requestBody, statusCode for each step). Then call \`skyramp_integration_test_generation\` with the returned scenario file.
   **Use the pre-built scenario JSON from the Execution Plan** — pass the steps array directly. Do NOT read source code models to construct request bodies if the plan already provides them.
-  Scenario JSON and test files go in ${resolveServiceDetailsRef().testDirRef}. Do NOT create a new \`tests/\` directory at the repo root — use that path. If not configured, default to the language-conventional location (e.g. \`src/test/java/...\` for Java, \`tests/\` for Python).
+  Scenario JSON and test files go in the \`testDirectory\` from \`workspace.yml\` (visible in the service context block at the top of this prompt). Do NOT create a new \`tests/\` directory at the repo root — use the path the workspace config specifies. If no \`testDirectory\` is configured, default to the language-conventional location (e.g. \`src/test/java/...\` for Java, \`tests/\` for Python).
   **Pipeline for speed**: Call ALL \`skyramp_batch_scenario_test_generation\` calls in one batch. When they return, call ALL \`skyramp_integration_test_generation\` calls in the next batch. Do NOT serialize per-scenario (batch→integration→batch→integration) — batch ALL scenarios first, then generate ALL integration tests.
 - **Contract**: call \`skyramp_contract_test_generation\` with \`endpointURL\`, \`method\`, and \`requestData\` for POST/PUT/PATCH.
   Pass \`apiSchema\` if an OpenAPI spec exists.
@@ -156,7 +149,6 @@ ${CONTRACT_MODE_GUIDANCE}
 - ${PATH_PARAM_UUID_GUIDANCE}
 - **UI**: First check for existing Playwright trace \`.zip\` files in the repo (Testbot scans recursively up to 5 directory levels — the per-service output directories, \`frontend/\`, \`public/\`, \`.skyramp/\`, or any subdirectory).
   If a relevant trace exists (covers the UI changes in this PR), use it directly with \`skyramp_ui_test_generation\` and \`modularizeCode: false\`.
-  **Output directory**: When calling \`skyramp_ui_test_generation\`, set \`outputDir\` to ${resolveServiceDetailsRef().frontendTestDirRef} — NOT \`.skyramp/\` (that directory is only for trace \`.zip\` files and workspace config).
   If NO relevant trace exists, **you MUST write out your full trace plan as text BEFORE calling \`browser_navigate\`**. Do not touch the browser until the plan is written.
 
   **Browser authentication (check BEFORE navigating)**: If \`<ui-credentials>\` appears in your context above, the app requires login. Parse the credentials — each line is \`username:password\`. Type the values verbatim (they are not encoded or escaped). Before navigating to ANY feature URL:

package/build/services/ScenarioGenerationService.js

@@ -1,6 +1,5 @@
 import { AUTH_PLACEHOLDER_TOKEN } from "../types/TestTypes.js";
 import { isAuthorizationHeaderName } from "../utils/workspaceAuth.js";
-import { inferExpectedStatus } from "../utils/httpDefaults.js";
 import { logger } from "../utils/logger.js";
 import fs from "fs";
 import path from "path";
@@ -125,7 +124,7 @@ ${JSON.stringify(traceRequest, null, 2)}
         }
         const timestamp = new Date().toISOString();
         const method = params.method;
-        const statusCode = params.statusCode ?? inferExpectedStatus(method);
+        const statusCode = params.statusCode ?? (method === "POST" ? 201 : method === "DELETE" ? 204 : 200);
         const requestBody = params.requestBody ||
             (method === "GET" || method === "DELETE" ? "" : "{}");
         const responseHeaders = params.responseHeaders

package/build/tools/generate-tests/generateBatchScenarioRestTool.js

@@ -57,7 +57,8 @@ export const stepSchema = z.object({
         .describe("JSON string of the expected response body"),
     statusCode: z
         .number()
-        .describe("Expected HTTP status code — determine from the source code (e.g. 200, 201, 204)."),
+        .optional()
+        .describe("Expected HTTP status code. Defaults: POST→201, DELETE→204, GET/PUT/PATCH→200."),
     responseHeaders: z
         .record(z.array(z.string()))
         .optional()
@@ -140,7 +141,7 @@ export function registerBatchScenarioTestTool(server) {
 This tool accepts AI-parsed structured parameters from a natural language scenario description. Analyze the scenario and provide structured parameters for all steps.
 1. **Dynamic context**: If \`skyramp_analyze_changes\` has already run and returned a \`sessionId\`, fetch endpoint detail before building each step: \`skyramp://analysis/{sessionId}/endpoints/{path}/{method}\`. This gives you exact request body fields, types, and required vs optional — use it instead of guessing from field names.
 2. **Endpoints**: Confirm each step's method + path exists as a real endpoint (from OpenAPI spec, source code routes, or skyramp_analyze_changes output). Do NOT invent paths.
-3. **HTTP Status Codes**: Determine expected HTTP status code per step from the source code — do not assume conventions.
+3. **Status codes**: Confirm expected status code per step (defaults: POST→201, DELETE→204, GET/PUT/PATCH→200 — note if non-standard).
 4. **Request bodies**: Identify each field and its source (schema / prior step response / user input). For GET/DELETE steps, confirm filters go in queryParams — NEVER in requestBody.
 5. **Chaining**: For steps that use an ID from a prior step, use the same concrete value in the path (e.g. \`/api/v1/orders/1\`) that will appear in the prior step's response body (e.g. \`{"id": 1}\`). The backend auto-detects chaining by matching values across step responses.
 6. **Echo-back fields**: Identify which request body fields will be returned unchanged in the response — these will need exact-value assertions in the generated test.
@@ -258,7 +259,7 @@ Call \`skyramp_integration_test_generation\` with the returned \`scenarioFile\`
                     type: "text",
                     text: `**Batch Scenario Generated — ${stepCount} steps**\n\n`
                         + `**Scenario:** ${params.scenarioName}\n`
-                        + `**Steps:**\n${steps.map((s, i) => `  ${i + 1}. ${s.method} ${s.path} → ${s.statusCode ?? ""}`).join("\n")}\n\n`
+                        + `**Steps:**\n${steps.map((s, i) => `  ${i + 1}. ${s.method} ${s.path} → ${s.statusCode ?? "default"}`).join("\n")}\n\n`
                         + `**File:** ${filePath}\n\n`
                         + `**Next:** Call \`skyramp_integration_test_generation\` with \`scenarioFile: "${filePath}"\``,
                 },

package/build/tools/generate-tests/generateBatchScenarioRestTool.test.js

@@ -9,7 +9,6 @@ describe("stepSchema — requestBody validation", () => {
         const result = stepSchema.safeParse({
             method: "POST",
             path: "/api/v1/products",
-            statusCode: 201,
             requestBody: JSON.stringify({ name: "Widget-123", price: 9.99 }),
         });
         expect(result.success).toBe(true);
@@ -18,7 +17,6 @@ describe("stepSchema — requestBody validation", () => {
         const result = stepSchema.safeParse({
             method: "POST",
             path: "/api/v1/products",
-            statusCode: 201,
             requestBody: "{}",
         });
         expect(result.success).toBe(false);
@@ -30,7 +28,6 @@ describe("stepSchema — requestBody validation", () => {
         const result = stepSchema.safeParse({
             method: "PATCH",
             path: "/api/v1/orders/1",
-            statusCode: 200,
             requestBody: "{}",
         });
         expect(result.success).toBe(false);
@@ -40,7 +37,6 @@ describe("stepSchema — requestBody validation", () => {
         const result = stepSchema.safeParse({
             method: "PUT",
             path: "/api/v1/products/1",
-            statusCode: 200,
             requestBody: "{}",
         });
         expect(result.success).toBe(false);
@@ -53,7 +49,6 @@ describe("stepSchema — requestBody validation", () => {
         const result = stepSchema.safeParse({
             method: "POST",
             path: "/api/v1/products",
-            statusCode: 201,
         });
         expect(result.success).toBe(true);
     });
@@ -62,7 +57,6 @@ describe("stepSchema — requestBody validation", () => {
         const result = stepSchema.safeParse({
             method: "POST",
             path: "/api/v1/products",
-            statusCode: 201,
             requestBody: "null",
         });
         expect(result.success).toBe(true); // null is not an empty object — not rejected
@@ -71,7 +65,6 @@ describe("stepSchema — requestBody validation", () => {
         const result = stepSchema.safeParse({
             method: "GET",
             path: "/api/v1/products/1",
-            statusCode: 200,
         });
         expect(result.success).toBe(true);
     });
@@ -79,7 +72,6 @@ describe("stepSchema — requestBody validation", () => {
         const result = stepSchema.safeParse({
             method: "DELETE",
             path: "/api/v1/products/1",
-            statusCode: 204,
         });
         expect(result.success).toBe(true);
     });
@@ -89,7 +81,6 @@ describe("stepSchema — requestBody validation", () => {
         const result = stepSchema.safeParse({
             method: "GET",
             path: "/api/v1/products",
-            statusCode: 200,
             requestBody: "{}",
         });
         expect(result.success).toBe(true);

package/build/tools/test-management/analyzeChangesTool.js

@@ -573,22 +573,17 @@ to produce a unified state file for the test health workflow.
                 }
             }
             // ── Step 9: Draft scenarios ──
-            // New and changed endpoints get minimal intent-marker scenarios (contract + integration
-            // for mutating methods) via draftMinimalScenarios. The LLM enriches these with
-            // prerequisite steps and error paths during source-code analysis. Removed endpoints
-            // are handled by the LLM from the diffContext.removedEndpoints signal.
+            // Only new endpoints are passed as "diff-direct" — draftDiffDirectScenarios
+            // generates success-oriented scenarios (200/201/204) which are wrong for
+            // removed endpoints. Removal coverage (verify-404) is handled by the LLM
+            // from the diffContext.removedEndpoints signal in the recommendation prompt.
             // Classified endpoints have full paths and concrete methods (no MULTI sentinels).
             const newEndpointsForDrafting = classifiedEndpoints?.newEndpoints.flatMap((ep) => ep.methods.map((m) => ({
                 method: m,
                 path: ep.path,
                 sourceFile: ep.sourceFile,
             }))) ?? [];
-            const changedEndpointsForDrafting = classifiedEndpoints?.changedEndpoints.flatMap((ep) => ep.methods.map((m) => ({
-                method: m,
-                path: ep.path,
-                sourceFile: ep.sourceFile,
-            }))) ?? [];
-            const codeInferredScenarios = draftScenariosFromEndpoints(skeletonEndpoints, newEndpointsForDrafting, changedEndpointsForDrafting);
+            const codeInferredScenarios = draftScenariosFromEndpoints(skeletonEndpoints, newEndpointsForDrafting);
             let allDraftedScenarios = codeInferredScenarios;
             if (traceResult && traceResult.userFlows.length > 0) {
                 const traceScenarios = traceResult.userFlows

package/build/types/TestRecommendation.js

@@ -24,8 +24,6 @@ const CATEGORIES = [
 export const SCENARIO_CATEGORIES = [...INTERNAL_CATEGORIES, ...CATEGORIES];
 /** Categories valid for tool submissions (excludes internal-only categories). */
 export const TEST_CATEGORIES = CATEGORIES;
-/** Numeric ordering for priority tiers (higher = more important). */
-export const PRIORITY_TIER_ORDER = { CRITICAL: 4, HIGH: 3, MEDIUM: 2, LOW: 1 };
 /** Priority assignment for each category. */
 export const CATEGORY_PRIORITY = {
     new_endpoint: "CRITICAL",

package/build/utils/featureFlags.js

@@ -32,28 +32,3 @@
 export function isContractConsumerModeEnabled() {
     return process.env.SKYRAMP_FEATURE_CONTRACT_CONSUMER_MODE === "1";
 }
-export function isTestbotMode() {
-    return process.env.SKYRAMP_FEATURE_TESTBOT === "1";
-}
-/**
- * Returns the prompt phrasing for where to find service details.
- *
- * - Testbot mode: references the `<services>` XML block injected at the top of the prompt.
- * - Normal MCP mode: references `.skyramp/workspace.yml`.
- */
-export function resolveServiceDetailsRef() {
-    if (isTestbotMode()) {
-        return {
-            testDirRef: "the `<output_dir>` from the `<services>` block",
-            frontendTestDirRef: "the **frontend** service's `<output_dir>` from the `<services>` block",
-            baseUrlRef: "the `<base_url>` from the `<services>` block",
-            authSourceRef: "the `<services>` block",
-        };
-    }
-    return {
-        testDirRef: "the `testDirectory` from `.skyramp/workspace.yml`",
-        frontendTestDirRef: "the **frontend** service's `testDirectory` from `.skyramp/workspace.yml`",
-        baseUrlRef: "the `api.baseUrl` from `.skyramp/workspace.yml`",
-        authSourceRef: "`.skyramp/workspace.yml`",
-    };
-}