@bendyline/gilde 0.1.38 → 0.1.39

package/data/craftbook-templates/bo/board-game-web/versions/1.0.2/craftbook.json

@@ -0,0 +1,162 @@
+{
+  "id": "board-game-web",
+  "name": "Digital Board Game",
+  "description": "Build a single-file web version of a turn-based board game such as tic-tac-toe, checkers, connect-four, reversi, or a simple chess variant, with two-player hotseat or a basic AI opponent. Locks the rules, turn order, legal-move set, and win/draw detection first, then the board visual language, then implements an authoritative turn state machine. Board games demand correct turn alternation and exhaustive win/draw detection, so the rules phase enumerates every terminal condition before rendering — the ordering that stops a small model from shipping a board where turns desync or a win goes unnoticed.\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. Rules design (game-designer) — turn order, legal moves, win/draw detection → gated on artifact `{{workPath}}/rules-design.md` (markdown-notes)\n2. Visual design (visual-designer) — board look, pieces, turn indicator → gated on artifact `{{workPath}}/visual-design.md` (markdown-notes)\n3. Build (developer) — implement the turn state machine in index.html → gated on `index.html` (html-game)\n\nThe gates never advance with an unmet criterion, and loop back to the\nowning phase to fix named gaps.\n",
+  "entryStepId": "rules-design",
+  "triggers": [
+    "board game",
+    "tic tac toe",
+    "connect four",
+    "checkers",
+    "make chess",
+    "two player game"
+  ],
+  "steps": [
+    {
+      "id": "rules-design",
+      "name": "Rules design",
+      "description": "turn order, legal moves, win/draw detection",
+      "prompt": "Pin the RULES of the board game. (1) State the board size and pieces. (2) Define turn order and how the active player alternates. (3) Enumerate legal moves per piece and what makes a move illegal. (4) List EVERY terminal condition: each win pattern, draw/stalemate, and how each is detected from board state. (5) Decide the opponent: hotseat two-player, or a simple AI (random or one-ply) — state which. (6) Write an acceptance-criteria checklist of 5-8 items, e.g. 'players strictly alternate', 'illegal moves are rejected', 'every win line is detected and announced', 'a full board with no winner declares a draw', 'a new-game button resets cleanly', 'no console errors'. Write to {{workPath}}/rules-design.md and via write_task_note. No code yet.\n\nThe deliverable `{{workPath}}/rules-design.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": "game-designer",
+      "advanceWhen": {
+        "file": "{{workPath}}/rules-design.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "{{workPath}}/rules-design.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "{{workPath}}/rules-design.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "rules-design",
+        "maxAttempts": 3
+      },
+      "next": "visual-design"
+    },
+    {
+      "id": "visual-design",
+      "name": "Visual design",
+      "description": "board look, pieces, turn indicator",
+      "prompt": "Design the board look from the locked rules. (1) Choose a palette (hex) and the board grid styling. (2) Specify how each piece/player renders (X vs O, red vs black discs, glyphs). (3) Show the active-player turn indicator and how a winning line is highlighted. (4) Lay out status text (whose turn, win/draw banner) and a new-game button. (5) Keep it self-contained CSS grid or canvas, no external assets. Write the visual spec to {{workPath}}/visual-design.md and via write_task_note. No game logic yet.\n\nThe deliverable `{{workPath}}/visual-design.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": "visual-designer",
+      "advanceWhen": {
+        "file": "{{workPath}}/visual-design.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "{{workPath}}/visual-design.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "{{workPath}}/visual-design.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "visual-design",
+        "maxAttempts": 3
+      },
+      "next": "build"
+    },
+    {
+      "id": "build",
+      "name": "Build",
+      "description": "implement the turn state machine in index.html",
+      "prompt": "Implement the board game in a single index.html (inline CSS + JS) to the visual spec, satisfying every criterion. (1) Model board state and a currentPlayer variable. (2) On a cell/piece interaction, validate the move, apply it, then check all terminal conditions before switching the active player. (3) Announce win (highlighting the line) or draw and lock further input until new-game. (4) If an AI was specified, have it move after the human. (5) Wire a new-game button that fully resets. Vanilla JS, no CDN. On a loop-back, fix only the named gaps without regressing passing criteria. write_task_note the path and passing criteria.",
+      "suggestedRole": "developer",
+      "advanceWhen": {
+        "file": "index.html",
+        "minBytes": 1,
+        "sniff": "html-complete"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "index.html",
+            "bytes": 1500
+          },
+          {
+            "kind": "htmlLint",
+            "file": "index.html"
+          }
+        ],
+        "scripts": [
+          {
+            "name": "checkHtmlGame",
+            "scope": "standard",
+            "inputs": {
+              "file": "index.html"
+            }
+          },
+          {
+            "name": "checkJsParses",
+            "scope": "standard",
+            "inputs": {
+              "file": "index.html"
+            }
+          }
+        ],
+        "onReject": "build",
+        "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": "Play several full games. Open index.html if possible, else trace the turn and win logic. Check EACH criterion from {{workPath}}/rules-design.md and write PASS/FAIL with a reason: do players strictly alternate, are illegal moves rejected, is every win line detected, does a full no-winner board declare a draw, does new-game reset, zero console errors? Force at least one win and one draw to confirm both fire. Any missed terminal condition is a FAIL — loop back.\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": "index.html"
+        }
+      ],
+      "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"
+}

package/data/craftbook-templates/bo/board-game-web/versions/1.0.2/test.json

@@ -0,0 +1,102 @@
+{
+  "schemaVersion": 1,
+  "title": "Digital Board Game smoke eval",
+  "objective": "Self-contained smoke eval for the Digital Board Game craftbook using the html-game generic harness.",
+  "tags": [
+    "html-game"
+  ],
+  "prompt": "Make us a fun litle browser game around the returns-desk theme — just one file, index.html, that we can open and play.",
+  "setup": {
+    "projectName": "Digital Board Game Eval",
+    "about": "Self-contained eval project for board-game-web. Seeded inputs are under workspace/source or workspace/fixtures; final deliverable is workspace/index.html.",
+    "missionObjectives": "Use the Digital Board Game craftbook/template, read the seeded local fixtures, and write index.html without network calls, real credentials, or live services.",
+    "files": [
+      {
+        "path": "source/brief.md",
+        "content": "# Digital Board Game Eval Brief\n\nClient: Boreal Desk, a home-office accessories company.\nAudience: operations leads who need an artifact they can use this week.\n\nFixed source facts for grounding:\n- The returns desk pilot covered 18 SKUs.\n- Median first response improved from 18 hours to 6 hours.\n- Preventable refund leakage fell from 14.2% to 8.9%.\n- The top unresolved complaint is status silence after photo submission.\n- Required next actions are automated status emails, barcode-exception training, and a weekly Finance exception export.\n\nUse these facts when the task asks for prose, analysis, copy, UI content, or test data. Do not use live web services, real credentials, or current outside data.\n\nCraftbook under test: board-game-web - Digital Board Game.\n"
+      }
+    ],
+    "worker": {
+      "name": "Jules",
+      "role": "Developer"
+    },
+    "craftbookParams": {
+      "workPath": "tasks/eval"
+    }
+  },
+  "mocks": [],
+  "success": {
+    "summary": "index.html is a complete self-contained browser game smoke artifact.",
+    "deliverables": [
+      {
+        "path": "index.html",
+        "kind": "html-game",
+        "minBytes": 3200,
+        "checks": [
+          {
+            "kind": "cssMinBytes",
+            "bytes": 600,
+            "file": "index.html"
+          },
+          {
+            "kind": "jsParses",
+            "file": "index.html"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "<canvas|<svg|requestAnimationFrame",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "score|state|level|turn",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "restart|play again|new game|game over|victory|you win|you lose",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "Boreal|returns|desk",
+            "flags": "i"
+          }
+        ]
+      }
+    ]
+  },
+  "rubric": {
+    "artifact": {
+      "path": "index.html",
+      "kind": "html"
+    },
+    "axes": [
+      {
+        "name": "playability",
+        "description": "The game is actually playable: input works, state advances, and a session can be completed."
+      },
+      {
+        "name": "completeness",
+        "description": "Core loop, scoring/win-lose, and restart are all present rather than stubbed."
+      },
+      {
+        "name": "polish",
+        "description": "Visual design and feedback (motion, states, messages) feel deliberate, not default."
+      },
+      {
+        "name": "robustness",
+        "description": "No console errors, dead controls, or states the player can get stuck in."
+      }
+    ]
+  },
+  "qualityFocus": [
+    "runtime surface",
+    "interaction loop",
+    "self-contained game"
+  ]
+}

package/data/craftbook-templates/bo/booking-automation/versions/1.0.2/craftbook.json

@@ -0,0 +1,170 @@
+{
+  "id": "booking-automation",
+  "name": "Automate a Booking or Checkout Flow",
+  "description": "Automate a multi-step booking, reservation, or checkout flow end-to-end — select, fill details, choose options, confirm — with a hard dry-run/confirmation guard so it never accidentally commits a real transaction during development. Maps the step-by-step flow, the success/failure signals, and the safety guard FIRST, then builds the resilient step driver with waits and retries, then tests both the happy path and the failure/abort paths against a stub or dry-run. Mapping-the-flow-and-guard-before-build is what makes booking automation safe and reliable instead of a brittle, money-spending click bot.\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 flow (planner) — step map, success/failure signals, safety guard → gated on artifact `{{workPath}}/scope.md` (markdown-notes)\n2. Build the flow driver (developer) — drive each step with waits, retries, and the guard → gated on `booking.py` (code-module)\n3. Test the flow (developer) — assert happy path, failure paths, and the guard → gated on `booking_test.py` (code-with-tests)\n\nThe gates never advance with an unmet criterion, and loop back to the\nowning phase to fix named gaps.\n",
+  "entryStepId": "scope",
+  "triggers": [
+    "automate a booking",
+    "auto-checkout flow",
+    "reserve automatically",
+    "automate a multi-step form",
+    "complete a booking for me"
+  ],
+  "steps": [
+    {
+      "id": "scope",
+      "name": "Scope the flow",
+      "description": "step map, success/failure signals, safety guard",
+      "prompt": "Map the flow and its guardrails before automating. Step 1: write the ordered step map (e.g. open → search/select → enter details → choose options → review → confirm), and for each step the element to act on and the signal that the step advanced. Step 2: define the inputs the flow needs (dates, quantities, traveler/customer details, payment placeholders) and where they come from. Step 3: define the success signal (a confirmation number / page) and the failure signals (sold out, validation error, timeout) and the abort behavior for each. Step 4: define the SAFETY GUARD — a dry-run/confirm flag that, when not explicitly set, stops before the irreversible commit step and never submits a real payment; default to dry-run. Step 5: write an acceptance-criteria checklist ('every step has a verifiable advance signal', 'dry-run stops before commit and asserts readiness', 'happy path reaches confirmation when armed', 'failure signals abort cleanly with a reason', 'no real transaction in dry-run', 'flow is idempotent / re-entrant'). Call write_task_note with the step map + signals + guard + 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 flow driver",
+      "description": "drive each step with waits, retries, and the guard",
+      "prompt": "Implement the booking driver to the locked step map. Step 1: read the dry-run/confirm flag first and honor it — in dry-run, perform every step up to but NOT including the irreversible commit, then report 'ready to confirm'. Step 2: for each step, perform the action, then wait for and assert the advance signal before proceeding (explicit waits, not fixed sleeps); on a transient failure retry with backoff a bounded number of times. Step 3: on a defined failure signal (sold out / validation), abort cleanly and record the reason rather than blindly proceeding. Step 4: when armed, perform the commit step and capture the confirmation number. Step 5: write a structured run-log of each step's outcome and write the driver as a runnable module. Call write_task_note with the module path, how the guard works, and a sample dry-run log.",
+      "suggestedRole": "developer",
+      "advanceWhen": {
+        "file": "booking.py",
+        "minBytes": 1,
+        "sniff": "nonempty"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "booking.py",
+            "bytes": 200
+          },
+          {
+            "kind": "sniff",
+            "file": "booking.py",
+            "sniff": "nonempty"
+          },
+          {
+            "kind": "esmImports",
+            "file": "booking.py"
+          },
+          {
+            "kind": "sourceParses",
+            "file": "booking.py"
+          }
+        ],
+        "onReject": "build",
+        "maxAttempts": 3
+      },
+      "next": "test"
+    },
+    {
+      "id": "test",
+      "name": "Test the flow",
+      "description": "assert happy path, failure paths, and the guard",
+      "prompt": "Prove the flow on every branch using a stub/dry-run — never a live commit. Step 1: write tests that drive the flow against a stubbed booking surface so no real transaction occurs. Step 2: assert the happy path advances through every step and reaches the confirmation signal when armed. Step 3: assert each failure signal (sold out, validation error, timeout) causes a clean abort with the right reason and does NOT proceed to commit. Step 4: assert the SAFETY GUARD — in dry-run the flow stops before the commit step and never submits, and that flag defaults to dry-run. Step 5: assert idempotency/retry — a transient failure is retried within the bound and a re-run does not double-book. Put the driver and tests in a code-with-tests file; run them and confirm green. Call write_task_note with the test path and the pass count.",
+      "suggestedRole": "developer",
+      "advanceWhen": {
+        "file": "booking_test.py",
+        "minBytes": 1,
+        "sniff": "nonempty"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "booking_test.py",
+            "bytes": 300
+          },
+          {
+            "kind": "sniff",
+            "file": "booking_test.py",
+            "sniff": "nonempty"
+          },
+          {
+            "kind": "esmImports",
+            "file": "booking_test.py"
+          },
+          {
+            "kind": "sourceParses",
+            "file": "booking_test.py"
+          }
+        ],
+        "scripts": [
+          {
+            "name": "checkContains",
+            "scope": "standard",
+            "inputs": {
+              "file": "booking_test.py",
+              "pattern": "\\b(test|describe|it|assert|expect)\\b",
+              "flags": "i"
+            }
+          }
+        ],
+        "onReject": "test",
+        "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 booking_test.py (or trace it) and verify every criterion from {{workPath}}/scope.md: every step asserts an advance signal, the happy path reaches confirmation when armed, each failure signal aborts cleanly with a reason and never commits, the safety guard defaults to dry-run and stops before the irreversible step, and retries/idempotency prevent double-booking. Critically confirm NO test performs a real commit. Write PASS/FAIL per criterion; on any failure, name it and loop back to test.\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: \"test\" })` 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": "booking_test.py"
+        }
+      ],
+      "next": "test"
+    },
+    {
+      "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/bo/booking-automation/versions/1.0.2/test.json

@@ -0,0 +1,165 @@
+{
+  "schemaVersion": 1,
+  "title": "Automate a Booking or Checkout Flow smoke eval",
+  "objective": "Self-contained smoke eval for the Automate a Booking or Checkout Flow craftbook using the external generic harness.",
+  "tags": [
+    "external"
+  ],
+  "prompt": "Theres a fake ops service wired up for this so nothing real gets touched — the endpoints are in mocks/services.md, and the ready-made mock-probe script talks to them for you. Can you run the automation against it and write up how it went in automation.md?",
+  "setup": {
+    "projectName": "Automate a Booking or Checkout Flow Eval",
+    "about": "Self-contained eval project for booking-automation. Seeded inputs are under workspace/source or workspace/fixtures; final deliverable is workspace/automation.md.",
+    "missionObjectives": "Use the Automate a Booking or Checkout Flow craftbook/template, read the seeded local fixtures, and write automation.md without network calls, real credentials, or live services.",
+    "files": [
+      {
+        "path": "source/brief.md",
+        "content": "# Automate a Booking or Checkout Flow Eval Brief\n\nClient: Boreal Desk, a home-office accessories company.\nAudience: operations leads who need an artifact they can use this week.\n\nFixed source facts for grounding:\n- The returns desk pilot covered 18 SKUs.\n- Median first response improved from 18 hours to 6 hours.\n- Preventable refund leakage fell from 14.2% to 8.9%.\n- The top unresolved complaint is status silence after photo submission.\n- Required next actions are automated status emails, barcode-exception training, and a weekly Finance exception export.\n\nUse these facts when the task asks for prose, analysis, copy, UI content, or test data. Do not use live web services, real credentials, or current outside data.\n\nCraftbook under test: booking-automation - Automate a Booking or Checkout Flow.\n"
+      }
+    ],
+    "worker": {
+      "name": "Jules",
+      "role": "Developer"
+    },
+    "craftbookParams": {
+      "workPath": "tasks/eval"
+    }
+  },
+  "mocks": [
+    {
+      "kind": "http",
+      "id": "ops",
+      "description": "Fake operations service for this eval. GET /api/bookings/open lists the open work items; POST /api/bookings/dry-run records a simulated submission and returns DRY_RUN_OK.",
+      "credential": {
+        "name": "mock.ops"
+      },
+      "routes": [
+        {
+          "method": "GET",
+          "path": "/api/bookings/open",
+          "body": {
+            "items": [
+              "BKG-1001",
+              "BKG-1002",
+              "BKG-1003"
+            ]
+          }
+        },
+        {
+          "method": "POST",
+          "path": "/api/bookings/dry-run",
+          "status": 201,
+          "body": {
+            "status": "DRY_RUN_OK",
+            "recorded": 3
+          }
+        }
+      ]
+    },
+    {
+      "kind": "webhook",
+      "id": "notify",
+      "description": "Notification receiver. POST a JSON completion notice here when the run finishes.",
+      "path": "/hooks/notify"
+    },
+    {
+      "kind": "cli",
+      "id": "probe",
+      "description": "Provenance-trusted project script `mock-probe` that exercises the fake ops service through http.authed and returns the raw responses.",
+      "shim": {
+        "path": "scripts/mock-probe.ts",
+        "content": "import { defineScript, gezel } from '@bendyline/gezel-sdk';\n\nexport const meta = defineScript({\n  name: 'mock-probe',\n  description:\n    'Probe the live fake ops service for this eval: lists the open work items and records a dry-run submission. Outputs the raw JSON responses as evidence for the write-up.',\n  inputs: {},\n  outputs: {\n    open: { type: 'string', description: 'Raw JSON body from the open-items listing.' },\n    dryRun: { type: 'string', description: 'Raw JSON body from the dry-run submission.' },\n  },\n  requires: ['workspace.read', 'network', 'credential:mock.ops'],\n});\n\nconst services = JSON.parse(await gezel.fs.read('mocks/services.json'));\nconst base = (id) => {\n  const service = services.find((entry) => entry.id === id);\n  if (!service) throw new Error(`mock service \"${id}\" is not listed in mocks/services.json`);\n  return service.baseUrl;\n};\n\nconst open = await gezel.http.authed(`${base('ops')}/api/bookings/open`, {\n  credential: 'mock.ops',\n});\nif (!open.ok) throw new Error(`open-items listing failed: ${open.status} ${open.body}`);\n\nconst dryRun = await gezel.http.authed(`${base('ops')}/api/bookings/dry-run`, {\n  credential: 'mock.ops',\n  method: 'POST',\n  body: JSON.stringify({ items: JSON.parse(open.body).items, mode: 'dry-run' }),\n});\nif (!dryRun.ok) throw new Error(`dry-run submission failed: ${dryRun.status} ${dryRun.body}`);\n\ngezel.output({ open: open.body, dryRun: dryRun.body });\n"
+      }
+    }
+  ],
+  "success": {
+    "summary": "automation.md is grounded in live fake-service responses: the open items were actually listed and a dry-run actually recorded (request-log assertions), with safety guards and signals described.",
+    "deliverables": [
+      {
+        "path": "automation.md",
+        "kind": "markdown-report",
+        "minBytes": 900,
+        "checks": [
+          {
+            "kind": "contains",
+            "file": "automation.md",
+            "pattern": "(?:^|\\n)#{1,3}\\s+\\S",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "automation.md",
+            "pattern": "DRY_RUN_OK|dry-run|dry run",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "automation.md",
+            "pattern": "fake-ci|fake-github|/api/bookings",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "automation.md",
+            "pattern": "no real|credentials|safety|guard",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "automation.md",
+            "pattern": "success|failure|retry|abort",
+            "flags": "i"
+          }
+        ]
+      }
+    ],
+    "mocks": [
+      {
+        "service": "ops",
+        "minRequests": 2,
+        "requiredPaths": [
+          "^/api/bookings/open$",
+          "^/api/bookings/dry-run$"
+        ]
+      }
+    ]
+  },
+  "rubric": {
+    "artifact": {
+      "path": "automation.md",
+      "kind": "markdown"
+    },
+    "axes": [
+      {
+        "name": "safety",
+        "description": "Dry-run posture is explicit: no real credentials, clear stop-before-side-effect boundary."
+      },
+      {
+        "name": "mapping",
+        "description": "Fake endpoints/commands are mapped completely to the workflow steps."
+      },
+      {
+        "name": "signals",
+        "description": "Success, failure, retry, and abort conditions are all defined."
+      },
+      {
+        "name": "containment",
+        "description": "The plan cannot accidentally reach a real service from a mock context."
+      }
+    ]
+  },
+  "qualityFocus": [
+    "dry-run safety",
+    "fake tool mapping",
+    "side-effect containment"
+  ],
+  "extensions": {
+    "legacySimulators": [
+      {
+        "id": "booking-automation-fake-service-fixture",
+        "kind": "data-source",
+        "status": "implemented",
+        "description": "Seeded local fake service contract replacing live CLIs, HTTP APIs, credentials, and side effects."
+      }
+    ]
+  }
+}