@bendyline/gilde 0.1.26 → 0.1.28

package/data/craftbook-templates/db/db-index-tuning/versions/1.0.1/test.json

@@ -0,0 +1,104 @@
+{
+  "schemaVersion": 1,
+  "title": "Diagnose + Add Database Indexes smoke eval",
+  "objective": "Self-contained smoke eval for the Diagnose + Add Database Indexes craftbook using the data generic harness.",
+  "tags": [
+    "data"
+  ],
+  "prompt": "I dropped our numbers in source/records.csv. Can you look at the data, analyze it, and put togehter some results in analysis.md?",
+  "setup": {
+    "projectName": "Diagnose + Add Database Indexes Eval",
+    "about": "Self-contained eval project for db-index-tuning. Seeded inputs are under workspace/source or workspace/fixtures; final deliverable is workspace/analysis.md.",
+    "missionObjectives": "Use the Diagnose + Add Database Indexes craftbook/template, read the seeded local fixtures, and write analysis.md without network calls, real credentials, or live services.",
+    "files": [
+      {
+        "path": "source/brief.md",
+        "content": "# Diagnose + Add Database Indexes 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: db-index-tuning - Diagnose + Add Database Indexes.\n"
+      },
+      {
+        "path": "source/records.csv",
+        "content": "customer,region,orders,revenue_usd,churn_risk\nAster,North,12,1440,low\nBoreal,South,8,720,medium\nCedar,West,15,2100,high\nDune,North,5,500,low\n"
+      }
+    ],
+    "worker": {
+      "name": "Jules",
+      "role": "Data Analyst"
+    }
+  },
+  "mocks": [],
+  "success": {
+    "summary": "analysis.md is a seeded-data analysis with deterministic computed facts.",
+    "deliverables": [
+      {
+        "path": "analysis.md",
+        "kind": "markdown-report",
+        "minBytes": 900,
+        "checks": [
+          {
+            "kind": "contains",
+            "file": "analysis.md",
+            "pattern": "(?:^|\\n)#{1,3}\\s+\\S",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "analysis.md",
+            "pattern": "40\\b",
+            "flags": "i",
+            "label": "include total orders of 40"
+          },
+          {
+            "kind": "contains",
+            "file": "analysis.md",
+            "pattern": "\\$?4,?760\\b",
+            "flags": "i",
+            "label": "include total revenue of 4760"
+          },
+          {
+            "kind": "contains",
+            "file": "analysis.md",
+            "pattern": "Cedar",
+            "flags": "i",
+            "label": "identify Cedar as top revenue and high risk"
+          },
+          {
+            "kind": "contains",
+            "file": "analysis.md",
+            "pattern": "high",
+            "flags": "i",
+            "label": "include churn-risk finding"
+          }
+        ]
+      }
+    ]
+  },
+  "rubric": {
+    "artifact": {
+      "path": "analysis.md",
+      "kind": "markdown"
+    },
+    "axes": [
+      {
+        "name": "accuracy",
+        "description": "Computed figures are correct against the seeded records."
+      },
+      {
+        "name": "grounding",
+        "description": "Every claim traces to the seeded data — nothing invented."
+      },
+      {
+        "name": "structure",
+        "description": "Tables and sections make the analysis checkable at a glance."
+      },
+      {
+        "name": "actionability",
+        "description": "Recommendations follow from the findings and are concretely doable."
+      }
+    ]
+  },
+  "qualityFocus": [
+    "seeded data reading",
+    "computed facts",
+    "recommendation grounding"
+  ]
+}

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

@@ -0,0 +1,211 @@
+{
+  "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\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. Reconnoiter the whole system (reviewer) — build a whole-system security map from the static index → gated on artifact `notes/security/surface-map.md` (markdown-notes)\n2. Threat-model the system (reviewer) — assets, actors, STRIDE per boundary, highest blast radius → gated on artifact `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 artifact `notes/security/findings.md` (markdown-notes)\n4. Cluster findings into systemic themes (reviewer) — group findings by root cause; rank by blast radius → gated on artifact `notes/security/themes.md` (markdown-notes)\n5. Write the security report (reviewer) — systemic report + machine-readable findings, all citing real files → gated on artifact `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.\n\nThe deliverable `notes/security/surface-map.md` lands in the project's artifacts drawer — write it with `write_artifact` and read it back with `read_artifact`; the shipped workspace stays untouched.",
+      "suggestedRole": "reviewer",
+      "advanceWhen": {
+        "file": "notes/security/surface-map.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "notes/security/surface-map.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "notes/security/surface-map.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "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`.\n\nThe deliverable `notes/security/threat-model.md` lands in the project's artifacts drawer — write it with `write_artifact` and read it back with `read_artifact`; the shipped workspace stays untouched.",
+      "suggestedRole": "reviewer",
+      "advanceWhen": {
+        "file": "notes/security/threat-model.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "notes/security/threat-model.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "notes/security/threat-model.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "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.\n\nThe deliverable `notes/security/findings.md` lands in the project's artifacts drawer — write it with `write_artifact` and read it back with `read_artifact`; the shipped workspace stays untouched.",
+      "suggestedRole": "reviewer",
+      "advanceWhen": {
+        "file": "notes/security/findings.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "notes/security/findings.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "notes/security/findings.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "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.\n\nThe deliverable `notes/security/themes.md` lands in the project's artifacts drawer — write it with `write_artifact` and read it back with `read_artifact`; the shipped workspace stays untouched.",
+      "suggestedRole": "reviewer",
+      "advanceWhen": {
+        "file": "notes/security/themes.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "notes/security/themes.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "notes/security/themes.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "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.\n\nThe deliverable `security-review/REPORT.md` lands in the project's artifacts drawer — write it with `write_artifact` and read it back with `read_artifact`; the shipped workspace stays untouched.",
+      "suggestedRole": "reviewer",
+      "advanceWhen": {
+        "file": "security-review/REPORT.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "security-review/REPORT.md",
+            "bytes": 1500,
+            "artifact": true
+          }
+        ],
+        "onReject": "report",
+        "maxAttempts": 4
+      },
+      "next": "evaluate"
+    },
+    {
+      "id": "evaluate",
+      "name": "Evaluate",
+      "description": "Grade the deliverable against every acceptance criterion. All pass → finish; any fail → loop back and fix the gap.",
+      "prompt": "Open `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\nThe deliverable lives in the project's artifacts drawer — open `security-review/REPORT.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: \"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",
+      "consumes": [
+        {
+          "file": "security-review/REPORT.md",
+          "artifact": true
+        }
+      ],
+      "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.1",
+  "releasedAt": "2026-08-14T00:00:00Z"
+}

package/data/craftbook-templates/de/deep-security-review/versions/1.1.1/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/de/dependency-audit/versions/1.1.1/craftbook.json

@@ -0,0 +1,141 @@
+{
+  "id": "dependency-audit",
+  "name": "Dependency Audit",
+  "description": "Audit a project's dependencies for security, staleness, license, and maintenance risk, then produce a prioritized remediation report. First scans the manifest and lockfile to inventory every dependency with its installed vs latest version, known CVEs, license, and maintenance signals, then assesses each into a risk tier weighing severity, exploitability, breaking-change cost, and removability, then writes a report with a concrete upgrade/replace/remove action and order for each risky dependency. Use this for a dependency audit, supply-chain review, checking for vulnerable or outdated packages, license compliance, npm/pip audit triage, or reducing dependency risk — it turns a raw audit dump into a prioritized, justified action plan rather than a wall of warnings.\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. Scan the dependency tree (developer) — inventory deps with versions, CVEs, licenses → gated on artifact `notes/scan.md` (markdown-notes)\n2. Assess risk (reviewer) — tier each dep by risk and remediation cost → gated on artifact `notes/assess.md` (markdown-notes)\n3. Write the audit report (reviewer) — prioritized upgrade/replace/remove plan → gated on artifact `dependency-audit.md` (markdown-report)\n\nThe gates never advance with an unmet criterion, and loop back to the\nowning phase to fix named gaps.\n\nEvidence discipline:\n\n- Treat supplied manifests, lockfiles, audit JSON, and dependency notes as the source of truth. Do not invent CVEs, licenses, package age, or network-audit results that are not in the evidence.\n- If evidence says no patched version exists, do not recommend a patch upgrade; recommend replacement, containment, or a human decision.\n- If evidence names a copyleft or incompatible license, the License flags section must name the package and license. Do not write that no license flags were found.\n- Dependencies with no seeded CVE, license issue, or maintenance issue should be explicitly deferred, not inflated into security or replacement work.\n- Recommended order is risk-first: critical no-patch security items come before unused cleanup and low-effort maintenance upgrades, even when the cleanup is easier.\n- Maintenance-only upgrades can still be recommended, but label them maintenance-only; do not describe them as security posture work unless the evidence names a vulnerability.\n- Copy exact license identifiers and exact target versions from the evidence, such as `GPL-3.0-only` or `4.18.3`; do not replace them with vague family labels or \"monitor later\" language.\n- Copy named replacement alternatives from the evidence, such as `chart.js 4.x`; do not replace them with vague \"find an alternative\" language.\n- If a dependency has no seeded CVE, avoid words like security, advisory, vulnerability, patch, or posture in that dependency's action unless the evidence explicitly supports them.\n- Do not infer missing licenses. If the evidence does not state a license for a dependency, say the license was not provided rather than guessing MIT or writing \"assumed.\"\n",
+  "entryStepId": "scan",
+  "triggers": [
+    "dependency audit",
+    "are my dependencies safe",
+    "check for outdated packages",
+    "supply chain review",
+    "npm audit triage",
+    "license compliance check"
+  ],
+  "steps": [
+    {
+      "id": "scan",
+      "name": "Scan the dependency tree",
+      "description": "inventory deps with versions, CVEs, licenses",
+      "prompt": "Step 1: Read the manifest and lockfile (package.json/lock, requirements/poetry, go.mod, Cargo.toml, etc.) to inventory direct and notable transitive dependencies. Step 2: For each, gather: installed version vs latest, the semver gap (patch/minor/major behind), known vulnerabilities (run the ecosystem audit tool if available — `npm audit`, `pip-audit`, `cargo audit` — and capture CVE id + severity), license, and maintenance signals (last release date, archived/deprecated, single-maintainer). If the task already provides audit output or dependency notes, treat those files as authoritative evidence and do not replace them with fresh network assumptions. Step 3: Flag duplicates/multiple versions of the same package and obviously unused or trivially-replaceable dependencies. Step 4: Write the acceptance-criteria checklist for the audit, e.g. 'every direct dependency is inventoried', 'all CVEs at high+ are captured with an id', 'each license is recorded and flagged if copyleft/incompatible', 'staleness is measured by both semver gap and release recency'. Step 5: Save the inventory table to `write_task_note` AND `notes/scan.md`. No prioritization yet — this phase is the raw inventory.\n\nThe deliverable `notes/scan.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": "notes/scan.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "notes/scan.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "notes/scan.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "scan",
+        "maxAttempts": 3
+      },
+      "next": "assess"
+    },
+    {
+      "id": "assess",
+      "name": "Assess risk",
+      "description": "tier each dep by risk and remediation cost",
+      "prompt": "Step 1: For each dependency in the inventory, assign a risk tier (Critical / High / Medium / Low) weighing: CVE severity AND whether the vulnerable code path is actually used, how far behind it is, whether the upgrade is a breaking major (and the migration cost), license incompatibility, and abandonment/maintenance risk. Step 2: Decide the remediation per dep: patch-upgrade (safe), minor/major upgrade (note breaking changes to handle), replace (name the alternative), remove (if unused), or defer (if no seeded issue is present). If the evidence says no patched version exists, do not recommend an update-to-patch; recommend replacement, containment, or a human decision instead. Step 3: Determine a sensible ORDER — critical/no-patch security items first, then other high CVEs, then cleanup and low-effort maintenance; do not put unused cleanup or low-risk maintenance ahead of a critical no-patch replacement just because it is easy. Step 4: Distinguish real exposure from theoretical (a CVE in an unreachable code path is lower risk — say so), and distinguish maintenance-only upgrades from security fixes. Step 5: Note anything needing human judgment (license/legal, a major framework bump). Good looks like: a tier justified by both severity and actual exposure, not just the audit tool's color. Stage the tiered list to `write_task_note`. Do not write the report yet.\n\nThe deliverable `notes/assess.md` lands in the project's artifacts drawer — write it with `write_artifact` and read it back with `read_artifact`; the shipped workspace stays untouched.",
+      "suggestedRole": "reviewer",
+      "advanceWhen": {
+        "file": "notes/assess.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "notes/assess.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "notes/assess.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "assess",
+        "maxAttempts": 3
+      },
+      "next": "report"
+    },
+    {
+      "id": "report",
+      "name": "Write the audit report",
+      "description": "prioritized upgrade/replace/remove plan",
+      "prompt": "Step 1: Open `dependency-audit.md` and write a '## Summary' line: total deps, count by risk tier, and the headline risk. Step 2: Add an '## Action plan' ordered by priority; each entry: `package@installed → action (target version / replacement / remove / defer)` with the reason (CVE id + severity, semver gap, license, abandonment, or no seeded issue), the breaking-change note if any, and the migration effort. Keep exact target versions and named replacement alternatives from the evidence; do not downgrade a named maintenance upgrade to vague monitoring or replace a named alternative with generic wording. Step 3: Add a '## License flags' section for any copyleft/incompatible licenses; if the source names GPL/copyleft, the section must name that package and exact license identifier, not say no flags were found. Do not infer missing licenses; say license not provided when the evidence does not name one. Step 4: Add a '## Needs human decision' section for legal/major-bump/no-patch calls. Step 5: Add a one-paragraph '## Recommended order' (what to do this week vs later), keeping critical no-patch CVEs ahead of unused cleanup and low-effort maintenance upgrades. Every action must name a concrete target and a justification — no 'update your packages'. On a loop-back, fix only the named gaps. `write_task_note` the report path and the counts by tier.\n\nThe deliverable `dependency-audit.md` lands in the project's artifacts drawer — write it with `write_artifact` and read it back with `read_artifact`; the shipped workspace stays untouched.",
+      "suggestedRole": "reviewer",
+      "advanceWhen": {
+        "file": "dependency-audit.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "dependency-audit.md",
+            "bytes": 1500,
+            "artifact": true
+          },
+          {
+            "kind": "contains",
+            "file": "dependency-audit.md",
+            "pattern": "(?:^|\\n)#{1,3}\\s+\\S",
+            "flags": "i",
+            "label": "at least one markdown heading",
+            "artifact": true
+          }
+        ],
+        "onReject": "report",
+        "maxAttempts": 4
+      },
+      "next": "evaluate"
+    },
+    {
+      "id": "evaluate",
+      "name": "Evaluate",
+      "description": "Grade the deliverable against every acceptance criterion. All pass → finish; any fail → loop back and fix the gap.",
+      "prompt": "Open `dependency-audit.md` and grade it against the scan checklist. Check EACH criterion and write PASS/FAIL with a one-line reason: (1) every direct dependency is inventoried with installed vs latest; (2) all high+ CVEs are captured with an id and severity; (3) each risky dep has a concrete action (upgrade target / replacement / remove / defer) and a justification; (4) breaking-change/migration cost is noted for major upgrades; (5) licenses are recorded and incompatibilities flagged, especially any GPL/copyleft source note; (6) the plan is prioritized with a recommended order that puts critical/no-patch security items before unused cleanup and maintenance-only upgrades; (7) risk tiers reflect actual exposure, not just the tool's raw severity; (8) no dependency with no seeded issue is inflated into a security/replacement recommendation; (9) no dependency with no patched version is described as patch-upgradeable. If any criterion fails, name the exact gap and loop back.\n\nThe deliverable lives in the project's artifacts drawer — open `dependency-audit.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: \"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",
+      "consumes": [
+        {
+          "file": "dependency-audit.md",
+          "artifact": true
+        }
+      ],
+      "next": "report"
+    },
+    {
+      "id": "finish",
+      "name": "Finish",
+      "description": "All acceptance criteria met. Stamp a short summary and report DONE.",
+      "prompt": "Every acceptance criterion passed. Write a one-paragraph DONE summary to task notes via `write_task_note`: what was built, the deliverable path(s), and a one-line confirmation that each criterion is met. Then report DONE.",
+      "suggestedRole": "developer",
+      "terminal": true
+    }
+  ],
+  "version": "1.1.1",
+  "releasedAt": "2026-08-14T00:00:00Z"
+}