@bendyline/gilde 0.1.26 → 0.1.28

package/data/craftbook-templates/co/company-research-brief/versions/1.0.1/test.json

@@ -0,0 +1,97 @@
+{
+  "schemaVersion": 1,
+  "title": "Company Research Brief smoke eval",
+  "objective": "Self-contained smoke eval for the Company Research Brief craftbook using the html-page generic harness.",
+  "tags": [
+    "html-page"
+  ],
+  "prompt": "Can you biuld us a little page for this? The content notes are in source/page-content.md. Save it as index.html — one file, nothing fancy needed on our end.",
+  "setup": {
+    "projectName": "Company Research Brief Eval",
+    "about": "Self-contained eval project for company-research-brief. Seeded inputs are under workspace/source or workspace/fixtures; final deliverable is workspace/index.html.",
+    "missionObjectives": "Use the Company Research Brief craftbook/template, read the seeded local fixtures, and write index.html without network calls, real credentials, or live services.",
+    "files": [
+      {
+        "path": "source/brief.md",
+        "content": "# Company Research Brief 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: company-research-brief - Company Research Brief.\n"
+      },
+      {
+        "path": "source/page-content.md",
+        "content": "# Boreal Desk Support Board\n\nBuild content around a support operations board. Required labels: Open issues, Status silence, Response time, Refund leakage, Next action. Required metric text: 18 hours to 6 hours and 14.2% to 8.9%.\n"
+      }
+    ],
+    "worker": {
+      "name": "Jules",
+      "role": "Developer"
+    }
+  },
+  "mocks": [],
+  "success": {
+    "summary": "index.html is a source-grounded self-contained HTML page/tool.",
+    "deliverables": [
+      {
+        "path": "index.html",
+        "kind": "html-page",
+        "minBytes": 3000,
+        "checks": [
+          {
+            "kind": "cssMinBytes",
+            "bytes": 650,
+            "file": "index.html"
+          },
+          {
+            "kind": "jsParses",
+            "file": "index.html"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "Boreal|Support Board|returns",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "18\\s*hours|6\\s*hours|14\\.2%|8\\.9%",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "button|input|filter|tab|card|section|nav",
+            "flags": "i"
+          }
+        ]
+      }
+    ]
+  },
+  "rubric": {
+    "artifact": {
+      "path": "index.html",
+      "kind": "html"
+    },
+    "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": [
+    "self-contained UI",
+    "source grounding",
+    "responsive structure"
+  ]
+}

package/data/craftbook-templates/co/comparison-matrix/versions/1.0.1/craftbook.json

@@ -0,0 +1,153 @@
+{
+  "id": "comparison-matrix",
+  "name": "Option Comparison Matrix",
+  "description": "Compare a set of options against weighted criteria and ship an interactive HTML comparison matrix with a recommendation: a planner locks the options, the criteria, and their weights, a researcher fills every cell with an evidence-backed value, and a developer builds a single-file HTML page with a sortable/filterable comparison table and a scored recommendation. The ordering matters because criteria and weights chosen after seeing the data bias the winner, and a static table buries the decision; locking weighted criteria first makes the comparison fair and lets the build compute a transparent score. Use this for option/tool/vendor comparisons, decision matrices, buying guides, 'help me choose between X, Y, Z', and weighted pros/cons tables.\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. Criteria scope (planner) — lock options, weighted criteria, and the scoring rule → gated on artifact `notes/criteria-scope.md` (markdown-notes)\n2. Fill the cells (researcher) — evidence-backed value + rating for every option x criterion → gated on artifact `notes/data.md` (markdown-notes)\n3. Build the matrix page (developer) — single-file HTML sortable comparison + scored recommendation → gated on `index.html` (html-page)\n\nThe gates never advance with an unmet criterion, and loop back to the\nowning phase to fix named gaps.\n",
+  "entryStepId": "criteria-scope",
+  "triggers": [
+    "comparison matrix",
+    "help me choose between",
+    "compare these options",
+    "decision matrix",
+    "buying guide table"
+  ],
+  "steps": [
+    {
+      "id": "criteria-scope",
+      "name": "Criteria scope",
+      "description": "lock options, weighted criteria, and the scoring rule",
+      "prompt": "1. List the options to compare (3-8 named candidates) and confirm they are genuinely comparable for the stated goal. 2. Choose 5-9 decision criteria, define each precisely, and assign each a weight (e.g. percentages summing to 100, or 1-5 importance) BEFORE looking at any data — justify each weight in one line. 3. Decide how each cell is scored (a 1-5 rating, a raw value, or yes/no) and the rule that turns ratings x weights into a total score. 4. Decide the page features: a comparison table (options x criteria), per-option total score, and a highlighted recommendation. 5. Write an acceptance-criteria checklist (e.g. 'every option x criterion cell is filled with evidence', 'weights are fixed before research and sum correctly', 'the page computes and shows a weighted total per option', 'the table is sortable or filterable', 'the recommended option is highlighted and justified'). 6. Record decisions. Call write_task_note with options, weighted criteria, scoring rule, and checklist; write the same to notes/criteria-scope.md.\n\nThe deliverable `notes/criteria-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": "notes/criteria-scope.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "notes/criteria-scope.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "notes/criteria-scope.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "criteria-scope",
+        "maxAttempts": 3
+      },
+      "next": "research"
+    },
+    {
+      "id": "research",
+      "name": "Fill the cells",
+      "description": "evidence-backed value + rating for every option x criterion",
+      "prompt": "1. For each option, research every locked criterion and record in notes/data.md: the raw value/fact, the rating per the scoring rule, the source [n], and a one-line note. 2. Rate consistently across options so scores are comparable; do not let a known favorite get generous ratings. 3. Cite each value to a real source; mark genuinely unknown cells UNKNOWN with a conservative rating and a note, never a fabricated value. 4. Pre-compute each option's weighted total using the locked rule and show your arithmetic so the developer can reproduce it. 5. Note any decisive strength or dealbreaker per option. Good looks like a complete, cited data file the build can render verbatim. Do not write HTML yet.\n\nThe deliverable `notes/data.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": "researcher",
+      "advanceWhen": {
+        "file": "notes/data.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "notes/data.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "notes/data.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "research",
+        "maxAttempts": 3
+      },
+      "next": "build"
+    },
+    {
+      "id": "build",
+      "name": "Build the matrix page",
+      "description": "single-file HTML sortable comparison + scored recommendation",
+      "prompt": "1. Build index.html (inline CSS + JS, no external assets) rendering the comparison as a table with options as rows (or columns) and criteria as columns, showing each cell's value/rating and the per-option weighted total. 2. Make the table interactive: at minimum sortable by total score and by any criterion, ideally with a filter; clicking a column header re-sorts. 3. Show the weights in the header and compute totals in JS from the locked rule so the math is transparent and verifiable. 4. Highlight the recommended option (highest weighted score) with a short justification drawn from notes/data.md, and carry source references. 5. Make it readable and responsive with real inline CSS: table layout, weight badges or header treatments, score/total emphasis, recommendation highlight, hover/focus states, and a mobile layout. Do not ship a bare unstyled table. 6. On a loop-back, fix only the named gaps. 7. Call write_task_note with the page path and which criteria now pass.\n\nBefore working, open the artifact input `notes/data.md` with `read_artifact`; do not look for it in the workspace.",
+      "suggestedRole": "developer",
+      "consumes": [
+        {
+          "file": "notes/data.md",
+          "artifact": true
+        }
+      ],
+      "advanceWhen": {
+        "file": "index.html",
+        "minBytes": 1,
+        "sniff": "html-complete"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "index.html",
+            "bytes": 1800
+          },
+          {
+            "kind": "htmlLint",
+            "file": "index.html"
+          },
+          {
+            "kind": "cssMinBytes",
+            "bytes": 400,
+            "file": "index.html"
+          }
+        ],
+        "scripts": [
+          {
+            "name": "checkHtmlComplete",
+            "scope": "standard",
+            "inputs": {
+              "file": "index.html"
+            }
+          }
+        ],
+        "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": "Open index.html (render it or trace the source) and check EACH criterion PASS/FAIL: (1) every option x criterion cell from notes/data.md is present with no blanks; (2) the weights shown match notes/criteria-scope.md and the JS-computed totals reproduce the locked scoring rule (recompute one option by hand); (3) the table actually sorts (and filters if specified) without console errors; (4) the recommended option is the highest-scoring one and is highlighted with a justification; (5) cells are evidence-backed with sources (spot-check 3). A static or mis-scored table, or one where weights were clearly tuned to the answer, FAILS.\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": "index.html"
+        }
+      ],
+      "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.1",
+  "releasedAt": "2026-08-14T00:00:00Z"
+}

package/data/craftbook-templates/co/comparison-matrix/versions/1.0.1/test.json

@@ -0,0 +1,109 @@
+{
+  "schemaVersion": 1,
+  "title": "Weighted vendor comparison matrix",
+  "objective": "Measure whether the comparison-matrix craftbook locks criteria and builds an interactive scored matrix from seeded option facts.",
+  "tags": [
+    "html-page"
+  ],
+  "prompt": "In the `Comparison Matrix Eval` project, read `source/options.md` and build `index.html`: an interactive weighted comparison for choosing a returns-management vendor. Compare Returnly, LoopDesk, and ParcelPilot across implementation effort, automation, reporting, and total cost. Show weights, scores, totals, a highlighted recommendation, and sortable table behavior. Vanilla HTML/CSS/JS only.",
+  "setup": {
+    "projectName": "Comparison Matrix Eval",
+    "about": "Self-contained eval project for the comparison-matrix craftbook. Option facts are in workspace/source/options.md.",
+    "missionObjectives": "Build a scored vendor comparison page with locked criteria weights, complete option cells, computed totals, recommendation, and interactive sorting.",
+    "files": [
+      {
+        "path": "source/options.md",
+        "content": "# Returns Vendor Options\n\nGoal: choose a returns-management vendor for a 90-day pilot.\nCriteria weights: implementation effort 25%, automation 30%, reporting 25%, total cost 20%.\n\n## Returnly\n- Implementation effort: medium, 4 weeks.\n- Automation: strong label rules and refund triggers.\n- Reporting: basic CSV export.\n- Total cost: $4,800 pilot.\n\n## LoopDesk\n- Implementation effort: low, 2 weeks.\n- Automation: moderate intake routing.\n- Reporting: strong dashboard and exception export.\n- Total cost: $5,600 pilot.\n\n## ParcelPilot\n- Implementation effort: high, 6 weeks.\n- Automation: strongest warehouse barcode workflow.\n- Reporting: moderate canned reports.\n- Total cost: $4,200 pilot.\n"
+      }
+    ],
+    "worker": {
+      "name": "Daan",
+      "role": "Developer"
+    }
+  },
+  "mocks": [],
+  "success": {
+    "summary": "workspace/index.html is a complete sortable comparison page with weights, totals, all options, and a recommendation.",
+    "deliverables": [
+      {
+        "path": "index.html",
+        "kind": "html-page",
+        "minBytes": 3600,
+        "checks": [
+          {
+            "kind": "cssMinBytes",
+            "bytes": 650,
+            "file": "index.html"
+          },
+          {
+            "kind": "jsParses",
+            "file": "index.html"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "Returnly|LoopDesk|ParcelPilot"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "25%|30%|20%"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "implementation effort|automation|reporting|total cost",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "score|weighted|total",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "recommend|best choice",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "sort|addEventListener|onclick",
+            "flags": "i"
+          }
+        ]
+      }
+    ]
+  },
+  "rubric": {
+    "artifact": {
+      "path": "index.html",
+      "kind": "html"
+    },
+    "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": [
+    "criteria weighting",
+    "complete matrix",
+    "computed recommendation"
+  ]
+}

package/data/craftbook-templates/co/compat-check/versions/1.0.1/craftbook.json

@@ -0,0 +1,146 @@
+{
+  "id": "compat-check",
+  "name": "Compatibility Check",
+  "description": "Answer 'does it still work on the new version?' with a matrix, not a shrug: the datapack's files checked against each target version's format rules, every break named with the exact file and the exact fix, and the upgrade path written down in order. Locks the target version list and the compat criteria FIRST (format numbers, renamed folders, changed identifiers), then checks version by version, then writes the matrix and the fixes. Use for version compatibility checks, 'does the mod work on 1.21', update breakage sweeps, and upgrade planning.\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 check (modmaker) — target versions, format rules, compat criteria locked → gated on artifact `notes/scope.md` (markdown-notes)\n2. Check each version (developer) — the pack walked against each version's rules, findings recorded → gated on artifact `notes/checks.md` (markdown-notes)\n3. Write the matrix (reviewer) — the compat matrix, the fixes, the ordered upgrade path → gated on artifact `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": "scope",
+  "triggers": [
+    "check compatibility",
+    "does it work on the new version",
+    "will the mod break",
+    "version check the datapack",
+    "plan the upgrade"
+  ],
+  "steps": [
+    {
+      "id": "scope",
+      "name": "Scope the check",
+      "description": "target versions, format rules, compat criteria locked",
+      "prompt": "Define the check before judging a single file. Step 1: list the target game versions to check against, and read the version notes in the workspace (the version-to-pack_format table and any renamed-folder or changed-identifier notes) — every claim in the matrix must trace to these notes or to the pack's own files, never to memory. Step 2: inventory the datapack — pack.mcmeta's current pack_format, the folder names in use under data/, and the identifiers the functions and JSON files rely on. Step 3: lock the compat criteria per version — the pack_format the version expects, the folder names it expects, and the identifiers it renamed or removed; anything the notes do not cover gets checked as 'unverified', not guessed. Step 4: write an acceptance-criteria checklist ('every target version gets a verdict', 'every break names the exact file and what breaks', 'every break has a concrete fix', 'verdicts trace to the version notes or the pack files', 'the upgrade path is ordered'). Call write_task_note with the version list + criteria + checklist and write notes/scope.md.\n\nThe deliverable `notes/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": "modmaker",
+      "advanceWhen": {
+        "file": "notes/scope.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "notes/scope.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "notes/scope.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "scope",
+        "maxAttempts": 3
+      },
+      "next": "check"
+    },
+    {
+      "id": "check",
+      "name": "Check each version",
+      "description": "the pack walked against each version's rules, findings recorded",
+      "prompt": "Walk the datapack against each target version's locked criteria. Step 1: for each version, check pack.mcmeta's pack_format against the version's expected number; a mismatch is a break with a one-line fix. Step 2: check every folder under data/ against the version's expected folder names — renamed folders are the silent killer, the pack loads and the content just never fires. Step 3: sweep the function and JSON files for identifiers the version renamed or removed, listing each occurrence by file. Step 4: record the findings per version in notes/checks.md — works, breaks with the named file and reason, or unverified where the notes ran out — and be honest about the unverified ones; a confident wrong verdict costs an evening of debugging. Call write_task_note with the per-version verdict counts.\n\nThe deliverable `notes/checks.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": "developer",
+      "advanceWhen": {
+        "file": "notes/checks.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "notes/checks.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "notes/checks.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "check",
+        "maxAttempts": 3
+      },
+      "next": "report"
+    },
+    {
+      "id": "report",
+      "name": "Write the matrix",
+      "description": "the compat matrix, the fixes, the ordered upgrade path",
+      "prompt": "Write the report that answers the question at a glance. Step 1: open with the verdict in one sentence — which versions the pack works on today and which break it. Step 2: build the compatibility matrix as a table — a row per target version with columns for Version and Status at minimum, the status stated plainly (works, breaks, unverified) with the one-line reason. Step 3: list the fixes — every break from notes/checks.md with the exact file and the exact change, grouped by version. Step 4: write the upgrade path — the fixes in the order to apply them, and what to test in-game after each, so the upgrade is an afternoon of steps rather than a weekend of guessing. Write report.md and call write_task_note with the report path and the verdict sentence.\n\nBefore working, open the artifact input `notes/checks.md` with `read_artifact`; do not look for it in the workspace.\n\nThe deliverable `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": "reviewer",
+      "consumes": [
+        {
+          "file": "notes/checks.md",
+          "artifact": true
+        }
+      ],
+      "advanceWhen": {
+        "file": "report.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "report.md",
+            "bytes": 1000,
+            "artifact": true
+          },
+          {
+            "kind": "contains",
+            "file": "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": "Open report.md, notes/checks.md, and the version notes and verify every criterion from notes/scope.md: every target version has a row in the matrix with a plain verdict, every break names the exact file and carries a concrete fix, every verdict traces to the version notes or the pack's actual files (spot-check two against the notes), unverified items are marked as such rather than guessed, and the upgrade path is ordered with a test step per fix. Write PASS/FAIL per criterion; on any failure, name the gap and loop back to report.\n\nThe deliverable lives in the project's artifacts drawer — open `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": "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.1",
+  "releasedAt": "2026-08-14T00:00:00Z"
+}

package/data/craftbook-templates/co/compat-check/versions/1.0.1/test.json

@@ -0,0 +1,145 @@
+{
+  "schemaVersion": 1,
+  "title": "Compatibility Check smoke eval",
+  "objective": "Task-specific eval for the Compatibility Check craftbook: a 1.20-era boat-diamond datapack (pack_format 15, plural folder names) checked against 1.21.5 and 1.20.6 using the house version notes — a Version/Status matrix, every break named with its file and fix, and an ordered upgrade path.",
+  "tags": [
+    "corpus"
+  ],
+  "prompt": "does our boat-diamond pack still work on 1.21.5? and what about 1.20.6? check compatability and write it up",
+  "setup": {
+    "projectName": "Mod Workshop — Compat Check Eval",
+    "about": "Self-contained eval project for compat-check. The datapack under test sits in the workspace: pack.mcmeta (currently pack_format 15) and the boatpack content under data/ using the pre-1.21 plural folder names. The house version notes at notes/format-versions.md carry the pack_format table and the 1.21 folder-rename rule. Findings go to notes/checks.md and the matrix report to report.md.",
+    "missionObjectives": "Use the Compatibility Check craftbook/template, check the pack against 1.21.5 and 1.20.6 using only the version notes and the pack's own files, and write report.md with a Version/Status matrix, per-break fixes, and an ordered upgrade path. Claims trace to the notes or the files — anything the notes do not cover is marked unverified, never guessed.",
+    "files": [
+      {
+        "path": "notes/format-versions.md",
+        "content": "# Datapack format numbers (house notes)\n\n| Game version | pack_format |\n| --- | --- |\n| 1.20 | 15 |\n| 1.20.6 | 41 |\n| 1.21 | 48 |\n| 1.21.5 | 71 |\n\nFolder names: since 1.21 the data folder names are singular - function,\nrecipe, advancement, loot_table, and tags/function. Before 1.21 they were\nplural - functions, recipes, advancements, loot_tables, tags/functions.\nA pack using the old plural names loads on 1.21+ but its content silently\nnever fires.\n"
+      },
+      {
+        "path": "pack.mcmeta",
+        "content": "{\n  \"pack\": {\n    \"pack_format\": 15,\n    \"description\": \"Boat Diamond - craft a boat, get a diamond\"\n  }\n}\n"
+      },
+      {
+        "path": "data/boatpack/functions/give_diamond.mcfunction",
+        "content": "give @s minecraft:diamond 1\nadvancement revoke @s only boatpack:craft_boat\ntellraw @s {\"text\":\"A boat! Have a diamond.\",\"color\":\"aqua\"}\n"
+      },
+      {
+        "path": "data/boatpack/advancements/craft_boat.json",
+        "content": "{\n  \"criteria\": {\n    \"crafted_boat\": {\n      \"trigger\": \"minecraft:inventory_changed\",\n      \"conditions\": {\n        \"items\": [\n          {\n            \"items\": [\n              \"minecraft:oak_boat\"\n            ]\n          }\n        ]\n      }\n    }\n  },\n  \"rewards\": {\n    \"function\": \"boatpack:give_diamond\"\n  }\n}\n"
+      }
+    ],
+    "worker": {
+      "name": "Jesse",
+      "role": "Developer"
+    }
+  },
+  "mocks": [],
+  "success": {
+    "summary": "report.md answers at a glance: a Version/Status matrix covering both asked versions, the pack_format mismatches named with the numbers from the notes, the 1.21 folder renames caught as breaks with exact files, and an ordered upgrade path.",
+    "deliverables": [
+      {
+        "path": "report.md",
+        "kind": "markdown-report",
+        "minBytes": 800,
+        "checks": [
+          {
+            "kind": "contains",
+            "file": "report.md",
+            "pattern": "(?:^|\\n)#{1,3}\\s+\\S",
+            "flags": "i"
+          },
+          {
+            "kind": "tableShape",
+            "file": "report.md",
+            "requiredColumns": [
+              "Version",
+              "Status"
+            ],
+            "minRows": 2
+          },
+          {
+            "kind": "contains",
+            "file": "report.md",
+            "pattern": "1\\.21\\.5",
+            "label": "the 1.21.5 verdict is present"
+          },
+          {
+            "kind": "contains",
+            "file": "report.md",
+            "pattern": "1\\.20\\.6",
+            "label": "the 1.20.6 verdict is present"
+          },
+          {
+            "kind": "contains",
+            "file": "report.md",
+            "pattern": "pack_format|format number",
+            "flags": "i",
+            "label": "the format-number break is named"
+          },
+          {
+            "kind": "contains",
+            "file": "report.md",
+            "pattern": "folder|functions|advancements",
+            "flags": "i",
+            "label": "the renamed-folder break is named"
+          },
+          {
+            "kind": "valuesSubsetOf",
+            "file": "report.md",
+            "sourceFiles": [
+              "notes/format-versions.md"
+            ],
+            "pattern": "\\b(1\\.2\\d(?:\\.\\d+)?)\\b",
+            "minMatches": 2,
+            "label": "every game version cited comes from the version notes"
+          },
+          {
+            "kind": "judge",
+            "file": "report.md",
+            "rubric": "Each verdict traces to the version notes or the pack's actual files (pack_format 15 versus the required 71 and 41; the plural functions/advancements folders breaking on 1.21+), fixes name the exact file and change, the upgrade path is ordered with a test step per fix, and nothing outside the notes is asserted with confidence.",
+            "sourceFiles": [
+              "notes/format-versions.md",
+              "pack.mcmeta",
+              "notes/checks.md"
+            ],
+            "label": "grounded verdicts and concrete fixes"
+          }
+        ]
+      },
+      {
+        "path": "notes/checks.md",
+        "kind": "markdown-notes",
+        "minBytes": 300
+      }
+    ]
+  },
+  "rubric": {
+    "artifact": {
+      "path": "report.md",
+      "kind": "markdown"
+    },
+    "axes": [
+      {
+        "name": "thoroughness",
+        "description": "Both asked versions get real verdicts; format number and folder names are both checked."
+      },
+      {
+        "name": "precision",
+        "description": "Breaks name the exact file and the exact expected value or name."
+      },
+      {
+        "name": "upgrade-guidance",
+        "description": "The fixes are ordered into a path with a test step per change."
+      },
+      {
+        "name": "honesty",
+        "description": "Anything beyond the notes is marked unverified, never asserted from memory."
+      }
+    ]
+  },
+  "qualityFocus": [
+    "grounded verdicts",
+    "exact-file fixes",
+    "ordered upgrade path"
+  ]
+}