@skyramp/mcp 0.4.1-rc.1 → 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.",
         ],
@@ -34,7 +51,7 @@ expect(response.statusCode).toBe(201);`,
             "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.",
+            '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: [
             {
@@ -60,16 +77,6 @@ assert skyramp.get_response_value(record_post_response, "insertedId") is None`,
             },
         ],
     },
-    {
-        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.",
@@ -117,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.",
@@ -128,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: [
             {
@@ -139,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: [
@@ -216,9 +223,18 @@ 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.
@@ -227,12 +243,14 @@ Before editing the given file, you must output a \`<thinking>\` block. The aim o
 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}
   }
@@ -251,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.
@@ -261,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,9 +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 { 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) {
@@ -25,7 +26,12 @@ const SKYRAMP_TEST_FILE_PATTERN = /(?:_test|_smoke|_contract|_fuzz|_integration|
  *  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();
+    // 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

@@ -5,6 +5,7 @@ import { buildPathParamGuidance, } from "../test-recommendation/recommendationSe
 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";
@@ -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 a twelve-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 7's maintenance update is Task 1's
-// tool step, step 10'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.
@@ -460,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.

package/build/recommendation/registerPlan.d.ts

@@ -1,4 +1,4 @@
-import { Objection, ObjectionAnswer, PlanChange, PlanDefect, PlanInput, PlannedTest, VerifyContext } from "./types.js";
+import { Objection, ObjectionAnswer, PlanChange, PlanDefect, PlanInput, PlanMaintenance, PlannedTest, VerifyContext } from "./types.js";
 /** The plan as stored for the run. Every registration produces one; the newest
  *  replaces the last. */
 export interface Plan {
@@ -10,6 +10,10 @@ export interface Plan {
      *  test that proves it. */
     defects: PlanDefect[];
     plannedTests: PlannedTest[];
+    /** Existing tests this run edits instead of planning new ones. Stored because
+     *  `coverage` counts the changes they cite, so a reader of the plan has to be
+     *  able to see which coverage came from maintenance rather than a new test. */
+    maintains?: PlanMaintenance[];
     /** Objections the agent answered, with the answers. */
     answeredObjections: Array<{
         objection: Objection;

package/build/recommendation/registerPlan.js

@@ -110,6 +110,11 @@ export function registerPlan(registration, ctx, previous) {
             changes,
             defects,
             plannedTests,
+            // Only when declared: the field is optional, and writing `[]` on every plan
+            // would change the stored shape of every run that maintains nothing.
+            ...(Array.isArray(registration.maintains) && registration.maintains.length > 0
+                ? { maintains: registration.maintains }
+                : {}),
             answeredObjections,
             unverifiedCloses,
             openObjections,

package/build/recommendation/types.d.ts

@@ -41,9 +41,15 @@ export interface PlanChange {
          *  test asserts a value the plan decided, not the value the running app
          *  happened to return — the one source that always agrees with a defect. */
         expectedValue?: string | number | boolean | null;
-        /** Where the agent read `expectedValue`: `pr-description`, `spec:<path>`,
-         *  `convention:<file:line>`, or `code`. */
+        /** Where the agent read `expectedValue` OR `derived` — the check reads it for
+         *  either one: `pr-description`, `spec:<path>`, `convention:<file:line>`, or
+         *  `code`. */
         expectedFrom?: string;
+        /** The rule the value follows from, in the source's words, when the source
+         *  states a rule and not a value. Stands in for `expectedValue`: the test
+         *  computes the number from what it sent, so nothing pins one the source
+         *  never wrote. */
+        derived?: string;
     }>;
 }
 /** One defect the code review found, as the agent read it. Nothing on the server
@@ -124,6 +130,20 @@ export interface ObjectionAnswer {
      *  An objection about an untested change closes only with one of these. */
     blocker?: string;
 }
+/** An existing test this run maintains instead of planning a new one, and the
+ *  declared changes that maintenance covers. A removal already covered by a spec
+ *  is maintained, not duplicated, so the plan needs a way to say "this change is
+ *  tested by a file I am editing" — without it, `coverage:change:` is unanswerable
+ *  for a correct maintenance decision, and it closes only with a `blocker`. */
+export interface PlanMaintenance {
+    /** Repository-relative path of the existing test. Only its presence in the
+     *  checkout is checked, the same rule `declarations.existingTests` follows. */
+    file: string;
+    /** The edit this run makes to it, in one sentence. */
+    differsBy: string;
+    /** The ids of the declared changes this maintenance covers. */
+    changes: string[];
+}
 export interface PlanInput {
     /** The changes the diff makes. Each planned test cites the ones it tests. */
     changes: PlanChange[];
@@ -132,6 +152,9 @@ export interface PlanInput {
      *  objection the agent answers. */
     defects: PlanDefect[];
     plannedTests: PlannedTest[];
+    /** Existing tests this run edits rather than replacing with new ones. Coverage
+     *  counts the changes these cite, so a maintenance-only plan is a complete plan. */
+    maintains?: PlanMaintenance[];
     answers: ObjectionAnswer[];
     /** The tool owns this and overwrites whatever the caller sends. */
     registrationNumber: number;

package/build/recommendation/verifierContracts.d.ts

@@ -106,8 +106,16 @@ export declare const EXISTING_COVERAGE_CONTRACT: {
             readonly message: "This planned test names an existing test file that is not in the checkout.";
             readonly suggestion: "Name the file repository-relative, spelled as the analysis lists it. Drop the entry if it names a test you did not read — naming none is an answer too.";
         };
+        readonly maintainedTestMissing: {
+            readonly message: "`maintains` names an existing test file that is not in the checkout.";
+            readonly suggestion: "Name the file repository-relative, spelled as the analysis lists it. A maintenance entry is what makes its changes count as covered, so it has to name a file this run can edit.";
+        };
+        readonly maintainedUnknownChange: {
+            readonly message: "A `maintains` entry cites a change id that this plan does not declare.";
+            readonly suggestion: "Spell the change's `id` exactly as your own `changes` list gives it — the match is exact apart from surrounding space. Declare the change if it is missing.";
+        };
     };
-    readonly suggestion: "Which existing tests did you read on this change, and how does this planned test differ from them?";
+    readonly suggestion: "Which existing tests did you read on this change, how does this planned test differ from them, and which changes does the maintenance you are doing cover?";
 };
 export declare const EXPECTED_OUTCOME_CONTRACT: {
     readonly id: "expectedOutcome";
@@ -150,7 +158,7 @@ export declare const COVERAGE_CONTRACT: {
     readonly objections: {
         readonly change: {
             readonly message: "This declared change has no test in the plan.";
-            readonly suggestion: "Plan a test that exercises it. If this run cannot write one, answer it and set `blocker` to what stopped the run — a service that is not running, a paired branch that no longer exists, the one credential the run holds. An answer with no blocker leaves this open: a change nothing prevented a test from reaching takes the test. Coverage per file is the basic minimum; coverage per change is what the plan is judged by, so a file covered by a shape test still leaves the change it makes untested.";
+            readonly suggestion: "Plan a test that exercises it. If an existing test already covers it and this run edits that test rather than writing a new one, declare it in `maintains` with the file, what your edit changes, and this change's id — maintenance is coverage, and a duplicate spec beside the one you edited is the mistake. If this run cannot write one, answer it and set `blocker` to what stopped the run — a service that is not running, a paired branch that no longer exists, the one credential the run holds. An answer with no blocker leaves this open: a change nothing prevented a test from reaching takes the test. Coverage per file is the basic minimum; coverage per change is what the plan is judged by, so a file covered by a shape test still leaves the change it makes untested.";
         };
         readonly noChanges: {
             readonly message: "The plan declares no changes, so nothing says what the pull request must make different.";
@@ -218,11 +226,15 @@ export declare const EXPECTED_VALUE_SOURCED_CONTRACT: {
         };
         readonly quoteMissing: {
             readonly message: "This case reads its value from the pull request, and its change does not quote the sentence that states the rule.";
-            readonly suggestion: "Put the sentence from the title or description on the change as `quote`, as written there. Derive this case's value from that rule; the value itself need not appear in the pull request.";
+            readonly suggestion: "Put the sentence from the title or description on the change as `quote`, as written there. If that sentence states the rule and not the number, put the rule in `derived` and leave `expectedValue` out.";
+        };
+        readonly valueNotQuoted: {
+            readonly message: "This case reads its value from the pull request, and the pull request does not state this value.";
+            readonly suggestion: "Quote the sentence that states it, or, if the pull request states a rule, put the rule in `derived` and leave `expectedValue` out; the test computes the value from what it sent.";
         };
         readonly failWithoutValue: {
             readonly message: "This test expects to fail, and no case on the changes it cites states the value it must assert.";
-            readonly suggestion: "Put the value the code does not return today on the case this test sends, as `expectedValue`, and name where you read it. If no source states the value, answer with what the test asserts instead and where that comes from.";
+            readonly suggestion: "Put the value the code does not return today on the case this test sends, as `expectedValue`, and name where you read it. If the source states a rule rather than a number, put the rule in `derived` instead. If no source states either, answer with what the test asserts instead and where that comes from.";
         };
     };
     readonly suggestion: "Where does the correct value for this case come from?";