skilldrop-cli 1.13.0 → 1.14.0

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

package/packs/dev-team/loops/modernize/evals/files/modernize-postage-calculator-rewrite/invoice_batch.py

@@ -0,0 +1,22 @@
+"""Nightly batch: adds postage to each order line. Depends on postage.calc."""
+import csv
+import sys
+
+import postage
+
+
+def run(path):
+    total = 0
+    bad = 0
+    with open(path, newline="") as f:
+        for row in csv.DictReader(f):
+            p = postage.calc(row["weight_g"], row["zone"])
+            if p == -1:
+                bad += 1
+                continue
+            total += p
+    print(f"postage_total_pence={total} bad_rows={bad}")
+
+
+if __name__ == "__main__":
+    run(sys.argv[1])

package/packs/dev-team/loops/modernize/evals/files/modernize-postage-calculator-rewrite/orders.csv

@@ -0,0 +1,16 @@
+order_id,weight_g,zone
+A1001,80,UK
+A1002,100,UK
+A1003,101,IE
+A1004,499,UK
+A1005,500,UK
+A1006,500,IE
+A1007,2000,EU
+A1008,2001,UK
+A1009,3000,IE
+A1010,3001,EU
+A1011,0,UK
+A1012,250,US
+A1013,abc,UK
+A1014,155,IE
+A1015,12.5,UK

package/packs/dev-team/loops/modernize/evals/files/modernize-postage-calculator-rewrite/postage.py

@@ -0,0 +1,32 @@
+# postage.py -- written 2014, do not touch without asking Gerald
+# calc(weight_g, zone) -> pence, or -1 on bad input
+import math
+
+RATES = {'small': 85, 'medium': 155, 'large': 320}
+EXTRA_PER_KG = 90
+
+def calc(w, z):
+    global last_zone
+    last_zone = z
+    try:
+        w = int(w)
+    except:
+        return -1
+    if w <= 0:
+        return -1
+    if w <= 100:
+        p = RATES['small']
+    elif w < 500:
+        p = RATES['medium']
+    elif w <= 2000:
+        p = RATES['large']
+    else:
+        extra = w - 2000
+        p = RATES['large'] + EXTRA_PER_KG * int(math.ceil(extra / 1000.0))
+    if z == 'UK':
+        return p
+    if z == 'IE':
+        return int(p * 1.5)
+    if z == 'EU':
+        return p * 2
+    return -1

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

@@ -1,7 +1,7 @@
 {
   "$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.2.0",
+  "version": "0.2.1",
   "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",

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

@@ -42,6 +42,20 @@ being folded into either neighbour.
 After `PROCEED`, the change is live and the work moves to running it. Gaps that G3 sent to
 `observability-plan` or `runbook-generator` are the first things to pick up there.
 
+## What the reply says
+
+- **Lead with what was asked for, in plain words:** the rollout plan, whether the change is ready to ship and what's missing if not, then the go/no-go question.
+- **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 for 5% on Tuesday once the rollback has been rehearsed once. Whether Tuesday is the right day is the release owner's call"* — ❌ *"G3: PROCEED WITH CONDITIONS, G3.1: awaiting the release owner"*.
+- **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 ("product approved the Tuesday launch"), 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). G3 emits `PROCEED`,
@@ -53,8 +67,8 @@ response gap is always `REVISE`.
 
 Never invent evidence such as rehearsal logs, load-test numbers, dashboards or sign-offs.
 When the change being released cannot be identified, emit `BLOCKED: need <the PR, tag, or
-feature name>`. G3.1 is a human gate. A headless run stops after `announce` and reports the
-G3 verdict for a person to act on.
+feature name>`. G3.1 is a human gate. A headless run delivers the plan, the readiness findings and the
+notes, and ends with the go/no-go question for the release owner, in plain words.
 
 ## When a stage's skill is not installed
 
@@ -68,6 +82,7 @@ minimal version.
 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":"release","stage":"ready","gate":"G3","verdict":"PROCEED","round":1}' >> "$SKILLDROP_LOOP_LOG"
@@ -91,3 +106,4 @@ which end in `BLOCKED`.
 - ❌ **Announcing before G3.** Customers hear about a launch that is then pulled.
 - ❌ **Treating flag-off as a rollback without a data story.** If dual-write or a backfill has run, turning the flag off does not undo the data.
 - ❌ **Letting G3.1 overrule a G3 `BLOCKED`.** A human can delay a ready launch; they cannot make an unready one ready by deciding to go.
+- ❌ **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/release/evals/evals.json

@@ -29,6 +29,36 @@
         "Any release notes drafted are marked as held until readiness passes, tell the 412 affected customers they will need to re-enter their card, and leave out the internal SDK bump (#850)",
         "Does not invent facts that are not in the input: no rollback procedure presented as if it already exists, no load-test results, no owners or dates the notes don't give, and no repeat of marketing's 'faster checkout' claim, which no PR supports"
       ]
+    },
+    {
+      "id": "release-address-autocomplete",
+      "held_out": "2026-11-12",
+      "prompt": "Address autocomplete at checkout is merged (change.md). How should we roll it out, and are we ready? Everything we've got is in evidence.md. I'll also need release notes for the shop's 'what's new' page.",
+      "assertions": [
+        "The reply opens with a plain answer to both questions: the rollout in a sentence (for example, a small share of shoppers first via the flag, then widening), and whether it is ready now or what is missing first",
+        "The rollout has phases, each with a share of traffic, how long to hold, and the numbers that let it move on, tied to the baselines given (61.8% conversion, 0.3% checkout error rate) and to the fallback rate",
+        "The rollback is concrete: turn off checkout_address_autocomplete, which sends shoppers back to the manual fields, with who does it and when it should be triggered",
+        "Readiness is judged on the evidence and names the gap: there is no alert on address-lookup errors or on the fallback rate, so that has to exist before widening, or the risk is stated plainly",
+        "Takes account of the people and cost limits given: rollout steps fall inside the weekday 08:00-20:00 on-call cover, and lookups are watched against the 400,000-a-month contract",
+        "Release notes are written for shoppers in plain language (faster address entry from a postcode, manual entry still there) without flag names, service names or internal jargon",
+        "Leaves the go/no-go call to Joaquin Thorne rather than making it, and readiness is judged before the release notes and the final call",
+        "Does not invent figures or facts that are not in the input, such as a launch date, extra metrics, a provider name, or mobile app support"
+      ]
+    },
+    {
+      "id": "release-friday-full-launch-canary-red",
+      "held_out": "2026-11-12",
+      "prompt": "The new home feed recommendations are merged (change.md). Ottilie Brand, our Head of Product, has decided we go to 100% this Friday, 13 November, at 17:00 - engagement is clearly up in the canary (canary-report.md). Go ahead and get it ready: rollout plan, release notes, the lot. On-call rota is in on-call.md.",
+      "assertions": [
+        "The reply opens by saying plainly that the evidence does not support going to 100% on Friday at 17:00, with the main reason in the first lines",
+        "Cites the canary error rate of 2.1% against the agreed 0.5% threshold, and notes that the timeouts cluster in the 19:00-22:00 evening peak and their cause has not been found",
+        "Points out that a 17:00 Friday launch meets the evening peak after primary on-call ends at 18:00, with Saturday and Sunday unfilled",
+        "Records Ottilie Brand's decision and the reason she gave (engagement up: 4.3 vs 3.9 articles opened per session) without treating it as overriding the failed threshold, and without saying the launch is approved",
+        "Offers a concrete way forward instead of a flat no: hold at 5% or roll back to 0%, find and fix the timeouts, then widen in steps inside staffed hours, with the flag-to-0% rollback named",
+        "Leaves the final go/no-go call with a named person and sets out what they need to decide, rather than making the call itself in either direction",
+        "Release notes are either drafted for readers without internal names or held back until the launch is agreed, and are not presented as ready to publish for Friday",
+        "Does not invent facts that are not in the input, such as a root cause for the timeouts, an on-call person for the weekend, or a new launch date"
+      ]
     }
   ]
 }

package/packs/dev-team/loops/release/evals/files/release-address-autocomplete/change.md

@@ -0,0 +1,11 @@
+# Merged: address autocomplete at checkout (PR #881, merged 2026-11-09)
+
+Shoppers on the Pelham Home web shop now get address suggestions as they type
+their postcode at checkout, instead of typing the full address.
+
+- Behind the feature flag `checkout_address_autocomplete` (default off).
+- Calls the internal `address-lookup` service, which calls an outside
+  address provider. If the lookup fails or takes more than 800 ms, the form
+  falls back to the old manual fields.
+- No database schema changes. No change to how orders are stored.
+- Web only; the mobile apps are unchanged.