@bendyline/gilde 0.1.38 → 0.1.40

package/data/craftbook-templates/cs/csv-transformer/versions/1.2.3/test.json

@@ -0,0 +1,105 @@
+{
+  "schemaVersion": 1,
+  "title": "Fixture-backed CSV normalization",
+  "objective": "Measure whether the csv-transformer craftbook locks a schema mapping and produces a transformed CSV from seeded source data.",
+  "tags": [
+    "html-page"
+  ],
+  "prompt": "In the `CSV Transformer Eval` project, read `data/source.csv` and write `data/output.csv`. Normalize to columns customer_id,full_name,total_cents,status. Trim whitespace, title-case names, convert dollar totals to integer cents, lowercase status, and de-duplicate by email keeping the latest row by updated_at. Keep the output sorted by customer_id.",
+  "setup": {
+    "projectName": "CSV Transformer Eval",
+    "about": "Self-contained eval project for csv-transformer. Source data is in workspace/data/source.csv and the deliverable is workspace/data/output.csv.",
+    "missionObjectives": "Transform the seeded messy CSV into a clean, sorted output CSV with normalized fields and duplicate handling.",
+    "files": [
+      {
+        "path": "data/source.csv",
+        "content": "customer_id,email,first,last,total_usd,status,updated_at\nC-001,ada@example.com, ada ,lane,12.99, ACTIVE ,2026-02-02\nC-002,bo@example.com,bo,ng,7.50,pending,2026-02-03\nC-001,ada@example.com,Ada,Lane,14.25,active,2026-02-05\nC-003,noor@example.com,noor,shah,25.00,Paused,2026-02-04\n"
+      }
+    ],
+    "worker": {
+      "name": "Nora",
+      "role": "Data Analyst"
+    },
+    "craftbookParams": {
+      "workPath": "tasks/eval"
+    }
+  },
+  "mocks": [],
+  "success": {
+    "summary": "data/output.csv has the expected normalized schema, deduped rows, integer cents, and lowercased statuses.",
+    "deliverables": [
+      {
+        "path": "data/output.csv",
+        "kind": "data-file",
+        "minBytes": 110,
+        "checks": [
+          {
+            "kind": "csvShape",
+            "file": "data/output.csv",
+            "exactColumns": [
+              "customer_id",
+              "full_name",
+              "total_cents",
+              "status"
+            ],
+            "minRows": 3,
+            "consistentColumns": true
+          },
+          {
+            "kind": "contains",
+            "file": "data/output.csv",
+            "pattern": "C-001,\"?Ada Lane\"?,1425,active",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "data/output.csv",
+            "pattern": "C-002,\"?Bo Ng\"?,750,pending",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "data/output.csv",
+            "pattern": "C-003,\"?Noor Shah\"?,2500,paused",
+            "flags": "i"
+          },
+          {
+            "kind": "notContains",
+            "file": "data/output.csv",
+            "pattern": "12\\.99|14\\.25|25\\.00",
+            "flags": "i"
+          }
+        ]
+      }
+    ]
+  },
+  "rubric": {
+    "artifact": {
+      "path": "data/output.csv",
+      "kind": "text"
+    },
+    "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": [
+    "schema mapping",
+    "dedupe rule",
+    "numeric normalization"
+  ]
+}

package/data/craftbook-templates/da/dashboard-spec/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "dashboard-spec",
   "role": "general",
+  "category": "code-docs",
   "name": "Dashboard Specification",
   "description": "Specify a dashboard from the questions it must answer, before anyone builds it — the artifact that prevents a chart-salad dashboard nobody uses. Scopes the audience, the decisions, and the questions FIRST, then designs the dashboard layout: which widgets/charts answer which question, their metric definitions, filters, refresh, and visual hierarchy. The output is a build-ready spec, not the dashboard itself. Use this for planning a dashboard, a BI/reporting spec, a metrics dashboard design, deciding what charts a dashboard needs, or a dashboard requirements doc.",
   "tags": [

package/data/craftbook-templates/da/dashboard-spec/versions/1.0.2/craftbook.json

@@ -0,0 +1,119 @@
+{
+  "id": "dashboard-spec",
+  "name": "Dashboard Specification",
+  "description": "Specify a dashboard from the questions it must answer, before anyone builds it — the artifact that prevents a chart-salad dashboard nobody uses. Scopes the audience, the decisions, and the questions FIRST, then designs the dashboard layout: which widgets/charts answer which question, their metric definitions, filters, refresh, and visual hierarchy. The output is a build-ready spec, not the dashboard itself. Use this for planning a dashboard, a BI/reporting spec, a metrics dashboard design, deciding what charts a dashboard needs, or a dashboard requirements doc.\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 questions (planner) — lock the audience, decisions, and questions the dashboard answers → gated on artifact `{{workPath}}/question-scope.md` (markdown-notes)\n2. Design the dashboard (designer) — produce a build-ready layout: widgets, metrics, filters, hierarchy → gated on `dashboard-spec.md` (markdown-doc)\n\nThe gates never advance with an unmet criterion, and loop back to the\nowning phase to fix named gaps.\n",
+  "entryStepId": "question-scope",
+  "triggers": [
+    "spec a dashboard",
+    "plan a metrics dashboard",
+    "dashboard requirements",
+    "what charts should my dashboard have",
+    "bi dashboard design"
+  ],
+  "steps": [
+    {
+      "id": "question-scope",
+      "name": "Scope the questions",
+      "description": "lock the audience, decisions, and questions the dashboard answers",
+      "prompt": "Establish why the dashboard exists before designing widgets. Step 1: name the primary audience and the recurring decisions they make. Step 2: list the 5-10 specific questions the dashboard must answer for those decisions, ordered by importance. Step 3: for each question, name the metric(s) that answer it and define each metric precisely (numerator/denominator, time window). Step 4: identify the filters/segments users need (date range, team, region) and the refresh cadence. Step 5: write an acceptance-criteria checklist ('every widget traces to a listed question', 'each metric has a precise definition', 'top question is most prominent', 'required filters are listed', 'no orphan chart that answers no question'). Call write_task_note and write the audience + questions + metric definitions + checklist to {{workPath}}/question-scope.md.\n\nThe deliverable `{{workPath}}/question-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}}/question-scope.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "{{workPath}}/question-scope.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "{{workPath}}/question-scope.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "question-scope",
+        "maxAttempts": 3
+      },
+      "next": "design"
+    },
+    {
+      "id": "design",
+      "name": "Design the dashboard",
+      "description": "produce a build-ready layout: widgets, metrics, filters, hierarchy",
+      "prompt": "Design the dashboard as a build-ready specification (a spec, not the live dashboard). Step 1: choose the widget per question — KPI tile for a single headline number, line for trend, bar for comparison, table for detail — and justify each choice. Step 2: lay out the screen in priority order: a top KPI strip for the headline numbers, then trend and breakdown sections; describe the grid/wireframe in markdown. Step 3: for each widget specify title, chart type, the exact metric + its definition, dimensions/filters it responds to, and the data source/field. Step 4: specify global filters, default date range, and refresh cadence. Step 5: confirm every widget maps to a scoped question and there are no orphans. Write the full spec to dashboard-spec.md and call write_task_note with the widget count. On a loop-back, fix only the named gaps.",
+      "suggestedRole": "designer",
+      "advanceWhen": {
+        "file": "dashboard-spec.md",
+        "minBytes": 1,
+        "sniff": "nonempty"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "dashboard-spec.md",
+            "bytes": 500
+          }
+        ],
+        "scripts": [
+          {
+            "name": "checkContains",
+            "scope": "standard",
+            "inputs": {
+              "file": "dashboard-spec.md",
+              "pattern": "(?:^|\\n)#{1,3}\\s+\\S",
+              "flags": "i"
+            }
+          }
+        ],
+        "onReject": "design",
+        "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 dashboard-spec.md and check it against {{workPath}}/question-scope.md. Verify: every widget traces explicitly to a listed question (and no orphan widget answers nothing); each widget names a chart type with a justification; each metric has a precise definition (numerator/denominator/window); the layout puts the top question most prominently; and required global filters, default date range, and refresh cadence are specified. Confirm a developer could build it without re-asking what a metric means. Write PASS/FAIL per criterion; any FAIL loops back to design.\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: \"design\" })` 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": "dashboard-spec.md"
+        }
+      ],
+      "next": "design"
+    },
+    {
+      "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/da/dashboard-spec/versions/1.0.2/test.json

@@ -0,0 +1,117 @@
+{
+  "schemaVersion": 1,
+  "title": "Build-ready dashboard requirements spec",
+  "objective": "Measure whether the dashboard-spec craftbook scopes audience decisions and writes a build-ready metrics/dashboard spec instead of designing chart salad.",
+  "tags": [
+    "html-page"
+  ],
+  "prompt": "In the `Dashboard Spec Eval` project, read `source/dashboard-brief.md` and write `dashboard-spec.md` for a support operations dashboard. It must define audience, decisions, five questions, widgets/charts, metric definitions, filters, refresh cadence, visual hierarchy, and acceptance criteria. Do not build the dashboard.",
+  "setup": {
+    "projectName": "Dashboard Spec Eval",
+    "about": "Self-contained eval project for the dashboard-spec craftbook. Requirements are in workspace/source/dashboard-brief.md.",
+    "missionObjectives": "Produce a build-ready dashboard specification with audience, decisions, questions, widgets, metric definitions, filters, refresh cadence, hierarchy, and acceptance criteria.",
+    "files": [
+      {
+        "path": "source/dashboard-brief.md",
+        "content": "# Support Operations Dashboard Brief\n\nAudience: support director and queue leads.\nDecisions: staffing for Monday backlog, escalation coaching, and carrier status messaging.\nSignals available: ticket volume by queue, first response time, reopen rate, SLA breaches, carrier scan delay count, premium subscriber duplicate tickets, agent capacity, and weekly exception export status.\nRefresh: hourly during business hours, daily summary at 17:00.\nFilters: queue, region, carrier, customer segment, agent team, date range.\n"
+      }
+    ],
+    "worker": {
+      "name": "Lotte",
+      "role": "Planner"
+    },
+    "craftbookParams": {
+      "workPath": "tasks/eval"
+    }
+  },
+  "mocks": [],
+  "success": {
+    "summary": "workspace/dashboard-spec.md is a build-ready spec with audience, decisions, questions, widgets, metric definitions, filters, cadence, and hierarchy.",
+    "deliverables": [
+      {
+        "path": "dashboard-spec.md",
+        "kind": "markdown-report",
+        "minBytes": 2200,
+        "checks": [
+          {
+            "kind": "contains",
+            "file": "dashboard-spec.md",
+            "pattern": "Audience|support director|queue leads",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "dashboard-spec.md",
+            "pattern": "Decisions|staffing|escalation|carrier",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "dashboard-spec.md",
+            "pattern": "Questions|question",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "dashboard-spec.md",
+            "pattern": "Widget|chart|table|KPI",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "dashboard-spec.md",
+            "pattern": "metric definition|formula|SLA|reopen",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "dashboard-spec.md",
+            "pattern": "filter|queue|region|carrier|date range",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "dashboard-spec.md",
+            "pattern": "hourly|17:00|refresh",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "dashboard-spec.md",
+            "pattern": "acceptance criteria|hierarchy",
+            "flags": "i"
+          }
+        ]
+      }
+    ]
+  },
+  "rubric": {
+    "artifact": {
+      "path": "dashboard-spec.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": [
+    "question-first scope",
+    "metric definitions",
+    "build-ready spec"
+  ]
+}

package/data/craftbook-templates/da/data-dictionary/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "data-dictionary",
   "role": "general",
+  "category": "code-data",
   "name": "Data Dictionary",
   "description": "Document a dataset's schema as a clear, complete data dictionary so others can use it without guessing. Inspects the data FIRST to derive each column's real type, value domain, null rate, units, and relationships from the actual values (not assumptions), then writes a readable dictionary with one entry per column plus dataset-level context. Use this for documenting a schema, building a data dictionary, a column glossary, a table reference, or onboarding docs for a dataset.",
   "tags": [

package/data/craftbook-templates/da/data-dictionary/versions/1.0.2/craftbook.json

@@ -0,0 +1,119 @@
+{
+  "id": "data-dictionary",
+  "name": "Data Dictionary",
+  "description": "Document a dataset's schema as a clear, complete data dictionary so others can use it without guessing. Inspects the data FIRST to derive each column's real type, value domain, null rate, units, and relationships from the actual values (not assumptions), then writes a readable dictionary with one entry per column plus dataset-level context. Use this for documenting a schema, building a data dictionary, a column glossary, a table reference, or onboarding docs for a dataset.\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. Inspect the schema (data-analyst) — derive each column's real type, domain, and relationships from values → gated on artifact `{{workPath}}/inspect.md` (markdown-notes)\n2. Write the dictionary (copywriter) — produce a readable per-column dictionary with dataset context → gated on `data-dictionary.md` (markdown-doc)\n\nThe gates never advance with an unmet criterion, and loop back to the\nowning phase to fix named gaps.\n",
+  "entryStepId": "inspect",
+  "triggers": [
+    "document a dataset",
+    "build a data dictionary",
+    "describe the columns",
+    "schema documentation",
+    "column glossary"
+  ],
+  "steps": [
+    {
+      "id": "inspect",
+      "name": "Inspect the schema",
+      "description": "derive each column's real type, domain, and relationships from values",
+      "prompt": "Profile the dataset to learn each column's TRUE characteristics from the data itself. Step 1: list every column. Step 2: for each, derive the data type, the value domain (range for numerics, the enumerated set for low-cardinality categoricals, format/pattern for strings like dates or IDs), the null/blank rate, the unit of measure, and an example value. Step 3: infer the likely meaning of each column and flag any whose name is ambiguous. Step 4: identify keys (unique columns), likely foreign keys, and any computed/derived columns. Step 5: write an acceptance-criteria checklist ('one entry per column', 'each entry has type + description + example', 'enumerated columns list their allowed values', 'keys and relationships are documented', 'units are stated where relevant'). Call write_task_note and write the per-column profile + checklist to {{workPath}}/inspect.md.\n\nThe deliverable `{{workPath}}/inspect.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}}/inspect.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "{{workPath}}/inspect.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "{{workPath}}/inspect.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "inspect",
+        "maxAttempts": 3
+      },
+      "next": "write"
+    },
+    {
+      "id": "write",
+      "name": "Write the dictionary",
+      "description": "produce a readable per-column dictionary with dataset context",
+      "prompt": "Write the data dictionary from the inspection profile — only describe what the data actually shows. Step 1: open with a dataset overview: what it is, the grain (one row = ?), the source, and the row/column counts. Step 2: produce a Markdown table with one row per column: Column, Type, Description, Allowed values / range, Nullable, Unit, Example. Step 3: write plain-English descriptions a newcomer understands; expand ambiguous names. Step 4: add a short 'Keys & relationships' section and a 'Notes / caveats' section (quirks, deprecated columns, derived fields). Step 5: ensure every column from the inspection appears. Write the dictionary to data-dictionary.md and call write_task_note with the path and column count. On a loop-back, fix only the named gaps.",
+      "suggestedRole": "copywriter",
+      "advanceWhen": {
+        "file": "data-dictionary.md",
+        "minBytes": 1,
+        "sniff": "nonempty"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "data-dictionary.md",
+            "bytes": 500
+          }
+        ],
+        "scripts": [
+          {
+            "name": "checkContains",
+            "scope": "standard",
+            "inputs": {
+              "file": "data-dictionary.md",
+              "pattern": "(?:^|\\n)#{1,3}\\s+\\S",
+              "flags": "i"
+            }
+          }
+        ],
+        "onReject": "write",
+        "maxAttempts": 4
+      },
+      "next": "evaluate"
+    },
+    {
+      "id": "evaluate",
+      "name": "Evaluate",
+      "description": "Grade the deliverable against every acceptance criterion. All pass → finish; any fail → loop back and fix the gap.",
+      "prompt": "Read data-dictionary.md and cross-check it against {{workPath}}/inspect.md and the dataset. Verify: there is exactly one entry per column (count them against the data); each entry has a type, a plain description, and an example; enumerated columns list their allowed values; nullability and units are stated where relevant; and keys/relationships are documented. Spot-check 3 columns' types and value domains against the actual data. Write PASS/FAIL per criterion; any FAIL loops back to write.\n\nThen route — this is the whole point of the loop:\n\n- **Every criterion PASSES →** call `advance_task_step({ ref, stepId: \"evaluate\", next: \"finish\" })`.\n- **Any criterion FAILS →** write the specific gaps to notes, then call `advance_task_step({ ref, stepId: \"evaluate\", next: \"write\" })` to loop back. The builder fixes exactly those gaps.\n\nNever route to `finish` while any criterion is unmet. The build phase's completion gate already blocked a grossly-incomplete deliverable; your job is the judgment an automated check cannot make (does it actually work, read well, look right). After ~3 unproductive loops, stop and report DONE_WITH_CONCERNS so the user can step in.",
+      "suggestedRole": "reviewer",
+      "consumes": [
+        {
+          "file": "data-dictionary.md"
+        }
+      ],
+      "next": "write"
+    },
+    {
+      "id": "finish",
+      "name": "Finish",
+      "description": "All acceptance criteria met. Stamp a short summary and report DONE.",
+      "prompt": "Every acceptance criterion passed. Write a one-paragraph DONE summary to task notes via `write_task_note`: what was built, the deliverable path(s), and a one-line confirmation that each criterion is met. Then report DONE.",
+      "suggestedRole": "developer",
+      "terminal": true
+    }
+  ],
+  "version": "1.0.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/da/data-dictionary/versions/1.0.2/test.json

@@ -0,0 +1,104 @@
+{
+  "schemaVersion": 1,
+  "title": "Dataset schema dictionary from CSV",
+  "objective": "Measure whether the data-dictionary craftbook inspects a seeded CSV and writes per-column definitions, types, null/domain notes, and dataset context.",
+  "tags": [
+    "data"
+  ],
+  "prompt": "In the `Data Dictionary Eval` project, inspect `data/orders.csv` and write `data-dictionary.md`. Include dataset context plus one entry per column: order_id, channel, region, discount_code, net_revenue, shipped_at, returned. For each column provide type, meaning, example values, allowed/domain notes, and null/blank behavior. Ground domain notes only in column names and observed CSV values; do not invent business rules, currencies, fees, fulfillment lifecycle, customer-interaction details, or systems not present in the CSV.",
+  "setup": {
+    "projectName": "Data Dictionary Eval",
+    "about": "Self-contained eval project for the data-dictionary craftbook. The dataset is workspace/data/orders.csv.",
+    "missionObjectives": "Inspect the CSV values and document every column with type, meaning, examples, domain/null notes, and dataset context. Use only observed values and column names for domain notes; avoid invented business rules, currencies, fees, fulfillment lifecycle, or customer-interaction details.",
+    "files": [
+      {
+        "path": "data/orders.csv",
+        "content": "order_id,channel,region,discount_code,net_revenue,shipped_at,returned\nO-1001,web,West,WELCOME10,84.50,2026-05-01,false\nO-1002,marketplace,East,,142.00,2026-05-02,true\nO-1003,web,North,SPRING15,57.25,2026-05-03,false\nO-1004,retail,West,,233.10,2026-05-05,false\nO-1005,marketplace,South,SPRING15,19.99,2026-05-07,true\n"
+      }
+    ],
+    "worker": {
+      "name": "Iris",
+      "role": "Data Analyst"
+    },
+    "craftbookParams": {
+      "workPath": "tasks/eval"
+    }
+  },
+  "mocks": [],
+  "success": {
+    "summary": "workspace/data-dictionary.md documents every seeded column with type, meaning, examples, and null/domain behavior.",
+    "deliverables": [
+      {
+        "path": "data-dictionary.md",
+        "kind": "markdown-doc",
+        "minBytes": 1800,
+        "checks": [
+          {
+            "kind": "contains",
+            "file": "data-dictionary.md",
+            "pattern": "order_id|channel|region|discount_code|net_revenue|shipped_at|returned"
+          },
+          {
+            "kind": "contains",
+            "file": "data-dictionary.md",
+            "pattern": "type|meaning|example|domain|null|blank",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "data-dictionary.md",
+            "pattern": "web|marketplace|retail"
+          },
+          {
+            "kind": "contains",
+            "file": "data-dictionary.md",
+            "pattern": "WELCOME10|SPRING15|blank|empty",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "data-dictionary.md",
+            "pattern": "84\\.50|233\\.10|boolean|true|false",
+            "flags": "i"
+          },
+          {
+            "kind": "notContains",
+            "file": "data-dictionary.md",
+            "pattern": "tax(?:es)?|order placement date|warehouse|fulfillment center|completed transactions?|sequential number|source field|core financial outcome|shipping fees?|returns?/shipping fees?|local currency|operational efficiency|fulfilled orders?|order lifecycle|customer interacted|physical stores?",
+            "flags": "i",
+            "label": "avoid invented operational context not present in the seeded CSV columns or values"
+          }
+        ]
+      }
+    ]
+  },
+  "rubric": {
+    "artifact": {
+      "path": "data-dictionary.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": [
+    "schema inspection",
+    "null/domain notes",
+    "dataset documentation"
+  ]
+}

package/data/craftbook-templates/da/data-export-migrate/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "data-export-migrate",
   "role": "general",
+  "category": "code-data",
   "name": "Migrate Data Between Tools",
   "description": "Migrate records from a source tool/format to a destination tool/format — CRM to CRM, spreadsheet to app, JSON export to a new API — with a field mapping, value transforms, and a reconciliation that proves nothing was lost or corrupted. Locks the source→destination field map, the transform/normalization rules, and the reconciliation criteria FIRST, then builds the extract-transform-load with a dry-run preview, then verifies record counts match, key fields round-trip, and a diff report flags any mismatch. Mapping-and-reconciliation-before-load is the discipline that makes a migration trustworthy rather than a one-shot leap of faith.",
   "tags": [