Critique v5.1: We Hit Go, Walked Away for Five Hours, and Shipped While Reviewing Ourselves

What we mean by “Critique built Critique”

Picture the boring version first, because the boring version is true. A cloud agent branch opened. It read the v5.1 spec from internal ship notes and the existing v5.0 surfaces. It implemented review-controller persistence, Builder credit previews, API idempotency, marketplace attribution UI, repo-home defaults, and connections copy. It ran unit tests. It opened a pull request.

Then Critique reviewed that pull request the same way it reviews yours: sandbox OpenCode, structured findings, passport linkage, merge policy context. A human did not line-edit TypeScript at 2 a.m. They pressed go, said run Remedy on the failures that mattered, and let the critique-review skill argue with the agent until the diff was boring enough to merge. The loop closed. Review infrastructure shipped on infrastructure that had just been reviewed by itself.

Review runs that explain themselves

PR Review v5 made the diff win the first screen. v5.1 answers the next question operators actually ask: why did the agent do that? OpenCode is no longer a black box that either returns JSON or times out. The cheap controller now persists liveness decisions (wait, nudge, abort) and artifact decisions (accept, follow up) with an evidence-quality score and explicit missing-requirement lists.

When merge is blocked, the review-run detail page does not dump twelve equal-weight buttons. It shows what blocked you across verdict, passport, merge policy, and evidence quality, then offers one primary path: Start Remedy, Queue BYOA, or Dismiss with feedback. That sounds like UX polish. It is actually policy: merge decisions should not feel like a settings panel.

If you lived through the era where every OpenCode failure looked like a hard 500, this release will feel almost insultingly calm. Recoverable stalls read as stalls. Thin evidence reads as thin evidence. The product stops training you to debug the harness when you meant to judge the pull request.

One Coding Agent product, two entry points

The most common v5.0 confusion was philosophical: “Is Builder different from the API?” Yes and no. Same `builderJob`, different front door. v5.1 makes that impossible to misunderstand.

Responses now return `builderJobId` plus `links.builder`, `links.status`, `links.stream`, and `links.passport` when a draft PR exists. The public `/coding-agent-api` page says this out loud. Signed-in operators can jump from marketing copy to their latest Builder job without guessing IDs.

From green Builder run to merge-grade review

Coding agents that only ship code are demos. Coding agents that ship code and land in your change-control story are products. When a published Builder job has a PR number, v5.1 surfaces draft PR and Change Passport actions together: open the PR, jump to review for that branch, or walk back to the repository passport queue. The Branch / PR tab links both directions.

That handoff is the v5 thesis in one gesture: generation is cheap; merge evidence is expensive. Critique already had passports and policy from v4. v5.1 makes sure Builder output does not dead-end in a URL you paste into Slack.

Marketplace feedback you can see

v5.0 launched `/skills` with browse, publish, and a performance leaderboard. v5.1 makes the flywheel visible before you publish your third version. Marketplace cards and skill detail pages show attributed review runs, false-positive rate, label counts, and leaderboard readiness. Publishers can trace “this skill was active on run X” to ranked quality instead of install vanity.

Automation catches up: `crt_` keys gain `read:skills`, pinned `SKILL.md` fetch by version, and portable bundles for CI portals. Install panels can mark a marketplace skill as the default PR-review lens per repository; manual dashboard launches attach the slug to review-run metadata for attribution.

Repo home first, Platform when you need the control room

New installs no longer land on a first-run chooser. Repo home is the default. `/dashboard/pull-requests` opens on a cross-repo attention inbox: blocked, failed, warned, running, needs review — without forcing you to pick a repository before you see fire. Rows keep repository context attached; the picker shows webhook and cache health (Healthy, Stale cache, Missed events, Refresh failed, Install warning) where you actually select repos.

The old control room is not gone. It is `Platform` in the nav: passports, policy, delivery, connections, and fleet status when you need the wide lens. Repo-first for daily review work; Platform for the operating picture. Settings still let you switch experiences if your team runs control-room-first.

Connections as a beta platform layer

We stopped describing Connections as “just settings.” v5.1 labels what is live today: scoped `crt_` keys, MCP v0.1.0 with three tools (`list_passports`, `get_review_run`, `queue_review`), REST v1 for passports and review runs, the Coding Agent API, native Linear and Slack, and Zapier-first positioning for Jira, Sentry, Vercel, and everything else in the long tail.

Three MCP tools is thin for the v5 story. We know. Expanding MCP is the obvious P0 — `queue_remedy`, `get_passport`, `list_review_runs`, `compile_merge_policy_draft` — because MCP is how Cursor and Claude distributions actually install habits. v5.1 ships honest beta framing instead of pretending the catalog is finished.

We really do not stop shipping

v5.0 was the “this is a platform” release. v5.1 is the “this is how we operate the platform while agents ship the next slice” release. The semver is honest: not a rewrite, a tightening of mental models and operator paths that v5.0 introduced faster than docs could follow.

What to do Monday morning

If you are an operator: open a recent review run that blocked merge and read the controller timeline. Flip a repo to an auth/security preset and rerun. If you automate coding: call create with `"preview": true` once before you wire CI spend. If you publish skills: check whether your lens shows attributed runs yet; install defaults per repo if you want leaderboard credit on manual launches.

If you are evaluating whether Critique is “real”: watch us ship v5.1 mostly agent-driven, then read the same findings we show you on your PRs. The ship log at `/version` is the operator contract. This essay is the why.