# Review brief: temporary static sites

You are an independent second reader of a design spec for the CARLOS
platform (this repository). Read cold and adversarially.

**Spec:** `docs/superpowers/specs/2026-09-25-temporary-static-sites-design.md`
at the commit named in the prompt.

## Fixed rulings, do not re-argue

§1 of the spec lists the rulings the product owner has taken. Do not
propose alternatives to them. Report only mechanisms that **fail to
honour** a ruling, or that break something else in the platform.

## What to check

Verify against the code, not the spec's description of it. Cite
`file:line` for every claim about existing code. The places that matter:

- `internal/release/trash.go` (tombstone, `TrashCooloff`, `PurgeApp`,
  `PurgeReady`), `internal/release/production.go` (signed flag envelope).
- `internal/domains/reconcile.go` (trash listing 1a, route drop 1c,
  auto-purge 1d, platform/canary minting).
- `internal/host/housekeeper.go`, `internal/host/agent.go` (which boxes
  run the domains reconcile, and whether they hold bucket write).
- `internal/console/apicli.go` (`handleAPITrashApp`,
  `handleAPIRestoreApp`), `internal/console/domainattach.go`,
  `internal/console/apiinstances.go`, `internal/console/authcli.go`.
- `internal/console/store.go` (apps table, `CreateAppIn`, trash rows), `internal/console/materialize.go`, `internal/console/ownership.go`, `internal/console/server.go` (`claimApp`), `accounts.go` (migrate).
- `deploy.go` (`runDeploy`, `mintPlatformHost`, `deployTargets`,
  ship-then-promote order), `apps.go`, `retention.go`.

Questions worth your time:

1. Can a real, permanent site end up expired, or purged on the 3-day
   window? Look for any path: races, restore, keep, the brand-new
   checks, legacy unqualified keys, apps with object stores, apps
   created by `carlos instances create` rather than deploy.
2. Can a temporary app escape expiry or the cap (keep races, restore
   loops, manual trash, `apps ttl` bounds, renaming, the listing)?
3. Does the fail-safe table in §2 hold at every consumer, including
   boxes running old code and keyless boxes?
4. Does the spec's claim that only the housekeeper writes the trash
   marker on expiry match how reconcile is actually scheduled? What
   bucket authority does that box have?
5. Ordering: expiry-record-first creation, restore's rewrite-then-
   untrash, and purge's re-read. Any window left?
6. Anything the spec relies on that does not exist, or exists with a
   different shape.

## Output

A numbered list of findings, each with: severity (P1 breaks a ruling or
loses data, P2 wrong behaviour, P3 clarity/gap), the spec section, the
code evidence with `file:line`, and a concrete fix. Then a one-line
verdict: accept, or revise. Do not rewrite the spec. No praise.

On a later round you will be given your earlier findings files. Start
with a disposition table (finding → fixed / declined-with-reason
acceptable / not fixed), then only new findings.