skilldrop-cli 0.16.35 → 0.16.36

package/packs/dev-team/loops/modernize/LOOP.md

@@ -0,0 +1,124 @@
+---
+name: modernize
+description: Replace or rewrite a legacy component without changing what it does: orient in the old code, plan the restructuring and the move, record the old system's behaviour before anything is rebuilt, rebuild in small steps, prove the new one gives the same results on the recordings, and cut over only when a person accepts the evidence. Use when the user is migrating, rewriting or porting a legacy service, batch job or module (COBOL to Java, Python 2 to 3, a monolith to a service, one framework to another), says "run the modernize loop", or asks how to replace old code without breaking what depends on it.
+---
+
+# modernize
+
+One legacy component, replaced without changing its behaviour. Models now migrate legacy code
+at scale; what they can't do on their own is show that the result behaves the same. This
+loop makes that the gate. The old system's behaviour is recorded **before** any new code
+exists, so the evidence can't be shaped by what was built. A script decides whether the new
+component matches the recordings. Then a person decides the cutover, because only a person
+can accept what the recordings don't cover and approve every intended change.
+
+## Stages
+
+| # | Stage | Type | Skills | Gate |
+|---|---|---|---|---|
+| 1 | `survey` | generate | [`codebase-tour`](../../skills/codebase-tour/SKILL.md) | — |
+| 2 | `plan` | generate | [`refactor-plan`](../../skills/refactor-plan/SKILL.md), [`migration-plan`](../../skills/migration-plan/SKILL.md) | — |
+| 3 | `capture` | generate | [`behaviour-equivalence`](../../skills/behaviour-equivalence/SKILL.md) | — |
+| 4 | `rebuild` | generate | [`feature-implement-loop`](../../skills/feature-implement-loop/SKILL.md) | — |
+| 5 | `prove` | verify | [`behaviour-equivalence`](../../skills/behaviour-equivalence/SKILL.md) | **G10** mechanical |
+| 6 | `cutover` | gate | [`launch-readiness`](../../skills/launch-readiness/SKILL.md) | **G10.1** human |
+
+## How to run this loop
+
+1. **Survey the boundary.** Run `codebase-tour` on the component being replaced. The tour
+   must end with the boundary it will be swapped at (an HTTP API, a function signature, a
+   batch file, a queue) and every caller and side effect that crosses it, each cited to a
+   file. A boundary nobody can name means the component isn't ready to be replaced.
+2. **Plan the work.**
+   - Restructuring the code in place → `refactor-plan`.
+   - Moving data, a schema or a platform → `migration-plan`.
+   - A rewrite usually needs both: a refactor to carve out a seam, then a migration across it.
+3. **Capture before rebuilding.** Run `behaviour-equivalence` against the **old** component
+   only:
+   - record production-shaped inputs and the edge cases at the boundary;
+   - run the old component twice on them;
+   - write the normalisation rules from what differed between those two runs.
+
+   Save `recordings/`, `rules.json` and the coverage note. Nothing from the new build may
+   change these later; if they must change, that is a return to this stage.
+4. **Rebuild in steps.** Hand each planned step to `feature-implement-loop`. Each step merges
+   on its own, behind the boundary, with the old component still serving.
+5. **Prove at G10.** Replay the recordings against the new component and compare:
+
+   ```bash
+   # Claude Code (the loop and behaviour-equivalence installed side by side)
+   python3 "${CLAUDE_SKILL_DIR}/../behaviour-equivalence/scripts/golden_diff.py" old.jsonl new.jsonl --rules rules.json --accepted accepted.json
+   # Other IDEs (from the folder the skills were installed into)
+   python3 behaviour-equivalence/scripts/golden_diff.py old.jsonl new.jsonl --rules rules.json --accepted accepted.json
+   ```
+
+   The exit code is the verdict: `0` is `READY` (equivalent, or equivalent except the changes
+   in `accepted.json`), `1` is `NOT READY`, `2` is `BLOCKED` (the recordings or rules can't
+   be read). `NOT READY` returns to `rebuild` with the differences the script lists. Adding a
+   normalisation rule to make a difference disappear is a return to `capture`, not a fix.
+6. **Decide the cutover at G10.1.** Run `launch-readiness` for the switch itself: rollback to
+   the old component, detection, the data cutover. Then show the person:
+   - the G10 result;
+   - what the recordings cover and what they don't;
+   - every entry in `accepted.json`, with the approver each one names.
+
+   The person decides.
+
+## Verdicts
+
+Defined in [`contracts/terminals.json`](../../../../contracts/terminals.json).
+
+- G10 emits `READY`, `NOT READY` or `BLOCKED`, from the script's exit code alone.
+- G10.1 emits:
+  - `PROCEED`: the cutover goes ahead.
+  - `PROCEED WITH CONDITIONS`: it goes ahead with named items, such as a shadow period or
+    extra recordings for an uncovered input class, each with a date.
+  - `REVISE`: the coverage is too thin or an intended change wasn't approved. Return to
+    `capture`.
+  - `RECONSIDER`: the boundary was wrong, so replacing the component this way won't work. The
+    loop ends here.
+  - `BLOCKED`: no person can accept the evidence, or no rollback exists.
+
+## Non-interactive runs
+
+With no person present, G10.1 cannot be satisfied. Run every stage through G10, deliver the
+evidence, and emit `BLOCKED: need the cutover decision from <the owner>`. Never mark an
+intended change as approved, and never widen a normalisation rule to reach `READY`.
+
+## When a stage's skill is not installed
+
+Name the missing skill and skilldrop as its source, do the minimal inline version of that
+stage, and record that it ran degraded. Without `behaviour-equivalence` there is no G10
+script. Say so, compare the recordings field by field by hand under the same rules, and mark
+G10 degraded. Never skip `capture` or G10.1.
+
+## Run log (opt-in)
+
+Only when the environment variable `SKILLDROP_LOOP_LOG` is set to a file path: after each
+gate's verdict, append one JSON line to that file. Nothing else is recorded, and nothing is
+sent anywhere. When the variable isn't set, or you can't read it, skip this section.
+
+```bash
+printf '%s\n' '{"ts":"2026-10-20T14:03:00Z","loop":"modernize","stage":"prove","gate":"G10","verdict":"NOT READY","round":1}' >> "$SKILLDROP_LOOP_LOG"
+```
+
+Fields: `ts` (UTC), `loop`, `stage`, `gate` (`null` for a stage without one), `verdict` (the
+gate's exact word), and `round` (1 for the first attempt, counting returns under the cap).
+The log holds verdicts only: never recordings, code or data.
+`skilldrop loop-stats` summarises the file.
+
+## Quality bar
+
+- **The old behaviour is recorded before the new code exists.** Recordings made after the rebuild prove only that the new code agrees with itself.
+- **G10 is the script's exit code.** No difference is waved through by reading it.
+- **Every normalisation rule is narrow and has a reason.** A rule added after a G10 failure goes back through `capture`.
+- **Every intended change names its approver.** The person at G10.1 sees each one.
+- **The coverage is stated.** The cutover decision is made knowing which input classes the proof does not reach.
+
+## Anti-patterns to avoid
+
+- ❌ **Recording from the new system,** or from tests written for it. The old system is the oracle.
+- ❌ **Fixing a G10 failure by ignoring the field.** That hides the regression the loop exists to catch.
+- ❌ **Rebuilding everything, then comparing once.** Each planned step merges on its own and is compared again.
+- ❌ **Calling the migration done at G10.** Equivalence on the recordings is evidence; the cutover is a person's decision, with a rollback.
+- ❌ **Skipping `survey` because the old code is "well known".** The callers and side effects nobody remembers are the ones that break.

package/packs/dev-team/loops/modernize/evals/eval_queries.json

@@ -0,0 +1,9 @@
+[
+  {"query": "we're rewriting our COBOL billing batch job in Java, how do we do it without breaking anything", "should_trigger": true},
+  {"query": "run the modernize loop on the legacy pricing service", "should_trigger": true},
+  {"query": "port this Python 2 module to Python 3 and prove it still behaves the same", "should_trigger": true},
+  {"query": "we're moving the orders module out of the monolith into its own service; plan it end to end", "should_trigger": true},
+  {"query": "do the new and old outputs match? here are both files", "should_trigger": false},
+  {"query": "plan how to untangle this 2,000-line class without stopping feature work", "should_trigger": false},
+  {"query": "plan the schema migration for the users table with a backfill", "should_trigger": false}
+]

package/packs/dev-team/loops/modernize/evals/evals.json

@@ -0,0 +1,27 @@
+{
+  "loop_name": "modernize",
+  "evals": [
+    {
+      "id": "capture-before-rebuild",
+      "prompt": "Run the modernize loop. We're replacing legacy/pricing.py (Python 2) with a Python 3 rewrite. The team has already written new/pricing.py and wants to record the expected outputs by running the new code over the test inputs, then compare.",
+      "assertions": [
+        "Says the expected outputs must be recorded from the old component, not the new one, before comparing",
+        "Runs or plans a second run of the old component to find nondeterministic fields before writing normalisation rules",
+        "Names the boundary the component is replaced at and the callers or side effects that cross it",
+        "Uses the comparison script's exit code as the G10 verdict",
+        "Stops at G10.1 for a person's cutover decision; does not approve intended changes itself",
+        "Does not invent callers, inputs or outputs that are not in the repository"
+      ]
+    },
+    {
+      "id": "rule-widening-returns-to-capture",
+      "prompt": "Continuing the modernize loop. G10 failed on 14 cases: the total field differs by a penny. Can we just add a 0.01 tolerance on total and rerun?",
+      "assertions": [
+        "Refuses to add a tolerance on a money field to pass G10",
+        "Treats the difference as a likely defect (rounding) to fix in rebuild, or as an intended change needing a named approver",
+        "Says a new or wider normalisation rule is a return to capture, not a fix",
+        "Counts the return under the cap of 3"
+      ]
+    }
+  ]
+}

package/packs/dev-team/loops/modernize/loop.json

@@ -0,0 +1,60 @@
+{
+  "$comment": "RFC-0057. A legacy component replaced without changing what it does. The old system's behaviour is recorded before anything is rebuilt, a script decides G10 from the recordings, and a person decides the cutover, because only they can accept the coverage and the listed changes.",
+  "name": "modernize",
+  "version": "0.1.0",
+  "description": "Replace or rewrite a legacy component without changing what it does: orient in the old code, plan the restructuring and the move, record the old system's behaviour before anything is rebuilt, rebuild in small steps, prove the new one gives the same results on the recordings, and cut over only when a person accepts the evidence. Use when the user is migrating, rewriting or porting a legacy service, batch job or module (COBOL to Java, Python 2 to 3, a monolith to a service, one framework to another), says \"run the modernize loop\", or asks how to replace old code without breaking what depends on it.",
+  "entrypoint": "LOOP.md",
+  "kind": "loop",
+  "cap": 3,
+  "stages": [
+    {
+      "id": "survey",
+      "type": "generate",
+      "intent": "Find the boundary the component is replaced at, what crosses it, who calls it, and the traps in the old code, each cited to a file.",
+      "skills": ["codebase-tour"]
+    },
+    {
+      "id": "plan",
+      "type": "generate",
+      "intent": "Sequence the work: behaviour-preserving restructuring steps, and the phases of any data, schema or platform move.",
+      "skills": ["refactor-plan", "migration-plan"]
+    },
+    {
+      "id": "capture",
+      "type": "generate",
+      "intent": "Record the old system's inputs and outputs at the boundary, run it twice to find its nondeterminism, and write the normalisation rules, before any new code exists.",
+      "skills": ["behaviour-equivalence"]
+    },
+    {
+      "id": "rebuild",
+      "type": "generate",
+      "intent": "Build the new component in the planned steps, each reviewed and merged on its own.",
+      "skills": ["feature-implement-loop"]
+    },
+    {
+      "id": "prove",
+      "type": "verify",
+      "intent": "Replay the recordings against the new component and compare after the rules; the script's exit code decides.",
+      "skills": ["behaviour-equivalence"],
+      "gate": {
+        "id": "G10",
+        "kind": "mechanical",
+        "script": "packs/dev-team/skills/behaviour-equivalence/scripts/golden_diff.py",
+        "verdicts": ["READY", "NOT READY", "BLOCKED"],
+        "revise_to": "rebuild"
+      }
+    },
+    {
+      "id": "cutover",
+      "type": "gate",
+      "intent": "A person accepts the coverage the recordings give and every listed intended change, and decides the cutover. The readiness check informs that decision; it does not make it.",
+      "skills": ["launch-readiness"],
+      "gate": {
+        "id": "G10.1",
+        "kind": "human",
+        "verdicts": ["PROCEED", "PROCEED WITH CONDITIONS", "REVISE", "RECONSIDER", "BLOCKED"],
+        "revise_to": "capture"
+      }
+    }
+  ]
+}

package/packs/dev-team/skills/behaviour-equivalence/SKILL.md

@@ -0,0 +1,155 @@
+---
+name: behaviour-equivalence
+description: Prove that a rewritten, migrated or refactored component behaves the same as the old one with a golden-master comparison — record inputs and outputs at a boundary (HTTP, function calls, batch files, DB writes, events) from production-shaped traffic and edge cases, run the old system twice to find its nondeterminism, normalise narrowly field by field, replay against the new one, triage every difference as defect, intended change (with a named approver) or missing normalisation, and give a verdict of EQUIVALENT, EQUIVALENT EXCEPT LISTED CHANGES, NOT EQUIVALENT or NOT PROVEN. Use when the user asks "does the new one behave the same as the old one", "can we sign off the rewrite", "are these diffs just noise", wants a golden-master, approval or shadow-traffic comparison, a parity check between old and new outputs, or says "prove behaviour equivalence".
+---
+
+# behaviour-equivalence
+
+Proves, or fails to prove, that a new implementation does what the old one did, at a boundary
+both share. The old system is the specification, bugs included. The output is a verdict, the
+differences behind it, each one classified, and the input classes the verdict covers.
+
+Planning the refactor steps is `refactor-plan` (which names a golden-master test as step one);
+this skill runs that comparison and judges it. Migration phases, backfill and cutover gates are
+`migration-plan`; this skill supplies the parity evidence a gate asks for. A test plan for new
+behaviour is `test-plan-generator`. Finding where the old code lives is `codebase-tour`.
+
+## How to respond
+
+**Four rules come before the steps and outrank them:**
+
+- **Answer what was asked, first.** The first line is the verdict word and the reason: ✅ *"NOT EQUIVALENT: the new service computes delivery dates in UTC, so orders placed after 23:00 London time get a date one day early."* — ❌ a table of match counts, or "mostly the same".
+- **Use only what you were given.** No invented cases, traffic volumes, approvers, dates or root causes. A cause is stated only when the code or the data shows it; otherwise it is a check to run.
+- **Deliver from what you have.** With recordings, compare them and give the verdict. With only a description, design the comparison and say no verdict exists yet. Ask only when there is no component to compare at all.
+- **Write for someone who has never heard of this skill.** No skill names, no paths or scripts from this folder. A next step is one plain sentence describing the work.
+- **For this skill:** every difference is classified before a verdict is given, and a normalisation rule that hides a difference the old system never showed against itself is a defect being hidden, not noise.
+
+1. **Fix the boundary and everything that crosses it.** Name the old and new component and the
+   seam both answer at: an HTTP endpoint, a function, a batch job's files, a queue consumer.
+   Output is everything a caller or downstream system can observe, not only the return value:
+   status codes, error bodies and exception types, headers clients read, rows written, events
+   emitted, files produced (reject and error files too), exit codes. ✅ *"Record `status`, `body`, and the rows written to
+   `invoice_lines`."* — ❌ *"compare the JSON responses"* when the job also writes a ledger.
+
+2. **Record production-shaped inputs, then the edge classes, and say which classes exist.**
+   Replay or sample real traffic (scrubbed) first; then add one case per edge class that
+   applies: empty, one, max size, nulls and missing fields, unicode and long strings, each error
+   path, time zones and DST changes, midnight and month end, leap day, rounding boundaries (a
+   value that lands on exactly .5 of the smallest unit), every currency or locale in use. Write
+   a coverage line per class: *recorded* (case ids), or *not recorded*. **Equivalence is proven
+   only for the recorded classes**, and the reply says which ones are missing.
+
+3. **Run the old system twice on the same inputs before comparing with the new one.** Every
+   field that differs between the two old runs is nondeterminism: those fields, and only those,
+   are normalisation candidates. A field that is stable old-vs-old and differs old-vs-new is a
+   behaviour difference until shown otherwise. When no second run exists, each rule is tagged
+   `[assumption]` and "run the old system twice" is the first thing to confirm.
+
+4. **Normalise explicitly and narrowly: one field, one rule, one reason.** Rules go in a JSON
+   file (format in [`reference.md`](reference.md), starter in
+   [`templates/rules.json`](templates/rules.json)).
+   - ✅ `body.issued_at` ignore, "wall-clock time of the call" — ❌ ignore `body` because it differs.
+   - ✅ `body.invoice_id` regex `^INV-[0-9]{6}$` → `INV-<id>` — keeps the format check; ❌ ignore the id.
+   - ✅ sort `body.items` by `line_no`, "built from a hash map; no consumer reads the order" — ❌ sort a list whose order a caller shows to a user.
+   - ✅ float tolerance per field with the reason it exists: `fx_rate` abs 1e-9, "double printed by a different library".
+   - ❌ **Never a tolerance or rounding rule on money.** Money is compared exactly, in minor units. A 1-cent tolerance on `tax_cents` is how a rounding-mode change ships.
+   - Whitespace, case, locale and key order are normalised only where the consumer ignores them too.
+   Every rule must leave the old-vs-old comparison EQUIVALENT and must have hit something.
+   **A rules file the user supplies is audited, not trusted:** check each rule's field against
+   the old-vs-old run, drop the ones on fields that never varied, rerun, and report what the
+   dropped rules were hiding. "With our rules the diff is clean" is the claim being tested.
+
+5. **Replay against the new system and diff with the script.** Same inputs, same frozen clock
+   and seeds where the system accepts them. Run old-vs-old first, then old-vs-new, with the same rules:
+
+   ```bash
+   # Claude Code
+   python3 "${CLAUDE_SKILL_DIR}/scripts/golden_diff.py" old_run1.jsonl old_run2.jsonl --rules rules.json
+   python3 "${CLAUDE_SKILL_DIR}/scripts/golden_diff.py" old.jsonl new.jsonl --rules rules.json --accepted accepted.json
+   # Other IDEs (from the skill folder)
+   python3 scripts/golden_diff.py old.jsonl new.jsonl --rules rules.json --json -o diff.json
+   ```
+
+   Either side is a JSONL file keyed by `case_id` or a directory with one file per case. Exit 0
+   is equivalent after rules, 1 not, 2 bad input. Read its warnings: a rule that matched
+   nothing, a rule with no reason, an ignore over a whole object, a tolerance on a money-like
+   field, and how many differences each tolerance absorbed. With no script, compare by hand
+   and show each difference with its case and path.
+
+6. **Triage every remaining difference into exactly one class.** Work from the per-field
+   summary, then open the cases:
+   - **Defect:** the new system is wrong, or changed something nobody asked for. Name the cause
+     when the code shows it (✅ *"`tax.go:LineTax` uses `math.RoundToEven`; the old
+     `TaxCalc.java` rounds `HALF_UP`"*).
+   - **Intended change:** listed, with the cases it affects and a **named approver** from the
+     input. No approver in the input means "approver: none named" and it counts as unresolved.
+   - **Missing normalisation:** only if the field also varies old-vs-old. Add the rule, rerun.
+   Look for what the differing cases share: all on a .5 boundary (rounding mode), all near
+   midnight (time zone), all non-ASCII (encoding, collation), all equal sort keys (unstable
+   sort). Catalogue in [`reference.md`](reference.md).
+
+7. **Give the verdict by the first row that applies:**
+
+   | Verdict | When |
+   |---|---|
+   | NOT EQUIVALENT | any defect, any unclassified difference, or a case missing on one side |
+   | NOT PROVEN | no defect, but an edge class or error path production sends was not recorded, side effects were not compared, or the rules were never checked old-vs-old |
+   | EQUIVALENT EXCEPT LISTED CHANGES | every difference is an intended change with a named approver |
+   | EQUIVALENT | no differences after rules that each have a reason and a hit |
+
+   "Mostly the same" and match percentages are not verdicts: 190 of 200 matching is NOT EQUIVALENT until the 10 are classified.
+
+8. **Reply chat-sized.** Verdict line; the differences, one line each: class, field, cases,
+   old → new, cause or the check that finds it; the rules, one line each, only when designed or
+   changed here; one line on what the verdict covers and what it doesn't; at most three items
+   under "To confirm". Write files (rules, accepted changes, a report) only where the user asked.
+   With no recordings yet: the boundary, what to record, the edge classes, the starting rules,
+   and how the verdict will be decided, as a short numbered plan.
+
+**Non-interactive runs** (subagent, CI, headless): with no component, boundary or recordings
+named at all, emit `BLOCKED: need the old and new component and the boundary to compare`.
+Everything else degrades to `[assumption]`: a missing second old run makes every rule an
+assumption, a missing approver leaves the change unresolved, and a missing coverage list makes
+the verdict NOT PROVEN at best.
+
+## Useful references in this skill
+
+- [`reference.md`](reference.md) — what to record per boundary, the normalisation catalogue, the rules-file format, the difference patterns and their usual causes
+- [`templates/rules.json`](templates/rules.json) — starter rules file; [`templates/accepted.json`](templates/accepted.json) — intended changes with approvers
+- [`scripts/golden_diff.py`](scripts/golden_diff.py) — case-by-case diff after rules, per-field summary, rule warnings (stdlib only)
+- [`examples/delivery-date.md`](examples/delivery-date.md) — worked example: a delivery-date endpoint rewrite with a time-zone defect hidden among timestamp and ID noise
+
+## Quality bar
+
+- **The first line is one of the four verdicts** with the reason in plain words.
+- **Every difference is classified** as defect, intended change or missing normalisation; none is left as "minor".
+- **Every normalisation rule names one field and a reason,** and the field varied old-vs-old.
+- **Money is compared exactly in minor units;** any float tolerance is per field with a reason.
+- **Error behaviour and side effects are compared,** not only return values.
+- **Coverage is stated by input class,** and the verdict covers only the recorded classes.
+- **Intended changes name an approver from the input,** or stay unresolved.
+- **Every case id, value, count and cause is from the input or the script output.**
+
+## When to use this skill
+
+- ✅ Signing off a rewrite, port or language migration of a component against the old one
+- ✅ Judging a golden-master or shadow-traffic diff: "are these differences just noise?"
+- ✅ Designing what to record and how to compare before a cutover
+- ✅ Reviewing a normalisation rules file that someone says makes the diff clean
+
+## When NOT to use this skill
+
+- ❌ Planning the refactor or rewrite steps themselves — `refactor-plan`
+- ❌ Phasing a data or platform migration, backfill and cutover — `migration-plan`
+- ❌ A test plan for a new feature or changed behaviour — `test-plan-generator`
+- ❌ Getting oriented in the old codebase before starting — `codebase-tour`
+
+## Anti-patterns to avoid
+
+- ❌ **"Matches apart from noise"** with the noise never listed or checked against an old-vs-old run.
+- ❌ **Ignoring the whole field because it differs.** That deletes the comparison instead of normalising it.
+- ❌ **A tolerance on money.** One cent absorbed per invoice is a rounding-mode change: what customers pay and the tax reported both move.
+- ❌ **Happy paths only.** No empty basket, no unknown id, no midnight order: the verdict is NOT PROVEN, not EQUIVALENT.
+- ❌ **Return values only.** The new service answers the same and stops writing the audit row.
+- ❌ **Calling a difference an intended change** because the new behaviour looks better, with nobody named who approved it.
+- ❌ **A percentage as the verdict.** 85% matching says nothing about the other 15%.

package/packs/dev-team/skills/behaviour-equivalence/evals/eval_queries.json

@@ -0,0 +1,11 @@
+[
+  {"query": "We ported our tax calculation from Java to Go. I have recorded outputs from both on 2,000 real invoices. How do I prove they behave the same?", "should_trigger": true},
+  {"query": "Our shadow-traffic diff between the old and new checkout API shows a bunch of differences. Are these just noise or real regressions?", "should_trigger": true},
+  {"query": "Set up a golden master comparison for the legacy report generator before we replace it", "should_trigger": true},
+  {"query": "The new billing service matches the old one apart from some timestamps and a few 1p differences. Can we sign off parity?", "should_trigger": true},
+  {"query": "Review these normalisation rules for our approval tests and tell me if they hide anything", "should_trigger": true},
+  {"query": "Plan how we break up the 3,000-line OrderService into smaller pieces without stopping feature work", "should_trigger": false},
+  {"query": "Write a phased plan to move our orders table from MySQL to Postgres with a backfill and zero downtime", "should_trigger": false},
+  {"query": "Write a test plan for the new loyalty-points feature before release", "should_trigger": false},
+  {"query": "I'm new to this repo, where does the legacy pricing code live and how do I run its tests?", "should_trigger": false}
+]

package/packs/dev-team/skills/behaviour-equivalence/evals/evals.json

@@ -0,0 +1,76 @@
+{
+  "skill_name": "behaviour-equivalence",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "We rewrote our quote service and ran a parity check. The old service is pricing_v1.py and the rewrite is pricing_v2.py; cases.jsonl has the 12 replayed requests; old.jsonl and old_rerun.jsonl are two runs of the old service; new.jsonl is the new one; rules.json is our normalisation rules, and with them the diff is clean. Background is in notes.md. Can we sign off the cutover?",
+      "assertions": [
+        "The first line gives a verdict of NOT EQUIVALENT (or plainly says the cutover should not be signed off), not 'equivalent' or 'mostly the same'",
+        "Identifies the real difference: VAT on reduced-rate lines is 1p lower in cases c04 and c07 (113 -> 112 and 1555 -> 1554, totals 2363 -> 2362 and 33185 -> 33184)",
+        "Names the cause from the code: pricing_v2 uses Python round() on a Decimal (half-to-even) where pricing_v1 quantizes with ROUND_HALF_UP",
+        "Says the 1p tolerance rules on vat_minor, lines[].vat_minor and total_minor are what make the diff look clean, and that money must be compared exactly rather than with a tolerance",
+        "Uses the two old runs to separate noise from regressions: quoted_at, quote_id and line order vary between old runs, the VAT values do not, so the VAT differences are not noise",
+        "Keeps the three justified rules (ignore quoted_at, regex on quote_id, sort lines by sku) and does not tell the team to ignore whole objects such as body or lines",
+        "States what the verdict does not cover, including promo codes, which notes.md says were not in the replay set",
+        "Does not invent cases, amounts, approvers, production volumes or dates that are not in the files"
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "We're replacing a nightly COBOL batch job that reads the day's card transactions and writes a settlement file plus a rejects file with a Java service. Before we turn the old one off, how do we prove the Java one produces the same output? Problems so far: the header line has the run timestamp, and the Java version writes the records in a different order. Short answer please.",
+      "assertions": [
+        "Answers in a short numbered plan, not a long document, and does not claim a verdict exists yet",
+        "Says to record inputs from real (scrubbed) production days, plus edge cases such as an empty day, a max-size day, rejected transactions, unusual characters, and dates around midnight, month end or DST",
+        "Says to run the COBOL job twice on the same input first and treat only fields that differ between those runs as noise",
+        "Normalises the run timestamp narrowly, in the header field only, not by ignoring the whole header or whole lines",
+        "Sorts records only after confirming the consumer of the settlement file does not depend on record order, and names that as a check",
+        "Compares the rejects file, trailer or control totals, and exit codes, not only the main settlement records",
+        "Says amounts are compared exactly (in minor units), with no tolerance",
+        "Does not invent volumes, file formats, field names or bank names not in the prompt"
+      ]
+    },
+    {
+      "id": 3,
+      "prompt": "Here's the golden master summary for our search API rewrite (diff-summary.txt). Dan says it's all cosmetic. Can we switch traffic?",
+      "assertions": [
+        "The first line says no, or gives a verdict of NOT EQUIVALENT, before any breakdown",
+        "Catches that the 3 status changes (404 -> 200 with empty results) are not covered by the error-copy sign-off and are a contract change clients may depend on, so they are unresolved until classified and approved",
+        "Accepts the 16 error.message changes as an intended change only because an approver (Mei, 3 Oct) is named, and notes clients that parse the message text should be checked",
+        "Says the 41 tie-order differences cannot be called noise without an old-vs-old run, because the old service may break ties deterministically and users see result order",
+        "Points out that the old-vs-old rerun was not done, so the normalised fields (took_ms, request_id, served_by) are unverified as noise, and asks for it",
+        "Does not treat 340 of 400 matching as a pass rate or verdict",
+        "Does not invent causes, cases, counts or names that are not in the summary"
+      ]
+    },
+    {
+      "id": 4,
+      "held_out": "2026-10-20",
+      "prompt": "ported our nightly fee calc job from py2 to py3 (fee_calc_py2.py -> fee_calc_py3.py). ran both on yesterday's input.csv, outputs are old_output.csv and new_output.csv, my diff is in diff.txt. only 3 of 12 rows differ and they're all off by a penny so pretty sure its just float noise. can i tell Priya its equivalent and switch off the old box friday?",
+      "assertions": [
+        "Answers the actual question directly near the top: no, it should not be signed off as equivalent or the old box switched off on that evidence, with an explicit verdict of NOT EQUIVALENT (or NOT PROVEN at best), not EQUIVALENT.",
+        "Says the three differing rows (A1001 163->162, A1009 361->360, A1011 113->112) are not float noise: each raw value is an exact half (162.5, 360.5, 112.5) and the change comes from Python 3 round() rounding half to even where the Python 2 code rounded half away from zero. A systematic rounding change, classed as a defect, or as an intended change only if finance names an approver.",
+        "Uses A1003 (167.5 -> 168) and/or A1007 (67.5 -> 68), which are also exact halves but match because they already round to even, as evidence the pattern is deterministic and not random noise; OR otherwise shows that every half-cent input is affected by the same rule.",
+        "Catches that the diff in diff.txt (cut -d, -f1,2) drops the currency and run_ts columns. That hides a real difference: new_output.csv has a blank currency for A1005, caused by the `ccy = row[\"currency\"] if fee > 0 else \"\"` line in fee_calc_py3.py. Treats it as a defect or as an intended change that needs a named approver, not as noise.",
+        "Says which differences can legitimately be normalised away, and only narrowly: the run_ts value, and row order (the Py2 version writes rows in arbitrary dict order, the Py3 version in input order), with a check that nothing downstream depends on row order. It does not drop whole columns.",
+        "Proposes a concrete fix for the rounding, such as decimal.Decimal with ROUND_HALF_UP, or an integer half-up formula, and says to re-run the comparison afterwards.",
+        "Flags that the evidence is too thin to switch off the old box: one day, 12 rows, all GBP, no negative amounts/refunds or other edge cases, and the old job was run only once, so its own nondeterminism is unknown. Recommends replaying more production-shaped input first. Keeps the answer proportionate to a quick Slack-style question rather than a long formal report.",
+        "Invents nothing that is not in the files: no extra account IDs, fee values, rates, downstream systems, or facts about Priya beyond her being the person to tell."
+      ]
+    },
+    {
+      "id": 5,
+      "held_out": "2026-10-20",
+      "prompt": "I'm the engineering manager who has to sign off the orders-api migration from Express to Fastify before we cut traffic over on Tuesday 27 Oct. The team says it's equivalent and the one remaining diff is noise. Their recorded replays are in recordings/ (two runs against the old service, one against the new), the normalisation they applied is normalisation.yaml, and their write-up is TEAM_NOTES.md. Please check their reasoning and give me a verdict I can paste into the change record, with what has to happen before cutover if it isn't a yes.",
+      "assertions": [
+        "Gives a clear verdict up front that can be pasted into the change record: NOT EQUIVALENT, not the team's 'equivalent'. It also says plainly whether the Tuesday 27 Oct cutover should go ahead, with the blocking items listed.",
+        "Rejects dismissing seq 4 (GET /orders/ord_bad!!, old 400 INVALID_ORDER_ID vs new 500 INTERNAL_ERROR) as noise. A malformed id that now produces a server error is a behaviour change, most likely a validation defect, whatever the team thinks about how often clients send it.",
+        "Finds that ignoring response.body.error wholesale hides a contract change at seq 6: error.code went from QUANTITY_INVALID to VALIDATION_ERROR. Ties this to TEAM_NOTES saying the Android app switches on error.code, so this is a user-visible break, not reworded text.",
+        "Finds that numeric_strings_to_numbers hides a type change: total went from a string (\"19.90\", \"5.00\", \"39.80\") to a number (19.9, 5.0, 39.8) in seq 1, 2, 5 and 7. Ties this to TEAM_NOTES saying the web checkout passes total to the payment widget as a string, and treats it as a defect or as an intended change that needs a named approver.",
+        "Uses old_run1 vs old_run2 to separate the old service's real nondeterminism (request_id, date header, the id and created_at of the order created at seq 5, and the order of tags on ord_1001) from everything else. Recommends narrowing the rules to match: tags-only sorting instead of sort_all_arrays, id/created_at ignored only on the POST-created resource instead of globally, and error.message ignored instead of the whole error object.",
+        "Puts each remaining difference into one category (defect, intended change, or missing/over-broad normalisation), including the reworded 404 message at seq 3 and the content-type charset change. Notes that the files name no approver for any intended change, so none of them counts as approved yet.",
+        "Notes that 8 hand-picked requests on a seeded staging database are not production-shaped traffic. Calls out obvious coverage gaps, such as auth failures, pagination, and concurrent or large orders, and recommends replaying a production-shaped sample, or shadow traffic, with the corrected normalisation before cutover.",
+        "Invents nothing that is not in the files: no extra endpoints, recorded results, error codes, consumers, approvers or dates beyond those in recordings/, normalisation.yaml and TEAM_NOTES.md (Dana Okafor is the only person named)."
+      ]
+    }
+  ]
+}

package/packs/dev-team/skills/behaviour-equivalence/evals/files/1/cases.jsonl

@@ -0,0 +1,12 @@
+{"case_id": "c01", "label": "one standard-rate line", "request": {"currency": "GBP", "items": [{"sku": "TEA-001", "qty": 1}]}}
+{"case_id": "c02", "label": "two standard-rate lines", "request": {"currency": "GBP", "items": [{"sku": "TEA-001", "qty": 2}, {"sku": "MUG-002", "qty": 1}]}}
+{"case_id": "c03", "label": "one reduced-rate line", "request": {"currency": "GBP", "items": [{"sku": "CHILD-SEAT-01", "qty": 1}]}}
+{"case_id": "c04", "label": "reduced-rate booster seat", "request": {"currency": "GBP", "items": [{"sku": "BOOSTER-02", "qty": 1}]}}
+{"case_id": "c05", "label": "reduced-rate, qty 2", "request": {"currency": "GBP", "items": [{"sku": "BOOSTER-02", "qty": 2}]}}
+{"case_id": "c06", "label": "reduced-rate, qty 3", "request": {"currency": "GBP", "items": [{"sku": "BOOSTER-02", "qty": 3}]}}
+{"case_id": "c07", "label": "pram plus tea, mixed bands", "request": {"currency": "GBP", "items": [{"sku": "PRAM-03", "qty": 1}, {"sku": "TEA-001", "qty": 1}]}}
+{"case_id": "c08", "label": "zero, standard and repeated lines", "request": {"currency": "GBP", "items": [{"sku": "BOOK-05", "qty": 1}, {"sku": "MUG-002", "qty": 1}, {"sku": "TEA-001", "qty": 2}, {"sku": "TEA-001", "qty": 1}]}}
+{"case_id": "c09", "label": "empty basket", "request": {"currency": "GBP", "items": []}}
+{"case_id": "c10", "label": "unknown sku", "request": {"currency": "GBP", "items": [{"sku": "XYZ-999", "qty": 1}]}}
+{"case_id": "c11", "label": "zero quantity", "request": {"currency": "GBP", "items": [{"sku": "MUG-002", "qty": 0}]}}
+{"case_id": "c12", "label": "large basket", "request": {"currency": "GBP", "items": [{"sku": "MUG-002", "qty": 100}, {"sku": "CHILD-SEAT-01", "qty": 4}, {"sku": "TEA-001", "qty": 50}]}}

package/packs/dev-team/skills/behaviour-equivalence/evals/files/1/new.jsonl

@@ -0,0 +1,12 @@
+{"case_id": "c01", "status": 200, "body": {"quote_id": "Q-9f767c45", "quoted_at": "2026-10-14T15:03:20.441+00:00", "currency": "GBP", "lines": [{"sku": "TEA-001", "qty": 1, "unit_price_minor": 450, "line_total_minor": 450, "vat_band": "standard", "vat_minor": 90}], "subtotal_minor": 450, "vat_minor": 90, "total_minor": 540}}
+{"case_id": "c02", "status": 200, "body": {"quote_id": "Q-bde5c099", "quoted_at": "2026-10-14T15:03:20.988+00:00", "currency": "GBP", "lines": [{"sku": "MUG-002", "qty": 1, "unit_price_minor": 899, "line_total_minor": 899, "vat_band": "standard", "vat_minor": 180}, {"sku": "TEA-001", "qty": 2, "unit_price_minor": 450, "line_total_minor": 900, "vat_band": "standard", "vat_minor": 180}], "subtotal_minor": 1799, "vat_minor": 360, "total_minor": 2159}}
+{"case_id": "c03", "status": 200, "body": {"quote_id": "Q-cb91ce37", "quoted_at": "2026-10-14T15:03:21.875+00:00", "currency": "GBP", "lines": [{"sku": "CHILD-SEAT-01", "qty": 1, "unit_price_minor": 12500, "line_total_minor": 12500, "vat_band": "reduced", "vat_minor": 625}], "subtotal_minor": 12500, "vat_minor": 625, "total_minor": 13125}}
+{"case_id": "c04", "status": 200, "body": {"quote_id": "Q-f1446bea", "quoted_at": "2026-10-14T15:03:22.722+00:00", "currency": "GBP", "lines": [{"sku": "BOOSTER-02", "qty": 1, "unit_price_minor": 2250, "line_total_minor": 2250, "vat_band": "reduced", "vat_minor": 112}], "subtotal_minor": 2250, "vat_minor": 112, "total_minor": 2362}}
+{"case_id": "c05", "status": 200, "body": {"quote_id": "Q-ec1d7da0", "quoted_at": "2026-10-14T15:03:23.444+00:00", "currency": "GBP", "lines": [{"sku": "BOOSTER-02", "qty": 2, "unit_price_minor": 2250, "line_total_minor": 4500, "vat_band": "reduced", "vat_minor": 225}], "subtotal_minor": 4500, "vat_minor": 225, "total_minor": 4725}}
+{"case_id": "c06", "status": 200, "body": {"quote_id": "Q-076ce2ef", "quoted_at": "2026-10-14T15:03:24.100+00:00", "currency": "GBP", "lines": [{"sku": "BOOSTER-02", "qty": 3, "unit_price_minor": 2250, "line_total_minor": 6750, "vat_band": "reduced", "vat_minor": 338}], "subtotal_minor": 6750, "vat_minor": 338, "total_minor": 7088}}
+{"case_id": "c07", "status": 200, "body": {"quote_id": "Q-c6a53877", "quoted_at": "2026-10-14T15:03:24.535+00:00", "currency": "GBP", "lines": [{"sku": "PRAM-03", "qty": 1, "unit_price_minor": 31090, "line_total_minor": 31090, "vat_band": "reduced", "vat_minor": 1554}, {"sku": "TEA-001", "qty": 1, "unit_price_minor": 450, "line_total_minor": 450, "vat_band": "standard", "vat_minor": 90}], "subtotal_minor": 31540, "vat_minor": 1644, "total_minor": 33184}}
+{"case_id": "c08", "status": 200, "body": {"quote_id": "Q-a6233255", "quoted_at": "2026-10-14T15:03:24.768+00:00", "currency": "GBP", "lines": [{"sku": "BOOK-05", "qty": 1, "unit_price_minor": 1299, "line_total_minor": 1299, "vat_band": "zero", "vat_minor": 0}, {"sku": "MUG-002", "qty": 1, "unit_price_minor": 899, "line_total_minor": 899, "vat_band": "standard", "vat_minor": 180}, {"sku": "TEA-001", "qty": 3, "unit_price_minor": 450, "line_total_minor": 1350, "vat_band": "standard", "vat_minor": 270}], "subtotal_minor": 3548, "vat_minor": 450, "total_minor": 3998}}
+{"case_id": "c09", "status": 422, "body": {"error": "empty_basket"}}
+{"case_id": "c10", "status": 422, "body": {"error": "unknown_sku", "sku": "XYZ-999"}}
+{"case_id": "c11", "status": 422, "body": {"error": "invalid_qty", "sku": "MUG-002"}}
+{"case_id": "c12", "status": 200, "body": {"quote_id": "Q-e6a16a3b", "quoted_at": "2026-10-14T15:03:25.108+00:00", "currency": "GBP", "lines": [{"sku": "CHILD-SEAT-01", "qty": 4, "unit_price_minor": 12500, "line_total_minor": 50000, "vat_band": "reduced", "vat_minor": 2500}, {"sku": "MUG-002", "qty": 100, "unit_price_minor": 899, "line_total_minor": 89900, "vat_band": "standard", "vat_minor": 17980}, {"sku": "TEA-001", "qty": 50, "unit_price_minor": 450, "line_total_minor": 22500, "vat_band": "standard", "vat_minor": 4500}], "subtotal_minor": 162400, "vat_minor": 24980, "total_minor": 187380}}

package/packs/dev-team/skills/behaviour-equivalence/evals/files/1/notes.md

@@ -0,0 +1,15 @@
+# Quote service rewrite: parity run
+
+Owner: Priya Raman (checkout team). Cutover planned for the release train after next.
+
+- `cases.jsonl`: the 12 requests we replayed. Taken from the staging request log on 12 Oct and
+  topped up with the error cases by hand. Promo codes aren't in this set: staging doesn't have
+  the promo service, so no request carries one.
+- `old.jsonl`, `old_rerun.jsonl`: `pricing_v1.quote` run twice on those requests (09:14 and
+  09:41 on 12 Oct).
+- `new.jsonl`: `pricing_v2.quote` on the same requests (14 Oct).
+- `rules.json`: our normalisation rules. With them the diff tool says every case matches.
+
+Differences we saw before normalising: timestamps, quote IDs, line order, and a few 1p
+rounding differences between the Decimal code paths, which the tolerance rules cover. We'd
+like to call this equivalent and book the cutover.

package/packs/dev-team/skills/behaviour-equivalence/evals/files/1/old.jsonl

@@ -0,0 +1,12 @@
+{"case_id": "c01", "status": 200, "body": {"quote_id": "Q-3ceb3ffd", "quoted_at": "2026-10-12T09:14:02.786+00:00", "currency": "GBP", "lines": [{"sku": "TEA-001", "qty": 1, "unit_price_minor": 450, "line_total_minor": 450, "vat_band": "standard", "vat_minor": 90}], "subtotal_minor": 450, "vat_minor": 90, "total_minor": 540}}
+{"case_id": "c02", "status": 200, "body": {"quote_id": "Q-8b529b4a", "quoted_at": "2026-10-12T09:14:03.099+00:00", "currency": "GBP", "lines": [{"sku": "TEA-001", "qty": 2, "unit_price_minor": 450, "line_total_minor": 900, "vat_band": "standard", "vat_minor": 180}, {"sku": "MUG-002", "qty": 1, "unit_price_minor": 899, "line_total_minor": 899, "vat_band": "standard", "vat_minor": 180}], "subtotal_minor": 1799, "vat_minor": 360, "total_minor": 2159}}
+{"case_id": "c03", "status": 200, "body": {"quote_id": "Q-5eb561a4", "quoted_at": "2026-10-12T09:14:03.897+00:00", "currency": "GBP", "lines": [{"sku": "CHILD-SEAT-01", "qty": 1, "unit_price_minor": 12500, "line_total_minor": 12500, "vat_band": "reduced", "vat_minor": 625}], "subtotal_minor": 12500, "vat_minor": 625, "total_minor": 13125}}
+{"case_id": "c04", "status": 200, "body": {"quote_id": "Q-795b929e", "quoted_at": "2026-10-12T09:14:04.717+00:00", "currency": "GBP", "lines": [{"sku": "BOOSTER-02", "qty": 1, "unit_price_minor": 2250, "line_total_minor": 2250, "vat_band": "reduced", "vat_minor": 113}], "subtotal_minor": 2250, "vat_minor": 113, "total_minor": 2363}}
+{"case_id": "c05", "status": 200, "body": {"quote_id": "Q-94b2b8fd", "quoted_at": "2026-10-12T09:14:04.964+00:00", "currency": "GBP", "lines": [{"sku": "BOOSTER-02", "qty": 2, "unit_price_minor": 2250, "line_total_minor": 4500, "vat_band": "reduced", "vat_minor": 225}], "subtotal_minor": 4500, "vat_minor": 225, "total_minor": 4725}}
+{"case_id": "c06", "status": 200, "body": {"quote_id": "Q-9b08923d", "quoted_at": "2026-10-12T09:14:05.157+00:00", "currency": "GBP", "lines": [{"sku": "BOOSTER-02", "qty": 3, "unit_price_minor": 2250, "line_total_minor": 6750, "vat_band": "reduced", "vat_minor": 338}], "subtotal_minor": 6750, "vat_minor": 338, "total_minor": 7088}}
+{"case_id": "c07", "status": 200, "body": {"quote_id": "Q-e8a8529f", "quoted_at": "2026-10-12T09:14:05.817+00:00", "currency": "GBP", "lines": [{"sku": "TEA-001", "qty": 1, "unit_price_minor": 450, "line_total_minor": 450, "vat_band": "standard", "vat_minor": 90}, {"sku": "PRAM-03", "qty": 1, "unit_price_minor": 31090, "line_total_minor": 31090, "vat_band": "reduced", "vat_minor": 1555}], "subtotal_minor": 31540, "vat_minor": 1645, "total_minor": 33185}}
+{"case_id": "c08", "status": 200, "body": {"quote_id": "Q-42650644", "quoted_at": "2026-10-12T09:14:06.561+00:00", "currency": "GBP", "lines": [{"sku": "BOOK-05", "qty": 1, "unit_price_minor": 1299, "line_total_minor": 1299, "vat_band": "zero", "vat_minor": 0}, {"sku": "TEA-001", "qty": 3, "unit_price_minor": 450, "line_total_minor": 1350, "vat_band": "standard", "vat_minor": 270}, {"sku": "MUG-002", "qty": 1, "unit_price_minor": 899, "line_total_minor": 899, "vat_band": "standard", "vat_minor": 180}], "subtotal_minor": 3548, "vat_minor": 450, "total_minor": 3998}}
+{"case_id": "c09", "status": 422, "body": {"error": "empty_basket"}}
+{"case_id": "c10", "status": 422, "body": {"error": "unknown_sku", "sku": "XYZ-999"}}
+{"case_id": "c11", "status": 422, "body": {"error": "invalid_qty", "sku": "MUG-002"}}
+{"case_id": "c12", "status": 200, "body": {"quote_id": "Q-3bfd1d33", "quoted_at": "2026-10-12T09:14:06.937+00:00", "currency": "GBP", "lines": [{"sku": "CHILD-SEAT-01", "qty": 4, "unit_price_minor": 12500, "line_total_minor": 50000, "vat_band": "reduced", "vat_minor": 2500}, {"sku": "TEA-001", "qty": 50, "unit_price_minor": 450, "line_total_minor": 22500, "vat_band": "standard", "vat_minor": 4500}, {"sku": "MUG-002", "qty": 100, "unit_price_minor": 899, "line_total_minor": 89900, "vat_band": "standard", "vat_minor": 17980}], "subtotal_minor": 162400, "vat_minor": 24980, "total_minor": 187380}}

package/packs/dev-team/skills/behaviour-equivalence/evals/files/1/old_rerun.jsonl

@@ -0,0 +1,12 @@
+{"case_id": "c01", "status": 200, "body": {"quote_id": "Q-3a096533", "quoted_at": "2026-10-12T09:41:37.559+00:00", "currency": "GBP", "lines": [{"sku": "TEA-001", "qty": 1, "unit_price_minor": 450, "line_total_minor": 450, "vat_band": "standard", "vat_minor": 90}], "subtotal_minor": 450, "vat_minor": 90, "total_minor": 540}}
+{"case_id": "c02", "status": 200, "body": {"quote_id": "Q-f658f7a7", "quoted_at": "2026-10-12T09:41:38.123+00:00", "currency": "GBP", "lines": [{"sku": "TEA-001", "qty": 2, "unit_price_minor": 450, "line_total_minor": 900, "vat_band": "standard", "vat_minor": 180}, {"sku": "MUG-002", "qty": 1, "unit_price_minor": 899, "line_total_minor": 899, "vat_band": "standard", "vat_minor": 180}], "subtotal_minor": 1799, "vat_minor": 360, "total_minor": 2159}}
+{"case_id": "c03", "status": 200, "body": {"quote_id": "Q-205738d1", "quoted_at": "2026-10-12T09:41:38.500+00:00", "currency": "GBP", "lines": [{"sku": "CHILD-SEAT-01", "qty": 1, "unit_price_minor": 12500, "line_total_minor": 12500, "vat_band": "reduced", "vat_minor": 625}], "subtotal_minor": 12500, "vat_minor": 625, "total_minor": 13125}}
+{"case_id": "c04", "status": 200, "body": {"quote_id": "Q-b46ee1da", "quoted_at": "2026-10-12T09:41:38.724+00:00", "currency": "GBP", "lines": [{"sku": "BOOSTER-02", "qty": 1, "unit_price_minor": 2250, "line_total_minor": 2250, "vat_band": "reduced", "vat_minor": 113}], "subtotal_minor": 2250, "vat_minor": 113, "total_minor": 2363}}
+{"case_id": "c05", "status": 200, "body": {"quote_id": "Q-15ceb3a1", "quoted_at": "2026-10-12T09:41:39.044+00:00", "currency": "GBP", "lines": [{"sku": "BOOSTER-02", "qty": 2, "unit_price_minor": 2250, "line_total_minor": 4500, "vat_band": "reduced", "vat_minor": 225}], "subtotal_minor": 4500, "vat_minor": 225, "total_minor": 4725}}
+{"case_id": "c06", "status": 200, "body": {"quote_id": "Q-3f584ad4", "quoted_at": "2026-10-12T09:41:39.742+00:00", "currency": "GBP", "lines": [{"sku": "BOOSTER-02", "qty": 3, "unit_price_minor": 2250, "line_total_minor": 6750, "vat_band": "reduced", "vat_minor": 338}], "subtotal_minor": 6750, "vat_minor": 338, "total_minor": 7088}}
+{"case_id": "c07", "status": 200, "body": {"quote_id": "Q-359b1548", "quoted_at": "2026-10-12T09:41:40.332+00:00", "currency": "GBP", "lines": [{"sku": "TEA-001", "qty": 1, "unit_price_minor": 450, "line_total_minor": 450, "vat_band": "standard", "vat_minor": 90}, {"sku": "PRAM-03", "qty": 1, "unit_price_minor": 31090, "line_total_minor": 31090, "vat_band": "reduced", "vat_minor": 1555}], "subtotal_minor": 31540, "vat_minor": 1645, "total_minor": 33185}}
+{"case_id": "c08", "status": 200, "body": {"quote_id": "Q-a4517d6c", "quoted_at": "2026-10-12T09:41:40.543+00:00", "currency": "GBP", "lines": [{"sku": "MUG-002", "qty": 1, "unit_price_minor": 899, "line_total_minor": 899, "vat_band": "standard", "vat_minor": 180}, {"sku": "TEA-001", "qty": 3, "unit_price_minor": 450, "line_total_minor": 1350, "vat_band": "standard", "vat_minor": 270}, {"sku": "BOOK-05", "qty": 1, "unit_price_minor": 1299, "line_total_minor": 1299, "vat_band": "zero", "vat_minor": 0}], "subtotal_minor": 3548, "vat_minor": 450, "total_minor": 3998}}
+{"case_id": "c09", "status": 422, "body": {"error": "empty_basket"}}
+{"case_id": "c10", "status": 422, "body": {"error": "unknown_sku", "sku": "XYZ-999"}}
+{"case_id": "c11", "status": 422, "body": {"error": "invalid_qty", "sku": "MUG-002"}}
+{"case_id": "c12", "status": 200, "body": {"quote_id": "Q-7589ca4a", "quoted_at": "2026-10-12T09:41:41.222+00:00", "currency": "GBP", "lines": [{"sku": "MUG-002", "qty": 100, "unit_price_minor": 899, "line_total_minor": 89900, "vat_band": "standard", "vat_minor": 17980}, {"sku": "TEA-001", "qty": 50, "unit_price_minor": 450, "line_total_minor": 22500, "vat_band": "standard", "vat_minor": 4500}, {"sku": "CHILD-SEAT-01", "qty": 4, "unit_price_minor": 12500, "line_total_minor": 50000, "vat_band": "reduced", "vat_minor": 2500}], "subtotal_minor": 162400, "vat_minor": 24980, "total_minor": 187380}}