@bendyline/gilde 0.1.38 → 0.1.40

package/data/craftbook-templates/co/cover-letter/versions/1.0.2/test.json

@@ -0,0 +1,103 @@
+{
+  "schemaVersion": 1,
+  "title": "Tailored cover letter from role and resume notes",
+  "objective": "Measure whether the cover-letter craftbook maps role requirements to real candidate proof points before drafting a tailored letter.",
+  "tags": [
+    "html-page"
+  ],
+  "prompt": "In the `Cover Letter Eval` project, read `source/job.md` and `source/resume-notes.md`, then write `cover-letter.md` for Avery Chen applying to Operations Automation Manager at Harbor & Finch. The letter must be tailored, one page, cite three concrete proof points, map them to role requirements, include a company hook, and avoid generic filler.",
+  "setup": {
+    "projectName": "Cover Letter Eval",
+    "about": "Self-contained eval project for the cover-letter craftbook. Job and resume notes are under workspace/source.",
+    "missionObjectives": "Produce a tailored one-page cover letter mapping Avery Chen proof points to Harbor & Finch role requirements.",
+    "files": [
+      {
+        "path": "source/job.md",
+        "content": "# Role: Operations Automation Manager, Harbor & Finch\n\nRequirements: design workflow automations, partner with support and warehouse teams, report operational metrics, lead pilots without disrupting daily work. Company hook: Harbor & Finch is expanding a returns-desk automation pilot after measurable support improvements.\n"
+      },
+      {
+        "path": "source/resume-notes.md",
+        "content": "# Avery Chen Resume Notes\n\n- Led a two-warehouse barcode exception pilot that cut manual lookup time by 38%.\n- Built weekly exception exports for Finance using SQL and CSV automation.\n- Partnered with support leads to reduce duplicate status tickets by 22%.\n- Trained 34 warehouse associates on new intake workflows.\n"
+      }
+    ],
+    "worker": {
+      "name": "Eva",
+      "role": "Writer"
+    },
+    "craftbookParams": {
+      "workPath": "tasks/eval"
+    }
+  },
+  "mocks": [],
+  "success": {
+    "summary": "workspace/cover-letter.md is tailored to the seeded role and candidate evidence with company hook and concrete proof points.",
+    "deliverables": [
+      {
+        "path": "cover-letter.md",
+        "kind": "markdown-doc",
+        "minBytes": 1200,
+        "checks": [
+          {
+            "kind": "contains",
+            "file": "cover-letter.md",
+            "pattern": "Avery Chen|Harbor & Finch|Operations Automation Manager",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "cover-letter.md",
+            "pattern": "38%|22%|34",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "cover-letter.md",
+            "pattern": "barcode exception|weekly exception exports|duplicate status tickets",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "cover-letter.md",
+            "pattern": "support|warehouse|Finance|pilot",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "cover-letter.md",
+            "pattern": "returns-desk automation pilot|company hook|expanding",
+            "flags": "i"
+          }
+        ]
+      }
+    ]
+  },
+  "rubric": {
+    "artifact": {
+      "path": "cover-letter.md",
+      "kind": "markdown"
+    },
+    "axes": [
+      {
+        "name": "structure",
+        "description": "Layout and hierarchy fit the content; sections are scannable and coherent."
+      },
+      {
+        "name": "grounding",
+        "description": "Seeded source content is used faithfully — no invented facts or dropped requirements."
+      },
+      {
+        "name": "interactivity",
+        "description": "Controls and states the page claims to offer actually work."
+      },
+      {
+        "name": "polish",
+        "description": "Styling is intentional and responsive rather than unstyled or broken."
+      }
+    ]
+  },
+  "qualityFocus": [
+    "role-fit mapping",
+    "evidence-backed prose",
+    "tailored application letter"
+  ]
+}

package/data/craftbook-templates/cr/crm-update-batch/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "crm-update-batch",
   "role": "general",
+  "category": "business",
   "name": "Bulk CRM Update from Notes",
   "description": "Turn unstructured notes (call logs, meeting recaps, email threads) into a batch of structured CRM updates: per-contact field changes, activity logs, and next-step tasks as a validated import file. Scopes the CRM field schema and extraction rules FIRST (which objects/fields, allowed picklist values, the match-or-create key, required fields), then a developer extracts and maps every note into rows against that schema, then a reviewer validates the batch for schema-conformance and that no update mutates a field without evidence in the source. Scoping the schema before extraction is what makes the import load cleanly and prevents fabricated field values. Use for CRM data entry, bulk contact updates, importing notes into Salesforce/HubSpot, activity logging, and turning call notes into pipeline updates.",
   "tags": [

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

@@ -0,0 +1,113 @@
+{
+  "id": "crm-update-batch",
+  "name": "Bulk CRM Update from Notes",
+  "description": "Turn unstructured notes (call logs, meeting recaps, email threads) into a batch of structured CRM updates: per-contact field changes, activity logs, and next-step tasks as a validated import file. Scopes the CRM field schema and extraction rules FIRST (which objects/fields, allowed picklist values, the match-or-create key, required fields), then a developer extracts and maps every note into rows against that schema, then a reviewer validates the batch for schema-conformance and that no update mutates a field without evidence in the source. Scoping the schema before extraction is what makes the import load cleanly and prevents fabricated field values. Use for CRM data entry, bulk contact updates, importing notes into Salesforce/HubSpot, activity logging, and turning call notes into pipeline updates.\n\nSource discipline:\n- Extract only contacts, accounts, emails, statuses, tasks, activities, and source quotes present in the provided notes or locked schema.\n- Preserve the locked import header exactly. Do not split schema fields into extra columns such as first_name, last_name, title, old_value, or new_value; put the attribute name in `field_name` and its value in `field_value`.\n- Treat object names, field names, and picklist values as case-sensitive when the target CRM/import schema gives exact values.\n- For CSV imports, keep empty placeholders as adjacent commas so every row has the same number of cells as the header.\n- When the schema has many optional cells, draft row shapes against the header before extraction and verify the cell count on each output row.\n- When a contact lacks the match key, flag it as UNMATCHED instead of creating a placeholder email, guessed ID, or new account.\n- If the locked schema explicitly needs separate Contact, Account, Activity, or Task rows, split each seeded note into supported rows. Do not add optional object rows just to pad the batch.\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 schema (planner) — lock the CRM fields, picklists, match key, and rules → gated on artifact `{{workPath}}/scope.md` (markdown-notes)\n2. Build the batch (developer) — extract and map notes into schema-conformant rows → gated on `updates.csv` (data-file)\n\nThe gates never advance with an unmet criterion, and loop back to the\nowning phase to fix named gaps.\n",
+  "entryStepId": "scope",
+  "triggers": [
+    "update crm from notes",
+    "bulk crm update",
+    "import notes into salesforce",
+    "log activities to hubspot",
+    "turn call notes into crm records"
+  ],
+  "steps": [
+    {
+      "id": "scope",
+      "name": "Scope the schema",
+      "description": "lock the CRM fields, picklists, match key, and rules",
+      "prompt": "Define the import contract before extracting. (1) Identify the CRM objects to touch (Contact, Account, Opportunity, Activity) and the EXACT fields per object you will update, with their types. (2) Lock allowed values for any picklist/enum field (stage, status, lead source) — extractions must map to these, never free text. (3) Define the match-or-create key (e.g. match Contact by email; if absent, flag for review rather than create blindly). (4) List required fields per row and the output format (CSV with a header, or the CRM's import schema). (5) Lock the evidence rule: every field change must be justified by a quote from the source note. Write an acceptance-criteria checklist ('every row conforms to the field schema and types', 'picklist fields use only allowed values', 'each changed field cites a source quote', 'unmatched contacts flagged not silently created', 'required fields populated', 'file parses as valid CSV/import format') plus the schema + picklists to {{workPath}}/scope.md via write_task_note AND 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 batch",
+      "description": "extract and map notes into schema-conformant rows",
+      "prompt": "Produce updates.csv (or the locked import format) by mapping the notes to the schema. (1) Read each note and identify the contact/account it concerns; resolve via the match key, flagging UNMATCHED in a status column rather than fabricating an ID. (2) Extract field updates ONLY where the note gives evidence; normalize every picklist value to an allowed option from scope (drop, don't invent, if no clean mapping). (3) Emit an Activity/log row per note capturing the interaction (type, date, summary) and a next-step task row if the note implies one. (4) Add a source-quote column on each row pointing at the justifying text. (5) Ensure required fields are present and the file parses cleanly (proper header, consistent column count, quoting/escaping). Touch no field the notes don't support. On a loop-back fix only the flagged rows. Write the path and row counts (updates, activities, tasks, unmatched) to notes via write_task_note.",
+      "suggestedRole": "developer",
+      "advanceWhen": {
+        "file": "updates.csv",
+        "minBytes": 1,
+        "sniff": "nonempty"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "updates.csv",
+            "bytes": 120
+          },
+          {
+            "kind": "sniff",
+            "file": "updates.csv",
+            "sniff": "data-table"
+          }
+        ],
+        "onReject": "build",
+        "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 updates.csv against every locked criterion. (1) Parse the CSV — malformed structure, a missing header, or ragged rows (inconsistent column count) is an immediate FAIL. (2) Confirm every field value conforms to its type and that picklist columns contain only allowed values from {{workPath}}/scope.md. (3) Confirm required fields are populated on every row and that unmatched contacts are flagged in the status column, not given fabricated IDs. (4) Trace 4-5 field changes to their source-quote column — any change with no supporting quote is a FAIL for fabrication. (5) Confirm Activity/task rows exist where the notes implied them. Write PASS/FAIL per criterion with the specific offending rows.\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": "updates.csv"
+        }
+      ],
+      "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/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/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "cron-job",
   "role": "project-starter",
+  "category": "code-ops",
   "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.",
   "tags": [

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"
+}