@skyramp/mcp 0.0.60-rc.4 → 0.0.61

package/build/index.js

@@ -19,8 +19,8 @@ import { registerLoginTool } from "./tools/auth/loginTool.js";
 import { registerLogoutTool } from "./tools/auth/logoutTool.js";
 import { registerFixErrorTool } from "./tools/fixErrorTool.js";
 import { registerAnalyzeRepositoryTool } from "./tools/test-recommendation/analyzeRepositoryTool.js";
+import { registerMapTestsTool } from "./tools/test-recommendation/mapTestsTool.js";
 import { registerRecommendTestsTool } from "./tools/test-recommendation/recommendTestsTool.js";
-import { registerRecommendTestsPrompt } from "./prompts/test-recommendation/registerRecommendTestsPrompt.js";
 import { registerModularizationTool } from "./tools/code-refactor/modularizationTool.js";
 import { registerCodeReuseTool } from "./tools/code-refactor/codeReuseTool.js";
 import { registerScenarioTestTool } from "./tools/generate-tests/generateScenarioRestTool.js";
@@ -34,7 +34,6 @@ import { registerTestbotPrompt, registerTestbotResource, } from "./prompts/testb
 import { registerInitTestbotTool } from "./tools/initTestbotTool.js";
 import { registerSubmitReportTool } from "./tools/submitReportTool.js";
 import { registerInitializeWorkspaceTool } from "./tools/workspace/initializeWorkspaceTool.js";
-import { registerAnalysisResources } from "./resources/analysisResources.js";
 import { AnalyticsService } from "./services/AnalyticsService.js";
 import { initCheck } from "./utils/initAgent.js";
 const server = new McpServer({
@@ -48,43 +47,27 @@ const server = new McpServer({
         prompts: {
             listChanged: true,
         },
-        resources: {
-            listChanged: true,
-        },
     },
-    instructions: `Skyramp MCP Server — generates and executes API tests (fuzz, contract, integration, E2E, UI).
+    instructions: `Skyramp MCP Server — generates and executes API tests (smoke, fuzz, contract, load, integration, E2E, UI).
 
 ## Rules
 - NEVER show CLI commands. ALWAYS use the MCP tools provided.
 - For UI and E2E tests, use the trace collection start/stop tools.
 
-## Test Recommendation Flow (2-step)
-1. Call \`skyramp_analyze_repository\` → returns a \`sessionId\`.
-   The analysis scans source code (code-first) to build enriched endpoints
-   (Path → Method → Interaction with request/response bodies, headers, cookies)
-   and draft user-flow scenarios for integration/E2E tests.
-2. Call \`skyramp_recommend_tests\` with \`sessionId\` → the LLM reasons over the
-   enriched data to recommend tests, referencing specific interactions and scenarios.
-
-After analysis, you can also inspect data via MCP Resources:
-- \`skyramp://analysis/{sessionId}/summary\` — high-level overview
-- \`skyramp://analysis/{sessionId}/endpoints\` — compact endpoint listing
-- \`skyramp://analysis/{sessionId}/endpoints/{path}\` — full path detail
-- \`skyramp://analysis/{sessionId}/endpoints/{path}/{method}\` — single method detail
-- \`skyramp://analysis/{sessionId}/scenarios\` — drafted scenarios
-- \`skyramp://analysis/{sessionId}/diff\` — branch diff context
-
 ## Workspace Initialization (before ANY other Skyramp tool)
 Follow this flow EVERY time before calling any Skyramp tool:
 
-1. **Check**: Does .skyramp/workspace.yml exist at the workspace root?
-2. **If YES** → proceed with the requested tool.
-3. **If NO** → you MUST call \`skyramp_initialize_workspace\` BEFORE doing anything else.
-   - Do NOT skip this step. Do NOT proceed to the requested tool first.
-   - Scan the repo for ALL services (see the tool description for detailed steps).
-   - A fullstack or monorepo MUST produce multiple services — never just one.
-   - After workspace init completes, THEN proceed with the originally requested tool.
-4. **ONLY skip init if the user EXPLICITLY says** "no", "skip", "don't create workspace", or similar.
+1. **Check**: Is the workspace root a git repository? (i.e. does a \`.git\` directory exist at the root?)
+   - **If NO** → it is a non-git repo. Do NOT call \`skyramp_initialize_workspace\`. Proceed directly with the requested tool. STOP — do not continue to step 2.
+   - **If YES** → it is a git repo. Continue to step 2.
+2. **Check**: Does .skyramp/workspace.yml exist at the workspace root?
+   - **If YES** → workspace is already initialized. Proceed with the requested tool. STOP here.
+   - **If NO** → you MUST call \`skyramp_initialize_workspace\` BEFORE doing anything else.
+     - Do NOT skip this step. Do NOT proceed to the requested tool first.
+     - Scan the repo for ALL services (see the tool description for detailed steps).
+     - A fullstack or monorepo MUST produce multiple services — never just one.
+     - After workspace init completes, THEN proceed with the originally requested tool.
+3. **ONLY skip init in these two cases: non-git repo (step 1) or explicit user decline** (i.e. user EXPLICITLY says "no", "skip", "don't create workspace", or similar).
    - A request like "execute tests" or "generate tests" is NOT a signal to skip init.
    - If the user does decline, respect it — do NOT ask again, and proceed with the requested tool.
 
@@ -95,13 +78,8 @@ Before calling ANY test generation tool, you MUST follow this flow:
 2. **Extract** the \`language\`, \`framework\`, \`outputDir\`, and \`api.baseUrl\` from the services section.
 3. **Use those values** as defaults for the test generation tool call. Do NOT ask the user for these values if they are already configured in the workspace file.
 4. **CRITICAL — endpointURL**: The \`endpointURL\` parameter MUST be the full URL to the specific endpoint being tested, NOT just the base URL. Construct it by combining \`api.baseUrl\` with the endpoint path. Example: if \`api.baseUrl\` is \`http://localhost:8000\` and the endpoint is \`/api/v1/products\`, pass \`endpointURL: "http://localhost:8000/api/v1/products"\`. NEVER pass just the base URL (e.g. \`http://localhost:8000\`) as \`endpointURL\`.
-5. **CRITICAL — scenario generation**: When calling \`skyramp_scenario_test_generation\`, ALWAYS pass:
-   - \`baseURL\`: The full base URL from \`api.baseUrl\` (e.g., \`http://localhost:3000\`). This determines the scheme, host, and port in the generated trace. Without it, the trace defaults to https:443 which is almost always wrong for local development.
-   - \`authHeader\`: The auth header name from \`api.authHeader\` in the workspace config. Use \`Cookie\` for cookie/session-based auth (NextAuth, etc.), \`Authorization\` for Bearer tokens, \`X-API-Key\` for API keys. Without it, the trace defaults to \`Authorization: Bearer\` which breaks cookie-based apps.
-   - \`apiSchema\` is OPTIONAL — omit it for code-first apps without OpenAPI specs.
-6. **CRITICAL — integration test from scenario**: When calling \`skyramp_integration_test_generation\` with a \`scenarioFile\`, ALSO pass \`authHeader\` (same value as used in scenario generation). This tells the CLI which header to parameterize with the auth token. Without it, the generated test defaults to \`Authorization: Bearer\` regardless of what's in the trace.
-7. **If the workspace file does not exist**, or the needed values (language, framework, outputDir) are missing from the workspace config, ASK the user which language and framework they want before calling the tool.
-8. The user can always override workspace defaults by explicitly specifying values in their request.
+5. **If the workspace file does not exist**, or the needed values (language, framework, outputDir) are missing from the workspace config, ASK the user which language and framework they want before calling the tool.
+6. The user can always override workspace defaults by explicitly specifying values in their request.
 `,
 });
 // Check for first-time invocation after version update (runs in background, doesn't block)
@@ -141,7 +119,6 @@ const prompts = [
     registerTestGenerationPrompt,
     registerStartTraceCollectionPrompt,
     registerTestHealthPrompt,
-    registerRecommendTestsPrompt,
 ];
 if (process.env.SKYRAMP_FEATURE_TESTBOT === "1") {
     prompts.push(registerTestbotPrompt);
@@ -171,9 +148,8 @@ const codeQualityTools = [
 codeQualityTools.forEach((registerTool) => registerTool(server));
 // Register test recommendation tools
 registerAnalyzeRepositoryTool(server);
+registerMapTestsTool(server);
 registerRecommendTestsTool(server);
-// Register analysis resources (MCP Resources for enriched data access)
-registerAnalysisResources(server);
 // Register test maintenance tools
 registerDiscoverTestsTool(server);
 registerAnalyzeTestDriftTool(server);

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

@@ -0,0 +1,326 @@
+/**
+ * Repository Analysis Prompt
+ * Comprehensive prompt for analyzing code repositories
+ */
+export function getRepositoryAnalysisPrompt(repositoryPath, analysisScope = "full_repo", parsedDiff) {
+    const isDiffScope = analysisScope === "current_branch_diff";
+    return `
+Analyze this repository systematically using the guide below.
+
+REPOSITORY PATH: ${repositoryPath}
+ANALYSIS SCOPE: ${analysisScope}${isDiffScope ? " (focus on branch changes only)" : " (full repository)"}
+
+IMPORTANT OUTPUT FORMAT:
+- Return analysis as valid JSON matching the RepositoryAnalysis interface
+- Use empty arrays [] for unavailable data rather than omitting fields
+- Use "unknown" for unknown string values
+- Provide evidence (file paths, line numbers) where possible
+${isDiffScope ? '- MUST include the "branchDiffContext" field in the output JSON' : ""}
+
+## CRITICAL RULES
+- If user flows are defined in documentation explicitly, follow them strictly and do not generate new ones.
+${isDiffScope ? `- Do NOT run git commands — the diff has already been parsed by the tool
+- Still gather full repo context (tech stack, infra, auth, existing tests) for accurate scoring
+- For branchDiffContext, use the following pre-parsed metadata:
+  - currentBranch: "${parsedDiff?.currentBranch || "unknown"}"
+  - baseBranch: "${parsedDiff?.baseBranch || "main"}"
+  - changedFiles: [${parsedDiff?.changedFiles.map((f) => `"${f}"`).join(", ") || ""}]
+- For newEndpoints and modifiedEndpoints: use the pre-parsed endpoint information provided by the tool as the primary source of truth.
+  - You may refine this list using only the metadata and code/context that is explicitly included in this prompt.
+  - Do NOT attempt to scan or open additional repository files beyond what has been provided here.
+  - It is acceptable if some indirect or transitive impacts are not fully captured; do not speculate beyond the available information.
+  - When you adjust endpoints, clearly explain your reasoning based on the pre-parsed data and any in-prompt context.
+- affectedServices: treat the changed file paths as high-level hints about which services are likely impacted, but do not perform exhaustive dependency tracing beyond the information provided` : ""}
+
+# Repository Analysis Guide
+
+## 1. Initial Repository Analysis
+
+### Documentation
+Review documentation files for any project-specific details and instructions
+
+### Project Type
+Identify what kind of application this is:
+- REST API service
+- Frontend application (React/Vue/Angular)
+- Full-stack application
+- Library/SDK
+- CLI tool
+- Microservices
+- Other (describe)
+
+### Primary Technology Stack
+- **Language**: Identify the primary programming language(s)
+- **Framework**: Identify the main framework(s) used
+- **Key Dependencies**: List critical dependencies from package files
+
+### Main Purpose
+Describe what this application does in 1-2 sentences.
+
+### Business Logic
+- **Common User Flows**: How do users typically interact with this system?
+  - Infer from documentation, endpoint analysis, and code structure
+- **Common Data Flows**: How does data move through the system?
+- **Common Integration Patterns**: How does this system integrate with other services?
+
+## 2. Artifact Discovery
+
+### OpenAPI/Swagger Specifications
+**Search Patterns:**
+- \`**/*{openapi,swagger}*.{yaml,yml,json}\`
+- \`**/api-spec.{yaml,yml,json}\`
+- \`**/docs/**/*.{yaml,yml,json}\`
+
+**Extract:**
+- OpenAPI/Swagger version
+- Total endpoint count
+- Base URL(s)
+- Authentication schemes
+- Paths and operations
+
+### Playwright Recordings
+**Search Patterns:**
+- \`**/*.zip\` in \`/recordings/\`, \`/tests/\`, \`/e2e/\` directories
+
+### API Trace Files
+**Search Patterns:**
+- \`**/*trace*.json\` - JSON trace files
+- \`**/*.har\` - HAR (HTTP Archive) files
+- \`**/traces/**/*.json\` - Trace directories
+
+## 3. API Endpoint Discovery
+
+### If OpenAPI Spec Available
+- Parse all paths and operations
+- Extract: path, HTTP methods, authentication requirements, path parameters
+- Count total endpoints
+- Identify base URL from servers section
+- Detect authentication type (bearer, api_key, oauth2, basic)
+
+### If No OpenAPI Spec
+Scan code for route definitions based on framework:
+
+**Express (Node.js):**
+- Patterns: \`app.get(\`, \`app.post(\`, \`router.get(\`, \`router.post(\`
+
+**FastAPI (Python):**
+- Patterns: \`@app.get(\`, \`@router.post(\`, \`@app.put(\`
+
+**Spring (Java):**
+- Patterns: \`@GetMapping\`, \`@PostMapping\`, \`@RestController\`, \`@RequestMapping\`
+
+**Django (Python):**
+- Patterns: \`path(\`, \`url(\` in \`urls.py\` files
+
+**Flask (Python):**
+- Patterns: \`@app.route(\`, \`@blueprint.route(\`
+
+## 4. Authentication Analysis
+
+Investigate how the application handles authentication and authorization.
+
+### Look For:
+- Environment variables: \`API_KEY\`, \`TOKEN\`, \`SECRET\`, \`AUTH_\`, \`JWT_\`
+- Authentication middleware or decorators
+- JWT handling libraries
+- OAuth configuration files
+- API key validation logic
+- Session management
+
+### Identify:
+1. **Authentication Method**: Bearer token, API key, OAuth 2.0, Basic Auth, JWT, etc.
+2. **Configuration Location**: Where auth is configured (env files, config files, middleware)
+3. **Credential Setup**: How to set authentication credentials
+
+## 5. Infrastructure Analysis
+
+Analyze deployment and infrastructure configuration.
+
+### Containerization
+**Check for:**
+- \`Dockerfile\`
+- \`docker-compose.yml\`
+- \`.dockerignore\`
+
+### Orchestration
+**Kubernetes:**
+- Check for manifests in \`k8s/\`, \`kubernetes/\`, or \`.yaml\` files with \`kind: Deployment\`
+
+**Docker Compose:**
+- Check for multi-service setup
+
+### CI/CD
+**Identify platforms from config files:**
+- GitHub Actions: \`.github/workflows/\`
+- GitLab CI: \`.gitlab-ci.yml\`
+- Jenkins: \`Jenkinsfile\`
+- CircleCI: \`.circleci/config.yml\`
+- Travis CI: \`.travis.yml\`
+
+### Deployment Pattern Inference
+- **Microservices**: Kubernetes AND multiple services detected
+- **Full-stack**: Docker Compose AND both API and Frontend components detected
+- **Containerized Monolith**: Single Dockerfile only (no compose, no K8s)
+- **Traditional**: No container configurations found
+
+## 6. Existing Test Analysis
+
+Analyze the testing infrastructure and coverage.
+
+### Test Directory Detection
+**Search Patterns:**
+- \`**/test/**\`
+- \`**/tests/**\`
+- \`**/__tests__/**\`
+- \`**/spec/**\`
+
+**Count test files:**
+- \`**/*{.test,.spec}.{ts,js,tsx,jsx,py,java,go}\`
+
+### Test Framework Detection
+**Configuration Files:**
+- \`pytest.ini\`, \`setup.cfg\` (pytest)
+- \`jest.config.js\`, \`jest.config.ts\` (Jest)
+- \`karma.conf.js\` (Karma)
+- \`playwright.config.ts\` (Playwright)
+- \`cypress.config.js\` (Cypress)
+
+### Test Type Inference
+**File Name Patterns:**
+- **Unit Tests**: \`*unit*.{test,spec}\`, \`*.unit.*\`
+- **Integration Tests**: \`*integration*.{test,spec}\`, \`*.integration.*\`
+- **E2E Tests**: \`*e2e*.{test,spec}\`, \`*end-to-end*\`, \`*.e2e.*\`
+- **Smoke Tests**: \`*smoke*.{test,spec}\`
+- **Load Tests**: \`*load*.{test,spec}\`, \`*performance*\`
+
+## OUTPUT STRUCTURE
+
+Return a JSON object with this exact structure:
+
+\`\`\`json
+{
+  "metadata": {
+    "repositoryName": "name-from-path",
+    "analysisDate": "2025-10-15T14:30:00Z",
+    "scanDepth": "full",
+    "analysisScope": "${analysisScope}"
+  },
+  "projectClassification": {
+    "projectType": "rest-api | frontend | full-stack | microservices | library | cli | other",
+    "primaryLanguage": "language",
+    "primaryFramework": "framework",
+    "deploymentPattern": "microservices | full-stack | containerized-monolith | traditional | unknown"
+  },
+  "technologyStack": {
+    "languages": ["language1", "language2"],
+    "frameworks": ["framework1", "framework2"],
+    "runtime": "runtime version",
+    "keyDependencies": [
+      { "name": "dep1", "version": "1.0.0", "purpose": "description" }
+    ]
+  },
+  "businessContext": {
+    "mainPurpose": "1-2 sentence description",
+    "userFlows": ["flow1", "flow2"],
+    "dataFlows": ["flow1", "flow2"],
+    "integrationPatterns": ["pattern1", "pattern2"]
+  },
+  "artifacts": {
+    "openApiSpecs": [
+      {
+        "path": "./docs/openapi.yaml",
+        "version": "3.0.0",
+        "endpointCount": 18,
+        "baseUrl": "http://localhost:3000/api/v1",
+        "authType": "bearer"
+      }
+    ],
+    "playwrightRecordings": [],
+    "traceFiles": [
+      {
+        "path": "./traces/user-session.json",
+        "format": "json"
+      }
+    ],
+    "notFound": ["Playwright recordings"]
+  },
+  "apiEndpoints": {
+    "totalCount": 18,
+    "baseUrl": "http://localhost:3000/api",
+    "endpoints": [
+      {
+        "path": "/users",
+        "method": "GET",
+        "resourceGroup": "Users",
+        "authRequired": true,
+        "sourceFile": "src/routes/user.js:10"
+      }
+    ]
+  },
+  "authentication": {
+    "method": "bearer | api-key | oauth2 | basic | jwt | none",
+    "configLocation": "path/to/config",
+    "envVarsRequired": ["VAR1", "VAR2"],
+    "setupExample": "export API_KEY=value"
+  },
+  "infrastructure": {
+    "isContainerized": true,
+    "hasDockerCompose": true,
+    "hasKubernetes": false,
+    "hasCiCd": true,
+    "ciCdPlatform": "github-actions"
+  },
+  "existingTests": {
+    "frameworks": ["jest", "supertest"],
+    "coverage": {
+      "unit": 45,
+      "integration": 0,
+      "e2e": 0,
+      "ui": 0,
+      "load": 0,
+      "contract": 0,
+      "smoke": 0
+    },
+    "testLocations": {
+      "unit": "src/tests/unit/"
+    },
+    "hasCoverageReports": true,
+    "estimatedCoverage": 78
+  }${isDiffScope ? `,
+  "branchDiffContext": {
+    "currentBranch": "feature/my-feature",
+    "baseBranch": "main",
+    "changedFiles": ["src/routes/products.ts", "src/models/Product.ts"],
+    "newEndpoints": [
+      { "path": "/api/v1/products/search", "method": "GET", "sourceFile": "src/routes/products.ts:45" }
+    ],
+    "modifiedEndpoints": [
+      { "path": "/api/v1/products", "method": "POST", "sourceFile": "src/routes/products.ts:12" }
+    ],
+    "affectedServices": ["product-service"],
+    "summary": "Added product search endpoint and modified product creation validation"
+  }` : ""}
+}
+\`\`\`
+
+VALIDATION CHECKLIST:
+- [ ] Project type identified with evidence
+- [ ] All artifacts searched with file paths
+- [ ] API endpoints counted and categorized
+- [ ] Authentication method determined
+- [ ] Infrastructure flags verified
+- [ ] Existing tests catalogued${isDiffScope ? `
+- [ ] branchDiffContext.changedFiles matches the list provided above
+- [ ] branchDiffContext.modifiedEndpoints includes ALL endpoints whose behaviour changed — including those affected by model/schema/validator changes (trace: changed file → which models/types → which endpoints use them)
+- [ ] branchDiffContext.newEndpoints includes any brand-new routes added in the diff
+- [ ] branchDiffContext.summary describes what changed in plain English` : ""}
+
+**CRITICAL INSTRUCTIONS**:
+- Construct the complete RepositoryAnalysis JSON object.
+- DO NOT create any .md or documentation files.
+- Save the analysis JSON to the state file path provided in the tool response.
+- Then call \`skyramp_map_tests\` with the \`stateFile\` parameter (NOT analysisReport) to avoid serialization issues.
+
+Begin analysis now.
+`;
+}