@bendyline/gilde 0.1.26 → 0.1.28

package/data/craftbook-templates/ca/calendar-brief/versions/1.0.1/craftbook.json

@@ -0,0 +1,107 @@
+{
+  "id": "calendar-brief",
+  "name": "Daily Calendar & Prep Brief",
+  "description": "Assemble a morning brief from the day's calendar: a chronological agenda with per-meeting prep notes, conflicts flagged, and a short focus-time/priorities summary. Scopes the brief layout and prep rules FIRST (which meetings need prep, what prep means, how to flag conflicts and back-to-backs), then a developer pulls the day's events and assembles the brief deterministically against those rules. The scope-first ordering ensures the brief always flags double-bookings and attaches the right context (attendees, agenda, links) instead of just dumping a raw event list. Use for daily agenda briefs, meeting prep, morning planning, schedule rundowns, and turning a calendar into an actionable day plan.\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 brief (planner) — lock the layout, prep rules, and conflict flags → gated on artifact `notes/scope.md` (markdown-notes)\n2. Assemble the brief (developer) — pull the day's events and build the brief to the rules → gated on `brief.md` (markdown-doc)\n\nThe gates never advance with an unmet criterion, and loop back to the\nowning phase to fix named gaps.\n",
+  "entryStepId": "scope",
+  "triggers": [
+    "daily brief",
+    "what's on my calendar",
+    "meeting prep",
+    "morning agenda",
+    "today's schedule"
+  ],
+  "steps": [
+    {
+      "id": "scope",
+      "name": "Scope the brief",
+      "description": "lock the layout, prep rules, and conflict flags",
+      "prompt": "Define the brief format before pulling events. (1) Lock the layout — At-a-glance (count of meetings, total meeting hours, first/last event), Agenda (chronological, with time, title, attendees, location/link), Prep (per-meeting context), Conflicts & gaps, Focus/priorities. (2) Set the prep rule: which meetings get prep notes (e.g. external attendees, no agenda attached, or >30 min) and what a prep note contains (purpose in one line, attendees, the doc/link, one suggested talking point). (3) Define conflict detection: overlapping events flagged RED, three+ back-to-backs flagged as a fatigue risk, and gaps ≥ 60 min surfaced as focus blocks. (4) Set the day/timezone. Write an acceptance-criteria checklist ('every event for the day appears in time order', 'overlaps are flagged', 'every meeting meeting the prep rule has a prep note', 'focus gaps surfaced', 'at-a-glance totals are correct') plus the layout + rules to notes/scope.md via write_task_note AND the produces path.\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": "planner",
+      "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": "assemble"
+    },
+    {
+      "id": "assemble",
+      "name": "Assemble the brief",
+      "description": "pull the day's events and build the brief to the rules",
+      "prompt": "Build brief.md for the target day using the locked layout and rules. (1) Pull the day's events (from the connected calendar tool or a pasted agenda); sort strictly by start time. (2) Compute the at-a-glance totals (meeting count, summed meeting hours, first start, last end). (3) Render the chronological agenda with time range, title, attendees, and location/link per event. (4) For each event meeting the prep rule, write its prep note (purpose, attendees, link, one talking point) — invent no facts; bracket anything the calendar doesn't provide. (5) Scan for overlaps (flag RED), 3+ back-to-backs (fatigue note), and ≥60-min gaps (focus blocks) and list them in Conflicts & gaps. (6) Close with a 3-item priorities line. On a loop-back fix only the flagged parts. Write the brief via write_task_note and the path + event count to notes.",
+      "suggestedRole": "developer",
+      "advanceWhen": {
+        "file": "brief.md",
+        "minBytes": 1,
+        "sniff": "nonempty"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "brief.md",
+            "bytes": 500
+          }
+        ],
+        "scripts": [
+          {
+            "name": "checkContains",
+            "scope": "standard",
+            "inputs": {
+              "file": "brief.md",
+              "pattern": "(?:^|\\n)#{1,3}\\s+\\S",
+              "flags": "i"
+            }
+          }
+        ],
+        "onReject": "assemble",
+        "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": "QA brief.md against the locked criteria. (1) Confirm every event for the day is present and strictly time-ordered; FAIL on any missing or out-of-order event. (2) Recompute the at-a-glance totals from the agenda and confirm they match. (3) Confirm every meeting matching the prep rule has a prep note with the required fields, and that no facts were invented (placeholders bracketed). (4) Verify conflict detection: any two overlapping events flagged, back-to-back runs noted, ≥60-min gaps surfaced as focus blocks. (5) Confirm the priorities line is present. Write PASS/FAIL per criterion with specifics.\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: \"assemble\" })` 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": "brief.md"
+        }
+      ],
+      "next": "assemble"
+    },
+    {
+      "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/ca/calendar-brief/versions/1.0.1/test.json

@@ -0,0 +1,102 @@
+{
+  "schemaVersion": 1,
+  "title": "Morning calendar brief from fixed agenda",
+  "objective": "Measure whether the calendar-brief craftbook turns a seeded agenda into a chronological, prep-oriented day brief with conflicts and focus gaps.",
+  "tags": [
+    "corpus"
+  ],
+  "prompt": "In the `Calendar Brief Eval` project, read `source/events.md` and write `brief.md` for Monday, June 29, 2026 in America/Los_Angeles. Include at-a-glance totals, chronological agenda, prep notes, conflicts/back-to-backs, focus blocks, and three priorities.",
+  "setup": {
+    "projectName": "Calendar Brief Eval",
+    "about": "Self-contained eval project for calendar-brief. The source agenda is in workspace/source/events.md.",
+    "missionObjectives": "Write an actionable morning brief from seeded events with all meetings, prep notes, conflicts, focus gaps, and priorities.",
+    "files": [
+      {
+        "path": "source/events.md",
+        "content": "# Events for Monday, June 29, 2026 PT\n\n- 08:30-09:00: Support standup. Attendees: Maya, Jules, Priya. Link: meet/support. Agenda: overnight backlog.\n- 09:00-10:00: West warehouse launch review. Attendees: Ops leads, Finance. Link: docs/warehouse-launch. External: no.\n- 09:30-10:15: Customer escalation: Acme Studio. Attendees: Acme, Maya, Jules. Link: crm/acme. External: yes. Agenda missing.\n- 11:30-12:00: Finance exception export check. Attendees: Finance, Data. Link: dashboard/exports.\n- 14:00-15:00: Product interview readout. Attendees: Product, Support. Link: docs/interview-readout.\n- 16:30-17:00: Weekly planning. Attendees: Support leads. Link: docs/weekly-plan.\n"
+      }
+    ],
+    "worker": {
+      "name": "Fleur",
+      "role": "Operations Assistant"
+    }
+  },
+  "mocks": [],
+  "success": {
+    "summary": "workspace/brief.md includes every seeded event in order with totals, prep, overlap/fatigue notes, focus gaps, and priorities.",
+    "deliverables": [
+      {
+        "path": "brief.md",
+        "kind": "markdown-doc",
+        "minBytes": 1800,
+        "checks": [
+          {
+            "kind": "contains",
+            "file": "brief.md",
+            "pattern": "(?:^|\\n)#{1,3}\\s+\\S",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "brief.md",
+            "pattern": "At-a-glance|Agenda|Prep|Conflicts|Focus|Priorities",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "brief.md",
+            "pattern": "Support standup|West warehouse|Acme Studio|Finance exception|Product interview|Weekly planning",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "brief.md",
+            "pattern": "09:00|09:30|overlap|conflict|RED",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "brief.md",
+            "pattern": "external|agenda missing|talking point|prep",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "brief.md",
+            "pattern": "focus block|gap|60",
+            "flags": "i"
+          }
+        ]
+      }
+    ]
+  },
+  "rubric": {
+    "artifact": {
+      "path": "brief.md",
+      "kind": "markdown"
+    },
+    "axes": [
+      {
+        "name": "grounding",
+        "description": "Seeded facts appear faithfully and the source is cited."
+      },
+      {
+        "name": "structure",
+        "description": "Sections progress logically for the artifact class."
+      },
+      {
+        "name": "completeness",
+        "description": "Required elements (risks, next actions, scope) are all present."
+      },
+      {
+        "name": "tone",
+        "description": "The register fits the audience and artifact class."
+      }
+    ]
+  },
+  "qualityFocus": [
+    "chronological agenda",
+    "conflict detection",
+    "meeting prep"
+  ]
+}

package/data/craftbook-templates/ca/canvas-generative-art/versions/1.0.1/craftbook.json

@@ -0,0 +1,110 @@
+{
+  "id": "canvas-generative-art",
+  "name": "Canvas Generative Art",
+  "description": "Build a single-file generative art piece on canvas — flow fields, particle systems, recursive trees, Voronoi, noise terrain, or geometric tilings — that produces a fresh composition each run from a seed, with parameters the viewer can tweak. Defines the aesthetic and the generative algorithm first, then implements a seeded, reproducible renderer with a regenerate control. Generative art is an algorithm-and-aesthetic problem, so the aesthetic-scope phase locks the visual rules and the seedable randomness before any drawing, the ordering that yields a deliberate piece rather than random noise.\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. Aesthetic scope (visual-designer) — the algorithm, palette, composition rules, seed → gated on artifact `notes/aesthetic-scope.md` (markdown-notes)\n2. Build (developer) — implement the seeded renderer in index.html → gated on `index.html` (html-page)\n\nThe gates never advance with an unmet criterion, and loop back to the\nowning phase to fix named gaps.\n",
+  "entryStepId": "aesthetic-scope",
+  "triggers": [
+    "generative art",
+    "creative coding",
+    "procedural art",
+    "flow field",
+    "canvas art",
+    "algorithmic art"
+  ],
+  "steps": [
+    {
+      "id": "aesthetic-scope",
+      "name": "Aesthetic scope",
+      "description": "the algorithm, palette, composition rules, seed",
+      "prompt": "Define the aesthetic and the generative system. (1) Choose the algorithm (flow field, particles, recursive subdivision, noise, Voronoi, packing) and describe in steps how it draws a composition. (2) Pick a palette (hex) and the composition rules (density, scale, symmetry, margins, layering, blend). (3) Decide the seed: each run uses a seed so output is reproducible, and a regenerate control makes a new one. (4) List the tweakable parameters exposed to the viewer (count, scale, palette). (5) Write an acceptance-criteria checklist of 5-8 items, e.g. 'a composition renders on load', 'regenerate produces a clearly different composition', 'the same seed reproduces the same image', 'parameters change the output', 'the palette is used (not random colors)', 'no console errors'. Write to notes/aesthetic-scope.md and via write_task_note. No code yet.\n\nThe deliverable `notes/aesthetic-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": "visual-designer",
+      "advanceWhen": {
+        "file": "notes/aesthetic-scope.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "notes/aesthetic-scope.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "notes/aesthetic-scope.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "aesthetic-scope",
+        "maxAttempts": 3
+      },
+      "next": "build"
+    },
+    {
+      "id": "build",
+      "name": "Build",
+      "description": "implement the seeded renderer in index.html",
+      "prompt": "Implement the generative piece in a single index.html (inline CSS + JS) to the aesthetic spec. (1) Set up a full-canvas 2d context sized to the viewport. (2) Implement a seedable PRNG (e.g. mulberry32) so a given seed reproduces the same image; derive all randomness from it. (3) Implement the algorithm to draw a composition honoring the palette and composition rules. (4) Add a regenerate button (new seed -> redraw) and controls for the exposed parameters that recompute on change. (5) Optionally a save/export. Vanilla JS, no CDN, no external assets. 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": 800
+          },
+          {
+            "kind": "htmlLint",
+            "file": "index.html"
+          }
+        ],
+        "scripts": [
+          {
+            "name": "checkHtmlComplete",
+            "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": "Evaluate the art piece. Open/render index.html, regenerate several times, and tweak a parameter. Check EACH criterion from notes/aesthetic-scope.md and write PASS/FAIL with a reason: does a composition render on load, does regenerate clearly change it, does the same seed reproduce the same image, do parameters affect output, is the chosen palette used (not arbitrary colors), zero console errors? If regenerate does nothing or the same seed gives different images, FAIL 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": "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.1",
+  "releasedAt": "2026-08-14T00:00:00Z"
+}

package/data/craftbook-templates/ca/canvas-generative-art/versions/1.0.1/test.json

@@ -0,0 +1,106 @@
+{
+  "schemaVersion": 1,
+  "title": "Seeded interactive canvas artwork",
+  "objective": "Measure whether the canvas-generative-art craftbook locks an aesthetic direction and ships a complete animated canvas page.",
+  "tags": [
+    "html-page"
+  ],
+  "prompt": "In the `Canvas Art Eval` project, build `index.html`: a self-contained generative canvas artwork called \"Harbor Current\". It should use a seeded pseudo-random generator, draw layered wave/particle forms on a canvas, animate subtly with requestAnimationFrame, include Regenerate and Pause controls, and show the seed on screen. Inline CSS and JS only; no external assets.",
+  "setup": {
+    "projectName": "Canvas Art Eval",
+    "about": "Self-contained eval project for canvas-generative-art. The only deliverable is workspace/index.html.",
+    "missionObjectives": "Produce a complete animated canvas artwork with seed display, controls, and substantial inline CSS/JS.",
+    "files": [],
+    "worker": {
+      "name": "Lio",
+      "role": "Developer"
+    }
+  },
+  "mocks": [],
+  "success": {
+    "summary": "index.html is a complete animated canvas page with seed and control vocabulary.",
+    "deliverables": [
+      {
+        "path": "index.html",
+        "kind": "html-page",
+        "minBytes": 3200,
+        "checks": [
+          {
+            "kind": "cssMinBytes",
+            "bytes": 650,
+            "file": "index.html"
+          },
+          {
+            "kind": "jsParses",
+            "file": "index.html"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "<canvas|canvas",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "requestAnimationFrame",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "seed|random",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "regenerate|new seed",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "pause|resume",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "Harbor Current",
+            "flags": "i"
+          }
+        ]
+      }
+    ]
+  },
+  "rubric": {
+    "artifact": {
+      "path": "index.html",
+      "kind": "html"
+    },
+    "axes": [
+      {
+        "name": "structure",
+        "description": "Layout and hierarchy fit the content; sections are scannable and coherent."
+      },
+      {
+        "name": "grounding",
+        "description": "Seeded source content is used faithfully — no invented facts or dropped requirements."
+      },
+      {
+        "name": "interactivity",
+        "description": "Controls and states the page claims to offer actually work."
+      },
+      {
+        "name": "polish",
+        "description": "Styling is intentional and responsive rather than unstyled or broken."
+      }
+    ]
+  },
+  "qualityFocus": [
+    "canvas rendering",
+    "seeded variation",
+    "interactive controls"
+  ]
+}

package/data/craftbook-templates/ca/case-study/versions/1.0.1/craftbook.json

@@ -0,0 +1,143 @@
+{
+  "id": "case-study",
+  "name": "Customer Case Study",
+  "description": "Write a persuasive, evidence-backed customer success story in the classic challenge-solution-results arc: it first scopes the customer, the quantified before/after metrics, the approved customer quotes, and the single takeaway for prospects, then writes the case study with a results-forward summary, a relatable challenge, the solution narrative, and a measurable results section, then a review pass verifies every number and quote and the persuasive flow. Covers case study, customer success story, customer testimonial, success story, proof point, and B2B marketing content. Scoping the metrics and quotes before writing is the point: a small model that locks the quantified results first writes a credible story buyers trust, instead of a vague testimonial with adjectives but no proof.\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. Story scope (planner) — lock the customer, before/after metrics, quotes, and takeaway → gated on artifact `notes/scope.md` (markdown-notes)\n2. Write the case study (copywriter) — write the challenge-solution-results narrative → gated on `case-study.md` (markdown-doc)\n3. Proof & flow review (reviewer) — verify every metric and quote and the persuasive arc → gated on `case-study.md` (markdown-doc)\n\nThe gates never advance with an unmet criterion, and loop back to the\nowning phase to fix named gaps.\n",
+  "entryStepId": "scope",
+  "triggers": [
+    "write a case study",
+    "customer success story",
+    "write a success story",
+    "customer testimonial writeup",
+    "proof point story"
+  ],
+  "steps": [
+    {
+      "id": "scope",
+      "name": "Story scope",
+      "description": "lock the customer, before/after metrics, quotes, and takeaway",
+      "prompt": "1) Identify the customer: who they are, their industry/size, and what makes them relatable to the target prospect. 2) Define the CHALLENGE they faced before, in their terms. 3) Capture the quantified BEFORE and AFTER metrics (e.g. '40% slower onboarding → cut to 2 days', 'support tickets down 60%') — these are the spine of the story and must be specific, not vague. 4) Collect 1-2 approved, attributable customer quotes (name + title). 5) State the single TAKEAWAY a prospect should draw. Write an acceptance-criteria checklist (e.g. 'challenge-solution-results structure'; 'at least 2 quantified result metrics'; 'every metric and quote is sourced/approved, none invented'; 'at least one attributed customer quote'; 'results-forward summary at top'; 'one clear takeaway/CTA'). Use write_task_note for the story brief + metrics + checklist, and write the same to the produces path. No case-study prose yet.\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": "planner",
+      "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": "write"
+    },
+    {
+      "id": "write",
+      "name": "Write the case study",
+      "description": "write the challenge-solution-results narrative",
+      "prompt": "Write the case study from the brief. 1) Headline + a results-forward summary box at the top (customer, the headline metric, the takeaway) so a skimmer gets the win immediately. 2) CHALLENGE section: tell the relatable before-state and what was at stake. 3) SOLUTION section: how the product/service was adopted and what changed in their workflow. 4) RESULTS section: present the quantified before/after metrics prominently (a short stat list or callouts), and weave in the customer quotes. 5) Close with the takeaway and a CTA for prospects. Use a credible, specific, third-person voice; let the numbers and quotes do the persuading. Output GitHub-flavored markdown. Save to the produces path and note which checklist items pass.",
+      "suggestedRole": "copywriter",
+      "advanceWhen": {
+        "file": "case-study.md",
+        "minBytes": 1,
+        "sniff": "nonempty"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "case-study.md",
+            "bytes": 500
+          }
+        ],
+        "scripts": [
+          {
+            "name": "checkContains",
+            "scope": "standard",
+            "inputs": {
+              "file": "case-study.md",
+              "pattern": "(?:^|\\n)#{1,3}\\s+\\S",
+              "flags": "i"
+            }
+          }
+        ],
+        "onReject": "write",
+        "maxAttempts": 3
+      },
+      "next": "review"
+    },
+    {
+      "id": "review",
+      "name": "Proof & flow review",
+      "description": "verify every metric and quote and the persuasive arc",
+      "prompt": "Review and edit the case study in place against the checklist. 1) Verify EVERY metric and quote against the scope's sourced data — nothing may be invented, rounded misleadingly, or unattributed (this is the credibility check). 2) Confirm the challenge-solution-results structure reads as a clear arc and the results-forward summary is at the top. 3) Cut vague claims and adjectives that are not backed by a number or quote. 4) Confirm at least one attributed customer quote and at least two quantified results. 5) Confirm the takeaway and CTA are clear. Fix weak passages directly. Save the polished case study to the produces path and note any criteria still unmet.",
+      "suggestedRole": "reviewer",
+      "advanceWhen": {
+        "file": "case-study.md",
+        "minBytes": 1,
+        "sniff": "nonempty"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "case-study.md",
+            "bytes": 500
+          }
+        ],
+        "scripts": [
+          {
+            "name": "checkContains",
+            "scope": "standard",
+            "inputs": {
+              "file": "case-study.md",
+              "pattern": "(?:^|\\n)#{1,3}\\s+\\S",
+              "flags": "i"
+            }
+          }
+        ],
+        "onReject": "review",
+        "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": "Read case-study.md against the scope. Check EACH criterion and write PASS/FAIL: (a) clear challenge-solution-results structure with a results-forward summary at top; (b) at least two specific, quantified result metrics; (c) every metric and quote matches the sourced data — none invented or unattributed; (d) at least one attributed customer quote; (e) one clear takeaway and CTA; (f) credible, specific voice with no unbacked adjectives. A story with vague claims and no real numbers FAILS — loop back to write.\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: \"write\" })` 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": "case-study.md"
+        }
+      ],
+      "next": "write"
+    },
+    {
+      "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"
+}