0050. The deploy guard holds by rules, detects through the gate endpoints, and rolls back by approval

Status: accepted, 2026-10-30

Context

The owner decided on a deploy guard: an AI review before production, a regression watch after with errors and analytics signals, and a rollback on evidence through an approval. apps already refuses a release that doesn't come up healthy and falls back to the last live one, but a release that starts and then answers 5xx, slows down or throws new errors stays live until someone looks, often from a phone, after deploying with a push. The signals exist in separate places (the nodes' request counts in analytics, errors by release, monitors, SLOs). The approvals design left open how the guard's rollbacks are approved; the observability design left the error-budget policy to this guard.

Decision

The service that owns releases runs the guard: apps for apps, pages for aliases, under per-environment settings in id beside the environment's approvals (watch: off, notify or ask; review: off, advise or hold; which findings hold; the error-budget gate).
Rules hold. Before production, deterministic checks over the change (variables it reads that the environment lacks, committed credentials, migrations, build and port changes, major dependency bumps) can hold a deploy: an automatic one waits for an approval the service asks for on its own behalf, a person's deploy shows them and needs an explicit confirmation. An AI note (with the team's consent to send code) explains the risk; it holds only where an environment says so, and then only adds a person's confirmation, never acts or removes one.
Rules detect, where the data is. For a window after a release goes live, the service asks the gate endpoints of analytics, errors and status that the autopilot uses (0043), for its own resource and with a more sensitive release profile, to compare it with the hour before on 5xx share, p95 latency, new and spiking errors, 404s (pages), monitors and SLO burn, with minimum samples; restarts are its own. A regression is a keyed alert with its numbers.
Rollback is an approval. The service asks id, on its own behalf, to roll back to the release before (approvers: the team's admins; confirm, a passkey in strict environments; at most an hour; bound to the regressed release so a newer one cancels it). It asks at once only for critical signals under ask, never at once when the release changed the database schema, and nothing rolls back without that approval.
An exhausted error budget holds automatic deploys into the environment through the same approval.

Consequences

Answers the approvals design's open point (the guard's rollbacks) and the observability design's (the error budget): both are approvals a service asks for itself.
The gate endpoints take apps' and pages' service tokens for their teams' resources, with the release profile beside the autopilot's own; git gains a bounded compare of two commits with patches (not a code browser).
Platform releases stay the autopilot's; the guard is for apps' releases and pages' deploys.
Low-traffic apps are judged on restarts, errors and monitors only; the ratios need samples.
Rolling back without any approval stays out until the guard's record shows its evidence is reliable.
Design: superpowers/specs/2026-10-30-assistant-design.md in this repository.