@bendyline/gilde 0.1.38 → 0.1.39

package/data/craftbook-templates/da/data-join-merge/versions/1.0.2/test.json

@@ -0,0 +1,107 @@
+{
+  "schemaVersion": 1,
+  "title": "Join / Merge Two Datasets smoke eval",
+  "objective": "Self-contained smoke eval for the Join / Merge Two Datasets 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": "Join / Merge Two Datasets Eval",
+    "about": "Self-contained eval project for data-join-merge. Seeded inputs are under workspace/source or workspace/fixtures; final deliverable is workspace/analysis.md.",
+    "missionObjectives": "Use the Join / Merge Two Datasets 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": "# Join / Merge Two Datasets 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: data-join-merge - Join / Merge Two Datasets.\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/da/data-pipeline-etl/versions/1.0.3/craftbook.json

@@ -0,0 +1,160 @@
+{
+  "id": "data-pipeline-etl",
+  "name": "ETL / Ingest Pipeline",
+  "description": "Build an extract-transform-load pipeline that ingests source data, reshapes it to a target schema, and loads it with validation at every stage. Locks the schemas FIRST — source shape, target shape, the field-by-field transform/mapping, type coercions, and the data-quality rules — then implements extract→transform→load with row-level error capture, then a reviewer validates output conformance, row counts, and reject handling. Covers ETL stages, schema mapping, type coercion, data validation, idempotent loads, dead-letter/reject rows, and reconciliation counts.\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. Schema scope (planner) — lock source/target schemas, mapping, quality rules → gated on artifact `{{workPath}}/schema-scope.md` (markdown-notes)\n2. Build the pipeline (developer) — implement extract → transform → load → gated on `src/pipeline.js` (code-module)\n3. Validate the output (reviewer) — check conformance, counts, and reject handling → gated on artifact `{{workPath}}/validate.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": "schema-scope",
+  "triggers": [
+    "build an etl pipeline",
+    "ingest and transform data",
+    "data pipeline",
+    "load data into a target schema",
+    "etl job"
+  ],
+  "steps": [
+    {
+      "id": "schema-scope",
+      "name": "Schema scope",
+      "description": "lock source/target schemas, mapping, quality rules",
+      "prompt": "Lock the schemas and mapping before writing pipeline code. Step 1: Document the SOURCE schema — fields, types, and any messiness (nulls, formats, encodings). Step 2: Document the TARGET schema the data must conform to. Step 3: Write the field-by-field transform map: which source field(s) feed each target field, the coercion/cleaning applied (trim, parse date, cast number), and the default for missing values. Step 4: Define data-quality rules and reject criteria — which rows are invalid and what happens to them (drop, dead-letter, fail run). Step 5: Write a numbered acceptance-criteria checklist of 5-9 items (e.g. 'every loaded row conforms to the target schema', 'invalid rows go to the reject sink and are counted', 'input count = loaded + rejected', 're-running does not duplicate rows'). `write_task_note` the schemas + mapping + checklist and write the same to the produces path.\n\nThe deliverable `{{workPath}}/schema-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}}/schema-scope.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "{{workPath}}/schema-scope.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "{{workPath}}/schema-scope.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "schema-scope",
+        "maxAttempts": 3
+      },
+      "next": "build"
+    },
+    {
+      "id": "build",
+      "name": "Build the pipeline",
+      "description": "implement extract → transform → load",
+      "prompt": "Implement the pipeline as three clear stages in a runnable script. Step 1 (extract): read the source data into records. Step 2 (transform): apply the locked mapping field-by-field with the specified coercions and defaults; validate each row against the quality rules. Step 3 (load): write conforming rows to the target and route failing rows to the reject sink, keeping running counts (read / loaded / rejected). Step 4: make the load idempotent (upsert or skip-seen) so re-runs do not duplicate. Emit a reconciliation summary at the end. Use sample/in-memory sources and sinks 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/pipeline.js",
+        "minBytes": 1,
+        "sniff": "nonempty"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "src/pipeline.js",
+            "bytes": 200
+          },
+          {
+            "kind": "sniff",
+            "file": "src/pipeline.js",
+            "sniff": "nonempty"
+          },
+          {
+            "kind": "esmImports",
+            "file": "src/pipeline.js"
+          },
+          {
+            "kind": "sourceParses",
+            "file": "src/pipeline.js"
+          }
+        ],
+        "onReject": "build",
+        "maxAttempts": 3
+      },
+      "next": "validate"
+    },
+    {
+      "id": "validate",
+      "name": "Validate the output",
+      "description": "check conformance, counts, and reject handling",
+      "prompt": "Validate the pipeline's output against the schema and the quality rules. Step 1: Run the pipeline on representative input including deliberately bad rows. Step 2: Confirm every loaded row conforms to the target schema exactly (fields present, types correct). Step 3: Confirm the reconciliation holds: input count equals loaded plus rejected, and rejected rows are the ones that violate the rules. Step 4: Re-run and confirm no duplicate rows appear. Write a short validation note with the counts and any conformance gaps to the produces path.\n\nThe deliverable `{{workPath}}/validate.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}}/validate.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "src/pipeline.js",
+            "bytes": 200
+          },
+          {
+            "kind": "sniff",
+            "file": "src/pipeline.js",
+            "sniff": "nonempty"
+          },
+          {
+            "kind": "esmImports",
+            "file": "src/pipeline.js"
+          },
+          {
+            "kind": "sourceParses",
+            "file": "src/pipeline.js"
+          }
+        ],
+        "onReject": "validate",
+        "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 pipeline on input that includes valid and invalid rows. For EACH acceptance criterion: confirm every loaded row conforms to the target schema, confirm invalid rows are rejected and counted, confirm input = loaded + rejected, and confirm a re-run produces no duplicates. Write PASS/FAIL per criterion with the reconciliation counts.\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/pipeline.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.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/da/data-pipeline-etl/versions/1.0.3/test.json

@@ -0,0 +1,165 @@
+{
+  "schemaVersion": 1,
+  "title": "ETL / Ingest Pipeline smoke eval",
+  "objective": "Self-contained smoke eval for the ETL / Ingest Pipeline craftbook using the external generic harness.",
+  "tags": [
+    "external"
+  ],
+  "prompt": "Theres a fake ops service wired up for this so nothing real gets touched — the endpoints are in mocks/services.md, and the ready-made mock-probe script talks to them for you. Can you run the automation against it and write up how it went in automation.md?",
+  "setup": {
+    "projectName": "ETL / Ingest Pipeline Eval",
+    "about": "Self-contained eval project for data-pipeline-etl. Seeded inputs are under workspace/source or workspace/fixtures; final deliverable is workspace/automation.md.",
+    "missionObjectives": "Use the ETL / Ingest Pipeline craftbook/template, read the seeded local fixtures, and write automation.md without network calls, real credentials, or live services.",
+    "files": [
+      {
+        "path": "source/brief.md",
+        "content": "# ETL / Ingest Pipeline 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: data-pipeline-etl - ETL / Ingest Pipeline.\n"
+      }
+    ],
+    "worker": {
+      "name": "Jules",
+      "role": "Developer"
+    },
+    "craftbookParams": {
+      "workPath": "tasks/eval"
+    }
+  },
+  "mocks": [
+    {
+      "kind": "http",
+      "id": "ops",
+      "description": "Fake operations service for this eval. GET /api/bookings/open lists the open work items; POST /api/bookings/dry-run records a simulated submission and returns DRY_RUN_OK.",
+      "credential": {
+        "name": "mock.ops"
+      },
+      "routes": [
+        {
+          "method": "GET",
+          "path": "/api/bookings/open",
+          "body": {
+            "items": [
+              "BKG-1001",
+              "BKG-1002",
+              "BKG-1003"
+            ]
+          }
+        },
+        {
+          "method": "POST",
+          "path": "/api/bookings/dry-run",
+          "status": 201,
+          "body": {
+            "status": "DRY_RUN_OK",
+            "recorded": 3
+          }
+        }
+      ]
+    },
+    {
+      "kind": "webhook",
+      "id": "notify",
+      "description": "Notification receiver. POST a JSON completion notice here when the run finishes.",
+      "path": "/hooks/notify"
+    },
+    {
+      "kind": "cli",
+      "id": "probe",
+      "description": "Provenance-trusted project script `mock-probe` that exercises the fake ops service through http.authed and returns the raw responses.",
+      "shim": {
+        "path": "scripts/mock-probe.ts",
+        "content": "import { defineScript, gezel } from '@bendyline/gezel-sdk';\n\nexport const meta = defineScript({\n  name: 'mock-probe',\n  description:\n    'Probe the live fake ops service for this eval: lists the open work items and records a dry-run submission. Outputs the raw JSON responses as evidence for the write-up.',\n  inputs: {},\n  outputs: {\n    open: { type: 'string', description: 'Raw JSON body from the open-items listing.' },\n    dryRun: { type: 'string', description: 'Raw JSON body from the dry-run submission.' },\n  },\n  requires: ['workspace.read', 'network', 'credential:mock.ops'],\n});\n\nconst services = JSON.parse(await gezel.fs.read('mocks/services.json'));\nconst base = (id) => {\n  const service = services.find((entry) => entry.id === id);\n  if (!service) throw new Error(`mock service \"${id}\" is not listed in mocks/services.json`);\n  return service.baseUrl;\n};\n\nconst open = await gezel.http.authed(`${base('ops')}/api/bookings/open`, {\n  credential: 'mock.ops',\n});\nif (!open.ok) throw new Error(`open-items listing failed: ${open.status} ${open.body}`);\n\nconst dryRun = await gezel.http.authed(`${base('ops')}/api/bookings/dry-run`, {\n  credential: 'mock.ops',\n  method: 'POST',\n  body: JSON.stringify({ items: JSON.parse(open.body).items, mode: 'dry-run' }),\n});\nif (!dryRun.ok) throw new Error(`dry-run submission failed: ${dryRun.status} ${dryRun.body}`);\n\ngezel.output({ open: open.body, dryRun: dryRun.body });\n"
+      }
+    }
+  ],
+  "success": {
+    "summary": "automation.md is grounded in live fake-service responses: the open items were actually listed and a dry-run actually recorded (request-log assertions), with safety guards and signals described.",
+    "deliverables": [
+      {
+        "path": "automation.md",
+        "kind": "markdown-report",
+        "minBytes": 900,
+        "checks": [
+          {
+            "kind": "contains",
+            "file": "automation.md",
+            "pattern": "(?:^|\\n)#{1,3}\\s+\\S",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "automation.md",
+            "pattern": "DRY_RUN_OK|dry-run|dry run",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "automation.md",
+            "pattern": "fake-ci|fake-github|/api/bookings",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "automation.md",
+            "pattern": "no real|credentials|safety|guard",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "automation.md",
+            "pattern": "success|failure|retry|abort",
+            "flags": "i"
+          }
+        ]
+      }
+    ],
+    "mocks": [
+      {
+        "service": "ops",
+        "minRequests": 2,
+        "requiredPaths": [
+          "^/api/bookings/open$",
+          "^/api/bookings/dry-run$"
+        ]
+      }
+    ]
+  },
+  "rubric": {
+    "artifact": {
+      "path": "automation.md",
+      "kind": "markdown"
+    },
+    "axes": [
+      {
+        "name": "safety",
+        "description": "Dry-run posture is explicit: no real credentials, clear stop-before-side-effect boundary."
+      },
+      {
+        "name": "mapping",
+        "description": "Fake endpoints/commands are mapped completely to the workflow steps."
+      },
+      {
+        "name": "signals",
+        "description": "Success, failure, retry, and abort conditions are all defined."
+      },
+      {
+        "name": "containment",
+        "description": "The plan cannot accidentally reach a real service from a mock context."
+      }
+    ]
+  },
+  "qualityFocus": [
+    "dry-run safety",
+    "fake tool mapping",
+    "side-effect containment"
+  ],
+  "extensions": {
+    "legacySimulators": [
+      {
+        "id": "data-pipeline-etl-fake-service-fixture",
+        "kind": "data-source",
+        "status": "implemented",
+        "description": "Seeded local fake service contract replacing live CLIs, HTTP APIs, credentials, and side effects."
+      }
+    ]
+  }
+}

package/data/craftbook-templates/da/data-quality-audit/versions/1.0.2/craftbook.json

@@ -0,0 +1,153 @@
+{
+  "id": "data-quality-audit",
+  "name": "Data Quality Audit",
+  "description": "Audit a dataset against explicit data-quality rules and produce a scorecard of where it passes and fails across completeness, validity, consistency, uniqueness, and timeliness. Defines the quality rules and dimensions FIRST (so 'quality' is measurable, not a vibe), then runs the audit to measure each rule with pass rates and failing examples, then writes a prioritized report with an overall score and remediation steps. Use this for a data quality audit, data health check, validation report, data-quality scorecard, or assessing whether a dataset is trustworthy.\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. Define quality rules (data-analyst) — lock the dimensions, rules, and thresholds for 'good' → gated on artifact `{{workPath}}/rules.md` (markdown-notes)\n2. Run the audit (developer) — measure every rule and emit pass rates with failing examples → gated on `data/audit.json` (json)\n3. Report the audit (copywriter) — write a prioritized scorecard with remediation steps → gated on artifact `{{workPath}}/report.md` (markdown-report)\n\nThe gates never advance with an unmet criterion, and loop back to the\nowning phase to fix named gaps.\n",
+  "entryStepId": "rules",
+  "triggers": [
+    "audit data quality",
+    "data health check",
+    "is this data trustworthy",
+    "data quality scorecard",
+    "validate a dataset"
+  ],
+  "steps": [
+    {
+      "id": "rules",
+      "name": "Define quality rules",
+      "description": "lock the dimensions, rules, and thresholds for 'good'",
+      "prompt": "Make data quality measurable before auditing. Step 1: choose the quality dimensions in scope — completeness (no missing required fields), validity (values match type/format/domain), consistency (cross-field logic, e.g. end_date >= start_date), uniqueness (no dupes on the key), timeliness (recency), and accuracy/referential integrity where checkable. Step 2: write concrete, testable rules per dimension naming the exact columns ('email matches an email regex', 'status in {active,churned,trial}', 'no duplicate customer_id'). Step 3: set a pass-rate threshold per rule (e.g. >= 99% non-null) and a weighting for the overall score. Step 4: write an acceptance-criteria checklist ('every dimension has at least one testable rule', 'each rule names its columns and threshold', 'audit reports a pass rate + failing examples per rule', 'an overall weighted score is produced'). Call write_task_note and write the rules + thresholds + weights + checklist to {{workPath}}/rules.md. No auditing yet.\n\nThe deliverable `{{workPath}}/rules.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": "data-analyst",
+      "advanceWhen": {
+        "file": "{{workPath}}/rules.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "{{workPath}}/rules.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "{{workPath}}/rules.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "rules",
+        "maxAttempts": 3
+      },
+      "next": "audit"
+    },
+    {
+      "id": "audit",
+      "name": "Run the audit",
+      "description": "measure every rule and emit pass rates with failing examples",
+      "prompt": "Run every quality rule against the full dataset deterministically. Step 1: for each rule, evaluate all rows and compute the pass rate (rows passing / total) and the count of failures. Step 2: capture up to 5 concrete failing examples per rule (the row id + the offending value) so the report can show evidence. Step 3: compare each pass rate to its threshold and mark the rule pass/fail. Step 4: compute the overall weighted quality score from the rule results and the weights. Step 5: emit data/audit.json — per-rule { dimension, rule, pass_rate, threshold, status, failing_examples } plus the overall score and a per-dimension rollup. Call write_task_note with the overall score and the worst rules.",
+      "suggestedRole": "developer",
+      "advanceWhen": {
+        "file": "data/audit.json",
+        "minBytes": 1,
+        "sniff": "json-valid"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "data/audit.json",
+            "bytes": 2
+          }
+        ],
+        "scripts": [
+          {
+            "name": "checkJsonValid",
+            "scope": "standard",
+            "inputs": {
+              "file": "data/audit.json"
+            }
+          }
+        ],
+        "onReject": "audit",
+        "maxAttempts": 3
+      },
+      "next": "report"
+    },
+    {
+      "id": "report",
+      "name": "Report the audit",
+      "description": "write a prioritized scorecard with remediation steps",
+      "prompt": "Write the data-quality report from the audit results — use only measured numbers. Step 1: open with the overall score and a one-line verdict on trustworthiness. Step 2: show a scorecard table: dimension, rule, pass rate, threshold, pass/fail. Step 3: detail the failing rules worst-first, each with its pass rate and 1-2 failing examples as evidence. Step 4: give a prioritized remediation list (fix the highest-impact, lowest-effort failures first) with a concrete action per failing rule. Step 5: note any rule that couldn't be evaluated and why. Write the report to {{workPath}}/report.md and call write_task_note with the path and overall score. On a loop-back, fix only the named gaps.\n\nThe deliverable `{{workPath}}/report.md` lands in the project's artifacts drawer — write it with `write_artifact` and read it back with `read_artifact`; the shipped workspace stays untouched.",
+      "suggestedRole": "copywriter",
+      "advanceWhen": {
+        "file": "{{workPath}}/report.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "{{workPath}}/report.md",
+            "bytes": 1500,
+            "artifact": true
+          },
+          {
+            "kind": "contains",
+            "file": "{{workPath}}/report.md",
+            "pattern": "(?:^|\\n)#{1,3}\\s+\\S",
+            "flags": "i",
+            "label": "at least one markdown heading",
+            "artifact": true
+          }
+        ],
+        "onReject": "report",
+        "maxAttempts": 4
+      },
+      "next": "evaluate"
+    },
+    {
+      "id": "evaluate",
+      "name": "Evaluate",
+      "description": "Grade the deliverable against every acceptance criterion. All pass → finish; any fail → loop back and fix the gap.",
+      "prompt": "Read {{workPath}}/report.md and cross-check against {{workPath}}/rules.md and data/audit.json. Verify: every quality dimension has at least one testable rule; each rule reports a pass rate against its threshold with a pass/fail; failing rules show concrete failing examples as evidence; an overall weighted score is reported; and remediation steps are prioritized and concrete. Re-compute one rule's pass rate against the audit data to confirm. Confirm no rule is marked passing while its examples show failures. Write PASS/FAIL per criterion; any FAIL loops back to report.\n\nThe deliverable lives in the project's artifacts drawer — open `{{workPath}}/report.md` with `read_artifact`, not `read_file`.\n\nThen route — this is the whole point of the loop:\n\n- **Every criterion PASSES →** call `advance_task_step({ ref, stepId: \"evaluate\", next: \"finish\" })`.\n- **Any criterion FAILS →** write the specific gaps to notes, then call `advance_task_step({ ref, stepId: \"evaluate\", next: \"report\" })` 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": "{{workPath}}/report.md",
+          "artifact": true
+        }
+      ],
+      "next": "report"
+    },
+    {
+      "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"
+}