@bendyline/gilde 0.1.38 → 0.1.39

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

@@ -0,0 +1,176 @@
+{
+  "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 `{{workPath}}/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 `{{workPath}}/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 `{{workPath}}/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 {{workPath}}/scope.md.\n\nThe deliverable `{{workPath}}/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": "{{workPath}}/scope.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "{{workPath}}/scope.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "{{workPath}}/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 {{workPath}}/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 `{{workPath}}/scope.md` with `read_artifact`; do not look for it in the workspace.",
+      "suggestedRole": "developer",
+      "consumes": [
+        {
+          "file": "{{workPath}}/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 {{workPath}}/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 `{{workPath}}/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": "{{workPath}}/dry-run.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "{{workPath}}/dry-run.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "{{workPath}}/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 {{workPath}}/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 {{workPath}}/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 {{workPath}}/report.md and call write_task_note with a one-line DONE summary.\n\nBefore working, open the artifact inputs `{{workPath}}/scope.md`, `{{workPath}}/dry-run.md` with `read_artifact`; do not look for them in the workspace.\n\nThe deliverable `{{workPath}}/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": "{{workPath}}/scope.md",
+          "artifact": true
+        },
+        {
+          "file": "{{workPath}}/dry-run.md",
+          "artifact": true
+        }
+      ],
+      "advanceWhen": {
+        "file": "{{workPath}}/report.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "{{workPath}}/report.md",
+            "bytes": 800,
+            "artifact": true
+          },
+          {
+            "kind": "contains",
+            "file": "{{workPath}}/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/, {{workPath}}/dry-run.md, {{workPath}}/report.md, and {{workPath}}/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 `{{workPath}}/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": "{{workPath}}/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.2",
+  "releasedAt": "2026-08-21T00:00:00Z",
+  "paramSchema": {
+    "type": "object",
+    "properties": {
+      "workPath": {
+        "type": "string",
+        "title": "Working folder",
+        "description": "Per-task working folder in the artifacts drawer. Defaults to this task's own folder so runs never collide; override with a stable name when you deliberately want runs to share files.",
+        "default": "{{task.dir}}"
+      }
+    }
+  },
+  "minGezelVersion": "1.26233"
+}

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

@@ -0,0 +1,299 @@
+{
+  "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 tasks/eval/dry-run.md, and the install notes to tasks/eval/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 tasks/eval/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"
+    },
+    "craftbookParams": {
+      "workPath": "tasks/eval"
+    }
+  },
+  "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 tasks/eval/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": "tasks/eval/report.md",
+        "kind": "markdown-report",
+        "minBytes": 600,
+        "checks": [
+          {
+            "kind": "contains",
+            "file": "tasks/eval/report.md",
+            "pattern": "(?:^|\\n)#{1,3}\\s+\\S",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "tasks/eval/report.md",
+            "pattern": "dry[ -]?run",
+            "flags": "i",
+            "label": "the dry run is reported"
+          },
+          {
+            "kind": "contains",
+            "file": "tasks/eval/report.md",
+            "pattern": "override|manual|stop",
+            "flags": "i",
+            "label": "the install notes say how to stop it"
+          },
+          {
+            "kind": "citationsResolve",
+            "file": "tasks/eval/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": "tasks/eval/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": [
+              "tasks/eval/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"
+  ]
+}

package/data/craftbook-templates/ba/backup-routine/versions/1.0.2/craftbook.json

@@ -0,0 +1,160 @@
+{
+  "id": "backup-routine",
+  "name": "Scheduled Backup or Export",
+  "description": "Build a scheduled, idempotent backup/export routine that snapshots data (files, a database, or an app export) to a timestamped, optionally compressed destination, prunes old backups by a retention policy, and verifies each backup is restorable. Locks what to back up, the destination layout, the retention policy, and the integrity check FIRST, then builds the snapshot-write-verify-prune routine, then verifies a fresh backup is created, integrity-checked, and that retention deletes only what it should. Defining retention and an integrity check up front is the wisdom that turns backups from a false sense of safety into a tested recovery path.\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 backup (planner) — sources, destination layout, retention, integrity check → gated on artifact `{{workPath}}/scope.md` (markdown-notes)\n2. Build the routine (developer) — snapshot, write, integrity-check, prune, log → gated on `backup.sh` (code-module)\n3. Verify the routine (reviewer) — fresh backup, integrity, safe retention, idempotency → gated on artifact `{{workPath}}/verify.md` (markdown-notes)\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 a backup",
+    "scheduled export",
+    "automate backups",
+    "backup my database",
+    "nightly backup routine"
+  ],
+  "steps": [
+    {
+      "id": "scope",
+      "name": "Scope the backup",
+      "description": "sources, destination layout, retention, integrity check",
+      "prompt": "Define the backup contract before building. Step 1: list exactly what to back up (which directories / which database / which export endpoint) and what to exclude. Step 2: define the destination and naming layout (e.g. backups/{name}-{YYYYMMDD-HHMMSS}.tar.gz) and whether to compress and/or checksum. Step 3: define the retention policy precisely (e.g. keep last N, or keep dailies 7d + weeklies 4w) and confirm it can never delete the only/most-recent backup. Step 4: define the integrity check that proves a backup is restorable (verify the archive lists/extracts, the checksum matches, or a row-count/sentinel survives a test restore). Step 5: write an acceptance-criteria checklist ('a fresh timestamped backup is produced each run', 'backup passes the integrity check', 'retention prunes only out-of-policy backups and never the newest', 'run is idempotent and logs each backup', 'a failed source aborts with a non-zero status, no silent empty backup'). Call write_task_note with sources + layout + retention + integrity + checklist and write {{workPath}}/scope.md. No code yet.\n\nThe deliverable `{{workPath}}/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": "planner",
+      "advanceWhen": {
+        "file": "{{workPath}}/scope.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "{{workPath}}/scope.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "{{workPath}}/scope.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "scope",
+        "maxAttempts": 3
+      },
+      "next": "build"
+    },
+    {
+      "id": "build",
+      "name": "Build the routine",
+      "description": "snapshot, write, integrity-check, prune, log",
+      "prompt": "Implement the backup routine to the locked contract. Step 1: snapshot the sources into a timestamped artifact at the destination (compress/checksum as scoped); fail loudly with a non-zero exit if a source is missing or empty rather than writing a hollow archive. Step 2: run the integrity check immediately after writing (list/extract the archive, verify the checksum) and mark the backup verified only if it passes. Step 3: apply the retention policy — compute which backups are out-of-policy and delete only those, with a hard guard that never removes the most-recent verified backup. Step 4: append a backup-log entry (timestamp, size, checksum, verified, pruned list). Step 5: write the routine as a cron-friendly runnable module. Call write_task_note with the module path, the destination layout, and how integrity + retention are enforced.",
+      "suggestedRole": "developer",
+      "advanceWhen": {
+        "file": "backup.sh",
+        "minBytes": 1,
+        "sniff": "nonempty"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "backup.sh",
+            "bytes": 200
+          },
+          {
+            "kind": "sniff",
+            "file": "backup.sh",
+            "sniff": "nonempty"
+          },
+          {
+            "kind": "esmImports",
+            "file": "backup.sh"
+          },
+          {
+            "kind": "sourceParses",
+            "file": "backup.sh"
+          }
+        ],
+        "onReject": "build",
+        "maxAttempts": 3
+      },
+      "next": "verify"
+    },
+    {
+      "id": "verify",
+      "name": "Verify the routine",
+      "description": "fresh backup, integrity, safe retention, idempotency",
+      "prompt": "Verify the routine against scope. Step 1: confirm a run produces a fresh timestamped backup at the destination. Step 2: confirm the integrity check actually runs and that a corrupted/empty backup would be caught (the verified flag is meaningful). Step 3: confirm retention deletes only out-of-policy backups and that the newest verified backup is protected even at the retention boundary. Step 4: confirm idempotency and failure handling — a re-run does not clobber prior backups, and a missing source causes a non-zero exit with no hollow archive written. Step 5: confirm each backup is logged. Write PASS/FAIL per criterion to {{workPath}}/verify.md and task notes; on failure, name it and loop back to build.\n\nThe deliverable `{{workPath}}/verify.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": "reviewer",
+      "advanceWhen": {
+        "file": "{{workPath}}/verify.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "backup.sh",
+            "bytes": 200
+          },
+          {
+            "kind": "sniff",
+            "file": "backup.sh",
+            "sniff": "nonempty"
+          },
+          {
+            "kind": "esmImports",
+            "file": "backup.sh"
+          },
+          {
+            "kind": "sourceParses",
+            "file": "backup.sh"
+          }
+        ],
+        "onReject": "verify",
+        "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": "Run backup.sh in a scratch location (or trace it) and verify every criterion from {{workPath}}/scope.md: a fresh timestamped backup is created, the integrity check runs and is meaningful, retention prunes only out-of-policy backups and never the newest verified one, a missing source aborts non-zero with no hollow archive, runs are idempotent, and each backup is logged. Write PASS/FAIL per criterion; on any failure, name it and loop back to build.\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: \"build\" })` 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": "backup.sh"
+        }
+      ],
+      "next": "build"
+    },
+    {
+      "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.2",
+  "releasedAt": "2026-08-21T00:00:00Z",
+  "paramSchema": {
+    "type": "object",
+    "properties": {
+      "workPath": {
+        "type": "string",
+        "title": "Working folder",
+        "description": "Per-task working folder in the artifacts drawer. Defaults to this task's own folder so runs never collide; override with a stable name when you deliberately want runs to share files.",
+        "default": "{{task.dir}}"
+      }
+    }
+  },
+  "minGezelVersion": "1.26233"
+}