Add self-serve data deletion and account deactivation with rolling 24h login block

[HunteRoi]

Summary

Implement self-serve data deletion and account deactivation flows with distinct semantics, soft-delete lifecycle handling, and a rolling 24-hour login block for deactivation.

Problem

The specification distinguishes two different user actions:

1. delete my data
2. deactivate my account

They are not the same operation.

The platform must support both while preserving:

• GDPR-oriented deletion semantics
• reactivation window behavior
• guild access consequences
• evidence retention rules
• account access restrictions after deactivation

Without this issue, account lifecycle behavior remains undefined in runtime code.

Why This Matters

This protects:

• compliance requirements
• clear user intent handling
• consistency between bot and web app behavior
• safe lifecycle management across all guilds using the platform

It is also foundational for future self-service web app functionality.

Required Behavior

1. Users can request data deletion.
2. Users can request account deactivation.
3. Data deletion and deactivation are treated as distinct actions.
4. Soft-delete behavior is applied first.
5. Hard delete occurs after the configured inactivity/grace window.
6. Deactivation blocks login for a rolling 24 hours.
7. Evidence retention requirements remain intact.
8. User-facing warnings explain guild-impact when data storage is stopped.

Semantics

Delete my data

• stored user data is soft-deleted
• user may start from scratch later
• login is not blocked solely because of data deletion
• guild consequences may apply if continued storage is required for participation

Deactivate my account

• account and associated data are soft-deleted
• login is blocked for rolling 24 hours
• account may be reactivated during the grace period
• hard delete occurs after the inactivity window if not reactivated

Acceptance Criteria

1. Delete-data and deactivate-account are exposed as distinct flows.
2. Data deletion does not automatically enforce the same login block as deactivation.
3. Deactivation enforces rolling 24h login block.
4. Soft-delete markers prevent normal retrieval by bot and web app.
5. Hard-delete window is respected after the grace period.
6. Required user warnings are shown before destructive actions.
7. Evidence retention remains preserved.

Suggested Implementation Targets

• backend API modules to be created
• prisma/schema.prisma
• src/services/PostgresDatabaseService.ts
• future auth/session middleware for web app

Suggested Technical Direction

Create explicit lifecycle fields or records that distinguish:

• data deletion request state
• account deactivation state
• soft-delete timestamp
• hard-delete eligibility timestamp
• reactivation metadata
• login-block-until timestamp

Do not overload one generic deletion flag for both user intents.

Validation

• unit test: delete-data marks data correctly without deactivation login block
• unit test: deactivate-account applies rolling 24h login block
• integration test: soft-deleted data is excluded from normal reads
• integration test: reactivation within grace period restores account access
• integration test: hard delete removes eligible data while preserving required evidence
• regression test: warnings and destructive flow confirmation are enforced

Traceability

• Spec: docs/specs/issue-93-specification.md
• Matrix rules:
  • TRC-020
  • TRC-023
• Related docs:
  • docs/specs/traceability-matrix.md
  • docs/specs/issue-drafts.md
  • docs/specs/non-mvp-roadmap.md

Related Issues

• Umbrella Epic - Feature List #93
• The admin should be able to configure the bot through a web interface for their guild #91
• Implement stale-write detection and superseded update deprecation for guild config #136