@bendyline/gilde 0.1.40 → 0.1.41

package/authoring/tactical/books/test-suite-backfill.json

@@ -0,0 +1,172 @@
+{
+  "id": "test-suite-backfill",
+  "name": "Test Suite Backfill",
+  "description": "Add tests that actually bite to untested code: rank the untested behavior by breakage cost, write tests in the project's real layout that a wrong implementation would fail, and prove the suite green with real run receipts — under an enforced independent review.",
+  "category": "code-quality",
+  "role": "maintenance-review",
+  "tags": [
+    "tests",
+    "coverage",
+    "testing",
+    "quality",
+    "regression"
+  ],
+  "triggers": [
+    "add tests to this code",
+    "backfill tests",
+    "increase test coverage",
+    "write tests for an untested module",
+    "test this function"
+  ],
+  "about": "Backfill a test suite that would actually catch a regression, not one that inflates a coverage number. First map the RISK: read the target modules and rank their untested behavior by breakage cost — what would hurt most if it went silently wrong — then choose concrete targets, because a suite built without that ranking pins the easy paths and misses the expensive ones. Then WRITE the tests in the project's real test layout and style, with one discipline above all others: every test must be able to FAIL. Assert actual values, actual errors, actual edge cases — never tautologies like expecting true, asserting a mock returns what it was told, or restating the implementation back at itself. The module under test does not change: if a test exposes what looks like a genuine bug, pin the current behavior or flag it honestly for the user instead of silently editing the source to match an expectation. Then VERIFY with the whole suite green — judged from real run receipts, not the author's summary — and a per-test statement of the regression each one guards. Finally an independent reviewer opens the tests themselves and grades the assertions against fixed criteria; a REVISE verdict routes the work back automatically with concrete findings. Needs a project whose tests run via `npm run test`. Suited to unattended night-shift runs. Works identically whether the run edits the project directly or drafts a change proposal for the user to apply.",
+  "doc": {
+    "capabilityFloor": "small",
+    "diffpackCapable": true,
+    "commands": [
+      {
+        "scope": "script",
+        "name": "test",
+        "reason": "The new tests must run green in the real suite — the verify gate checks real run receipts, not claims."
+      }
+    ],
+    "runModes": {
+      "nightShift": "supported"
+    }
+  },
+  "workflow": {
+    "plan": "Map untested behavior by breakage cost and choose targets -> write tests in the real layout that a wrong implementation would fail -> verify the whole suite green with run receipts -> enforced independent review of the assertions.",
+    "maxGateAttempts": 4,
+    "maxReviewRounds": 3,
+    "phases": [
+      {
+        "id": "risk-map",
+        "name": "Map the risk",
+        "description": "Read the target modules and rank untested behavior by breakage cost; choose concrete targets. No test writing yet.",
+        "suggestedRole": "quality engineer",
+        "capabilityFloor": "small",
+        "prompt": "Before writing any test, learn what is worth testing. Read the target module(s) named by the task with `read_file` — the whole file, not the signatures — and read the existing test layout (`list_dir` on the test folder, then the test files) to learn where tests live and how this project writes them. Rank the UNTESTED behavior by breakage cost: what would hurt users or downstream code most if it went silently wrong — boundary semantics, error contracts, arithmetic, state transitions — not what is easiest to cover. Then choose concrete targets: the specific functions and the specific behaviors of each you will pin, including the edge and error cases. Be honest about what you are deliberately leaving untested and why.\n\nWrite `{{workPath}}/risk-map.md` with exactly these sections: `## Modules` (each target module and what it does, with backtick paths), `## Risks ranked` (the untested behaviors ordered by breakage cost, with the cost stated), `## Chosen targets` (the tests you will write, each naming the behavior it pins). Every path you cite must be real.",
+        "output": {
+          "path": "{{workPath}}/risk-map.md",
+          "minBytes": 500,
+          "requiredPatterns": [
+            {
+              "pattern": "^##\\s+Modules",
+              "label": "Modules section"
+            },
+            {
+              "pattern": "^##\\s+Risks ranked",
+              "label": "Risks ranked section"
+            },
+            {
+              "pattern": "^##\\s+Chosen targets",
+              "label": "Chosen targets section"
+            }
+          ],
+          "additionalChecks": [
+            {
+              "kind": "citationsResolve",
+              "file": "{{workPath}}/risk-map.md",
+              "minCitations": 2,
+              "artifact": true
+            }
+          ]
+        }
+      },
+      {
+        "id": "write-tests",
+        "name": "Write tests that can fail",
+        "description": "Add the tests in the project's real layout and style, asserting actual behavior — never tautologies.",
+        "suggestedRole": "software engineer",
+        "capabilityFloor": "small",
+        "prompt": "Read `{{workPath}}/risk-map.md` and write the chosen tests in the project's REAL test layout and style — the same folder, naming convention, and assertion idioms the existing tests use, added with `write_file`. There is no prescribed output path for the tests themselves; they live where this project's tests live. Every test must be able to FAIL: assert actual values, actual thrown errors, actual edge-case results. Never write tautologies — expecting true, asserting a mock returns what it was told, or asserting whatever the implementation currently returns without knowing why it is right. Backfill means tests, not source changes: do not modify the module under test. If a test exposes what you believe is a genuine bug, pin the current behavior with a characterization test or flag it honestly in your notes for the user — never silently edit the source to match your expectation. Run the suite with `run_package_script` (`test`) as you go and make each test pass for the right reason; if the command needs first-use approval, say so and wait rather than guessing.\n\nThen write `{{workPath}}/test-notes.md` with exactly these sections: `## Tests added` (the real path of every new test file, backtick path per line), `## Behaviors pinned` (each test and the exact behavior it asserts), `## How each test would catch a realistic break` (for each test, the plausible wrong implementation it would fail on).",
+        "output": {
+          "path": "{{workPath}}/test-notes.md",
+          "minBytes": 600,
+          "requiredPatterns": [
+            {
+              "pattern": "^##\\s+Tests added",
+              "label": "Tests added section"
+            },
+            {
+              "pattern": "^##\\s+Behaviors pinned",
+              "label": "Behaviors pinned section"
+            },
+            {
+              "pattern": "^##\\s+How each test would catch a realistic break",
+              "label": "realistic-break section"
+            }
+          ],
+          "additionalChecks": [
+            {
+              "kind": "citationsResolve",
+              "file": "{{workPath}}/test-notes.md",
+              "minCitations": 2,
+              "artifact": true
+            }
+          ]
+        }
+      },
+      {
+        "id": "verify",
+        "name": "Verify the suite green",
+        "description": "Run the whole suite and record the real result, with a per-test statement of the regression it guards.",
+        "suggestedRole": "software engineer",
+        "capabilityFloor": "small",
+        "prompt": "Prove the backfill with a full, fresh run. Execute the whole suite with `run_package_script` (`test`) — every test, old and new, must pass. If anything fails, fix the TEST (or honestly report the module bug it exposed); do not touch the module under test to force green. Then account for the coverage: for each new test, one line stating the regression it now guards — what break it would catch that yesterday's suite would have missed. Compare against `{{workPath}}/risk-map.md`: any chosen target you did not cover gets an honest deferral with the reason, never silence.\n\nWrite `{{workPath}}/verification.md` with exactly these sections: `## Suite` (the exact command and the real full-suite result), `## Coverage summary` (per-test: the regression it guards; plus honest deferrals), `## Result` (green confirmed, or what remains open and why).",
+        "output": {
+          "path": "{{workPath}}/verification.md",
+          "minBytes": 400,
+          "requiredPatterns": [
+            {
+              "pattern": "^##\\s+Suite",
+              "label": "Suite section"
+            },
+            {
+              "pattern": "^##\\s+Coverage summary",
+              "label": "Coverage summary section"
+            },
+            {
+              "pattern": "^##\\s+Result",
+              "label": "Result section"
+            }
+          ],
+          "additionalChecks": [
+            {
+              "kind": "citationsResolve",
+              "file": "{{workPath}}/verification.md",
+              "minCitations": 2,
+              "artifact": true
+            },
+            {
+              "kind": "commandEvidence",
+              "script": "test",
+              "expect": "pass",
+              "label": "the whole suite is green with the new tests (verified run receipt)"
+            }
+          ]
+        }
+      }
+    ],
+    "review": {
+      "artifactPath": "{{workPath}}/verification.md",
+      "relatedPaths": [
+        "{{workPath}}/risk-map.md",
+        "{{workPath}}/test-notes.md"
+      ],
+      "reviewPath": "{{workPath}}/review.md",
+      "reviewerRole": "test reviewer",
+      "repairRole": "software engineer",
+      "minReviewBytes": 400,
+      "enforce": {
+        "fixStepId": "repair"
+      },
+      "criteria": [
+        "The new tests live in the project's real test layout and follow its existing naming and assertion style — open the test files and check.",
+        "Each test pins observable behavior a wrong implementation would fail: open the assertions — expecting true, asserting a mock returns what it was told, or restating the implementation back at itself does not pass.",
+        "The edge and error cases the risk map ranked are covered, or honestly deferred with a stated reason — reconcile risk-map.md's chosen targets against test-notes.md and verification.md.",
+        "The whole suite is green by real run receipt, judged from the recorded runs rather than the author's summary.",
+        "The module under test was not modified to make tests pass — the only changes are new or updated test files and the working notes."
+      ]
+    }
+  }
+}

package/authoring/tactical/books/type-safety-pass.json

@@ -0,0 +1,185 @@
+{
+  "id": "type-safety-pass",
+  "name": "Type-Safety Pass",
+  "description": "Tighten a module against unsafe patterns — loose equality, implicit coercions, swallowed catches, untyped boundaries, any-casts — with counted evidence: an audit that inventories the patterns by a stated method, fixes that never silence a check to move a count, a same-method re-count, and an enforced independent review.",
+  "category": "code-quality",
+  "role": "maintenance-review",
+  "tags": [
+    "types",
+    "typescript",
+    "javascript",
+    "type-safety",
+    "strict",
+    "quality"
+  ],
+  "triggers": [
+    "tighten the types",
+    "kill any types",
+    "add type annotations",
+    "make this type-safe",
+    "fix type errors"
+  ],
+  "about": "Tighten code against the unsafe patterns that turn into 3am bugs, with the improvement proven by counting rather than claiming. First AUDIT: inventory the patterns in scope WITH COUNTS gathered by a stated, repeatable method (a grep per pattern, expressions quoted) — loose equality against null or undefined, implicit string/number coercions, swallowed catches that hide real errors, untyped or unvalidated boundaries, and in TypeScript projects any-casts and ignore-comments. The audit picks the concrete targets, names which behavioral consequences of these patterns are bugs this pass is expected to fix, records the guardrail, and captures the suite green before any change. Then CHANGE: fix pattern by pattern at the real sites — and never buy a lower count by weakening the code: no deleted assertions, no silenced error paths, no bare casts, no ignore-comments; a count that falls that way is a regression wearing a metric. Then VERIFY: re-count with exactly the audit's method, quote before and after per pattern, and show the suite green. Finally an independent reviewer grades the chain — counts genuinely fell by the same method, no suppression, behavior preserved except the declared consequence fixes — and a REVISE verdict routes the work back automatically with concrete findings. Small enough to run as night-shift work. Needs a project whose tests run via `npm run test`. Works identically whether the run edits the project directly or drafts a change proposal for the user to apply.",
+  "doc": {
+    "paramSchema": {
+      "type": "object",
+      "properties": {
+        "scope": {
+          "type": "string",
+          "title": "Where to tighten",
+          "description": "The module, folder, or area to audit for unsafe patterns. Leave empty when the task description already carries it.",
+          "default": ""
+        }
+      }
+    },
+    "capabilityFloor": "small",
+    "diffpackCapable": true,
+    "runModes": {
+      "nightShift": "supported"
+    },
+    "commands": [
+      {
+        "scope": "script",
+        "name": "test",
+        "reason": "The suite is the guardrail: it must be green before the pass starts and green at the end, so tightened checks provably did not break pinned behavior. The gates verify the green-before/green-after receipts from real runs, not the author's claims."
+      }
+    ]
+  },
+  "workflow": {
+    "plan": "Audit the unsafe patterns with counts and a stated method, pick targets, record the guardrail and a green suite -> fix pattern by pattern at the real sites without silencing anything -> re-count with the same method, quote before/after, suite green -> enforced independent review.",
+    "maxGateAttempts": 4,
+    "maxReviewRounds": 3,
+    "phases": [
+      {
+        "id": "audit",
+        "name": "Audit with counts",
+        "description": "Inventory the unsafe patterns in scope with counts by a stated method, pick concrete targets, record the guardrail, and capture the suite green.",
+        "suggestedRole": "code auditor",
+        "capabilityFloor": "small",
+        "prompt": "The area to tighten: {{scope}}\n\nInventory the unsafe patterns before fixing any of them — the improvement will be proven by re-counting later, so the counts and the exact method are the deliverable here. Read the involved source, then count each pattern class in scope with a stated, repeatable method (a grep per pattern works; quote the exact expressions you used): loose equality against null or undefined (`==`/`!=` where a strict check belongs), implicit string/number coercions (arithmetic or concatenation on values that may arrive as strings), swallowed catches (a catch that hides the error and carries on as if nothing failed), untyped or unvalidated boundaries (inputs used without a shape check), and in TypeScript projects `any`-casts and ignore-comments. Record the count per pattern and where each hit lives.\n\nPick the concrete targets for this pass and state the guardrail: which behavior is pinned by tests and must not change, and which behavioral CONSEQUENCES of these patterns are bugs this pass is expected to fix — name each one. Then find how the project runs its tests (`list_package_scripts`), run the suite with `run_package_script` (`test`), and record it green before any change; if it is already red, stop and report that honestly. If the command needs first-use approval, say so and wait rather than guessing.\n\nWrite `{{workPath}}/audit.md` with exactly these sections: `## Inventory` (counts by pattern with the exact method and grep expressions used), `## Targets` (the hits this pass will fix, with backtick paths), `## Guardrail` (what must not change, and the declared consequence fixes that may). Cite the real files with backtick paths.",
+        "output": {
+          "path": "{{workPath}}/audit.md",
+          "minBytes": 600,
+          "requiredPatterns": [
+            {
+              "pattern": "^##\\s+Inventory[\\s\\S]*\\d",
+              "label": "Inventory section with counts"
+            },
+            {
+              "pattern": "^##\\s+Targets",
+              "label": "Targets section"
+            },
+            {
+              "pattern": "^##\\s+Guardrail",
+              "label": "Guardrail section"
+            }
+          ],
+          "additionalChecks": [
+            {
+              "kind": "citationsResolve",
+              "file": "{{workPath}}/audit.md",
+              "minCitations": 2,
+              "artifact": true
+            },
+            {
+              "kind": "commandEvidence",
+              "script": "test",
+              "expect": "pass",
+              "label": "green before the work starts"
+            }
+          ]
+        }
+      },
+      {
+        "id": "change",
+        "name": "Fix pattern by pattern",
+        "description": "Fix the targeted patterns at the real sites, never silencing a check or weakening an assertion to move a count.",
+        "suggestedRole": "software engineer",
+        "capabilityFloor": "small",
+        "prompt": "Read `{{workPath}}/audit.md` and fix the targeted patterns at the REAL sites with `read_file` plus `write_file`/`replace_in_file`, pattern by pattern. Replace loose equality with strict checks that state what they mean; normalize or validate values at the boundary they cross instead of coercing mid-calculation; make swallowed catches surface the error — rethrow, or report it the way the audit's guardrail declares — rather than carrying on as if nothing failed. Never buy a lower count by weakening the code: no deleting an assertion, no silencing an error path, no bare casts, and in TypeScript no `any` or ignore-comment to make a diagnostic disappear — a count that falls that way is a regression wearing a metric. Behavior changes only where the audit declared a consequence fix, and each one gets named in your notes. Run the suite with `run_package_script` (`test`) as you go and keep it green; a change that goes red gets narrowed, not stacked on. If a targeted hit turns out to be correct as written, record why and leave it — honesty beats a moved count.\n\nWrite `{{workPath}}/change-notes.md` with exactly these sections: `## Patterns addressed` (each pattern class, what the fix was, and any declared consequence fix it delivered), `## Files touched` (backtick path per line), `## Deviations` (targets handled differently than the audit planned, or `none`, honestly).",
+        "output": {
+          "path": "{{workPath}}/change-notes.md",
+          "minBytes": 600,
+          "requiredPatterns": [
+            {
+              "pattern": "^##\\s+Patterns addressed",
+              "label": "Patterns addressed section"
+            },
+            {
+              "pattern": "^##\\s+Files touched",
+              "label": "Files touched section"
+            },
+            {
+              "pattern": "^##\\s+Deviations",
+              "label": "Deviations section"
+            }
+          ],
+          "additionalChecks": [
+            {
+              "kind": "citationsResolve",
+              "file": "{{workPath}}/change-notes.md",
+              "minCitations": 2,
+              "artifact": true
+            }
+          ]
+        }
+      },
+      {
+        "id": "verify",
+        "name": "Re-count and verify",
+        "description": "Re-count every pattern with exactly the audit's method, quote before/after counts, and record the suite green.",
+        "suggestedRole": "software engineer",
+        "capabilityFloor": "small",
+        "prompt": "Prove the pass with fresh eyes. Read `{{workPath}}/audit.md` and RE-COUNT every pattern with EXACTLY the method and grep expressions it records — same expressions, same scope; a changed method voids the comparison, and if the recorded method cannot be reproduced that is a finding to report, not a license to substitute one. Quote the audit's count and the new count for each pattern side by side. Run the whole suite with `run_package_script` (`test`) and record the green result. Spot-check the fixed sites: the checks got stronger, not deleted, and no cast or ignore-comment crept in. Anything you could not actually re-run gets labeled unverified, never claimed.\n\nWrite `{{workPath}}/verification.md` with exactly these sections: `## Before / after counts` (per pattern, the audit count next to the re-count, same greps), `## Suite` (the full-suite result from the real run), `## Result` (which declared consequences are now fixed, and anything unverified).",
+        "output": {
+          "path": "{{workPath}}/verification.md",
+          "minBytes": 400,
+          "requiredPatterns": [
+            {
+              "pattern": "^##\\s+Before\\s*/\\s*after counts[\\s\\S]*\\d",
+              "label": "Before / after counts with figures"
+            },
+            {
+              "pattern": "^##\\s+Suite",
+              "label": "Suite section"
+            },
+            {
+              "pattern": "^##\\s+Result",
+              "label": "Result section"
+            }
+          ],
+          "additionalChecks": [
+            {
+              "kind": "commandEvidence",
+              "script": "test",
+              "expect": "pass",
+              "label": "green after the pass (verified run receipt)"
+            }
+          ]
+        }
+      }
+    ],
+    "review": {
+      "artifactPath": "{{workPath}}/verification.md",
+      "relatedPaths": [
+        "{{workPath}}/audit.md",
+        "{{workPath}}/change-notes.md"
+      ],
+      "reviewPath": "{{workPath}}/review.md",
+      "reviewerRole": "code-quality reviewer",
+      "repairRole": "software engineer",
+      "minReviewBytes": 400,
+      "enforce": {
+        "fixStepId": "repair"
+      },
+      "criteria": [
+        "audit.md counts real patterns in real files with the exact method recorded (grep expressions quoted), and a green suite receipt exists from before the work started.",
+        "Counts genuinely fell and the re-count method matches the audit's exactly: verification.md quotes before and after per pattern — the measured target moved against the recorded baseline using the same method.",
+        "No suppression bought the improvement: open the touched files and confirm no assertion was weakened, no check deleted, no error path silenced, and no cast or ignore-comment introduced to move a count.",
+        "Observable behavior unchanged (or changed only as the audit declared): each consequence fix the audit named happened and is recorded in change-notes.md, and nothing else moved.",
+        "No stage left the suite red (receipts, not claims): green before the pass and green after it, from real runs.",
+        "change-notes.md names every touched file (paths that exist) and records its deviations honestly, including targets left alone because they were correct as written."
+      ]
+    }
+  }
+}

package/authoring/tactical/books/ux-update.json

@@ -0,0 +1,178 @@
+{
+  "id": "ux-update",
+  "name": "Implement a UX Change",
+  "description": "Deliver a described UX change the disciplined way: capture the before state from the real markup, make the smallest coherent change at the real sites in the product's own conventions, and prove the after state with the existing behaviors still working — under an enforced independent review.",
+  "category": "code-build",
+  "role": "general",
+  "tags": [
+    "ux",
+    "ui",
+    "frontend",
+    "user-experience",
+    "polish"
+  ],
+  "triggers": [
+    "make this ux change",
+    "move the button",
+    "improve this flow",
+    "update the ui"
+  ],
+  "about": "Implement a UX change the way a careful product engineer would — grounded in the real code at every step, not in a redescription of it. First UNDERSTAND: restate the requested change as the user would experience it, find the involved surfaces in the actual pages, components, styles, and scripts, and capture the BEFORE state by quoting the real markup and wiring — including every behavior attached to those surfaces (handlers, keyboard shortcuts, ids, state), because each must still work afterwards. Then IMPLEMENT the smallest coherent change at those real sites, matching the surrounding product's conventions — its spacing, naming, and markup patterns — rather than inventing a new style, and moving existing behaviors with the elements rather than dropping them. Then VALIDATE by walking the changed flow and building a concrete before/after comparison grounded in the files, honest about what was inspected versus actually exercised. Finally an independent reviewer grades the delivered change as a user would judge it — request delivered, conventions respected, nothing that worked before broken — and a REVISE verdict routes the work back automatically with concrete findings. This is the fix-applying sibling of the report-only codebase UX review: that book tells you what is wrong, this one delivers the change. Works identically whether the run edits the project directly or drafts a change proposal for the user to apply.",
+  "doc": {
+    "paramSchema": {
+      "type": "object",
+      "properties": {
+        "scope": {
+          "type": "string",
+          "title": "The UX change",
+          "description": "What should change for the user, in plain words. Leave empty when the task description carries it.",
+          "default": ""
+        }
+      }
+    },
+    "capabilityFloor": "small",
+    "diffpackCapable": true
+  },
+  "workflow": {
+    "plan": "Understand the request and capture the before state from the real code -> implement the smallest coherent change at the real sites in the product's own conventions -> validate the flow with a concrete before/after -> enforced independent review.",
+    "maxGateAttempts": 4,
+    "maxReviewRounds": 3,
+    "phases": [
+      {
+        "id": "understand",
+        "name": "Understand and capture the before state",
+        "description": "Restate the change as the user experiences it, find the real surfaces, and quote the current markup and wiring.",
+        "suggestedRole": "product engineer",
+        "capabilityFloor": "small",
+        "prompt": "The UX change to deliver: {{scope}}\n\nUnderstand before touching anything. Restate the requested change as the USER would experience it — what they see and do today, what they should see and do afterwards. Then find the involved surfaces in the REAL code: read the actual pages, components, styles, and scripts with `read_file` until you can point at the exact markup and wiring behind the current experience. Capture the BEFORE state from those files — quote the relevant snippets (the current markup, the handler, the shortcut wiring) so the change can later be judged against reality rather than memory. Catalogue every behavior attached to the surfaces you will touch — handlers, keyboard shortcuts, element ids other code references, state — because each of them must still work afterwards. If the request is ambiguous, record the reading you chose and why; if the described surface cannot be located in this codebase at all, say so honestly and stop rather than inventing one.\n\nWrite `{{workPath}}/before.md` with exactly these sections: `## Request` (the change in the user's terms), `## Current behavior` (what happens today, with the quoted snippets), `## Surfaces involved` (each file and the part it plays, with backtick paths). Every path you cite must be real.",
+        "output": {
+          "path": "{{workPath}}/before.md",
+          "minBytes": 500,
+          "requiredPatterns": [
+            {
+              "pattern": "^##\\s+Request",
+              "label": "Request section"
+            },
+            {
+              "pattern": "^##\\s+Current behavior",
+              "label": "Current behavior section"
+            },
+            {
+              "pattern": "^##\\s+Surfaces involved",
+              "label": "Surfaces involved section"
+            }
+          ],
+          "additionalChecks": [
+            {
+              "kind": "citationsResolve",
+              "file": "{{workPath}}/before.md",
+              "minCitations": 2,
+              "artifact": true
+            }
+          ]
+        }
+      },
+      {
+        "id": "implement",
+        "name": "Implement the smallest coherent change",
+        "description": "Deliver the request at the real sites, in the product's own conventions, keeping existing behaviors wired.",
+        "suggestedRole": "frontend engineer",
+        "capabilityFloor": "small",
+        "prompt": "Read `{{workPath}}/before.md` and deliver the SMALLEST coherent change at the real sites it names — edit the actual files with `read_file` plus `write_file`/`replace_in_file`; there is no prescribed output path for the change itself. Match the surrounding product's conventions: reuse its spacing, naming, class patterns, and markup style rather than inventing a new one — open neighboring code to see how this product already does the same kind of thing. Keep every existing behavior working: the handlers, keyboard shortcuts, element ids, and state catalogued in before.md must still be wired when you are done — move them with the element rather than dropping or duplicating them. Do not smuggle in unrequested changes; polish beyond the request is scope creep, not generosity.\n\nThen write `{{workPath}}/fix-notes.md` with exactly these sections: `## Problem` (the request, one paragraph), `## Change` (what you altered and how it delivers the request), `## Files touched` (backtick path per line), `## Consistency notes` (which existing conventions you followed and where you saw them), `## Risk` (what could break; be honest about anything unverified), `## How to verify` (the exact steps a person follows to see the new experience).",
+        "output": {
+          "path": "{{workPath}}/fix-notes.md",
+          "minBytes": 700,
+          "requiredPatterns": [
+            {
+              "pattern": "^##\\s+Problem",
+              "label": "Problem section"
+            },
+            {
+              "pattern": "^##\\s+Change",
+              "label": "Change section"
+            },
+            {
+              "pattern": "^##\\s+Files touched",
+              "label": "Files touched section"
+            },
+            {
+              "pattern": "^##\\s+Consistency notes",
+              "label": "Consistency notes section"
+            },
+            {
+              "pattern": "^##\\s+Risk",
+              "label": "Risk section"
+            },
+            {
+              "pattern": "^##\\s+How to verify",
+              "label": "How to verify section"
+            }
+          ],
+          "additionalChecks": [
+            {
+              "kind": "citationsResolve",
+              "file": "{{workPath}}/fix-notes.md",
+              "minCitations": 2,
+              "artifact": true
+            }
+          ]
+        }
+      },
+      {
+        "id": "validate",
+        "name": "Validate the changed flow",
+        "description": "Walk the new experience and build a concrete before/after grounded in the real files.",
+        "suggestedRole": "product engineer",
+        "capabilityFloor": "small",
+        "prompt": "Prove the change as the user would experience it. Read `{{workPath}}/before.md` and `{{workPath}}/fix-notes.md`, then re-open the changed files with `read_file` and walk the flow: where the element lives now, what happens on each interaction, where focus goes, what each shortcut does. Build a concrete before/after comparison grounded in the real files — quote the after state next to the before state that before.md recorded. Re-check every behavior from before.md's catalogue: each handler, shortcut, and id must be verifiably still wired in the current code. Say plainly which parts you INSPECTED (read the code) versus EXERCISED (actually ran or interacted with) — anything that is neither is unverified and must be named, never claimed.\n\nWrite `{{workPath}}/validation.md` with exactly these sections: `## Before / after` (the concrete comparison, quoting both states), `## What was exercised` (inspected versus exercised, honestly), `## Result` (delivered as requested, or what remains open and why).",
+        "output": {
+          "path": "{{workPath}}/validation.md",
+          "minBytes": 500,
+          "requiredPatterns": [
+            {
+              "pattern": "^##\\s+Before\\s*/\\s*after",
+              "label": "Before / after section"
+            },
+            {
+              "pattern": "^##\\s+What was exercised",
+              "label": "What was exercised section"
+            },
+            {
+              "pattern": "^##\\s+Result",
+              "label": "Result section"
+            }
+          ],
+          "additionalChecks": [
+            {
+              "kind": "citationsResolve",
+              "file": "{{workPath}}/validation.md",
+              "minCitations": 2,
+              "artifact": true
+            }
+          ]
+        }
+      }
+    ],
+    "review": {
+      "artifactPath": "{{workPath}}/validation.md",
+      "relatedPaths": [
+        "{{workPath}}/before.md",
+        "{{workPath}}/fix-notes.md"
+      ],
+      "reviewPath": "{{workPath}}/review.md",
+      "reviewerRole": "ux reviewer",
+      "repairRole": "frontend engineer",
+      "minReviewBytes": 400,
+      "enforce": {
+        "fixStepId": "repair"
+      },
+      "criteria": [
+        "The delivered change matches the request as a user would judge it — open the changed files and walk the flow; do not grade from fix-notes.md alone.",
+        "The change respects the surrounding product's conventions — open neighboring code and compare naming, spacing, and markup patterns; a one-off new style where an existing pattern served does not pass.",
+        "Nothing that worked before broke: every handler, keyboard shortcut, and id catalogued in before.md is still wired in the current code — check the wiring, not the claim.",
+        "before.md quotes the real prior state and validation.md's before/after is grounded in the current files, not reconstructed from memory.",
+        "The change is minimal: no unrequested alterations rode along with it."
+      ]
+    }
+  }
+}