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.
 
 ## Поток: ревизия и бандл для ноды