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.