Реализация на отдельных двух машинах с протестированным взаимодействием по проверке сообщений

architectory/arch-01-system-architecture.md

@@ -195,7 +195,7 @@ Frontend не должен:
 - локальную регистрацию пользователя приложения: `find-or-create` `UserIdentity` по `keycloak_sub`, создание минимального `ClientProfile` для нового пользователя, обновление `last_login_at` для существующего (после OTP — см. `POST /api/v1/auth/bootstrap`);
 - **приём события `session_start`**: запись `UxSession`, audit/analytics-событие; **не** используется для контроля доступа;
 - валидация данных получаемых от frontend (соответствие типов данных, проверка обязательности полей, проверка формата данных, диапазоны значений, размер полей) через Pydantic 
-- хранение согласий пользователя в App DB (**`user_id`**, **`ux_session_id`**, **`client_ip`**, версии документов) — только после JWT;
+- хранение согласий пользователя в App DB (**`user_id`**, nullable **`ux_session_id`**, **`client_ip`**, версии документов) — только после JWT; при bootstrap `ux_session_id=NULL` допустим, потому что новая UX-сессия создаётся следующим запросом;
 - профиль, структурированный блоками;
 - API чата, истории, файлов и документов;
 - realtime-доставку входящих сообщений клиенту;
@@ -435,7 +435,7 @@ api-backend не решает, sync или async нужна проверка в
     - при **`KEYCLOAK_OTP_MOCK_ENABLED=false`**: значение сверяется локально с HMAC OTP, сгенерированного Keycloak и переданного в закрытом заказе `sms-service`; статусы Direct и callback на verify не влияют.
     - при неверном коде Keycloak возвращает ошибку; frontend не получает tokens, шаг 12 не выполняется.
 12. При успешной проверке frontend получает tokens через OIDC Authorization Code Flow with PKCE.
-13. Frontend с JWT вызывает **`POST /api/v1/auth/bootstrap`** — в теле передаёт локально принятые согласия и device metadata (см. arch-02). api-backend атомарно: `find-or-create` по JWT `sub` (`keycloak_sub`), телефон из JWT claims (не из body) → сохранение `UserConsent` на `user_id` → минимальный профиль.
+13. Frontend с JWT вызывает **`POST /api/v1/auth/bootstrap`** — в теле передаёт локально принятые согласия и device metadata (см. arch-02). api-backend атомарно: `find-or-create` по JWT `sub` (`keycloak_sub`), телефон из JWT claims (не из body) → сохранение `UserConsent` на `user_id` с nullable `ux_session_id` (на bootstrap обычно `NULL`) → минимальный профиль.
 14. Frontend вызывает **`POST /api/v1/analytics/session-start`** (если нужна новая UX-сессия) и далее работает с `X-Ux-Session-Id`.
 15. Триггер App DB ставит задачу `contact.map_or_create` в `sync_queue`; `bitrix-sync` асинхронно находит или создает Contact в Битрикс24. Авторизация не должна синхронно зависеть от ответа Битрикс24 CRM.
 16. Frontend создаёт диалог и отправляет отложенное сообщение (см. «Создание диалога» и поток чата).
@@ -596,56 +596,7 @@ App DB — **локальный кэш** для UI. Двусторонний syn
 
 ### Предлагаемая структура backend-репозитория
 
-```text
-backend/
-  docker-compose.yml                 # root compose ВМ1
-  .env.example
-  nginx/
-    docker-compose.yml
-    nginx.conf
-    conf.d/
-    certs/
-      .gitkeep
-  api-backend/
-    app/
-    docker-compose.yml
-    tests/
-    pyproject.toml
-    Dockerfile
-  bitrix-local-app/
-    app/
-    docker-compose.yml
-    deploy/
-    tests/
-    pyproject.toml
-    Dockerfile
-  keycloak/
-    docker-compose.yml
-    realm/
-    themes/
-    providers/
-  sms-service/
-    app/
-    migrations/
-    openapi.yaml
-    Dockerfile
-  redis/
-    docker-compose.yml
-  observability/
-    docker-compose.yml              # collector ВМ1
-    otel-collector.yaml
-
-processing/
-  docker-compose.yml                # root compose ВМ2
-  nginx-internal/
-  message-safety/
-  bitrix-sync/
-  clamav/
-  redis/
-  observability/                    # collector ВМ2
-```
-
-Детальная внутренняя структура каждого сервиса (`app/`, модули, миграции) определяется в профильных спецификациях модулей (TBD).
+Каноническая структура root Compose, service includes, networks и mounts задаётся в [`arch-03-docker-compose-blueprint.md`](arch-03-docker-compose-blueprint.md). Детальная внутренняя структура сервиса определяется его профильной спецификацией.
 
 ### Compose-контуры