Next privacy erasure slice: a reviewed inventory plan
This is a source map and implementation proposal, not an erasure receipt. Privacy case004 still refuses completion without verified execution; artifact006 covers only its declared export collections. Neither deleting a profile nor preparing an export establishes complete erasure.
| Source in the migrated repository | Ownership predicate | Proposed first-slice handling |
|---|---|---|
addresses, carts, favorites, search_history | user_id = case.user_id | Freeze identifiers/counts for a separately reviewed deletion plan after retention classification |
chat_sessions, chat_messages | Session user_id; message session_id joins that session | Inventory personal assistant conversations together, including attachment references; inspect retention before approving deletion |
user_sessions | user_id | Inventory personal device/IP metadata; auth session revocation requires a separate verified system step |
storage.objects | Verified owner_id or legacy owner, exact bucket/name | Inventory bytes and ownership; deletion must use the Storage API with per-object outcomes, never deleting metadata rows alone |
profiles, user_private_info, auth.users | Subject UUID | Preserve until reviewed field-level deidentification and auth/session/provider plans exist; deleting these can cascade or unlink other evidence |
orders, payments, transactions, payout_requests, checkout/transfer intents, bank/virtual-account records | Buyer/vendor/account ownership, shared commercial context | Exclude from the initial deletion plan; financial retention and provider obligations require explicit reviewed treatment |
messages, conversations, support_tickets, support_messages, disputes, reports/reviews | Sender, recipient, ticket owner and counterpart relationships | Inventory separately; shared counterpart data, support attachments and possible legal evidence prevent blanket subject deletion |
| Audit logs, reviewed proposals, moderation histories/appeals, privacy receipts/artifacts | Actor/subject identifiers and immutable evidence | Retain under explicit audit/hold policy; no cascading deletion or rewriting immutable receipts |
| Notification inbox/delivery/outbox and external providers/backups | Recipient or external identity | Separate system tasks and retention rules; callbacks/workers must not recreate erased content after a completed step |
Repository anchors are the canonical remote schema table/FK definitions, case governance004, support attachment012 and outbox001 ownership checks, and export artifact006. storage.objects ownership compatibility is already handled with coalesce(nullif(to_jsonb(o)->>'owner_id',''),to_jsonb(o)->>'owner') in support attachment verification. A stored URL alone does not prove ownership or deletion.
The next implementable command is prepare an erasure inventory plan, with no deletion effect. It should lock current global canManageUsers authority, assignment, verified identity, request type, case revision and absence of holds. Freeze the complete scoped identifier/count manifest, actual schema/bucket availability, collection policy decision, current storage ownership and exclusions. Missing schema or an unclassified collection remains unavailable and blocks execution approval. Bind independent approval to a SHA-256 manifest and revision; changed ownership, hold or counts requires re-preparation.
A later bounded worker can execute only reviewed low-retention tasks with leases, fencing, retry-safe per-item outcomes, immutable receipts and verified post-delete counts. Shared/financial/audit records and legal holds remain excluded. Auth revocation, provider copies, storage bytes, backups and outstanding workers need their own evidence. Until every owned system has an explicit retained/deleted outcome and required evidence, the privacy case stays in progress.