@bendyline/gilde 0.1.26 → 0.1.28

package/data/craftbook-templates/th/threat-model/versions/1.0.1/craftbook.json

@@ -0,0 +1,141 @@
+{
+  "id": "threat-model",
+  "name": "Lightweight Threat Model",
+  "description": "Produce a lightweight threat model for a feature or system using a structured method (STRIDE over a simple data-flow diagram) and output a prioritized mitigation plan. First scopes the system by drawing its data-flow — actors, processes, data stores, and trust boundaries — and locks what is in scope, then enumerates threats per element using STRIDE (spoofing, tampering, repudiation, info-disclosure, denial-of-service, elevation-of-privilege) and rates each by likelihood and impact, then writes a threat-model report mapping each credible threat to a concrete mitigation and an owner. Use this for a threat model, security design review, STRIDE analysis, attack-surface mapping, or thinking through what could go wrong before building a feature — it yields a structured, prioritized set of threats and mitigations rather than an ad-hoc list of worries.\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\nEvery deliverable lands in the project's **artifacts drawer** (`write_artifact`),\nnot the shipped workspace — a threat model is review/analysis output, not\nproduct source — and each is gated for size/shape there exactly as a workspace\nfile would be.\n\nPhases:\n\n1. Scope the system (planner) — draw the data-flow + trust boundaries, lock scope → gated on artifact `reports/threat-model-scope.md` (markdown-notes)\n2. Enumerate threats (reviewer) — STRIDE each element, rate likelihood × impact → gated on artifact `reports/threat-model-stride.md` (markdown-notes)\n3. Write the threat model (reviewer) — prioritized threats mapped to mitigations → gated on artifact `reports/threat-model.md` (markdown-report)\n\nThe gates never advance with an unmet criterion, and loop back to the\nowning phase to fix named gaps.\n",
+  "entryStepId": "scope",
+  "triggers": [
+    "threat model this",
+    "STRIDE analysis",
+    "what could go wrong with this design",
+    "security design review",
+    "map the attack surface",
+    "model the threats"
+  ],
+  "steps": [
+    {
+      "id": "scope",
+      "name": "Scope the system",
+      "description": "draw the data-flow + trust boundaries, lock scope",
+      "prompt": "Step 1: Describe the feature/system and draw its data-flow as a simple diagram (text/markdown is fine): the external actors and clients, the processes/services, the data stores, and the data flows between them. Step 2: Mark the TRUST BOUNDARIES — every line a request crosses from less-trusted to more-trusted (internet→service, service→db, user→admin). Step 3: List the assets worth protecting (PII, credentials, money, integrity of records) and the security objectives (confidentiality/integrity/availability priorities). Step 4: State what is IN scope and explicitly OUT of scope. Step 5: Write the acceptance-criteria checklist for the model, e.g. 'every element and trust boundary is in the diagram', 'each element is analyzed against all six STRIDE categories', 'every credible threat has a likelihood, impact, and mitigation'. A threat model is a review/analysis deliverable, not shipped product source, so write the diagram + assets + scope + checklist to the ARTIFACT `reports/threat-model-scope.md` with `write_artifact` (not the workspace), and drop a one-line summary via `write_task_note`. No threat enumeration yet.",
+      "suggestedRole": "planner",
+      "advanceWhen": {
+        "file": "reports/threat-model-scope.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "reports/threat-model-scope.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "reports/threat-model-scope.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "scope",
+        "maxAttempts": 3
+      },
+      "next": "model"
+    },
+    {
+      "id": "model",
+      "name": "Enumerate threats",
+      "description": "STRIDE each element, rate likelihood × impact",
+      "prompt": "Step 1: For EACH element and trust-boundary crossing in the diagram, walk the six STRIDE categories and ask what a malicious actor could do: Spoofing (impersonate an actor/service), Tampering (alter data in transit or at rest), Repudiation (deny an action without an audit trail), Information disclosure (read data they shouldn't), Denial of service (exhaust a resource), Elevation of privilege (gain rights they shouldn't). Step 2: For each credible threat capture: the element/flow it targets, the STRIDE category, a one-line attack scenario, the likelihood (high/med/low) and impact (high/med/low), and a resulting risk rating. Step 3: Drop threats that are not credible for THIS system and say why (so the model is honest, not exhaustive theater). Step 4: For each credible threat, draft a concrete mitigation (e.g. 'sign tokens + verify on every boundary', 'parameterize + least-privilege the db role', 'rate-limit + idempotency key'). Step 5: Note existing controls already covering a threat. Good looks like: threats anchored to specific diagram elements with a plausible scenario, not generic 'hackers could attack'. Write the STRIDE threat table to the ARTIFACT `reports/threat-model-stride.md` with `write_artifact`, and note progress with `write_task_note`. Do not write the final report yet.",
+      "suggestedRole": "reviewer",
+      "advanceWhen": {
+        "file": "reports/threat-model-stride.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "reports/threat-model-stride.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "reports/threat-model-stride.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "model",
+        "maxAttempts": 3
+      },
+      "next": "report"
+    },
+    {
+      "id": "report",
+      "name": "Write the threat model",
+      "description": "prioritized threats mapped to mitigations",
+      "prompt": "Step 1: Write the report to the ARTIFACT `reports/threat-model.md` with `write_artifact`, embedding the data-flow diagram and the trust boundaries up top. Step 2: Add a '## Threats' table ranked by risk (likelihood × impact): each row = element/flow, STRIDE category, attack scenario, likelihood, impact, risk, and the mitigation. Step 3: Add a '## Mitigation plan' ordered by priority — the must-do-before-ship controls first, with an owner/area for each. Step 4: Add an '## Accepted/low risks' section for threats consciously not mitigated and the rationale, and a '## Existing controls' note. Every credible threat must map to a concrete mitigation; no generic security platitudes. On a loop-back, fix only the named gaps. `write_task_note` the report path and the count of high-risk threats.",
+      "suggestedRole": "reviewer",
+      "advanceWhen": {
+        "file": "reports/threat-model.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "reports/threat-model.md",
+            "bytes": 1500,
+            "artifact": true
+          },
+          {
+            "kind": "contains",
+            "file": "reports/threat-model.md",
+            "pattern": "(?:^|\\n)#{1,3}\\s+\\S",
+            "flags": "i",
+            "label": "at least one markdown heading",
+            "artifact": true
+          }
+        ],
+        "onReject": "report",
+        "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 the artifact `reports/threat-model.md` (with `read_artifact`) and grade it against the scope checklist. Check EACH criterion and write PASS/FAIL with a one-line reason: (1) the data-flow diagram and trust boundaries are present; (2) every element/boundary was analyzed against all six STRIDE categories; (3) each credible threat has a concrete attack scenario, a likelihood, and an impact; (4) threats are ranked by risk; (5) every credible threat maps to a specific mitigation with an owner/area; (6) non-credible or accepted risks are stated with rationale; (7) no generic 'hackers could attack' filler. If any criterion fails, name the exact gap 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: \"report\" })` 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": "reports/threat-model.md",
+          "artifact": true
+        }
+      ],
+      "next": "report"
+    },
+    {
+      "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) (the artifacts under `reports/`), 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/th/threat-model/versions/1.0.1/test.json

@@ -0,0 +1,110 @@
+{
+  "schemaVersion": 1,
+  "title": "Lightweight Threat Model smoke eval",
+  "objective": "Self-contained smoke eval for the Lightweight Threat Model craftbook using the corpus generic harness.",
+  "tags": [
+    "corpus"
+  ],
+  "prompt": "We need a lightweight threat model for the returns-desk work. The backgound info is in source/brief.md — have a look and write it up in report.md.",
+  "setup": {
+    "projectName": "Lightweight Threat Model Eval",
+    "about": "Self-contained eval project for threat-model. Seeded inputs are under workspace/source or workspace/fixtures; final deliverable is workspace/report.md.",
+    "missionObjectives": "Use the Lightweight Threat Model craftbook/template, read the seeded local fixtures, and write report.md without network calls, real credentials, or live services.",
+    "files": [
+      {
+        "path": "source/brief.md",
+        "content": "# Lightweight Threat Model 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: threat-model - Lightweight Threat Model.\n"
+      }
+    ],
+    "worker": {
+      "name": "Jules",
+      "role": "Writer"
+    }
+  },
+  "mocks": [],
+  "success": {
+    "summary": "report.md is a source-grounded markdown artifact with required facts and actions.",
+    "deliverables": [
+      {
+        "path": "report.md",
+        "kind": "markdown-report",
+        "minBytes": 1000,
+        "checks": [
+          {
+            "kind": "contains",
+            "file": "report.md",
+            "pattern": "(?:^|\\n)#{1,3}\\s+\\S",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "report.md",
+            "pattern": "source/brief\\.md|Brief",
+            "flags": "i",
+            "label": "cite or name the seeded source"
+          },
+          {
+            "kind": "contains",
+            "file": "report.md",
+            "pattern": "18\\b[\\s\\S]{0,30}\\bSKUs",
+            "flags": "i",
+            "label": "include the 18-SKU pilot scope"
+          },
+          {
+            "kind": "contains",
+            "file": "report.md",
+            "pattern": "18\\s*hours|6\\s*hours",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "report.md",
+            "pattern": "14\\.2%|8\\.9%",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "report.md",
+            "pattern": "status silence|photo submission",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "report.md",
+            "pattern": "automated status emails|barcode|Finance",
+            "flags": "i"
+          }
+        ]
+      }
+    ]
+  },
+  "rubric": {
+    "artifact": {
+      "path": "report.md",
+      "kind": "markdown"
+    },
+    "axes": [
+      {
+        "name": "grounding",
+        "description": "Seeded facts appear faithfully and the source is cited."
+      },
+      {
+        "name": "structure",
+        "description": "Sections progress logically for the artifact class."
+      },
+      {
+        "name": "completeness",
+        "description": "Required elements (risks, next actions, scope) are all present."
+      },
+      {
+        "name": "tone",
+        "description": "The register fits the audience and artifact class."
+      }
+    ]
+  },
+  "qualityFocus": [
+    "source-grounded prose",
+    "section structure",
+    "next-action clarity"
+  ]
+}

package/data/craftbook-templates/th/thumbnail-generator/versions/1.0.1/craftbook.json

@@ -0,0 +1,103 @@
+{
+  "id": "thumbnail-generator",
+  "name": "Thumbnail Generator",
+  "description": "Derive a consistent set of thumbnails or responsive size-variants from a folder of source images — square crops for grids, srcset widths for the web, smart-cropped to keep the subject centered — and emit them with predictable names. Scope the target sizes, crop strategy, and naming convention FIRST so the output plugs straight into a gallery or srcset, then build every variant and confirm the matrix is complete. Covers thumbnails, responsive images, srcset, image variants, gallery tiles, and preview generation.\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. Scope the variants (planner) — lock sizes, crop strategy, format, and naming → gated on artifact `notes/scope.md` (markdown-notes)\n2. Build the variants (developer) — generate every variant per source with the naming convention → gated on `out` (image-set)\n\nThe gates never advance with an unmet criterion, and loop back to the\nowning phase to fix named gaps.\n",
+  "entryStepId": "scope",
+  "triggers": [
+    "generate thumbnails",
+    "make responsive image variants",
+    "create srcset images",
+    "thumbnail a folder",
+    "gallery thumbnails"
+  ],
+  "steps": [
+    {
+      "id": "scope",
+      "name": "Scope the variants",
+      "description": "lock sizes, crop strategy, format, and naming",
+      "prompt": "1) List the source images and their dimensions. 2) Decide the variant matrix: the target sizes (e.g. 1x square 200px for grid tiles, plus srcset widths 320/640/1024), the aspect ratio per variant (square thumb vs preserved ratio), and the crop strategy (center vs subject-aware smart crop). 3) Choose output format(s) (e.g. WebP + JPEG fallback) and quality. 4) Lock a naming convention that encodes size, e.g. <name>-200.jpg, <name>-640w.webp, so it drops into srcset. 5) Write an acceptance-criteria checklist: 'every source yields every named variant', 'square thumbs are exactly NxN and keep the subject', 'srcset widths match the spec', 'filenames follow the convention', 'no upscaling beyond source dimensions'. 6) Record matrix + checklist via write_task_note AND to notes/scope.md.\n\nThe deliverable `notes/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": "planner",
+      "advanceWhen": {
+        "file": "notes/scope.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "notes/scope.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "notes/scope.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "scope",
+        "maxAttempts": 3
+      },
+      "next": "build"
+    },
+    {
+      "id": "build",
+      "name": "Build the variants",
+      "description": "generate every variant per source with the naming convention",
+      "prompt": "1) Read scope.md. 2) Prefer a small rerunnable script (ImageMagick/sharp/Pillow) over manual edits. 3) For each source image, generate every variant in the matrix: square thumbs cropped to keep the subject centered (smart-crop if available, else center-crop), srcset widths scaled preserving ratio, in the chosen format(s) and quality. 4) Never upscale past the source's native size — skip-and-log a variant the source is too small for. 5) Write outputs to out/ using the exact naming convention. 6) Build a tiny index.html (optional but encouraged) or at least a manifest line proving the srcset wiring. 7) write_task_note the out/ folder and the produced-vs-expected variant counts. Good looks like: a complete, predictably-named matrix ready for a gallery or srcset.",
+      "suggestedRole": "developer",
+      "advanceWhen": {
+        "file": "out",
+        "minBytes": 1,
+        "sniff": "nonempty"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "fileCount",
+            "ext": [
+              "png",
+              "jpg",
+              "jpeg",
+              "svg",
+              "webp"
+            ],
+            "min": 3,
+            "dir": "out"
+          }
+        ],
+        "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": "1) Open out/ and verify the variant matrix is complete: each source has each named variant (PASS/FAIL on count). 2) Probe a sample: square thumbs are exactly the target NxN and the subject is still in frame; srcset widths match spec (PASS/FAIL). 3) Confirm filenames follow the naming convention so they'd work in srcset. 4) Confirm no variant was upscaled beyond its source. 5) Write PASS/FAIL per criterion with measured numbers. Any gap → loop back to build to fill missing/incorrect variants.\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": "out"
+        }
+      ],
+      "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/th/thumbnail-generator/versions/1.0.1/test.json

@@ -0,0 +1,103 @@
+{
+  "schemaVersion": 1,
+  "title": "Thumbnail Generator smoke eval",
+  "objective": "Self-contained smoke eval for the Thumbnail Generator craftbook using the media generic harness.",
+  "tags": [
+    "media"
+  ],
+  "prompt": "Our media files are all listd in source/media-index.csv. Can you put together the production plan for them as media-plan.json?",
+  "setup": {
+    "projectName": "Thumbnail Generator Eval",
+    "about": "Self-contained eval project for thumbnail-generator. Seeded inputs are under workspace/source or workspace/fixtures; final deliverable is workspace/media-plan.json.",
+    "missionObjectives": "Use the Thumbnail Generator craftbook/template, read the seeded local fixtures, and write media-plan.json without network calls, real credentials, or live services.",
+    "files": [
+      {
+        "path": "source/brief.md",
+        "content": "# Thumbnail Generator 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: thumbnail-generator - Thumbnail Generator.\n"
+      },
+      {
+        "path": "source/media-index.csv",
+        "content": "filename,type,duration_or_size,notes\npilot-interview.wav,audio,00:02:15,mentions response time and status silence\nreturns-desk.png,image,1600x900,shows intake form and photo evidence step\nlaunch-clip.mp4,video,00:01:05,shows barcode exception handling\n"
+      }
+    ],
+    "worker": {
+      "name": "Jules",
+      "role": "Producer"
+    }
+  },
+  "mocks": [],
+  "success": {
+    "summary": "media-plan.json is a valid JSON media-production manifest grounded in seeded fixture metadata.",
+    "deliverables": [
+      {
+        "path": "media-plan.json",
+        "kind": "json",
+        "minBytes": 700,
+        "checks": [
+          {
+            "kind": "sniff",
+            "file": "media-plan.json",
+            "sniff": "json-valid"
+          },
+          {
+            "kind": "contains",
+            "file": "media-plan.json",
+            "pattern": "pilot-interview\\.wav|returns-desk\\.png|launch-clip\\.mp4",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "media-plan.json",
+            "pattern": "outputs|assets|steps|cues|verification",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "media-plan.json",
+            "pattern": "accessibility|alt|caption|transcript|metadata",
+            "flags": "i"
+          }
+        ]
+      }
+    ]
+  },
+  "rubric": {
+    "artifact": {
+      "path": "media-plan.json",
+      "kind": "json"
+    },
+    "axes": [
+      {
+        "name": "completeness",
+        "description": "The manifest covers sources, outputs, and processing steps end to end."
+      },
+      {
+        "name": "grounding",
+        "description": "Only seeded media fixtures are referenced, with faithful metadata."
+      },
+      {
+        "name": "accessibility",
+        "description": "Alt text, captions, or transcripts are planned wherever the class requires."
+      },
+      {
+        "name": "precision",
+        "description": "Timestamps, crops, and cues are specific enough to execute."
+      }
+    ]
+  },
+  "qualityFocus": [
+    "media fixture handling",
+    "structured manifest",
+    "verification metadata"
+  ],
+  "extensions": {
+    "legacySimulators": [
+      {
+        "id": "thumbnail-generator-media-fixtures",
+        "kind": "data-source",
+        "status": "implemented",
+        "description": "Seeded local media index replacing real audio, video, image generation, and external media metadata services."
+      }
+    ]
+  }
+}

package/data/craftbook-templates/ti/tileset-batch/versions/1.0.1/craftbook.json

@@ -0,0 +1,160 @@
+{
+  "id": "tileset-batch",
+  "name": "Tileset Batch",
+  "description": "Produce a style-locked batch of tiles and account for every one: named to the convention, sized to spec, generated against the library's style anchor, and appended to the manifest with tags — an asset library a game engine can trust, not a folder of maybes. Locks the tile list and the naming convention FIRST, then generates the batch in the house style, then writes the manifest records and the batch summary. Use for tile batches, 'we need forest tiles', growing a game's asset library, style-consistent tilesets, and keeping the asset manifest honest.\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. Lock the batch (assetsmid) — tile list, naming convention, size spec, style anchor → gated on artifact `notes/scope.md` (markdown-notes)\n2. Generate the tiles (image-generator) — the batch, named to the convention, in the house style → gated on `assets/tiles` (image-set)\n3. Write the manifest records (data-analyst) — one record per new tile, appended, ids unique\n4. Write the batch summary (copywriter) — what was made, how it is named, what the library now holds → gated on artifact `report.md` (markdown-report)\n\nThe gates never advance with an unmet criterion, and loop back to the\nowning phase to fix named gaps.\n",
+  "entryStepId": "scope",
+  "triggers": [
+    "make a batch of tiles",
+    "we need more tiles for the game",
+    "tileset for the platformer",
+    "generate the tile batch",
+    "grow the asset library"
+  ],
+  "steps": [
+    {
+      "id": "scope",
+      "name": "Lock the batch",
+      "description": "tile list, naming convention, size spec, style anchor",
+      "prompt": "Lock the batch before generating a tile. Step 1: read assets/manifest.json from the workspace — the library's existing records — and the style notes in assets/ (the palette, tile size, outline and shading rules that make the library one family). Step 2: write the tile list from the ask — every tile the batch needs, including the unglamorous edges and corners that make a set usable, at least eight. Step 3: lock the conventions — file names as assets/tiles/tile-<terrain>-<variant>.png, the size spec from the style notes, and the tags each tile will carry. Step 4: write an acceptance-criteria checklist ('every listed tile generated at spec size in the house style', 'every file named to the convention', 'every new tile appended to the manifest with id, file, size, and tags', 'the manifest stays valid JSON and lists only files that exist'). Call write_task_note with the tile list + checklist and write notes/scope.md.\n\nThe deliverable `notes/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": "assetsmid",
+      "advanceWhen": {
+        "file": "notes/scope.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "notes/scope.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "notes/scope.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "scope",
+        "maxAttempts": 3
+      },
+      "next": "generate"
+    },
+    {
+      "id": "generate",
+      "name": "Generate the tiles",
+      "description": "the batch, named to the convention, in the house style",
+      "prompt": "Generate the batch into assets/tiles/. Step 1: work the locked tile list one tile at a time through the project's image capabilities — every prompt built from the style anchor (palette, outline, shading) so the batch reads as one hand's work, saved under the locked naming convention. Step 2: keep the set complete — the edge and corner variants from the list matter more to a level builder than another hero tile. Step 3: after generating, re-list assets/tiles/ against the tile list and fill any gap before completing. Call write_task_note with the count generated and the names.",
+      "suggestedRole": "image-generator",
+      "advanceWhen": {
+        "file": "assets/tiles",
+        "minBytes": 1,
+        "sniff": "nonempty"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "fileCount",
+            "ext": [
+              "png",
+              "jpg",
+              "jpeg",
+              "svg",
+              "webp"
+            ],
+            "min": 3,
+            "dir": "assets/tiles"
+          },
+          {
+            "kind": "fileCount",
+            "ext": [
+              "png"
+            ],
+            "min": 8,
+            "dir": "assets/tiles"
+          }
+        ],
+        "onReject": "generate",
+        "maxAttempts": 3
+      },
+      "next": "manifest"
+    },
+    {
+      "id": "manifest",
+      "name": "Write the manifest records",
+      "description": "one record per new tile, appended, ids unique",
+      "prompt": "Account for every tile in assets/manifest.json. Step 1: append one record per new tile to the top-level JSON array, keeping the existing records untouched. Step 2: each record carries exactly these fields: \"id\" (unique, e.g. tile-grass-01), \"file\" (the workspace-relative path, e.g. assets/tiles/tile-grass-01.png), \"size\" (the pixel spec, e.g. 32x32), and \"tags\" (an array like [\"forest\", \"ground\"]) — plus \"seed\" and \"prompt\" where the generation gave you them, so a tile can be re-made in-style later. Step 3: re-read the whole file after writing — it must parse as JSON, ids must stay unique, and every recorded file must exist on disk; a manifest that lists a tile that is not there is worse than no manifest. Call write_task_note with the record count before and after.",
+      "suggestedRole": "data-analyst",
+      "consumes": [
+        {
+          "file": "assets/tiles"
+        }
+      ],
+      "next": "report"
+    },
+    {
+      "id": "report",
+      "name": "Write the batch summary",
+      "description": "what was made, how it is named, what the library now holds",
+      "prompt": "Write the batch summary at report.md. Step 1: the headline — how many tiles this batch added and what terrain they cover, in one plain sentence. Step 2: the batch list — each tile's id, file, and tags, one line each. Step 3: note the conventions used (naming, size, style anchor) so the next batch starts from the same page, and name anything from the ask that was skipped and why. Step 4: close with the library's new total. Keep it under a page. Write report.md and call write_task_note with the report path and the new total.\n\nThe deliverable `report.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": "copywriter",
+      "advanceWhen": {
+        "file": "report.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "report.md",
+            "bytes": 600,
+            "artifact": true
+          },
+          {
+            "kind": "contains",
+            "file": "report.md",
+            "pattern": "(?:^|\\n)#{1,3}\\s+\\S",
+            "flags": "i",
+            "label": "at least one markdown heading",
+            "artifact": true
+          }
+        ],
+        "onReject": "report",
+        "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 assets/manifest.json, the assets/tiles/ listing, notes/scope.md, and report.md and verify every criterion: every tile on the locked list exists at the convention name — the missing corner variant is the classic failure; every new tile has a manifest record with id, file, size, and tags, ids unique, and every recorded path resolves to a real file — check both directions; the batch reads as one style family against the anchor notes; and the report's counts match the manifest. Write PASS/FAIL per criterion; on any failure, name the tile or record and loop back to generate.\n\nThe deliverable lives in the project's artifacts drawer — open `report.md` with `read_artifact`, not `read_file`.\n\nThen route — this is the whole point of the loop:\n\n- **Every criterion PASSES →** call `advance_task_step({ ref, stepId: \"evaluate\", next: \"finish\" })`.\n- **Any criterion FAILS →** write the specific gaps to notes, then call `advance_task_step({ ref, stepId: \"evaluate\", next: \"generate\" })` 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": "report.md",
+          "artifact": true
+        }
+      ],
+      "next": "generate"
+    },
+    {
+      "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"
+}