@bendyline/gilde 0.1.39 → 0.1.41

package/data/craftbook-templates/de/dependency-upgrade/versions/1.0.0/test.json

@@ -0,0 +1,236 @@
+{
+  "schemaVersion": 1,
+  "title": "Vendored dependency upgrade with staged receipts",
+  "objective": "The craftbook drives a staged upgrade of a vendored library across a breaking major: a recorded green suite before any change, the v2 API adopted at both real call sites with behavior preserved against the v1 reference, an honest stage record, and an enforced review - all verified mechanically, including a resolved-module check proving the call sites genuinely run v2.",
+  "tags": [
+    "code",
+    "dependency-upgrade",
+    "tactical-fleet"
+  ],
+  "prompt": "Use the Upgrade a Dependency craftbook for this: upgrade our vendored markdownlite library from 1.4.2 to the staged 2.0.0 copy. The vendoring convention and the v2 changelog are in VENDORING.md, and the request is in source/upgrade-request.md. Rendering behavior must not change - adapt the call sites to the new API rather than accepting the new defaults.",
+  "setup": {
+    "projectName": "Relay Notes",
+    "about": "A tiny note-rendering module for a team relay tool. Dependencies are vendored under lib/vendored/ per VENDORING.md. Tests run with `npm run test` (node --test).",
+    "files": [
+      {
+        "path": "package.json",
+        "content": "{\n  \"name\": \"relay-notes\",\n  \"private\": true,\n  \"version\": \"1.0.0\",\n  \"type\": \"module\",\n  \"scripts\": {\n    \"test\": \"node --test\"\n  }\n}\n"
+      },
+      {
+        "path": "lib/vendored/markdownlite.js",
+        "content": "// markdownlite 1.4.2 (vendored - see VENDORING.md)\nexport function parse(text) {\n  const lines = String(text).split(/\\r?\\n/);\n  const out = [];\n  for (const line of lines) {\n    const t = line.trim();\n    if (t === '') continue;\n    const h = /^(#{1,3})\\s+(.*)$/.exec(t);\n    if (h) {\n      out.push(`<h${h[1].length}>${inline(h[2])}</h${h[1].length}>`);\n    } else {\n      out.push(`<p>${inline(t)}</p>`);\n    }\n  }\n  return out.join('\\n');\n}\n\nfunction inline(text) {\n  return text.replace(/\\*([^*]+)\\*/g, '<em>$1</em>');\n}\n"
+      },
+      {
+        "path": "lib/vendored/v2/markdownlite.js",
+        "content": "// markdownlite 2.0.0 (vendored staging copy - see VENDORING.md)\nexport function parseDoc(text, options = {}) {\n  const wrapParagraphs = options.wrapParagraphs ?? false;\n  const lines = String(text).split(/\\r?\\n/);\n  const out = [];\n  for (const line of lines) {\n    const t = line.trim();\n    if (t === '') continue;\n    const h = /^(#{1,3})\\s+(.*)$/.exec(t);\n    if (h) {\n      out.push(`<h${h[1].length}>${inline(h[2])}</h${h[1].length}>`);\n    } else {\n      out.push(wrapParagraphs ? `<p>${inline(t)}</p>` : inline(t));\n    }\n  }\n  return out.join('\\n');\n}\n\nfunction inline(text) {\n  return text.replace(/\\*([^*]+)\\*/g, '<em>$1</em>');\n}\n"
+      },
+      {
+        "path": "src/render-note.js",
+        "content": "import { parse } from '../lib/vendored/markdownlite.js';\n\nexport function renderNote(note) {\n  return `<h2>${note.title}</h2>\\n${parse(note.body)}`;\n}\n"
+      },
+      {
+        "path": "src/render-digest.js",
+        "content": "import { parse } from '../lib/vendored/markdownlite.js';\n\nexport function renderDigest(notes) {\n  return notes\n    .map((note) => `<section>\\n<h2>${note.title}</h2>\\n${parse(note.body)}\\n</section>`)\n    .join('\\n');\n}\n"
+      },
+      {
+        "path": "tests/render-note.test.mjs",
+        "content": "import assert from 'node:assert/strict';\nimport { test } from 'node:test';\nimport { renderNote } from '../src/render-note.js';\n\ntest('renders the body as wrapped paragraphs', () => {\n  assert.equal(\n    renderNote({ title: 'Standup', body: 'we shipped the *fast* path' }),\n    '<h2>Standup</h2>\\n<p>we shipped the <em>fast</em> path</p>',\n  );\n});\n\ntest('renders headings inside the body', () => {\n  assert.equal(\n    renderNote({ title: 'Plan', body: '# Goals\\nship it' }),\n    '<h2>Plan</h2>\\n<h1>Goals</h1>\\n<p>ship it</p>',\n  );\n});\n"
+      },
+      {
+        "path": "tests/render-digest.test.mjs",
+        "content": "import assert from 'node:assert/strict';\nimport { test } from 'node:test';\nimport { renderDigest } from '../src/render-digest.js';\n\ntest('joins every note as a wrapped section', () => {\n  const html = renderDigest([\n    { title: 'One', body: 'first' },\n    { title: 'Two', body: 'second line' },\n  ]);\n  assert.equal(\n    html,\n    '<section>\\n<h2>One</h2>\\n<p>first</p>\\n</section>\\n<section>\\n<h2>Two</h2>\\n<p>second line</p>\\n</section>',\n  );\n});\n"
+      },
+      {
+        "path": "VENDORING.md",
+        "content": "# Vendoring convention\n\nThis project vendors small dependencies directly under `lib/vendored/` instead\nof installing them from a registry. Each vendored library is a single file named\nafter the package. Upgrades arrive as a staged copy in a version subfolder\n(for example `lib/vendored/v2/`) so the switch is an explicit, reviewable\nchange: move the staged copy into place (or point the imports at it), adapt the\ncall sites, and remove the staging folder when the switch is complete.\n\n## markdownlite\n\nCurrent vendored version: 1.4.2 at `lib/vendored/markdownlite.js`.\nStaged upgrade: 2.0.0 at `lib/vendored/v2/markdownlite.js`.\n\n### markdownlite 2.0.0 changelog\n\n- BREAKING: `parse(text)` is renamed to `parseDoc(text, options)`.\n- BREAKING: plain lines are no longer wrapped in `<p>` by default. Paragraph\n  wrapping is now opt-in: pass `{ wrapParagraphs: true }` to keep the 1.x\n  output.\n- Heading and emphasis handling are unchanged.\n"
+      },
+      {
+        "path": "source/upgrade-request.md",
+        "content": "# Upgrade request\n\nPlease move us from vendored markdownlite 1.4.2 to the staged 2.0.0 copy.\nThe v2 changelog is in VENDORING.md. Rendering behavior must not change:\nnotes and digests must produce exactly the same HTML as today, so adapt the\ncall sites to the new API rather than accepting the new defaults.\n"
+      },
+      {
+        "path": "tests/verify-upgrade.mjs",
+        "content": "import assert from 'node:assert/strict';\nimport { execFileSync } from 'node:child_process';\nimport { readFileSync } from 'node:fs';\nimport { join } from 'node:path';\nimport { pathToFileURL } from 'node:url';\n\nconst root = process.cwd();\n\n// 1) Both call sites moved off the removed v1 API and resolve to a v2 module.\n//    Accepted either way: v2 copied into place at lib/vendored/markdownlite.js,\n//    or imports repointed at the staged v2 file.\nconst callSites = ['src/render-note.js', 'src/render-digest.js'];\nfor (const file of callSites) {\n  const source = readFileSync(join(root, file), 'utf8');\n  assert.ok(/\\bparseDoc\\s*\\(/.test(source), `${file} must call the v2 parseDoc API`);\n  assert.ok(!/\\bparse\\s*\\(/.test(source), `${file} still calls the removed v1 parse API`);\n  const spec = /import\\s*\\{[^}]*\\}\\s*from\\s*['\"]([^'\"]*markdownlite[^'\"]*)['\"]/.exec(source);\n  assert.ok(spec, `${file} must import the vendored markdownlite module`);\n  const mod = await import(new URL(spec[1], pathToFileURL(join(root, file))).href);\n  assert.equal(typeof mod.parseDoc, 'function', `${file} must resolve to markdownlite v2 (parseDoc export)`);\n  assert.equal(mod.parse, undefined, `${file} resolves to a module that still exports the removed v1 parse API`);\n}\nconsole.log('DEPUPGRADE_ORACLE call sites adapted');\n\n// 2) Behavior is unchanged against the v1 reference output.\nconst { renderNote } = await import(pathToFileURL(join(root, 'src/render-note.js')).href);\nconst { renderDigest } = await import(pathToFileURL(join(root, 'src/render-digest.js')).href);\nassert.equal(\n  renderNote({ title: 'Standup', body: 'we shipped the *fast* path' }),\n  '<h2>Standup</h2>\\n<p>we shipped the <em>fast</em> path</p>',\n  'renderNote must keep wrapping paragraphs after the upgrade',\n);\nassert.equal(\n  renderNote({ title: 'Plan', body: '# Goals\\nship it' }),\n  '<h2>Plan</h2>\\n<h1>Goals</h1>\\n<p>ship it</p>',\n  'renderNote must keep heading handling after the upgrade',\n);\nassert.equal(\n  renderDigest([\n    { title: 'One', body: 'first' },\n    { title: 'Two', body: 'second line' },\n  ]),\n  '<section>\\n<h2>One</h2>\\n<p>first</p>\\n</section>\\n<section>\\n<h2>Two</h2>\\n<p>second line</p>\\n</section>',\n  'renderDigest must keep its exact output after the upgrade',\n);\nconsole.log('DEPUPGRADE_ORACLE behavior ok');\n\n// 3) The suite is green on the upgraded tree, and the seeded tests survive.\nreadFileSync(join(root, 'tests/render-note.test.mjs'));\nreadFileSync(join(root, 'tests/render-digest.test.mjs'));\nfunction runSuite(cwd) {\n  try {\n    execFileSync(process.execPath, ['--test'], { cwd, stdio: 'pipe', timeout: 30000 });\n    return 0;\n  } catch (err) {\n    return typeof err.status === 'number' ? err.status : 1;\n  }\n}\nassert.equal(runSuite(root), 0, 'the suite must be green on the upgraded tree');\nconsole.log('DEPUPGRADE_ORACLE suite green');\nconsole.log('DEPUPGRADE_ORACLE done');\n",
+        "surface": "harness"
+      }
+    ],
+    "craftbookParams": {
+      "workPath": "tasks/eval",
+      "scope": "Upgrade the vendored markdownlite from 1.4.2 to the staged 2.0.0 copy per VENDORING.md; rendering behavior must not change."
+    }
+  },
+  "mocks": [],
+  "success": {
+    "summary": "The vendored library runs at v2 through both call sites (either moved into place or repointed), every adaptation preserves the exact v1 rendering behavior, the suite is green, and every fleet artifact exists with honest receipts.",
+    "deliverables": [
+      {
+        "path": "tasks/eval/survey.md",
+        "kind": "markdown-notes",
+        "artifact": true,
+        "minBytes": 600,
+        "checks": [
+          {
+            "kind": "contains",
+            "file": "tasks/eval/survey.md",
+            "pattern": "^##\\s+Current state[\\s\\S]*^##\\s+Candidates[\\s\\S]*^##\\s+Breaking-change notes[\\s\\S]*^##\\s+Stage plan",
+            "flags": "im",
+            "label": "survey sections in order"
+          },
+          {
+            "kind": "contains",
+            "file": "tasks/eval/survey.md",
+            "pattern": "parseDoc",
+            "label": "names the real v2 API change from the local changelog"
+          },
+          {
+            "kind": "citationsResolve",
+            "file": "tasks/eval/survey.md",
+            "minCitations": 2,
+            "artifact": true
+          }
+        ]
+      },
+      {
+        "path": "tasks/eval/change-notes.md",
+        "kind": "markdown-notes",
+        "artifact": true,
+        "minBytes": 700,
+        "checks": [
+          {
+            "kind": "contains",
+            "file": "tasks/eval/change-notes.md",
+            "pattern": "^##\\s+Stages executed[\\s\\S]*^##\\s+Files touched[\\s\\S]*^##\\s+Adaptations[\\s\\S]*^##\\s+Reverted stages",
+            "flags": "im",
+            "label": "change-notes sections in order"
+          },
+          {
+            "kind": "citationsResolve",
+            "file": "tasks/eval/change-notes.md",
+            "minCitations": 2,
+            "artifact": true
+          }
+        ]
+      },
+      {
+        "path": "tasks/eval/verification.md",
+        "kind": "markdown-notes",
+        "artifact": true,
+        "minBytes": 450,
+        "checks": [
+          {
+            "kind": "contains",
+            "file": "tasks/eval/verification.md",
+            "pattern": "^##\\s+Suite[\\s\\S]*^##\\s+Adaptations verified[\\s\\S]*^##\\s+Rollback[\\s\\S]*^##\\s+Result",
+            "flags": "im",
+            "label": "verification sections in order"
+          }
+        ]
+      },
+      {
+        "path": "tasks/eval/review.md",
+        "kind": "markdown-report",
+        "artifact": true,
+        "minBytes": 400,
+        "checks": [
+          {
+            "kind": "contains",
+            "file": "tasks/eval/review.md",
+            "pattern": "Verdict:\\s*(?:PASS|REVISE)",
+            "flags": "i",
+            "label": "explicit reviewer verdict"
+          }
+        ]
+      }
+    ],
+    "checks": [
+      {
+        "kind": "notContains",
+        "file": "src/render-note.js",
+        "pattern": "\\bparse\\s*\\(|import\\s*\\{[^}]*\\bparse\\b[^}]*\\}",
+        "label": "the removed v1 parse API is gone from the note call site"
+      },
+      {
+        "kind": "notContains",
+        "file": "src/render-digest.js",
+        "pattern": "\\bparse\\s*\\(|import\\s*\\{[^}]*\\bparse\\b[^}]*\\}",
+        "label": "the removed v1 parse API is gone from the digest call site"
+      },
+      {
+        "kind": "sourceParses",
+        "file": "src/render-note.js"
+      },
+      {
+        "kind": "sourceParses",
+        "file": "src/render-digest.js"
+      },
+      {
+        "kind": "nodeRuns",
+        "file": "tests/render-note.test.mjs"
+      },
+      {
+        "kind": "nodeScriptPasses",
+        "script": "tests/verify-upgrade.mjs",
+        "timeoutMs": 60000,
+        "requiredOutput": [
+          {
+            "pattern": "DEPUPGRADE_ORACLE call sites adapted",
+            "label": "both call sites run the v2 API"
+          },
+          {
+            "pattern": "DEPUPGRADE_ORACLE behavior ok",
+            "label": "rendering behavior preserved against the v1 reference"
+          },
+          {
+            "pattern": "DEPUPGRADE_ORACLE suite green",
+            "label": "suite green on the upgraded tree"
+          }
+        ]
+      }
+    ],
+    "taskNotes": {
+      "minBytes": 120,
+      "checks": [
+        {
+          "kind": "contains",
+          "file": "task-notes.md",
+          "pattern": "\\bDONE\\b[\\s\\S]*(npm\\s+run\\s+test|node\\s+--test)",
+          "flags": "i",
+          "label": "DONE note names the real test command"
+        }
+      ]
+    },
+    "taskGraph": {
+      "requireCraftbookTask": true,
+      "requireTerminalStep": true
+    },
+    "unchangedFixtures": [
+      "source/upgrade-request.md",
+      "package.json"
+    ]
+  },
+  "rubric": {
+    "artifact": {
+      "path": "tasks/eval/change-notes.md",
+      "kind": "markdown"
+    },
+    "axes": [
+      {
+        "name": "Staged discipline",
+        "description": "The work ran as ordered stages with the suite genuinely run before the first change and between stages, and the record distinguishes executed stages from reverted or deferred ones."
+      },
+      {
+        "name": "Local evidence honesty",
+        "description": "Breaking-change notes come from sources actually read in the repository (VENDORING.md, the staged v2 file), with nothing presented as a release note that was invented."
+      },
+      {
+        "name": "Adaptation fidelity",
+        "description": "Call sites were adapted at their real locations to preserve exact rendering behavior under the v2 API, rather than accepting changed defaults or weakening tests."
+      }
+    ]
+  },
+  "qualityFocus": [
+    "staged upgrades with receipts",
+    "local breaking-change evidence",
+    "honest reverts"
+  ]
+}

package/data/craftbook-templates/de/deploy-checklist/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "deploy-checklist",
   "role": "general",
+  "category": "code-release",
   "name": "Deploy Checklist",
   "description": "Author and then actually execute a pre-deploy verification checklist for shipping a release to production — the concrete gates that must be green before the deploy button is pressed: tests passing, build clean, migrations reviewed, config/secrets present, feature flags set, rollback path confirmed, and observability/alerts ready. A planner scopes the checklist tailored to this service and risk level, a developer runs each item and records real evidence (command output, links, screenshots) for pass or fail, and a reviewer signs off go/no-go. Use this before a production deploy, a release cut-over, or any 'are we ready to ship?' gate where skipping a step causes outages.",
   "tags": [

package/data/craftbook-templates/de/design-review/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "design-review",
   "role": "maintenance-review",
+  "category": "design",
   "name": "UX & Visual Design Review",
   "description": "Critique a UI's user experience and visual design and produce a prioritized design-review report. First scopes the screens and flows and locks a heuristic checklist (visual hierarchy, spacing rhythm and alignment, typographic scale, color and contrast, consistency, affordance and feedback, empty/loading/error states, and the primary task's friction), then reviews each screen against those heuristics with a designer's eye for both polish and usability, then writes a findings report rating each issue by impact with a concrete, specific design fix. Use this for a design review, UX critique, visual QA, design feedback, a heuristic evaluation, or 'does this look and feel right' — it gives actionable, specific design fixes (exact spacing, color, hierarchy changes) rather than 'make it pop'.",
   "tags": [

package/data/craftbook-templates/de/design-system-consultation/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "design-system-consultation",
   "role": "maintenance-review",
+  "category": "design",
   "name": "Design System Consultation",
   "description": "Interview for product context and taste, then propose a full design system — type, color, layout, motion — and capture it as a DESIGN.md with live preview pages.",
   "tags": [

package/data/craftbook-templates/di/diagram-from-text/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "diagram-from-text",
   "role": "general",
+  "category": "code-docs",
   "name": "Diagram from Text",
   "description": "Render a clear technical diagram — flowchart, architecture, sequence, ER, or org chart — from a plain-language description, as code-defined (Mermaid/Graphviz/SVG) so it is editable and version-controllable rather than a flat picture. Spec FIRST the diagram type, the exact nodes and edges, and the layout direction, because diagrams fail when relationships are wrong or the graph is an unreadable tangle; then build the diagram so it renders, with every described entity and relationship present and labeled. Covers flowcharts, architecture diagrams, sequence diagrams, ER diagrams, org charts, mind maps, and diagram-as-code.",
   "tags": [

package/data/craftbook-templates/di/digest-from-feeds/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "digest-from-feeds",
   "role": "general",
+  "category": "research",
   "name": "RSS / Feed Digest",
   "description": "Build a recurring digest from RSS/Atom feeds or news sources: fetch the latest items in the window, dedupe and cluster by topic, then write a scannable digest with one-line takes and source links. Scopes the feed list and digest format FIRST (which feeds, the time window, topic sections, item cap, ranking signal), then a developer fetches and normalizes the feed items into a deduped item list, then a copywriter writes the curated digest from those items only. Scoping sources and the window before fetching is what keeps the digest fresh, deduped, and within length instead of an unranked firehose. Use for RSS digests, news roundups, feed summaries, content curation, and recurring reading digests.",
   "tags": [

package/data/craftbook-templates/do/doc-intake-pipeline/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "doc-intake-pipeline",
   "role": "general",
+  "category": "business",
   "name": "Classify and Route Incoming Documents",
   "description": "Build a document-intake pipeline that classifies each incoming file (invoice, contract, resume, receipt, ID, support ticket, other) into a fixed type set, extracts a few key fields per type, and routes it to the right destination folder with a normalized filename. Locks the document-type taxonomy, per-type extraction fields, and the routing/naming rules FIRST, then builds the classify-extract-route loop, then verifies every input file was handled, classifications are in-set with an 'other' fallback, and routing is deterministic. Taxonomy-and-routing-before-build prevents files from silently vanishing or piling into a misc bucket.",
   "tags": [

package/data/craftbook-templates/do/doc-rewrite/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "doc-rewrite",
   "role": "general",
+  "category": "code-docs",
   "name": "Documentation Rewrite",
   "description": "Rewrite confusing existing documentation into clear, scannable, task-oriented prose without losing any technical fact: it first audits the current doc to catalog every problem — buried steps, undefined jargon, missing prerequisites, broken structure — and locks a clarity checklist, then rewrites the doc to fix exactly those issues while preserving every accurate instruction. Covers documentation rewrite, doc cleanup, clarify docs, improve README, restructure guide, and technical editing. Auditing before rewriting is the point: a small model that first inventories what is wrong rewrites with intent and preserves the facts, instead of producing a prettier doc that quietly drops a critical step.",
   "tags": [

package/data/craftbook-templates/do/dockerize-app/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "dockerize-app",
   "role": "maintenance-review",
+  "category": "code-release",
   "name": "Containerize a Service",
   "description": "Containerize an application with a production-grade Dockerfile — small, secure, reproducible, and buildable — plus the supporting files to run it. Scopes the container contract FIRST — base image, build vs runtime stages, dependencies, exposed port, entrypoint, env config, and the size/security bar — then writes the Dockerfile + .dockerignore + compose, then a reviewer confirms it builds, runs, and meets the bar. Covers multi-stage builds, slim base images, layer caching, non-root user, .dockerignore, healthchecks, EXPOSE/ENTRYPOINT, and reproducible image builds.",
   "tags": [

package/data/craftbook-templates/do/docs-site/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "docs-site",
   "role": "project-starter",
+  "category": "code-docs",
   "name": "Documentation Site",
   "description": "Build a single-page documentation site with a sidebar table of contents, anchored sections, code blocks, and in-page navigation — the kind of reference page a library or API ships. Locks the information architecture (the section tree and ordering) first, then a readable docs visual design with good typography and code styling, then builds the HTML with working anchor links and a sticky sidebar. Getting the IA right before layout is what makes docs findable; a small model that jumps straight to HTML produces an unnavigable wall of text.",
   "tags": [

package/data/craftbook-templates/do/documentation-drift-review/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "documentation-drift-review",
   "role": "maintenance-review",
+  "category": "code-docs",
   "name": "Documentation Drift Review",
   "description": "Review project documentation against the code, configuration, commands, API surface, and shipped behavior to find stale or misleading guidance. Uses the indexed docs and source map to verify examples and references instead of proofreading in isolation, then leaves a prioritized morning report with exact doc locations, source-of-truth evidence, corrected text, owners, and a prevention plan. Use for a weekly docs-health sweep, documentation accuracy review, stale README audit, or finding runbook and API-documentation drift.",
   "tags": [

package/data/craftbook-templates/dr/draft-social-post/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "draft-social-post",
   "role": "general",
+  "category": "marketing",
   "name": "Draft a Social Post",
   "description": "Draft one social post from idea to approved copy. Reads your voice guide and recent posts, grounds the angle in what your feeds actually responded to, drafts the base message, then fits a variant to each platform's limits — Bluesky 300 graphemes, X 280 characters, Instagram captions with the hook in the first 125 characters, LinkedIn up to 3000 characters in a professional register — with hashtags where idiomatic, alt text for media, and thread splits when the copy runs long. Then it stops for your review: approve, ask for a revision round, or approve and queue to Bluesky through the outbox. Covers social media copywriting, tweet and thread drafting, Bluesky posts, Instagram captions, post scheduling, and a human approval gate. Nothing is ever published without your say-so.",
   "tags": [

package/data/craftbook-templates/dr/drive-wrap-up/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "drive-wrap-up",
   "role": "general",
+  "category": "personal",
   "name": "Fundraiser Wrap-Up",
   "description": "Close a fundraising drive properly: verify the final numbers against the donation ledger, confirm every donor was thanked (or finish the thank-yous now), and write the wrap-up story — the total, what the money does, and the people who made it happen — ready to share with the community and hand to the next organizer. Locks the wrap-up's claims and the thank-you completeness check FIRST, then verifies against the ledger, then writes the story. Use for ending a fundraiser, drive wrap-up reports, final fundraising totals, and community thank-you posts.",
   "tags": [

package/data/craftbook-templates/du/due-diligence-brief/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "due-diligence-brief",
   "role": "general",
+  "category": "research",
   "name": "Due-Diligence Brief",
   "description": "Produce a structured due-diligence brief on an entity (company, vendor, investment, partner): a planner locks the diligence dimensions and red-flag criteria, a researcher gathers verifiable facts and risk signals per dimension with sources, and a copywriter writes a decision-oriented brief with findings, risks, and an overall read. The ordering matters because diligence without locked dimensions misses a category (e.g. legal, financial, reputational) and a brief without a red-flag rubric buries the risks; fixing the dimensions and what counts as a flag first makes the brief decision-ready and defensible. Use this for vendor/partner due diligence, investment diligence, background briefs on a company or person, risk assessments, and 'should we work with / invest in X' questions.",
   "tags": [

package/data/craftbook-templates/eb/ebook-compile/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "ebook-compile",
   "role": "general",
+  "category": "writing",
   "name": "Ebook Compile",
   "description": "Compile a collection of notes, articles, or chapter drafts into a coherent, readable ebook — with a title page, table of contents, consistently formatted chapters, and front/back matter — output as a single navigable HTML book. Outlines the chapter structure and through-line FIRST (so disparate notes become a real book, not a pile), writes/edits each chapter to a consistent voice and adds connective tissue, then builds the compiled HTML with a linked TOC and chapter navigation. Use for turning a blog backlog, course notes, or drafts into a downloadable ebook.",
   "tags": [

package/data/craftbook-templates/ed/edit-notes/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "edit-notes",
   "role": "maintenance-review",
+  "category": "media",
   "name": "Edit Notes Pass",
   "description": "Review the footage like an editor: timestamped notes on pacing and cuts read against the transcript and the media index, then a machine-readable cut list the assembly step can execute — opinion upstream, precision downstream. Locks the review criteria FIRST (every keep or cut carries a timecode and a reason, b-roll gaps get named), then writes the edit notes, then distills them into the cut list — so the creative call and the executable record never drift apart. Use for edit passes, footage reviews, 'what should we cut', cutlist prep, and tightening a video that drags.",
   "tags": [

package/data/craftbook-templates/em/email-sequence/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "email-sequence",
   "role": "general",
+  "category": "marketing",
   "name": "Lifecycle Email Sequence",
   "description": "Design and build a multi-email lifecycle sequence (welcome, onboarding, nurture, re-engagement) that moves a subscriber from one stage to the next: it first maps the customer journey — entry trigger, the goal of each email, send timing/cadence, and the one CTA per email — then drafts every email's subject line, preview text, and body to its single goal, then builds the sequence into a client-safe, inline-styled HTML email set ready to load into an ESP. Covers email sequence, drip campaign, welcome series, onboarding emails, nurture sequence, and lifecycle marketing. Journey-mapping before writing is the point: a small model that assigns each email one job and one CTA avoids the redundant sequence where every email says the same thing and asks for everything at once.",
   "tags": [

package/data/craftbook-templates/em/email-template/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "email-template",
   "role": "project-starter",
+  "category": "marketing",
   "name": "Responsive HTML Email",
   "description": "Build a responsive HTML email template that renders across email clients — Outlook, Gmail, Apple Mail — using table-based layout, inline styles, and bulletproof buttons, for a newsletter, transactional, or promo send. Designs the visual structure and the client-safe constraints first, writes the copy, then builds the table-based HTML with all CSS inlined. Email is not the web: external CSS, flexbox, and modern selectors break, so the design phase locks the table layout and inline-only rule before any markup, the ordering that keeps a small model from producing a div-and-class email that renders broken in Outlook.",
   "tags": [

package/data/craftbook-templates/en/engineering-retrospective/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "engineering-retrospective",
   "role": "maintenance-review",
+  "category": "business",
   "name": "Engineering Retrospective",
   "description": "Build a data-grounded engineering retrospective from git history: activity, hotspots, review patterns, and per-person growth notes for a given window.",
   "tags": [

package/data/craftbook-templates/ep/episode-plan/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "episode-plan",
   "role": "general",
+  "category": "media",
   "name": "Plan the Episode",
   "description": "Turn the idea backlog and last episode's loose threads into a locked plan for the next episode: a rundown with timed segments, what to prep, and a record date — so the show ships on rhythm instead of on adrenaline. Locks the episode goal and the acceptance checklist FIRST, then builds the timed rundown, then writes the brief with prep owners and the record date. Use for planning the next episode, episode rundowns, show planning, and 'what's the next episode'.",
   "tags": [

package/data/craftbook-templates/es/escalation-playbook/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "escalation-playbook",
   "role": "general",
+  "category": "code-ops",
   "name": "On-Call Escalation Playbook",
   "description": "Author an on-call escalation playbook: the severity ladder, who-to-page-when escalation tiers with timeouts, communication cadence to stakeholders, and the step-by-step actions for each severity. Scopes the severity definitions and escalation policy FIRST (SEV levels with concrete examples, tier timeouts, roles, comms channels and cadence), then a copywriter writes the playbook in clear, do-this-now imperative steps, then a reviewer validates it for completeness and that no severity dead-ends without an escalation path. Scoping the SEV ladder and timeouts before writing prose is what makes the playbook unambiguous at 3am. Use for on-call runbooks, incident escalation policy, paging tiers, severity ladders, and SRE escalation procedures.",
   "tags": [

package/data/craftbook-templates/ev/evidence-brief/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "evidence-brief",
   "role": "general",
+  "category": "research",
   "name": "Decision Evidence Brief",
   "description": "Answer a specific decision question with a weighted, confidence-rated evidence brief: a planner frames the decision and the options, locks the evidence criteria and a confidence scale, a researcher gathers evidence for and against each option and rates the strength of each piece, and a copywriter writes a decision-oriented brief that states a recommendation with explicit confidence levels and the key uncertainties. The ordering matters because evidence gathered before framing the decision is unfocused and a recommendation without a confidence scale hides how strong the case really is; fixing the question, the options, and a confidence rubric first produces an honest, decision-ready brief. Use this for evidence-based decision support, 'what does the evidence say we should do about X', recommendation memos, weighing options with confidence levels, and policy/strategy briefs grounded in sources.",
   "tags": [

package/data/craftbook-templates/ex/executive-level-review/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "executive-level-review",
   "role": "maintenance-review",
+  "category": "practice",
   "name": "Executive-Level Review",
   "description": "A strategic, executive-level review of a plan or scope: challenge the premise, weigh alternatives, and score each dimension before committing — the 'should we even build this' p...",
   "tags": [

package/data/craftbook-templates/ex/expense-categorize/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "expense-categorize",
   "role": "general",
+  "category": "business",
   "name": "Categorize Transactions",
   "description": "Classify a list of bank/card transactions into a fixed chart-of-accounts category set, with confidence and a review queue for the uncertain ones, producing a clean categorized ledger ready for bookkeeping or tax. Locks the category taxonomy and the matching rules (merchant patterns, amount/sign heuristics) FIRST, then categorizes every transaction deterministically-first then by inference, then reviews that the taxonomy is closed, low-confidence rows are queued not force-fit, and totals reconcile to the input. Rules-before-categorize is the wisdom: a defined taxonomy plus rule precedence makes results auditable and repeatable, not a one-off guess.",
   "tags": [

package/data/craftbook-templates/fa/fact-check/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "fact-check",
   "role": "maintenance-review",
+  "category": "research",
   "name": "Fact-Check a Set of Claims",
   "description": "Verify a set of claims one by one and produce a verdict report: a planner extracts and itemizes every checkable claim and locks the rating scale, a researcher independently verifies each claim against primary sources and logs the evidence, and a reviewer compiles a per-claim verdict report with ratings and corrections. The ordering matters because verifying before itemizing lets claims slip through unchecked, and a report without a fixed rating scale gives inconsistent verdicts; isolating each atomic claim and locking the scale first makes the check exhaustive and auditable. Use this for fact-checking articles or statements, verifying claims, debunking, accuracy passes, and 'is this true' / 'check these facts' requests.",
   "tags": [

package/data/craftbook-templates/fa/family-story-chapter/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "family-story-chapter",
   "role": "general",
+  "category": "writing",
   "name": "Family Story Chapter",
   "description": "Write one chapter of the family story from the record you actually have — interviews and tree facts woven into narrative, speculation clearly dressed as speculation — the ritual that turns an archive into the book every family means to write. Locks the chapter's arc and the sourcing rules FIRST, then drafts from the record only, with a faithfulness pass that loops until every event traces. Use for drafting a family history chapter, writing up the emigration years, turning interviews into narrative, and 'write the family story'.",
   "tags": [

package/data/craftbook-templates/fa/faq-from-docs/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "faq-from-docs",
   "role": "general",
+  "category": "writing",
   "name": "FAQ from Source Docs",
   "description": "Build a grounded FAQ page by mining real source documents for the questions users actually ask, then writing tight, accurate answers traced back to the source: it first researches the corpus to extract candidate questions, dedupes and groups them, and ranks by likely frequency, then writes clear question-and-answer pairs where every answer is supported by the docs. Covers FAQ generation, help center questions, support docs, knowledge mining, common questions, and self-service content. Mining the source before writing is the point: a small model that derives questions from the actual docs avoids inventing FAQs nobody asks and answers the docs cannot support.",
   "tags": [

package/data/craftbook-templates/fa/favicon-set/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "favicon-set",
   "role": "general",
+  "category": "design",
   "name": "Favicon & App-Icon Set",
   "description": "Generate the complete favicon and app-icon set a modern site needs — the multi-size favicon, Apple touch icon, Android/maskable icons, and the web app manifest plus the exact HTML link/meta tags — from a single source mark, ensuring the icon stays legible at 16px and the maskable variant survives platform cropping. Lock FIRST the source mark, the exact size matrix, and the safe-area/padding rules (maskable icons need extra padding or platforms clip them) because favicon sets fail when the icon is illegible tiny or gets cropped on Android; then generate every size and emit the manifest + install snippet. Covers favicons, app icons, PWA icons, touch icons, maskable icons, and the web app manifest.",
   "tags": [

package/data/craftbook-templates/fe/feature-flag-release/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "feature-flag-release",
   "role": "general",
+  "category": "code-release",
   "name": "Feature Flag Release Plan",
   "description": "Plan and document a progressive feature-flag rollout for shipping a change behind a flag — defining the flag and its default-off state, the staged ramp (internal → 1% → 10% → 50% → 100%) with the success and guardrail metrics that gate each step, the automatic rollback/kill-switch criteria, and the cleanup that removes the flag once fully rolled out. A planner scopes the flag, ramp stages, and metrics, a developer writes the rollout runbook with the exact flag changes and the kill-switch procedure, and a reviewer verifies each ramp step has a measurable gate and a safe abort. Use this for gradual rollouts, canary releases, dark launches, percentage-based ramps, and de-risking a risky change behind a toggle.",
   "tags": [
@@ -19,6 +20,10 @@
   },
   "logo": "logo.webp",
   "license": "MIT",
-  "yankedVersions": [],
+  "yankedVersions": [
+    "1.0.0",
+    "1.0.1",
+    "1.0.2"
+  ],
   "workflow": "build-loop"
 }

package/data/craftbook-templates/fe/feature-flag-rollout/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "feature-flag-rollout",
   "role": "maintenance-review",
+  "category": "code-release",
   "name": "Flagged Feature Rollout",
   "description": "Add a new feature behind a feature flag so it can ship dark, be toggled per-environment/user, and roll back instantly without a deploy. Plans the flag contract FIRST — the flag name/default, the toggle points, the on/off behavior, the targeting (env/percentage/user), and the cleanup plan — then implements the flagged code with both paths working, then a reviewer verifies both states behave and the off-state default is safe. Covers feature flags, toggle points, percentage/targeted rollout, default-off safety, dark launches, and flag-cleanup discipline.",
   "tags": [
@@ -11,7 +12,10 @@
     "rollout",
     "toggle",
     "release",
-    "experiment"
+    "experiment",
+    "canary",
+    "progressive-delivery",
+    "kill-switch"
   ],
   "maintainer": {
     "name": "Gezel"