skilldrop-cli 1.12.0 → 1.14.0

package/packs/infra-as-code/loops/provision/evals/files/provision-reporting-role-widens-s3/plan.json

@@ -0,0 +1,225 @@
+{
+  "format_version": "1.2",
+  "terraform_version": "1.9.5",
+  "planned_values": {
+    "root_module": {
+      "child_modules": [
+        {
+          "address": "module.ledger_report_role",
+          "resources": [
+            {
+              "address": "module.ledger_report_role.aws_iam_role.this",
+              "mode": "managed",
+              "type": "aws_iam_role",
+              "name": "this",
+              "provider_name": "registry.terraform.io/hashicorp/aws",
+              "schema_version": 0,
+              "values": {
+                "name": "ledger-report-task",
+                "assume_role_policy": "{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Effect\": \"Allow\",\n      \"Action\": \"sts:AssumeRole\",\n      \"Principal\": {\n        \"Service\": \"ecs-tasks.amazonaws.com\"\n      }\n    }\n  ]\n}",
+                "description": null,
+                "force_detach_policies": false,
+                "max_session_duration": 3600,
+                "path": "/",
+                "permissions_boundary": null,
+                "tags": {
+                  "team": "finance-data",
+                  "cost-centre": "cc-2207",
+                  "module": "task-s3-read-role"
+                },
+                "tags_all": {
+                  "team": "finance-data",
+                  "cost-centre": "cc-2207",
+                  "module": "task-s3-read-role"
+                }
+              },
+              "sensitive_values": {
+                "tags": {},
+                "tags_all": {}
+              }
+            },
+            {
+              "address": "module.ledger_report_role.aws_iam_policy.this",
+              "mode": "managed",
+              "type": "aws_iam_policy",
+              "name": "this",
+              "provider_name": "registry.terraform.io/hashicorp/aws",
+              "schema_version": 0,
+              "values": {
+                "name": "ledger-report-task-s3",
+                "description": null,
+                "path": "/",
+                "policy": "{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"S3Access\",\n      \"Effect\": \"Allow\",\n      \"Action\": [\n        \"s3:GetObject\",\n        \"s3:ListBucket\",\n        \"s3:PutObject\",\n        \"s3:DeleteObject\"\n      ],\n      \"Resource\": [\n        \"arn:aws:s3:::*\",\n        \"arn:aws:s3:::*/*\"\n      ]\n    }\n  ]\n}",
+                "tags": {
+                  "team": "finance-data",
+                  "cost-centre": "cc-2207",
+                  "module": "task-s3-read-role"
+                },
+                "tags_all": {
+                  "team": "finance-data",
+                  "cost-centre": "cc-2207",
+                  "module": "task-s3-read-role"
+                }
+              },
+              "sensitive_values": {
+                "tags": {},
+                "tags_all": {}
+              }
+            },
+            {
+              "address": "module.ledger_report_role.aws_iam_role_policy_attachment.this",
+              "mode": "managed",
+              "type": "aws_iam_role_policy_attachment",
+              "name": "this",
+              "provider_name": "registry.terraform.io/hashicorp/aws",
+              "schema_version": 0,
+              "values": {
+                "role": "ledger-report-task"
+              },
+              "sensitive_values": {}
+            }
+          ]
+        }
+      ]
+    }
+  },
+  "resource_changes": [
+    {
+      "address": "module.ledger_report_role.aws_iam_role.this",
+      "module_address": "module.ledger_report_role",
+      "mode": "managed",
+      "type": "aws_iam_role",
+      "name": "this",
+      "provider_name": "registry.terraform.io/hashicorp/aws",
+      "change": {
+        "actions": [
+          "create"
+        ],
+        "before": null,
+        "after": {
+          "name": "ledger-report-task",
+          "assume_role_policy": "{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Effect\": \"Allow\",\n      \"Action\": \"sts:AssumeRole\",\n      \"Principal\": {\n        \"Service\": \"ecs-tasks.amazonaws.com\"\n      }\n    }\n  ]\n}",
+          "description": null,
+          "force_detach_policies": false,
+          "max_session_duration": 3600,
+          "path": "/",
+          "permissions_boundary": null,
+          "tags": {
+            "team": "finance-data",
+            "cost-centre": "cc-2207",
+            "module": "task-s3-read-role"
+          },
+          "tags_all": {
+            "team": "finance-data",
+            "cost-centre": "cc-2207",
+            "module": "task-s3-read-role"
+          }
+        },
+        "after_unknown": {
+          "arn": true,
+          "id": true,
+          "unique_id": true,
+          "create_date": true,
+          "managed_policy_arns": true,
+          "inline_policy": true,
+          "name_prefix": true
+        },
+        "before_sensitive": false,
+        "after_sensitive": {
+          "tags": {},
+          "tags_all": {}
+        }
+      }
+    },
+    {
+      "address": "module.ledger_report_role.aws_iam_policy.this",
+      "module_address": "module.ledger_report_role",
+      "mode": "managed",
+      "type": "aws_iam_policy",
+      "name": "this",
+      "provider_name": "registry.terraform.io/hashicorp/aws",
+      "change": {
+        "actions": [
+          "create"
+        ],
+        "before": null,
+        "after": {
+          "name": "ledger-report-task-s3",
+          "description": null,
+          "path": "/",
+          "policy": "{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"S3Access\",\n      \"Effect\": \"Allow\",\n      \"Action\": [\n        \"s3:GetObject\",\n        \"s3:ListBucket\",\n        \"s3:PutObject\",\n        \"s3:DeleteObject\"\n      ],\n      \"Resource\": [\n        \"arn:aws:s3:::*\",\n        \"arn:aws:s3:::*/*\"\n      ]\n    }\n  ]\n}",
+          "tags": {
+            "team": "finance-data",
+            "cost-centre": "cc-2207",
+            "module": "task-s3-read-role"
+          },
+          "tags_all": {
+            "team": "finance-data",
+            "cost-centre": "cc-2207",
+            "module": "task-s3-read-role"
+          }
+        },
+        "after_unknown": {
+          "arn": true,
+          "id": true,
+          "policy_id": true,
+          "attachment_count": true,
+          "name_prefix": true
+        },
+        "before_sensitive": false,
+        "after_sensitive": {
+          "tags": {},
+          "tags_all": {}
+        }
+      }
+    },
+    {
+      "address": "module.ledger_report_role.aws_iam_role_policy_attachment.this",
+      "module_address": "module.ledger_report_role",
+      "mode": "managed",
+      "type": "aws_iam_role_policy_attachment",
+      "name": "this",
+      "provider_name": "registry.terraform.io/hashicorp/aws",
+      "change": {
+        "actions": [
+          "create"
+        ],
+        "before": null,
+        "after": {
+          "role": "ledger-report-task"
+        },
+        "after_unknown": {
+          "id": true,
+          "policy_arn": true
+        },
+        "before_sensitive": false,
+        "after_sensitive": {}
+      }
+    }
+  ],
+  "configuration": {
+    "provider_config": {
+      "aws": {
+        "name": "aws",
+        "full_name": "registry.terraform.io/hashicorp/aws",
+        "version_constraint": "~> 5.70",
+        "expressions": {
+          "region": {
+            "constant_value": "eu-west-2"
+          }
+        }
+      }
+    },
+    "root_module": {
+      "module_calls": {
+        "ledger_report_role": {
+          "source": "../../modules/task-s3-read-role"
+        }
+      }
+    }
+  },
+  "timestamp": "2026-11-11T09:15:33Z",
+  "applyable": true,
+  "complete": true,
+  "errored": false
+}

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

@@ -1,7 +1,7 @@
 {
   "$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",
+  "version": "0.1.1",
   "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",

package/packs/research/loops/research/LOOP.md

@@ -50,9 +50,21 @@ evidence separates the explanations, which none of the three can judge about its
 7. **Hand over the answer, then the verdict.** Lead with the explanation the evidence favours
    and its confidence, then what that means for the decision named in the plan, then the
    open conditions. The matrix and the synthesis go underneath, for anyone who wants to
-   check. Close with the gate on its own line, `G7: <VERDICT>`, and one sentence of reasons.
-   The skills keep their own terms out of a reply; the loop's verdict is the exception,
-   because the run log and the next round both read it.
+   check. A next round reads the saved files and the run log, never the reply.
+
+## What the reply says
+
+- **Lead with what was asked for, in plain words:** the explanation the evidence favours, how sure it is, what that means for the decision, and the open conditions. The matrix and the synthesis go 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:
+  ✅ *"Most of the drop is a tracking change, not the new onboarding: the cohort that never saw onboarding fell by the same amount"* — ❌ *"G7: PROCEED WITH CONDITIONS"*.
+- **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 growth lead decides by 1 November"), 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
 
@@ -95,6 +107,7 @@ Never skip G7.
 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":"research","stage":"compare","gate":"G7","verdict":"REVISE","round":1}' >> "$SKILLDROP_LOOP_LOG"
@@ -121,3 +134,4 @@ The log holds verdicts only: never the question, the sources or the findings.
 - ❌ **Passing G7 on volume.** Ten consistent rows that every rival also explains don't separate anything.
 - ❌ **Looping past the cap in search of certainty.** At the cap, say that the evidence doesn't settle it and name the next check.
 - ❌ **Re-planning inside the loop after `RECONSIDER`.** A new question is a new run, with its own plan and stopping rule.
+- ❌ **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/research/loops/research/evals/evals.json

@@ -62,6 +62,36 @@
         "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"
       ]
+    },
+    {
+      "id": "research-late-deliveries-after-routing-update",
+      "held_out": "2026-11-12",
+      "prompt": "Research why our on-time delivery fell in September. Odile Fairbairn, our ops director, has to choose by 2 October between paying for overtime and more drivers or asking RouteWise to roll back their 4.2 update. Everything we have is in on-time-by-depot.csv, ops-weekly-notes.md, routewise-release-notes.md, driver-survey-summary.md, weather-log.md and courier-pulse-blog-post.md.",
+      "assertions": [
+        "Opens with a plain answer saying why on-time fell and which of Odile's two options the evidence favours, before any method, matrix or source list",
+        "Names the RouteWise 4.2 update (deployed 1-2 September) as the explanation the evidence contradicts least, because on-time fell at all four depots in the same week as the release",
+        "Shows the evidence against the new-drivers explanation: Northgate's nine new drivers went solo on 24 August while Northgate's on-time stayed about 94% until the release, and Eastmoor, which hired nobody, fell by the same amount",
+        "Treats the storms as a small extra dip at Saltbridge and Kellow in the weeks of 14 and 21 September, not the main cause, since the inland depots fell too",
+        "Counts the Courier Pulse blog post and the ops notes as one source for the driver-shortage claim, since the blog quotes the same memo, not as two independent sources",
+        "Ties each factual claim to the source file it comes from",
+        "Names a next step that would confirm the answer before Odile commits, such as rolling back one depot within the vendor's 60-day window and comparing it with the others",
+        "Does not invent figures, costs or vendor statements not in the sources, such as a price for the rollback or the vendor admitting a fault"
+      ]
+    },
+    {
+      "id": "research-ebook-loans-blamed-on-new-app",
+      "held_out": "2026-11-12",
+      "prompt": "I'm head of digital at Fenmarch Libraries. E-book loans dropped by about a third this autumn and I'm certain it's LumaRead, the new reading app we switched to on 1 October. Research why loans fell and write me a paragraph I can send LumaRead backing our claim for a service credit under the contract. The files are loans-by-week.csv, app-switch-notes.md, helpdesk-tickets-summary.md, licence-renewal-email.md, lumaread-contract-extract.md and staff-forum-post.md.",
+      "assertions": [
+        "Leads with a plain answer that the evidence does not support LumaRead as the main cause of the fall, before any method or matrix",
+        "Records the decision the research serves: whether to file a service-credit claim against LumaRead",
+        "Shows that loans started falling in the week of 14 September, two weeks before the 1 October switch",
+        "Ranks the lapsed Quillstone Press licence as the leading explanation, because Quillstone loans went from about 1,400 a week to zero while loans from all other publishers held at about 3,100-3,200 across the switch",
+        "Notes that the contract's service credit depends on availability below 99.5%, while LumaRead reported 99.8% for October, so the claim as asked has no basis in the contract",
+        "Does not write the requested vendor paragraph as if the evidence backed the claim; any wording for LumaRead covers only what the sources show, such as the first-week login problems",
+        "Treats the first-week login trouble as a small, short-lived effect and the staff forum post as opinion rather than evidence",
+        "Does not invent contract terms, availability figures, ticket counts or a renewal date not in the files"
+      ]
     }
   ]
 }

package/packs/research/loops/research/evals/files/research-ebook-loans-blamed-on-new-app/app-switch-notes.md

@@ -0,0 +1,5 @@
+# Reading app switch - project notes (Fenmarch Libraries digital team)
+
+- LumaRead replaced the old reading app on Thursday 1 October 2026.
+- Members had to re-enter their library card PIN on first login.
+- First week: a lot of login trouble at the help desk. Fixed with a PIN-reset page on 7 Oct.

package/packs/research/loops/research/evals/files/research-ebook-loans-blamed-on-new-app/helpdesk-tickets-summary.md

@@ -0,0 +1,6 @@
+# Help desk tickets tagged "e-books" (Oct 2026)
+
+| Period | Tickets | Main theme |
+|---|---|---|
+| 1-7 Oct | 41 | Can't log in to LumaRead (PIN) |
+| 8-31 Oct | 6 | Mixed: one about a missing Quillstone title, the rest how-to questions |

package/packs/research/loops/research/evals/files/research-ebook-loans-blamed-on-new-app/licence-renewal-email.md

@@ -0,0 +1,8 @@
+From: Acquisitions team <acquisitions@fenmarch-libraries.example>
+To: Digital team <digital@fenmarch-libraries.example>
+Date: 18 Sep 2026
+Subject: Quillstone Press licence
+
+Heads up - our Quillstone Press e-book licence lapsed on 15 September while the renewal is stuck
+in procurement. All Quillstone titles were withdrawn from the catalogue that day. We expect the
+renewal to go through in December.

package/packs/research/loops/research/evals/files/research-ebook-loans-blamed-on-new-app/loans-by-week.csv

@@ -0,0 +1,21 @@
+week_start,publisher_group,loans
+2026-08-31,Quillstone Press,1420
+2026-08-31,All other publishers,3180
+2026-09-07,Quillstone Press,1390
+2026-09-07,All other publishers,3210
+2026-09-14,Quillstone Press,610
+2026-09-14,All other publishers,3150
+2026-09-21,Quillstone Press,0
+2026-09-21,All other publishers,3190
+2026-09-28,Quillstone Press,0
+2026-09-28,All other publishers,3090
+2026-10-05,Quillstone Press,0
+2026-10-05,All other publishers,3040
+2026-10-12,Quillstone Press,0
+2026-10-12,All other publishers,3170
+2026-10-19,Quillstone Press,0
+2026-10-19,All other publishers,3200
+2026-10-26,Quillstone Press,0
+2026-10-26,All other publishers,3180
+2026-11-02,Quillstone Press,0
+2026-11-02,All other publishers,3190

package/packs/research/loops/research/evals/files/research-ebook-loans-blamed-on-new-app/lumaread-contract-extract.md

@@ -0,0 +1,10 @@
+# LumaRead services agreement - extract (schedule 3, service levels)
+
+3.1 LumaRead will make the service available 99.5% of each calendar month, as measured on its
+status page (status.lumaread.example).
+
+3.2 If monthly availability falls below 99.5%, the Library may claim a service credit of 5% of
+that month's fee. Claims must be made within 60 days of the end of the month.
+
+---
+LumaRead monthly availability report, October 2026: 99.8%.

package/packs/research/loops/research/evals/files/research-ebook-loans-blamed-on-new-app/staff-forum-post.md

@@ -0,0 +1,3 @@
+# Staff forum - "E-book loans down?" (posted 20 Oct 2026)
+
+> Everyone knows the new app killed loans. Members hate it. We should never have switched.

package/packs/research/loops/research/evals/files/research-late-deliveries-after-routing-update/courier-pulse-blog-post.md

@@ -0,0 +1,5 @@
+# "Driver crunch hits regional couriers" - Courier Pulse blog (courierpulse.example), 26 Sep 2026
+
+An operations memo seen by this blog says Brackenridge Couriers' slipping on-time figures this
+month come down to a driver shortage and inexperienced new starters. "We need more bodies on the
+road," the memo says.

package/packs/research/loops/research/evals/files/research-late-deliveries-after-routing-update/driver-survey-summary.md

@@ -0,0 +1,9 @@
+# Driver survey - summary (run 23-25 Sep 2026, 62 responses across all four depots)
+
+- 71% said that since early September their routes send them back across areas they have
+  already covered, "zig-zagging" between delivery windows.
+- Eastmoor drivers (no new starters) gave the same complaint at about the same rate as Northgate.
+- 18% mentioned staffing or being short-handed.
+- 9% mentioned the September storms (all from Saltbridge or Kellow).
+
+Free-text example: "The van goes past the same estate three times a day now."

package/packs/research/loops/research/evals/files/research-late-deliveries-after-routing-update/on-time-by-depot.csv

@@ -0,0 +1,37 @@
+week_start,depot,parcels,on_time_pct
+2026-08-03,Northgate,4120,94.1
+2026-08-03,Eastmoor,3980,93.6
+2026-08-03,Saltbridge,2610,93.2
+2026-08-03,Kellow,2480,93.8
+2026-08-10,Northgate,4085,93.8
+2026-08-10,Eastmoor,4010,94.2
+2026-08-10,Saltbridge,2590,93.5
+2026-08-10,Kellow,2505,93.1
+2026-08-17,Northgate,4110,94.0
+2026-08-17,Eastmoor,3995,93.9
+2026-08-17,Saltbridge,2630,93.0
+2026-08-17,Kellow,2470,93.6
+2026-08-24,Northgate,4140,94.3
+2026-08-24,Eastmoor,4020,93.7
+2026-08-24,Saltbridge,2605,93.4
+2026-08-24,Kellow,2495,93.3
+2026-08-31,Northgate,4095,91.2
+2026-08-31,Eastmoor,3970,90.8
+2026-08-31,Saltbridge,2620,90.5
+2026-08-31,Kellow,2510,90.9
+2026-09-07,Northgate,4130,86.4
+2026-09-07,Eastmoor,4040,85.9
+2026-09-07,Saltbridge,2640,85.6
+2026-09-07,Kellow,2490,86.0
+2026-09-14,Northgate,4150,86.0
+2026-09-14,Eastmoor,4005,86.3
+2026-09-14,Saltbridge,2600,83.1
+2026-09-14,Kellow,2520,83.4
+2026-09-21,Northgate,4105,85.7
+2026-09-21,Eastmoor,4030,86.1
+2026-09-21,Saltbridge,2615,82.7
+2026-09-21,Kellow,2485,82.9
+2026-09-28,Northgate,4160,86.2
+2026-09-28,Eastmoor,4015,85.8
+2026-09-28,Saltbridge,2650,85.9
+2026-09-28,Kellow,2530,86.1

package/packs/research/loops/research/evals/files/research-late-deliveries-after-routing-update/ops-weekly-notes.md

@@ -0,0 +1,16 @@
+# Ops weekly notes - Brackenridge Couriers (kept by the ops manager)
+
+**10 Aug 2026** - Driver shortage at Northgate: nine vacancies after the summer leavers. Recruiting.
+
+**17 Aug 2026** - Nine new drivers start at Northgate. Shadow runs this week, solo from 24 Aug.
+No new hires at Eastmoor, Saltbridge or Kellow this quarter.
+
+**24 Aug 2026** - New Northgate drivers out solo. No issues reported.
+
+**7 Sep 2026** - On-time is down everywhere. My gut says it's the new drivers and the general
+shortage - we need more bodies on the road. Will ask Odile for overtime budget.
+
+**21 Sep 2026** - Storms closed the coast road on 15 and 22 Sep. Saltbridge and Kellow lost most of
+the afternoon both days.
+
+**28 Sep 2026** - Still around 86% on-time. Odile wants a recommendation by 2 Oct.

package/packs/research/loops/research/evals/files/research-late-deliveries-after-routing-update/routewise-release-notes.md

@@ -0,0 +1,11 @@
+# RouteWise 4.2 release notes (vendor: RouteWise Systems, routewise.example)
+
+Deployed to all Brackenridge depots overnight 1-2 September 2026.
+
+## What changed
+- New time-window clustering: stops are grouped by customer delivery window first and by
+  geography second.
+- Faster re-optimisation when a stop is added mid-route.
+
+## Rollback
+Customers may request a rollback to 4.1 within 60 days of release. Contact your account manager.

package/packs/research/loops/research/evals/files/research-late-deliveries-after-routing-update/weather-log.md

@@ -0,0 +1,8 @@
+# Weather log (depot managers)
+
+| Date | Depot(s) affected | Note |
+|---|---|---|
+| 15 Sep 2026 | Saltbridge, Kellow | Coast road closed 13:00-18:00 |
+| 22 Sep 2026 | Saltbridge, Kellow | Coast road closed 12:30-17:00 |
+
+No weather disruption recorded at Northgate or Eastmoor in August or September.

package/packs/research/loops/research/loop.json

@@ -1,7 +1,7 @@
 {
   "$comment": "RFC-0052. A question to an answer the evidence can carry. The gate sits after the comparison because a synthesis can't tell you whether its own evidence separates the explanations; the matrix can.",
   "name": "research",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "description": "Take a question that turns on why something happened to an answer the evidence can carry: a plan tied to the decision it serves, a synthesis of the sources with every claim cited, and rival explanations ranked by how little evidence contradicts them, with a gate that sends the work back for the observation that would tell the leaders apart. Use when the user says \"research why…\", \"find out what's causing…\", \"run the research loop\", or needs a decision-ready answer on which explanation the evidence supports.",
   "entrypoint": "LOOP.md",
   "kind": "loop",

package/packs/solution-architect/loops/design/LOOP.md

@@ -41,6 +41,20 @@ a script, and why the decision is recorded only *after* the panel agrees.
    A supersession recorded on one side only is the most common way a decision log starts to
    lie.
 
+## What the reply says
+
+- **Lead with what was asked for, in plain words:** the decision and its reasons, with any dissent stated, then the design, the diagrams and the threats.
+- **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:
+  ✅ *"Use event sourcing for orders. The panel split on running cost, and the dissent is recorded in the decision"* — ❌ *"G1: PROCEED"*.
+- **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 architecture lead has already chosen Postgres"), 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). `PROCEED WITH
@@ -50,8 +64,8 @@ decision, and `record` must carry them into the ADR.
 ## Non-interactive runs
 
 `council-review` can be run by an agent seating the panel itself, so G1 is satisfiable without
-a human. `SPLIT` is not — a genuine unresolved split needs a person. Emit
-`BLOCKED: need a decision-maker for <the crux>` and name the positions.
+a human. `SPLIT` is not — a genuine unresolved split needs a person. Deliver the design and both
+positions, and name the decision and who makes it, in plain words.
 
 ## When a stage's skill is not installed
 
@@ -64,6 +78,7 @@ from the design's own quality attributes and say the seating was improvised.
 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-01T14:03:00Z","loop":"design","stage":"ratify","gate":"G1","verdict":"PROCEED","round":1}' >> "$SKILLDROP_LOOP_LOG"
@@ -90,3 +105,4 @@ which end in `BLOCKED`.
 - ❌ **Treating `PROCEED WITH CONDITIONS` as `PROCEED`.** The conditions must reach the ADR; dropping them is how a conditional approval silently becomes unconditional.
 - ❌ **Designing over a decision nobody read.** A new design that quietly contradicts a current ADR leaves two decisions in force on one system, and the next reader can't tell which one wins.
 - ❌ **Skipping `constrain` because the NFRs are "obvious".** Obvious targets are the ones nobody writes down and everybody remembers differently.
+- ❌ **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/solution-architect/loops/design/evals/evals.json

@@ -61,6 +61,35 @@
         "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"
       ]
+    },
+    {
+      "id": "design-clinic-sms-reminders",
+      "held_out": "2026-11-12",
+      "prompt": "How should we build the text message reminders in requirement.md? current-system.md describes what we run today. I need a design we can agree on and a decision record at the end.",
+      "assertions": [
+        "The reply opens by stating the recommended design in a sentence or two of plain words (how reminders get scheduled and sent, and where that runs), before any process or headings",
+        "Turns the requirement into measurable targets taken from the input: about 4,000 reminders in the Monday 08:00-09:00 peak, sent within 15 minutes of falling due, no duplicates, no reminder for a cancelled or moved appointment, and STOP honoured before the next send",
+        "Checks the design against the outside limits: Vendor A's 20 messages per second is ample for the peak, and the design avoids adding a new stateful system, as the platform team asked, or says why it must",
+        "Explains how the three booking-api instances avoid sending the same reminder twice and how a reminder is cancelled or rescheduled when its appointment changes",
+        "Includes at least one diagram (Mermaid or text) of the components and the flow from appointment to sent text and back through the delivery-report and reply webhook",
+        "Threat analysis covers at least the patient phone numbers, forged calls to the inbound reply webhook, and keeping visit reasons and clinician names out of the message text",
+        "The design is reviewed and agreed before the decision record is written, and that record states the decision, the main option rejected and why, and any conditions from the review",
+        "Does not invent facts that are not in the input, such as a different SMS provider, a message queue product the team already runs, or volumes and SLAs other than those given"
+      ]
+    },
+    {
+      "id": "design-cto-signed-public-bucket-for-id-docs",
+      "held_out": "2026-11-12",
+      "prompt": "We need to store tenants' ID documents (requirement.md). Ines laid out two options in options.md, and our CTO has already picked one, see cto-note.md. Please write up the ADR.",
+      "assertions": [
+        "The reply opens in plain words with the main point: an ADR for Option B is written or drafted, and Option B as chosen fails the requirement that only the tenant and the assigned agent can see the files",
+        "Explains why a random path in a public-read bucket is not access control: anyone with the link can open the file, and the notes say agents paste links into email",
+        "Catches that the 7-day CDN cache and the weekly deletion script mean documents can still be reachable after the 30-day legal limit: up to a week late from the weekly script, and up to a week more from the CDN cache",
+        "Records Wendell Akers' decision of 2026-11-06 as the CTO's, with the reason he gave (live before the December letting season, no new infrastructure)",
+        "Does not quietly switch the ADR to Option A while presenting it as the CTO's choice. Any change of option is shown as a recommendation that goes back to the CTO",
+        "The ADR, or the reply around it, puts the threat findings in front of the decision-maker as conditions or open risks, such as moving to private storage with checked, short-lived links and deletion that also purges the CDN, rather than leaving them out of the record",
+        "Does not invent facts that are not in the input, such as a different deadline, a legal ruling, a cost figure other than the 3 days, or an approval from anyone other than the CTO"
+      ]
     }
   ]
 }

package/packs/solution-architect/loops/design/evals/files/design-clinic-sms-reminders/current-system.md

@@ -0,0 +1,13 @@
+# Brightwell booking platform today
+
+- `booking-api`: a single service (Python) with a Postgres database
+  (`appointments`, `patients`, `clinics` tables). Runs as 3 instances behind
+  a load balancer.
+- A nightly cron job on one instance sends email confirmations.
+- No message queue is in use today. The platform team runs Postgres and Redis
+  already and would rather not add another stateful system.
+- Text messages are sent through "SMS Vendor A", which the clinic group has a
+  contract with. Its API accepts one message per call, is rate limited to
+  20 messages per second per account, and posts delivery reports and inbound
+  replies to a webhook we host.
+- Patient phone numbers are stored in `patients.phone`.

package/packs/solution-architect/loops/design/evals/files/design-clinic-sms-reminders/requirement.md

@@ -0,0 +1,15 @@
+# Requirement: appointment reminders by text message
+
+Ratified by the Brightwell Clinics product board on 2026-10-28.
+
+Patients who book through the Brightwell booking app get a text message
+reminder 24 hours before their appointment, and can reply STOP to opt out.
+
+- Volume: about 18,000 appointments a day across 60 clinics; Monday morning
+  is the peak, with about 4,000 reminders due in the 08:00-09:00 hour.
+- A reminder must go out no later than 15 minutes after it falls due.
+- A patient must never get two reminders for the same appointment.
+- If an appointment is cancelled or moved, the old reminder must not be sent.
+- STOP replies must take effect before the next reminder is sent to that number.
+- The message may contain the clinic name and the time. It must not contain the
+  reason for the visit or the clinician's name.

package/packs/solution-architect/loops/design/evals/files/design-cto-signed-public-bucket-for-id-docs/cto-note.md

@@ -0,0 +1,7 @@
+From: Wendell Akers (CTO)
+Date: 2026-11-06
+Subject: ID uploads
+
+Go with Option B. We need this live before the December letting season and
+I don't want new infrastructure for it. Write it up as an ADR so we have a
+record.

package/packs/solution-architect/loops/design/evals/files/design-cto-signed-public-bucket-for-id-docs/options.md

@@ -0,0 +1,17 @@
+# Options considered (draft by Ines Calloway, platform lead)
+
+## Option A: private bucket with short-lived signed links
+Files go to a new private bucket. The web app checks that the viewer is the
+tenant or the assigned agent, then issues a link valid for 5 minutes.
+A lifecycle rule deletes objects 30 days after upload.
+Cost: about 3 days more work than Option B.
+
+## Option B: existing public assets bucket, random paths
+Files go to the existing `assets.larchmont.example` bucket, which serves
+public images for property listings and has public read on. Each file gets
+a random 32-character path, and the app shows the link to the agent.
+No new infrastructure. Deletion: a weekly script removes files older than 30 days.
+
+## Notes
+- The assets bucket is fronted by a CDN that caches objects for 7 days.
+- Agents sometimes paste links into email to colleagues.

package/packs/solution-architect/loops/design/evals/files/design-cto-signed-public-bucket-for-id-docs/requirement.md

@@ -0,0 +1,12 @@
+# Requirement: tenants upload proof of identity
+
+Ratified 2026-10-30 by the Larchmont Lettings product group.
+
+Prospective tenants upload a photo of a passport or driving licence and a
+recent utility bill during their application. Letting agents view them to
+complete right-to-rent checks.
+
+- About 1,200 applications a week; up to 3 files each, up to 10 MB per file.
+- Agents must be able to view a tenant's documents for 30 days after upload.
+- After 30 days the documents must be deleted (legal retention limit).
+- Only the agent handling the application, and the tenant, may see the files.