skilldrop-cli 0.16.8 → 0.16.10

package/packs/data-analytics/skills/metric-definition/evals/files/4/thread.md

@@ -0,0 +1,31 @@
+# #ops-reporting — export, 1–2 October 2026
+
+**Gethin Aldous (Regional Ops Manager), 1 Oct 09:12**
+September first-time fix is in. 3,912 of 4,830 completed repairs closed with no follow-up flag. That's 84%. Best month this year.
+
+**Roisin Fairweather (Customer Care Lead), 1 Oct 09:40**
+We get 68%. 3,282 of 4,830. We only count a repair as fixed if nobody had to go back within 30 days.
+
+**Gethin Aldous, 1 Oct 09:44**
+The engineer ticks follow_up_required when the job needs another visit. That is the record. If they didn't tick it, it was fixed.
+
+**Roisin Fairweather, 1 Oct 09:58**
+They don't tick it when they think it's fixed and it isn't. 630 of your 3,912 had someone back out within 30 days. Those customers rang us, not you.
+And you can't just count recalls either. The contact centre logs about half of the go-backs as a brand new repair instead of a recall, because that's the default in the booking screen.
+
+**Gethin Aldous, 1 Oct 10:03**
+For what it's worth 4,830 already leaves out cancelled and no-access visits. We agree on that at least.
+
+**Nkechi Brandt (BI Analyst), 1 Oct 10:20**
+I pulled both sets of numbers this morning. Two things from the data side:
+- appliance_id has only been filled in since 3 March 2026 when the new engineer app went live. Before that it's NULL and all you have is address_id.
+- Some addresses have more than one appliance (HMOs, small commercial units). So "same address" and "same appliance" are not the same test.
+
+**Owen Prys (Finance Director), 2 Oct 08:15**
+The board pack needs one number, ready on the 1st of each month, with last September next to it for comparison. Subcontractors in or out, I don't mind, just tell me which. And who owns this going forward?
+
+**Gethin Aldous, 2 Oct 08:31**
+It was Marguerite's before she left in August. Nobody has picked it up.
+
+**Roisin Fairweather, 2 Oct 08:40**
+Installs and annual services shouldn't be anywhere near this, by the way. It's a repair measure.

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

@@ -15,9 +15,9 @@ being folded into either neighbour.
 | # | Stage | Type | Skills | Gate |
 |---|---|---|---|---|
 | 1 | `plan` | generate | [`migration-plan`](../../skills/migration-plan/SKILL.md) | — |
-| 2 | `ready` | verify | [`launch-readiness`](../../skills/launch-readiness/SKILL.md) | **G2.5** review |
+| 2 | `ready` | verify | [`launch-readiness`](../../skills/launch-readiness/SKILL.md) | **G3** review |
 | 3 | `announce` | generate | [`release-notes`](../../skills/release-notes/SKILL.md) | — |
-| 4 | `go` | gate | [`council-review`](../../../core/skills/council-review/SKILL.md) | **G2.6** human |
+| 4 | `go` | gate | [`council-review`](../../../core/skills/council-review/SKILL.md) | **G3.1** human |
 
 ## How to run this loop
 
@@ -25,34 +25,34 @@ being folded into either neighbour.
    rollback for each one, and at most one named point of no return. For a code-only change
    behind a flag, the plan can be short: the flag, the stages and how to turn it off. It still
    has to exist.
-2. **Judge readiness at G2.5.** `launch-readiness` lists the change's own failure modes, then
+2. **Judge readiness at G3.** `launch-readiness` lists the change's own failure modes, then
    checks rollback, detection, response, measured targets, data and privacy, comms and
    exposure, each with evidence. `REVISE` returns to `plan`, and the report names which gap to
    close and which skill closes it. A missing rollback is `BLOCKED` on its own.
 3. **Announce only once it is ready.** `release-notes` drafts the customer-facing and
-   internal notes from the git range. Writing them before G2.5 risks announcing a launch that
+   internal notes from the git range. Writing them before G3 risks announcing a launch that
    then does not happen.
-4. **A human decides at G2.6.** The release owner decides whether to ship *now*, given
+4. **A human decides at G3.1.** The release owner decides whether to ship *now*, given
    timing, freeze windows and on-call coverage. When that decision is contested, use
    `council-review`. `RECONSIDER` means it is ready but this is the wrong time, and the work
    waits instead of going back to `plan`.
 
-After `PROCEED`, the change is live and the work moves to `operate`. Gaps that G2.5 sent to
+After `PROCEED`, the change is live and the work moves to `operate`. Gaps that G3 sent to
 `observability-plan` or `runbook-generator` are the first things `operate` picks up.
 
 ## Verdicts
 
-Defined in [`contracts/terminals.json`](../../../../contracts/terminals.json). G2.5 emits `PROCEED`,
-`PROCEED WITH CONDITIONS`, `REVISE` or `BLOCKED`. G2.6 adds `RECONSIDER`. `PROCEED WITH
-CONDITIONS` at G2.5 is allowed only when the open rows are comms or exposure. A detection or
+Defined in [`contracts/terminals.json`](../../../../contracts/terminals.json). G3 emits `PROCEED`,
+`PROCEED WITH CONDITIONS`, `REVISE` or `BLOCKED`. G3.1 adds `RECONSIDER`. `PROCEED WITH
+CONDITIONS` at G3 is allowed only when the open rows are comms or exposure. A detection or
 response gap is always `REVISE`.
 
 ## Non-interactive runs
 
 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>`. G2.6 is a human gate. A headless run stops after `announce` and reports the
-G2.5 verdict for a person to act on.
+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.
 
 ## When a stage's skill is not installed
 
@@ -68,7 +68,7 @@ gate's verdict, append one JSON line to that file. Nothing else is recorded, and
 sent anywhere. When the variable isn't set, or you can't read it, skip this section.
 
 ```bash
-printf '%s\n' '{"ts":"2026-10-01T14:03:00Z","loop":"release","stage":"ready","gate":"G2.5","verdict":"PROCEED","round":1}' >> "$SKILLDROP_LOOP_LOG"
+printf '%s\n' '{"ts":"2026-10-01T14:03:00Z","loop":"release","stage":"ready","gate":"G3","verdict":"PROCEED","round":1}' >> "$SKILLDROP_LOOP_LOG"
 ```
 
 Fields: `ts` (UTC), `loop`, `stage`, `gate` (`null` for a stage without one), `verdict` (the
@@ -80,12 +80,12 @@ which end in `BLOCKED`.
 
 - **Rollback exists before readiness is judged.** A plan with no way back is the one thing that cannot be fixed after launch.
 - **Readiness rests on evidence.** Every check links to something; "we're good" is `not met`.
-- **Can and should are separate gates.** G2.5 says whether it can ship; G2.6 says whether it should ship now.
+- **Can and should are separate gates.** G3 says whether it can ship; G3.1 says whether it should ship now.
 - **Detection gaps leave this loop as hand-offs.** `operate` picks them up first, rather than discovering them during the first incident.
 
 ## Anti-patterns to avoid
 
 - ❌ **Jumping from merge to "instrument a running service".** That skips this loop entirely, which is the gap it exists to close.
-- ❌ **Announcing before G2.5.** Customers hear about a launch that is then pulled.
+- ❌ **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 G2.6 overrule a G2.5 `BLOCKED`.** A human can delay a ready launch; they cannot make an unready one ready by deciding to go.
+- ❌ **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.

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

@@ -1,5 +1,5 @@
 {
-  "$comment": "RFC-0031. Covers the step between build (ends at merge, G2.1) and operate (starts at instrument). The gate ids sit between G2 and G3 to match where the loop sits in the lifecycle.",
+  "$comment": "RFC-0031. Covers the step between build (ends at merge, G2.1) and operate (starts at instrument). Its gates are G3 and G3.1: the whole number places the loop in the lifecycle (discover G0 through operate G4), and a decimal is a second gate inside the same loop (RFC-0044).",
   "name": "release",
   "version": "0.2.0",
   "description": "Take merged code to live users through a planned, reversible rollout — plan the phases and the rollback, judge readiness on evidence, draft the release notes, then a human makes the go/no-go call. Use when the user has merged a change and asks how to roll it out, whether they are ready to launch, or for a go/no-go decision.",
@@ -19,7 +19,7 @@
       "intent": "Judge on evidence whether the change can go live: rollback, detection, response, measured targets, data, comms, exposure.",
       "skills": ["launch-readiness"],
       "gate": {
-        "id": "G2.5",
+        "id": "G3",
         "kind": "review",
         "verdicts": ["PROCEED", "PROCEED WITH CONDITIONS", "REVISE", "BLOCKED"],
         "revise_to": "plan"
@@ -37,7 +37,7 @@
       "intent": "A human decides whether it should ship now. Readiness says it can; this decides timing, freeze windows, and who is on call.",
       "skills": ["council-review"],
       "gate": {
-        "id": "G2.6",
+        "id": "G3.1",
         "kind": "human",
         "verdicts": ["PROCEED", "PROCEED WITH CONDITIONS", "REVISE", "RECONSIDER", "BLOCKED"],
         "revise_to": "plan"

package/packs/dev-team/skills/contribution-wizard/evals/evals.json

@@ -43,6 +43,36 @@
         "It does not invent the director's name, the team's name, team members other than Priya, or a specific repo folder stated as fact",
         "The test cases use realistic pasted standup notes as input, and at least one covers thin or missing notes"
       ]
+    },
+    {
+      "id": 4,
+      "held_out": "2026-10-06",
+      "prompt": "Our library systems team keeps a small skills repo, it's this folder (CONTRIBUTING.md, registry.json, a couple of existing skills under skills/). I want to add one called ILL_Request_Triage. Staff paste in an interlibrary loan request from the request form export (patron name, card number, the title, author, year published, list price, and whether the catalogue check found a copy on our shelves) and it says which of our four routes the request goes down, with a one-line reason:\n\n- fill from our own stock, if the catalogue check says we hold a copy that's on the shelf\n- borrow through the Northmere Consortium, if we don't hold it and it was published more than 2 years ago\n- buy it, if we don't hold it, it was published in the last 2 years and the list price is under £60\n\nCategory is resource-sharing, maintainer is resource-sharing@harrowgate.example. Can you write up everything I need for the pull request?",
+      "assertions": [
+        "The skill's metadata is delivered as a skill.toml file alongside PROMPT.md and an examples folder, and no meta.json is created for the new skill",
+        "The skill is given a lowercase hyphenated name that starts with a verb and spells out interlibrary loan (for example triage-interlibrary-loan-requests), not ILL_Request_Triage or a name containing the abbreviation ill, and the reply tells the author the name was changed to fit the naming rules",
+        "handles_patron_data is set to true, and the skill's instructions tell the assistant not to repeat the library card number in its output",
+        "The reply tells the author that four routes were mentioned but only three were described, and does not write a rule for a fourth route as though the author had given one",
+        "It points out at least one request the stated rules do not cover, such as a title published in the last 2 years with a list price of £60 or more, or a copy we hold that is out on loan",
+        "The skill's instructions carry the 2-year and £60 thresholds exactly as given and introduce no other price or age threshold",
+        "There are at least three example input/expected pairs, and at least one is an awkward case such as a request with a field missing",
+        "A registry.json entry for the new skill is provided with category resource-sharing and maintainer resource-sharing@harrowgate.example"
+      ]
+    },
+    {
+      "id": 5,
+      "held_out": "2026-10-06",
+      "prompt": "my cofounder keeps saying we should have a 'skill' so our coding agent writes the release notes instead of me doing it every other friday. input is the list of merged PR titles since the last release, output is the notes we post for customers (they're shop owners, not devs). some PRs shouldn't show up publicly, security fixes mostly, so handle that somehow. we're 4 people and don't have a skills setup yet, i think it'd go in .claude/skills in the main repo but not sure that's right. keep it small, one file if possible, plus a couple of examples i can try it on",
+      "assertions": [
+        "It delivers a drafted instruction file for the release-notes skill and at least two example inputs to try it on, and does not stop at a list of questions",
+        "The skill itself is one instruction file, with no separate manifest, metadata file or multi-file package presented as required",
+        "It says where the skill should live is unconfirmed, treating .claude/skills as the author's guess to check, not as an established fact about their repo",
+        "The skill's instructions tell it to write only from the PR titles it is given and not to add features, fixes or details the titles do not contain",
+        "The skill's instructions tell it to write for shop owners in plain language, not to copy developer-facing PR titles through as they are",
+        "The skill's instructions keep security-fix PRs out of the public notes or set them aside for a person to decide, and the reply says the exact rule for what stays private is the author's to confirm",
+        "At least one of the examples includes a security-fix PR title",
+        "It does not invent a product name, a company name, a version number scheme, PR label names or a command for fetching the PR titles and state it as fact"
+      ]
     }
   ]
 }

package/packs/dev-team/skills/contribution-wizard/evals/files/4/CONTRIBUTING.md

@@ -0,0 +1,63 @@
+# Contributing a skill
+
+Harrowgate University Library, Systems & Discovery team. Last revised 12 March 2026.
+
+Skills are short instruction files our staff assistant loads when a member of staff
+asks for a particular job. Six of us maintain them. Keep them small.
+
+## Layout
+
+Each skill is one folder under `skills/`:
+
+```
+skills/<name>/
+  skill.toml            metadata
+  PROMPT.md             the instructions the assistant follows
+  examples/
+    01-input.md         what a member of staff would paste
+    01-expected.md      what a good answer looks like
+    02-input.md
+    ...
+```
+
+At least three input/expected pairs. One of them must be an awkward case (missing
+field, contradictory request, nothing to do).
+
+Since March 2026 metadata lives in `skill.toml`. A few older skills still carry a
+`meta.json` until someone migrates them. New skills must not add one.
+
+## skill.toml
+
+```toml
+name = "summarise-reading-list"      # same as the folder name
+summary = "One sentence, 120 characters at most."
+category = "cataloguing"             # one of the categories in registry.json
+maintainer = "alias@harrowgate.example"
+handles_patron_data = false
+version = "0.1.0"                    # new skills start at 0.1.0
+```
+
+## Naming
+
+- lowercase, words joined with hyphens
+- starts with a verb (`summarise-`, `flag-`, `draft-`)
+- no abbreviations a new member of staff would not know. Write `interlibrary-loan`,
+  not `ill`; write `reading-list`, not `rl`.
+- 40 characters at most
+
+## Patron data
+
+If the input a skill receives can contain patron names, library card numbers or
+contact details, set `handles_patron_data = true`, and PROMPT.md must tell the
+assistant never to repeat a library card number in its output (refer to the patron
+by name or by request number instead).
+
+## Registry
+
+Add one entry for the skill to the `skills` list in `registry.json` (name, category,
+maintainer). Keep the list in alphabetical order by name.
+
+## Before you open a pull request
+
+Run `python3 tools/lint_skills.py` from the repo root. It checks the layout, the
+naming rules and that every skill is in the registry.

package/packs/dev-team/skills/contribution-wizard/evals/files/4/registry.json

@@ -0,0 +1,15 @@
+{
+  "categories": ["acquisitions", "cataloguing", "circulation", "resource-sharing"],
+  "skills": [
+    {
+      "name": "flag-overdue-holds",
+      "category": "circulation",
+      "maintainer": "circdesk@harrowgate.example"
+    },
+    {
+      "name": "summarise-reading-list",
+      "category": "cataloguing",
+      "maintainer": "metadata@harrowgate.example"
+    }
+  ]
+}

package/packs/dev-team/skills/contribution-wizard/evals/files/4/skills/flag-overdue-holds/PROMPT.md

@@ -0,0 +1,10 @@
+# flag-overdue-holds
+
+You are given the hold-shelf report: one line per item with request number, title,
+patron name, card number and the date the item was shelved.
+
+1. List every item shelved more than 7 days before the report date, oldest first.
+2. For each, give the request number, the title and the patron's name.
+3. Never repeat a library card number. Refer to the patron by name.
+
+If nothing is over 7 days, say so.

package/packs/dev-team/skills/contribution-wizard/evals/files/4/skills/flag-overdue-holds/examples/01-expected.md

@@ -0,0 +1,2 @@
+1 item over 7 days:
+- R-88121, Silent Spring, Amara Okoye (shelved 2026-02-09)

package/packs/dev-team/skills/contribution-wizard/evals/files/4/skills/flag-overdue-holds/examples/01-input.md

@@ -0,0 +1,3 @@
+Report date 2026-02-20
+R-88121 | Silent Spring | Amara Okoye | 2100457781 | 2026-02-09
+R-88160 | The Peregrine | Jonas Lind | 2100331290 | 2026-02-17

package/packs/dev-team/skills/contribution-wizard/evals/files/4/skills/flag-overdue-holds/examples/02-expected.md

@@ -0,0 +1 @@
+Nothing on the hold shelf is over 7 days.

package/packs/dev-team/skills/contribution-wizard/evals/files/4/skills/flag-overdue-holds/examples/02-input.md

@@ -0,0 +1,2 @@
+Report date 2026-02-20
+R-88160 | The Peregrine | Jonas Lind | 2100331290 | 2026-02-17

package/packs/dev-team/skills/contribution-wizard/evals/files/4/skills/flag-overdue-holds/examples/03-expected.md

@@ -0,0 +1 @@
+Nothing can be flagged: R-88171 (Waterlog, Petra Havel) has no shelved date.

package/packs/dev-team/skills/contribution-wizard/evals/files/4/skills/flag-overdue-holds/examples/03-input.md

@@ -0,0 +1,2 @@
+Report date 2026-02-20
+R-88171 | Waterlog | Petra Havel | 2100778123 |

package/packs/dev-team/skills/contribution-wizard/evals/files/4/skills/flag-overdue-holds/meta.json

@@ -0,0 +1,7 @@
+{
+  "name": "flag-overdue-holds",
+  "summary": "Lists hold-shelf items uncollected for more than 7 days so the desk can release them.",
+  "category": "circulation",
+  "maintainer": "circdesk@harrowgate.example",
+  "version": "1.2.0"
+}

package/packs/dev-team/skills/contribution-wizard/evals/files/4/skills/summarise-reading-list/PROMPT.md

@@ -0,0 +1,11 @@
+# summarise-reading-list
+
+You are given a module reading list pasted from the reading list system: one item
+per line, with title, author, year, format and a `held` column (yes/no).
+
+1. Count the items by format (book, e-book, article, other).
+2. List every item where `held` is `no`, with title, author and year.
+3. If a line has no `held` value, list it separately under "Holding not stated".
+   Do not guess.
+
+Never add items that are not in the pasted list. If the list is empty, say so and stop.

package/packs/dev-team/skills/contribution-wizard/evals/files/4/skills/summarise-reading-list/examples/01-expected.md

@@ -0,0 +1,4 @@
+Books: 2, e-books: 1.
+
+Not held:
+- Landscape and Memory, Schama, 1995

package/packs/dev-team/skills/contribution-wizard/evals/files/4/skills/summarise-reading-list/examples/01-input.md

@@ -0,0 +1,4 @@
+Module HIS2041
+The Making of the English Landscape | Hoskins | 1955 | book | yes
+Landscape and Memory | Schama | 1995 | book | no
+Fields of Vision | Daniels | 1993 | e-book | yes

package/packs/dev-team/skills/contribution-wizard/evals/files/4/skills/summarise-reading-list/examples/02-expected.md

@@ -0,0 +1,6 @@
+Books: 1.
+
+Not held: none.
+
+Holding not stated:
+- An Atlas of Rural Settlement, Roberts, 2000

package/packs/dev-team/skills/contribution-wizard/evals/files/4/skills/summarise-reading-list/examples/02-input.md

@@ -0,0 +1,2 @@
+Module GEO1010
+An Atlas of Rural Settlement | Roberts | 2000 | book |

package/packs/dev-team/skills/contribution-wizard/evals/files/4/skills/summarise-reading-list/examples/03-expected.md

@@ -0,0 +1 @@
+The reading list for ENG3300 has no items.

package/packs/dev-team/skills/contribution-wizard/evals/files/4/skills/summarise-reading-list/examples/03-input.md

@@ -0,0 +1 @@
+Module ENG3300

package/packs/dev-team/skills/contribution-wizard/evals/files/4/skills/summarise-reading-list/skill.toml

@@ -0,0 +1,6 @@
+name = "summarise-reading-list"
+summary = "Turns a module reading list into a count of items by format and a list of titles we do not hold."
+category = "cataloguing"
+maintainer = "metadata@harrowgate.example"
+handles_patron_data = false
+version = "0.3.0"

package/packs/dev-team/skills/devils-advocate/evals/evals.json

@@ -43,6 +43,35 @@
         "It gives a concrete fix, such as reading with the csv module and normalising the email with strip and lower",
         "It does not state as fact what the other columns hold or what the real file contains beyond what was given"
       ]
+    },
+    {
+      "id": 4,
+      "held_out": "2026-10-06",
+      "prompt": "Finished the late fee feature for the tenant billing service (lateFees.ts, tests in lateFees.test.ts). Rules from finance: nothing if the invoice is 5 days or fewer past due. After that it's 1.5% of the balance for each calendar month the invoice has been overdue in, so one due 20 March and still open on 2 May has March, April and May. Capped at $75 per invoice in total. Never on paid or void invoices. A nightly job calls applyLateFees with every invoice. Tests are green. Can you go over it before I merge? Skip the style nits, I want the things that would actually bite us.",
+      "assertions": [
+        "It flags that monthsOverdue subtracts month numbers without the year, so an invoice due in November or December and still open in January gets a zero or negative count and no fee",
+        "It flags that the $75 cap is applied to one month's amount before multiplying by the months, so a large balance overdue for two or more months is charged more than $75 (for example $10,000 over two months gives $150)",
+        "It flags that applyLateFees adds the whole fee to the balance on every nightly run with nothing recording what was already charged, so the same invoice is charged again each night",
+        "It points out that the cap test uses a single month overdue, where a per-month cap and a total cap give the same $75, so it cannot catch the cap bug",
+        "It points out that the applyLateFees test only checks the balance went up after one run, and that no test runs it twice or checks the amount",
+        "It names a missing test for an invoice that is overdue across a year boundary",
+        "It does not report the grace-period check as a bug: charging nothing at 5 days late or fewer matches the stated rule",
+        "It says plainly that the change is not ready to merge as it stands"
+      ]
+    },
+    {
+      "id": 5,
+      "held_out": "2026-10-06",
+      "prompt": "agent wrote this migration for me. adds region onto orders so the regional dashboards don't need the join to customers. ran clean on my laptop db. postgres. the orders table in prod is big-ish, don't know the exact size. top 3 things i should worry about before i run it friday?\n\n```sql\nALTER TABLE orders ADD COLUMN region_code VARCHAR(2) NOT NULL;\n\nUPDATE orders\nSET region_code = (SELECT region FROM customers WHERE customers.id = orders.customer_id);\n\nCREATE INDEX idx_orders_region ON orders(region_code);\n```",
+      "assertions": [
+        "It flags that adding a NOT NULL column with no default fails on a table that already has rows, so the first statement will error on prod",
+        "It says the clean run on the laptop does not show the migration works on prod, for example because the local orders table may have been empty",
+        "It flags locking or long-running work on a large table, from the single full-table UPDATE or the non-concurrent index build, and gives a concrete mitigation such as batching the backfill or CREATE INDEX CONCURRENTLY",
+        "It flags that a customer with no region, or a region longer than 2 characters, would break the backfill, and says what customers.region holds is not known from what was given",
+        "It gives a corrected order of steps: add the column as nullable, backfill it, then add the NOT NULL constraint",
+        "It does not state the row count of orders, how long the migration will take, or what customers.region contains as fact",
+        "It leads with three main concerns as asked, and anything beyond the three is kept to a brief mention"
+      ]
     }
   ]
 }

package/packs/dev-team/skills/devils-advocate/evals/files/4/lateFees.test.ts

@@ -0,0 +1,46 @@
+import { describe, it, expect } from "vitest";
+import { applyLateFees, computeLateFee, Invoice } from "./lateFees";
+
+const day = (s: string) => new Date(s + "T12:00:00Z");
+
+const invoice = (over: Partial<Invoice> = {}): Invoice => ({
+  id: "INV-1001",
+  tenantId: "T-204",
+  dueDate: "2026-03-01",
+  balance: 1000,
+  status: "open",
+  ...over,
+});
+
+describe("computeLateFee", () => {
+  it("charges nothing inside the grace period", () => {
+    expect(computeLateFee(invoice(), day("2026-03-06"))).toBe(0);
+  });
+
+  it("charges 1.5% once the grace period is over", () => {
+    expect(computeLateFee(invoice(), day("2026-03-07"))).toBe(15);
+  });
+
+  it("charges for each calendar month overdue", () => {
+    const inv = invoice({ dueDate: "2026-03-20" });
+    expect(computeLateFee(inv, day("2026-05-02"))).toBe(45);
+  });
+
+  it("caps the fee at $75", () => {
+    const inv = invoice({ balance: 10000 });
+    expect(computeLateFee(inv, day("2026-03-10"))).toBe(75);
+  });
+
+  it("never charges paid or void invoices", () => {
+    expect(computeLateFee(invoice({ status: "paid" }), day("2026-06-01"))).toBe(0);
+    expect(computeLateFee(invoice({ status: "void" }), day("2026-06-01"))).toBe(0);
+  });
+});
+
+describe("applyLateFees", () => {
+  it("adds the fee to open invoices", () => {
+    const inv = invoice();
+    applyLateFees([inv], day("2026-03-10"));
+    expect(inv.balance).toBeGreaterThan(1000);
+  });
+});

package/packs/dev-team/skills/devils-advocate/evals/files/4/lateFees.ts

@@ -0,0 +1,46 @@
+export interface Invoice {
+  id: string;
+  tenantId: string;
+  dueDate: string; // ISO date, e.g. "2026-03-01"
+  balance: number; // dollars outstanding
+  status: "open" | "paid" | "void";
+}
+
+const GRACE_DAYS = 5;
+const MONTHLY_RATE = 0.015;
+const FEE_CAP = 75;
+const MS_PER_DAY = 86_400_000;
+
+function parseDue(inv: Invoice): Date {
+  return new Date(inv.dueDate + "T00:00:00Z");
+}
+
+export function daysLate(inv: Invoice, today: Date): number {
+  return Math.floor((today.getTime() - parseDue(inv).getTime()) / MS_PER_DAY);
+}
+
+// Number of calendar months the invoice has been overdue in, counting the
+// month it fell due. Due 20 March, today 2 May -> 3.
+export function monthsOverdue(inv: Invoice, today: Date): number {
+  return today.getUTCMonth() - parseDue(inv).getUTCMonth() + 1;
+}
+
+export function computeLateFee(inv: Invoice, today: Date): number {
+  if (inv.status !== "open") return 0;
+  if (daysLate(inv, today) <= GRACE_DAYS) return 0;
+
+  const monthly = Math.min(inv.balance * MONTHLY_RATE, FEE_CAP);
+  const fee = monthly * monthsOverdue(inv, today);
+  return Math.round(fee * 100) / 100;
+}
+
+// Called by the nightly job with every invoice for the portfolio.
+export function applyLateFees(invoices: Invoice[], today: Date): Invoice[] {
+  for (const inv of invoices) {
+    const fee = computeLateFee(inv, today);
+    if (fee > 0) {
+      inv.balance += fee;
+    }
+  }
+  return invoices;
+}

package/packs/dev-team/skills/release-notes/evals/evals.json

@@ -43,6 +43,35 @@
         "It does not invent dates, PR numbers, a commit count for commits it was not shown, or features not in the pasted list",
         "It delivers usable release notes in the reply rather than only asking questions, and lists the items that need confirming before sending"
       ]
+    },
+    {
+      "id": 4,
+      "held_out": "2026-10-06",
+      "prompt": "Portside WMS 5.0.0 goes out to customers on Thursday. The log since 4.9.2 is in git-log.txt. Two things please: (1) upgrade notes for admins. Our customers run Portside on their own servers, so their IT people need to know what to do before they upgrade. (2) A short paragraph for the customer newsletter, three or four sentences. Sales want the newsletter to lead with batch scanning and to say the duplicate pick list problem is finally fixed. Also remind people that 4.x support ends on 31 December.",
+      "assertions": [
+        "The PostgreSQL 15+ requirement is called out as something admins must deal with before upgrading (the installer aborts on PostgreSQL 13 and 14), even though its commit is labelled chore",
+        "The removal of /api/v1/stock is called out as a breaking change with /api/v2/stock-levels as the replacement, and the breaking items come before the new features in the admin notes",
+        "Batch scanning is described as off by default (flag scan.batch.enabled, missed reads on older handhelds), not as a feature that works out of the box after upgrading",
+        "The duplicate pick list problem is not described as fully fixed; the output says split shipments can still produce a duplicate line (#1893) or flags that the 'finally fixed' claim is not supported by the log",
+        "The end of 4.x maintenance is given as 31 March 2027, or the conflict between the requested 31 December date and the log is flagged; 31 December is not repeated as fact",
+        "The wms.mail.host to wms.smtp.host rename is described as a deprecation where the old key still works, not as a change that breaks existing configuration on upgrade",
+        "The admin notes include the security fix for session tokens not being invalidated on password change (LSA-2026-04)",
+        "The newsletter paragraph does not mention the spring-boot bump, the StockLedger refactor or the CI test shards"
+      ]
+    },
+    {
+      "id": 5,
+      "held_out": "2026-10-06",
+      "prompt": "need the what's new text for the app stores for Tallybird 1.6 (habit tracker, it's just me and Sam). short, people don't read these. stuff that's in: dark mode, home screen widgets (iOS only i think? Sam would know), fixed the bug where streaks reset if you logged right around midnight, a few crash fixes, Sam did something with sync, and we dropped iOS 15. iOS goes out tomorrow, android build is still stuck in review",
+      "assertions": [
+        "It delivers store text that could be pasted in as it stands, not only a list of questions",
+        "Dark mode and the fix for streaks resetting around midnight both appear in the store text",
+        "The end of iOS 15 support is mentioned in the iOS text or raised explicitly as something users on iOS 15 need to be told",
+        "Widgets are not promised to Android users; the output flags that whether widgets are iOS-only needs confirming with Sam, or gives separate iOS and Android text with widgets only in the iOS one",
+        "The sync change is not described as a specific improvement (such as faster or more reliable sync); it is left out or flagged as needing detail from Sam",
+        "It does not invent crash counts, percentages, a release date for Android, or features that are not in the list",
+        "The store text itself is short: about 100 words or fewer per store"
+      ]
     }
   ]
 }

package/packs/dev-team/skills/release-notes/evals/files/4/git-log.txt

@@ -0,0 +1,26 @@
+# git log v4.9.2..v5.0.0-rc2 (oldest first) -- Portside WMS
+9c1e4a7 2026-07-14 feat(picking): wave planning screen groups orders by carrier cutoff (#1802)
+b3d0f52 2026-07-16 fix(receiving): ASN import rejects files that start with a BOM (#1809)
+4e7a918 2026-07-21 chore(deps): bump spring-boot 3.2.5 -> 3.3.2
+a80c3de 2026-07-23 feat(scan): batch barcode scan mode for handhelds (#1777)
+17f6b0c 2026-07-28 chore(db): migrations now use MERGE; requires PostgreSQL 15+ (#1815)
+    Installer aborts on PostgreSQL 13 and 14. 4.x supported 13+.
+d52e9a1 2026-07-30 fix(labels): ZPL label truncates SKUs longer than 20 characters (#1821)
+6fa23c8 2026-08-04 refactor(inventory): split StockLedger into reader and writer
+e19b7d4 2026-08-06 feat(api): /api/v2/stock-levels endpoint with pagination (#1790)
+0b4c8f1 2026-08-11 fix(picking): dedupe pick lists on wave release (#1833)
+    Partial. Split shipments can still produce a duplicate line, tracked in #1893.
+c7719ae 2026-08-13 perf(reports): stock valuation report at 500k SKUs: 212s -> 58s (#1840)
+83ad5e0 2026-08-18 feat(scan): put batch scan behind flag scan.batch.enabled, default false (#1848)
+    Field test at the pilot site showed missed reads on older handhelds.
+    Stays off by default until #1851 is fixed.
+f2061bb 2026-08-20 security: session tokens were not invalidated on password change (LSA-2026-04) (#1852)
+5d9e3c0 2026-08-25 docs: 4.x maintenance ends 2027-03-31 (was 2026-12-31) (#1856)
+a1f47e2 2026-08-27 feat(api)!: remove /api/v1/stock (deprecated since 4.6); use /api/v2/stock-levels (#1858)
+39b8d6f 2026-09-01 ci: split integration tests into 4 shards
+7c40e95 2026-09-03 fix: tweaks
+e6d1a07 2026-09-08 feat(config): rename wms.mail.host to wms.smtp.host (#1866)
+    Old key is still read and logs a deprecation warning. Removal planned for 6.0.
+2ab95f3 2026-09-10 fix(receiving): putaway suggestion ignored the bin weight limit (#1870)
+b90c7e8 2026-09-15 feat(ui): Polish translation of the handheld screens (#1874)
+d07a3b6 2026-09-22 fix(installer): upgrade from 4.9.x failed when the backup directory was a symlink (#1881)

package/packs/research/skills/source-synthesis/evals/evals.json

@@ -44,6 +44,36 @@
         "It says five conversations are too few to set a price or to conclude that cafe owners want it, and gives any price suggestion as tentative",
         "It does not add market figures, competitor prices or cafe-industry facts that are not in the notes"
       ]
+    },
+    {
+      "id": 4,
+      "held_out": "2026-10-06",
+      "prompt": "I'm the governance officer at Marlowe Vale Academy Trust (9 secondary schools). Next month the board decides whether to roll the phone-pouch scheme out from the two pilot schools to all nine. Everything we've got is in this folder: pilot-report.md, behaviour-logs.md, teacher-focus-group.md, parent-survey.md and vendor-brochure.md. Can you pull together what the evidence actually shows? Two pages max, it's going in the board pack. They'll particularly want to know what it did to behaviour and to exam results.",
+      "assertions": [
+        "It states that logged incidents at Fenwick Park rose from 280 to 291, which contradicts the pilot report's statement that incidents fell at both schools",
+        "It says Ashcombe's fall from 412 to 318 cannot be credited to the pouches because the logging system changed on 5 January 2026 and stopped counting low-level disruption, which was 96 of the 412 the year before",
+        "It traces the 40% reduction figure to the vendor brochure's footnote (a 2019 study of three New Zealand schools commissioned by the vendor) and does not count the pilot report's repetition of it as separate evidence",
+        "It corrects the parent survey response rate: 1,140 out of 3,050 is about 37%, not 47%",
+        "On exam results it says the sources contain no attainment data (the pilot report says results were not analysed and the brochure's 'improves grades' has no source), and it gives no estimated effect on results",
+        "It reports that phone confiscations fell at both schools (87 to 9 at Ashcombe, 64 to 22 at Fenwick Park) as the clearest measured change",
+        "It notes the teacher focus group was six teachers all from Ashcombe, with none from Fenwick Park, and reports the drawbacks they raised (for example ten minutes lost at form time or pupils pouching a dummy phone), not only the positive view in the pilot report",
+        "It does not bring in research, statistics or claims about phones in schools that are not in the five files"
+      ]
+    },
+    {
+      "id": 5,
+      "held_out": "2026-10-06",
+      "prompt": "I'm on the committee for our village hall and the boiler is on its last legs. We're arguing about whether to get a heat pump instead. This is everything I've collected, sorry it's a bit scrappy:\n\n- Quote from Fernbrook Renewables: £14,200 to fit an air source heat pump. They only do heat pumps. The chap reckoned a new gas boiler would be 'about £4,100' but that's not a quote, he doesn't fit them.\n- Spoke to the treasurer at Little Aldwick hall, they got a heat pump in 2024. She said their bills 'went down about a third'. They also had the roof insulated the same year.\n- Cut a paragraph out of a magazine a while ago, no idea which one or when: 'heat pumps are three to four times as efficient as gas boilers'.\n- I think there's a grant, up to £7,500? Read it somewhere. Not sure village halls can get it.\n- We spent about £2,300 on gas last year I think. Hall's in use maybe 4 days a week.\n\nCan you pull together what we actually know? Mainly: would a heat pump be cheaper to run?",
+      "assertions": [
+        "It delivers the write-up from the notes as given and does not stop to ask for more information first",
+        "It says the notes cannot answer whether a heat pump would be cheaper to run, because they contain no electricity or gas prices and no running-cost estimate for this hall, and it states no annual saving as fact",
+        "It says Little Aldwick's bills falling by about a third cannot be put down to the heat pump alone because the roof was insulated in the same year",
+        "It says the 'three to four times as efficient' line is about efficiency, not running cost, and comes from an undated cutting from an unknown magazine",
+        "The grant is treated as unconfirmed on both the amount and whether a village hall qualifies, and the £7,500 is not subtracted from the cost as if it were secured",
+        "It notes that the £4,100 boiler figure is an offhand estimate from an installer who only fits heat pumps, not a quote",
+        "It gives the up-front gap as about £10,100 (£14,200 against about £4,100)",
+        "It does not add energy prices, grant scheme rules or typical heat pump costs from outside the notes, unless clearly labelled as not coming from the notes"
+      ]
     }
   ]
 }

package/packs/research/skills/source-synthesis/evals/files/4/behaviour-logs.md

@@ -0,0 +1,31 @@
+# Behaviour logs: pilot schools
+
+Extract by the trust data team, 9 July 2026. Counts of logged behaviour incidents per term.
+
+## Ashcombe School (1,620 pupils)
+
+| Year | Autumn | Spring | Summer | Total |
+|---|---|---|---|---|
+| 2024-25 (before pilot) | 150 | 138 | 124 | 412 |
+| 2025-26 (pilot year) | 141 | 92 | 85 | 318 |
+
+Note: on 5 January 2026 Ashcombe moved from the old paper-and-spreadsheet log to ClassLedger. Under ClassLedger, "low-level disruption" is recorded as a classroom note and is no longer logged as an incident. In 2024-25, low-level disruption accounted for 96 of Ashcombe's 412 incidents.
+
+## Fenwick Park School (1,430 pupils)
+
+| Year | Autumn | Spring | Summer | Total |
+|---|---|---|---|---|
+| 2024-25 (before pilot) | 98 | 94 | 88 | 280 |
+| 2025-26 (pilot year) | 101 | 97 | 93 | 291 |
+
+Note: no change to the logging system at Fenwick Park in either year.
+
+## Phone confiscations (both years logged the same way at both schools)
+
+| School | 2024-25 | 2025-26 |
+|---|---|---|
+| Ashcombe | 87 | 9 |
+| Fenwick Park | 64 | 22 |
+
+## Not available
+No behaviour extract was requested for the seven schools outside the pilot.