Проект разделен на два репозитория

architectory/arch-01-system-architecture.md

@@ -20,11 +20,11 @@ HAN Chat - приложение для мигрантов, где стартов
 - Мультиязычность в первом релизе не нужна, но тексты должны храниться по мнемоникам для будущих переводов.
 - Среда на первом этапе одна и проектируется как боевая.
 - Вложения чата MVP: **только изображения и PDF** — см. [`arch-04-settings-and-content.md`](arch-04-settings-and-content.md), «Разрешённые типы файлов чата».
-- SMS OTP вводится поэтапно: до production rollout действует явный mock (`KEYCLOAK_OTP_MOCK_ENABLED=true`); целевой real mode — Keycloak генерирует/локально проверяет OTP и создаёт durable order в `sms-service`, а worker асинхронно вызывает i-Digital Direct. Контракт и gates — [`module-11-idgtl-sms.md`](../modules/module-11-idgtl-sms.md).
+- SMS OTP вводится поэтапно: до production rollout действует явный mock (`KEYCLOAK_OTP_MOCK_ENABLED=true`); целевой real mode — Keycloak генерирует/локально проверяет OTP и создаёт durable order в `sms-service`, а worker асинхронно вызывает i-Digital Direct. Контракт и gates — [`module-11-idgtl-sms.md`](../VM1_app/documentation/module-11-idgtl-sms.md).
 - Популярный вопрос при выборе **автоматически отправляется как сообщение**; если пользователь не авторизован — сначала согласия и OTP, затем отправка.
 - Notification Center v1 использует два контура: G — общие read-only гостевые кампании, P — персональные уведомления с состоянием в App DB. Виды, CTA, кнопки и палитра задаются каталогом данных.
 - Инструкция `install_app` всегда открывается во внешней новой вкладке; iframe/модалка для неё не используется.
-- Перечень таблиц и миграций App DB проектирует модуль `database` (и владельцы схем других сервисов); arch фиксирует только **разделение схем** PostgreSQL и контракты между сервисами.
+- Перечень таблиц и миграций схемы `han_app` проектирует `module-01-api-backend` и его migration owner; владельцы остальных сервисов проектируют свои схемы. Arch фиксирует только **разделение схем** PostgreSQL и контракты между сервисами.
 
 ## Пользовательские сценарии
 
@@ -243,7 +243,7 @@ Frontend не должен:
 
 ### Bitrix24 sync service
 
-Отвечает за асинхронную двустороннюю синхронизацию данных между App DB и Битрикс24 CRM по контракту [`../modules/module-07-bitrix-sync.md`](../modules/module-07-bitrix-sync.md):
+Отвечает за асинхронную двустороннюю синхронизацию данных между App DB и Битрикс24 CRM по контракту [`module-07-bitrix-sync.md`](../VM2_services/documentation/module-07-bitrix-sync.md):
 
 - **канонический mapping** и его историю в `bitrix_sync.entity_external_mapping`; App DB не хранит CRM Contact ID;
 - **App DB → Bitrix24:** durable workflow для `contact.map_or_create`, `contact.update`, `contact.deactivate`;
@@ -287,7 +287,7 @@ Frontend не должен:
 
 Confidential **backend client** Keycloak (client credentials) в MVP **не обязателен**: S2S между нашими сервисами идёт по service tokens, не через Keycloak. Client можно завести заранее в realm как optional для будущих admin/ops сценариев.
 
-### Nginx Reverse Proxy
+### Nginx Reverse Proxy (целевая двух-VM топология)
 
 Отвечает за:
 
@@ -296,11 +296,11 @@ Confidential **backend client** Keycloak (client credentials) в MVP **не об
 - редирект HTTP на HTTPS (на веб-домене; для выделенного API-домена HTTP не допускается — см. «Принципы безопасности»);
 - маршрутизацию `/api/*` в api-backend (включая `WS /api/v1/realtime`);
 - маршрутизацию `/auth/*` или выделенного auth-домена в Keycloak;
-- маршрутизацию публичных `/bitrix/*` endpoint в `bitrix-local-app`;
-- маршрутизацию `/bitrix/sync/*` webhook endpoint в `bitrix-sync`;
+- на nginx ВМ1 — маршрутизацию только `/bitrix/handler`, `/bitrix/install`, `/bitrix/placement` в `bitrix-local-app`;
+- на отдельном public nginx ВМ2 — маршрутизацию только exact `/bitrix/sync/webhook/contact` и `/bitrix/sync/webhook/alert` в `bitrix-sync`; ВМ1 эти paths не проксирует;
 - маршрутизацию только exact `POST /callbacks/idgtl/sms` в `sms-service` по HTTPS, с allowlist актуального IP Direct и без логирования Basic Authorization;
 - защиту internal endpoint `bitrix-local-app` через private network или `nginx allowlist`;
-- отсутствие публичной маршрутизации к `message-safety` — сервис доступен только из внутренней Docker-сети;
+- отсутствие публичной маршрутизации к `message-safety`: `api-backend` ВМ1 вызывает private nginx ВМ2 `:8443` по HTTPS с internal CA и service token; Docker DNS/HTTP допустим только внутри ВМ2 за gateway;
 - передачу `X-Forwarded-For`, `X-Forwarded-Proto`, `X-Forwarded-Host`, `X-Request-ID` (если клиент не прислал `X-Request-ID` — nginx **генерирует** UUID и прокидывает upstream);
 - базовые лимиты размера запроса и timeout;
 - грубые edge rate limits по IP, route и зоне риска;