carlos / platform Public

spec: draft 3 — close review 2

Three blockers. One of them is mine to own.

The consent chain had a door straight through it. The landed sweep
refuses to read tenant bytes without the member's attestation, skips
stores attested client-encrypted, and scan grant refuses without a
request — on the stated ground that an operator must not start reading
someone's objects on their own. Draft 2's enqueue checked only the
deployment switch, so an app's own credential could make the console
fetch and scan a store that was never requested or was attested
encrypted. Enqueue AND drain now enforce all four conditions, the drain
because the record can change between the two and the drain is where
bytes are actually read.

The upgrade would have silently stopped scanning. The pass reads a
record that exists on no current deployment, and CARLOS_CLAMD_SOCKET was
renamed underneath operators. That is exactly the failure main.go
already refuses to permit. Boot now fatals when the retired variable is
set, naming its replacement and the enable command — the fatal IS the
migration, since nobody upgrades past it by accident. The record is not
auto-seeded: silently enabling a control that reads tenant bytes during
an upgrade is the wrong default.

The queue index had a stranding race with no removal rule stated: drain
lists empty, enqueue writes, enqueue marks, drain unmarks, item
invisible. Now a generation counter under a mutex, object written before
the mark, removal only if the generation is unchanged — and the boot
rebuild collects stranded and expired items, which makes it load-bearing
rather than an optimisation. Draft 2's claim that losing the index
"costs latency, never items" was also wrong twice over: the fallback
sweep is 24h not hourly, and the lost thing is the callback.

Smaller corrections: two mint doors exist, so the account-scope refusal
goes in NewServicePrincipal where neither can forget it; Allow() admits
Admin by construction, so the isolation property is scoped to role
Service and says so; the Scanner interface needs a Status method because
scanS3API is the scanner's private seam and the door only holds a
Scanner; the webhook key CAN be delivered like a store credential —
what cannot be reused is keeping nothing, since the console must sign
later — and rotation needs a two-master window or every app breaks
between the console rotating and its own re-seal.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>