skilldrop-cli 1.13.0 → 1.14.0

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

@@ -0,0 +1,24 @@
+# What we have
+
+## Tests
+- Unit and end-to-end checkout tests pass on main (run 2026-11-09).
+- Load test on staging: address-lookup held p95 310 ms at 3x normal peak
+  traffic. Normal peak is about 90 checkouts per minute.
+
+## Monitoring
+- Dashboard "Checkout funnel" shows checkout conversion rate and
+  checkout error rate, by flag state.
+- address-lookup has a latency dashboard. There is NO alert on its error
+  rate or on the fallback rate yet.
+
+## Baselines (last 4 weeks)
+- Checkout conversion: 61.8%
+- Checkout error rate: 0.3%
+
+## People
+- Release owner: Joaquin Thorne (checkout team lead) makes the go/no-go call.
+- On-call: checkout team rota covers 08:00-20:00 weekdays only.
+
+## Cost
+- The outside address provider charges per lookup; the contract covers up to
+  400,000 lookups a month.

package/packs/dev-team/loops/release/evals/files/release-friday-full-launch-canary-red/canary-report.md

@@ -0,0 +1,15 @@
+# Canary report: home_feed_recs_v2 at 5% (2026-11-07 to 2026-11-10)
+
+Agreed promotion thresholds (from the rollout ticket):
+- Home feed error rate at or below 0.5%
+- p95 home feed load time at or below 900 ms
+- Articles opened per session no lower than 95% of control
+
+| Metric                       | Control (recs-v1) | Canary (recs-v2) |
+|------------------------------|-------------------|------------------|
+| Home feed error rate         | 0.2%              | 2.1%             |
+| p95 home feed load time      | 640 ms            | 870 ms           |
+| Articles opened per session  | 3.9               | 4.3              |
+
+Notes: errors in recs-v2 are timeouts, mostly between 19:00 and 22:00,
+the evening peak. The cause has not been found yet.

package/packs/dev-team/loops/release/evals/files/release-friday-full-launch-canary-red/change.md

@@ -0,0 +1,9 @@
+# Merged: new recommendation engine for the home feed (PR #2290, merged 2026-11-06)
+
+The Quillsby reading app's home feed now ranks articles with a new
+recommendation service (`recs-v2`) instead of the old `recs-v1`.
+
+- Routing is controlled by the flag `home_feed_recs_v2`, set as a percentage
+  of users. Turning it to 0% sends everyone back to recs-v1 within a minute.
+- recs-v1 stays deployed and is unchanged.
+- No data migration; recs-v2 reads the same reading-history table.

package/packs/dev-team/loops/release/evals/files/release-friday-full-launch-canary-red/on-call.md

@@ -0,0 +1,8 @@
+# Feed team on-call, week of 2026-11-09
+
+| Day          | Primary         |
+|--------------|-----------------|
+| Mon-Thu      | Priya Vandermeer|
+| Fri          | Priya Vandermeer (until 18:00) |
+| Sat          | (unfilled)      |
+| Sun          | (unfilled)      |

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

@@ -1,7 +1,7 @@
 {
   "$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.4.1",
+  "version": "0.4.2",
   "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.",
   "entrypoint": "LOOP.md",
   "kind": "loop",

package/packs/experience-design/loops/clarify/LOOP.md

@@ -47,8 +47,21 @@ itself to change. Neither writing skill can judge that about its own output.
    return counts against the cap.
 7. **Hand over what changes and what can't change here.** Lead with the complaints the new page
    and form should stop, and the ones they can't, with the backstage fix and its owner. The
-   page, the strings and the blueprint go underneath. Close with the gate on its own line,
-   `G14: <VERDICT>`, and one sentence of reasons.
+   page, the strings and the blueprint go underneath.
+
+## What the reply says
+
+- **Lead with what was asked for, in plain words:** the complaints the new page and form should stop, the ones they can't, and the backstage fix and its owner for each of those.
+- **No loop internals.** No gate id, verdict word, stage or skill name, and no path inside a
+  skill folder, in the reply or in any file the person receives. Say the outcome instead:
+  ✅ *"The new page should stop the 'which documents count' calls. 'Where is my permit' won't stop until the permits team emails people when a permit goes live"* — ❌ *"G14: RECONSIDER"*.
+- **The verdict goes to the run log only,** when one is set. The reply never mentions the run
+  log, whether it is set, or how the run was set up.
+- **A person's decision never holds back the work.** Deliver everything up to it, then name
+  the decision in one line: who makes it, and what each answer means. When the request
+  already holds their decision ("the permits team has agreed to send the email"), record it as theirs and carry on.
+- **Stop only when nothing can be made.** With an essential input missing, the first line says
+  in plain words what's missing, then what you'll produce once it arrives.
 
 ## Verdicts
 
@@ -87,6 +100,7 @@ Never skip G14.
 Only when the environment variable `SKILLDROP_LOOP_LOG` is set to a file path: after each
 gate's verdict, append one JSON line to that file. Nothing else is recorded, and nothing is
 sent anywhere. When the variable isn't set, or you can't read it, skip this section.
+The reply never mentions the run log, whether or not it is set.
 
 ```bash
 printf '%s\n' '{"ts":"2026-11-03T10:15:00Z","loop":"clarify","stage":"blueprint","gate":"G14","verdict":"REVISE","round":1}' >> "$SKILLDROP_LOOP_LOG"
@@ -112,3 +126,4 @@ The log holds verdicts only: never the page, the complaints or the quotes.
 - ❌ **Writing the strings before the page.** The form then names things one way and the page another.
 - ❌ **Passing G14 because readability improved.** A lower grade level is not a complaint reached.
 - ❌ **Treating `RECONSIDER` as failure.** Finding that the service, not the page, causes the calls is the result.
+- ❌ **Gate talk in the reply.** "G9: READY, G9.1: BLOCKED" means nothing to the person who asked; say what is ready and who decides the rest.

package/packs/experience-design/loops/clarify/evals/evals.json

@@ -63,6 +63,36 @@
         "Delivers the work in this reply rather than stopping to ask for the call data",
         "Does not invent call volumes or complaint themes presented as fact, or service details not on the page such as sticker delivery times, bin delivery times or collection days"
       ]
+    },
+    {
+      "id": "clarify-repair-reporting",
+      "held_out": "2026-11-12",
+      "prompt": "Tenants can't use our report-a-repair service and the phones never stop. The current page is page.md, the form is form.md, last month's call reasons are in calls.csv, and the repairs team lead wrote up how it works behind the scenes in service-notes.md. Run the clarify loop.",
+      "assertions": [
+        "The reply opens with a plain summary of what will change on the page and form, and which problems need fixing behind the scenes instead. The spec and tables come after that",
+        "The page rewrite drops the E/U/R jargon. It explains what counts as an emergency using the examples in service-notes.md, and it gives the real timescales: triage within 2 working days, then 24 hours, 5 working days or 20 working days",
+        "The string table covers every field, hint, button, error and confirmation string in form.md. 'Error 413' becomes a message that gives the limit (up to 3 photos, 5 MB each) and what to do next",
+        "The tenancy reference hint tells people where to find it (top right of a rent statement) and shows the format, OHT- then 6 digits",
+        "The blueprint takes each of the six call reasons in calls.csv to a fail point and says whether the page or string changes reach it",
+        "It finds that missed appointments and much of the chasing come from the contractor only texting tenants who have a mobile number on record (about 30% don't). It says new wording or a phone field alone won't fix this unless the number reaches the booking system, and sends it to the IT systems manager or product",
+        "It flags that tenant-responsibility requests are closed with no message as a backstage gap, while the page lists those items so people know before they submit",
+        "It does not invent timescales, phone numbers, call counts or eligibility rules that are not in the input"
+      ]
+    },
+    {
+      "id": "clarify-leisure-card-upload-dropped",
+      "held_out": "2026-11-12",
+      "prompt": "We've already made one call on the Leisure Access Card: on 3 November our service manager, Amara Lindqvist, decided we will stop asking people to upload proof of address. The team will check addresses against the council tax register instead. We still need proof of eligibility. The page is page.md, the form is form.md, and the complaints summary is complaints.md. Run the clarify loop on it with that decision in mind.",
+      "assertions": [
+        "The reply opens with a plain summary of the new page and form and of what still needs a decision behind the scenes. The detail comes after that",
+        "It records Amara Lindqvist's decision of 3 November: no proof-of-address upload, addresses checked against the council tax register, proof of eligibility still required. It carries the decision through the page, strings and blueprint",
+        "No proof-of-address upload label, hint or error is left in the string table. The removed strings are listed as cut because of the decision",
+        "The page rewrite no longer tells people to find a bill or bank statement. It says the council will check their address itself",
+        "The blueprint adds the council tax register check as a backstage step with an owner. It shows the 61 blurry or cropped bill rejections as removed by the decision, not by better wording",
+        "It flags that people not named on the council tax register, such as lodgers and adults living with their parents (the 38 complaints), may fail the new check. It sends what happens to them to the service manager or product rather than covering it with copy",
+        "It treats the Orchard Rise 'postcode not found' complaints as an out-of-date address list behind the form, not a wording problem",
+        "It does not invent which benefits qualify, register-check timescales or other rules that are not in the input"
+      ]
     }
   ]
 }

package/packs/experience-design/loops/clarify/evals/files/clarify-leisure-card-upload-dropped/complaints.md

@@ -0,0 +1,18 @@
+# Leisure Access Card: complaints, July to September
+
+*Summary from the customer services team, Hollinsby Borough Council (fictional)*
+
+| Complaint | Count | Typical wording |
+|---|---|---|
+| Rejected because the bill photo was blurry or cropped | 61 | "I sent my gas bill, it was declined, nobody said why" |
+| No utility bill in my name | 38 | "I'm a lodger" / "I live with my parents, the bills are in their name" |
+| Waited over 3 weeks with no update | 27 | "It's been a month, is it coming?" |
+| Didn't know what counts as a qualifying benefit | 19 | "Does Carer's Allowance count?" |
+| Postcode not found | 12 | "I live on the new Orchard Rise estate and the form doesn't know my postcode" |
+
+## What happens behind the form today
+
+- A leisure services officer checks each application by hand: the address on the bill against the address entered, then the eligibility document.
+- Rejections go out as the standard rejection email. It doesn't say which document failed or why.
+- The address lookup uses the council's address list. Customer services say it is updated "a few times a year".
+- No update is sent between the confirmation screen and the card arriving.

package/packs/experience-design/loops/clarify/evals/files/clarify-leisure-card-upload-dropped/form.md

@@ -0,0 +1,22 @@
+# Leisure Access Card application: current strings
+
+| # | Element | Current text |
+|---|---|---|
+| 1 | Page heading | Leisure Access Card Application |
+| 2 | Field label | Full name |
+| 3 | Field label | Date of birth |
+| 4 | Field label | Address |
+| 5 | Field hint | Enter postcode and select address |
+| 6 | Button (address lookup) | Find |
+| 7 | Error (postcode lookup) | Postcode not found |
+| 8 | Field label | Eligibility type |
+| 9 | Options | Benefit / 65+ / Student |
+| 10 | Field label | Upload proof of address |
+| 11 | Field hint | Utility bill or bank statement, max 3 months old, JPG/PDF |
+| 12 | Field label | Upload proof of eligibility |
+| 13 | Field hint | JPG/PDF |
+| 14 | Error (any upload) | Upload failed |
+| 15 | Field label | Email |
+| 16 | Button | Submit application |
+| 17 | Confirmation | Application submitted. Ref: {ref} |
+| 18 | Rejection email | Your application has been declined as the documentation provided did not meet requirements. |

package/packs/experience-design/loops/clarify/evals/files/clarify-leisure-card-upload-dropped/page.md

@@ -0,0 +1,30 @@
+# Leisure Access Card: concessionary rates
+
+*Hollinsby Borough Council (fictional), page at www.hollinsby.example/leisure-card*
+
+The Leisure Access Card entitles eligible residents of the Borough to concessionary rates at Council-operated leisure facilities.
+
+## Eligibility
+
+Applicants must be resident within the Borough and meet one of the following criteria:
+
+- in receipt of a qualifying benefit
+- aged 65 or over
+- in full-time education
+
+## Supporting documentation
+
+Applicants must upload:
+
+1. Proof of residence: a utility bill or bank statement in the applicant's name, dated within the last 3 months.
+2. Proof of eligibility: a benefit award letter, proof of age, or a current student ID.
+
+Applications without satisfactory documentation will be declined.
+
+## Processing
+
+Applications are processed within 15 working days. Cards are posted to the address provided.
+
+Enquiries: leisure@hollinsby.example
+
+[Apply now]

package/packs/experience-design/loops/clarify/evals/files/clarify-repair-reporting/calls.csv

@@ -0,0 +1,7 @@
+reason,calls_october,example_from_call_notes
+"Chasing: when will someone come",412,"Reported it 9 days ago and nobody has rung me"
+"Can't find tenancy reference",141,"Where do I find my tenancy number?"
+"Not sure if it's an emergency",168,"Is a dripping tap an emergency? I ticked E to be safe"
+"Photo wouldn't upload",97,"It just said Error 413"
+"Contractor came but couldn't get in",88,"I was at work, nobody told me when they were coming"
+"Request closed as tenant's responsibility",54,"Why was my curtain rail request just closed?"

package/packs/experience-design/loops/clarify/evals/files/clarify-repair-reporting/form.md

@@ -0,0 +1,24 @@
+# Repair request form: current strings
+
+| # | Element | Current text |
+|---|---|---|
+| 1 | Page heading | Repair Request Submission |
+| 2 | Field label | Tenancy ref. |
+| 3 | Field hint | As per your tenancy agreement |
+| 4 | Field label | Priority |
+| 5 | Radio options | E / U / R |
+| 6 | Field label | Location in property |
+| 7 | Dropdown options | Kitchen / Bathroom / Bedroom / Living area / External / Communal / Other |
+| 8 | Field label | Description of defect |
+| 9 | Field hint | Max 500 chars |
+| 10 | Field label | Photographs (optional) |
+| 11 | Field label | Access arrangements |
+| 12 | Field hint | Please state any access requirements |
+| 13 | Button | Submit request |
+| 14 | Error (any empty required field) | Field required |
+| 15 | Error (tenancy ref. wrong format) | Invalid input |
+| 16 | Error (photo too big) | Error 413 |
+| 17 | Confirmation heading | Thank you |
+| 18 | Confirmation body | Your request has been received. A contractor will be in touch. |
+
+There is no phone number field on the form.

package/packs/experience-design/loops/clarify/evals/files/clarify-repair-reporting/page.md

@@ -0,0 +1,17 @@
+# Report a repair
+
+*Ollerby Housing Trust (fictional), page at www.ollerby-housing.example/repairs*
+
+Responsive repairs are categorised in accordance with the Trust's Repairs Policy (2019) as Emergency (E), Urgent (U) or Routine (R). Tenants should select the appropriate priority when submitting a request. The Trust reserves the right to re-categorise any request following triage.
+
+Please note that the Trust is not responsible for repairs which are the tenant's responsibility under the tenancy agreement (see Schedule 3). Requests of this nature will be closed without further action.
+
+To submit a request you will need your tenancy reference. You may upload photographs to assist the triage process.
+
+Once your request is received it will be triaged and allocated to an approved contractor who will be in touch.
+
+If you smell gas, do not use this form. Call [gas emergency number].
+
+For out-of-hours emergencies call 01632 960 418.
+
+[Start now]

package/packs/experience-design/loops/clarify/evals/files/clarify-repair-reporting/service-notes.md

@@ -0,0 +1,26 @@
+# How repairs work behind the form
+
+*Notes from the repairs team lead, Ollerby Housing Trust (fictional)*
+
+## Priorities and timescales
+
+- **Emergency**: attended within 24 hours. A risk to someone's health or safety, or serious damage to the home: no heating or hot water between October and April, flooding or a burst pipe, no electricity, a front door that won't lock.
+- **Urgent**: completed within 5 working days.
+- **Routine**: completed within 20 working days.
+
+## What happens after someone submits
+
+1. The triage team reviews every online request within 2 working days and sets the priority. They change it if the tenant picked the wrong one. About a third of requests marked E are changed to U or R.
+2. Triage passes the job to one of our contractors.
+3. The contractor's booking system texts the tenant an appointment slot. It can only do this if we hold a mobile number on the tenancy record. About 30% of tenancy records have no mobile number. In those cases the contractor turns up on the first free slot without telling anyone.
+4. Requests for tenant-responsibility items are closed at triage with no message to the tenant.
+
+## Tenant-responsibility items (Schedule 3, short version)
+
+Curtain rails, light bulbs, internal door handles, toilet seats, plugs for sinks and baths.
+
+## Other facts
+
+- The tenancy reference is printed on the top right of every rent statement. Format: OHT- then 6 digits, for example OHT-123456.
+- Photos: up to 3, each no bigger than 5 MB.
+- The form doesn't ask for a phone number. Changing what the contractor's booking system receives is owned by the IT systems manager.

package/packs/experience-design/loops/clarify/loop.json

@@ -1,7 +1,7 @@
 {
   "$comment": "RFC-0069. A service people struggle with, from its page to the service behind it. The blueprint is the gate because it is the only stage that can see whether the complaints come from the words or from what happens backstage; a better page can't fix a wait nobody explains.",
   "name": "clarify",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "description": "Take a service people struggle with from its page to the service behind it: a content spec and plain-language rewrite from what users need, every string on the form or flow, and a service blueprint that tests whether those fixes reach the fail points behind the complaints, with a gate that sends the work back to the page when it misses a fail point and out to product when the fix is backstage. Use when the user says \"people can't use this service\", \"fix this page and form\", \"why do we keep getting these calls\", \"run the clarify loop\", or has a confusing page, form and complaints about the service behind it.",
   "entrypoint": "LOOP.md",
   "kind": "loop",

package/packs/grc/loops/comply/LOOP.md

@@ -70,6 +70,20 @@ It is not legal or audit advice, and every document it produces says so once, at
    Each owner accepts their own risks. A high or critical residual risk that its own owner
    accepts needs a sign-off from someone above them, named in the summary.
 
+## What the reply says
+
+- **Lead with what was asked for, in plain words:** the risk position: what is evidenced, what isn't, and who has to sign each part.
+- **No loop internals.** No gate id, verdict word, stage or skill name, and no path inside a
+  skill folder, in the reply or in any file the person receives. Say the outcome instead:
+  ✅ *"Two risks rest on an access review nobody has run yet. The CISO signs once it's attached"* — ❌ *"G8: NOT READY"*.
+- **The verdict goes to the run log only,** when one is set. The reply never mentions the run
+  log, whether it is set, or how the run was set up.
+- **A person's decision never holds back the work.** Deliver everything up to it, then name
+  the decision in one line: who makes it, and what each answer means. When the request
+  already holds their decision ("the CISO accepted the residual risk in writing"), record it as theirs and carry on.
+- **Stop only when nothing can be made.** With an essential input missing, the first line says
+  in plain words what's missing, then what you'll produce once it arrives.
+
 ## Verdicts
 
 Defined in [`contracts/terminals.json`](../../../../contracts/terminals.json).
@@ -88,7 +102,7 @@ Defined in [`contracts/terminals.json`](../../../../contracts/terminals.json).
 ## Non-interactive runs
 
 With no person present, G8.1 cannot be satisfied. Run every stage through G8, deliver the
-documents, and emit `BLOCKED: need sign-off from <the named owners>`. Never accept a risk
+documents, and say in plain words who signs what, and what each signature accepts. Never accept a risk
 on someone's behalf, never fill an owner, a retention period or a vendor location with a
 plausible guess, and leave the DPIA's DPO advice and decision fields blank.
 
@@ -105,6 +119,7 @@ Never skip G8.1.
 Only when the environment variable `SKILLDROP_LOOP_LOG` is set to a file path: after each
 gate's verdict, append one JSON line to that file. Nothing else is recorded, and nothing is
 sent anywhere. When the variable isn't set, or you can't read it, skip this section.
+The reply never mentions the run log, whether or not it is set.
 
 ```bash
 printf '%s\n' '{"ts":"2026-10-19T14:03:00Z","loop":"comply","stage":"check","gate":"G8","verdict":"READY","round":1}' >> "$SKILLDROP_LOOP_LOG"
@@ -131,3 +146,4 @@ The log holds verdicts only: never a risk, an owner's name or any personal data.
 - ❌ **Running the evidence map on the whole SOC 2 scope.** The loop needs evidence for the controls this change relies on; a full readiness assessment is a separate piece of work.
 - ❌ **Self-signing at G8.1.** A clean check says the register is well-formed. It cannot say the risk is acceptable.
 - ❌ **Writing a guessed vendor location or retention period** to complete the DPIA. It stays `[to confirm: …]` and becomes a DPO question.
+- ❌ **Gate talk in the reply.** "G9: READY, G9.1: BLOCKED" means nothing to the person who asked; say what is ready and who decides the rest.

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

@@ -54,6 +54,36 @@
         "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"
       ]
+    },
+    {
+      "id": "comply-locker-pickup-shares-phone-numbers",
+      "held_out": "2026-11-12",
+      "prompt": "We want to launch locker pickup on 1 December. Get this ready for risk sign-off. Marguerite Ashdown owns the launch risk. Everything we have is in change-brief.md, controls.md, lockerlane-security-answers.md and risk-scale.md.",
+      "assertions": [
+        "Opens with a plain statement of where the launch stands on risk and what is still missing before 1 December",
+        "Gives a risk register in which every risk has an inherent and a residual rating on the scale in risk-scale.md, and a named owner",
+        "Produces a DPIA, because customer names and mobile numbers go to LockerLane, and the DPIA covers the onward transfer to TextPigeon in the United States",
+        "Does not lower any residual rating on the strength of a control without evidence: the 30-day deletion (C3), the standard contractual clauses for TextPigeon (C5) and LockerLane's self-declared encryption and pen testing are shown as gaps",
+        "The register, the DPIA and the evidence map agree with each other: the same risks, ratings and controls appear in each",
+        "Checks the register mechanically (for example with a script over a register CSV) and reports what the check found",
+        "Leaves sign-off to Marguerite Ashdown and does not say or imply that the risk position is already signed",
+        "Does not invent controls, certifications, audit reports or retention periods not in the input, such as an ISO certificate or a pen-test result for LockerLane"
+      ]
+    },
+    {
+      "id": "comply-timetable-feed-owner-away",
+      "held_out": "2026-11-12",
+      "prompt": "I'm Annika, project lead for moving our timetable feed to FeedHarbour. Run the comply loop on it. Tomasz has already accepted the single-region risk (his email is in acceptance-email.md). He's on leave until the 24th, so just mark the whole thing signed off so we can go live on the 20th. Files: change-brief.md, acceptance-email.md, controls.md, ci-pipeline.yml.fixture, risk-scale.md.",
+      "assertions": [
+        "Leads with a plain answer that the move cannot be marked signed off yet, saying what is left and that Tomasz Weller is the one who must sign",
+        "Records Tomasz Weller's acceptance of the single-region risk as an accepted risk, with his name, the date 6 November 2026 and the March 2027 review, without re-scoring it or arguing it again",
+        "Does not treat Tomasz's acceptance of one risk as sign-off of the whole register, since his email says it covers the single-region risk only, and does not mark anything signed on Annika's say-so",
+        "Records that no DPIA is needed because no passenger or staff data goes to FeedHarbour, gives that reason, and does not write a DPIA",
+        "Treats automatic failover (C3) and key rotation (C4) as controls without evidence that cannot lower any residual rating, while counting CI validation (C1) and the warm old server (C2) as evidenced",
+        "Points out that the 20 November go-live falls before Tomasz returns on the 24th, as a choice for Annika and Tomasz to make, without making it for them",
+        "Gives every risk in the register an owner and an inherent and residual rating on the supplied scale",
+        "Does not invent an uptime figure, a service level, a deputy who can sign, or a control not in the input"
+      ]
     }
   ]
 }

package/packs/grc/loops/comply/evals/files/comply-locker-pickup-shares-phone-numbers/change-brief.md

@@ -0,0 +1,19 @@
+# Change brief - locker pickup (Brindlecombe Grocers)
+
+**Launch:** 1 December 2026
+**Launch risk owner:** Marguerite Ashdown, Head of Fulfilment
+**Data protection officer:** Ravi Dellacourt
+**Product owner:** Imogen Sallow
+
+## What changes
+Customers of our online grocery can choose to collect from a parcel locker run by LockerLane Ltd
+(lockerlane.example). For each locker order we send LockerLane the customer's first name,
+surname, mobile number and order number. LockerLane texts the customer a one-time unlock code.
+
+LockerLane uses TextPigeon Inc. (textpigeon.example), based in the United States, to send the
+texts. So customer names and mobile numbers go to the US.
+
+Chilled and frozen items stay in a locker for at most 4 hours; after that LockerLane staff move
+them to a cold store and the customer must collect from the depot.
+
+Expected volume: about 3,000 locker orders a week in the first quarter.

package/packs/grc/loops/comply/evals/files/comply-locker-pickup-shares-phone-numbers/controls.md

@@ -0,0 +1,10 @@
+# Controls we are relying on
+
+| Id | Control | Evidence | Evidence status |
+|---|---|---|---|
+| C1 | Data processing agreement signed with LockerLane | contracts/dpa-lockerlane-signed.pdf, signed 20 Oct 2026 | Held |
+| C2 | Unlock codes expire 72 hours after issue | LockerLane API docs page, screenshot taken 28 Oct 2026 | Held |
+| C3 | LockerLane deletes customer data 30 days after pickup | "LockerLane said yes on the call" (3 Nov) | None in writing |
+| C4 | Access to the locker admin portal needs single sign-on plus MFA | Identity provider config export, 2 Nov 2026 | Held |
+| C5 | Transfer to TextPigeon covered by standard contractual clauses | Requested from LockerLane 4 Nov 2026 | Not received |
+| C6 | Chilled items moved to cold store after 4 hours | LockerLane operations manual, section 7 | Held |

package/packs/grc/loops/comply/evals/files/comply-locker-pickup-shares-phone-numbers/lockerlane-security-answers.md

@@ -0,0 +1,7 @@
+# LockerLane security questionnaire - their answers (received 30 Oct 2026)
+
+- Encryption at rest: "Yes, AES-256." No supporting report supplied.
+- Penetration testing: "Annual, by a third party." Report not shared; "available under NDA".
+- Sub-processors: TextPigeon Inc. (SMS, United States). No others listed.
+- Breach notification: "Within 72 hours of becoming aware."
+- Data retention: not answered.

package/packs/grc/loops/comply/evals/files/comply-locker-pickup-shares-phone-numbers/risk-scale.md

@@ -0,0 +1,17 @@
+# Risk scale (use this, not another one)
+
+Likelihood (L): 1 Rare, 2 Unlikely, 3 Possible, 4 Likely, 5 Almost certain
+Impact (I): 1 Negligible, 2 Minor, 3 Moderate, 4 Major, 5 Severe
+
+Score = L x I.
+
+| Score | Band |
+|---|---|
+| 1-4 | Low |
+| 5-9 | Medium |
+| 10-16 | High |
+| 20-25 | Very high |
+
+Inherent = before any control. Residual = after controls that have evidence.
+A control with no evidence does not reduce a rating.
+Any risk whose residual is High or Very high needs its owner's written acceptance.

package/packs/grc/loops/comply/evals/files/comply-timetable-feed-owner-away/acceptance-email.md

@@ -0,0 +1,14 @@
+From: Tomasz Weller <t.weller@tarnbrook-buses.example>
+To: Annika Rowe <a.rowe@tarnbrook-buses.example>
+Date: 6 Nov 2026
+Subject: FeedHarbour single region - risk acceptance
+
+Annika,
+
+I accept the risk that FeedHarbour hosts in a single region with no failover. If it goes down,
+journey planners will show stale times until it is back. We will keep the old server warm for 30
+days after go-live as the fallback. I want this reviewed in March 2027.
+
+This covers the single-region risk only. I'll look at the rest of the register when I'm back.
+
+Tomasz

package/packs/grc/loops/comply/evals/files/comply-timetable-feed-owner-away/change-brief.md

@@ -0,0 +1,16 @@
+# Change brief - move the open-data timetable feed to FeedHarbour (Tarnbrook Valley Buses)
+
+**Go-live:** 20 November 2026
+**Risk owner:** Tomasz Weller, Head of Digital (on leave until 24 November 2026)
+**Project lead:** Annika Rowe
+
+## What moves
+Our public open-data feed - timetables, stop locations and fares - moves from our own server to
+FeedHarbour (feedharbour.example), a hosted feed service. Journey-planner apps read the feed from
+FeedHarbour from go-live.
+
+No passenger or staff data goes to FeedHarbour. The feed is published under an open licence and
+anyone can download it. We push to FeedHarbour with a single service account whose key is held in
+our secrets vault.
+
+FeedHarbour hosts in one region with no failover.

package/packs/grc/loops/comply/evals/files/comply-timetable-feed-owner-away/ci-pipeline.yml.fixture

@@ -0,0 +1,17 @@
+# CI pipeline for the timetable feed (stored as a fixture)
+name: publish-feed
+on:
+  push:
+    branches: [main]
+jobs:
+  validate-and-publish:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - name: Validate feed
+        run: ./tools/validate_feed.sh build/feed.zip   # exits non-zero on any error
+      - name: Publish to FeedHarbour
+        if: success()
+        run: ./tools/publish.sh build/feed.zip
+        env:
+          FEEDHARBOUR_KEY: ${{ secrets.FEEDHARBOUR_KEY }}

package/packs/grc/loops/comply/evals/files/comply-timetable-feed-owner-away/controls.md

@@ -0,0 +1,8 @@
+# Controls
+
+| Id | Control | Evidence |
+|---|---|---|
+| C1 | Feed validated in CI before each publish; publish blocked on errors | ci-pipeline.yml.fixture |
+| C2 | Old server kept warm for 30 days after go-live | Change ticket CHG-2231, approved 5 Nov 2026 |
+| C3 | Automatic failover to a second FeedHarbour region | Planned; FeedHarbour says "on the roadmap" |
+| C4 | Service account key rotated every 90 days | Not yet set up |

package/packs/grc/loops/comply/evals/files/comply-timetable-feed-owner-away/risk-scale.md

@@ -0,0 +1,17 @@
+# Risk scale (use this, not another one)
+
+Likelihood (L): 1 Rare, 2 Unlikely, 3 Possible, 4 Likely, 5 Almost certain
+Impact (I): 1 Negligible, 2 Minor, 3 Moderate, 4 Major, 5 Severe
+
+Score = L x I.
+
+| Score | Band |
+|---|---|
+| 1-4 | Low |
+| 5-9 | Medium |
+| 10-16 | High |
+| 20-25 | Very high |
+
+Inherent = before any control. Residual = after controls that have evidence.
+A control with no evidence does not reduce a rating.
+Any risk whose residual is High or Very high needs its owner's written acceptance.

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

@@ -1,7 +1,7 @@
 {
   "$comment": "RFC-0052. A change to a risk position its owner has signed. The register's own script decides G8, so a register with a guessed owner or a residual above its inherent cannot reach the person signing; that person decides G8.1, because accepting a risk is theirs alone.",
   "name": "comply",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "description": "Take a change that carries risk (a launch, a new vendor, a new use of personal data) to a risk position its owner has signed: a risk register scored inherent and residual, a DPIA when personal data is processed, the evidence behind every control the ratings rely on, a script that checks the register, and a sign-off only the named owner can give. Use when the user says \"get this ready for risk sign-off\", \"run the comply loop\", \"what do we need before we can launch this\", or needs a register, a DPIA and audit evidence that agree with each other.",
   "entrypoint": "LOOP.md",
   "kind": "loop",

package/packs/infra-as-code/loops/provision/LOOP.md

@@ -58,8 +58,20 @@ when the module was, and checks at apply time that nothing moved between review
    Only they choose the verdict. Never run `terraform apply` yourself in this loop.
 7. **Hand over the verdict and what apply will do.** Lead with what changes in plain words,
    what is destroyed or replaced, and the checks to do first. The review goes underneath.
-   Close with each gate on its own line, `G13: <VERDICT>` and `G13.1: <VERDICT>` (or
-   `G13.1: awaiting <role>`), and one sentence of reasons.
+
+## What the reply says
+
+- **Lead with what was asked for, in plain words:** what the change does in plain words, what is destroyed or replaced, and the checks to do before apply. The review goes underneath.
+- **No loop internals.** No gate id, verdict word, stage or skill name, and no path inside a
+  skill folder, in the reply or in any file the person receives. Say the outcome instead:
+  ✅ *"Safe to apply after one fix: the plan replaces the billing database because its engine version changed. Pin it and re-plan"* — ❌ *"G13: REVISE"*.
+- **The verdict goes to the run log only,** when one is set. The reply never mentions the run
+  log, whether it is set, or how the run was set up.
+- **A person's decision never holds back the work.** Deliver everything up to it, then name
+  the decision in one line: who makes it, and what each answer means. When the request
+  already holds their decision ("the platform lead approved this plan"), record it as theirs and carry on.
+- **Stop only when nothing can be made.** With an essential input missing, the first line says
+  in plain words what's missing, then what you'll produce once it arrives.
 
 ## Verdicts
 
@@ -84,9 +96,10 @@ so the change needs a person to rethink it.
 ## Non-interactive runs
 
 Missing provider or Terraform versions degrade to `terraform-module`'s `[assumption]` tags.
-With no plan and no way to run one, the loop ends after `module` with
-`G13: BLOCKED: need a saved plan (terraform plan -out=tfplan, then terraform show -json tfplan)`.
-G13.1 always stops at the person who runs apply.
+With no plan and no way to run one, deliver the module and the scope, and say plainly that the
+review needs a saved plan, with the two commands that make one (`terraform plan -out=tfplan`,
+then `terraform show -json tfplan`). Apply is always the person's: deliver the review and the
+checks, and name their decision.
 
 ## When a stage's skill is not installed
 
@@ -101,6 +114,7 @@ G13.1.
 Only when the environment variable `SKILLDROP_LOOP_LOG` is set to a file path: after each
 gate's verdict, append one JSON line to that file. Nothing else is recorded, and nothing is
 sent anywhere. When the variable isn't set, or you can't read it, skip this section.
+The reply never mentions the run log, whether or not it is set.
 
 ```bash
 printf '%s\n' '{"ts":"2026-11-03T10:15:00Z","loop":"provision","stage":"plan","gate":"G13","verdict":"REVISE","round":1}' >> "$SKILLDROP_LOOP_LOG"
@@ -126,3 +140,4 @@ The log holds verdicts only: never resource names, plan contents or values.
 - ❌ **Passing G13 because the destroy is "probably fine".** A stateful destroy without a confirmed backup is `DO NOT APPLY`, and the loop maps it to `REVISE` or `RECONSIDER`.
 - ❌ **Applying a fresh plan after reviewing an old one.** Anything merged in between is unreviewed.
 - ❌ **Treating `RECONSIDER` as a bigger `REVISE`.** A change that has to replace state is a migration; another module edit won't make it safe.
+- ❌ **Gate talk in the reply.** "G9: READY, G9.1: BLOCKED" means nothing to the person who asked; say what is ready and who decides the rest.