@bendyline/gilde 0.1.37 → 0.1.39

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/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/versions/1.0.2/craftbook.json

@@ -0,0 +1,153 @@
+{
+  "id": "release-readiness-review",
+  "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'.\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 readiness checklist (reviewer) — lock the release scope + a go/no-go checklist → gated on artifact `{{workPath}}/scope.md` (markdown-notes)\n2. Verify readiness (developer) — check each item against the real state → gated on artifact `{{workPath}}/verify.md` (markdown-notes)\n3. Write the go/no-go report (reviewer) — ship decision + blockers + residual risk → gated on artifact `{{workPath}}/release-readiness.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": [
+    "release readiness review",
+    "are we ready to ship",
+    "go no go decision",
+    "pre-launch checklist",
+    "is this safe to deploy",
+    "ship readiness review"
+  ],
+  "steps": [
+    {
+      "id": "scope",
+      "name": "Scope the readiness checklist",
+      "description": "lock the release scope + a go/no-go checklist",
+      "prompt": "Step 1: Define the release: what is shipping (features/changes), to whom, and the rollout mechanism (full deploy / staged / flagged). Step 2: Write a readiness acceptance-criteria checklist covering: the feature's own acceptance criteria are met; the test suite and CI are green; there are no open blocking bugs or unresolved review comments; database migrations are reversible and a rollback path exists; monitoring, logging, and alerts cover the new code; user-facing docs, release notes, and changelog are updated; feature flags and config/secrets are set correctly for the target env; and on-call ownership and a comms/rollback plan are ready. Step 3: For each item, state the concrete pass condition and HOW it will be verified (where to look). Step 4: Mark which items are hard blockers vs advisory. Write the release definition + checklist to `write_task_note` AND `{{workPath}}/scope.md`. No verification 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": "reviewer",
+      "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": "verify"
+    },
+    {
+      "id": "verify",
+      "name": "Verify readiness",
+      "description": "check each item against the real state",
+      "prompt": "Step 1: For EACH checklist item, VERIFY the actual state — do not assume. Run/inspect the tests and CI status; search for open issues/TODOs/blocking review comments; check that the migration has a down path and that a rollback is documented; confirm alerts/dashboards reference the new code paths; open the docs/changelog/release notes to confirm they are updated; check the flag and config/secret values for the target environment; confirm on-call and the rollback/comms plan exist. Step 2: For each item record PASS/FAIL/NA with the EVIDENCE (the command output, the file, the config value, the issue link) — a claim without evidence is not a pass. Step 3: Classify every FAIL as a hard blocker or an accepted risk. Step 4: Note residual risks even where items pass (e.g. 'migration is reversible but locks the table for ~30s'). Good looks like: every item backed by an observation, not 'should be fine'. Stage the verification log to `write_task_note`. Do not write the report yet.\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": "developer",
+      "advanceWhen": {
+        "file": "{{workPath}}/verify.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "{{workPath}}/verify.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "{{workPath}}/verify.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "verify",
+        "maxAttempts": 3
+      },
+      "next": "report"
+    },
+    {
+      "id": "report",
+      "name": "Write the go/no-go report",
+      "description": "ship decision + blockers + residual risk",
+      "prompt": "Step 1: Open `{{workPath}}/release-readiness.md` and write the DECISION at the top: GO / NO-GO / GO-WITH-CONDITIONS, in one sentence with the deciding factor. Step 2: Add a '## Checklist' table: each item with PASS/FAIL/NA and its evidence. Step 3: Add a '## Blockers' section listing every must-clear item before ship, with the concrete action to clear it and an owner. Step 4: Add a '## Residual risks' section (accepted risks and watch-items for after deploy) and a '## Rollback' note summarizing how to back out. Step 5: If GO-WITH-CONDITIONS, list the exact conditions. The decision must follow from the evidence — no GO with an open hard blocker. On a loop-back, fix only the named gaps. `write_task_note` the report path, the decision, and the count of open blockers.\n\nThe deliverable `{{workPath}}/release-readiness.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": "{{workPath}}/release-readiness.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "{{workPath}}/release-readiness.md",
+            "bytes": 1500,
+            "artifact": true
+          },
+          {
+            "kind": "contains",
+            "file": "{{workPath}}/release-readiness.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 `{{workPath}}/release-readiness.md` and grade it against the scope checklist. Check EACH criterion and write PASS/FAIL with a one-line reason: (1) every checklist item has a PASS/FAIL/NA with concrete evidence (not an assumption); (2) tests/CI status was actually checked; (3) migration reversibility and a rollback path are confirmed; (4) monitoring/alerts and docs/changelog were verified; (5) flags/config for the target env were checked; (6) all blockers are listed with an action and owner, and residual risks are stated; (7) the GO/NO-GO decision is consistent with the evidence (no GO with an open hard blocker). If any criterion fails, name the exact gap and loop back.\n\nThe deliverable lives in the project's artifacts drawer — open `{{workPath}}/release-readiness.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": "{{workPath}}/release-readiness.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.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"
+}