An account can own auth identity, profile data, cloud history, memory records, usage state, and other rows protected by row-level security. Deleting only the auth user can orphan records; deleting from the browser can be interrupted halfway.
The operation needs an authenticated server boundary, a known table inventory, and an order compatible with foreign keys. A success response should mean every required store completed.
What was actually going wrong
Client-side deletion assumed the signed-in user had permission to remove every dependent record and then its own auth identity.
What I tried
- Deleting only the profile row
- Clearing browser storage as if it were cloud deletion
- Issuing unrelated table deletes with no completion contract
A privileged deletion function verifies the caller, removes user-owned data in a defined sequence, and deletes the auth identity last.
Why it worked
One trusted operation can cross RLS boundaries intentionally and report partial failure instead of hiding it.
Complete deletion requires a data inventory before it requires a button.
Where EACI uses this today
Main account controls can request deletion across account history and associated service data.
This journal covers real engineering on EACI Companion / The Veil. Companions include Caelum, Chad, Natalia, Atreus, Luna, Roxy, and Cael. Journal articles stay family-safe in content. See Privacy and Ethics.