@bendyline/gilde 0.1.26 → 0.1.28

package/data/craftbook-templates/ch/chart-pack/versions/1.0.1/craftbook.json

@@ -0,0 +1,148 @@
+{
+  "id": "chart-pack",
+  "name": "Chart Pack from Data",
+  "description": "Build a single interactive HTML page of charts that answers a defined set of questions about a dataset. Scopes the questions and the right chart type per question FIRST (so you don't make a pretty chart that answers nothing), then analyzes the data into chart-ready series, then builds one self-contained HTML page rendering every chart with titles, axis labels, and a one-line takeaway caption each. Use this for a dashboard of charts, a visualization pack, a metrics page, or turning a CSV into graphs and plots.\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 questions (planner) — lock the questions and the chart type that answers each → gated on artifact `notes/question-scope.md` (markdown-notes)\n2. Analyze into chart-ready series (data-analyst) — aggregate the data into the exact series each chart needs → gated on `data/series.json` (json)\n3. Build the chart page (developer) — render every chart in one self-contained 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": "question-scope",
+  "triggers": [
+    "make charts from data",
+    "chart pack",
+    "visualize this dataset",
+    "graphs from a csv",
+    "build a charts page"
+  ],
+  "steps": [
+    {
+      "id": "question-scope",
+      "name": "Scope the questions",
+      "description": "lock the questions and the chart type that answers each",
+      "prompt": "Decide WHAT the chart pack must answer before any analysis. Step 1: list 4-8 specific questions a reader has about this data (e.g. 'how did revenue trend by month?', 'which 5 categories are largest?', 'how are values distributed?'). Step 2: for EACH question pick the chart type that answers it best and say why (trend over time -> line; part-to-whole -> bar/stacked, not pie unless <=5 slices; distribution -> histogram; comparison -> grouped bar; relationship -> scatter). Step 3: name the exact columns and aggregation each chart needs. Step 4: write an acceptance-criteria checklist ('one chart per question', 'every chart has a title + axis labels', 'every chart has a one-line takeaway caption', 'chart type matches the question'). Call write_task_note and write the question->chart mapping + checklist to notes/question-scope.md.\n\nThe deliverable `notes/question-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/question-scope.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "notes/question-scope.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "notes/question-scope.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "question-scope",
+        "maxAttempts": 3
+      },
+      "next": "analyze"
+    },
+    {
+      "id": "analyze",
+      "name": "Analyze into chart-ready series",
+      "description": "aggregate the data into the exact series each chart needs",
+      "prompt": "Transform the raw data into the precise series each scoped chart needs. Step 1: for each chart, group/aggregate the columns named in the scope (sum, count, average, bucketed histogram) and produce ordered (label, value) arrays. Step 2: sort sensibly (time ascending, categories by magnitude) and cap to a readable count (top-N + 'other' if needed). Step 3: write the computed takeaway caption for each chart from the numbers ('March was the peak at 4.2k, up 38% from Feb'). Step 4: emit the series as data/series.json keyed by chart id so the build phase reads it directly. Call write_task_note with the series summary and the captions.",
+      "suggestedRole": "data-analyst",
+      "advanceWhen": {
+        "file": "data/series.json",
+        "minBytes": 1,
+        "sniff": "json-valid"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "data/series.json",
+            "bytes": 2
+          }
+        ],
+        "scripts": [
+          {
+            "name": "checkJsonValid",
+            "scope": "standard",
+            "inputs": {
+              "file": "data/series.json"
+            }
+          }
+        ],
+        "onReject": "analyze",
+        "maxAttempts": 3
+      },
+      "next": "build"
+    },
+    {
+      "id": "build",
+      "name": "Build the chart page",
+      "description": "render every chart in one self-contained index.html",
+      "prompt": "Build a single self-contained index.html that renders every scoped chart from data/series.json. Step 1: use inline <canvas>/SVG drawing or a single inlined chart library — no external network asset that could fail offline; if you embed the series, keep it in sync with the JSON. Step 2: render each chart with its title, labeled axes, readable ticks, and a legend where needed. Step 3: place the one-line takeaway caption under each chart. Step 4: lay the charts out responsively in a grid that reads top-to-bottom in the scoped order. Step 5: ensure no console errors and that charts have real data, not placeholders. On a loop-back, fix only the named gaps. Call write_task_note with the path and chart count.",
+      "suggestedRole": "developer",
+      "consumes": [
+        {
+          "file": "data/series.json"
+        }
+      ],
+      "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": "Open index.html (render it if a browser capability exists, else trace the source). Verify: there is one chart per scoped question; each chart has a title, labeled axes, and a takeaway caption; the chart type matches the question from the scope; charts render real values from the series, not placeholders; and there are no console errors. Spot-check two charts' values against data/series.json. Write PASS/FAIL per criterion; any FAIL loops 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/ch/chart-pack/versions/1.0.1/test.json

@@ -0,0 +1,104 @@
+{
+  "schemaVersion": 1,
+  "title": "Interactive chart pack from seeded CSV",
+  "objective": "Measure whether the chart-pack craftbook scopes analytical questions, derives series from data, and builds a self-contained chart page.",
+  "tags": [
+    "html-page"
+  ],
+  "prompt": "In the `Chart Pack Eval` project, read `data/support-week.csv` and build `index.html`: an interactive chart pack answering ticket volume by day, SLA breaches by queue, and reopen rate by queue. Include chart titles, axis labels, one-line takeaway captions, and inline data/JS with no external libraries.",
+  "setup": {
+    "projectName": "Chart Pack Eval",
+    "about": "Self-contained eval project for the chart-pack craftbook. The dataset is workspace/data/support-week.csv.",
+    "missionObjectives": "Build a single-page chart pack from the seeded CSV with three question-driven charts, labels, captions, and inline JS/CSS.",
+    "files": [
+      {
+        "path": "data/support-week.csv",
+        "content": "day,queue,tickets,sla_breaches,reopen_rate\nMon,Returns,82,14,0.18\nMon,Shipping,61,9,0.11\nTue,Returns,64,8,0.14\nTue,Shipping,55,5,0.09\nWed,Returns,58,6,0.12\nWed,Shipping,49,4,0.08\nThu,Returns,71,10,0.16\nThu,Shipping,52,6,0.1\nFri,Returns,77,11,0.15\nFri,Shipping,57,7,0.1\n"
+      }
+    ],
+    "worker": {
+      "name": "Karel",
+      "role": "Developer"
+    }
+  },
+  "mocks": [],
+  "success": {
+    "summary": "workspace/index.html is a complete chart pack page with source-derived data, chart labels, captions, and inline rendering logic.",
+    "deliverables": [
+      {
+        "path": "index.html",
+        "kind": "html-page",
+        "minBytes": 3400,
+        "checks": [
+          {
+            "kind": "cssMinBytes",
+            "bytes": 600,
+            "file": "index.html"
+          },
+          {
+            "kind": "jsParses",
+            "file": "index.html"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "ticket volume|SLA breaches|reopen rate",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "Returns|Shipping|Mon|Fri"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "axis|label|caption|takeaway",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "82|14|0\\.18|57",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "canvas|svg|bar|line",
+            "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": [
+    "question-first charts",
+    "data-derived series",
+    "self-contained visualization"
+  ]
+}

package/data/craftbook-templates/ch/chrome-extension/versions/1.0.1/craftbook.json

@@ -0,0 +1,148 @@
+{
+  "id": "chrome-extension",
+  "name": "Browser Extension",
+  "description": "Build a Manifest V3 browser extension scaffold — a popup, a content script, and the manifest — that does one concrete thing on the current page (highlight, count, extract, or toggle). Scopes the single capability and the required permissions first, designs the popup UI, then builds a valid manifest.json plus popup and content-script files wired by messaging. Extensions fail at the manifest and the popup↔content messaging boundary, so the scope phase pins the exact MV3 permissions and message contract before any code, keeping a small model from producing a manifest the browser rejects.\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 (planner) — the one capability + MV3 permissions + message contract → gated on artifact `notes/scope.md` (markdown-notes)\n2. Popup UI design (designer) — popup layout, button, result display → gated on artifact `notes/ui-design.md` (markdown-notes)\n3. Build (developer) — manifest.json + popup + content script → 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": "scope",
+  "triggers": [
+    "chrome extension",
+    "browser extension",
+    "build an extension",
+    "manifest v3 extension",
+    "firefox extension",
+    "browser plugin"
+  ],
+  "steps": [
+    {
+      "id": "scope",
+      "name": "Scope",
+      "description": "the one capability + MV3 permissions + message contract",
+      "prompt": "Scope the extension to ONE capability. (1) State exactly what it does on the current page in one sentence (e.g. 'count and highlight all links'). (2) List the minimum MV3 permissions and host_permissions needed and why — no over-permissioning. (3) Define the components: popup (trigger + display), content script (acts on the page), and the message contract between them (message names and payloads). (4) Decide what the popup shows back to the user. (5) Write an acceptance-criteria checklist of 5-8 items, e.g. 'manifest is valid MV3 (manifest_version 3)', 'the popup has a working button', 'clicking it messages the content script', 'the content script performs the action on the page', 'a result is shown in the popup', 'only the listed permissions are requested'. Write to notes/scope.md and via write_task_note. No code 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": "ui-design"
+    },
+    {
+      "id": "ui-design",
+      "name": "Popup UI design",
+      "description": "popup layout, button, result display",
+      "prompt": "Design the popup UI. (1) Pick a small fixed popup size and a clean palette (hex). (2) Lay out the action button(s) and the result/status area. (3) Specify states: idle, running, result, and error. (4) Keep styles self-contained in the popup. (5) Note any icon needs. Write the popup spec to notes/ui-design.md and via write_task_note. No code yet.\n\nThe deliverable `notes/ui-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": "designer",
+      "advanceWhen": {
+        "file": "notes/ui-design.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "notes/ui-design.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "notes/ui-design.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "ui-design",
+        "maxAttempts": 3
+      },
+      "next": "build"
+    },
+    {
+      "id": "build",
+      "name": "Build",
+      "description": "manifest.json + popup + content script",
+      "prompt": "Build the extension files to the scope and UI spec. (1) Write a valid manifest.json with manifest_version 3, name, version, description, the exact permissions/host_permissions from scope, an action.default_popup, and a content_scripts entry. (2) Write popup.html + popup.js to the UI spec; the button sends the contract message to the active tab via chrome.tabs.query + chrome.tabs.sendMessage. (3) Write content.js that listens with chrome.runtime.onMessage, performs the page action, and replies with the result. (4) Render the reply in the popup, handling the error state. Bundle everything; the deliverable is index.html acting as the popup plus the supporting files. On a loop-back, fix only the named gaps. write_task_note the file paths and passing criteria.",
+      "suggestedRole": "developer",
+      "advanceWhen": {
+        "file": "index.html",
+        "minBytes": 1,
+        "sniff": "html-complete"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "index.html",
+            "bytes": 600
+          },
+          {
+            "kind": "htmlLint",
+            "file": "index.html"
+          },
+          {
+            "kind": "sniff",
+            "file": "manifest.json",
+            "sniff": "json-valid"
+          }
+        ],
+        "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 extension scaffold. Read manifest.json, popup (index.html) + its JS, and the content script. Check EACH criterion from notes/scope.md and write PASS/FAIL with a reason: is manifest.json valid JSON with manifest_version 3 and an action popup and content_scripts entry, does the popup have a working button, does it message the content script via chrome.tabs.sendMessage, does the content script onMessage perform the action and reply, does the popup show the result, are only the listed permissions requested? A manifest the browser would reject (missing manifest_version 3 or malformed) is a FAIL — 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/ch/chrome-extension/versions/1.0.1/test.json

@@ -0,0 +1,97 @@
+{
+  "schemaVersion": 1,
+  "title": "Browser Extension smoke eval",
+  "objective": "Self-contained smoke eval for the Browser Extension craftbook using the html-page generic harness.",
+  "tags": [
+    "html-page"
+  ],
+  "prompt": "Can you biuld us a little page for this? The content notes are in source/page-content.md. Save it as index.html — one file, nothing fancy needed on our end.",
+  "setup": {
+    "projectName": "Browser Extension Eval",
+    "about": "Self-contained eval project for chrome-extension. Seeded inputs are under workspace/source or workspace/fixtures; final deliverable is workspace/index.html.",
+    "missionObjectives": "Use the Browser Extension 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": "# Browser Extension 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: chrome-extension - Browser Extension.\n"
+      },
+      {
+        "path": "source/page-content.md",
+        "content": "# Boreal Desk Support Board\n\nBuild content around a support operations board. Required labels: Open issues, Status silence, Response time, Refund leakage, Next action. Required metric text: 18 hours to 6 hours and 14.2% to 8.9%.\n"
+      }
+    ],
+    "worker": {
+      "name": "Jules",
+      "role": "Developer"
+    }
+  },
+  "mocks": [],
+  "success": {
+    "summary": "index.html is a source-grounded self-contained HTML page/tool.",
+    "deliverables": [
+      {
+        "path": "index.html",
+        "kind": "html-page",
+        "minBytes": 3000,
+        "checks": [
+          {
+            "kind": "cssMinBytes",
+            "bytes": 650,
+            "file": "index.html"
+          },
+          {
+            "kind": "jsParses",
+            "file": "index.html"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "Boreal|Support Board|returns",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "18\\s*hours|6\\s*hours|14\\.2%|8\\.9%",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "button|input|filter|tab|card|section|nav",
+            "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": [
+    "self-contained UI",
+    "source grounding",
+    "responsive structure"
+  ]
+}

package/data/craftbook-templates/ci/ci-pipeline/versions/1.0.1/craftbook.json

@@ -0,0 +1,132 @@
+{
+  "id": "ci-pipeline",
+  "name": "CI Pipeline from Scratch",
+  "description": "Build a continuous-integration pipeline that installs, lints, tests, and builds on every push/PR — fast, cached, and gating merges on green. Scopes the pipeline contract FIRST — triggers, the job/stage graph, the matrix, caching strategy, and the gates — then writes the CI workflow YAML, then a reviewer validates the syntax, stage ordering, caching, and that it actually fails on a broken build. Covers CI triggers, job/stage dependencies, dependency caching, build matrices, status checks, fail-fast gating, and a valid workflow file.\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 pipeline (planner) — lock triggers, stages, matrix, caching, gates → gated on artifact `notes/scope.md` (markdown-notes)\n2. Write the workflow (developer) — implement the CI workflow YAML → gated on `.github/workflows/ci.yml` (yaml-spec)\n3. Verify the workflow (reviewer) — confirm syntax, ordering, caching, gating → gated on artifact `notes/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 ci",
+    "create a ci pipeline",
+    "github actions workflow",
+    "build a ci/cd pipeline",
+    "add automated testing on push"
+  ],
+  "steps": [
+    {
+      "id": "scope",
+      "name": "Scope the pipeline",
+      "description": "lock triggers, stages, matrix, caching, gates",
+      "prompt": "Scope the CI pipeline before writing YAML. Step 1: Decide the triggers (push to which branches, pull requests, manual). Step 2: Lay out the job/stage graph: install → lint → test → build, including which stages can run in parallel and which depend on others. Step 3: Decide the matrix (e.g. OS/runtime versions) and the caching strategy (cache the dependency store keyed on the lockfile) to keep runs fast. Step 4: Define the gates: which stages must pass to mark the check green and block a merge, and fail-fast behavior. Step 5: Write a numbered acceptance-criteria checklist of 5-9 items (e.g. 'the workflow triggers on push and PR', 'dependencies are cached', 'a failing test fails the pipeline and blocks merge', 'lint/test/build run in a sensible order'). `write_task_note` the scope + checklist and write the same to 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": "build"
+    },
+    {
+      "id": "build",
+      "name": "Write the workflow",
+      "description": "implement the CI workflow YAML",
+      "prompt": "Author the CI workflow file to the scope. Step 1: Set the triggers and the matrix exactly as scoped. Step 2: Define the jobs/stages with their dependency edges (test depends on install, etc.) and a checkout + runtime-setup step. Step 3: Add dependency caching keyed on the lockfile so repeat runs are fast. Step 4: Run lint, test, and build as gating steps so any non-zero exit fails the job. Step 5: Ensure the file is valid YAML for the target CI system and that the failing-test case would actually fail the run. Write the workflow to the produces path. On a loop-back, fix only the named gaps. `write_task_note` the file path and which criteria now pass.",
+      "suggestedRole": "developer",
+      "advanceWhen": {
+        "file": ".github/workflows/ci.yml",
+        "minBytes": 1,
+        "sniff": "nonempty"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": ".github/workflows/ci.yml",
+            "bytes": 200
+          },
+          {
+            "kind": "sniff",
+            "file": ".github/workflows/ci.yml",
+            "sniff": "nonempty"
+          }
+        ],
+        "onReject": "build",
+        "maxAttempts": 3
+      },
+      "next": "verify"
+    },
+    {
+      "id": "verify",
+      "name": "Verify the workflow",
+      "description": "confirm syntax, ordering, caching, gating",
+      "prompt": "Verify the CI workflow. Step 1: Confirm the file parses as valid YAML and conforms to the target CI system's schema (lint it if a linter is available). Step 2: Confirm the triggers, matrix, and stage-dependency ordering match the scope. Step 3: Confirm caching is wired to the lockfile and the cache key is sensible. Step 4: Trace the gating logic and confirm a failing lint/test/build step would fail the run and block a merge (no `continue-on-error` masking failures). Write a verification note with the YAML-validity result and the gating trace to the produces path.\n\nThe deliverable `notes/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": "notes/verify.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": ".github/workflows/ci.yml",
+            "bytes": 200
+          },
+          {
+            "kind": "sniff",
+            "file": ".github/workflows/ci.yml",
+            "sniff": "nonempty"
+          }
+        ],
+        "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": "Validate the workflow file. For EACH acceptance criterion: confirm it is valid YAML for the target CI system, confirm triggers/matrix/stage-ordering match the scope, confirm dependency caching is wired correctly, and confirm a failing test would fail the pipeline and block merge (nothing masks failures). Write PASS/FAIL per criterion.\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": ".github/workflows/ci.yml"
+        }
+      ],
+      "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"
+}