@skyramp/mcp 0.3.8 → 0.4.0-rc.1

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

@@ -2,9 +2,10 @@
  * 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.
+ * These sections are ALWAYS included: the prompt tells the agent to grep for
+ * component tests itself, so nothing gates them on a server verdict about the
+ * diff. Browser tests (Playwright/Cypress/Selenium) and component/widget tests
+ * (RTL/Flutter widget/vue-test-utils/angular-testbed) read the same text.
  * Component tests always use source-only analysis regardless of blueprintCaptured.
  */
 import { buildUiAssignAction, EMPTY_TEST_LIST_PLACEHOLDER, NO_PRELOADED_TESTS_NOTE } from "./driftAnalysisShared.js";
@@ -39,10 +40,12 @@ Matching none does **not** mean IGNORE — first run the selector safety net: ma
 
 Build a detection list first: for each matched diff line, write one line: \`{pattern type} — "{diff line}" — affects {route/component}\`.
 
+**Visual-snapshot baselines.** A test that calls \`toHaveScreenshot("<name>.png")\` pixel-compares a page, element, or region against a committed baseline PNG. For such a test only — this does not widen the detection list for any other test — also treat as a reaching change any appearance edit inside what the call captures: a CSS/Tailwind/styled-components change, a changed literal string that renders, a swapped image or icon, a reordered or added visible element. When such a change reaches what one of those calls captures, the baseline is stale — the assertion's expected value is the image, and it must be refreshed exactly as a text assertion would be corrected. Assign **UPDATE** and list the affected baseline filenames in \`rebaselineSnapshots\` (only those whose captured page/element/region the diff reaches — an unaffected baseline in the same spec stays as it is). The refresh happens at execution via \`skyramp_execute_test\`'s \`rebaselineSnapshots\`; never edit the \`toHaveScreenshot()\` call, raise \`maxDiffPixelRatio\`, delete the assertion, or hand-edit a PNG to make it pass — those hide real regressions. When a pre-edit run reports \`Screenshot comparison failed\` and NO diff line explains the mismatch for that capture, the baseline is not stale: leave the test as it is, keep it \`Fail\`, and record the finding in \`issuesFound\`.
+
 **Rules (assign exactly one action per test; severity order above):**
 - **DELETE** when the test's target is gone: all routes/pages it covers no longer exist; all critical selectors were removed with no migration path; or, for a component/widget test, the component it renders was deleted (source removed with no re-export; report-only for external tests).
 - **REGENERATE** when the interaction model changed so fundamentally that the test's action sequence is broken with no migration path: the flow itself changed, not just selector values (e.g. a form replaced by a modal, buttons replaced by a dropdown, a click-to-update button replaced by an auto-updating stepper). Re-recording from scratch is the only viable approach. Broken-selector count alone does not decide REGENERATE; if the flow still works with targeted edits, it is UPDATE.
-- **UPDATE** when the test's flow still holds but something it relies on shifted on a page or component it exercises: a selector (className, data-testid, aria-*) was renamed or moved, a new selector was added that the test should adopt or assert (including a dynamic class like \`+ \`btn--\${variant}\`\`), or an assertion needs adjusting. Fix it in place in the existing file, never a new spec for the same page or component. An added selector is still drift, not a no-op. Read the test/POM to confirm the component is targeted and prefer UPDATE; fall back to VERIFY only when reading leaves impact undetermined.
+- **UPDATE** when the test's flow still holds but something it relies on shifted on a page or component it exercises: a selector (className, data-testid, aria-*) was renamed or moved, a new selector was added that the test should adopt or assert (including a dynamic class like \`+ \`btn--\${variant}\`\`), an assertion needs adjusting, or a \`toHaveScreenshot()\` baseline captures something whose appearance the diff changed (see **Visual-snapshot baselines** above — name the stale files in \`rebaselineSnapshots\`). Fix it in place in the existing file, never a new spec for the same page or component. An added selector is still drift, not a no-op. Read the test/POM to confirm the component is targeted and prefer UPDATE; fall back to VERIFY only when reading leaves impact undetermined.
 - **VERIFY** when the test may be impacted but you cannot confirm breakage without reading more context (e.g. the affected selectors live in a page object or indirect import you have not read). Read that file before escalating to UPDATE.
 - **IGNORE** when the changed code cannot reach this test's routes or rendered components (the diff touches different routes or components). If you cannot point to a diff line affecting this test's routes, selectors, or rendered components, the action is IGNORE or VERIFY, not UPDATE.
 </ui_decision_rules>`;
@@ -182,6 +185,7 @@ Test: {testFile}
 Action: UPDATE
 Rationale: UPDATE because {quoted diff line}; name the concrete before→after value (e.g. data-testid "old-id" → "new-id", class "btn-old" → "btn-new", route "/old" → "/new") — this rationale is the report's record of what was maintained, so a vague "selector changed" is not enough
 UpdateInstructions: {what must change — specific selectors to update, routes to patch, assertions to add}
+RebaselineSnapshots: {only when a toHaveScreenshot() baseline captures what the diff visibly changed — the stale filenames, e.g. ["page-001.png"]; omit otherwise}
 \`\`\`
 \`\`\`
 Test: {testFile}

package/build/prompts/test-recommendation/diffExecutionPlan.d.ts

@@ -1,25 +1,8 @@
-import { DraftedScenario } from "../../types/RepositoryAnalysis.js";
-import { Novelty, PriorityTier } from "../../types/TestRecommendation.js";
-/** "0" — Code Review: correctness analysis */
-export declare const EXEC_STEP_CODE_REVIEW: string;
-/** "1" — External test coverage verification */
-export declare const EXEC_STEP_COVERAGE: string;
-/** "2" — Parameter grounding & priority assignment */
+/** "0" — Parameter grounding: the source values every tool call is filled from */
 export declare const EXEC_STEP_ENRICH: string;
-/** "3" — Diversity check */
-export declare const EXEC_STEP_DIVERSITY: string;
-/** "4" — Execute merged plan */
-export declare const EXEC_STEP_EXECUTE: string;
-/** "5" — Register test plan (SKYR-3879 Path B checkpoint) */
-export declare const EXEC_STEP_REGISTER: string;
-export declare function buildExecutionPlan(scored: Array<{
-    scenario: DraftedScenario;
-    priority: PriorityTier;
-    novelty: Novelty;
-}>, maxGen: number, topN: number, baseUrl: string, authHeaderValue: string, authSchemeSnippet: string, authTypeValue: string, seed: string, endpointCount: number, isUIOnlyPR: boolean, hasFrontendChanges?: boolean, hasTraces?: boolean, externalCoverage?: Set<string>, relevantExternalTestPaths?: string[], 
 /**
- * Whether the diff classified at least one new/modified/removed endpoint.
- * Defaults to true so existing callers keep the fixed-budget rendering.
- * See buildScopeAssessmentSection's hasClassifiedApiChanges (SKYR-3820).
+ * The generation half of the recommendation prompt. What to test and how to
+ * declare it is the planning procedure's job; this renders only how to fill a
+ * generation tool call once the plan is submitted.
  */
-hasApiChanges?: boolean): string;
+export declare function buildExecutionPlan(hasTraces?: boolean, isDiffScope?: boolean): string;