@skyramp/mcp 0.1.0 → 0.1.2

package/build/prompts/enhance-assertions/contractProviderAssertionsPrompt.js

@@ -1,110 +1,28 @@
-import { getPersonaPrefix } from "../personas.js";
-export const CONTRACT_PROVIDER_ASSERTIONS_PROMPT = `${getPersonaPrefix()}Your task is to enhance assertions for the given contract-provider test.
-Rules 1–9 apply to success-path responses (2xx with a body). Rule 10 covers 4xx/5xx with a body and no-body responses (e.g. DELETE 204).
-
-### Top Priorities
-You MUST output a \`<thinking>\` block that explicitly confirms each of these for the file:
-1. Echo-back EVERY request body field with the exact sent value (no \`is not None\` for sent values)
-2. Stable response values — covers BOTH request-mirrored fields AND response-only fields (e.g. \`filename_download\`, \`type\`, \`size\`, \`url\`); use exact assertions, NOT \`>= 0\`, type-only, or null-only checks
-3. **Status code matches the recorded/expected response exactly** — if the expected response is \`201\`, assert \`201\`, not a default \`200\`/\`20x\`
-4. Every array (data and error): per-item field + next-index-null guard. **Empty-array handling**: if \`expected_response_body\` shows \`[]\`, assert \`length == 0\` AND \`data[0]\` is null — do NOT add per-item field assertions on indices that do not exist (e.g. \`data.0.id is not None\` on an empty array is vacuous and forbidden)
-5. All asserted values come from inline request body literals; no \`beforeAll\` provisioning data
-6. Computed numeric fields use the exact pre-computed value from \`expected_response_body\`; never hardcoded without it
-7. **Query-param constraints reflected in the response** — when the request includes \`limit\`, \`pageSize\`, \`offset\`, \`page\`, \`since\`, \`until\`, or \`filter\`, assert the response satisfies that constraint (array length \`<=\` limit, pagination metadata matches, filter values pass the predicate)
-8. 4xx/5xx with a response body: exact values for every error-body field; status-only is NEVER sufficient
-
-### SDK Helpers
-**IMPORTANT — How to access response body fields (use the SDK helpers already available in the generated file, NOT dict/attribute access on the response variable):**
-| Language | Helper |
-|----------|--------|
-| Python | \`skyramp.get_response_value(response, "json.path")\` |
-| TypeScript / JavaScript | Use the existing imported SDK JSON-path helper in the file: typically \`getValue(response, "json.path")\` or \`getResponseValue(response, "json.path")\` from \`@skyramp/skyramp\` |
-| Java | \`getValue(response, "json.path")\` |
-
-### What Not to Do — any of these is a violation
-- Do NOT access response fields via dict syntax (\`response["field"]\`) or attribute access (\`response.field\`).
-- Do NOT change imports solely to swap between \`getValue\` and \`getResponseValue\` — keep whichever SDK helper the generated file already imports.
-- Do NOT assert \`is not None\` / \`.not.toBeNull()\` on a field whose exact value was sent in the request body.
-- Do NOT remove or modify existing assertions.
-- Do NOT add assertions for **genuinely unpredictable** fields only (random tokens, opaque server-generated IDs without a known format, timestamps without a fixed format). This is NOT a license to skip body assertions on success responses or 4xx/5xx error bodies — every field present in \`expected_response_body\` IS inferable and MUST be asserted.
-- Do NOT use permissive status matchers — never \`checkStatusCode(response, '20x')\`, \`.toMatch(/^2/)\`, \`.toBeGreaterThanOrEqual(200)\`, or any range/pattern check on the status code. Always assert the exact status code from \`expected_response_body\` (e.g. \`expect(response.statusCode).toBe(204)\`).
-- Do NOT use type-only or shape-only assertions as a substitute for content validation. Specifically forbidden: \`Array.isArray(...)\`, \`typeof X === 'number'/'string'/'boolean'/'object'\`, \`X instanceof Array\`, \`Object.keys(X).length > 0\`. When \`expected_response_body\` shows actual values or items, assert exact values (scalars) and per-item fields + exact length (arrays).
-- Do NOT restructure, reformat, or reorder existing code.
-- Do NOT add comments or docstrings.
-- Do NOT change function signatures, imports, or variable names.
-- Do NOT touch \`beforeAll\`, \`afterAll\`, or setup/teardown helpers — only modify test functions.
-- Do NOT reference \`beforeAll\` provisioning data in assertions. Use inline request body literals for all fields.
-
-### Assertion Rules [MANDATORY]
-1. **Echo-back EVERY request body field** with the exact sent value.
-   ❌ BAD: \`expect(getValue(response, "name")).not.toBeNull()\`
-   ✅ GOOD: \`expect(getValue(response, "name")).toBe("Skyramp Tester")\`
-
-2. **Stable response values** — assert exact values for ALL stable response fields. Covers BOTH:
-   - **Response-only fields** (e.g. \`filename_download\`, \`type\`, \`size\`, \`url\`, \`mime_type\`) present in \`expected_response_body\` — do NOT stop at \`data.id is not None\` for resource responses
-   - **Counts, booleans, status, enums** — never \`>= 0\`, type-only, or null-only checks
-
-   ❌ BAD (range matcher on a known scalar): \`expect(getValue(response, "count")).toBeGreaterThanOrEqual(0)\`
-   ✅ GOOD: \`expect(getValue(response, "count")).toBe(3)\`
-
-   ❌ BAD (resource response with only id asserted): \`expect(getValue(response, "data.id")).not.toBeNull()\`
-   ✅ GOOD: also assert response-only stable fields, e.g. \`expect(getValue(response, "data.filename_download")).toBe("invoice.pdf"); expect(getValue(response, "data.type")).toBe("application/pdf")\`
-
-   ❌ BAD (type-only on a scalar, exact value ignored): \`expect(typeof getValue(response, "total_count")).toBe("number")\`
-   ✅ GOOD: \`expect(getValue(response, "total_count")).toBe(<exact count from expected_response_body>)\`
-
-3. **Server-generated IDs** — \`is not None\` only.
-4. **Status code from expected response** — assert the exact status code from \`expected_response_body\` (e.g. \`201\` for create endpoints), not a generic \`200\` or \`20x\`.
-   ❌ BAD (default status code, ignoring the expected response which is \`201\`): \`expect(response.statusCode).toBe(200)\`
-   ✅ GOOD: \`expect(response.statusCode).toBe(201)\`
-
-   ❌ BAD (permissive status matcher hides the exact code and skips body assertions): \`checkStatusCode(response, "20x")\` or \`expect(response.statusCode.toString()).toMatch(/^2/)\`
-   ✅ GOOD: \`expect(response.statusCode).toBe(204)\` — exact code from \`expected_response_body\`, then add the body field assertions on top
-
-5. **Arrays** — for every array (data and error):
-   - **Empty array in expected response** (\`data: []\`) → assert exact \`length == 0\` AND \`data[0]\` is null/None. NEVER assert \`data.0.<field> is not None\` on an empty array — this is vacuous and forbidden.
-   - **Non-empty array in expected response** → assert exact count (or count field), each present item's key fields, next index is null/None
-   - if \`orderBy\`/\`sort\` is set, assert ordering across the first two items
-   - **Shape-only check is NEVER sufficient** — \`Array.isArray(getValue(response, "results"))\` does not validate contents. When \`expected_response_body\` contains items, you MUST assert exact length AND per-item key fields, even if \`Array.isArray\` already passes.
-
-   ❌ BAD (vacuous null-check on an empty-array expected response, where \`data: []\`): \`expect(getValue(response, "data.0.id")).not.toBeNull()\`
-   ✅ GOOD: \`expect(getValue(response, "data").length).toBe(0); expect(getValue(response, "data.0")).toBeUndefined()\`
-
-   ❌ BAD (shape-only check on a list endpoint, items never validated): \`expect(Array.isArray(getValue(response, "results"))).toBe(true)\`
-   ✅ GOOD: \`expect(getValue(response, "results").length).toBe(2); expect(getValue(response, "results.0.id")).toBe(<exact id from expected_response_body>); expect(getValue(response, "results.0.title")).toBe(<exact title>); expect(getValue(response, "results.2")).toBeUndefined()\`
-
-6. **Computed numeric fields** — use the exact pre-computed value from \`expected_response_body\` directly; never hardcode without it.
-   ❌ BAD (hardcoded without checking expected_response_body): \`expect(getValue(response, "total_amount")).toBe(29.99)\`
-   ✅ GOOD: use the exact value from \`expected_response_body\`
-
-7. **Format/type** — dates, UUIDs, enums get pattern or type assertions, not just \`is not None\`.
-8. **Parity** — every assertion derivable from the request/response must appear independently in both the contract and integration tests.
-9. **Query-param constraints** — when the request URL includes \`limit\`, \`pageSize\`, \`offset\`, \`page\`, \`since\`, \`until\`, or \`filter\`, the response MUST be asserted against that constraint:
-   - \`limit=N\` → assert returned array length \`<=\` N (or exactly N when \`expected_response_body\` shows it filled)
-   - \`offset=N\` → assert pagination metadata reflects N
-   - \`filter=k=v\` → assert every returned item satisfies the predicate
-
-   ❌ BAD (\`?limit=10\` request, response length never asserted): \`expect(getValue(response, "data")).not.toBeNull()\`
-   ✅ GOOD: \`expect(getValue(response, "data").length).toBeLessThanOrEqual(10)\`  (use \`.toBe(10)\` if \`expected_response_body\` shows the limit was filled)
-
-10. **Error-path** — for every 4xx/5xx with a response body, assert every error body field with exact values (\`error.code\`, \`error.message\`, \`detail\`, \`invalid_rows\`, etc.). Apply rule 5 to error arrays. No-body responses (DELETE 204): assert status code only.
-    ❌ BAD (status only, error body never inspected): \`expect(getValue(response, "detail")).not.toBeNull()\`
-    ✅ GOOD: \`expect(getValue(response, "detail")).toBe("Use POST /api/flow_runs/{id}/stop")\`
-
-### Verification of enhanced assertions
-1. Every request body field has an exact-value assertion or a documented server-generated reason
-2. No \`is not None\` / \`.not.toBeNull()\` on any field whose exact value was sent in the request
-3. All stable response values (request-mirrored AND response-only — \`filename_download\`, \`type\`, \`size\`, etc., AND counts/booleans/enums) use exact assertions — no leftover \`>= 0\` or type-only checks
-4. Status code asserted matches \`expected_response_body\` exactly (e.g. \`201\` not a default \`200\`)
-5. Every non-empty array has per-item field + next-index-null-guard assertions; every empty-array expected response asserts \`length == 0\` with no per-item field assertions on missing indices
-6. No shape-only or type-only checks remain — every \`Array.isArray(...)\`, \`typeof X === '...'\`, \`instanceof Array\`, or \`Object.keys(...).length > 0\` has been replaced with exact value and per-item field assertions when \`expected_response_body\` contains data
-7. If \`orderBy\`/\`sort\` is set, ordering direction asserted across the first two items
-8. No references to \`beforeAll\` provisioning data — all values inline
-9. Computed fields use exact pre-computed value from \`expected_response_body\`
-10. Format/type fields (dates, UUIDs, enums) asserted with pattern or type check — not just \`is not None\`
-11. Query-param constraints (\`limit\`, \`pageSize\`, \`offset\`, \`filter\`) reflected in response assertions
-12. Every 4xx/5xx with a body has exact error-body assertions; status-only is never used
-13. All field access uses SDK helpers; no dict/attribute access; no import swaps
-
-An item passes verification only when the assertion is present AND is a good assertion per the rules above. If any item is not satisfied — assertion missing, OR present but a bad assertion — add or fix it per the rules before completing, preferring the strongest applicable assertion for the scenario.
-`;
+import { getAssertionsPrompt, } from "./sharedAssertionRules.js";
+const specificRules = [
+    {
+        title: "Chained values from inline request data",
+        description: "Every value used in an assertion must come from what is written inline in the test function — the request body, path, or query parameters.",
+        subPoints: [
+            "Do not reference data set up in `beforeAll` or any other setup helper.",
+            "When an ID was sent in the request body, path, or query, assert its exact value in the response. Since the sent value is already known, asserting only that it is non-null is not sufficient.",
+            "Reserve `is not None` / `not.toBeNull()` for server-generated IDs only.",
+            "Apply the same rule to all other fields and to array items: use inline request body values as the expected values, not setup helper data.",
+            "Every assertion that can be derived from `expected_response_body`, the inline request body, or path/query literals must appear in this file — do not rely on the integration test to cover it.",
+        ],
+        examples: [
+            {
+                language: "javascript",
+                code: `expect(getResponseValue(productGetResponse, "id"), 'id').toBe(getResponseValue(productsPostResponse, "id"));`,
+            },
+        ],
+    },
+];
+const SCOPE = `### Scope
+- Only modify test functions — do not touch \`beforeAll\`, \`afterAll\`, or any setup or teardown helper.
+- Only add assertions clearly supported by \`expected_response_body\`, inline request / path / query literals, codebase evidence, or the test generation recommendations received for this test. Do not invent constraints.
+- Add new assertions immediately after the existing status-code assertion — do not move or remove anything.
+- Do not reference \`beforeAll\` / \`afterAll\` provisioning data in any assertion — every assertion value must come from the inline request body, path, query, prior response, or \`expected_response_body\`.`;
+export function getContractProviderAssertionsPrompt(testFile, enhanceType) {
+    return getAssertionsPrompt(specificRules, SCOPE, testFile, enhanceType);
+}

package/build/prompts/enhance-assertions/integrationAssertionsPrompt.js

@@ -1,128 +1,35 @@
-import { getPersonaPrefix } from "../personas.js";
-export const INTEGRATION_ASSERTIONS_PROMPT = `${getPersonaPrefix()}Your task is to enhance assertions for the given integration test.
-Rules 1–12 apply to success-path responses (2xx with a body). Rule 13 covers 4xx/5xx with a body and no-body responses (e.g. DELETE 204).
-
-### Top Priorities
-You MUST output a \`<thinking>\` block that explicitly confirms each of these for the file:
-1. Exact stable values from the recorded response — covers BOTH request-mirrored fields AND response-only fields (e.g. \`filename_download\`, \`type\`, \`size\`, \`url\`); NOT \`>= 0\`, type-only, or null-only checks
-2. **Status code matches the recorded trace exactly** — if the trace recorded \`201\`, assert \`201\`, not a default \`200\`/\`20x\`
-3. Every array (success-path AND error arrays): per-item field assertions + assert next index is null/None. **Empty-array handling**: if the recorded trace shows \`[]\`, assert \`length == 0\` AND \`data[0]\` is null — do NOT add per-item field assertions on indices that do not exist in the trace (e.g. \`data.0.id is not None\` on an empty array is vacuous and forbidden)
-4. POST response IDs chained into every subsequent path param, body, and assertion (no hardcoded IDs)
-5. Non-ID response-derived values (e.g. \`collection\`, \`slug\`, \`role\`) extracted from prior responses, not hardcoded
-6. **Cross-endpoint invariants** — when one endpoint returns a scalar that describes a sibling endpoint's collection (e.g. \`active_session_count\` from \`/users/me\` and the array returned by \`/users/me/sessions\`), assert the relationship by extracting both and comparing — not by hardcoding the same value twice
-7. Read steps re-assert chained values, exact stable values, and computed fields — no null/type/range fallbacks
-8. Computed numeric fields use the source-derived formula from prior responses, never hardcoded numbers
-9. **Query-param constraints reflected in the response** — when the request includes \`limit\`, \`pageSize\`, \`offset\`, \`page\`, \`since\`, \`until\`, or \`filter\`, assert the response satisfies that constraint (array length \`<=\` limit, pagination metadata matches, filter values pass the predicate)
-10. 4xx/5xx with a response body: exact values for every error-body field; status-only is NEVER sufficient
-
-### SDK Helpers
-**IMPORTANT — How to access response body fields (use the SDK helpers already available in the generated file, NOT dict/attribute access on the response variable):**
-| Language | Helper |
-|----------|--------|
-| Python | \`skyramp.get_response_value(response, "json.path")\` |
-| TypeScript / JavaScript | Use the existing imported SDK JSON-path helper in the file: typically \`getValue(response, "json.path")\` or \`getResponseValue(response, "json.path")\` from \`@skyramp/skyramp\` |
-| Java | \`getValue(response, "json.path")\` |
-
-### What Not to Do — any of these is a violation
-- Do NOT access response fields via dict syntax (\`response["field"]\`) or attribute access (\`response.field\`).
-- Do NOT change imports solely to swap between \`getValue\` and \`getResponseValue\` — keep whichever SDK helper the generated file already imports.
-- Do NOT assert \`is not None\` / \`.not.toBeNull()\` on a field whose exact value was sent in the request body.
-- Do NOT remove or modify existing assertions.
-- Do NOT add assertions for **genuinely unpredictable** fields only (random tokens, opaque server-generated IDs without a known format, timestamps without a fixed format). This is NOT a license to skip body assertions on success responses or 4xx/5xx error bodies — every field present in the recorded trace IS inferable and MUST be asserted.
-- Do NOT use permissive status matchers — never \`checkStatusCode(response, '20x')\`, \`.toMatch(/^2/)\`, \`.toBeGreaterThanOrEqual(200)\`, or any range/pattern check on the status code. Always assert the exact status code from the trace (e.g. \`expect(response.statusCode).toBe(204)\`).
-- Do NOT use type-only or shape-only assertions as a substitute for content validation. Specifically forbidden: \`Array.isArray(...)\`, \`typeof X === 'number'/'string'/'boolean'/'object'\`, \`X instanceof Array\`, \`Object.keys(X).length > 0\`. When the trace shows actual values or items, assert exact values (scalars) and per-item fields + exact length (arrays).
-- Do NOT restructure, reformat, or reorder existing code.
-- Do NOT add comments or docstrings.
-- Do NOT change function signatures, imports, or variable names.
-
-### Assertion Rules [MANDATORY]
-1. **Echo-back EVERY request body field** with the exact sent value. \`is not None\` only for genuinely server-generated fields (timestamps, auto-incremented IDs).
-   ❌ BAD: \`expect(getValue(response, "name")).not.toBeNull()\`
-   ✅ GOOD: \`expect(getValue(response, "name")).toBe("Skyramp Tester")\`
-
-2. **Stable response values** — assert exact values for ALL stable response fields. Covers BOTH:
-   - **Response-only fields** (e.g. \`filename_download\`, \`type\`, \`size\`, \`url\`, \`mime_type\`) — do NOT stop at \`data.id is not None\` for resource responses
-   - **Counts, booleans, status, enums** — never \`>= 0\`, type-only, or null-only checks
-
-   ❌ BAD (range matcher on a known scalar): \`expect(getValue(response, "active_session_count")).toBeGreaterThanOrEqual(0)\`
-   ✅ GOOD: \`expect(getValue(response, "active_session_count")).toBe(3)\`
-
-   ❌ BAD (resource response with only id asserted): \`expect(getValue(response, "data.id")).not.toBeNull()\`
-   ✅ GOOD: also assert response-only stable fields, e.g. \`expect(getValue(response, "data.filename_download")).toBe("invoice.pdf"); expect(getValue(response, "data.type")).toBe("application/pdf")\`
-
-   ❌ BAD (type-only on a scalar, exact value ignored): \`expect(typeof getValue(response, "total_count")).toBe("number")\`
-   ✅ GOOD: \`expect(getValue(response, "total_count")).toBe(<exact count from trace>)\`
-
-3. **Status code from trace** — assert the exact status code recorded in the trace (e.g. \`201\` for create endpoints), not a generic \`200\` or \`20x\`. If the trace shows \`201\`, asserting \`200\` is a bug.
-   ❌ BAD (default status code, ignoring the trace which recorded \`201\`): \`expect(response.statusCode).toBe(200)\`
-   ✅ GOOD: \`expect(response.statusCode).toBe(201)\`
-
-   ❌ BAD (permissive status matcher hides the exact code and skips body assertions): \`checkStatusCode(response, "20x")\` or \`expect(response.statusCode.toString()).toMatch(/^2/)\`
-   ✅ GOOD: \`expect(response.statusCode).toBe(204)\` — exact code from the recorded trace, then add the body field assertions on top
-
-4. **Chained IDs** — extract each POST ID once and reuse it in every subsequent step (path params, request bodies, assertions). Compare by value in later GET/PATCH/PUT responses; never null-check a chained ID.
-   ❌ BAD (chained ID null-check): \`expect(getValue(get_response, "data.id")).not.toBeNull()\`
-   ✅ GOOD: \`expect(getValue(get_response, "data.id")).toBe(getValue(post_response, "data.id"))\`
-
-5. **Chained non-ID values** — extract response-driven values (\`collection\`, \`slug\`, \`role\`, etc.) from prior responses; never hardcode reused values.
-   ❌ BAD (hardcoded reused value): \`let collection = "test_coerce_001"\`
-   ✅ GOOD: \`let collection = getValue(collections_post_response, "data.collection")\`
-
-6. **Cross-endpoint invariants** — when one response field encodes the count, identity, or summary of a collection returned by a sibling endpoint, assert the relationship by extracting both values from their respective responses and comparing them. Do not assume the count and the array length will both incidentally match the same hardcoded number.
-   ❌ BAD (count and array length both hardcoded to the same number — no invariant): \`expect(getValue(me_response, "data.active_session_count")).toBe(3); expect(getValue(sessions_response, "data").length).toBe(3);\`
-   ✅ GOOD: \`expect(getValue(sessions_response, "data").length).toBe(getValue(me_response, "data.active_session_count"))\`
-
-7. **Arrays** — for every array (data and error):
-   - **Empty array in trace** (\`data: []\`) → assert exact \`length == 0\` AND \`data[0]\` is null/None. NEVER assert \`data.0.<field> is not None\` on an empty array — this is vacuous and forbidden.
-   - **Non-empty array in trace** → assert exact count (or count field), each present item's key fields, next index is null/None
-   - if \`orderBy\`/\`sort\` is set, assert ordering across the first two items
-   - **Shape-only check is NEVER sufficient** — \`Array.isArray(getValue(response, "results"))\` does not validate contents. When the trace contains items, you MUST assert exact length AND per-item key fields, even if \`Array.isArray\` already passes.
-
-   ❌ BAD (null-check on a session/items array): \`expect(getValue(response, "data")).not.toBeNull()\`
-   ✅ GOOD: assert exact count, per-item fields, and \`data[N]\` is null
-
-   ❌ BAD (vacuous null-check on an empty-array trace, where \`data: []\`): \`expect(getValue(response, "data.0.id")).not.toBeNull()\`
-   ✅ GOOD: \`expect(getValue(response, "data").length).toBe(0); expect(getValue(response, "data.0")).toBeUndefined()\`
-
-   ❌ BAD (shape-only check on a list endpoint, items never validated): \`expect(Array.isArray(getValue(response, "results"))).toBe(true)\`
-   ✅ GOOD: \`expect(getValue(response, "results").length).toBe(2); expect(getValue(response, "results.0.id")).toBe(<exact id from trace>); expect(getValue(response, "results.0.title")).toBe(<exact title>); expect(getValue(response, "results.2")).toBeUndefined()\`
-
-8. **Computed numeric fields** — scan the source models/services for the arithmetic formula (e.g. \`total_amount = price * quantity\`), then derive dynamically from prior responses using that formula. Never guess or hardcode a computed number.
-   ❌ BAD (hardcoded computed number): \`expect(getValue(patch_response, "total_amount")).toBe(29.99)\`
-   ✅ GOOD: \`expect(getValue(patch_response, "total_amount")).toBe(getValue(product_post_response, "price") * quantitySent)\`
-
-9. **Format/type** — dates, UUIDs, enums get pattern or type assertions, not just \`is not None\`.
-10. **Read steps after POST/PATCH** — re-assert chained values, exact stable values, and computed fields; do not reduce to null/type/range checks.
-11. **Parity** — every assertion derivable from the request/response must appear independently in both the contract and integration tests.
-12. **Query-param constraints** — when the request URL includes \`limit\`, \`pageSize\`, \`offset\`, \`page\`, \`since\`, \`until\`, or \`filter\`, the response MUST be asserted against that constraint:
-    - \`limit=N\` → assert returned array length \`<=\` N (or exactly N when the trace shows it filled)
-    - \`offset=N\` → assert pagination metadata reflects N
-    - \`filter=k=v\` → assert every returned item satisfies the predicate
-
-    ❌ BAD (\`?limit=10\` request, response length never asserted): \`expect(getValue(response, "data")).not.toBeNull()\`
-    ✅ GOOD: \`expect(getValue(response, "data").length).toBeLessThanOrEqual(10)\`  (use \`.toBe(10)\` if the trace shows the limit was filled)
-
-13. **Error-path** — for every 4xx/5xx with a response body, assert every error body field with exact values (\`error.code\`, \`error.message\`, \`detail\`, \`invalid_rows\`, etc.). Apply rule 7 to error arrays. No-body responses (DELETE 204): assert status code only.
-    ❌ BAD (status only when the body has \`detail\`/\`errors\`): \`expect(response.statusCode).toBe(422)\`
-    ✅ GOOD: \`expect(getValue(response, "detail")).toBe("Use POST /api/flow_runs/{id}/stop")\` plus exact assertions for each \`errors[i]\` field
-
-### Verification of enhanced assertions
-1. All stable response values (request-mirrored AND response-only — \`filename_download\`, \`type\`, \`size\`, etc., AND counts/booleans/enums) use exact assertions — no leftover \`>= 0\` or type-only checks
-2. Status code asserted matches the recorded trace exactly (e.g. \`201\` not a default \`200\`)
-3. Every non-empty array has per-item field + next-index-null-guard assertions; every empty-array trace asserts \`length == 0\` with no per-item field assertions on missing indices
-4. No shape-only or type-only checks remain — every \`Array.isArray(...)\`, \`typeof X === '...'\`, \`instanceof Array\`, or \`Object.keys(...).length > 0\` has been replaced with exact value and per-item field assertions when the trace contains data
-5. If \`orderBy\`/\`sort\` is set, ordering direction asserted across the first two items
-6. POST IDs chained into all subsequent steps; no hardcoded IDs
-7. Non-ID response values extracted from prior responses; no hardcoded reused values
-8. Cross-endpoint invariants (e.g. count scalar from one endpoint vs. array length from a sibling endpoint) asserted by extract-and-compare; no twin hardcoded values
-9. Read steps re-assert chained/exact/computed fields — no null/type/range fallbacks
-10. Computed fields use source-derived formulas; no hardcoded computed numbers
-11. Every request body field has an exact-value assertion or a documented server-generated reason
-12. No \`is not None\` / \`.not.toBeNull()\` on any field whose exact value was sent in the request
-13. Format/type fields (dates, UUIDs, enums) asserted with pattern or type check — not just \`is not None\`
-14. Query-param constraints (\`limit\`, \`pageSize\`, \`offset\`, \`filter\`) reflected in response assertions
-15. Every 4xx/5xx with a body has exact error-body assertions; status-only is never used
-16. All field access uses SDK helpers; no dict/attribute access; no import swaps
-
-An item passes verification only when the assertion is present AND is a good assertion per the rules above. If any item is not satisfied — assertion missing, OR present but a bad assertion — add or fix it per the rules before completing, preferring the strongest applicable assertion for the scenario.
-`;
+import { getAssertionsPrompt, } from "./sharedAssertionRules.js";
+const specificRules = [
+    {
+        title: "Chained values across steps — chain, never hardcode",
+        description: "Every ID used in a later step must come from a prior step's response using the SDK helper — never hardcode an ID or declare it as a constant before the response that provides it.",
+        subPoints: [
+            "After a POST creates a resource, GET and PATCH steps should assert that the returned ID matches the one from the POST response.",
+            "When a non-ID response value (such as a collection name, slug, or timestamp) is reused in a later request, extract it from the prior response instead of hardcoding it.",
+            "After any POST, PATCH, DELETE, sort, reorder, or bulk operation, re-assert the chained, stable, and computed values on the follow-up read step: a follow-up GET after DELETE should return 404 or show the item absent; a follow-up GET after PATCH should assert the new value; a follow-up GET after sort/reorder should confirm the new ordering with chained IDs.",
+            "After a POST creates a resource and a GET retrieves the collection, assert that the created item appears in the list by its chained ID with its exact stable fields — do not stop at a null-check on the array or the id alone.",
+            "When one response field describes a count or summary of a collection returned by a related endpoint (for example, `active_session_count` from `/users/me` and the array length from `/users/me/sessions`), assert that relationship by comparing both extracted values — never hardcode the same number in two places.",
+            "Every assertion that can be derived from the request and response must appear in this file. If a test name claims a state change (such as \"Updates X\" or \"Increments Y\"), include an assertion that proves that state change across the relevant calls — do not rely on the contract test to cover it.",
+        ],
+        examples: [
+            {
+                language: "javascript",
+                code: `expect(getResponseValue(productGetResponse, "id"), 'id').toBe(getResponseValue(productsPostResponse, "id"));
+const collection = getValue(collectionsPostResponse, "data.collection");
+expect(getValue(sessionsResponse, "data").length).toBe(getValue(meResponse, "data.active_session_count"));`,
+            },
+            {
+                language: "javascript",
+                code: `const orderId = getResponseValue(ordersPostResponse, "id");
+await skyramp.sendRequest(\`/orders/\${orderId}\`);`,
+            },
+        ],
+    },
+];
+const SCOPE = `### Scope
+- Apply to every \`send_request\` / \`sendRequest\` call that returns a body.
+- Only add assertions clearly supported by the request body, prior response values, field names, codebase evidence, or the test generation recommendations received for this test. Do not invent constraints.
+- Add new assertions immediately after the existing status-code assertion — do not move or remove anything.`;
+export function getIntegrationAssertionsPrompt(testFile, enhanceType) {
+    return getAssertionsPrompt(specificRules, SCOPE, testFile, enhanceType);
+}

package/build/prompts/enhance-assertions/sharedAssertionRules.js

@@ -0,0 +1,212 @@
+import { getPersonaPrefix } from "../personas.js";
+export const MAINTENANCE_SCOPE_NOTE = "Apply only to new test functions you are adding and existing test functions affected by changes in the diff. Do NOT modify test functions unrelated to the diff.";
+export function maintenanceTaskSuffix(enhanceType) {
+    return enhanceType === "maintenance" ? ` ${MAINTENANCE_SCOPE_NOTE}` : "";
+}
+const SHARED_RULES = [
+    {
+        title: "Echo-back the request fields",
+        description: "For every field returned unchanged from the request body, assert the exact sent value.",
+        subPoints: [
+            "`is not None` / `not.toBeNull()` is only acceptable when the value is genuinely unknown — for server-generated timestamps or opaque IDs. This rule does not apply to computed fields.",
+            "When a response field's value equals the value sent in the request body, path, or query, assert that exact value rather than a null-check — the sent value is known and reproducible.",
+            "Also applies to response-only fields the server always returns the same value for (`filename_download`, `content_type`, `size`, `url`, enum status after creation). Asserting only the id on a multi-key resource response is not sufficient.",
+            "Range matchers like `toBeGreaterThanOrEqual(0)` and type-only checks like `typeof X === 'number'` are not acceptable for fields whose exact values are known.",
+            "Assert the exact status code from the recorded trace or `expected_response_body` — for example, `201` for create endpoints, not a generic `200`. Permissive status matchers are never acceptable.",
+        ],
+        examples: [
+            {
+                language: "javascript",
+                code: `expect(getValue(response, "data.filename_download")).toBe("invoice.pdf");
+expect(getValue(response, "data.type")).toBe("application/pdf");
+expect(response.statusCode).toBe(201);`,
+            },
+            {
+                language: "javascript",
+                code: `expect(getResponseValue(productsPostResponse, "name"), 'name').toBe("Skyramp Tester");`,
+            },
+        ],
+    },
+    {
+        title: "Error path (HTTP 4xx/5xx responses)",
+        description: "For every HTTP 4xx/5xx response that includes a response body, assert every error body field with its exact value — including `error.code`, `error.message`, `detail`, `errors[0].message`, and `errors[0].extensions.code`.",
+        subPoints: [
+            "Also apply the array-validation rule to any errors array.",
+            "Asserting only the status code is never sufficient when a body is present.",
+            "For no-body responses such as a successful DELETE (204): assert the status code only.",
+        ],
+        examples: [
+            {
+                language: "javascript",
+                code: `expect(response.statusCode).toBe(404);
+expect(getValue(response, "errors.0.message")).toBe("Item not found");
+expect(getValue(response, "errors.0.extensions.code")).toBe("RECORD_NOT_FOUND");
+expect(getValue(response, "errors.1")).toBeUndefined();`,
+            },
+        ],
+    },
+    {
+        title: "Value ranges",
+        description: "For numeric fields where a realistic range is inferable from the field name, domain, or OpenAPI schema (`minimum` / `maximum`), assert the value falls within the expected range.",
+        examples: [
+            {
+                language: "javascript",
+                code: `expect(getResponseValue(productsPostResponse, "price")).toBeGreaterThanOrEqual(0);`,
+            },
+        ],
+    },
+    {
+        title: "Specific known values",
+        description: "For enum or status fields where only one outcome is valid for this flow, assert the exact expected value.",
+        subPoints: [
+            "When the OpenAPI schema defines allowed values, assert the schema-defined value.",
+            "Also assert cross-field invariants when one field encodes the count or summary of another (e.g. `total_count == results.length`).",
+        ],
+        examples: [
+            {
+                language: "javascript",
+                code: `expect(getResponseValue(ordersPostResponse, "status"), 'status').toBe("pending");`,
+            },
+        ],
+    },
+    {
+        title: "Array / Items validation",
+        description: "Only assert indices that exist in the recorded response — never infer array length from the request or scenario name.",
+        subPoints: [
+            "When the response is an empty array: assert the length is 0 and that the first index is absent. Never assert a field on index 0 of an empty array.",
+            "When the response is a non-empty array: assert the exact length, key fields on each item, and that the index after the last item is absent.",
+            "Shape-only checks such as `Array.isArray` or `typeof` are not sufficient when the response contains actual values.",
+            "If the response is sorted or ordered: assert the ordering direction across the first two items.",
+            "When the response is an empty or minimal body (an empty object, empty array, null, or only a few keys): assert the empty or minimal shape and the absence of error fields — do not stop at the status code.",
+            "When the request includes pagination or filter parameters, assert the response reflects them.",
+        ],
+        examples: [
+            {
+                language: "javascript",
+                code: `expect(getResponseValue(patchResponse, "items.0.product_id")).toBe(getResponseValue(productPostResponse, "id"));
+expect(getResponseValue(patchResponse, "items.0.quantity")).toBe(2);
+expect(getResponseValue(patchResponse, "items.1.product_id")).toBeNull();
+expect(getValue(response, "data").length).toBeLessThanOrEqual(10);  // request sent limit=10`,
+            },
+            {
+                language: "javascript",
+                code: `expect(getValue(response, "results").length).toBe(2);
+expect(getValue(response, "results.0.id")).toBe("prod_001");
+expect(getValue(response, "results.2")).toBeUndefined();`,
+            },
+            {
+                language: "javascript",
+                code: `expect(getValue(response, "data").length).toBe(0);
+expect(getValue(response, "data.0")).toBeUndefined();`,
+            },
+        ],
+    },
+    {
+        title: "Format for server-generated fields",
+        description: "For fields whose exact value varies across runs — UUIDs, auto-incremented IDs, ISO timestamps, IP addresses, emails, and URLs — assert the format or pattern rather than the exact value.",
+        subPoints: [
+            "UUID matches `/^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/i`.",
+            "Auto-incremented ID is greater than 0.",
+            "ISO timestamp matches `/^\\d{4}-\\d{2}-\\d{2}T/`.",
+            "IP address matches IPv4 or IPv6 format.",
+            "Email contains `@` and a domain.",
+            "URL starts with `http://` or `https://`.",
+            "Use `not.toBeNull()` / `is not None` only for truly opaque random tokens where no format is recognizable.",
+            "Use format info from the OpenAPI schema (`format: uuid`, `format: date-time`) to identify these fields.",
+        ],
+        examples: [
+            {
+                language: "javascript",
+                code: `expect(getResponseValue(productsPostResponse, "id")).toMatch(/^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/i);
+expect(getResponseValue(productsPostResponse, "created_at")).toMatch(/^\\d{4}-\\d{2}-\\d{2}T/);`,
+            },
+        ],
+    },
+    {
+        title: "Computed response fields, derived using dynamic formulas",
+        description: "When the response contains a field whose value is derived from a calculation, assert the result using a formula built from prior response values and request inputs, not a hardcoded literal.",
+        subPoints: [
+            "Use a dynamic formula when the formula is visible in source.",
+            "Fall back to the exact pre-computed value from `expected_response_body` only when no formula is knowable — all inputs must come from the inline request body or the response.",
+        ],
+        examples: [
+            {
+                language: "javascript",
+                code: `expect(getResponseValue(patchResponse, "discount_amount")).toBe(getResponseValue(patchResponse, "total_amount") * (getResponseValue(patchResponse, "discount_value") / 100));`,
+            },
+            {
+                language: "javascript",
+                code: `expect(getResponseValue(patchResponse, "total_amount")).toBe(getResponseValue(productPostResponse, "price") * quantitySent);`,
+            },
+        ],
+    },
+];
+export function renderRule(index, rule) {
+    const subPoints = rule.subPoints && rule.subPoints.length > 0
+        ? "\n" + rule.subPoints.map((p) => `- ${p}`).join("\n")
+        : "";
+    const examplesBlock = rule.examples.length > 0
+        ? "\n" +
+            rule.examples
+                .map((ex) => `<example language="${ex.language}">
+${ex.code}
+</example>`)
+                .join("\n")
+        : "";
+    return `${index}. ${rule.title}\n${rule.description}${subPoints}${examplesBlock}`;
+}
+function renderRules(rules) {
+    return rules.map((rule, i) => renderRule(i + 1, rule)).join("\n\n");
+}
+export function getAssertionsPrompt(specificRules, scope, testFile, enhanceType) {
+    const allRules = [...SHARED_RULES, ...specificRules];
+    const ruleChecklistKeys = allRules
+        .map((rule) => `    "${rule.title}": []`)
+        .join(",\n");
+    return `${getPersonaPrefix()}Your task is to enhance response body assertions in the given test file: \`${testFile}\`.${maintenanceTaskSuffix(enhanceType)}
+
+### Pre-Edit Assertion Analysis
+Before editing the given file, you must output a \`<thinking>\` block. The aim of the \`<thinking>\` block is to analyze each in-scope response in the given test file and output a JSON array that ensures no assertion rule is overlooked. The JSON array should match the template below — every assertion rule title must appear as a key in the \`rule_checklist\`, even when the value is \`[]\`.
+1. Scan the given test file and expected responses based on the test recommendations 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.
+   1. 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.
+   2. Success with no body (204, or 202 with empty body): assert the status code only. Also apply chained-values rules if a follow-up step uses this response's ID.
+   3. Error response (4xx/5xx with a body): assert every error body field with its exact value plus array / items validation on the \`errors[]\` array (exact length + per-item fields + next index undefined). Status code alone is never sufficient when a body is present — for example, also assert \`errors.0.extensions.code == 'INVALID_PAYLOAD'\` and that \`errors.1\` is undefined.
+3. For each in-scope response, output one JSON object using the template below. The output is an array — one object per in-scope response.
+   - \`step\`: the HTTP method, path, and response variable name for this request (e.g. \`POST /products → products_POST_response\`).
+   - \`response_status\`: one of \`success\`, \`no_body\`, or \`error\` based on the classification in step 2.
+   - \`rule_checklist\`: an object that MUST contain every rule title below as a key. For each rule, the value is an array of assertion lines you will add for this response under that rule. Use \`[]\` only when the rule does not apply to this response — every key must still be present. This forces you to consider every rule for every response.
+
+\`\`\`json
+[{
+  "step": "<METHOD> <path> → <responseVar>",
+  "response_status": "success | no_body | error",
+  "rule_checklist": {
+${ruleChecklistKeys}
+  }
+}]
+\`\`\`
+
+### SDK Helpers
+Access response body fields via the SDK helper already imported in the generated file (never dict/attribute access on the response variable): Python \`skyramp.get_response_value(response, "json.path")\`; TypeScript / JavaScript \`getValue(response, "json.path")\` or \`getResponseValue(response, "json.path")\` from \`@skyramp/skyramp\`; Java \`getValue(response, "json.path")\`.
+
+### Assertion Rules with Examples
+${renderRules(allRules)}
+
+${scope}
+
+### What not to do
+- Do not access response fields via dict syntax (\`response["field"]\`) or attribute access (\`response.field\`) — always use the SDK helper.
+- Do not assert \`not.toBeNull()\` / \`is not None\` on a field whose exact value is in the request body, prior response, or trace.
+- Do not skip body assertions citing genuinely unpredictable fields — every assertable field still needs an assertion.
+- Do not use permissive status matchers (\`.toMatch(/^2/)\`, \`.toBeGreaterThanOrEqual(200)\`, \`checkStatusCode(response, '20x')\`).
+- Do not use shape-only or type-only assertions as a substitute for exact value validation. Forbidden patterns: \`Array.isArray(...)\`, \`typeof X === '...'\`, \`X instanceof Array\`, \`Object.keys(X).length > 0\`. When the recorded response contains actual values, assert them exactly.
+- Do not use shape-only, containment-only, range-only, or weak-length as the sole assertion on a populated array.
+- Do not swap between \`getValue\` and \`getResponseValue\` — keep whichever SDK helper the file already imports.
+- Do not restructure, reformat, reorder, or modify existing code; do not add comments or docstrings.
+- Do not change function signatures, imports, or variable names.
+- Do not remove existing assertions.
+
+### Verification of Assertions
+After adding all assertion lines in the given test file, verify that every applicable rule has been applied correctly to each in-scope response. If any are missing or weakly applied, fix them before completing.`;
+}