@bendyline/gilde 0.1.37 → 0.1.39

package/data/craftbook-templates/cr/crm-update-batch/versions/1.0.2/test.json

@@ -0,0 +1,210 @@
+{
+  "schemaVersion": 1,
+  "title": "CRM import CSV from call notes",
+  "objective": "Measure whether the crm-update-batch craftbook locks schema/picklists and maps every note into evidence-backed import rows.",
+  "tags": [
+    "data"
+  ],
+  "prompt": "In the `CRM Update Batch Eval` project, read `source/schema.md` and `source/call-notes.md`, then write `updates.csv`. The CSV must use the exact 10-column header from the schema, with exactly 10 cells in every row. Keep empty placeholders as adjacent commas; do not create extra columns such as first_name, last_name, title, old_value, or new_value. The CSV must include Contact rows plus Activity or Task rows with exact object_type values, allowed picklist values only, source_quote evidence on every field update, and UNMATCHED status instead of fabricated IDs. Use the account_name column for account context; do not create separate Account rows unless the seeded notes explicitly request an account field update. Do not add people, accounts, emails, issues, tasks, or source_quote text that are not in the seeded call notes. If you need more rows, split the seeded notes into supported Contact, Activity, and Task rows rather than inventing new contacts.",
+  "setup": {
+    "projectName": "CRM Update Batch Eval",
+    "about": "Self-contained eval project for crm-update-batch. Schema and call notes are seeded under workspace/source.",
+    "missionObjectives": "Produce a parseable CRM update CSV with schema-conformant rows, picklists, source quotes, activities/tasks, and unmatched-contact handling.",
+    "files": [
+      {
+        "path": "source/schema.md",
+        "content": "# CRM schema\n\nMatch Contact by email. Required columns, in this exact order: object_type,match_key,email,account_name,field_name,field_value,activity_type,next_task,status,source_quote.\n\nEvery data row must have exactly 10 cells. If a value is blank, keep the comma placeholder; do not add extra columns. Allowed object_type values are case-sensitive: Contact, Activity, Task. Allowed field_name values: status, activity_type, next_task. Allowed status values: Active, Renewal Risk, Expansion, UNMATCHED. Activity types: call, email, meeting. Do not create unlisted fields such as first_name, last_name, title, old_value, new_value, account_name update rows, or account ID.\n\nRow shapes, not data to copy:\n- Contact: Contact,<email-or-UNMATCHED>,<email-or-blank>,<account>,status,<status>,call,<task-or-blank>,<status>,\"<source words>\"\n- Activity: Activity,<email-or-UNMATCHED>,<email-or-blank>,<account>,activity_type,call,call,,<status>,\"<source words>\"\n- Task: Task,<email-or-UNMATCHED>,<email-or-blank>,<account>,next_task,<task text>,call,<task text>,<status>,\"<source words>\"\n"
+      },
+      {
+        "path": "source/call-notes.md",
+        "content": "# Call notes\n\n1. Priya Shah, priya@northstar.example, Northstar Studio: asked for West warehouse expansion pricing and said budget opens July 15. Status should become Expansion. Create next task: send pricing sheet Friday.\n2. Marcus Lee, marcus@acme.example, Acme Studio: complained about missed photo status emails and may delay renewal. Status should become Renewal Risk. Activity type call.\n3. Unknown caller from Harbor Design, no email captured: asked for a demo and should be flagged UNMATCHED rather than created blindly.\n"
+      }
+    ],
+    "worker": {
+      "name": "Niels",
+      "role": "Operations Analyst"
+    },
+    "craftbookParams": {
+      "workPath": "tasks/eval"
+    }
+  },
+  "mocks": [],
+  "success": {
+    "summary": "workspace/updates.csv has schema-conformant CRM rows with allowed statuses, source quotes, activity/task rows, and unmatched handling.",
+    "deliverables": [
+      {
+        "path": "updates.csv",
+        "kind": "generic-file",
+        "minBytes": 500,
+        "checks": [
+          {
+            "kind": "csvShape",
+            "file": "updates.csv",
+            "exactColumns": [
+              "object_type",
+              "match_key",
+              "email",
+              "account_name",
+              "field_name",
+              "field_value",
+              "activity_type",
+              "next_task",
+              "status",
+              "source_quote"
+            ],
+            "minRows": 4,
+            "allowedValues": {
+              "object_type": [
+                "Contact",
+                "Activity",
+                "Task"
+              ],
+              "match_key": [
+                "priya@northstar.example",
+                "marcus@acme.example",
+                "N/A",
+                "UNMATCHED"
+              ],
+              "email": [
+                "priya@northstar.example",
+                "marcus@acme.example"
+              ],
+              "account_name": [
+                "Northstar Studio",
+                "Acme Studio",
+                "Harbor Design"
+              ],
+              "field_name": [
+                "status",
+                "activity_type",
+                "next_task"
+              ],
+              "field_value": [
+                "Expansion",
+                "Renewal Risk",
+                "UNMATCHED",
+                "call",
+                "email",
+                "meeting",
+                "send pricing sheet Friday",
+                "demo"
+              ],
+              "activity_type": [
+                "call",
+                "email",
+                "meeting"
+              ],
+              "status": [
+                "Active",
+                "Renewal Risk",
+                "Expansion",
+                "UNMATCHED"
+              ]
+            }
+          },
+          {
+            "kind": "contains",
+            "file": "updates.csv",
+            "pattern": "object_type,match_key,email,account_name,field_name,field_value,activity_type,next_task,status,source_quote",
+            "flags": ""
+          },
+          {
+            "kind": "contains",
+            "file": "updates.csv",
+            "pattern": "priya@northstar\\.example|marcus@acme\\.example",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "updates.csv",
+            "pattern": "(?:^|\\n)(?:Activity|Task),",
+            "flags": "m",
+            "label": "include activity or task rows"
+          },
+          {
+            "kind": "contains",
+            "file": "updates.csv",
+            "pattern": "Expansion|Renewal Risk|UNMATCHED",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "updates.csv",
+            "pattern": "send pricing sheet",
+            "flags": "i",
+            "label": "include Priya pricing task"
+          },
+          {
+            "kind": "contains",
+            "file": "updates.csv",
+            "pattern": "missed photo status",
+            "flags": "i",
+            "label": "include Marcus renewal-risk note"
+          },
+          {
+            "kind": "contains",
+            "file": "updates.csv",
+            "pattern": "demo",
+            "flags": "i",
+            "label": "include unknown caller demo request"
+          },
+          {
+            "kind": "contains",
+            "file": "updates.csv",
+            "pattern": "Harbor Design[\\s\\S]{0,250}UNMATCHED|UNMATCHED[\\s\\S]{0,250}Harbor Design",
+            "flags": "i",
+            "label": "flag Harbor Design caller as UNMATCHED"
+          },
+          {
+            "kind": "contains",
+            "file": "updates.csv",
+            "pattern": "source_quote|asked for|complained",
+            "flags": "i"
+          },
+          {
+            "kind": "notContains",
+            "file": "updates.csv",
+            "pattern": "\\b(?!(?:priya@northstar|marcus@acme)\\.example\\b)[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\.example\\b|Stellar|Innovate|Acme Corp|Acme Solutions|NorthStar Inc\\.|Northstar Corp|Senior Manager|Director|Smith|first_name|last_name|title|old_value|new_value|premium package|billing issue|initial inquiry|website form|Upsell Opportunity|New Lead Qualification|CRM update requirements|Q3 review|Completed|Pending",
+            "flags": "i",
+            "label": "do not invent contacts, accounts, issues, tasks, or source quotes outside the seeded call notes"
+          },
+          {
+            "kind": "notContains",
+            "file": "updates.csv",
+            "pattern": "fake-id|unknown@example|Harbor Design,.*Active",
+            "flags": "i"
+          }
+        ]
+      }
+    ]
+  },
+  "rubric": {
+    "artifact": {
+      "path": "updates.csv",
+      "kind": "text"
+    },
+    "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": [
+    "schema lock",
+    "source-quote evidence",
+    "unmatched handling"
+  ]
+}

package/data/craftbook-templates/cr/cron-job/versions/1.0.2/craftbook.json

@@ -0,0 +1,159 @@
+{
+  "id": "cron-job",
+  "name": "Scheduled Batch Job",
+  "description": "Build a scheduled batch job that runs on a cadence, processes a unit of work, is safe to re-run, and reports its outcome. Scopes the job FIRST — trigger cadence, the work it does, batch/chunk size, idempotency, failure/partial-failure handling, and observable output — then implements the runnable job, then tests a clean run, an empty run, a partial-failure run, and re-run safety. Covers cron scheduling semantics, batch processing, idempotent reruns, chunking, structured logging, exit codes, and graceful partial-failure handling.\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 job (planner) — lock cadence, work unit, idempotency, failure handling → gated on artifact `{{workPath}}/scope.md` (markdown-notes)\n2. Build the job (developer) — implement the runnable batch job → gated on `src/job.js` (code-module)\n3. Write job tests (developer) — test clean, empty, partial-failure, and re-run → gated on `src/job.test.js` (code-with-tests)\n\nThe gates never advance with an unmet criterion, and loop back to the\nowning phase to fix named gaps.\n",
+  "entryStepId": "scope",
+  "triggers": [
+    "build a cron job",
+    "scheduled batch job",
+    "nightly job",
+    "recurring task script",
+    "batch processor"
+  ],
+  "steps": [
+    {
+      "id": "scope",
+      "name": "Scope the job",
+      "description": "lock cadence, work unit, idempotency, failure handling",
+      "prompt": "Scope the batch job before coding. Step 1: State the cadence (e.g. the cron expression) and what one run is responsible for. Step 2: Define the unit of work and how items are fetched and chunked (batch size, ordering). Step 3: Decide idempotency: how a re-run avoids double-processing already-done items, and what happens if a previous run died mid-batch. Step 4: Define failure handling: does one bad item abort the run or get skipped-and-logged, the exit code on full vs partial success, and what gets logged for observability. Step 5: Write a numbered acceptance-criteria checklist of 5-9 items (e.g. 'a clean run processes all items and exits 0', 'an empty input run is a no-op that exits 0', 'a re-run does not reprocess completed items', 'a bad item is logged and skipped without aborting the batch'). `write_task_note` the scope + checklist and write the same to the produces path.\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 job",
+      "description": "implement the runnable batch job",
+      "prompt": "Implement the job as a single runnable script with a clear entry point. Step 1: Fetch the work items and process them in chunks of the scoped batch size. Step 2: Make it idempotent — check a done-marker/store before processing each item so re-runs skip completed work. Step 3: Handle failures per the scope (skip-and-log vs abort) and emit structured log lines (start, per-batch progress, per-item errors, summary count). Step 4: Exit 0 on full success, a non-zero code on full failure, and the scoped code on partial. Use an in-memory store/sample data if none specified. On a loop-back, fix only the named gaps. `write_task_note` the file path and which criteria now pass.",
+      "suggestedRole": "developer",
+      "advanceWhen": {
+        "file": "src/job.js",
+        "minBytes": 1,
+        "sniff": "nonempty"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "src/job.js",
+            "bytes": 200
+          },
+          {
+            "kind": "sniff",
+            "file": "src/job.js",
+            "sniff": "nonempty"
+          },
+          {
+            "kind": "esmImports",
+            "file": "src/job.js"
+          },
+          {
+            "kind": "sourceParses",
+            "file": "src/job.js"
+          }
+        ],
+        "onReject": "build",
+        "maxAttempts": 3
+      },
+      "next": "test"
+    },
+    {
+      "id": "test",
+      "name": "Write job tests",
+      "description": "test clean, empty, partial-failure, and re-run",
+      "prompt": "Write tests that invoke the job's run function with controlled inputs. Step 1: Assert a clean run processes every item and exits 0 with a correct summary count. Step 2: Assert an empty-input run is a no-op exiting 0. Step 3: Inject one failing item and assert it is logged/skipped (or aborts) per the scope, with the right exit code. Step 4: Run twice over the same input and assert the second run skips already-done items. `write_task_note` the test file path and pass/fail count.",
+      "suggestedRole": "developer",
+      "advanceWhen": {
+        "file": "src/job.test.js",
+        "minBytes": 1,
+        "sniff": "nonempty"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "src/job.js",
+            "bytes": 200
+          },
+          {
+            "kind": "sniff",
+            "file": "src/job.js",
+            "sniff": "nonempty"
+          },
+          {
+            "kind": "esmImports",
+            "file": "src/job.js"
+          },
+          {
+            "kind": "sourceParses",
+            "file": "src/job.js"
+          }
+        ],
+        "onReject": "test",
+        "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 tests and execute the job. For EACH acceptance criterion: confirm a clean run processes all items and exits 0, confirm an empty run is a safe no-op, confirm a re-run does not reprocess completed items, confirm a bad item is handled per the scope, and confirm exit codes and log output match. Write PASS/FAIL 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: \"build\" })` to loop back. The builder fixes exactly those gaps.\n\nNever route to `finish` while any criterion is unmet. The build phase's completion gate already blocked a grossly-incomplete deliverable; your job is the judgment an automated check cannot make (does it actually work, read well, look right). After ~3 unproductive loops, stop and report DONE_WITH_CONCERNS so the user can step in.",
+      "suggestedRole": "reviewer",
+      "consumes": [
+        {
+          "file": "src/job.js"
+        }
+      ],
+      "next": "build"
+    },
+    {
+      "id": "finish",
+      "name": "Finish",
+      "description": "All acceptance criteria met. Stamp a short summary and report DONE.",
+      "prompt": "Every acceptance criterion passed. Write a one-paragraph DONE summary to task notes via `write_task_note`: what was built, the deliverable path(s), and a one-line confirmation that each criterion is met. Then report DONE.",
+      "suggestedRole": "developer",
+      "terminal": true
+    }
+  ],
+  "version": "1.0.2",
+  "releasedAt": "2026-08-21T00:00:00Z",
+  "paramSchema": {
+    "type": "object",
+    "properties": {
+      "workPath": {
+        "type": "string",
+        "title": "Working folder",
+        "description": "Per-task working folder in the artifacts drawer. Defaults to this task's own folder so runs never collide; override with a stable name when you deliberately want runs to share files.",
+        "default": "{{task.dir}}"
+      }
+    }
+  },
+  "minGezelVersion": "1.26233"
+}

package/data/craftbook-templates/cr/cron-job/versions/1.0.2/test.json

@@ -0,0 +1,107 @@
+{
+  "schemaVersion": 1,
+  "title": "Scheduled Batch Job smoke eval",
+  "objective": "Self-contained smoke eval for the Scheduled Batch Job 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": "Scheduled Batch Job Eval",
+    "about": "Self-contained eval project for cron-job. Seeded inputs are under workspace/source or workspace/fixtures; final deliverable is workspace/analysis.md.",
+    "missionObjectives": "Use the Scheduled Batch Job 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": "# Scheduled Batch Job 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: cron-job - Scheduled Batch Job.\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/cr/crossword-forge/versions/1.0.2/craftbook.json

@@ -0,0 +1,176 @@
+{
+  "id": "crossword-forge",
+  "name": "Forge a Crossword",
+  "description": "Construct a personalized crossword and prove it works before anyone's pencil touches it: the grid actually interlocks, every entry sits in the grid exactly where its number says, every clue is tuned to the solver — and the whole thing ships as a printable page with the solution kept decently out of sight. Locks the theme and the word list FIRST, then constructs the mechanically-verified grid, then renders the printable puzzle. Use for making a crossword, a personalized puzzle for the family, 'a crossword with the grandkids' names in it', and printable puzzle gifts.\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 puzzle (puzzle-maker) — theme and word list from the personal material, construction rules → gated on artifact `{{workPath}}/scope.md` (markdown-notes)\n2. Construct the grid (developer) — verified puzzle data — grid, entries, clues → gated on `puzzle.json` (json)\n3. Render the printable page (developer) — printable grid and clues, solution out of sight, shelf copy filed → gated on `puzzle.html` (html-page)\n\nThe gates never advance with an unmet criterion, and loop back to the\nowning phase to fix named gaps.\n",
+  "entryStepId": "scope",
+  "triggers": [
+    "make a crossword",
+    "crossword for the family",
+    "personalized crossword puzzle",
+    "forge a crossword",
+    "printable crossword"
+  ],
+  "steps": [
+    {
+      "id": "scope",
+      "name": "Scope the puzzle",
+      "description": "theme and word list from the personal material, construction rules",
+      "prompt": "Set the build before placing a letter. Step 1: gather the personal material — the task's params (theme, names, size) and any notes in the workspace about the solvers: names, places, pets, running jokes. Step 2: draft the word list — the personal entries first, filler words only where the grid needs them to interlock, everything spellable in plain uppercase letters. Step 3: lock the construction rules — grid size from the size param (small about 9x9, medium about 13x13, large about 15x15), every entry placed in the grid and crossing at least one other entry, no entry without a clue, clue difficulty tuned to the solvers. Step 4: write an acceptance-criteria checklist ('every entry reads out of the grid at its stated coordinates', 'every crossing agrees letter for letter', 'every entry has a clue at the target difficulty', 'the personal words made it into the grid', 'the rendered page prints cleanly with the solution out of casual sight'). Call write_task_note with the theme + word count + checklist and write {{workPath}}/scope.md.\n\nThe deliverable `{{workPath}}/scope.md` lands in the project's artifacts drawer — write it with `write_artifact` and read it back with `read_artifact`; the shipped workspace stays untouched.",
+      "suggestedRole": "puzzle-maker",
+      "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": "construct"
+    },
+    {
+      "id": "construct",
+      "name": "Construct the grid",
+      "description": "verified puzzle data — grid, entries, clues",
+      "prompt": "Construct the puzzle as data at puzzle.json. Step 1: build the grid — uppercase letters in filled cells, '.' for blocks — placing every word from the locked list so the entries interlock. Step 2: write it as JSON with this exact shape: { \"title\": ..., \"size\": { \"rows\": N, \"cols\": N }, \"grid\": [ one string per row ], \"entries\": [ { \"number\", \"answer\", \"row\", \"col\", \"direction\": \"across\" or \"down\", \"clue\" } ] } — rows and columns zero-indexed from the top-left. Step 3: verify your own work cell by cell before completing — every answer must read out of the grid exactly at its coordinates and every crossing letter must agree; the gate re-checks this mechanically and names any entry that lies. Step 4: write the clues into the entries — personal entries clued with the in-jokes, fillers clued honestly at the target difficulty. Call write_task_note with the grid size and the entry count.",
+      "suggestedRole": "developer",
+      "advanceWhen": {
+        "file": "puzzle.json",
+        "minBytes": 1,
+        "sniff": "json-valid"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "puzzle.json",
+            "bytes": 400
+          }
+        ],
+        "scripts": [
+          {
+            "name": "checkJsonValid",
+            "scope": "standard",
+            "inputs": {
+              "file": "puzzle.json"
+            }
+          }
+        ],
+        "onReject": "construct",
+        "maxAttempts": 3
+      },
+      "next": "render"
+    },
+    {
+      "id": "render",
+      "name": "Render the printable page",
+      "description": "printable grid and clues, solution out of sight, shelf copy filed",
+      "prompt": "Render the playable, printable page at puzzle.html. Step 1: draw the empty numbered grid from puzzle.json — blocks and cell numbers exactly as the data has them — beside the across and down clue lists. Step 2: make it print-ready — an @page rule, print styles, the grid sized so a pencil fits in the squares. Step 3: keep the solution out of casual sight — behind a toggle on screen and on its own page in print, never beside the blank grid. Step 4: any script on the page must actually run — check it before completing. Step 5: file a dated copy of puzzle.json and puzzle.html into the puzzles/ shelf named for the theme, so the pack-layout ritual can find them later. Call write_task_note with the page path and the shelf copies.",
+      "suggestedRole": "developer",
+      "consumes": [
+        {
+          "file": "puzzle.json"
+        }
+      ],
+      "advanceWhen": {
+        "file": "puzzle.html",
+        "minBytes": 1,
+        "sniff": "html-complete"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "puzzle.html",
+            "bytes": 800
+          },
+          {
+            "kind": "htmlLint",
+            "file": "puzzle.html"
+          },
+          {
+            "kind": "cssMinBytes",
+            "bytes": 650,
+            "file": "puzzle.html"
+          },
+          {
+            "kind": "contains",
+            "file": "puzzle.html",
+            "pattern": "@page|@media\\s+print",
+            "flags": "i",
+            "label": "print CSS"
+          },
+          {
+            "kind": "jsParses",
+            "file": "puzzle.html"
+          }
+        ],
+        "scripts": [
+          {
+            "name": "checkHtmlComplete",
+            "scope": "standard",
+            "inputs": {
+              "file": "puzzle.html"
+            }
+          }
+        ],
+        "onReject": "render",
+        "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 puzzle.json and puzzle.html and verify every criterion from {{workPath}}/scope.md: read three entries out of the grid by their coordinates and confirm each matches its answer, check one crossing square agrees in both directions, confirm every entry has a clue and the personal words from the scope made it in, and check the rendered page — the grid matches the data, the clue numbers line up, and the solution stays out of sight on screen and in print. Write PASS/FAIL per criterion; on any failure, name the entry or cell and loop back to construct.\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: \"construct\" })` 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": "puzzle.html"
+        }
+      ],
+      "next": "construct"
+    },
+    {
+      "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"
+}