@bendyline/gilde 0.1.38 → 0.1.40

package/data/craftbook-templates/mo/mock-interview/versions/1.0.2/craftbook.json

@@ -0,0 +1,151 @@
+{
+  "id": "mock-interview",
+  "name": "Mock Interview",
+  "description": "A realistic practice interview run live with the candidate — planned questions calibrated to the target role and round, a real-time interview with pressure follow-ups, and a kind, specific debrief: strengths in the candidate's own words, fixes with sketched stronger answers, one drill, and an honest readiness read. The debrief is the deliverable. Use before any real interview round.\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. Plan the interview (Oefen-interviewer) — six to ten calibrated questions with planned follow-up chains → gated on artifact `{{workPath}}/interview-plan.md` (markdown-notes)\n2. Conduct the interview (Oefen-interviewer) — the live practice round, transcribed as it runs → gated on artifact `{{workPath}}/interview-transcript.md` (markdown-notes)\n3. Write the debrief (Oefen-interviewer) — kind, specific, grounded in the transcript → gated on artifact `{{workPath}}/reports/interview-debrief.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": "plan",
+  "triggers": [
+    "mock interview",
+    "practice interview",
+    "interview prep session",
+    "run me through a practice round"
+  ],
+  "steps": [
+    {
+      "id": "plan",
+      "name": "Plan the interview",
+      "description": "six to ten calibrated questions with planned follow-up chains",
+      "prompt": "Build the interview plan. Step 1: establish the target role, company, and round — read the project's pipeline record and company brief when present; otherwise ask, briefly. Step 2: draft six to ten questions mixing behavioral and role-specific, calibrated to the round (a recruiter screen is not a final loop). Step 3: for each major expected claim, plan a follow-up chain — the 'what did YOU do?' probe. At least one chain must apply real pressure. Step 4: define the debrief contract up front: two or three strengths quoting the candidate, two or three fixes each with a sketched stronger answer, exactly one drill, and a readiness read. Step 5: write an acceptance-criteria checklist ('questions specific to the target role', 'at least one pressure follow-up chain', 'debrief contract stated'). Write the plan + checklist via write_task_note AND to {{workPath}}/interview-plan.md.\n\nThe deliverable `{{workPath}}/interview-plan.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": "Oefen-interviewer",
+      "advanceWhen": {
+        "file": "{{workPath}}/interview-plan.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "{{workPath}}/interview-plan.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "{{workPath}}/interview-plan.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "plan",
+        "maxAttempts": 3
+      },
+      "next": "conduct"
+    },
+    {
+      "id": "conduct",
+      "name": "Conduct the interview",
+      "description": "the live practice round, transcribed as it runs",
+      "prompt": "Run the interview live with the user. Step 1: set the frame in one line ('I'm your interviewer for a <round> for <role> — ready?') then go in character. Step 2: one question per turn, through the user-interaction capabilities on your current roster; wait for the answer before the next. Step 3: use the planned follow-up chains on vague or team-credited answers; stay realistic, never cruel — if the candidate is rattled, step out of character, steady them, resume when ready. Step 4: after each exchange, append a condensed record to {{workPath}}/interview-transcript.md: the question, the gist of the answer, your one-line read. Step 5: end the roleplay explicitly ('Stepping out of character now') once the planned questions or the candidate's energy are spent. The transcript file is the phase's deliverable — keep it current as you go, not reconstructed after.\n\nThe deliverable `{{workPath}}/interview-transcript.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": "Oefen-interviewer",
+      "advanceWhen": {
+        "file": "{{workPath}}/interview-transcript.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "{{workPath}}/interview-transcript.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "{{workPath}}/interview-transcript.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "conduct",
+        "maxAttempts": 3
+      },
+      "next": "debrief"
+    },
+    {
+      "id": "debrief",
+      "name": "Write the debrief",
+      "description": "kind, specific, grounded in the transcript",
+      "prompt": "Write {{workPath}}/reports/interview-debrief.md to the contract from the plan. Step 1: '## Strengths' — two or three, each quoting the candidate's own words from the transcript so they can hear what worked. Step 2: '## Fixes' — two or three, each naming the moment it surfaced, why it lands badly in a real round, and a sketched stronger answer they could actually give. Step 3: '## Drill' — exactly one exercise to run before the real interview, matched to the biggest fix. Step 4: '## Readiness' — an honest read: ready, or one more round (and on what). Step 5: every point must trace to the transcript; no generic interview advice. On a loop-back, fix ONLY the named issues.\n\nThe deliverable `{{workPath}}/reports/interview-debrief.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": "Oefen-interviewer",
+      "advanceWhen": {
+        "file": "{{workPath}}/reports/interview-debrief.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "{{workPath}}/reports/interview-debrief.md",
+            "bytes": 1500,
+            "artifact": true
+          },
+          {
+            "kind": "contains",
+            "file": "{{workPath}}/reports/interview-debrief.md",
+            "pattern": "(?:^|\\n)#{1,3}\\s+\\S",
+            "flags": "i",
+            "label": "at least one markdown heading",
+            "artifact": true
+          }
+        ],
+        "onReject": "debrief",
+        "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": "Review the debrief as the candidate's coach. Step 1: cross-check every fix and strength against {{workPath}}/interview-transcript.md — FAIL any point that does not trace to an actual exchange. Step 2: check the tone — kind and concrete; FAIL generic advice ('be more confident') that names no moment and sketches no stronger answer. Step 3: confirm exactly one drill, actionable tonight. Step 4: confirm the readiness read is honest about whether another round is needed. Write PASS/FAIL per criterion.\n\nThe deliverable lives in the project's artifacts drawer — open `{{workPath}}/reports/interview-debrief.md` with `read_artifact`, not `read_file`.\n\nThen route — this is the whole point of the loop:\n\n- **Every criterion PASSES →** call `advance_task_step({ ref, stepId: \"evaluate\", next: \"finish\" })`.\n- **Any criterion FAILS →** write the specific gaps to notes, then call `advance_task_step({ ref, stepId: \"evaluate\", next: \"debrief\" })` 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": "{{workPath}}/reports/interview-debrief.md",
+          "artifact": true
+        }
+      ],
+      "next": "debrief"
+    },
+    {
+      "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/mo/mock-interview/versions/1.0.2/test.json

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

package/data/craftbook-templates/mo/mod-scaffold/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "mod-scaffold",
   "role": "project-starter",
+  "category": "code-build",
   "name": "Scaffold a Mod",
   "description": "Start the mod right: a correctly-shaped Minecraft datapack — pack.mcmeta carrying the right format number for the target game version, namespaced folders laid out properly, and one working example of the mod's core idea — plus install steps a twelve-year-old can follow. Locks the idea and the version's structure rules FIRST, then scaffolds the tree, then writes the README. Use for starting a datapack, scaffolding a mod, 'my kid wants a mod that…', datapack setup, and first-mod projects.",
   "tags": [

package/data/craftbook-templates/mo/mod-scaffold/versions/1.0.2/craftbook.json

@@ -0,0 +1,168 @@
+{
+  "id": "mod-scaffold",
+  "name": "Scaffold a Mod",
+  "description": "Start the mod right: a correctly-shaped Minecraft datapack — pack.mcmeta carrying the right format number for the target game version, namespaced folders laid out properly, and one working example of the mod's core idea — plus install steps a twelve-year-old can follow. Locks the idea and the version's structure rules FIRST, then scaffolds the tree, then writes the README. Use for starting a datapack, scaffolding a mod, 'my kid wants a mod that…', datapack setup, and first-mod projects.\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 mod (modmaker) — the idea, the target version, the structure rules locked → gated on artifact `{{workPath}}/scope.md` (markdown-notes)\n2. Scaffold the datapack (developer) — pack.mcmeta plus the namespaced tree with one working example → gated on `pack.mcmeta` (json)\n3. Write the README (copywriter) — install and test steps a twelve-year-old can follow → gated on `README.md` (markdown-doc)\n\nThe gates never advance with an unmet criterion, and loop back to the\nowning phase to fix named gaps.\n",
+  "entryStepId": "scope",
+  "triggers": [
+    "scaffold a mod",
+    "start a datapack",
+    "make a minecraft mod",
+    "set up the datapack",
+    "my kid wants a mod"
+  ],
+  "steps": [
+    {
+      "id": "scope",
+      "name": "Scope the mod",
+      "description": "the idea, the target version, the structure rules locked",
+      "prompt": "Define the mod before creating a single file. Step 1: state the mod's core idea in one sentence — the thing that should happen in the game — and the target game version it must run on. Step 2: lock the structure rules for that version — the pack_format number pack.mcmeta must carry for the target version (from the project's version notes when present, stated explicitly either way), the namespace for this mod (short, lowercase, no spaces), and the folder layout the version expects under data/ for the mechanics the idea needs (functions, recipes, advancements, tags). Step 3: decide the one working example that proves the core idea end to end — the smallest set of files that makes the thing actually happen in-game. Step 4: write an acceptance-criteria checklist ('pack.mcmeta is valid JSON with the right pack_format for the target version', 'all content lives under the namespaced folders', 'the working example is complete — every file it needs exists', 'README has install steps and a test step a kid can follow'). Call write_task_note with the idea + version + pack_format + checklist and write {{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": "modmaker",
+      "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": "scaffold"
+    },
+    {
+      "id": "scaffold",
+      "name": "Scaffold the datapack",
+      "description": "pack.mcmeta plus the namespaced tree with one working example",
+      "prompt": "Build the datapack tree against the locked rules. Step 1: write pack.mcmeta at the workspace root — valid JSON with the pack object carrying the pack_format number locked in scope and a one-line description of the mod. Step 2: lay out the namespaced tree under data/ exactly as the target version expects, and build the working example — every function, recipe, advancement, or tag file the core idea needs, each in its right folder with its right name; a scaffold whose example is missing a file teaches a kid that mods do not work. Step 3: use the version's correct folder names and identifier syntax throughout — one renamed folder between versions is the classic silent break, so double-check against the structure rules from scope. Step 4: re-read every JSON file for validity and every function file for command syntax. Call write_task_note with the file count and the namespace.",
+      "suggestedRole": "developer",
+      "advanceWhen": {
+        "file": "pack.mcmeta",
+        "minBytes": 1,
+        "sniff": "json-valid"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "pack.mcmeta",
+            "bytes": 2
+          },
+          {
+            "kind": "contains",
+            "file": "pack.mcmeta",
+            "pattern": "pack_format",
+            "label": "pack.mcmeta declares its pack_format"
+          },
+          {
+            "kind": "fileCount",
+            "ext": [
+              "json",
+              "mcfunction"
+            ],
+            "min": 3,
+            "dir": "data"
+          }
+        ],
+        "scripts": [
+          {
+            "name": "checkJsonValid",
+            "scope": "standard",
+            "inputs": {
+              "file": "pack.mcmeta"
+            }
+          }
+        ],
+        "onReject": "scaffold",
+        "maxAttempts": 3
+      },
+      "next": "docs"
+    },
+    {
+      "id": "docs",
+      "name": "Write the README",
+      "description": "install and test steps a twelve-year-old can follow",
+      "prompt": "Write the README that gets the mod into the game. Step 1: open with what the mod does, in one line a kid would repeat to a friend. Step 2: write the install steps — where the datapack folder goes for the target version, written concretely for the platform, one action per step, no step assuming knowledge the last step did not give. Step 3: write the test step — exactly what to do in-game to see the mod work, and exactly what should happen when it does. Step 4: add the version note — which game version this pack targets and the one-line warning that other versions may need a different format number. Write README.md and call write_task_note with the README path and the test step in one line.",
+      "suggestedRole": "copywriter",
+      "advanceWhen": {
+        "file": "README.md",
+        "minBytes": 1,
+        "sniff": "nonempty"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "README.md",
+            "bytes": 600
+          }
+        ],
+        "scripts": [
+          {
+            "name": "checkContains",
+            "scope": "standard",
+            "inputs": {
+              "file": "README.md",
+              "pattern": "(?:^|\\n)#{1,3}\\s+\\S",
+              "flags": "i"
+            }
+          }
+        ],
+        "onReject": "docs",
+        "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 pack.mcmeta, walk the tree under data/, and read README.md against every criterion from {{workPath}}/scope.md: pack.mcmeta is valid JSON carrying the pack_format locked for the target version, all content sits under the namespaced folders with the version's correct folder names, the working example is complete — trace the core idea file by file and confirm every reference resolves — and the README's install and test steps are concrete enough for a twelve-year-old to follow without help. Write PASS/FAIL per criterion; on any failure, name the missing or misplaced file and loop back to scaffold.\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: \"scaffold\" })` 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": "README.md"
+        }
+      ],
+      "next": "scaffold"
+    },
+    {
+      "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/mo/mod-scaffold/versions/1.0.2/test.json

@@ -0,0 +1,136 @@
+{
+  "schemaVersion": 1,
+  "title": "Scaffold a Mod smoke eval",
+  "objective": "Task-specific eval for the Scaffold a Mod craftbook: a craft-a-boat-get-a-diamond datapack for Minecraft 1.21 — pack.mcmeta with the format number from the house version notes, singular 1.21 folder names under a namespace, one working example, and a README a kid can follow.",
+  "tags": [
+    "corpus"
+  ],
+  "prompt": "my kid wants a datapack that gives you a diamond when you craft a boat — can you scafold it for 1.21?",
+  "setup": {
+    "projectName": "Mod Workshop — Datapack Scaffold Eval",
+    "about": "Self-contained eval project for mod-scaffold. The target is a Minecraft 1.21 datapack; the house version notes at tasks/eval/format-versions.md carry the pack_format table (1.21 uses 48) and the 1.21 singular folder-name rule. pack.mcmeta goes at the workspace root, the namespaced content under data/, and the install guide in README.md.",
+    "missionObjectives": "Use the Scaffold a Mod craftbook/template, lock the 1.21 structure rules from the version notes, build the datapack tree with one working example of the boat-diamond idea, and write README.md with install and test steps. No game launches or external tools — the scaffold and docs are the deliverable.",
+    "files": [
+      {
+        "path": "tasks/eval/format-versions.md",
+        "content": "# Datapack format numbers (house notes)\n\n| Game version | pack_format |\n| --- | --- |\n| 1.20 | 15 |\n| 1.20.6 | 41 |\n| 1.21 | 48 |\n| 1.21.5 | 71 |\n\nFolder names: since 1.21 the data folder names are singular - function,\nrecipe, advancement, loot_table, and tags/function. Before 1.21 they were\nplural - functions, recipes, advancements, loot_tables, tags/functions.\nA pack using the old plural names loads on 1.21+ but its content silently\nnever fires.\n"
+      }
+    ],
+    "worker": {
+      "name": "Milan",
+      "role": "Developer"
+    },
+    "craftbookParams": {
+      "workPath": "tasks/eval"
+    }
+  },
+  "mocks": [],
+  "success": {
+    "summary": "pack.mcmeta declares pack_format 48 per the version notes, the namespaced tree under data/ carries a working boat-diamond example in at least three content files, and README.md gives concrete install and test steps naming 1.21.",
+    "deliverables": [
+      {
+        "path": "pack.mcmeta",
+        "kind": "json",
+        "checks": [
+          {
+            "kind": "jsonPathEquals",
+            "file": "pack.mcmeta",
+            "path": "pack.pack_format",
+            "value": 48,
+            "label": "pack_format matches the 1.21 value from the version notes"
+          }
+        ]
+      },
+      {
+        "path": "README.md",
+        "kind": "markdown-doc",
+        "minBytes": 500,
+        "checks": [
+          {
+            "kind": "contains",
+            "file": "README.md",
+            "pattern": "(?:^|\\n)#{1,3}\\s+\\S",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "README.md",
+            "pattern": "install",
+            "flags": "i",
+            "label": "install steps are present"
+          },
+          {
+            "kind": "contains",
+            "file": "README.md",
+            "pattern": "1\\.21",
+            "label": "the target version is named"
+          },
+          {
+            "kind": "contains",
+            "file": "README.md",
+            "pattern": "boat",
+            "flags": "i",
+            "label": "the test step exercises the mod idea"
+          }
+        ]
+      }
+    ],
+    "checks": [
+      {
+        "kind": "fileCount",
+        "ext": [
+          "json",
+          "mcfunction"
+        ],
+        "min": 3,
+        "dir": "data"
+      },
+      {
+        "kind": "fileCount",
+        "ext": [
+          "mcfunction"
+        ],
+        "min": 1,
+        "dir": "data"
+      },
+      {
+        "kind": "judge",
+        "file": "README.md",
+        "rubric": "The install steps are concrete enough for a twelve-year-old (where the folder goes, one action per step) and the test step says exactly what to do in-game and what should happen. The version note warns that other versions may need a different format number.",
+        "sourceFiles": [
+          "tasks/eval/format-versions.md"
+        ],
+        "label": "kid-followable docs"
+      }
+    ]
+  },
+  "rubric": {
+    "artifact": {
+      "path": "README.md",
+      "kind": "markdown"
+    },
+    "axes": [
+      {
+        "name": "structure-correctness",
+        "description": "The tree uses the 1.21 singular folder names under a proper namespace; every file the example needs exists."
+      },
+      {
+        "name": "version-awareness",
+        "description": "pack_format and folder layout come from the version notes, not memory."
+      },
+      {
+        "name": "docs-clarity",
+        "description": "Install and test steps work for a kid with no prior modding."
+      },
+      {
+        "name": "idea-fit",
+        "description": "The working example actually implements craft-a-boat-get-a-diamond."
+      }
+    ]
+  },
+  "qualityFocus": [
+    "version-correct structure",
+    "complete working example",
+    "kid-followable docs"
+  ]
+}

package/data/craftbook-templates/mo/monitor-and-alert/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "monitor-and-alert",
   "role": "general",
+  "category": "code-ops",
   "name": "Watch a Page or API and Alert",
   "description": "Build a watcher that polls a web page or API endpoint on a schedule, detects a meaningful change or threshold breach, and fires an alert (and only alerts on real changes, not noise). Scopes the watched target, the exact change/threshold condition, and the dedup/cooldown policy FIRST, then builds the poll-diff-notify loop with persisted state, then tests it against simulated change and no-change inputs so it neither misses a real change nor spams on every poll. Condition-and-cooldown-before-build is the wisdom that separates a useful monitor from an alert-fatigue generator.",
   "tags": [