@skyramp/mcp 0.1.0-rc.6 → 0.1.0

package/build/playwright/registerPlaywrightTools.js

@@ -30,8 +30,10 @@ export async function registerPlaywrightTools(server, options) {
         'browser_snapshot',
         'browser_click',
         'browser_type',
+        'browser_press_key',
         'browser_select_option',
         'browser_hover',
+        'browser_drag',
         'browser_tabs',
         'browser_navigate_back',
         'browser_wait_for',

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

@@ -93,8 +93,18 @@ ${nextStep}`;
         ? `\n<diff>\n${p.diffContent}\n</diff>`
         : "";
     const step2 = isUIOnly
-        ? `### Step 2: Identify consumed API endpoints
-UI-only PR — read changed components to find API calls (fetch, axios, hooks).`
+        ? `### Step 2: Identify consumed API endpoints and integration status
+UI-only PR — perform two checks:
+1. Read changed frontend files to find API calls (fetch, axios, hooks).
+2. For each changed component file (skip CSS/HTML/style-only files — they have no exported component name to search for): check whether any production source file imports, re-exports, or renders it.
+   - Search for both the component's exported name AND its module path/filename to catch aliased and default imports (e.g. \`import Foo from './CartLine'\`).
+   - Derive the exported name from the file itself: use the default export name, a named exported PascalCase component, or the PascalCase file basename when no clearer name exists.
+   - Exclude test/story files from the search: ignore matches in \`*.test.*\`, \`*.spec.*\`, \`*.stories.*\`, and \`__tests__/\` directories — only production code imports count as integration.
+
+If no production file imports, re-exports, or renders a changed component, mark it as **unintegrated** in the Execution Plan output.
+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 — do NOT mark it as unintegrated.
+Do NOT apply the unintegrated heuristic to route/entrypoint files themselves — those are always reachable by convention.
+An unintegrated non-route component has no DOM node in the running app and cannot be browser-tested — it qualifies as a dead-code / unintegrated-component no-surface PR regardless of how complex the component logic is.`
         : p.diffContent
             ? `### Step 2: Extract new and modified API endpoints from the diff
 Read the \`<diff>\` above and identify every new or modified API endpoint — route registrations, handler methods, controller annotations. Then use the **Router Mounting / Nesting** section above to reconstruct the full URL path for each endpoint by chaining all parent router prefixes down to the handler (e.g. a handler in a file with \`prefix="/reviews"\` that is mounted at \`/{product_id}\` under a router mounted at \`/api/v1/products\` → full path \`/api/v1/products/{product_id}/reviews\`).

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

@@ -51,7 +51,7 @@ Use those recommendations as your baseline. Only add or remove tests that the us
 
 1. Call \`skyramp_analyze_changes\` with \`repositoryPath\`: "${repositoryPath}", \`scope\`: "branch_diff", \`topN\`: ${maxRecommendations}, \`maxGenerate\`: ${maxGenerate}${baseBranch ? `, \`baseBranch\`: "${baseBranch}"` : ""}${prNumber ? `, \`prNumber\`: ${prNumber}` : ""}${stateOutputFile ? `, \`stateOutputFile\`: "${stateOutputFile}"` : ""} — discovers existing Skyramp tests, scans endpoints changed in the diff, loads workspace config, and returns ${maxRecommendations} ranked ADD recommendations (${maxGenerate} to generate, ${maxRecommendations - maxGenerate} as additional).${prNumber ? " Uses PR comment history to avoid re-recommending already-generated tests." : ""}
    **If \`skyramp_analyze_changes\` returns an error:** retry once only if the error is transient (timeout, network blip, temporary unavailability) — do NOT retry for permanent errors (invalid repository path, missing required parameter, authentication failure). If it fails again, call \`skyramp_submit_report\` with a minimal valid payload: leave all test arrays empty and add the error to \`issuesFound\`. Refer to the \`skyramp_submit_report\` schema for required fields. Do NOT attempt Task 2 without a valid stateFile.
-   **If all changed files are non-application** (CI/CD, docs, lock files, config) → skip to Task 3 (Submit Report) with empty arrays.
+   **If all changed files are non-application** (CI/CD, docs, lock files, config) → skip to Task 3 (Submit Report) with empty arrays and a single \`issuesFound\` entry explaining why (same format as the zero-test path below).
 
 2. **Maintain existing tests** using the rules in \`<drift_analysis_rules>\` below. For each existing test reported by \`skyramp_analyze_changes\`, score it and choose the action exactly as directed by the Action Decision Matrix in \`<drift_analysis_rules>\`. Only read test files that require action per that matrix — do NOT read files that will be IGNORED. **Do NOT read source files (routers, models, CRUD, components) — all the information you need is in the \`skyramp_analyze_changes\` output and the diff.** When reading multiple test files, **read them all in a single parallel batch** — do NOT read them one at a time. Apply actions directly. Results go in \`testMaintenance\`.
 
@@ -98,7 +98,16 @@ ${userPrompt ? "" : "Drift-based maintenance (Task 1) is complete. This step onl
   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. Items that become UPDATEs (covered resource) do not count — backfill from ADDITIONAL candidates (highest-ranked first) until \`newTestsCreated\` reaches ${maxGenerate} or all candidates are exhausted.
-- **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. Only skip if the app is unreachable. This takes priority over generating additional backend-only tests.
+- **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) 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\`.
@@ -197,8 +206,7 @@ If a test **generation** tool call fails:
 2. If it fails again, **skip** that candidate and move to the next ranked candidate.
 3. If all candidates in the GENERATE set fail, fall back to generating the **simplest possible test**: a single contract test for the highest-scored endpoint (GET → 200 or POST → 201).
    **Exception — frontend-only PRs**: If the diff modifies ONLY frontend files (\`.tsx\`, \`.jsx\`, \`.vue\`, \`.svelte\`, \`.css\`, \`.html\`) AND browser recording was not possible, do NOT generate a backend fallback contract test — it is irrelevant to the PR. Instead move ALL GENERATE candidates to \`additionalRecommendations\` and proceed to Task 3.
-4. You MUST generate **at least 1 test** for any PR that touches application code. Zero generated tests is NOT acceptable — unless the frontend-only exception above applies.
-5. Log skipped candidates in \`issuesFound\` with the error message.
+4. Log skipped candidates in \`issuesFound\` with the error message.
 
 If a test **execution** (\`skyramp_execute_test\`) fails for a newly generated test:
 1. Read the error output to diagnose the root cause (4xx on prereq step, assertion mismatch, floating-point precision, 500 from app bug, timeout, etc.).
@@ -235,9 +243,16 @@ Do not make any changes other than the assertion enhancements described above. F
 **Before calling \`skyramp_submit_report\` — mandatory count check:**
 If you skipped here due to non-application changes (per Task 1), submit with empty arrays — the count checks below do not apply.
 
-**If you generated zero new tests because the PR has no testable behavioral surface (cosmetic/docs/style/dependency-only):**
+**If you generated zero new tests because the PR has no testable behavioral surface:**
+This applies when the diff contains ONLY changes with no observable API or UI behavior change. Examples:
+- Cosmetic/docs/style: JSDoc updates, CSS reformats, comment-only changes
+- Dependency-only: version bumps with no API surface change
+- Dead code / unintegrated utility or component: a new helper function, utility, or UI component added to the codebase but not imported, mounted, or rendered anywhere — use this classification only after confirming the new symbol does not appear as an import or render call in any other source file; do NOT classify as dead code based solely on the diff. For UI components specifically: an unintegrated component has no DOM node in the running app and cannot be browser-tested regardless of how complex its logic is
+- Config-only: linter rules, build config, environment variable additions with no runtime behavior change
+
+In these cases:
 - \`newTestsCreated\` must be \`[]\`
-- Add exactly one entry to \`issuesFound\`: \`"No testable behavioral surface detected: <brief reason, e.g. 'JSDoc-only changes with no endpoint modifications', 'CSS reformat with no logic changes', 'dependency version bump with no API surface change'>. Zero new tests generated by design."\`
+- Add exactly one entry to \`issuesFound\`: \`"No testable behavioral surface detected: <brief reason, e.g. 'JSDoc-only changes with no endpoint modifications', 'CSS reformat with no logic changes', 'dependency version bump with no API surface change', 'utility function added but not integrated into any endpoint or component'>. Zero new tests generated by design."\`
 - \`businessCaseAnalysis\` must be a one-sentence summary of what the PR actually does (do NOT leave it blank)
 - \`additionalRecommendations\` must be \`[]\` — do NOT recommend tests for a no-surface PR
 - A blank \`issuesFound\` when tests were intentionally skipped will lose report quality points

package/build/utils/docker.test.js

@@ -54,7 +54,7 @@ describe("dockerImageExistsLocally", () => {
     });
 });
 describe("pullDockerImage", () => {
-    const IMAGE = "skyramp/executor:v1.3.21";
+    const IMAGE = "skyramp/executor:v1.3.22";
     beforeEach(() => jest.clearAllMocks());
     describe("on amd64 host", () => {
         const originalArch = process.arch;

package/build/utils/versions.js

@@ -1,3 +1,3 @@
-export const SKYRAMP_IMAGE_VERSION = "v1.3.21";
+export const SKYRAMP_IMAGE_VERSION = "v1.3.22";
 export const EXECUTOR_DOCKER_IMAGE = `skyramp/executor:${SKYRAMP_IMAGE_VERSION}`;
 export const WORKER_DOCKER_IMAGE = `skyramp/worker:${SKYRAMP_IMAGE_VERSION}`;