@bendyline/gilde 0.1.38 → 0.1.39

package/data/craftbook-templates/re/record-a-relative/versions/1.0.2/test.json

@@ -0,0 +1,113 @@
+{
+  "schemaVersion": 1,
+  "title": "Record a Relative — Oma's interview",
+  "objective": "Measure whether the record-a-relative craftbook files the interview transcript, extracts family facts with their quotes, and surfaces the conflict with the existing tree instead of silently resolving it.",
+  "tags": [
+    "corpus"
+  ],
+  "prompt": "we recorded an intervew with oma yesterday, transcript is in recordings/oma-2026-07.txt — can you file it and pull out the family facts?",
+  "setup": {
+    "projectName": "Van Dam Family History",
+    "about": "Family history project for the van Dam family. The family record is workspace/tree.json; raw interview recordings land under workspace/recordings; filed transcripts live under workspace/interviews.",
+    "missionObjectives": "Bank every elder interview while the telling is fresh: transcript filed, facts extracted with their source quotes, conflicts surfaced, follow-up questions written. Grounded in the seeded transcript and tree; no live services, no real credentials.",
+    "files": [
+      {
+        "path": "recordings/oma-2026-07.txt",
+        "content": "Interview with Oma (Geertje van Dam-Boersma), recorded 18 July 2026 at the kitchen table. Interviewer: Thomas (grandson).\n\nTHOMAS: Let's start with your father. What do you remember being told about when he was born?\n\nOMA: My father, Hendrik, was born in 1919. I know the register says 1921, everyone waves the register at me, but his own mother told me 1919, at this table, and she would know better than a clerk with cold fingers. The registration was late because of the farm — they registered him when they registered the new calf, that was the joke.\n\nTHOMAS: And where was that?\n\nOMA: On the farm at Wons. The family had been at Wons since anyone could count. He left for the harbor town in 1936 to work the fish auction — sixteen years old with one good coat.\n\nTHOMAS: When did he meet your mother?\n\nOMA: At the auction. She was a mender of nets, Anna Visser, and he bought a torn net on purpose three weeks running to have a reason to speak to her. They married in 1941. I do not know the church — ask Tante Riet, she has the photograph with the church behind them.\n\nTHOMAS: And you came along —\n\nOMA: 1943, in the middle of everything. My brother Jan in 1946, and Els, the youngest, in 1949. Three of us in a house you could cross in four steps.\n\nTHOMAS: What about the shop I've heard about?\n\nOMA: The fish shop, 1952 he opened it, the year of the great herring catch. He painted the name himself and misspelled it — VAN DAMM with two Ms — and he refused to repaint it, he said the extra M was free advertising. It stayed two Ms until they sold in 1961.\n\nTHOMAS: Did he ever talk about his brothers?\n\nOMA: Two brothers. Willem, the eldest, and little Piet. Piet went to Rotterdam — or Willem went, and Piet stayed — no. I am not sure. One of them went to Rotterdam for the docks and one stayed at Wons. Do not write it down as certain, I am guessing which was which.\n\nTHOMAS: Anything you want the record to keep?\n\nOMA: That he sang. Nobody remembers it because he only sang gutting fish, when his hands were busy and his face forgot to be stern. Put that in. The dates you can argue about. The singing was true.\n\n[recording ends 41:19]\n"
+      },
+      {
+        "path": "tree.json",
+        "content": "{\n  \"family\": \"van Dam\",\n  \"updated\": \"2026-07-01\",\n  \"people\": [\n    { \"id\": \"hendrik\", \"name\": \"Hendrik van Dam\", \"born\": 1921, \"bornNote\": \"per civil register\", \"died\": 1998, \"birthplace\": \"Wons\" },\n    { \"id\": \"anna\", \"name\": \"Anna van Dam-Visser\", \"born\": 1920, \"died\": 2001, \"occupation\": \"net mender\" },\n    { \"id\": \"geertje\", \"name\": \"Geertje van Dam-Boersma\", \"born\": 1943, \"note\": \"Oma — this interview's teller\" },\n    { \"id\": \"jan\", \"name\": \"Jan van Dam\", \"born\": 1946 },\n    { \"id\": \"els\", \"name\": \"Els van Dam\", \"born\": 1949 },\n    { \"id\": \"willem\", \"name\": \"Willem van Dam\", \"born\": 1915, \"note\": \"Hendrik's brother — whereabouts after 1936 unknown\" },\n    { \"id\": \"piet\", \"name\": \"Piet van Dam\", \"born\": 1924, \"note\": \"Hendrik's brother — whereabouts uncertain\" },\n    { \"id\": \"riet\", \"name\": \"Riet Boersma\", \"born\": 1940, \"note\": \"Tante Riet — holds the wedding photograph\" },\n    { \"id\": \"thomas\", \"name\": \"Thomas van Dam\", \"born\": 1998, \"note\": \"grandson, interviewer\" },\n    { \"id\": \"hendrik-sr\", \"name\": \"Hendrik van Dam sr.\", \"born\": 1888, \"died\": 1954, \"birthplace\": \"Wons\" },\n    { \"id\": \"trijntje\", \"name\": \"Trijntje van Dam-Postma\", \"born\": 1892, \"died\": 1975, \"note\": \"Hendrik's mother — source of the 1919 birth-year claim\" },\n    { \"id\": \"marriage-hendrik-anna\", \"name\": \"Marriage: Hendrik & Anna\", \"born\": 1941, \"note\": \"church unknown\" }\n  ]\n}\n"
+      }
+    ],
+    "worker": {
+      "name": "Teun",
+      "role": "Genealogist"
+    },
+    "craftbookParams": {
+      "workPath": "tasks/eval"
+    }
+  },
+  "mocks": [],
+  "success": {
+    "summary": "The transcript is filed under interviews/, and tasks/eval/report.md extracts the facts with their quotes, surfaces the 1919-vs-1921 birth-year conflict as a conflict, keeps the uncertain brother story uncertain, and asks follow-up questions.",
+    "deliverables": [
+      {
+        "path": "tasks/eval/report.md",
+        "kind": "markdown-report",
+        "minBytes": 1000,
+        "checks": [
+          {
+            "kind": "contains",
+            "file": "tasks/eval/report.md",
+            "pattern": "(?:^|\\n)#{1,3}\\s+\\S",
+            "flags": "i"
+          },
+          {
+            "kind": "valuesSubsetOf",
+            "file": "tasks/eval/report.md",
+            "sourceFiles": [
+              "recordings/oma-2026-07.txt",
+              "tree.json"
+            ],
+            "pattern": "\\b(1[89]\\d{2}|20\\d{2})\\b",
+            "minMatches": 2,
+            "label": "every year cited exists in the transcript or the tree"
+          },
+          {
+            "kind": "contains",
+            "file": "tasks/eval/report.md",
+            "pattern": "conflict|differs|doesn.t match|discrepan|disagree",
+            "flags": "i",
+            "label": "the tree conflict is surfaced"
+          },
+          {
+            "kind": "contains",
+            "file": "tasks/eval/report.md",
+            "pattern": "\\?",
+            "label": "follow-up questions are real questions"
+          }
+        ]
+      }
+    ],
+    "checks": [
+      {
+        "kind": "fileCount",
+        "ext": [
+          "md"
+        ],
+        "min": 1,
+        "dir": "interviews"
+      }
+    ]
+  },
+  "rubric": {
+    "artifact": {
+      "path": "tasks/eval/report.md",
+      "kind": "markdown"
+    },
+    "axes": [
+      {
+        "name": "fidelity",
+        "description": "Every extracted fact carries a quote that actually appears in the transcript; nothing is attributed that wasn't said."
+      },
+      {
+        "name": "genealogical rigor",
+        "description": "Facts, sources, and confidence are kept apart — the register year and the mother's year are both recorded, and the uncertain brother story stays uncertain."
+      },
+      {
+        "name": "conflict surfacing",
+        "description": "The 1919-vs-1921 birth year is presented as a conflict for the owner, never silently resolved to one value."
+      },
+      {
+        "name": "warmth",
+        "description": "The record keeps the human material — the singing, the two Ms — alongside the dates."
+      }
+    ]
+  },
+  "qualityFocus": [
+    "fact-to-quote sourcing",
+    "conflict surfacing",
+    "uncertainty preservation"
+  ]
+}

package/data/craftbook-templates/re/recurring-invoice-run/versions/1.0.2/craftbook.json

@@ -0,0 +1,160 @@
+{
+  "id": "recurring-invoice-run",
+  "name": "Generate and Send Recurring Invoices",
+  "description": "Run a recurring billing batch: for each active client/subscription due this period, generate a correctly-numbered, line-itemed invoice with taxes and totals, render it, and send it — once, idempotently, with a sent-log. Locks the invoice template, the numbering scheme, the tax/total math, and the due/idempotency rules FIRST, then builds the generate-render-send batch keyed to a billing-run log, then verifies every due client was invoiced exactly once, totals are arithmetically correct, and numbers are sequential with no gaps or dupes. Locking numbering and math up front is what keeps recurring billing audit-clean instead of producing duplicate or mis-totaled invoices.\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 invoice run (planner) — template, numbering, tax/total math, due + idempotency → gated on artifact `{{workPath}}/scope.md` (markdown-notes)\n2. Build the invoice run (developer) — select due, number, compute, render, send, log → gated on `invoice_run.py` (code-module)\n3. Verify the run (reviewer) — once-per-client, correct math, gap-free numbering → gated on artifact `{{workPath}}/verify.md` (markdown-notes)\n\nThe gates never advance with an unmet criterion, and loop back to the\nowning phase to fix named gaps.\n",
+  "entryStepId": "scope",
+  "triggers": [
+    "generate recurring invoices",
+    "send monthly invoices",
+    "automate billing",
+    "invoice run",
+    "recurring invoice batch"
+  ],
+  "steps": [
+    {
+      "id": "scope",
+      "name": "Scope the invoice run",
+      "description": "template, numbering, tax/total math, due + idempotency",
+      "prompt": "Define the billing contract before generating anything. Step 1: identify the client/subscription source (who is active, their rate/plan, billing cycle, tax region) and the rule for who is DUE this period. Step 2: define the invoice template fields (issuer, client, line items, quantities, unit price, subtotal, tax, total, due date) and the numbering scheme (prefix + zero-padded sequence) with the rule that numbers are sequential, unique, and gap-free. Step 3: define the math exactly — line total = qty × unit price, subtotal = sum of lines, tax = subtotal × rate (per region), total = subtotal + tax, with rounding to currency precision. Step 4: define the idempotency rule — a billing-run log keyed by client+period prevents double-invoicing and double-sending on a re-run. Step 5: write an acceptance-criteria checklist ('every due client invoiced exactly once', 'invoice numbers sequential/unique/gap-free', 'all totals arithmetically correct to currency precision', 'each invoice rendered and sent once', 'a re-run sends nothing already sent', 'a sent-log records client, number, amount, timestamp'). Call write_task_note with template + numbering + math + rules + checklist and write {{workPath}}/scope.md. No generation 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": "build"
+    },
+    {
+      "id": "build",
+      "name": "Build the invoice run",
+      "description": "select due, number, compute, render, send, log",
+      "prompt": "Implement the billing batch to the locked contract. Step 1: load the billing-run log and select clients DUE this period who are not already invoiced for it. Step 2: assign the next sequential invoice number (atomic against the log so no two invoices share a number and there are no gaps). Step 3: compute line totals, subtotal, region tax, and total with correct currency rounding; never eyeball the math. Step 4: render each invoice to the deliverable format and send it via the available channel, recording success before marking sent. Step 5: append a sent-log row per invoice (client, number, period, amount, timestamp, status) and write the batch as a runnable module; on a per-client failure, log it and continue. Call write_task_note with the module path, the sent-log path, and counts (invoiced/sent/failed).",
+      "suggestedRole": "developer",
+      "advanceWhen": {
+        "file": "invoice_run.py",
+        "minBytes": 1,
+        "sniff": "nonempty"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "invoice_run.py",
+            "bytes": 200
+          },
+          {
+            "kind": "sniff",
+            "file": "invoice_run.py",
+            "sniff": "nonempty"
+          },
+          {
+            "kind": "esmImports",
+            "file": "invoice_run.py"
+          },
+          {
+            "kind": "sourceParses",
+            "file": "invoice_run.py"
+          }
+        ],
+        "onReject": "build",
+        "maxAttempts": 3
+      },
+      "next": "verify"
+    },
+    {
+      "id": "verify",
+      "name": "Verify the run",
+      "description": "once-per-client, correct math, gap-free numbering",
+      "prompt": "Verify the billing run against scope. Step 1: confirm the module runs and produces a sent-log. Step 2: confirm every DUE client was invoiced exactly once and no not-due client was billed. Step 3: confirm invoice numbers are sequential, unique, and gap-free across the run and continuous with prior runs. Step 4: re-derive the math on 3 invoices by hand (line totals, subtotal, tax, total, rounding) and confirm it matches. Step 5: confirm idempotency — a re-run sends nothing already in the sent-log — and that per-client send failures were logged without aborting the batch. Write PASS/FAIL per criterion to {{workPath}}/verify.md and task notes; on failure, name the invoices and loop back to build.\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": "invoice_run.py",
+            "bytes": 200
+          },
+          {
+            "kind": "sniff",
+            "file": "invoice_run.py",
+            "sniff": "nonempty"
+          },
+          {
+            "kind": "esmImports",
+            "file": "invoice_run.py"
+          },
+          {
+            "kind": "sourceParses",
+            "file": "invoice_run.py"
+          }
+        ],
+        "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": "Run invoice_run.py (or trace it) and verify every criterion from {{workPath}}/scope.md: every due client invoiced exactly once (no not-due client billed), invoice numbers sequential/unique/gap-free and continuous with prior runs, totals arithmetically correct (re-derive 3 invoices by hand including tax and rounding), each invoice sent once with a re-run sending nothing already in the sent-log, and per-client failures logged without aborting. Write PASS/FAIL per criterion; on any failure, name the invoices and loop back to build.\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": "invoice_run.py"
+        }
+      ],
+      "next": "build"
+    },
+    {
+      "id": "finish",
+      "name": "Finish",
+      "description": "All acceptance criteria met. Stamp a short summary and report DONE.",
+      "prompt": "Every acceptance criterion passed. Write a one-paragraph DONE summary to task notes via `write_task_note`: what was built, the deliverable path(s), and a one-line confirmation that each criterion is met. Then report DONE.",
+      "suggestedRole": "developer",
+      "terminal": true
+    }
+  ],
+  "version": "1.0.2",
+  "releasedAt": "2026-08-21T00:00:00Z",
+  "paramSchema": {
+    "type": "object",
+    "properties": {
+      "workPath": {
+        "type": "string",
+        "title": "Working folder",
+        "description": "Per-task working folder in the artifacts drawer. Defaults to this task's own folder so runs never collide; override with a stable name when you deliberately want runs to share files.",
+        "default": "{{task.dir}}"
+      }
+    }
+  },
+  "minGezelVersion": "1.26233"
+}

package/data/craftbook-templates/re/recurring-invoice-run/versions/1.0.2/test.json

@@ -0,0 +1,107 @@
+{
+  "schemaVersion": 1,
+  "title": "Generate and Send Recurring Invoices smoke eval",
+  "objective": "Self-contained smoke eval for the Generate and Send Recurring Invoices 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": "Generate and Send Recurring Invoices Eval",
+    "about": "Self-contained eval project for recurring-invoice-run. Seeded inputs are under workspace/source or workspace/fixtures; final deliverable is workspace/analysis.md.",
+    "missionObjectives": "Use the Generate and Send Recurring Invoices 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": "# Generate and Send Recurring Invoices 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: recurring-invoice-run - Generate and Send Recurring Invoices.\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/re/refactor-module/versions/1.0.3/craftbook.json

@@ -0,0 +1,160 @@
+{
+  "id": "refactor-module",
+  "name": "Behavior-Preserving Refactor",
+  "description": "Refactor a module to improve its structure, readability, or design WITHOUT changing observable behavior — the defining constraint is that the tests stay green throughout. Plans the refactor FIRST — the target structure, the seams to introduce, the safe step sequence, and the green-tests guardrail — then refactors in small reversible steps, then a reviewer confirms behavior is unchanged and the code is genuinely cleaner. Covers extract-function/module, dependency seams, removing duplication, naming, and test-green-as-invariant refactoring.\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 refactor (planner) — lock target structure, steps, green-tests guardrail → gated on artifact `{{workPath}}/plan.md` (markdown-notes)\n2. Refactor (developer) — apply small reversible steps, tests green throughout → gated on `src/refactored.js` (code-module)\n3. Verify behavior preserved (reviewer) — confirm tests green and code is genuinely cleaner → 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": [
+    "refactor this module",
+    "clean up the code",
+    "improve code structure",
+    "behavior-preserving refactor",
+    "reduce duplication"
+  ],
+  "steps": [
+    {
+      "id": "plan",
+      "name": "Plan the refactor",
+      "description": "lock target structure, steps, green-tests guardrail",
+      "prompt": "Plan the refactor before touching code — the prime directive is preserving behavior. Step 1: Identify the specific smells (duplication, long function, tangled responsibilities, poor names) and the target structure you want. Step 2: Confirm there is a test safety net; if coverage is thin, note the characterization tests to add FIRST so behavior is pinned before changing structure. Step 3: Break the work into small, individually-reversible steps (extract this function, introduce this seam, rename that), each of which keeps tests green. Step 4: Write a numbered acceptance-criteria checklist of 5-9 items (e.g. 'all existing tests pass before and after', 'public API/behavior is unchanged', 'the targeted duplication is gone', 'no function exceeds N lines / responsibilities are separated'). `write_task_note` the 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": "refactor"
+    },
+    {
+      "id": "refactor",
+      "name": "Refactor",
+      "description": "apply small reversible steps, tests green throughout",
+      "prompt": "Execute the refactor in small steps, keeping the tests green the entire time. Step 1: If the plan called for characterization tests, add them first and confirm they pass against current behavior. Step 2: Apply one planned step at a time — extract, rename, dedupe, introduce a seam — and run the tests after EACH step; if a step breaks them, revert it and try smaller. Step 3: Do not change public signatures or observable behavior unless the plan explicitly says so. Step 4: Stop when the target structure is reached and the smells are gone. Write the refactor summary (what changed structurally, tests still green) to the produces path. On a loop-back, address only the reviewer's points. `write_task_note` the summary and which criteria now pass.",
+      "suggestedRole": "developer",
+      "advanceWhen": {
+        "file": "src/refactored.js",
+        "minBytes": 1,
+        "sniff": "nonempty"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "src/refactored.js",
+            "bytes": 200
+          },
+          {
+            "kind": "sniff",
+            "file": "src/refactored.js",
+            "sniff": "nonempty"
+          },
+          {
+            "kind": "esmImports",
+            "file": "src/refactored.js"
+          },
+          {
+            "kind": "sourceParses",
+            "file": "src/refactored.js"
+          }
+        ],
+        "onReject": "refactor",
+        "maxAttempts": 3
+      },
+      "next": "verify"
+    },
+    {
+      "id": "verify",
+      "name": "Verify behavior preserved",
+      "description": "confirm tests green and code is genuinely cleaner",
+      "prompt": "Verify the refactor preserved behavior and actually improved the code. Step 1: Run the full test suite and confirm it is green (this is the hard gate). Step 2: Confirm the public API/observable behavior is identical to before. Step 3: Confirm the targeted smell is actually fixed — the duplication is gone, the function is decomposed, names are clearer — not just moved around. Step 4: Confirm no behavior was sneaked in under cover of the refactor. Write a verification note with the test result and a before/after readability assessment 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/refactored.js",
+            "bytes": 200
+          },
+          {
+            "kind": "sniff",
+            "file": "src/refactored.js",
+            "sniff": "nonempty"
+          },
+          {
+            "kind": "esmImports",
+            "file": "src/refactored.js"
+          },
+          {
+            "kind": "sourceParses",
+            "file": "src/refactored.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": "Run the test suite. For EACH acceptance criterion: confirm ALL existing tests pass (green is mandatory), confirm public behavior is unchanged, confirm the targeted smell is genuinely fixed, and confirm no new behavior crept in. Write PASS/FAIL per criterion; a single failing test is an automatic FAIL of the whole refactor.\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: \"refactor\" })` 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/refactored.js"
+        }
+      ],
+      "next": "refactor"
+    },
+    {
+      "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.3",
+  "releasedAt": "2026-08-21T00:00:00Z",
+  "paramSchema": {
+    "type": "object",
+    "properties": {
+      "workPath": {
+        "type": "string",
+        "title": "Working folder",
+        "description": "Per-task working folder in the artifacts drawer. Defaults to this task's own folder so runs never collide; override with a stable name when you deliberately want runs to share files.",
+        "default": "{{task.dir}}"
+      }
+    }
+  },
+  "minGezelVersion": "1.26233"
+}

package/data/craftbook-templates/re/refactor-module/versions/1.0.3/test.json

@@ -0,0 +1,95 @@
+{
+  "schemaVersion": 1,
+  "title": "Behavior-Preserving Refactor smoke eval",
+  "objective": "Self-contained smoke eval for the Behavior-Preserving Refactor craftbook using the code generic harness.",
+  "tags": [
+    "code"
+  ],
+  "prompt": "We need a small Node helper for this — the requirments are in source/requirements.md. Put it in src/solution.mjs.",
+  "setup": {
+    "projectName": "Behavior-Preserving Refactor Eval",
+    "about": "Self-contained eval project for refactor-module. Seeded inputs are under workspace/source or workspace/fixtures; final deliverable is workspace/src/solution.mjs.",
+    "missionObjectives": "Use the Behavior-Preserving Refactor craftbook/template, read the seeded local fixtures, and write src/solution.mjs without network calls, real credentials, or live services.",
+    "files": [
+      {
+        "path": "source/brief.md",
+        "content": "# Behavior-Preserving Refactor 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: refactor-module - Behavior-Preserving Refactor.\n"
+      },
+      {
+        "path": "source/requirements.md",
+        "content": "# Runner Requirements\n\nBuild a dependency-free Node ESM helper for Boreal Desk support operations. Export at least one function. Include a tiny self-test section using node:assert or an equivalent assertion helper. Use fixture values for 18 -> 6 hour response time and 14.2 -> 8.9 refund leakage.\n"
+      }
+    ],
+    "worker": {
+      "name": "Jules",
+      "role": "Developer"
+    },
+    "craftbookParams": {
+      "workPath": "tasks/eval"
+    }
+  },
+  "mocks": [],
+  "success": {
+    "summary": "src/solution.mjs is a local ESM module with basic self-test scaffolding.",
+    "deliverables": [
+      {
+        "path": "src/solution.mjs",
+        "kind": "code-with-tests",
+        "minBytes": 1500,
+        "checks": [
+          {
+            "kind": "esmImports",
+            "file": "src/solution.mjs"
+          },
+          {
+            "kind": "contains",
+            "file": "src/solution.mjs",
+            "pattern": "export\\s+(function|const|class)|export\\s*\\{",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "src/solution.mjs",
+            "pattern": "assert|test|describe|it|expect",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "src/solution.mjs",
+            "pattern": "18|6|14\\.2|8\\.9|Boreal",
+            "flags": "i"
+          }
+        ]
+      }
+    ]
+  },
+  "rubric": {
+    "artifact": {
+      "path": "src/solution.mjs",
+      "kind": "typescript"
+    },
+    "axes": [
+      {
+        "name": "correctness",
+        "description": "The module does what the requirements ask, with sensible edge handling."
+      },
+      {
+        "name": "verification",
+        "description": "Self-tests exercise real behavior, not trivial truths."
+      },
+      {
+        "name": "clarity",
+        "description": "Exports, naming, and structure make the module usable without reading every line."
+      },
+      {
+        "name": "robustness",
+        "description": "Invalid input and boundary cases fail loudly rather than silently."
+      }
+    ]
+  },
+  "qualityFocus": [
+    "runnable ESM",
+    "test scaffolding",
+    "local fixtures"
+  ]
+}