carlos / platform Public

1. Important — Restore counts one slot but revives the app’s instances too. plancaps.go:100 With two running things and a limit of three, restoring an app with two retained instance records passes, then raises the count to five. runningThings correctly excludes those records while the app is trashed, but checkRestore adds only one. Both restore modes use this check. Fix: count the full restored footprint before changing anything; test this scenario in both claim modes.

1. Important — Concurrent requests can mint multiple free accounts. authcli.go:1778 Someone who owns only paid accounts can send two creation requests. Both can observe zero free accounts before either reaches mintAccount, so both succeed. The browser door has the same gap; the account allocator prevents duplicate IDs, not duplicate free allowances. Fix: serialize the check and mint by person across both doors. Coordinate auto-mint through the same mechanism while preserving its never-refuse behavior.

1. Important — Adopting an existing app undercounts its instances. apicli.go:455 An owner may adopt an app that already has bucket objects but no console row. Its instance records are excluded from runningThings because the app is outside liveSet. The new check reserves only one slot; inserting the app row makes all its instances count immediately. The browser door behaves identically. Fix: include existing instance records in the prospective count when adopting an app, under the account lock.

1. Important — Pending claim creates do not retain cap reservations. plancaps.go:73 Counting includes only materialized instance keys. A claims-mode create can return 202 after an uncertain record write, releasing planLock while its claim remains pending. Another create can consume the same final slot before the original write becomes visible. checkSidecars has the equivalent omission. Fix: count durable pending reservations alongside records, deduplicating by identity, and release reservations only after definitive cancellation. Test a delayed record write followed by another create.

1. Minor — The sponsored-limit test does not exercise the catalog ceiling. plancaps_test.go:117 The test sets a sponsored limit of 300 but creates only four apps. It would still pass if enforcement incorrectly clamped that limit to 200. Fix: use the planned count of 250 and assert both admission below 300 and refusal beyond it.

Declined to judge

• Refusal wording and settled policy decisions, as instructed.
• Direct-to-bucket enforcement: the implementation plan excludes it, although spec §5.1 requires coverage. This review does not certify that path as capped.
• Runtime test results and production-scale listing cost. Targeted tests could not start because the read-only sandbox prevented Go from creating its build directory. Census coverage and hashes matched on static inspection.

Verdict: Request changes. The creation caps have Important bypasses. HEAD remains 4681e4c3660cccd6fc0c3958a9691bc45dc82754; the working tree is unchanged.