@bendyline/gilde 0.1.27 → 0.1.29

package/data/craftbook-templates/an/anomaly-scan/versions/1.0.1/test.json

@@ -0,0 +1,120 @@
+{
+  "schemaVersion": 1,
+  "title": "Anomaly scan over seeded orders data",
+  "objective": "Measure whether the anomaly-scan craftbook defines reproducible criteria, emits machine-readable flags, and writes a triage-ready report.",
+  "tags": [
+    "data"
+  ],
+  "prompt": "In the `Anomaly Scan Eval` project, read `data/orders.csv`, define concrete anomaly thresholds, write `data/anomalies.json`, and then write `report.md` ranking the findings. The report must separate likely real problems from probable noise.",
+  "setup": {
+    "projectName": "Anomaly Scan Eval",
+    "about": "Self-contained eval project for anomaly-scan. The source dataset is workspace/data/orders.csv.",
+    "missionObjectives": "Find and explain anomalous order rows with explicit rules, JSON flags, severities, and a triage report.",
+    "files": [
+      {
+        "path": "data/orders.csv",
+        "content": "order_id,order_date,sku,quantity,revenue,region\nO-1001,2026-05-01,CHAIR-1,2,240,West\nO-1002,2026-05-01,LAMP-2,1,80,East\nO-1003,2026-05-02,DESK-5,1,620,West\nO-1004,2026-05-02,CHAIR-1,3,360,South\nO-1005,2026-05-03,LAMP-2,2,160,East\nO-1006,2026-05-03,DESK-5,1,610,West\nO-1007,2026-05-04,CHAIR-1,4,-480,West\nO-1008,2026-05-04,LAMP-2,1,82,North\nO-1009,2026-05-05,DESK-5,50,30500,West\nO-1010,2028-01-01,LAMP-2,1,80,East\nO-1011,2026-05-06,CHAIR-1,2,242,South\nO-1012,2026-05-06,DESK-5,1,615,West\nO-1013,2026-05-07,LAMP-2,0,0,East\n"
+      }
+    ],
+    "worker": {
+      "name": "Cato",
+      "role": "Data Analyst"
+    }
+  },
+  "mocks": [],
+  "success": {
+    "summary": "workspace/report.md and data/anomalies.json identify the seeded anomalous rows with rules, thresholds, severity, and triage guidance.",
+    "deliverables": [
+      {
+        "path": "report.md",
+        "kind": "markdown-report",
+        "minBytes": 1800,
+        "checks": [
+          {
+            "kind": "contains",
+            "file": "report.md",
+            "pattern": "(?:^|\\n)#{1,3}\\s+\\S",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "report.md",
+            "pattern": "O-1007|O-1009|O-1010|O-1013",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "report.md",
+            "pattern": "negative|future|quantity|outlier|threshold|severity",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "report.md",
+            "pattern": "likely real|probable noise|false positive",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "report.md",
+            "pattern": "recommended next steps|triage|action",
+            "flags": "i"
+          }
+        ]
+      },
+      {
+        "path": "data/anomalies.json",
+        "kind": "json",
+        "minBytes": 300,
+        "checks": [
+          {
+            "kind": "sniff",
+            "file": "data/anomalies.json",
+            "sniff": "json-valid"
+          },
+          {
+            "kind": "contains",
+            "file": "data/anomalies.json",
+            "pattern": "O-1007|O-1009|O-1010|O-1013",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "data/anomalies.json",
+            "pattern": "severity|rule|threshold|summary",
+            "flags": "i"
+          }
+        ]
+      }
+    ]
+  },
+  "rubric": {
+    "artifact": {
+      "path": "report.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": [
+    "criteria first",
+    "JSON flags",
+    "ranked triage report"
+  ]
+}

package/data/craftbook-templates/ap/api-contract-review/versions/1.1.1/craftbook.json

@@ -0,0 +1,141 @@
+{
+  "id": "api-contract-review",
+  "name": "API Contract Review",
+  "description": "Review an API contract or specification (OpenAPI/REST/GraphQL) for correctness, consistency, and developer ergonomics, then produce a findings report. First scopes the surface and locks an API design checklist (resource naming and HTTP semantics, status codes, pagination and filtering, error schema consistency, auth, versioning and backward compatibility, idempotency, and schema/type rigor), then reviews each endpoint and type against those rules and REST/GraphQL best practices, then writes a findings report rating each issue and giving the corrected contract snippet. Use this for an API design review, reviewing an OpenAPI/Swagger spec, a REST or GraphQL contract review, endpoint/schema critique, or checking an API for consistency and backward compatibility before it ships — it returns specific, spec-anchored fixes rather than 'make the API cleaner'.\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 contract review (reviewer) — map the surface, lock an API design checklist → gated on artifact `notes/scope.md` (markdown-notes)\n2. Review the endpoints (developer) — check each operation + type against the rules → gated on artifact `notes/review.md` (markdown-notes)\n3. Write the contract report (reviewer) — findings with corrected snippets + compat verdict → gated on artifact `api-review.md` (markdown-report)\n\nThe gates never advance with an unmet criterion, and loop back to the\nowning phase to fix named gaps.\n",
+  "entryStepId": "scope",
+  "triggers": [
+    "api contract review",
+    "review my openapi spec",
+    "review this REST API",
+    "graphql schema review",
+    "is this api backward compatible",
+    "api design review"
+  ],
+  "steps": [
+    {
+      "id": "scope",
+      "name": "Scope the contract review",
+      "description": "map the surface, lock an API design checklist",
+      "prompt": "Step 1: Read the contract (OpenAPI/Swagger YAML/JSON, a GraphQL SDL, or the route/handler definitions) and inventory every endpoint/operation/type with its method, path, params, request/response schema, and auth. Step 2: Note whether this is a NEW API or a CHANGE to an existing one (if a change, backward compatibility is a first-class criterion). Step 3: Write an API acceptance-criteria checklist covering: resource naming (nouns, plural collections, consistent casing) and correct HTTP-method semantics; correct and consistent status codes (201 on create, 204 on empty, 4xx vs 5xx); a single consistent error schema across all endpoints; pagination/filtering/sorting conventions applied uniformly; auth declared per operation; explicit versioning and no breaking changes (no removed/renamed fields, no narrowed types, no new required inputs) for changes; idempotency for unsafe-but-retried operations; and schema rigor (required vs optional correct, enums constrained, types precise, examples present). Step 4: State the pass condition for each. Write the surface inventory + checklist to `write_task_note` AND `notes/scope.md`. No findings yet.\n\nThe deliverable `notes/scope.md` lands in the project's artifacts drawer — write it with `write_artifact` and read it back with `read_artifact`; the shipped workspace stays untouched.",
+      "suggestedRole": "reviewer",
+      "advanceWhen": {
+        "file": "notes/scope.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "notes/scope.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "notes/scope.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "scope",
+        "maxAttempts": 3
+      },
+      "next": "review"
+    },
+    {
+      "id": "review",
+      "name": "Review the endpoints",
+      "description": "check each operation + type against the rules",
+      "prompt": "Step 1: Walk EACH endpoint/operation against the checklist: verify the method matches the action, the path is a sensible resource, the status codes are correct and complete (including error codes), the request/response schemas are precise, and auth is declared. Step 2: Walk EACH type/schema: required vs optional fields are right, enums and formats constrain values, nullability is intentional, and naming is consistent. Step 3: Cross-cut the whole surface for consistency: do all errors share one schema, is pagination uniform, is casing consistent, are similar resources modeled the same way. Step 4: For a CHANGE, diff against the prior contract and flag every breaking change. Step 5: For each finding capture: the operation/type, the rule violated, the impact on a client developer, severity, and the CORRECTED snippet (the fixed YAML/SDL/schema fragment). Good looks like: a finding with a before/after contract snippet, not 'improve error handling'. Stage findings to `write_task_note`. Do not write the report yet.\n\nThe deliverable `notes/review.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/review.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "notes/review.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "notes/review.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "review",
+        "maxAttempts": 3
+      },
+      "next": "report"
+    },
+    {
+      "id": "report",
+      "name": "Write the contract report",
+      "description": "findings with corrected snippets + compat verdict",
+      "prompt": "Step 1: Open `api-review.md` and write a verdict: Approve / Approve-with-changes / Request-changes, and for a change an explicit Backward-compatible: yes/no. Step 2: Add a '## Breaking changes' section first if any (each with the operation and the corrected approach), then '## Blocking' and '## Non-blocking' findings, each as `operation/type — rule — impact — corrected snippet`. Step 3: Add a '## Consistency' section for cross-cutting issues (error schema, pagination, casing). Step 4: Add a '## Strengths' note on what the contract gets right. Every finding must cite the operation/type and include a concrete corrected snippet — no generic advice. On a loop-back, fix only the named gaps. `write_task_note` the report path, the compatibility verdict, and the count of blocking findings.\n\nThe deliverable `api-review.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": "api-review.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "api-review.md",
+            "bytes": 1500,
+            "artifact": true
+          },
+          {
+            "kind": "contains",
+            "file": "api-review.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 `api-review.md` and grade it against the scope checklist. Check EACH criterion and write PASS/FAIL with a one-line reason: (1) every endpoint/operation and type was reviewed; (2) HTTP-method/status-code semantics were checked; (3) error schema, pagination, and naming consistency were assessed across the surface; (4) for a change, backward compatibility is explicitly stated and any breaking change is flagged; (5) each finding includes a concrete corrected contract snippet; (6) findings are prioritized (breaking/blocking/non-blocking); (7) the verdict matches the findings. If any criterion fails, name the exact gap and loop back.\n\nThe deliverable lives in the project's artifacts drawer — open `api-review.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": "api-review.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"
+}

package/data/craftbook-templates/ap/api-contract-review/versions/1.1.1/test.json

@@ -0,0 +1,115 @@
+{
+  "schemaVersion": 1,
+  "title": "API Contract Review codebase eval",
+  "objective": "Measure whether the review reconciles an OpenAPI contract with its handler and catches consistency, semantics, auth, and pagination defects.",
+  "tags": [
+    "corpus"
+  ],
+  "prompt": "Use the API Contract Review craftbook for a codebase-wide API design pass. Compare openapi.yaml with src/routes.ts and write api-review.md with corrected snippets. Do not edit the contract or handler.",
+  "setup": {
+    "projectName": "API Design Maintenance Eval",
+    "about": "A small REST API whose contract and implementation contain deliberate design and drift defects.",
+    "missionObjectives": "Produce an evidence-backed API design report covering every seeded operation and its implementation.",
+    "files": [
+      {
+        "path": "openapi.yaml",
+        "content": "openapi: 3.0.3\ninfo: { title: Widget API, version: 1.0.0 }\npaths:\n  /getWidgets:\n    get:\n      responses:\n        '200':\n          description: widgets\n          content:\n            application/json:\n              schema: { type: array, items: { $ref: '#/components/schemas/Widget' } }\n  /widgets:\n    post:\n      requestBody:\n        required: true\n        content:\n          application/json:\n            schema: { $ref: '#/components/schemas/Widget' }\n      responses:\n        '200': { description: created }\ncomponents:\n  schemas:\n    Widget:\n      type: object\n      properties:\n        id: { type: string }\n        display_name: { type: string }\n"
+      },
+      {
+        "path": "src/routes.ts",
+        "content": "app.get('/widgets', async (_req, res) => res.json(await db.widgets.all()));\napp.post('/widgets', async (req, res) => {\n  const widget = await db.widgets.create(req.body);\n  res.status(200).json(widget);\n});\napp.get('/widgets/:id', async (req, res) => {\n  const item = await db.widgets.get(req.params.id);\n  if (!item) return res.status(404).json({ message: 'missing' });\n  res.json(item);\n});\n"
+      }
+    ],
+    "worker": {
+      "name": "Rae",
+      "role": "Reviewer"
+    }
+  },
+  "mocks": [],
+  "success": {
+    "summary": "api-review.md covers every seeded operation, contract/implementation drift, and corrected contract snippets.",
+    "deliverables": [
+      {
+        "path": "api-review.md",
+        "kind": "markdown-report",
+        "minBytes": 1400,
+        "checks": [
+          {
+            "kind": "contains",
+            "file": "api-review.md",
+            "pattern": "openapi\\.yaml|src/routes\\.ts",
+            "flags": "i",
+            "label": "real evidence"
+          },
+          {
+            "kind": "contains",
+            "file": "api-review.md",
+            "pattern": "/getWidgets|resource naming|noun",
+            "flags": "i",
+            "label": "resource naming"
+          },
+          {
+            "kind": "contains",
+            "file": "api-review.md",
+            "pattern": "201|created",
+            "flags": "i",
+            "label": "create response semantics"
+          },
+          {
+            "kind": "contains",
+            "file": "api-review.md",
+            "pattern": "pagination|cursor|limit",
+            "flags": "i",
+            "label": "collection pagination"
+          },
+          {
+            "kind": "contains",
+            "file": "api-review.md",
+            "pattern": "auth|security",
+            "flags": "i",
+            "label": "auth coverage"
+          },
+          {
+            "kind": "contains",
+            "file": "api-review.md",
+            "pattern": "/widgets/:id|not documented|drift",
+            "flags": "i",
+            "label": "implementation drift"
+          },
+          {
+            "kind": "contains",
+            "file": "api-review.md",
+            "pattern": "```(?:ya?ml|json)?[\\s\\S]{20,}```",
+            "flags": "i",
+            "label": "corrected snippet"
+          }
+        ]
+      }
+    ]
+  },
+  "rubric": {
+    "artifact": {
+      "path": "api-review.md",
+      "kind": "markdown"
+    },
+    "axes": [
+      {
+        "name": "surface coverage",
+        "description": "The contract and all implemented operations are reconciled."
+      },
+      {
+        "name": "design rigor",
+        "description": "Semantics, consistency, auth, pagination, and schema quality are reviewed."
+      },
+      {
+        "name": "actionability",
+        "description": "Findings include concrete corrected snippets and compatibility impact."
+      }
+    ]
+  },
+  "qualityFocus": [
+    "contract-implementation reconciliation",
+    "API semantics",
+    "corrected snippets"
+  ]
+}

package/data/craftbook-templates/ar/artifact-integrity-review/versions/1.0.1/craftbook.json

@@ -0,0 +1,158 @@
+{
+  "id": "artifact-integrity-review",
+  "name": "Artifact Integrity & Ship Review",
+  "description": "Perform an isolated ship-readiness review of the actual built artifacts of a project—sites, npm packages, archives, CLIs, binaries, installers, checksums, signatures, and release bundles—rather than trusting source or CI status. Inventories expected versus present assets, stages immutable copies, inspects archive contents and metadata, runs safe sandboxed smoke checks where possible, and leaves per-artifact GO/NO-GO verdicts plus a release-wide decision. Can review locally staged assets or public-release evidence supplied to the project. Use before shipping a release or as a recurring artifact-integrity night-shift audit.\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. Inventory and stage the release (reviewer) — lock the expected matrix and immutable evidence set before inspecting it → gated on artifact `notes/artifacts/inventory.md` (markdown-notes)\n2. Inspect each artifact (developer) — verify identity, contents, installability, safety, and cross-artifact consistency → gated on artifact `notes/artifacts/checks.md` (markdown-notes)\n3. Write the artifact ship report (reviewer) — per-artifact verdicts and a release-wide ship decision → gated on artifact `artifact-integrity-review.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": "inventory",
+  "triggers": [
+    "artifact integrity review",
+    "review the built artifacts",
+    "test the release assets",
+    "are these installers ready to ship",
+    "audit a public github release",
+    "nightly artifact review"
+  ],
+  "toolsets": [
+    {
+      "toolsetId": "builtin.archives",
+      "autoAllow": true,
+      "reason": "inspect zip, tar, tgz, and package contents without trusting filenames"
+    },
+    {
+      "toolsetId": "builtin.code-execution",
+      "autoAllow": true,
+      "reason": "perform bounded, sandboxed metadata and smoke checks on staged artifacts"
+    },
+    {
+      "toolsetId": "builtin.web",
+      "autoAllow": true,
+      "reason": "read public release metadata and verify supplied public asset URLs when allowed"
+    }
+  ],
+  "steps": [
+    {
+      "id": "inventory",
+      "name": "Inventory and stage the release",
+      "description": "lock the expected matrix and immutable evidence set before inspecting it",
+      "prompt": "Define the exact release under review (version, commit/tag, target platforms, artifact types). Derive the expected asset matrix from release manifests, package metadata, CI/release configuration, checksums, and supplied release notes. Inventory every locally staged artifact with path, byte size, type/magic when available, and a cryptographic hash. If public release metadata or URLs were supplied and Web Access is allowed, verify the public listing and headers; never claim a remote binary was downloaded or inspected unless it is actually present in the workspace. Preserve the originals and work only on isolated extracted/staged copies. Record missing, duplicate, unexpected, truncated, or zero-byte assets immediately. Write the expected-vs-present matrix, provenance, hashes, acquisition limitations, and isolation plan to `notes/artifacts/inventory.md`.\n\nThe deliverable `notes/artifacts/inventory.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/artifacts/inventory.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "notes/artifacts/inventory.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "notes/artifacts/inventory.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "inventory",
+        "maxAttempts": 3
+      },
+      "next": "inspect"
+    },
+    {
+      "id": "inspect",
+      "name": "Inspect each artifact",
+      "description": "verify identity, contents, installability, safety, and cross-artifact consistency",
+      "prompt": "Inspect every artifact independently. Use `list_archive` before extraction, then extract into isolated paths. Verify filename/type/magic, version and commit identity, checksums/signatures when provided, expected entrypoints, executable bits, package manifests, dependency/lock and license/SBOM notices, source-map/debug-symbol policy, update/uninstall metadata, and absence of secrets, private keys, `.env`, build caches, absolute developer paths, or unexpected source. Check sites for missing referenced assets. For npm/CLI/packages, perform only safe sandboxed pack/install/help/version/smoke checks; never run an untrusted native installer on the host. For platform artifacts that cannot run here, inspect statically and mark the platform smoke test NOT VERIFIED. Compare all artifacts for one version/commit and consistent bundled files. Record commands, exit codes, and evidence per artifact in `notes/artifacts/checks.md`.\n\nThe deliverable `notes/artifacts/checks.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/artifacts/checks.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "notes/artifacts/checks.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "notes/artifacts/checks.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "inspect",
+        "maxAttempts": 3
+      },
+      "next": "report"
+    },
+    {
+      "id": "report",
+      "name": "Write the artifact ship report",
+      "description": "per-artifact verdicts and a release-wide ship decision",
+      "prompt": "Write `artifact-integrity-review.md` with: `## Release verdict`, `## Evidence provenance`, `## Artifact matrix`, `## Blocking findings`, `## Advisory findings`, `## Cross-artifact consistency`, `## Not verified`, and `## Reproduction commands`. Give every artifact its own GO / NO-GO / NOT-VERIFIED verdict. Every claim must point to a staged path, hash, manifest field, archive member, command/exit code, or supplied public-release record. Any missing expected artifact, secret/private key, checksum/signature mismatch, version/commit mismatch, broken entrypoint, failed smoke test, or missing referenced site asset is a blocker unless explicitly justified. A release cannot be GO when any required artifact is NO-GO or materially unverified. Keep source-code readiness outside scope except where needed to explain artifact provenance.\n\nThe deliverable `artifact-integrity-review.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": "artifact-integrity-review.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "artifact-integrity-review.md",
+            "bytes": 2000,
+            "artifact": true
+          },
+          {
+            "kind": "contains",
+            "file": "artifact-integrity-review.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": "Grade `artifact-integrity-review.md`: (1) expected and present assets are reconciled; (2) each artifact has provenance, size/type/hash, checks, and an individual verdict; (3) archive/package contents and metadata were inspected in isolation; (4) safe smoke tests include commands and exit codes while unrun platform tests are NOT VERIFIED; (5) versions/commits and bundled content agree across artifacts; (6) secrets, licenses/SBOM, source maps/debug files, signatures/checksums, entrypoints, and missing site assets were considered where applicable; (7) the release verdict follows blockers and uncertainty. PASS all or loop back with exact gaps.\n\nThe deliverable lives in the project's artifacts drawer — open `artifact-integrity-review.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": "artifact-integrity-review.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.0.1",
+  "releasedAt": "2026-08-14T00:00:00Z"
+}