Pushkin Editorial Site

Идея зафиксирована 2 мая 2026. Не делаем сейчас — после стабилизации Lyumi v4 (Sprint 1 + observation week до 9 мая).

Зачем

Сейчас Pushkin = один линейный pipeline: research → writer → fact-check → publish → Telegram. Telegram сразу = output.

Хочется превратить Pushkin в редакцию с разделением ролей:

Pushkin = junior writer (генерит черновик)
Wiki = editorial board (хранит, версионирует, single source of truth)
Камал + Claude = senior editor (ревью, правки, approve)
Telegram канал = output (только после approve)

Telegram — outside, не часть редакции. Внутренний контур — wiki + сайт + я.

Что должен уметь сайт

MVP (3-5 дней работы)

Kanban доска drafts: idea → researching → writing → review → approved → scheduled → published
Превью поста как он будет выглядеть в TG (markdown + эмодзи + картинка)
Inline edit в браузере (Markdown editor)
Кнопки: Approve / Reject / Edit / Regenerate
Календарь публикаций — когда что выходит
Backlog тем на неделю/месяц вперёд

v2 (по желанию)

Diff между версиями: Outline (Gemini) → Draft (Opus) → Edit (Sonnet) → Polish (Opus)
Trigger-кнопки: regenerate, change tone, change image
Аналитика постов: реакции, репосты, отписки после конкретного поста
Multi-author support (если когда-нибудь будет команда)

Архитектура — критичный выбор

Backend = wiki через wiki_write, не отдельная SQLite.

Почему: - Pushkin уже пишет в wiki через kb_api bridge - Claude имеет прямой wiki доступ — может ревьюить вместе с Камалом - Cowork имеет тот же доступ - Никакого нового узла в системе — встраивается в существующий контур - Wiki history даёт версионирование бесплатно

Если backend = отдельная SQLite — фрагментация, два source of truth, лишняя работа на синхронизацию.

Стек

Frontend: Next.js + Tailwind + shadcn/ui (готовый визуал)
Backend: FastAPI поверх существующего Pushkin Python кода + wiki_write/wiki_read
Auth: Telegram Login Widget (один клик через TG, без паролей)
Hosting: на том же AX41 (уже стоит, Caddy SSL уже работает)
Storage: wiki как single source of truth (pushkin/drafts/<date>-<slug>.md)

Workflow

[Идея темы]
    ↓
  Pushkin читает backlog в wiki → выбирает тему
    ↓
  Pushkin pipeline: research → writer → fact-check
    ↓
  Draft записывается в wiki: pushkin/drafts/2026-05-XX-topic.md
  Frontmatter: status: pending_review
    ↓
  Notification в TG-бот: "готов draft, [link to site]"
    ↓
  Камал на сайте видит draft, превью как TG-пост, можно:
    - Approve → Pushkin читает status: approved → публикует в TG
    - Edit → правит → save → status: pending_review снова
    - Reject → status: rejected, в архив
    - Regenerate → trigger Pushkin pipeline на новую попытку
    ↓
  После publish: status: published, ссылка на TG-пост, метрики позже подтягиваются

Почему именно сайт, а не TG-бот для редакции

TG плохо подходит для редакторской работы: - Нет версий, нет статусов, нет ревью "вернуться через час и доточить" - Нет diff между draft v1 и v2 - Нет визуального календаря - Нет drag-n-drop kanban

Сайт даёт всё это + он специализирован под один workflow (редакция Pushkin), не общий портал ко всем инструментам.

Phasing

Phase 0 (можно уже сейчас, 1-2 часа): - Pushkin продолжает auto-publish как обычно - НО параллельно копирует draft в wiki (pushkin/drafts/auto/.md) для архива - Это non-breaking change — ничего не ломается, Claude начинает видеть драфты

Phase 1 (3-5 дней, после Lyumi v4 стабилизирован): - Сайт MVP: kanban + превью + approve - Pushkin переходит в draft mode: пишет в wiki со status pending_review - TG канал получает пост ТОЛЬКО после approve

Phase 2 (когда привычка сформировалась): - Inline edit, diff между версиями, trigger-кнопки - Календарь публикаций - Backlog тем

Phase 3 (далеко): - Аналитика постов - Editorial board: несколько Pushkin'ов в разных стилях - Cross-checking между Pushkin и Lyumi (если факт в посте противоречит SQL — alert)

Критичный вопрос для решения

Когда Pushkin переходит в draft mode (Phase 1) — нужно активно ревьюить, иначе посты не выходят. Это меняет workflow Камала: придётся регулярно ревьюить, иначе канал замолкает.

Риск: пропустил день — нет публикации. Текущий auto-publish не имеет этой проблемы.

Варианты: - Auto-approve fallback: если draft pending_review больше N часов и Камал не ответил — публикуется автоматически (с notification "опубликовали без твоего ревью") - Confidence threshold: если Pushkin внутренний confidence high — auto-publish; если low — review - Только новые форматы через review: обычные дайджесты auto-publish, эксперименты через review

Решение по этому вопросу — в Phase 1 startup, не сейчас.

Не делаем

НЕ делаем общий портал ко всем инструментам Lyumi/Pushkin/wiki/Notes — это overkill, fragmentation
НЕ делаем Notion-интеграцию — wiki уже есть, не дублировать
НЕ делаем сейчас, до стабилизации Lyumi v4 (Sprint 1 + observation до 9 мая)

Связи

[[lyumi/pushkin]] — текущая архитектура Pushkin
[[lyumi/v4_structured_retrieval]] — архитектурный sprint 1 мая
[[lyumi/strategy_2026]] — общая стратегия
[[lyumi/sprints/2026-05-01-sql-acgih-ax41]] — последний sprint summary