@bendyline/gilde 0.1.37 → 0.1.39

package/data/craftbook-templates/im/image-seo-rename/versions/1.0.2/test.json

@@ -0,0 +1,106 @@
+{
+  "schemaVersion": 1,
+  "title": "Image SEO Rename & Tag smoke eval",
+  "objective": "Self-contained smoke eval for the Image SEO Rename & Tag craftbook using the media generic harness.",
+  "tags": [
+    "media"
+  ],
+  "prompt": "Our media files are all listd in source/media-index.csv. Can you put together the production plan for them as media-plan.json?",
+  "setup": {
+    "projectName": "Image SEO Rename & Tag Eval",
+    "about": "Self-contained eval project for image-seo-rename. Seeded inputs are under workspace/source or workspace/fixtures; final deliverable is workspace/media-plan.json.",
+    "missionObjectives": "Use the Image SEO Rename & Tag craftbook/template, read the seeded local fixtures, and write media-plan.json without network calls, real credentials, or live services.",
+    "files": [
+      {
+        "path": "source/brief.md",
+        "content": "# Image SEO Rename & Tag 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: image-seo-rename - Image SEO Rename & Tag.\n"
+      },
+      {
+        "path": "source/media-index.csv",
+        "content": "filename,type,duration_or_size,notes\npilot-interview.wav,audio,00:02:15,mentions response time and status silence\nreturns-desk.png,image,1600x900,shows intake form and photo evidence step\nlaunch-clip.mp4,video,00:01:05,shows barcode exception handling\n"
+      }
+    ],
+    "worker": {
+      "name": "Jules",
+      "role": "Producer"
+    },
+    "craftbookParams": {
+      "workPath": "tasks/eval"
+    }
+  },
+  "mocks": [],
+  "success": {
+    "summary": "media-plan.json is a valid JSON media-production manifest grounded in seeded fixture metadata.",
+    "deliverables": [
+      {
+        "path": "media-plan.json",
+        "kind": "json",
+        "minBytes": 700,
+        "checks": [
+          {
+            "kind": "sniff",
+            "file": "media-plan.json",
+            "sniff": "json-valid"
+          },
+          {
+            "kind": "contains",
+            "file": "media-plan.json",
+            "pattern": "pilot-interview\\.wav|returns-desk\\.png|launch-clip\\.mp4",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "media-plan.json",
+            "pattern": "outputs|assets|steps|cues|verification",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "media-plan.json",
+            "pattern": "accessibility|alt|caption|transcript|metadata",
+            "flags": "i"
+          }
+        ]
+      }
+    ]
+  },
+  "rubric": {
+    "artifact": {
+      "path": "media-plan.json",
+      "kind": "json"
+    },
+    "axes": [
+      {
+        "name": "completeness",
+        "description": "The manifest covers sources, outputs, and processing steps end to end."
+      },
+      {
+        "name": "grounding",
+        "description": "Only seeded media fixtures are referenced, with faithful metadata."
+      },
+      {
+        "name": "accessibility",
+        "description": "Alt text, captions, or transcripts are planned wherever the class requires."
+      },
+      {
+        "name": "precision",
+        "description": "Timestamps, crops, and cues are specific enough to execute."
+      }
+    ]
+  },
+  "qualityFocus": [
+    "media fixture handling",
+    "structured manifest",
+    "verification metadata"
+  ],
+  "extensions": {
+    "legacySimulators": [
+      {
+        "id": "image-seo-rename-media-fixtures",
+        "kind": "data-source",
+        "status": "implemented",
+        "description": "Seeded local media index replacing real audio, video, image generation, and external media metadata services."
+      }
+    ]
+  }
+}

package/data/craftbook-templates/in/inbox-triage/versions/1.0.2/craftbook.json

@@ -0,0 +1,152 @@
+{
+  "id": "inbox-triage",
+  "name": "Inbox Triage & Reply Drafts",
+  "description": "Triage a batch of incoming emails or messages into priority buckets and draft replies for the ones that need them. Locks the triage rules and bucket taxonomy FIRST (urgent / needs-reply / FYI / archive, plus the criteria for each and a reply policy), then classifies every message deterministically against those rules, then a copywriter drafts on-voice replies only for the messages flagged needs-reply. The rules-before-triage ordering is what stops a small model from inventing ad-hoc categories and gives the reviewer something to grade. Use for inbox zero, support-queue triage, email sorting, message prioritization, and auto-drafting responses.\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. Rules scope (planner) — lock the bucket taxonomy + triage rules + reply policy → gated on artifact `{{workPath}}/rules-scope.md` (markdown-notes)\n2. Triage (developer) — classify every message against the locked rules → gated on artifact `{{workPath}}/triage.md` (markdown-notes)\n3. Draft replies (copywriter) — write on-voice replies for the flagged messages → gated on `drafts.md` (markdown-doc)\n\nThe gates never advance with an unmet criterion, and loop back to the\nowning phase to fix named gaps.\n",
+  "entryStepId": "rules-scope",
+  "triggers": [
+    "triage my inbox",
+    "sort these emails",
+    "draft replies",
+    "inbox zero",
+    "prioritize my messages"
+  ],
+  "steps": [
+    {
+      "id": "rules-scope",
+      "name": "Rules scope",
+      "description": "lock the bucket taxonomy + triage rules + reply policy",
+      "prompt": "Define the triage system BEFORE touching any message. (1) Lock a small bucket taxonomy — exactly four: Urgent (needs action today), Needs-reply (a response is expected but not urgent), FYI (read-and-keep, no reply), Archive (no action). (2) Write 1-2 plain-language rules per bucket so classification is reproducible (e.g. 'Urgent = sender is a customer AND message contains a deadline within 48h OR the word \"blocked\"'). (3) Set a reply policy: which buckets get drafted (Urgent + Needs-reply), the target length (2-4 sentences), the voice, and any auto-close phrasing. (4) Decide the output schema: a markdown table with columns sender, subject, bucket, one-line reason, reply-needed (Y/N). Good looks like rules a different person could apply and reach the same buckets. Write an acceptance-criteria checklist ('every message lands in exactly one bucket', 'every Urgent/Needs-reply item has a drafted reply', 'no message is dropped', 'each classification cites the rule that fired') and the rules/schema to {{workPath}}/rules-scope.md via write_task_note AND to the produces path.\n\nThe deliverable `{{workPath}}/rules-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}}/rules-scope.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "{{workPath}}/rules-scope.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "{{workPath}}/rules-scope.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "rules-scope",
+        "maxAttempts": 3
+      },
+      "next": "triage"
+    },
+    {
+      "id": "triage",
+      "name": "Triage",
+      "description": "classify every message against the locked rules",
+      "prompt": "Read the message corpus (inbox export, pasted threads, or the connected mail tool). For EACH message, apply the locked rules and record: sender, subject/snippet, the assigned bucket, a one-line reason that names the rule that fired, and reply-needed Y/N. Process every message — do not sample or skip. Keep classification mechanical: when two rules could fire, the highest-severity bucket wins (Urgent > Needs-reply > FYI > Archive). Write the full classification table to {{workPath}}/triage.md via write_task_note. Stage it incrementally so progress is observable, and end with a count line (N messages, M urgent, K needs-reply).\n\nThe deliverable `{{workPath}}/triage.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}}/triage.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "{{workPath}}/triage.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "{{workPath}}/triage.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "triage",
+        "maxAttempts": 3
+      },
+      "next": "draft"
+    },
+    {
+      "id": "draft",
+      "name": "Draft replies",
+      "description": "write on-voice replies for the flagged messages",
+      "prompt": "Write a reply for EVERY message flagged reply-needed=Y in the triage table — and only those. Each draft: a clear subject (Re: …), a greeting, 2-4 sentences that directly answer or acknowledge the message and state the next step, and an on-voice sign-off matching the locked reply policy. Do not invent facts, commitments, or dates not present in the source thread; where information is missing, write a placeholder in [brackets] the user can fill. Assemble all drafts into a single drafts.md, one section per message keyed by sender + subject, with the original snippet quoted above each draft for context. On a loop-back, fix only the replies the reviewer flagged. Write the path and a count (drafts written vs replies needed) to notes via write_task_note.",
+      "suggestedRole": "copywriter",
+      "advanceWhen": {
+        "file": "drafts.md",
+        "minBytes": 1,
+        "sniff": "nonempty"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "drafts.md",
+            "bytes": 500
+          }
+        ],
+        "scripts": [
+          {
+            "name": "checkContains",
+            "scope": "standard",
+            "inputs": {
+              "file": "drafts.md",
+              "pattern": "(?:^|\\n)#{1,3}\\s+\\S",
+              "flags": "i"
+            }
+          }
+        ],
+        "onReject": "draft",
+        "maxAttempts": 4
+      },
+      "next": "evaluate"
+    },
+    {
+      "id": "evaluate",
+      "name": "Evaluate",
+      "description": "Grade the deliverable against every acceptance criterion. All pass → finish; any fail → loop back and fix the gap.",
+      "prompt": "QA the triage and drafts against the locked criteria. (1) Open {{workPath}}/triage.md and confirm every message in the corpus appears exactly once — count rows vs source messages; FAIL on any drop or duplicate. (2) Spot-check 3-4 classifications against the rules: does the cited rule actually fire for that message? (3) Open drafts.md and confirm there is a draft for every reply-needed=Y row and none for the others. (4) Read 2-3 drafts: do they answer the actual message, stay on-voice, invent no facts/dates, and bracket missing info rather than fabricating it? (5) Confirm bucket precedence was applied (no message double-bucketed). Write PASS/FAIL with the specific failing items per criterion.\n\nThen route — this is the whole point of the loop:\n\n- **Every criterion PASSES →** call `advance_task_step({ ref, stepId: \"evaluate\", next: \"finish\" })`.\n- **Any criterion FAILS →** write the specific gaps to notes, then call `advance_task_step({ ref, stepId: \"evaluate\", next: \"draft\" })` 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": "drafts.md"
+        }
+      ],
+      "next": "draft"
+    },
+    {
+      "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/in/inbox-triage/versions/1.0.2/test.json

@@ -0,0 +1,107 @@
+{
+  "schemaVersion": 1,
+  "title": "Inbox Triage & Reply Drafts smoke eval",
+  "objective": "Self-contained smoke eval for the Inbox Triage & Reply Drafts craftbook using the data generic harness.",
+  "tags": [
+    "data"
+  ],
+  "prompt": "I dropped our numbers in source/records.csv. Can you look at the data, analyze it, and put togehter some results in analysis.md?",
+  "setup": {
+    "projectName": "Inbox Triage & Reply Drafts Eval",
+    "about": "Self-contained eval project for inbox-triage. Seeded inputs are under workspace/source or workspace/fixtures; final deliverable is workspace/analysis.md.",
+    "missionObjectives": "Use the Inbox Triage & Reply Drafts craftbook/template, read the seeded local fixtures, and write analysis.md without network calls, real credentials, or live services.",
+    "files": [
+      {
+        "path": "source/brief.md",
+        "content": "# Inbox Triage & Reply Drafts 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: inbox-triage - Inbox Triage & Reply Drafts.\n"
+      },
+      {
+        "path": "source/records.csv",
+        "content": "customer,region,orders,revenue_usd,churn_risk\nAster,North,12,1440,low\nBoreal,South,8,720,medium\nCedar,West,15,2100,high\nDune,North,5,500,low\n"
+      }
+    ],
+    "worker": {
+      "name": "Jules",
+      "role": "Data Analyst"
+    },
+    "craftbookParams": {
+      "workPath": "tasks/eval"
+    }
+  },
+  "mocks": [],
+  "success": {
+    "summary": "analysis.md is a seeded-data analysis with deterministic computed facts.",
+    "deliverables": [
+      {
+        "path": "analysis.md",
+        "kind": "markdown-report",
+        "minBytes": 900,
+        "checks": [
+          {
+            "kind": "contains",
+            "file": "analysis.md",
+            "pattern": "(?:^|\\n)#{1,3}\\s+\\S",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "analysis.md",
+            "pattern": "40\\b",
+            "flags": "i",
+            "label": "include total orders of 40"
+          },
+          {
+            "kind": "contains",
+            "file": "analysis.md",
+            "pattern": "\\$?4,?760\\b",
+            "flags": "i",
+            "label": "include total revenue of 4760"
+          },
+          {
+            "kind": "contains",
+            "file": "analysis.md",
+            "pattern": "Cedar",
+            "flags": "i",
+            "label": "identify Cedar as top revenue and high risk"
+          },
+          {
+            "kind": "contains",
+            "file": "analysis.md",
+            "pattern": "high",
+            "flags": "i",
+            "label": "include churn-risk finding"
+          }
+        ]
+      }
+    ]
+  },
+  "rubric": {
+    "artifact": {
+      "path": "analysis.md",
+      "kind": "markdown"
+    },
+    "axes": [
+      {
+        "name": "accuracy",
+        "description": "Computed figures are correct against the seeded records."
+      },
+      {
+        "name": "grounding",
+        "description": "Every claim traces to the seeded data — nothing invented."
+      },
+      {
+        "name": "structure",
+        "description": "Tables and sections make the analysis checkable at a glance."
+      },
+      {
+        "name": "actionability",
+        "description": "Recommendations follow from the findings and are concretely doable."
+      }
+    ]
+  },
+  "qualityFocus": [
+    "seeded data reading",
+    "computed facts",
+    "recommendation grounding"
+  ]
+}

package/data/craftbook-templates/in/incident-comms-templates/versions/1.0.2/craftbook.json

@@ -0,0 +1,119 @@
+{
+  "id": "incident-comms-templates",
+  "name": "Incident Communication Templates",
+  "description": "Author a reusable set of incident communication templates: status-page posts and stakeholder update messages for each phase of an incident (Investigating, Identified, Monitoring, Resolved) across severities, with fill-in variables and a cadence guide. Scopes the audiences, phases, and tone rules FIRST (who reads each channel, the phase ladder, what may and may not be said, the variable set), then a copywriter writes the on-brand templates with bracketed placeholders, then a reviewer checks coverage, tone, and that no template over-promises or leaks blame. Scoping audiences and phases before drafting is what produces calm, honest, copy-paste-ready updates instead of ad-hoc panic posts. Use for incident comms, status page templates, customer incident updates, outage communication, and stakeholder messaging during an incident.\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 comms (planner) — lock audiences, phases, variables, and tone rules → gated on artifact `{{workPath}}/scope.md` (markdown-notes)\n2. Write the templates (copywriter) — draft on-brand templates with bracketed variables → gated on `templates.md` (markdown-doc)\n\nThe gates never advance with an unmet criterion, and loop back to the\nowning phase to fix named gaps.\n",
+  "entryStepId": "scope",
+  "triggers": [
+    "incident communication templates",
+    "status page templates",
+    "outage update messages",
+    "customer incident comms",
+    "stakeholder update templates"
+  ],
+  "steps": [
+    {
+      "id": "scope",
+      "name": "Scope the comms",
+      "description": "lock audiences, phases, variables, and tone rules",
+      "prompt": "Define the comms framework before drafting. (1) Lock the audiences/channels (public status page, affected-customer email, internal stakeholders) and what level of detail each receives. (2) Lock the incident phase ladder — Investigating → Identified → Monitoring → Resolved — and which severities trigger external comms. (3) Define the tone rules: calm, factual, no speculation, no premature root-cause, no blame, acknowledge impact and give a next-update time — and a do-not-say list. (4) Define the variable set every template uses ([service], [impact], [start_time], [next_update_eta], [workaround]). (5) Set the update cadence per severity. Write an acceptance-criteria checklist ('a template exists for every (audience × phase) that applies', 'each template uses the locked variables with brackets', 'every external template states impact + a next-update time', 'tone follows the rules and the do-not-say list', 'no template asserts root cause before Identified') plus the matrix + variables + tone rules to {{workPath}}/scope.md via write_task_note AND the produces path. No templates yet.\n\nThe deliverable `{{workPath}}/scope.md` lands in the project's artifacts drawer — write it with `write_artifact` and read it back with `read_artifact`; the shipped workspace stays untouched.",
+      "suggestedRole": "planner",
+      "advanceWhen": {
+        "file": "{{workPath}}/scope.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "{{workPath}}/scope.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "{{workPath}}/scope.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "scope",
+        "maxAttempts": 3
+      },
+      "next": "write"
+    },
+    {
+      "id": "write",
+      "name": "Write the templates",
+      "description": "draft on-brand templates with bracketed variables",
+      "prompt": "Write templates.md covering the locked (audience × phase) matrix — a template for every applicable cell. For each cell write a ready-to-send template: a clear subject/headline, a body in the locked tone using the bracketed variables, an explicit impact statement, and a next-update time (where the phase isn't Resolved). (1) Investigating templates acknowledge the issue and impact WITHOUT asserting cause. (2) Identified templates state what's wrong in plain language and the fix direction. (3) Monitoring templates say a fix is applied and they're watching. (4) Resolved templates confirm resolution, give a brief plain-language summary, and (for stakeholders) point to a forthcoming postmortem. Group by audience, then phase; add a short cadence guide at the top. Keep every template copy-paste-ready — only the [variables] need filling. Obey the do-not-say list and never over-promise a fix time as a guarantee. On a loop-back fix only the flagged templates. Write the path and a coverage count to notes via write_task_note.",
+      "suggestedRole": "copywriter",
+      "advanceWhen": {
+        "file": "templates.md",
+        "minBytes": 1,
+        "sniff": "nonempty"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "templates.md",
+            "bytes": 500
+          }
+        ],
+        "scripts": [
+          {
+            "name": "checkContains",
+            "scope": "standard",
+            "inputs": {
+              "file": "templates.md",
+              "pattern": "(?:^|\\n)#{1,3}\\s+\\S",
+              "flags": "i"
+            }
+          }
+        ],
+        "onReject": "write",
+        "maxAttempts": 4
+      },
+      "next": "evaluate"
+    },
+    {
+      "id": "evaluate",
+      "name": "Evaluate",
+      "description": "Grade the deliverable against every acceptance criterion. All pass → finish; any fail → loop back and fix the gap.",
+      "prompt": "Validate templates.md against every locked criterion. (1) Build the (audience × phase) matrix from {{workPath}}/scope.md and confirm a template exists for every applicable cell — any missing cell is FAIL. (2) Confirm each template uses the locked bracketed variables and that external templates state impact and a next-update time. (3) Read 3 templates for tone — calm, factual, no blame, no speculation — and confirm the do-not-say list isn't violated. (4) Confirm no Investigating template asserts a root cause and no template over-promises a fix time as a guarantee. (5) Confirm Resolved templates include a plain-language summary and (for stakeholders) a postmortem pointer, and that a cadence guide is present. Write PASS/FAIL per criterion with the specific templates at fault.\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": "templates.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/in/incident-comms-templates/versions/1.0.2/test.json

@@ -0,0 +1,113 @@
+{
+  "schemaVersion": 1,
+  "title": "Incident Communication Templates smoke eval",
+  "objective": "Self-contained smoke eval for the Incident Communication Templates craftbook using the corpus generic harness.",
+  "tags": [
+    "corpus"
+  ],
+  "prompt": "We need a incident communication templates for the returns-desk work. The backgound info is in source/brief.md — have a look and write it up in report.md.",
+  "setup": {
+    "projectName": "Incident Communication Templates Eval",
+    "about": "Self-contained eval project for incident-comms-templates. Seeded inputs are under workspace/source or workspace/fixtures; final deliverable is workspace/report.md.",
+    "missionObjectives": "Use the Incident Communication Templates craftbook/template, read the seeded local fixtures, and write report.md without network calls, real credentials, or live services.",
+    "files": [
+      {
+        "path": "source/brief.md",
+        "content": "# Incident Communication Templates 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: incident-comms-templates - Incident Communication Templates.\n"
+      }
+    ],
+    "worker": {
+      "name": "Jules",
+      "role": "Writer"
+    },
+    "craftbookParams": {
+      "workPath": "tasks/eval"
+    }
+  },
+  "mocks": [],
+  "success": {
+    "summary": "report.md is a source-grounded markdown artifact with required facts and actions.",
+    "deliverables": [
+      {
+        "path": "report.md",
+        "kind": "markdown-report",
+        "minBytes": 1000,
+        "checks": [
+          {
+            "kind": "contains",
+            "file": "report.md",
+            "pattern": "(?:^|\\n)#{1,3}\\s+\\S",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "report.md",
+            "pattern": "source/brief\\.md|Brief",
+            "flags": "i",
+            "label": "cite or name the seeded source"
+          },
+          {
+            "kind": "contains",
+            "file": "report.md",
+            "pattern": "18\\b[\\s\\S]{0,30}\\bSKUs",
+            "flags": "i",
+            "label": "include the 18-SKU pilot scope"
+          },
+          {
+            "kind": "contains",
+            "file": "report.md",
+            "pattern": "18\\s*hours|6\\s*hours",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "report.md",
+            "pattern": "14\\.2%|8\\.9%",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "report.md",
+            "pattern": "status silence|photo submission",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "report.md",
+            "pattern": "automated status emails|barcode|Finance",
+            "flags": "i"
+          }
+        ]
+      }
+    ]
+  },
+  "rubric": {
+    "artifact": {
+      "path": "report.md",
+      "kind": "markdown"
+    },
+    "axes": [
+      {
+        "name": "grounding",
+        "description": "Seeded facts appear faithfully and the source is cited."
+      },
+      {
+        "name": "structure",
+        "description": "Sections progress logically for the artifact class."
+      },
+      {
+        "name": "completeness",
+        "description": "Required elements (risks, next actions, scope) are all present."
+      },
+      {
+        "name": "tone",
+        "description": "The register fits the audience and artifact class."
+      }
+    ]
+  },
+  "qualityFocus": [
+    "source-grounded prose",
+    "section structure",
+    "next-action clarity"
+  ]
+}