Этот материал не «теория про ИИ». Это практический разбор конкретной рабочей сессии, где мы последовательно вели блог на Hugo через Codex CLI: писали новые статьи, чинили продовые проблемы, настраивали тему и закрепляли правила процесса.

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

Исходный контекст #

На старте у нас уже был рабочий блог на Hugo с темой typo, CI/CD через Forgejo Actions и поиском на Pagefind.

Дальше в рамках одной непрерывной сессии мы сделали:

1. Написали и опубликовали новый пост про Hugo 0.157.0.
2. Поймали проблему с невидимостью поста из-за времени публикации.
3. Добавили правила в AGENTS.md, чтобы больше не ловить future-ошибки.
4. Настроили и протестировали подсветку кода (в итоге перешли на dracula).
5. Привели к dracula цвета выдачи поиска.
6. Исправили некорректные заголовки в Pagefind (вместо названия поста показывалось имя сайта).
7. Структурировали README.md и AGENTS.md как рабочую документацию процесса.

То есть это уже не «написать один пост», а полноценный операционный цикл контентного проекта.

Как выглядел рабочий цикл с Codex CLI #

Самый полезный паттерн из этой сессии:

1. Чёткая постановка задачи #

Каждый шаг формулировался как конкретный результат:

• «Напиши новую статью про релиз».
• «Почему статья не видна? Исправь».
• «Сделай правило, чтобы проблема не повторялась».
• «Сделай тему поиска в dracula».

Чем конкретнее цель, тем меньше «творческого шума» и выше скорость прохождения задачи.

2. Локальная диагностика перед правкой #

Перед изменением файлов Codex проходил короткий аудит:

• чтение текущих шаблонов/конфигов;
• проверка фактического рендера;
• сверка с реальным поведением сайта;
• поиск причинно-следственной связи, а не симптомов.

Пример мышления: если цвета не применились, сначала проверить порядок подключения CSS, а не сразу «добавить ещё !important».

3. Точечная правка + обязательная валидация #

После каждого изменения шёл одинаковый технический минимум:

hugo list future
hugo --minify
git status --short

Это сильно снижает вероятность того, что в main улетит «логически верно, но технически сыро».

4. Фиксация в git маленькими коммитами #

Вместо одного гигантского коммита по итогам сессии:

• каждый смысловой шаг фиксировался отдельно;
• сообщения коммитов были предметными;
• любой этап можно быстро отследить и откатить локально при необходимости.

Для блога это особенно удобно: контент, стили, шаблоны и правила не смешиваются в «одно большое изменение».

Реальные проблемы, которые мы поймали и закрыли #

Проблема 1: пост «не видно на сайте» #

Симптом: статья есть в репозитории, но не отображается в списке публикаций.

Причина: date в фронтматтере оказался в будущем относительно московского времени на момент деплоя.

Решение:

• сдвиг даты в прошлое;
• проверка hugo list future;
• фиксация правила в AGENTS.md: новые посты ставить на 5-10 минут в прошлое и всегда проверять future-список перед коммитом.

Ключевой эффект: проблема устранена один раз на уровне процесса, а не «подкручена вручную» только для одного поста.

Проблема 2: подсветка кода «всё одним цветом» #

Симптом: HTML уже содержит chroma-классы, но визуально код почти монохромный.

Причина: базовый файл подсветки темы был близок к bw-палитре.

Решение:

1. Включили работу через CSS-классы (noClasses = false).
2. Добавили собственный assets/css/syntax-highlighting.css.
3. Сначала проверили monokai, затем переключили на dracula.

Итог: читаемая цветная подсветка с контролируемой темой в репозитории.

Проблема 3: выдача поиска не в стиле сайта #

Симптом: поле и результаты поиска выпадали из общей цветовой схемы.

Причина: стили Pagefind подключались после custom.css, и часть переопределений не применялась.

Решение:

• сначала добавили CSS-переменные Pagefind в custom.css;
• затем сделали гарантированное переопределение после pagefind-ui.css прямо в шаблоне layouts/search/single.html.

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

Проблема 4: у результатов поиска заголовок «Evgeny Kushnarenko» #

Симптом: каждая найденная строка в выдаче имела одинаковый title (имя сайта).

Причина: Pagefind подхватывал h1 из шапки страницы.

Решение:

• вынесли локальный layouts/partials/header.html и пометили шапку data-pagefind-ignore;
• добавили data-pagefind-meta="title" на h1 поста в layouts/_default/single.html.

Итог: выдача начала показывать реальные заголовки материалов.

Что это даёт в ежедневной работе #

После такого цикла становится заметно:

1. Время между идеей и публикацией сокращается.
2. Ошибки переходят из категории «случайные и повторяющиеся» в «редкие и диагностируемые».
3. Репозиторий становится документацией процесса, а не просто папкой с контентом.
4. Снижается когнитивная нагрузка на автора: меньше ручной рутины, больше фокуса на смысле.

На длинной дистанции это важнее, чем «сэкономить 5 минут на одной статье».

Практический шаблон автоматизации под Hugo #

Если хотите повторить подход, можно взять такой минимум:

1. Для каждой задачи: цель в 1-2 предложениях.
2. Перед правкой: чтение текущего состояния (rg, sed, шаблоны, конфиги).
3. После правки: hugo list future + hugo --minify.
4. Фиксация: один смысл = один коммит.
5. Публикация: git push сразу после проверки.
6. Если баг повторяемый: правило в AGENTS.md, а не «устная договорённость».

Набор команд, который реально работал в этой сессии #

# Проверки контента и даты
hugo list future
hugo --minify

# Диагностика
rg -n "pagefind|highlight|chroma" -S .
sed -n '1,220p' layouts/search/single.html

# Публикация
git add <файлы>
git commit -m "Осмысленный коммит по одной задаче"
git push

Никакой экзотики: сила не в сложных командах, а в дисциплине последовательности.

Практические выводы #

Автоматизация блога через Codex CLI работает лучше всего, когда вы относитесь к ней как к инженерному процессу:

1. Чёткая постановка задач.
2. Наблюдаемость и проверки после каждого шага.
3. Маленькие коммиты с понятной ответственностью.
4. Фиксация правил в репозитории.

Тогда Codex становится не «генератором текста», а операционным партнёром, который помогает держать качество и темп публикаций одновременно. ✅