@bendyline/gilde 0.1.4 → 0.1.5

package/data/craftbook-templates/de/deep-security-review/versions/1.1.0/craftbook.json

@@ -0,0 +1,201 @@
+{
+  "id": "deep-security-review",
+  "name": "Deep Security Review",
+  "description": "Run a slow, thorough, WHOLE-CODEBASE security audit that looks for SYSTEMIC weaknesses — a vulnerability class repeated across many routes, a missing control at an architectural layer, inconsistent authorization, ad-hoc secret handling, a trust-boundary violation — not just isolated issues in one file. First reconnoiters the whole system using gezel's static security index (dependency inventory, attack surface, source/sink findings, taint reachability), then builds a threat model to find the highest-blast-radius areas, then audits those areas holistically confirming real source-to-sink paths and consistency of controls across every entry point, then clusters findings into root-cause systemic themes, then writes a prioritized report with a machine-readable findings file. Use this for a deep or systemic security review, a codebase security audit, a nightly security sweep, or finding security issues across a whole project — it is intentionally broader and deeper than a PR-time diff review (see pr-security-review for that).\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\nPhases:\n\n1. Reconnoiter the whole system (reviewer) — build a whole-system security map from the static index → gated on `notes/security/surface-map.md` (markdown-notes)\n2. Threat-model the system (reviewer) — assets, actors, STRIDE per boundary, highest blast radius → gated on `notes/security/threat-model.md` (markdown-notes)\n3. Audit for systemic weaknesses (reviewer) — confirm real source→sink paths and control consistency across all entry points → gated on `notes/security/findings.md` (markdown-notes)\n4. Cluster findings into systemic themes (reviewer) — group findings by root cause; rank by blast radius → gated on `notes/security/themes.md` (markdown-notes)\n5. Write the security report (reviewer) — systemic report + machine-readable findings, all citing real files → gated on `security-review/REPORT.md` (security-report)\n\nThe gates never advance with an unmet criterion, and loop back to the\nowning phase to fix named gaps.\n",
+  "entryStepId": "recon",
+  "triggers": [
+    "deep security review",
+    "audit the codebase for vulnerabilities",
+    "systemic security review",
+    "find security issues across the whole codebase",
+    "whole-codebase security audit",
+    "nightly security audit"
+  ],
+  "toolsets": [
+    {
+      "toolsetId": "builtin.security-intel",
+      "autoAllow": true,
+      "reason": "static security analysis over the index — scan, findings, attack surface, dependencies, taint reachability"
+    },
+    {
+      "toolsetId": "builtin.code-intel",
+      "autoAllow": true,
+      "reason": "navigate and read the code to confirm each lead"
+    }
+  ],
+  "steps": [
+    {
+      "id": "recon",
+      "name": "Reconnoiter the whole system",
+      "description": "build a whole-system security map from the static index",
+      "prompt": "You are starting a deep, whole-codebase security review — take your time and look across the ENTIRE system, not one file. Step 1: Call `security_scan` to build the dependency inventory and run any installed OSS scanners (semgrep / osv-scanner / gitleaks). Step 2: Call `map_repo`, `map_attack_surface`, `security_overview`, and `list_dependencies` to assemble a whole-system picture: languages and top areas; entry points; route/handler files; auth & middleware boundaries; secret touchpoints (config/env/credential files); files that read untrusted input (taint sources); external integrations and data stores; and the dependency inventory with any advisories. Step 3: Identify the trust boundaries — where untrusted data crosses into the system and where privileged/state-changing operations live. Step 4: Record the CANDIDATE SYSTEMIC THEMES that `security_overview` surfaced (categories recurring across many files) as leads to investigate. Write a whole-system surface map — assets, entry points, trust boundaries, the auth model, data stores, external dependencies, and the candidate themes — to `notes/security/surface-map.md`. No findings yet; this phase orients the review across the whole codebase.",
+      "suggestedRole": "reviewer",
+      "advanceWhen": {
+        "file": "notes/security/surface-map.md",
+        "minBytes": 1,
+        "sniff": "nonempty"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "notes/security/surface-map.md",
+            "bytes": 120
+          },
+          {
+            "kind": "sniff",
+            "file": "notes/security/surface-map.md",
+            "sniff": "nonempty"
+          }
+        ],
+        "onReject": "recon",
+        "maxAttempts": 3
+      },
+      "next": "threatmodel"
+    },
+    {
+      "id": "threatmodel",
+      "name": "Threat-model the system",
+      "description": "assets, actors, STRIDE per boundary, highest blast radius",
+      "prompt": "Using the surface map, build the system's threat model to decide WHERE systemic weaknesses would hurt most. Step 1: List the assets worth protecting (user data, secrets, money/state-changing operations, admin capability) and the actors/threats (unauthenticated user, authenticated user, insider, compromised dependency). Step 2: For each trust boundary, walk STRIDE (spoofing, tampering, repudiation, information-disclosure, denial-of-service, elevation-of-privilege) and note where a weakness would have the highest BLAST RADIUS across the system. Step 3: Prioritize — which boundaries or assets, if weak, would compromise many parts of the app at once? Those are where systemic issues hide and where the audit should spend its time. Write the threat model — assets, actors, trust zones, STRIDE-per-boundary, and the ranked high-blast-radius areas to focus on — to `notes/security/threat-model.md`.",
+      "suggestedRole": "reviewer",
+      "advanceWhen": {
+        "file": "notes/security/threat-model.md",
+        "minBytes": 1,
+        "sniff": "nonempty"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "notes/security/threat-model.md",
+            "bytes": 120
+          },
+          {
+            "kind": "sniff",
+            "file": "notes/security/threat-model.md",
+            "sniff": "nonempty"
+          }
+        ],
+        "onReject": "threatmodel",
+        "maxAttempts": 3
+      },
+      "next": "audit"
+    },
+    {
+      "id": "audit",
+      "name": "Audit for systemic weaknesses",
+      "description": "confirm real source→sink paths and control consistency across all entry points",
+      "prompt": "Investigate the high-blast-radius areas for CONCRETE, SYSTEMIC weaknesses — not one-off style nits. Step 1: Use `scan_findings` (filter by severity/category) to pull the static leads, then VERIFY each in the code with `read_symbol` / `read_file` — a regex lead is not a finding until you confirm the vulnerable path. Step 2: For untrusted inputs, use `trace_taint` on the relevant files to see which sinks are reachable, then confirm the actual source→sink path by reading it; flag any path that reaches a dangerous sink without validation, escaping, or parameterization. Step 3: Assess the auth model HOLISTICALLY — is every route behind an auth boundary? Is authorization applied consistently across ALL entry points, or is the same check missing or re-implemented differently in several places (a systemic broken-access / IDOR pattern)? Step 4: Check secrets posture (hardcoded or logged secrets, ad-hoc env reads), crypto usage (weak algorithms, predictable randomness), and dependency risk (advisory-bearing packages from `list_dependencies`). Step 5: For every CONFIRMED finding capture file:line, the vulnerability class, an exploit sketch, severity and likelihood, and a concrete remediation. Prefer findings that RECUR across the codebase — a class of bug appearing in many places is the systemic signal. Stage the running findings list to `notes/security/findings.md`; also note the threat classes you checked and found clean.",
+      "suggestedRole": "reviewer",
+      "advanceWhen": {
+        "file": "notes/security/findings.md",
+        "minBytes": 1,
+        "sniff": "nonempty"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "notes/security/findings.md",
+            "bytes": 120
+          },
+          {
+            "kind": "sniff",
+            "file": "notes/security/findings.md",
+            "sniff": "nonempty"
+          }
+        ],
+        "onReject": "audit",
+        "maxAttempts": 3
+      },
+      "next": "synthesize"
+    },
+    {
+      "id": "synthesize",
+      "name": "Cluster findings into systemic themes",
+      "description": "group findings by root cause; rank by blast radius",
+      "prompt": "Step back from the individual findings and cluster them into SYSTEMIC THEMES — the root-cause patterns that explain many findings at once (e.g. 'input validation is inconsistent across the API routes', 'secrets are loaded ad hoc in several modules with no central config', 'there is no shared authorization layer so each endpoint re-checks access differently'). Step 1: Group the findings by ROOT CAUSE, not by file. Step 2: For each theme, state the root cause (the architectural gap), the BLAST RADIUS (how much of the system it touches and how many findings it explains), and the systemic FIX (the single change that would prevent the whole class). Step 3: Rank the themes by blast radius × severity. Write the themes to `notes/security/themes.md`. A clean codebase with no material findings can say so plainly rather than inventing themes.",
+      "suggestedRole": "reviewer",
+      "advanceWhen": {
+        "file": "notes/security/themes.md",
+        "minBytes": 1,
+        "sniff": "nonempty"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "notes/security/themes.md",
+            "bytes": 120
+          },
+          {
+            "kind": "sniff",
+            "file": "notes/security/themes.md",
+            "sniff": "nonempty"
+          }
+        ],
+        "onReject": "synthesize",
+        "maxAttempts": 3
+      },
+      "next": "report"
+    },
+    {
+      "id": "report",
+      "name": "Write the security report",
+      "description": "systemic report + machine-readable findings, all citing real files",
+      "prompt": "Write the final deliverable as TWO files in the `security-review/` folder. Step 1: Write `security-review/findings.json` — a JSON array where each finding is an object with: `file` (a REAL workspace path), `line` (a number), `severity` (one of critical, high, medium, low, info), `category`, `title`, `remediation` (a concrete fix), and `theme` (the systemic theme it belongs to). Every `file` MUST be a real path in this workspace and every finding MUST have a line, a severity, and a concrete remediation — no fabricated paths. Step 2: Write `security-review/REPORT.md` with these sections, using those exact headings: `## Verdict` — a one-line top verdict (e.g. Block / Remediate-then-ship / Acceptable) with the count of findings by severity; do NOT say 'safe to merge' while any critical/high finding is open. `## Systemic Themes` — each theme from synthesize with its root cause and blast radius (this is the heart of a deep review). `## Findings` — each finding as `### [SEVERITY] class — file:line` with the exploit sketch, impact, and remediation, ordered by severity then blast radius. `## Verified Safe` — the threat classes you checked and found clean, so coverage is auditable. `## Not Statically Verifiable` — anything needing a pentest or runtime check. On a loop-back, fix ONLY the gaps the evaluator named without dropping findings that already passed.",
+      "suggestedRole": "reviewer",
+      "advanceWhen": {
+        "file": "security-review/REPORT.md",
+        "minBytes": 1,
+        "sniff": "nonempty"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "security-review/REPORT.md",
+            "bytes": 1500
+          }
+        ],
+        "scripts": [
+          {
+            "name": "checkSecurityReport",
+            "scope": "standard",
+            "inputs": {
+              "file": "security-review/REPORT.md",
+              "findings": "security-review/findings.json"
+            }
+          }
+        ],
+        "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 `security-review/REPORT.md` and `security-review/findings.json` and grade the review against its acceptance criteria. Check EACH and write PASS/FAIL with a one-line reason: (1) every finding is pinned to a REAL file:line (no fabricated paths) with a severity and a concrete remediation; (2) the Systemic Themes section names the root-cause patterns with their blast radius — a deep review is about systemic issues, not a list of isolated nits; (3) untrusted-input findings trace a real source→sink path rather than restating a raw scanner hit; (4) the auth model was assessed HOLISTICALLY (consistency across all entry points), not file-by-file; (5) a Verified-safe section makes the review's coverage auditable; (6) the verdict matches the open severity (no 'safe' with an open critical/high); (7) no vague filler like 'consider validating inputs' — every finding is concrete. If any criterion fails, name the exact gap and loop back.\n\nThen route — this is the whole point of the loop:\n\n- **Every criterion PASSES →** call `advance_task_step({ ref, stepId: \"evaluate\", next: \"finish\" })`.\n- **Any criterion FAILS →** write the specific gaps to notes, then call `advance_task_step({ ref, stepId: \"evaluate\", next: \"report\" })` to loop back. The builder fixes exactly those gaps.\n\nNever route to `finish` while any criterion is unmet. The build phase's completion gate already blocked a grossly-incomplete deliverable; your job is the judgment an automated check cannot make (does it actually work, read well, look right). After ~3 unproductive loops, stop and report DONE_WITH_CONCERNS so the user can step in.",
+      "suggestedRole": "reviewer",
+      "next": "report"
+    },
+    {
+      "id": "finish",
+      "name": "Finish",
+      "description": "All acceptance criteria met. Stamp a short summary and report DONE.",
+      "prompt": "The security review passed every acceptance criterion. Write a one-paragraph DONE summary to task notes via `write_task_note`: the top-line verdict, the count of findings by severity, the systemic themes, and the deliverable paths (`security-review/REPORT.md` + `security-review/findings.json`). Then report DONE.",
+      "suggestedRole": "developer",
+      "terminal": true
+    }
+  ],
+  "version": "1.1.0",
+  "releasedAt": "2026-07-28T00:00:00Z"
+}

package/data/craftbook-templates/de/deep-security-review/versions/1.1.0/test.json

@@ -0,0 +1,157 @@
+{
+  "schemaVersion": 1,
+  "title": "Deep Security Review systemic eval",
+  "objective": "Measure whether the review confirms seeded source-to-sink vulnerabilities, identifies systemic root causes, and emits valid machine-readable findings.",
+  "tags": [
+    "corpus"
+  ],
+  "prompt": "Use the Deep Security Review craftbook for a whole-codebase security sweep. The fixture is offline and self-contained. Write security-review/REPORT.md and security-review/findings.json; do not modify source.",
+  "setup": {
+    "projectName": "Security Maintenance Eval",
+    "about": "A tiny admin service with deliberate command injection, SQL injection, and inconsistent authorization.",
+    "missionObjectives": "Confirm real source-to-sink paths, cluster root causes, and leave report plus structured findings without inventing files or advisories.",
+    "files": [
+      {
+        "path": "src/admin.ts",
+        "content": "import { exec } from 'node:child_process';\nexport function register(app, db) {\n  app.get('/admin/export', (req, res) => {\n    exec('zip -r /tmp/' + req.query.name + '.zip data', (_e, out) => res.send(out));\n  });\n  app.get('/admin/users', async (req, res) => {\n    const rows = await db.query(`SELECT * FROM users WHERE team = '${req.query.team}'`);\n    res.json(rows);\n  });\n}\n"
+      },
+      {
+        "path": "src/profile.ts",
+        "content": "export function registerProfile(app, db, requireUser) {\n  app.get('/profile', requireUser, async (req, res) => {\n    const row = await db.query('SELECT * FROM users WHERE id = ?', [req.user.id]);\n    res.json(row);\n  });\n}\n"
+      },
+      {
+        "path": "docs/security.md",
+        "content": "# Security model\n\nAll /admin routes must require the requireAdmin middleware before business logic runs. SQL must use placeholders. Shell commands must not include request data.\n"
+      }
+    ],
+    "worker": {
+      "name": "Rae",
+      "role": "Reviewer"
+    }
+  },
+  "mocks": [],
+  "success": {
+    "summary": "The report and findings JSON confirm both injection paths and the missing admin boundary with systemic remediation.",
+    "deliverables": [
+      {
+        "path": "security-review/REPORT.md",
+        "kind": "security-report",
+        "minBytes": 1500,
+        "checks": [
+          {
+            "kind": "contains",
+            "file": "security-review/REPORT.md",
+            "pattern": "src/admin\\.ts:[0-9]+",
+            "flags": "i",
+            "label": "real file and line"
+          },
+          {
+            "kind": "contains",
+            "file": "security-review/REPORT.md",
+            "pattern": "command injection|exec",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "security-review/REPORT.md",
+            "pattern": "SQL injection|parameter",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "security-review/REPORT.md",
+            "pattern": "authorization|requireAdmin|auth",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "security-review/REPORT.md",
+            "pattern": "Systemic Themes|root cause|blast radius",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "security-review/REPORT.md",
+            "pattern": "Verified Safe|Not Statically Verifiable",
+            "flags": "i"
+          }
+        ]
+      },
+      {
+        "path": "security-review/findings.json",
+        "kind": "json",
+        "minBytes": 300,
+        "checks": [
+          {
+            "kind": "sniff",
+            "file": "security-review/findings.json",
+            "sniff": "json-valid"
+          },
+          {
+            "kind": "recordSchema",
+            "file": "security-review/findings.json",
+            "format": "json",
+            "minRows": 3,
+            "fields": [
+              {
+                "name": "file",
+                "type": "nonempty",
+                "required": true
+              },
+              {
+                "name": "line",
+                "type": "integer",
+                "required": true
+              },
+              {
+                "name": "severity",
+                "type": "^(critical|high|medium|low|info)$",
+                "required": true
+              },
+              {
+                "name": "category",
+                "type": "nonempty",
+                "required": true
+              },
+              {
+                "name": "remediation",
+                "type": "nonempty",
+                "required": true
+              },
+              {
+                "name": "theme",
+                "type": "nonempty",
+                "required": true
+              }
+            ]
+          }
+        ]
+      }
+    ]
+  },
+  "rubric": {
+    "artifact": {
+      "path": "security-review/REPORT.md",
+      "kind": "markdown"
+    },
+    "axes": [
+      {
+        "name": "verification",
+        "description": "Raw leads are confirmed as real source-to-sink or authorization paths."
+      },
+      {
+        "name": "systemic analysis",
+        "description": "Findings are grouped by root cause and blast radius."
+      },
+      {
+        "name": "remediation",
+        "description": "The report and JSON contain concrete, severity-consistent fixes."
+      }
+    ]
+  },
+  "qualityFocus": [
+    "confirmed vulnerabilities",
+    "systemic themes",
+    "machine-readable findings"
+  ]
+}

package/data/craftbook-templates/do/dockerize-app/versions/1.0.0/test.json

@@ -55,11 +55,6 @@
             "file": "src/solution.mjs",
             "pattern": "18|6|14\\.2|8\\.9|Boreal",
             "flags": "i"
-          },
-          {
-            "kind": "nodeScriptPasses",
-            "script": "src/solution.mjs",
-            "timeoutMs": 10000
           }
         ]
       }

package/data/craftbook-templates/fr/freeze-scope/manifest.json

@@ -13,6 +13,5 @@
   },
   "logo": "logo.webp",
   "license": "MIT",
-  "yankedVersions": [],
-  "version": "1.0.1"
+  "yankedVersions": []
 }

package/data/craftbook-templates/fr/freeze-scope/versions/{1.0.1 → 1.1.0}/craftbook.json

@@ -18,7 +18,7 @@
   "hooks": [
     {
       "phase": "PreToolUse",
-      "matcher": "^(writeFile|appendToFile|replaceInFile|replaceLines|applyPatch|insertAtMarker|rename|rm|mkdir)$",
+      "matcher": "^(write_file|append_to_file|replace_in_file|replace_lines|apply_patch|insert_at_marker|rename|rm|mkdir)$",
       "script": {
         "name": "check-freeze",
         "scope": "craftbook"
@@ -31,30 +31,18 @@
       "id": "set-boundary",
       "name": "Agree the frozen directory",
       "prompt": "Confirm with the user which single workspace directory edits are allowed in — use `ask_user_question` if the kickoff didn’t name one. Then record it by writing `.gezel/freeze.json` with exactly:\n\n```json\n{ \"dir\": \"<workspace-relative-directory>\" }\n```\n\nUse a relative path with no leading `./` and no trailing slash (e.g. `src/billing`). Tell the user the freeze is on and advance.",
-      "next": "frozen",
-      "suggestedRole": "developer",
-      "gate": {
-        "maxAttempts": 2,
-        "checks": [
-          {
-            "kind": "minBytes",
-            "file": ".gezel/freeze.json",
-            "bytes": 10
-          }
-        ]
-      }
+      "next": "frozen"
     },
     {
       "id": "frozen",
       "name": "Freeze active",
       "prompt": "The write boundary is active: any write outside the frozen directory is denied automatically — you will see the denial as a tool error naming the boundary. Do the scoped work normally inside the directory. If the work genuinely needs to touch something outside, do NOT fight the boundary: tell the user what needs changing and why, and let them either widen `.gezel/freeze.json` deliberately or end this task to lift the freeze.",
-      "terminal": true,
-      "suggestedRole": "developer"
+      "terminal": true
     }
   ],
   "scripts": {
     "check-freeze": "import { defineScript, gezel } from '@bendyline/gezel-sdk';\n\nexport const meta = defineScript({\n  name: 'check-freeze',\n  description: 'Block workspace writes outside the frozen directory (freeze scope).',\n  inputs: {},\n  outputs: {\n    decision: { type: 'string', description: 'allow | deny' },\n    message: { type: 'string', description: 'Reason shown on deny.' },\n  },\n  requires: ['workspace.read'],\n});\n\nconst STATE_FILE = '.gezel/freeze.json';\n\nfunction normalize(p: string): string {\n  return p.replace(/\\\\/g, '/').replace(/\\/{2,}/g, '/').replace(/^\\.\\//, '').replace(/\\/$/, '');\n}\n\nasync function main(): Promise<void> {\n  const input = gezel.input as { args?: Record<string, unknown> };\n  const args = input.args ?? {};\n\n  let frozenDir = '';\n  try {\n    const raw = await gezel.fs.read(STATE_FILE);\n    frozenDir = normalize(String(JSON.parse(raw).dir ?? ''));\n  } catch {\n    // Not configured yet (the setup step writes it) — allow everything.\n    gezel.output({ decision: 'allow', message: '' });\n    return;\n  }\n  if (!frozenDir) {\n    gezel.output({ decision: 'allow', message: '' });\n    return;\n  }\n\n  // Every path-like argument the write-tool family carries.\n  const candidates = ['path', 'from', 'to', 'file']\n    .map((key) => (args as Record<string, unknown>)[key])\n    .filter((value): value is string => typeof value === 'string' && value.length > 0)\n    .map(normalize);\n  if (candidates.length === 0) {\n    gezel.output({ decision: 'allow', message: '' });\n    return;\n  }\n\n  for (const candidate of candidates) {\n    const inside = candidate === frozenDir || candidate.startsWith(frozenDir + '/');\n    const isStateFile = candidate === normalize(STATE_FILE);\n    if (candidate.includes('..')) {\n      gezel.output({ decision: 'deny', message: '[freeze] Path escapes are blocked while freeze scope is active.' });\n      return;\n    }\n    if (!inside && !isStateFile) {\n      gezel.output({\n        decision: 'deny',\n        message:\n          '[freeze] Writes are frozen to \"' + frozenDir + '/\" — \"' + candidate + '\" is outside it. Finish the scoped work first, or end the freeze-scope task to lift the boundary.',\n      });\n      return;\n    }\n  }\n  gezel.output({ decision: 'allow', message: '' });\n}\n\nawait main();\n"
   },
-  "version": "1.0.1",
-  "releasedAt": "2026-07-25T22:45:00.000Z"
+  "version": "1.1.0",
+  "releasedAt": "2026-07-28T00:00:00Z"
 }

package/data/craftbook-templates/gr/graphql-api/versions/1.0.1/test.json

@@ -55,11 +55,6 @@
             "file": "src/solution.mjs",
             "pattern": "18|6|14\\.2|8\\.9|Boreal",
             "flags": "i"
-          },
-          {
-            "kind": "nodeScriptPasses",
-            "script": "src/solution.mjs",
-            "timeoutMs": 10000
           }
         ]
       }

package/data/craftbook-templates/gr/grpc-service/versions/1.0.0/test.json

@@ -55,11 +55,6 @@
             "file": "src/solution.mjs",
             "pattern": "18|6|14\\.2|8\\.9|Boreal",
             "flags": "i"
-          },
-          {
-            "kind": "nodeScriptPasses",
-            "script": "src/solution.mjs",
-            "timeoutMs": 10000
           }
         ]
       }

package/data/craftbook-templates/ho/hotfix-flow/versions/1.0.0/test.json

@@ -55,11 +55,6 @@
             "file": "src/solution.mjs",
             "pattern": "18|6|14\\.2|8\\.9|Boreal",
             "flags": "i"
-          },
-          {
-            "kind": "nodeScriptPasses",
-            "script": "src/solution.mjs",
-            "timeoutMs": 10000
           }
         ]
       }

package/data/craftbook-templates/in/investigate/versions/1.1.0/craftbook.json

@@ -0,0 +1,81 @@
+{
+  "id": "investigate",
+  "name": "Investigate",
+  "description": "Systematic root-cause debugging procedure. Six steps:\n\n1. **Gather symptoms** — observable signals, no theorizing yet\n2. **Search prior** — has this project seen this before? (memory)\n3. **Reproduce** — deterministic repro before any tracing\n4. **Trace to root cause** — keep asking 'and why is THAT?'\n5. **Propose fix** — state it; don't apply unless asked\n6. **Save learning** — stamp (symptom → root cause → fix) into memory\n\nPorted from gstack's `/investigate`. The principle is the Iron Law:\n**no fixes without investigation**. Jumping to a fix without root cause\neither ships a coincidence (the bug comes back), papers over the real\ncause (introduces tech debt), or fixes a symptom you didn't actually\nunderstand.\n\nWhere gstack used `~/.gstack/projects/{slug}/learnings.jsonl`, this\ncraftbook uses the per-gezel/project memory subsystem. The\n`search-prior.ts` script wraps `search_memory` with the symptom-shape\nquery; `save-learning.ts` wraps `save_memory` with structured metadata\nso future `search-prior` queries find the match.\n\nThe Iron Law is not literal: sometimes a one-line typo fix is the right\nmove. The principle is \"if you can't say *why* this fix works, you're\nguessing.\" The craftbook's structure makes that guessing visible.\n",
+  "entryStepId": "gather-symptoms",
+  "triggers": [
+    "investigate this",
+    "debug this",
+    "why is this broken",
+    "find the bug",
+    "root cause"
+  ],
+  "steps": [
+    {
+      "id": "gather-symptoms",
+      "name": "Gather symptoms",
+      "description": "Pull together every observable signal: error messages, stack traces, logs, repro steps, when it started.",
+      "prompt": "**For this task you are an investigator, not an author.** The Iron Law: no fixes without investigation. Resist the urge to `write_file` a fix — even if your default persona is a developer, this craftbook is about *understanding what broke* and the fix comes later (separate task).\n\n**Your first action this turn:** call `ask_user_question` with the four bullets below if any signal is missing from the chat. If the user already supplied the symptom in their message, skip to `write_task_note`.\n\nElicit (if missing):\n- What's the observable failure? (exact error message, screenshot, stack trace, log line)\n- When did it start? (recent commit? deploy? environment change?)\n- Is it reproducible? (every time? intermittent? specific input?)\n- What's the smallest input that triggers it?\n\nThen `write_task_note({ ref, content: <3-5 line symptom summary> })`. Do NOT theorize yet. Do NOT propose causes — that's the next step. Do NOT call `read_task_notes` to find the procedure; it's right here.",
+      "suggestedRole": "developer",
+      "next": "search-prior"
+    },
+    {
+      "id": "search-prior",
+      "name": "Search prior",
+      "description": "Have we seen this before? Search memory for prior investigations in this project.",
+      "prompt": "Run the `search-prior` script. It searches project memory for prior investigations matching the symptom signature. If we've seen this before, the model returns the prior learning + the fix that landed.\n\nIf there's a match: state what the prior investigation found, and ask the user if this looks like the same bug (with `ask_user_question`). If yes, jump straight to the fix. If no, proceed to fresh investigation.\n\nIf there's no match: note 'no prior matches' to task notes and advance.",
+      "suggestedRole": "developer",
+      "onExit": {
+        "name": "search-prior",
+        "autoAdvanceWhen": {
+          "op": "ok"
+        }
+      },
+      "next": "reproduce"
+    },
+    {
+      "id": "reproduce",
+      "name": "Reproduce",
+      "description": "Get a deterministic repro. Often the longest step. Cannot fix what can't be reproduced.",
+      "prompt": "Get the bug to fire on demand. Strategies:\n\n1. **Read the failing path** — find the function/route from the stack trace (use `read_file` / `search_files`).\n2. **Walk inputs backward** — what user action triggered this? What's the request shape?\n3. **Try the minimal trigger** — strip the user's repro down. Half the bugs disappear when you isolate.\n4. **Run a small script if needed** — `run_nodejs_script` against a synthetic input.\n5. **If it won't reproduce**: state that explicitly. Either get more info from the user (`ask_user_question`) or escalate.\n\nWhen you have a repro, write the minimal trigger to task notes. Do not move on without one.",
+      "suggestedRole": "developer",
+      "next": "trace"
+    },
+    {
+      "id": "trace",
+      "name": "Trace to root cause",
+      "description": "Follow the data from the failure point back to the smallest 'this is the thing that's wrong.'",
+      "prompt": "Trace backward from the failure. Read the code path. The Iron Law: **the cause is not 'the function returned the wrong thing,' it's WHY the function returned the wrong thing.** Keep asking 'and why is THAT?' until you hit one of:\n\n- A coding bug (assignment swapped, condition inverted, type mismatch)\n- A bad invariant (assumed X but the data has Y)\n- A wrong assumption about a dependency (the API returns null in this case)\n- An environment / config issue (the staging DB doesn't have this column)\n\nDocument the chain in task notes. Bullet form is fine. End with: 'Root cause: <one sentence>.'",
+      "suggestedRole": "developer",
+      "next": "propose-fix"
+    },
+    {
+      "id": "propose-fix",
+      "name": "Propose fix",
+      "description": "State the fix. Don't apply it yet — let the user (or a separate craftbook) decide.",
+      "prompt": "Now the easy part. State the fix in plain language:\n\n- What file/function changes?\n- What's the new behavior?\n- What did NOT change (so the user knows you didn't gold-plate)?\n- What test would catch this regressing?\n\nDo NOT apply the fix unless the user explicitly asks. Investigation lives separate from edit-the-code so the diff stays minimal and reviewable. Advance.",
+      "suggestedRole": "developer",
+      "next": "save-learning"
+    },
+    {
+      "id": "save-learning",
+      "name": "Save learning",
+      "description": "Stamp the (symptom → root cause → fix) triple into project memory so future investigations find it.",
+      "prompt": "Run the `save-learning` script with the symptom, root cause, and proposed fix. It saves them to project memory with appropriate tags so `search-prior` finds them next time.\n\nThen report DONE with a one-line summary: 'Investigated <symptom>; root cause: <cause>; fix proposed: <fix>.'",
+      "suggestedRole": "developer",
+      "onExit": {
+        "name": "save-learning",
+        "autoAdvanceWhen": {
+          "op": "ok"
+        }
+      },
+      "terminal": true
+    }
+  ],
+  "scripts": {
+    "search-prior": "import { defineScript, gezel } from '@bendyline/gezel-sdk';\n\nexport const meta = defineScript({\n  name: 'search-prior',\n  description:\n    'Search project memory for prior investigations matching a symptom signature. Stamps {matches: number, hits: [{text, score}]}.',\n  inputs: {\n    symptom: {\n      type: 'string',\n      description: 'Short symptom description (1-3 sentences). Used as the search query.',\n      required: true,\n    },\n  },\n  outputs: {\n    matches: { type: 'number', description: 'Number of memory hits returned.' },\n    hits: {\n      type: 'array',\n      description: 'Top matches, each with text + score.',\n      itemType: 'object',\n    },\n  },\n  requires: ['memory.read'],\n});\n\ninterface MemoryHit {\n  text: string;\n  score: number;\n}\n\nasync function main(): Promise<void> {\n  const input = gezel.input as { symptom: string };\n  const query = `investigation: ${input.symptom}`;\n  const results = (await gezel.memory.search(query)) as MemoryHit[];\n  const filtered = (results ?? []).filter(\n    (r): r is MemoryHit => Boolean(r) && typeof r.text === 'string' && typeof r.score === 'number',\n  );\n  gezel.log(`Memory search for \"${query}\" returned ${filtered.length} hit(s)`);\n  gezel.output({ matches: filtered.length, hits: filtered.slice(0, 5) });\n}\n\nawait main();\n",
+    "save-learning": "import { defineScript, gezel } from '@bendyline/gezel-sdk';\n\nexport const meta = defineScript({\n  name: 'save-learning',\n  description:\n    'Stamp a (symptom → root cause → fix) investigation triple into project memory so future `search-prior` queries find it.',\n  inputs: {\n    symptom: { type: 'string', description: 'Observable failure.', required: true },\n    rootCause: { type: 'string', description: 'Root cause in one sentence.', required: true },\n    fix: { type: 'string', description: 'Proposed fix.', required: true },\n    files: {\n      type: 'string',\n      description: 'Comma-separated list of files touched (or expected to be touched).',\n    },\n  },\n  outputs: {\n    ok: { type: 'boolean', description: 'True on successful save.' },\n  },\n  requires: ['memory.write'],\n});\n\nasync function main(): Promise<void> {\n  const input = gezel.input as {\n    symptom: string;\n    rootCause: string;\n    fix: string;\n    files?: string;\n  };\n  const text = [\n    'investigation:',\n    `symptom: ${input.symptom}`,\n    `root cause: ${input.rootCause}`,\n    `fix: ${input.fix}`,\n    ...(input.files ? [`files: ${input.files}`] : []),\n  ].join('\\n');\n  await gezel.memory.save(text, {\n    kind: 'investigation',\n    ...(input.files ? { files: input.files } : {}),\n  });\n  gezel.log('Saved investigation to memory.');\n  gezel.output({ ok: true });\n}\n\nawait main();\n"
+  },
+  "version": "1.1.0",
+  "releasedAt": "2026-07-28T00:00:00Z"
+}