# QMAX Architecture

```mermaid
flowchart LR
    A["Android app<br/>Kotlin + Compose"] -->|HTTPS JSON + uploads| B["QMAX API<br/>ASP.NET Core"]
    A -->|SignalR planned/available| B
    B --> C["SQLite cache<br/>chats/messages/sessions"]
    B --> D["Local storage<br/>attachments/releases"]
    B -->|HTTP internal| E["MAX worker<br/>Node + Playwright"]
    E -->|persistent browser profile| F["web.max.ru"]
    B --> G["Caddy TLS<br/>qmax.kusoft.xyz"]
```

The server is the only public backend surface. The MAX worker stays inside the Docker network and is controlled through the API/admin page.

## Security Rules

- Android pairs to the private server with `QMAX_PAIRING_CODE`.
- API access uses JWT access tokens and refresh tokens.
- MAX credentials and sessions live only on the Pi in Docker volumes.
- `.env`, service-account files, keystores and runtime data are ignored by git.
- Attachments are written as `.part` first and moved into place only after full upload.
- Android image attachments are downloaded to a local `.part` cache and exposed to the UI only after size validation.

## Current Verified Status

- MAX Web login is authorized on the Raspberry Pi worker.
- Chat list, message history, text sending and attachment sending are mapped through `worker/src/server.js`.
- Image, video, file and voice attachments are projected through the API and rendered by the Android client.
- Firebase initialization and Android push token registration are enabled for `xyz.kusoft.qmax`.

## Remaining Production Checks

- Keep selector drift monitoring for future MAX Web UI changes.
- Run an unlocked-device visual pass on the connected phone for every major UI change.
- Replace debug fallback signing with a real release key in `android/key.properties`.