@bendyline/gilde 0.1.26 → 0.1.28

package/data/craftbook-templates/ht/html-arcade-game/versions/1.2.1/test.json

@@ -0,0 +1,176 @@
+{
+  "schemaVersion": 1,
+  "title": "Playable single-file arcade-game workflow",
+  "objective": "Run the HTML Arcade Game craftbook and verify concrete game/visual design artifacts precede a complete playable canvas game with end state and restart behavior.",
+  "tags": [
+    "html-game",
+    "workflow"
+  ],
+  "prompt": "Use the HTML Arcade Game craftbook. Read workspace `source/game-brief.md`, then build workspace `index.html` as a self-contained canvas game called Returns Rush. The player moves a sorting cart left/right, catches accepted parcels for points, avoids exception parcels that cost a life, wins at 10 points, loses at zero lives, and can restart in-page after either end state. Use keyboard controls, a visible score/lives HUD, inline CSS/JS, and no external assets. Complete game-design and visual-design artifacts before implementation.",
+  "setup": {
+    "projectName": "HTML Arcade Game Eval",
+    "about": "Self-contained workflow eval for the HTML Arcade Game craftbook. The brief is in the workspace, design deliverables belong in artifacts, and the playable game belongs at workspace/index.html.",
+    "missionObjectives": "Ship a playable Returns Rush canvas game with real input, score/lives state, win and lose states, restart behavior, visual feedback, and no external dependencies.",
+    "files": [
+      {
+        "path": "source/game-brief.md",
+        "content": "# Returns Rush Game Brief\n\nTheme: a busy returns desk sorting accepted parcels from exception parcels.\n\nRequired mechanics:\n- Move a sorting cart left and right with ArrowLeft/ArrowRight (A/D may also work).\n- Accepted parcels add one point.\n- Exception parcels remove one life.\n- Start with three lives.\n- Win at 10 points and lose at zero lives.\n- Show score, lives, controls, and current state on screen.\n- After win or game over, an in-page control restarts a fresh round.\n- Keep the game self-contained in one index.html with no network assets.\n"
+      }
+    ],
+    "worker": {
+      "name": "Jules",
+      "role": "Developer"
+    }
+  },
+  "mocks": [],
+  "success": {
+    "summary": "A craftbook task records game/visual designs and ships a parseable, substantial Returns Rush game with input, end states, and restart behavior.",
+    "deliverables": [
+      {
+        "path": "index.html",
+        "kind": "html-game",
+        "minBytes": 4200,
+        "checks": [
+          {
+            "kind": "cssMinBytes",
+            "bytes": 600,
+            "file": "index.html"
+          },
+          {
+            "kind": "jsParses",
+            "file": "index.html"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "<canvas\\b",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "Returns Rush|returns desk",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "ArrowLeft|ArrowRight|keydown"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "score[\\s\\S]*lives|lives[\\s\\S]*score",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "game\\s*-?\\s*over|you\\s+(?:win|lose)|victory|defeat",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "restart|play\\s*again|new\\s*game|try\\s*again",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "requestAnimationFrame"
+          }
+        ]
+      }
+    ],
+    "checks": [
+      {
+        "kind": "minBytes",
+        "file": "design/game-design.md",
+        "bytes": 600,
+        "artifact": true
+      },
+      {
+        "kind": "contains",
+        "file": "design/game-design.md",
+        "pattern": "(?:acceptance|criteria)[\\s\\S]*(?:control|input)[\\s\\S]*(?:win|lose|game over)",
+        "flags": "i",
+        "artifact": true
+      },
+      {
+        "kind": "minBytes",
+        "file": "design/visual-design.md",
+        "bytes": 450,
+        "artifact": true
+      },
+      {
+        "kind": "contains",
+        "file": "design/visual-design.md",
+        "pattern": "#[0-9a-f]{3,8}[\\s\\S]*(?:HUD|score|lives)",
+        "flags": "i",
+        "artifact": true
+      }
+    ],
+    "taskNotes": {
+      "minBytes": 160,
+      "checks": [
+        {
+          "kind": "contains",
+          "file": "task-notes.md",
+          "pattern": "game-design\\.md",
+          "flags": "i"
+        },
+        {
+          "kind": "contains",
+          "file": "task-notes.md",
+          "pattern": "visual-design\\.md",
+          "flags": "i"
+        },
+        {
+          "kind": "contains",
+          "file": "task-notes.md",
+          "pattern": "index\\.html",
+          "flags": "i"
+        }
+      ],
+      "requireCraftbookTask": true
+    },
+    "taskGraph": {
+      "requireCraftbookTask": true,
+      "requireTerminalStep": true
+    },
+    "unchangedFixtures": [
+      "source/game-brief.md"
+    ]
+  },
+  "rubric": {
+    "artifact": {
+      "path": "index.html",
+      "kind": "html"
+    },
+    "axes": [
+      {
+        "name": "playability",
+        "description": "Keyboard input moves the player, collisions change score/lives, and a round can reach both win and lose states."
+      },
+      {
+        "name": "completeness",
+        "description": "The game includes a real loop, visible HUD, end-state feedback, and a reliable fresh-round restart."
+      },
+      {
+        "name": "visual feedback",
+        "description": "The locked palette, readable game objects, HUD hierarchy, and collision/end-state feedback are applied intentionally."
+      },
+      {
+        "name": "workflow evidence",
+        "description": "The game and visual design artifacts are concrete and agree with the implementation."
+      }
+    ]
+  },
+  "qualityFocus": [
+    "craftbook attribution",
+    "design-before-build ordering",
+    "runtime playability",
+    "end-state and restart behavior"
+  ]
+}

package/data/craftbook-templates/ht/html-puzzle-game/versions/1.0.1/craftbook.json

@@ -0,0 +1,150 @@
+{
+  "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 `notes/game-design.md` (markdown-notes)\n2. Visual design (visual-designer) — grid look, tile states, feedback → gated on artifact `notes/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 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": "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 notes/visual-design.md and via write_task_note. No game logic 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 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 notes/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.1",
+  "releasedAt": "2026-08-14T00:00:00Z"
+}

package/data/craftbook-templates/ht/html-puzzle-game/versions/1.0.1/test.json

@@ -0,0 +1,99 @@
+{
+  "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"
+    }
+  },
+  "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/ic/icon-pack/versions/1.0.1/craftbook.json

@@ -0,0 +1,146 @@
+{
+  "id": "icon-pack",
+  "name": "Coherent Icon Pack",
+  "description": "Produce a coherent set of UI icons that look like they belong to one family — consistent grid, stroke weight, corner radius, optical sizing, and metaphor language — from a named list of concepts. Lock the style system (grid, stroke, padding, keyline shapes) BEFORE drawing any icon, because icon-set quality is almost entirely about consistency: a pack of individually-nice icons with mismatched strokes looks broken. Then generate every icon to the system and assemble a previewable sheet. Covers icon sets, UI icons, SVG icon libraries, glyph packs, and design systems.\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. Style scope (visual-designer) — lock grid, stroke, radius, padding, and the icon list → gated on artifact `notes/style-scope.md` (markdown-notes)\n2. Generate icons (image-generator) — draw every icon to the locked system → gated on `assets` (image-set)\n3. Assemble the sheet (developer) — preview grid + usage snippet → gated on `index.html` (html-page)\n\nThe gates never advance with an unmet criterion, and loop back to the\nowning phase to fix named gaps.\n",
+  "entryStepId": "style-scope",
+  "triggers": [
+    "make an icon pack",
+    "design a set of icons",
+    "ui icon set",
+    "consistent icons",
+    "svg icon library"
+  ],
+  "steps": [
+    {
+      "id": "style-scope",
+      "name": "Style scope",
+      "description": "lock grid, stroke, radius, padding, and the icon list",
+      "prompt": "1) Lock the icon system parameters: canvas/grid size (e.g. 24x24), uniform stroke weight (e.g. 2px), corner radius, end-cap style (round/square), and the safe padding/keyline so every glyph occupies the same optical area. 2) Decide outline vs filled and the metaphor language (e.g. minimal line icons). 3) Enumerate the EXACT icon list to produce (name each, e.g. home, search, settings, user, bell, trash) — aim for at least 6. 4) Write an acceptance-criteria checklist: 'all icons share the same grid and stroke weight', 'all use the same cap/join style', 'each icon is a valid standalone SVG', 'metaphors are conventional and recognizable', 'at least 6 icons produced'. 5) Record the system + list + checklist via write_task_note AND to notes/style-scope.md. No drawing yet.\n\nThe deliverable `notes/style-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": "visual-designer",
+      "advanceWhen": {
+        "file": "notes/style-scope.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "notes/style-scope.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "notes/style-scope.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "style-scope",
+        "maxAttempts": 3
+      },
+      "next": "generate"
+    },
+    {
+      "id": "generate",
+      "name": "Generate icons",
+      "description": "draw every icon to the locked system",
+      "prompt": "1) Read style-scope.md. 2) Author each icon as a standalone SVG on the locked grid (e.g. 24x24 viewBox) with the EXACT stroke weight, cap, and join from the system — set these as shared attributes, not per-path guesses. 3) Keep every glyph within the safe padding so they sit at matching optical weight. 4) Use conventional, instantly-recognizable metaphors. 5) Save each into assets/ as <name>.svg (matching the scoped list). 6) After drawing, eyeball them side by side and fix any that have a heavier stroke or odd padding. Good looks like: laid out in a row, they read as ONE family. Produce all named icons; do not skip any.",
+      "suggestedRole": "image-generator",
+      "advanceWhen": {
+        "file": "assets",
+        "minBytes": 1,
+        "sniff": "nonempty"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "fileCount",
+            "ext": [
+              "png",
+              "jpg",
+              "jpeg",
+              "svg",
+              "webp"
+            ],
+            "min": 3,
+            "dir": "assets"
+          }
+        ],
+        "onReject": "generate",
+        "maxAttempts": 3
+      },
+      "next": "assemble"
+    },
+    {
+      "id": "assemble",
+      "name": "Assemble the sheet",
+      "description": "preview grid + usage snippet",
+      "prompt": "1) Build a single index.html that lays every icon out in a uniform grid with its name label, rendered at the intended size and again at a small size (16px) to expose alignment drift. 2) Render each icon on both light and dark backgrounds to confirm the stroke color is themeable. 3) Include a one-line usage note (how to drop an SVG inline) and restate the grid/stroke spec. 4) Reference the real assets/*.svg files. 5) On a loop-back, fix only named gaps. 6) write_task_note the sheet path and icon count. Good looks like: a tidy preview where any inconsistency is obvious.",
+      "suggestedRole": "developer",
+      "consumes": [
+        {
+          "file": "assets"
+        }
+      ],
+      "advanceWhen": {
+        "file": "index.html",
+        "minBytes": 1,
+        "sniff": "html-complete"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "index.html",
+            "bytes": 800
+          },
+          {
+            "kind": "htmlLint",
+            "file": "index.html"
+          }
+        ],
+        "scripts": [
+          {
+            "name": "checkHtmlComplete",
+            "scope": "standard",
+            "inputs": {
+              "file": "index.html"
+            }
+          }
+        ],
+        "onReject": "assemble",
+        "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": "1) Confirm assets/ holds at least 6 valid SVG files matching the scoped names (PASS/FAIL). 2) Open index.html and inspect the grid at both sizes: do all icons share stroke weight, cap style, and optical padding (PASS/FAIL — this is the make-or-break criterion)? 3) Check each metaphor is conventional and recognizable. 4) Confirm icons render on light and dark backgrounds. 5) Write PASS/FAIL per criterion. Inconsistent stroke/grid → loop back to generate; presentation issues → assemble.\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: \"assemble\" })` 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": "assemble"
+    },
+    {
+      "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"
+}