openspec: архив 14 завершённых change-ов (веб-фиксы, crawler-queue, own-content-hub, publisher-service); спеки влиты в openspec/specs

openspec/changes/archive/2026-09-16-publisher-service/proposal.md

@@ -0,0 +1,66 @@
+## Why
+
+Сейчас публикатор встроен в веб-приложение (web/app.py импортирует publisher.bot напрямую
+и вызывает publish_multi). Это нарушает изоляцию элементов системы и мешает масштабированию:
+- публикация привязана к процессу веба (ошибка Bot API роняет весь approve);
+- нет отдельного жизненного цикла (нельзя перезапустить/обновить публикатор отдельно);
+- каналы захардкожены шаблоном @dedinit_vesti_<dir>_<lang>_bot, а реальная схема —
+  «один бот-контроллер, несколько каналов» (на старте один @dedinit_vesti, потом больше);
+- нет единой точки входа для публикации из любых компонентов (веб, cron, будущие боты VK/fediverse).
+
+Цель — вынести публикацию в **изолированный микросервис** (отдельный FastAPI-сервис в
+контейнере), который вызывается HTTP-запросом при необходимости. Это соответствует
+архитектурному решению «сегментировать элементы системы на микросервисы в отдельных
+контейнерах» (PRD, раздел 5).
+
+## What Changes
+
+- Новый сервис `publisher/` (или `services/publisher/`): FastAPI-приложение с эндпоинтом
+  `POST /api/v1/publish` (публикация карточки в один или несколько каналов) и
+  `GET /healthz` (healthcheck).
+- Конфигурация сервиса: `VESTI_BOT_TOKEN` (токен бота-контроллера @dedinit_controller_bot),
+  `TG_PROXY=socks5://127.0.0.1:1080` (Telegram из РФ доступен только через SOCKS5),
+  список каналов (сейчас `@dedinit_vesti`, потом несколько) — из .env или отдельного YAML.
+- Бот-контроллер: один (id 7765665742, @dedinit_controller_bot), публикует во все каналы,
+  в которые добавлен администратором.
+- `publisher/bot.py` переносится в сервис (логика publish_card/publish_multi/get_views),
+  но с конфигом каналов вместо шаблона @dedinit_vesti_<dir>_<lang>_bot.
+- `web/app.py` больше НЕ импортирует publisher напрямую: вместо publish_multi — HTTP POST
+  на publisher-service `/api/v1/publish`.
+- Dockerfile + docker-compose для сервиса; healthcheck; логирование.
+
+### Не меняется
+- Карточка (publisher/card.py) остаётся (формат ≤4096, атрибуция «Дед в АйТи», ссылка на оригинал).
+- Режим публикации «черновик на подтверждение» (веб подтверждает → публикация). Без автопостинга.
+
+## Capabilities
+
+### New Capabilities
+- `tg-publisher-service`: Изолированный FastAPI-сервис публикации в Telegram:
+  единая точка `POST /api/v1/publish`, конфиг каналов, прокси SOCKS5 для Bot API,
+  сбор views, healthcheck.
+
+### Modified Capabilities
+- `tg-publisher`: логика публикации переезжает в сервис; вызывающий код (веб) использует HTTP.
+- `vesti-web`: approve вызывает publisher-service по HTTP вместо прямого импорта.
+- `news-store`: без изменений (бандлы создаёт веб, как раньше).
+
+## Impact
+
+- Затронутые сервисы/порты: publisher-service — новый порт (напр. 8410, локально);
+  vesti-web :8400 — меняет способ вызова публикатора (HTTP вместо импорта).
+- Файлы:
+  - новый: services/publisher/ (app/, Dockerfile, docker-compose.yml, requirements.py, README.md)
+  - изменён: web/app.py (HTTP-вызов), .env.example (VESTI_BOT_CHANNELS, TG_PROXY)
+  - перенос: publisher/bot.py → services/publisher/ (логика сохраняется)
+- Данные: без миграций БД (published.tg_message_id/distributed_dirs остаются).
+- Секреты: тот же VESTI_BOT_TOKEN (бот-контроллер); TG_PROXY переиспользуется.
+- Прокси: Bot API ТОЛЬКО через SOCKS5 127.0.0.1:1080 (api.telegram.org из РФ недоступен).
+- Rollback: вернуть в web/app.py импорт publisher.bot (старый путь); сервис можно не запускать.
+
+## Risks
+
+- SOCKS5-прокси недоступен → сервис не может опубликовать: healthcheck должен это показывать.
+- Бот не админ канала → sendMessage 403: сервис возвращает понятную ошибку, веб показывает ее.
+- Несколько каналов в будущем: конфиг списком (VESTI_BOT_CHANNELS=@a,@b), fan-out по каналам.
+- Рестарт сервисов — только извне (SSH sudo systemctl restart) — правило окружения.