@bendyline/gilde 0.1.39 → 0.1.41

package/data/craftbook-templates/no/notification-router/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "notification-router",
   "role": "general",
+  "category": "code-build",
   "name": "Notification Router",
   "description": "Build an event-to-channel notification router: a small module that takes incoming events and routes each to the right destination (Slack channel, email, PagerDuty, webhook) based on type, severity, and quiet-hours rules — with dedupe, throttling, and a fallback channel. Scopes the routing matrix and policy FIRST (event taxonomy, channel map, severity→destination rules, dedupe key, rate limits, fallback), then a developer implements the router module to that matrix, then writes tests covering each routing branch. Scoping the matrix before coding is what guarantees every event type has a defined destination and that critical events can never be silently dropped. Use for notification routing, alert fan-out, event dispatch, webhook routing, and on-call/Slack notification systems.",
   "tags": [

package/data/craftbook-templates/oc/ocr-extract/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "ocr-extract",
   "role": "general",
+  "category": "media",
   "name": "OCR a Folder of Scans",
   "description": "Extract the text from a folder of scanned documents or photographed pages into clean, structured text — preserving reading order, paragraph breaks, and per-file provenance — then verify the extraction against the source images. Scope FIRST the languages, output structure (one file per scan vs a combined doc), and how to handle tables/columns/low-confidence regions, because OCR quality is dominated by handling layout and flagging uncertainty; then run extraction and verify a sample reads correctly. Covers OCR, text extraction, scanned documents, digitizing paper, receipt/invoice text, and image-to-text.",
   "tags": [

package/data/craftbook-templates/of/offer-compare/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "offer-compare",
   "role": "general",
+  "category": "business",
   "name": "Offer Comparison",
   "description": "Turn competing job offers into one honest decision sheet — every offer normalized into the same fact grid (comp, equity with vesting caveats, benefits, level, location, growth, deadlines), unknowns marked UNKNOWN instead of guessed, computed year-1 and 4-year views under stated assumptions, a weighted read against the candidate's OWN priorities, and a recommendation that separates arithmetic from judgment. Use when any second offer (or a strong counter) lands.",
   "tags": [

package/data/craftbook-templates/of/office-hours/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "office-hours",
   "role": "general",
+  "category": "practice",
   "name": "Office Hours",
   "description": "YC-style office-hours diagnostic. Surfaces forcing questions, challenges premises, lands on a sharper problem statement before any code is written.",
   "tags": [

package/data/craftbook-templates/on/onboarding-checklist/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "onboarding-checklist",
   "role": "general",
+  "category": "business",
   "name": "Generate an Onboarding Checklist",
   "description": "Produce a clear, role-specific onboarding checklist for a new hire, customer, or user — grouped by phase (before day one, week one, first 30 days), with each item owned, actionable, and verifiable. Scopes the audience, the phases, and a 'good item' rule FIRST so the checklist is complete and non-overlapping, then writes the actual checklist as a clean markdown document with grouped, owner-tagged, checkbox items. Scoping the phases and item-quality bar before writing is what turns a vague to-do dump into a sequenced, accountable onboarding plan.",
   "tags": [

package/data/craftbook-templates/on/onboarding-flow/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "onboarding-flow",
   "role": "project-starter",
+  "category": "code-build",
   "name": "Product Onboarding Tour",
   "description": "Build a single-file product onboarding tour or coachmark walkthrough that guides a new user through key features with sequential tooltips, a highlighted target, next/back/skip controls, and a finish state. Designs the step sequence, what each step points at, and the copy strategy first, writes the step copy, then implements the spotlight overlay and step navigation. Tours break when a step points at the wrong element or skip/finish does not dismiss, so the flow-design phase locks the step-to-target map before any code.",
   "tags": [

package/data/craftbook-templates/on/oncall-handoff/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "oncall-handoff",
   "role": "general",
+  "category": "code-ops",
   "name": "On-Call Shift Handoff",
   "description": "Produce a clean end-of-shift on-call handoff: open incidents and their state, watch-items and known-flapping alerts, deferred actions, and anything the next on-call must do in the first hour. Scopes the handoff template and the carry-over rule FIRST (sections, what counts as an open item, the must-not-drop list), then a developer gathers the shift's signals (active incidents, recent pages, deferred follow-ups) and assembles the handoff so the incoming engineer can pick up cold. Scoping the template and carry-over rule before assembling is what guarantees no live incident or hot watch-item is dropped at the shift boundary. Use for on-call handoffs, shift handover notes, pager handoff, SRE shift change, and end-of-shift summaries.",
   "tags": [

package/data/craftbook-templates/on/one-pager/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "one-pager",
   "role": "general",
+  "category": "marketing",
   "name": "One-Pager Brief",
   "description": "Create a single-page brief or summary that fits one printed page and lands one message fast — a product one-pager, executive summary, project brief, or leave-behind. Scopes the single audience + the one thing they must remember FIRST, then designs a tight one-page layout (headline, scannable sections, a sidebar of facts), then writes punchy copy that fits the page — ruthless about cutting anything that pushes past one page. Use when the answer must be skimmable in 60 seconds on a single sheet.",
   "tags": [

package/data/craftbook-templates/op/ops-runbook/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "ops-runbook",
   "role": "maintenance-review",
+  "category": "code-ops",
   "name": "Execute an Ops Runbook",
   "description": "Execute a written operational procedure step by step with verification and a stop-on-anomaly rule. Inventories the runbook and its preconditions FIRST, then executes each step in order — act, verify the step's own check, record verbatim evidence in a run log — halting immediately when observed state does not match what the procedure expects, then writes an outcome report (clean completion, or a halt report naming the failing step, expected vs. observed, and the steps deliberately not executed). Recording verbatim evidence and refusing to run past an anomaly is the wisdom that separates a trustworthy operator from one who papers over broken state.",
   "tags": [

package/data/craftbook-templates/pa/page-spread/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "page-spread",
   "role": "general",
+  "category": "media",
   "name": "Page Spread",
   "description": "Produce one page spread from script to panels: beats planned, panel art generated against the character sheets — never freehand from memory — lettered and laid out as the page the reader turns to. Locks the panel plan FIRST — each panel naming the sheet references that anchor it and the caption text it carries — then generates the panels from those anchors, then assembles the lettered spread. Use for producing a comic page, 'let's do page three', panel-and-letter passes, turning a script page into art, and the per-page ritual of a whole book.",
   "tags": [

package/data/craftbook-templates/pa/parser-grammar/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "parser-grammar",
   "role": "project-starter",
+  "category": "code-data",
   "name": "Parser / DSL for a Small Grammar",
   "description": "Build a parser for a small domain-specific language or data format — tokenize, parse to an AST, and report clear errors on malformed input. Designs the grammar FIRST — the token set, the grammar rules (BNF-style), operator precedence, the AST node shapes, and the error strategy — then implements lexer + parser producing the AST, then tests valid inputs parse to the right AST and invalid inputs fail with useful errors. Covers tokenization/lexing, recursive-descent parsing, grammar rules, operator precedence, AST construction, and helpful parse-error messages.",
   "tags": [

package/data/craftbook-templates/pe/perf-audit/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "perf-audit",
   "role": "maintenance-review",
+  "category": "code-quality",
   "name": "Performance Audit",
   "description": "Audit an application or page for performance problems with measurements, then produce a report of the highest-impact optimizations. First scopes the workloads and locks a performance budget and checklist (load time and Core Web Vitals, bundle/asset weight, render and main-thread cost, network waterfall and request count, server/query latency, memory and re-render churn), then MEASURES each against a baseline using real profiling rather than guessing, then writes a report that ranks bottlenecks by impact-vs-effort with a specific fix and the expected gain for each. Use this for a performance audit, speed optimization, finding bottlenecks, a Lighthouse-style review, reducing load time, or profiling slowness — it grounds every recommendation in a measured number and an estimated payoff, not 'it feels slow'.",
   "tags": [

package/data/craftbook-templates/pe/perf-audit/versions/1.1.0/craftbook.json

@@ -0,0 +1,195 @@
+{
+  "id": "perf-audit",
+  "name": "Performance Audit",
+  "description": "Audit an application or page for performance problems with measurements, then produce a report of the highest-impact optimizations. First scopes the workloads and locks a performance budget and checklist (load time and Core Web Vitals, bundle/asset weight, render and main-thread cost, network waterfall and request count, server/query latency, memory and re-render churn), then MEASURES each against a baseline using real profiling rather than guessing, then writes a report that ranks bottlenecks by impact-vs-effort with a specific fix and the expected gain for each. Use this for a performance audit, speed optimization, finding bottlenecks, a Lighthouse-style review, reducing load time, or profiling slowness — it grounds every recommendation in a measured number and an estimated payoff, not 'it feels slow'.\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 perf budget (reviewer) — lock workloads, a budget, and a metrics checklist → gated on artifact `{{workPath}}/scope.md` (markdown-notes)\n2. Measure the baseline (developer) — profile each workload, locate the real bottlenecks → gated on artifact `{{workPath}}/measure.md` (markdown-notes)\n3. Write the perf report (reviewer) — rank optimizations by impact vs effort → gated on artifact `{{workPath}}/perf-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": [
+    "performance audit",
+    "why is this slow",
+    "find the bottleneck",
+    "optimize load time",
+    "speed this up",
+    "profile the app"
+  ],
+  "steps": [
+    {
+      "id": "scope",
+      "name": "Scope the perf budget",
+      "description": "lock workloads, a budget, and a metrics checklist",
+      "prompt": "Step 1: Identify the workloads to audit (the slow page/route/endpoint/operation and its typical usage). Step 2: Write a performance acceptance-criteria checklist with concrete budgets, drawn from the relevant metrics: page load and Core Web Vitals (LCP < 2.5s, CLS < 0.1, INP < 200ms), total JS/CSS/image transfer weight, time-to-interactive and main-thread blocking, request count and waterfall serialization, server response and DB query latency (and N+1 detection), and memory growth / excessive re-renders for SPAs. Step 3: For each metric, set the target/budget for THIS app and note the current pain. Step 4: Decide the measurement method and environment (Lighthouse/devtools/profiler/timing logs if available; otherwise read the code and reason about asymptotic and I/O costs). Write the workloads + budgeted checklist + method to `write_task_note` AND `{{workPath}}/scope.md`. No optimizing yet — define 'fast enough' first.\n\nThe deliverable `{{workPath}}/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": "reviewer",
+      "advanceWhen": {
+        "file": "{{workPath}}/scope.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "{{workPath}}/scope.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "{{workPath}}/scope.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "scope",
+        "maxAttempts": 3
+      },
+      "next": "measure"
+    },
+    {
+      "id": "measure",
+      "name": "Measure the baseline",
+      "description": "profile each workload, locate the real bottlenecks",
+      "prompt": "Step 1: Establish a baseline by MEASURING each metric in the checklist (run Lighthouse/devtools/a profiler, time the endpoint, inspect the network waterfall and bundle, log query times). If no live env, statically analyze: bundle composition, algorithmic complexity of hot paths, query patterns, and render triggers. Step 2: For each metric over budget, drill into WHY — which asset is heaviest, which function dominates the flame chart, which query is slow or repeated, which component re-renders needlessly. Step 3: Record the actual numbers (e.g. 'LCP 4.1s; main.js is 480KB, 60% is moment.js+lodash'; 'GET /feed: 1.2s, runs 1+N queries, N≈40'). Step 4: For each bottleneck, identify the fix and ESTIMATE the expected gain and the effort. Step 5: Separate confirmed bottlenecks from suspicions you could not measure. Good looks like: every claim has a number behind it. Stage measurements to `write_task_note`. Do not write the report yet.\n\nThe deliverable `{{workPath}}/measure.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": "developer",
+      "advanceWhen": {
+        "file": "{{workPath}}/measure.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "{{workPath}}/measure.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "{{workPath}}/measure.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "measure",
+        "maxAttempts": 3
+      },
+      "next": "report"
+    },
+    {
+      "id": "report",
+      "name": "Write the perf report",
+      "description": "rank optimizations by impact vs effort",
+      "prompt": "Step 1: Open `{{workPath}}/perf-report.md` and write a '## Summary' table of each metric: budget vs measured vs PASS/FAIL. Step 2: Add a '## Recommendations' section ranked by impact-vs-effort; each entry: the bottleneck (with its measured number), the specific fix (e.g. 'code-split the editor route and lazy-load it', 'replace the 1+N with a single JOIN/batch', 'serve images as WebP at 2x and add width/height'), the ESTIMATED gain, and the effort. Step 3: Add a '## Quick wins' callout for the high-impact/low-effort items to do first. Step 4: Add a '## Needs measurement' section for suspicions not yet confirmed. Every recommendation must cite a measured number and an expected payoff — no generic 'optimize images'. On a loop-back, fix only the named gaps. `write_task_note` the report path and the count of failing metrics.\n\nThe deliverable `{{workPath}}/perf-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": "reviewer",
+      "advanceWhen": {
+        "file": "{{workPath}}/perf-report.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true,
+        "requireChange": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "{{workPath}}/perf-report.md",
+            "bytes": 1500,
+            "artifact": true
+          },
+          {
+            "kind": "contains",
+            "file": "{{workPath}}/perf-report.md",
+            "pattern": "(?:^|\\n)#{1,3}\\s+\\S",
+            "flags": "i",
+            "label": "at least one markdown heading",
+            "artifact": true
+          },
+          {
+            "kind": "citationsResolve",
+            "file": "{{workPath}}/perf-report.md",
+            "minCitations": 2,
+            "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 `{{workPath}}/perf-report.md` with `read_artifact` first, then review it against the original scope: every claim cites a real path, the severities and priorities are defensible, and nothing important in scope was skipped. Open the underlying files for at least the top findings; do not grade from the report's own summary. If a finding cannot be verified, say so explicitly.\n\nWrite your review to the artifact `{{workPath}}/review.md` with one `write_artifact` call: what you checked, what held, what did not (as a findings table with columns `| Severity | File | Line | Problem | Fix |` when anything needs fixing), ending with exactly `Verdict: PASS` or `Verdict: REVISE`. The gate enforces the verdict: a well-formed REVISE is routed back to the `report` step automatically with your findings. On PASS, `advance_task_step` to `finish`.",
+      "suggestedRole": "reviewer",
+      "consumes": [
+        {
+          "file": "{{workPath}}/perf-report.md",
+          "artifact": true
+        }
+      ],
+      "next": "finish",
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "{{workPath}}/review.md",
+            "bytes": 300,
+            "artifact": true
+          },
+          {
+            "kind": "contains",
+            "file": "{{workPath}}/review.md",
+            "pattern": "Verdict:\\s*(?:PASS|REVISE)",
+            "flags": "i",
+            "label": "explicit PASS or REVISE verdict",
+            "artifact": true
+          }
+        ],
+        "scripts": [
+          {
+            "name": "checkFixReview",
+            "scope": "standard",
+            "inputs": {
+              "taskRef": "{{task.ref}}",
+              "reviewPath": "{{workPath}}/review.md",
+              "fixStepId": "report"
+            }
+          }
+        ],
+        "onReject": "evaluate",
+        "maxAttempts": 4
+      }
+    },
+    {
+      "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-08-24T00:00:00.000Z",
+  "paramSchema": {
+    "type": "object",
+    "properties": {
+      "workPath": {
+        "type": "string",
+        "title": "Working folder",
+        "description": "Per-task working folder in the artifacts drawer. Defaults to this task's own folder so runs never collide; override with a stable name when you deliberately want runs to share files.",
+        "default": "{{task.dir}}"
+      }
+    }
+  },
+  "minGezelVersion": "1.26236",
+  "runModes": {
+    "nightShift": "supported"
+  }
+}

package/data/craftbook-templates/pe/perf-audit/versions/1.1.0/test.json

@@ -0,0 +1,165 @@
+{
+  "schemaVersion": 1,
+  "title": "Performance Audit smoke eval",
+  "objective": "Self-contained smoke eval for the Performance Audit craftbook using the external generic harness.",
+  "tags": [
+    "external"
+  ],
+  "prompt": "Theres a fake ops service wired up for this so nothing real gets touched — the endpoints are in mocks/services.md, and the ready-made mock-probe script talks to them for you. Can you run the automation against it and write up how it went in automation.md?",
+  "setup": {
+    "projectName": "Performance Audit Eval",
+    "about": "Self-contained eval project for perf-audit. Seeded inputs are under workspace/source or workspace/fixtures; final deliverable is workspace/automation.md.",
+    "missionObjectives": "Use the Performance Audit craftbook/template, read the seeded local fixtures, and write automation.md without network calls, real credentials, or live services.",
+    "files": [
+      {
+        "path": "source/brief.md",
+        "content": "# Performance Audit 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: perf-audit - Performance Audit.\n"
+      }
+    ],
+    "worker": {
+      "name": "Jules",
+      "role": "Developer"
+    },
+    "craftbookParams": {
+      "workPath": "tasks/eval"
+    }
+  },
+  "mocks": [
+    {
+      "kind": "http",
+      "id": "ops",
+      "description": "Fake operations service for this eval. GET /api/bookings/open lists the open work items; POST /api/bookings/dry-run records a simulated submission and returns DRY_RUN_OK.",
+      "credential": {
+        "name": "mock.ops"
+      },
+      "routes": [
+        {
+          "method": "GET",
+          "path": "/api/bookings/open",
+          "body": {
+            "items": [
+              "BKG-1001",
+              "BKG-1002",
+              "BKG-1003"
+            ]
+          }
+        },
+        {
+          "method": "POST",
+          "path": "/api/bookings/dry-run",
+          "status": 201,
+          "body": {
+            "status": "DRY_RUN_OK",
+            "recorded": 3
+          }
+        }
+      ]
+    },
+    {
+      "kind": "webhook",
+      "id": "notify",
+      "description": "Notification receiver. POST a JSON completion notice here when the run finishes.",
+      "path": "/hooks/notify"
+    },
+    {
+      "kind": "cli",
+      "id": "probe",
+      "description": "Provenance-trusted project script `mock-probe` that exercises the fake ops service through http.authed and returns the raw responses.",
+      "shim": {
+        "path": "scripts/mock-probe.ts",
+        "content": "import { defineScript, gezel } from '@bendyline/gezel-sdk';\n\nexport const meta = defineScript({\n  name: 'mock-probe',\n  description:\n    'Probe the live fake ops service for this eval: lists the open work items and records a dry-run submission. Outputs the raw JSON responses as evidence for the write-up.',\n  inputs: {},\n  outputs: {\n    open: { type: 'string', description: 'Raw JSON body from the open-items listing.' },\n    dryRun: { type: 'string', description: 'Raw JSON body from the dry-run submission.' },\n  },\n  requires: ['workspace.read', 'network', 'credential:mock.ops'],\n});\n\nconst services = JSON.parse(await gezel.fs.read('mocks/services.json'));\nconst base = (id) => {\n  const service = services.find((entry) => entry.id === id);\n  if (!service) throw new Error(`mock service \"${id}\" is not listed in mocks/services.json`);\n  return service.baseUrl;\n};\n\nconst open = await gezel.http.authed(`${base('ops')}/api/bookings/open`, {\n  credential: 'mock.ops',\n});\nif (!open.ok) throw new Error(`open-items listing failed: ${open.status} ${open.body}`);\n\nconst dryRun = await gezel.http.authed(`${base('ops')}/api/bookings/dry-run`, {\n  credential: 'mock.ops',\n  method: 'POST',\n  body: JSON.stringify({ items: JSON.parse(open.body).items, mode: 'dry-run' }),\n});\nif (!dryRun.ok) throw new Error(`dry-run submission failed: ${dryRun.status} ${dryRun.body}`);\n\ngezel.output({ open: open.body, dryRun: dryRun.body });\n"
+      }
+    }
+  ],
+  "success": {
+    "summary": "automation.md is grounded in live fake-service responses: the open items were actually listed and a dry-run actually recorded (request-log assertions), with safety guards and signals described.",
+    "deliverables": [
+      {
+        "path": "automation.md",
+        "kind": "markdown-report",
+        "minBytes": 900,
+        "checks": [
+          {
+            "kind": "contains",
+            "file": "automation.md",
+            "pattern": "(?:^|\\n)#{1,3}\\s+\\S",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "automation.md",
+            "pattern": "DRY_RUN_OK|dry-run|dry run",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "automation.md",
+            "pattern": "fake-ci|fake-github|/api/bookings",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "automation.md",
+            "pattern": "no real|credentials|safety|guard",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "automation.md",
+            "pattern": "success|failure|retry|abort",
+            "flags": "i"
+          }
+        ]
+      }
+    ],
+    "mocks": [
+      {
+        "service": "ops",
+        "minRequests": 2,
+        "requiredPaths": [
+          "^/api/bookings/open$",
+          "^/api/bookings/dry-run$"
+        ]
+      }
+    ]
+  },
+  "rubric": {
+    "artifact": {
+      "path": "automation.md",
+      "kind": "markdown"
+    },
+    "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": [
+    "dry-run safety",
+    "fake tool mapping",
+    "side-effect containment"
+  ],
+  "extensions": {
+    "legacySimulators": [
+      {
+        "id": "perf-audit-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/pe/perf-optimization/manifest.json

@@ -3,15 +3,16 @@
   "kind": "craftbook-template",
   "id": "perf-optimization",
   "role": "maintenance-review",
+  "category": "code-quality",
   "name": "Targeted Performance Fix",
-  "description": "Make a measured, targeted performance improvement — profile to find the real bottleneck, optimize it, then prove the speedup with before/after numbers while keeping behavior correct. Profiles FIRST and locks a measurable target, because optimizing without measuring is guessing, then applies the focused change, then a reviewer confirms the improvement is real, behavior is unchanged, and the code is not needlessly obfuscated. Covers profiling/benchmarking, hotspot identification, algorithmic vs micro optimization, before/after measurement, and correctness-preserving speedups.",
+  "description": "Make a measured, targeted performance improvement: baseline numbers recorded with their method before anything changes, one bottleneck fixed in reversible stages with the suite green, the same measurement re-run to prove the gain, and an enforced independent review.",
   "tags": [
-    "gallery",
     "performance",
     "optimization",
     "profiling",
     "benchmark",
-    "speed"
+    "speed",
+    "tests"
   ],
   "maintainer": {
     "name": "Gezel"