@bendyline/gilde 0.1.26 → 0.1.28

package/data/craftbook-templates/bo/board-deck/versions/1.0.1/craftbook.json

@@ -0,0 +1,141 @@
+{
+  "id": "board-deck",
+  "name": "Board Meeting Deck",
+  "description": "Build a board-meeting deck that briefs directors efficiently — an executive summary up top, KPI dashboard, financials, progress against goals, key risks/asks, and an appendix — structured so a director gets the state of the business in minutes. Locks the standard board narrative and the metrics that matter FIRST (boards want a consistent dashboard, not a redesign every quarter), designs a dense data-forward slide system, then builds a navigable HTML deck where every slide leads with its number and the asks are unmistakable. Use for quarterly board meetings, board updates, and investor board reports.\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. Board narrative (planner) — lock the standard board slide order + the KPIs + the asks → gated on artifact `notes/narrative.md` (markdown-notes)\n2. Dashboard design (designer) — dense, data-forward slide system with status colors → gated on artifact `notes/design.md` (markdown-notes)\n3. Build the deck (developer) — implement index.html dashboard deck to the locked order + system → gated on `index.html` (slide-deck)\n\nThe gates never advance with an unmet criterion, and loop back to the\nowning phase to fix named gaps.\n",
+  "entryStepId": "narrative",
+  "triggers": [
+    "board deck",
+    "board meeting slides",
+    "board update deck",
+    "quarterly board deck",
+    "directors presentation",
+    "board report deck"
+  ],
+  "steps": [
+    {
+      "id": "narrative",
+      "name": "Board narrative",
+      "description": "lock the standard board slide order + the KPIs + the asks",
+      "prompt": "Structure the board story before any design — boards expect a consistent shape. Step 1: gather inputs: the period's headline, the KPIs that matter (with current vs target vs prior), financial summary (revenue, burn, runway), progress against the goals set last meeting, key risks, and the specific ASKS/decisions you need from the board. Step 2: lay out the canonical order: (1) title + period, (2) executive summary / TL;DR, (3) KPI dashboard, (4) financials + runway, (5) progress against last quarter's goals, (6) key risks + mitigations, (7) asks/decisions needed, (8) appendix. Step 3: for each KPI decide current value, comparison, and status (on/off track). Step 4: write the explicit asks as decisions the board must make. Step 5: write an acceptance-criteria checklist ('opens with an executive summary slide', 'KPI dashboard shows current vs target/prior with status', 'financials include runway', 'progress slide references last quarter's goals', 'a dedicated asks/decisions slide states what is needed', 'one topic per slide'). Write the slide-by-slide outline + metrics + checklist via write_task_note AND to notes/narrative.md. No design or HTML yet.\n\nThe deliverable `notes/narrative.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/narrative.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "notes/narrative.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "notes/narrative.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "narrative",
+        "maxAttempts": 3
+      },
+      "next": "design"
+    },
+    {
+      "id": "design",
+      "name": "Dashboard design",
+      "description": "dense, data-forward slide system with status colors",
+      "prompt": "Design a data-forward slide system suited to dense board content. Step 1: pick a restrained, serious palette with exact hex plus a clear status scale (on-track / at-risk / off-track colors used consistently). Step 2: define the grid: title + period in a header, a footer with slide number and confidentiality label, and a content zone that can hold a KPI grid or a metrics table without feeling cramped. Step 3: define slide archetypes: an executive-summary slide, a KPI dashboard (a grid of metric cards: label, big value, comparison, status dot), a financials slide (table + runway callout), a progress slide (goal -> status rows), a risks slide, and an asks slide that visually stands out. Step 4: ensure big numbers and statuses are scannable at a glance. Step 5: write a visual-criteria checklist ('consistent status colors throughout', 'KPI values are visually dominant', 'every slide has header period + footer slide number', 'asks slide visually distinct'). Write the slide-system spec + checklist via write_task_note AND to notes/design.md. No content yet.\n\nThe deliverable `notes/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": "designer",
+      "advanceWhen": {
+        "file": "notes/design.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "notes/design.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "notes/design.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "design",
+        "maxAttempts": 3
+      },
+      "next": "build"
+    },
+    {
+      "id": "build",
+      "name": "Build the deck",
+      "description": "implement index.html dashboard deck to the locked order + system",
+      "prompt": "Implement the board deck as a single self-contained index.html (inline CSS + minimal JS, no external assets). Step 1: create one full-viewport section per slide in the locked board order. Step 2: apply the design system exactly — palette hex, the status color scale used consistently, header with period and footer with slide number + confidentiality label on every slide. Step 3: render the KPI dashboard as a grid of metric cards (label, dominant value, vs target/prior, status dot) and the financials slide with a table + a runway callout. Step 4: render the progress slide as goal -> status rows and make the asks/decisions slide visually distinct so directors cannot miss what is needed. Step 5: wire arrow-key navigation and visible slide numbers. Drop the approved numbers/content in verbatim; do not invent metrics. On a loop-back, fix ONLY the named gaps. Write the deck path + slide count via write_task_note.",
+      "suggestedRole": "developer",
+      "advanceWhen": {
+        "file": "index.html",
+        "minBytes": 1,
+        "sniff": "nonempty"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "index.html",
+            "bytes": 600
+          }
+        ],
+        "scripts": [
+          {
+            "name": "checkContains",
+            "scope": "standard",
+            "inputs": {
+              "file": "index.html",
+              "pattern": "(?:slide|section|^---$)",
+              "flags": "im"
+            }
+          }
+        ],
+        "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": "QA the board deck against the locked criteria. Step 1: open/render index.html and step through every slide with the arrow keys. Step 2: verify the board order (title -> exec summary -> KPI dashboard -> financials -> progress -> risks -> asks -> appendix). Step 3: check EACH acceptance criterion: opens with an executive summary, the KPI dashboard shows current vs target/prior with a consistent status color scale and dominant values, financials include runway, the progress slide references last quarter's goals, a dedicated asks/decisions slide clearly states what the board must decide and is visually distinct, every slide has the period header + slide-number footer, and there is one topic per slide. Step 4: confirm no metrics were invented beyond the outline. Write PASS/FAIL per criterion with the offending slide on any FAIL.\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/bo/board-deck/versions/1.0.1/test.json

@@ -0,0 +1,100 @@
+{
+  "schemaVersion": 1,
+  "title": "Board-meeting HTML deck",
+  "objective": "Measure whether the board-deck craftbook locks the board narrative and builds a dense navigable deck with KPIs, financials, risks, asks, and appendix.",
+  "tags": [
+    "html-page"
+  ],
+  "prompt": "In the `Board Deck Eval` project, read `source/board-brief.md` and build `index.html`: a navigable Q2 board deck for Harbor & Finch with executive summary, KPI dashboard, financials, goals progress, risks, board asks, and appendix. Every slide should have a slide number and clear title. Vanilla HTML/CSS/JS only.",
+  "setup": {
+    "projectName": "Board Deck Eval",
+    "about": "Self-contained eval project for the board-deck craftbook. Board brief facts are in workspace/source/board-brief.md.",
+    "missionObjectives": "Build a navigable board deck with executive summary, KPI dashboard, financials, goals progress, risks, asks, appendix, slide numbers, and visual hierarchy.",
+    "files": [
+      {
+        "path": "source/board-brief.md",
+        "content": "# Q2 Board Brief\n\nCompany: Harbor & Finch.\nRevenue: $4.8M Q2, up 18% QoQ. Gross margin: 41%. Cash runway: 14 months.\nKPIs: first response 6 hours, refund leakage 8.9%, warehouse SLA 96%, NPS 42.\nGoals: returns automation pilot complete in West; East rollout pending Finance exception export.\nRisks: carrier scan delays in Zone 5; Monday photo-review queue exceeds SLA.\nBoard asks: approve $220K automation budget and endorse East warehouse rollout.\nAppendix: metric definitions and pilot scope.\n"
+      }
+    ],
+    "worker": {
+      "name": "Liv",
+      "role": "Developer"
+    }
+  },
+  "mocks": [],
+  "success": {
+    "summary": "workspace/index.html is a navigable board deck with the required board sections, seeded numbers, slide numbers, and controls.",
+    "deliverables": [
+      {
+        "path": "index.html",
+        "kind": "slide-deck",
+        "minBytes": 4200,
+        "checks": [
+          {
+            "kind": "cssMinBytes",
+            "bytes": 900,
+            "file": "index.html"
+          },
+          {
+            "kind": "jsParses",
+            "file": "index.html"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "Executive summary|KPI|Financials|Goals|Risks|Board asks|Appendix",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "\\$4\\.8M|18%|41%|14 months|8\\.9%|96%|NPS 42",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "\\$220K|East warehouse rollout|Zone 5",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "slide\\s*\\d|next|previous|keydown|arrow",
+            "flags": "i"
+          }
+        ]
+      }
+    ]
+  },
+  "rubric": {
+    "artifact": {
+      "path": "index.html",
+      "kind": "html"
+    },
+    "axes": [
+      {
+        "name": "structure",
+        "description": "Layout and hierarchy fit the content; sections are scannable and coherent."
+      },
+      {
+        "name": "grounding",
+        "description": "Seeded source content is used faithfully — no invented facts or dropped requirements."
+      },
+      {
+        "name": "interactivity",
+        "description": "Controls and states the page claims to offer actually work."
+      },
+      {
+        "name": "polish",
+        "description": "Styling is intentional and responsive rather than unstyled or broken."
+      }
+    ]
+  },
+  "qualityFocus": [
+    "board narrative",
+    "KPI/financial density",
+    "asks and risks",
+    "deck navigation"
+  ]
+}

package/data/craftbook-templates/bo/board-game-web/versions/1.0.1/craftbook.json

@@ -0,0 +1,150 @@
+{
+  "id": "board-game-web",
+  "name": "Digital Board Game",
+  "description": "Build a single-file web version of a turn-based board game such as tic-tac-toe, checkers, connect-four, reversi, or a simple chess variant, with two-player hotseat or a basic AI opponent. Locks the rules, turn order, legal-move set, and win/draw detection first, then the board visual language, then implements an authoritative turn state machine. Board games demand correct turn alternation and exhaustive win/draw detection, so the rules phase enumerates every terminal condition before rendering — the ordering that stops a small model from shipping a board where turns desync or a win goes unnoticed.\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. Rules design (game-designer) — turn order, legal moves, win/draw detection → gated on artifact `notes/rules-design.md` (markdown-notes)\n2. Visual design (visual-designer) — board look, pieces, turn indicator → gated on artifact `notes/visual-design.md` (markdown-notes)\n3. Build (developer) — implement the turn state machine 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": "rules-design",
+  "triggers": [
+    "board game",
+    "tic tac toe",
+    "connect four",
+    "checkers",
+    "make chess",
+    "two player game"
+  ],
+  "steps": [
+    {
+      "id": "rules-design",
+      "name": "Rules design",
+      "description": "turn order, legal moves, win/draw detection",
+      "prompt": "Pin the RULES of the board game. (1) State the board size and pieces. (2) Define turn order and how the active player alternates. (3) Enumerate legal moves per piece and what makes a move illegal. (4) List EVERY terminal condition: each win pattern, draw/stalemate, and how each is detected from board state. (5) Decide the opponent: hotseat two-player, or a simple AI (random or one-ply) — state which. (6) Write an acceptance-criteria checklist of 5-8 items, e.g. 'players strictly alternate', 'illegal moves are rejected', 'every win line is detected and announced', 'a full board with no winner declares a draw', 'a new-game button resets cleanly', 'no console errors'. Write to notes/rules-design.md and via write_task_note. No code yet.\n\nThe deliverable `notes/rules-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/rules-design.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "notes/rules-design.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "notes/rules-design.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "rules-design",
+        "maxAttempts": 3
+      },
+      "next": "visual-design"
+    },
+    {
+      "id": "visual-design",
+      "name": "Visual design",
+      "description": "board look, pieces, turn indicator",
+      "prompt": "Design the board look from the locked rules. (1) Choose a palette (hex) and the board grid styling. (2) Specify how each piece/player renders (X vs O, red vs black discs, glyphs). (3) Show the active-player turn indicator and how a winning line is highlighted. (4) Lay out status text (whose turn, win/draw banner) and a new-game button. (5) Keep it self-contained 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 the turn state machine in index.html",
+      "prompt": "Implement the board game in a single index.html (inline CSS + JS) to the visual spec, satisfying every criterion. (1) Model board state and a currentPlayer variable. (2) On a cell/piece interaction, validate the move, apply it, then check all terminal conditions before switching the active player. (3) Announce win (highlighting the line) or draw and lock further input until new-game. (4) If an AI was specified, have it move after the human. (5) Wire a new-game button that fully resets. Vanilla JS, 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 several full games. Open index.html if possible, else trace the turn and win logic. Check EACH criterion from notes/rules-design.md and write PASS/FAIL with a reason: do players strictly alternate, are illegal moves rejected, is every win line detected, does a full no-winner board declare a draw, does new-game reset, zero console errors? Force at least one win and one draw to confirm both fire. Any missed terminal condition is a FAIL — 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/bo/board-game-web/versions/1.0.1/test.json

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