@bendyline/gilde 0.1.38 → 0.1.40

package/data/craftbook-templates/al/alert-rules/versions/1.0.2/craftbook.json

@@ -0,0 +1,113 @@
+{
+  "id": "alert-rules",
+  "name": "Monitoring Alert Rules",
+  "description": "Author a set of monitoring/alerting rules as a deployable config (Prometheus alerting rules, Grafana/Alertmanager YAML, or a CloudWatch-style spec): the right signals, thresholds, severities, for-durations, and routing labels. Scopes the SLOs and alert philosophy FIRST (what to alert on, symptom-vs-cause, thresholds and burn windows, severity ladder, noise budget), then a developer writes the rules config to that spec, then a reviewer validates for completeness, dedupe, and anti-flapping. Scoping thresholds and severities before writing YAML is what produces actionable, low-noise alerts instead of a wall of CPU-over-80% pages. Use for alerting rules, Prometheus alerts, SLO monitoring, on-call paging rules, and reducing alert fatigue.\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 alerts (planner) — lock signals, thresholds, severities, and routing → gated on artifact `{{workPath}}/scope.md` (markdown-notes)\n2. Build the rules (developer) — write the alerting-rules config to the locked spec → gated on `alerts.yaml` (yaml-spec)\n\nThe gates never advance with an unmet criterion, and loop back to the\nowning phase to fix named gaps.\n",
+  "entryStepId": "scope",
+  "triggers": [
+    "write alert rules",
+    "prometheus alerts",
+    "monitoring rules",
+    "set up alerting",
+    "SLO alerts"
+  ],
+  "steps": [
+    {
+      "id": "scope",
+      "name": "Scope the alerts",
+      "description": "lock signals, thresholds, severities, and routing",
+      "prompt": "Define the alerting philosophy before writing config. (1) List the services/SLOs to cover and, for each, the symptom-level signals that matter (latency p99, error rate, saturation, availability) — prefer alerting on user-facing symptoms over raw causes. (2) For every signal lock a threshold, an evaluation/for-duration (to suppress transient spikes), and a severity from a fixed ladder (page = wake someone, ticket = next business day, info = dashboard-only). (3) Define routing labels (team/service/severity) and which severities page. (4) State a noise budget (e.g. no more than N page-level rules) and require a runbook link annotation on every page-level alert. (5) Pick the output format (Prometheus alerting-rules YAML by default). Write an acceptance-criteria checklist ('every SLO has at least one symptom alert', 'every alert has expr + for + severity + summary + runbook annotation', 'no duplicate/overlapping alerts', 'page-level alerts within the noise budget', 'config is valid YAML for the target system') plus the table of signals/thresholds to {{workPath}}/scope.md via write_task_note AND the produces path. No YAML yet.\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": "planner",
+      "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": "build"
+    },
+    {
+      "id": "build",
+      "name": "Build the rules",
+      "description": "write the alerting-rules config to the locked spec",
+      "prompt": "Write alerts.yaml as a valid alerting-rules config for the target system using the locked signals. For EACH alert author: a clear alert name, the metric expression (expr) implementing the threshold, a for: duration (non-zero, to suppress flapping), labels (severity + routing), and annotations (a one-line summary with templated context, a description, and a runbook_url for page-level alerts). Group related alerts. Keep thresholds and for-durations exactly as scoped. Ensure the file parses as YAML and matches the target's schema (e.g. groups[].rules[].alert/expr/for/labels/annotations for Prometheus). Cover every scoped SLO with at least one symptom-level alert, add no alerts that weren't scoped, avoid duplicate/overlapping rules, and do not exceed the page-level noise budget. On a loop-back fix only the flagged rules. Write the path and an alert count (by severity) to notes via write_task_note.",
+      "suggestedRole": "developer",
+      "advanceWhen": {
+        "file": "alerts.yaml",
+        "minBytes": 1,
+        "sniff": "nonempty"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "alerts.yaml",
+            "bytes": 200
+          },
+          {
+            "kind": "sniff",
+            "file": "alerts.yaml",
+            "sniff": "nonempty"
+          }
+        ],
+        "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": "Validate alerts.yaml against every locked criterion. (1) Parse the YAML — invalid YAML or non-conformance to the target system's rule schema (e.g. groups[].rules[]) is an immediate FAIL. (2) Confirm every scoped SLO is covered by at least one symptom-level alert; FAIL on any missing SLO. (3) Check each alert carries expr, a non-zero for: duration, a severity from the ladder, routing labels, a summary, and — for page-level alerts — a runbook_url annotation. (4) Scan for duplicate or overlapping rules (two firing on the same condition) and flag them. (5) Confirm page-level alerts stay within the noise budget, and sanity-check 2-3 thresholds and for-durations against the scope. Write PASS/FAIL per criterion with the specific offending rule names.\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": "alerts.yaml"
+        }
+      ],
+      "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.2",
+  "releasedAt": "2026-08-21T00:00:00Z",
+  "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.26233"
+}

package/data/craftbook-templates/al/alert-rules/versions/1.0.2/test.json

@@ -0,0 +1,148 @@
+{
+  "schemaVersion": 1,
+  "title": "Prometheus alerts from scoped SLO brief",
+  "objective": "Measure whether the alert-rules craftbook scopes symptom alerts before writing deployable, low-noise alerting YAML.",
+  "tags": [
+    "html-page"
+  ],
+  "prompt": "In the `Alert Rules Eval` project, read `source/slo-brief.md` and write `alerts.yaml` as Prometheus-style alerting rules. Scope the signals and noise budget first, then produce YAML with groups, alert names, expr, for, severity/routing labels, summaries, descriptions, and runbook_url annotations for page alerts.",
+  "setup": {
+    "projectName": "Alert Rules Eval",
+    "about": "Self-contained eval project for alert-rules. The service SLO brief is in workspace/source/slo-brief.md and the deliverable is workspace/alerts.yaml.",
+    "missionObjectives": "Produce low-noise alerting rules from the seeded SLO brief with symptom signals, thresholds, severities, runbook links, and routing labels.",
+    "files": [
+      {
+        "path": "source/slo-brief.md",
+        "content": "# Alert scope brief\n\nService: Harbor Payments checkout-api and webhook-worker.\n\nSLOs:\n- Checkout p99 latency should stay below 800 ms over 10 minutes.\n- Checkout 5xx error rate should stay below 2% over 5 minutes.\n- Webhook retry backlog should stay below 5,000 jobs for more than 10 minutes.\n\nRouting:\n- page severity routes to team=payments, service=checkout-api or webhook-worker.\n- ticket severity routes to team=payments during business hours.\n- Page-level noise budget: no more than two page alerts.\n- Required runbooks: https://runbooks.example/payments/checkout-latency, https://runbooks.example/payments/checkout-errors, https://runbooks.example/payments/webhook-backlog.\n"
+      }
+    ],
+    "worker": {
+      "name": "Aafke",
+      "role": "SRE"
+    },
+    "craftbookParams": {
+      "workPath": "tasks/eval"
+    }
+  },
+  "mocks": [],
+  "success": {
+    "summary": "workspace/alerts.yaml is a Prometheus-style rule file with scoped symptom signals, thresholds, severities, routing, runbook annotations, and noise-budget evidence.",
+    "deliverables": [
+      {
+        "path": "alerts.yaml",
+        "kind": "yaml-spec",
+        "minBytes": 1200,
+        "checks": [
+          {
+            "kind": "prometheusAlerts",
+            "file": "alerts.yaml",
+            "minRules": 3,
+            "maxPageAlerts": 2,
+            "allowedSeverities": [
+              "page",
+              "ticket",
+              "info"
+            ],
+            "requiredServices": [
+              "checkout-api",
+              "webhook-worker"
+            ],
+            "requiredRunbookUrls": [
+              "https://runbooks.example/payments/checkout-latency",
+              "https://runbooks.example/payments/checkout-errors",
+              "https://runbooks.example/payments/webhook-backlog"
+            ]
+          },
+          {
+            "kind": "contains",
+            "file": "alerts.yaml",
+            "pattern": "groups:|rules:|alert:|expr:|for:",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "alerts.yaml",
+            "pattern": "severity:|team:|service:",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "alerts.yaml",
+            "pattern": "runbook_url|runbook",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "alerts.yaml",
+            "pattern": "checkout-api|webhook-worker|latency|error|backlog",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "alerts.yaml",
+            "pattern": "800|0\\.8|2%|0\\.02|5000|5,000|10m|5m",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "alerts.yaml",
+            "pattern": "histogram_quantile|p99|0\\.99",
+            "flags": "i",
+            "label": "checkout latency alert uses a p99 signal"
+          },
+          {
+            "kind": "contains",
+            "file": "alerts.yaml",
+            "pattern": "5xx|5\\.\\.|status",
+            "flags": "i",
+            "label": "checkout error alert targets 5xx rate"
+          },
+          {
+            "kind": "contains",
+            "file": "alerts.yaml",
+            "pattern": "retry|backlog|5000|5,000",
+            "flags": "i",
+            "label": "webhook backlog alert uses retry backlog threshold"
+          },
+          {
+            "kind": "notContains",
+            "file": "alerts.yaml",
+            "pattern": "CPU|memory|disk|node_cpu|node_memory|node_filesystem",
+            "flags": "i",
+            "label": "avoid raw infrastructure cause alerts not present in the SLO brief"
+          }
+        ]
+      }
+    ]
+  },
+  "rubric": {
+    "artifact": {
+      "path": "alerts.yaml",
+      "kind": "yaml"
+    },
+    "axes": [
+      {
+        "name": "structure",
+        "description": "Layout and hierarchy fit the content; sections are scannable and coherent."
+      },
+      {
+        "name": "grounding",
+        "description": "Seeded source content is used faithfully — no invented facts or dropped requirements."
+      },
+      {
+        "name": "interactivity",
+        "description": "Controls and states the page claims to offer actually work."
+      },
+      {
+        "name": "polish",
+        "description": "Styling is intentional and responsive rather than unstyled or broken."
+      }
+    ]
+  },
+  "qualityFocus": [
+    "symptom alerts",
+    "noise budget",
+    "runbook annotations",
+    "routing labels"
+  ]
+}

package/data/craftbook-templates/al/alt-text-pass/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "alt-text-pass",
   "role": "general",
+  "category": "code-review",
   "name": "Alt-Text Pass",
   "description": "Generate accurate, WCAG-appropriate alt text for every image referenced by a site or folder and apply it back into the markup. Scope FIRST which images are content vs decorative (decorative images get empty alt, not a description) and the voice/length rules, because the most common alt-text failure is verbose, redundant, or wrong-purpose descriptions. Then caption each content image from what is actually visible and write the alt attributes back into the HTML. Covers accessibility, alt text, image descriptions, WCAG compliance, screen-reader support, and a11y retrofits.",
   "tags": [

package/data/craftbook-templates/al/alt-text-pass/versions/1.0.2/craftbook.json

@@ -0,0 +1,154 @@
+{
+  "id": "alt-text-pass",
+  "name": "Alt-Text Pass",
+  "description": "Generate accurate, WCAG-appropriate alt text for every image referenced by a site or folder and apply it back into the markup. Scope FIRST which images are content vs decorative (decorative images get empty alt, not a description) and the voice/length rules, because the most common alt-text failure is verbose, redundant, or wrong-purpose descriptions. Then caption each content image from what is actually visible and write the alt attributes back into the HTML. Covers accessibility, alt text, image descriptions, WCAG compliance, screen-reader support, and a11y retrofits.\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 pass (planner) — list images, classify content vs decorative, set rules → gated on artifact `{{workPath}}/scope.md` (markdown-notes)\n2. Caption content images (developer) — write alt text from what is actually visible → gated on artifact `{{workPath}}/caption.md` (markdown-notes)\n3. Apply to markup (developer) — write alt attributes back into the HTML → gated on `index.html` (html-page)\n\nThe gates never advance with an unmet criterion, and loop back to the\nowning phase to fix named gaps.\n",
+  "entryStepId": "scope",
+  "triggers": [
+    "add alt text",
+    "generate alt text for images",
+    "make images accessible",
+    "alt text for my site",
+    "wcag image descriptions"
+  ],
+  "steps": [
+    {
+      "id": "scope",
+      "name": "Scope the pass",
+      "description": "list images, classify content vs decorative, set rules",
+      "prompt": "1) Find every image reference (img tags, CSS background images, picture/source) in the target file(s) or folder and list each with its current alt (if any) and surrounding context. 2) Classify each as CONTENT (conveys information → needs a description) or DECORATIVE (purely visual → must get alt=\"\"). 3) Set the rules: alt text is concise (roughly under ~125 chars), describes purpose/content not 'image of', never duplicates adjacent caption text, and conveys any text embedded in the image. 4) Write an acceptance-criteria checklist: 'every content image has non-empty, purposeful alt', 'every decorative image has alt=\"\"', 'no alt begins with \"image of\"/\"picture of\"', 'embedded text is transcribed', 'no alt is redundant with nearby visible text'. 5) Record the inventory + rules + checklist via write_task_note AND to {{workPath}}/scope.md.\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": "planner",
+      "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": "caption"
+    },
+    {
+      "id": "caption",
+      "name": "Caption content images",
+      "description": "write alt text from what is actually visible",
+      "prompt": "1) Read scope.md's inventory and rules. 2) For each CONTENT image, use the vision capability to look at the actual image and write alt text that conveys its purpose in context (a chart's takeaway, a product's key detail, a screenshot's salient state) — not a literal pixel inventory. 3) Transcribe any meaningful text baked into the image. 4) Keep each under the length rule and avoid 'image of'/'photo of' openers. 5) For DECORATIVE images, record alt=\"\" (intentional empty). 6) Produce a mapping of image → alt string. write_task_note the mapping. Good looks like: a blind user would understand each image's role from your text alone.\n\nThe deliverable `{{workPath}}/caption.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}}/caption.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "{{workPath}}/caption.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "{{workPath}}/caption.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "caption",
+        "maxAttempts": 3
+      },
+      "next": "apply"
+    },
+    {
+      "id": "apply",
+      "name": "Apply to markup",
+      "description": "write alt attributes back into the HTML",
+      "prompt": "1) Read the caption mapping. 2) Edit the source HTML so every img has the correct alt attribute (content → its description, decorative → alt=\"\"). 3) For CSS background images that carry meaning, add an accessible equivalent (aria-label or a visually-hidden span) since they cannot take alt. 4) Do not alter layout, other attributes, or content — only the accessibility attributes. 5) Confirm the HTML still parses/renders. 6) On a loop-back, fix only the images the reviewer flagged. 7) write_task_note the edited file path and a count of images updated (content vs decorative). The deliverable is the updated index.html.",
+      "suggestedRole": "developer",
+      "advanceWhen": {
+        "file": "index.html",
+        "minBytes": 1,
+        "sniff": "html-complete"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "index.html",
+            "bytes": 800
+          },
+          {
+            "kind": "htmlLint",
+            "file": "index.html"
+          }
+        ],
+        "scripts": [
+          {
+            "name": "checkHtmlComplete",
+            "scope": "standard",
+            "inputs": {
+              "file": "index.html"
+            }
+          }
+        ],
+        "onReject": "apply",
+        "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 index.html and enumerate every image. 2) Cross-check against scope.md: every content image has non-empty purposeful alt; every decorative image has alt=\"\" (PASS/FAIL each class). 3) Verify no alt opens with 'image of'/'picture of' and none is over-long or redundant with adjacent text. 4) Spot-check 3 captions against the real images — accurate and purposeful? 5) Confirm CSS-background meaningful images got an aria equivalent. 6) Write PASS/FAIL per criterion. Any failure → loop back to apply (or caption if a description is wrong).\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: \"apply\" })` to loop back. The builder fixes exactly those gaps.\n\nNever route to `finish` while any criterion is unmet. The build phase's completion gate already blocked a grossly-incomplete deliverable; your job is the judgment an automated check cannot make (does it actually work, read well, look right). After ~3 unproductive loops, stop and report DONE_WITH_CONCERNS so the user can step in.",
+      "suggestedRole": "reviewer",
+      "consumes": [
+        {
+          "file": "index.html"
+        }
+      ],
+      "next": "apply"
+    },
+    {
+      "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.2",
+  "releasedAt": "2026-08-21T00:00:00Z",
+  "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.26233"
+}

package/data/craftbook-templates/al/alt-text-pass/versions/1.0.2/test.json

@@ -0,0 +1,100 @@
+{
+  "schemaVersion": 1,
+  "title": "Alt-Text Pass smoke eval",
+  "objective": "Self-contained smoke eval for the Alt-Text Pass craftbook using the html-page generic harness.",
+  "tags": [
+    "html-page"
+  ],
+  "prompt": "Can you biuld us a little page for this? The content notes are in source/page-content.md. Save it as index.html — one file, nothing fancy needed on our end.",
+  "setup": {
+    "projectName": "Alt-Text Pass Eval",
+    "about": "Self-contained eval project for alt-text-pass. Seeded inputs are under workspace/source or workspace/fixtures; final deliverable is workspace/index.html.",
+    "missionObjectives": "Use the Alt-Text Pass craftbook/template, read the seeded local fixtures, and write index.html without network calls, real credentials, or live services.",
+    "files": [
+      {
+        "path": "source/brief.md",
+        "content": "# Alt-Text Pass 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: alt-text-pass - Alt-Text Pass.\n"
+      },
+      {
+        "path": "source/page-content.md",
+        "content": "# Boreal Desk Support Board\n\nBuild content around a support operations board. Required labels: Open issues, Status silence, Response time, Refund leakage, Next action. Required metric text: 18 hours to 6 hours and 14.2% to 8.9%.\n"
+      }
+    ],
+    "worker": {
+      "name": "Jules",
+      "role": "Developer"
+    },
+    "craftbookParams": {
+      "workPath": "tasks/eval"
+    }
+  },
+  "mocks": [],
+  "success": {
+    "summary": "index.html is a source-grounded self-contained HTML page/tool.",
+    "deliverables": [
+      {
+        "path": "index.html",
+        "kind": "html-page",
+        "minBytes": 3000,
+        "checks": [
+          {
+            "kind": "cssMinBytes",
+            "bytes": 650,
+            "file": "index.html"
+          },
+          {
+            "kind": "jsParses",
+            "file": "index.html"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "Boreal|Support Board|returns",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "18\\s*hours|6\\s*hours|14\\.2%|8\\.9%",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "index.html",
+            "pattern": "button|input|filter|tab|card|section|nav",
+            "flags": "i"
+          }
+        ]
+      }
+    ]
+  },
+  "rubric": {
+    "artifact": {
+      "path": "index.html",
+      "kind": "html"
+    },
+    "axes": [
+      {
+        "name": "structure",
+        "description": "Layout and hierarchy fit the content; sections are scannable and coherent."
+      },
+      {
+        "name": "grounding",
+        "description": "Seeded source content is used faithfully — no invented facts or dropped requirements."
+      },
+      {
+        "name": "interactivity",
+        "description": "Controls and states the page claims to offer actually work."
+      },
+      {
+        "name": "polish",
+        "description": "Styling is intentional and responsive rather than unstyled or broken."
+      }
+    ]
+  },
+  "qualityFocus": [
+    "self-contained UI",
+    "source grounding",
+    "responsive structure"
+  ]
+}

package/data/craftbook-templates/an/anniversary-cut/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "anniversary-cut",
   "role": "general",
+  "category": "media",
   "name": "Anniversary Cut",
   "description": "Build the highlight reel for the occasion: the archive queried for the person and the years that matter, clips chosen with stated reasons, assembled through the project's media pipeline with a run log, and delivered with a chapter list and a dedication — the reel that makes the birthday. Locks the occasion and the selection criteria FIRST (era coverage, the famous moments in, a length budget), then selects from the archive with no invented footage, then assembles, then writes the presentation notes. Use for birthday reels, anniversary videos, memorial montages, 'make a highlight reel', and milestone tributes.",
   "tags": [