eryao/docs/protocols/profile/profile-protocol.md

# Profile Protocol (Frontend <-> Backend)

This document defines the canonical backend contract for user profile read/write, avatar upload signing, and account hard deletion.

Protocol verification status:

- Backend route source: `backend/src/v1/users/router.py`
- Backend schema source: `backend/src/v1/users/schemas.py`
- 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: profile/avatar aligned; account deletion backend implemented (frontend wiring pending)

## Compatibility strategy

- Current strategy: additive evolution (`backward-compatible`).
- Breaking change requires explicit migration + rollback notes (`requires-migration`).

## Route overview

- Get profile: `GET /api/v1/users/me/profile`
- Update profile: `PATCH /api/v1/users/me/profile`
- 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

- All routes require authenticated user context.
- `user_id` is derived from verified JWT `sub`; never accepted from client payload.

## Profile read contract

### `GET /api/v1/users/me/profile`

Response:

```json
{
  "user_id": "uuid",
  "display_name": "string",
  "bio": "string|null",
  "avatar_path": "avatars/{user_id}/{file}",
  "avatar_url": "https://...signed-or-public...",
  "settings": {
    "version": 1,
    "preferences": {
      "interface_language": "zh-CN",
      "ai_language": "zh-CN",
      "timezone": "Asia/Shanghai",
      "country": "CN"
    },
    "privacy": {},
    "notification": {}
  },
  "updated_at": "2026-04-05T12:34:56+00:00"
}
```

Mapping note:

- `display_name` maps to `profiles.username`.
- `avatar_path` is stored in profile layer.
- `avatar_url` is render-ready URL generated from storage strategy.

## Profile update contract

### `PATCH /api/v1/users/me/profile`

Request:

```json
{
  "display_name": "string(1..30)",
  "bio": "string(0..200)",
  "avatar_path": "avatars/{user_id}/{file}"
}
```

Rules:

- At least one field must be provided.
- `display_name` must be non-empty after trim.
- `bio` can be empty string and should be normalized to `null` only if agreed by API implementation.
- `avatar_path` must stay in current user prefix: `avatars/{current_user.id}/`.

Response:

- Returns the same shape as `GET /users/me/profile`.

## Settings update contract

### `PATCH /api/v1/users/me/settings`

Request:

```json
{
  "settings": {
    "version": 1,
    "preferences": {
      "interface_language": "zh-CN",
      "ai_language": "zh-CN",
      "timezone": "Asia/Shanghai",
      "country": "CN"
    },
    "privacy": {},
    "notification": {
      "allow_notifications": true,
      "allow_vibration": true
    }
  }
}
```

Rules:

- `settings` must conform to `ProfileSettingsV1`.
- Additional fields are forbidden.

Response:

- Returns the same shape as `GET /users/me/profile`.

## Avatar upload signing contract

### `POST /api/v1/users/me/avatar/upload-url`

Request:

```json
{
  "mime_type": "image/png|image/jpeg|image/webp",
  "file_size": 123456,
  "ext": "png|jpg|jpeg|webp"
}
```

Response:

```json
{
  "bucket": "avatars",
  "path": "avatars/{user_id}/{uuid}.png",
  "upload_url": "https://...signed...",
  "expires_in": 600
}
```

Validation rules:

- `bucket` must equal `config.storage.avatar.bucket`.
- `file_size` must be `>0` and `<= config.storage.avatar.max_size_mb`.
- Only image mime types are allowed.
- Path must be server-generated and never trusted from client.

## Direct avatar upload contract

### `POST /api/v1/users/me/avatar`

Request:

- `multipart/form-data`
- field name: `file`

Validation rules:

- extension must be one of `png|jpg|jpeg|webp`
- mime must map to image type (`image/png|image/jpeg|image/webp`)
- payload size must be `<= config.storage.avatar.max_size_mb`

Behavior:

- backend writes avatar bytes to `bucket=config.storage.avatar.bucket`
- backend stores canonical path in profile
- response returns latest profile payload (`ProfileResponse`)

## Error contract linkage

- 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.