Build-in-public: как две автоматизации чуть не опубликовали черновик без проверки

TL;DR: В моём AI-конвейере обнаружилась гонка: контент-агент создал черновик, а отдельный approval-процесс успел изменить его статус до завершения контрольной проверки. Сбой показал простую вещь: успешный ответ API — ещё не финальное состояние, если одну запись меняют несколько автоматизаций.

Ключевые факты

Факт	Что это значит на практике	Источник
21 августа 2026 года запись №931 была создана со статусом draft, но между контрольными запросами внешний процесс перевёл её в publish; агент вернул запись в draft	Два корректно работающих процесса могут дать некорректный общий результат, если меняют один объект без координации	Локальный журнал запуска cron.log, записи по посту №931
WordPress REST API позволяет передавать для записи статусы publish, future, draft, pending и private	Статус — обычное изменяемое поле записи; другой авторизованный процесс может обновить его отдельным запросом	WordPress REST API Handbook: Posts
Для внешних скриптов WordPress поддерживает отдельные пароли приложений и Basic Auth через HTTPS	Интеграциям не нужен основной пароль пользователя; доступ каждого процесса можно отдельно отозвать	WordPress: Application Passwords
Публичность статуса описывается отдельным признаком public	Проверять нужно не только наличие записи, но и её фактический статус после всех автоматических действий	WordPress REST API Handbook: Statuses

Что именно сломалось

Мой ежедневный агент не должен публиковать статьи. Его зона ответственности заканчивается на черновике: выбрать новую тему, собрать источники, подготовить HTML и обложку, загрузить всё в WordPress и поставить правильную рубрику. Дальше работает отдельный approval-процесс.

21 августа цепочка выглядела нормально. Агент отправил в WordPress запись №931 с явным status: draft. Первый ответ подтвердил: запись существует, категория и обложка назначены, SEO-поля сохранены. Но при следующей проверке статус уже оказался publish. Между этими двумя чтениями запись успела попасть в другой процесс.

Это важное различие: контент-агент не отправлял команду публикации, и каждый компонент по отдельности мог считать, что действует правильно. Ошибка возникла на стыке — один процесс ещё проверял результат, а второй уже воспринял новый черновик как готовый вход.

Что я изменил в логике контроля

1. Проверяю состояние после записи, а не доверяю только ответу на создание

Ответ на POST говорит, что WordPress принял запрос в конкретный момент. Он не гарантирует, что через секунду другой скрипт не изменит запись. Поэтому после создания я отдельно читаю пост в контексте редактирования и проверяю минимум четыре поля: status, categories, featured_media и SEO-метаданные.

2. Считаю статус частью результата, а не технической мелочью

Раньше главным результатом для меня были текст, обложка и ID поста. Теперь результат считается корректным только тогда, когда WordPress подтверждает именно draft. Если статус другой, запуск нельзя помечать успешным, даже если сам текст идеален.

3. Разделяю права и ответственность процессов

У контент-агента есть одно правило: он создаёт только черновик и не отправляет сообщения в Telegram или соцсети. Решение о публикации принадлежит другому контуру. Практический следующий шаг для такой архитектуры — не только разделять скрипты логически, но и давать им отдельные учётные данные и максимально узкие права. Тогда в журнале проще понять, какой процесс и когда изменил запись, а скомпрометированный ключ можно отозвать отдельно.

4. Убираю двусмысленный сигнал «новый черновик значит одобрено»

Сам факт появления draft не должен быть разрешением на публикацию. Черновик означает только «материал создан». Для передачи дальше нужен отдельный однозначный признак одобрения: ручное действие, специальный статус или служебное поле. Иначе скорость опроса превращается в лотерею — какой процесс первым успел увидеть запись.

Честно: текущий инцидент я погасил реактивно — вернул пост в черновики и снова проверил состояние. Это сработало для конкретной записи, но не является полной защитой от повторения. Надёжное исправление должно находиться в протоколе взаимодействия двух процессов, а не в ещё одном цикле перепроверок.

Частые вопросы (FAQ)

Разве status: draft в запросе не гарантирует, что статья останется черновиком?

Он гарантирует статус в момент успешного выполнения этого запроса. Если у другого авторизованного процесса есть право обновить тот же пост, он может изменить статус следующим запросом.

Почему просто не отключить approval-процесс?

Потому что сама идея разделения полезна: один контур готовит материал, другой управляет одобрением и дальнейшими действиями. Исправлять нужно условие передачи между ними, чтобы новый черновик не считался автоматически одобренным.

Достаточно ли одной повторной проверки статуса?

Нет. Она помогает обнаружить часть сбоев, но между любой проверкой и следующим действием остаётся временное окно. Нужен явный сигнал одобрения и правило, по которому только один процесс отвечает за переход в публикацию.

Зачем отдельные пароли приложений?

Так проще ограничивать и отзывать доступ интеграций, не раскрывая основной пароль. Это также делает архитектуру понятнее: у каждого автоматического процесса должна быть собственная техническая идентичность.

Итог

Главный урок этого запуска не в том, что WordPress или автоматизация «ненадёжны». Проблема была в моём контракте между двумя процессами: один ещё завершал создание черновика, а второй уже считал его готовым к следующему шагу. Теперь мой критерий успеха жёстче: статья должна не просто появиться в WordPress, а остаться черновиком с правильной категорией, обложкой и метаданными; публикация требует отдельного, недвусмысленного разрешения.

---

Автор: Denis | Дата: 2026-09-07 | Обновлено: 2026-09-07
Denis — трейдер с 10+ летним опытом на форексе и крипторынках