@bendyline/gilde 0.1.38 → 0.1.39

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

@@ -0,0 +1,115 @@
+{
+  "schemaVersion": 1,
+  "title": "Customer case study from interview notes",
+  "objective": "Measure whether the case-study craftbook scopes metrics and quotes before writing a challenge-solution-results story.",
+  "tags": [
+    "corpus"
+  ],
+  "prompt": "In the `Case Study Eval` project, read `source/customer-notes.md` and write `case-study.md` for HarborCRM customer Northstar Studio. Use a challenge-solution-results arc, lead with quantified outcomes, include approved quotes, and avoid unsupported claims.",
+  "setup": {
+    "projectName": "Case Study Eval",
+    "about": "Self-contained eval project for case-study. Customer interview notes are in workspace/source/customer-notes.md.",
+    "missionObjectives": "Write a credible customer success story grounded in the seeded metrics and quotes.",
+    "files": [
+      {
+        "path": "source/customer-notes.md",
+        "content": "# Northstar Studio notes\n\nCustomer: Northstar Studio, 48-person interior design firm.\nChallenge: returns questions consumed two support coordinators every Monday and order context lived in email threads.\nSolution: HarborCRM guided returns intake plus triage queue, launched March 2026.\nBefore/after metrics: median first response fell from 18 hours to 6 hours; preventable refund leakage fell from 14.2% to 8.9%; onboarding for new coordinators fell from 11 days to 4 days.\nApproved quote 1: \"The queue gave us one place to see what mattered first,\" said Lena Ortiz, Director of Client Operations.\nApproved quote 2: \"We stopped hunting through inboxes before every customer call,\" said Marco Reed, Support Lead.\nTakeaway: operations teams can reduce refund leakage without adding headcount.\nCTA: Book a returns workflow audit.\n"
+      }
+    ],
+    "worker": {
+      "name": "Gijs",
+      "role": "Copywriter"
+    },
+    "craftbookParams": {
+      "workPath": "tasks/eval"
+    }
+  },
+  "mocks": [],
+  "success": {
+    "summary": "workspace/case-study.md is a source-grounded challenge-solution-results case study with metrics, quotes, takeaway, and CTA.",
+    "deliverables": [
+      {
+        "path": "case-study.md",
+        "kind": "markdown-doc",
+        "minBytes": 2400,
+        "checks": [
+          {
+            "kind": "contains",
+            "file": "case-study.md",
+            "pattern": "(?:^|\\n)#{1,3}\\s+\\S",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "case-study.md",
+            "pattern": "Challenge|Solution|Results|Takeaway|CTA",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "case-study.md",
+            "pattern": "Northstar Studio|Lena Ortiz|Marco Reed",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "case-study.md",
+            "pattern": "18\\s*hours|6\\s*hours|14\\.2%|8\\.9%|11\\s*days|4\\s*days",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "case-study.md",
+            "pattern": "Book a returns workflow audit|refund leakage|headcount",
+            "flags": "i"
+          },
+          {
+            "kind": "notContains",
+            "file": "case-study.md",
+            "pattern": "guaranteed|revolutionary|world-class",
+            "flags": "i"
+          }
+        ]
+      }
+    ]
+  },
+  "rubric": {
+    "artifact": {
+      "path": "case-study.md",
+      "kind": "markdown"
+    },
+    "axes": [
+      {
+        "name": "safety",
+        "description": "Dry-run posture is explicit: no real credentials, clear stop-before-side-effect boundary."
+      },
+      {
+        "name": "mapping",
+        "description": "Fake endpoints/commands are mapped completely to the workflow steps."
+      },
+      {
+        "name": "signals",
+        "description": "Success, failure, retry, and abort conditions are all defined."
+      },
+      {
+        "name": "containment",
+        "description": "The plan cannot accidentally reach a real service from a mock context."
+      }
+    ]
+  },
+  "qualityFocus": [
+    "results-forward summary",
+    "approved quotes",
+    "metric grounding"
+  ],
+  "extensions": {
+    "legacySimulators": [
+      {
+        "id": "case-study-fake-service-fixture",
+        "kind": "data-source",
+        "status": "implemented",
+        "description": "Seeded local fake service contract replacing live CLIs, HTTP APIs, credentials, and side effects."
+      }
+    ]
+  }
+}

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

@@ -0,0 +1,163 @@
+{
+  "id": "case-study-writeup",
+  "name": "Customer Case Study",
+  "description": "Write a persuasive customer/case-study writeup that turns a customer's results into a credible marketing asset — challenge, solution, and quantified results in the classic before/after arc, with a pull-quote and a clear CTA. Scopes the customer story and the hard metrics FIRST (results without numbers are not a case study), writes the narrative copy in the proven challenge-solution-results structure, then builds a clean, branded single-page HTML asset with a results-highlight band and quote callout. Use for marketing case studies, customer success stories, and sales proof assets.\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 story (planner) — the challenge, the solution, and the quantified results + quote → gated on artifact `{{workPath}}/scope.md` (markdown-notes)\n2. Write the narrative (copywriter) — challenge -> solution -> results copy with the pull-quote → gated on artifact `{{workPath}}/write.md` (markdown-notes)\n3. Build the page (developer) — render index.html: results band, quote callout, branded styling → gated on `index.html` (html-marketing-site)\n\nThe gates never advance with an unmet criterion, and loop back to the\nowning phase to fix named gaps.\n",
+  "entryStepId": "scope",
+  "triggers": [
+    "write a case study",
+    "customer success story",
+    "case study writeup",
+    "customer story",
+    "results story",
+    "case study page"
+  ],
+  "steps": [
+    {
+      "id": "scope",
+      "name": "Scope the story",
+      "description": "the challenge, the solution, and the quantified results + quote",
+      "prompt": "Find the story and the proof before writing. Step 1: identify the customer (and their industry/size) and the single headline result that makes this worth publishing. Step 2: map the classic arc: the CHALLENGE (the pain before, ideally with a baseline number), the SOLUTION (what they adopted and how), and the RESULTS (the after, with HARD METRICS — %, time, revenue, scale). Step 3: gather a real customer quote (or note that one is needed) for the pull-quote. Step 4: define the one CTA the asset should drive (demo, contact, signup). Step 5: write an acceptance-criteria checklist ('names the customer + context', 'challenge has a concrete before-state', 'solution is specific', 'results include at least two quantified metrics', 'has a customer pull-quote', 'ends with one clear CTA'). Write the story map + metrics + checklist via write_task_note AND to {{workPath}}/scope.md. Do not invent metrics — if a number is unknown, mark it as a placeholder to fill, not a fabricated stat. No copy or HTML yet.\n\nThe deliverable `{{workPath}}/scope.md` lands in the project's artifacts drawer — write it with `write_artifact` and read it back with `read_artifact`; the shipped workspace stays untouched.",
+      "suggestedRole": "planner",
+      "advanceWhen": {
+        "file": "{{workPath}}/scope.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "{{workPath}}/scope.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "{{workPath}}/scope.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "scope",
+        "maxAttempts": 3
+      },
+      "next": "write"
+    },
+    {
+      "id": "write",
+      "name": "Write the narrative",
+      "description": "challenge -> solution -> results copy with the pull-quote",
+      "prompt": "Write the case-study copy in the proven structure. Step 1: write a results-led headline and a one-line dek summarizing customer + outcome. Step 2: write a short 'at a glance' summary (industry, the 2-3 key metrics) for skimmers. Step 3: write the Challenge section — set the before-state and stakes concretely. Step 4: write the Solution section — what they did, specifically, and why it fit. Step 5: write the Results section leading with the quantified metrics and what they meant for the business; place the customer pull-quote where it lands hardest. Step 6: write the CTA copy. Keep it credible and specific, not hype; let the numbers do the bragging. Use only the metrics from the scope (no invented stats). Write the section-by-section copy via write_task_note AND to {{workPath}}/write.md.\n\nThe deliverable `{{workPath}}/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": "{{workPath}}/write.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "{{workPath}}/write.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "{{workPath}}/write.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "write",
+        "maxAttempts": 3
+      },
+      "next": "build"
+    },
+    {
+      "id": "build",
+      "name": "Build the page",
+      "description": "render index.html: results band, quote callout, branded styling",
+      "prompt": "Build the case study as a single self-contained index.html (inline CSS, real branded styling). Step 1: build a header with the results-led headline and dek. Step 2: render an 'at a glance' results band that makes the 2-3 key metrics visually dominant (big numbers, accent color). Step 3: lay out the Challenge -> Solution -> Results sections in order with comfortable reading width and clear section headings. Step 4: render the customer pull-quote as a styled blockquote callout with attribution (name, title, company). Step 5: end with a prominent CTA button. Apply a coherent palette (exact hex) and type scale so it reads as a polished marketing asset, and make it responsive. Drop in the approved copy verbatim; do not invent metrics. 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": 1200
+          },
+          {
+            "kind": "htmlLint",
+            "file": "index.html"
+          }
+        ],
+        "scripts": [
+          {
+            "name": "checkHtmlComplete",
+            "scope": "standard",
+            "inputs": {
+              "file": "index.html"
+            }
+          },
+          {
+            "name": "checkCssMinBytes",
+            "scope": "standard",
+            "inputs": {
+              "file": "index.html",
+              "minBytes": 600
+            }
+          }
+        ],
+        "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 case study against the locked criteria. Step 1: open/render index.html. Step 2: check EACH acceptance criterion: customer + context named, a results band makes at least two quantified metrics visually dominant, the Challenge has a concrete before-state, the Solution is specific, the Results lead with the metrics, a customer pull-quote with attribution is present, and one clear CTA button closes it. Step 3: confirm the visual styling is real and branded (palette + type applied, not unstyled) and responsive. Step 4: confirm no metrics were invented beyond the scope. 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.2",
+  "releasedAt": "2026-08-21T00:00:00Z",
+  "paramSchema": {
+    "type": "object",
+    "properties": {
+      "workPath": {
+        "type": "string",
+        "title": "Working folder",
+        "description": "Per-task working folder in the artifacts drawer. Defaults to this task's own folder so runs never collide; override with a stable name when you deliberately want runs to share files.",
+        "default": "{{task.dir}}"
+      }
+    }
+  },
+  "minGezelVersion": "1.26233"
+}

package/data/craftbook-templates/ca/case-study-writeup/versions/1.0.2/test.json

@@ -0,0 +1,108 @@
+{
+  "schemaVersion": 1,
+  "title": "Customer case-study HTML asset",
+  "objective": "Measure whether the case-study-writeup craftbook scopes challenge, solution, quantified results, and quote before building a polished proof asset.",
+  "tags": [
+    "html-page"
+  ],
+  "prompt": "In the `Case Study Writeup Eval` project, read `source/story.md` and build `index.html`: a one-page customer case study for Harbor & Finch using a challenge-solution-results arc, quantified results, a pull quote, CTA, and branded styling. Vanilla HTML/CSS only is fine.",
+  "setup": {
+    "projectName": "Case Study Writeup Eval",
+    "about": "Self-contained eval project for the case-study-writeup craftbook. Story facts are in workspace/source/story.md.",
+    "missionObjectives": "Build a polished one-page case study from seeded facts with challenge, solution, results, quote, CTA, and branded styling.",
+    "files": [
+      {
+        "path": "source/story.md",
+        "content": "# Harbor & Finch Case Study Facts\n\nCustomer: Harbor & Finch, home-office accessories retailer.\nChallenge: preventable refund leakage and slow returns responses.\nSolution: guided intake form, photo evidence, triage queue, barcode exception training.\nResults: first response improved from 18 hours to 6 hours; refund leakage fell from 14.2% to 8.9%; support escalations dropped 21%.\nPull quote: \"The pilot gave our support leads a shared operating picture without slowing the warehouse.\"\nCTA: Book a returns workflow audit.\n"
+      }
+    ],
+    "worker": {
+      "name": "Noemi",
+      "role": "Developer"
+    },
+    "craftbookParams": {
+      "workPath": "tasks/eval"
+    }
+  },
+  "mocks": [],
+  "success": {
+    "summary": "workspace/index.html is a branded case-study page with challenge, solution, quantified results, pull quote, and CTA.",
+    "deliverables": [
+      {
+        "path": "index.html",
+        "kind": "html-marketing-site",
+        "minBytes": 3600,
+        "checks": [
+          {
+            "kind": "cssMinBytes",
+            "bytes": 750,
+            "file": "index.html"
+          },
+          {
+            "kind": "jsParses",
+            "file": "index.html"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "Challenge|Solution|Results",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "18\\s*hours|6\\s*hours|14\\.2%|8\\.9%|21%",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "shared operating picture|pull quote|quote",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "Book a returns workflow audit|CTA",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "Harbor & Finch",
+            "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": [
+    "challenge-solution-results arc",
+    "quantified proof",
+    "branded HTML asset"
+  ]
+}

package/data/craftbook-templates/ch/changelog-cut/versions/1.0.2/craftbook.json

@@ -0,0 +1,125 @@
+{
+  "id": "changelog-cut",
+  "name": "Changelog Cut",
+  "description": "Cut a new versioned section into a Keep a Changelog / CHANGELOG.md style file for a release — moving entries out of the Unreleased section into a dated, semver-stamped version block under the standard Added / Changed / Deprecated / Removed / Fixed / Security headings, with a fresh empty Unreleased section left behind. A developer gathers the unreleased entries and reconciles them against actual merged changes before a copywriter normalizes them into terse, consistent changelog lines and stamps the version block. Use this whenever you 'cut a release', 'update the changelog', or roll the Unreleased section into a tagged version while keeping the file append-only and machine-comparable.\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. Gather unreleased entries (developer) — reconcile the Unreleased section against actual merged changes → gated on artifact `{{workPath}}/gather.md` (markdown-notes)\n2. Cut the version block (copywriter) — normalize entries and stamp the dated version section → gated on `CHANGELOG.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": "gather",
+  "triggers": [
+    "cut a changelog",
+    "update CHANGELOG.md",
+    "roll unreleased into a version",
+    "stamp the changelog for v1.4",
+    "keep a changelog release"
+  ],
+  "steps": [
+    {
+      "id": "gather",
+      "name": "Gather unreleased entries",
+      "description": "reconcile the Unreleased section against actual merged changes",
+      "prompt": "1. Locate the changelog file (CHANGELOG.md or similar) and read its existing format — Keep a Changelog headings (Added, Changed, Deprecated, Removed, Fixed, Security) are the default; match whatever the file already uses. 2. Read the current Unreleased section and reconcile it against the real merged changes since the last version block (git log / merged PRs) — add anything user-facing that is missing, and remove or merge duplicates. 3. Determine the new version number per semver: bump MAJOR for breaking changes, MINOR for new backward-compatible features, PATCH for fixes only; note the reasoning. 4. Map each entry to the correct heading (Removed and Security are not Changed). 5. Good looks like: a reconciled, categorized list of every unreleased user-facing change, the chosen version number with a one-line semver justification, and the release date. Write an acceptance-criteria checklist ('version follows semver given the change set', 'every entry sits under the correct standard heading', 'Unreleased reconciles with merged changes', 'existing version blocks untouched') plus the inventory to the notes file via write_task_note AND to {{workPath}}/gather.md.\n\nThe deliverable `{{workPath}}/gather.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": "developer",
+      "advanceWhen": {
+        "file": "{{workPath}}/gather.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "{{workPath}}/gather.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "{{workPath}}/gather.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "gather",
+        "maxAttempts": 3
+      },
+      "next": "write"
+    },
+    {
+      "id": "write",
+      "name": "Cut the version block",
+      "description": "normalize entries and stamp the dated version section",
+      "prompt": "1. Open {{workPath}}/gather.md and rewrite the changelog so the reconciled entries form a new version block headed '## [VERSION] - YYYY-MM-DD' inserted directly above the previous version block. 2. Under that block, emit only the non-empty standard headings, each with terse, parallel one-line bullets in the imperative ('Add…', 'Fix…') — one change per bullet, no implementation chatter. 3. Leave a fresh, empty '## [Unreleased]' section at the top with the standard heading placeholders. 4. Do NOT alter any pre-existing version block, the file header, or the comparison-link footer except to add the new version's link if the file uses them. 5. Preserve issue/PR references if the file's convention includes them. 6. Good looks like: a clean, append-only CHANGELOG.md where the new dated version block is correct semver, Unreleased is empty, and the file still parses as Keep a Changelog. Write the updated changelog to CHANGELOG.md.\n\nBefore working, open the artifact input `{{workPath}}/gather.md` with `read_artifact`; do not look for it in the workspace.",
+      "suggestedRole": "copywriter",
+      "consumes": [
+        {
+          "file": "{{workPath}}/gather.md",
+          "artifact": true
+        }
+      ],
+      "advanceWhen": {
+        "file": "CHANGELOG.md",
+        "minBytes": 1,
+        "sniff": "nonempty"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "CHANGELOG.md",
+            "bytes": 500
+          }
+        ],
+        "scripts": [
+          {
+            "name": "checkContains",
+            "scope": "standard",
+            "inputs": {
+              "file": "CHANGELOG.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": "Open CHANGELOG.md and check it against the acceptance criteria in {{workPath}}/gather.md, PASS/FAIL each. Confirm: (a) a new '## [VERSION] - DATE' block exists with a valid date and a semver-correct version for the change set; (b) every gathered entry appears once under the correct standard heading and empty headings are omitted; (c) a fresh empty Unreleased section sits at the top; (d) all previous version blocks and the file header/footer are unchanged; (e) bullets are terse and parallel with one change each; (f) the file still reads as a valid Keep a Changelog document. Any FAIL routes back to the write phase.\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": "CHANGELOG.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.2",
+  "releasedAt": "2026-08-21T00:00:00Z",
+  "paramSchema": {
+    "type": "object",
+    "properties": {
+      "workPath": {
+        "type": "string",
+        "title": "Working folder",
+        "description": "Per-task working folder in the artifacts drawer. Defaults to this task's own folder so runs never collide; override with a stable name when you deliberately want runs to share files.",
+        "default": "{{task.dir}}"
+      }
+    }
+  },
+  "minGezelVersion": "1.26233"
+}

package/data/craftbook-templates/ch/changelog-cut/versions/1.0.2/test.json

@@ -0,0 +1,109 @@
+{
+  "schemaVersion": 1,
+  "title": "Cut Unreleased changelog into dated version block",
+  "objective": "Measure whether the changelog-cut craftbook preserves the existing file while moving user-facing Unreleased entries into a semver block.",
+  "tags": [
+    "html-page"
+  ],
+  "prompt": "In the `Changelog Cut Eval` project, read the existing `CHANGELOG.md` and `source/merged-prs.md`, then cut release 2.4.0 dated 2026-06-28. Leave a fresh empty Unreleased section, move user-facing entries into the correct standard headings, preserve PR references, and do not include internal-only chores.",
+  "setup": {
+    "projectName": "Changelog Cut Eval",
+    "about": "Self-contained eval project for changelog-cut. Existing changelog and merged PR inventory are seeded in the workspace.",
+    "missionObjectives": "Update CHANGELOG.md append-only style for version 2.4.0 while preserving previous blocks and excluding internal-only noise.",
+    "files": [
+      {
+        "path": "CHANGELOG.md",
+        "content": "# Changelog\n\n## [Unreleased]\n\n### Added\n- Add saved invoice filters for finance teams (#812).\n- Add webhook retry visibility in the admin panel (#817).\n\n### Fixed\n- Fix duplicate customer merge suggestions after CSV import (#829).\n\n### Security\n- Rotate default API key salt for new installs (#836).\n\n### Changed\n- Internal reducer file rename in billing package (#831).\n\n## [2.3.1] - 2026-05-14\n\n### Fixed\n- Fix invoice PDF currency rounding (#801).\n"
+      },
+      {
+        "path": "source/merged-prs.md",
+        "content": "# Merged PRs since 2.3.1\n\n- #812 user-facing feature: saved invoice filters.\n- #817 user-facing improvement: webhook retry queue shows next retry time.\n- #829 user-facing fix: duplicate customer merge suggestions.\n- #831 internal-only: reducer file rename, do not publish.\n- #836 security: rotate default API key salt for new installs.\n"
+      }
+    ],
+    "worker": {
+      "name": "Hanne",
+      "role": "Release Writer"
+    },
+    "craftbookParams": {
+      "workPath": "tasks/eval"
+    }
+  },
+  "mocks": [],
+  "success": {
+    "summary": "workspace/CHANGELOG.md contains a new 2.4.0 block with user-facing entries, fresh Unreleased, previous block preserved, and internal-only PRs excluded.",
+    "deliverables": [
+      {
+        "path": "CHANGELOG.md",
+        "kind": "markdown-doc",
+        "minBytes": 1200,
+        "checks": [
+          {
+            "kind": "contains",
+            "file": "CHANGELOG.md",
+            "pattern": "## \\[Unreleased\\]",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "CHANGELOG.md",
+            "pattern": "## \\[2\\.4\\.0\\] - 2026-06-28",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "CHANGELOG.md",
+            "pattern": "Added|Fixed|Security",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "CHANGELOG.md",
+            "pattern": "#812|#817|#829|#836",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "CHANGELOG.md",
+            "pattern": "## \\[2\\.3\\.1\\] - 2026-05-14",
+            "flags": "i"
+          },
+          {
+            "kind": "notContains",
+            "file": "CHANGELOG.md",
+            "pattern": "reducer file rename|#831",
+            "flags": "i"
+          }
+        ]
+      }
+    ]
+  },
+  "rubric": {
+    "artifact": {
+      "path": "CHANGELOG.md",
+      "kind": "markdown"
+    },
+    "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": [
+    "append-only changelog edit",
+    "semver heading",
+    "de-noising"
+  ]
+}