Почему я не верю зелёному статусу cron: проверяемый след AI-черновика

TL;DR: Я перестал считать зелёный статус cron доказательством того, что статья действительно готова. Теперь ежедневный агент обязан оставить три проверяемых следа: ID записи WordPress, прямую ссылку на черновик и строку в журнале тем — иначе запуск для меня не завершён.

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

Факт	Что это меняет в моей автоматизации	Источник
WordPress создаёт запись через POST /wp/v2/posts; у запроса есть отдельные поля статуса, рубрик и главного изображения.	Я передаю status: draft, categories: [73] и featured_media явно, а не надеюсь на настройки по умолчанию.	WordPress: Posts REST API
Медиафайл создаётся отдельным запросом POST /wp/v2/media.	Успешная загрузка обложки ещё не означает, что сама статья создана или что изображение прикреплено к ней.	WordPress: Media REST API
Application Password предназначен для программного доступа, может быть отозван отдельно и должен использоваться через HTTPS.	Агенту не нужен мой основной пароль от админки; сбой или отзыв отдельного ключа можно диагностировать независимо.	WordPress: Application Passwords
REST API использует HTTP-коды ошибок и JSON-ответы.	Я могу проверять не только завершение процесса, но и фактический ответ WordPress с созданным ресурсом.	WordPress: REST API Reference

Почему «скрипт отработал» — плохой критерий

Самая неприятная автоматизация ломается не громко. Она не падает с красным экраном, а выполняет восемь шагов из девяти и оставляет ощущение, что всё в порядке. Обложка могла загрузиться, а пост — нет. Пост мог создаться, но попасть в «Без рубрики». Запись могла получить ID, но не остаться черновиком.

Сегодняшний запуск снова напомнил мне об этом на простом примере. Генератор обложки четыре раза отвечал состоянием waiting и только на пятой проверке вернул success. Если бы я трактовал первый корректный HTTP-ответ как готовую картинку, следующему шагу просто нечего было бы загружать.

Поэтому мой критерий завершения теперь выглядит не как «процесс дошёл до конца файла», а как маленькая квитанция:

• WordPress вернул числовой post ID;
• повторное чтение этой записи показывает status: draft;
• в записи стоит рубрика 73 и задано главное изображение;
• из базового адреса сайта и ID собирается прямая ссылка на экран редактирования;
• тема добавлена в covered-topics.log только после успешной проверки.

Что именно я изменил в подходе

1. Разделил создание и проверку

Ответ на запрос создания — это важная квитанция, но я дополнительно перечитываю запись по её ID. Так я проверяю состояние уже сохранённого объекта, а не только то, что отправил в запросе. Это особенно полезно, когда плагины WordPress или серверные правила могут изменить данные.

2. Сделал итог понятным человеку

Лог из сотни технических строк почти бесполезен утром. В конце мне нужны тема, ID и кликабельный адрес черновика, плюс две-три фразы о содержании. Если этих данных нет, я не считаю запуск успешным — даже если код завершился с нулём.

3. Не записываю тему раньше времени

Журнал тем нужен, чтобы агент не повторялся и ротировал рубрики A → B → C → D → E. Если добавить строку до создания поста, неудачный запуск «съест» тему: черновика нет, а следующий агент решит, что статья уже написана. Поэтому журнал обновляется в самом конце.

4. Секреты и результат живут отдельно

В локальном .env лежат отдельные учётные данные для API, но в итоговый лог попадают только несекретные данные: тема, ID и адрес админки. Я намеренно не печатаю пароль приложения, ключ генератора изображений или любые токены. Лог должен помогать диагностике, а не превращаться во второе хранилище секретов.

Что всё ещё может сломаться

Эта схема не делает процесс неуязвимым. WordPress может принять медиа, а затем отклонить пост; сеть может оборваться после сохранения записи, но до получения ответа; SEO-метаполя могут не сохраниться, если конкретный плагин не открыл их для REST API. Поэтому следующий полезный шаг для меня — проверять не только базовые поля записи, но и те метаданные, которые реально возвращает сайт.

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

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

Разве кода завершения 0 недостаточно?

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

Почему обязательно выводить post ID?

ID — устойчивый идентификатор созданной записи. По нему можно перечитать объект через API, открыть точный черновик в админке и не перепутать его с похожим заголовком.

Зачем хранить отдельный журнал тем, если записи уже есть в WordPress?

Это дешёвая локальная память для ротации рубрик и защиты от повторов до сетевого запроса. Но WordPress остаётся источником правды о самом черновике, поэтому журнал обновляется только после успешного создания и проверки записи.

Почему агент не публикует статью сразу?

Потому что автоматизация готовит материал, а не принимает редакционное решение. Статус draft оставляет человеку контроль над фактами, формулировками и моментом публикации.

Можно ли считать ссылку на админку полноценным мониторингом?

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

Итог

Главный урок для меня простой: автоматизация закончена не тогда, когда исчез курсор в терминале, а когда появился проверяемый результат. Для ежедневного блога таким результатом служит черновик с конкретным ID, правильным статусом, рубрикой и обложкой; всё остальное — промежуточные сигналы.

---

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