@skyramp/mcp 0.4.2-rc.2 → 0.4.2-rc.3

package/build/tools/generate-tests/generateE2ERestTool.d.ts

@@ -7,7 +7,6 @@ export declare class E2ETestService extends TestGenerationService {
     protected buildGenerationOptions(params: BaseTestParams & {
         responseData?: string;
         playwrightInput?: string;
-        testName?: string;
     }): any;
     protected handleApiAnalysis(_params: BaseTestParams): Promise<CallToolResult | null>;
 }

package/build/tools/generate-tests/generateE2ERestTool.js

@@ -1,5 +1,5 @@
 import { z } from "zod";
-import { baseSchema, baseTraceSchema, TestType, codeRefactoringSchema, testNameField, } from "../../types/TestTypes.js";
+import { baseSchema, baseTraceSchema, TestType, codeRefactoringSchema, } from "../../types/TestTypes.js";
 import { TestGenerationService, } from "../../services/TestGenerationService.js";
 import { AnalyticsService } from "../../services/AnalyticsService.js";
 import { toolError } from "../../utils/utils.js";
@@ -16,7 +16,6 @@ const e2eTestSchema = {
         "from a Playwright zip that already produced one is rejected — one recording covers one scenario, and reusing " +
         "it manufactures identical tests under names the recording never covered. Set true only when the same " +
         "recording genuinely covers the new scenario end-to-end."),
-    testName: testNameField("testE2e"),
     ...codeRefactoringSchema.shape,
     ...baseSchema.shape,
 };
@@ -29,11 +28,6 @@ export class E2ETestService extends TestGenerationService {
             ...super.buildBaseGenerationOptions(params),
             responseData: params.responseData,
             playwrightInput: params.playwrightInput,
-            // SKYR-4468: free-form title for the generated test, so the spec names the
-            // behaviour it verifies instead of the generic `testE2e`. The option is
-            // inert until the pinned @skyramp/skyramp release carries it — the client
-            // ignores options it does not know, so passing it early is safe.
-            testName: params.testName,
         };
     }
     async handleApiAnalysis(_params) {
@@ -50,8 +44,6 @@ End-to-End tests validate complete user journeys by testing the entire applicati
 TRACE & UI INTEGRATION:
 E2E tests require both trace files (capturing backend API interactions) and Playwright recordings (capturing UI interactions captured using start_trace_collection tool) to generate comprehensive tests that validate the complete user experience.
 
-**Test title:** Pass \`testName\` with the behaviour this recording verifies (e.g. "Add to cart from search results"), taken from the recommendation the recording came from. Omit it and the spec is titled \`testE2e\`, which claims nothing.
-
 **CRITICAL - When using trace parameter:**
 If \`trace\` parameter is provided (path to a trace file), DO NOT pass \`apiSchema\` or \`endpointURL\` parameters. The trace file already contains all necessary endpoint and schema information. Passing both will cause test generation to fail.`,
         inputSchema: e2eTestSchema,

package/build/tools/generate-tests/generateUIRestTool.d.ts

@@ -8,7 +8,6 @@ export declare class UITestService extends TestGenerationService {
     protected buildGenerationOptions(params: BaseTestParams & {
         playwrightInput?: string;
         uniqueUIFormInputs?: string[];
-        testName?: string;
     }): any;
     protected handleApiAnalysis(_params: BaseTestParams): Promise<CallToolResult | null>;
     generateTest(params: BaseTestParams & Record<string, any>): Promise<CallToolResult>;
@@ -20,7 +19,6 @@ export declare const uiTestSchema: {
     include: z.ZodOptional<z.ZodDefault<z.ZodArray<z.ZodString, "many">>>;
     exclude: z.ZodOptional<z.ZodDefault<z.ZodArray<z.ZodString, "many">>>;
     uniqueUIFormInputs: z.ZodOptional<z.ZodArray<z.ZodString, "many">>;
-    testName: z.ZodOptional<z.ZodString>;
     output: z.ZodEffects<z.ZodOptional<z.ZodString>, string | undefined, string | undefined>;
     outputDir: z.ZodString;
     force: z.ZodDefault<z.ZodBoolean>;

package/build/tools/generate-tests/generateUIRestTool.js

@@ -1,4 +1,4 @@
-import { baseSchema, languageSchema, TestType, codeRefactoringSchema, baseTraceSchema, testNameField, } from "../../types/TestTypes.js";
+import { baseSchema, languageSchema, TestType, codeRefactoringSchema, baseTraceSchema, } from "../../types/TestTypes.js";
 import { z } from "zod";
 import { AnalyticsService } from "../../services/AnalyticsService.js";
 import { TestGenerationService, } from "../../services/TestGenerationService.js";
@@ -21,11 +21,6 @@ export class UITestService extends TestGenerationService {
             // SKYR-4012: create-form inputs the agent flagged as unique-constrained,
             // so Skyramp codegen types a per-run-unique value into them.
             uniqueUIFormInputs: params.uniqueUIFormInputs,
-            // SKYR-4468: free-form title for the generated test, so the spec names the
-            // behaviour it verifies instead of the generic `testUi`. The option is
-            // inert until the pinned @skyramp/skyramp release carries it — the client
-            // ignores options it does not know, so passing it early is safe.
-            testName: params.testName,
         };
     }
     async handleApiAnalysis(_params) {
@@ -91,7 +86,6 @@ export const uiTestSchema = {
         .array(z.string().min(1))
         .optional()
         .describe("Create-form inputs whose value is UNIQUE-constrained (e.g. a name/slug that the backend rejects as a duplicate). Identify each by the accessible label or selector you typed into during recording (the same value passed to getByLabel/getByPlaceholder/getByRole, or a raw selector). Skyramp types a per-run-unique value into these inputs — and reuses it in later assertions — so the generated UI test can be re-run without hitting a duplicate/conflict error. Inspect the app's data model for unique constraints; omit when no create-form field is unique-constrained."),
-    testName: testNameField("testUi"),
     output: baseSchema.shape.output,
     outputDir: baseSchema.shape.outputDir,
     force: baseSchema.shape.force,
@@ -129,8 +123,6 @@ This tells you exactly which frontend files changed so you record traces for the
 
 **Idempotency (re-runnable create flows):** If the recorded flow creates a resource by typing into a UNIQUE-constrained field (a name/slug the backend rejects as a duplicate on a second run), pass those inputs in \`uniqueUIFormInputs\`. Skyramp then types a per-run-unique value into them (and reuses it in later assertions) so the generated test can be re-run without a duplicate/conflict failure.
 
-**Test title:** Pass \`testName\` with the behaviour this recording verifies (e.g. "Add to cart from search results"), taken from the recommendation the recording came from. Omit it and the spec is titled \`testUi\`, which claims nothing.
-
 **DOM Analyzer tools for blueprint-aware recording:** alongside the basic \`browser_*\` interaction tools, the Skyramp MCP exposes \`browser_blueprint\` (canonical PageBlueprint capture). This enables semantic target selection and delta-derived assertions: capture a blueprint before each meaningful action, perform the action, then capture again — the delta between the two grounds your assertions in observable state changes rather than author guesses about what "success" looks like.
 
 **CRITICAL: Do NOT use skyramp_start_trace_collection/skyramp_stop_trace_collection for UI test recording — use browser_* tools + skyramp_export_zip instead.**`,

package/build/types/TestTypes.d.ts

@@ -255,13 +255,6 @@ export declare const codeRefactoringSchema: z.ZodObject<{
     codeReuse?: boolean | undefined;
     modularizeCode?: boolean | undefined;
 }>;
-/** The `testName` field for a recording-driven generation tool.
- *
- *  Single-sourced because the description is prompt text: it is the only thing
- *  steering the agent's choice of title, it gets re-tuned against eval results,
- *  and two copies would let the UI and E2E tools drift apart silently. Each
- *  tool passes the title its own generator falls back to (SKYR-4468). */
-export declare const testNameField: (fallbackTitle: string) => z.ZodOptional<z.ZodString>;
 /** Test types skyramp_enhance_assertions supports — single-sourced so the
  *  tool's schema enum and generation-time baseline seeding cannot drift
  *  (contract additionally requires provider mode at the seeding site). */

package/build/types/TestTypes.js

@@ -291,26 +291,6 @@ export const codeRefactoringSchema = z.object({
         .default(false)
         .describe("Whether to modularize the code"),
 });
-/** The `testName` field for a recording-driven generation tool.
- *
- *  Single-sourced because the description is prompt text: it is the only thing
- *  steering the agent's choice of title, it gets re-tuned against eval results,
- *  and two copies would let the UI and E2E tools drift apart silently. Each
- *  tool passes the title its own generator falls back to (SKYR-4468). */
-export const testNameField = (fallbackTitle) => z
-    .string()
-    // .trim() normalises incidental whitespace and, combined with .min(1),
-    // rejects a whitespace-only title, which would otherwise produce a
-    // meaningless test title and identifier (SKYR-4468).
-    .trim()
-    .min(1)
-    .optional()
-    .describe("Title for the generated test. Name the BEHAVIOUR this recording verifies, " +
-    "taken from the recommendation the recording came from — not the page it happens on. " +
-    'Example: "Add to cart from search results", not "Search page". ' +
-    "Skyramp emits it verbatim as the Playwright test title for TypeScript/JavaScript, " +
-    "and as a snake_case `def test_<name>` identifier for Python. " +
-    `Omit it and the test stays titled \`${fallbackTitle}\`, which claims nothing.`);
 /** Test types skyramp_enhance_assertions supports — single-sourced so the
  *  tool's schema enum and generation-time baseline seeding cannot drift
  *  (contract additionally requires provider mode at the seeding site). */

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@skyramp/mcp",
-  "version": "0.4.2-rc.2",
+  "version": "0.4.2-rc.3",
   "main": "build/index.js",
   "exports": {
     ".": "./build/index.js",

package/plugin/skills/enhance-assertions/reference/shared-rules.md

@@ -26,7 +26,7 @@ Apply only to new test functions you are adding and existing test functions affe
 
 Before editing `$2`, you must output a `<thinking>` block. It states the behaviour each test evaluates, then works through the rules for the responses that behaviour depends on, so no rule that applies is overlooked. The JSON array must match the `rule_checklist` template that accompanies the `$0` rules. Use the template's keys verbatim; each key is the slug shown in that rule's heading. Every key must appear — `[]` where the rule does not apply.
 
-1. For each test function in scope, name the behaviour it evaluates in one line, taken from the recommendation it came from. A generated test function may carry a name that states its behaviour — trust that name when it does. A function still named `test_integration` or `testUi` claims nothing, so use the name only when it is specific enough to add something, and never treat a generic one as evidence the test has no single behaviour. Then scan `$2` and the expected responses for the code change tested.
+1. For each test function in scope, name the behaviour it evaluates in one line, taken from the recommendation it came from. Generated test functions are usually named `test_integration` or `testUi`, which claim nothing — use the name only when it is specific enough to add something, and never treat a generic one as evidence the test has no single behaviour. Then scan `$2` and the expected responses for the code change tested.
 2. Classify each response first by its response status type and then assign the applicable assertion rules to the response.
    - Success with body (2xx with a response body): all assertion rules below may apply — echo-back of request fields, computed response fields, array / items validation, and chained values across steps.
    - Success with no body (200/202/204 with an empty body — e.g. logout/cancel/submit action endpoints): assert the status code only. Also apply chained-values rules if a follow-up step uses this response's ID.

package/plugin/skills/enhance-assertions/reference/ui.md

@@ -126,7 +126,7 @@ if (await existingSecret.isVisible().catch(() => false)) {
 
 Before editing `$2`, you must output a `<thinking>` block. It states the behaviour each test evaluates, then works through the rules for the items that behaviour depends on, so no rule that applies is overlooked. The JSON array should match the template below — every assertion category and every rule title under it must appear as a key, with `[]` where the rule does not apply.
 
-1. For each test in scope, name the behaviour it evaluates in one line, taken from the recommendation it came from, and name the page where that behaviour shows. A generated spec may carry a title that names its behaviour — trust that title when it does. A spec still named `testUi` claims nothing, so use the name only when it is specific enough to add something.
+1. For each test in scope, name the behaviour it evaluates in one line, taken from the recommendation it came from, and name the page where that behaviour shows. Generated specs are usually named `testUi`, which claims nothing — use the name only when it is specific enough to add something.
 2. Selector inventory — list every selector already present in `$2` (`data-testid`, role + name, text, label, etc.). New assertions may use only selectors from this list. An assertion the recorder dropped because it failed during recording may use the selector of the element named in that recording's blueprint capture. Do not invent `data-testid` values, role names, or aria attributes. Also note captured network responses, repeated element patterns, exact rendered text/value/attribute from trace/source, and existing `toBeVisible()` assertions whose exact text is knowable.
 3. Process — Replay → Identify → Fix or Add — walk through these three steps explicitly.
    a. Replay the scenario mentally. At each state-changing action (form submit, item add/edit/delete), ask: "What is the EXPECTED outcome based on the action performed?"