@bendyline/gilde 0.1.26 → 0.1.28

package/data/craftbook-templates/pr/proposal-sow/versions/1.0.1/craftbook.json

@@ -0,0 +1,143 @@
+{
+  "id": "proposal-sow",
+  "name": "Proposal / Statement of Work",
+  "description": "Draft a client proposal or statement of work that wins the deal and prevents scope creep — covering objectives, scope, deliverables, timeline/milestones, pricing, assumptions, and acceptance criteria. Scopes the engagement and the in-scope/out-of-scope boundary FIRST (the boundary is what protects both sides), writes persuasive yet precise proposal copy, then formats it into a clean client-ready document with a structured deliverables-and-pricing table. Use for freelance/agency bids, consulting SOWs, and project proposals.\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 engagement (planner) — objectives, in/out-of-scope boundary, deliverables, milestones, price → gated on artifact `notes/scope.md` (markdown-notes)\n2. Write the proposal (copywriter) — persuasive, precise proposal copy section by section → gated on artifact `notes/write.md` (markdown-notes)\n3. Format the document (developer) — render proposal.html with cover, deliverables/pricing tables, sign-off → gated on `proposal.html` (html-page)\n\nThe gates never advance with an unmet criterion, and loop back to the\nowning phase to fix named gaps.\n",
+  "entryStepId": "scope",
+  "triggers": [
+    "write a proposal",
+    "statement of work",
+    "sow",
+    "client proposal",
+    "project proposal",
+    "consulting proposal"
+  ],
+  "steps": [
+    {
+      "id": "scope",
+      "name": "Scope the engagement",
+      "description": "objectives, in/out-of-scope boundary, deliverables, milestones, price",
+      "prompt": "Define the engagement precisely before any selling prose. Step 1: state the client's objective and the outcome the work delivers. Step 2: enumerate the deliverables concretely, and — critically — draw the IN-SCOPE vs OUT-OF-SCOPE boundary explicitly (the out-of-scope list is what prevents scope creep and disputes). Step 3: lay out the timeline as milestones/phases with rough durations and dependencies. Step 4: decide the pricing model (fixed, T&M, retainer), the amount or rate, and the payment schedule tied to milestones. Step 5: list assumptions and client responsibilities (access, approvals, content) and the per-deliverable acceptance criteria. Step 6: write an acceptance-criteria checklist for the document itself ('objective stated', 'explicit out-of-scope section', 'deliverables map to milestones', 'pricing tied to a payment schedule', 'assumptions + client responsibilities listed', 'acceptance criteria per deliverable'). Write all decisions + checklist via write_task_note AND to notes/scope.md. No prose or formatting 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": "planner",
+      "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": "write"
+    },
+    {
+      "id": "write",
+      "name": "Write the proposal",
+      "description": "persuasive, precise proposal copy section by section",
+      "prompt": "Write the proposal copy from the locked scope — persuasive about value, precise about commitments. Step 1: open with a short overview that restates the client's objective in their language and frames your approach. Step 2: write the approach/methodology section showing HOW you will deliver, then a deliverables section listing each deliverable with its acceptance criterion. Step 3: write the timeline section as milestones, and a clearly worded scope section with the in-scope list AND a plainly labeled out-of-scope list. Step 4: write the investment/pricing section in client-friendly terms tied to the payment schedule, then the assumptions + client-responsibilities section, and a short next-steps/sign-off close. Step 5: keep the tone confident and specific — no vague 'best efforts' language around commitments. Do not soften or drop the out-of-scope boundary. Write the section-by-section copy via write_task_note AND to notes/write.md.\n\nThe deliverable `notes/write.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": "copywriter",
+      "advanceWhen": {
+        "file": "notes/write.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "notes/write.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "notes/write.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "write",
+        "maxAttempts": 3
+      },
+      "next": "format"
+    },
+    {
+      "id": "format",
+      "name": "Format the document",
+      "description": "render proposal.html with cover, deliverables/pricing tables, sign-off",
+      "prompt": "Format the approved copy into a client-ready document as a single self-contained proposal.html (inline CSS with print @page rules). Step 1: build a cover/header with the project title, client name, your name/company, and date. Step 2: lay out the sections in proposal order (overview, approach, deliverables, scope incl. out-of-scope, timeline, pricing, assumptions/responsibilities, next steps). Step 3: render the deliverables and the pricing/payment schedule as clean bordered tables (deliverable | acceptance criterion; milestone | amount | due) — these must be unambiguous. Step 4: visually distinguish the out-of-scope list (e.g. its own boxed callout) so it cannot be missed. Step 5: add a sign-off block (signature lines, date) and clean print page breaks. Drop the approved copy in verbatim; do not rewrite commitments. On a loop-back, fix ONLY the named gaps. Write the path + a note confirming the tables and out-of-scope section are present via write_task_note.",
+      "suggestedRole": "developer",
+      "advanceWhen": {
+        "file": "proposal.html",
+        "minBytes": 1,
+        "sniff": "html-complete"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "proposal.html",
+            "bytes": 800
+          },
+          {
+            "kind": "htmlLint",
+            "file": "proposal.html"
+          }
+        ],
+        "scripts": [
+          {
+            "name": "checkHtmlComplete",
+            "scope": "standard",
+            "inputs": {
+              "file": "proposal.html"
+            }
+          }
+        ],
+        "onReject": "format",
+        "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": "QA the proposal against the locked criteria. Step 1: open/render proposal.html. Step 2: check EACH acceptance criterion: the client objective is stated up front, there is an explicit and visually distinct out-of-scope section, deliverables are listed with acceptance criteria and map to the timeline milestones, pricing is shown as a table tied to a payment schedule, assumptions + client responsibilities are listed, and a sign-off block is present. Step 3: confirm the deliverables and pricing tables are unambiguous and the commitment language is specific (no vague hedging where commitments belong). Step 4: confirm it prints cleanly. Write PASS/FAIL per criterion, noting the offending section on any FAIL.\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: \"format\" })` 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": "proposal.html"
+        }
+      ],
+      "next": "format"
+    },
+    {
+      "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"
+}

package/data/craftbook-templates/pr/proposal-sow/versions/1.0.1/test.json

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

package/data/craftbook-templates/pu/pull-request-review/manifest.json

@@ -18,6 +18,8 @@
   },
   "logo": "logo.webp",
   "license": "MIT",
-  "yankedVersions": [],
+  "yankedVersions": [
+    "1.4.0"
+  ],
   "workflow": "review"
 }

package/data/craftbook-templates/pu/pull-request-review/versions/1.4.1/craftbook.json

@@ -0,0 +1,180 @@
+{
+  "id": "pull-request-review",
+  "name": "Pull Request Review",
+  "description": "Review a GitHub pull request from a complete, launch-time local mirror rather than a context-sized API response. The runtime resolves the explicit PR number or current-branch PR, materializes an overview, a machine-readable changed-file manifest, one untruncated patch record per changed path, comments, and the full diff. The reviewer processes at most 25 records per activation; a mechanical coverage gate reactivates the scan with a fresh context until every changed path is accounted for. Repository symbol search and GitHub check status ground cross-file and compile/CI claims before the final local verdict.",
+  "basedOn": {
+    "name": "Gezel Code Review",
+    "url": "https://github.com/bendyline/gezel"
+  },
+  "entryStepId": "scope",
+  "triggers": [
+    "review this pr",
+    "review the current pr",
+    "review this pull request",
+    "pr review",
+    "review the github pull request"
+  ],
+  "requirements": [
+    {
+      "kind": "github"
+    }
+  ],
+  "connectors": [
+    {
+      "typeId": "github-pulls",
+      "reason": "materialize the selected pull request as a complete, chunk-readable local corpus"
+    }
+  ],
+  "toolsets": [
+    {
+      "toolsetId": "github",
+      "optional": true,
+      "autoAllow": true,
+      "reason": "read CI/check status and perform targeted PR verification"
+    }
+  ],
+  "paramSchema": {
+    "type": "object",
+    "properties": {
+      "number": {
+        "type": "number",
+        "title": "Pull request number",
+        "description": "Optional PR number. Leave blank to use the open PR whose head matches the project's checked-out branch."
+      },
+      "focus": {
+        "type": "string",
+        "title": "Review focus",
+        "default": "general correctness",
+        "description": "Optional area to emphasize, e.g. security, performance, or tests."
+      },
+      "intensity": {
+        "type": "string",
+        "title": "Intensity",
+        "enum": [
+          "low",
+          "medium",
+          "high"
+        ],
+        "default": "medium",
+        "squisq": {
+          "control": "segmented"
+        },
+        "description": "How deep to go on each changed-file batch. Coverage remains complete at every intensity."
+      }
+    }
+  },
+  "steps": [
+    {
+      "id": "scope",
+      "name": "Map the pull request corpus",
+      "description": "Read the launch-time PR overview and manifest, record the authoritative changed-file count and review batches, and capture current CI/check evidence.",
+      "prompt": "**You are reviewing PR #{{number}}, not authoring it. Never modify project source in this craftbook.** The runtime already mirrored the selected PR into `{{corpusScope}}`; this corpus, not a single live diff call, is the authoritative review surface.\n\nCall `list_artifacts({ path: \"{{corpusScope}}\", recursive: true })`. Find and read the overview Markdown record and its attached `pr-{{number}}-files.json` manifest. The manifest contains the complete changed-file list and deterministic 25-file batches. Read the overview's PR metadata and existing comments. Call `github_check_status` for the overview's head ref and record whether checks are success, failure, pending, or unknown; this is evidence, not a substitute for reviewing the diff.\n\nWrite ONE task note beginning `## Scope — PR #{{number}}`. Include title, URL, head → base, draft state, exact changed-file count, manifest path, batch count/ranges, CI/check status, existing-review themes, and 3–6 review themes weighted by focus `{{focus}}` and intensity `{{intensity}}`. Do not retype paths from memory: derive them from the manifest. End by calling `advance_task_step`.",
+      "suggestedRole": "reviewer",
+      "gate": {
+        "at": "completion",
+        "scripts": [
+          {
+            "name": "checkTaskNoteContains",
+            "scope": "standard",
+            "inputs": {
+              "pattern": "##\\s*Scope\\s*[—-]\\s*PR\\s*#{{number}}[\\s\\S]*(?:changed.file|files?)"
+            }
+          }
+        ],
+        "onReject": "scope",
+        "maxAttempts": 3
+      },
+      "next": "scan"
+    },
+    {
+      "id": "scan",
+      "name": "Review the next changed-file batch",
+      "description": "Review at most 25 previously unreviewed PR records, persist observations and exact path coverage, then let the runtime reactivate this step with a fresh context until the corpus is complete.",
+      "prompt": "Process exactly ONE bounded batch this activation; do not try to load the whole PR into context.\n\n1. Call `list_artifacts({ path: \"{{corpusScope}}/files\", recursive: true })`. Read `pr-review-coverage.json` if it exists; otherwise start `{ \"pullRequest\": {{number}}, \"reviewedFiles\": [], \"reviewedRecords\": [] }`.\n2. Choose the next at-most-25 artifact record paths not present in `reviewedRecords`. Read every selected record with `read_artifact`; each carries one complete changed-file patch and authoritative `path` frontmatter. Binary/no-patch records still count, but note that limitation.\n3. Review this batch for correctness, security, data loss, error handling, concurrency, compatibility, tests, and clarity, weighted by focus `{{focus}}` and intensity `{{intensity}}`. Append concise batch observations and candidate findings to `pr-review-observations.md`. Include exact `path:new-line` evidence from diff hunks.\n4. Before claiming that a referenced API/type/module does not exist, call `find_symbol`, `search_code`, or `grep_files` against the checkout. Treat successful CI/typecheck evidence from the Scope note as rebuttable evidence that typed APIs resolve; never allege a missing typed API without a failed symbol/search verification. Use `github_pr_file` or paginated `github_pr_diff({ path, offset })` only for targeted live confirmation when the corpus record is ambiguous.\n5. Write `pr-review-coverage.json` after the observations, adding every exact `path` you actually reviewed to `reviewedFiles` and every artifact record path you read to `reviewedRecords`. Preserve prior entries and use valid JSON. Then call `advance_task_step`.\n\nThe completion gate compares `reviewedFiles` with every per-file corpus record. If files remain, rejection is expected: it names missing paths and reactivates this step in a fresh session. Continue with the next batch. Never claim complete coverage until the gate approves.",
+      "suggestedRole": "reviewer",
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "corpusCoverage",
+            "file": "pr-review-coverage.json",
+            "corpusDir": "{{corpusScope}}"
+          }
+        ],
+        "onReject": "scan",
+        "maxAttempts": 6
+      },
+      "next": "report"
+    },
+    {
+      "id": "report",
+      "name": "Synthesize the review",
+      "description": "Synthesize the complete batch ledger into a cited report, re-verifying cross-file claims and keeping CI status distinct from code-review judgment.",
+      "prompt": "The coverage gate has proved that every changed path in PR #{{number}} was reviewed. Read the Scope note, `pr-review-coverage.json`, and `pr-review-observations.md`. Re-check every critical or major candidate against the relevant workspace source with `find_symbol`, `search_code`, `grep_files`, `read_file`, or `read_files`; call `github_check_status` again if the earlier status was pending. Drop any candidate that is not supported. Do not repeat an existing PR comment unless it still needs action and you explicitly say it was already raised.\n\nCite every finding as `path:line` using a changed path and a new-side diff line. Any critical or major finding requires `request-changes`; otherwise use `approve`. CI success is evidence that the checked revision compiled/tested as configured, but it does not erase logic findings. CI unknown/pending is not itself a code defect.\n\nWrite `pr-review.md` in ONE `write_file` call using exactly this skeleton:\n\n```\n# Pull Request Review — PR #{{number}}: <title>\n\n## Summary\n<2–6 sentences: what changes, overall risk, existing-comment coverage, and CI/check status. Say \"No findings.\" when there are none.>\n\nCoverage: <reviewed count>/<changed-file count> changed files across <batch count> batches.\n\n## Findings\n| # | Severity | File | Line | Finding | Recommendation |\n|---|----------|------|------|---------|----------------|\n<one row per finding; severities: critical, major, minor, nit. Keep the header when there are no findings.>\n\n## Verdict\nVerdict: approve\n<or> Verdict: request-changes\n<one sentence of rationale>\n```\n\nDo not modify source and do not call `github_pr_comment`; the report is local. If the gate rejects, repair the named gap and rewrite the whole report. Then call `advance_task_step`.",
+      "suggestedRole": "reviewer",
+      "advanceWhen": {
+        "file": "pr-review.md",
+        "minBytes": 500
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "pr-review.md",
+            "bytes": 500
+          },
+          {
+            "kind": "contains",
+            "file": "pr-review.md",
+            "pattern": "#\\s+Pull Request Review\\s+[—-]\\s+PR\\s+#{{number}}",
+            "label": "PR-numbered title"
+          },
+          {
+            "kind": "contains",
+            "file": "pr-review.md",
+            "pattern": "Coverage:\\s*\\d+\\s*/\\s*\\d+\\s+changed files",
+            "label": "coverage summary"
+          },
+          {
+            "kind": "contains",
+            "file": "pr-review.md",
+            "pattern": "##\\s+Summary[\\s\\S]*##\\s+Findings[\\s\\S]*##\\s+Verdict",
+            "label": "required sections"
+          },
+          {
+            "kind": "contains",
+            "file": "pr-review.md",
+            "pattern": "Verdict:\\s*(approve|request-changes)",
+            "label": "verdict line"
+          },
+          {
+            "kind": "tableShape",
+            "file": "pr-review.md",
+            "requiredColumns": [
+              "Severity",
+              "File",
+              "Line",
+              "Finding",
+              "Recommendation"
+            ]
+          }
+        ],
+        "onReject": "report",
+        "maxAttempts": 4
+      },
+      "next": "done"
+    },
+    {
+      "id": "done",
+      "name": "Deliver the verdict",
+      "description": "The complete-coverage report passed its gates. Summarize the verdict and point the user to the local evidence files.",
+      "prompt": "Read `pr-review.md` and `pr-review-coverage.json`, then write one final task note with `write_task_note`: `PR #{{number}} — Verdict: <approve|request-changes> — N findings (a critical, b major, c minor, d nit) — coverage X/X` plus a one-paragraph summary. Tell the user the full local review is at `pr-review.md`, the coverage ledger is at `pr-review-coverage.json`, and nothing was posted to GitHub. Then call `advance_task_step` to complete the task.",
+      "suggestedRole": "reviewer",
+      "terminal": true
+    }
+  ],
+  "minGezelVersion": "1.26225",
+  "version": "1.4.1",
+  "releasedAt": "2026-08-14T00:00:00Z"
+}

package/data/craftbook-templates/pu/pull-request-review/versions/1.4.1/test.json

@@ -0,0 +1,123 @@
+{
+  "schemaVersion": 1,
+  "title": "Complete-corpus pull request review",
+  "objective": "Verify that Pull Request Review accounts for every changed path in a chunk-readable PR corpus, verifies an API use against a late definition, finds a late-file defect, reports CI evidence separately, and writes a cited local verdict without modifying source or posting to GitHub.",
+  "tags": [
+    "external",
+    "pull-request",
+    "large-corpus",
+    "coverage"
+  ],
+  "prompt": "Review the deterministic large pull-request corpus completely. Work in bounded batches, maintain pr-review-coverage.json, verify the early API call against its late definition, find the late-file authorization defect, and write pr-review.md. Do not modify source or post a GitHub comment.",
+  "setup": {
+    "projectName": "Large PR Review Eval",
+    "about": "A deterministic PR-review fixture. The registered hand-authored scenario materializes more than 100 changed-file records and more than 80 KB of patch text in the artifacts corpus.",
+    "missionObjectives": "Account for every changed path, avoid a false missing-API finding, catch the late authorization defect, and deliver a local request-changes report with exact path:line evidence.",
+    "files": [
+      {
+        "path": "src/api/use-assured-api.ts",
+        "content": "import { assuredApi } from './assured-api.js';\n\nexport function loadWidget(id: string): string {\n  return assuredApi(id);\n}\n"
+      },
+      {
+        "path": "src/api/assured-api.ts",
+        "content": "export function assuredApi(id: string): string {\n  return `widget:${id}`;\n}\n"
+      },
+      {
+        "path": "src/security/late-authorization.ts",
+        "content": "export function canDeleteProject(userId: string, ownerId: string): boolean {\n  if (!userId) return false;\n  // Regression: any authenticated user can delete another owner's project.\n  return true;\n}\n"
+      }
+    ],
+    "worker": {
+      "name": "Rina",
+      "role": "Reviewer",
+      "description": "A careful code reviewer who works through large change sets in bounded batches and verifies cross-file claims."
+    }
+  },
+  "mocks": [],
+  "success": {
+    "summary": "The report covers all 120 changed files, recognizes that assuredApi exists, cites the late authorization defect, requests changes, and leaves the seeded source unchanged.",
+    "deliverables": [
+      {
+        "path": "pr-review.md",
+        "kind": "markdown-report",
+        "minBytes": 500,
+        "checks": [
+          {
+            "kind": "contains",
+            "file": "pr-review.md",
+            "pattern": "Coverage:\\s*120\\s*/\\s*120\\s+changed files",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "pr-review.md",
+            "pattern": "src/security/late-authorization\\.ts(?::|\\s*\\|\\s*)4",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "pr-review.md",
+            "pattern": "Verdict:\\s*request-changes",
+            "flags": "i"
+          },
+          {
+            "kind": "notContains",
+            "file": "pr-review.md",
+            "pattern": "assuredApi.{0,80}(missing|does not exist|undefined)|(?:missing|does not exist|undefined).{0,80}assuredApi",
+            "flags": "is"
+          }
+        ]
+      },
+      {
+        "path": "pr-review-coverage.json",
+        "kind": "json",
+        "minBytes": 500
+      }
+    ],
+    "unchangedFixtures": [
+      "src/api/use-assured-api.ts",
+      "src/api/assured-api.ts",
+      "src/security/late-authorization.ts"
+    ]
+  },
+  "rubric": {
+    "artifact": {
+      "path": "pr-review.md",
+      "kind": "markdown"
+    },
+    "axes": [
+      {
+        "name": "coverage",
+        "description": "The review demonstrates complete 120-file coverage rather than reasoning from an early prefix."
+      },
+      {
+        "name": "cross-file-verification",
+        "description": "The report does not allege that assuredApi is missing because its definition exists later in the corpus and checkout."
+      },
+      {
+        "name": "late-defect",
+        "description": "The report finds and cites the authorization defect deliberately placed in the final changed file."
+      },
+      {
+        "name": "side-effects",
+        "description": "The review remains local and source fixtures stay unchanged."
+      }
+    ]
+  },
+  "qualityFocus": [
+    "complete large-PR coverage",
+    "cross-file API verification",
+    "late-file defect detection",
+    "safe local-only delivery"
+  ],
+  "extensions": {
+    "legacySimulators": [
+      {
+        "id": "large-pr-artifact-corpus",
+        "kind": "data-source",
+        "status": "implemented",
+        "description": "The hand-authored eval scenario seeds 120 per-file PR records totaling more than 80 KB, with an API use early, its valid definition late, and a real authorization defect in the final record."
+      }
+    ]
+  }
+}