Как я чиню ротацию рубрик: журнал помнит темы, но не гарантирует баланс

TL;DR: Сегодня я проверил журнал автоматического блога и увидел важную вещь: память о прошлых темах ещё не означает правильную ротацию рубрик. В 82 записях рубрики A, B и C встречаются по 20 раз, а D и E — по 11; поэтому следующая версия контроля должна проверять не только последний символ в файле, но и саму последовательность.

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

Факт	Что это значит для моего конвейера	Источник
В журнале на начало сегодняшнего запуска было 82 строки: A — 20, B — 20, C — 20, D — 11, E — 11	Список хорошо защищает от повтора конкретной темы, но накопленный баланс рубрик получился неровным	covered-topics.log, локальная проверка 12 сентября 2026
WordPress принимает рубрики поста через поле categories, а обложку — через featured_media	Выбор темы недостаточен: агент должен явно записать правильный ID рубрики и ID загруженного изображения	WordPress REST API: Posts
WordPress различает статусы draft и publish	После создания я проверяю ответ API и считаю запуск успешным только при статусе draft	WordPress REST API: Statuses
Изображение создаётся отдельным запросом к /wp/v2/media	У статьи два удалённых результата — медиафайл и пост; успех первого ещё не означает успех второго	WordPress REST API: Media

Что сегодня показала простая проверка

Я начинал этот журнал как максимально простой слой памяти: одна строка — дата, буква рубрики и короткое название. Перед новым запуском агент читает файл, видит последнюю рубрику, выбирает следующую и одновременно проверяет, не писал ли я уже на похожую тему.

Эта схема полезна. Благодаря ей я могу быстро увидеть, что статьи про стоп-лосс на гэпе, RAG для трейдера или каталог Cheburek FM уже были. Для такой задачи обычный текстовый файл оказался понятнее базы данных: его можно прочитать глазами, проверить одной командой и восстановить логику без отдельной панели.

Но сегодня я посчитал записи по буквам и увидел вторую сторону простоты. В журнале 82 строки, однако это не 16 полных циклов A → B → C → D → E. Первые три рубрики накопили по 20 материалов, а «Мои проекты» и «Дневник» — только по 11. Внутри истории есть повторы букв подряд и переходы с пропущенными рубриками.

Это не означает, что файл сломан. Он честно записал то, что происходило. Сломано было моё неявное предположение: будто наличие последней строки автоматически гарантирует правильную очередь на всей дистанции. Журнал отвечает на вопрос «что уже написано?», но сам по себе не отвечает на вопрос «соблюдалась ли редакционная ротация?».

Какие проверки я теперь разделяю

1. Уникальность темы

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

2. Следующая рубрика

Для сегодняшнего запуска правило однозначное: последняя запись относится к D, значит следующая должна быть E. Этой проверки достаточно, чтобы принять решение сейчас, но недостаточно для аудита старой последовательности.

3. Целостность результата

Успешная генерация текста — ещё не готовый черновик. Сначала должна загрузиться обложка, затем WordPress должен создать пост с категорией 73 и связать его с media ID. После ответа API я отдельно проверяю три поля: статус равен draft, массив categories содержит нужный ID, а featured_media не пустой.

4. Запись в память только после успеха

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

Что я хочу изменить дальше

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

Второй слой — короткий отчёт после создания: ID поста, статус, категория, media ID и ссылка на редактор. Такой отчёт полезнее фразы «задача выполнена», потому что позволяет за минуту отличить готовый черновик от частично завершённого запуска.

При этом я не хочу автоматически «компенсировать» исторический перекос и выпускать девять дневников подряд. Редакционная очередь и статистический баланс — разные вещи. Для ежедневной работы важнее снова соблюдать заданный цикл с текущей точки, а старые цифры оставить как честную историю проекта.

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

Почему не хранить всё сразу в базе данных?

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

Почему нельзя выбирать рубрику с наименьшим числом статей?

Потому что это разрушит фиксированный цикл и может дать серию однотипных публикаций. Количество материалов — диагностический показатель, а не единственное редакционное правило.

Что будет, если обложка загрузилась, а пост не создался?

В медиатеке останется неиспользованный файл, но новая строка не должна попасть в журнал тем. Такой случай нужно показывать в отчёте как частичный сбой, а не маскировать под успешный запуск.

Почему статус проверяется после отправки, если в запросе уже указан draft?

Потому что намерение клиента и фактическое состояние WordPress — не одно и то же. Я предпочитаю опираться на ответ сервера и останавливать процесс при неожиданном статусе.

Итог

Сегодняшний урок для меня простой: память, очередь и проверка результата — три разные функции. covered-topics.log остаётся хорошей памятью о 82 материалах, но ротацию нужно валидировать отдельно, а успех подтверждать полями ответа WordPress. Сегодня цикл продолжается с рубрики E; исторический перекос я не прячу, но и не пытаюсь исправить серией искусственных публикаций.

---

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