@skyramp/mcp 0.0.40 → 0.0.41

package/build/prompts/code-reuse.js

@@ -36,7 +36,7 @@ export function getCodeReusePrompt(testFile, language) {
 - Example: Multiple sequences of \`await page.fill()\`, \`await page.click()\` directly in test body
 - These patterns should NOT be extracted during code reuse - that's what modularization is for
 
-🚨 **CODE REUSE ≠ REFACTORING** 🚨
+** CODE REUSE ≠ REFACTORING**
 - Code reuse = Finding EXISTING helper functions and reusing them
 - Refactoring = Creating NEW helper functions from patterns (handled by modularization tool)
 
@@ -64,40 +64,40 @@ Use the Grep tool to search for other test files containing "${SKYRAMP_UTILS_HEA
 - Output mode: "files_with_matches"
 **CRITICAL: Exclude ${testFile} from the results** - only look at OTHER test files, not the current file.
 
-🚨 **STOP HERE IF NO OTHER TEST FILES FOUND** 🚨
+**STOP HERE IF NO OTHER TEST FILES FOUND**
 **IF NO OTHER TEST FILES ARE FOUND, SKIP TO STEP 6 - DO NOT CREATE ANY UTILS FILES.**
 
 If other test files are found, read those files and look for ALREADY DEFINED helper functions with clear function signatures.
 
 **How to identify helper functions in other test files:**
-✅ HELPER FUNCTION (move to utils):
+ HELPER FUNCTION (move to utils):
    - Has function signature: \`async function doSomething(params) { ... }\`
    - Can be called multiple times with different parameters
    - Example: \`async function fillProductForm(page, product) { ... }\`
 
-❌ NOT A HELPER FUNCTION (do not extract):
+NOT A HELPER FUNCTION (do not extract):
    - Just repetitive inline test code in test body
    - No function definition/signature
    - Example: Multiple \`await page.getByTestId("xyz").click()\` directly in test
 
-🚨 **IF OTHER TEST FILES ONLY CONTAIN REPETITIVE PATTERNS (NO ACTUAL HELPER FUNCTIONS), SKIP TO STEP 6** 🚨
-🚨 **IF OTHER TEST FILES ARE ESSENTIALLY IDENTICAL TO CURRENT FILE, SKIP TO STEP 6** 🚨
+**IF OTHER TEST FILES ONLY CONTAIN REPETITIVE PATTERNS (NO ACTUAL HELPER FUNCTIONS), SKIP TO STEP 6**
+**IF OTHER TEST FILES ARE ESSENTIALLY IDENTICAL TO CURRENT FILE, SKIP TO STEP 6**
 
 ## STEP 5: IF LOCAL HELPERS ARE FOUND IN STEP 4 THAT CAN BE REUSED in ${testFile}, MOVE THOSE LOCAL HELPERS TO UTILS SOURCE FILES AND USE THEM
 
-🚨 **ONLY PROCEED WITH STEP 5 IF ALL CONDITIONS ARE MET:** 🚨
-- ✅ You found OTHER test files in STEP 4 (not just ${testFile})
-- ✅ Those test files contain ACTUAL HELPER FUNCTIONS with function signatures (not just repetitive patterns)
-- ✅ The helper functions are ALREADY IMPLEMENTED and working in those OTHER test files
-- ✅ The helper functions are DIFFERENT from the current file (not just identical patterns)
+**ONLY PROCEED WITH STEP 5 IF ALL CONDITIONS ARE MET:**
+- You found OTHER test files in STEP 4 (not just ${testFile})
+- Those test files contain ACTUAL HELPER FUNCTIONS with function signatures (not just repetitive patterns)
+- The helper functions are ALREADY IMPLEMENTED and working in those OTHER test files
+- The helper functions are DIFFERENT from the current file (not just identical patterns)
 
-🚨 **IF ANY CONDITION IS NOT MET, SKIP TO STEP 6 - DO NOT CREATE ANY UTILS FILES.** 🚨
+**IF ANY CONDITION IS NOT MET, SKIP TO STEP 6 - DO NOT CREATE ANY UTILS FILES.**
 
 **Examples of when to SKIP STEP 5:**
-- ❌ Other test files have identical repetitive code but no helper functions
-- ❌ Other test files are generated from same template and look identical
-- ❌ You see patterns but no actual function definitions
-- ❌ You would need to CREATE new functions to extract the patterns
+- Other test files have identical repetitive code but no helper functions
+- Other test files are generated from same template and look identical
+- You see patterns but no actual function definitions
+- You would need to CREATE new functions to extract the patterns
 
 **CRITICAL:** For helpers found in STEP 4:
 1. **CREATE** \`${fileName}\` file if it doesn't exist with the following header:
@@ -111,8 +111,8 @@ If other test files are found, read those files and look for ALREADY DEFINED hel
 5. **IMPORT** those local helper functions from \`${fileName}\` into ${testFile}
 6. **REPLACE** duplicate code in ${testFile} with calls to imported helper functions WITHOUT MAKING ANY OTHER CHANGE.
 
-🚨 **CRITICAL: DO NOT CREATE UNNECESSARY HELPER FUNCTIONS** 🚨
-🚨 **DO NOT CREATE HELPERS BASED ON PATTERNS IN THE CURRENT FILE** 🚨
+**CRITICAL: DO NOT CREATE UNNECESSARY HELPER FUNCTIONS** 
+**DO NOT CREATE HELPERS BASED ON PATTERNS IN THE CURRENT FILE** 
 
 ## STEP 6: VERIFY AND VALIDATE
 1. **BEFORE** making any changes, read the original test file and identify ALL helper functions
@@ -126,8 +126,8 @@ If other test files are found, read those files and look for ALREADY DEFINED hel
 9. **NEVER** refactor, reorganize, or restructure existing source test files beyond moving helpers
 10. **RUN TESTS** to ensure functionality is preserved after refactoring
 
-🚨 **FINAL REMINDER: DO NOT CREATE HELPER FUNCTIONS FROM SCRATCH** 🚨
-🚨 **ONLY MOVE EXISTING HELPERS FROM OTHER TEST FILES** 🚨
+**FINAL REMINDER: DO NOT CREATE HELPER FUNCTIONS FROM SCRATCH** 
+**ONLY MOVE EXISTING HELPERS FROM OTHER TEST FILES** 
 
 **IMPORTANT NOTES:**
 - The process is designed to REUSE existing helper functions, not create new ones

package/build/prompts/modularization/integration-test-modularization.js

@@ -29,10 +29,11 @@ Look for API calls that repeat 2+ times with IDENTICAL structure but different d
 **CRITICAL RULES:**
 1. **EXACT CODE COPY** - Copy the API call code EXACTLY as-is from the original test
 2. **ONLY ADD PARAMETERS** - The ONLY change allowed is converting hardcoded values to parameters
-3. **NO LOGIC CHANGES** - Do not modify conditions, validations, or assertions
-4. **NO DATA CHANGES** - Do not change any request/response values or expected results
-5. **PRESERVE PATH PARAMETERS** - API path parameters must be passed as function parameters
-6. **PRESERVE ORDER** - Keep all operations in the exact same order
+3. **NEVER GENERALIZE SELECTORS** - Keep all selectors/locators exactly as they are in the original code (do not refactor into dynamic template strings)
+4. **NO LOGIC CHANGES** - Do not modify conditions, validations, or assertions
+5. **NO DATA CHANGES** - Do not change any request/response values or expected results
+6. **PRESERVE PATH PARAMETERS** - API path parameters must be passed as function parameters
+7. **PRESERVE ORDER** - Keep all operations in the exact same order
 
 **PARAMETER CONVERSION RULES:**
 - Find the values that DIFFER between repetitions (e.g., user IDs, product names)
@@ -57,12 +58,13 @@ async function getUser(userId: number) {
 \`\`\`
 
 **WHAT NOT TO DO:**
-❌ Changing API endpoints
-❌ Modifying expected status codes
-❌ Changing request/response validation
-❌ Reordering operations
-❌ "Improving" error handling
-❌ Adding new assertions
+Generalizing or refactoring selectors into dynamic templates
+Changing API endpoints
+Modifying expected status codes
+Changing request/response validation
+Reordering operations
+"Improving" error handling
+Adding new assertions
 
 ## STEP 4: USE HELPERS WITH EXACT SAME DATA
 When calling the helpers, use the EXACT same values from the original test.

package/build/prompts/modularization/ui-test-modularization.js

@@ -20,8 +20,8 @@ Read ${filePath} completely and identify:
 
 **IF CODE IS ALREADY MODULARIZED** (has functions like \`breakpoint_section_0\`, \`breakpoint_section_1\`):
 1. **RENAME** functions with meaningful names that describe what they do
-   - ❌ BAD: \`breakpoint_section_0\`, \`breakpoint_section_1\`
-   - ✅ GOOD: \`createProduct\`, \`editProductPrice\`, \`createOrder\`
+   - BAD: \`breakpoint_section_0\`, \`breakpoint_section_1\`
+   - GOOD: \`createProduct\`, \`editProductPrice\`, \`createOrder\`
 2. **PARAMETERIZE** hardcoded values in these functions
 3. **DO NOT** change the function logic or structure
 4. **DO NOT** create new functions - work with existing ones
@@ -51,11 +51,15 @@ Extract code in TWO scenarios:
 
 **CRITICAL - AVOID BUGS:**
 - Copy the code block EXACTLY as-is from the original test
+- **NEVER generalize selectors** - Keep selectors exactly as they are in the original code
+  - CORRECT: \`await page.getByTestId("product-Product-2-price").toContainText("$444.00")\`
+  - WRONG: \`await page.getByTestId("product-\${name}-price").toContainText("$\${price}.00")\`
+  - DO NOT refactor hardcoded selectors into dynamic template strings with variables
 - **VERIFY ALL field mappings** - EVERY \`.fill()\` must use the correct parameter
-  - ✅ CORRECT: quantity field → \`.fill(quantity.toString())\`
-  - ❌ WRONG: quantity field → \`.fill("12")\` then \`.fill(quantity.toString())\` - remove hardcoded "12"!
-  - ❌ WRONG: name field → \`.fill(description)\` - fields must match their data!
-- **Replace ALL hardcoded values with parameters** - No leftover hardcoded fills
+  - CORRECT: quantity field → \`.fill(quantity.toString())\`
+  - WRONG: quantity field → \`.fill("12")\` then \`.fill(quantity.toString())\` - remove hardcoded "12"!
+  - WRONG: name field → \`.fill(description)\` - fields must match their data!
+- **Replace ALL hardcoded values with parameters** - No leftover hardcoded fills (selectors are the ONLY exception: selectors must remain exactly as in the original code)
 - **NEVER create new conditional logic** (no ternaries, no if/else, no loops to derive parameter values)
 - **NEVER add logic that wasn't in the original code**
 - Keep ALL existing logic, calculations, and assertions unchanged
@@ -63,16 +67,16 @@ Extract code in TWO scenarios:
 
 **PARAMETERIZATION BEST PRACTICES:**
 1. **Use individual parameters, not data objects** - Makes helper usage clearer
-   - ✅ GOOD: \`createProduct(page, name, price, category)\`
-   - ❌ BAD: \`createProduct(page, productData)\` - unclear what fields are needed
+   - GOOD: \`createProduct(page, name, price, category)\`
+   - BAD: \`createProduct(page, productData)\` - unclear what fields are needed
 
 2. **Avoid nested helpers** - Keep helpers flat and independent
-   - ✅ GOOD: One helper does the complete operation
-   - ❌ BAD: Helper calls another helper - adds complexity
+   - GOOD: One helper does the complete operation
+   - BAD: Helper calls another helper - adds complexity
 
 3. **No duplicate helpers** - If you have 2+ helpers doing similar things, consolidate them
-   - ✅ GOOD: One \`createOrder(email, items)\` handles both simple and complex orders
-   - ❌ BAD: \`createSimpleOrder\` and \`createOrderWithItems\` - consolidate into one
+   - GOOD: One \`createOrder(email, items)\` handles both simple and complex orders
+   - BAD: \`createSimpleOrder\` and \`createOrderWithItems\` - consolidate into one
    - Exception: Keep separate if it significantly improves readability
 
 4. **For repetitive code**: Only parameterize values that DIFFER between occurrences
@@ -92,13 +96,13 @@ Extract code in TWO scenarios:
 
 **WRONG - Bad practices:**
 \`\`\`typescript
-// ❌ DON'T DO THIS - Adding conditional logic to handle multiple cases
+// DON'T DO THIS - Adding conditional logic to handle multiple cases
 async function addItem(page, index: number) {
   const name = index === 1 ? "item1" : index === 2 ? "item2" : "item3";
   await page.fill("#name", name);
 }
 
-// ❌ DON'T DO THIS - Duplicate actions
+// DON'T DO THIS - Duplicate actions
 async function createProduct(page, name) {
   await page.click("#add-button");  // Helper clicks button
   // ... rest of product creation
@@ -107,7 +111,7 @@ async function createProduct(page, name) {
 await page.click("#add-button");  // Test ALSO clicks button - DUPLICATE!
 await createProduct(page, "item1");
 
-// ❌ DON'T DO THIS - Multiple helpers for same operation
+// DON'T DO THIS - Multiple helpers for same operation
 async function createSimpleOrder(...) { }
 async function createOrderWithItems(...) { }
 // Should be ONE helper: createOrder(page, email, items)
@@ -115,12 +119,12 @@ async function createOrderWithItems(...) { }
 
 **RIGHT - Good practices:**
 \`\`\`typescript
-// ✅ CORRECT - Extract with parameter, no new logic
+// CORRECT - Extract with parameter, no new logic
 async function addItem(page, name: string) {
   await page.fill("#name", name);  // Replace literal with parameter
 }
 
-// ✅ CORRECT - Call helper for EACH original occurrence
+// CORRECT - Call helper for EACH original occurrence
 await addItem(page, "item1");
 await addItem(page, "item2");
 await addItem(page, "item3");

package/build/services/TestGenerationService.js

@@ -38,7 +38,7 @@ export class TestGenerationService {
             if (params.codeReuse) {
                 // Only code reuse
                 postGenerationMessage += `
-✅ Test generated successfully!
+ Test generated successfully!
 
 ⏭️**CRITICAL NEXT STEP**: Running code reuse analysis with skyramp_reuse_code tool.
 `;
@@ -46,7 +46,7 @@ export class TestGenerationService {
             else if (params.modularizeCode) {
                 // Only modularization
                 postGenerationMessage += `
-✅ Test generated successfully!
+ Test generated successfully!
 
 ⏭️**CRITICAL NEXT STEP**: Running modularization with skyramp_modularization tool.
 `;

package/build/tools/executeSkyrampTestTool.js

@@ -5,7 +5,7 @@ import { Writable } from "stream";
 import { logger } from "../utils/logger.js";
 import { stripVTControlCharacters } from "util";
 import fs from "fs";
-const EXECUTOR_DOCKER_IMAGE = "skyramp/executor:v1.2.30";
+const EXECUTOR_DOCKER_IMAGE = "skyramp/executor:v1.2.31";
 const DOCKER_PLATFORM = "linux/amd64";
 export function registerExecuteSkyrampTestTool(server) {
     server.registerTool("skyramp_execute_test", {

package/build/tools/trace/startTraceCollectionTool.js

@@ -88,6 +88,17 @@ For detailed documentation visit: https://www.skyramp.dev/docs/load-test/advance
         };
         try {
             const result = await client.generateRestTest(generateOptions);
+            if (result.toLowerCase().includes("failed")) {
+                return {
+                    content: [
+                        {
+                            type: "text",
+                            text: `Trace collection failed: ${result}`,
+                        },
+                    ],
+                    isError: true,
+                };
+            }
             await openProxyTerminalTracked();
             return {
                 content: [

package/package.json

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