Почему ArticleFactory должен быть диспетчером, а не вторым редактором
Когда автоматизация начинает работать хорошо, у нее появляется опасное желание стать всем сразу. Она уже умеет принять тему, написать текст, сделать обложку, опубликовать статью, поставить посты в Telegram и VK, проверить очередь и обновить статусы. На первый взгляд это удобно: меньше ручных шагов, быстрее публикации, больше ощущения живого завода.
Но именно здесь production-процесс чаще всего начинает расползаться. Если один и тот же контур и пишет, и рисует, и публикует, и сам себя спасает fallback-решениями, качество становится неуправляемым. Вчера он сделал хорошую обложку. Сегодня не нашел media package и нарисовал декоративные кубики. Завтра текст стал коротким, но очередь всё равно пополнилась. Формально завод работает. По смыслу он уже перешел границу ответственности.
Поэтому ArticleFactory должен быть диспетчером, а не вторым редактором. Его сила не в том, чтобы творить качество. Его сила в другом: взять готовый проверенный пакет, опубликовать его, поставить социальные посты в очередь, сохранить статусы и не врать, если что-то заблокировано.
OpenAI в материале про Codex app говорит о Codex как о командном центре для агентов, навыков, автоматизаций и долгих задач. В Codex Automations отдельно видна идея фоновой регулярной работы: можно запускать задачи по расписанию и получать результат без постоянного ручного пинка. Но для бизнеса это работает только при ясном разделении ролей. Автоматизация должна знать, где она выполняет работу, а где только переносит готовый результат дальше.
Почему fallback опасен
Fallback кажется заботой о процессе. Нет картинки — сгенерируем временную. Нет проверки — пропустим, потом поправим. Не удалось красиво оформить — поставим старый шаблон. Для очереди это удобно: публикация не останавливается. Для качества это почти всегда вредно.
Проблема в том, что fallback скрывает ответственность. Если ArticleFactory сам придумал обложку, кто отвечает за визуальный язык? Если он сам «улучшил» текст, кто отвечает за редакционный тон? Если он сам решил, что публикация достаточно хороша, где человеческая приемка? В итоге система становится быстрой, но мутной.
Для ONFF мы уже увидели этот риск на визуалах. ArticleFactory как hosted engine был полезен как временный технический контур. Но как только он начал восприниматься как production renderer, качество ушло в сторону: изображения стали похожими, слишком абстрактными, с визуальными решениями, которые не несут мысль статьи. Поэтому новое правило жесткое: Codex skill создает и проверяет визуал; Langfuse хранит версии промптов; ArticleFactory получает только готовый media package.
Роли в нормальном контуре
| Участник | Что делает | Что не должен делать |
|---|---|---|
| Codex skill | пишет, генерирует визуал, делает QA, собирает пакет | скрывать fallback или публиковать без проверки |
| Langfuse | хранит версии промптов и trace | быть редактором или художником |
| ArticleFactory | публикует готовое, ставит соцсети в очередь, хранит статусы | писать статью, рисовать обложку, чинить качество по дороге |
| Человек | утверждает границы, active-версии, публикационное решение | вручную помнить все технические детали |
Такой контур выглядит строже, но на самом деле он проще. Если статья не готова, она не публикуется. Если визуала нет, она блокируется по media. Если review gate не прошел, social handoff не запускается. Если очередь пустая, автоматизация честно говорит: нужен новый пакет, а не имитирует работу случайным контентом.
Что должен содержать готовый пакет
ArticleFactory должен принимать не «тему» и не «примерный текст», а пакет. Для статьи это может быть:
draft.md— только читательский текст, без SEO-меток и внутренних заметок;seo_fields.yaml— заголовок, slug, meta title, meta description, excerpt, tags;media_manifest.yaml— кто создал визуал, какой backend, prompt id, prompt version, source image, final GIF или image, QA status;AUDIT.md— что проверено до публикации;PUBLISH_LOG.yaml— что опубликовано, куда поставлено в очередь, какие job ids получены;VERIFICATION.md— live URL, homepage/card check, public-body audit.
Когда такой пакет готов, ArticleFactory становится сильным диспетчером. Он не спорит с редакцией, не изобретает картинку, не переписывает смысл. Он делает то, что у очереди получается лучше всего: доставляет готовый материал в нужные каналы и возвращает статусы.
Рабочее правило для владельца проекта
Перед публикацией проверь пакет.
1. Есть ли reader-visible draft.md без служебных меток?
2. Есть ли seo_fields.yaml?
3. Есть ли media_manifest.yaml с visual_owner: codex_skill?
4. Есть ли verified source image или final GIF?
5. Пройден ли ARTICLE_TEXT_REVIEW?
6. После публикации пройден ли LIVE_PUBLIC_BODY_AUDIT?
7. Только после этого можно ставить Telegram/VK/Dzen в очередь.
Если один из пунктов отсутствует, не проси фабрику «как-нибудь допридумать».
Блокируй пакет и верни его в нужную студию: текст, визуал или проверка.Это правило особенно важно для не-программиста. Ему не нужно знать, как устроен воркер, API или очередь. Ему нужно видеть управленческую картину: кто создал качество, кто проверил, кто доставил и где остановка.
Где здесь ценность для бизнеса
Бизнесу не нужен «умный завод», который сам принимает творческие решения в темноте. Бизнесу нужен контур, где качество создается в понятном месте, версии промптов управляются отдельно, публикация идет по расписанию, а статусы видны.
ArticleFactory как диспетчер — это не понижение роли. Это взрослая роль. Диспетчер не обязан быть автором статьи, дизайнером и редактором. Он обязан не потерять готовый пакет, не перепутать каналы, не создать дубль, не отправить недопроверенное, не назвать scheduled пост sent и не спрятать сбой.
Когда эта граница соблюдается, Codex skills могут становиться настоящими производственными студиями: одна пишет, другая делает визуал, третья проверяет SEO, четвертая собирает клиентский пакет. Langfuse хранит версии промптов. ArticleFactory держит очередь и доставку. Человек принимает решения. И только в такой архитектуре автоматизация перестает быть хаотичным набором хороших скриптов и становится управляемым производством.
