content-pipeline/README.md

content-pipeline

Оркестратор контентного конвейера + CMS-слой для управления публикациями.

Не CMS как таковая, а развитие editor-pro + GEO через более глубкую интеграцию.

Что это

Гибрид двух слоёв в едином UI:

┌─────────────────────────────────────────┐
│           UI-панель (один экран)          │
├─────────────────────────────────────────┤
│  1. Pipeline-оркестратор                 │  ← управление конвейером
│     (editor-pro → GEO → публикация)      │     запуск, статус, ретрай
│                                          │
│  2. CMS-слой                            │  ← удобная правка
│     (список статей / редактор /          │     BlockNote + превью
│      превью / публикации)               │
├─────────────────────────────────────────┤
│  FastAPI-оркестратор на 9876            │
│  (уже есть для SEO-проектов)            │
└─────────────────────────────────────────┘

Архитектура

Единая модель данных (src/types.ts)

Один объект «статья» используют оба слоя:

• slug, title, body — базовые поля
• utm — UTM-теги для персонализации hero
• geo — GEO-мета (сущности, ключевые запросы)
• status — draft / in-review / published / archived
• editorProTaskId — связь с editor-pro

Валидация и slugify — единые для обоих слоёв (никакого дублирования).

Pipeline-оркестратор (src/pipeline.ts)

Шаги: generate (editor-pro) → optimize (GEO) → publish.

• Запуск конвейера для списка статей
• Статусы шагов (pending/running/success/failed)
• Ретрай до 3 раз при ошибке (экспоненциальный backoff)
• Делегирует тяжёлую работу шагам (не выполняет сам)

Хранилище (src/store.ts)

Единый источник данных для обоих слоёв:

• CRUD статей
• Фильтрация по статусу (для CMS)
• Поиск по заголовку/тексту
• В MVP — in-memory Map; в прода — SQLite/Postgres (тот же интерфейс)

Почему не форк CMS

Готовые CMS (AstroAdmin, astro-cms, EmDash) — CRUD для контента, не pipeline-оркестратор. Они не знают про editor-pro, GEO, UTM-теги. Им пришлось бы писать слой адаптации — свой слой проще и точнее.

Roadmap

MVP (базовый конвейер)

• FastAPI-оркестратор (9876) — запуск pipeline
• SQLite-репозиторий вместо in-memory
• Блок-редактор (BlockNote/TipTap) для CMS-слоя
• Превью через iframe dev-сервера
• Привязка к deploy-пайплайну (rsync на хостинг)
• Статусы pipeline в UI (отслеживание задач)

Расширение типов контента (отдельные направления)

Каждый тип — отдельное направление, которое нужно глубоко прорабатывать и тестировать для качества. Не делать всё сразу — получится хрупкий конвейер, тормозящий на a2000 (12GB GPU).

Приоритет: подкасты → видео.

Текст (уже работает)

• editor-pro → GEO → публикация
• низкая сложность

Подкасты (средняя сложность)

• ACE-Step 1.5 для музыки (~34s batch), Silero TTS для голоса
• GEO через транскрипт + метаданные
• GPU-нагрузка на a2000: одна операция за раз (не параллельно)

Видео (высокая сложность)

• генерация или сборка из стоков/скринов
• storage больших файлов (артефакты pipeline, не в статье)
• GEO: описание + теги + таймкоды (менее зрелый тренд)

Общие требования для мультимедиа:

• фоновые задачи с очередью (текст за секунды, видео/подкаст за минуты/часы)
• отдельный storage для аудио/видео артефактов
• разная логика GEO по сравнению с текстом

License

Приватный. Концепт: развитие editor-pro + GEO.