@bendyline/gilde 0.1.26 → 0.1.28

package/data/craftbook-templates/na/narrated-slideshow/versions/1.1.1/test.json

@@ -0,0 +1,86 @@
+{
+  "schemaVersion": 1,
+  "title": "Animated Content Slideshow Markdown-source smoke eval",
+  "objective": "Verify that the media workflow produces concise scene-structured Markdown before DocBlocks MP4/GIF conversion; catalog contract tests cover the media toolset and dual artifact gate.",
+  "tags": [
+    "media"
+  ],
+  "prompt": "Read source/brief.md and write slideshow.md for a seven-scene animated operations update. Use one H1 heading per scene, short on-screen bullets, and a final next-actions scene. Do not create HTML.",
+  "setup": {
+    "projectName": "Animated Content Slideshow Eval",
+    "about": "The slideshow source is Markdown and will be rendered to MP4 and GIF by DocBlocks.",
+    "missionObjectives": "Create concise, source-grounded slideshow.md with one H1 per scene and no HTML intermediary.",
+    "files": [
+      {
+        "path": "source/brief.md",
+        "content": "# Boreal Desk Returns Pilot\n\nAudience: operations leads.\n\nFacts:\n- Pilot coverage: 18 SKUs.\n- Median first response: 18 hours to 6 hours.\n- Preventable refund leakage: 14.2% to 8.9%.\n- Top unresolved complaint: status silence after photo submission.\n- Next actions: automated status emails, barcode-exception training, weekly Finance exception export.\n\nDo not invent other metrics."
+      }
+    ],
+    "worker": {
+      "name": "Jules",
+      "role": "Copywriter"
+    }
+  },
+  "mocks": [],
+  "success": {
+    "summary": "slideshow.md is a concise, source-grounded scene sequence ready for DocBlocks MP4/GIF conversion.",
+    "deliverables": [
+      {
+        "path": "slideshow.md",
+        "kind": "markdown-doc",
+        "minBytes": 650,
+        "checks": [
+          {
+            "kind": "contains",
+            "file": "slideshow.md",
+            "pattern": "(?:^|\\n)#\\s+.+",
+            "flags": "m"
+          },
+          {
+            "kind": "contains",
+            "file": "slideshow.md",
+            "pattern": "18\\s+SKUs|18\\s+hours|6\\s+hours|14\\.2%|8\\.9%",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "slideshow.md",
+            "pattern": "automated status emails|barcode-exception training|weekly Finance exception export",
+            "flags": "i"
+          },
+          {
+            "kind": "notContains",
+            "file": "slideshow.md",
+            "pattern": "<html|<script|<style|base64",
+            "flags": "i"
+          }
+        ]
+      }
+    ]
+  },
+  "rubric": {
+    "artifact": {
+      "path": "slideshow.md",
+      "kind": "markdown"
+    },
+    "axes": [
+      {
+        "name": "story",
+        "description": "The scenes form a coherent update with one message per scene and a clear final action."
+      },
+      {
+        "name": "grounding",
+        "description": "Every metric and action comes from the seeded brief."
+      },
+      {
+        "name": "renderability",
+        "description": "One H1 per scene and concise blocks make the source suitable for rendered MP4/GIF output."
+      }
+    ]
+  },
+  "qualityFocus": [
+    "one H1 per scene",
+    "source grounding",
+    "no HTML intermediary"
+  ]
+}

package/data/craftbook-templates/ne/newsletter-issue/versions/1.0.1/craftbook.json

@@ -0,0 +1,143 @@
+{
+  "id": "newsletter-issue",
+  "name": "Newsletter Issue",
+  "description": "Produce a single polished, email-client-safe newsletter issue — intro, a few curated stories with links, a featured section, and a CTA — that renders correctly across email clients. Outlines the issue's theme and section lineup FIRST, writes scannable, personable copy with working links, then builds the email-safe HTML using inline styles and table layout so it survives Gmail/Outlook. Use for recurring email newsletters, product updates, and curated digests sent to subscribers.\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. Outline the issue (planner) — theme, section lineup, story picks, and the one CTA → gated on artifact `notes/outline.md` (markdown-notes)\n2. Write the copy (copywriter) — scannable, personable copy with links and one CTA → gated on artifact `notes/write.md` (markdown-notes)\n3. Build the email HTML (developer) — render index.html email-safe: inline styles, table layout, ~600px → 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": "outline",
+  "triggers": [
+    "newsletter issue",
+    "write a newsletter",
+    "email newsletter",
+    "build a newsletter",
+    "weekly update email",
+    "subscriber email"
+  ],
+  "steps": [
+    {
+      "id": "outline",
+      "name": "Outline the issue",
+      "description": "theme, section lineup, story picks, and the one CTA",
+      "prompt": "Plan the issue before writing. Step 1: name this issue's theme/hook and the audience. Step 2: lay out the section lineup in order — subject line + preheader, a short personal intro, 3-5 curated stories (each: title, link, 1-2 line take), a featured/deep-dive block, and a single clear CTA. Step 3: pick the actual stories/links to include and note the angle for each; cut anything off-theme. Step 4: decide the one primary action you want readers to take. Step 5: write an acceptance-criteria checklist ('has a subject line + preheader', 'intro is short and personable', '3-5 stories each with a working link and a one-line take', 'exactly one primary CTA', 'scannable in under two minutes'). Write the lineup + checklist via write_task_note AND to notes/outline.md. No copy or HTML yet.\n\nThe deliverable `notes/outline.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/outline.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "notes/outline.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "notes/outline.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "outline",
+        "maxAttempts": 3
+      },
+      "next": "write"
+    },
+    {
+      "id": "write",
+      "name": "Write the copy",
+      "description": "scannable, personable copy with links and one CTA",
+      "prompt": "Write the newsletter copy from the outline in a warm, scannable voice. Step 1: write a subject line (under ~50 chars, curiosity or value) and a preheader that complements it. Step 2: write a short, personable intro (2-4 sentences) tied to the theme. Step 3: for each curated story write a punchy title and a 1-2 line take that gives the reader a reason to click, with the link. Step 4: write the featured/deep-dive block — a few sentences with a clear payoff. Step 5: write the one CTA with action-oriented button copy. Keep paragraphs short, use the second person, and make it skimmable. Do not invent links — use the ones from the outline. Write the section-by-section copy via write_task_note AND to notes/write.md.\n\nThe deliverable `notes/write.md` lands in the project's artifacts drawer — write it with `write_artifact` and read it back with `read_artifact`; the shipped workspace stays untouched.",
+      "suggestedRole": "copywriter",
+      "advanceWhen": {
+        "file": "notes/write.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "notes/write.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "notes/write.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "write",
+        "maxAttempts": 3
+      },
+      "next": "build"
+    },
+    {
+      "id": "build",
+      "name": "Build the email HTML",
+      "description": "render index.html email-safe: inline styles, table layout, ~600px",
+      "prompt": "Build the issue as a single self-contained index.html that renders in real email clients. Step 1: use a table-based layout centered at ~600px with all CSS INLINE on elements (email clients strip <style> and ignore fl/grid) — no external stylesheets, no web fonts, web-safe font stacks only. Step 2: lay out the sections per the outline order (preheader text first, hidden but present; intro; story list; featured block; CTA button) with the approved copy verbatim. Step 3: render the CTA as a bulletproof button (a padded, background-colored anchor styled as a table cell) and make every story link a real working <a href>. Step 4: keep images optional and provide alt text; ensure it degrades gracefully with images off. Step 5: include a footer with an (illustrative) unsubscribe link. On a loop-back, fix ONLY the named gaps. Write the path via write_task_note.",
+      "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": "QA the newsletter against the locked criteria. Step 1: open/render index.html. Step 2: confirm email-safety: table layout, inline styles only (no reliance on <style>/flex/grid), centered ~600px, web-safe fonts. Step 3: check EACH acceptance criterion: subject line + preheader present, short personable intro, 3-5 stories each with a working <a href> link and a one-line take, exactly one primary CTA rendered as a tappable button, footer with unsubscribe. Step 4: confirm it is scannable in under two minutes and links are real (from the outline, not invented). Write PASS/FAIL per criterion with the offending section on any FAIL.\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/ne/newsletter-issue/versions/1.0.1/test.json

@@ -0,0 +1,110 @@
+{
+  "schemaVersion": 1,
+  "title": "Newsletter Issue smoke eval",
+  "objective": "Self-contained smoke eval for the Newsletter Issue craftbook using the corpus generic harness.",
+  "tags": [
+    "corpus"
+  ],
+  "prompt": "We need a newsletter issue for the returns-desk work. The backgound info is in source/brief.md — have a look and write it up in report.md.",
+  "setup": {
+    "projectName": "Newsletter Issue Eval",
+    "about": "Self-contained eval project for newsletter-issue. Seeded inputs are under workspace/source or workspace/fixtures; final deliverable is workspace/report.md.",
+    "missionObjectives": "Use the Newsletter Issue craftbook/template, read the seeded local fixtures, and write report.md without network calls, real credentials, or live services.",
+    "files": [
+      {
+        "path": "source/brief.md",
+        "content": "# Newsletter Issue 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: newsletter-issue - Newsletter Issue.\n"
+      }
+    ],
+    "worker": {
+      "name": "Jules",
+      "role": "Writer"
+    }
+  },
+  "mocks": [],
+  "success": {
+    "summary": "report.md is a source-grounded markdown artifact with required facts and actions.",
+    "deliverables": [
+      {
+        "path": "report.md",
+        "kind": "markdown-report",
+        "minBytes": 1000,
+        "checks": [
+          {
+            "kind": "contains",
+            "file": "report.md",
+            "pattern": "(?:^|\\n)#{1,3}\\s+\\S",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "report.md",
+            "pattern": "source/brief\\.md|Brief",
+            "flags": "i",
+            "label": "cite or name the seeded source"
+          },
+          {
+            "kind": "contains",
+            "file": "report.md",
+            "pattern": "18\\b[\\s\\S]{0,30}\\bSKUs",
+            "flags": "i",
+            "label": "include the 18-SKU pilot scope"
+          },
+          {
+            "kind": "contains",
+            "file": "report.md",
+            "pattern": "18\\s*hours|6\\s*hours",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "report.md",
+            "pattern": "14\\.2%|8\\.9%",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "report.md",
+            "pattern": "status silence|photo submission",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "report.md",
+            "pattern": "automated status emails|barcode|Finance",
+            "flags": "i"
+          }
+        ]
+      }
+    ]
+  },
+  "rubric": {
+    "artifact": {
+      "path": "report.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": [
+    "source-grounded prose",
+    "section structure",
+    "next-action clarity"
+  ]
+}

package/data/craftbook-templates/no/notification-router/versions/1.0.1/craftbook.json

@@ -0,0 +1,158 @@
+{
+  "id": "notification-router",
+  "name": "Notification Router",
+  "description": "Build an event-to-channel notification router: a small module that takes incoming events and routes each to the right destination (Slack channel, email, PagerDuty, webhook) based on type, severity, and quiet-hours rules — with dedupe, throttling, and a fallback channel. Scopes the routing matrix and policy FIRST (event taxonomy, channel map, severity→destination rules, dedupe key, rate limits, fallback), then a developer implements the router module to that matrix, then writes tests covering each routing branch. Scoping the matrix before coding is what guarantees every event type has a defined destination and that critical events can never be silently dropped. Use for notification routing, alert fan-out, event dispatch, webhook routing, and on-call/Slack notification systems.\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 router (planner) — lock the routing matrix, dedupe, throttle, and fallback → gated on artifact `notes/scope.md` (markdown-notes)\n2. Build the router (developer) — implement the router module to the matrix → gated on `router.ts` (code-module)\n3. Test the router (developer) — cover every routing branch with assertions → gated on `router.test.ts` (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": [
+    "notification router",
+    "route events to channels",
+    "alert fan-out",
+    "event dispatch",
+    "send notifications to slack"
+  ],
+  "steps": [
+    {
+      "id": "scope",
+      "name": "Scope the router",
+      "description": "lock the routing matrix, dedupe, throttle, and fallback",
+      "prompt": "Define the routing contract before coding. (1) Enumerate the event taxonomy (the event types/shapes the router accepts) and the available destination channels. (2) Build the routing matrix: for each (event type × severity) pair, the destination channel(s) — make it total so no input is undefined. (3) Define the dedupe key (which fields identify a duplicate within a window) and the suppression window. (4) Set per-channel rate limits/throttling and a quiet-hours rule (and which severities override quiet hours). (5) Define a fallback channel for events that match no rule, so nothing is dropped silently, and the behavior on a destination send failure (retry/fallback). (6) Pick the language and the function signature, e.g. route(event) -> Destination[]. Write an acceptance-criteria checklist ('every (type,severity) maps to a destination', 'unmatched events hit the fallback, never dropped', 'duplicates within the window are suppressed', 'rate limits enforced', 'critical severity overrides quiet hours', 'pure routing logic is unit-testable without live channels') plus the matrix 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": "build"
+    },
+    {
+      "id": "build",
+      "name": "Build the router",
+      "description": "implement the router module to the matrix",
+      "prompt": "Implement the router as a single module (e.g. router.ts/router.py) realizing the locked matrix. Separate PURE routing logic — route(event) returning the destination list — from any side-effecting send, so routing is testable in isolation. Implement: matrix lookup with the fallback for unmatched events, dedupe via the locked key + window (an in-memory recent-key set is fine), per-channel throttling, and the quiet-hours rule with the critical-severity override. Validate/normalize inbound events and reject malformed ones explicitly. Never let an event with no matching rule vanish — it goes to fallback. Add brief doc comments mapping code back to matrix rows. On a loop-back fix only the flagged behavior. Write the module path and the implemented signature to notes via write_task_note.",
+      "suggestedRole": "developer",
+      "advanceWhen": {
+        "file": "router.ts",
+        "minBytes": 1,
+        "sniff": "nonempty"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "router.ts",
+            "bytes": 200
+          },
+          {
+            "kind": "sniff",
+            "file": "router.ts",
+            "sniff": "nonempty"
+          },
+          {
+            "kind": "esmImports",
+            "file": "router.ts"
+          },
+          {
+            "kind": "sourceParses",
+            "file": "router.ts"
+          }
+        ],
+        "onReject": "build",
+        "maxAttempts": 3
+      },
+      "next": "test"
+    },
+    {
+      "id": "test",
+      "name": "Test the router",
+      "description": "cover every routing branch with assertions",
+      "prompt": "Write router.test.ts exercising the router's pure logic. Cover, with explicit assertions: (1) a representative event for each (type,severity) row resolves to the matrix's destination; (2) an unmatched event routes to the fallback and is NOT dropped; (3) a duplicate within the window is suppressed and the same key after the window is allowed; (4) throttling blocks the N+1th send to a channel in the window; (5) a critical event during quiet hours still routes, a non-critical one is held; (6) a malformed event is rejected. Use the test runner's describe/it/expect (or equivalent assert). Tests must run without live channels. On a loop-back add the missing cases. Write the test path and the branch-coverage list to notes via write_task_note.",
+      "suggestedRole": "developer",
+      "advanceWhen": {
+        "file": "router.test.ts",
+        "minBytes": 1,
+        "sniff": "nonempty"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "router.test.ts",
+            "bytes": 300
+          },
+          {
+            "kind": "sniff",
+            "file": "router.test.ts",
+            "sniff": "nonempty"
+          },
+          {
+            "kind": "esmImports",
+            "file": "router.test.ts"
+          },
+          {
+            "kind": "sourceParses",
+            "file": "router.test.ts"
+          }
+        ],
+        "scripts": [
+          {
+            "name": "checkContains",
+            "scope": "standard",
+            "inputs": {
+              "file": "router.test.ts",
+              "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": "QA the router against the locked criteria. (1) Run the test suite (or trace it) — every test must pass; a failing/empty suite is FAIL. (2) Confirm tests exist for each matrix row, the fallback path, dedupe (hit and post-window allow), throttling, the quiet-hours + critical-override behavior, and malformed-event rejection. (3) Read router.ts: is routing pure and side-effect-free, is the matrix total, can an unmatched event ever be silently dropped (must be NO)? (4) Spot-check 2 matrix rows in code against notes/scope.md. Write PASS/FAIL per criterion with the gaps.\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": "router.test.ts"
+        }
+      ],
+      "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"
+}