@skyramp/mcp 0.4.0 → 0.4.1-rc.2

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

@@ -8,7 +8,7 @@ const specificRules = [
             "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.",
+            "The behaviour this test claims must be proven from `expected_response_body`, the inline request body, or path/query literals — do not rely on the integration test to cover it.",
         ],
         examples: [
             {
@@ -21,6 +21,7 @@ const specificRules = [
 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.
+- A response no behaviour in this file depends on needs its status code and nothing more.
 - 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) {

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

@@ -9,7 +9,7 @@ const specificRules = [
             "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.",
+            'A state change the test is for ("Updates X", "Increments Y" — from the recommendation it came from, or from the test name when that name says more than `test_integration`) must be proven across the calls that carry it — do not rely on the contract test to cover it.',
         ],
         examples: [
             {
@@ -29,6 +29,7 @@ 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.
+- A response no behaviour in this file depends on needs its status code and nothing more.
 - 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.d.ts

@@ -1,5 +1,5 @@
 export type EnhanceType = "generation" | "maintenance";
-export declare 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 declare 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. A test function you do touch is held to the same standard as a new one: the behaviour the diff changed must be asserted by its exact value there too, so an existing `is not None` on a field the diff gives a knowable value becomes that value.";
 export declare function maintenanceTaskSuffix(enhanceType: EnhanceType): string;
 export interface AssertionEnrichmentExample {
     language: string;

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

@@ -1,16 +1,33 @@
 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 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. A test function you do touch is held to the same standard as a new one: the behaviour the diff changed must be asserted by its exact value there too, so an existing `is not None` on a field the diff gives a knowable value becomes that value.";
 export function maintenanceTaskSuffix(enhanceType) {
     return enhanceType === "maintenance" ? ` ${MAINTENANCE_SCOPE_NOTE}` : "";
 }
 const SHARED_RULES = [
+    {
+        title: "Assert the behaviour under test",
+        description: "Every test needs at least one assertion that fails when the behaviour it claims is broken. This is the rule the others support; a test that satisfies every rule below and still does not distinguish the behaviour working from the behaviour broken has not been enhanced.",
+        subPoints: [
+            "Name the behaviour, then ask what value in the response changes when it breaks. Assert that value exactly.",
+            'When the test claims a state change ("Updates X", "Increments Y", "rejects Z"), the assertion must prove the change, not merely that the call succeeded.',
+            "When the PR changed the behaviour, the expected value is the one the diff, the PR description, or the referenced spec establishes — even when the running service still returns the old value. The test is expected to fail until the code is fixed.",
+        ],
+        examples: [
+            {
+                language: "javascript",
+                code: `// "PATCH /orders applies the coupon discount" — the discount is the behaviour.
+expect(getResponseValue(patchResponse, "discount_amount"), 'discount applied').toBe(20);
+expect(getResponseValue(patchResponse, "total_amount"), 'total after discount').toBe(80);`,
+            },
+        ],
+    },
     {
         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.",
-            "Assert the exact value of a response-only field when the request this test sends determines it (`filename_download`, `content_type`, `size`, an enum status after creation). A value the app generates gets a format check when the test case depends on that value; leave the rest unasserted. Asserting only the id on a multi-key resource response is not sufficient.",
+            "Assert the exact value of a response-only field when the request this test sends determines it (`filename_download`, `content_type`, `size`, an enum status after creation). A value the app generates gets a format check when the test case depends on that value; leave the rest unasserted. When the behaviour is that a resource was created with the fields sent, the id alone does not prove it — assert those fields.",
             "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 resource-creation endpoints. Action-style endpoints with verb path segments like `/run`, `/trigger`, `/execute`, `/deploy`, `/submit`, `/start`, `/stop`, or `/cancel` often use `200`, but assert the recorded or expected code. Permissive status matchers are never acceptable.",
         ],
@@ -28,12 +45,13 @@ expect(response.statusCode).toBe(201);`,
         ],
     },
     {
-        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`.",
+        title: "Error path (HTTP 4xx/5xx, or a 2xx carrying only an error body)",
+        description: "For every error response that includes a body, assert every error body field with its exact value — including `error.code`, `error.message`, `detail`, `errors[0].message`, and `errors[0].extensions.code`. An error response is any 4xx/5xx with a body, and any 2xx whose body is an error object (`error`, `message`, `errors[]`) with no resource payload.",
         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.",
+            'For a 2xx error body, assert the exact status code, the error field\'s exact value, and that the resource fields carry no value (`toBeNull()` / `is None` — the SDK helper reads a missing path and an explicit null the same way, so this asserts "no payload", not "key absent"; use `checkSchema` when the two must be told apart). Never assert the success shape (a non-empty collection, `error` absent) against a response the recorded trace or `expected_response_body` shows returning an error or no-match body — classify the response by what this request returns, not by the outcome the test was meant to check for. The one exception is a test the plan declared `expected.outcome: fail` (typically a `bug_caught` or `requirement_conflict` candidate; the category is only the fallback when nothing was declared): it asserts the intended behaviour established by the diff, the PR statement, or the code\'s evident intent — keep that assertion and let the test fail.',
         ],
         examples: [
             {
@@ -43,15 +61,19 @@ 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")).toBeNull();`,
             },
-        ],
-    },
-    {
-        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);`,
+                code: `// Recorded response is a 200 carrying an error object and no payload
+expect(searchPostResponse.statusCode, 'status code').toBe(200);
+expect(getResponseValue(searchPostResponse, "error"), 'error').toBe("No items matched the criteria.");
+expect(getResponseValue(searchPostResponse, "results"), 'results carries no value').toBeNull();`,
+            },
+            {
+                language: "python",
+                code: `# Recorded response: 400 {"error": "level must be one of Intern, Junior, Senior"}
+assert record_post_response.status_code == 400
+assert skyramp.get_response_value(record_post_response, "error") == "level must be one of Intern, Junior, Senior"
+assert skyramp.get_response_value(record_post_response, "insertedId") is None`,
             },
         ],
     },
@@ -77,7 +99,7 @@ expect(getValue(response, "errors.1")).toBeNull();`,
             "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 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. A minimal body that is itself an error object falls under the Error path rule instead: assert its error field exactly.",
             "When the request includes pagination or filter parameters, assert the response reflects them.",
         ],
         examples: [
@@ -102,8 +124,8 @@ expect(getValue(response, "data.0")).toBeNull();`,
         ],
     },
     {
-        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.",
+        title: "Fields whose value varies across runs",
+        description: "For a field whose exact value varies across runs — a UUID, an auto-incremented ID, an ISO timestamp, an IP address, an email, a URL, or a number with no knowable exact value — assert its format or its range instead of its value, and only when the behaviour under test depends on that field. A generated id the test chains onward needs a format check; the same id on a response nothing reads again needs no assertion at all.",
         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.",
@@ -113,6 +135,7 @@ expect(getValue(response, "data.0")).toBeNull();`,
             "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.",
+            "A numeric field with no knowable exact value takes a range from the field name, the domain, or the OpenAPI `minimum` / `maximum` — a range is the weakest assertion in this rule set, so use it only where no exact value exists and the behaviour depends on the field.",
         ],
         examples: [
             {
@@ -124,9 +147,8 @@ expect(getResponseValue(productsPostResponse, "created_at")).toMatch(/^\\d{4}-\\
     },
     {
         title: "Use exact recorded JSON paths",
-        description: "Do not add object-wrapper prefixes or nested paths that are not present in the actual response body. Use the exact JSON path from the recorded response body.",
+        description: 'Read every field at the path the recorded body actually uses. A wrapper prefix the response does not have makes the assertion read null and the test fail for a reason that is not the behaviour — if the body is flat (`{"id": "acc_...", "tax_exempt": true}`), the path is `"tax_exempt"`, never `"account.tax_exempt"`.',
         subPoints: [
-            `If the body is flat (\`{"id": "acc_...", "tax_exempt": true}\`), use \`"tax_exempt"\`, not \`"account.tax_exempt"\`.`,
             "Only use dot notation when the recorded response genuinely nests the field under that key.",
         ],
         examples: [
@@ -201,22 +223,34 @@ export function getAssertionsPrompt(specificRules, scope, testFile, enhanceType)
         .join(",\n");
     return `${getPersonaPrefix()}Your task is to enhance response body assertions in the given test file: \`${testFile}\`.${maintenanceTaskSuffix(enhanceType)}
 
+### What to assert
+Each test evaluates ONE behaviour — the one the recommendation it came from asked for. Assert that behaviour, and the values it depends on, exactly. Leave the rest of the response alone.
+
+A field belongs in the test when a wrong value in it would mean the behaviour is broken. A field does not belong when its value can change for reasons that have nothing to do with the behaviour — a generated id, a timestamp, an unrelated sibling field. Asserting those does not make the test stronger. It makes the test fail for reasons the test is not about, and it buries the one assertion a reader needs to understand what the test is for.
+
+So the rules below say how to assert a value, not how many values to assert. Apply a rule to the fields the behaviour depends on. \`[]\` is the correct answer for a rule whose fields this test does not depend on.
+
+If nothing in the response distinguishes the behaviour working from the behaviour broken, the test is exercising the wrong request or reading the wrong response. Say so; do not pad it with assertions on whatever else the body carries.
+
 ### 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.
+Before editing the given file, 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 should match the template below — every assertion rule title must appear as a key in the \`rule_checklist\`, with \`[]\` 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. 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 the given test file 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.
    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 (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.
-   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 null). 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 null.
+   3. Error response (4xx/5xx with a body, or any status whose body is an error object such as \`{"error": "..."}\` with no resource payload): assert every error body field with its exact value plus array / items validation on the \`errors[]\` array (exact length + per-item fields + next index null). 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 null.
+   Classify by the response the recorded trace or \`expected_response_body\` shows this request returning. The one exception is a test the plan declared \`expected.outcome: fail\` (typically a \`bug_caught\` or \`requirement_conflict\` candidate; read the declaration first and fall back to the category only when none was made): there the expected response is the intended behaviour established by the diff, the PR statement, or the code's evident intent, and the test is expected to fail until the code is fixed.
 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.
+   - \`behaviour_under_test\`: the one-line behaviour from step 1 that this response is evidence for. When a response is evidence for no behaviour any test in scope claims, write \`none\` and add nothing for it.
+   - \`rule_checklist\`: an object that MUST contain every rule title below as a key. For each rule, the value is the assertion lines you will add for this response under that rule. \`[]\` means the rule does not apply here, which is a normal and expected answer: it is the right one whenever the rule's fields are not part of \`behaviour_under_test\`. Listing every key keeps a rule that DOES apply from being skipped; it is not a quota to fill.
 
 \`\`\`json
 [{
   "step": "<METHOD> <path> → <responseVar>",
   "response_status": "success | no_body | error",
+  "behaviour_under_test": "<the one-line behaviour this response is evidence for, or none>",
   "rule_checklist": {
 ${ruleChecklistKeys}
   }
@@ -235,7 +269,8 @@ ${scope}
 - 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 or a prior response.
 - Do not assert an exact value you learned only from a request you sent yourself while writing the test. Take the value from the diff, from what the request determines, or from a response this test received earlier.
-- Do not skip body assertions citing genuinely unpredictable fields — every assertable field still needs an assertion.
+- Do not assert a field only because the body carries it. If a wrong value there would not mean the behaviour under test is broken, leave it alone.
+- Do not leave a test whose assertions would all still pass with the behaviour under test broken.
 - 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 a field's value comes from one of those sources, assert it exactly.
 - Do not use shape-only, containment-only, range-only, or weak-length as the sole assertion on a populated array.
@@ -245,5 +280,5 @@ ${scope}
 - 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.`;
+After adding the assertion lines in the given test file, re-read each test and check two things: every rule that applies to the behaviour under test has been applied correctly, and the test now fails if that behaviour breaks. Fix anything missing or weakly applied before completing. Remove any assertion you added that the behaviour does not depend on.`;
 }

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

@@ -51,6 +51,8 @@ expect(trigger).to_be_focused()`,
                     "Anchor on the removed attribute+value or role+name, never on text or position — a text-based absence check breaks when unrelated siblings change.",
                     "Do not add a guard for an element whose whole page or route was removed — that is maintenance of the tests that covered it, not a new assertion; a spec that opens a deleted route must be anchored on a surviving page first (a retained element asserted on a live page in the same spec) — a spec whose only visited page is the dead URL is not a valid guard.",
                     "A renamed test id or accessible name (a removed `aria-label` included) is not a removed element: assert the element under its new identifier and never assert the retired identifier `toBeHidden()` — it passes today and turns into a false failure the day the name is reused.",
+                    "An element that exists only inside a control the page has to open — an `option` of a `select`, an item of a closed menu or dropdown — takes `toHaveCount(0)`, not `toBeHidden()`. A closed control's contents have no bounding box, so `toBeHidden()` passes whether the element was removed or not, and the guard stays green the day it comes back. If the spec opens the control before asserting, the element would have had a box had it survived, so assert both.",
+                    "The positive companion for that guard is counted or read, never `toBeVisible`: the same missing bounding box that makes `toBeHidden()` a false green on the removed entry makes `toBeVisible()` a false red on the one that stayed. Assert a retained sibling with `toHaveCount(1)` or `toHaveText`, or assert the control itself, which does have a box.",
                 ],
                 examples: [
                     {
@@ -83,7 +85,7 @@ expect(page.get_by_test_id('navbar-products')).to_have_text('Products')`,
             },
             {
                 title: "Tests target the changed behavior introduced by the pull request",
-                description: "At least one assertion targets the changed behavior on populated or updated state, not only empty or zero state.",
+                description: "Every test needs at least one assertion that fails when the behaviour it claims is broken. This is the rule the others support: a test that satisfies every rule below and still does not distinguish the behaviour working from the behaviour broken has not been enhanced. Target it on populated or updated state, not only on empty or zero state, and assert it on the page where the behaviour shows. When the PR changed the behaviour, the expected value is the one the diff, the PR description, or the referenced spec establishes — even when the running app still renders the old value; the test is expected to fail until the code is fixed.",
                 examples: [],
             },
             {
@@ -222,6 +224,9 @@ export function getUIAssertionsPrompt(testFile, enhanceType) {
     const categoryTemplate = renderAssertionCategoriesTemplate(UI_ASSERTION_CATEGORIES);
     return `${getPersonaPrefix()}Your task is to enhance assertions for the given UI test file: \`${testFile}\`.${maintenanceTaskSuffix(enhanceType)}
 
+### What to assert
+Each test evaluates ONE behaviour — the one the recommendation it came from asked for. Assert that behaviour on the page where it shows, and the rendered values it depends on, exactly. A page the test only passes through, and an element the behaviour does not touch, need no assertion: asserting them makes the test fail for reasons the test is not about and buries what the test is for. The rules below say how to assert a value, not how many values to assert.
+
 ### First Check
 If the generated test file has no \`expect()\` assertions, you MUST manually add them before anything else. Use \`import { expect } from '@skyramp/skyramp';\` — never from \`@playwright/test\`. If an existing import pulls \`expect\` from \`@playwright/test\`, move it to \`@skyramp/skyramp\` (keep \`test\` on the playwright line).
 
@@ -328,25 +333,28 @@ if (await existingSecret.isVisible().catch(() => false)) {
 \`\`\`
 
 ### Pre-Edit Assertion Analysis
-Before editing the given test file, you must output a \`<thinking>\` block. The aim of the \`<thinking>\` block is to analyze each in-scope item (action, selector, or captured network 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 category and every rule title under it must appear as a key, even when the value is \`[]\`.
-1. Selector inventory — list every selector already present in the generated test file (\`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.
-2. Process — Replay → Identify → Fix or Add — walk through these three steps explicitly.
+Before editing the given test file, 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. 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 the generated test file (\`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?"
    b. Identify expectation mismatches. If the recorded trace shows a result that contradicts the action (e.g. removing 1 of 2 items but the page shows 3, submitting a form but getting a blank page, editing a field but the old value persists), that is an app bug the test should catch. List every mismatch you find.
    c. Fix or add assertions for each mismatch.
       - If an existing assertion uses the wrong (buggy) value, edit it to assert the correct expected value.
       - If no assertion exists for the buggy behavior, add one immediately after the action that triggers it.
-3. Classify each in-scope action / selector / captured response by its applicable assertion category, marking each category APPLICABLE or NOT APPLICABLE.
+4. Classify each in-scope action / selector / captured response by its applicable assertion category, marking each category APPLICABLE or NOT APPLICABLE.
    - Critical UI Assertions applies when there is a collection / repeated element (\`toHaveCount\`), a pageerror handler, a captured network response, a negative-only or URL-only test needing a positive-path companion, or a tautological locator-by-text + assert-text to replace.
    - Computed Values applies when there is a knowable exact text / value / attribute, including a definition-page displayed value or an image \`src\`.
    - Post-edit State applies whenever EITHER (a) the test contains a state-changing action (form fill+submit, save / delete / create / toggle, checkbox click, hover / mouseout, refresh, reload, JS update, form edit), OR (b) the PR changes interactive behavior — in case (b), add the triggering action and assert the before/after transition (see "Exercise the changed interaction"). Mark NOT APPLICABLE only when the PR changes no interactive behavior and the test has no state-changing action.
-4. For each in-scope item, output one JSON object using the template below. The output is an array — repeat the object template below once per in-scope item.
+5. For each in-scope item, output one JSON object using the template below. The output is an array — repeat the object template below once per in-scope item.
    - \`action_or_selector_or_response\`: the selector, action, or captured network response this entry covers.
-   - \`assertion_categories\`: an object that MUST contain every category name below as a key. The value of each category is itself an object that MUST contain every rule title under that category as a key. For each rule, the value is an array of assertion lines you will add for this item under that rule. Use \`[]\` only when the rule does not apply to this item — every category key and every rule key must still be present. This forces you to consider every rule for every item.
+   - \`behaviour_under_test\`: the one-line behaviour from step 1 that this item is evidence for. When an item is evidence for no behaviour any test in scope claims, write \`none\` and add nothing for it.
+   - \`assertion_categories\`: an object that MUST contain every category name below as a key. The value of each category is itself an object that MUST contain every rule title under that category as a key. For each rule, the value is the assertion lines you will add for this item under that rule. \`[]\` means the rule does not apply here, which is a normal and expected answer: it is the right one whenever the rule's elements are not part of \`behaviour_under_test\`. Listing every key keeps a rule that DOES apply from being skipped; it is not a quota to fill.
 
 \`\`\`json
 [{
   "action_or_selector_or_response": "<selector | action | response>",
+  "behaviour_under_test": "<the one-line behaviour this item is evidence for, or none>",
   "assertion_categories": {
 ${categoryTemplate}
   }
@@ -354,7 +362,7 @@ ${categoryTemplate}
 \`\`\`
 
 ### Assertion Rules with Examples
-Most-violated patterns — apply every time. (1) repeated elements → \`toHaveCount(N)\` + per-item \`toHaveText\`/\`toHaveValue\`/\`toHaveAttribute\` (Collection / repeated UI elements). (2) post-action state → \`toHaveText\`/\`toHaveValue\`/\`toHaveAttribute\`/\`toBeChecked\`, not \`toBeVisible\` when exact value is knowable (Post-action visible state). (3) routing/URL-only tests → at least one rendered-element exact text (Positive-path companion).
+Most-violated patterns — whenever the behaviour under test involves one of these, this is the shape it takes. (1) repeated elements → \`toHaveCount(N)\` + per-item \`toHaveText\`/\`toHaveValue\`/\`toHaveAttribute\` (Collection / repeated UI elements). (2) post-action state → \`toHaveText\`/\`toHaveValue\`/\`toHaveAttribute\`/\`toBeChecked\`, not \`toBeVisible\` when exact value is knowable (Post-action visible state). (3) routing/URL-only tests → at least one rendered-element exact text (Positive-path companion).
 Strength order. \`toHaveCount\`/\`toHaveText\`/\`toHaveValue\`/\`toHaveAttribute\` > \`toContainText\` (only when string is genuinely dynamic) > \`toBeVisible\` (only when presence is the actual test).
 
 ${renderCategories(UI_ASSERTION_CATEGORIES)}
@@ -373,7 +381,7 @@ ${renderCategories(UI_ASSERTION_CATEGORIES)}
 - Do not assert buggy/error text as expected (unless the intended UX is an error state)
 
 ### 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 action, selector, and captured response. If any are missing or weakly applied, fix them before completing.
+After adding the assertion lines in the given test file, re-read each test and check two things: every rule that applies to the behaviour under test has been applied correctly, and the test now fails if that behaviour breaks. Fix anything missing or weakly applied before completing. Remove any assertion you added that the behaviour does not depend on.
 
 The goal is tests that FAIL when the app has bugs, not tests that simply replay what happened.
 `;

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

@@ -1,14 +1,12 @@
 import { fillPlaceholders } from "../../recommendation/verifierContracts.js";
 import { sectionBody } from "../promptAssets.js";
 import { readPromptAsset } from "../promptAssets.js";
-import { AUTH_MIDDLEWARE_PATTERNS_STR } from "../../utils/workspaceAuth.js";
 import { resolveServiceDetailsRef } from "../../utils/utils.js";
 import { PromptPlan } from "./promptPlan.js";
 import { buildTestPatternGuidelines, buildTestQualityCriteria, buildGenerationRules, buildFinishChecks, } from "./recommendationSections.js";
 const EXECUTION_PLAN_MD = readPromptAsset("generate-tests/execution-plan.md");
 function _execEnrichBody(ctx) {
     return fillPlaceholders(sectionBody(EXECUTION_PLAN_MD, "## Parameter grounding"), {
-        authMiddlewarePatterns: AUTH_MIDDLEWARE_PATTERNS_STR,
         enrichSurface: ctx.isDiffScope ? "the diff" : "the analysed surface",
         testPatternGuidelines: buildTestPatternGuidelines(),
     });

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

@@ -1,10 +1,10 @@
 import { AnalysisScope, isDiff, } from "../../types/RepositoryAnalysis.js";
-import { WorkspaceAuthType, getDefaultAuthHeader } from "../../utils/workspaceAuth.js";
+import { WorkspaceAuthType, getDefaultAuthHeader, AUTH_MIDDLEWARE_PATTERNS_STR } from "../../utils/workspaceAuth.js";
 import { logger } from "../../utils/logger.js";
 import { buildArchitectPreamble, buildContextFetchingGuidance, buildReasoningProtocol, buildToolWorkflows, buildVerificationChecklist, } from "./recommendationSections.js";
 import { buildExecutionPlan, EXEC_STEP_ENRICH } from "./diffExecutionPlan.js";
 import { readPromptAsset } from "../promptAssets.js";
-import { renderPlanDeclarationGuidance } from "../testbot/planDeclarations.js";
+import { fillPlaceholders } from "../../recommendation/verifierContracts.js";
 import { TASK_GENERATE, taskRef, } from "./recommendationShared.js";
 // Re-export for backward compatibility (tests and external callers import this from this module)
 function formatTestLocations(locs) {
@@ -22,11 +22,16 @@ function formatTestLocations(locs) {
 // on subsequent testbot runs on the same PR.
 const SKYRAMP_TEST_FILE_PATTERN = /(?:_test|_smoke|_contract|_fuzz|_integration|_load|_e2e|_ui)\.[^/]+$|scenario_[^/]+\.json$/;
 /** How this prompt tells the agent to plan: the whole procedure, every time.
- *  Rendered from `plugin/prompts/plan-tests.md` and `declaring-a-plan.md` rather
- *  than retyped, so there is one text and nothing to drift from. `isDiffScope` is
- *  unused here — the procedure reads the same for a diff and for a repository. */
+ *  Rendered from `plugin/prompts/plan-tests.md` rather than retyped, so there is
+ *  one text and nothing to drift from. `isDiffScope` is unused here — the
+ *  procedure reads the same for a diff and for a repository. */
 function planningInstruction(_isDiffScope) {
-    return `${readPromptAsset("plan-tests.md").trim()}\n\n${renderPlanDeclarationGuidance()}`;
+    // The procedure names the auth patterns. BOTH renderers of this asset fill the
+    // placeholder — this lane's and the testbot lane's — or one of them ships the
+    // literal `{authMiddlewarePatterns}` to the model.
+    return fillPlaceholders(readPromptAsset("plan-tests.md").trim(), {
+        authMiddlewarePatterns: AUTH_MIDDLEWARE_PATTERNS_STR,
+    });
 }
 export function buildRecommendationPrompt(analysis, analysisScope = AnalysisScope.FullRepo, prContext, workspaceAuthHeader, workspaceAuthType, workspaceAuthScheme, sessionId) {
     const isDiffScope = isDiff(analysisScope);

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

@@ -4,10 +4,11 @@ import { AnalyticsService } from "../../services/AnalyticsService.js";
 import { buildPathParamGuidance, } from "../test-recommendation/recommendationSections.js";
 import { setReportLanguage } from "../../utils/reportLanguage.js";
 import { setPlanOnlyMode } from "../../utils/planOnlyMode.js";
+import { recordPullRequestText } from "../../recommendation/pullRequestText.js";
+import { AUTH_MIDDLEWARE_PATTERNS_STR } from "../../utils/workspaceAuth.js";
 import { TASK_ANALYZE_MAINTAIN, TASK_GENERATE, TASK_SUBMIT, TESTBOT_TASK1_MAINTAIN_LABELS, TESTBOT_TASK1_MULTIREPO_LABELS, TESTBOT_TASK1_STEP_LABELS, orderedLabels, stepSubRef, taskRef, } from "../test-recommendation/recommendationShared.js";
 import { getTraceRecordingPromptText } from "../../playwright/traceRecordingPrompt.js";
 import { isContractConsumerModeEnabled, isPomReuseEnabled, isUtilsReuseEnabled, isSkillsLoaded, } from "../../utils/featureFlags.js";
-import { renderPlanDeclarationGuidance } from "./planDeclarations.js";
 import { fixErrorsInstruction } from "../../skills/fixTestImportErrorsSkill.js";
 import { resolveServiceDetailsRef } from "../../utils/utils.js";
 import { section, sectionBody } from "../promptAssets.js";
@@ -59,24 +60,28 @@ const PLAN_TESTS_MD = readPromptAsset("plan-tests.md").trim();
 // rendered neither it nor a copy, so the agent planned without the claims step and
 // without the backward surface map. Rendered here, never retyped.
 //
-// It sits OUTSIDE Task 1: the procedure is an eleven-item numbered list, Task 1's
+// It sits OUTSIDE Task 1: the procedure is a numbered list, Task 1's
 // own steps are numbered too, and nested inside Task 1 the two share one ordinal
 // space (`referenceIntegrity.test.ts` reads every `N.` there as a Task 1 step).
 //
-// Two steps run elsewhere in this lane — step 6's maintenance update is Task 1's
-// tool step, step 9's registration happens in Task 2 after it. The note states that
-// order; the markdown stays the source.
+// Two steps run elsewhere in this lane — the maintenance update in **Group the
+// changes into behaviours and decide each** is Task 1's tool step, and **Register the
+// whole plan in one call to `skyramp_register_test_plan`** happens in Task 2 after it.
+// The note states that order; the markdown stays the source.
 //
 // The count sentence sits HERE, beside the register instruction, because the agent
 // reads the URI first and plans straight after: on run 34005367281 it read
 // `maxGenerate=3` as this run's budget and left its fourth planned test unwritten.
-const planProcedureBlock = `${section(PLAN_TESTS_MD, "## Terms")}
+// The procedure names the auth patterns. BOTH renderers of this asset fill the
+// placeholder — this lane's and the recommendation lane's — or one of them ships
+// the literal `{authMiddlewarePatterns}` to the model.
+const planProcedureBlock = fillPlaceholders(`${section(PLAN_TESTS_MD, "## Terms")}
 
 ${section(PLAN_TESTS_MD, "## The procedure")}
 
 **In this run:** ${taskRef(TASK_ANALYZE_MAINTAIN)}'s maintenance step performs the maintenance update of an existing test, with the maintenance tools — a test those tools update is not a plan planned test. Register the plan in ${taskRef(TASK_GENERATE)}, after that step. Nothing caps how many planned tests the plan holds: \`maxGenerate\` and \`maxRecommendations\` arrive in this run's URI, and the server accepts both and applies neither — no check reads either one, so a count you see there is not a budget.
 
-${section(PLAN_TESTS_MD, "## Decisions the checks leave to you")}`;
+${section(PLAN_TESTS_MD, "## Decisions the checks leave to you")}`, { authMiddlewarePatterns: AUTH_MIDDLEWARE_PATTERNS_STR });
 // The checks on the test file itself. One home — `generation.md` — rendered by
 // this lane at the end of generation and by the IDE lane after its generation
 // rules, so neither carries a retyped copy.
@@ -173,6 +178,8 @@ export function parseRelatedRepositories(raw) {
 }
 export function getTestbotPrompt(opts) {
     const { prTitle, prDescription, repositoryPath, baseBranch, prNumber, userPrompt, services, uiCredentials, testsRepoDir, relatedRepositories, primaryRepo, planOnly = false, language, } = opts;
+    // Kept in the process for the plan tool, which is registered on this server.
+    recordPullRequestText(prTitle, prDescription);
     // The legacy count arguments are DECLARED NOWHERE, so zod strips them and their
     // names never reach the agent — not in a schema it lists, not in rendered text.
     // A number in front of the agent reads as a ceiling whatever the words around it
@@ -357,7 +364,7 @@ ${uiGroundingBlock}
 This is a plan-only evaluation run: the application under test is NOT running, and this run evaluates test SELECTION only. Nothing is generated or executed in this task.
 
 - Draft your complete plannedTest list — every test you would generate OR recommend for this PR, grounded in the analysis output and the diff. Favor tests that would FAIL if the changed logic were buggy, not just tests that exercise the new surface.
-- Register that list through \`skyramp_register_test_plan\` as "How to declare your plan" above describes. What you register is the plan — nothing re-ranks or trims it.
+- Register that list through \`skyramp_register_test_plan\` as the planning procedure above describes. What you register is the plan — nothing re-ranks or trims it.
 - Include UI and E2E planned tests on the same footing as the API types. The app is not running, so you cannot capture a blueprint — plan them ungrounded rather than drop them. For every UI plannedTest, set \`elements.items\` to null and set \`elements.pageUrl\` to the route path the test would visit, read out of the source: \`/orders/1\`, not a full URL, because no host is serving the app. Set \`screenEvidence.file\` to the changed frontend file that renders that route — the app not running does not excuse this one, because you read the file out of the diff. Describe the page or feature the test would exercise; do not name an element you have not seen. This lane is the one case where you fall back without attempting a capture first, so do NOT log the fallback in \`issuesFound\` — capture was never applicable here, and nothing failed.
 - Take no other actions in this task: no test generation tools, no browser traces or blueprint captures, no test files written, no test executions. Proceed directly to ${taskRef(TASK_SUBMIT)}.`;
     }
@@ -458,7 +465,7 @@ ${CONTRACT_MODE_GUIDANCE}
   - \`skyramp_export_zip\` outputPath: \`${repositoryPath}/.skyramp/<test_name>_trace.zip\`
   - \`skyramp_ui_test_generation\`: set \`modularizeCode: false\` and \`codeReuse: true\` (TypeScript/JavaScript Playwright only — the default; leave \`codeReuse\` unset for other languages)
   - **\`browser_assert\`**: the \`browser_navigate\` result states the rule this tool has to satisfy on every page you reach. Call multiple assertions in the same tool call batch when checking independent elements.
-  - **Removal guard — when \`uiContext.removedElements\` is non-empty**: the server lists which elements this PR removed — each identified by a \`data-*\` attribute and value, with the file it came from (renames, moves and deleted files are excluded). Read that file and the route or page files that render it to decide which page each appeared on. Per PAGE: \`browser_navigate\` to it, wait for the app to render, then call \`browser_assert_hidden\` once per listed element using the target the list shows — \`testId: "<value>"\` when the attribute is \`data-testid\`, otherwise \`attribute: "<name>", value: "<value>"\` (e.g. \`attribute: "data-cy"\`); no \`ref\` — the element no longer exists, so no snapshot has one; the tool checks the live page and refuses to record on a blank or un-rendered page. Then at least one \`browser_assert\` on a RETAINED element of the same page verifying its text, value or state. If a UI trace for that page is already planned, record the guard assertions inside that trace; otherwise this is its own trace and spec, \`verify-removed-ui-<page-slug>\`. The generated test asserts \`toBeHidden()\` on \`getByTestId(...)\` or \`page.locator('[data-cy="..."]')\` accordingly. A removed element the server did not list still gets its test (the removal check requires it) — ground that one in the diff and prefix its \`reasoning\` with \`[removed-element diff-grounded]\`; prefix \`reasoning\` with \`[removed-element server-listed]\` when the element came from \`uiContext.removedElements\`. **Deleted routes or pages are deleted features, not removed elements**: test the removal through the link or entry point that survives. A trace may still open the retired URL — to assert the app's fallback there, or that the old page's elements are gone — after it has recorded a positive \`browser_assert\` on a surviving page; a trace whose only visited page is the dead URL has no positive companion and is not a guard spec.
+  - **Removal guard — when \`uiContext.removedElements\` is non-empty**: the server lists which elements this PR removed — each identified by a \`data-*\` attribute and value, with the file it came from (renames, moves and deleted files are excluded). Read that file and the route or page files that render it to decide which page each appeared on. Per PAGE: \`browser_navigate\` to it, wait for the app to render, then call \`browser_assert_hidden\` once per listed element using the target the list shows — \`testId: "<value>"\` when the attribute is \`data-testid\`, otherwise \`attribute: "<name>", value: "<value>"\` (e.g. \`attribute: "data-cy"\`); no \`ref\` — the element no longer exists, so no snapshot has one; the tool checks the live page and refuses to record on a blank or un-rendered page. Then at least one \`browser_assert\` on a RETAINED element of the same page verifying its text, value or state. If a UI trace for that page is already planned, record the guard assertions inside that trace; otherwise this is its own trace and spec, \`verify-removed-ui-<page-slug>\`. The generated test asserts \`toBeHidden()\` on \`getByTestId(...)\` or \`page.locator('[data-cy="..."]')\` accordingly. A removed element the server did not list still gets its test (the removal check requires it) — ground that one in the diff and prefix its \`reasoning\` with \`[removed-element diff-grounded]\`; prefix \`reasoning\` with \`[removed-element server-listed]\` when the element came from \`uiContext.removedElements\`. When the removed element lived inside a control the page has to open — an \`option\` of a \`select\`, an item of a closed menu — open that control before asserting: a closed control's contents are never visible, so a hidden assertion recorded against a shut one passes whether the element was removed or not. \`browser_assert_hidden\` stays the tool either way, because \`browser_assert\` needs a snapshot \`ref\` and a removed element has none; where the control cannot be opened, say so in \`reasoning\` so the assertion step turns that guard into a count. **Deleted routes or pages are deleted features, not removed elements**: test the removal through the link or entry point that survives. A trace may still open the retired URL — to assert the app's fallback there, or that the old page's elements are gone — after it has recorded a positive \`browser_assert\` on a surviving page; a trace whose only visited page is the dead URL has no positive companion and is not a guard spec.
   - **Renames are not removals — on every PR, whatever \`uiContext.removedElements\` holds**: when a test id, \`aria-label\` or other accessible name changed, assert the element by its new identifier and leave the retired identifier alone (no \`browser_assert_hidden\` on it). A rename PR removes nothing, so this rule applies when the removed list is empty.
   - **\`browser_visual_snapshot\` — for visual/appearance checks**: when the instruction asks to take a screenshot, capture a baseline, or verify how a page/element/region *looks* (not its text or value), call \`browser_visual_snapshot\` — it records a \`toHaveScreenshot()\` assertion so the generated test pixel-compares against a baseline on every run. Do NOT use \`browser_take_screenshot\` for this: it captures a throwaway image that is dropped at export and never appears in the generated test (use it only to view the page yourself).
   - **Wait for stable state before the second capture**: After performing an action that affects computed fields (filling a discount, submitting a form, adding an item), check the current page state before calling the second \`browser_blueprint\` (the capture after the action). If a computed field — total, price, count, derived text — still shows its initial empty or zero value (e.g. \`$0.00\`, \`0\`, \`Loading...\`, empty string), that means async data hasn't finished loading yet. Use \`browser_wait_for\` to wait up to 10 seconds for the field to update to a real value (for example, wait for the total to show a non-zero amount like \`$799.99\` instead of \`$0.00\`). Once the field shows a real value, THEN call the second \`browser_blueprint\` to capture stable state. If after 10 seconds the field still hasn't updated, skip the assertion on that field — don't capture and assert a value that hasn't loaded.
@@ -573,7 +580,7 @@ ${FINISH_CHECKS_BLOCK}
     // to name the changed file it is about, and cite the file it sits
     // in, and cite `routes` from the checkout, and all of those happen while
     // it analyzes in Task 1.
-    const planningBlock = `\n${planProcedureBlock}\n\n${renderPlanDeclarationGuidance()}\n`;
+    const planningBlock = `\n${planProcedureBlock}\n`;
     return `<TITLE>${prTitle}</TITLE>
 <DESCRIPTION>${prDescription}</DESCRIPTION>
 ${primaryRepoBlock}<REPOSITORY PATH>${repositoryPath}</REPOSITORY PATH>
@@ -603,9 +610,9 @@ In these cases:
 - \`issuesFound\` must be \`[]\` — do NOT add a "No testable behavioral surface" entry; the business case already explains the abstention
 - \`businessCaseAnalysis\` must be a one-sentence summary of what the PR actually does (do NOT leave it blank)
 
-**This zero-test path does NOT apply when the requirement check in ${taskRef(TASK_ANALYZE_MAINTAIN)} found a \`requirement_conflict\`.** A requirement the PR states and the diff did not implement is testable surface, whatever the diff otherwise contains. Report the conflict in \`issuesFound\` at severity \`high\` or above, and carry the failing \`requirement_conflict\` test in \`newTestsCreated\`. Where the requirement is observable nowhere you can reach, say that in \`businessCaseAnalysis\`. Abstaining there hands the author back their own code as though it were the requirement.
+**This zero-test path does NOT apply when the requirement check found a \`requirement_conflict\`.** A requirement the PR states and the diff did not implement is testable surface, whatever the diff otherwise contains. Report the conflict in \`issuesFound\` at severity \`high\` or above, and carry the failing \`requirement_conflict\` test in \`newTestsCreated\`. Where the requirement is observable nowhere you can reach, say that in \`businessCaseAnalysis\`. Abstaining there hands the author back their own code as though it were the requirement.
 
-${task3CountRule ? `${task3CountRule}\n\n` : ""}${reportLanguageBlock}Call \`skyramp_submit_report\`. Field names, types, and formats are defined in the tool's parameter schema — follow them exactly.
+${task3CountRule ? `${task3CountRule}\n\n` : ""}${reportLanguageBlock}Call \`skyramp_submit_report\`. Field names, types, and formats are defined in the tool's parameter schema — follow them exactly. A report check objects to an \`issuesFound\` entry with \`category: bug\` that no delivered test proves. The \`plannedTestId\` and \`defectId\` descriptions in the schema say what closes it. Answer an objection in one line.
 
 ${hasRelatedRepos
         ? `

package/build/recommendation/answers.d.ts

@@ -19,13 +19,17 @@ export declare function unknownAnswerObjections(objections: Objection[], acknowl
  *  leave the bug. `verifierContracts.ts` carries the evidence. */
 export declare const NON_ANSWERABLE_PREFIX = "coverage:stateTest:";
 export declare function isNonAnswerable(objectionId: unknown): boolean;
-/** The objection a sentence alone does not close either. A change with no test
- *  needs the test, unless this run could not write one — so the answer closes it
- *  only when it also names what stopped the run. Measured on run 34176038240:
- *  across eight fixtures 45 objections were raised and 45 were closed, and the one
- *  class that a sentence cannot close was never raised at all. Prose closed every
- *  uncovered change, including changes nothing prevented a test from reaching. */
-export declare const BLOCKER_ONLY_PREFIX = "coverage:change:";
+/** The objections a sentence alone does not close either. A change with no test
+ *  needs the test, and a defect with no test needs the test — a defect the code
+ *  already had before this pull request included. Either one closes only when the
+ *  answer also names what stopped the test: a service that is not running, a
+ *  branch that no longer exists, the one credential the run holds. Measured on run
+ *  34176038240: across eight fixtures 45 objections were raised and 45 were
+ *  closed, and the one class that a sentence cannot close was never raised at all.
+ *  Prose closed every uncovered change, including changes nothing prevented a test
+ *  from reaching. Runs 34423214322 and 34423217796 then lost three defects the
+ *  baseline reported: each was listed and closed by a sentence. */
+export declare const BLOCKER_ONLY_PREFIXES: readonly ["coverage:change:", "defects:untested:"];
 export declare function needsBlocker(objectionId: unknown): boolean;
 /** The objection raised below carries this prefix and the id it objects to. */
 export declare const REFUSED_ANSWER_PREFIX = "answers:refused:";

package/build/recommendation/answers.js

@@ -49,15 +49,19 @@ export const NON_ANSWERABLE_PREFIX = "coverage:stateTest:";
 export function isNonAnswerable(objectionId) {
     return typeof objectionId === "string" && objectionId.startsWith(NON_ANSWERABLE_PREFIX);
 }
-/** The objection a sentence alone does not close either. A change with no test
- *  needs the test, unless this run could not write one — so the answer closes it
- *  only when it also names what stopped the run. Measured on run 34176038240:
- *  across eight fixtures 45 objections were raised and 45 were closed, and the one
- *  class that a sentence cannot close was never raised at all. Prose closed every
- *  uncovered change, including changes nothing prevented a test from reaching. */
-export const BLOCKER_ONLY_PREFIX = "coverage:change:";
+/** The objections a sentence alone does not close either. A change with no test
+ *  needs the test, and a defect with no test needs the test — a defect the code
+ *  already had before this pull request included. Either one closes only when the
+ *  answer also names what stopped the test: a service that is not running, a
+ *  branch that no longer exists, the one credential the run holds. Measured on run
+ *  34176038240: across eight fixtures 45 objections were raised and 45 were
+ *  closed, and the one class that a sentence cannot close was never raised at all.
+ *  Prose closed every uncovered change, including changes nothing prevented a test
+ *  from reaching. Runs 34423214322 and 34423217796 then lost three defects the
+ *  baseline reported: each was listed and closed by a sentence. */
+export const BLOCKER_ONLY_PREFIXES = ["coverage:change:", "defects:untested:"];
 export function needsBlocker(objectionId) {
-    return typeof objectionId === "string" && objectionId.startsWith(BLOCKER_ONLY_PREFIX);
+    return typeof objectionId === "string" && BLOCKER_ONLY_PREFIXES.some((prefix) => objectionId.startsWith(prefix));
 }
 /** The objection raised below carries this prefix and the id it objects to. */
 export const REFUSED_ANSWER_PREFIX = "answers:refused:";
@@ -84,11 +88,11 @@ export function refusedAnswerObjections(objections, acknowledged) {
             objectionId: `${REFUSED_ANSWER_PREFIX}${id}`,
             verifier: "answers",
             message: needsBlocker(id)
-                ? "The answer says why this change has no test, and it does not say what stopped this run from writing one, so the objection stays open."
+                ? "The answer says why there is no test, and it does not say what stopped this run from writing one, so the objection stays open."
                 : "This objection is closed only by a planned test, so the answer closed nothing and the objection stays open.",
             evidence: `answered "${id}"${needsBlocker(id) ? " with no `blocker`" : ", which no answer closes"}`,
             suggestion: needsBlocker(id)
-                ? "Plan a test for this change and register the plan again. If this run cannot write one, send the same answer with `blocker` naming what stopped it — a service that is not running, a paired branch that no longer exists, the one credential the run holds. A reason the change is not worth testing is not a blocker."
+                ? "Plan the test and register the plan again. If this run cannot write one, send the same answer with `blocker` naming what stopped it — a service that is not running, a paired branch that no longer exists, the one credential the run holds. A reason it is not worth testing is not a blocker."
                 : "Add a planned test that names the record's state as `startState` and runs this route's mutation on it, then register the plan again. Every other objection takes an answer; this one takes a test.",
         });
     }

package/build/recommendation/pullRequestText.d.ts

@@ -0,0 +1,18 @@
+/** Called by every entry point that renders the testbot prompt, with the values it
+ *  renders. */
+export declare function recordPullRequestText(title: unknown, description: unknown): void;
+/** UNDEFINED when this process never rendered the prompt — a caller that drives the
+ *  tools directly, or a test. A check that reads the pull request stays silent then;
+ *  it cannot tell an empty pull request from one it never saw. */
+export declare function pullRequestText(): {
+    title: string;
+    description: string;
+} | undefined;
+export declare function clearPullRequestText(): void;
+/** The pull request as one searchable string. Whitespace runs fold to one space, so
+ *  a quote wrapped across lines still matches the sentence it was taken from. */
+export declare const searchable: (pr: {
+    title: string;
+    description: string;
+}) => string;
+export declare const appearsIn: (haystack: string, needle: string) => boolean;