@bendyline/gilde 0.1.26 → 0.1.28

package/data/craftbook-templates/pi/pitch-deck/versions/1.0.1/craftbook.json

@@ -0,0 +1,141 @@
+{
+  "id": "pitch-deck",
+  "name": "Investor Pitch Deck",
+  "description": "Build a fundraising or sales pitch deck that tells a tight investor-grade story: problem, solution, market size, product, business model, traction, go-to-market, competition, team, and the ask. Locks the NARRATIVE arc and per-slide message FIRST (a deck lives or dies on story order, not visuals), then designs a single consistent slide system, then builds a navigable HTML deck — one idea per slide, big claim plus one supporting proof, ending on a crisp ask and use-of-funds. Use for seed/Series-A raises, sales decks, demo days, and investor updates.\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. Narrative arc (planner) — lock the story order + one message per slide + the ask → gated on artifact `notes/narrative.md` (markdown-notes)\n2. Visual design (visual-designer) — one reusable slide system: grid, palette, type, number style → gated on artifact `notes/visual-design.md` (markdown-notes)\n3. Build the deck (developer) — implement a navigable index.html applying the system to the outline → gated on `index.html` (slide-deck)\n\nThe gates never advance with an unmet criterion, and loop back to the\nowning phase to fix named gaps.\n",
+  "entryStepId": "narrative",
+  "triggers": [
+    "pitch deck",
+    "investor deck",
+    "fundraising deck",
+    "make a deck to raise money",
+    "demo day slides",
+    "sales deck"
+  ],
+  "steps": [
+    {
+      "id": "narrative",
+      "name": "Narrative arc",
+      "description": "lock the story order + one message per slide + the ask",
+      "prompt": "Design the STORY before any layout or pixels. Step 1: gather the inputs you actually have (problem, who feels it, the product, any traction numbers, the market, the team, and the specific ask amount + use of funds). Step 2: lay out the canonical 10-12 slide arc in order: (1) title/one-liner, (2) problem, (3) solution, (4) how it works / product, (5) market size (TAM/SAM/SOM), (6) business model, (7) traction, (8) go-to-market, (9) competition / why-now, (10) team, (11) the ask + use of funds, (12) closing/contact. Step 3: for EACH slide write exactly one headline claim plus 1-3 supporting bullets or a single number — never a wall of text. Step 4: flag any slide where you lack data and note the assumption you will state. Step 5: write an acceptance-criteria checklist (e.g. 'opens with a one-line value prop title slide', 'problem precedes solution', 'market-size slide gives a concrete number with a stated basis', 'traction slide shows at least one metric or an honest \"pre-launch\" note', 'closes with a specific ask amount + use of funds', 'one core idea per slide, <= 40 words of body each'). Write the slide-by-slide outline + decisions + checklist via write_task_note AND to notes/narrative.md. No design, no HTML yet.\n\nThe deliverable `notes/narrative.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/narrative.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "notes/narrative.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "notes/narrative.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "narrative",
+        "maxAttempts": 3
+      },
+      "next": "visual-design"
+    },
+    {
+      "id": "visual-design",
+      "name": "Visual design",
+      "description": "one reusable slide system: grid, palette, type, number style",
+      "prompt": "Design ONE slide system the build will apply uniformly, so the deck reads as designed not assembled. Step 1: pick a palette with exact hex values (one ink, one background, one accent, one muted) and a confident type pairing (display weight for headlines, readable weight for body). Step 2: define the slide grid — title position, body zone, footer with slide number, and generous margins. Step 3: define how each slide ARCHETYPE renders: a hero/title slide, a big-number slide (for market size and traction), a 2-up or 3-up comparison slide (competition), a bullet slide, and a team slide. Step 4: specify one restrained accent treatment (a rule, a colored keyword, or a single accent shape) and a consistent emphasis style for the one big number per data slide. Step 5: write a visual-criteria checklist ('every slide uses the same grid + footer', 'exactly one accent color used consistently', 'big numbers are visually dominant on data slides', 'no slide mixes more than two type sizes for body'). Write the slide-system spec + checklist via write_task_note AND to notes/visual-design.md. No slide content yet.\n\nThe deliverable `notes/visual-design.md` lands in the project's artifacts drawer — write it with `write_artifact` and read it back with `read_artifact`; the shipped workspace stays untouched.",
+      "suggestedRole": "visual-designer",
+      "advanceWhen": {
+        "file": "notes/visual-design.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "notes/visual-design.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "notes/visual-design.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "visual-design",
+        "maxAttempts": 3
+      },
+      "next": "build"
+    },
+    {
+      "id": "build",
+      "name": "Build the deck",
+      "description": "implement a navigable index.html applying the system to the outline",
+      "prompt": "Implement the deck as a single self-contained index.html (inline CSS + minimal JS, no external assets or CDNs). Step 1: create one full-viewport section per slide following the locked narrative order. Step 2: apply the slide system exactly — same grid, palette hex values, type pairing, and footer-with-slide-number on every slide; render each slide using its archetype from the visual spec (hero, big-number, comparison, bullet, team). Step 3: wire keyboard navigation (ArrowLeft/ArrowRight or PageUp/PageDown) and visible slide numbers so it is presentable. Step 4: drop in the approved per-slide headline + supporting content from the outline verbatim — do not rewrite the story or invent new metrics. Step 5: make data slides visually lead with their one big number; ensure the ask slide states the concrete amount + use of funds. On a loop-back, fix ONLY the gaps the reviewer named and do not regress slides that already passed. Write the deck path + final slide count via write_task_note.",
+      "suggestedRole": "developer",
+      "advanceWhen": {
+        "file": "index.html",
+        "minBytes": 1,
+        "sniff": "nonempty"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "index.html",
+            "bytes": 600
+          }
+        ],
+        "scripts": [
+          {
+            "name": "checkContains",
+            "scope": "standard",
+            "inputs": {
+              "file": "index.html",
+              "pattern": "(?:slide|section|^---$)",
+              "flags": "im"
+            }
+          }
+        ],
+        "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 deck against the locked criteria. Step 1: open/render index.html (or trace the source) and step through every slide with the arrow keys; confirm navigation works and slide numbers show. Step 2: verify the narrative order matches the outline (title -> problem -> solution -> ... -> ask -> close) and that problem precedes solution. Step 3: check EACH acceptance criterion from notes/narrative.md and notes/visual-design.md: one idea per slide and <= 40 words of body each, market-size slide gives a concrete number with a stated basis, traction slide shows a metric or an honest pre-launch note, the deck closes with a specific ask amount + use of funds, every slide shares the same grid/footer and one consistent accent color, big numbers dominate on data slides. Step 4: confirm no invented metrics crept in beyond the outline. Write PASS/FAIL for every criterion with the offending slide noted 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/pi/pitch-deck/versions/1.0.1/test.json

@@ -0,0 +1,97 @@
+{
+  "schemaVersion": 1,
+  "title": "Investor Pitch Deck smoke eval",
+  "objective": "Self-contained smoke eval for the Investor Pitch Deck 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": "Investor Pitch Deck Eval",
+    "about": "Self-contained eval project for pitch-deck. Seeded inputs are under workspace/source or workspace/fixtures; final deliverable is workspace/index.html.",
+    "missionObjectives": "Use the Investor Pitch Deck 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": "# Investor Pitch Deck 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: pitch-deck - Investor Pitch Deck.\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/pl/playtest-report/versions/1.0.1/craftbook.json

@@ -0,0 +1,140 @@
+{
+  "id": "playtest-report",
+  "name": "Playtest Report",
+  "description": "Playtest like it matters: a structured pass over the mechanics, the edge inputs, and the score loop, every finding written with its repro steps — a ranked fix list, not vibes. Locks the test plan FIRST — what to try and what correct looks like — then plays through it taking notes, then writes the findings with a ranked issue table. Use for playtesting a game before sharing it, 'is the game actually solid', bug hunts on an arcade page, pre-release game QA, and turning playtest feelings into a fix list.\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. Write the test plan (reviewer) — mechanics list, edge inputs, what the score loop should do → gated on artifact `notes/scope.md` (markdown-notes)\n2. Play through the plan (reviewer) — structured playthrough notes, observed versus expected, with repros → gated on artifact `notes/playtest.md` (markdown-notes)\n3. Write the findings (copywriter) — ranked issue table, repros attached, honest verdict → gated on artifact `report.md` (markdown-report)\n\nThe gates never advance with an unmet criterion, and loop back to the\nowning phase to fix named gaps.\n",
+  "entryStepId": "scope",
+  "triggers": [
+    "playtest the game",
+    "is the game solid",
+    "test the arcade game before i share it",
+    "find the bugs in the game",
+    "playtest report"
+  ],
+  "steps": [
+    {
+      "id": "scope",
+      "name": "Write the test plan",
+      "description": "mechanics list, edge inputs, what the score loop should do",
+      "prompt": "Plan the playtest before playing a frame. Step 1: read index.html from the workspace and list the mechanics — movement, actions, collisions, scoring, lives or health, game over, restart — and how the score is kept between rounds. Step 2: write the edge-input list — keys mashed and held, action during game over, restarting mid-motion, playing again three times in a row, anything a ten-year-old with a keyboard would do in the first minute. Step 3: state what correct looks like per item — especially the score loop: what the score should read after a restart, and what should carry over versus reset. Step 4: write an acceptance-criteria checklist ('every mechanic exercised', 'every edge input tried', 'every finding has repro steps', 'findings ranked by player impact', 'the score loop gets an explicit verdict'). Call write_task_note with the plan size + checklist and write notes/scope.md.\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": "reviewer",
+      "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": "test"
+    },
+    {
+      "id": "test",
+      "name": "Play through the plan",
+      "description": "structured playthrough notes, observed versus expected, with repros",
+      "prompt": "Work the plan against the code and write down what actually happens. Step 1: walk each mechanic and each edge input through the game's logic, tracing the code path the input takes; record observed versus expected for every item — passes too, not just failures. Step 2: for every mismatch, write the repro then and there: the exact steps, what happens, what should happen; a finding without a repro is a rumor. Step 3: give the score loop special care — trace a full round, game over, and restart, and record exactly what the score does at each point. Step 4: write the structured notes to notes/playtest.md and call write_task_note with the pass/fail counts.\n\nThe deliverable `notes/playtest.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/playtest.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "notes/playtest.md",
+            "bytes": 800,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "notes/playtest.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "test",
+        "maxAttempts": 3
+      },
+      "next": "report"
+    },
+    {
+      "id": "report",
+      "name": "Write the findings",
+      "description": "ranked issue table, repros attached, honest verdict",
+      "prompt": "Write the playtest report at report.md. Step 1: open with the honest one-paragraph verdict — what state the game is in and whether it is ready to share. Step 2: the issue table — a Markdown table with columns Issue, Severity, and Repro, one row per finding, ranked by player impact (what ruins a session outranks what merely looks off). Step 3: under the table, give each finding its detail — the full repro steps, what happens, what should happen, and where in the code the trail leads. Step 4: state the score-loop verdict explicitly, and close with what passed cleanly so the good news is on record too. Write report.md and call write_task_note with the finding count and the top-ranked issue.\n\nThe deliverable `report.md` lands in the project's artifacts drawer — write it with `write_artifact` and read it back with `read_artifact`; the shipped workspace stays untouched.",
+      "suggestedRole": "copywriter",
+      "advanceWhen": {
+        "file": "report.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "report.md",
+            "bytes": 1200,
+            "artifact": true
+          },
+          {
+            "kind": "contains",
+            "file": "report.md",
+            "pattern": "(?:^|\\n)#{1,3}\\s+\\S",
+            "flags": "i",
+            "label": "at least one markdown heading",
+            "artifact": true
+          }
+        ],
+        "onReject": "report",
+        "maxAttempts": 4
+      },
+      "next": "evaluate"
+    },
+    {
+      "id": "evaluate",
+      "name": "Evaluate",
+      "description": "Grade the deliverable against every acceptance criterion. All pass → finish; any fail → loop back and fix the gap.",
+      "prompt": "Open report.md and notes/playtest.md against notes/scope.md and verify every criterion: every mechanic and edge input from the plan appears in the notes with observed versus expected; every finding in the report carries repro steps a stranger could follow — re-trace one against the code to check it is real, a finding that does not reproduce is worse than none; the table ranks by player impact with severities that match the prose; and the score loop has its explicit verdict. Write PASS/FAIL per criterion; on any failure, name the finding or the gap and loop back to report.\n\nThe deliverable lives in the project's artifacts drawer — open `report.md` with `read_artifact`, not `read_file`.\n\nThen route — this is the whole point of the loop:\n\n- **Every criterion PASSES →** call `advance_task_step({ ref, stepId: \"evaluate\", next: \"finish\" })`.\n- **Any criterion FAILS →** write the specific gaps to notes, then call `advance_task_step({ ref, stepId: \"evaluate\", next: \"report\" })` 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": "report.md",
+          "artifact": true
+        }
+      ],
+      "next": "report"
+    },
+    {
+      "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/pl/playtest-report/versions/1.0.1/test.json

@@ -0,0 +1,111 @@
+{
+  "schemaVersion": 1,
+  "title": "Playtest Report — repros, ranks, and the score-loop verdict",
+  "objective": "Measure whether the playtest-report craftbook finds the seeded flaws in a small arcade game (score not resetting between rounds; input handler stacking across restarts) and writes them up with repro steps in a ranked issue table.",
+  "tags": [
+    "corpus"
+  ],
+  "prompt": "can you playtest the arcade game properly before i send it to my freinds? write up whatever you find",
+  "setup": {
+    "projectName": "Star Catcher Arcade",
+    "about": "Web arcade project. The game under test is workspace/index.html; the playtest plan and notes go under workspace/notes and the findings to workspace/report.md.",
+    "missionObjectives": "A structured playtest with evidence: every finding carries repro steps, findings are ranked by player impact, and the score loop across game over and restart gets an explicit verdict. No live services, no real credentials.",
+    "files": [
+      {
+        "path": "index.html",
+        "content": "<!DOCTYPE html>\n<html lang=\"en\">\n<head>\n<meta charset=\"utf-8\">\n<title>Star Catcher</title>\n<style>\n  body { margin: 0; background: #101020; color: #eee; font-family: monospace;\n         display: flex; flex-direction: column; align-items: center; }\n  h1 { font-size: 18px; margin: 12px 0 4px; }\n  canvas { border: 1px solid #334; background: #181830; }\n  p { font-size: 12px; color: #99a; }\n</style>\n</head>\n<body>\n<h1>Star Catcher</h1>\n<canvas id=\"game\" width=\"480\" height=\"560\"></canvas>\n<p>Arrow keys to move the basket. Catch stars, miss three and it's over. Enter to restart.</p>\n<script>\nvar canvas = document.getElementById('game');\nvar ctx = canvas.getContext('2d');\nvar W = canvas.width, H = canvas.height;\n\nvar basket, stars, score = 0, missed, over, spawnTimer;\n\nfunction onKey(e) {\n  if (over) {\n    if (e.key === 'Enter') startGame();\n    return;\n  }\n  if (e.key === 'ArrowLeft') basket.x -= 24;\n  if (e.key === 'ArrowRight') basket.x += 24;\n  basket.x = Math.max(basket.w / 2, Math.min(W - basket.w / 2, basket.x));\n}\n\nfunction startGame() {\n  basket = { x: W / 2, y: H - 40, w: 64, h: 16 };\n  stars = [];\n  missed = 0;\n  over = false;\n  spawnTimer = 0;\n  document.addEventListener('keydown', onKey);\n}\n\nfunction spawnStar() {\n  stars.push({ x: 16 + Math.random() * (W - 32), y: -10, vy: 1.4 + Math.random() * 1.8 });\n}\n\nfunction update() {\n  if (over) return;\n  spawnTimer -= 1;\n  if (spawnTimer <= 0) {\n    spawnStar();\n    spawnTimer = 50;\n  }\n  for (var i = stars.length - 1; i >= 0; i--) {\n    var s = stars[i];\n    s.y += s.vy;\n    if (s.y > basket.y - 6 && s.y < basket.y + basket.h &&\n        Math.abs(s.x - basket.x) < basket.w / 2 + 6) {\n      stars.splice(i, 1);\n      score += 10;\n      continue;\n    }\n    if (s.y > H + 10) {\n      stars.splice(i, 1);\n      missed += 1;\n      if (missed >= 3) over = true;\n    }\n  }\n}\n\nfunction draw() {\n  ctx.clearRect(0, 0, W, H);\n  ctx.fillStyle = '#ffd75e';\n  for (var i = 0; i < stars.length; i++) {\n    var s = stars[i];\n    ctx.beginPath();\n    ctx.arc(s.x, s.y, 6, 0, Math.PI * 2);\n    ctx.fill();\n  }\n  ctx.fillStyle = '#7ec8ff';\n  ctx.fillRect(basket.x - basket.w / 2, basket.y, basket.w, basket.h);\n  ctx.fillStyle = '#eee';\n  ctx.font = '16px monospace';\n  ctx.fillText('Score: ' + score, 12, 24);\n  ctx.fillText('Missed: ' + missed + '/3', 12, 44);\n  if (over) {\n    ctx.font = '26px monospace';\n    ctx.fillText('GAME OVER', W / 2 - 70, H / 2 - 10);\n    ctx.font = '14px monospace';\n    ctx.fillText('Press Enter to play again', W / 2 - 96, H / 2 + 16);\n  }\n}\n\nfunction loop() {\n  update();\n  draw();\n  requestAnimationFrame(loop);\n}\n\nstartGame();\nloop();\n</script>\n</body>\n</html>\n"
+      }
+    ],
+    "worker": {
+      "name": "Roos",
+      "role": "Reviewer"
+    }
+  },
+  "mocks": [],
+  "success": {
+    "summary": "report.md is a ranked, repro-backed playtest report that catches the restart flaws — the score carrying over between rounds and the stacking input handler.",
+    "deliverables": [
+      {
+        "path": "report.md",
+        "kind": "markdown-report",
+        "minBytes": 1200,
+        "checks": [
+          {
+            "kind": "contains",
+            "file": "report.md",
+            "pattern": "(?:^|\\n)#{1,3}\\s+\\S",
+            "flags": "i"
+          },
+          {
+            "kind": "tableShape",
+            "file": "report.md",
+            "requiredColumns": [
+              "Issue",
+              "Severity"
+            ],
+            "minRows": 1
+          },
+          {
+            "kind": "contains",
+            "file": "report.md",
+            "pattern": "repro|steps",
+            "flags": "i",
+            "label": "repros attached"
+          },
+          {
+            "kind": "contains",
+            "file": "report.md",
+            "pattern": "score",
+            "flags": "i",
+            "label": "score loop covered"
+          },
+          {
+            "kind": "contains",
+            "file": "report.md",
+            "pattern": "restart|play again|enter",
+            "flags": "i",
+            "label": "the restart path was exercised"
+          },
+          {
+            "kind": "judge",
+            "file": "report.md",
+            "rubric": "Findings are specific and reproducible — concrete steps a stranger could follow — and ranked by player impact; the report catches that restarting does not reset the score and that input handling degrades across restarts.",
+            "sourceFiles": [
+              "index.html"
+            ],
+            "label": "finding quality"
+          }
+        ]
+      }
+    ]
+  },
+  "rubric": {
+    "artifact": {
+      "path": "report.md",
+      "kind": "markdown"
+    },
+    "axes": [
+      {
+        "name": "rigor",
+        "description": "The plan's mechanics and edge inputs were actually exercised — passes recorded alongside failures."
+      },
+      {
+        "name": "repro quality",
+        "description": "Each finding's steps reproduce it exactly; observed and expected behavior are both stated."
+      },
+      {
+        "name": "prioritization",
+        "description": "The table ranks by what ruins a play session, not by discovery order."
+      },
+      {
+        "name": "player empathy",
+        "description": "The report reads like someone who played the game, and says what is already good."
+      }
+    ]
+  },
+  "qualityFocus": [
+    "seeded-flaw detection",
+    "repro discipline",
+    "ranked issue table"
+  ]
+}

package/data/craftbook-templates/po/podcast-chaptering/versions/1.0.1/craftbook.json

@@ -0,0 +1,140 @@
+{
+  "id": "podcast-chaptering",
+  "name": "Podcast Chapters & Show Notes",
+  "description": "Turn a podcast episode into navigable chapter markers plus publish-ready show notes — timestamped chapter titles, an episode summary, key takeaways, and linked mentions. Scopes the chapter format and show-notes structure FIRST, analyzes the transcript to find real topic boundaries with timestamps, then writes the listener-facing notes in the show's voice. Separating boundary-detection (analysis) from the write-up (copy) is what yields chapters that land on actual topic shifts and notes that read like a human wrote them.\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 chapters & notes (planner) — chapter format, count, show-notes sections, voice → gated on artifact `notes/scope.md` (markdown-notes)\n2. Find chapter boundaries (developer) — detect topic shifts, assign timestamps + titles → gated on artifact `notes/chapters.json` (json)\n3. Write show notes (copywriter) — summary, takeaways, chapter list, links in the show voice → gated on `show-notes.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": [
+    "podcast chapters",
+    "chapter markers for my episode",
+    "write show notes",
+    "timestamp my podcast",
+    "episode summary and chapters"
+  ],
+  "steps": [
+    {
+      "id": "scope",
+      "name": "Scope chapters & notes",
+      "description": "chapter format, count, show-notes sections, voice",
+      "prompt": "Define the deliverable BEFORE analyzing. Step 1: record the source (episode title, transcript path or audio, duration). Step 2: pick the chapter marker format — the widely-supported `HH:MM:SS Title` lines (Apple/YouTube style), where the FIRST chapter must be `00:00:00`. Step 3: set chapter density (e.g. 5-12 chapters, min ~60s apart, titles ≤ ~40 chars). Step 4: define the show-notes structure: one-paragraph episode summary, 3-6 key takeaways, the timestamped chapter list, and a 'mentioned in this episode' links list. Step 5: capture the show's voice. Write an acceptance-criteria checklist (first chapter is 00:00:00, timestamps monotonic and within duration, titles concise and descriptive, notes have all four sections, every claim traces to the transcript) and decisions to `notes/scope.md` via write_task_note AND 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": "analyze"
+    },
+    {
+      "id": "analyze",
+      "name": "Find chapter boundaries",
+      "description": "detect topic shifts, assign timestamps + titles",
+      "prompt": "Find where topics actually change. Step 1: read the transcript with its timestamps. Step 2: detect topic boundaries — points where the subject clearly shifts (new question, new segment, ad break, guest change) — not arbitrary fixed intervals. Step 3: for each boundary record the start timestamp (rounded to the second) and a short descriptive title; force the first to `00:00:00`. Step 4: enforce the scoped density/spacing/title-length rules, merging boundaries that are too close. Step 5: write the structured chapter list to `notes/chapters.json` (each: start `HH:MM:SS`, title, a one-line topic note) via write_task_note AND the produces path so the writer has structured input. On a loop-back, adjust only the flagged boundaries.\n\nThe deliverable `notes/chapters.json` lands in the project's artifacts drawer — write it with `write_artifact` and read it back with `read_artifact`; the shipped workspace stays untouched.",
+      "suggestedRole": "developer",
+      "advanceWhen": {
+        "file": "notes/chapters.json",
+        "minBytes": 1,
+        "sniff": "json-valid",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "notes/chapters.json",
+            "bytes": 2,
+            "artifact": true
+          }
+        ],
+        "onReject": "analyze",
+        "maxAttempts": 3
+      },
+      "next": "write"
+    },
+    {
+      "id": "write",
+      "name": "Write show notes",
+      "description": "summary, takeaways, chapter list, links in the show voice",
+      "prompt": "Write the publish-ready notes from the analysis. Step 1: open with a one-paragraph episode summary in the show's voice. Step 2: list 3-6 key takeaways as tight bullets. Step 3: render the chapter list as plain `HH:MM:SS Title` lines (paste-ready into a podcast host / YouTube description) directly from `notes/chapters.json`, first line `00:00:00`. Step 4: add a 'Mentioned in this episode' section with the people/links/resources referenced. Step 5: assemble all of it into `show-notes.md` with clear section headers. Do not invent facts not in the transcript. write_task_note the path and chapter count. On a loop-back, fix only the flagged sections.\n\nBefore working, open the artifact input `notes/chapters.json` with `read_artifact`; do not look for it in the workspace.",
+      "suggestedRole": "copywriter",
+      "consumes": [
+        {
+          "file": "notes/chapters.json",
+          "artifact": true
+        }
+      ],
+      "advanceWhen": {
+        "file": "show-notes.md",
+        "minBytes": 1,
+        "sniff": "nonempty"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "show-notes.md",
+            "bytes": 500
+          }
+        ],
+        "scripts": [
+          {
+            "name": "checkContains",
+            "scope": "standard",
+            "inputs": {
+              "file": "show-notes.md",
+              "pattern": "(?:^|\\n)#{1,3}\\s+\\S",
+              "flags": "i"
+            }
+          }
+        ],
+        "onReject": "write",
+        "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": "Check the chapters and notes. Step 1: confirm the chapter list's FIRST line is `00:00:00` and all timestamps are monotonic, spaced per scope, and within the episode duration (PASS/FAIL). Step 2: spot-check 3 chapter timestamps against the transcript — does each land on a real topic shift? Step 3: confirm show-notes.md has all four sections (summary, takeaways, chapters, mentions). Step 4: confirm claims trace to the transcript (nothing invented) and the voice matches the show. Step 5: confirm titles are concise and descriptive. 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: \"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": "show-notes.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"
+}