The problem

Soft-delete logic often drifts across models, query scopes, and external services. This leads to deleted-record leaks in APIs, broken uniqueness constraints, orphaned child records, and stale data in search indexes or caches.

What it does

• Analyzes repository files to identify visibility leaks where soft-deleted records are accidentally exposed.
• Repairs restore logic by adding preflight collision checks and dependency restoration plans.
• Fixes search and cache projection drift by implementing versioned, idempotent event handling.
• Secures external object storage by adding visibility gates to download paths.
• Standardizes purge workflows using a state machine that separates intent, cleanup, and finalization.

Frameworks & tools

Works with any repository containing models, ORM schemas (Prisma, Django, TypeORM, etc.), API routes, and background workers.

Why this beats prompting it yourself

General prompting often misses the deep edge cases of soft deletion like identifier reuse and parent-child visibility inheritance. This skill traces the entire lifecycle across database, API, and infra layers to ensure a consistent contract rather than just applying a simple query filter.

Use cases

• Fixing API endpoints that still return deleted records via direct-ID lookups.
• Preventing uniqueness collisions when recreating a record with a deleted slug or email.
• Synchronizing search indexes and Redis caches when records are deleted or restored.
• Building safe purge jobs that respect legal holds and verify storage cleanup before database commits.

Known limitations

Does not access production databases or real customer data. It cannot define your legal retention policies or verify deletion completeness in backups and logs.