amadan
Console mutation classifier allows deletes under control/boxes/ and control/box-volumes/, which dev's new box-records bucket policy refuses Issue open
internal/hostops/mutation_classifier.go:58-59 (main 04819f9) lists control/boxes/ and control/box-volumes/ as storage families the console's gated store may delete from (deletes: true, "box identity records keyed by box", "box volume inventory keyed by enrollment").
The deployment bucket policy from infra/modules/deployment-buckets (deployment_box_records) refuses every delete there for every principal. Its BoxRecordsAreNeverDeleted statement denies s3:DeleteObject and s3:DeleteObjectVersion on control/boxes/*, control/box-volumes/*, control/box-enrollment/* and control/box-fences/*. Its BoxRecordsAreCreateOnly statement also requires If-None-Match on every put there. Dev got this policy on 2026-10-18 (carlosframework/platform-infrastructure#46, for the host-claim dev cohort-1 trial). The flagship applies the same module.
Today nothing calls a delete under these prefixes. I traced every writer for #46: boxid.Publish (internal/boxid/record.go:49), boxvolumes.Write (internal/boxvolumes/volumes.go:223) and the termination fence writer (internal/hostfence/termination.go:119). All of them create with If-None-Match: *, and none deletes. So nothing breaks yet. But the classifier says one thing and storage enforces the opposite, so any future console path that relies on the classifier entry (box retirement, stale-box cleanup) would get AccessDenied in production.
Suggested fix, for whoever owns the classifier: drop deletes: true from those two entries (records there are written once and kept), or record why the console needs deletes there and change the module policy deliberately. Ideally add a test that pins the classifier's delete-permitted families against the module's never-deleted prefixes.
Found while preparing the dev cohort-1 trial; runbook: branch claim-dev-cohort1-runbook, docs/superpowers/plans/2026-10-16-claim-activation-dev-cohort1.md.