Account Deletion

Product Contract

Account settings exposes Supprimer mon compte for an existing linked or anonymous account. An explicit irreversible confirmation is required. Cancelling does not send a deletion request. The catalogue remains usable after deletion.

This is not sign-out and is not the reversible deleted support status. Apple requires a way to initiate deletion in the app and removal of associated data unless retention is legally necessary. See Apple's account deletion guidance. Implementation and automated checks do not establish App Store approval or legal compliance; native iOS execution and the store review remain separate.

An active store subscription is not cancelled by erasing the Snag account. The confirmation explains that cancellation is managed separately in App Store or Google Play settings. Deletion must not force a purchase or subscription change.

API Contract

The current client sends authenticated POST /auth/account/delete with JSON {"confirmation":"DELETE","operationId":"<stable-random-id>","code":"<mailbox-code>"}. Linked accounts require a valid mailbox code; anonymous accounts omit it. The account comes from the bearer credential, never a submitted user ID or email. The UI additionally checks the displayed owner before submitting and requires typed SUPPRIMER confirmation. A successful erasure returns 204. The operator write token is not an account credential. Missing/invalid authorization, invalid confirmation and failed erasure must not be reported as success. The legacy DELETE /me/account endpoint remains available for already distributed clients.

Server erasure removes the live user record and its dependent personal records, including holdings, soft-deleted holdings, mutation receipts/history, sessions, credentials, plans/usage, shares, alerts, push registrations and profile metadata. Uploaded avatar file removal is part of erasure, not a best-effort success after leaving the file behind. The backend PR documents the exact transactional and filesystem failure behaviour and its verification evidence.

Device Cleanup

The mobile app serializes the request with ownership mutations and account changes, using the stored root credential so recovery does not depend on an already-erased access session. It does not clear credentials or private records before HTTP 204. A persisted secure operation ID survives a lost success reply; the backend retains a hashed retry receipt for seven days. An uncertain request freezes ordinary account use and can be resumed from Account settings. A later 401 alone is not treated as proof of erasure. Definitively rejected mailbox proofs leave the account usable.

After acknowledgement the app clears:

• Both native credential slots and the old plaintext account entry.
• The erased owner's holdings, activity/bin and migration/pending-operation copies.
• Device-local wishlist, binders, sales, catalogue favourites, scan-history records, manual valuations and nickname, which are not currently cloud-synchronized.
• Mounted private collection state via the existing account boundary.

The in-memory bulk-scan queue is also cleared. Queued ownership mutations and late sync responses cannot recreate the erased collection.

Other owners' explicitly scoped caches remain untouched. Device-level appearance, catalogue preferences and public catalogue cache remain. A non-secret pending cleanup marker lets interrupted local erasure be resumed before reading/adopting another account, including after a partial Keychain reset. Markers left by the previous shipped flow are migrated to this recovery path without resending a server deletion. The marker is removed after successful cleanup.

Boundaries And Release Checklist

• Apply the additive 0044_account_deletions.sql migration and deploy backend PR #507 before distributing mobile PR #742. Merging these PRs does not apply that migration or deploy the API. No user account is deleted by deployment or by the unit/integration checks.
• The current Maestro flow checks warning and cancellation by default. The full destructive path requires an anonymous disposable account and explicit ACCOUNT_DELETION_QA=DELETE_DISPOSABLE_ACCOUNT opt-in, never a real user.
• Existing OS-managed camera temporary files are not explicitly wiped by this JavaScript-only change. Scan-history references are removed. This is not a claim that every device cache or photo in the user's library has been wiped.
• Other installations cannot be remotely wiped. Their server sessions become unusable, but offline copies need a separately verified device cleanup policy.
• Operator/support audit trails, historical logs, scan-debug archives and backups need their own documented lawful retention and restoration procedure. Do not silently restore erased users from old backups. No automatic offsite backup policy or verified restore-time erasure replay is asserted here.
• The reversible admin support status still exists and must not be presented as this irreversible self-service flow. Staff-directed erasure is a distinct scope.
• This change does not add Sign in with Apple or other OAuth providers. Provider token revocation must be implemented if such providers are introduced later.