@skyramp/mcp 0.2.8 → 0.2.10-rc.1

package/build/prompts/test-maintenance/driftAnalysisShared.js

@@ -0,0 +1,80 @@
+/** Shared drift prompt sections (assign-action, external test policy, symbol discovery) for API and UI prompts. */
+/**
+ * Build the symbol-discovery grep instruction — unified for API and UI tests.
+ * Two-pass: hunk-context symbols (what changed) + full file exports (what exists),
+ * covering aliases, indirect renders, and shared hooks the diff doesn't mention.
+ */
+export function buildSymbolDiscoveryStep(hasTests, repoPaths) {
+    if (!hasTests)
+        return "";
+    const repoList = repoPaths && repoPaths.length > 1
+        ? repoPaths.map(p => `\`${p}\``).join(", ")
+        : repoPaths?.[0] ? `\`${repoPaths[0]}\`` : "the repository";
+    return `**Symbol discovery (before assessing):** Find additional test files that reference changed code:
+
+1. **Hunk context:** Extract function and class names from \`@@\` context lines and changed endpoint URL path segments. Grep ${repoList} for each.
+2. **Full file exports:** For each changed source file in the diff, read it and extract all exported symbols (component names, function names, hooks, class names). Grep ${repoList} for each (case-insensitive). This catches tests using aliased imports, indirect renders, or shared hooks not visible in the diff hunk.
+
+Add any matched test files not already in your assessment, and include them in \`recommendations[]\`.`;
+}
+/** One source of truth for the recommendations[] contract passed to skyramp_actions. */
+export const RECOMMENDATIONS_INSTRUCTION = `Pass VERIFY, UPDATE, REGENERATE, and DELETE entries to \`recommendations[]\`. Omit IGNORE.`;
+export function buildSharedExternalTestPolicy() {
+    return `**For user-written (external) tests** marked \`[external]\` in the test list:
+- UPDATE is permitted — pass the exact file that needs editing as \`testFile\`. This can be the test file itself, a snapshot file, a page object, or a fixture. \`skyramp_actions\` will edit that file using \`updateInstructions\`; application source files are automatically rejected.
+- REGENERATE and DELETE: assign these actions when the evidence clearly warrants them (page gone → DELETE, component structure fundamentally changed → REGENERATE). \`skyramp_actions\` handles execution restrictions at apply time — assign the action that the evidence supports. Leave user-authored test files unchanged; edits go only through \`skyramp_actions\` with explicit \`updateInstructions\`. VERIFY means "uncertain, need more context" — assign DELETE or REGENERATE when you have confirmed the failure, and VERIFY only when you genuinely cannot determine impact without more information.`;
+}
+/** Shared boilerplate: VERIFY rule, pre-commit structure, and external policy. */
+function buildAssignActionCore(opts) {
+    return `Based on the above checks, choose the action (IGNORE / VERIFY / UPDATE / REGENERATE / DELETE) and provide a 1-2 sentence rationale.
+
+**Every action requires a specific rationale — including IGNORE:**
+- UPDATE / REGENERATE / DELETE: ${opts.triggerEvidence}.
+- VERIFY: name the uncertain element (e.g. ${opts.verifyExample}).
+- IGNORE: ${opts.ignoreGuidance}.
+
+${opts.domainNotes}
+
+**When uncertain, use VERIFY not IGNORE:** If the diff touches code this test could exercise but you cannot confirm impact without reading more context, assign VERIFY — do not default to IGNORE.
+
+**Pre-commit verification — confirm before finalizing UPDATE/REGENERATE/DELETE:**
+1. You can quote a specific diff line${opts.blueprintSuffix} this test observes that triggered the action.
+2. ${opts.reachabilityCheck}
+3. ${opts.regenerateCheck}
+4. ${opts.deleteCheck}
+If any check fails, downgrade to VERIFY or IGNORE.
+
+${buildSharedExternalTestPolicy()}`;
+}
+/**
+ * Assign-action section for the API drift prompt.
+ * @param domainNotes  API-specific bullets (additive-fields guidance, scope-gate note).
+ */
+export function buildApiAssignAction(domainNotes) {
+    return buildAssignActionCore({
+        triggerEvidence: "quote the specific diff line that triggered it",
+        ignoreGuidance: `name the changed file(s) from the diff AND explain why they cannot reach this test's endpoint (e.g. "diff only touches \`auth/session-service.js\` — this test targets \`/api/v1/orders\` which has no session dependency"). You must reference at least one specific changed file. Generic "unrelated endpoint" or "service boundary" without naming the changed file is not sufficient`,
+        verifyExample: `"model-only change, cannot confirm field is exposed without checking the output layer"`,
+        blueprintSuffix: "",
+        reachabilityCheck: "The changed code is reachable through this test's service and base URL.",
+        regenerateCheck: "For REGENERATE: every assertion in the file is invalid, not just some — if you can patch N paths, it is UPDATE.",
+        deleteCheck: "For DELETE: all covered endpoints no longer exist.",
+        domainNotes,
+    });
+}
+/**
+ * Assign-action section for the UI drift prompt.
+ * @param domainNotes  UI-specific bullets (component/widget matching notes).
+ */
+export function buildUiAssignAction(domainNotes) {
+    return buildAssignActionCore({
+        triggerEvidence: "quote the specific diff line and/or blueprint element that triggered it",
+        ignoreGuidance: `name the specific route or component and why the diff cannot reach it (e.g. "diff only touches \`/api/v1/users\` — this test targets \`/dashboard\`")`,
+        verifyExample: `"component is imported but not directly rendered — cannot confirm impact without reading the parent"`,
+        blueprintSuffix: " or blueprint element",
+        reachabilityCheck: "The changed code is reachable through this test's routes (browser tests) or a render/mount call in the test that references a changed component (component/widget tests).",
+        regenerateCheck: "For REGENERATE: the interaction model changed fundamentally — the test's action sequence has no migration path. If selectors changed but the flow (navigate → interact → assert) can still be expressed with targeted edits, it is UPDATE regardless of how many selectors changed.",
+        deleteCheck: "For DELETE: the route is completely gone (browser tests) or the rendered component was deleted (component/widget tests).",
+        domainNotes,
+    });
+}

package/build/prompts/test-maintenance/uiDriftAnalysisSections.d.ts

@@ -0,0 +1,32 @@
+/**
+ * Build the UI Action Decision Tree section.
+ * This is the main entry point for UI drift analysis.
+ */
+export declare function buildUiActionDecisionTree(): string;
+/**
+ * Check if routes targeted by the UI test still exist.
+ */
+export declare function buildUiCheckRouteExistence(): string;
+/**
+ * Check if selectors used by the UI test still exist in the blueprints.
+ */
+export declare function buildUiCheckSelectors(): string;
+/**
+ * Check if page objects/fixtures referenced by the test still exist.
+ */
+export declare function buildUiCheckPageObjects(): string;
+/**
+ * Check for component behavior changes that affect assertions.
+ */
+export declare function buildUiCheckBehavioralChanges(): string;
+/**
+ * Assign the final UI drift action.
+ */
+export declare function buildUiCheckAssignAction(): string;
+/**
+ * Build the UI drift output checklist.
+ */
+export declare function buildUiDriftOutputChecklist(stateFile?: string, tests?: Array<{
+    testFile: string;
+    source?: string;
+}>): string;

package/build/prompts/test-maintenance/uiDriftAnalysisSections.js

@@ -0,0 +1,212 @@
+/**
+ * UI Drift Analysis prompt sections for Component 2.
+ *
+ * Mirrors the driftAnalysisSections.ts pattern but for UI-specific drift detection.
+ * These sections are included whenever `uiContext.changedFrontendFiles` is non-empty —
+ * both browser tests (Playwright/Cypress/Selenium) and component/widget tests
+ * (RTL/Flutter widget/vue-test-utils/angular-testbed) go through the same gate.
+ * Component tests always use source-only analysis regardless of blueprintCaptured.
+ */
+import { buildUiAssignAction } from "./driftAnalysisShared.js";
+/**
+ * Build the UI Action Decision Tree section.
+ * This is the main entry point for UI drift analysis.
+ */
+export function buildUiActionDecisionTree() {
+    return `<ui_decision_rules>
+For each UI test listed in the \`<ui_analysis_context>\` above, assess whether the test is still valid given the diff (and blueprint diff when blueprints were captured). The diff may have changed:
+- Element selectors (CSS class changes, component restructuring)
+- Page structure (new containers, removed sections)
+- Route paths (URL changes)
+- Component behavior (state changes, visibility conditions)
+
+**Scope gate:** Read each test file to determine its type, then apply the correct gate:
+- **Browser test** (has \`page.goto()\`, \`cy.visit()\`, \`driver.get()\`): check that the test navigates to a page the changed frontend file serves. Infer from the changed file's directory path (e.g. \`modules/bookings/\` → bookings page) or explicit route-path diff signals.
+- **Component/widget test** (has \`render(<…>)\`, \`mount()\`, \`shallowMount()\`): check if it directly renders/mounts a changed component. If none of the rendered components match a changed file, the test is unaffected.
+If neither condition applies, assign **IGNORE** and skip remaining checks.
+
+
+**Severity order (highest first): DELETE > REGENERATE > UPDATE > VERIFY > IGNORE**
+
+**Pre-scan the diff for UI-relevant changes:**
+- Component file changes: \`+ import { NewComponent }\`, \`- <OldComponent />\` / \`+ <NewComponent />\`
+- CSS/Tailwind changes: \`+ className="..."\`, \`+ tw="..."\`, \`+ styles.\`
+- Route changes: \`- path: "/old"\` / \`+ path: "/new"\`
+- Selector changes: \`+ data-testid="..."\`, \`- data-testid="..."\`, \`+ aria-label="..."\`
+- State/visibility changes: \`+ isOpen\`, \`+ isVisible\`, \`+ showModal\`
+
+Build a detection list first: for each matched diff line, write one line: \`{pattern type} — "{diff line}" — affects {route/component}\`.
+
+**Action definitions:**
+- **DELETE**: The test targets a page/route that no longer exists, or all selectors the test uses have been removed and there's no migration path.
+- **REGENERATE**: The interaction model changed so fundamentally that the test flow itself is broken — not just selector values, but the sequence of actions (e.g. a form replaced by a modal, buttons replaced by a dropdown, a multi-step flow collapsed into one). There is no rename mapping; re-recording from scratch is the only viable approach.
+- **UPDATE**: Specific selectors need updating, assertions need adjustment, or new elements were added to a page the test already exercises. Always an in-place edit to the existing file — do not generate a new spec to cover the same page or component.
+- **VERIFY**: The test may be impacted but you cannot confirm breakage without reading more context (e.g. selectors are hidden in a page object file you have not read, or the component is imported indirectly).
+- **IGNORE**: The changed code cannot reach this test's routes or rendered components — the test covers unchanged functionality. If you cannot point to a diff line that affects this test's routes, selectors, or rendered components, the action is IGNORE or VERIFY, not UPDATE.
+
+**Rules:**
+- DELETE when all routes the test covers were removed or all critical selectors are gone.
+- REGENERATE when the interaction model changed fundamentally — the test's sequence of actions is broken with no migration path (e.g. a click-to-update button replaced by an auto-updating stepper; a remove button moved into a dropdown). The number of broken selectors alone does not determine REGENERATE; what matters is whether the flow can still be expressed with targeted edits.
+- UPDATE when specific selectors changed (renamed classes, moved data-testid) but the test flow remains valid, or when new elements were added to a page the test already covers — append the assertion to the existing file.
+- VERIFY when a page object or indirect import hides the affected selectors — read the imported file before escalating to UPDATE.
+- IGNORE when the diff touches unrelated frontend code (different routes, different components).
+
+**Additional rule for component/widget tests** ([rtl], [flutter-widget], [vue-test-utils], [angular-testbed]):
+- Rule #7: Component deleted — source file removed with no re-export → **DELETE** (report-only for external tests). These tests have no navigation; the rendered component is their only target.
+- Skip the route-existence check (step 1.1) for component/widget tests — they have no \`page.goto()\` or equivalent navigation calls.
+- Primary matching signal: read the test to check if it directly renders a changed component — if so, it is impacted.
+</ui_decision_rules>`;
+}
+/**
+ * Check if routes targeted by the UI test still exist.
+ */
+export function buildUiCheckRouteExistence() {
+    return `Does the route/page this UI test navigates to still exist?
+
+**Skip this check for component/widget tests** ([rtl], [flutter-widget], [vue-test-utils], [angular-testbed]) — they render components directly with no navigation calls. Proceed to selector checks.
+
+Diff signals to look for (browser tests only):
+- Route removed: \`- path: "/old-path"\`, \`- @app.route("/old-path")\`, \`- router.get("/old-path")\`
+- Route renamed: paired \`-\` and \`+\` on route definitions with different paths
+- Redirect added: \`+ redirect: "/old-path" → "/new-path"\`, \`+ res.redirect(301, "/new-path")\`
+
+Actions:
+- ALL routes the test uses were removed → **DELETE**
+- SOME routes renamed with no redirect → **UPDATE** (update navigation calls to new URLs)
+- Routes renamed with redirect kept → **UPDATE** (verify redirect behavior, test should still work)
+- Routes unchanged → proceed to selector checks`;
+}
+/**
+ * Check if selectors used by the UI test still exist in the blueprints.
+ */
+export function buildUiCheckSelectors() {
+    return `Do the selectors/locators this UI test uses still match the current UI?
+
+Read the test (and any imported page object/fixture files) to extract the selectors/locators it uses — \`getByTestId(...)\`, \`locator(...)\`, \`.find('...')\`, \`data-testid\`, \`aria-label\`, CSS class names.
+
+Diff signals to look for:
+- CSS class changes: \`- className="old-class"\` / \`+ className="new-class"\`
+- Tailwind changes: \`- tw="p-4"\` / \`+ tw="p-6"\`
+- Test ID changes: \`- data-testid="old-id"\` / \`+ data-testid="new-id"\`
+- ARIA changes: \`- aria-label="Old"\` / \`+ aria-label="New"\`
+- Component restructuring: \`+ <NewWrapper>\` around existing content, \`- <OldWrapper>\`
+
+**When blueprints are available** (\`blueprintCaptured=true\`): compare extracted selectors against \`browser_blueprint_diff\` for the affected page — elements absent from the new blueprint signal breakage.
+
+**When blueprints are not available** (\`blueprintCaptured=false\`): use diff signals only. If a selector the test uses matches a value renamed or removed in the diff, assign UPDATE. If you cannot confirm breakage from the diff alone (e.g. selectors live in a page object you have not read), assign VERIFY rather than guessing.
+
+Actions:
+- Selectors confirmed unchanged (diff or blueprint) → **IGNORE** (no drift)
+- Selectors renamed (class, testid, aria-label changed) → **UPDATE** (patch selector values)
+- Selectors removed with no confirmed replacement → **UPDATE** (find replacement; use blueprint if available, diff otherwise)
+- Major restructuring (most selectors gone) → **REGENERATE** (page structure fundamentally changed)
+- All selectors gone, no replacement elements → **DELETE** (page no longer testable)
+- Cannot confirm without reading page object or additional files → **VERIFY**
+- Hardcoded visible string wrapped in a translation key (e.g. a literal moved to \`$t('...')\`) and the default-locale rendering is unchanged → **UPDATE**: the assertion now silently depends on the active locale. Add explicit locale context to the test fixture or assert via the translation key so the test tracks the translation rather than a hardcoded copy.`;
+}
+/**
+ * Check if page objects/fixtures referenced by the test still exist.
+ */
+export function buildUiCheckPageObjects() {
+    return `Do the page objects or fixture files imported by this UI test still exist, and are their underlying selectors still valid?
+
+**Always follow imports to find page objects — regardless of whether blueprints were captured.**
+Page objects can live anywhere in the repo (not just \`page-objects/\` or \`fixtures/\`). Do not assume a fixed directory. The only reliable way to find them is to follow the spec file's \`import\` statements.
+
+**Protocol for every browser test (Playwright/Cypress/Selenium):**
+1. Read the spec file and collect all local \`import\` statements (skip \`@playwright/test\`, \`vitest\`, etc. — only follow relative or repo-local paths).
+2. For each imported file, read it and extract the selectors it encapsulates — \`locator()\`, \`getByTestId()\`, \`getByRole()\`, \`getByLabel()\`, \`data-test-*\`, \`aria-label\`, CSS class strings.
+3. Compare those selectors against the diff: if a selector value the page object uses was renamed or removed in a \`-\` diff line → the page object needs **UPDATE**.
+4. **Update the page object file, not the spec file** — the page object is the selector source of truth. In the recommendation: set \`testFile\` to the **spec file** (so it shows correctly in the maintenance report) and set \`pomFile\` to the **page object path** (so \`skyramp_actions\` edits the right file). If the edit is rejected at action time, the agent or developer can address it separately.
+5. If the imported file is missing or unreadable → **VERIFY** (cannot confirm without the file).
+
+A clean spec with no raw selector calls is not a reason to assign VERIFY — it is expected when page objects are used. Assign the action based on the POM's selectors.
+
+Diff signals to look for in the spec's imports:
+- Import deleted: \`- import { OldPage } from './pages/OldPage'\` → page object removed
+- Import path changed: paired \`-\`/\`+\` on the same import → page object moved or renamed
+- New import added: \`+ import { NewFixture } from '../fixtures/new'\` → new dependency
+
+Actions:
+- Page object's selectors match a renamed/removed diff value → **UPDATE** (patch the page object)
+- Page object import path changed in the diff → **UPDATE** (fix the import in the spec)
+- Page object file deleted, no replacement found → **UPDATE** (inline selectors or find alternative)
+- Selectors in page object unchanged and diff does not affect them → **IGNORE**
+- **All POM selectors are gone with no migration path in the diff** (the component's interaction model changed fundamentally — no ` + ` lines showing replacement selectors) → **REGENERATE**. Do not stay at VERIFY after reading the POM and confirming this — escalate once you have confirmed the failure.`;
+}
+/**
+ * Check for component behavior changes that affect assertions.
+ */
+export function buildUiCheckBehavioralChanges() {
+    return `Have component behaviors changed in ways that would break test assertions?
+
+Diff signals to look for:
+- State changes: \`+ isLoading\`, \`+ isOpen\`, \`+ showModal\`, \`+ disabled\`
+- Visibility conditions: \`+ if (condition) return null\`, \`+ {condition && <Component />}\`
+- Interaction changes: \`+ onClick={() => setOpen(true)}\`, \`+ require('auth')\`
+- Async behavior: \`+ setTimeout\`, \`+ debounce\`, \`+ async/await\` in handlers
+
+Actions:
+- New loading states → **UPDATE** (add waitFor or assertion for loading state)
+- New conditional rendering → **UPDATE** (update assertions to match new conditions)
+- Auth behavior changed → **UPDATE** (adjust login flow in test)
+- Async delays added → **UPDATE** (add appropriate waits/timeouts)
+- Shared component changed (used across multiple pages, dialogs, or layouts): if the test covers only one consumer and you have not read all other consumers, assign **VERIFY** — the blast radius across other consumers is indeterminate. Only assign UPDATE if you have confirmed the change is isolated to this test's consumer.`;
+}
+/**
+ * Assign the final UI drift action.
+ */
+export function buildUiCheckAssignAction() {
+    return buildUiAssignAction(`**Component/widget test matching (source-only):**
+- Read the test to check if it directly renders a changed component — if so, it is impacted.
+- If the test only imports but does not directly render the component, assign VERIFY (component-import signal — cannot confirm impact without reading the parent).
+- If neither signal fires, assign **IGNORE**.`);
+}
+/**
+ * Build the UI drift output checklist.
+ */
+export function buildUiDriftOutputChecklist(stateFile, tests) {
+    const finalStep = `Call \`skyramp_actions\` with \`stateFile: "${stateFile ?? "<stateFile>"}"\`.`;
+    const hasTests = (tests?.length ?? 0) > 0;
+    const testList = hasTests
+        ? tests.map(t => `- ${t.testFile}${t.source === "external" ? " [external]" : ""}`).join("\n")
+        : "- (none)";
+    const noTestsNote = !hasTests
+        ? `\nNo existing tests were found. Call \`skyramp_actions\` with \`recommendations: []\`.\n`
+        : "";
+    const existingTestSection = `**Tests (${tests?.length ?? 0} total) — assess ALL of the following:**
+${testList}
+${noTestsNote}
+
+**Execution policy:**
+- Skyramp-generated tests: UPDATE/REGENERATE/DELETE applied automatically by \`skyramp_actions\`. Run via \`skyramp_execute_test\`.
+- External tests (Playwright, Cypress, RTL, etc.): \`skyramp_actions\` applies UPDATE edits to \`testFile\` — which can be the test itself, a snapshot file, a page object, or a fixture. Application source files are automatically rejected. After a successful UPDATE, call \`skyramp_execute_test\` to confirm the patched test passes (the test environment is already running). Record the result as the after-state in the report. For DELETE and REGENERATE on external tests, see the execution policy in the decision rules above.
+
+For each UI test above, output one structured entry in \`recommendations[]\`:
+- **IGNORE**: \`{testFile} — IGNORE: {specific reason the diff cannot reach this test — name the route or component that differs}\` — do not pass to \`skyramp_actions\`
+- **VERIFY**: \`{testFile} — VERIFY: {uncertain element, e.g. "selectors hidden in page object not yet read"}\`
+\`\`\`
+Test: {testFile}
+Action: UPDATE
+Rationale: UPDATE because {quoted diff line}; {selector/route/behavior change}
+UpdateInstructions: {what must change — specific selectors to update, routes to patch, assertions to add}
+\`\`\`
+\`\`\`
+Test: {testFile}
+Action: REGENERATE
+Rationale: REGENERATE because {quoted diff line}; page structure fundamentally changed
+\`\`\`
+\`\`\`
+Test: {testFile}
+Action: DELETE
+Rationale: DELETE because {quoted diff line}; all routes removed or no valid selectors remain
+\`\`\`
+
+Be concise — one line per VERIFY/IGNORE entry.`;
+    const sections = [existingTestSection, finalStep];
+    return `<ui_output_format>
+Complete ALL of the following:
+
+${sections.join("\n\n")}
+</ui_output_format>`;
+}

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

@@ -76,7 +76,7 @@ export function buildExternalCoverageSet(testLocations) {
     }
     return coverage;
 }
-// Shared TestBot task and step labels used by prompt modules that cannot import
+// Shared Testbot task and step labels used by prompt modules that cannot import
 // testbot-prompts.ts directly without creating a circular dependency.
 export const TASK_UI_PRESCAN = "0";
 export const TASK_ANALYZE_MAINTAIN = "1";

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

@@ -11,7 +11,12 @@ const FLUTTER_DART_EXT = /\.dart$/i;
 const LIKELY_FRONTEND_EXT = /\.(tsx|jsx)$/i;
 // Ambiguous extensions need directory context to distinguish frontend from backend.
 const AMBIGUOUS_FRONTEND_PATTERN = /\.(tsx?|jsx?|css|scss|less|html?|erb|jsp|asp|jinja2?|twig)$/i;
-const API_DIR_PATTERN = /\/(api|routes?|controllers?|routers?|handlers?|endpoints?|server)\//;
+// /api/ always signals backend — even .tsx files (e.g. Next.js pages/api/*.tsx handlers).
+const STRICT_API_DIR_PATTERN = /\/(api)\//i;
+// Framework route dirs that contain React page components in modern full-stack apps
+// (Medusa Admin, Remix, React Router v6). These only block non-.tsx/.jsx files —
+// a .tsx file in routes/ is a page component, not a route handler.
+const FRAMEWORK_ROUTE_DIR_PATTERN = /\/(routes?|controllers?|routers?|handlers?|endpoints?|server)\//i;
 const FRONTEND_DIR_PATTERN = /(^|\/)(components?|pages?|views?|layouts?|app|src\/app|frontend|client|public|styles?|templates?)\//i;
 /**
  * Returns true if the repository root's `pubspec.yaml` declares a Flutter
@@ -120,7 +125,12 @@ export function isFrontendFile(filePath, { hasFlutterSdkDep = false } = {}) {
         return true;
     if (hasFlutterSdkDep && FLUTTER_DART_EXT.test(filePath))
         return true;
-    if (API_DIR_PATTERN.test(filePath))
+    // /api/ always means backend regardless of extension (Next.js API routes use .tsx).
+    if (STRICT_API_DIR_PATTERN.test(filePath))
+        return false;
+    // routes/, controllers/ etc. block .ts/.js but not .tsx/.jsx — Medusa Admin and
+    // React Router place page components under routes/, not API handlers.
+    if (!LIKELY_FRONTEND_EXT.test(filePath) && FRAMEWORK_ROUTE_DIR_PATTERN.test(filePath))
         return false;
     if (LIKELY_FRONTEND_EXT.test(filePath))
         return true;

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

@@ -86,7 +86,7 @@ Verify the prompt inside <USER_PROMPT> is related to adding or removing tests fr
 
 ### Task 1: Retrieve Previous Recommendations
 Call \`skyramp_analyze_changes\` with \`repositoryPath\`: "${repositoryPath}", \`scope\`: "branch_diff"${baseBranch ? `, \`baseBranch\`: "${baseBranch}"` : ""}${prNumber ? `, \`prNumber\`: ${prNumber}` : ""}${testsRepoDir ? `, \`testsRepoDir\`: "${testsRepoDir}"` : ""}.
-This will fetch the previous TestBot report from the PR comments and return deduplicated recommendations.
+This will fetch the previous Testbot report from the PR comments and return deduplicated recommendations.
 Use those recommendations as your baseline. Only add or remove tests that the user requested AND that appear in the Additional Recommendations. Then proceed straight to Task 2: Generate New Tests.
 `
         : `
@@ -102,7 +102,7 @@ Use those recommendations as your baseline. Only add or remove tests that the us
    **Feature context check:** After capturing a blueprint per the UI Blueprint Capture instructions, cross-check whether it actually shows the changed feature. Look at the diff — what component, field, or UI element was changed? If that component only renders in a specific context (a particular collection type, a non-empty list, a specific user role, a form that only appears after a prior action), and the blueprint you captured doesn't contain it, navigate to the right context before using this blueprint for recommendations. A blueprint that doesn't show the changed feature produces recommendations that test the wrong thing — for example, recommending tests against a system collection when the PR changed behavior on custom collections. If you can't determine the right context from the diff and workspace config, note it in \`issuesFound\` and fall back to source-grounded recommendations for that URL.
 
    **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 and a single \`issuesFound\` entry explaining why (same format as the zero-test path below).
+   **If all changed files are non-application** (CI/CD, docs, lock files, config) → skip to Task 3 (Submit Report) with empty arrays. Put the one-paragraph summary in \`businessCaseAnalysis\` (always populated; that's where end-state narration belongs); leave \`issuesFound\` empty — a non-application diff is not an issue. Example narration for a Testbot onboarding PR (\`.github/workflows/skyramp-testbot.yml\` and/or files under \`.skyramp/\`): "This PR adds Skyramp Testbot GitHub Actions workflow configuration to enable automated test generation on every pull request. It also adds System Under Test (SUT) setup files under \`.skyramp/sut/\` required for the testbot workflow, to bring up services for testing. It contains no application code changes and has no testable behavioral surface."
 ${hasRelatedRepos ? `
    **MULTI-REPO CONTEXT (MANDATORY).** This run includes ${relatedRepositories.length} related ${relatedRepositories.length === 1 ? "repository" : "repositories"} listed in the \`<related_repositories>\` block below, each with an explicit \`repository\` (\`owner/repo\`), \`path\`, and \`base_branch\`. Use the \`repository\` value verbatim — do NOT infer it from git remotes or paths. You MUST analyze EACH related repository — exactly one \`skyramp_analyze_changes\` call per listed repo (${relatedRepositories.length} ${relatedRepositories.length === 1 ? "call" : "calls"}), in addition to the primary call in step 2.
 
@@ -126,11 +126,11 @@ ${hasRelatedRepos ? `
 
 2. **Maintain existing tests:**
 
-   a. Call \`skyramp_analyze_test_health\` with \`stateFile\` (from \`skyramp_analyze_changes\` output). **Do NOT read application source files** (routes, models, controllers) — all change information you need is in the \`skyramp_analyze_changes\` output and the diff.
+   a. Call \`skyramp_analyze_test_health\` with \`stateFile\` (from \`skyramp_analyze_changes\` output). Pass \`blueprintCaptured: true\` when \`browser_blueprint\` was called successfully earlier in this session — see the parameter description for when this applies. **Do NOT read application source files** (routes, models, controllers) — all change information you need is in the \`skyramp_analyze_changes\` output and the diff. Exception: the UI drift pre-scan (\`UI_SYMBOL_PRESCAN\`) may instruct you to read changed frontend files to extract exported symbols — follow those instructions when present.
 
    b. Write \`updateInstructions\` for each UPDATE or REGENERATE test before calling \`skyramp_actions\` — articulating the change first prevents file content from overriding diff-based reasoning.
 
-   c. Call \`skyramp_execute_test\` with \`phase: "before"\` and \`stateFile\` for every test whose action is UPDATE or REGENERATE. Run them in parallel. This captures the pre-edit baseline — do not skip even if you expect the test to fail.
+   c. Call \`skyramp_execute_test\` with \`phase: "before"\` and \`stateFile\` for every test whose action is UPDATE, REGENERATE, or DELETE. Run them sequentially, not in parallel. This captures the pre-edit baseline — do not skip even if you expect the test to fail.
 
    d. Call \`skyramp_actions\` with \`stateFile\` (from \`skyramp_analyze_changes\` output) and apply the edits it returns.
 
@@ -370,7 +370,7 @@ ${userPrompt ? "Generate only the tests that the user requested from the Additio
   **Flutter web apps:** Skyramp's Playwright tools automatically enable Flutter's accessibility semantics tree on every \`browser_navigate\` call — you do NOT need to manually click \`flt-semantics-placeholder\` or add any activation step to the trace. Do NOT log an \`issuesFound\` entry about Flutter canvas rendering or accessibility activation — this is handled transparently. **Do NOT skip test generation or abstain from recording based on what you see in the Flutter source code** (e.g. \`SemanticsBinding.ensureSemantics()\` commented out, \`IS_TESTING\` flag absent, or similar) — Skyramp enables accessibility from the browser side regardless of the app's Dart code. Proceed with \`browser_navigate\` and test recording as normal. **Start at the app's root URL** (e.g. \`{baseUrl}/\`) — do NOT \`browser_navigate\` straight to a deep sub-route (e.g. \`/authors\`, \`/orders/13\`). Flutter \`go_router\` SPAs route from the root: deep-linking on a cold page load often fails to render the expected screen (the route's widgets never mount, so the trace captures the wrong page). Load the root, let the app's own routing/auth-redirect render, then reach target screens by interaction. **After the initial login, navigate using in-app controls only** (tab buttons, links, back buttons) — do NOT call \`browser_navigate\` to a different URL after login. Flutter web apps are SPAs: a \`browser_navigate\` to a new URL after login triggers a full page reload which clears the auth session, causing redundant re-login cycles in the generated test. Use button clicks to reach target screens instead.
   **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:
+  - **(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. **The server already computes this** — check \`uiContext.frontendFileIntegration\` in the \`skyramp_analyze_changes\` output: if it marks the changed file \`integrated: false\`, treat the component as unintegrated WITHOUT re-running the grep below (the tool output's accompanying instruction block already tells you what to do — do not substitute another page or trace). Only fall back to the manual grep procedure when \`frontendFileIntegration\` is absent (older MCP versions) or doesn't cover the changed file:
     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.
@@ -547,7 +547,7 @@ Do NOT use \`page.waitForTimeout()\` with fixed delays. Do NOT retry more than o
 4. **Wait**: Do NOT proceed to test execution until steps 1–3 are complete and the verification checklist in the \`skyramp_enhance_assertions\` tool result has been validated for EVERY generated test file.
 Do not make any changes other than the assertion enhancements described above. For example: do not modify auth headers, cookies, tokens, env vars, or imports that the generation tool already set correctly — those are correct by construction and changing them breaks auth or execution.
 
-**Final execution (mandatory):** Do NOT call \`skyramp_execute_test\` until ALL maintenance edits AND ALL new test generation/enhancement are complete.
+**Final execution (mandatory):** Do NOT call \`skyramp_execute_test\` until ALL maintenance edits AND ALL new test generation/enhancement are complete. Run these calls sequentially, not in parallel.
 - Only report test results for files you actually ran.
 **Auth**: If \`skyramp_analyze_changes\` reports an auth token or \`SKYRAMP_TEST_TOKEN\` is set, pass it in **every** \`skyramp_execute_test\` call from the first attempt — do NOT wait for a 401/403 to discover auth is needed.
 
@@ -572,13 +572,14 @@ In these cases:
 Otherwise: in \`newTestsCreated\`, you must have exactly ${maxGenerate} budget-counting new tests for the planned GENERATE items. Only new files (ADD) created for those planned GENERATE items count toward this ${maxGenerate} target — GENERATE items converted to UPDATE do not. You may also include at most one additional discovered-scenario file in \`newTestsCreated\` (the bug-catching test generated after all planned items); that extra test does **not** count against the ${maxGenerate} budget. If you have fewer than ${maxGenerate} budget-counting new tests, backfill from the remaining ADDITIONAL candidates before proceeding. Only proceed with fewer than ${maxGenerate} budget-counting new tests if all candidates failed after retry AND the fallback single-contract test also failed.
 
 Call \`skyramp_submit_report\` with \`summaryOutputFile\`: "${summaryOutputFile}" and \`stateFile\` (from \`skyramp_analyze_changes\` output) — the stateFile is required for execution outcome tracking. Field names, types, and formats are defined in the tool's parameter schema — follow them exactly.
+
 ${hasRelatedRepos ? `
 - **MULTI-REPO attribution**: Set the \`repository\` field (\`owner/repo\`) on EVERY \`newTestsCreated\`, \`testResults\`, \`issuesFound\`, and \`additionalRecommendations\` item — including items about the PRIMARY repo — so each finding is unambiguously attributed. The primary repo's \`repository\` is \`${primaryRepo || "<the primary repo's owner/repo>"}\`; items derived from a related repo's diff (from the \`<related_repositories>\` analysis) carry that repo's \`repository\` value. In \`businessCaseAnalysis\`, include a short per-repo subsection and call out any cross-repo correlations you found.
 ` : ""}
 - **additionalRecommendations**: AT MOST ${maxRecommendations - maxGenerate} items.
   - For \`testType: "contract"\` entries: **\`primaryEndpoint\` is required** (e.g. \`"GET /api/v1/users/{user_id}"\`). The tool will reject the submission without it — do not omit it or you will be forced to resubmit.
   - For \`testType: "integration"\` or \`"e2e"\` entries: omit \`primaryEndpoint\` — use \`description\` to list the endpoints involved instead.
-- **testMaintenance**: Use \`[]\` **only** if no existing Skyramp tests were found in the repository. If existing tests were found (any score), include one entry per test. Set \`action\` to the exact drift action you chose from the Action Decision Matrix (\`UPDATE\`, \`REGENERATE\`, \`DELETE\`, \`VERIFY\`, or \`IGNORE\`). For UPDATE/REGENERATE/DELETE tests that were modified and executed, populate \`beforeDetails\` and \`afterDetails\` from what you observed in \`skyramp_execute_test\` output — one line each, no newlines. For passing runs write the count and timing (e.g. \`"4 passed in 15.09s"\`). For failing runs write the test name and failure reason (e.g. \`"1 failed: test_foo - assert X == Y — shared-state pollution"\`). For VERIFY/IGNORE tests (not modified), omit \`beforeDetails\` and \`afterDetails\`. Do **not** add entries for tests that were not returned by the health analysis.
+- **\`testMaintenanceDetails\`**: include one entry per test that received UPDATE, REGENERATE, DELETE, or VERIFY. Do NOT include IGNORE — a test assessed and confirmed clean is not a maintenance action and adds noise to the report.
 - **testResults**: For UI/E2E test entries, include the \`videoPath\` field if \`skyramp_execute_test\` returned one.
 
 ---
@@ -630,7 +631,7 @@ export function buildWorkspaceRecoveryPrefix(repositoryPath) {
 export function registerTestbotPrompt(server) {
     logger.info("Registering testbot prompt");
     server.registerPrompt("skyramp_testbot", {
-        description: "Run Skyramp TestBot to generate test recommendations and perform test maintenance for a pull request.",
+        description: "Run Skyramp Testbot to generate test recommendations and perform test maintenance for a pull request.",
         argsSchema: {
             prTitle: z.string().describe("Pull request title"),
             prDescription: z.string().describe("Pull request description/body"),
@@ -660,7 +661,7 @@ export function registerTestbotPrompt(server) {
             prNumber: z
                 .number()
                 .optional()
-                .describe("GitHub PR number. Passed to skyramp_analyze_changes to fetch previous TestBot comments for recommendation consistency across commits."),
+                .describe("GitHub PR number. Passed to skyramp_analyze_changes to fetch previous Testbot comments for recommendation consistency across commits."),
             userPrompt: z
                 .string()
                 .optional()

package/build/resources/testbotResource.js

@@ -14,7 +14,7 @@ export function registerTestbotResource(server) {
         list: undefined,
     });
     server.registerResource("skyramp_testbot", template, {
-        title: "Skyramp TestBot Prompt",
+        title: "Skyramp Testbot Prompt",
         description: "Returns task instructions for PR test analysis, generation, and maintenance.",
         mimeType: "text/plain",
     }, async (uri) => {

package/build/services/TestDiscoveryService.d.ts

@@ -9,14 +9,16 @@ export interface TestDiscoveryOptions {
      * Resource names derived from endpoints in changed files (e.g. ["orders", "products"]).
      * - Non-empty array: external files partitioned by relevance; only relevant files
      *   get full endpoint extraction. May be the sentinel `["unknown"]` when endpoints
-     *   exist but resource names are unresolvable — treated as "endpoints present" to
-     *   avoid skipping external coverage. Also used for "add field" PRs where the changed
-     *   files have no endpoint definitions but the scanner found related endpoints nearby.
-     * - Empty array `[]`: PR mode with no endpoints from diff or scanner — external
-     *   tests are skipped entirely to avoid flooding context.
+     *   exist but resource names are unresolvable — most files score 0 (low-relevance)
+     *   and are excluded; only the few that happen to match the sentinel are kept.
+     * - Empty array `[]`: PR mode with no endpoints from diff or scanner — API/integration
+     *   external tests are excluded entirely; UI tests may still be promoted via hasFrontendChanges.
      * - `undefined`: full-repo mode — external tests capped at MAX_EXTERNAL_FULL_REPO.
      */
     changedResources?: string[];
+    /** True when the diff contains frontend files — promotes UI test files for framework
+     *  detection regardless of changedResources. Orthogonal to API relevance scoring. */
+    hasFrontendChanges?: boolean;
 }
 export declare class TestDiscoveryService {
     private readonly EXCLUDED_DIRS;
@@ -45,9 +47,13 @@ export declare class TestDiscoveryService {
      * Example: "test_orders_api.py" vs ["orders"] → score 1.
      */
     private scoreRelevance;
+    private readonly MAX_CONTENT_PROMOTED;
     /**
      * Partition external test files into relevant (score > 0) and low-relevance (score = 0).
-     * Signal: path/name token overlap with changedResources.
+     * Two-pass: filename token overlap first (primary); content-based endpoint path scan
+     * as a capped fallback for tests misnamed relative to the endpoint they exercise
+     * (e.g. test_checkout_flow.py testing /api/orders scores 0 by name but matches in content).
+     * Content matches are capped at MAX_CONTENT_PROMOTED to bound token impact.
      */
     private partitionByRelevance;
     /**
@@ -101,9 +107,6 @@ export declare class TestDiscoveryService {
      * Falls back to directory/filename heuristics since external tests lack Skyramp command lines.
      */
     private detectExternalTestType;
-    /**
-     * Detect test framework from external test file content by checking imports.
-     */
     private detectExternalFramework;
     /**
      * Detect programming language from file extension
@@ -118,7 +121,6 @@ export declare class TestDiscoveryService {
      * Extract API schema path from test content
      * Looks for Skyramp command line first, then fallback to other patterns
      */
-    private extractApiSchema;
     /**
      * Extract Framework from test content
      * Looks for Skyramp command line first, then fallback to other patterns