carlos / platform Public

console, provision: the private-storage policy, and the create door that spends it (issue #412)

`Manifest.PrivateStorage` is the app's standing declaration that every
instance it creates gets a config environment of its own and an object
store bound to that environment. Written by the person-only enable door;
spent by the create door, which an `instance`-role service credential
already reaches. That split is the feature: a public signup path
provisions a tenant's own bucket without ever holding the power to
create one.

A plain bool, not a pointer, unlike Record's Hibernate and StatusNamed.
Their reason is convergence — a box re-reads them every pass, so absent
has to differ from an explicit false — and it does not apply to a field
read at one door at create time whose false IS the legacy behaviour.
Pinned by a test that parses the bytes an older console wrote.

The create door, in order: derive the environment from the host's first
label (an explicit one in the request wins, and still gets a store —
the policy fills a blank, it does not seize the axis), refuse the three
names that cannot carry a store, check the ceiling, run the walk, and
only then write the record.

THE STORE IS PROVISIONED BEFORE THE RECORD. Record-first leaves an
instance whose bundle has no coordinates: it wakes onto local disk,
silently, with no verb to repair it. Store-first leaves a store no
instance is bound to, which `store status` lists and which a retry of
the same host reuses exactly, because the environment came from the
host and GrantIn is idempotent. One window stays open and is logged in
those words rather than papered over — the sibling-apex undo withdraws
a record whose store survives it, and tearing that bucket down from a
path nobody drove would make this the platform's first automatic
destroyer of tenant data (#408 §3 rules it out).

Not a second implementation of provisioning: the same lock, seal key,
timeout, entitlement re-read and GrantSourceAccountApproval the store
door uses. The env prefix is inherited from the app's own store, so an
app reading JELLY_S3_* does not get a second vocabulary for one thing.

CARLOS_STORE_MAX_PER_APP (default 100) caps environment stores per app,
because a bucket plus an IAM user per instance is a bigger footprint
than an instance and IAM's limits are per cloud account. Enforced on
the MANUAL store door too — a ceiling only the automatic path respected
would be one anyone could step over by hand — and re-using an
environment that already has a store is never capped, or a retry would
be refused by the ceiling it had just reached.

The enable door refuses to declare a policy it knows cannot be
honoured: no object-storage backend, or an unapproved account. That
departs from its habit of writing whatever policy it is handed, and
deliberately — a manifest that guarantees every future create fails is
a trap that fires once per signup, in a door whose caller is a machine.
Turning the policy OFF is never refused, so an account whose
entitlement was later declined can get its create door working again
without an operator.

The IAM-ceiling guard's test is watched to fail: with the check removed
the caller gets a 502 they cannot act on instead of a 400 naming the
part to shorten. Its arithmetic (body 55, bucket 55 and legal,
principal 68 and refused) is encoded so the guard cannot quietly become
dead code — under any prefix longer than "carlos-store-" the bucket
refusal always fires first.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>