@bendyline/gilde 0.1.38 → 0.1.39

package/data/craftbook-templates/ho/hotfix-flow/versions/1.0.2/craftbook.json

@@ -0,0 +1,194 @@
+{
+  "id": "hotfix-flow",
+  "name": "Hotfix Flow",
+  "description": "Drive an expedited production hotfix from red to green: reproduce the live defect with a failing test, apply the smallest safe fix that makes it pass without scope-creeping into a refactor, and verify the fix plus a clean regression check before it ships out-of-band. The ordering is the whole discipline — reproduce FIRST (a failing test that captures the bug is the contract the fix must satisfy), then fix minimally, then verify the new test passes and nothing else broke. Use this for urgent production bugs, expedited patch releases, and out-of-band fixes where speed matters but a regression would be worse than the original bug.\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. Reproduce with a failing test (developer) — capture the live defect as a failing, deterministic test → gated on artifact `{{workPath}}/reproduce.md` (markdown-notes)\n2. Apply the minimal fix (developer) — smallest safe change that turns the failing test green → gated on `hotfix.ts` (code-with-tests)\n3. Verify and regression-check (reviewer) — confirm green plus no regressions before shipping → gated on artifact `{{workPath}}/verify.md` (markdown-notes)\n\nThe gates never advance with an unmet criterion, and loop back to the\nowning phase to fix named gaps.\n",
+  "entryStepId": "reproduce",
+  "triggers": [
+    "hotfix this bug",
+    "urgent production fix",
+    "expedited patch",
+    "fix the live defect",
+    "out-of-band fix"
+  ],
+  "steps": [
+    {
+      "id": "reproduce",
+      "name": "Reproduce with a failing test",
+      "description": "capture the live defect as a failing, deterministic test",
+      "prompt": "1. Read the bug report / incident and state the exact observed behavior vs the expected behavior in one line each. 2. Identify the smallest input or scenario that triggers the defect. 3. Write a NEW automated test that exercises that scenario and asserts the EXPECTED (correct) behavior — so it fails RED against current code for the right reason (it reproduces THIS bug, not some unrelated assertion). 4. Run the test and confirm it fails, capturing the failure output as proof of reproduction. 5. Do NOT fix anything yet and do NOT alter unrelated code. 6. Good looks like: one focused, deterministic failing test that pins the defect, plus the captured red output. Write an acceptance-criteria checklist ('a new test reproduces the bug and fails red', 'the test asserts correct behavior not the buggy behavior', 'the test is deterministic and minimal', 'the fix will be the smallest change that turns it green', 'full suite must stay green after the fix') plus the observed/expected behavior and the test location to the notes file via write_task_note AND to {{workPath}}/reproduce.md.\n\nThe deliverable `{{workPath}}/reproduce.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": "{{workPath}}/reproduce.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "{{workPath}}/reproduce.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "{{workPath}}/reproduce.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "reproduce",
+        "maxAttempts": 3
+      },
+      "next": "fix"
+    },
+    {
+      "id": "fix",
+      "name": "Apply the minimal fix",
+      "description": "smallest safe change that turns the failing test green",
+      "prompt": "1. Open {{workPath}}/reproduce.md and make the SMALLEST change that turns the reproducing test green — fix the root cause, not the symptom, but resist refactoring, renaming, or unrelated cleanup (this is a hotfix, not a rewrite). 2. Keep the diff tight and reviewable; touch only what the fix requires. 3. Run the reproducing test and confirm it now passes GREEN; capture the output. 4. If the fix needs a follow-up (a deeper refactor, tech-debt), note it as a separate item rather than doing it now. 5. Implement the fix and the reproducing test together in the deliverable file so the change is self-verifying. 6. Good looks like: a minimal diff that makes the new test pass for the right reason, with no scope creep. Write the fix plus the reproducing test (the source/test module that now passes) to hotfix.ts.\n\nBefore working, open the artifact input `{{workPath}}/reproduce.md` with `read_artifact`; do not look for it in the workspace.",
+      "suggestedRole": "developer",
+      "consumes": [
+        {
+          "file": "{{workPath}}/reproduce.md",
+          "artifact": true
+        }
+      ],
+      "advanceWhen": {
+        "file": "hotfix.ts",
+        "minBytes": 1,
+        "sniff": "nonempty"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "hotfix.ts",
+            "bytes": 300
+          },
+          {
+            "kind": "sniff",
+            "file": "hotfix.ts",
+            "sniff": "nonempty"
+          },
+          {
+            "kind": "esmImports",
+            "file": "hotfix.ts"
+          },
+          {
+            "kind": "sourceParses",
+            "file": "hotfix.ts"
+          }
+        ],
+        "scripts": [
+          {
+            "name": "checkContains",
+            "scope": "standard",
+            "inputs": {
+              "file": "hotfix.ts",
+              "pattern": "\\b(test|describe|it|assert|expect)\\b",
+              "flags": "i"
+            }
+          }
+        ],
+        "onReject": "fix",
+        "maxAttempts": 3
+      },
+      "next": "verify"
+    },
+    {
+      "id": "verify",
+      "name": "Verify and regression-check",
+      "description": "confirm green plus no regressions before shipping",
+      "prompt": "1. Run the reproducing test and confirm it now passes GREEN. 2. Run the FULL relevant test suite and confirm nothing else broke — a hotfix that fixes one bug and regresses another is a failure. 3. Review the diff for scope creep: confirm the change is minimal and addresses the root cause described in {{workPath}}/reproduce.md, not a symptom patch. 4. Sanity-check edge cases adjacent to the fix that a single test might miss. 5. Write a PASS/FAIL per acceptance criterion from reproduce.md, with the test output as evidence and any regression or over-reach called out. 6. Any failure routes back to the fix phase. Write findings to {{workPath}}/verify.md.\n\nBefore working, open the artifact input `{{workPath}}/reproduce.md` with `read_artifact`; do not look for it in the workspace.\n\nThe deliverable `{{workPath}}/verify.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": "{{workPath}}/reproduce.md",
+          "artifact": true
+        }
+      ],
+      "advanceWhen": {
+        "file": "{{workPath}}/verify.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "hotfix.ts",
+            "bytes": 300
+          },
+          {
+            "kind": "sniff",
+            "file": "hotfix.ts",
+            "sniff": "nonempty"
+          },
+          {
+            "kind": "esmImports",
+            "file": "hotfix.ts"
+          },
+          {
+            "kind": "sourceParses",
+            "file": "hotfix.ts"
+          }
+        ],
+        "scripts": [
+          {
+            "name": "checkContains",
+            "scope": "standard",
+            "inputs": {
+              "file": "hotfix.ts",
+              "pattern": "\\b(test|describe|it|assert|expect)\\b",
+              "flags": "i"
+            }
+          }
+        ],
+        "onReject": "verify",
+        "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 hotfix.ts and verify it against the criteria in {{workPath}}/reproduce.md, PASS/FAIL each. Confirm: (a) it contains a test that reproduces the reported bug by asserting the correct behavior; (b) that test passes GREEN against the fix; (c) the fix is minimal and targets the root cause with no unrelated refactor/scope-creep; (d) the change does not regress adjacent behavior (the broader suite stays green); (e) the test is deterministic. Run/trace the test to gather evidence. Any FAIL routes back to the fix phase.\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: \"fix\" })` 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": "hotfix.ts"
+        }
+      ],
+      "next": "fix"
+    },
+    {
+      "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/ho/hotfix-flow/versions/1.0.2/test.json

@@ -0,0 +1,95 @@
+{
+  "schemaVersion": 1,
+  "title": "Hotfix Flow smoke eval",
+  "objective": "Self-contained smoke eval for the Hotfix Flow 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": "Hotfix Flow Eval",
+    "about": "Self-contained eval project for hotfix-flow. Seeded inputs are under workspace/source or workspace/fixtures; final deliverable is workspace/src/solution.mjs.",
+    "missionObjectives": "Use the Hotfix Flow 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": "# Hotfix Flow 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: hotfix-flow - Hotfix Flow.\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/ht/html-puzzle-game/versions/1.0.2/craftbook.json

@@ -0,0 +1,162 @@
+{
+  "id": "html-puzzle-game",
+  "name": "HTML Puzzle Game",
+  "description": "Build a single-file HTML logic or puzzle game such as a match-3, sliding tile, Sokoban, 2048, minesweeper, or sudoku. Locks the rule system, the solve/fail condition, and the win detection first, then a clean grid visual language, then implements deterministic board state with valid-move enforcement. Puzzle games live or die on correct rules and reliable win detection, so the design phase pins the exact legal-move and victory logic before any rendering — the ordering that prevents a small model from shipping a grid that looks right but never registers a win.\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) — rules, legal moves, win/fail detection → gated on artifact `{{workPath}}/game-design.md` (markdown-notes)\n2. Visual design (visual-designer) — grid look, tile states, feedback → gated on artifact `{{workPath}}/visual-design.md` (markdown-notes)\n3. Build (developer) — implement board state + move rules in 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": "game-design",
+  "triggers": [
+    "puzzle game",
+    "logic game",
+    "make a 2048",
+    "sliding puzzle",
+    "match three game",
+    "sudoku"
+  ],
+  "steps": [
+    {
+      "id": "game-design",
+      "name": "Game design",
+      "description": "rules, legal moves, win/fail detection",
+      "prompt": "Specify the PUZZLE precisely. (1) State the board: dimensions and what each cell can hold. (2) Enumerate the legal moves and the exact rule that makes a move valid or invalid. (3) Define the win condition as a checkable predicate over board state (e.g. 'a tile reaches 2048', 'every mine is flagged and every safe cell revealed') and the fail/stuck condition if any. (4) Describe the initial state and how a new puzzle is generated or shuffled so it is solvable. (5) Write an acceptance-criteria checklist of 5-8 binary items, e.g. 'illegal moves are rejected with no state change', 'a win triggers a visible win message', 'the board reshuffles on new-game', 'score/move-count updates each move', 'no console errors during a full solve'. Write it to {{workPath}}/game-design.md and via write_task_note. No code yet.\n\nThe deliverable `{{workPath}}/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": "{{workPath}}/game-design.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "{{workPath}}/game-design.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "{{workPath}}/game-design.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "game-design",
+        "maxAttempts": 3
+      },
+      "next": "visual-design"
+    },
+    {
+      "id": "visual-design",
+      "name": "Visual design",
+      "description": "grid look, tile states, feedback",
+      "prompt": "Design the grid look from the locked rules. (1) Choose a palette (hex) and how each cell value or state maps to a color/glyph. (2) Specify the grid layout, cell sizing, gaps, and how the board stays square and centered. (3) Define visual feedback: selected cell, invalid-move shake, merge/clear animation, and the win banner. (4) Lay out the HUD (score, moves, timer, new-game button) and the typography. (5) Keep it self-contained with CSS grid or canvas — no external assets. Write the visual spec to {{workPath}}/visual-design.md and via write_task_note. No game logic yet.\n\nThe deliverable `{{workPath}}/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": "{{workPath}}/visual-design.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "{{workPath}}/visual-design.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "{{workPath}}/visual-design.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "visual-design",
+        "maxAttempts": 3
+      },
+      "next": "build"
+    },
+    {
+      "id": "build",
+      "name": "Build",
+      "description": "implement board state + move rules in index.html",
+      "prompt": "Implement the puzzle in a single index.html (inline CSS + JS) matching the visual spec and satisfying every criterion. (1) Model the board as a 2D array or flat array; render it to a CSS grid or canvas. (2) Implement the legal-move function so illegal inputs change nothing. (3) Implement the win predicate and check it after every move; show the win banner when true. (4) Wire input (clicks, drags, or arrow keys as designed) and a new-game button that reshuffles to a solvable state. (5) Update the HUD each move. Vanilla JS only, no CDN. 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 puzzle. Open index.html if a browser is available, otherwise trace the move and win logic in source. Check EACH criterion from {{workPath}}/game-design.md and write PASS/FAIL with a reason: are illegal moves truly rejected, does a real solve trigger the win message, does new-game reshuffle solvably, does the HUD update, are there zero console errors? Most important: drive the board to a winning state and confirm the win actually fires — if it never does, FAIL and loop back.\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/ht/html-puzzle-game/versions/1.0.2/test.json

@@ -0,0 +1,102 @@
+{
+  "schemaVersion": 1,
+  "title": "HTML Puzzle Game smoke eval",
+  "objective": "Self-contained smoke eval for the HTML Puzzle Game 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": "HTML Puzzle Game Eval",
+    "about": "Self-contained eval project for html-puzzle-game. Seeded inputs are under workspace/source or workspace/fixtures; final deliverable is workspace/index.html.",
+    "missionObjectives": "Use the HTML Puzzle Game 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": "# HTML Puzzle Game 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: html-puzzle-game - HTML Puzzle Game.\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"
+  ]
+}