@bendyline/gilde 0.1.38 → 0.1.39

package/data/craftbook-templates/fe/feature-flag-release/versions/1.0.2/craftbook.json

@@ -0,0 +1,171 @@
+{
+  "id": "feature-flag-release",
+  "name": "Feature Flag Release Plan",
+  "description": "Plan and document a progressive feature-flag rollout for shipping a change behind a flag — defining the flag and its default-off state, the staged ramp (internal → 1% → 10% → 50% → 100%) with the success and guardrail metrics that gate each step, the automatic rollback/kill-switch criteria, and the cleanup that removes the flag once fully rolled out. A planner scopes the flag, ramp stages, and metrics, a developer writes the rollout runbook with the exact flag changes and the kill-switch procedure, and a reviewer verifies each ramp step has a measurable gate and a safe abort. Use this for gradual rollouts, canary releases, dark launches, percentage-based ramps, and de-risking a risky change behind a toggle.\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 rollout (planner) — define the flag, ramp stages, and gating metrics → gated on artifact `{{workPath}}/scope.md` (markdown-notes)\n2. Write the rollout runbook (developer) — exact flag changes, gates, and kill-switch procedure → gated on `rollout-plan.md` (markdown-doc)\n3. Review the rollout safety (reviewer) — verify each stage has a measurable gate and safe abort → 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": "scope",
+  "triggers": [
+    "feature flag rollout plan",
+    "gradual rollout",
+    "canary release plan",
+    "percentage ramp",
+    "dark launch behind a flag"
+  ],
+  "steps": [
+    {
+      "id": "scope",
+      "name": "Scope the rollout",
+      "description": "define the flag, ramp stages, and gating metrics",
+      "prompt": "1. Define the feature flag: name, what it controls, and its initial state (default OFF in production). 2. Design the ramp stages — typically internal/dogfood → 1% → 10% → 50% → 100% — and the dwell time (or sample size) at each stage before advancing. 3. For each stage define the SUCCESS metric that must improve/hold and the GUARDRAIL metrics that must NOT regress (error rate, latency, conversion) — these gate the advance. 4. Define the kill-switch / automatic rollback criteria: the thresholds that mean 'flip the flag off immediately'. 5. Identify the targeting dimension (user %, account, region) and any segments to exclude. 6. Good looks like: a staged ramp where each step has an entry condition, success + guardrail metrics, and an abort threshold, plus the flag definition and cleanup intent. Write this as an acceptance-criteria checklist ('flag defaults OFF', 'each ramp stage has success + guardrail metrics gating the advance', 'kill-switch thresholds are defined and measurable', 'targeting and exclusions specified', 'flag-cleanup step exists') plus the plan 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": "write"
+    },
+    {
+      "id": "write",
+      "name": "Write the rollout runbook",
+      "description": "exact flag changes, gates, and kill-switch procedure",
+      "prompt": "1. Open {{workPath}}/scope.md and write the rollout as a numbered runbook an operator can execute stage by stage. 2. For each stage give the EXACT flag change (set flag X to Y% for segment Z), the metrics to watch and where (dashboard/query), the dwell time, and the explicit GO/HOLD/ABORT decision against the success+guardrail thresholds. 3. Document the kill-switch procedure prominently: the exact action to flip the flag fully OFF and the thresholds that trigger it automatically or manually. 4. Include the verification at each step (confirm the flag actually took effect for the intended cohort). 5. End with the cleanup step: after 100% and a soak period, remove the flag and the dead code path, and delete the flag config. 6. Good looks like: a stage-by-stage runbook where every ramp step has a concrete flag change, a measurable gate, and an abort path, plus a kill-switch and a cleanup step. Write the runbook to rollout-plan.md.\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": "rollout-plan.md",
+        "minBytes": 1,
+        "sniff": "nonempty"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "rollout-plan.md",
+            "bytes": 500
+          }
+        ],
+        "scripts": [
+          {
+            "name": "checkContains",
+            "scope": "standard",
+            "inputs": {
+              "file": "rollout-plan.md",
+              "pattern": "(?:^|\\n)#{1,3}\\s+\\S",
+              "flags": "i"
+            }
+          }
+        ],
+        "onReject": "write",
+        "maxAttempts": 3
+      },
+      "next": "review"
+    },
+    {
+      "id": "review",
+      "name": "Review the rollout safety",
+      "description": "verify each stage has a measurable gate and safe abort",
+      "prompt": "1. Open rollout-plan.md and confirm the flag defaults OFF and that every ramp stage from {{workPath}}/scope.md is present with a concrete flag change. 2. Verify each stage's advance is gated on MEASURABLE success + guardrail metrics with thresholds — a stage that advances on vibes is a FAIL. 3. Scrutinize the kill-switch: is the abort action exact, and are the trigger thresholds defined and reachable mid-rollout? 4. Confirm targeting/exclusions are specified and the cleanup step removes the flag and dead code. 5. Write a PASS/FAIL per acceptance criterion, flagging any ungated advance or missing abort. 6. Any failure routes back to the write phase. Write findings to {{workPath}}/review.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}}/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}}/scope.md",
+          "artifact": true
+        },
+        {
+          "file": "rollout-plan.md"
+        }
+      ],
+      "advanceWhen": {
+        "file": "{{workPath}}/review.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "rollout-plan.md",
+            "bytes": 500
+          }
+        ],
+        "scripts": [
+          {
+            "name": "checkContains",
+            "scope": "standard",
+            "inputs": {
+              "file": "rollout-plan.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 rollout-plan.md and verify it against {{workPath}}/scope.md, PASS/FAIL each criterion. Confirm: (a) the flag is defined and defaults OFF in production; (b) every ramp stage has a concrete flag change AND a measurable success+guardrail metric gate that controls the advance; (c) a kill-switch with exact abort action and defined trigger thresholds is present and prominent; (d) targeting and exclusions are specified; (e) a cleanup step removes the flag and dead code after full rollout. Any ungated advance or missing abort path 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": "rollout-plan.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/fe/feature-flag-release/versions/1.0.2/test.json

@@ -0,0 +1,165 @@
+{
+  "schemaVersion": 1,
+  "title": "Feature Flag Release Plan smoke eval",
+  "objective": "Self-contained smoke eval for the Feature Flag Release Plan 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": "Feature Flag Release Plan Eval",
+    "about": "Self-contained eval project for feature-flag-release. Seeded inputs are under workspace/source or workspace/fixtures; final deliverable is workspace/automation.md.",
+    "missionObjectives": "Use the Feature Flag Release Plan 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": "# Feature Flag Release Plan 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: feature-flag-release - Feature Flag Release Plan.\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": "feature-flag-release-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/fe/feature-flag-rollout/versions/1.0.2/craftbook.json

@@ -0,0 +1,160 @@
+{
+  "id": "feature-flag-rollout",
+  "name": "Flagged Feature Rollout",
+  "description": "Add a new feature behind a feature flag so it can ship dark, be toggled per-environment/user, and roll back instantly without a deploy. Plans the flag contract FIRST — the flag name/default, the toggle points, the on/off behavior, the targeting (env/percentage/user), and the cleanup plan — then implements the flagged code with both paths working, then a reviewer verifies both states behave and the off-state default is safe. Covers feature flags, toggle points, percentage/targeted rollout, default-off safety, dark launches, and flag-cleanup discipline.\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. Plan the flag (planner) — lock flag name, default, toggle points, targeting → gated on artifact `{{workPath}}/plan.md` (markdown-notes)\n2. Build the flagged feature (developer) — implement both paths behind the flag → gated on `src/feature.js` (code-module)\n3. Verify both states (reviewer) — confirm off=original, on=new, safe default → 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": "plan",
+  "triggers": [
+    "add a feature flag",
+    "ship behind a flag",
+    "feature toggle",
+    "gradual rollout",
+    "dark launch a feature"
+  ],
+  "steps": [
+    {
+      "id": "plan",
+      "name": "Plan the flag",
+      "description": "lock flag name, default, toggle points, targeting",
+      "prompt": "Plan the feature flag before coding. Step 1: Name the flag and set its DEFAULT (default-off is the safe choice for new features) and where its value is read from (config/env/flag service). Step 2: Identify the toggle points in the code — exactly where the flag branches old behavior vs new. Step 3: Define the behavior in each state precisely, and the targeting strategy (all-on/off, per-environment, percentage, or specific users). Step 4: Note the rollback story (flip the flag, no deploy) and the cleanup plan (when/how the flag and the dead branch get removed later). Step 5: Write a numbered acceptance-criteria checklist of 5-9 items (e.g. 'flag-off reproduces the original behavior exactly', 'flag-on enables the new feature', 'the default is safe', 'no code path runs both branches'). `write_task_note` the flag plan + checklist and write the same to the produces path.\n\nThe deliverable `{{workPath}}/plan.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}}/plan.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "{{workPath}}/plan.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "{{workPath}}/plan.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "plan",
+        "maxAttempts": 3
+      },
+      "next": "build"
+    },
+    {
+      "id": "build",
+      "name": "Build the flagged feature",
+      "description": "implement both paths behind the flag",
+      "prompt": "Implement the feature behind the flag to the plan. Step 1: Read the flag value from the agreed source with the safe default. Step 2: At each toggle point, branch cleanly: flag-OFF must reproduce the original behavior exactly (no behavior change for existing users), flag-ON enables the new feature. Step 3: Keep the flag check at the boundary so the two paths are clear and neither leaks into the other; support the targeting strategy (e.g. percentage/user check) if specified. Step 4: Ensure the new feature is reachable only when on, and that the off path is the trusted fallback. Write the implementation to the produces path. On a loop-back, fix only the named gap. `write_task_note` the file path and which criteria now pass.",
+      "suggestedRole": "developer",
+      "advanceWhen": {
+        "file": "src/feature.js",
+        "minBytes": 1,
+        "sniff": "nonempty"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "src/feature.js",
+            "bytes": 200
+          },
+          {
+            "kind": "sniff",
+            "file": "src/feature.js",
+            "sniff": "nonempty"
+          },
+          {
+            "kind": "esmImports",
+            "file": "src/feature.js"
+          },
+          {
+            "kind": "sourceParses",
+            "file": "src/feature.js"
+          }
+        ],
+        "onReject": "build",
+        "maxAttempts": 3
+      },
+      "next": "verify"
+    },
+    {
+      "id": "verify",
+      "name": "Verify both states",
+      "description": "confirm off=original, on=new, safe default",
+      "prompt": "Verify the flag behaves in both states. Step 1: With the flag OFF, confirm the behavior is identical to before the feature existed (existing tests still green, no surprises). Step 2: With the flag ON, confirm the new feature works as specified. Step 3: Confirm the default value is the safe one and that flipping the flag fully switches behavior with no deploy needed. Step 4: Confirm targeting (if any) routes correctly and that no path accidentally runs both branches. Write a verification note covering the off-state, on-state, and default to the produces path.\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",
+      "advanceWhen": {
+        "file": "{{workPath}}/verify.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "src/feature.js",
+            "bytes": 200
+          },
+          {
+            "kind": "sniff",
+            "file": "src/feature.js",
+            "sniff": "nonempty"
+          },
+          {
+            "kind": "esmImports",
+            "file": "src/feature.js"
+          },
+          {
+            "kind": "sourceParses",
+            "file": "src/feature.js"
+          }
+        ],
+        "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": "Toggle the flag and test both states. For EACH acceptance criterion: confirm flag-OFF reproduces the original behavior exactly, confirm flag-ON enables the new feature, confirm the default is safe, confirm targeting routes correctly, and confirm no path runs both branches. Write PASS/FAIL per criterion; an off-state that changed existing behavior is a 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": "src/feature.js"
+        }
+      ],
+      "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"
+}