@bendyline/gilde 0.1.27 → 0.1.28

package/data/craftbook-templates/au/auth-flow/versions/1.0.1/test.json

@@ -0,0 +1,140 @@
+{
+  "schemaVersion": 1,
+  "title": "Secure auth-flow module",
+  "objective": "Measure whether the auth-flow craftbook scopes threats before writing a password/session flow with basic security controls.",
+  "tags": [
+    "code"
+  ],
+  "prompt": "In the `Auth Flow Eval` project, write `src/auth.js`: a small dependency-free ESM module for a session-based email/password login flow. Include registration, login, logout, session creation/validation, password hashing with Node crypto pbkdf2 or scrypt, CSRF token generation/validation, rate-limit bookkeeping, and safe error messages. Also write `notes/review.md` with a concise security review that covers password storage, session expiry, CSRF, rate limiting, and what is intentionally out of scope. Do not use live network services or real credentials.",
+  "setup": {
+    "projectName": "Auth Flow Eval",
+    "about": "Self-contained eval project for auth-flow. Deliverables are workspace/src/auth.js and workspace/notes/review.md.",
+    "missionObjectives": "Build a small local auth module and a threat/security review covering storage, sessions, CSRF, and rate limiting.",
+    "files": [],
+    "worker": {
+      "name": "Sander",
+      "role": "Developer"
+    }
+  },
+  "mocks": [],
+  "success": {
+    "summary": "src/auth.js implements a local auth module and notes/review.md covers the required security controls.",
+    "deliverables": [
+      {
+        "path": "src/auth.js",
+        "kind": "code-module",
+        "minBytes": 1800,
+        "checks": [
+          {
+            "kind": "contains",
+            "file": "src/auth.js",
+            "pattern": "pbkdf2|scrypt|crypto",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "src/auth.js",
+            "pattern": "register",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "src/auth.js",
+            "pattern": "login",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "src/auth.js",
+            "pattern": "logout",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "src/auth.js",
+            "pattern": "session",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "src/auth.js",
+            "pattern": "csrf",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "src/auth.js",
+            "pattern": "rate|attempt",
+            "flags": "i"
+          }
+        ]
+      },
+      {
+        "path": "notes/review.md",
+        "kind": "markdown-notes",
+        "minBytes": 350,
+        "checks": [
+          {
+            "kind": "contains",
+            "file": "notes/review.md",
+            "pattern": "(?:^|\\n)#{1,3}\\s+\\S",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "notes/review.md",
+            "pattern": "password|hash",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "notes/review.md",
+            "pattern": "session|expiry|expiration",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "notes/review.md",
+            "pattern": "csrf",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "notes/review.md",
+            "pattern": "rate limit|rate-limit|attempt",
+            "flags": "i"
+          }
+        ]
+      }
+    ]
+  },
+  "rubric": {
+    "artifact": {
+      "path": "src/auth.js",
+      "kind": "typescript"
+    },
+    "axes": [
+      {
+        "name": "correctness",
+        "description": "The module does what the requirements ask, with sensible edge handling."
+      },
+      {
+        "name": "verification",
+        "description": "Self-tests exercise real behavior, not trivial truths."
+      },
+      {
+        "name": "clarity",
+        "description": "Exports, naming, and structure make the module usable without reading every line."
+      },
+      {
+        "name": "robustness",
+        "description": "Invalid input and boundary cases fail loudly rather than silently."
+      }
+    ]
+  },
+  "qualityFocus": [
+    "security scoping",
+    "session flow",
+    "review notes"
+  ]
+}

package/data/craftbook-templates/au/automation-recipe/versions/1.0.1/craftbook.json

@@ -0,0 +1,164 @@
+{
+  "id": "automation-recipe",
+  "name": "Write an Automation Recipe",
+  "description": "Turn 'I wish the house would...' into an inspectable, versioned automation: triggers and actions that name real devices from the house's own inventory, a dry run through the device tools before anything is armed, and a manual override always written in. Locks the owner's intent and the safety rules FIRST (nothing that heats or locks runs unattended without a failsafe, an override path is mandatory, dry-run before arm), then drafts the recipe, then proves it against the devices — so the house only ever does what was actually asked, and never anything it cannot be talked out of. Use for home automations, 'make the lights do X', schedules and scenes, sensor-triggered routines, and wiring up a new smart-home behavior.\n\nA gallery craftbook generated from an archetype spec. It runs\n`phase → (per-phase gate) → … → evaluate → (loop) → finish`. Each build\nphase that produces a checkable artifact is followed by a **runtime\ngate-checkpoint** — the runtime verifies the artifact and routes with no\nmodel turn, looping back to redo the phase on a miss. The final `evaluate`\nstep holds a static deliverable gate plus a reviewer QA pass. What it adds\nover the generic `build-loop`: a specialist role per phase, a\ndomain-correct ordering, and a concrete per-phase quality bar.\n\nDeliverables marked \"artifact\" land in the project's artifacts drawer (`write_artifact` / `read_artifact`), not the shipped workspace — review output is not product source.\n\nPhases:\n\n1. Scope the wish (huisautomaat) — the owner's intent, the real device inventory, and the safety rules locked → gated on artifact `notes/scope.md` (markdown-notes)\n2. Draft the recipe (developer) — the automation as one inspectable JSON file under automations/\n3. Dry-run the recipe (developer) — every trigger and action exercised against the devices, evidence on file → gated on artifact `notes/dry-run.md` (markdown-notes)\n4. Write the install notes (copywriter) — what it does, how to arm it, how to stop it, what the dry run proved → gated on artifact `report.md` (markdown-report)\n\nThe gates never advance with an unmet criterion, and loop back to the\nowning phase to fix named gaps.\n",
+  "entryStepId": "scope",
+  "triggers": [
+    "set up an automation",
+    "make the house do",
+    "automate the lights",
+    "write an automation recipe",
+    "when I get home, turn on"
+  ],
+  "steps": [
+    {
+      "id": "scope",
+      "name": "Scope the wish",
+      "description": "the owner's intent, the real device inventory, and the safety rules locked",
+      "prompt": "Understand the wish and the house before writing a single trigger. Step 1: restate the owner's intent in one plain sentence — when should what happen, and when should it NOT — and confirm it with them if anything is ambiguous. Step 2: pull the device inventory through the project's home capabilities and list the devices this automation actually needs: the sensors that will trigger it, the devices it will act on, each with its exact inventory id and current state. If a device the wish assumes does not exist in the inventory, say so now — never plan around an invented device. Step 3: lock the safety rules — nothing that heats, locks, or opens runs unattended without a stated failsafe; every automation carries a manual override the owner can flip without ceremony; and no recipe is armed before a dry run has exercised it against the devices. Step 4: write an acceptance-criteria checklist ('every device in the recipe exists in the inventory, by exact id', 'trigger, conditions, and actions are all present and specific', 'a manual override is written into the recipe', 'the dry run exercised every action with the tool responses recorded', 'the install notes say how to arm it and how to stop it'). Call write_task_note with the intent sentence + the devices involved + the checklist and write notes/scope.md.\n\nThe deliverable `notes/scope.md` lands in the project's artifacts drawer — write it with `write_artifact` and read it back with `read_artifact`; the shipped workspace stays untouched.",
+      "suggestedRole": "huisautomaat",
+      "advanceWhen": {
+        "file": "notes/scope.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "notes/scope.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "notes/scope.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "scope",
+        "maxAttempts": 3
+      },
+      "next": "draft"
+    },
+    {
+      "id": "draft",
+      "name": "Draft the recipe",
+      "description": "the automation as one inspectable JSON file under automations/",
+      "prompt": "Write the automation down as a file someone can read, diff, and version. Step 1: derive a short lowercase-kebab slug from the automation's name and write the recipe to automations/<slug>.json — one JSON object with a name, a plain-language summary, the trigger (what starts it), the conditions (what must also be true), the actions (what happens, in order), and the override (how a human stops or bypasses it, always present). Step 2: reference every device by its exact inventory id from notes/scope.md — the id the house actually answers to, not a nickname. Step 3: keep every field concrete: a trigger names its sensor and the state change, a condition names what it checks, an action names the device and the state it sets. Step 4: re-read the file once as JSON — valid, complete, no placeholder values left. Call write_task_note with the recipe path and a one-line description of trigger, conditions, actions, and override.\n\nBefore working, open the artifact input `notes/scope.md` with `read_artifact`; do not look for it in the workspace.",
+      "suggestedRole": "developer",
+      "consumes": [
+        {
+          "file": "notes/scope.md",
+          "artifact": true
+        }
+      ],
+      "next": "dryrun"
+    },
+    {
+      "id": "dryrun",
+      "name": "Dry-run the recipe",
+      "description": "every trigger and action exercised against the devices, evidence on file",
+      "prompt": "Prove the recipe against the real device inventory before anyone arms it. Step 1: for every device the recipe references, read its current state through the project's home capabilities and confirm the device answers — a device that does not exist or does not respond sends you back to the draft, not onward. Step 2: exercise each action through the device tools' dry-run path, so the intended state change is checked without actually switching anything in the house. Step 3: record the evidence in notes/dry-run.md — for each device: its id, the state you read, the dry-run response you got, verbatim — plus a short verdict per action (would fire as intended, or what was off). Step 4: if any action came back wrong, fix the recipe first and dry-run again; the notes must describe the run that matches the final recipe. Call write_task_note with the device count exercised and the verdict.\n\nThe deliverable `notes/dry-run.md` lands in the project's artifacts drawer — write it with `write_artifact` and read it back with `read_artifact`; the shipped workspace stays untouched.",
+      "suggestedRole": "developer",
+      "advanceWhen": {
+        "file": "notes/dry-run.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "notes/dry-run.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "notes/dry-run.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "dryrun",
+        "maxAttempts": 3
+      },
+      "next": "report"
+    },
+    {
+      "id": "report",
+      "name": "Write the install notes",
+      "description": "what it does, how to arm it, how to stop it, what the dry run proved",
+      "prompt": "Write the install notes the owner will actually read. Step 1: open with one warm paragraph saying what the automation does and when — the intent sentence from notes/scope.md, in the owner's language. Step 2: list the devices it touches, each with its friendly name and inventory id, and where the recipe file lives. Step 3: say how to arm it and — just as prominently — how to stop or override it: the manual override path from the recipe, spelled out so it works at 2am. Step 4: summarize what the dry run proved, citing the evidence in notes/dry-run.md — which devices answered, which actions were exercised, and that nothing was actually switched. Step 5: close with what to watch the first week and the one or two ways this automation could misbehave (the safety rules from scope, made concrete). Write report.md and call write_task_note with a one-line DONE summary.\n\nBefore working, open the artifact inputs `notes/scope.md`, `notes/dry-run.md` with `read_artifact`; do not look for them in the workspace.\n\nThe deliverable `report.md` lands in the project's artifacts drawer — write it with `write_artifact` and read it back with `read_artifact`; the shipped workspace stays untouched.",
+      "suggestedRole": "copywriter",
+      "consumes": [
+        {
+          "file": "notes/scope.md",
+          "artifact": true
+        },
+        {
+          "file": "notes/dry-run.md",
+          "artifact": true
+        }
+      ],
+      "advanceWhen": {
+        "file": "report.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "report.md",
+            "bytes": 800,
+            "artifact": true
+          },
+          {
+            "kind": "contains",
+            "file": "report.md",
+            "pattern": "(?:^|\\n)#{1,3}\\s+\\S",
+            "flags": "i",
+            "label": "at least one markdown heading",
+            "artifact": true
+          }
+        ],
+        "onReject": "report",
+        "maxAttempts": 4
+      },
+      "next": "evaluate"
+    },
+    {
+      "id": "evaluate",
+      "name": "Evaluate",
+      "description": "Grade the deliverable against every acceptance criterion. All pass → finish; any fail → loop back and fix the gap.",
+      "prompt": "Open automations/, notes/dry-run.md, report.md, and notes/scope.md and verify every criterion from the checklist: the recipe file parses as JSON and carries a trigger, conditions, actions, and a manual override; every device id in the recipe appears in the inventory evidence gathered during scope and dry-run — no invented devices; the dry-run notes show every action exercised with real tool responses recorded, not paraphrased; and the install notes say how to arm the automation, how to stop it, and what the dry run proved. Write PASS/FAIL per criterion; on any failure, name the field or device that is wrong and loop back to draft.\n\nThe deliverable lives in the project's artifacts drawer — open `report.md` with `read_artifact`, not `read_file`.\n\nThen route — this is the whole point of the loop:\n\n- **Every criterion PASSES →** call `advance_task_step({ ref, stepId: \"evaluate\", next: \"finish\" })`.\n- **Any criterion FAILS →** write the specific gaps to notes, then call `advance_task_step({ ref, stepId: \"evaluate\", next: \"draft\" })` to loop back. The builder fixes exactly those gaps.\n\nNever route to `finish` while any criterion is unmet. The build phase's completion gate already blocked a grossly-incomplete deliverable; your job is the judgment an automated check cannot make (does it actually work, read well, look right). After ~3 unproductive loops, stop and report DONE_WITH_CONCERNS so the user can step in.",
+      "suggestedRole": "reviewer",
+      "consumes": [
+        {
+          "file": "report.md",
+          "artifact": true
+        }
+      ],
+      "next": "draft"
+    },
+    {
+      "id": "finish",
+      "name": "Finish",
+      "description": "All acceptance criteria met. Stamp a short summary and report DONE.",
+      "prompt": "Every acceptance criterion passed. Write a one-paragraph DONE summary to task notes via `write_task_note`: what was built, the deliverable path(s), and a one-line confirmation that each criterion is met. Then report DONE.",
+      "suggestedRole": "developer",
+      "terminal": true
+    }
+  ],
+  "version": "1.0.1",
+  "releasedAt": "2026-08-14T00:00:00Z"
+}

package/data/craftbook-templates/au/automation-recipe/versions/1.0.1/test.json

@@ -0,0 +1,296 @@
+{
+  "schemaVersion": 1,
+  "title": "Write an Automation Recipe smoke eval",
+  "objective": "Task-specific eval for the Write an Automation Recipe craftbook: a porch-light-at-sunset wish becomes a versioned JSON recipe grounded in the live fake-house inventory, dry-run through the wired device tools before anything would be armed, with a manual override written in and install notes that say how to stop it.",
+  "tags": [
+    "external"
+  ],
+  "prompt": "can you set up an automation so the porch light comes on at sunset when someones home? dry run it first plaese - i dont want anything actually switching yet",
+  "setup": {
+    "projectName": "Smart Home — Automation Recipe Eval",
+    "about": "Self-contained eval project for automation-recipe. The fake house's device tools are wired into the project's tool roster — the live inventory and device states come from them, and their state-setting path runs dry-run only in this eval, so nothing actually switches. A cached inventory snapshot from last night is on file at home/devices.json for reference; the live tools are authoritative. The recipe goes to automations/porch-light.json, the dry-run evidence to notes/dry-run.md, and the install notes to report.md.",
+    "missionObjectives": "Use the Write an Automation Recipe craftbook/template, ground every device reference in the live inventory read through the wired device tools, exercise the recipe in dry-run before anything would be armed, and deliver automations/porch-light.json plus report.md. No real smart-home services, hubs, or credentials — only the wired fake house.",
+    "files": [
+      {
+        "path": "home/devices.json",
+        "content": "{\n  \"note\": \"cached inventory snapshot - the live device tools are authoritative\",\n  \"generatedAt\": \"2026-07-18T22:30:00Z\",\n  \"devices\": [\n    { \"id\": \"dev-01\", \"name\": \"porch light\", \"zone\": \"outside\", \"type\": \"light\", \"state\": \"off\" },\n    { \"id\": \"dev-02\", \"name\": \"front hall presence sensor\", \"zone\": \"hall\", \"type\": \"presence\", \"state\": \"home\" },\n    { \"id\": \"dev-03\", \"name\": \"living room thermostat\", \"zone\": \"living room\", \"type\": \"thermostat\", \"state\": \"heat 19.5C\" },\n    { \"id\": \"dev-04\", \"name\": \"garage door\", \"zone\": \"garage\", \"type\": \"cover\", \"state\": \"closed\" },\n    { \"id\": \"dev-05\", \"name\": \"kitchen ceiling light\", \"zone\": \"kitchen\", \"type\": \"light\", \"state\": \"off\" },\n    { \"id\": \"dev-06\", \"name\": \"bedroom lamp\", \"zone\": \"bedroom\", \"type\": \"light\", \"state\": \"off\" },\n    { \"id\": \"dev-07\", \"name\": \"front door lock\", \"zone\": \"hall\", \"type\": \"lock\", \"state\": \"locked\" },\n    { \"id\": \"dev-08\", \"name\": \"backyard motion sensor\", \"zone\": \"outside\", \"type\": \"motion\", \"state\": \"clear\", \"battery\": 82 }\n  ]\n}\n"
+      }
+    ],
+    "worker": {
+      "name": "Daan",
+      "role": "Huisautomaat"
+    }
+  },
+  "mocks": [
+    {
+      "kind": "mcp",
+      "id": "home",
+      "description": "Fake smart-home MCP for this eval. Its tools surface directly on the tool roster: list the house's device inventory, read the current device states, and request a state change — state changes always run as a dry run here, validated and echoed back but never applied.",
+      "tools": [
+        {
+          "name": "list_devices",
+          "description": "List every device in the house with its id, name, zone, type, and current state",
+          "resultTemplate": {
+            "devices": [
+              {
+                "id": "dev-01",
+                "name": "porch light",
+                "zone": "outside",
+                "type": "light",
+                "state": "off"
+              },
+              {
+                "id": "dev-02",
+                "name": "front hall presence sensor",
+                "zone": "hall",
+                "type": "presence",
+                "state": "home"
+              },
+              {
+                "id": "dev-03",
+                "name": "living room thermostat",
+                "zone": "living room",
+                "type": "thermostat",
+                "state": "heat 19.5C"
+              },
+              {
+                "id": "dev-04",
+                "name": "garage door",
+                "zone": "garage",
+                "type": "cover",
+                "state": "closed"
+              },
+              {
+                "id": "dev-05",
+                "name": "kitchen ceiling light",
+                "zone": "kitchen",
+                "type": "light",
+                "state": "off"
+              },
+              {
+                "id": "dev-06",
+                "name": "bedroom lamp",
+                "zone": "bedroom",
+                "type": "light",
+                "state": "off"
+              },
+              {
+                "id": "dev-07",
+                "name": "front door lock",
+                "zone": "hall",
+                "type": "lock",
+                "state": "locked"
+              },
+              {
+                "id": "dev-08",
+                "name": "backyard motion sensor",
+                "zone": "outside",
+                "type": "motion",
+                "state": "clear",
+                "battery": 82
+              }
+            ]
+          }
+        },
+        {
+          "name": "get_state",
+          "description": "Read the current state snapshot of the house's devices",
+          "resultTemplate": {
+            "asOf": "2026-07-19T17:55:00Z",
+            "states": [
+              {
+                "id": "dev-01",
+                "name": "porch light",
+                "state": "off",
+                "reachable": true
+              },
+              {
+                "id": "dev-02",
+                "name": "front hall presence sensor",
+                "state": "home",
+                "reachable": true
+              },
+              {
+                "id": "dev-03",
+                "name": "living room thermostat",
+                "state": "heat 19.5C",
+                "reachable": true
+              },
+              {
+                "id": "dev-04",
+                "name": "garage door",
+                "state": "closed",
+                "reachable": true
+              },
+              {
+                "id": "dev-05",
+                "name": "kitchen ceiling light",
+                "state": "off",
+                "reachable": true
+              },
+              {
+                "id": "dev-06",
+                "name": "bedroom lamp",
+                "state": "off",
+                "reachable": true
+              },
+              {
+                "id": "dev-07",
+                "name": "front door lock",
+                "state": "locked",
+                "reachable": true
+              },
+              {
+                "id": "dev-08",
+                "name": "backyard motion sensor",
+                "state": "clear",
+                "battery": 82,
+                "reachable": true
+              }
+            ]
+          }
+        },
+        {
+          "name": "set_state",
+          "description": "Request a device state change; in this eval every request runs as a dry run — validated and echoed back, never applied",
+          "resultTemplate": {
+            "ok": true,
+            "mode": "dry-run",
+            "applied": false,
+            "note": "dry run only: the request was validated and recorded; no device state was changed"
+          }
+        }
+      ]
+    }
+  ],
+  "success": {
+    "summary": "automations/porch-light.json is a valid recipe whose trigger, conditions, actions, and manual override name only devices from the live inventory (the inventory was actually listed and the action path actually exercised in dry-run — request-log assertions), and report.md says how to arm it, how to stop it, and what the dry run proved.",
+    "deliverables": [
+      {
+        "path": "automations/porch-light.json",
+        "kind": "json",
+        "checks": [
+          {
+            "kind": "sniff",
+            "file": "automations/porch-light.json",
+            "sniff": "json-valid"
+          },
+          {
+            "kind": "contains",
+            "file": "automations/porch-light.json",
+            "pattern": "trigger",
+            "flags": "i",
+            "label": "the recipe declares its trigger"
+          },
+          {
+            "kind": "contains",
+            "file": "automations/porch-light.json",
+            "pattern": "action",
+            "flags": "i",
+            "label": "the recipe declares its actions"
+          },
+          {
+            "kind": "contains",
+            "file": "automations/porch-light.json",
+            "pattern": "override|manual",
+            "flags": "i",
+            "label": "a manual override is written in"
+          },
+          {
+            "kind": "valuesSubsetOf",
+            "file": "automations/porch-light.json",
+            "sourceFiles": [
+              "home/devices.json"
+            ],
+            "pattern": "\"(dev-\\d{2})\"",
+            "minMatches": 2,
+            "label": "every device id in the recipe exists in the house inventory"
+          }
+        ]
+      },
+      {
+        "path": "report.md",
+        "kind": "markdown-report",
+        "minBytes": 600,
+        "checks": [
+          {
+            "kind": "contains",
+            "file": "report.md",
+            "pattern": "(?:^|\\n)#{1,3}\\s+\\S",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "report.md",
+            "pattern": "dry[ -]?run",
+            "flags": "i",
+            "label": "the dry run is reported"
+          },
+          {
+            "kind": "contains",
+            "file": "report.md",
+            "pattern": "override|manual|stop",
+            "flags": "i",
+            "label": "the install notes say how to stop it"
+          },
+          {
+            "kind": "citationsResolve",
+            "file": "report.md",
+            "pattern": "(automations/[a-z0-9-]+\\.json)",
+            "minCitations": 1,
+            "label": "the install notes point at a recipe file that exists on disk"
+          },
+          {
+            "kind": "judge",
+            "file": "report.md",
+            "rubric": "The install notes explain how to arm the automation and how to stop or override it in plain language, the dry-run summary matches the recorded evidence rather than overclaiming, and no device outside the house inventory is mentioned.",
+            "sourceFiles": [
+              "notes/dry-run.md",
+              "home/devices.json"
+            ],
+            "label": "honest, grounded install notes"
+          }
+        ]
+      }
+    ],
+    "mocks": [
+      {
+        "service": "home",
+        "minRequests": 2,
+        "requiredTools": [
+          "list_devices",
+          "set_state"
+        ]
+      }
+    ]
+  },
+  "rubric": {
+    "artifact": {
+      "path": "automations/porch-light.json",
+      "kind": "json"
+    },
+    "axes": [
+      {
+        "name": "safety",
+        "description": "Dry-run before arm is respected, a manual override is written into the recipe, and nothing claims to have actually switched a device."
+      },
+      {
+        "name": "groundedness",
+        "description": "Trigger, conditions, and actions reference real inventory device ids — the presence sensor and the porch light — never invented devices."
+      },
+      {
+        "name": "clarity",
+        "description": "The recipe reads as an inspectable record: concrete trigger, conditions, ordered actions, and a plain-language summary."
+      },
+      {
+        "name": "maintainability",
+        "description": "A stranger could arm, stop, or edit this automation from the recipe file and the install notes alone."
+      }
+    ]
+  },
+  "qualityFocus": [
+    "dry-run before arm",
+    "inventory-grounded device ids",
+    "manual override always present"
+  ]
+}