Reviewed privacy erasure inventory plans
Migration015 and PrivacyErasurePlanService prepare and independently review a declared inventory plan. They never delete data, revoke authentication, call storage or provider APIs, or mark a privacy case complete. An approved receipt is approved_plan_only, with executionAvailable:false and requestComplete:false.
Mount privacyErasurePlanRoutes under /admin/privacy-erasure-plans. The API provides a case preview, the latest 100 case plans, proposal creation and independent approval/rejection. Every command checks fresh global canManageUsers authority. Preview/proposal require an assigned, identity-verified erasure case in progress without a hold. Review checks the proposer’s current authority and case eligibility too; the reviewer must differ from the proposer.
One SQL statement inventories subject-owned addresses, carts, favorites, search history, assistant chat sessions/messages and user session metadata, plus storage objects whose current or legacy owner field matches the subject UUID. It returns whole counts and SHA-256 digests of canonical row contents, without personal field values, object names or signed URLs. Empty sources produce actual zero counts; a missing table or column refuses preparation. More than 10,000 combined rows or 10 MiB of source text refuses the inventory rather than returning a truncated success.
Storage byte totals are null if any owned object has unavailable or unsupported size metadata. Metadata ownership does not prove storage-byte deletion. The manifest explicitly retains financial orders/payments/ledger/payouts, immutable audit/approval/privacy evidence, shared support/dispute/message/moderation records, profile/auth/provider identities, notifications/workers, backups/external systems, and unclassified storage. Coverage stays incomplete until those systems have reviewed retention and execution evidence.
A proposal binds the displayed case revision, checksum, content digests, collection counts and exact reason. Approval recomputes the same manifest and refuses changed data, holds, assignment, identity, scope or permission grants. Reasons, manifest and final review receipts are immutable, and service-role direct writes/truncate are denied even under baseline default grants.
Verification is recorded by scripts/db-privacy-erasure-plan-checks.mjs and backend receipt tests. Representative SQL fixtures verify exact ownership counts, incomplete coverage, independent review without effects, content drift, missing sources, legal holds and proposer revocation. Native full-baseline execution remains a separate CI check; these tests do not establish hosted compatibility or completed erasure.