| 1 | # Review brief: temporary static sites |
| 2 | |
| 3 | You are an independent second reader of a design spec for the CARLOS |
| 4 | platform (this repository). Read cold and adversarially. |
| 5 | |
| 6 | **Spec:** `docs/superpowers/specs/2026-09-25-temporary-static-sites-design.md` |
| 7 | at the commit named in the prompt. |
| 8 | |
| 9 | ## Fixed rulings, do not re-argue |
| 10 | |
| 11 | §1 of the spec lists the rulings the product owner has taken. Do not |
| 12 | propose alternatives to them. Report only mechanisms that **fail to |
| 13 | honour** a ruling, or that break something else in the platform. |
| 14 | |
| 15 | ## What to check |
| 16 | |
| 17 | Verify against the code, not the spec's description of it. Cite |
| 18 | `file:line` for every claim about existing code. The places that matter: |
| 19 | |
| 20 | - `internal/release/trash.go` (tombstone, `TrashCooloff`, `PurgeApp`, |
| 21 | `PurgeReady`), `internal/release/production.go` (signed flag envelope). |
| 22 | - `internal/domains/reconcile.go` (trash listing 1a, route drop 1c, |
| 23 | auto-purge 1d, platform/canary minting). |
| 24 | - `internal/host/housekeeper.go`, `internal/host/agent.go` (which boxes |
| 25 | run the domains reconcile, and whether they hold bucket write). |
| 26 | - `internal/console/apicli.go` (`handleAPITrashApp`, |
| 27 | `handleAPIRestoreApp`), `internal/console/domainattach.go`, |
| 28 | `internal/console/apiinstances.go`, `internal/console/authcli.go`. |
| 29 | - `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). |
| 30 | - `deploy.go` (`runDeploy`, `mintPlatformHost`, `deployTargets`, |
| 31 | ship-then-promote order), `apps.go`, `retention.go`. |
| 32 | |
| 33 | Questions worth your time: |
| 34 | |
| 35 | 1. Can a real, permanent site end up expired, or purged on the 3-day |
| 36 | window? Look for any path: races, restore, keep, the brand-new |
| 37 | checks, legacy unqualified keys, apps with object stores, apps |
| 38 | created by `carlos instances create` rather than deploy. |
| 39 | 2. Can a temporary app escape expiry or the cap (keep races, restore |
| 40 | loops, manual trash, `apps ttl` bounds, renaming, the listing)? |
| 41 | 3. Does the fail-safe table in §2 hold at every consumer, including |
| 42 | boxes running old code and keyless boxes? |
| 43 | 4. Does the spec's claim that only the housekeeper writes the trash |
| 44 | marker on expiry match how reconcile is actually scheduled? What |
| 45 | bucket authority does that box have? |
| 46 | 5. Ordering: expiry-record-first creation, restore's rewrite-then- |
| 47 | untrash, and purge's re-read. Any window left? |
| 48 | 6. Anything the spec relies on that does not exist, or exists with a |
| 49 | different shape. |
| 50 | |
| 51 | ## Output |
| 52 | |
| 53 | A numbered list of findings, each with: severity (P1 breaks a ruling or |
| 54 | loses data, P2 wrong behaviour, P3 clarity/gap), the spec section, the |
| 55 | code evidence with `file:line`, and a concrete fix. Then a one-line |
| 56 | verdict: accept, or revise. Do not rewrite the spec. No praise. |
| 57 | |
| 58 | On a later round you will be given your earlier findings files. Start |
| 59 | with a disposition table (finding → fixed / declined-with-reason |
| 60 | acceptable / not fixed), then only new findings. |
| 61 | |
amadan