# WTG — сбор, обработка и подготовка публикационных материалов

Статус пакета: архивный кейс после полного вывода WTG из эксплуатации 07.09.2026. Удаление подтверждено в retirement.md и повторной проверкой отсутствия runtime/data. Разделы ниже описывают наблюдения до удаления.

WTG объединяет сбор публикаций и сведений о сообществах VK, нормализацию, OCR изображений, извлечение публикационных материалов и операторскую проверку. Telegram- и MAX-компоненты используют подготовленные данные. Это прикладная система с административным интерфейсом, очередями и историей обработки.

## Что подтверждено непосредственно

07.09.2026 через SSH и браузер исследована работающая VPS. На первом замере были запущены семь контейнеров WTG: web, scheduler, OCR worker, PaddleOCR sidecar, Telegram bot, MAX bot и PostgreSQL. Всего на сервере было 13 контейнеров, включая магазин и Codex proxy.

SQL-подсчёт зафиксировал 75 366 сообществ, 527 718 публикаций, 824 349 решений классификатора, 277 498 материалов и 29 092 OCR-задания. Эти сущности имеют разные значения: одна публикация может иметь несколько версий решения и несколько материалов. Их нельзя складывать или представлять числом уникальных успешных публикаций.

Из OCR-заданий 17 222 имеют состояние completed, 11 870 — failed. Это история состояния очереди, а не оценка точности OCR. Сохранённый confidence также не является измеренной точностью модели.

## Технологии и их роль

Python обслуживает сборщики, планирование и обработку. FastAPI отдаёт HTML и JSON API. Jinja, Bootstrap и небольшой JavaScript формируют операционную админку. SQLAlchemy и Alembic обеспечивают модели и миграции PostgreSQL. PaddleOCR работает в отдельном сервисе. Playwright использовался для ручной авторизации и браузерного пути сбора. Docker Compose, Nginx и systemd обеспечивали эксплуатацию.

publication-intelligence выделяет детерминированную классификацию и извлечение материалов в независимый пакет; WTG связывает его с БД и review-процессом. В документации предусмотрено опциональное обогащение внешней LLM. В ходе архивирования внешняя LLM и новый сбор не запускались.

## Рабочий сценарий

1. Оператор подключает аккаунт и проверяет отдельно браузерную сессию и API-доступ.
2. Список групп формирует пул и расписание проверок. Фоновая задача получает lease и фиксирует heartbeat.
3. Сборщик сохраняет публикацию, метаданные и медиа. Повторная обработка опирается на идентичность источника.
4. Локальный фильтр и быстрый OCR отделяют очевидные случаи; сложные изображения поступают в очередь PaddleOCR.
5. Классификатор сохраняет версионированное решение и нормализованные материалы.
6. Оператор сравнивает исходник, OCR, классификацию и разметку. Готовые данные доступны downstream-компонентам.

## Инженерные решения

- Долгая обработка вынесена из пользовательского действия в задания и worker-процессы.
- Исходная публикация, промежуточные результаты и итоговый материал разделены: можно объяснить происхождение результата.
- OCR отделён от web-сервиса, а его задания имеют статусы, попытки и блокировки.
- Canonical publication output отделён от старого pipeline evidence/review слоя.
- API polling и браузерная авторизация имеют самостоятельные состояния и ограничения.
- Карта кода связывает интерфейс, очередь, обработчик, модели и тесты, чтобы изменения оставались прослеживаемыми.

## Ограничения и фактическое состояние

Часть интерфейса показывает исторические состояния июня–июля. Статус running со старым heartbeat не доказывает текущую обработку. На экране группы выявлены отменённый проход, rate_limited и отсутствие service token. Legacy noVNC-маршруты не имели работающих слушателей при исходном аудите.

Во время просмотра тяжёлого раздела web-процесс вырос примерно до 3,8 GiB и перестал отвечать на healthcheck. Это наблюдение эксплуатации; точная первопричина в коде не локализована. После перезапуска только web-контейнера, ограничения его памяти до 2 GiB и остановки scheduler/OCR worker ограниченные страницы снова открывались. Повторно нагружать рабочую БД ради проблемного экрана не требовалось.

До очистки каталог WTG занимал около 104 GiB, в том числе около 75 GiB резервных копий и 27 GiB PostgreSQL. В backup-скрипте ротация выполнялась после успешного dump: переполнение диска мешало созданию новой копии и последующей ротации. Архивные файлы не проверялись восстановлением и не сохраняются этим пакетом.

## Даты и версии

Документация code-map датирована 22.06.2026; в данных есть история работы июня–июля 2026. Дата архивной съёмки — 07.09.2026. Начало разработки и коммерческий результат по этим сведениям не устанавливаются.

Checkout исходников на VPS: `21841487f52489d8bafaac379b9cc08199937661`; рабочее дерево при сборе метаданных чистое. Публичный аудитированный репозиторий wtg-s: `b3c779a190884d708ae10bd6e68021b08bd18689`. Эти версии не отождествляются. Image ID каждого реально запущенного контейнера сохранён в агрегированном снимке; соответствие содержимого образа checkout отдельно не доказывалось.

## Как читать материалы

Галерея показывает реальные экраны с обозначенным скрытием идентификаторов. CSV и графики содержат агрегаты. Исходные дампы, cookies, browser profiles, токены, пользовательские сессии и raw payload exports в пакет не входят. Исходная документация сервера сохранена в source-reference как исторический источник, а не инструкция запускать удалённый сервис.

Исходники: https://github.com/komaroffsergei/wtg-s
