@skyramp/mcp 0.0.59 → 0.0.60-rc.2

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

@@ -1,326 +0,0 @@
-/**
- * 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.
-`;
-}

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

@@ -1,266 +0,0 @@
-import { BASE_SCORES, CONTEXT_RULES } from "../../types/TestMapping.js";
-/**
- * Test Mapping Prompt
- * Prompt for calculating test priority scores
- */
-export function getTestMappingPrompt(analysis) {
-    return `
-Calculate priority scores for Skyramp test types based on repository analysis results and the test definitions below.
-
-## CRITICAL RULES
-- Do not suggest test scenarios at this stage.
-
-# Skyramp Test Types & Requirements
-
-Skyramp offers comprehensive testing capabilities across multiple test types. 
-Each test type serves specific purposes and requires different inputs for generation.
-
-## 1. Smoke Tests (Base Score: ${BASE_SCORES.smoke})
-
-**Purpose**: Quickly verify that an endpoint is accessible and returns a valid response. Ideal for identifying critical defects after significant changes.
-
-**Required Inputs**:
-- **OpenAPI Schema** (JSON/YAML) - API specification file
-- **Sample Request Data** (Optional) - JSON blob or file for request body
-- **Endpoint URL** - Target endpoint to test
-- **HTTP Method** (Optional) - Specific method to test
-
-**Use Cases**: 
-- Post-deployment verification
-- Quick health checks
-- Critical path validation
-
-## 2. Contract Tests (Base Score: ${BASE_SCORES.contract})
-
-**Purpose**: Ensure services adhere to agreed-upon API contracts, preventing integration issues between services.
-
-**Required Inputs**:
-- **OpenAPI Schema** (JSON/YAML) - API specification file
-- **Endpoint URL** - Target endpoint to test
-- **Response Validation** (Optional) - Expected response structure
-
-**Use Cases**:
-- API compatibility validation
-- Service contract enforcement
-- Breaking change detection
-
-## 3. Fuzz Tests (Base Score: ${BASE_SCORES.fuzz})
-
-**Purpose**: Identify vulnerabilities and unexpected behaviors by sending random or invalid data to the application.
-
-**Required Inputs**:
-- **OpenAPI Schema** (JSON/YAML) - API specification file
-- **Endpoint URL** - Target endpoint to test
-- **Fuzz Parameters** (Optional) - Custom fuzzing configuration
-
-**Use Cases**:
-- Security vulnerability testing
-- Input validation verification
-- Edge case discovery
-
-## 4. Integration Tests (Base Score: ${BASE_SCORES.integration})
-
-**Purpose**: Verify that different components of a system work together as expected, ensuring reliable data flow and system behavior.
-
-**Required Inputs**:
-- **OpenAPI Schema** (JSON/YAML) - API specification file
-- **Endpoint URL** - Target endpoint to test
-- **Integration Scenarios** (Optional) - Specific integration flows
-
-**Use Cases**:
-- Microservices integration
-- Database connectivity testing
-- External API integration
-
-## 5. Load Tests (Base Score: ${BASE_SCORES.load})
-
-**Purpose**: Assess performance and scalability under various load conditions.
-
-**Required Inputs**:
-- **OpenAPI Schema** (JSON/YAML) - API specification file
-- **Endpoint URL** - Target endpoint to test
-- **Load Parameters**: 
-  - \`--load-duration\` (default: 5 seconds)
-  - \`--load-num-threads\` (default: 1)
-  - \`--load-target-rps\` (requests per second)
-  - \`--load-rampup-duration\` (gradual load increase)
-
-**Use Cases**:
-- Performance benchmarking
-- Scalability assessment
-- Stress testing
-
-## 6. UI Tests (Base Score: ${BASE_SCORES.ui})
-
-**Purpose**: Validate user interface functionality and user experience.
-
-**Required Inputs**:
-- **Playwright Recording** - ZIP file containing UI interaction traces
-- **Browser Context** (Optional) - Specific browser/device configurations
-
-**Use Cases**:
-- User workflow validation
-- Cross-browser compatibility
-- UI regression testing
-
-## 7. End-to-End (E2E) Tests (Base Score: ${BASE_SCORES.e2e})
-
-**Purpose**: Test complete application flow from start to finish, ensuring all integrated components function as expected.
-
-**Required Inputs**:
-- **Trace File** - JSON file containing API interactions
-- **Playwright Recording** - ZIP file containing UI interactions
-- **Integration Scenarios** - Complete user journey definitions
-
-**Use Cases**:
-- Complete user journey testing
-- Full-stack integration validation
-- Business process verification
-
-## Test Type Priority Hierarchy (Base Impact Score)
-
-Based on impact and value:
-
-1. **E2E Tests: ${BASE_SCORES.e2e}**
-   - Highest value: validates complete user journeys
-   - Catches integration issues across full stack
-   - Most realistic representation of user experience
-
-2. **UI Tests: ${BASE_SCORES.ui}**
-   - Critical for user-facing functionality
-   - Prevents UI regressions
-   - Validates actual user interactions
-
-3. **Integration Tests: ${BASE_SCORES.integration}**
-   - Validates component interactions
-   - Catches interface mismatches
-   - Tests realistic workflows
-
-4. **Load Tests: ${BASE_SCORES.load}**
-   - Ensures performance under pressure
-   - Prevents production outages from traffic spikes
-   - Validates scalability
-
-5. **Fuzz Tests: ${BASE_SCORES.fuzz}**
-   - Uncovers security vulnerabilities
-   - Finds edge cases
-   - Validates input handling
-
-6. **Contract Tests: ${BASE_SCORES.contract}**
-   - Prevents API breaking changes
-   - Ensures service compatibility
-   - Important for microservices
-
-7. **Smoke Tests: ${BASE_SCORES.smoke}**
-   - Basic verification only
-   - Quick feedback but shallow coverage
-   - Catches only obvious failures
-
----
-
-## Contextual Score Adjustment by Test Type
-
-### Scoring Formula
-\`\`\`
-_finalScore = _baseScore × contextMultiplier
-\`\`\`
-
-### E2E Tests Context Multipliers
-- **Full-stack application**: ×1.2 (full value)
-- **Backend-only API**: ×0.7 (reduced, no UI to test end-to-end)
-- **Frontend SPA without backend**: ×0.9 (slightly reduced)
-- **Library/SDK**: ×0 (not applicable)
-
-### UI Tests Context Multipliers
-- **Frontend SPA or full-stack**: ×1.2 (full value)
-- **Backend-only**: ×0 (not applicable)
-
-### Integration Tests Context Multipliers
-- **Full-stack application**: ×1.2 (full value)
-- **Microservices**: ×1.1 (service communication important)
-- **Has unit tests, missing integration**: ×1.2 (fill coverage gap)
-
-### Load Tests Context Multipliers
-- **Has Kubernetes or Docker Compose**: ×1.2 (scaled infrastructure suggests high traffic)
-- **Daily deployments**: ×1.15 (frequent deploys need performance validation)
-- **CLI tool or library**: ×0.4 (low traffic expected)
-- **Internal tool (<10 users)**: ×0.4 (minimal load)
-
-### Fuzz Tests Context Multipliers
-- **Handles payments or PII**: ×1.2 (security critical)
-- **OAuth2 authentication**: ×1.15 (public API indicator)
-- **Public-facing API**: ×1.2 (higher security needs)
-- **Internal service**: ×0.9 (lower security priority)
-
-### Contract Tests Context Multipliers
-- **Microservices architecture**: ×1.2 (critical for service contracts)
-- **Multiple services detected**: ×1.15 (service interactions important)
-- **Monolithic application**: ×0.9 (less critical)
-
-### Smoke Tests Context Multipliers
-- **No existing tests**: ×1.2 (quick wins needed)
-- **Production system**: ×1.1 (deployment validation)
-- **Already has comprehensive tests**: ×0.8 (less valuable)
-
----
-
-## Context Multiplier Rules (Programmatic)
-
-${generateContextRulesTable()}
-
-## Repository Analysis
-
-\`\`\`json
-${JSON.stringify(analysis, null, 2)}
-\`\`\`
-
-## Your Task
-
-Calculate priority scores for ALL test types and return a JSON object with this structure:
-
-\`\`\`json
-{
-  "priorityScores": [
-    {
-      "testType": "integration",
-      "_baseScore": 85,
-      "contextMultiplier": 1.2,
-      "_finalScore": 102,
-      "feasibility": "high",
-      "requiredArtifacts": {
-        "available": ["openApiSpec"],
-        "missing": []
-      },
-      "reasoning": "Detailed explanation of why this score was calculated"
-    }
-  ],
-  "contextFactors": {
-    "applied": [
-      {
-        "factor": "hasDockerCompose",
-        "impact": "Increases integration test importance",
-        "multiplier": 1.1
-      }
-    ]
-  },
-  "summary": {
-    "highPriority": ["integration", "fuzz"],
-    "mediumPriority": ["contract", "load"],
-    "lowPriority": ["smoke"]
-  }
-}
-\`\`\`
-
-Calculate scores now. Return ONLY the JSON object, no other text.
-`;
-}
-function generateContextRulesTable() {
-    let table = "";
-    for (const [testType, rules] of Object.entries(CONTEXT_RULES)) {
-        table += `\n**${testType.toUpperCase()} Context Multipliers:**\n`;
-        for (const rule of rules) {
-            table += `- ${rule.condition}: ×${rule.multiplier} (${rule.description})\n`;
-        }
-    }
-    return table;
-}