schema: spec-driven

context: |
  Проект VESTI — новостной агрегатор с веб-интерфейсом (эволюция /opt/news).
  Домен: медиа-конвейер: краулинг (RSS, email, сайты, Telegram, WeChat, X) → дедуп + слияние источников в одну статью → факт-чек → категоризация (Технологии, Политика, Игры, Электроника, БЯМ, Линукс) → банк статей (markdown-бандлы с frontmatter) → дайджесты по направлениям (для еженедельных видео) + ленты ботов (Telegram, VK, fediverse).
  Окружение: Hermes-агент на bigbox (10.8.0.2, home server), сервисы в /opt/<service>/; Docker (docker compose), systemd; рестарт сервисов — только извне (SSH sudo systemctl restart).
  Ключевые сервисы: telegram-tunnel (SOCKS5 127.0.0.1:1080 → VPS01), ollama (:11434), qdrant (:6333), redis (:6379), gitea (:3000, зеркало), gitverse.ru (источник истины), gotosocial (fediverse, :8082), garage (S3).
  LLM: локально qwen3:8b-nothink (классификация, категоризация, быстрые задачи); qwen3-vl:8b (vision); облако (deepseek, текущий провайдер) — факт-чек, слияние, дайджесты, отдельный API/ключ для учёта затрат (решение E2).
  Telegram: доступ только через SOCKS5 127.0.0.1:1080; api_id=24276216, api_hash из /opt/icq/docker-compose.yml; Telethon-сессия /opt/news/telegram/ переиспользуется; боты-публикаторы — через Bot API (свой токен).
  Направления: Технологии, Политика, Игры, Электроника, БЯМ, Линукс. Языки ботов: ru, en, zh, ko. Именование ботов: @dedinit_vesti_<направление>_<язык>_bot.
  Соглашения: отдельный каталог /opt/vesti/ на сервис; секреты в .env; порты фиксируются в README.md; апдейты через git (источник истины gitverse.ru); статьи — markdown-бандлы: bundles/<направление>/<YYYY-MM>/<slug>.md + media/ рядом; веб — локально (пока без внешнего домена).
  Прототип (итерация 1): TG-краулер (Telethon) + классификатор (локальный qwen) + TG-бот-публикатор (режим «черновик на подтверждение») + минимальный веб (FastAPI + Bootstrap 5.3 + Jinja2 + HTMX) с авторизацией.
  Метрики: для внешних TG-постов — views/reactions; для своих постов — views через Bot API; сайты/RSS — только свои переходы (UTM).

rules:
  proposal:
    - Указывать затронутые сервисы и порты
    - Включать план отката (rollback)
  specs:
    - Требования в формате MUST/SHOULD/MAY
    - Сценарии проверки: GIVEN/WHEN/THEN с конкретными командами верификации (systemctl status, curl, docker ps, python -c ...)
  design:
    - Указывать конкретные файлы конфигов и юнитов
    - Включать команды применения и проверки
  tasks:
    - Каждая задача — проверяемый шаг с командой верификации