carlos / platform Public

Questions ranked by importance, referring to the design at the reviewed commit:

1. What enforcement is permitted when an account exceeds awake hours but never becomes idle? (§§3, 5.2, 5.7) Shortening the idle window cannot stop frequent HTTP requests, streaming responses or an existing WebSocket: the idle check requires no requests in flight and enough inactivity. Refusing new WebSocket upgrades does not close existing connections. The plan needs a permitted action that satisfies the required never-sleep abuse guard; the stated action does not.

1. How must the universal grace decision apply to creation refusals and reductions in memory/CPU limits? (§§3, 5.1, 5.3, 6) Section 3 requires grace for every cap, but §5.1 refuses creation immediately and §5.3 explicitly excludes grace. In particular, lowering an existing app’s memory limit after a lapse can kill it immediately. The answer changes admission rules and whether resource-limit reductions require a delayed transition.

1. Are sidecars intentionally exempt from “counting everything that runs,” and what bounds their number on paid accounts? (§§3, 5.1, 8.3) Section 5.1 excludes sidecars from the running-things cap and specifies a separate bound only for free accounts. Consequently, the advertised 200 ceiling does not bound paid workers. The answer determines whether worker creation consumes slots or needs another effective limit.

1. What counts as fair notice having reached owners, and can a hard ceiling take effect before that happens? (§§6, 12) The design withholds after-grace enforcement where owners could only have been reached by email, but does not define whether rendering a banner, returning a CLI warning or explicit acknowledgement establishes receipt. An unattended account might receive none of these before reaching 2× usage. This determines the notice state to record, when enforcement becomes eligible, and whether hard ceilings override that eligibility.

1. What is the storage allowance’s unit: account pool, logical app across all instances, or individual instance? (§§4.2, 5.4) The table calls the pack an account pool; §5.4 instead adds its increment to every app. Furthermore, the cited data directory is per host, and an app can have instances on multiple boxes. One shared app allowance needs allocation across boxes; one allowance per instance multiplies the storage sold. This must be settled before choosing the quota mechanism.

1. What availability and disk-safety guarantees apply on existing boxes without kernel quotas? (§§2, 5.4, 6) Refusing future wakes stops reads once an app sleeps, contrary to “reads keep working” and “apps keep serving.” It also does not stop an already-awake app filling the disk. Is that degraded protection an accepted launch condition, or must existing boxes gain quotas before enforcement starts? The answer changes rollout prerequisites and whether stopping an active app is permitted.

1. What happens to existing paid-only features after a downgrade? (§§4.2, 5.1, 5.2, 8.4, 9.2) Examples include attached custom domains, customer fleets and one-minute schedules. Section 9.2 applies ordinary cap grace, but these features have no defined after-grace transition. Grandfathering existing configurations, disabling them and rejecting only subsequent changes produce different reconciliation work and different availability outcomes.

1. How does “one free account per person” apply to ownership changes and paid accounts that lapse? (§§8.1, 9.2) A person can own several paid accounts, all of which must become free when subscriptions end. Checking only mintAccount cannot enforce the ownership rule after those transitions or after someone becomes an owner of another free account. The plan needs the policy for these cases without deleting data or automatically charging.

1. How is sponsored “current usage” measured for recurring limits, and does it override the stated hard ceilings? (§§4.2, 8.7, 12) Counts and stored bytes can be captured at switch-on; email, bandwidth and awake hours need a reference period. Month-to-date usage can understate an unchanged account’s normal monthly needs. Existing usage might also exceed an operator-only ceiling. The answer determines the enrollment measurements and which limits can be assigned automatically.

Separately, these code references would mislead a builder:

• §5.1 — provision.CreateRecord is not a common instance-creation enforcement point. In apiinstances.go:1658, claims-mode creation uses finishClaimCreate and bypasses it. A guard placed only in CreateRecord misses that path.
• §5.6 — the existing email mechanism is per sender, not per account. mailcounts.go:253 reads one sender’s counts and persisted grant. mailBillingTier is used when creating that grant. Replacing its answer alone neither establishes an account-wide cap nor updates existing grants.
• §9.4 — the harvested house flag does not by itself cover sponsorship. At 165472b8, internal/console/entitlementstore.go:219–220 returns without publishing an entitlement when no subscription exists. Sponsoring existing accounts before checkout requires an additional subscription-independent assignment path.