refactor: update worker processes in EvoBGP to accept dependencies for shared store and job registry. Enhance scheduler, ingest, render, and deploy components to utilize a unified context and improve logging for drift detection. Update architecture documentation to reflect changes in process interactions and worker functionalities.

docs/architecture.md

@@ -13,11 +13,11 @@
 | Бинарник | Роль |
 |----------|------|
 | `evobgp-api` | Только HTTP API и связанная логика в одном процессе. |
-| `evobgp-all` | Режим одной VPS: тот же API + in-process запуск заглушек scheduler, ingest, render, deploy. |
-| `evobgp-scheduler` | Планировщик cron/интервалов модулей (в коде сейчас **stub**). |
-| `evobgp-ingest` | Воркеры загрузки внешних источников (CDN и т.д.) (**stub**). |
-| `evobgp-render` | Генерация артефактов BIRD из ревизий (**stub**). |
-| `evobgp-deploy` | Выкладка на спикеры / взаимодействие с BIRD на стороне деплоя (**stub**). |
+| `evobgp-all` | Тот же API + in-process **scheduler** (очередь `module_refresh` в общем Registry), **ingest** (prefetch ETag CDN), **render** (опционально auto-publish), **deploy** (лог расхождений published/applied). |
+| `evobgp-scheduler` | По `refresh_interval_sec` ставит refresh: в одном процессе с API — через `jobs.Registry`; в reference Compose — **HTTP** `POST /v1/modules/{id}/refresh` (`EVOBGP_CONTROL_PLANE_URL`, `EVOBGP_SCHEDULER_BEARER`). |
+| `evobgp-ingest` | Периодический conditional GET по URL CDN-источников и обновление `etag` в БД. |
+| `evobgp-render` | По умолчанию только heartbeat; при `EVOBGP_RENDER_AUTOPUBLISH=1` выставляет всем спикерам tenant последнюю ревизию (упрощение для демо). |
+| `evobgp-deploy` | Периодически логирует **drift**: `last_applied_revision_id` vs опубликованная ревизия для ноды. |
 | `evobgp-node` | CLI реплики: `pull-bundle`, `verify-bundle`, `apply-bundle`. |
 | `evobgp-agent` | Локальный агент рядом с BIRD (например `watch` по сокету). |
 
@@ -39,6 +39,7 @@
 | `config` | Переменные окружения `EVOBGP_*`. |
 | `observability` | Метрики Prometheus, HTTP middleware. |
 | `broker` | Заготовка под NATS/Redis (логирование подключения в воркерах). |
+| `pipeline` | Ingest+render в одном шаге для `module_refresh`: выборка префиксов (CDN/AS/IP/пустые DOMAINS), `CreateRenderRevision`, превью BIRD через `birdfmt`. |
 
 ## Диаграмма: эталонный Compose (reference)
 
@@ -51,12 +52,11 @@ flowchart LR
   end
   subgraph control [Control_plane]
     API[evobgp_api]
-    Sched[evobgp_scheduler_stub]
-    Ingest[evobgp_ingest_stub]
-    Render[evobgp_render_stub]
-    Deploy[evobgp_deploy_stub]
+    Sched[evobgp_scheduler]
+    Ingest[evobgp_ingest]
+    Render[evobgp_render]
+    Deploy[evobgp_deploy]
     PG[(PostgreSQL)]
-    NATS[NATS_JetStream]
   end
   subgraph data [Data_plane]
     BIRD[BIRD2]
@@ -66,10 +66,7 @@ flowchart LR
   Operator --> API
   NodeCLI --> API
   API --> PG
-  Sched --> NATS
-  Ingest --> NATS
-  Render --> NATS
-  Deploy --> NATS
+  Sched -->|HTTP_or_DB| API
   Sched --> PG
   Ingest --> PG
   Render --> PG
@@ -77,7 +74,7 @@ flowchart LR
   Agent --> BIRD
 ```
 
-На практике воркеры **пока не выполняют** полноценную работу с очередью — они резервируют место в топологии и пишут в лог. API и БД уже обеспечивают основной сценарий разработки и тестов.
+Очередь задач по-прежнему **in-memory в процессе API** (`jobs.Registry`); отдельный контейнер `evobgp-scheduler` не разделяет память с API и дергает refresh по HTTP. Полноценный брокер (NATS) и общая очередь `job_audit` между процессами — в следующих итерациях.
 
 ## Диаграмма: microvps (`evobgp-all`)
 
@@ -92,7 +89,7 @@ flowchart LR
   All --> BIRD
 ```
 
-Внутри процесса `evobgp-all` горутины scheduler/ingest/render/deploy — те же **stub**, что и отдельные бинарники.
+Внутри `evobgp-all` все воркеры используют **тот же** `store` и `jobs.Registry`, что и HTTP handlers, поэтому `module_refresh` выполняется в том же процессе без HTTP.
 
 ## Поток: ревизия и бандл для ноды
 

docs/quickstart.md

@@ -60,7 +60,9 @@ docker compose --profile reference up -d --build
 | 9090 | Prometheus (в compose) |
 | 179 | BGP (BIRD2) |
 
-**Важно:** процессы `evobgp-scheduler`, `evobgp-ingest`, `evobgp-render`, `evobgp-deploy` в текущей версии кода — **заглушки** (логирование и периодический тик). Реальная очередь задач и брокер подключаются в будущих итерациях; API и БД при этом уже работают.
+**Воркеры reference:** `evobgp-scheduler` ходит в API по HTTP (`EVOBGP_CONTROL_PLANE_URL`, `EVOBGP_SCHEDULER_BEARER`); в [docker-compose.yaml](../deploy/compose/docker-compose.yaml) для локального запуска включены `EVOBGP_DEV_INSECURE=1` на API и токен `dev` у планировщика. `evobgp-ingest` обновляет ETag CDN-источников; `evobgp-render` по умолчанию не трогает `published_revision` (включите `EVOBGP_RENDER_AUTOPUBLISH=1` осознанно); `evobgp-deploy` пишет в лог расхождение applied vs published. Очередь `jobs` остаётся in-process у **evobgp-api**; общий брокер — в планах.
+
+В **evobgp-all** (microvps) те же пакеты крутятся в одном процессе и используют общий `jobs.Registry` без HTTP.
 
 ## Вариант 3: Локально без Docker (только API)