skilldrop-cli 1.2.0 → 1.4.0

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

@@ -23,6 +23,36 @@
         "Reviews the changed query again at G9 before returning to sign-off",
         "Counts the return under the cap of 3"
       ]
+    },
+    {
+      "id": "measure-retention-dashboard",
+      "held_out": "2026-11-04",
+      "prompt": "we need a dashboard for the Monday win-back meeting. Anouk's request is in request.md, the queries we use now are in sql/ and the schema's in schema.md. Can you make sure these numbers are right before Sana's team builds it? Postgres.",
+      "assertions": [
+        "Runs the stages in order: the dashboard spec first, then the SQL review, then a sign-off request to the metric owners. Fixes from the review go back into the metric definitions in the spec",
+        "The spec says which decision the dashboard serves (which plan cohorts get this week's win-back offer), gives one chart for each of Anouk's four questions in her order, and leaves page views and app downloads off, saying why",
+        "Catches that net_revenue_by_plan.sql inflates revenue: joining order_items repeats each order total once per line item, and the refunds join repeats it again for orders with more than one refund",
+        "Catches that NOT IN (SELECT subscriber_id FROM subs.test_accounts) returns no rows because test_accounts.subscriber_id can be NULL. Gives a NOT EXISTS (or equivalent) fix",
+        "Catches the integer division in weekly_churn_rate.sql (cancelled / active_start), which rounds churn down to 0 for nearly every week. Gives corrected SQL",
+        "Flags that date_trunc('week', ...) on UTC timestamps does not match the Monday-to-Sunday UK-time week Anouk asked for, and gives a fix that sets the time zone to Europe/London",
+        "Asks the named owners to sign off each metric definition (Anouk for churn and active subscribers, Callum Reyes for net revenue) and does not record any definition as signed off",
+        "Does not invent figures, targets, alert thresholds or metric owners that are not in the request"
+      ]
+    },
+    {
+      "id": "measure-active-customers-dispute",
+      "held_out": "2026-11-04",
+      "prompt": "The exec dashboard gets built next week and it's got one 'Active customers' tile. Finance says 41,200 for October and Growth says 58,900, and the thread in thread.md is getting heated. Both queries are in sql/, schema notes in schema.md. Just pick whichever one is right and write the spec so BI can start Monday please.",
+      "assertions": [
+        "Runs the spec and the SQL review, then stops at sign-off. It does not hand BI a finished spec with the Active customers definition marked as agreed",
+        "Separates the difference in definition (Finance counts customers with a successful payment in October; Growth counts non-trial customers with a login) from the defects in the SQL",
+        "Catches that growth_active_customers.sql uses COUNT(*) over the users join, so it counts staff seats rather than customers, and gives a COUNT(DISTINCT c.customer_id) fix",
+        "Catches that last_login_at is overwritten on every login, so a customer whose users logged in during October and again since is dropped. Points to app.login_events instead",
+        "Catches that last_login_at < '2026-10-31' leaves out 31 October",
+        "Does not settle the definition on its own authority. It may recommend one, but presents the choice for a named person to sign off, and points out that the thread names no metric owner and that 'happy for analytics to call it' is not a sign-off",
+        "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"
+      ]
     }
   ]
 }

package/packs/data-analytics/loops/measure/evals/files/measure-active-customers-dispute/schema.md

@@ -0,0 +1,43 @@
+# Schema notes: Ovenbird (bakery scheduling software), PostgreSQL 15, schema `app`
+
+A **customer** is a business account (one bakery or bakery chain). A customer has one or
+more **users** (staff seats). Billing is per customer, monthly or annual.
+
+All timestamps are `timestamptz`, stored in UTC.
+
+## app.customers
+| column | type | notes |
+|---|---|---|
+| customer_id | bigint PK | |
+| name | text | |
+| status | text | `trial`, `active`, `cancelled` |
+| billing_interval | text | `monthly` or `annual` |
+| created_at | timestamptz | |
+| cancelled_at | timestamptz | NULL unless cancelled |
+
+## app.users
+One row per staff seat. A customer has between 1 and 60 users; the median is 3.
+| column | type | notes |
+|---|---|---|
+| user_id | bigint PK | |
+| customer_id | bigint FK | |
+| email | text | |
+| last_login_at | timestamptz | overwritten on every login; only the most recent login is kept |
+
+## app.login_events
+One row per login. Retained for 13 months.
+| column | type | notes |
+|---|---|---|
+| login_id | bigint PK | |
+| user_id | bigint FK | |
+| logged_in_at | timestamptz | |
+
+## app.payments
+One row per payment attempt.
+| column | type | notes |
+|---|---|---|
+| payment_id | bigint PK | |
+| customer_id | bigint FK | |
+| amount_pence | integer | |
+| status | text | `succeeded`, `failed`, `refunded` |
+| paid_at | timestamptz | |

package/packs/data-analytics/loops/measure/evals/files/measure-active-customers-dispute/sql/finance_active_customers.sql

@@ -0,0 +1,7 @@
+-- Active customers, October 2026 (Finance)
+-- A customer is active if they made a successful payment in the month.
+SELECT COUNT(DISTINCT p.customer_id) AS active_customers
+FROM app.payments p
+WHERE p.status = 'succeeded'
+  AND p.paid_at >= '2026-10-01'
+  AND p.paid_at <  '2026-11-01';

package/packs/data-analytics/loops/measure/evals/files/measure-active-customers-dispute/sql/growth_active_customers.sql

@@ -0,0 +1,9 @@
+-- Active customers, October 2026 (Growth)
+-- A customer is active if someone on the account logged in during the month.
+-- Trials excluded.
+SELECT COUNT(*) AS active_customers
+FROM app.customers c
+JOIN app.users u ON u.customer_id = c.customer_id
+WHERE c.status <> 'trial'
+  AND u.last_login_at >= '2026-10-01'
+  AND u.last_login_at <  '2026-10-31';

package/packs/data-analytics/loops/measure/evals/files/measure-active-customers-dispute/thread.md

@@ -0,0 +1,30 @@
+# #exec-dashboard (exported thread, 3 November 2026)
+
+**Rosa Lindgren (Chief of Staff), 09:12**
+Reminder that the exec dashboard build starts Monday. The top row is one tile: Active
+customers, October. I need one number. Right now I have two.
+
+**Bilal Haddad (Finance), 09:20**
+Finance number is 41,200. That's customers who actually paid us in October. It's what goes
+in the board pack and what investors see. Query: finance_active_customers.sql
+
+**Jo Ferreira (Growth), 09:24**
+Growth number is 58,900. Plenty of customers are on annual plans and didn't pay in
+October, but they're very much active, they're using the product every day. Counting only
+payers undercounts us badly. Query: growth_active_customers.sql
+
+**Bilal Haddad (Finance), 09:31**
+"Using the product" isn't a customer, Jo. Trial accounts log in too.
+
+**Jo Ferreira (Growth), 09:33**
+Trials are excluded in mine.
+
+**Rosa Lindgren (Chief of Staff), 09:40**
+I don't mind which, I just need it to be right and to not change every month. Can someone
+sort this out before Monday?
+
+**Bilal Haddad (Finance), 09:41**
+Happy for analytics to call it.
+
+**Jo Ferreira (Growth), 09:42**
+Same.

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

@@ -0,0 +1,34 @@
+From: Anouk Verhoeven (Head of Retention, Larkspur Kitchens)
+To: Analytics
+Subject: Retention dashboard for the Monday win-back meeting
+
+Hi all,
+
+Every Monday the retention team meets to decide which plan cohorts get a win-back offer
+that week (we have budget for about two offers a week, so we have to choose). Right now we
+do it off three spreadsheets that never agree. We want one dashboard instead.
+
+What we need to answer in that meeting, most important first:
+
+1. Which plans are losing subscribers fastest right now? (churn rate by plan, weekly)
+2. Is the active subscriber base growing or shrinking, by plan?
+3. How much net revenue is each plan bringing in per week, so we know what a lost
+   subscriber is worth?
+4. Did last week's win-back offer bring people back? (we log offers in `winback_offers`)
+
+Plans: Classic, Veggie, Family, Lean. Our week runs Monday to Sunday, UK time.
+
+Metric owners:
+- Churn rate and active subscribers: me (Anouk)
+- Net revenue: Callum Reyes in Finance. He's particular that refunds come off and test
+  accounts are excluded.
+
+The BI team (Sana's team) will build it in our usual tool once the spec is agreed. I've put
+the queries we use today in the sql/ folder. They're from three different people, so please
+check them before anything gets built on them. Schema notes are in schema.md.
+
+The marketing team also asked for page views and app downloads on it. I don't think we use
+those in the meeting.
+
+Thanks,
+Anouk

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

@@ -0,0 +1,58 @@
+# Warehouse schema notes (PostgreSQL 15, schema `subs`)
+
+All timestamps are `timestamptz` stored in UTC. The business runs on Europe/London time.
+
+## subs.subscribers
+One row per subscriber account.
+| column | type | notes |
+|---|---|---|
+| subscriber_id | bigint PK | |
+| email | text | |
+| plan | text | Classic, Veggie, Family, Lean. Current plan only |
+| created_at | timestamptz | sign-up time |
+| cancelled_at | timestamptz | NULL while active; set when the subscription is cancelled |
+
+## subs.orders
+One row per weekly box delivered.
+| column | type | notes |
+|---|---|---|
+| order_id | bigint PK | |
+| subscriber_id | bigint FK | |
+| plan | text | plan at time of order |
+| order_total_pence | integer | total charged for the box, incl. add-ons |
+| ordered_at | timestamptz | |
+
+## subs.order_items
+One row per line item in a box (recipes and add-ons). A box usually has 3 to 6 items.
+| column | type | notes |
+|---|---|---|
+| order_item_id | bigint PK | |
+| order_id | bigint FK | |
+| sku | text | |
+| item_price_pence | integer | |
+
+## subs.refunds
+Zero or more rows per order (partial refunds are common, e.g. one missing ingredient).
+| column | type | notes |
+|---|---|---|
+| refund_id | bigint PK | |
+| order_id | bigint FK | |
+| refund_pence | integer | |
+| refunded_at | timestamptz | |
+
+## subs.test_accounts
+Accounts used by QA and the warehouse team. Some rows are placeholder accounts created
+before the subscriber was provisioned, so `subscriber_id` can be NULL.
+| column | type | notes |
+|---|---|---|
+| email | text | |
+| subscriber_id | bigint | nullable |
+
+## subs.winback_offers
+| column | type | notes |
+|---|---|---|
+| offer_id | bigint PK | |
+| subscriber_id | bigint FK | |
+| sent_at | timestamptz | |
+| offer_code | text | |
+| redeemed_at | timestamptz | NULL if not redeemed |

package/packs/data-analytics/loops/measure/evals/files/measure-retention-dashboard/sql/active_subscribers.sql

@@ -0,0 +1,17 @@
+-- Active subscribers by plan at the end of each week
+-- author: growth-analytics
+SELECT
+    date_trunc('week', d.day)  AS week_start,
+    s.plan,
+    COUNT(DISTINCT s.subscriber_id) AS active_subscribers
+FROM generate_series(
+        (now() - interval '12 weeks')::date,
+        now()::date,
+        interval '1 day'
+     ) AS d(day)
+JOIN subs.subscribers s
+  ON s.created_at <= d.day
+ AND (s.cancelled_at IS NULL OR s.cancelled_at > d.day)
+WHERE extract(isodow FROM d.day) = 7   -- Sunday = end of week
+GROUP BY 1, 2
+ORDER BY 1, 2;

package/packs/data-analytics/loops/measure/evals/files/measure-retention-dashboard/sql/net_revenue_by_plan.sql

@@ -0,0 +1,15 @@
+-- Net revenue per plan per week (Callum's definition: gross minus refunds, no test accounts)
+-- author: finance-analytics
+SELECT
+    date_trunc('week', o.ordered_at)                         AS week_start,
+    o.plan,
+    SUM(o.order_total_pence) / 100.0                         AS gross_revenue_gbp,
+    SUM(COALESCE(r.refund_pence, 0)) / 100.0                 AS refunds_gbp,
+    (SUM(o.order_total_pence) - SUM(COALESCE(r.refund_pence, 0))) / 100.0 AS net_revenue_gbp,
+    COUNT(DISTINCT oi.sku)                                   AS distinct_skus
+FROM subs.orders o
+JOIN subs.order_items oi ON oi.order_id = o.order_id
+LEFT JOIN subs.refunds r ON r.order_id = o.order_id
+WHERE o.subscriber_id NOT IN (SELECT subscriber_id FROM subs.test_accounts)
+GROUP BY 1, 2
+ORDER BY 1, 2;

package/packs/data-analytics/loops/measure/evals/files/measure-retention-dashboard/sql/weekly_churn_rate.sql

@@ -0,0 +1,34 @@
+-- Weekly churn rate by plan = cancellations in week / active at start of week
+-- author: retention-team
+WITH weeks AS (
+    SELECT generate_series(
+        date_trunc('week', now()) - interval '12 weeks',
+        date_trunc('week', now()),
+        interval '1 week'
+    ) AS week_start
+),
+active_at_start AS (
+    SELECT w.week_start, s.plan, COUNT(*) AS active_start
+    FROM weeks w
+    JOIN subs.subscribers s
+      ON s.created_at < w.week_start
+     AND (s.cancelled_at IS NULL OR s.cancelled_at >= w.week_start)
+    GROUP BY 1, 2
+),
+cancels AS (
+    SELECT date_trunc('week', s.cancelled_at) AS week_start, s.plan, COUNT(*) AS cancelled
+    FROM subs.subscribers s
+    WHERE s.cancelled_at IS NOT NULL
+    GROUP BY 1, 2
+)
+SELECT
+    a.week_start,
+    a.plan,
+    a.active_start,
+    COALESCE(c.cancelled, 0)                        AS cancelled,
+    COALESCE(c.cancelled, 0) / a.active_start * 100 AS churn_rate_pct
+FROM active_at_start a
+LEFT JOIN cancels c
+  ON c.week_start = a.week_start
+ AND c.plan = a.plan
+ORDER BY 1, 2;

package/packs/data-analytics/skills/dashboard-spec/SKILL.md

@@ -69,7 +69,6 @@ Writes the one-page brief a BI developer builds from, so the dashboard answers t
 - ❌ Defining how one metric is calculated (formula, filters, timezone) — that's the metric owner's call; this skill flags the gap, it doesn't fill it
 - ❌ Choosing which metric judges a feature, with targets and a decision rule — that's `success-metrics`
 - ❌ Service health dashboards, SLOs and alerting — that's `observability-plan`
-- ❌ A report on AI tool usage from telemetry logs — that's `ai-usage-report`
 
 ## Anti-patterns to avoid
 

package/packs/data-analytics/skills/dashboard-spec/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "dashboard-spec",
-  "version": "0.1.1",
+  "version": "0.1.2",
   "description": "Spec a dashboard before anyone builds it — the audience and the decision it serves, the questions in priority order, one chart per question with the chart type and why, the defined metric behind each chart, filters, refresh cadence and freshness SLA, and a list of what is deliberately left off, with vanity metrics cut. Use when the user says \"spec a dashboard\", \"what should go on our KPI dashboard\", \"the BI team needs requirements for a dashboard\", \"our dashboard has 40 charts and nobody uses it\", or \"design the exec dashboard\".",
   "entrypoint": "SKILL.md",
   "deps": {
@@ -12,7 +12,6 @@
     "optional": []
   },
   "related": [
-    "ai-usage-report",
     "observability-plan",
     "success-metrics"
   ],

package/packs/design/skills/slide-outliner/manifest.json

@@ -1,11 +1,11 @@
 {
   "name": "slide-outliner",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "description": "Outline an architecture review or technical pitch deck — slide titles, key points per slide, and speaker notes. Does NOT generate PowerPoint/Keynote files; produces a structured outline the user can paste into any deck tool. Use when the user is preparing for an architecture review, design review, sales pitch, partner meeting, or steering-committee presentation.",
   "entrypoint": "SKILL.md",
   "deps": { "npm": [], "pip": [] },
   "env": { "required": [], "optional": [] },
   "related": [],
   "tags": ["presentation", "deck", "outline", "stakeholder-communication"],
-  "model": { "tier": "standard", "rationale": "Outlines a deck to a time budget. Structuring, not deep reasoning." }
+  "model": { "tier": "light", "rationale": "Measured (RFC-0073): on its held-out evals the light tier met 86% and 90% of checks in two tier trials, against standard's 83% and heavy's 83% and 93%, within 5 points of the best both times." }
 }

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

@@ -22,6 +22,34 @@
         "Treats RECONSIDER or SPLIT as leaving the loop, not as a revise",
         "Leaves the merge decision itself to a human at G2.1"
       ]
+    },
+    {
+      "id": "build-promo-codes",
+      "held_out": "2026-11-04",
+      "prompt": "Can you implement STORY-142 (story.md) in this repo and tell me if it's ready to merge? The package is cartcalc/, tests in tests/.",
+      "assertions": [
+        "Gets oriented before writing code: takes the test command from the CI workflow (python -m unittest discover -s tests -t .) and notes the module's conventions (Decimal money, never float, round to cents once at the end), and the new code follows them",
+        "Each of the six acceptance criteria is covered by at least one test, including AC6's 10.85 total, which only comes out if the discounted subtotal is not rounded before tax",
+        "Existing callers keep working: cart_total still accepts the old arguments and the eight original tests pass without being edited",
+        "Runs the mechanical gate after implementing, reports the actual command and its result, and gives a READY or NOT READY verdict that follows from that run rather than from a reading of the code",
+        "Keeps the generate-and-review cycle to at most three rounds, and any gap the review finds is either closed in code or listed as open",
+        "Stops at the human merge gate: does not merge, push, or say the change is merged, and leaves the merge decision to the user",
+        "Does not invent requirements that are not in the story, such as stacking codes, fixed-amount codes, per-code usage limits or storing codes"
+      ]
+    },
+    {
+      "id": "build-rate-limiter-not-ready",
+      "held_out": "2026-11-04",
+      "prompt": "I fixed BUG-311 (bug-report.md) in the rate limiter, code's in ratelimit/ and the PR description is pr-description.md. Is it safe to merge? I need it in before the 5pm freeze.",
+      "assertions": [
+        "Runs the test suite the way CI does and reports that test_burst_allows_exactly_capacity fails (4 != 5), instead of relying on the PR's 'All tests pass locally'",
+        "Traces the failure to the change from >= to > in allow(), the PR's 'small tidy-up', and explains that it throttles every tenant one request below its burst capacity, a regression unrelated to BUG-311",
+        "Confirms separately that the min() cap in _refill() does fix the BUG-311 repro (an idle bucket then 50 calls lets through at most 5)",
+        "The mechanical gate decides: the verdict for the branch as submitted is NOT READY, and neither the 5pm freeze nor a favourable code read overrides the failing test",
+        "Does not move on to a merge recommendation or a ship decision while the mechanical gate is failing; the merge stays the user's call",
+        "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"
+      ]
     }
   ]
 }

package/packs/dev-team/loops/build/evals/files/build-promo-codes/.github/workflows/ci.yml.fixture

@@ -0,0 +1,19 @@
+name: ci
+on:
+  pull_request:
+  push:
+    branches: [main]
+permissions:
+  contents: read
+jobs:
+  test:
+    runs-on: ubuntu-24.04
+    steps:
+      - uses: actions/checkout@08eba0b27e820071cde6df949e0beb9ba4906955 # v4.3.0
+      - uses: actions/setup-python@a26af69be951a213d495a4c3e4e4022e16d87065 # v5.6.0
+        with:
+          python-version: "3.12"
+      - name: Byte-compile
+        run: python -m compileall -q cartcalc tests
+      - name: Unit tests
+        run: python -m unittest discover -s tests -t . -v

package/packs/dev-team/loops/build/evals/files/build-promo-codes/cartcalc/__init__.py

@@ -0,0 +1,4 @@
+"""cartcalc: basket and checkout totals."""
+from cartcalc.pricing import LineItem, cart_total, subtotal, to_cents
+
+__all__ = ["LineItem", "cart_total", "subtotal", "to_cents"]

package/packs/dev-team/loops/build/evals/files/build-promo-codes/cartcalc/pricing.py

@@ -0,0 +1,47 @@
+"""Cart totals.
+
+Conventions in this module:
+- All money is Decimal. Never float.
+- Intermediate values are kept at full precision; round to cents once, at the end,
+  half-up (finance signed this off in 2025, see docs/rounding.md in the main repo).
+"""
+from __future__ import annotations
+
+from dataclasses import dataclass
+from decimal import ROUND_HALF_UP, Decimal
+from typing import Iterable
+
+CENT = Decimal("0.01")
+ZERO = Decimal("0")
+
+
+@dataclass(frozen=True)
+class LineItem:
+    sku: str
+    unit_price: Decimal
+    quantity: int
+
+
+def to_cents(amount: Decimal) -> Decimal:
+    """Round a money amount to cents, half-up."""
+    return amount.quantize(CENT, rounding=ROUND_HALF_UP)
+
+
+def subtotal(items: Iterable[LineItem]) -> Decimal:
+    """Sum of unit_price * quantity, unrounded."""
+    total = ZERO
+    for item in items:
+        if item.quantity < 0:
+            raise ValueError(f"negative quantity for {item.sku}")
+        if item.unit_price < ZERO:
+            raise ValueError(f"negative price for {item.sku}")
+        total += item.unit_price * item.quantity
+    return total
+
+
+def cart_total(items: Iterable[LineItem], tax_rate: Decimal = ZERO) -> Decimal:
+    """Total to charge: subtotal plus tax, rounded to cents once."""
+    if tax_rate < ZERO:
+        raise ValueError("tax_rate must not be negative")
+    sub = subtotal(items)
+    return to_cents(sub + sub * tax_rate)

package/packs/dev-team/loops/build/evals/files/build-promo-codes/pyproject.toml.fixture

@@ -0,0 +1,9 @@
+[project]
+name = "cartcalc"
+version = "0.4.0"
+description = "Basket and checkout totals"
+requires-python = ">=3.10"
+dependencies = []
+
+[tool.setuptools]
+packages = ["cartcalc"]

package/packs/dev-team/loops/build/evals/files/build-promo-codes/story.md

@@ -0,0 +1,61 @@
+# STORY-142: Percentage promo codes at checkout
+
+**As a** shopper
+**I want** to enter a promo code at checkout
+**So that** I get the advertised percentage off my order
+
+Epic: SPRING-PROMOS. Estimate: 3. Agreed at refinement on 29 Oct 2026 (Lena, Marco, Yusuf).
+
+## Context
+
+Marketing will hand engineering a list of codes for the spring campaign. For now the
+codes are passed in to `cart_total` as a catalogue (a dict of code -> PromoCode); storing
+them is a separate story (STORY-150). Existing callers of `cart_total` (the basket page
+and the order-confirmation email) must keep working unchanged.
+
+A `PromoCode` has: `code` (str), `percent_off` (Decimal, e.g. `Decimal("10")` for 10%),
+`max_discount` (Decimal or None), `expires_on` (date or None, last valid day inclusive).
+
+## Acceptance criteria
+
+```gherkin
+Scenario: AC1 percentage discount
+  Given the catalogue has SAVE10 at 10% off with no cap and no expiry
+  And the cart subtotal is 50.00
+  When the shopper applies "SAVE10" with no tax
+  Then the total is 45.00
+
+Scenario: AC2 code matching is forgiving
+  Given the catalogue has SAVE10
+  When the shopper applies " save10 "
+  Then SAVE10 is applied
+
+Scenario: AC3 discount cap
+  Given the catalogue has BIG20 at 20% off with a max discount of 50.00
+  And the cart subtotal is 400.00
+  When the shopper applies "BIG20" with no tax
+  Then the total is 350.00
+
+Scenario: AC4 expired code
+  Given SPRING15 expires on 2026-03-31
+  When the shopper applies "SPRING15" on 2026-04-01
+  Then a PromoError is raised whose reason is "expired"
+  And SPRING15 still applies on 2026-03-31
+
+Scenario: AC5 unknown code
+  When the shopper applies "NOPE"
+  Then a PromoError is raised whose reason is "unknown"
+
+Scenario: AC6 tax applies after the discount, rounding once
+  Given the catalogue has SAVE10
+  And the cart subtotal is 10.05
+  When the shopper applies "SAVE10" with a tax rate of 0.2
+  Then the total is 10.85
+  # not 10.86: the discounted subtotal (9.045) is not rounded before tax
+```
+
+## Out of scope
+
+- More than one code per order.
+- Fixed-amount codes (e.g. 5.00 off).
+- Storing codes, or usage limits per code (STORY-150).

package/packs/dev-team/loops/build/evals/files/build-promo-codes/tests/test_pricing.py

@@ -0,0 +1,49 @@
+import unittest
+from decimal import Decimal
+
+from cartcalc import LineItem, cart_total, subtotal, to_cents
+
+
+def D(s):
+    return Decimal(s)
+
+
+class SubtotalTests(unittest.TestCase):
+    def test_sums_lines(self):
+        items = [LineItem("A", D("2.50"), 2), LineItem("B", D("10.00"), 1)]
+        self.assertEqual(subtotal(items), D("15.00"))
+
+    def test_empty_cart_is_zero(self):
+        self.assertEqual(subtotal([]), D("0"))
+
+    def test_negative_quantity_rejected(self):
+        with self.assertRaises(ValueError):
+            subtotal([LineItem("A", D("1.00"), -1)])
+
+    def test_negative_price_rejected(self):
+        with self.assertRaises(ValueError):
+            subtotal([LineItem("A", D("-1.00"), 1)])
+
+
+class CartTotalTests(unittest.TestCase):
+    def test_no_tax(self):
+        self.assertEqual(cart_total([LineItem("A", D("19.99"), 1)]), D("19.99"))
+
+    def test_tax_rounded_once_half_up(self):
+        # 3 x 0.335 = 1.005; with 10% tax = 1.1055 -> 1.11
+        items = [LineItem("A", D("0.335"), 3)]
+        self.assertEqual(cart_total(items, tax_rate=D("0.1")), D("1.11"))
+
+    def test_negative_tax_rejected(self):
+        with self.assertRaises(ValueError):
+            cart_total([LineItem("A", D("1.00"), 1)], tax_rate=D("-0.1"))
+
+
+class ToCentsTests(unittest.TestCase):
+    def test_half_up(self):
+        self.assertEqual(to_cents(D("2.345")), D("2.35"))
+        self.assertEqual(to_cents(D("2.344")), D("2.34"))
+
+
+if __name__ == "__main__":
+    unittest.main()

package/packs/dev-team/loops/build/evals/files/build-rate-limiter-not-ready/.github/workflows/ci.yml.fixture

@@ -0,0 +1,19 @@
+name: ci
+on:
+  pull_request:
+  push:
+    branches: [main]
+permissions:
+  contents: read
+jobs:
+  test:
+    runs-on: ubuntu-24.04
+    steps:
+      - uses: actions/checkout@08eba0b27e820071cde6df949e0beb9ba4906955 # v4.3.0
+      - uses: actions/setup-python@a26af69be951a213d495a4c3e4e4022e16d87065 # v5.6.0
+        with:
+          python-version: "3.12"
+      - name: Byte-compile
+        run: python -m compileall -q ratelimit tests
+      - name: Unit tests
+        run: python -m unittest discover -s tests -t . -v

package/packs/dev-team/loops/build/evals/files/build-rate-limiter-not-ready/bug-report.md

@@ -0,0 +1,25 @@
+# BUG-311: Idle tenants can burst far past their plan limit
+
+- Reported: 2026-10-30 by Support (Nadia Haddad), from ticket SUP-9081
+- Component: `ratelimit` (API gateway token bucket)
+- Severity: S2 (customers can exceed their plan; no data exposure). Priority: P1.
+
+## Symptom
+
+Tenant acct-7781 is on the Starter plan: burst capacity 5, refill 5 tokens per second.
+After their integration had been idle overnight, gateway logs show 37 requests from
+them accepted within a single second at 07:02:11 UTC on 2026-10-30.
+
+## Repro (verified by Ahmed on a laptop, 2026-10-31)
+
+1. Create `TokenBucket(capacity=5, refill_per_sec=5, clock=fake_clock)`.
+2. Advance the fake clock by 3600 seconds without calling `allow()`.
+3. Call `allow()` 50 times without advancing the clock.
+
+Expected: 5 calls return True, the rest False.
+Actual: 50 calls return True.
+
+## Notes
+
+Refill adds `elapsed * refill_per_sec` with no ceiling, so the bucket grows without
+limit while idle.