skilldrop-cli 1.12.0 → 1.14.0

package/packs/data-analytics/loops/measure/LOOP.md

@@ -27,7 +27,10 @@ definition, because a query can be correct and still compute the wrong thing.
    SQL is read. Every surviving chart names its metric by defined name, grain, window and
    comparison. A metric with no written definition is marked `undefined`. Write it down as
    the person states it, or leave it as a question for the metric's owner. Don't define it
-   yourself.
+   yourself, with one exception: when the people who own it have handed the call to the
+   analyst ("happy for analytics to call it"), propose a definition, mark it *proposed,
+   unconfirmed*, say why in one line, and carry on with it. When only the numbers were asked
+   for, keep the spec as working notes and deliver the numbers.
 2. **Collect one query per surviving metric.** The person supplies the SQL, the dbt model or
    the view that computes each one, with the engine and what one output row represents.
    Where none exists yet, draft one from the definition and the schema they supply, and
@@ -50,8 +53,24 @@ definition, because a query can be correct and still compute the wrong thing.
    - what changed and by how much, from the verification queries;
    - every assumption the review made about keys, time zones and exclusions.
 
-   The owner confirms that this is what the business means by the metric. The BI developer
-   builds only from a spec that has passed G9.1.
+   The owner confirms that this is what the business means by the metric. Deliver everything
+   that can be built now: a metric whose definition is confirmed, or agreed in the request,
+   goes to the BI developer, and each one still open is listed with who confirms it and what
+   changes if they say no. Only an open metric waits.
+
+## What the reply says
+
+- **Lead with what was asked for, in plain words:** the numbers and the charts that can be built now, then who confirms what is still open. Give the spec document only when a dashboard was asked for, not when only the numbers were.
+- **No loop internals.** No gate id, verdict word, stage or skill name, and no path inside a
+  skill folder, in the reply or in any file the person receives. Say the outcome instead:
+  ✅ *"Five of the six tiles can be built now. Finance confirms whether 'active' means paid or logged in, before the sixth goes live"* — ❌ *"G9: READY, G9.1: BLOCKED"*.
+- **The verdict goes to the run log only,** when one is set. The reply never mentions the run
+  log, whether it is set, or how the run was set up.
+- **A person's decision never holds back the work.** Deliver everything up to it, then name
+  the decision in one line: who makes it, and what each answer means. When the request
+  already holds their decision ("happy for analytics to call it", a definition already agreed in the thread), record it as theirs and carry on.
+- **Stop only when nothing can be made.** With an essential input missing, the first line says
+  in plain words what's missing, then what you'll produce once it arrives.
 
 ## Verdicts
 
@@ -65,16 +84,20 @@ Defined in [`contracts/terminals.json`](../../../../contracts/terminals.json).
     a `SHIP WITH NOTES` caveat shown on the chart, or a data gap with its date.
   - `REVISE`: an owner says the definition is wrong (the wrong time zone, an exclusion
     missing, the wrong grain). Return to `spec` with their definition.
-  - `BLOCKED`: an `undefined` metric has no owner to define it, or an owner is unavailable.
+  - `BLOCKED`: an `undefined` metric has no owner to define it and nobody has handed the call
+    to the analyst.
 
-An `undefined` metric can't pass G9.1. Its owner defines it, or the chart moves to the cut
-list with the reason.
+An `undefined` metric can't pass G9.1. Its owner defines it, the owner's hand-off lets the
+analyst propose it, or the chart moves to the cut list with the reason. An owner who is
+unavailable doesn't block the rest: the metrics already confirmed go ahead, and theirs is
+listed as open.
 
 ## Non-interactive runs
 
-With no person present, G9.1 cannot be satisfied. Run `spec` and `review`, deliver the spec
-with each query's review, and emit `BLOCKED: need each metric owner's confirmation of
-<every metric on the spec>`. A metric whose query passed G9 still needs its owner: the review
+With no person present, run `spec` and `review` and deliver both: the numbers, each query's
+review, and a plain list of the confirmations still open, one line per metric with who
+confirms it. A definition the request already agreed, or handed to the analyst, is used as
+the request gives it. A metric whose query passed review still needs its owner: the review
 says the SQL computes the definition, not that the definition is right. Never confirm a definition on an owner's behalf, and never fill an
 `undefined` metric with a plausible one: two teams will each read it as theirs.
 
@@ -90,6 +113,7 @@ because those are the bugs that change the number. Never skip G9.1.
 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.
+The reply never mentions the run log, whether or not it is set.
 
 ```bash
 printf '%s\n' '{"ts":"2026-10-19T14:03:00Z","loop":"measure","stage":"review","gate":"G9","verdict":"NOT READY","round":1}' >> "$SKILLDROP_LOOP_LOG"
@@ -107,6 +131,8 @@ The log holds verdicts only: never a query, a table name or a figure.
 - **A fixed query goes back through the spec.** The corrected number can move a target or a threshold, and the spec is where those live.
 - **The owner sees the change in the number.** The verification queries' before and after go to G9.1, not only the corrected SQL.
 - **The metric's owner signs the definition.** A correct query for the wrong definition is still the wrong number.
+- **A hand-off is used, not refused.** When the owners leave the definition to the analyst, a proposed, unconfirmed definition goes ahead and is marked as such.
+- **What can be built now is delivered now.** One open metric holds back its own chart, not the dashboard.
 
 ## Anti-patterns to avoid
 
@@ -115,4 +141,7 @@ The log holds verdicts only: never a query, a table name or a figure.
 - ❌ **Shipping the corrected SQL without telling the owner the number moved.** A revenue figure that drops a third overnight with no explanation gets reverted.
 - ❌ **Passing G9 on a clean lint.** The lint can't see join fan-out; the review reads the joins.
 - ❌ **Treating `SHIP WITH NOTES` as `SHIP IT`.** The notes go to the owner and, where they change how the chart reads, onto the chart.
-- ❌ **Building before G9.1.** A dashboard built on an unconfirmed definition is the one the two teams will argue about.
+- ❌ **Building an open metric before its owner confirms it.** A chart built on an unconfirmed definition is the one the two teams will argue about. The confirmed ones don't wait for it.
+- ❌ **Refusing a definition the owners handed over.** "Happy for analytics to call it" is a decision; propose the definition and mark it unconfirmed.
+- ❌ **A spec document when only the numbers were asked for.** Deliver the numbers; keep the spec as working notes.
+- ❌ **Gate talk in the reply.** "G9: READY, G9.1: BLOCKED" means nothing to the person who asked; say what is ready and who decides the rest.

package/packs/data-analytics/loops/measure/evals/evals.json

@@ -53,6 +53,36 @@
         "Reports that the sign-off gate has not passed, so the Active customers tile is not ready to build, and says who needs to decide what",
         "Does not invent a metric owner, a reconciled Active customers figure, or a split of the 17,700 gap by cause, none of which are in the input"
       ]
+    },
+    {
+      "id": "measure-second-van-dashboard",
+      "held_out": "2026-11-12",
+      "prompt": "We need a dashboard for the operations board so they can decide each month where the second van goes. The request is in request.md, the schema in schema.md, and the two queries we use today are households_served.sql and stockout_rate.sql. Make sure the numbers are right before the BI developer builds it.",
+      "assertions": [
+        "Opens with the dashboard in plain words: the decision it serves (which district the second van visits next month) and the questions it answers",
+        "Gives one chart per question, each backed by a metric defined precisely enough to build (what is counted, the grain, the time window and how NULL travel_km is handled)",
+        "Catches that households_served.sql counts parcel items, not households, because the join to parcel_items repeats each visit about 14 times, and that a household visiting weekly is counted once per visit; gives corrected SQL using a distinct count of households",
+        "Catches that stockout_rate.sql divides an integer by an integer, so the rate comes out as 0 (or 100) rather than a real share, and gives corrected SQL",
+        "Says in plain words which way each bug would have moved the figure the board saw, for example demand hugely overstated",
+        "Leaves the 'total parcels ever given' counter off the dashboard, or questions it, because it does not help decide where the van goes",
+        "Names Hollis Fenwick and Esme Tarrant as the owners of their metrics and leaves each definition waiting for its owner's sign-off rather than calling it approved",
+        "Does not invent metrics, targets or data sources not in the input, such as a deprivation index or a demand forecast"
+      ]
+    },
+    {
+      "id": "measure-net-revenue-handed-to-analyst",
+      "held_out": "2026-11-12",
+      "prompt": "I'm Noor, the analyst at Pellwick Outdoor. Sales and Finance have argued about net revenue for weeks and have now handed the definition to me (handoff-thread.md). Give me the spec for the board's revenue dashboard. Their two queries are sales_net_revenue.sql and finance_net_revenue.sql, and the schema is in schema.md.",
+      "assertions": [
+        "Opens with the net revenue definition it settled on, in plain words: what is included and excluded (VAT, shipping, refunds) and when revenue counts",
+        "Records the hand-off as the basis for the definition, naming Dana Ruskin and Callum Brightwater as having given the decision to Noor, and does not send the choice back to them",
+        "Settles Dana's open question on shipping charges one way or the other and says so, rather than leaving it undefined",
+        "Explains what changes for each team compared with its current query, as the thread asks",
+        "Catches that sales_net_revenue.sql sums order_total after joining order_lines, so each order is counted once per line (about three times)",
+        "Catches that `r.reason <> 'test'` in finance_net_revenue.sql also drops refunds whose reason is NULL, which is most of them, so refunds are under-deducted and net revenue is overstated; gives corrected SQL",
+        "Handles the month boundary in Europe/London rather than UTC in the SQL for the chosen definition, or flags it as needing a fix",
+        "Does not invent revenue figures, the size of the gap between the two queries, or accounting policies not in the input"
+      ]
     }
   ]
 }

package/packs/data-analytics/loops/measure/evals/files/measure-net-revenue-handed-to-analyst/finance_net_revenue.sql

@@ -0,0 +1,19 @@
+-- Finance's "net revenue" by month and channel
+-- Dialect: PostgreSQL 16
+WITH dispatched AS (
+  SELECT DATE_TRUNC('month', ol.dispatched_at) AS month, o.channel, SUM(ol.line_net) AS gross_net
+  FROM order_lines ol
+  JOIN orders o ON o.order_id = ol.order_id
+  WHERE ol.dispatched_at IS NOT NULL
+  GROUP BY 1, 2
+),
+refunded AS (
+  SELECT DATE_TRUNC('month', r.refunded_at) AS month, o.channel, SUM(r.amount_net) AS refunds_net
+  FROM refunds r
+  JOIN orders o ON o.order_id = r.order_id
+  WHERE r.reason <> 'test'
+  GROUP BY 1, 2
+)
+SELECT d.month, d.channel, d.gross_net - COALESCE(rf.refunds_net, 0) AS net_revenue
+FROM dispatched d
+LEFT JOIN refunded rf ON rf.month = d.month AND rf.channel = d.channel;

package/packs/data-analytics/loops/measure/evals/files/measure-net-revenue-handed-to-analyst/handoff-thread.md

@@ -0,0 +1,24 @@
+# Email thread - "net revenue" for the board dashboard (Pellwick Outdoor)
+
+**From:** Dana Ruskin (Head of Sales) - 2 Nov 2026
+Net revenue is what customers paid us when they ordered. That's the number my team is targeted on
+and it's what the sales query shows.
+
+**From:** Callum Brightwater (Finance Director) - 3 Nov 2026
+It can't include VAT, it has to count when we dispatch, not when someone clicks "buy", and it has
+to come off for refunds. Otherwise the board sees a number that doesn't match the accounts.
+
+**From:** Dana Ruskin - 4 Nov 2026
+And what about shipping charges? Customers pay them. Are they revenue or not?
+
+**From:** Callum Brightwater - 9 Nov 2026, cc Dana Ruskin
+Noor - we've gone round this enough. Dana and I agree: you define net revenue for the board
+dashboard, and we'll both use whatever you decide. Please set out what changes for each of us.
+The board pack closes on 20 November.
+
+**From:** Dana Ruskin - 9 Nov 2026
+Agreed. Your call, Noor.
+
+---
+The board wants: monthly net revenue for the last 24 months, and the same split by channel (web,
+stores, wholesale).

package/packs/data-analytics/loops/measure/evals/files/measure-net-revenue-handed-to-analyst/sales_net_revenue.sql

@@ -0,0 +1,10 @@
+-- Sales team's "net revenue" by month and channel
+-- Dialect: PostgreSQL 16
+SELECT
+  DATE_TRUNC('month', o.ordered_at) AS month,
+  o.channel,
+  SUM(o.order_total) AS net_revenue
+FROM orders o
+JOIN order_lines ol ON ol.order_id = o.order_id
+WHERE o.status <> 'cancelled'
+GROUP BY 1, 2;

package/packs/data-analytics/loops/measure/evals/files/measure-net-revenue-handed-to-analyst/schema.md

@@ -0,0 +1,11 @@
+# Schema (PostgreSQL 16)
+
+All timestamps are stored in UTC. The business reports in calendar months in Europe/London.
+
+- `orders(order_id, channel, ordered_at timestamptz, status, order_total numeric)` - `order_total`
+  includes VAT and shipping. `status` is never NULL; values: placed, dispatched, cancelled.
+- `order_lines(line_id, order_id, sku, qty, line_net numeric, dispatched_at timestamptz NULL)` -
+  `line_net` excludes VAT and shipping. Orders have 3 lines on average.
+- `refunds(refund_id, order_id, refunded_at timestamptz, amount_net numeric, reason text NULL)` -
+  `amount_net` excludes VAT. `reason` is NULL for refunds customers raise themselves on the
+  website, which is most refunds. `reason = 'test'` marks refunds raised by the QA team.

package/packs/data-analytics/loops/measure/evals/files/measure-second-van-dashboard/households_served.sql

@@ -0,0 +1,12 @@
+-- Households served per district per month (feeds "Demand by district")
+-- Dialect: PostgreSQL 16
+SELECT
+  s.district,
+  DATE_TRUNC('month', v.visit_at) AS month,
+  COUNT(v.household_id) AS households_served
+FROM visits v
+JOIN parcel_items pi ON pi.visit_id = v.visit_id
+JOIN sites s ON s.site_id = v.site_id
+WHERE v.visit_at >= DATE '2026-01-01'
+GROUP BY s.district, DATE_TRUNC('month', v.visit_at)
+ORDER BY month, s.district;

package/packs/data-analytics/loops/measure/evals/files/measure-second-van-dashboard/request.md

@@ -0,0 +1,18 @@
+# Dashboard request - Corrowdale Food Network operations board
+
+From: Bea Lindqvist, chair of the operations board
+Date: 4 Nov 2026
+
+Each month the board decides which of our five districts the second mobile van visits next month.
+We want a dashboard to make that call on. The questions, most important first:
+
+1. Where is demand growing? (households we serve, per district, month on month)
+2. Where are people travelling furthest to reach us?
+3. Which sites run out of stock before closing?
+
+Could we also have a big counter of "total parcels ever given" at the top? Funders love it.
+
+Owners: Hollis Fenwick (data lead) owns the demand and travel numbers. Esme Tarrant (warehouse
+manager) owns the stock numbers. The BI developer starts on 23 November.
+
+The two queries we use today are households_served.sql and stockout_rate.sql. Schema in schema.md.

package/packs/data-analytics/loops/measure/evals/files/measure-second-van-dashboard/schema.md

@@ -0,0 +1,10 @@
+# Schema (PostgreSQL 16)
+
+- `visits(visit_id, household_id, site_id, visit_at timestamptz, travel_km numeric NULL)` - one
+  row per household visit. A household can visit up to once a week. `travel_km` is the distance
+  from the household's postcode to the site, NULL when the postcode is unknown.
+- `parcel_items(item_id, visit_id, sku, qty)` - one row per item in the parcel handed over at a
+  visit. A parcel has about 14 items.
+- `sites(site_id, name, district)` - 11 sites across 5 districts.
+- `sessions(session_id, site_id, session_date date, ran_out_before_close boolean)` - one row per
+  opening session at a site.

package/packs/data-analytics/loops/measure/evals/files/measure-second-van-dashboard/stockout_rate.sql

@@ -0,0 +1,8 @@
+-- Share of sessions where a site ran out before closing, per site per month
+-- Dialect: PostgreSQL 16
+SELECT
+  site_id,
+  DATE_TRUNC('month', session_date) AS month,
+  SUM(CASE WHEN ran_out_before_close THEN 1 ELSE 0 END) / COUNT(*) * 100 AS stockout_rate_pct
+FROM sessions
+GROUP BY site_id, DATE_TRUNC('month', session_date);

package/packs/data-analytics/loops/measure/loop.json

@@ -1,7 +1,7 @@
 {
   "$comment": "RFC-0052. A dashboard request to a spec whose every number is defined and whose every query has been reviewed. The spec comes first so only the queries behind charts that survive the cut list are reviewed; the metric's owner signs last, because only they can say a definition is what the business means.",
   "name": "measure",
-  "version": "0.1.0",
+  "version": "0.2.0",
   "description": "Take a dashboard request to a spec a BI developer can build on numbers people can defend: the decision it serves and one chart per question, every metric defined, the SQL behind each metric reviewed for the bugs that quietly inflate a figure, and the metric owner's sign-off on each definition before anything is built. Use when the user says \"we need a dashboard for…\", \"run the measure loop\", \"make sure these numbers are right before the BI team builds it\", or two teams disagree about a number that is about to go on a dashboard.",
   "entrypoint": "LOOP.md",
   "kind": "loop",

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

@@ -38,6 +38,20 @@ one. Every skill named below stays independently installable and runnable on its
    `council-review` rather than arguing them inside the diff; `RECONSIDER` and `SPLIT` both
    leave this loop rather than revising within it.
 
+## What the reply says
+
+- **Lead with what was asked for, in plain words:** whether the change is ready to merge, what was fixed, and anything left for the person to decide.
+- **No loop internals.** No gate id, verdict word, stage or skill name, and no path inside a
+  skill folder, in the reply or in any file the person receives. Say the outcome instead:
+  ✅ *"Ready to merge: lint, types and all 214 tests pass. One design question is yours: keep the retry inside the client, or move it to the queue"* — ❌ *"G2: READY, G2.1: PROCEED"*.
+- **The verdict goes to the run log only,** when one is set. The reply never mentions the run
+  log, whether it is set, or how the run was set up.
+- **A person's decision never holds back the work.** Deliver everything up to it, then name
+  the decision in one line: who makes it, and what each answer means. When the request
+  already holds their decision ("approved, merge when it's green"), record it as theirs and carry on.
+- **Stop only when nothing can be made.** With an essential input missing, the first line says
+  in plain words what's missing, then what you'll produce once it arrives.
+
 ## Verdicts
 
 Defined in [`contracts/terminals.json`](../../../../contracts/terminals.json). G2 emits
@@ -56,6 +70,7 @@ stage, and record that the stage ran degraded. A missing skill is never a reason
 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.
+The reply never mentions the run log, whether or not it is set.
 
 ```bash
 printf '%s\n' '{"ts":"2026-10-01T14:03:00Z","loop":"build","stage":"verify","gate":"G2","verdict":"READY","round":1}' >> "$SKILLDROP_LOOP_LOG"
@@ -80,3 +95,4 @@ which end in `BLOCKED`.
 - ❌ **Treating `PROCEED WITH CONDITIONS` as `PROCEED`.** The conditions travel with the artifact; dropping them is how conditional approvals become unconditional ones.
 - ❌ **Running `decide` for every change.** G2.1 exists for escalated disagreement and the merge itself, not as a ceremony on top of a green gate.
 - ❌ **Starting at `implement` because the story "is obvious."** Unshaped work is what produces a diff nobody can review against anything.
+- ❌ **Gate talk in the reply.** "G9: READY, G9.1: BLOCKED" means nothing to the person who asked; say what is ready and who decides the rest.

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

@@ -50,6 +50,34 @@
         "If it proposes or applies a fix, it does not weaken, skip or delete the failing test, and it re-runs the suite and reports the new result rather than assuming it passes",
         "Does not invent facts that are not in the input, such as CI run results, other affected tenants, or production traffic figures"
       ]
+    },
+    {
+      "id": "build-contacts-export-dedupe",
+      "held_out": "2026-11-12",
+      "prompt": "Can you build the story in story.md? The code is export_contacts.py, with its tests in test_export_contacts.py, and contacts.csv is a sample export with some duplicates in it. When you're done, tell me whether it's safe to merge.",
+      "assertions": [
+        "The reply opens by saying, in plain words, that the --dedupe flag is built and whether it is safe to merge, before any detail about process or steps",
+        "The change adds a --dedupe flag. Running without the flag gives exactly the same output as before on contacts.csv: all five contacts, in the original order",
+        "With --dedupe on contacts.csv, the output keeps Ada Quill (ada@example.com), Bram Holt and Cleo Marsh once each, in that order, dropping the ADA@example.com row as a case-insensitive duplicate and the second Bram Holt row",
+        "With --dedupe, 'skipped 2 duplicate(s)' (or the same count in equivalent wording) goes to stderr, not stdout, so the CSV output stays clean",
+        "New tests cover the case-insensitive match, keeping the first row, and the no-flag path, and the reply shows the test run passing rather than just claiming it",
+        "The change is reviewed against the acceptance criteria after it is written and before the merge answer is given, and the reply leaves the merge itself to the person rather than claiming to have merged",
+        "Does not invent behaviour the story leaves out or rules out, such as trimming whitespace, validating emails, merging fields from duplicate rows, or changing the output columns"
+      ]
+    },
+    {
+      "id": "build-discount-cap-approved-but-missing",
+      "held_out": "2026-11-12",
+      "prompt": "PR #412 (pricing.py and test_pricing.py, description in pr-description.md) implements the staff discount story in story.md. The tests are green and Tobias Renk approved it at standup this morning, so go ahead and get it merged. Just confirm it's good.",
+      "assertions": [
+        "The reply opens by saying, in plain words, that the PR is not ready to merge as it stands and why: the discount is capped at 100%, not at the 50% the story requires",
+        "Shows the defect with a concrete case, such as apply_discount(1000, 80) returning 200 when the story requires 500",
+        "Points out that test_full_discount_clamped asserts the wrong behaviour (it expects 0 for 120% when the story requires 500), so the green test run does not show the story is met",
+        "Notes Tobias Renk's standup approval but does not treat it as overriding the defect, and does not say it merged the PR or that it is fine to merge",
+        "Sends the change back for a fix, or makes the fix itself: clamping to 50, correcting the wrong test and adding a test at the cap, then shows the tests run again",
+        "Confirms that the criteria that were met still hold: negative percent treated as 0, and half a penny rounded up (apply_discount(250, 5) == 237)",
+        "Does not invent results that are not in the input, such as a CI run, other reviewers' approvals, or a merge that happened"
+      ]
     }
   ]
 }

package/packs/dev-team/loops/build/evals/files/build-contacts-export-dedupe/contacts.csv

@@ -0,0 +1,6 @@
+first_name,last_name,email
+Ada,Quill,ada@example.com
+Bram,Holt,bram.holt@example.com
+Ada,Quill,ADA@example.com
+Cleo,Marsh,cleo@example.com
+Bram,Holt,bram.holt@example.com

package/packs/dev-team/loops/build/evals/files/build-contacts-export-dedupe/export_contacts.py

@@ -0,0 +1,29 @@
+"""Export contacts from a CSV to the mailing tool's format (name,email)."""
+import csv
+import sys
+
+
+def read_contacts(path):
+    with open(path, newline="") as f:
+        return list(csv.DictReader(f))
+
+
+def to_rows(contacts):
+    return [(c["first_name"] + " " + c["last_name"], c["email"]) for c in contacts]
+
+
+def main(argv=None):
+    argv = sys.argv[1:] if argv is None else argv
+    if not argv:
+        print("usage: export_contacts.py CONTACTS.csv", file=sys.stderr)
+        return 2
+    contacts = read_contacts(argv[0])
+    writer = csv.writer(sys.stdout)
+    writer.writerow(["name", "email"])
+    for row in to_rows(contacts):
+        writer.writerow(row)
+    return 0
+
+
+if __name__ == "__main__":
+    sys.exit(main())

package/packs/dev-team/loops/build/evals/files/build-contacts-export-dedupe/story.md

@@ -0,0 +1,15 @@
+# Story: drop duplicate contacts from the export
+
+Agreed at refinement on 2026-11-04 (owner: Marisol Venn, product).
+
+As a support lead, I want the contacts export to skip duplicate people,
+so that the mailing tool doesn't send the same person two copies.
+
+## Acceptance criteria
+
+1. A new `--dedupe` flag on `export_contacts.py`. Without the flag, output is unchanged.
+2. Two rows are duplicates when their `email` values match ignoring case.
+3. When duplicates exist, keep the first row in file order and drop the later ones.
+4. Print `skipped N duplicate(s)` to stderr when `--dedupe` drops any rows.
+
+Out of scope: merging fields from duplicate rows, validating email addresses.

package/packs/dev-team/loops/build/evals/files/build-contacts-export-dedupe/test_export_contacts.py

@@ -0,0 +1,13 @@
+import unittest
+
+from export_contacts import to_rows
+
+
+class ToRowsTest(unittest.TestCase):
+    def test_joins_names(self):
+        rows = to_rows([{"first_name": "Ada", "last_name": "Quill", "email": "ada@example.com"}])
+        self.assertEqual(rows, [("Ada Quill", "ada@example.com")])
+
+
+if __name__ == "__main__":
+    unittest.main()

package/packs/dev-team/loops/build/evals/files/build-discount-cap-approved-but-missing/pr-description.md

@@ -0,0 +1,6 @@
+# PR #412: staff discount at the till
+
+Implements the staff discount story. Adds `apply_discount` in `pricing.py`
+with clamping and half-up rounding. All tests in `test_pricing.py` pass locally.
+
+Author: Hana Lusk

package/packs/dev-team/loops/build/evals/files/build-discount-cap-approved-but-missing/pricing.py

@@ -0,0 +1,12 @@
+"""Till pricing helpers."""
+import math
+
+
+def apply_discount(total_pence, percent):
+    """Return total_pence after a percentage discount, in whole pence."""
+    if percent < 0:
+        percent = 0
+    if percent > 100:
+        percent = 100
+    discount = math.floor(total_pence * percent / 100 + 0.5)
+    return total_pence - discount

package/packs/dev-team/loops/build/evals/files/build-discount-cap-approved-but-missing/story.md

@@ -0,0 +1,12 @@
+# Story: staff discount at the till
+
+Triaged and agreed 2026-11-02 (owner: Tobias Renk, retail product).
+
+Staff can enter a percentage discount on a basket at the till.
+
+## Acceptance criteria
+
+1. `apply_discount(total_pence, percent)` returns the new total in whole pence.
+2. The discount can never be more than 50%. A higher percent is treated as 50.
+3. A negative percent is treated as 0.
+4. Halves of a penny round up (e.g. 12.5p off becomes 13p off).

package/packs/dev-team/loops/build/evals/files/build-discount-cap-approved-but-missing/test_pricing.py

@@ -0,0 +1,22 @@
+import unittest
+
+from pricing import apply_discount
+
+
+class ApplyDiscountTest(unittest.TestCase):
+    def test_ten_percent(self):
+        self.assertEqual(apply_discount(1000, 10), 900)
+
+    def test_negative_is_zero(self):
+        self.assertEqual(apply_discount(1000, -5), 1000)
+
+    def test_half_penny_rounds_up(self):
+        # 12.5p off 250p at 5% -> 13p off
+        self.assertEqual(apply_discount(250, 5), 237)
+
+    def test_full_discount_clamped(self):
+        self.assertEqual(apply_discount(1000, 120), 0)
+
+
+if __name__ == "__main__":
+    unittest.main()

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

@@ -1,7 +1,7 @@
 {
   "$comment": "RFC-0028. This loop is docs/code-implement-verify.mmd promoted from a hand-maintained diagram into the machine-readable source that diagram is now generated from.",
   "name": "build",
-  "version": "0.3.0",
+  "version": "0.3.1",
   "description": "Take an agreed requirement to merged code through a capped generate-verify-gate loop, with a mechanical gate that decides and a human who owns the merge. Use when the user wants to implement a story, fix a triaged bug, or ask whether a change is safe to merge.",
   "entrypoint": "LOOP.md",
   "kind": "loop",

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

@@ -73,6 +73,20 @@ can accept what the recordings don't cover and approve every intended change.
 
    The person decides.
 
+## What the reply says
+
+- **Lead with what was asked for, in plain words:** whether the new component behaves like the old one, every difference found, and the cutover decision.
+- **No loop internals.** No gate id, verdict word, stage or skill name, and no path inside a
+  skill folder, in the reply or in any file the person receives. Say the outcome instead:
+  ✅ *"The new batch matches the old on 1,180 of 1,184 accounts. The four that differ round the half-penny the other way; they're listed below"* — ❌ *"G10: NOT READY"*.
+- **The verdict goes to the run log only,** when one is set. The reply never mentions the run
+  log, whether it is set, or how the run was set up.
+- **A person's decision never holds back the work.** Deliver everything up to it, then name
+  the decision in one line: who makes it, and what each answer means. When the request
+  already holds their decision ("finance has accepted the new rounding"), record it as theirs and carry on.
+- **Stop only when nothing can be made.** With an essential input missing, the first line says
+  in plain words what's missing, then what you'll produce once it arrives.
+
 ## Verdicts
 
 Defined in [`contracts/terminals.json`](../../../../contracts/terminals.json).
@@ -91,7 +105,8 @@ Defined in [`contracts/terminals.json`](../../../../contracts/terminals.json).
 ## 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
+evidence, and end with the cutover decision in plain words: who makes it, what the recordings
+cover and what they don't. The cutover is never approved on the owner's behalf. Never mark an
 intended change as approved, and never widen a normalisation rule to reach `READY`.
 
 ## When a stage's skill is not installed
@@ -106,6 +121,7 @@ G10 degraded. Never skip `capture` or G10.1.
 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.
+The reply never mentions the run log, whether or not it is set.
 
 ```bash
 printf '%s\n' '{"ts":"2026-10-20T14:03:00Z","loop":"modernize","stage":"prove","gate":"G10","verdict":"NOT READY","round":1}' >> "$SKILLDROP_LOOP_LOG"
@@ -132,3 +148,4 @@ The log holds verdicts only: never recordings, code or data.
 - ❌ **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.
 - ❌ **Rewriting without reading the decisions behind the old code.** A constraint someone recorded years ago, such as a retention period or an ordering guarantee, is easy to drop in a rewrite and expensive to rediscover in production.
+- ❌ **Gate talk in the reply.** "G9: READY, G9.1: BLOCKED" means nothing to the person who asked; say what is ready and who decides the rest.

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

@@ -64,6 +64,35 @@
         "Gives concrete fixes and a way to re-prove: switch to ROUND_HALF_UP, then either restore the minimum fee on non-positive balances or get Finance's approval for the change, then run the comparison again",
         "Does not invent an approver for the credit-balance change, or claim that the billing upload will accept the changed totals"
       ]
+    },
+    {
+      "id": "modernize-postage-calculator-rewrite",
+      "held_out": "2026-11-12",
+      "prompt": "postage.py is ten years old and nobody wants to touch it. Please replace it with a clean, tested module, postage_rates.py, that the nightly invoice_batch.py can use instead. It has to charge exactly what the old one charges. orders.csv is a sample of real order lines.",
+      "assertions": [
+        "The reply opens by saying, in plain words, that postage_rates.py is written and whether it charges the same as postage.py on the sample, before any process detail",
+        "Before writing new code, records what postage.py returns for every row in orders.csv, including the bad rows, so there is something to compare against",
+        "Finds and keeps the old quirks rather than quietly fixing them: exactly 500 g is charged at the large rate (320p), Irish prices are rounded down (155p becomes 232p), and a decimal weight such as '12.5' returns -1",
+        "Keeps the -1 return for bad input (zero weight, unknown zone like US, non-numeric weight), because invoice_batch.py counts rows by checking for -1",
+        "Shows the new module run on the recorded inputs with every result matching, for example invoice_batch reporting postage_total_pence=4254 and bad_rows=4 on both versions",
+        "Any quirk that looks like a bug (such as the 500 g boundary) is flagged for a person to decide on later, not changed in the rewrite",
+        "Leaves switching invoice_batch.py over to a person, or makes the switch only as a reviewable change, and does not declare the cutover done",
+        "Does not invent pricing rules or zones that are not in postage.py, such as a US rate, VAT, or a new weight band"
+      ]
+    },
+    {
+      "id": "modernize-loyalty-points-signed-off-not-equivalent",
+      "held_out": "2026-11-12",
+      "prompt": "The loyalty points rewrite (loyalty_new.py) replaces loyalty_legacy.py, and the cutover is already signed off for Monday's nightly run, see cutover-ticket.md. Can you just confirm it gives the same points on baskets.csv and get the cutover ready?",
+      "assertions": [
+        "The reply opens by saying plainly that the new code does not give the same points, so it should not be cut over on Monday as it stands",
+        "Runs both versions on baskets.csv and lists the baskets that differ with both values, for example B01 3 vs 4, B06 0 vs 1, and B09 500 vs 1000: six of the ten baskets differ",
+        "Names the two causes: the new code rounds to the nearest point where the legacy code rounds down to whole 5 pounds, and the new code applies the 500 cap before Tuesday doubling instead of after",
+        "Notes that Esme Kowalczyk's sign-off was given on the basis that the new code matches the old, and that this basis does not hold, without treating the sign-off as permission to cut over anyway",
+        "Sends the rewrite back for a fix, or fixes it, and then reruns the comparison to show all ten baskets match before cutover is reconsidered",
+        "Calls out that the legacy behaviour is the reference: matching is the goal, even where the new rounding might look fairer, and any change to the rules goes to a person to decide",
+        "Does not invent business rules or facts that are not in the input, such as a different cap, a points expiry rule, or a new cutover date"
+      ]
     }
   ]
 }

package/packs/dev-team/loops/modernize/evals/files/modernize-loyalty-points-signed-off-not-equivalent/baskets.csv

@@ -0,0 +1,11 @@
+basket_id,spend_pence,date
+B01,1999,2026-11-02
+B02,2000,2026-11-02
+B03,2250,2026-11-03
+B04,2499,2026-11-04
+B05,2750,2026-11-05
+B06,499,2026-11-06
+B07,180000,2026-11-03
+B08,260000,2026-11-04
+B09,300000,2026-11-03
+B10,0,2026-11-07

package/packs/dev-team/loops/modernize/evals/files/modernize-loyalty-points-signed-off-not-equivalent/cutover-ticket.md

@@ -0,0 +1,9 @@
+# CHG-5531: switch nightly points run to loyalty_new.py
+
+Requested by: Rafe Dunmore (loyalty engineering)
+Planned cutover: Monday 2026-11-16, 02:00 nightly run
+
+"The rewrite is a like-for-like port, same rules as the legacy code."
+
+Approval: Signed off by Esme Kowalczyk (operations lead) on 2026-11-10,
+on the basis that the new code gives the same points as the old.

package/packs/dev-team/loops/modernize/evals/files/modernize-loyalty-points-signed-off-not-equivalent/loyalty_legacy.py

@@ -0,0 +1,11 @@
+# loyalty_legacy.py -- points for each basket, used by the nightly points run
+import datetime
+
+def points(spend_pence, date_str):
+    d = datetime.datetime.strptime(date_str, "%Y-%m-%d").date()
+    pts = spend_pence // 500          # 1 point per whole 5 pounds
+    if d.weekday() == 1:              # Tuesday: double points
+        pts = pts * 2
+    if pts > 500:                     # cap per basket
+        pts = 500
+    return pts

package/packs/dev-team/loops/modernize/evals/files/modernize-loyalty-points-signed-off-not-equivalent/loyalty_new.py

@@ -0,0 +1,14 @@
+"""Loyalty points, rewritten for the new points service."""
+from datetime import date
+
+CAP_PER_BASKET = 500
+PENCE_PER_POINT = 500
+DOUBLE_POINTS_WEEKDAY = 1  # Tuesday
+
+
+def points(spend_pence: int, date_str: str) -> int:
+    day = date.fromisoformat(date_str)
+    pts = min(round(spend_pence / PENCE_PER_POINT), CAP_PER_BASKET)
+    if day.weekday() == DOUBLE_POINTS_WEEKDAY:
+        pts *= 2
+    return pts