@bendyline/gilde 0.1.37 → 0.1.39

package/data/craftbook-templates/me/message-queue-consumer/versions/1.0.2/test.json

@@ -0,0 +1,95 @@
+{
+  "schemaVersion": 1,
+  "title": "Message Queue Consumer / Worker smoke eval",
+  "objective": "Self-contained smoke eval for the Message Queue Consumer / Worker craftbook using the code generic harness.",
+  "tags": [
+    "code"
+  ],
+  "prompt": "We need a small Node helper for this — the requirments are in source/requirements.md. Put it in src/solution.mjs.",
+  "setup": {
+    "projectName": "Message Queue Consumer / Worker Eval",
+    "about": "Self-contained eval project for message-queue-consumer. Seeded inputs are under workspace/source or workspace/fixtures; final deliverable is workspace/src/solution.mjs.",
+    "missionObjectives": "Use the Message Queue Consumer / Worker craftbook/template, read the seeded local fixtures, and write src/solution.mjs without network calls, real credentials, or live services.",
+    "files": [
+      {
+        "path": "source/brief.md",
+        "content": "# Message Queue Consumer / Worker 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: message-queue-consumer - Message Queue Consumer / Worker.\n"
+      },
+      {
+        "path": "source/requirements.md",
+        "content": "# Runner Requirements\n\nBuild a dependency-free Node ESM helper for Boreal Desk support operations. Export at least one function. Include a tiny self-test section using node:assert or an equivalent assertion helper. Use fixture values for 18 -> 6 hour response time and 14.2 -> 8.9 refund leakage.\n"
+      }
+    ],
+    "worker": {
+      "name": "Jules",
+      "role": "Developer"
+    },
+    "craftbookParams": {
+      "workPath": "tasks/eval"
+    }
+  },
+  "mocks": [],
+  "success": {
+    "summary": "src/solution.mjs is a local ESM module with basic self-test scaffolding.",
+    "deliverables": [
+      {
+        "path": "src/solution.mjs",
+        "kind": "code-with-tests",
+        "minBytes": 1500,
+        "checks": [
+          {
+            "kind": "esmImports",
+            "file": "src/solution.mjs"
+          },
+          {
+            "kind": "contains",
+            "file": "src/solution.mjs",
+            "pattern": "export\\s+(function|const|class)|export\\s*\\{",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "src/solution.mjs",
+            "pattern": "assert|test|describe|it|expect",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "src/solution.mjs",
+            "pattern": "18|6|14\\.2|8\\.9|Boreal",
+            "flags": "i"
+          }
+        ]
+      }
+    ]
+  },
+  "rubric": {
+    "artifact": {
+      "path": "src/solution.mjs",
+      "kind": "typescript"
+    },
+    "axes": [
+      {
+        "name": "correctness",
+        "description": "The module does what the requirements ask, with sensible edge handling."
+      },
+      {
+        "name": "verification",
+        "description": "Self-tests exercise real behavior, not trivial truths."
+      },
+      {
+        "name": "clarity",
+        "description": "Exports, naming, and structure make the module usable without reading every line."
+      },
+      {
+        "name": "robustness",
+        "description": "Invalid input and boundary cases fail loudly rather than silently."
+      }
+    ]
+  },
+  "qualityFocus": [
+    "runnable ESM",
+    "test scaffolding",
+    "local fixtures"
+  ]
+}

package/data/craftbook-templates/mi/micro-game-jam/versions/1.0.2/craftbook.json

@@ -0,0 +1,129 @@
+{
+  "id": "micro-game-jam",
+  "name": "Micro Game Jam",
+  "description": "Build a tiny, complete, themed micro-game from a one-word or one-line prompt — a 60-second arcade or one-mechanic toy that fully fits in a single HTML file with a clear goal and a win/lose. Interprets the theme into one tight mechanic and a scope you can actually finish first, then builds the whole game in one pass. The jam discipline is ruthless scope: pick ONE mechanic that expresses the theme, lock a tiny acceptance bar, and ship it playable rather than sprawling — the ordering that gets a small model to a finished game instead of an unfinished engine.\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. Theme design (game-designer) — interpret the theme into ONE finishable mechanic → gated on artifact `{{workPath}}/theme-design.md` (markdown-notes)\n2. Build (developer) — implement the whole micro-game in one index.html → gated on `index.html` (html-game)\n\nThe gates never advance with an unmet criterion, and loop back to the\nowning phase to fix named gaps.\n",
+  "entryStepId": "theme-design",
+  "triggers": [
+    "game jam",
+    "tiny game",
+    "themed game",
+    "make a quick game",
+    "one mechanic game",
+    "micro game"
+  ],
+  "steps": [
+    {
+      "id": "theme-design",
+      "name": "Theme design",
+      "description": "interpret the theme into ONE finishable mechanic",
+      "prompt": "Turn the theme into a finishable micro-game. (1) Restate the theme/prompt in one line and brainstorm the single mechanic that best expresses it — pick exactly ONE (resist scope creep). (2) Define controls, the goal, and a clear win AND lose in one screen. (3) Time-box the scope: what is in (one mechanic, one screen, score or timer) and explicitly what is OUT. (4) Pick a tiny visual style (a few shapes, a 3-color palette with hex). (5) Write a SHORT acceptance-criteria checklist of 4-6 binary items, e.g. 'the theme is recognizable in the mechanic', 'controls work', 'a win condition can be reached', 'a lose condition can be reached', 'a restart exists', 'runs with no console error'. Write to {{workPath}}/theme-design.md and via write_task_note. No code yet.\n\nThe deliverable `{{workPath}}/theme-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": "{{workPath}}/theme-design.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "{{workPath}}/theme-design.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "{{workPath}}/theme-design.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "theme-design",
+        "maxAttempts": 3
+      },
+      "next": "build"
+    },
+    {
+      "id": "build",
+      "name": "Build",
+      "description": "implement the whole micro-game in one index.html",
+      "prompt": "Build the entire micro-game in a single index.html (inline CSS + JS) satisfying the small checklist. (1) <canvas> + 2d context, the one mechanic, real input handling, and a game loop. (2) Implement the goal and BOTH win and lose states on the single screen, plus a restart (press a key / click). (3) Apply the tiny visual style and show score or timer. (4) Keep it small and complete — finishing beats features. 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": 1500
+          },
+          {
+            "kind": "htmlLint",
+            "file": "index.html"
+          }
+        ],
+        "scripts": [
+          {
+            "name": "checkHtmlGame",
+            "scope": "standard",
+            "inputs": {
+              "file": "index.html"
+            }
+          },
+          {
+            "name": "checkJsParses",
+            "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": "Play the micro-game. Open index.html if possible, else trace the loop. Check EACH criterion from {{workPath}}/theme-design.md and write PASS/FAIL with a reason: is the theme recognizable in the mechanic, do controls work, can you reach BOTH a win and a lose, does restart work, zero console errors? It must be a complete tiny game, not an unfinished engine — if win or lose is unreachable, FAIL and 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.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/mi/micro-game-jam/versions/1.0.2/test.json

@@ -0,0 +1,102 @@
+{
+  "schemaVersion": 1,
+  "title": "Micro Game Jam smoke eval",
+  "objective": "Self-contained smoke eval for the Micro Game Jam 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": "Micro Game Jam Eval",
+    "about": "Self-contained eval project for micro-game-jam. Seeded inputs are under workspace/source or workspace/fixtures; final deliverable is workspace/index.html.",
+    "missionObjectives": "Use the Micro Game Jam 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": "# Micro Game Jam 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: micro-game-jam - Micro Game Jam.\n"
+      }
+    ],
+    "worker": {
+      "name": "Jules",
+      "role": "Developer"
+    },
+    "craftbookParams": {
+      "workPath": "tasks/eval"
+    }
+  },
+  "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/mo/mock-interview/versions/1.0.2/craftbook.json

@@ -0,0 +1,151 @@
+{
+  "id": "mock-interview",
+  "name": "Mock Interview",
+  "description": "A realistic practice interview run live with the candidate — planned questions calibrated to the target role and round, a real-time interview with pressure follow-ups, and a kind, specific debrief: strengths in the candidate's own words, fixes with sketched stronger answers, one drill, and an honest readiness read. The debrief is the deliverable. Use before any real interview round.\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. Plan the interview (Oefen-interviewer) — six to ten calibrated questions with planned follow-up chains → gated on artifact `{{workPath}}/interview-plan.md` (markdown-notes)\n2. Conduct the interview (Oefen-interviewer) — the live practice round, transcribed as it runs → gated on artifact `{{workPath}}/interview-transcript.md` (markdown-notes)\n3. Write the debrief (Oefen-interviewer) — kind, specific, grounded in the transcript → gated on artifact `{{workPath}}/reports/interview-debrief.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": "plan",
+  "triggers": [
+    "mock interview",
+    "practice interview",
+    "interview prep session",
+    "run me through a practice round"
+  ],
+  "steps": [
+    {
+      "id": "plan",
+      "name": "Plan the interview",
+      "description": "six to ten calibrated questions with planned follow-up chains",
+      "prompt": "Build the interview plan. Step 1: establish the target role, company, and round — read the project's pipeline record and company brief when present; otherwise ask, briefly. Step 2: draft six to ten questions mixing behavioral and role-specific, calibrated to the round (a recruiter screen is not a final loop). Step 3: for each major expected claim, plan a follow-up chain — the 'what did YOU do?' probe. At least one chain must apply real pressure. Step 4: define the debrief contract up front: two or three strengths quoting the candidate, two or three fixes each with a sketched stronger answer, exactly one drill, and a readiness read. Step 5: write an acceptance-criteria checklist ('questions specific to the target role', 'at least one pressure follow-up chain', 'debrief contract stated'). Write the plan + checklist via write_task_note AND to {{workPath}}/interview-plan.md.\n\nThe deliverable `{{workPath}}/interview-plan.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": "Oefen-interviewer",
+      "advanceWhen": {
+        "file": "{{workPath}}/interview-plan.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "{{workPath}}/interview-plan.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "{{workPath}}/interview-plan.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "plan",
+        "maxAttempts": 3
+      },
+      "next": "conduct"
+    },
+    {
+      "id": "conduct",
+      "name": "Conduct the interview",
+      "description": "the live practice round, transcribed as it runs",
+      "prompt": "Run the interview live with the user. Step 1: set the frame in one line ('I'm your interviewer for a <round> for <role> — ready?') then go in character. Step 2: one question per turn, through the user-interaction capabilities on your current roster; wait for the answer before the next. Step 3: use the planned follow-up chains on vague or team-credited answers; stay realistic, never cruel — if the candidate is rattled, step out of character, steady them, resume when ready. Step 4: after each exchange, append a condensed record to {{workPath}}/interview-transcript.md: the question, the gist of the answer, your one-line read. Step 5: end the roleplay explicitly ('Stepping out of character now') once the planned questions or the candidate's energy are spent. The transcript file is the phase's deliverable — keep it current as you go, not reconstructed after.\n\nThe deliverable `{{workPath}}/interview-transcript.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": "Oefen-interviewer",
+      "advanceWhen": {
+        "file": "{{workPath}}/interview-transcript.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "{{workPath}}/interview-transcript.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "{{workPath}}/interview-transcript.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "conduct",
+        "maxAttempts": 3
+      },
+      "next": "debrief"
+    },
+    {
+      "id": "debrief",
+      "name": "Write the debrief",
+      "description": "kind, specific, grounded in the transcript",
+      "prompt": "Write {{workPath}}/reports/interview-debrief.md to the contract from the plan. Step 1: '## Strengths' — two or three, each quoting the candidate's own words from the transcript so they can hear what worked. Step 2: '## Fixes' — two or three, each naming the moment it surfaced, why it lands badly in a real round, and a sketched stronger answer they could actually give. Step 3: '## Drill' — exactly one exercise to run before the real interview, matched to the biggest fix. Step 4: '## Readiness' — an honest read: ready, or one more round (and on what). Step 5: every point must trace to the transcript; no generic interview advice. On a loop-back, fix ONLY the named issues.\n\nThe deliverable `{{workPath}}/reports/interview-debrief.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": "Oefen-interviewer",
+      "advanceWhen": {
+        "file": "{{workPath}}/reports/interview-debrief.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "{{workPath}}/reports/interview-debrief.md",
+            "bytes": 1500,
+            "artifact": true
+          },
+          {
+            "kind": "contains",
+            "file": "{{workPath}}/reports/interview-debrief.md",
+            "pattern": "(?:^|\\n)#{1,3}\\s+\\S",
+            "flags": "i",
+            "label": "at least one markdown heading",
+            "artifact": true
+          }
+        ],
+        "onReject": "debrief",
+        "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": "Review the debrief as the candidate's coach. Step 1: cross-check every fix and strength against {{workPath}}/interview-transcript.md — FAIL any point that does not trace to an actual exchange. Step 2: check the tone — kind and concrete; FAIL generic advice ('be more confident') that names no moment and sketches no stronger answer. Step 3: confirm exactly one drill, actionable tonight. Step 4: confirm the readiness read is honest about whether another round is needed. Write PASS/FAIL per criterion.\n\nThe deliverable lives in the project's artifacts drawer — open `{{workPath}}/reports/interview-debrief.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: \"debrief\" })` to loop back. The builder fixes exactly those gaps.\n\nNever route to `finish` while any criterion is unmet. The build phase's completion gate already blocked a grossly-incomplete deliverable; your job is the judgment an automated check cannot make (does it actually work, read well, look right). After ~3 unproductive loops, stop and report DONE_WITH_CONCERNS so the user can step in.",
+      "suggestedRole": "reviewer",
+      "consumes": [
+        {
+          "file": "{{workPath}}/reports/interview-debrief.md",
+          "artifact": true
+        }
+      ],
+      "next": "debrief"
+    },
+    {
+      "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/mo/mock-interview/versions/1.0.2/test.json

@@ -0,0 +1,113 @@
+{
+  "schemaVersion": 1,
+  "title": "Mock Interview smoke eval",
+  "objective": "Self-contained smoke eval for the Mock Interview craftbook using the corpus generic harness.",
+  "tags": [
+    "corpus"
+  ],
+  "prompt": "We need a mock interview 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": "Mock Interview Eval",
+    "about": "Self-contained eval project for mock-interview. Seeded inputs are under workspace/source or workspace/fixtures; final deliverable is workspace/report.md.",
+    "missionObjectives": "Use the Mock Interview 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": "# Mock Interview 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: mock-interview - Mock Interview.\n"
+      }
+    ],
+    "worker": {
+      "name": "Jules",
+      "role": "Writer"
+    },
+    "craftbookParams": {
+      "workPath": "tasks/eval"
+    }
+  },
+  "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"
+  ]
+}