Map every delete operation in my app and trace what it actually removes, including cascades through foreign keys, ORM lifecycle hooks, and application-level 'also delete the related stuff' code. Build the delete graph: when a user is deleted, what goes with them (posts, comments, orders, files, team memberships)? When a project is deleted, what follows? For each cascade, decide deliberately whether it's right: content the user owns should probably go or be anonymized; financial records and audit trails must survive in anonymized form; shared resources (a team, a document others collaborate on) must not die because one member left. Flag the dangerous patterns: cascades deeper than two levels (deleting a team that deletes projects that delete orders), bulk delete endpoints with no confirmation or limit, and ORM hooks that delete related records invisibly to the calling code. Don't change the delete behavior yet where it's ambiguous; present the graph and let me decide the policy per relationship, then apply it. Do add safeguards immediately where a cascade could clearly destroy unrelated users' data. Deliver: the delete graph per entity, the policy decision per relationship, the safeguards added, and verification: delete a test entity and enumerate exactly what was removed, confirming it matches the policy.