@skyramp/mcp 0.0.31 → 0.0.32

package/build/tools/generateScenarioRestTool.js

@@ -0,0 +1,81 @@
+import { z } from "zod";
+import { ScenarioGenerationService } from "../services/ScenarioGenerationService.js";
+import { baseSchema } from "../types/TestTypes.js";
+const scenarioTestSchema = {
+    scenarioName: z
+        .string()
+        .describe("Name of the test scenario with multiple steps. Describe the complete workflow you want to test, including all actions and their sequence.KEEP IT SHORT AND DESCRIPTIVE AS USED FOR FILE NAME"),
+    apiSchema: z
+        .string()
+        .describe("MUST be absolute path (/path/to/openapi.json) to the OpenAPI/Swagger schema file or a URL to the OpenAPI/Swagger schema file (e.g. https://demoshop.skyramp.dev/openapi.json). Required for accurate API mapping."),
+    baseURL: z
+        .string()
+        .optional()
+        .describe("Base URL for the API endpoints (e.g., https://demoshop.skyramp.dev/api/v1). If not provided, will be extracted from the API schema."),
+    prompt: z.string().describe("The prompt user provided to generate the test"),
+    // AI-parsed parameters (required)
+    method: z
+        .string()
+        .describe("HTTP method (GET, POST, PUT, DELETE, etc.) parsed by AI from the scenario"),
+    path: z
+        .string()
+        .describe("API path (e.g., /api/v1/products, /api/v1/orders/{product_id}) parsed by AI from the scenario"),
+    // AI-parsed parameters (optional)
+    requestBody: z
+        .string()
+        .optional()
+        .describe("JSON string of the request body parsed by AI from the scenario"),
+    responseBody: z
+        .string()
+        .optional()
+        .describe("JSON string of the response body parsed by AI from the scenario"),
+    statusCode: z
+        .number()
+        .optional()
+        .describe("HTTP status code (e.g., 200, 201, 204) parsed by AI from the scenario"),
+    outputDir: baseSchema.shape.outputDir,
+};
+export function registerScenarioTestTool(server) {
+    server.registerTool("skyramp_scenario_test_generation", {
+        description: `Generate a single trace request from AI-parsed scenario parameters.
+
+This tool generates a single TraceRequest object using parameters that have been parsed by AI from a natural language scenario. The AI should analyze the scenario and provide structured parameters instead of relying on hardcoded parsing logic.
+
+**What it does:**
+1. **Accept AI-Parsed Data**: Takes structured parameters parsed by AI from natural language
+2. **Generate Trace Request**: Creates a single TraceRequest object with proper format
+3. **File Management**: Appends the request to an existing trace file or creates a new one
+4. **Dynamic Source**: IF DNS NAME IS PROVIDED, USE IT FOR SOURCE IP AND PORT
+
+**Output:**
+Returns a single TraceRequest object with:
+- Dynamic source IP and port
+- Destination host (extracted from API schema)
+- HTTP method and path (provided by AI)
+- Request and response bodies (provided by AI or generated)
+- Request and response headers
+- Status code and timestamp
+- Network details (port, scheme)
+
+**AI Responsibilities:**
+The AI should parse the natural language scenario and provide:
+- HTTP method (POST, GET, PUT, DELETE)
+- API path (e.g., /api/v1/products, /api/v1/products/{product_id})
+- Request body (JSON string, if applicable)
+- Response body (JSON string, if applicable)
+- Status code (optional, defaults based on method)
+- Entity details (name, price, quantity, ID as needed)
+
+**Requirements:**
+- Natural language scenario description
+- API schema (OpenAPI/Swagger file or URL) for destination extraction
+- AI-parsed HTTP method and path (required)
+- AI-parsed request/response bodies (optional)
+
+**Note:** This tool generates one request at a time. Call multiple times for multi-step scenarios.`,
+        inputSchema: scenarioTestSchema,
+    }, async (params) => {
+        const service = new ScenarioGenerationService();
+        return await service.parseScenario(params);
+    });
+}

package/build/tools/generateSmokeRestTool.js

@@ -1,10 +1,10 @@
-import { baseTestSchema } from "../types/TestTypes.js";
+import { baseTestSchema, TestType } from "../types/TestTypes.js";
 import { TestGenerationService, } from "../services/TestGenerationService.js";
 import z from "zod";
 // Concrete implementations for each test type
 export class SmokeTestService extends TestGenerationService {
     getTestType() {
-        return "smoke";
+        return TestType.SMOKE;
     }
     buildGenerationOptions(params) {
         return super.buildBaseGenerationOptions(params);

package/build/tools/generateUIRestTool.js

@@ -1,9 +1,9 @@
-import { baseSchema, languageSchema } from "../types/TestTypes.js";
+import { baseSchema, languageSchema, TestType, codeRefactoringSchema, } from "../types/TestTypes.js";
 import { z } from "zod";
 import { TestGenerationService, } from "../services/TestGenerationService.js";
 export class UITestService extends TestGenerationService {
     getTestType() {
-        return "ui";
+        return TestType.UI;
     }
     buildGenerationOptions(params) {
         const options = this.buildBaseGenerationOptions(params);
@@ -25,6 +25,7 @@ const uiTestSchema = {
     output: baseSchema.shape.output,
     outputDir: baseSchema.shape.outputDir,
     force: baseSchema.shape.force,
+    ...codeRefactoringSchema.shape,
 };
 export function registerUITestTool(server) {
     server.registerTool("skyramp_ui_test_generation", {

package/build/tools/modularizationTool.js

@@ -1,22 +1,29 @@
 import { z } from "zod";
-import { ModularizationService, } from "../services/ModularizationService.js";
 import { logger } from "../utils/logger.js";
+import { TestType } from "../types/TestTypes.js";
+import { ModularizationService, } from "../services/ModularizationService.js";
 const modularizationSchema = {
     testFile: z
         .string()
         .describe("The test file to process with modularization principles applied"),
     language: z.string().describe("The programming language of the test file"),
     testType: z
-        .string()
-        .describe("The type of test (ui, e2e, integration, api, etc.)"),
+        .enum([TestType.UI, TestType.E2E, TestType.INTEGRATION])
+        .describe("Specifies the type of test (UI, E2E, or Integration)"),
     prompt: z
         .string()
         .describe("The prompt or code content to process with modularization principles applied"),
 };
 export function registerModularizationTool(server) {
     server.registerTool("skyramp_modularization", {
-        description: `This tool applies modularization principles to structure and organize content, code, or responses in a logical, maintainable way.
-      After this step, review it for correctness. If errors remain, call skyramp_fix_errors`,
+        description: `Provides modularization instructions and test file content. YOU MUST immediately modularize the code and write it back to the file. The tool returns:
+1. Complete modularization instructions
+2. The current test file content
+3. Step-by-step requirements you must complete
+
+After modularization, if errors remain, call skyramp_fix_errors.
+
+CRITICAL: This tool expects you to complete the modularization by writing the refactored code back to the file.`,
         inputSchema: modularizationSchema,
         annotations: {
             keywords: [

package/build/tools/startTraceCollectionTool.js

@@ -44,7 +44,7 @@ For detailed documentation visit: https://www.skyramp.dev/docs/load-test/advance
                 .describe("List of hosts or patterns that should bypass proxy during tracing"),
             dockerNetwork: z
                 .string()
-                .default("")
+                .default("skyramp")
                 .describe("Docker network name to use for containerized trace collection"),
             dockerWorkerPort: z
                 .number()
@@ -71,9 +71,9 @@ For detailed documentation visit: https://www.skyramp.dev/docs/load-test/advance
         const client = new SkyrampClient();
         const generateOptions = {
             testType: "trace",
-            runtime: params.runtime ?? "docker",
-            dockerNetwork: params.dockerNetwork ?? "skyramp",
-            dockerWorkerPort: (params.dockerWorkerPort ?? 35142).toString(),
+            runtime: params.runtime,
+            dockerNetwork: params.dockerNetwork,
+            dockerWorkerPort: params.dockerWorkerPort.toString(),
             generateInclude: params.include,
             generateExclude: params.exclude,
             generateNoProxy: params.noProxy,

package/build/tools/stopTraceCollectionTool.js

@@ -1,7 +1,7 @@
 import { SkyrampClient } from "@skyramp/skyramp";
 import { closeProxyTerminal } from "../utils/proxy-terminal.js";
 import { z } from "zod";
-import { TELEMETRY_entrypoint_FIELD_NAME, } from "../utils/utils.js";
+import { TELEMETRY_entrypoint_FIELD_NAME } from "../utils/utils.js";
 import { logger } from "../utils/logger.js";
 import { baseSchema } from "../types/TestTypes.js";
 import { existsSync, mkdirSync } from "fs";
@@ -22,13 +22,15 @@ For detailed documentation visit: https://www.skyramp.dev/docs/load-test/advance
         inputSchema: {
             traceOutputFile: z
                 .string()
-                .describe("File name to save the trace output file (e.g., skyramp-traces.json). This file will contain the collected backend trace data"),
+                .default("skyramp_traces.json")
+                .describe("File name to save the trace output file (e.g., skyramp_traces.json). This file will contain the collected backend trace data"),
             playwrightEnabled: z
                 .boolean()
                 .describe("Whether Playwright was used for trace collection. Must match the setting used when starting trace collection"),
             playwrightOutput: z
                 .string()
-                .describe("File name to save the Playwright output file (e.g., playwright.zip). Only used when playwright is true"),
+                .default("skyramp_playwright.zip")
+                .describe("File name to save the Playwright output file (e.g., skyramp_playwright.zip). Only used when playwright is true"),
             outputDir: baseSchema.shape.outputDir,
             prompt: z
                 .string()
@@ -47,13 +49,17 @@ For detailed documentation visit: https://www.skyramp.dev/docs/load-test/advance
         const client = new SkyrampClient();
         try {
             const stopTraceOptions = {
-                output: params.traceOutputFile ?? "skyramp-traces.json",
+                output: params.traceOutputFile,
                 workerContainerName: "skyramp-trace-worker",
                 playwright: params.playwrightEnabled ?? false,
-                playwrightOutput: params.playwrightOutput ?? "playwright.zip",
+                playwrightOutput: params.playwrightOutput,
                 entrypoint: TELEMETRY_entrypoint_FIELD_NAME,
                 outputDir: params.outputDir,
             };
+            // remove playwright trace file if playwright is disabled
+            if (!params.playwrightEnabled) {
+                stopTraceOptions.playwrightOutput = "";
+            }
             // Check if output dir exists and if not create it.
             if (!existsSync(params.outputDir)) {
                 mkdirSync(params.outputDir, { recursive: true });

package/build/types/TestTypes.js

@@ -1,4 +1,14 @@
 import { z } from "zod";
+export var TestType;
+(function (TestType) {
+    TestType["SMOKE"] = "smoke";
+    TestType["FUZZ"] = "fuzz";
+    TestType["CONTRACT"] = "contract";
+    TestType["LOAD"] = "load";
+    TestType["INTEGRATION"] = "integration";
+    TestType["E2E"] = "e2e";
+    TestType["UI"] = "ui";
+})(TestType || (TestType = {}));
 export const languageSchema = z.object({
     language: z
         .string()
@@ -103,3 +113,13 @@ export const baseTestSchema = {
         .describe("Expected HTTP response status code (e.g., '200', '201', '404'). DO NOT ASSUME STATUS CODE IF NOT PROVIDED"),
     ...baseSchema.shape,
 };
+export const codeRefactoringSchema = z.object({
+    codeReuse: z
+        .boolean()
+        .default(false)
+        .describe("Whether to reuse existing code"),
+    modularizeCode: z
+        .boolean()
+        .default(false)
+        .describe("Whether to modularize the code"),
+});

package/build/utils/utils.js

@@ -12,6 +12,7 @@ export function IsValidKeyValueList(input) {
     const regex = /^([a-zA-Z0-9_-]+)(,([a-zA-Z0-9_-]+))*$/;
     return regex.test(input);
 }
+export const SKYRAMP_UTILS_HEADER = `Generated by Skyramp`;
 export function getPathParameterValidationError(requiredPathParams) {
     if (requiredPathParams.split(",").length > 1) {
         return (`Please specify values for the following required path parameters: \n` +
@@ -116,3 +117,21 @@ export function validateRequestData(value) {
     }
     return null;
 }
+const COMMENT_PREFIX_MAP = {
+    python: "#",
+    java: "//",
+    javascript: "//",
+    typescript: "//",
+};
+/**
+ * Generates a Skyramp header for generated files
+ * @param language The programming language for the file
+ * @returns The formatted header string
+ */
+export function generateSkyrampHeader(language) {
+    const now = new Date();
+    const timestamp = now.toISOString().replace("T", " ").replace("Z", "");
+    const timezone = now.toString().match(/\(([^)]+)\)$/)?.[1] || "UTC";
+    const commentPrefix = COMMENT_PREFIX_MAP[language] || "#";
+    return `${commentPrefix} ${SKYRAMP_UTILS_HEADER} on ${timestamp} ${timezone}\n\n`;
+}

package/build/utils/utils.test.js

@@ -1,5 +1,5 @@
 // @ts-ignore
-import { validateParams } from "./utils.js";
+import { validateParams, generateSkyrampHeader } from "./utils.js";
 describe("validateParams", () => {
     it("should return null for valid comma-separated key=value pairs", () => {
         const result = validateParams("foo=bar,baz=qux", "testField");
@@ -30,3 +30,36 @@ describe("validateParams", () => {
         expect(result?.content?.[0].text).toMatch(/key=value/);
     });
 });
+describe("generateSkyrampHeader", () => {
+    it("should generate correct header for Python", () => {
+        const header = generateSkyrampHeader("python");
+        expect(header).toMatch(/^# Generated by Skyramp v1\.2\.23 on/);
+        expect(header).toContain("\n\n");
+    });
+    it("should generate correct header for JavaScript", () => {
+        const header = generateSkyrampHeader("javascript");
+        expect(header).toMatch(/^\/\/ Generated by Skyramp v1\.2\.23 on/);
+        expect(header).toContain("\n\n");
+    });
+    it("should generate correct header for TypeScript", () => {
+        const header = generateSkyrampHeader("typescript");
+        expect(header).toMatch(/^\/\/ Generated by Skyramp v1\.2\.23 on/);
+        expect(header).toContain("\n\n");
+    });
+    it("should generate correct header for Java", () => {
+        const header = generateSkyrampHeader("java");
+        expect(header).toMatch(/^\/\/ Generated by Skyramp v1\.2\.23 on/);
+        expect(header).toContain("\n\n");
+    });
+    it("should generate correct header for unknown language", () => {
+        const header = generateSkyrampHeader("unknown");
+        expect(header).toMatch(/^# Generated by Skyramp v1\.2\.23 on/);
+        expect(header).toContain("\n\n");
+    });
+    it("should include timestamp in header", () => {
+        const header = generateSkyrampHeader("python");
+        // Check that the header contains a timestamp in the expected format
+        expect(header).toMatch(/on \d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}\.\d{3}/);
+        expect(header).toMatch(/Generated by Skyramp/);
+    });
+});

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@skyramp/mcp",
-  "version": "0.0.31",
+  "version": "0.0.32",
   "main": "build/index.js",
   "type": "module",
   "bin": {
@@ -42,7 +42,7 @@
   },
   "dependencies": {
     "@modelcontextprotocol/sdk": "^1.11.4",
-    "@skyramp/skyramp": "^1.2.23",
+    "@skyramp/skyramp": "^1.2.24",
     "@playwright/test": "^1.55.0",
     "dockerode": "^4.0.6",
     "zod": "^3.25.3"

package/build/prompts/modularization-prompts.js

@@ -1,281 +0,0 @@
-export function getModularizationPrompt(filePath, language) {
-    return `
-**CRITICAL: Refactor code with modularization principles. Respond with complete, modularized code only WITHOUT ERRORS AND WRITTEN BACK TO THE FILE ${filePath}**
-
-**CRITICAL: DO NOT CHANGE THE FUNCTIONALITY OF THE TESTS. ONLY MODULARIZE THE CODE.**
-
-**ABSOLUTELY FORBIDDEN: DO NOT CREATE ANY INTERFACES, CLASSES, TYPES, OR NEW DATA STRUCTURES. USE INLINE TYPES ONLY.**
-
-Only if NO existing function can be reused:
-1. Group related lines logically (e.g., login steps together) to improve readability and parameterize the test function(s) with meaningful parameters to make it more flexible.
-2. If functions are already modularized (like breakpoint_section_0, breakpoint_section_1), then rename them with meaningful names WITHOUT ANY OTHER CHANGES.
-3. KEEP CHANGES TO A MINIMUM. DO NOT MODIFY THE FUNCTIONALITY OF THE TESTS. ONLY MODULARIZE THE CODE.
-4. Parameterize the test function(s) with meaningful parameters to make it more flexible. Preserve the original order of code lines within each function.
-5. Only extract reusable logical sections into helper functions. Use inline parameter types instead of creating interfaces or type definitions.
-
-**IMPORT CLEANUP AFTER MODULARIZATION:**
-After applying modularization principles:
-1. **Analyze Remaining Imports**: Review all import statements at the top of the file
-2. **Identify Unused Imports**: Check which imported modules, functions, or classes are no longer referenced in the modularized code
-3. **Remove Unused Imports**: Delete any import statements that are not used in the final modularized code
-4. **Preserve Required Imports**: Keep all imports that are actually used by the modularized functions
-5. **Maintain Import Order**: Preserve the original ordering of remaining imports for consistency
-
-**IMPORT REMOVAL RULES:**
-- Only remove imports that are completely unused after modularization
-- Keep imports used by any function, even if usage decreased
-- Preserve imports for types used in function parameters (inline types)
-- Do not remove imports for testing frameworks or utilities
-- Maintain proper import syntax and formatting
-
-**LANGUAGE-SPECIFIC IMPORT HANDLING:**
-- **Python**: Remove unused import and from...import statements
-- **JavaScript/TypeScript**: Remove unused import and require() statements
-- **Java**: Remove unused import statements
-- **All Languages**: Preserve framework-specific imports (testing libraries, etc.)
-
-**CRITICAL CONSTRAINTS:**
-- NO interfaces, classes, types, or data structures
-- NO new test cases or logic
-- NO additional files
-- ONLY helper functions with inline types
-- PRESERVE original functionality exactly
-- REMOVE unused imports after modularization
-- DO NOT CREATE/UPDATE package.json or requirements.txt or pom.xml or build.gradle file
-
-**CRITICAL: If you skip any step, the modularization is incomplete. You MUST complete all steps before proceeding.FIX ERRORS IN MODULARIZED CODE USING skyramp_fix_errors TOOL**
-`;
-}
-export function getFixErrorsPrompt() {
-    return `
-**Fix errors in refactored code.**
-
-1. **Parameter Passing:** Identify functions using variables from outside scope (like 'page' object). Pass these as parameters.
-2. **Validate Correctness:** Ensure code is free of reference errors, undefined variables, runtime issues.
-3. **Import Paths:** Ensure import paths are correct and there are no circular imports.
-4. **Import Validation:** Ensure all remaining imports are necessary and no missing imports cause reference errors.
-5. **Unused Import Cleanup:** Verify that unused imports were properly removed without breaking functionality.
-6. **UI State Management:** Check for UI state conflicts, modal interference, or element interaction issues.
-7. **Sequential Operations:** Ensure UI operations don't interfere with each other when called in sequence.
-
-**IMPORT ERROR DEBUGGING:**
-- Check for missing imports that cause undefined reference errors
-- Verify that import removal didn't break existing functionality
-- Ensure all imported modules are actually available in the project
-- Confirm that import syntax is correct for the target language
-
-**CRITICAL CONSTRAINTS:**
-- DO NOT CREATE/UPDATE package.json or requirements.txt or pom.xml or build.gradle file
-- NEVER create dependency management files, even when linting errors suggest missing dependencies
-- Focus on fixing code errors within existing files only
-
-**KEY: Variables not defined within function scope MUST be passed as parameters.**
-**UI KEY: Helper functions that perform UI operations must be self-contained and not leave modals/dialogs open.**
-**IMPORT KEY: All imports must be either used in the code or properly removed.**
-**DEPENDENCY KEY: DO NOT create package.json, requirements.txt, or any dependency files regardless of linting errors.**
-`;
-}
-export function getModularizationPromptForUI(filePath, language) {
-    return `
-**CRITICAL: Refactor code with modularization principles. Respond with complete, modularized code only WITHOUT ERRORS AND WRITTEN BACK TO THE FILE ${filePath}**
-
-**CRITICAL: DO NOT CHANGE THE FUNCTIONALITY OF THE TESTS. ONLY MODULARIZE THE CODE.**
-
-**ABSOLUTELY FORBIDDEN: DO NOT CREATE ANY INTERFACES, CLASSES, TYPES, OR NEW DATA STRUCTURES. USE INLINE TYPES ONLY.**
-
-**COMMON UI TEST FAILURE: Many UI tests fail after modularization because navigation steps between similar operations are incorrectly moved into helper functions. This breaks the test flow and causes timeouts.**
-
-**COMMON CALCULATION FAILURE: UI tests fail when complex logic patterns (loops, conditionals, array handling) are incorrectly generalized in helper functions, causing wrong quantities, prices, or missing operations.**
-
-**COMMON SELECTOR FAILURE: UI tests fail when specific selectors are generalized into generic ones, causing wrong elements to be clicked.**
-
-**MANDATORY ANALYSIS BEFORE MODULARIZATION:**
-Before creating any helper functions, identify ALL critical patterns in the original test:
-- Look for patterns like: page.getByTestId("navbar-*").click()
-- Look for patterns like: page.goto()
-- Look for patterns like: page.goBack()
-- Look for complex loops with conditionals or null handling
-- Look for unique sequences that differ between similar operations
-- Look for specific selector chains that target exact elements
-- These MUST remain in the main test function in their EXACT original positions and logic
-
-**CRITICAL RULE: If the original test performs operations in a specific sequence with unique logic for each step, DO NOT generalize this into a loop or helper function. Keep the exact original sequence.**
-
-**SELECTOR PRESERVATION RULE: If the original test uses specific selector chains, DO NOT generalize them into generic selectors. Preserve the exact selector specificity.**
-
-STEPS:
-1. **PRESERVE EXACT UI SEQUENCE**: For UI TESTS, maintain the EXACT sequence of UI interactions. Do NOT extract steps that break the natural flow.
-2. **CAREFUL EXTRACTION**: Only extract helper functions for COMPLETE, REPEATABLE workflows that do NOT include navigation between different pages/sections and do NOT contain complex conditional logic.
-3. **PRESERVE UNIQUE STEPS**: If a workflow has unique steps (like clicking specific labels), DO NOT extract it into a generic helper function.
-4. **PRESERVE COMPLEX LOGIC**: If the original test has loops, conditionals, or array processing with unique patterns, DO NOT generalize these - keep them exactly as written.
-5. **PRESERVE SPECIFIC SELECTORS**: If the original test uses specific selector chains, maintain the exact same selectors in helper functions. Do not make them more generic.
-6. **RESPONSE PROMISES**: Maintain the exact timing of response promise creation and awaiting. Do not move these into helper functions unless the entire request-response cycle is contained.
-7. **PARAMETERIZATION**: When creating helper functions, ensure ALL required parameters (page, data objects, response promises) are passed correctly.
-8. **VALIDATION**: Each extracted function must work independently without relying on external scope variables.
-9. **PRESERVE ORIGINAL FLOW**: If the original code has different patterns for similar operations (like product creation), preserve those differences - they exist for a reason.
-10. **NAVIGATION PRESERVATION**: CRITICAL - If the original test has navigation steps between similar operations (like clicking "navbar-products" between product creations), these MUST be preserved in the main test flow, NOT moved into helper functions.
-
-**WHAT SHOULD BE EXTRACTED (SAFE TO EXTRACT):**
-- Simple form filling sequences within a single page/modal
-- Basic button clicking sequences within a single workflow that use the same specific selectors
-- Simple data entry that doesn't change page state
-- Basic assertions and validations within the same page context
-
-**WHAT SHOULD NEVER BE EXTRACTED (KEEP IN MAIN TEST):**
-- Navigation between pages (navbar clicks, page.goto)
-- Steps that change the overall page context
-- Sequences that span multiple pages or sections
-- Any step that affects where the user is in the application
-- Complex loops with conditionals or special handling
-- Operations with unique patterns that differ between similar workflows
-- Array processing with null handling or special indexing
-- Button clicks with complex selector chains that are unique to specific contexts
-
-**IMPORT CLEANUP AFTER MODULARIZATION:**
-After applying modularization principles:
-1. **Analyze Remaining Imports**: Review all import statements at the top of the file
-2. **Identify Unused Imports**: Check which imported modules, functions, or classes are no longer referenced in the modularized code
-3. **Remove Unused Imports**: Delete any import statements that are not used in the final modularized code
-4. **Preserve Required Imports**: Keep all imports that are actually used by the modularized functions
-5. **Maintain Import Order**: Preserve the original ordering of remaining imports for consistency
-
-**UI-SPECIFIC IMPORT CONSIDERATIONS:**
-- Preserve all Playwright/testing framework imports (page, expect, test, etc.)
-- Keep UI-specific utility imports even if usage appears reduced
-- Maintain browser-specific imports that may be needed for UI operations
-- Do not remove imports for UI components or page object models
-- Preserve imports for locators, selectors, and UI interaction utilities
-
-**IMPORT REMOVAL RULES FOR UI TESTS:**
-- Only remove imports that are completely unused after modularization
-- Keep imports used by any function, even if usage decreased
-- Preserve imports for types used in function parameters (inline types)
-- Do not remove imports for testing frameworks or utilities
-- Maintain proper import syntax and formatting
-- Be extra cautious with UI framework imports - they may be used in ways not immediately obvious
-
-**LANGUAGE-SPECIFIC UI IMPORT HANDLING:**
-- **Python**: Remove unused import and from...import statements, but keep pytest, playwright imports
-- **JavaScript/TypeScript**: Remove unused import and require() statements, but preserve @playwright/test imports
-- **Java**: Remove unused import statements, but keep testing framework imports
-- **All Languages**: Always preserve UI testing framework and browser automation imports
-
-**CRITICAL CONSTRAINTS:**
-- NO interfaces, classes, types, or data structures
-- DO NOT CREATE/UPDATE package.json or requirements.txt or pom.xml or build.gradle file
-- NO changes to the core UI interaction sequence
-- NO extraction of partial workflows that depend on external state
-- NO generalization of complex logic patterns into loops or helper functions
-- NO generalization of specific selectors into generic ones
-- ONLY extract COMPLETE, self-contained operations that occur within the same page context
-- PRESERVE original functionality exactly
-- DO NOT extract steps that have unique UI interactions
-- DO NOT move navigation steps (like navbar clicks) into helper functions - keep them in the main test flow
-- PRESERVE all navigation between similar operations exactly as in the original test
-- PRESERVE all specific selector chains exactly as in the original test
-- NAVIGATION STEPS MUST REMAIN IN THE MAIN TEST FUNCTION TO MAINTAIN PROPER PAGE STATE
-- COMPLEX LOGIC PATTERNS MUST REMAIN IN THE MAIN TEST FUNCTION TO MAINTAIN EXACT BEHAVIOR
-- SPECIFIC SELECTORS MUST BE PRESERVED TO ENSURE CORRECT ELEMENT TARGETING
-- REMOVE unused imports after modularization (following UI-specific import rules)
-
-**BEFORE SUBMITTING: Double-check that every navigation step, complex operation, and specific selector from the original test appears in the same position with the same logic in the main test function.**
-
-**CRITICAL: If you skip any step, the modularization is incomplete. You MUST complete all steps before proceeding.FIX ERRORS IN MODULARIZED CODE USING skyramp_fix_errors TOOL**
-`;
-}
-export function getFixErrorsPromptForUI() {
-    return `
-**Fix errors in refactored code.**
-
-**COMMON UI TEST TIMEOUT ERROR: Test timeouts often occur when navigation steps are incorrectly moved into helper functions, causing the page to be in the wrong state when trying to interact with elements.**
-
-**COMMON UI TEST CALCULATION ERROR: Order totals, quantities, or other calculated values may be incorrect if the original test's unique logic was incorrectly generalized in helper functions.**
-
-**COMMON UI TEST SELECTOR ERROR: Tests fail when specific selectors are replaced with generic ones, causing wrong elements to be clicked or interacted with.**
-
-**IMMEDIATE TIMEOUT DEBUGGING STEPS:**
-1. Compare the original test and modularized test side by side
-2. Identify every navigation step in the original (navbar clicks, page.goto, etc.)
-3. Verify each navigation step appears in the EXACT same position in the main test function
-4. If any navigation step was moved into a helper function, move it back to the main test
-
-**IMMEDIATE CALCULATION ERROR DEBUGGING STEPS:**
-1. Compare the exact sequence of operations in the original vs modularized test
-2. Check if helper functions are skipping steps that the original test performed
-3. Verify that loops and conditional logic in helper functions match the original exactly
-4. Look for cases where null/empty values in data arrays are handled differently
-
-**IMMEDIATE SELECTOR ERROR DEBUGGING STEPS:**
-1. Compare selectors in the original vs modularized test
-2. Check if specific selector chains were replaced with generic selectors
-3. Verify that helper functions use the same exact selectors as the original
-4. Look for cases where container-specific selectors were made too generic
-
-**DETAILED FIX STEPS:**
-1. **UI Sequence Validation**: Verify that the exact UI interaction sequence from the original test is preserved. Check for missing clicks, form openings, or navigation steps.
-2. **Navigation Step Preservation**: CRITICAL - Ensure all navigation steps between similar operations (like "navbar-products" clicks between product creations) are preserved in the main test flow, not moved into helper functions.
-3. **Page State Debugging**: If test is timing out on element interactions, check if the page is in the expected state. Often this means navigation steps were incorrectly extracted.
-4. **Logic Preservation**: If test has incorrect calculations or missing operations, check if helper functions are generalizing logic that should remain unique to each operation.
-5. **Selector Preservation**: If test is clicking wrong elements or failing to find elements, check if specific selectors were made too generic in helper functions.
-6. **Parameter Passing**: Identify functions using variables from outside scope (like 'page' object, response promises, test data). Pass these as parameters.
-7. **Response Promise Timing**: Ensure response promises are created and awaited at the exact same points as the original test.
-8. **Unique Workflow Preservation**: If the original test has unique steps for similar operations, ensure these are preserved and not generalized incorrectly.
-9. **Complete Workflow Validation**: Ensure that extracted helper functions contain COMPLETE workflows, not partial steps that depend on external state.
-10. **Page State Management**: Verify that helper functions don't assume specific page states - the main test should handle navigation between different pages/states.
-11. **Import Validation**: Ensure all remaining imports are necessary and no missing imports cause reference errors.
-12. **Unused Import Cleanup**: Verify that unused imports were properly removed without breaking UI test functionality.
-13. **UI Framework Import Preservation**: Ensure that critical UI testing imports (Playwright, testing frameworks) were not accidentally removed.
-14. **Validate Correctness**: Ensure code is free of reference errors, undefined variables, runtime issues.
-15. **Import Paths**: Ensure import paths are correct and there are no circular imports.
-
-**TIMEOUT DEBUGGING CHECKLIST:**
-- Are all navigation steps (navbar clicks, page.goto) in the main test function?
-- Do helper functions only contain self-contained operations without navigation?
-- Is the page in the expected state before each helper function call?
-- Are there any missing navigation steps between operations?
-- Compare line-by-line: does the main test flow match the original test flow exactly?
-
-**CALCULATION ERROR DEBUGGING CHECKLIST:**
-- Are all operations from the original test being performed in the modularized version?
-- Do helper functions handle null/empty values the same way as the original?
-- Are loops and conditionals in helper functions exact matches to the original logic?
-- Are quantities, prices, and other data values being processed identically?
-
-**SELECTOR ERROR DEBUGGING CHECKLIST:**
-- Are all selectors in helper functions exactly the same as in the original test?
-- Were any specific container-based selectors replaced with generic ones?
-- Do button clicks use the same selector specificity as the original?
-- Are there any ambiguous selectors that could match multiple elements?
-
-**IMPORT ERROR DEBUGGING CHECKLIST:**
-- Are there any undefined reference errors due to missing imports?
-- Were any critical UI framework imports (page, expect, test) accidentally removed?
-- Do all remaining imports correspond to actually used functionality?
-- Are import paths correct and accessible in the project structure?
-- Were any imports removed that are used in non-obvious ways (like in string templates)?
-
-**SPECIFIC FIX FOR COMMON ERRORS:**
-If you see timeout on button clicks or element interactions:
-- Check if navigation steps were moved into helper functions and move them back to main test
-- Check if specific selectors were made generic and restore original selector specificity
-- Verify the page is in the expected state before each interaction
-
-If you see incorrect calculations or missing operations:
-- Check if unique logic patterns were incorrectly generalized
-- Verify all operations from original test are present in modularized version
-- Look for null value handling differences
-
-If you see import or reference errors:
-- Check if critical UI framework imports were accidentally removed
-- Verify all remaining imports are necessary and properly used
-- Restore any imports needed for UI interactions, even if usage seems minimal
-- Confirm import paths match the project structure
-
-**KEY: Every UI interaction from the original test must be present in the modularized version.**
-**CRITICAL: Helper functions should only contain COMPLETE, self-contained workflows.**
-**NAVIGATION KEY: Navigation steps between operations must remain in the main test flow to maintain proper page state.**
-**CALCULATION KEY: Unique logic patterns should not be generalized if they produce different results.**
-**SELECTOR KEY: Specific selectors must be preserved to ensure correct element targeting.**
-**IMPORT KEY: All necessary imports must be preserved, especially UI framework imports.**
-`;
-}