@bendyline/gilde 0.1.26 → 0.1.28

package/data/craftbook-templates/fo/form-wizard/versions/1.0.1/test.json

@@ -0,0 +1,110 @@
+{
+  "schemaVersion": 1,
+  "title": "Stateful multi-step signup form",
+  "objective": "Run the form-wizard template on a self-contained interactive HTML task with static gates for navigation, validation, progress, review, and success states.",
+  "tags": [
+    "external"
+  ],
+  "prompt": "In the `Form Wizard Eval` project, build a self-contained `index.html` for a three-step volunteer signup wizard: Contact, Preferences, Review. It must block Next on invalid required fields, preserve entered data when Back is used, show progress, render a review step with every answer, and show a success state on submit. Vanilla HTML/CSS/JS only, no external assets or build step.",
+  "setup": {
+    "projectName": "Form Wizard Eval",
+    "about": "Self-contained eval project for the form-wizard craftbook. The only deliverable is workspace/index.html.",
+    "missionObjectives": "Build a three-step wizard with validation, Back preserving state, progress, review, submit success, and no external dependencies.",
+    "files": [],
+    "worker": {
+      "name": "Fenna",
+      "role": "Developer"
+    }
+  },
+  "mocks": [],
+  "success": {
+    "summary": "workspace/index.html is a complete interactive page with substantial JS/CSS and visible wizard-state vocabulary.",
+    "deliverables": [
+      {
+        "path": "index.html",
+        "kind": "html-page",
+        "minBytes": 2600,
+        "checks": [
+          {
+            "kind": "cssMinBytes",
+            "bytes": 500,
+            "file": "index.html"
+          },
+          {
+            "kind": "jsParses",
+            "file": "index.html"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "next|continue",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "back|previous",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "review|summary",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "progress|step\\s+\\d",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "success|submitted|thank",
+            "flags": "i"
+          }
+        ]
+      }
+    ]
+  },
+  "rubric": {
+    "artifact": {
+      "path": "index.html",
+      "kind": "html"
+    },
+    "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": [
+    "stateful UI",
+    "static HTML gates",
+    "craftbook prompt routing"
+  ],
+  "extensions": {
+    "legacySimulators": [
+      {
+        "id": "form-wizard-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/ga/game-with-screens/versions/1.0.1/craftbook.json

@@ -0,0 +1,168 @@
+{
+  "id": "game-with-screens",
+  "name": "Full Game with Title & Game-Over Screens",
+  "description": "Build a complete single-file HTML game with the full screen flow — a title/start screen, the gameplay screen, a game-over screen showing the score, and a restart back to a fresh game — wrapping any core arcade or survival mechanic. Designs the mechanic and the screen-state machine first, a cohesive visual look across all screens, then implements a screen manager so transitions are clean and restart truly resets. Many small models nail gameplay but ship with no start or game-over screen; this archetype makes the screen flow a first-class, gated requirement.\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. Game design (game-designer) — mechanic + the title/play/over/restart state machine → gated on artifact `notes/game-design.md` (markdown-notes)\n2. Visual design (visual-designer) — cohesive look across all three screens → gated on artifact `notes/visual-design.md` (markdown-notes)\n3. Build (developer) — implement screen manager + game in index.html → gated on `index.html` (html-multiscreen-game)\n\nThe gates never advance with an unmet criterion, and loop back to the\nowning phase to fix named gaps.\n",
+  "entryStepId": "game-design",
+  "triggers": [
+    "full game with menu",
+    "game with title screen",
+    "game over screen",
+    "complete game",
+    "game with start and restart",
+    "multiscreen game"
+  ],
+  "steps": [
+    {
+      "id": "game-design",
+      "name": "Game design",
+      "description": "mechanic + the title/play/over/restart state machine",
+      "prompt": "Design the game AND its screen flow. (1) Define the core mechanic, controls, scoring, and the lose condition (a survival/arcade loop). (2) Specify the screen state machine: TITLE (instructions + a start control) -> PLAYING (the game) -> GAME OVER (final score + a restart control) -> back to a FRESH PLAYING state. (3) Define exactly how each transition triggers (press key/click to start; lose -> game over; restart -> reset all state). (4) Write an acceptance-criteria checklist of 6-8 items, e.g. 'a title screen shows before play with a start control', 'starting begins gameplay', 'the mechanic and controls work', 'losing shows a game-over screen with the final score', 'restart returns to a fully reset game (score 0)', 'no leftover state between runs', 'no console errors'. Write to notes/game-design.md and via write_task_note. No code yet.\n\nThe deliverable `notes/game-design.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": "game-designer",
+      "advanceWhen": {
+        "file": "notes/game-design.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "notes/game-design.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "notes/game-design.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "game-design",
+        "maxAttempts": 3
+      },
+      "next": "visual-design"
+    },
+    {
+      "id": "visual-design",
+      "name": "Visual design",
+      "description": "cohesive look across all three screens",
+      "prompt": "Design a cohesive look across all screens. (1) Pick one palette (hex) and type used on title, gameplay HUD, and game-over so they feel like one game. (2) Design the title screen (game name, brief how-to, start prompt), the in-game HUD (score, lives), and the game-over screen (final score, restart prompt). (3) Specify the entity shapes/sprites for gameplay (canvas primitives, no external assets). (4) Add a touch of juice on transitions. Write the visual spec to notes/visual-design.md and via write_task_note. No code yet.\n\nThe deliverable `notes/visual-design.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": "visual-designer",
+      "advanceWhen": {
+        "file": "notes/visual-design.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "notes/visual-design.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "notes/visual-design.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "visual-design",
+        "maxAttempts": 3
+      },
+      "next": "build"
+    },
+    {
+      "id": "build",
+      "name": "Build",
+      "description": "implement screen manager + game in index.html",
+      "prompt": "Implement the full game in a single index.html (inline CSS + JS) to the visual spec, satisfying every criterion. (1) Maintain a gameState variable ('title' | 'playing' | 'over') and route rendering and input by it. (2) Build the title screen with a start control that switches to 'playing' and initializes fresh state. (3) Implement the gameplay loop (mechanic, input, scoring, collision) on canvas. (4) On the lose condition switch to 'over' and show the final score with a restart control. (5) Restart must RESET all state (score 0, entities cleared) and return to a fresh 'playing' (or title). Vanilla JS, no CDN, no external assets. On a loop-back, fix only the named gaps without regressing passing criteria. write_task_note the path and passing criteria.",
+      "suggestedRole": "developer",
+      "advanceWhen": {
+        "file": "index.html",
+        "minBytes": 1,
+        "sniff": "html-complete"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "index.html",
+            "bytes": 2500
+          },
+          {
+            "kind": "htmlLint",
+            "file": "index.html"
+          }
+        ],
+        "scripts": [
+          {
+            "name": "checkHtmlGame",
+            "scope": "standard",
+            "inputs": {
+              "file": "index.html"
+            }
+          },
+          {
+            "name": "checkJsParses",
+            "scope": "standard",
+            "inputs": {
+              "file": "index.html"
+            }
+          },
+          {
+            "name": "checkContains",
+            "scope": "standard",
+            "inputs": {
+              "file": "index.html",
+              "pattern": "game\\s*-?\\s*over|you\\s+(?:win|won|lose|lost|died|die)|defeat|victory",
+              "flags": "i"
+            }
+          },
+          {
+            "name": "checkContains",
+            "scope": "standard",
+            "inputs": {
+              "file": "index.html",
+              "pattern": "restart|play\\s*again|try\\s*again|new\\s+game|press\\s+\\S+\\s+to\\s+(?:restart|play|start)",
+              "flags": "i"
+            }
+          }
+        ],
+        "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": "Play a full cycle twice. Open index.html if possible: from the title, start, play until you lose, see game-over with the score, restart, and confirm it begins fresh. Check EACH criterion from notes/game-design.md and write PASS/FAIL with a reason: is there a title screen with a start control, does starting begin gameplay, do the mechanic/controls work, does losing show a game-over screen with the final score, does restart fully reset (score back to 0, no leftover entities), zero console errors? Stale state after restart, or a missing title/game-over screen, is a FAIL — loop back to build.\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/ga/game-with-screens/versions/1.0.1/test.json

@@ -0,0 +1,99 @@
+{
+  "schemaVersion": 1,
+  "title": "Full Game with Title & Game-Over Screens smoke eval",
+  "objective": "Self-contained smoke eval for the Full Game with Title & Game-Over Screens craftbook using the html-game generic harness.",
+  "tags": [
+    "html-game"
+  ],
+  "prompt": "Make us a fun litle browser game around the returns-desk theme — just one file, index.html, that we can open and play.",
+  "setup": {
+    "projectName": "Full Game with Title & Game-Over Screens Eval",
+    "about": "Self-contained eval project for game-with-screens. Seeded inputs are under workspace/source or workspace/fixtures; final deliverable is workspace/index.html.",
+    "missionObjectives": "Use the Full Game with Title & Game-Over Screens 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": "# Full Game with Title & Game-Over Screens 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: game-with-screens - Full Game with Title & Game-Over Screens.\n"
+      }
+    ],
+    "worker": {
+      "name": "Jules",
+      "role": "Developer"
+    }
+  },
+  "mocks": [],
+  "success": {
+    "summary": "index.html is a complete self-contained browser game smoke artifact.",
+    "deliverables": [
+      {
+        "path": "index.html",
+        "kind": "html-game",
+        "minBytes": 3200,
+        "checks": [
+          {
+            "kind": "cssMinBytes",
+            "bytes": 600,
+            "file": "index.html"
+          },
+          {
+            "kind": "jsParses",
+            "file": "index.html"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "<canvas|<svg|requestAnimationFrame",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "score|state|level|turn",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "restart|play again|new game|game over|victory|you win|you lose",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "Boreal|returns|desk",
+            "flags": "i"
+          }
+        ]
+      }
+    ]
+  },
+  "rubric": {
+    "artifact": {
+      "path": "index.html",
+      "kind": "html"
+    },
+    "axes": [
+      {
+        "name": "playability",
+        "description": "The game is actually playable: input works, state advances, and a session can be completed."
+      },
+      {
+        "name": "completeness",
+        "description": "Core loop, scoring/win-lose, and restart are all present rather than stubbed."
+      },
+      {
+        "name": "polish",
+        "description": "Visual design and feedback (motion, states, messages) feel deliberate, not default."
+      },
+      {
+        "name": "robustness",
+        "description": "No console errors, dead controls, or states the player can get stuck in."
+      }
+    ]
+  },
+  "qualityFocus": [
+    "runtime surface",
+    "interaction loop",
+    "self-contained game"
+  ]
+}

package/data/craftbook-templates/gl/glossary-build/versions/1.0.1/craftbook.json

@@ -0,0 +1,140 @@
+{
+  "id": "glossary-build",
+  "name": "Domain Glossary",
+  "description": "Build a consistent, accurate glossary for a domain: a planner sets the domain scope, the term-selection criteria, and the entry template, a researcher gathers the canonical definition and usage for each term with sources, and a copywriter writes the alphabetized glossary with cross-references and consistent entries. The ordering matters because terms picked ad hoc leave gaps and inconsistent entries confuse readers; locking the scope, what makes a term in-scope, and a fixed entry template first guarantees coverage and a uniform, cross-linked glossary. Use this for building a domain or product glossary, a terms/definitions reference, an acronym list, onboarding vocabulary, and 'define all the key terms in X' requests.\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 glossary (planner) — domain, term-selection criteria, and entry template → gated on artifact `notes/scope.md` (markdown-notes)\n2. Gather definitions (researcher) — canonical definition + usage per term, with sources → gated on artifact `notes/terms.md` (markdown-notes)\n3. Write the glossary (copywriter) — alphabetized, cross-referenced glossary to the template → gated on `glossary.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": "scope",
+  "triggers": [
+    "build a glossary",
+    "define the key terms",
+    "domain terminology reference",
+    "acronym list",
+    "terms and definitions for"
+  ],
+  "steps": [
+    {
+      "id": "scope",
+      "name": "Scope the glossary",
+      "description": "domain, term-selection criteria, and entry template",
+      "prompt": "1. Define the domain and audience in one sentence (who reads this and at what level). 2. Set term-selection criteria (what makes a term in-scope) and produce the candidate term list (aim for the genuinely core terms, not every word). 3. Lock the entry template every term will follow: term, short definition (1-2 sentences), expanded explanation if needed, example/usage, related terms (cross-references), and source. 4. Decide ordering (alphabetical) and any grouping. 5. Write an acceptance-criteria checklist (e.g. 'every candidate term has an entry following the template', 'definitions are accurate and audience-appropriate', 'cross-referenced related terms exist as their own entries', 'entries are alphabetized', 'acronyms are expanded on first definition'). 6. Record decisions. Call write_task_note with the term list, entry template, and checklist; write the same to 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": "planner",
+      "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": "gather"
+    },
+    {
+      "id": "gather",
+      "name": "Gather definitions",
+      "description": "canonical definition + usage per term, with sources",
+      "prompt": "1. For each candidate term, gather the canonical definition into notes/terms.md following the entry template: term, accurate short definition, expanded note if the term is subtle, a real usage example, candidate related terms, and a source [n]. 2. Use authoritative sources (standards, official docs, reputable references) and reconcile conflicting definitions by noting the dominant usage in this domain. 3. Ensure every term named as a 'related term' is itself in the term list — add it if it is missing so cross-references resolve. 4. Expand every acronym and note common synonyms. 5. Flag any term whose meaning is contested or uncertain. Good looks like a complete, sourced entry per term with resolvable cross-references. Do not write the final glossary yet.\n\nThe deliverable `notes/terms.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/terms.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "notes/terms.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "notes/terms.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "gather",
+        "maxAttempts": 3
+      },
+      "next": "write"
+    },
+    {
+      "id": "write",
+      "name": "Write the glossary",
+      "description": "alphabetized, cross-referenced glossary to the template",
+      "prompt": "1. Write glossary.md as an alphabetized list of entries, each following the locked template exactly (term as a heading, definition, optional expansion, example, related terms, source). 2. Make cross-references real: every 'related term' links to or names an entry that exists in the glossary. 3. Keep voice and depth uniform across entries — same level of detail and the same audience pitch throughout. 4. Expand acronyms on their defining entry. 5. Carry source references so definitions are traceable. 6. On a loop-back, fix only the named gaps. 7. Call write_task_note with the glossary path and term count.",
+      "suggestedRole": "copywriter",
+      "advanceWhen": {
+        "file": "glossary.md",
+        "minBytes": 1,
+        "sniff": "nonempty"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "glossary.md",
+            "bytes": 500
+          }
+        ],
+        "scripts": [
+          {
+            "name": "checkContains",
+            "scope": "standard",
+            "inputs": {
+              "file": "glossary.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": "Open glossary.md and check EACH criterion PASS/FAIL: (1) every candidate term from notes/scope.md has an entry following the template; (2) entries are alphabetized; (3) every related-term cross-reference resolves to an actual entry (check 3 at random); (4) definitions are accurate and at the right audience level (spot-check 3 against notes/terms.md); (5) acronyms are expanded on first definition; (6) entry depth and voice are uniform. A glossary with missing terms, dangling cross-references, or inconsistent entry depth 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: \"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": "glossary.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.1",
+  "releasedAt": "2026-08-14T00:00:00Z"
+}

package/data/craftbook-templates/gl/glossary-build/versions/1.0.1/test.json

@@ -0,0 +1,110 @@
+{
+  "schemaVersion": 1,
+  "title": "Domain Glossary smoke eval",
+  "objective": "Self-contained smoke eval for the Domain Glossary craftbook using the corpus generic harness.",
+  "tags": [
+    "corpus"
+  ],
+  "prompt": "We need a domain glossary for the returns-desk work. The backgound info is in source/brief.md — have a look and write it up in report.md.",
+  "setup": {
+    "projectName": "Domain Glossary Eval",
+    "about": "Self-contained eval project for glossary-build. Seeded inputs are under workspace/source or workspace/fixtures; final deliverable is workspace/report.md.",
+    "missionObjectives": "Use the Domain Glossary craftbook/template, read the seeded local fixtures, and write report.md without network calls, real credentials, or live services.",
+    "files": [
+      {
+        "path": "source/brief.md",
+        "content": "# Domain Glossary 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: glossary-build - Domain Glossary.\n"
+      }
+    ],
+    "worker": {
+      "name": "Jules",
+      "role": "Writer"
+    }
+  },
+  "mocks": [],
+  "success": {
+    "summary": "report.md is a source-grounded markdown artifact with required facts and actions.",
+    "deliverables": [
+      {
+        "path": "report.md",
+        "kind": "markdown-report",
+        "minBytes": 1000,
+        "checks": [
+          {
+            "kind": "contains",
+            "file": "report.md",
+            "pattern": "(?:^|\\n)#{1,3}\\s+\\S",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "report.md",
+            "pattern": "source/brief\\.md|Brief",
+            "flags": "i",
+            "label": "cite or name the seeded source"
+          },
+          {
+            "kind": "contains",
+            "file": "report.md",
+            "pattern": "18\\b[\\s\\S]{0,30}\\bSKUs",
+            "flags": "i",
+            "label": "include the 18-SKU pilot scope"
+          },
+          {
+            "kind": "contains",
+            "file": "report.md",
+            "pattern": "18\\s*hours|6\\s*hours",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "report.md",
+            "pattern": "14\\.2%|8\\.9%",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "report.md",
+            "pattern": "status silence|photo submission",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "report.md",
+            "pattern": "automated status emails|barcode|Finance",
+            "flags": "i"
+          }
+        ]
+      }
+    ]
+  },
+  "rubric": {
+    "artifact": {
+      "path": "report.md",
+      "kind": "markdown"
+    },
+    "axes": [
+      {
+        "name": "grounding",
+        "description": "Seeded facts appear faithfully and the source is cited."
+      },
+      {
+        "name": "structure",
+        "description": "Sections progress logically for the artifact class."
+      },
+      {
+        "name": "completeness",
+        "description": "Required elements (risks, next actions, scope) are all present."
+      },
+      {
+        "name": "tone",
+        "description": "The register fits the audience and artifact class."
+      }
+    ]
+  },
+  "qualityFocus": [
+    "source-grounded prose",
+    "section structure",
+    "next-action clarity"
+  ]
+}