feat: 添加账号删除功能

docs/protocols/profile/profile-protocol.md

@@ -1,6 +1,6 @@
 # Profile Protocol (Frontend <-> Backend)
 
-This document defines the canonical backend contract for user profile read/write and avatar upload signing.
+This document defines the canonical backend contract for user profile read/write, avatar upload signing, and account hard deletion.
 
 Protocol verification status:
 
@@ -9,7 +9,7 @@ Protocol verification status:
 - Backend service source: `backend/src/v1/users/service.py`
 - Frontend mapping source: `apps/lib/features/settings/data/apis/profile_api.dart`
 - Storage config source: `backend/src/core/config/settings.py`
-- Current status: aligned
+- Current status: profile/avatar aligned; account deletion backend implemented (frontend wiring pending)
 
 ## Compatibility strategy
 
@@ -23,6 +23,7 @@ Protocol verification status:
 - Update settings: `PATCH /api/v1/users/me/settings`
 - Create avatar upload url: `POST /api/v1/users/me/avatar/upload-url`
 - Upload avatar directly: `POST /api/v1/users/me/avatar` (multipart)
+- Delete account and personal data (hard delete): `DELETE /api/v1/users/me`
 
 ## Auth and trust boundary
 
@@ -179,3 +180,57 @@ Behavior:
 
 - All errors must follow RFC7807 `application/problem+json`.
 - `code` values must be registered in `docs/protocols/common/http-error-codes.md`.
+
+## Account hard deletion contract
+
+### `DELETE /api/v1/users/me`
+
+Purpose:
+
+- Permanently delete the current account and associated personal data from developer records.
+- This is hard delete behavior, not soft delete and not temporary deactivation.
+
+Request:
+
+- No request body.
+- Auth required (same JWT trust boundary as other `/users/me/*` routes).
+
+Success response:
+
+- `204 No Content`
+
+Behavior contract:
+
+1. Deletion target is always the authenticated user (`sub`), never a client-supplied `user_id`.
+2. Deletion must remove account identity and associated user data for this product scope.
+3. Deletion must be irreversible from client perspective.
+4. After successful deletion, existing local session must be treated as invalid by client and backend.
+
+### Deletion scope (current product contract)
+
+The delete operation must remove data owned by the authenticated user in the following domains:
+
+- Identity: `auth.users` row for current user.
+- Profile: `profiles` row.
+- Points: `user_points`, `points_ledger` rows linked to user.
+- Chat: `sessions`, `messages` rows linked to user/session ownership.
+- Avatar storage objects under prefix `avatars/{user_id}/`.
+
+Notes:
+
+- If future legal/compliance requirements introduce mandatory retention, retained fields must be explicitly documented and user-visible in deletion UI copy.
+- This protocol version assumes no regulated retention exemption for current product scope.
+
+### Error semantics
+
+The route follows common RFC7807 error payload and registry codes. Expected HTTP classes:
+
+- `401` when auth is missing/invalid.
+- `403` when auth context is valid but action is not permitted by policy.
+- `409` when server cannot complete deletion due to a conflict that requires user action.
+- `5xx` for unexpected server/upstream failure (must not fail silently).
+
+### Consistency and idempotency expectations
+
+- API behavior is request-idempotent at user intent level: once account is deleted, repeating the action should not recreate state and should not produce partial undeleted data.
+- Client should treat any post-deletion authenticated call failure as terminal session invalidation and force logout flow.