@bendyline/gilde 0.1.26 → 0.1.28

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

@@ -0,0 +1,107 @@
+{
+  "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 `notes/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 notes/scope.md via write_task_note AND the produces path. No templates yet.\n\nThe deliverable `notes/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": "notes/scope.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "notes/scope.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "notes/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 notes/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.1",
+  "releasedAt": "2026-08-14T00:00:00Z"
+}

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

@@ -0,0 +1,110 @@
+{
+  "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"
+    }
+  },
+  "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"
+  ]
+}

package/data/craftbook-templates/in/incident-postmortem/versions/1.0.1/craftbook.json

@@ -0,0 +1,158 @@
+{
+  "id": "incident-postmortem",
+  "name": "Incident Postmortem",
+  "description": "Write a blameless incident postmortem after a production outage or degradation — a structured, factual document covering the impact, a precise timeline (detection → diagnosis → mitigation → resolution), the root cause and contributing factors via a five-whys analysis, what went well and what went poorly, and concrete, owned, dated action items that prevent recurrence. A researcher assembles the verified timeline and evidence from logs/alerts/chat, a copywriter writes the blameless narrative and root-cause analysis, and a reviewer checks the timeline is accurate, the analysis reaches a true root cause, and every action item is specific and owned. Use this for outage retrospectives, severity-incident reviews, and any 'what happened and how do we prevent it' writeup.\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. Assemble the timeline (researcher) — build a verified, timestamped factual timeline → gated on artifact `notes/timeline.md` (markdown-notes)\n2. Write the postmortem (copywriter) — blameless narrative, root-cause, and owned action items → gated on artifact `postmortem.md` (markdown-report)\n3. Review for accuracy and blamelessness (reviewer) — check root cause, timeline fidelity, and action quality → gated on artifact `notes/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": "timeline",
+  "triggers": [
+    "write a postmortem",
+    "incident retrospective",
+    "outage writeup",
+    "root cause analysis",
+    "post-incident review"
+  ],
+  "steps": [
+    {
+      "id": "timeline",
+      "name": "Assemble the timeline",
+      "description": "build a verified, timestamped factual timeline",
+      "prompt": "1. Gather the raw record of the incident from every available source: alerts, monitoring graphs, deploy log, incident chat, error logs, and any commands run. 2. Reconstruct a precise, timestamped timeline of key moments: first impact, detection/alert, acknowledgement, diagnosis milestones, the mitigation action, full resolution, and the all-clear. 3. Quantify the impact factually: duration, who/what was affected, magnitude (error rate, users, revenue if known). 4. Note the detection method (alert vs customer report) and time-to-detect / time-to-mitigate. 5. Keep this BLAMELESS and factual — what happened and when, not who is at fault. 6. Good looks like: a chronological, timestamped timeline whose every entry is backed by evidence, plus a quantified impact statement. Write an acceptance-criteria checklist ('timeline is timestamped and chronological', 'impact is quantified with duration and scope', 'detection and mitigation times are stated', 'analysis must reach a true root cause via five-whys', 'every action item must be specific, owned, and dated', 'tone stays blameless') plus the timeline and impact to the notes file via write_task_note AND to notes/timeline.md.\n\nThe deliverable `notes/timeline.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": "researcher",
+      "advanceWhen": {
+        "file": "notes/timeline.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "notes/timeline.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "notes/timeline.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "timeline",
+        "maxAttempts": 3
+      },
+      "next": "write"
+    },
+    {
+      "id": "write",
+      "name": "Write the postmortem",
+      "description": "blameless narrative, root-cause, and owned action items",
+      "prompt": "1. Open notes/timeline.md and write the postmortem with standard sections: Summary, Impact, Timeline, Root Cause, Contributing Factors, What Went Well, What Went Poorly, and Action Items. 2. In Root Cause, run a five-whys (or equivalent) from the symptom down to the systemic cause — not 'human made a mistake' but the system that allowed the mistake to cause an outage. 3. Keep the entire document BLAMELESS: describe systems and decisions, never blame individuals. 4. Make each Action Item concrete, with an explicit owner and a due date, and tied to a contributing factor — preventing recurrence, not vague 'be more careful'. 5. Lead with a tight executive Summary (what happened, impact, status) readable in 30 seconds. 6. Good looks like: a factual, blameless document where the root cause is systemic, the timeline matches notes/timeline.md, and every action item is specific/owned/dated. Write the postmortem to postmortem.md.\n\nBefore working, open the artifact input `notes/timeline.md` with `read_artifact`; do not look for it in the workspace.\n\nThe deliverable `postmortem.md` lands in the project's artifacts drawer — write it with `write_artifact` and read it back with `read_artifact`; the shipped workspace stays untouched.",
+      "suggestedRole": "copywriter",
+      "consumes": [
+        {
+          "file": "notes/timeline.md",
+          "artifact": true
+        }
+      ],
+      "advanceWhen": {
+        "file": "postmortem.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "postmortem.md",
+            "bytes": 1500,
+            "artifact": true
+          },
+          {
+            "kind": "contains",
+            "file": "postmortem.md",
+            "pattern": "(?:^|\\n)#{1,3}\\s+\\S",
+            "flags": "i",
+            "label": "at least one markdown heading",
+            "artifact": true
+          }
+        ],
+        "onReject": "write",
+        "maxAttempts": 3
+      },
+      "next": "review"
+    },
+    {
+      "id": "review",
+      "name": "Review for accuracy and blamelessness",
+      "description": "check root cause, timeline fidelity, and action quality",
+      "prompt": "1. Open postmortem.md and cross-check its Timeline against notes/timeline.md — every entry must be accurate and evidence-backed, nothing invented or reordered. 2. Pressure-test the Root Cause: does the five-whys actually reach a SYSTEMIC cause, or does it stop at 'someone erred'? If it stops short, it fails. 3. Verify the document is genuinely blameless — flag any individual-blaming language. 4. Audit each Action Item: is it specific, does it have an owner and a due date, and would it actually reduce recurrence of THIS class of incident? 5. Confirm Impact is quantified and the Summary is tight and accurate. 6. Write a PASS/FAIL per acceptance criterion with specifics; any failure routes back to the write phase. Write findings to notes/review.md.\n\nBefore working, open the artifact inputs `notes/timeline.md`, `postmortem.md` with `read_artifact`; do not look for them in the workspace.\n\nThe deliverable `notes/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": "notes/timeline.md",
+          "artifact": true
+        },
+        {
+          "file": "postmortem.md",
+          "artifact": true
+        }
+      ],
+      "advanceWhen": {
+        "file": "notes/review.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "postmortem.md",
+            "bytes": 1500,
+            "artifact": true
+          },
+          {
+            "kind": "contains",
+            "file": "postmortem.md",
+            "pattern": "(?:^|\\n)#{1,3}\\s+\\S",
+            "flags": "i",
+            "label": "at least one markdown heading",
+            "artifact": true
+          }
+        ],
+        "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 postmortem.md and verify it against the criteria in notes/timeline.md, PASS/FAIL each. Confirm: (a) it has Summary, Impact, Timeline, Root Cause, Contributing Factors, What Went Well/Poorly, and Action Items sections; (b) the timeline is chronological, timestamped, and matches the assembled evidence; (c) impact is quantified (duration + scope); (d) the root-cause analysis reaches a systemic cause via five-whys, not individual blame; (e) the document is blameless throughout; (f) every action item is specific, owned, and dated, and addresses a contributing factor. Any FAIL routes back to the write phase.\n\nThe deliverable lives in the project's artifacts drawer — open `postmortem.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: \"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": "postmortem.md",
+          "artifact": true
+        }
+      ],
+      "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.1",
+  "releasedAt": "2026-08-14T00:00:00Z"
+}

package/data/craftbook-templates/in/incident-postmortem/versions/1.0.1/test.json

@@ -0,0 +1,109 @@
+{
+  "schemaVersion": 1,
+  "title": "Evidence-grounded incident postmortem",
+  "objective": "Measure whether a postmortem craftbook keeps a local model grounded in a dense evidence pack and produces ordered SRE sections.",
+  "tags": [
+    "corpus"
+  ],
+  "prompt": "Theres a fake service set up for this so nothing real gets touched — details are in fixtures/fake-service.md. Can you work out the automation and write up how it woudl run in automation.md?",
+  "setup": {
+    "projectName": "Incident Postmortem Eval",
+    "files": [
+      {
+        "path": "source/brief.md",
+        "content": "# Incident Postmortem 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-postmortem - Incident Postmortem.\n"
+      },
+      {
+        "path": "fixtures/fake-service.md",
+        "content": "# Fake Service Fixture\n\nThis eval must stay in dry-run mode.\n\nAvailable fake endpoints and commands:\n- GET /api/bookings/open returns BKG-1001, BKG-1002, BKG-1003.\n- POST /api/bookings/dry-run records a simulated submission and returns DRY_RUN_OK.\n- fake-ci status returns pending twice and success on the third poll.\n- fake-github pr create returns https://example.invalid/pull/42.\n\nThe deliverable must reference these fixture names instead of real services or credentials.\n"
+      }
+    ],
+    "worker": {
+      "name": "Jules",
+      "role": "Developer"
+    }
+  },
+  "mocks": [],
+  "success": {
+    "summary": "The hand-authored incident-postmortem grader seeds five evidence files and checks ordered sections, evidence citations, timestamp citations, size, and blame-free language.",
+    "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"
+          }
+        ]
+      }
+    ]
+  },
+  "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": [
+    "dense reading",
+    "evidence grounding",
+    "ordered report structure",
+    "repair nudges"
+  ],
+  "extensions": {
+    "legacySimulators": [
+      {
+        "id": "incident-postmortem-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/in/insurance-inventory/versions/1.0.1/craftbook.json

@@ -0,0 +1,153 @@
+{
+  "id": "insurance-inventory",
+  "name": "Insurance Inventory",
+  "description": "Compile the inventory nobody has until the day they desperately need it: every cataloged item with its value, photo reference, and acquisition info in one document, the gaps (no photo, no value) named instead of papered over, and the total stated with its basis. Locks the completeness criteria FIRST, then compiles the full table, then writes the cover note — the quiet payoff of keeping the catalog honest. Use for insurance inventories, 'our agent wants a full inventory', documenting the collection for coverage, and preparing a collection record for a claim.\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 inventory (curator) — item and gap counts, completeness criteria locked → gated on artifact `notes/scope.md` (markdown-notes)\n2. Compile the inventory (data-analyst) — full item table, gaps section, stated total → gated on `insurance-inventory.md` (markdown-doc)\n3. Write the cover note (copywriter) — one-page cover note: total, gaps, review date → gated on artifact `report.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": [
+    "insurance inventory",
+    "full inventory with values",
+    "document the collection for insurance",
+    "collection inventory for our agent",
+    "compile the insurance list"
+  ],
+  "steps": [
+    {
+      "id": "scope",
+      "name": "Scope the inventory",
+      "description": "item and gap counts, completeness criteria locked",
+      "prompt": "Define the inventory before compiling it. Step 1: read the catalog store (collection.json) — the item count, which items carry values, which carry photo references and acquisition info. Step 2: lock the completeness criteria — every cataloged item appears in the inventory; every value in the inventory traces to the catalog, never invented on the spot; items without a value or photo are listed with the gap named, not quietly dropped or estimated; the total covers only the values actually on record and says so. Step 3: fix the document's shape — one table with Item, Value, and Photo columns (plus acquisition info where recorded), then a gaps section, then the stated total. Step 4: write an acceptance-criteria checklist ('every item present', 'every value traceable to the catalog', 'every gap named with a next step', 'total stated with its basis', 'readable by an insurance agent cold'). Call write_task_note with the item and gap counts + checklist and write notes/scope.md.\n\nThe deliverable `notes/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": "curator",
+      "advanceWhen": {
+        "file": "notes/scope.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "notes/scope.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "notes/scope.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "scope",
+        "maxAttempts": 3
+      },
+      "next": "compile"
+    },
+    {
+      "id": "compile",
+      "name": "Compile the inventory",
+      "description": "full item table, gaps section, stated total",
+      "prompt": "Compile the inventory document from the catalog. Step 1: build the full item table — one row per cataloged item with Item, Value, and Photo columns and acquisition info where the record has it; values copied exactly from the catalog, and gaps marked plainly in the cell rather than guessed. Step 2: after the table, list the gaps by kind — items with no value on record, items with no photo — each with the concrete step that would close it. Step 3: state the total of the recorded values and what it does not include. Write insurance-inventory.md and call write_task_note with the row count and the total.",
+      "suggestedRole": "data-analyst",
+      "advanceWhen": {
+        "file": "insurance-inventory.md",
+        "minBytes": 1,
+        "sniff": "nonempty"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "insurance-inventory.md",
+            "bytes": 1200
+          },
+          {
+            "kind": "tableShape",
+            "file": "insurance-inventory.md",
+            "requiredColumns": [
+              "Item",
+              "Value",
+              "Photo"
+            ],
+            "minRows": 3
+          }
+        ],
+        "scripts": [
+          {
+            "name": "checkContains",
+            "scope": "standard",
+            "inputs": {
+              "file": "insurance-inventory.md",
+              "pattern": "(?:^|\\n)#{1,3}\\s+\\S",
+              "flags": "i"
+            }
+          }
+        ],
+        "onReject": "compile",
+        "maxAttempts": 3
+      },
+      "next": "report"
+    },
+    {
+      "id": "report",
+      "name": "Write the cover note",
+      "description": "one-page cover note: total, gaps, review date",
+      "prompt": "Write the cover note for the inventory. Step 1: one paragraph an insurance agent can read cold — what the collection is, how many items, the total of recorded values and what that total excludes. Step 2: the gap list in brief — how many items lack values or photos and the plan to close those gaps. Step 3: a review date a year out, so the inventory stays alive instead of rotting in a drawer. Keep it calm and professional. Write report.md and call write_task_note with the report path and the total.\n\nThe deliverable `report.md` lands in the project's artifacts drawer — write it with `write_artifact` and read it back with `read_artifact`; the shipped workspace stays untouched.",
+      "suggestedRole": "copywriter",
+      "advanceWhen": {
+        "file": "report.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "report.md",
+            "bytes": 800,
+            "artifact": true
+          },
+          {
+            "kind": "contains",
+            "file": "report.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 insurance-inventory.md, report.md, and the catalog store and verify every criterion from notes/scope.md: every cataloged item has a row in the inventory (count them against the store), every value in the table matches the catalog exactly (spot-check five), every item missing a value or photo appears in the gaps section with a next step, the total re-adds correctly from the recorded values, and the cover note stands alone. Write PASS/FAIL per criterion; on any failure, name the gap and loop back to compile.\n\nThe deliverable lives in the project's artifacts drawer — open `report.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: \"compile\" })` 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": "report.md",
+          "artifact": true
+        }
+      ],
+      "next": "compile"
+    },
+    {
+      "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.1",
+  "releasedAt": "2026-08-14T00:00:00Z"
+}