@bendyline/gilde 0.1.38 → 0.1.40

package/data/craftbook-templates/re/release-notes/versions/1.0.2/craftbook.json

@@ -0,0 +1,171 @@
+{
+  "id": "release-notes",
+  "name": "Release Notes",
+  "description": "Turn a raw set of merged commits, pull requests, and ticket IDs into polished, human-readable release notes for a versioned release — grouped by theme (Features, Improvements, Bug Fixes, Breaking Changes), written for users rather than engineers, with upgrade/migration callouts surfaced first. The ordering is deliberate: a developer gathers and de-noises the change inventory before any prose is written, a copywriter turns that inventory into benefit-led notes in a consistent voice, and a reviewer verifies every shipped change is represented and nothing internal-only or unreleased leaked in. Use this for GitHub Releases, product announcement posts, or the user-facing notes that ship alongside a tagged version.\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 the change inventory (developer) — collect and de-noise every shipped change since the last tag → gated on artifact `{{workPath}}/gather.md` (markdown-notes)\n2. Write the notes (copywriter) — turn the inventory into benefit-led, user-facing notes → gated on `release-notes.md` (markdown-doc)\n3. Review for completeness and tone (reviewer) — verify coverage, accuracy, and that nothing internal leaked → gated on artifact `{{workPath}}/review.md` (markdown-notes)\n\nThe gates never advance with an unmet criterion, and loop back to the\nowning phase to fix named gaps.\n",
+  "entryStepId": "gather",
+  "triggers": [
+    "write release notes",
+    "release notes for v2",
+    "what changed this release",
+    "draft release announcement",
+    "notes for the new version"
+  ],
+  "steps": [
+    {
+      "id": "gather",
+      "name": "Gather the change inventory",
+      "description": "collect and de-noise every shipped change since the last tag",
+      "prompt": "1. Determine the version range: the last released tag (or last release date) up to HEAD/the release candidate. 2. Collect the raw inventory — merged PRs, commit subjects, and linked issue IDs (use git log, gh pr list --state merged, or the changelog source available to you). 3. Filter OUT noise that should never reach users: merge commits, dependency-bump-only commits, CI/build-config tweaks, lint/format-only commits, and anything not yet actually released. 4. Classify each remaining change into exactly one bucket: Features, Improvements, Bug Fixes, Breaking Changes. 5. Flag every Breaking Change and anything requiring a user action (config change, migration, new env var) — these get top billing later. 6. Good looks like: a deduplicated, categorized list where each item has a PR/issue reference and a one-line plain description, and every category is either populated or explicitly marked 'none'. Write an acceptance-criteria checklist (e.g. 'every shipped user-facing change appears exactly once', 'breaking changes are flagged with the required user action', 'no merge/dependency/CI-only noise', 'each item cites a PR or issue') plus the version range and the classified 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": "Write the notes",
+      "description": "turn the inventory into benefit-led, user-facing notes",
+      "prompt": "1. Open {{workPath}}/gather.md and write the release notes for HUMANS, not for the commit log — lead each item with the user-visible benefit, not the implementation. 2. Order the document: a one-paragraph highlights summary, then Breaking Changes / Upgrade Notes (with the exact action the user must take), then Features, Improvements, Bug Fixes. 3. Keep each line tight and parallel in voice; use the imperative or present tense consistently ('Adds…', 'Fixes…'). 4. Preserve the PR/issue references as links or trailing (#123) so readers can dig in. 5. Open with the version number and release date as an H1/H2. 6. Good looks like: a reader who has never seen the codebase understands what changed and what they must do, breaking changes are impossible to miss, and every inventory item from gather.md is represented. Write the notes to release-notes.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": "release-notes.md",
+        "minBytes": 1,
+        "sniff": "nonempty"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "release-notes.md",
+            "bytes": 500
+          }
+        ],
+        "scripts": [
+          {
+            "name": "checkContains",
+            "scope": "standard",
+            "inputs": {
+              "file": "release-notes.md",
+              "pattern": "(?:^|\\n)#{1,3}\\s+\\S",
+              "flags": "i"
+            }
+          }
+        ],
+        "onReject": "write",
+        "maxAttempts": 3
+      },
+      "next": "review"
+    },
+    {
+      "id": "review",
+      "name": "Review for completeness and tone",
+      "description": "verify coverage, accuracy, and that nothing internal leaked",
+      "prompt": "1. Cross-check release-notes.md against {{workPath}}/gather.md: every classified item must appear, and nothing must appear that was filtered as noise or is unreleased. 2. Verify Breaking Changes are at the top with a concrete user action, not buried. 3. Check the voice is consistent and benefit-led, version + date are present, and references resolve. 4. Confirm no internal-only details (private ticket chatter, internal service names, secrets, profanity) leaked into a public document. 5. Write a PASS/FAIL against each acceptance criterion from gather.md, listing any specific gap. 6. If anything fails, the fix happens back in the write phase. Write your findings to {{workPath}}/review.md.\n\nBefore working, open the artifact input `{{workPath}}/gather.md` with `read_artifact`; do not look for it in the workspace.\n\nThe deliverable `{{workPath}}/review.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",
+      "consumes": [
+        {
+          "file": "{{workPath}}/gather.md",
+          "artifact": true
+        },
+        {
+          "file": "release-notes.md"
+        }
+      ],
+      "advanceWhen": {
+        "file": "{{workPath}}/review.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "release-notes.md",
+            "bytes": 500
+          }
+        ],
+        "scripts": [
+          {
+            "name": "checkContains",
+            "scope": "standard",
+            "inputs": {
+              "file": "release-notes.md",
+              "pattern": "(?:^|\\n)#{1,3}\\s+\\S",
+              "flags": "i"
+            }
+          }
+        ],
+        "onReject": "review",
+        "maxAttempts": 4
+      },
+      "next": "evaluate"
+    },
+    {
+      "id": "evaluate",
+      "name": "Evaluate",
+      "description": "Grade the deliverable against every acceptance criterion. All pass → finish; any fail → loop back and fix the gap.",
+      "prompt": "Open release-notes.md and verify it against the acceptance criteria locked in {{workPath}}/gather.md, checking EACH one and writing PASS/FAIL with the evidence. Confirm: (a) every user-facing change from the gathered inventory is represented exactly once; (b) breaking changes and required user actions appear at the top, each with a concrete action; (c) no merge/dependency/CI-only noise and nothing unreleased leaked in; (d) every item cites a PR or issue; (e) the version number and release date appear as a heading; (f) the voice is consistent and written for users, not the commit log. Any FAIL routes back to the write phase to fix exactly that gap.\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": "release-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.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/re/release-notes/versions/1.0.2/test.json

@@ -0,0 +1,114 @@
+{
+  "schemaVersion": 1,
+  "title": "Public release notes from noisy change inventory",
+  "objective": "Measure whether the release-notes craftbook gathers, de-noises, classifies, and writes benefit-led release notes with breaking changes up front.",
+  "tags": [
+    "corpus"
+  ],
+  "prompt": "In the `Release Notes Eval` project, read `source/change-inventory.md` and write `release-notes.md` for HarborCRM 3.8.0 dated 2026-06-28. Include Highlights, Breaking Changes / Upgrade Notes, Features, Improvements, and Bug Fixes. Preserve PR references, exclude internal-only noise, and make the breaking config action impossible to miss.",
+  "setup": {
+    "projectName": "Release Notes Eval",
+    "about": "Self-contained eval project for release-notes. The raw change inventory is seeded in workspace/source/change-inventory.md.",
+    "missionObjectives": "Write public release notes from a noisy change inventory, preserving user-facing changes and references while excluding internal-only noise.",
+    "files": [
+      {
+        "path": "source/change-inventory.md",
+        "content": "# HarborCRM 3.8.0 change inventory\n\n- PR #812 Feature: adds saved invoice filters for finance teams.\n- PR #817 Improvement: webhook retry queue now shows next retry time in the admin panel.\n- PR #823 Breaking: integrations must rename env var `HC_WEBHOOK_SECRET` to `PAYMENTS_WEBHOOK_SECRET` before deploy.\n- PR #829 Bug fix: fixes duplicate customer merge suggestions after CSV import.\n- PR #831 Internal: renamed reducer files in the billing package.\n- PR #832 CI-only: upgraded lint runner and prettier config.\n- PR #835 Dependency bump only: patch-level dev dependency update.\n"
+      }
+    ],
+    "worker": {
+      "name": "Rina",
+      "role": "Copywriter"
+    },
+    "craftbookParams": {
+      "workPath": "tasks/eval"
+    }
+  },
+  "mocks": [],
+  "success": {
+    "summary": "workspace/release-notes.md has version/date, public sections, PR references, all user-facing changes, a prominent breaking action, and excludes internal/CI/dependency noise.",
+    "deliverables": [
+      {
+        "path": "release-notes.md",
+        "kind": "markdown-doc",
+        "minBytes": 1500,
+        "checks": [
+          {
+            "kind": "contains",
+            "file": "release-notes.md",
+            "pattern": "HarborCRM|3\\.8\\.0|2026-06-28"
+          },
+          {
+            "kind": "contains",
+            "file": "release-notes.md",
+            "pattern": "Highlights|Breaking Changes|Upgrade Notes|Features|Improvements|Bug Fixes",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "release-notes.md",
+            "pattern": "#812|#817|#823|#829",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "release-notes.md",
+            "pattern": "saved invoice filters|retry queue|duplicate customer merge",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "release-notes.md",
+            "pattern": "HC_WEBHOOK_SECRET|PAYMENTS_WEBHOOK_SECRET|before deploy|breaking",
+            "flags": "i"
+          },
+          {
+            "kind": "notContains",
+            "file": "release-notes.md",
+            "pattern": "reducer|lint runner|prettier|dependency bump|#831|#832|#835",
+            "flags": "i"
+          }
+        ]
+      }
+    ]
+  },
+  "rubric": {
+    "artifact": {
+      "path": "release-notes.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": [
+    "de-noising",
+    "benefit-led notes",
+    "breaking action visibility"
+  ],
+  "extensions": {
+    "legacySimulators": [
+      {
+        "id": "release-notes-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/re/release-pipeline-ci/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "release-pipeline-ci",
   "role": "maintenance-review",
+  "category": "code-release",
   "name": "Release Pipeline (CI/CD)",
   "description": "Author a CI/CD release workflow as a YAML pipeline (GitHub Actions style) that takes a tagged commit and turns it into a published release — running tests and build as gates, then on a version tag building the artifact, generating release notes, publishing the package/image, and creating the GitHub Release, with the dangerous publish steps gated behind the green test/build stages and the tag trigger. A planner scopes the trigger, stages, secrets, and the publish target, a developer writes the valid pipeline YAML wiring the stages in the safe order, and a reviewer validates the syntax and that publishing cannot run before tests pass. Use this to set up automated releases, a publish-on-tag workflow, or a deploy pipeline from scratch.",
   "tags": [

package/data/craftbook-templates/re/release-pipeline-ci/versions/1.0.2/craftbook.json

@@ -0,0 +1,159 @@
+{
+  "id": "release-pipeline-ci",
+  "name": "Release Pipeline (CI/CD)",
+  "description": "Author a CI/CD release workflow as a YAML pipeline (GitHub Actions style) that takes a tagged commit and turns it into a published release — running tests and build as gates, then on a version tag building the artifact, generating release notes, publishing the package/image, and creating the GitHub Release, with the dangerous publish steps gated behind the green test/build stages and the tag trigger. A planner scopes the trigger, stages, secrets, and the publish target, a developer writes the valid pipeline YAML wiring the stages in the safe order, and a reviewer validates the syntax and that publishing cannot run before tests pass. Use this to set up automated releases, a publish-on-tag workflow, or a deploy pipeline from scratch.\n\nA gallery craftbook generated from an archetype spec. It runs\n`phase → (per-phase gate) → … → evaluate → (loop) → finish`. Each build\nphase that produces a checkable artifact is followed by a **runtime\ngate-checkpoint** — the runtime verifies the artifact and routes with no\nmodel turn, looping back to redo the phase on a miss. The final `evaluate`\nstep holds a static deliverable gate plus a reviewer QA pass. What it adds\nover the generic `build-loop`: a specialist role per phase, a\ndomain-correct ordering, and a concrete per-phase quality bar.\n\nDeliverables marked \"artifact\" land in the project's artifacts drawer (`write_artifact` / `read_artifact`), not the shipped workspace — review output is not product source.\n\nPhases:\n\n1. Scope the pipeline (planner) — define trigger, stages, secrets, and publish target → gated on artifact `{{workPath}}/scope.md` (markdown-notes)\n2. Write the pipeline (developer) — implement the gated release workflow YAML → gated on `release.yml` (yaml-spec)\n3. Validate the pipeline (reviewer) — check syntax and that publish cannot run before tests pass → gated on artifact `{{workPath}}/verify.md` (markdown-notes)\n\nThe gates never advance with an unmet criterion, and loop back to the\nowning phase to fix named gaps.\n",
+  "entryStepId": "scope",
+  "triggers": [
+    "set up a release pipeline",
+    "ci/cd for releases",
+    "publish on tag workflow",
+    "github actions release",
+    "automate the release"
+  ],
+  "steps": [
+    {
+      "id": "scope",
+      "name": "Scope the pipeline",
+      "description": "define trigger, stages, secrets, and publish target",
+      "prompt": "1. Decide the trigger: typically push of a semver tag (e.g. v*.*.*) for the release path, plus PR/push for the test gate. 2. Define the ordered stages: test → build → (on tag) package/publish → create release — and which stages gate which (publish must depend on test+build passing). 3. Identify the platform (GitHub Actions assumed unless told otherwise), the runner/language toolchain, and the cache strategy. 4. Enumerate the secrets/permissions the publish step needs (registry token, GITHUB_TOKEN scopes) WITHOUT inventing real values — reference them by name. 5. Specify the publish target (npm, container registry, GitHub Release) and the artifact. 6. Good looks like: an unambiguous stage graph with explicit dependencies, the trigger condition, the named secrets, and the publish target. Write this as an acceptance-criteria checklist ('publish only runs on a version tag', 'publish depends on a green test+build', 'secrets referenced by name not value', 'stages run in the safe order', 'creates the release/artifact on the named target') plus the design to the notes file via write_task_note AND to {{workPath}}/scope.md.\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": "build"
+    },
+    {
+      "id": "build",
+      "name": "Write the pipeline",
+      "description": "implement the gated release workflow YAML",
+      "prompt": "1. Open {{workPath}}/scope.md and write the pipeline as a single valid workflow YAML file (GitHub Actions schema unless another platform was specified). 2. Wire the jobs in the safe order: a test job and a build job triggered broadly, and a publish/release job that runs ONLY on the version-tag trigger and DECLARES a needs:/dependency on test (and build) so it cannot start until they pass. 3. Reference secrets via the platform's secrets context by name (e.g. ${{ secrets.NPM_TOKEN }}) — never hardcode credentials. 4. Include checkout, toolchain setup, dependency cache, the test command, the build command, the publish command, and the create-release step against the named target. 5. Use correct YAML indentation and real action references/versions so the file would actually parse and run. 6. Good looks like: a valid, well-indented workflow where publish is gated on green tests and the tag trigger, secrets are name-referenced, and every scoped stage is present. Write the pipeline to release.yml.\n\nBefore working, open the artifact input `{{workPath}}/scope.md` with `read_artifact`; do not look for it in the workspace.",
+      "suggestedRole": "developer",
+      "consumes": [
+        {
+          "file": "{{workPath}}/scope.md",
+          "artifact": true
+        }
+      ],
+      "advanceWhen": {
+        "file": "release.yml",
+        "minBytes": 1,
+        "sniff": "nonempty"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "release.yml",
+            "bytes": 200
+          },
+          {
+            "kind": "sniff",
+            "file": "release.yml",
+            "sniff": "nonempty"
+          }
+        ],
+        "onReject": "build",
+        "maxAttempts": 3
+      },
+      "next": "verify"
+    },
+    {
+      "id": "verify",
+      "name": "Validate the pipeline",
+      "description": "check syntax and that publish cannot run before tests pass",
+      "prompt": "1. Open release.yml and confirm it is syntactically valid YAML with the platform's required top-level keys (name, on/trigger, jobs). 2. Verify the TRIGGER gating: the publish/release job must run only on a version tag, and must declare a dependency (needs:) on the test/build jobs so it cannot execute before they pass — a publish that can run on a red build is a critical FAIL. 3. Confirm secrets are referenced by name with no hardcoded credentials. 4. Check every stage from {{workPath}}/scope.md is present (test, build, publish, create-release) with real commands and pinned action versions. 5. Write a PASS/FAIL per acceptance criterion, calling out any ungated publish, syntax error, or missing stage. 6. Any failure routes back to the build phase. Write findings to {{workPath}}/verify.md.\n\nBefore working, open the artifact input `{{workPath}}/scope.md` with `read_artifact`; do not look for it in the workspace.\n\nThe deliverable `{{workPath}}/verify.md` lands in the project's artifacts drawer — write it with `write_artifact` and read it back with `read_artifact`; the shipped workspace stays untouched.",
+      "suggestedRole": "reviewer",
+      "consumes": [
+        {
+          "file": "{{workPath}}/scope.md",
+          "artifact": true
+        },
+        {
+          "file": "release.yml"
+        }
+      ],
+      "advanceWhen": {
+        "file": "{{workPath}}/verify.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "release.yml",
+            "bytes": 200
+          },
+          {
+            "kind": "sniff",
+            "file": "release.yml",
+            "sniff": "nonempty"
+          }
+        ],
+        "onReject": "verify",
+        "maxAttempts": 4
+      },
+      "next": "evaluate"
+    },
+    {
+      "id": "evaluate",
+      "name": "Evaluate",
+      "description": "Grade the deliverable against every acceptance criterion. All pass → finish; any fail → loop back and fix the gap.",
+      "prompt": "Open release.yml and verify it against {{workPath}}/scope.md, PASS/FAIL each criterion. Confirm: (a) it is valid YAML with the platform's required keys; (b) the publish/release job runs only on a version-tag trigger AND declares a needs:/dependency on the test (and build) job so it cannot run on a red build; (c) secrets are referenced by name with no hardcoded credentials; (d) every scoped stage (test, build, publish, create-release) is present with real commands and pinned action versions; (e) the publish target matches the scope. Any ungated publish, syntax error, or missing stage routes back to the build 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: \"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": "release.yml"
+        }
+      ],
+      "next": "build"
+    },
+    {
+      "id": "finish",
+      "name": "Finish",
+      "description": "All acceptance criteria met. Stamp a short summary and report DONE.",
+      "prompt": "Every acceptance criterion passed. Write a one-paragraph DONE summary to task notes via `write_task_note`: what was built, the deliverable path(s), and a one-line confirmation that each criterion is met. Then report DONE.",
+      "suggestedRole": "developer",
+      "terminal": true
+    }
+  ],
+  "version": "1.0.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/re/release-pipeline-ci/versions/1.0.2/test.json

@@ -0,0 +1,165 @@
+{
+  "schemaVersion": 1,
+  "title": "Release Pipeline (CI/CD) smoke eval",
+  "objective": "Self-contained smoke eval for the Release Pipeline (CI/CD) craftbook using the external generic harness.",
+  "tags": [
+    "external"
+  ],
+  "prompt": "Theres a fake ops service wired up for this so nothing real gets touched — the endpoints are in mocks/services.md, and the ready-made mock-probe script talks to them for you. Can you run the automation against it and write up how it went in automation.md?",
+  "setup": {
+    "projectName": "Release Pipeline (CI/CD) Eval",
+    "about": "Self-contained eval project for release-pipeline-ci. Seeded inputs are under workspace/source or workspace/fixtures; final deliverable is workspace/automation.md.",
+    "missionObjectives": "Use the Release Pipeline (CI/CD) craftbook/template, read the seeded local fixtures, and write automation.md without network calls, real credentials, or live services.",
+    "files": [
+      {
+        "path": "source/brief.md",
+        "content": "# Release Pipeline (CI/CD) 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: release-pipeline-ci - Release Pipeline (CI/CD).\n"
+      }
+    ],
+    "worker": {
+      "name": "Jules",
+      "role": "Developer"
+    },
+    "craftbookParams": {
+      "workPath": "tasks/eval"
+    }
+  },
+  "mocks": [
+    {
+      "kind": "http",
+      "id": "ops",
+      "description": "Fake operations service for this eval. GET /api/bookings/open lists the open work items; POST /api/bookings/dry-run records a simulated submission and returns DRY_RUN_OK.",
+      "credential": {
+        "name": "mock.ops"
+      },
+      "routes": [
+        {
+          "method": "GET",
+          "path": "/api/bookings/open",
+          "body": {
+            "items": [
+              "BKG-1001",
+              "BKG-1002",
+              "BKG-1003"
+            ]
+          }
+        },
+        {
+          "method": "POST",
+          "path": "/api/bookings/dry-run",
+          "status": 201,
+          "body": {
+            "status": "DRY_RUN_OK",
+            "recorded": 3
+          }
+        }
+      ]
+    },
+    {
+      "kind": "webhook",
+      "id": "notify",
+      "description": "Notification receiver. POST a JSON completion notice here when the run finishes.",
+      "path": "/hooks/notify"
+    },
+    {
+      "kind": "cli",
+      "id": "probe",
+      "description": "Provenance-trusted project script `mock-probe` that exercises the fake ops service through http.authed and returns the raw responses.",
+      "shim": {
+        "path": "scripts/mock-probe.ts",
+        "content": "import { defineScript, gezel } from '@bendyline/gezel-sdk';\n\nexport const meta = defineScript({\n  name: 'mock-probe',\n  description:\n    'Probe the live fake ops service for this eval: lists the open work items and records a dry-run submission. Outputs the raw JSON responses as evidence for the write-up.',\n  inputs: {},\n  outputs: {\n    open: { type: 'string', description: 'Raw JSON body from the open-items listing.' },\n    dryRun: { type: 'string', description: 'Raw JSON body from the dry-run submission.' },\n  },\n  requires: ['workspace.read', 'network', 'credential:mock.ops'],\n});\n\nconst services = JSON.parse(await gezel.fs.read('mocks/services.json'));\nconst base = (id) => {\n  const service = services.find((entry) => entry.id === id);\n  if (!service) throw new Error(`mock service \"${id}\" is not listed in mocks/services.json`);\n  return service.baseUrl;\n};\n\nconst open = await gezel.http.authed(`${base('ops')}/api/bookings/open`, {\n  credential: 'mock.ops',\n});\nif (!open.ok) throw new Error(`open-items listing failed: ${open.status} ${open.body}`);\n\nconst dryRun = await gezel.http.authed(`${base('ops')}/api/bookings/dry-run`, {\n  credential: 'mock.ops',\n  method: 'POST',\n  body: JSON.stringify({ items: JSON.parse(open.body).items, mode: 'dry-run' }),\n});\nif (!dryRun.ok) throw new Error(`dry-run submission failed: ${dryRun.status} ${dryRun.body}`);\n\ngezel.output({ open: open.body, dryRun: dryRun.body });\n"
+      }
+    }
+  ],
+  "success": {
+    "summary": "automation.md is grounded in live fake-service responses: the open items were actually listed and a dry-run actually recorded (request-log assertions), with safety guards and signals described.",
+    "deliverables": [
+      {
+        "path": "automation.md",
+        "kind": "markdown-report",
+        "minBytes": 900,
+        "checks": [
+          {
+            "kind": "contains",
+            "file": "automation.md",
+            "pattern": "(?:^|\\n)#{1,3}\\s+\\S",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "automation.md",
+            "pattern": "DRY_RUN_OK|dry-run|dry run",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "automation.md",
+            "pattern": "fake-ci|fake-github|/api/bookings",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "automation.md",
+            "pattern": "no real|credentials|safety|guard",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "automation.md",
+            "pattern": "success|failure|retry|abort",
+            "flags": "i"
+          }
+        ]
+      }
+    ],
+    "mocks": [
+      {
+        "service": "ops",
+        "minRequests": 2,
+        "requiredPaths": [
+          "^/api/bookings/open$",
+          "^/api/bookings/dry-run$"
+        ]
+      }
+    ]
+  },
+  "rubric": {
+    "artifact": {
+      "path": "automation.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": [
+    "dry-run safety",
+    "fake tool mapping",
+    "side-effect containment"
+  ],
+  "extensions": {
+    "legacySimulators": [
+      {
+        "id": "release-pipeline-ci-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/re/release-readiness-review/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "release-readiness-review",
   "role": "maintenance-review",
+  "category": "code-release",
   "name": "Release Readiness Review",
   "description": "Run a go/no-go release readiness review against a structured pre-launch checklist and produce a sign-off report with a clear ship decision. First scopes the release and locks a readiness checklist (acceptance criteria met, tests and CI green, no open blockers, migrations and rollback ready, monitoring and alerts in place, docs and changelog updated, feature flags and config set, and on-call/comms prepared), then verifies each item by inspecting the actual state rather than assuming, then writes a go/no-go report listing every blocker that must clear before ship and the residual risks. Use this for a release readiness review, a go/no-go decision, a pre-launch checklist, a ship-readiness gate, a launch review, or deciding if a change is safe to deploy — it produces an evidence-backed ship decision rather than a gut-feel 'looks good'.",
   "tags": [