@skyramp/mcp 0.0.64-rc.13 → 0.0.64-rc.14

package/build/prompts/test-maintenance/drift-analysis-prompt.js

@@ -6,9 +6,9 @@ export function buildDriftAnalysisPrompt(params) {
     let diffSection = "";
     if (parsedDiff) {
         const lines = parsedDiff.split("\n");
-        const epMatches = parsedDiff.match(/(?:^|\n)\*\*(GET|POST|PUT|PATCH|DELETE)\s+[^\*]+\*\*/gm);
-        if (epMatches)
-            newEndpointCount = epMatches.length;
+        const newEndpointMatch = parsedDiff.match(/\*\*New Endpoints\*\*\s+\((\d+)\)/);
+        if (newEndpointMatch)
+            newEndpointCount = parseInt(newEndpointMatch[1], 10);
         diffSection = `## Branch Diff
 \`\`\`
 ${lines.slice(0, 200).join("\n")}

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

@@ -136,6 +136,12 @@ Execute every UPDATE, DELETE, and REGENERATE decision from Step 2 regardless of
 ### UPDATE
 Edit the existing test file directly:
 - Add missing assertions for new response fields (e.g. \`assert "archived" in resp\` or \`assert resp["archived"] >= 0\`).
+- **Enhance assertions** for new response fields touched by the diff (integration and contract-provider tests — MANDATORY, no step exempt):
+  - **Every step**: assert non-null IDs, echo-back values, and value ranges. Echo-back must use the value sent in the *current* step's request — use the \`data_override\` source if set, otherwise the hardcoded literal. For example: if the request updated \`customer_email\` to \`"updated@mail.com"\`, assert \`get_response_value(response, "customer_email") == "updated@mail.com"\`; same for \`status\` (e.g. \`== "confirmed"\`) and \`discount_type\`/\`discount_value\` (e.g. \`== "percentage"\`, \`== 10.0\`).
+  - **Create/modify steps**: also assert computed/derived fields (e.g. \`total_amount\`, \`discount_amount\`) by tracing inputs through all prior responses. In integration tests, use dynamic chained values (e.g. \`get_response_value(product_response, "price") * quantity\`); in contract tests, use the hardcoded literals from the request body and expected response (e.g. \`assert total_amount == 19.99 * 2\`).
+  - **Read steps**: re-assert chained and computed fields — do not reduce to null-checks only.
+  - **Array fields**: only assert indices that exist in the recorded response body — never infer array length from the request or scenario name. Use the \`expected_response_body\` as the source of truth for which indices to assert. For example: if \`expected_response_body\` defines \`items[0]\` with \`product_id: 1\` and \`quantity: 3\`, assert \`get_response_value(response, "items.0.product_id") == 1\` and \`get_response_value(response, "items.0.quantity") == 3\` — do not assert \`items[1]\` if it does not exist in the expected response body.
+  - **Parity**: every assertion derivable from the request body or response (non-null, echo-back, value ranges, computed) must appear in both the contract test and the integration test independently.
 - Fix path/method changes in the test.
 - **When adding a new method to an existing resource:** Add the new method's test cases to the existing test file that covers that resource path (e.g. adding POST to a file that already tests GET /products). This applies to ALL existing test files for that resource — contract, integration, UI — not just the one the GENERATE plan names.
 - **Happy path first (CRITICAL):** When adding a new HTTP method (PUT, PATCH, POST) to an existing test file, always include the happy path (2xx success) assertion. Do NOT add only an error-path test (e.g. 404, 422) for the new method — error cases may follow, but the happy path is mandatory.
@@ -215,10 +221,10 @@ Do NOT use \`page.waitForTimeout()\` with fixed delays — these are flaky in CI
 **After generation, you MUST do exactly these steps — nothing more, nothing less:**
 1. **Fix chaining**: replace hardcoded IDs with dynamic response values — path params like \`id = 'id'\` → \`skyramp.get_response_value(prev_response, "id")\`, and hardcoded IDs in request bodies → dynamic values from prior responses.
 2. **Enhance assertions** (integration and contract tests — MANDATORY, no step exempt):
-   - **Every step**: assert non-null IDs, echo-back values, and value ranges. Echo-back must use the value sent in the *current* step's request — use the \`data_override\` source if set, otherwise the hardcoded literal.
+   - **Every step**: assert non-null IDs, echo-back values, and value ranges. Echo-back must use the value sent in the *current* step's request — use the \`data_override\` source if set, otherwise the hardcoded literal. For example: if the request set \`customer_email\` to \`"updated@mail.com"\`, assert \`get_response_value(response, "customer_email") == "updated@mail.com"\`; same for \`status\` (e.g. \`== "confirmed"\`) and \`discount_type\`/\`discount_value\` (e.g. \`== "percentage"\`, \`== 10.0\`).
    - **Create/modify steps**: also assert computed/derived fields (e.g. \`total_amount\`, \`discount_amount\`) by tracing inputs through all prior responses. In integration tests, use dynamic chained values (e.g. \`get_response_value(product_response, "price") * quantity\`); in contract tests, use the hardcoded literals from the request body and expected response (e.g. \`assert total_amount == 19.99 * 2\`).
    - **Read steps**: re-assert chained and computed fields — do not reduce to null-checks only.
-   - **Array fields**: only assert indices that exist in the recorded response body — never infer array length from the request or scenario name.
+   - **Array fields**: only assert indices that exist in the recorded response body — never infer array length from the request or scenario name. Use the \`expected_response_body\` as the source of truth for which indices to assert. For example: if \`expected_response_body\` defines \`items[0]\` with \`product_id: 1\` and \`quantity: 3\`, assert \`get_response_value(response, "items.0.product_id") == 1\` and \`get_response_value(response, "items.0.quantity") == 3\` — do not assert \`items[1]\` if it does not exist in the expected response body.
    - **Parity**: every assertion derivable from the request body or response (non-null, echo-back, value ranges, computed) must appear in both the contract test and the integration test independently.
 3. **Enhance UI test assertions**: for UI tests, refer back to your business logic analysis from Step 2 (code review) and the \`issuesFound\` you logged. Add assertions that catch real user-facing bugs:
    - **Page renders after navigation**: after clicking a button that navigates (e.g. "Edit Order"), assert that the target page loaded its expected heading or key element. A blank page or missing heading means a rendering crash.