add backend hatchet worker for calendar predue sync

docs/adr/0001-chat-platform-service-boundaries.md

@@ -5,10 +5,11 @@
 
 ## Контекст
 
-Нужна минимальная и предсказуемая схема из 5 сервисов:
+Нужна минимальная и предсказуемая схема из 6 сервисов:
 
 - `frontend`
 - `backend`
+- `backend_worker`
 - `telegram_backend`
 - `telegram_worker`
 - `hatchet`
@@ -42,7 +43,11 @@
 - для outbound вызывает `telegram_backend /graphql` (`sendTelegramMessage`), затем `backend /graphql` (`reportTelegramOutbound`);
 - не имеет собственной Prisma-базы.
 
-4. `hatchet`
+4. `backend_worker`
+- исполняет периодические backend workflow в Hatchet;
+- для cron-задач вызывает `backend /graphql` (без прямого доступа к Prisma).
+
+5. `hatchet`
 - единый оркестратор задач, ретраев и backoff-политик.
 
 ## Потоки
@@ -61,6 +66,12 @@
 3. `telegram_worker` вызывает `telegram_backend.sendTelegramMessage`.
 4. `telegram_worker` репортит итог в `backend.reportTelegramOutbound`.
 
+### Calendar Predue (Backend cron)
+
+1. Hatchet по cron запускает workflow в `backend_worker`.
+2. `backend_worker` вызывает `backend.syncCalendarPredueTimeline`.
+3. `backend` делает upsert `ClientTimelineEntry` для `CalendarEvent` в окне `startsAt - preDue`.
+
 ## Границы ответственности
 
 `backend`:
@@ -75,19 +86,24 @@
 - можно: исполнение задач, ретраи, orchestration шагов;
 - нельзя: хранение CRM-состояния и прямой доступ к основной БД.
 
+`backend_worker`:
+- можно: периодические orchestration задачи через Hatchet;
+- нельзя: прямой доступ к основной БД (только через backend GraphQL).
+
 ## Надежность
 
 - webhook отвечает `200` только после успешной постановки задачи в Hatchet;
 - при недоступности сервисов задача ретраится Hatchet;
 - inbound обработка идемпотентна через `idempotencyKey` и provider identifiers в `backend`.
+- календарный sync использует advisory-lock в `backend`, поэтому параллельные cron-run безопасны.
 
 ## Последствия
 
 Плюсы:
-- меньше сервисов и меньше скрытых связей;
+- меньше скрытых связей;
 - изоляция доменной БД в `backend`;
 - единая точка ретраев/оркестрации (Hatchet).
 
 Минусы:
 - выше требования к стабильности GraphQL-контрактов между сервисами;
-- нужна наблюдаемость по цепочке `telegram_backend -> hatchet -> telegram_worker -> backend`.
+- нужна наблюдаемость по цепочкам `telegram_backend -> hatchet -> telegram_worker -> backend` и `hatchet -> backend_worker -> backend`.

docs/prisma-governance.md

@@ -2,18 +2,18 @@
 
 ## Single source of truth
 
-- Canonical Prisma schema: `Frontend/prisma/schema.prisma`.
+- Canonical Prisma schema: `frontend/prisma/schema.prisma`.
 - Service copy:
   - `backend/prisma/schema.prisma`
 
 ## Update flow
 
-1. Edit only `Frontend/prisma/schema.prisma`.
+1. Edit only `frontend/prisma/schema.prisma`.
 2. Run `./scripts/prisma-sync.sh`.
 3. Run `./scripts/prisma-check.sh`.
 4. Commit changed schema copy.
 
 ## Rollout policy
 
-- Schema rollout (`prisma db push` / migrations) is allowed only in `Frontend`.
+- Schema rollout (`prisma db push` / migrations) is allowed only in `frontend`.
 - `backend` must use generated Prisma client only.