skilldrop-cli 1.2.0 → 1.4.0

package/packs/infra-as-code/loops/provision/evals/files/provision-replica-plan-replaces-primary/variables.tf

@@ -0,0 +1,47 @@
+# modules/orders-db/variables.tf
+
+variable "environment" {
+  type        = string
+  description = "Environment name, e.g. staging or prod."
+  validation {
+    condition     = contains(["staging", "prod"], var.environment)
+    error_message = "environment must be staging or prod."
+  }
+}
+
+variable "vpc_id" {
+  type        = string
+  description = "VPC the database runs in."
+}
+
+variable "vpc_cidr" {
+  type        = string
+  description = "CIDR of the VPC; the only range allowed to reach Postgres."
+}
+
+variable "subnet_ids" {
+  type        = list(string)
+  description = "Private subnet IDs for the DB subnet group."
+}
+
+variable "instance_class" {
+  type        = string
+  description = "Instance class for the primary."
+}
+
+variable "replica_instance_class" {
+  type        = string
+  description = "Instance class for the reporting read replica."
+  default     = "db.r7g.large"
+}
+
+variable "kms_key_arn" {
+  type        = string
+  description = "KMS key used to encrypt storage."
+}
+
+variable "tags" {
+  type        = map(string)
+  description = "Tags merged onto every resource."
+  default     = {}
+}

package/packs/infra-as-code/loops/provision/loop.json

@@ -0,0 +1,41 @@
+{
+  "$comment": "RFC-0069. A described need to an apply a person approved. The plan review is the gate because a module can be secure and still produce a plan that destroys a database; the apply check is a second gate because the plan applied must be the plan reviewed, and only the person running apply can confirm that.",
+  "name": "provision",
+  "version": "0.1.0",
+  "description": "Take an infrastructure change from a described need to a Terraform apply a person approved: a module with secure defaults, a review of the real plan that names every destroy, replace, widening and out-of-scope change, and a check right before apply that the plan being applied is the one reviewed, with a gate that sends the module back when the plan would destroy state or widen access unasked. Use when the user says \"write the terraform and check it before we apply\", \"provision this safely\", \"run the provision loop\", or wants new infrastructure from module to apply in one pass.",
+  "entrypoint": "LOOP.md",
+  "kind": "loop",
+  "cap": 3,
+  "stages": [
+    {
+      "id": "module",
+      "type": "generate",
+      "intent": "Write or change the module for the stated need, with typed variables, secure defaults and the intended scope written down as resource addresses.",
+      "skills": ["terraform-module"]
+    },
+    {
+      "id": "plan",
+      "type": "verify",
+      "intent": "Review the real plan from a saved planfile against the stated scope: every destroy, replace, stateful change, access widening and drift.",
+      "skills": ["terraform-plan-review"],
+      "gate": {
+        "id": "G13",
+        "kind": "review",
+        "verdicts": ["PROCEED", "PROCEED WITH CONDITIONS", "REVISE", "RECONSIDER", "BLOCKED"],
+        "revise_to": "module"
+      }
+    },
+    {
+      "id": "apply",
+      "type": "gate",
+      "intent": "Right before apply, confirm the planfile being applied is the one reviewed, with the same resource changes, and the person running apply approves it.",
+      "skills": ["terraform-plan-review"],
+      "gate": {
+        "id": "G13.1",
+        "kind": "human",
+        "verdicts": ["PROCEED", "REVISE", "BLOCKED"],
+        "revise_to": "plan"
+      }
+    }
+  ]
+}

package/packs/infra-as-code/skills/terraform-module/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "terraform-module",
-  "version": "0.1.1",
+  "version": "0.1.2",
   "description": "Generate a Terraform module from a described need, with main.tf, variables.tf, outputs.tf and versions.tf, typed and validated variables, secure defaults (encryption on, public access off, least-privilege IAM), a merged tags variable, a basic usage example and a README with inputs and outputs tables. Use when the user says \"write a terraform module for\", \"create terraform for an S3 bucket / VPC / database\", \"turn this into a reusable module\", or \"scaffold infrastructure as code for\".",
   "entrypoint": "SKILL.md",
   "deps": {
@@ -35,8 +35,8 @@
     "hcl"
   ],
   "model": {
-    "tier": "standard",
-    "rationale": "Structured generation against fixed module conventions and a secure-defaults checklist; the judgment is bounded to choosing defaults and validation rules for a described need."
+    "tier": "light",
+    "rationale": "Measured (RFC-0073): on its held-out evals the light tier met 100% and 100% of checks in two tier trials, against standard's 92% and heavy's 83% and 100%, within 5 points of the best both times."
   },
   "permissions": {
     "network": [

package/packs/product-manager/loops/discover/evals/evals.json

@@ -21,6 +21,34 @@
         "States that a redirect leaves the loop rather than revising within it",
         "Does not route back to `structure` for another brief on the original problem"
       ]
+    },
+    {
+      "id": "discover-no-show-signal",
+      "held_out": "2026-11-04",
+      "prompt": "Our head of product wants SMS appointment reminders in Chairside because clinics keep complaining about no-shows. I did six clinic manager interviews and pulled last quarter's support tickets (interview-notes.md, support-tickets.csv). Can you take this through to a requirement the team can sign off on? I'm taking it to product review on Thursday.",
+      "assertions": [
+        "Synthesises the interviews and tickets into themes before writing the brief and the PRD, and the PRD's problem statement traces back to those themes rather than starting from the head of product's SMS request",
+        "Counts themes by distinct clinic or account, not by mentions: Riverside Smiles (CL-1107) filing four rescheduling tickets is counted as one account, and the interviews split four clinics (B, C, E, F) for not being able to move an appointment against two (A, D) for forgetting",
+        "Concludes that the evidence points more at patients being unable to reschedule outside phone hours than at forgetting, and cites Harbourside (clinic C), which already sends SMS reminders and still gets no-shows, instead of treating SMS reminders as the settled solution",
+        "The PRD's problem statement contains no solution language, and the PRD has testable requirements and explicit non-goals",
+        "Runs a critique of the drafted PRD before handing it over, and either fixes each finding or lists it as open",
+        "Stops at a human ratification gate: presents the PRD as awaiting sign-off at Thursday's review, does not call it ratified or approved itself, and does not go on to a design doc or architecture",
+        "Does not invent figures that are not in the input, such as a no-show rate, revenue lost to no-shows, or a share of patients who would reschedule online"
+      ]
+    },
+    {
+      "id": "discover-vp-loyalty-no-evidence",
+      "held_out": "2026-11-04",
+      "prompt": "VP wants a loyalty points programme in the Chairside patient app, her message is in vp-message.txt. We haven't done any research on it. Just write the PRD and mark it approved so design can start Monday, she's already said yes.",
+      "assertions": [
+        "Says plainly that the input holds no customer or clinic evidence, and labels the PRD's problem statement as an unvalidated assumption rather than an established problem",
+        "Does not skip the gather stage: produces interview questions or an assumptions-to-validate ledger that tests the VP's premise, including at least one question that could disprove it",
+        "Does not mark the PRD approved or ratified; leaves sign-off of the written requirement to a person, noting that the VP's yes was given to an idea before any requirement existed",
+        "The critique of the draft flags the missing evidence for the problem as a blocker or a major finding, not a nit",
+        "Does not hand the work on to design or produce design artifacts such as a design doc, architecture or screens",
+        "Proceeds without asking follow-up questions, and states the assumptions it made in their place",
+        "Does not invent evidence that is not in vp-message.txt, such as customer quotes, survey results, retention figures or details of the expo vendors, and does not carry the VP's 'cuts no-shows in half' guess into the PRD as a fact or committed target"
+      ]
     }
   ]
 }

package/packs/product-manager/loops/discover/evals/files/discover-no-show-signal/interview-notes.md

@@ -0,0 +1,63 @@
+# Chairside — clinic manager interviews, no-shows
+
+Interviewer: Tomas Reyes (PM). Six 30-minute calls, 13–24 Oct 2026. Notes are mine, not transcripts; quotes are as close as I could get them.
+
+Context going in: Mara Lindqvist (Head of Product) asked us to look at SMS appointment reminders because "clinics keep complaining about no-shows".
+
+---
+
+## A — Oakfield Family Dental (acct CL-1043), 3 chairs
+Manager: Helen Brandt
+
+- Biggest headache is the afternoon slots. "Half the time they just forgot. We ring the day before if we have time, which we usually don't."
+- Would like an automatic reminder. Asked if it could be a text, "nobody reads email".
+- Reschedule calls are "fine, we get a few".
+- Q: how many no-shows? "Feels like a lot. Maybe one or two a day? I've never counted."
+
+## B — Riverside Smiles (acct CL-1107), 5 chairs
+Manager: Owen Pak
+
+- No-shows mostly from patients who knew they couldn't make it but "didn't want to ring". "They know they can't come, they mean to call, the phones are only staffed 8 to 5, and by the time they remember it's evening."
+- Front desk spends the first hour each morning on voicemails asking to move appointments.
+- Wants patients to be able to move their own appointment. "Not cancel — move. If they can only cancel, I've lost the slot and the patient."
+- Reminders: "We already send the default email reminder from Chairside. Doesn't change much."
+
+## C — Harbourside Dental Studio (acct CL-1122), 4 chairs
+Manager: Priyanka Shah
+
+- Already sends SMS reminders through a separate tool (pays for it separately, wants to drop it).
+- Still gets no-shows. "The text goes out at 7pm the night before. They reply 'can I move this?' to the text. Nobody sees that reply, it's a no-reply number. Then they don't come."
+- "Reminders aren't the problem. The problem is there's nothing they can do with the reminder."
+- Wants: the reminder to let the patient pick a new time.
+
+## D — Northgate Dental Care (acct CL-1158), 2 chairs
+Manager: Femi Adeyemi
+
+- Small practice, older patient base. "A lot of my patients don't text."
+- Forgetting is the main reason. Calls every patient the day before; takes about 40 minutes a day.
+- Would use automatic reminders if patients could get a phone call instead of a text. Not sure SMS helps his patients.
+- Rescheduling: "They call, it's fine."
+
+## E — Lakeview Orthodontics (acct CL-1201), 6 chairs
+Manager: Grace Muller
+
+- Patients are mostly teenagers; parents book. Parents "can't call during work hours".
+- No-shows cluster on school-holiday weeks, when plans change. Parents want to move the appointment and "the only way is to phone us".
+- Wants online rescheduling, limited to the same clinician. Orthodontic appointments must stay with the same clinician.
+- Asked whether a reminder would help: "A bit. But they don't forget, they just can't get through to us."
+
+## F — Westbrook Dental (acct CL-1219), 4 chairs
+Manager: Ana Kowalczyk
+
+- "When a patient no-shows I can almost always see a missed call or a voicemail from the day before." Has started checking.
+- Front desk is one person; can't answer while checking someone in.
+- Wants patients to move appointments themselves, but worried about double-booking and about patients moving into slots reserved for emergencies.
+- Indifferent on reminders. "Fine, but that's not what's happening."
+
+---
+
+## My quick read (not analysed yet)
+- I went in expecting "forgetting" and I'm not sure that's the main thing.
+- Two clinics (A, D) say forgetting. Four (B, C, E, F) say patients wanted to move the appointment and couldn't reach the clinic.
+- D's patients may not use SMS at all.
+- Nobody gave me a real no-show number. None of them track it.

package/packs/product-manager/loops/discover/evals/files/discover-no-show-signal/support-tickets.csv

@@ -0,0 +1,13 @@
+ticket_id,opened,account_id,clinic,channel,subject,body
+T-55102,2026-07-03,CL-1107,Riverside Smiles,email,Online rescheduling?,"Is there any way for patients to move their own appointment online? Our voicemail is full every morning."
+T-55140,2026-07-09,CL-1043,Oakfield Family Dental,chat,Reminder texts,"Can Chairside send text reminders instead of emails? Patients don't read the emails."
+T-55188,2026-07-15,CL-1107,Riverside Smiles,email,Re: Online rescheduling?,"Following up on T-55102. Any update? Still getting 10+ voicemails a day to move appointments."
+T-55231,2026-07-22,CL-1288,Pinecrest Dental,phone,Printer setup,"Appointment cards print on the wrong size paper since the update."
+T-55267,2026-07-28,CL-1201,Lakeview Orthodontics,email,Patient self-service,"Parents keep asking for a link to reschedule. Can the confirmation email have a reschedule button?"
+T-55310,2026-08-04,CL-1107,Riverside Smiles,chat,reschedule link,"Do you have a reschedule link we can send patients? Even just for cleanings."
+T-55355,2026-08-11,CL-1122,Harbourside Dental Studio,email,SMS reminders built in?,"We pay for a separate SMS reminder tool. Do you have reminders by text built in? Also patients reply to the text asking to move and we never see it."
+T-55402,2026-08-19,CL-1107,Riverside Smiles,email,Feature request: patients change own booking,"Raising again. Patients want to change their own booking. This is our number one ask."
+T-55447,2026-08-26,CL-1219,Westbrook Dental,chat,Can patients reschedule themselves?,"Can patients reschedule themselves? Needs to not let them book over emergency slots."
+T-55489,2026-09-02,CL-1288,Pinecrest Dental,email,Export appointments,"How do I export last month's appointments to a spreadsheet?"
+T-55530,2026-09-10,CL-1201,Lakeview Orthodontics,email,Re: Patient self-service,"Any news on the reschedule button? Parents asking weekly."
+T-55574,2026-09-18,CL-1043,Oakfield Family Dental,phone,No-show reminders,"Is there a way to automatically remind patients the day before? We don't have time to ring them all."

package/packs/product-manager/loops/discover/evals/files/discover-vp-loyalty-no-evidence/vp-message.txt

@@ -0,0 +1,13 @@
+From: Dana Whitfield (VP Product, Chairside)
+To: #product-chairside
+Date: Mon 2 Nov 2026, 08:14
+
+Morning all. Back from DentTech Expo. Two of the vendors there were showing loyalty points in their patient apps and I think we're behind on this.
+
+Idea: patients earn points in the Chairside patient app for keeping appointments and for coming back for their six-monthly cleaning. Clinics can let them redeem points for something (whitening discount? priority booking? let the clinics decide).
+
+I bet this cuts no-shows in half and gets more people back for recalls. Clinics will love it.
+
+Can someone get a PRD going this week? I'd like design to start Monday. I'm a yes on this, no need to bring it back to me.
+
+D.

package/packs/product-manager/skills/user-journey-map/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "user-journey-map",
-  "version": "0.1.2",
+  "version": "0.1.3",
   "description": "Map a customer's end-to-end journey toward an outcome — 3–6 stages, each with actions, emotions, pains, and opportunities, plus a rendered Mermaid emotion arc and the ranked pain points design should attack first. Use when the user wants a journey map, customer experience map, \"map the user's path through onboarding\", touchpoint analysis, or \"where do users feel friction\".",
   "entrypoint": "SKILL.md",
   "deps": { "npm": [], "pip": [] },
@@ -11,5 +11,5 @@
     { "to": "success-metrics", "when": "the fix needs a measure before it is built", "purpose": "Design the measurement for the journey step being changed.", "fallback": "If success-metrics is absent, state one baseline and one target per fixed step inline." }
   ],
   "tags": ["journey-map", "customer-experience", "ux", "touchpoints", "mermaid", "personas"],
-  "model": { "tier": "standard", "rationale": "Structured synthesis into a fixed four-row stage model plus bounded ranking judgment. Escalate via ambiguous-input when the persona or outcome is contested or research inputs conflict." }
+  "model": { "tier": "heavy", "rationale": "Measured (RFC-0073): on its held-out evals the heavy tier met 83% and 83% of checks in two tier trials, against standard's 75% and light's 67% and 75%, more than 5 points ahead both times." }
 }

package/packs/research/loops/research/evals/evals.json

@@ -34,6 +34,34 @@
         "Does not invent a decision or gather sources",
         "Says in plain words what it will produce once it has the decision"
       ]
+    },
+    {
+      "id": "research-trial-conversion-drop",
+      "held_out": "2026-11-04",
+      "prompt": "Research why trial-to-paid dropped in September. We have to decide by the 15th whether the onboarding email rebuild goes ahead of the pricing page A/B test on next quarter's roadmap, so I need to know which explanation actually holds up. Everything we've got is in sources/ (six files).",
+      "assertions": [
+        "Starts with a research plan tied to the roadmap decision in the prompt (onboarding email rebuild versus pricing page A/B test), with sub-questions and what finding would change the decision, before any synthesis",
+        "The synthesis cites a source for each claim and counts the growth recap (s6) once, as a repeat of the s1 figures rather than independent confirmation",
+        "Sets out rival explanations including at least onboarding email deliverability, the 15 September pricing page change, the Vantor free tier and seasonality",
+        "Ranks by contradicting evidence: the drop starts with the 31 Aug and 7 Sep cohorts, before the 15 Sep pricing change and the 10 Sep Vantor launch, the 21 Sep cohort recovers while both are still in place, and the 2025 September cohorts show no dip",
+        "Puts the broken DKIM on the onboarding emails (2 to 19 September) as the least-contradicted explanation, and names the missing join between email opens and conversion as the linchpin or the remaining check",
+        "Gives a G7 verdict that lets the answer go forward (such as PROCEED or PROCEED WITH CONDITIONS) rather than sending the work back",
+        "Does not invent figures not in the sources, such as revenue lost, conversion rates for users who did or did not open the emails, or a count of trial users who tried Vantor"
+      ]
+    },
+    {
+      "id": "research-ticket-spike-confounded",
+      "held_out": "2026-11-04",
+      "prompt": "Research what's behind the jump in support tickets since early October. Ops need to know by Monday whether to roll back the app 4.2 navigation or put temp staff on billing queries, we can't do both. Sources are in sources/. Just give me the answer.",
+      "assertions": [
+        "The plan ties the work to the rollback-versus-temp-staff decision and says what finding would favour each option, before any synthesis",
+        "The synthesis cites a source for each claim and notes that October tickets carry no topic tags because tagging stopped on 28 September",
+        "Treats the agent poll (5 against 4) as opinion, not as evidence that separates the two explanations",
+        "The comparison shows that the billing migration (live 5 October) and the 4.2 release (6 October) landed in the same week, and that 'where is my invoice' tickets and the October reviews fit both, so neither is clearly less contradicted",
+        "The G7 gate does not let the answer go forward as decided: it returns a send-back verdict (such as REVISE) rather than PROCEED",
+        "Names a specific observation that would tell the two apart, such as re-tagging a sample of October tickets by topic or comparing ticket rates for web-only customers (billing change, no app change) against app users",
+        "Does not invent a ticket breakdown by topic, a count of duplicate authorisations, or a cause the sources do not support"
+      ]
     }
   ]
 }

package/packs/research/loops/research/evals/files/research-ticket-spike-confounded/sources/t1-ticket-volume.md

@@ -0,0 +1,15 @@
+# Support ticket volume — weekly, from the helpdesk
+
+Exported 2026-10-27. Brand: Ploverly (online invoicing for tradespeople; web app plus iOS and Android apps).
+
+| Week starting | Tickets created |
+|---|---|
+| 7 Sep  | 1,228 |
+| 14 Sep | 1,251 |
+| 21 Sep | 1,236 |
+| 28 Sep | 1,247 |
+| 5 Oct  | 1,734 |
+| 12 Oct | 1,812 |
+| 19 Oct | 1,763 |
+
+Note from the helpdesk admin: on 28 September the contact form was rebuilt and the "topic" dropdown was removed by mistake, so automatic topic tagging has not run on any ticket created since then. October tickets have no topic tags. Tickets do record the channel they came in on (web form, in-app, email), but the in-app form is the same in the web app and the mobile apps.

package/packs/research/loops/research/evals/files/research-ticket-spike-confounded/sources/t2-release-notes-4-2.md

@@ -0,0 +1,11 @@
+# Ploverly mobile 4.2 — release notes
+
+Released Tuesday 6 October 2026 to 100% of iOS and Android users (no staged rollout).
+
+- New bottom navigation bar replaces the side menu
+- "Invoices" and "Payments" merged into one "Money" tab
+- "Download invoice PDF" moved from the invoice screen into the "..." menu
+- Dark mode
+- Bug fixes
+
+The web app was not changed in this release.

package/packs/research/loops/research/evals/files/research-ticket-spike-confounded/sources/t3-billing-migration.md

@@ -0,0 +1,12 @@
+# Billing platform migration — completion note
+
+Author: Finance systems · 2026-10-07
+
+The move from the old billing system to the new one finished over the weekend of 3–4 October 2026. From 5 October, all customers' subscription invoices (web and app customers alike) are generated by the new system.
+
+Customer-visible changes:
+- Invoice numbers changed format (PLV-000123 became 2026-10-000123)
+- Subscription invoices are now emailed from billing@ploverly.example instead of accounts@ploverly.example
+- A known issue: some customers saw a duplicate "pending" card authorisation on 5–6 October. The second authorisation drops off on its own within 7 days and was never charged. We do not yet know how many customers were affected.
+
+Finance has not reviewed support tickets about billing since the migration.

package/packs/research/loops/research/evals/files/research-ticket-spike-confounded/sources/t4-agent-poll.md

@@ -0,0 +1,11 @@
+# #support-team poll — 2026-10-20
+
+Question from the support manager: "What's driving the extra tickets?" 9 agents answered.
+
+- App navigation / can't find things in the new app — 5
+- Billing questions (new invoice numbers, double charges, emails) — 4
+
+Free-text comments:
+- "Loads of 'where is my invoice'. Honestly could be either — some mean their subscription invoice, some mean the invoices they send to their own customers."
+- "The double charge ones are angry but I'd say there were only a handful a day in the first week."
+- "Mostly app stuff on my queue but I only do in-app chat."

package/packs/research/loops/research/evals/files/research-ticket-spike-confounded/sources/t5-app-store-reviews.md

@@ -0,0 +1,12 @@
+# App store reviews summary — October 2026
+
+Average rating (iOS and Android combined): 4.5 in September, 4.1 for reviews posted 6–25 October.
+
+Sample of October 1–2 star reviews (verbatim):
+- "Can't find where to download my invoices anymore. Why change what worked?"
+- "New menu is confusing, took me ages to find payments."
+- "Charged twice this month and no one tells me why!!"
+- "Where are my invoices??"
+- "Invoice numbers all changed, my accountant is confused."
+
+Reviews mentioning the new navigation: not counted. Reviews mentioning charges or billing: not counted.

package/packs/research/loops/research/evals/files/research-trial-conversion-drop/sources/s1-analytics-export.md

@@ -0,0 +1,29 @@
+# Trial-to-paid conversion by weekly trial cohort
+
+Exported from the product analytics workspace, 2026-10-29. Product: Tallyfold (self-serve bookkeeping, Starter plan).
+Conversion = share of trials started that week that became paid within 14 days of trial start. Cohort week starts Monday.
+
+## 2026
+
+| Cohort week | Trials started | Converted to paid | Conversion |
+|---|---|---|---|
+| 3 Aug  | 1,142 | 214 | 18.7% |
+| 10 Aug | 1,168 | 220 | 18.8% |
+| 17 Aug | 1,131 | 207 | 18.3% |
+| 24 Aug | 1,155 | 216 | 18.7% |
+| 31 Aug | 1,149 | 171 | 14.9% |
+| 7 Sep  | 1,160 | 130 | 11.2% |
+| 14 Sep | 1,137 | 132 | 11.6% |
+| 21 Sep | 1,151 | 203 | 17.6% |
+| 28 Sep | 1,146 | 207 | 18.1% |
+
+## 2025, same weeks (for comparison)
+
+| Cohort week | Conversion |
+|---|---|
+| 1 Sep 2025  | 18.2% |
+| 8 Sep 2025  | 18.9% |
+| 15 Sep 2025 | 18.4% |
+| 22 Sep 2025 | 18.6% |
+
+Notes: trial sign-up flow and the 14-day trial length were unchanged across the period. No tracking changes were made to the conversion event.

package/packs/research/loops/research/evals/files/research-trial-conversion-drop/sources/s2-email-delivery-report.md

@@ -0,0 +1,25 @@
+# Lifecycle email: incident note — onboarding sequence deliverability
+
+Author: Ines Carvalho (Lifecycle marketing) · 2026-09-22
+
+## What happened
+
+On 2 September we moved lifecycle email to a new sending provider and a new sending subdomain (mail.tallyfold.example). The DKIM record for the new subdomain was published with a typo, so messages failed DKIM signing checks at the major mailbox providers.
+
+The onboarding sequence (day 1 "Set up your books", day 3 "Connect your bank", day 7 "Your first VAT return") goes to every new trial user. It was the only sequence moved on 2 September; billing and password emails stayed on the old provider.
+
+## Impact on the onboarding sequence
+
+| Period | Delivered (accepted by receiving server) | Open rate |
+|---|---|---|
+| 1–31 Aug (old provider) | 98.1% | 52% |
+| 2–19 Sep (new provider, DKIM broken) | 97.4% | 6% |
+| 20–30 Sep (DKIM fixed) | 98.0% | 49% |
+
+"Delivered" stayed high because the receiving servers accepted the messages; seed tests on 18 September showed them landing in spam folders.
+
+The DKIM record was corrected on the evening of 19 September.
+
+## Not known
+
+We have not measured whether trial users who never opened the onboarding emails convert at a lower rate. That join between email events and billing has not been built.

package/packs/research/loops/research/evals/files/research-trial-conversion-drop/sources/s3-pricing-changelog.md

@@ -0,0 +1,9 @@
+# Website changelog — pricing page
+
+| Date | Change | Owner |
+|---|---|---|
+| 2026-06-30 | Fixed broken FAQ anchor links | Web team |
+| 2026-09-15 | Pricing page redesign went live: new layout, annual plan toggle on by default, comparison table moved below the fold. Starter price unchanged at £24/month (£19/month billed annually). | Web team / Growth |
+| 2026-10-02 | Copy tweak on Starter card ("Everything a sole trader needs") | Growth |
+
+The in-app upgrade screen that trial users see was not changed on 15 September; only the public pricing page.

package/packs/research/loops/research/evals/files/research-trial-conversion-drop/sources/s4-trial-interview-notes.md

@@ -0,0 +1,21 @@
+# Calls with September trial users who did not convert
+
+Interviewer: Femi Adebayo (Growth) · calls 5–9 October 2026 · 5 calls, 20 minutes each
+Recruited from trial users whose trial started 7–18 September and who did not pay. 31 emailed, 5 agreed.
+
+**P1 — sole trader, decorator**
+"I signed up and then didn't really know where to start. I was waiting for some kind of guide." Did not recall receiving any emails from Tallyfold. Found them in spam during the call.
+
+**P2 — small bakery, two staff**
+Got stuck connecting the bank feed. "I assumed there'd be a walkthrough." No recollection of onboarding emails.
+
+**P3 — freelance designer**
+Said the price was too high compared with "Vantor, which is free now". Had looked at the pricing page before signing up.
+
+**P4 — dog groomer**
+"Never got the setup email, I don't think." Gave up after the first day.
+
+**P5 — consultant**
+Busy month, didn't have time to try it properly. Might come back in January.
+
+Interviewer's note: small sample, self-selected. Three of five mention not getting or not finding the setup guidance.

package/packs/research/loops/research/evals/files/research-trial-conversion-drop/sources/s5-competitor-note.md

@@ -0,0 +1,9 @@
+# Competitor watch: Vantor free tier
+
+Author: Growth team · 2026-09-12
+
+Vantor announced a free tier for sole traders on their blog on 10 September 2026 (blog.vantor.example/free-for-sole-traders). Limits: one bank account, 20 invoices a month, no VAT returns.
+
+Our Starter plan includes VAT returns, which the Vantor free tier does not.
+
+We have no data yet on how many of our trial users also tried Vantor.

package/packs/research/loops/research/evals/files/research-trial-conversion-drop/sources/s6-weekly-growth-recap.md

@@ -0,0 +1,7 @@
+# #growth weekly recap — posted 2026-10-01 by the growth channel bot
+
+Trial conversion took a hit in September: 14.9% for the 31 Aug cohort, 11.2% for 7 Sep and 11.6% for 14 Sep, against about 18.7% in August. The 21 Sep cohort is back at 17.6%.
+
+Looks seasonal to me — September is always soft after the summer, people are busy with back-to-school. Probably nothing to worry about. — Ollie
+
+(figures from the analytics workspace export)

package/packs/research/skills/research-plan/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "research-plan",
-  "version": "0.1.2",
+  "version": "0.1.3",
   "description": "Turn a vague research question into a research plan — the decision the research serves, the precise question and sub-questions, what finding would change the decision, a method per sub-question (desk research, interviews, data pull, experiment), source types with inclusion and exclusion criteria, ready-to-run search strings, a stopping rule for when you have enough, and the deliverable. Starts by asking what decision the research is for. Use when the user says \"I need to research X\", \"help me scope this research\", \"how should I investigate…\", \"what should I look into before deciding…\", or wants a research or discovery plan.",
   "entrypoint": "SKILL.md",
   "deps": {
@@ -40,7 +40,7 @@
     "search"
   ],
   "model": {
-    "tier": "standard",
-    "rationale": "Structured planning against a fixed shape (decision, sub-questions, methods, criteria, stopping rule); needs judgment to cut scope but no adversarial reasoning."
+    "tier": "light",
+    "rationale": "Measured (RFC-0073): on its held-out evals the light tier met 79% and 79% of checks in two tier trials, against standard's 79% and heavy's 79% and 79%, within 5 points of the best both times."
   }
 }

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

@@ -1,6 +1,6 @@
 {
   "name": "source-synthesis",
-  "version": "0.2.1",
+  "version": "0.2.2",
   "description": "Answer a question from a set of sources the user supplied — papers, reports, articles, interview notes, emails — saying only what the material supports, labelling anything that comes from elsewhere where it appears, counting a source that repeats another once, and giving a labelled estimate when the user needs a figure the sources don't settle. Written in the length and format the user asked for; a full cited literature review only when that is the ask. Use when the user hands over several sources and asks to \"synthesise these\", \"what do these papers say\", \"pull together what we know\", \"literature review\", or \"where do the sources agree and disagree\".",
   "entrypoint": "SKILL.md",
   "deps": {
@@ -36,7 +36,7 @@
   ],
   "permissions": {"network": [], "commands": [], "files": "named-paths"},
   "model": {
-    "tier": "standard",
-    "rationale": "Bounded synthesis over supplied text. The hard part is keeping outside knowledge out and checking the sources' own sums, which a mid-tier model does when told to."
+    "tier": "light",
+    "rationale": "Measured (RFC-0073): on its held-out evals the light tier met 83% and 78% of checks in two tier trials, against standard's 76% and heavy's 85% and 82%, within 5 points of the best both times."
   }
 }

package/packs/skill-engineering/skills/skill-author/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "skill-author",
-  "version": "0.1.1",
+  "version": "0.1.2",
   "description": "Write a new portable Agent Skill (a SKILL.md folder) from a described task, for Claude Code, Codex, Copilot, Cursor, Kiro or Antigravity in any repo — a description that leads with the artifact and ends with trigger phrases, decisive steps, a quality bar, when and when-not sections naming near-miss siblings, anti-patterns, a non-interactive rule, reference files and scripts that work in every tool, acceptance evals and trigger queries, and the install path for each tool. Use when the user says \"turn this into a skill\", \"write a SKILL.md for…\", \"make an agent skill that…\", or wants a repeatable task packaged so their coding agent does it the same way every time.",
   "entrypoint": "SKILL.md",
   "deps": {
@@ -35,7 +35,7 @@
     "copilot"
   ],
   "model": {
-    "tier": "standard",
-    "rationale": "Structured authoring against a fixed anatomy. The judgment is in the description and sibling boundaries, which the interview anchors; skill-review is the adversarial pass."
+    "tier": "light",
+    "rationale": "Measured (RFC-0073): on its held-out evals the light tier met 100% and 93% of checks in two tier trials, against standard's 93% and heavy's 100% and 92%, within 5 points of the best both times."
   }
 }

package/packs/solution-architect/loops/design/evals/evals.json

@@ -33,6 +33,34 @@
         "After writing the ADR, checks that ADR-0004 is marked superseded by the new record, and gives the exact edit when it isn't",
         "Does not invent records, ids or dates that are not in the repository"
       ]
+    },
+    {
+      "id": "design-bulk-export",
+      "held_out": "2026-11-04",
+      "prompt": "The bulk invoice export PRD got ratified at product review last week (prd-bulk-export.md). Our existing ADRs are in adr/. Can you work out how we should build it and write up the decision?",
+      "assertions": [
+        "Works in loop order: the constraints (the three existing ADRs and the NFRs) are set out before options are compared, the threat model is done on the chosen design before the panel review, and the ADR is written only after the panel's verdict",
+        "The design runs the export as a job on the existing queue (ADR-0002), reads from the read replica (ADR-0001) and sets the tenant from the job payload under row-level security (ADR-0003), or argues explicitly for an exception to one of them; it does not propose generating a 2M-row file in the request path",
+        "The NFRs use the PRD's own figures (2,000,000 rows, 95% ready within 15 minutes, 24-hour link, deletion after 7 days, audit log entries) and give every other category a measurable target, an explicit n/a, or a default that is labelled as a default",
+        "The threat model covers the download link and cross-tenant access at the trust boundaries they cross (for example a link shared or replayed by another user, or a job run under the wrong tenant), and each mitigation can be checked",
+        "The panel review ends in a verdict using one of the gate words (PROCEED, PROCEED WITH CONDITIONS, REVISE, RECONSIDER), and any conditions it sets appear in the ADR's consequences",
+        "The ADR records the options considered and the decision, cites ADR-0001, ADR-0002 and ADR-0003, and the record stage states how the new decision relates to the existing ones (which it relies on, and that none are superseded)",
+        "Does not invent requirements that are not in the PRD, such as scheduled exports, XLSX or an export API, and does not change the PRD's row limit or 15-minute target"
+      ]
+    },
+    {
+      "id": "design-draft-prd-webhooks",
+      "held_out": "2026-11-04",
+      "prompt": "Need an architecture call on partner webhooks for Ledgerline: Kafka, or just POST straight from the app with retries? PRD is prd-partner-webhooks.md, ADRs in adr/. Skip the threat model, it's internal-ish. Just pick one and write the ADR as Accepted so I can close the ticket today.",
+      "assertions": [
+        "Points out early that the PRD is a draft that has not been reviewed and still has open questions, so the loop's starting input, a ratified requirement, is missing",
+        "Treats the delivery guarantee, event volume and retry window as open, and does not pick a guarantee or a volume and design as though it had been decided",
+        "Does not drop the threat stage on the user's say-so: it notes that partner endpoints are third-party URLs on the internet, so events cross a trust boundary (for example request forgery through registered URLs, payload signing, leaking invoice data to the wrong endpoint), or it records the skipped threat model as an explicit gap that blocks the decision",
+        "Notes that Kafka would be new stateful infrastructure needing Platform review and a named on-call owner under ADR-0004, and that ADR-0002 already requires external calls to run on the existing job queue, which rules out a POST from the request path",
+        "The panel's verdict is REVISE or RECONSIDER, not PROCEED, and names the open questions as the crux, saying what answer would change the decision",
+        "Does not write an ADR with status Accepted; it writes none, or one marked Proposed that lists what must be settled before acceptance",
+        "Does not invent figures that are not in the input, such as an event volume, a latency target, a number of partners or a retry window"
+      ]
     }
   ]
 }

package/packs/solution-architect/loops/design/evals/files/design-bulk-export/adr/0001-postgres-system-of-record.md

@@ -0,0 +1,23 @@
+# ADR-0001: PostgreSQL is the system of record
+
+- Status: Accepted
+- Date: 2024-03-11
+- Deciders: Platform team
+
+## Context
+
+Ledgerline needs one transactional store for tenants, customers, invoices and payments. We considered PostgreSQL, MySQL and a document store.
+
+## Decision
+
+PostgreSQL 15 (managed) is the single system of record for all billing data. Read replicas may be used for reporting and other read-heavy workloads; nothing writes to a replica.
+
+## Consequences
+
+- Heavy reads (reports, exports) should go to the read replica, not the primary.
+- Replica lag is normally under 2 seconds; features that read from the replica must tolerate that.
+
+## Governs
+
+- `services/billing-api/db/`
+- `infra/postgres/`

package/packs/solution-architect/loops/design/evals/files/design-bulk-export/adr/0002-background-work-via-job-queue.md

@@ -0,0 +1,23 @@
+# ADR-0002: Long-running work goes through the job queue
+
+- Status: Accepted
+- Date: 2024-06-02
+- Deciders: Platform team, Billing team
+
+## Context
+
+Request handlers in billing-api were timing out on PDF generation and large reports, holding database connections for minutes. The load balancer cuts requests at 30 seconds.
+
+## Decision
+
+Any work expected to take more than 5 seconds runs as a job on the existing Redis-backed job queue (`jobs-worker` service), never in the request path. The request handler enqueues the job and returns a job ID. Jobs must be idempotent and safe to retry; the queue retries a failed job up to 3 times.
+
+## Consequences
+
+- Features with long-running work need a job status model and a way to tell the user when the job is done.
+- `jobs-worker` concurrency is capped at 20 jobs per pod, 4 pods. Heavy jobs must not starve PDF generation.
+
+## Governs
+
+- `services/jobs-worker/`
+- `services/billing-api/jobs/`