@bendyline/gilde 0.1.4 → 0.1.5

package/data/craftbook-templates/bu/build-loop/versions/1.1.0/craftbook.json

@@ -0,0 +1,65 @@
+{
+  "id": "build-loop",
+  "name": "Build Loop",
+  "description": "A generic **make-something** procedure: `build → evaluate → (loop) → finish`.\n\nIt exists for the common case where the user wants a thing built (\"make an arcade game\", \"build a landing page\", \"write a script that does X\") and no domain-specific craftbook fits better. It gives a small/medium model the thing it loses on multi-phase work: a **durable structure with a gate** — so it drives one deliverable to a checkable bar instead of declaring victory early.\n\n## How the loop works\n\n1. **Build** (developer) first writes an **acceptance-criteria checklist** to task notes, then builds the deliverable to meet it. For a web build that's `index.html`.\n2. **Evaluate** (reviewer) grades the deliverable against every criterion and routes: all pass → `advance_task_step(next: \"finish\")`; any fail → write the gaps → `advance_task_step(next: \"build\")` to loop back.\n3. **Finish** stamps a DONE summary.\n\nEvaluate's default forward edge loops back to **Build**, not Finish — so the safe failure mode is \"keep improving\", never \"ship half-done\".\n\n## Advancement rides on the deliverable, not a meta-tool call\n\nThe Build step declares an `advanceWhen` contract: when a complete `index.html` lands (clears a size floor + a non-truncation `html-complete` sniff), the runtime advances Build → Evaluate **automatically**, without the model calling `advance_task_step`. This is deliberate: models reliably *do work* (`write_file`) but reliably *skip* the meta-navigation tool — two eval runs (gemma4-31b, gemma4-e4b-q8) produced the deliverable and advanced **zero** steps. Observable-progress auto-advance closes that gap. For a non-`index.html` deliverable the auto-advance is a no-op and Build advances model-driven (its prompt says so).\n\n## Why criteria-first matters for small models\n\nThe acceptance-criteria checklist is the scaffold. Without it a weak model declares victory early; with it, \"is this good?\" becomes \"does criterion 4 pass?\" — answerable even by a small model, and the thing the gate and the next loop iteration check against.\n\n## Specific books beat this one\n\nThis is the **fallback**. A domain craftbook earns its keep by encoding things this generic shape can't: the right *specialist role per phase* (a space-shooter splits design into a game-designer and a visual-designer) and the *domain-correct ordering* (a branding site locks a visual language before any HTML). When selection finds a specific match, prefer it; fall back to Build Loop when nothing fits. In a **solo** project the meester pins this book with every step collapsed onto the one specialist (it can't recruit); in a **crew** project it pins the matching multi-role gallery book instead.\n\n## Roles are suggestions\n\n`build → developer`, `evaluate → reviewer` are `suggestedRole` hints resolved via `ensureGezel`; domain gallery books override them (game-designer, visual-designer, copywriter, …).\n\n## Next: an automated evaluate gate\n\nEvaluate is still reviewer-gated (a gezel grades + routes). The follow-up replaces its routing with a script that judges and advances deterministically — now reachable because observable-advance gets the workflow *to* Evaluate without depending on the model to navigate there.\n",
+  "entryStepId": "build",
+  "steps": [
+    {
+      "id": "build",
+      "name": "Build",
+      "description": "Lock concrete acceptance criteria, then build the deliverable to meet them. The workflow advances to Evaluate automatically when the deliverable lands.",
+      "prompt": "**Two things, in order.**\n\n1. **Lock the bar.** Write an **acceptance-criteria checklist** to task notes via `write_task_note` — 4-8 concrete, checkable statements that define \"good enough\" (e.g. \"clicking Start begins play\", \"score increments on a hit\", \"page loads with no console error\"). This is the contract Evaluate grades against; without it the loop has no target.\n2. **Build it.** Create the real deliverable with your file-writing capability, to satisfy every criterion. For a web build that's `index.html` (inline CSS + JS, no build step). On a loop-back from Evaluate, read the gaps in notes and fix ONLY those — don't regress criteria that already passed.\n\n**Advancing:** the workflow moves you to Evaluate automatically when you actually WRITE `index.html` this turn — you do NOT need to call `advance_task_step`. On a loop-back, narrating the gaps is not enough: the step holds until you make a real edit to `index.html`. For any other deliverable path, write the file, then call `advance_task_step({ ref, stepId: \"build\", next: \"evaluate\" })` yourself.",
+      "suggestedRole": "developer",
+      "advanceWhen": {
+        "file": "index.html",
+        "minBytes": 800,
+        "sniff": "html-complete",
+        "requireChange": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "index.html",
+            "bytes": 2048
+          },
+          {
+            "kind": "jsParses",
+            "file": "index.html"
+          }
+        ],
+        "scripts": [
+          {
+            "name": "checkHtmlComplete",
+            "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 → write the gaps and loop back to Build.",
+      "prompt": "**You are the gate. Judge, then route — do not build here.**\n\n1. `read_task_notes({ ref })` for the acceptance-criteria checklist + the deliverable path.\n2. Open the deliverable and check it against each criterion (exercise it in a browser/with a test capability if the project has one — don't grade from source alone when you can observe behavior). Write a PASS/FAIL per criterion to notes.\n\nThen route:\n\n- **Every criterion PASSES →** `advance_task_step({ ref, stepId: \"evaluate\", next: \"finish\" })`.\n- **Any criterion FAILS →** write the specific gaps to notes, then `advance_task_step({ ref, stepId: \"evaluate\", next: \"build\" })` to loop back.\n\nNever route to `finish` with an unmet criterion — under-delivering is the failure this gate exists to catch. After ~3 unproductive loops, stop and report DONE_WITH_CONCERNS so the user can step in.",
+      "suggestedRole": "reviewer",
+      "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.1.0",
+  "releasedAt": "2026-07-28T00:00:00Z"
+}

package/data/craftbook-templates/bu/build-loop/versions/1.1.0/test.json

@@ -0,0 +1,121 @@
+{
+  "schemaVersion": 1,
+  "title": "Generic build-evaluate loop",
+  "objective": "Measure whether the fallback build-loop craftbook creates acceptance criteria, builds a complete interactive deliverable, and iterates through deterministic gates.",
+  "tags": [
+    "external"
+  ],
+  "prompt": "In the `Build Loop Eval` project, build a self-contained `index.html` checklist timer for a small workshop. It must let a facilitator add agenda items, mark items done, start/pause a countdown timer, reset the timer, show remaining time, and display a completion summary. Lock acceptance criteria in task notes first, then build the page with inline CSS/JS and no external assets.",
+  "setup": {
+    "projectName": "Build Loop Eval",
+    "about": "Self-contained eval project for the build-loop craftbook. The deliverable is workspace/index.html.",
+    "missionObjectives": "Build an interactive checklist timer with acceptance criteria, add/complete agenda behavior, start/pause/reset timer, remaining time display, and completion summary.",
+    "files": [],
+    "worker": {
+      "name": "Bram",
+      "role": "Developer"
+    }
+  },
+  "mocks": [],
+  "success": {
+    "summary": "workspace/index.html is a complete interactive checklist timer with substantial JS/CSS and task notes show the criteria-first loop was used.",
+    "deliverables": [
+      {
+        "path": "index.html",
+        "kind": "html-page",
+        "minBytes": 3200,
+        "checks": [
+          {
+            "kind": "cssMinBytes",
+            "bytes": 650,
+            "file": "index.html"
+          },
+          {
+            "kind": "jsParses",
+            "file": "index.html"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "agenda|checklist",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "start|pause|reset",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "remaining|countdown|timer",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "complete|summary",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "addEventListener|setInterval",
+            "flags": "i"
+          }
+        ]
+      }
+    ],
+    "taskNotes": {
+      "minBytes": 160,
+      "checks": [
+        {
+          "kind": "contains",
+          "file": "task-notes.md",
+          "pattern": "acceptance criteria|criteria checklist",
+          "flags": "i"
+        }
+      ]
+    }
+  },
+  "rubric": {
+    "artifact": {
+      "path": "index.html",
+      "kind": "html"
+    },
+    "axes": [
+      {
+        "name": "safety",
+        "description": "Dry-run posture is explicit: no real credentials, clear stop-before-side-effect boundary."
+      },
+      {
+        "name": "mapping",
+        "description": "Fake endpoints/commands are mapped completely to the workflow steps."
+      },
+      {
+        "name": "signals",
+        "description": "Success, failure, retry, and abort conditions are all defined."
+      },
+      {
+        "name": "containment",
+        "description": "The plan cannot accidentally reach a real service from a mock context."
+      }
+    ]
+  },
+  "qualityFocus": [
+    "criteria-first build",
+    "loop behavior",
+    "interactive HTML gates"
+  ],
+  "extensions": {
+    "legacySimulators": [
+      {
+        "id": "build-loop-fake-service-fixture",
+        "kind": "data-source",
+        "status": "implemented",
+        "description": "Seeded local fake service contract replacing live CLIs, HTTP APIs, credentials, and side effects."
+      }
+    ]
+  }
+}

package/data/craftbook-templates/ch/character-sheet/versions/1.0.0/test.json

@@ -31,8 +31,7 @@
           "png"
         ],
         "min": 4,
-        "dir": "characters/pip",
-        "verifyImageBytes": true
+        "dir": "characters/pip"
       }
     ],
     "deliverables": [

package/data/craftbook-templates/ch/character-turnaround/versions/1.0.0/test.json

@@ -43,8 +43,7 @@
           "png"
         ],
         "min": 4,
-        "dir": "assets/characters/knight",
-        "verifyImageBytes": true
+        "dir": "assets/characters/knight"
       }
     ],
     "deliverables": [

package/data/craftbook-templates/cl/cli-tool/versions/1.1.0/craftbook.json

@@ -0,0 +1,139 @@
+{
+  "id": "cli-tool",
+  "name": "Command-Line Tool",
+  "description": "Build a command-line tool with subcommands, flags, arguments, help text, and proper exit codes. Designs the CLI UX FIRST — the command surface, flags with defaults, positional args, help/usage output, and exit-code conventions — because a CLI's contract is its interface, then implements argument parsing and command logic, then writes tests for parsing, help, happy paths, and error exits. Covers argv parsing, subcommands, --flags and -short forms, --help, stdin/stdout/stderr conventions, and non-zero exit codes on error.\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\nPhases:\n\n1. CLI UX scope (planner) — lock the command surface, flags, args, exit codes → gated on `notes/ux-scope.md` (markdown-notes)\n2. Build the CLI (developer) — implement parsing + command logic → gated on `src/cli.js` (code-module)\n3. Write CLI tests (developer) — test parsing, help, happy paths, error exits → gated on `src/cli.test.js` (code-with-tests)\n\nThe gates never advance with an unmet criterion, and loop back to the\nowning phase to fix named gaps.\n",
+  "entryStepId": "ux-scope",
+  "triggers": [
+    "build a cli tool",
+    "command line tool",
+    "make a terminal command",
+    "cli with subcommands",
+    "argv parser"
+  ],
+  "steps": [
+    {
+      "id": "ux-scope",
+      "name": "CLI UX scope",
+      "description": "lock the command surface, flags, args, exit codes",
+      "prompt": "Design the command-line interface before any logic — the interface IS the contract. Step 1: Enumerate the commands/subcommands and what each does. Step 2: For each, list the positional arguments (required vs optional) and the flags (`--long`, `-s` short form, type, default value, whether it takes a value). Step 3: Draft the exact `--help`/usage text the tool prints, including a one-line synopsis per command. Step 4: Define the IO and exit-code contract: what goes to stdout vs stderr, exit 0 on success, distinct non-zero codes for usage errors vs runtime errors. Step 5: Write a numbered acceptance-criteria checklist of 5-9 items (e.g. 'running with no args or --help prints usage and exits 0', 'an unknown flag prints an error to stderr and exits non-zero', 'the primary command produces the documented output'). `write_task_note` the command spec + checklist and write the same to the produces path. No implementation yet.",
+      "suggestedRole": "planner",
+      "advanceWhen": {
+        "file": "notes/ux-scope.md",
+        "minBytes": 1,
+        "sniff": "nonempty"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "notes/ux-scope.md",
+            "bytes": 120
+          },
+          {
+            "kind": "sniff",
+            "file": "notes/ux-scope.md",
+            "sniff": "nonempty"
+          }
+        ],
+        "onReject": "ux-scope",
+        "maxAttempts": 3
+      },
+      "next": "build"
+    },
+    {
+      "id": "build",
+      "name": "Build the CLI",
+      "description": "implement parsing + command logic",
+      "prompt": "Implement the CLI in a single runnable source file with a real entry point. Step 1: Parse argv into commands, positional args, and flags exactly as scoped — support both long and short flag forms and apply defaults. Step 2: Implement each command's logic; write normal output to stdout and diagnostics/errors to stderr. Step 3: Wire `--help` (and bare invocation) to print the usage text and exit 0; on unknown command/flag or missing required arg, print a clear error to stderr and exit non-zero. Step 4: Ensure the process exits with the documented code in every path. On a loop-back, fix only the named gaps without regressing working commands. `write_task_note` the file path and which criteria now pass.",
+      "suggestedRole": "developer",
+      "advanceWhen": {
+        "file": "src/cli.js",
+        "minBytes": 1,
+        "sniff": "nonempty"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "src/cli.js",
+            "bytes": 200
+          },
+          {
+            "kind": "sniff",
+            "file": "src/cli.js",
+            "sniff": "nonempty"
+          },
+          {
+            "kind": "esmImports",
+            "file": "src/cli.js"
+          },
+          {
+            "kind": "sourceParses",
+            "file": "src/cli.js"
+          }
+        ],
+        "onReject": "build",
+        "maxAttempts": 3
+      },
+      "next": "test"
+    },
+    {
+      "id": "test",
+      "name": "Write CLI tests",
+      "description": "test parsing, help, happy paths, error exits",
+      "prompt": "Write tests that invoke the CLI and inspect output + exit code. Step 1: Assert `--help` and bare invocation print usage and exit 0. Step 2: Assert each command's happy path produces the documented stdout and exits 0. Step 3: Assert error cases (unknown flag, missing required arg, bad value) print to stderr and exit non-zero with the right code. Step 4: Assert flag parsing handles long form, short form, and defaults. Capture stdout/stderr separately. `write_task_note` the test file path and pass/fail count.",
+      "suggestedRole": "developer",
+      "advanceWhen": {
+        "file": "src/cli.test.js",
+        "minBytes": 1,
+        "sniff": "nonempty"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "src/cli.js",
+            "bytes": 200
+          },
+          {
+            "kind": "sniff",
+            "file": "src/cli.js",
+            "sniff": "nonempty"
+          },
+          {
+            "kind": "esmImports",
+            "file": "src/cli.js"
+          },
+          {
+            "kind": "sourceParses",
+            "file": "src/cli.js"
+          }
+        ],
+        "onReject": "test",
+        "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": "Run the tests and invoke the CLI directly. For EACH acceptance criterion: confirm --help/usage works and exits 0, confirm each command's output matches the spec, confirm errors go to stderr with a non-zero exit, and confirm flag parsing (long, short, defaults) works. Write PASS/FAIL per criterion.\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",
+      "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.1.0",
+  "releasedAt": "2026-07-28T00:00:00Z"
+}

package/data/craftbook-templates/cl/cli-tool/versions/1.1.0/test.json

@@ -0,0 +1,128 @@
+{
+  "schemaVersion": 1,
+  "title": "Small CSV summary CLI",
+  "objective": "Measure whether the cli-tool craftbook scopes command UX, writes a runnable Node CLI, and includes tests/examples.",
+  "tags": [
+    "html-page"
+  ],
+  "prompt": "In the `CLI Tool Eval` project, build a small dependency-free Node ESM CLI named `summarize-orders`. Write `src/cli.js` and `src/cli.test.js`. The CLI should accept `--input <csv>`, `--format table|json`, and `--min-total <number>`, parse order rows with customer,status,total fields, filter by minimum total, and print either a text table or JSON summary. The test file should use Node assert or a tiny test harness and cover JSON output, table output, and min-total filtering.",
+  "setup": {
+    "projectName": "CLI Tool Eval",
+    "about": "Self-contained eval project for cli-tool. Deliverables are workspace/src/cli.js and workspace/src/cli.test.js.",
+    "missionObjectives": "Produce a small dependency-free Node CLI with argument parsing, CSV parsing, JSON/table output, and tests.",
+    "files": [],
+    "worker": {
+      "name": "Koen",
+      "role": "Developer"
+    }
+  },
+  "mocks": [],
+  "success": {
+    "summary": "src/cli.js implements argument parsing/output modes and src/cli.test.js covers the core CLI behavior.",
+    "deliverables": [
+      {
+        "path": "src/cli.js",
+        "kind": "code-module",
+        "minBytes": 1600,
+        "checks": [
+          {
+            "kind": "contains",
+            "file": "src/cli.js",
+            "pattern": "process\\.argv|argv",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "src/cli.js",
+            "pattern": "--input",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "src/cli.js",
+            "pattern": "--format",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "src/cli.js",
+            "pattern": "--min-total",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "src/cli.js",
+            "pattern": "read_file|fs",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "src/cli.js",
+            "pattern": "JSON\\.stringify|console\\.log",
+            "flags": "i"
+          }
+        ]
+      },
+      {
+        "path": "src/cli.test.js",
+        "kind": "code-with-tests",
+        "minBytes": 900,
+        "checks": [
+          {
+            "kind": "contains",
+            "file": "src/cli.test.js",
+            "pattern": "assert|describe|it|test",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "src/cli.test.js",
+            "pattern": "json",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "src/cli.test.js",
+            "pattern": "table",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "src/cli.test.js",
+            "pattern": "min-total|filter",
+            "flags": "i"
+          }
+        ]
+      }
+    ]
+  },
+  "rubric": {
+    "artifact": {
+      "path": "src/cli.js",
+      "kind": "typescript"
+    },
+    "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": [
+    "CLI UX scope",
+    "argument parsing",
+    "test coverage"
+  ]
+}

package/data/craftbook-templates/cr/crossword-forge/manifest.json

@@ -18,6 +18,5 @@
   "logo": "logo.webp",
   "license": "MIT",
   "yankedVersions": [],
-  "workflow": "build-loop",
-  "version": "1.0.1"
+  "workflow": "build-loop"
 }