skilldrop-cli 1.3.0 → 1.4.0

package/packs/dev-team/loops/release/evals/files/release-irreversible-tomorrow/merged-prs.md

@@ -0,0 +1,13 @@
+# Tallyhall — billing provider switch (Corvane Payments -> Haldrin Pay)
+
+Merged to main 2–4 Nov 2026. Not deployed yet. Planned deploy: 5 Nov, 07:00 UTC.
+
+| PR | Title | Author | Notes |
+|---|---|---|---|
+| #840 | Haldrin Pay client and webhook handler | Bea Lindgren | Replaces `CorvaneClient` in `billing/charge.py`. No flag; the switch happens on deploy. |
+| #842 | Token import: load Haldrin token map | Bea Lindgren | Loads Haldrin's import file into `card_token_map (legacy_card_token, provider_token)`. Ran against production on 3 Nov. |
+| #845 | Migration 0061: switch payment_methods to Haldrin tokens | Bea Lindgren | See `0061_switch_to_haldrin_tokens.sql`. Runs as part of the 5 Nov deploy. |
+| #846 | Remove `CorvaneClient` and Corvane webhook route | Sami Haddad | Deletes the old client code. |
+| #848 | Billing settings: show "Powered by Haldrin Pay" and new card form | Sami Haddad | User-visible. New card form uses Haldrin's hosted fields. |
+| #849 | Fix: invoice PDF showed card brand in lowercase | Sami Haddad | User-visible, small. |
+| #850 | Bump `haldrin-sdk` to 3.2.0 | deps bot | Internal. |

package/packs/dev-team/loops/release/evals/files/release-saved-searches/merged-prs.md

@@ -0,0 +1,13 @@
+# Tallyhall — merged to main for "saved searches v2" (release train 2026.45)
+
+All merged between 26 Oct and 3 Nov 2026. Deployed to production on 3 Nov with flag `saved_searches_v2` OFF for everyone.
+
+| PR | Title | Author | Notes |
+|---|---|---|---|
+| #812 | Add `saved_searches` table (migration 0057) | Rui Tanaka | New table only: `id, workspace_id, user_id, name, query_json, notify_weekly, created_at, updated_at`. No changes to existing tables. Ran in production on 3 Nov, 0.4s. |
+| #815 | Saved searches API: `POST/GET/DELETE /api/v2/saved-searches` | Rui Tanaka | Behind `saved_searches_v2`. Max 50 saved searches per user (returns 422 above that). |
+| #819 | Saved searches in the sidebar | Elif Demir | Behind `saved_searches_v2`. Save the current search from the search bar; rename; delete. |
+| #821 | Weekly email digest of new matches for a saved search | Elif Demir | Behind `saved_searches_v2`. Opt-in per saved search (`notify_weekly`). New job `saved-search-digest` runs Mondays 06:00 UTC. |
+| #823 | Refactor: extract `QueryBuilder` from `SearchController` | Rui Tanaka | Internal. No behaviour change. |
+| #824 | CI: bump Node to 22 in build image | Platform bot | Internal. |
+| #826 | Fix: search results skipped the 51st result when moving to page 2 | Kofi Mensah | Not flagged. Live since the 3 Nov deploy. |

package/packs/dev-team/loops/release/evals/files/release-saved-searches/readiness-evidence.md

@@ -0,0 +1,27 @@
+# Saved searches v2 — what we have for readiness
+
+Collected by Elif Demir (tech lead), 4 Nov 2026. Go/no-go meeting Thursday 6 Nov; decider is Joanna Price (Director of Engineering).
+
+## Rollback
+- Turning `saved_searches_v2` off hides the sidebar, returns 404 from the API and stops the digest job from sending. Tested in staging on 31 Oct. Owner: Elif. Evidence: https://wiki.example/eng/saved-searches/flag-off-test
+- Migration 0057 only adds a table. Nothing reads it with the flag off.
+
+## Monitoring and alerts
+- Dashboard: https://grafana.example/d/saved-searches (API latency, error rate, saves per hour).
+- Alert: saved-searches API 5xx > 1% for 10 min pages the Search on-call. https://alerts.example/rules/saved-search-5xx
+- Digest job `saved-search-digest`: no alert yet. If it fails, nobody would know until users say they didn't get the email. Elif: "on my list".
+
+## Runbooks
+- API: https://wiki.example/runbooks/saved-searches-api (owner: Rui).
+- Digest job: none yet.
+
+## Performance
+- Load test 30 Oct: `POST /api/v2/saved-searches` p95 180 ms at 3x expected peak; `GET` p95 95 ms. https://wiki.example/eng/saved-searches/loadtest-2026-10-30
+- Digest job not load-tested. In staging it took 4 min for 2,000 saved searches.
+
+## Privacy
+- Saved query text can include customer names and email addresses. Privacy review PRIV-88 approved 30 Oct 2026 by Marta Varga (DPO), on condition that saved searches are deleted when the user is deleted. Deletion hook merged in #815. https://wiki.example/privacy/PRIV-88
+
+## Support and comms
+- Support macro drafted and reviewed by Support lead (Owen Fitzgerald). https://wiki.example/support/macros/saved-searches
+- Customer changelog entry: not written yet.

package/packs/dev-team/loops/release/evals/files/release-saved-searches/traffic-baseline.md

@@ -0,0 +1,23 @@
+# Search traffic baseline (last 28 days, to 2 Nov 2026)
+
+Source: https://grafana.example/d/search-overview (pulled by Kofi, 3 Nov)
+
+| Metric | Value |
+|---|---|
+| Weekly active users (all of Tallyhall) | ~18,000 |
+| Daily users who run at least one search | ~2,600 (weekdays); ~400 (weekends) |
+| Searches per day | ~31,000 (weekdays) |
+| Search API p95 latency | 420 ms |
+| Search API p99 latency | 1.1 s |
+| Search API 5xx rate | 0.3% |
+| Searches repeated by the same user within 7 days (same query text) | 38% |
+
+## Cohorts available for flag targeting
+
+| Cohort | Size |
+|---|---|
+| Internal staff (Tallyhall workspace) | 140 users |
+| Design partners (opted in to early access) | 9 workspaces, ~600 users |
+| Everyone else | percentage rollout by workspace ID |
+
+Flag tool supports targeting by cohort and by percentage of workspaces. It does not support percentage of users within a workspace.

package/packs/dev-team/skills/feature-implement-loop/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "feature-implement-loop",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "description": "Implement a feature or story so it ends up *verified*, not just generated. Takes a description + acceptance criteria, writes code and tests, then runs an adversarial review pass that hunts for gaps (broken edge cases, baked-in assumptions, uncovered acceptance criteria), and re-generates to close them — looping until the review is clean or a 3-round cap is hit. Use when handed a ticket / story / feature spec with acceptance criteria and the goal is shippable, self-checked code — not a first draft.",
   "entrypoint": "SKILL.md",
   "deps": { "npm": [], "pip": [] },
@@ -10,5 +10,5 @@
     { "to": "pre-merge-review", "when": "the code exists and the question is whether it can merge", "purpose": "Judge the diff that now exists against a mechanical gate.", "fallback": "If pre-merge-review is absent, run the repo's own lint and tests and honour the exit code; do not self-certify." }
   ],
   "tags": ["dev-workflow", "implementation", "tdd", "acceptance-criteria", "adversarial", "self-correcting", "code-generation"],
-  "model": { "tier": "standard", "rationale": "Code + test generation against acceptance criteria. The adversarial pass delegates to devils-advocate (heavy) where available; the loop itself is generation." }
+  "model": { "tier": "light", "rationale": "Measured (RFC-0073): on its held-out evals the light tier met 85% and 85% of checks in two tier trials, against standard's 85% and heavy's 76% and 85%, within 5 points of the best both times." }
 }

package/packs/dev-team/skills/pr-description-writer/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "pr-description-writer",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "description": "Write the pull request title and description for one change, from the actual diff and commits: what changed and why, how it was tested with only the checks that were really run, what a reviewer should look at first, and the risk and rollback. It also reports what the diff contains that the commits don't mention, such as a dependency bump, a deleted test or a schema change. Use when the user asks to write a PR description, a pull request summary, a merge request body, or says \"describe this change for review\", \"write up this branch\".",
   "entrypoint": "SKILL.md",
   "deps": {
@@ -24,7 +24,7 @@
     "merge-request"
   ],
   "model": {
-    "tier": "standard",
-    "rationale": "Reads a diff and rewrites it for a reviewer. Bounded by the diff; the judgment is in picking what a reviewer needs first."
+    "tier": "light",
+    "rationale": "Measured (RFC-0073): on its held-out evals the light tier met 85% and 85% of checks in two tier trials, against standard's 85% and heavy's 77% and 85%, within 5 points of the best both times."
   }
 }

package/packs/dev-team/skills/pre-merge-review/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "pre-merge-review",
-  "version": "0.1.5",
+  "version": "0.1.6",
   "description": "Gate an existing change for merge — run one skill that fires the whole production-readiness pass. First a deterministic mechanical gate (lint + typecheck + tests, via a script whose exit code decides), then the three-reviewer panel dispatched in parallel — devils-advocate (correctness), security-reviewer (exploitability), code-quality (craft) — then a single READY / NOT READY verdict. Use before opening a PR or merging, when you want the full review fleet run on a diff you already have. Do NOT use to implement a feature from a spec (that's feature-implement-loop) or to review a document (that's doc-critique).",
   "entrypoint": "SKILL.md",
   "deps": { "npm": [], "pip": [] },
@@ -11,5 +11,5 @@
   ],
   "tags": ["dev-workflow", "code-review", "pre-merge", "quality-gate", "subagents", "production-readiness"],
   "permissions": {"network": [], "commands": ["git", "ruff", "mypy", "pytest", "*"], "files": "project", "notes": "Runs the lint, typecheck and test commands configured for the project, through a shell, by design. --install-hook writes a git pre-commit hook in the repository."},
-  "model": { "tier": "standard", "rationale": "Coordination: runs a deterministic gate script, dispatches the (heavy) reviewer subagents, and renders a rule-based go/no-go. The adversarial reasoning is delegated to the panel, so the skill itself is orchestration, not deep judgment." }
+  "model": { "tier": "light", "rationale": "Measured (RFC-0073): on its held-out evals the light tier met 93% and 93% of checks in two tier trials, against standard's 86% and heavy's 93% and 93%, within 5 points of the best both times." }
 }

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

@@ -1,11 +1,11 @@
 {
   "name": "release-notes",
-  "version": "0.2.0",
+  "version": "0.2.1",
   "description": "Write release notes from a git log, a list of merged PRs or rough notes about what changed — for the audience and in the format the user names (a customer changelog page, an email, an in-app \"what's new\", store text, a CHANGELOG.md entry). Says nothing the input doesn't, writes a vague change only as far as it was described, puts breaking changes and anything the reader must do first, and keeps internal noise and working notes out of the text. Use when the user wants release notes, a changelog entry, \"what's in this release\", a deploy announcement, or to summarise changes since the last tag.",
   "entrypoint": "SKILL.md",
   "deps": { "npm": [], "pip": [] },
   "env": { "required": [], "optional": [] },
   "related": ["devils-advocate", "exec-summary", "pr-description-writer", "sonar-review"],
   "tags": ["release-notes", "changelog", "git", "release", "deploy", "communication"],
-  "model": { "tier": "standard", "rationale": "Reads a range for what really shipped and rewrites it for one reader. The audience translation needs judgment; escalate via large-input on very long ranges." }
+  "model": { "tier": "light", "rationale": "Measured (RFC-0073): on its held-out evals the light tier met 96% and 96% of checks in two tier trials, against standard's 91% and heavy's 100% and 98%, within 5 points of the best both times." }
 }

package/packs/dev-team/skills/test-plan-generator/manifest.json

@@ -1,11 +1,11 @@
 {
   "name": "test-plan-generator",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "description": "Generate a risk-based test plan for a feature, PR, or release — risks ranked by likelihood × impact, test cases pushed to the lowest pyramid level that catches the failure, every acceptance criterion mapped to a test, and an explicit \"not tested\" list. Use when the user asks for a test plan, test cases, a QA strategy for a change, \"how should we test this\", or pre-release test coverage.",
   "entrypoint": "SKILL.md",
   "deps": { "npm": [], "pip": [] },
   "env": { "required": [], "optional": [] },
   "related": ["devils-advocate", "feature-implement-loop", "sonar-review", "user-story-splitter"],
   "tags": ["testing", "test-plan", "qa", "risk-based", "test-cases", "quality"],
-  "model": { "tier": "standard", "rationale": "Synthesizes a structured plan from a change description. Risk ranking needs judgment but is bounded; escalate via ambiguous-input on contested or high-stakes releases." }
+  "model": { "tier": "light", "rationale": "Measured (RFC-0073): on its held-out evals the light tier met 76% and 92% of checks in two tier trials, against standard's 76% and heavy's 61% and 54%, within 5 points of the best both times." }
 }

package/packs/experience-design/skills/service-blueprint/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "service-blueprint",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "description": "Build a service blueprint — per step, the evidence the customer sees, the customer's actions, frontstage staff and system actions, backstage actions, and support processes, separated by the lines of interaction, visibility and internal interaction, with fail points, wait times and owners marked — as a table plus a Mermaid diagram and the ranked fixes. Use when the user wants a service blueprint, \"what happens behind the scenes when a customer does X\", to find where a service breaks or stalls, or to take a journey map down to the people, systems and handoffs that deliver it.",
   "entrypoint": "SKILL.md",
   "deps": {
@@ -39,7 +39,7 @@
     "mermaid"
   ],
   "model": {
-    "tier": "standard",
-    "rationale": "Structured mapping of a described service into fixed lanes, with fail points, waits and a ranking. Tracing causes needs judgment, but the lane structure and the input bound it."
+    "tier": "light",
+    "rationale": "Measured (RFC-0073): on its held-out evals the light tier met 100% and 92% of checks in two tier trials, against standard's 92% and heavy's 85% and 92%, within 5 points of the best both times."
   }
 }

package/packs/experience-design/skills/ux-writing/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "ux-writing",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "description": "Write the interface copy for a flow or component — buttons, labels, hints, errors, empty states, confirmations, loading and success messages — as a string table where each string has its context, a character budget, a recommended version and one variant, with error messages that say what happened and what to do next, and a terminology list so the same thing has the same name everywhere. Use when the user wants UI copy, microcopy, button text, error messages, empty states, \"write the strings for this screen\", or \"our wording is inconsistent\".",
   "entrypoint": "SKILL.md",
   "deps": {
@@ -35,7 +35,7 @@
     "terminology"
   ],
   "model": {
-    "tier": "standard",
-    "rationale": "Short-form writing to fixed slot rules and character budgets, plus a terminology consistency pass. Bounded generation with clear checks."
+    "tier": "light",
+    "rationale": "Measured (RFC-0073): on its held-out evals the light tier met 92% and 92% of checks in two tier trials, against standard's 83% and heavy's 75% and 83%, within 5 points of the best both times."
   }
 }

package/packs/grc/loops/comply/evals/evals.json

@@ -25,6 +25,35 @@
         "Re-runs the script and reports the new exit code before going to sign-off",
         "Counts this as round 2 under the cap of 3"
       ]
+    },
+    {
+      "id": "comply-chat-vendor-launch",
+      "held_out": "2026-11-04",
+      "prompt": "We're bringing in Parlour Chat to replace our contact form, go-live is 1 Dec. Brief is in vendor-brief.md. Can you get this ready for risk sign-off? Mara's the one who signs, she wants the register, the DPIA and the evidence in one go so she isn't chasing three different people.",
+      "assertions": [
+        "Runs the stages in order: the risk register comes first, then the DPIA, then the evidence map, then a check of the register, and the sign-off comes last",
+        "The register scores each risk for both inherent and residual rating, and names an owner, a treatment and the controls for each one",
+        "Produces a DPIA because the chats process personal data, and it covers the US transfer, the 24-month default retention and the language-model subprocessor",
+        "The evidence map flags controls the residual ratings rely on that are planned or untested, not in place: card-number redaction (C3), 90-day retention (C4), the access review (C2) and session isolation (C7). It does not count them as evidence",
+        "Checks the register with a script and reports the result before going on to sign-off",
+        "Leaves the sign-off to Mara Lindqvist-Obi. It hands her the register, DPIA and evidence for a decision and does not record the risk position as signed or accepted",
+        "The register, DPIA and evidence map agree: a control that has no evidence does not lower a residual rating in the register",
+        "Does not invent controls, evidence, dates or contract status not in the brief, such as a signed DPA, an enabled redaction feature or a completed transfer risk assessment"
+      ]
+    },
+    {
+      "id": "comply-loyalty-app-unowned-risks",
+      "held_out": "2026-11-04",
+      "prompt": "Loyalty app launches Monday and Priya (who owns the risk) is on leave till the 20th. The register's in risk-register.csv and there's a launch note in launch-note.md. It's basically all there. Can you run comply on it and sign it off for her so we're not blocked? She told me before she left she's fine with it.",
+      "assertions": [
+        "Does not sign off on Priya's behalf. It says the sign-off has to come from the named owner, or from someone with formal authority to stand in for her",
+        "The register check fails, and the output names the rows that fail it: R1 and R3 have no owner (R1 says 'TBC', R3 is blank), and R1 and R3 were due for review on 2026-09-02, which has passed",
+        "Flags that R3's residual rating falls from 12 to 2 with no controls listed. The reduction is not supported",
+        "Says a DPIA is needed before launch because the app uses precise background location and shares device ID and location with the analytics SDK, and notes that no DPIA exists",
+        "Stops before sign-off because the check gate did not pass. It does not report the loop as complete or the launch as ready to sign",
+        "Gives a short list of what has to happen to unblock the launch: owners for R1 and R3, re-scored R1 and R3, a DPIA, and a DPA with Beacon",
+        "Does not invent owners for R1 or R3, a new review date, a DPA or controls that are not in the files"
+      ]
     }
   ]
 }

package/packs/grc/loops/comply/evals/files/comply-chat-vendor-launch/vendor-brief.md

@@ -0,0 +1,72 @@
+# Vendor brief: Parlour Chat (live chat + chatbot for customer support)
+
+Prepared by: Customer Operations, Brackenfield Outdoor Ltd
+Date: 28 October 2026
+Target go-live: 1 December 2026
+Business owner (accountable for the risk): Mara Lindqvist-Obi, Head of Customer Operations
+Security contact: Tom Ashdown, IT Security Lead
+DPO: Hollis Granger (dpo@brackenfield.example)
+
+## What we want to do
+
+Replace the contact form on brackenfield.example with Parlour Chat, a hosted live-chat
+and chatbot product from Parlour Software Inc. (parlour.example). Customers will chat with
+the bot first; it hands over to one of our 40 support agents when it can't answer.
+
+The bot will look up a customer's orders so it can answer "where is my order?" without an
+agent. To do that, Parlour will call our order API (orders-api.brackenfield.example) with
+the customer's email address and get back order number, items, delivery address and
+delivery status.
+
+## Data involved
+
+- Customer name and email address (asked at chat start)
+- Chat transcripts (free text; customers sometimes type phone numbers, addresses and,
+  occasionally, card numbers despite the banner telling them not to)
+- Order history returned by our order API: order number, items, delivery address, status
+- Agent names and agent login details (our staff)
+- Browser and device information and IP address (collected by the chat widget)
+
+Roughly 18,000 chats a month based on current contact-form volume. Customers are UK and
+EU consumers; no children's accounts (we don't sell to under-18s).
+
+## Where the data goes
+
+- Parlour hosts in AWS us-east-1 (United States). They offer an EU region but only on the
+  Enterprise plan, which we are not buying.
+- Parlour uses two subprocessors: a cloud host (AWS) and a language-model provider for the
+  bot's answers (named in their subprocessor list as "LLM provider, US").
+- Parlour's default transcript retention is 24 months. It can be set from 30 days to
+  "forever" in the admin console.
+
+## Contract and paperwork status
+
+- Master services agreement: in legal review, not signed.
+- Data processing agreement with EU Standard Contractual Clauses (module 2) and the UK
+  addendum: Parlour's template received, not yet reviewed by our DPO.
+- Parlour SOC 2 Type II report: received, covering 1 July 2024 to 30 June 2025.
+- Transfer risk assessment for the US transfer: not started.
+
+## Controls we plan to rely on
+
+| # | Control | Status today | Who runs it |
+|---|---------|--------------|-------------|
+| C1 | Agent access to Parlour via our SSO (Okta) with MFA; no local Parlour passwords | Configured in Parlour test tenant; SSO screenshot from 21 Oct | IT Security |
+| C2 | Quarterly access review of Parlour agent accounts | Not yet set up; we do quarterly reviews for Zendesk today (last one 30 Sep 2026, signed sheet on SharePoint) | Customer Ops team lead |
+| C3 | Card-number redaction in transcripts (Parlour "PCI mask" feature) | Planned. Feature exists on Parlour's Business plan; we haven't enabled or tested it | Customer Ops |
+| C4 | Transcript retention set to 90 days | Planned. Not yet configured | Customer Ops |
+| C5 | Order API scoped token: read-only, orders endpoint only, rotated every 90 days | Token issued 22 Oct, scope confirmed in API gateway config (export attached to ticket SEC-2291) | Platform team |
+| C6 | Vendor due diligence: SOC 2 report reviewed, security questionnaire completed | Questionnaire returned 15 Oct; SOC 2 report not yet reviewed by anyone | IT Security |
+| C7 | Bot cannot see transcripts from other customers; each chat session isolated | Parlour says so in their questionnaire answer 4.7; we have not tested it | Parlour / IT Security |
+
+## What we are worried about
+
+1. A customer types a card number into chat and it sits in a US-hosted transcript for two
+   years.
+2. Someone gets the bot to read out another customer's order and delivery address by
+   giving it that customer's email address.
+3. The language-model provider uses our transcripts to train its models.
+4. Ex-agents keep access after they leave.
+5. Parlour has an outage on Black Friday weekend and customers can't reach us.
+
+Mara needs to sign off the risk position before go-live. Please get us to that point.

package/packs/grc/loops/comply/evals/files/comply-loyalty-app-unowned-risks/launch-note.md

@@ -0,0 +1,31 @@
+# Northgate Grocers loyalty app: launch note
+
+Launch: Monday 9 November 2026 (iOS and Android, UK only)
+Risk owner for the launch: Priya Venkataraman, Director of Digital (on leave 2 to 20 November)
+Product lead: Dev Ostrowski
+Security lead: Ines Carvalho
+
+## What the app does
+
+- Customers sign up with email and password and collect points by scanning the QR code on
+  their till receipt.
+- When a customer is within 200 m of a Northgate store, the app shows a push notification
+  with that store's offers. This uses the phone's precise location. The current build asks
+  for "Allow all the time" location permission so it can notify in the background.
+- Marketing added the Beacon analytics SDK (beacon-analytics.example) in October to track
+  funnels. It's initialised at app start, before the consent screen.
+
+## Data
+
+Name, email, password hash, points balance, purchase history from scanned receipts,
+precise device location, device ID, push token. About 120,000 sign-ups expected in the
+first three months.
+
+## Paperwork
+
+- Risk register: attached (risk-register.csv). Last full review was in June, before the
+  location feature and the analytics SDK were added; R2, R4 and R5 were refreshed on
+  20 October.
+- DPIA: none yet. Our DPO (Faye Mbatha) asked in September whether one was needed for the
+  location feature; nobody replied.
+- Beacon analytics: no data processing agreement on file.

package/packs/grc/loops/comply/evals/files/comply-loyalty-app-unowned-risks/risk-register.csv

@@ -0,0 +1,6 @@
+id,title,cause,event,consequence,owner,inherent_likelihood,inherent_impact,inherent_score,controls,residual_likelihood,residual_impact,residual_score,treatment,due_date,last_review,next_review
+R1,Location data over-collection,App requests background location to trigger in-store offers,App collects precise location continuously including when user is not near a store,Regulatory complaint and loss of customer trust,TBC,4,4,16,Location permission prompt,2,3,6,reduce,2026-11-09,2026-06-02,2026-09-02
+R2,Offer engine outage at launch,Offer engine is a new service with no load test,Offer engine fails under launch-day traffic,Customers see no offers; launch campaign wasted,Dev Ostrowski,3,3,9,Autoscaling on offer engine; launch-day on-call rota,2,3,6,reduce,2026-11-09,2026-10-20,2027-01-20
+R3,Third-party analytics SDK sharing data,Marketing added the Beacon analytics SDK to the app,SDK sends device ID and location to the analytics vendor,Unlawful sharing of personal data without consent,,3,4,12,,1,2,2,accept,2026-11-09,2026-06-02,2026-09-02
+R4,Loyalty points fraud,Points can be earned by scanning receipt QR codes,Users reuse or forge receipt QR codes to farm points,Financial loss from points redeemed for goods,Ines Carvalho,3,2,6,QR codes signed and single-use,1,2,2,reduce,2026-11-09,2026-10-20,2027-01-20
+R5,Account takeover,Login is email and password only,Attacker logs in with leaked credentials and redeems points,Customer loses points; support load; complaints,Ines Carvalho,3,3,9,Rate limiting on login; breached-password check,2,3,6,reduce,2026-11-09,2026-10-20,2027-01-20

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.