# Review brief: console release defences

You are reviewing `docs/superpowers/specs/2026-10-06-console-release-defences-design.md`
on branch `design-console-release-defences` in the carlos/platform repo, at the
commit named in the prompt. Read the spec, then read the code it cites:

- `internal/release/adopt.go`, `adoptHost`: the restart-failure rollback
  branch, `poisoned`, `ensureStaged`, `PointLive`, `stageBlocked`, `BakeDir`,
  `WithStartUnit`.
- `internal/host/agent.go`: `makeRestartRoute`, `rootRestartRoute`,
  `systemctlTryRestartUnit`, `makeStartRoute`, the `-stage-only` verb and the
  stage-request relay, the fast converge loop.
- `internal/release/release.go`: `Manifest`, `Ship`.
- `cli.go` (the direct-bucket ship) and `internal/console/apicli.go` (the API
  ship door).
- `internal/release/bake.go`, `internal/release/signer.go`,
  `internal/registry/registry.go` (`Route.Unit`, `Route.Health`, `Route.Addr`).
- `internal/host/alertsink.go`.

## Fixed rulings (§1): do not re-argue them

Four defences (D1 rollback on a named unit that will not come up, D2 refuse
the wrong Go main package, D3 dev-proof requirement for the flagship console,
D4 process). No new AWS account. D1 and D2 on everywhere; D3 opt-in per
deployment with no per-promote bypass. Enforcement on the adopting box, not
the client. External uptime alerting is out of scope. The threat model is
mistakes, not a compromised key or bucket.

## What to look for

Report mechanisms that fail to honour those rulings or that break something
that works today. In particular:

1. Interleavings between the agent's fast loop, the root stage pass, the
   hourly root pass and the stage-request relay that defeat the refusal
   record, the proof wait or the settle check. Examples: a relay storm, a
   bounce loop, a refusal the agent cannot read, a proof minted for a build
   that is no longer live.
2. States in which D1 makes things worse than today, such as rolling back a
   healthy build, leaving the unit stopped, or fighting an operator's
   deliberate stop.
3. Ways today's exact failure still gets through: CLI binary as console,
   hand ship, promote with the root key.
4. Ways D3 blocks a recovery it should allow (rollback to a previously-run
   build, break glass) or allows a build it should block (different bytes
   under a proven version name).
5. Claims about the code that are wrong. Cite file:line.
6. Placeholders, contradictions, or requirements an implementer could read
   two ways.

A mechanism that is named, bounded and assigned to the plan is complete at
spec level; do not pull plan-level detail up into the spec.

## Output

Number each finding, give it a severity (P1 breaks a ruling or production,
P2 a real defect, P3 clarity), and cite the spec section and any code
file:line. End with a one-line verdict: accept, accept with fixes, or reject.