skilldrop-cli 1.13.0 → 1.14.0

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.

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

@@ -1,7 +1,7 @@
 {
   "$comment": "RFC-0028. The loop with the worst reversibility profile: a design mistake surfaces months later in code nobody wants to unwind. That is why its gate is a panel, not a script.",
   "name": "design",
-  "version": "0.3.0",
+  "version": "0.3.1",
   "description": "Take a ratified requirement to a recorded architectural decision — constraints, structure, diagrams, threats, then a panel that must agree before the decision is written down. Use when the user is designing a system, choosing an architecture, or asking how something should be built.",
   "entrypoint": "LOOP.md",
   "kind": "loop",