Critique reviewer runtime
How the Critique CLI owns its pinned OpenCode runtime, model roles, evidence capture, and repository review configuration.
The Critique CLI is a reviewer harness, not a parent process that launches whichever agent happens to be installed on a developer's machine.
Critique ships a pinned OpenCode distribution, drives it through the typed SDK, injects Critique's review agents and plugin, and owns the session boundary. The coding agent remains the author and caller. Critique is the independent reviewer and second brain.
flowchart LR
A[Main coding agent\nClaude Code, Codex, Cursor, or another agent]
C[Critique CLI\ntask spine + review policy]
R[Pinned Critique reviewer runtime\nOpenCode + typed SDK]
P[Critique plugin\ncontroller-captured evidence]
W[Complete isolated repository\ncritic · repairer · verifier]
A -->|task, question, checkpoint, review request| C
C --> R
R --> P
R --> W
P -->|argv, exit code, digests, tree state| C
C -->|structured result| AOne owned runtime
The package pins the OpenCode binary, SDK, and plugin to the same exact version. Startup resolves the package-local binary, disables uncontrolled project configuration and auto-update, creates isolated runtime directories, and completes a typed SDK handshake before a review can run.
The CLI never relies on an ambient opencode executable, undocumented permission flags, or a guessed JSONL wire format. The runtime exposes sessions and messages through the SDK. Critique's plugin observes the commands that matter to a finding and emits evidence that the reviewer cannot author for itself.
OpenCode remains an implementation component. It is not a selectable Critique reviewer engine. --engine chooses execution location only when the command supports it, such as cloud; it does not let the caller swap out Critique's reviewer harness.
Model roles are separate
Critique uses different roles even when a caller chooses the same provider:
| Role | Responsibility | Context boundary |
|---|---|---|
| Critic | Recon the repository, form hypotheses, reproduce consequential defects, and return findings | Fresh session, complete isolated repository, no author transcript |
| Specialist | Investigate one evidence obligation such as correctness, security, tests, architecture, or performance | Separate workspace and fresh session per lane |
| Lead | Reproduce and adjudicate specialist candidates, reject duplicates, and resolve conflicts | Fresh lead session over the repository and lane output |
| Repairer | Edit only the allowed paths for one proven defect | Fresh repair workspace |
| Verifier | Re-run the original reproduction and regression checks against the proposed patch | Fresh workspace, fresh conversation, different model family |
| Second brain | Discuss architecture, investigate the repository, and delegate read-only exploration while work is in motion | Persistent named conversation, author tree mutation denied |
The default verifier is deliberately a different model family from the repairer. A repository profile can select another verifier explicitly:
{
"schema_version": "critique.review-profile.v1",
"reviewer": {
"repository_recon": "deep",
"max_findings": 8,
"require_reproduction": true,
"verifier_model": "qwen/qwen3.7-flash"
}
}Evidence belongs to Critique
Reviewers use the bundled critique_check tool for commands whose results support a finding. The plugin records the exact executable and arguments, exit code, duration, output digests, and before/after repository tree digests. The controller binds that evidence to the current session, message, actor, and repository state.
Model prose can suggest a hypothesis. It cannot turn a claimed command into proof. A strict repair verification therefore requires current Critique-runner evidence, a reset workspace, a fresh verifier conversation, and a different model family. If any part is missing, the repair remains rejected or unverified.
Repository configuration is portable
.critique/profile.json controls review behavior without moving execution into the web application. It can select or exclude bundled methodologies, choose focused or deep repository reconnaissance, cap findings, require reproduction, select the verifier model, and tune how the second brain interrupts the main agent.
The document is intentionally portable. A future configuration UI can author or export it, while the CLI remains the execution authority and the reviewer never treats the profile as evidence about the code.
Why Critique does not rebuild the agent loop
Critique owns the layers that differentiate a reviewer: task continuity, author-context exclusion, complete-repository recon, specialist assignments, lead adjudication, evidence capture, repair boundaries, and fresh verification.
It does not reimplement tool calling, provider streaming, retries, session storage, and model adapters. OpenCode already owns that difficult, fast-moving loop. Driving the pinned runtime through its SDK gives Critique a stable ownership boundary without taking on an unnecessary fork.
Local and cloud execution
Local review is the default. The CLI creates disposable workspaces on the developer's machine and keeps source, patches, and normal environment files local. Cloud review is a separate execution location for a clean remote machine. It receives a protected working-tree snapshot and gives each critic, repairer, and verifier a fresh workspace.
The reviewer contract is the same in both locations: complete repository context, fresh judgment, Critique-controlled evidence, and a structured result for the calling agent.