Pimp My IDE / garage dispatch
Back to garage
September 29, 2026 | release engineering / change health

Inconclusive is a real verdict.

A deploy monitor should compare the candidate with a live control. It should also refuse a green light when the signals cannot support one.

Wire the witness panelRead the source log

Put "I don't know" on the dashboard.

Cursor's new Rollouts bot watches each change as it reaches an environment. It reports one of three states: verified healthy, regression detected, or inconclusive. Before deployment, it writes a monitoring plan that names expected effects, risks, signals, and instrumentation gaps. A person can edit that plan in the pull request.[1]

The useful design choice is not the bot. It is the third state. Missing telemetry, quiet traffic, and a short observation window do not become healthy because no alert fired.

No alarm is an observation. It is not a verdict.

Compare the candidate with what users already have.

Google's Site Reliability Engineering workbook defines a canary as a partial, time-limited deployment plus an evaluation. The changed population is the canary. The unchanged population is the control. The release process needs a way to route a subset of traffic, judge the change, and use that judgment in the rollout.[2]

A dashboard that shows only the candidate loses the comparison. Traffic mix, dependency behavior, and ordinary demand can move both populations. Keep the control on the same panel. Name the revision, environment, population, window, and signals before reading the result.

Separate evidence from permission.

Cursor says Rollouts can open a revert pull request or hand a finding to another agent, depending on configuration. It does not merge or roll back by itself today.[1] That boundary is sound. A health judgment and permission to change production are different records.

GitHub environments make the same separation available in the deployment path. Protection rules can require a reviewer, add a wait timer, restrict branches, or ask an external system for a decision. Environment secrets remain unavailable until required approval is complete.[3]

Write the observation window before the release.

A monitor needs time to see the behavior it claims to judge. The right window depends on traffic, delayed work, cache cycles, and the failure being watched. One fixed number cannot cover every service.

Write the expected effect, control population, signals, minimum observation window, and rollback owner in the pull request. If any field is missing, keep the verdict inconclusive. If the evidence points to harm, stop expansion and hand the exact revision and signal to the rollback owner.

Interactive makeover / comparison bus

Rollout witness panel

Traditional purpose replaced: one deployment status badge. Better version: keep the control and candidate on one bus, select the evidence fields, then check whether the chosen verdict is supported.

Build the decision record

The bars are a diagram, not live telemetry. The native controls own every state shown below.

ControlLIVE BASELINE
CandidateNEW REVISION
Compare in one environment
Evidence fields included
Proposed rollout verdict
Verdict checkInconclusive is supported.Three evidence fields remain open.
Copyable release packet

Keep the unknowns visible

This panel drafts a review packet. It does not inspect logs, measure a canary, approve a deployment, or execute a rollback.

What this panel proves. The template keeps evidence fields, a proposed verdict, and deployment authority separate. Real health still needs measured candidate and control data from the named environment.

Sources and limits

Open the source log
  1. Cursor changelog, "Rollouts and Security Review," September 23, 2026, read September 29, 2026. Cursor documents per-environment monitoring plans, the healthy/regression/inconclusive verdicts, telemetry connections, and its current rule that the bot does not merge or roll back on its own.
  2. Google SRE Workbook, "Canarying Releases", read September 29, 2026. The chapter defines a canary as a partial, time-limited deployment plus evaluation, with the unchanged service acting as the control. It also describes the routing, evaluation, and release integration needed for a canary process.
  3. GitHub Docs, "Deployments and environments", read September 29, 2026. GitHub documents required reviewers, wait timers, branch restrictions, external protection rules, and the release of environment secrets after approval.

Source boundary. Cursor describes one commercial monitoring product. Google describes general canary practice. GitHub documents deployment gates. None claims that this static panel measures release health. The panel is a copyable decision-record pattern. Test signal quality, comparison logic, stop behavior, and rollback on the service you operate.