Temporary static sites

Status: rev 9, accepted by Astra round 9 (2026-09-25), approved by Paul 2026-09-26. Rulings in §1 are Paul's and are fixed. Revs 2-9 answer Astra rounds 1-8 (CODEX-FINDINGS-TEMPORARY-SITES-R{1..8}.md). §§10-17 disposition each finding; the text marks fixes (astra N), (astra 2.N) and so on.

0. Why

Two uses want a site that cleans itself up:

• an LLM scratchpad: an agent deploys a directory, looks at it, iterates, and walks away;
• a one-shot page for a customer: documentation, a proposal, a report that matters for a week.

Today both become permanent apps. Nothing expires them, there is no storage quota (only the 256 MiB per-ship cap, apiShipMaxBytes), and an agent in a loop can leave hundreds of apps behind. The opposite risk is as real: a real site marked temporary by mistake must never quietly vanish.

1. Rulings (fixed)

1. The unit is the whole app. Not a host on an existing app, not a release.
2. Expiry trashes; purge follows after a short window. At expiry the app goes to the Trash exactly as carlos apps delete would put it there (routes drop, apps restore works). A temporary app is purged 3 days after it was trashed, not 30.
3. Bounded while live. TTL defaults to 7 days, maximum 30. An account holds at most 20 live temporary apps; past that a new one is refused, never evicted.
4. carlos apps keep makes a temporary app permanent; carlos apps ttl moves its expiry.
5. Temporary apps get the platform host only. No custom domains.
6. Only a brand-new app can be made temporary.
7. Temporary apps live in a reserved tmp- namespace (Paul, 2026-09-25, after Astra round 6). Every temporary app is named tmp-<label>. Nothing permanent may be created under a tmp- name. A kept app keeps its tmp- name.
8. Temporary creates have their own budget of 50 per principal per day (Paul, 2026-09-26, raised while planning). It is separate from the permanent create budget of 10 a day (authcli.go:119), which would refuse a scratchpad agent at its 11th app. The live cap (20) bounds storage while apps are live. This budget bounds churn: a trashed temporary app holds storage for its 3-day window, so the worst case is about 150 trashed-but-unpurged apps per principal.

2. Where the state lives: the console, not the bucket

Rev 1 put a signed expiry.json in the bucket and had boxes act on it. Every P1 in round 1 traced back to that: a signed record that authorises destruction can be confused with another signed record (astra 1), replayed after it is revoked (astra 5), copied by migration (astra 10), deleted mid-purge (astra 9), and raced by writers that share no lock (astra 3, 4).

Rev 2 keeps the lifecycle in the console's apps table and makes the console the only actor that expires or early-purges anything.

• Boxes learn nothing new. They see a trash marker, drop routes, and their existing auto-purge still runs at 30 days (reconcile.go:226-238). For a temporary app that pass is a backstop the console normally beats by 27 days. No box code changes.
• Nothing in the bucket can make an app temporary, so bucket write access cannot shorten a permanent app's purge window, and there is no record to forge, replay or copy.
• All transitions serialise in one place: a per-app mutex in the console process plus conditional UPDATEs on the row (§5).
• Every transition settles first (astra 3.1, 3.3). Under the mutex, before acting, each door and pass calls s.settleApp, which reads the app's tombstone and brings the row into line with it: the one-app form of MaterializeApps, extended by §5 and §6. A crash between a bucket write and its row write is therefore repaired by the next thing that touches the app, not only at console start (materializeQuietly runs once, server.go:1278). After settling, the door re-reads the row and re-checks its own preconditions; a candidate list taken before the lock is only a hint.
• Absence is never evidence on its own (astra 4.1). Every branch below that reasons from a missing marker and missing objects to "the purge finished" and calls PurgeAppRow first requires the empty-bucket tripwire MaterializeApps already has (materialize.go:296, :388): a successful listing of apps/ that is not empty. An empty or failed listing means "no evidence"; the row is left exactly as it is and the pass logs the same warning materialize does. The tripwire is factored out of MaterializeApps into one helper that both use. The expiry pass runs it once per pass; a door runs it only if it reaches an absence branch.
• A tripped pass writes nothing it cannot justify (astra 5.2, 7.3). If the tripwire fails at the start of an expiry pass, the pass does no expiry trashes and no absence finalisation. It does still retry early purges, because PurgeAppIfTrashedAt acts only on the presence of a marker whose deleted_at matches the row's purge_for to the second: that match is evidence of the right bucket, and a wrong, empty bucket has no such marker (it gets ErrNotTrashed, which is an absence branch and waits). This matters when an early purge of a deployment's last app fails on its final marker delete: the marker is then the only key left, the tripwire trips on every pass, and without this exception nothing would retry it. When PurgeAppIfTrashedAt succeeds, the pass calls PurgeAppRow in the same step, so a successful purge never needs the absence branch to finish. Otherwise the pass's own trash markers would be the only thing in a wrong, empty bucket, and the next pass would read them as evidence the bucket is real. For the same reason the tripwire counts only keys that are not trash markers (deleted.json): markers are the one thing this feature writes into a bucket that holds nothing else. What is left is the corner MaterializeApps already accepts in its comment (materialize.go:311 onward): other writers, like a user's deploy, landing in the wrong bucket. This spec does not widen it.

This assumes one console per deployment bucket, which is how every deployment runs today. If the console is down, nothing expires and nothing early-purges; both fail toward keeping data.

New columns on apps (migration in store.go):

| Column | Meaning | |---|---| | expires_at INTEGER NOT NULL DEFAULT 0 | 0 = permanent. Unix seconds otherwise. | | restoring INTEGER NOT NULL DEFAULT 0 | 1 from just before a restore deletes the marker until the row is live again (§6). Counts against the cap. | | purge_after INTEGER NOT NULL DEFAULT 0 | 0 = no early purge. Set only when a temporary app is trashed. | | purge_for INTEGER NOT NULL DEFAULT 0 | The tombstone deleted_at (Unix seconds) that purge_after was computed from. |

purge_after and purge_for are fixed at trash time, from whether the app was temporary at that moment. Nothing later re-derives them.

3. Creation: a fresh claim, never an adoption

Temporary apps are created through a new route, POST /api/cli/apps/{account}/new-temporary {"name": "...", "ttl_seconds": N}, that shares handleAPICreateApp's body (apicli.go:359 onward) but not its request type. A separate route, not a field on /new, because /new's decoder accepts unknown fields (authcli.go:940): an older console would take temporary silently and create a permanent app. An older console answers the new route with 404, and the CLI stops there with nothing created (astra 2.7). The CLI also checks the response carries a non-zero expires_at before it ships.

The route takes no control_plane, place or build_probe; a temporary app is never the control plane (astra 2.8). On this route (astra 2):

• claimApp runs with ownerClaim = false regardless of role. An app name with any object under its prefix (and, for ops, the legacy prefix) is refused (server.go:3487 onward). Shipped-but-unpromoted releases count, because the check is "any key", not "any pointer". Together with the namespace and route checks below, this is the brand-new test: claimApp already checks the row, the apex hold and the prefixes.
• The name is in the tmp- namespace (ruling 7) (astra 6.1, 6.2). This is what makes "brand new" provable. Routes are tied to apps by name alone, the console cannot see hand-added routes on other boxes (apex.go:74), and reconcile can re-stamp a route with whichever account solely owns the name in the bucket (reconcile.go:723-735, before the trash drop at :189/:206). No inventory the console can read proves a name unused across the fleet. A reserved namespace makes the question unnecessary: no permanent app, row or route can hold a tmp- name, so a temporary app's expiry can only ever drop routes a temporary app created. The reservation is enforced at every door that creates a name without a temporary claim:

| Door | Refuses a tmp- name | |---|---| | claimApp (server.go:3460), so /new, the browser create form, and every other permanent claim | yes; /new-temporary is the only caller allowed through | | rename destination (appsettings.go) | yes | | carlos add (cli.go:198, box-local) | yes, for --app | | console grant <address> <app> → Store.Grant (cmd/console/main.go:124, store.go:522) | yes (astra 7.2) | | BackfillOpsMemberships (server.go:1285, store.go:661), which turns unclaimed grants into rows at start-up | skips a tmp- grant and logs it, never creates a permanent tmp- row (astra 7.2) | | carlos instances create and deploy's host minting | already require an existing row, which for tmp- is temporary |

Direct-mode ship (ops only, no claim) can still write under a tmp- prefix; the temporary claim then refuses that name because the prefix is not empty, which is the safe direction.

Rollout: enforcement first, then the scan, then the switch (astra 7.1). Boxes on older binaries do not know the reservation, and hand-added routes are visible only in each box's own registry. So the create route ships off, behind a console setting (CARLOS_TEMPORARY_APPS=1 in the console unit's environment), and the operator turns it on only after, in this order:

1. every box runs a platform binary that carries the reservation. carlos add is box-local and runs the box's own installed binary, so upgrading the box upgrades the writer; there is no second copy of it anywhere else; 2. every box's registry, and the console's apps and owners tables, show no tmp- name, and the result is recorded in the rollout discussion.

After that nothing that can write a route or a row accepts a tmp- name except /new-temporary. An operator deliberately running an old binary kept in /opt/carlos/versions by hand is outside what any platform guard can stop, and is not in scope. The scan is platform work below the API, which AGENTS.md's operate-via-API rule allows; no user ever runs it. The plan makes both steps release steps, not code.

• No routes for the name, on this console's registry (astra 5.1). Kept as a second check behind the namespace, not as the proof. An app can exist with no row and nothing in the bucket: a service added with carlos add over a TCP upstream (cli.go:198) is only routes. claimApp's apex check lets a route of the same account and app through (apex.go:92), and on expiry reconcile would drop every route of that account and app (reconcile.go:206), the real service's included. So the temporary route also refuses if the console's registry holds any route whose account (release.RouteAccount) and app match, platform apex included. It uses an account-scoped form of appHasRoutes (appsettings.go:711, which matches on app name alone). A registry that cannot be opened or listed refuses: "could not check" is not "no routes".
• The row is inserted with expires_at set, in the same INSERT that claims the name (CreateAppIn, store.go:1345, which is ON CONFLICT DO NOTHING). There is no moment where the row exists permanent, and a racing permanent create of the same name gets claimTaken.
• The cap is checked under the console's account-level lock before the insert: count rows in the account with expires_at > 0 and deleted_at = 0; refuse at 20. The refusal lists each with its expiry. Because the count and the insert are serialised in the console, the cap is exact (astra 6).

There is no door that sets expires_at on an existing row. apps ttl only moves a non-zero expires_at.

Rename refuses a temporary app (astra 2.1). The rename door (appsettings.go:785) checks that the source is unshipped, not that the destination prefix is empty, so a temporary row renamed onto a name with unclaimed releases would put those releases under expiry. Keep first, then rename.

Direct mode (ship straight to the bucket, ops only) skips claims today and cannot create a temporary app. That is fine: the feature is API-mode only.

4. Temporary apps stay static and platform-hosted (astra 7)

Enforced at the server mutation paths, not in the CLI, on any row with expires_at > 0:

| Path | Refuses | |---|---| | handleAPIShip (apicli.go:1530) | a manifest whose kind is not static | | handleAPIInstanceCreate (apiinstances.go) | kind other than static, and any host other than the platform host | | handleAPIDomainAttach and the console attach form (domainattach.go) | everything | | the object-store create door | everything | | the instances-manifest door, private_storage: true (apiinstances.go:1751) | everything (astra 2.6) | | the shared store-provisioning path instance create reaches (apiinstances.go:995) | everything, as a backstop to the row above | | email: carlos email domains add (apimail.go:1016), standalone credentials (apimail.go:1391), email enable | everything (astra 2.2) | | SetProduction(…, true) door | everything | | rename (appsettings.go) | everything (§3) | | move to another account, MoveApp (appsettings.go:1350, store.go:1705) | everything (astra 3.2) | | control-plane setter, handleAppControlPlaneSet → SetAppControlPlane(…, true) (controlplane.go:288) | everything (astra 3.5) |

The rule behind the table: a temporary row cannot change its name, its account, or its protection class. Each of those doors either points the row at bucket state it did not create (rename, move) or takes it out of automatic destruction's reach (production, control plane). The refusals are enforced in the shared store operation where one exists (RenameAppIn, MoveApp, SetAppControlPlane), not only in the handlers, and each checks under the per-app mutex.

Each refusal says carlos apps keep first. Keep lifts them all. The point of the store and email rows is that an automatic purge never meets backend estate it would need a person to tear down. Canary hosts for static apps (reconcile.go:318-340) still mint; they are platform hosts and go with the app.

carlos accounts migrate opens the registry and bucket directly (accounts.go:330, :346) and never sees a console row, so it would copy a temporary app as permanent. It is an ops-only verb run by hand, and that outcome (the copy outlives the original) errs toward keeping data. Accepted (astra 10).

5. The expiry pass and the early purge

A new console loop, expirypass.go, beside economicspass.go and scanpass.go, on a 5-minute ticker. Every transition below takes the per-app mutex that keep, ttl, restore, trash and the purge door also take, so a pass and a user command never interleave on one app (astra 3, 4).

Settle sweep (astra 8.1). Each pass first compares every temporary row (expires_at > 0) with the one apps/ listing it has already taken for the tripwire: a row whose trash state disagrees with the presence of its marker (live row with a marker, trashed row without one, or restoring = 1) gets settleApp under its mutex. This is what repairs a trash door that wrote the marker and then failed its row update (apicli.go:1247, :1279) while the expiry is still far off, without waiting for a console restart or a user touching the app. It costs no extra listing, and a GET only for rows that disagree. A tripped pass still runs the sweep's presence branch (a marker is evidence) and skips its absence branches, per §2.

Expire. The pass lists rows with 0 < expires_at <= now and deleted_at = 0 as candidates. For each, under the mutex:

1. settleApp, then re-read the row. Go on only if expires_at > 0 AND expires_at <= now AND deleted_at = 0 AND restoring = 0 still holds (astra 3.1): a keep that ran after the listing set expires_at = 0, which fails > 0.
2. Refuse, log and audit if the app is the control plane (controlPlaneRefusal) (astra 3.5). §4 makes this unreachable.
3. release.TrashApp(ctx, s, sqid, app, "expiry", now), then ReadAppTombstone (create-only: if a marker already existed, its clock stands, the same re-read handleAPITrashApp does).
4. In one statement, guarded by expires_at > 0 AND deleted_at = 0: deleted_at = tomb.DeletedAt, purge_for = tomb.DeletedAt, purge_after = tomb.DeletedAt + 3 days.

A failure at 3 writes nothing, and the next pass tries again. A failure at 4 leaves a marker and a live row. The mutex has not been released between 3 and 4, so no keep has run; the next door or pass to touch the app settles it (the marker wins, with the temporary window, per the materialize rule below). Keep and ttl settle first, so a keep after a failed step 4 finds the app in the Trash and is refused ("restore it first"), rather than succeeding on a row the bucket has already trashed. No in-progress flag is needed, which removes the round 3 problem of one surviving a restore (astra 3.3).

One deadline, everywhere (astra 4.2). A new effectivePurgeAt(row) returns purge_after when it is set and deleted_at + TrashCooloff otherwise. Every place that shows or returns a purge date uses it instead of computing DeletedAt + TrashCooloff itself:

• the Trash view's TrashedApps / PurgesAt (view.go:492) and the template's fixed "30 days" wording (trash.html:10, :21), which becomes the per-app date;
• the trash API's restorable_until (apicli.go:1295) and the CLI's "restorable until" line (apps.go:317) in API mode;
• the delete confirmation in the browser, and /list (§7).

The box's own 30-day auto-purge is not a displayed deadline and is unchanged.

Direct mode (astra 7.4). carlos apps delete in direct mode (apps.go:250, headlessTrash at :307) has no console row, so it cannot know whether the app is temporary, and the tmp- prefix does not say (kept apps keep it). It stops promising a window it cannot know (astra 8.2). The line is built from the marker's own deleted_at, which headlessTrash already re-reads (apps.go:298), so a retry never restarts the clock: "in the Trash since <T>. It is purged at <T+3d> if it is a temporary app, or <T+30d> if not; carlos apps list against the console shows which." A date already in the past is printed as "may be purged at any time" instead. Direct mode is ops-only.

Trash by hand. handleAPITrashApp and the browser door set purge_after/purge_for the same way when the row has expires_at > 0, and leave them 0 otherwise.

Materialize (astra 2.5). Where MaterializeApps marks a row trashed from a marker (materialize.go:367), a row with expires_at > 0 also gets purge_for = tomb.DeletedAt and purge_after = tomb.DeletedAt + 3 days, in the same statement. This is the recovery path when a trash door wrote the marker and failed the row update. The rule is the same one every door follows: the window is bound to the marker's clock and to whether the row was temporary when the marker was found.

Early purge. For each row with deleted_at > 0, purge_after > 0, purge_after <= now: call a new

release.PurgeAppIfTrashedAt(ctx, s, pub, sqid, app, wantDeletedAt, now)

which is PurgeApp plus one precondition: the current tombstone's DeletedAt, truncated to seconds, equals wantDeletedAt (the row's purge_for). A restore followed by a keep and a fresh trash writes a new tombstone with a new clock and a row with purge_after = 0, so the old decision can no longer fire (astra 4). PurgeReady's other guards (production flag, object-store estate) still apply. On success the row goes through the existing PurgeAppRow.

Before calling it, the pass refuses, logs and audits (leaving the app for a person at the console purge door) if:

• the app is the control plane (controlPlaneRefusal) (astra 2.8);
• it has any email estate, by the same test the purge door uses (mail.Get plus mailAppDomains, ownership.go:380-394) (astra 2.2).

§4 makes both impossible to reach; this is the backstop, and it never tears anything down on its own authority.

Because the decision lives in the row and not in a bucket object, an interrupted PurgeApp leaves purge_after in place and the next pass resumes it (astra 9).

ErrNotTrashed from the early purge does not mean "restored" (astra 2.4). PurgeApp deletes the marker last, so a finished purge whose PurgeAppRow failed, a 30-day box purge, a headless restore, and a §6 restore that crashed after deleting the marker all look the same at the marker. The pass tells them apart the way MaterializeApps already does (materialize.go:376): list the prefix.

• No objects, tripwire passes (§2): the purge finished. PurgeAppRow and stop. Tripwire fails: leave the row, log.
• Objects: the app was restored outside the pass. Finish a restore (§6 steps 2 and 5, no cap check since the bucket already serves it) and log it. If the row has restoring = 1 this is a console restore that crashed or failed at step 5, and its cap slot was already held (§6). If it has restoring = 0 it was a direct-mode restore, whose cap overrun §6 accepts.

6. Restore (astra 6, 8)

One helper, s.restoreApp, used by the CLI door (handleAPIRestoreApp), the browser door (ownership.go:251) and the §5 ErrNotTrashed catch-up. Under the per-app mutex, for a row with expires_at > 0:

1. settleApp. Cap check, as §3, counting this app as a new live one. Over the cap: refuse, nothing changes.
2. If expires_at < now + 1h: expires_at = now + 7 days. The row is still trashed, so this is harmless if what follows fails.
3. restoring = 1. From here the app holds a cap slot (astra 3.4).
4. release.RestoreApp (delete the tombstone).
5. One statement: deleted_at = 0, restoring = 0, purge_after = 0, purge_for = 0.

The cap counts rows with expires_at > 0 AND (deleted_at = 0 OR restoring = 1), so a restore that has deleted the marker but not reached step 5 still occupies its slot, and no new temporary app can take it.

settleApp resolves restoring = 1 wherever it finds it:

• marker present: step 4 failed. restoring = 0; the app stays in the Trash with its deadline intact (astra 2.3).
• marker absent, objects present: step 5 failed or crashed. Do step 5.
• marker absent, no objects: a box purge got there; PurgeAppRow, subject to the §2 tripwire.

Step 2 before 4 means the expiry pass never sees an untrashed row with a stale expiry. Headless carlos apps restore in direct mode writes only the bucket; the row catches up through the ErrNotTrashed path or the start-up materialize, and at that point gets step 2. It does not get the cap check. Direct mode is ops-only, and that overrun is accepted.

7. Commands

All user-facing strings go through copy review before they are written into code.

| Command | Does | |---|---| | carlos deploy --temporary [--ttl 3d] ./dir | Creates the app through /new-temporary (§3), then ships and promotes as today. --ttl alone implies --temporary. Default 7d, max 30d, min 1h. Without --app, the name is tmp- plus 6 random lowercase letters and digits, retried on claimTaken. With --app acme-docs the name is tmp-acme-docs (an --app already starting tmp- is used as given), and the CLI prints the final name before shipping. Refused locally with --host or --kind binary. | | carlos deploy to an existing temporary app | Ships and promotes. Expiry unchanged, printed. | | carlos deploy --temporary to an existing app | Refused: the create door says the name is taken. | | carlos apps ttl --app <a> 5d | expires_at = now + 5d, same bounds. Live temporary apps only. | | carlos apps keep --app <a> | expires_at = 0. Live apps only; settles first, so an app the bucket has already trashed is refused. | | carlos apps list [--account <a>] | New subcommand (astra 3.6). One line per app the caller can see, trashed ones included: name, live or trashed, and expires in 3d, purged in 2d or nothing. | | carlos apps delete on a temporary app | As today; the output says "purged in 3 days". |

API additions (authcli.go, svcrole.Publish like /new):

POST /api/cli/apps/{account}/new-temporary {"name": "...", "ttlseconds": N} POST /api/cli/apps/{account}/{app}/ttl {"ttlseconds": N} POST /api/cli/apps/{account}/{app}/keep GET /api/cli/apps/{account}/list

/list is new rather than a change to the accounts listing, whose apps field is a []string that clients decode as such (apicli.go:548, account_choose.go:27) and whose query hides trashed apps (store.go:1362). /list returns [{"app", "deleted_at", "expires_at", "purge_after"}] with times as RFC 3339 or null, includes trashed apps, and applies the same per-principal filtering the accounts listing applies to service principals (apicli.go just above 548). docs/site/cli.md gains the flags and both commands.

The console app page shows the expiry in the header with a Keep button (deploy rights; no passkey step, since keep only makes the app safer).

8. What this does not do

• No email warning before expiry. Tenant email senders are not merged. (Email provisioning exists and is refused on temporary apps, §4.)
• No byte cap across temporary apps. The storage pass could feed one.
• No temporary binary apps or instances.
• No change to how edge boxes clean their local static cache; that gap applies to every app and gets its own discussion.

9. Testing

• Store: migration adds the four columns with defaults; CreateAppIn with an expiry; conditional updates return zero rows when they lose.
• Namespace: /new, the browser form, rename and carlos add refuse tmp- names; /new-temporary refuses names without it.
• Create route: refuses a name with a route of the same account and app and no bucket objects or row (a carlos add service); refuses when the registry cannot be read; refuses a name with any key under its prefix, including a manifest with no channel pointer; owner role does not exempt it; cap refuses the 21st and is exact under concurrent creates; the CLI against a console without the route creates nothing.
• Server paths in §4 each refuse on a temporary row and pass after keep.
• Expiry pass, fake clock and a recording store: expire → trash → purge at 3 days; keep between candidate listing and lock acquisition (the pass must skip); failure at step 3 retries; failure at step 4 followed by a keep (keep refused, row settled trashed with the 3-day window); restore→keep→trash between decision and purge refuses via PurgeAppIfTrashedAt; interrupted purge resumes; ErrNotTrashed with an empty prefix finalises, with objects restores; control-plane and email-estate backstops refuse without tearing down.
• Materialize: a marker found for a temporary row sets the 3-day window from the marker's clock; for a permanent row, leaves it 0.
• Restore: rewrites expiry before deleting the tombstone and clears the deadline only after (order asserted); a failed tombstone delete keeps the deadline and releases restoring; a failed step 5 holds the cap slot until settled; cap enforced on every console restore door.
• settleApp: each marker/row/restoring combination.
• Empty bucket: start the console against an empty replacement bucket with one temporary row awaiting purge and one live but expired; run startup materialize and then several expiry passes; no marker is written, and both rows survive unchanged. The same with a bucket that holds only trash markers.
• Deadline display: a temporary and a permanent app trashed together; the Trash view, trash API, CLI output and /list each show 3 and 30 days respectively; direct-mode delete prints both dates from the marker, including on a retry two days in and after the 3-day date.
• Settle sweep: manual trash of a temporary app with 30 days left whose row update fails; with no restart and no user action, the next pass settles it and the early purge runs at 3 days.
• Early purge whose final marker delete fails, with no other keys in the bucket: the next pass trips the tripwire, still retries the purge, finishes, and removes the row.
• console grant refuses a tmp- name; backfill skips one already in owners; carlos add --app tmp-x refuses.
• The create route answers 404 until CARLOS_TEMPORARY_APPS=1.
• /list: trashed apps shown; the accounts listing's []string unchanged; service-principal filtering matches.
• Rename, move, control-plane, email, private storage and store doors refuse on a temporary row, at the store operation as well as the handler.
• Boxes: no change; an existing reconcile test confirms a trashed app with no row knowledge still purges at 30 days.
• CLI: --ttl implies --temporary; local refusals; generated name shape and retry.

10. Round 1 dispositions

| # | Finding | Disposition | |---|---|---| | 1 | Expiry signature validates as production-off | Fixed by §2: no signed bucket record | | 2 | Five checks miss shipped-unpromoted and legacy state | Fixed by §3: claimApp with ownerClaim=false, any key refuses | | 3 | Keep/ttl race the expiry | Fixed by §5: per-app mutex, conditional updates (rev 4 corrects the condition, astra 3.1) | | 4 | Purge re-read misses deadline | Fixed by §5: PurgeAppIfTrashedAt binds to purge_for | | 5 | Deleting expiry does not revoke it | Fixed by §2: no bucket record to replay | | 6 | Restore bypasses cap | Fixed by §6 for console doors; direct-mode restore accepted | | 7 | Static-only enforced only in CLI | Fixed by §4: server paths | | 8 | Browser and headless restore miss expiry | Fixed by §6: shared helper; headless catches up via §5 | | 9 | Interrupted purge falls back to 30 days | Fixed by §5: decision lives in the row | | 10 | Migration disables expiry | Fixed by §4: migrate refuses in API mode; direct mode accepted |

11. Round 2 dispositions

| # | Finding | Disposition | |---|---|---| | R1.4 | Box auto-purge checks an old tombstone's age, then purges unguarded | Declined here, filed separately. This race exists for every app today and this spec leaves the box path unchanged: a box only acts on a tombstone 30 days old, temporary or not. Guarding it (PurgeAppIfTrashedAt with the listed marker's clock) is a small, separate box change, filed as amadan discussion #182. | | R1.10 | Migrate has no API mode | Fixed: §4 now describes migrate as it is and accepts the outcome. | | 2.1 | Rename puts permanent data under expiry | Fixed: §3 and §4, rename refuses a temporary app | | 2.2 | Early purge skips mail teardown | Fixed: §4 refuses email on temporary apps; §5 backstop refuses to purge with email estate | | 2.3 | Failed restore cancels the 3-day window | Fixed: §6 clears the deadline only with the row restore | | 2.4 | ErrNotTrashed is not proof of restore | Fixed: §5 lists the prefix, as materialize does | | 2.5 | Materialize omits the window | Fixed: §5 materialize rule | | 2.6 | Instance manifest enables private storage | Fixed: §4 rows for the manifest door and the shared provisioning path | | 2.7 | Older console makes --temporary permanent | Fixed: §3 separate route; CLI checks expires_at | | 2.8 | Expiry bypasses control-plane protection | Fixed: §3 route takes no control_plane; §5 backstop |

12. Round 3 dispositions

| # | Finding | Disposition | |---|---|---| | 2.7 residue | §7 still said /new | Fixed: §7 names /new-temporary | | 3.1 | Expiry update matches a kept row (0 <= now) | Fixed: §5 re-checks expires_at > 0 under the mutex after settling | | 3.2 | Account move puts a permanent site under expiry | Fixed: §4 move refuses, at MoveApp | | 3.3 | expiring survives restore | Fixed: expiring removed; §2 settle-first rule covers the crash it guarded | | 3.4 | Failed restore frees a cap slot | Fixed: §6 restoring holds the slot until settled | | 3.5 | Control-plane setter on a temporary app | Fixed: §4 refuses; §5 re-checks before trash as well as purge | | 3.6 | apps list and the listing shape do not exist | Fixed: §7 new subcommand and /list endpoint; old contract unchanged |

13. Round 4 dispositions

| # | Finding | Disposition | |---|---|---| | 4.1 | Absence-based recovery skips the empty-bucket tripwire | Fixed: §2 absence rule, shared tripwire helper; §5 and §6 branches cite it | | 4.2 | Trash page and API promise 30 days | Fixed: §5 effectivePurgeAt used by every displayed deadline |

14. Round 5 dispositions

| # | Finding | Disposition | |---|---|---| | 5.1 | Route-only permanent service can be claimed temporary | Fixed: §3 refuses when any route of the account and app exists, or the registry cannot be read | | 5.2 | Expiry's own markers defeat the empty-bucket tripwire | Fixed: §2 a tripped pass writes nothing; the tripwire ignores trash markers |

15. Round 6 dispositions

| # | Finding | Disposition | |---|---|---| | 6.1 | Console registry misses routes on other boxes | Fixed by ruling 7: reserved tmp- namespace (§3); the registry check stays as a second line | | 6.2 | Reconcile can re-stamp a same-name route to the temporary app's account | Fixed by ruling 7: no permanent route can carry a tmp- name | | 5.1 residue | Route check incomplete | Superseded by ruling 7 |

16. Round 7 dispositions

| # | Finding | Disposition | |---|---|---| | 7.1 | Rollout scan gives no lasting protection against older writers | Fixed: §3 ships the route off; enable only after every box carries the reservation and the scan is clean | | 7.2 | Grant and backfill bypass the namespace | Fixed: §3 table, Store.Grant refuses, backfill skips | | 7.3 | Interrupted last-app purge cannot retry under the tripwire | Fixed: §2 early purge acts on marker presence, which is evidence, and still runs when tripped | | 7.4 | Direct-mode delete promises 30 days | Fixed: §5 direct-mode line no longer promises 30 days |

17. Round 8 dispositions

| # | Finding | Disposition | |---|---|---| | 8.1 | Failed manual-trash row update escapes both candidate queries | Fixed: §5 settle sweep over every temporary row against the pass's listing | | 8.2 | Direct-mode retry overpromises | Fixed: §5 dates from the marker's deleted_at, elapsed dates said as such |