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

Последний успешный полный workflow перед запуском новой схемы шёл 12 минут 53 секунды. Для изменений в коде это нормально. Для исправленной запятой — слишком долго.

Я разделил два разных выпуска

Полный деплой остался для кода, конфигурации и смешанных изменений. Для статей я сделал отдельный путь, который принимает только Markdown блога и не пересобирает всё приложение.

Это не сокращённая версия обычного деплоя. Быстрый путь работает с отдельной проекцией контента, проверяет точный Git-коммит и переключает новую версию целиком. Если что-то идёт не так, сайт возвращается к предыдущему состоянию.

Как устроен быстрый путь

Я добавил три компонента:

Главная страница, список блога, сама статья и sitemap должны видеть один и тот же набор материалов. Простого копирования .md на сервер для этого недостаточно: основное приложение продолжит работать с данными и HTML из прежней сборки.

Поэтому renderer читает полный снимок блога из Git и создаёт новую проекцию. Gateway использует её только для маршрутов из строгого списка. Административные страницы, API, неизвестные URL и методы кроме GET и HEAD остаются на основном приложении.

Промпт: спроектировать быстрый путь для контента

Я хочу отделить публикацию Markdown-статей от полного деплоя Nuxt-сайта.

Сначала изучи текущий проект и установи:
- откуда build и runtime получают статьи;
- какие страницы, списки, API и sitemap зависят от блога;
- какие prerender-артефакты и кеши создаёт Nuxt;
- как сейчас устроены deploy, rollback и production-проверки.

После этого предложи минимальную архитектуру быстрого выпуска.
Она должна:
1. Принимать только полный 40-символьный Git SHA.
2. Разрешать только датированные Markdown-файлы блога.
3. Отклонять пустые, смешанные и неизвестные изменения.
4. Переключать полный неизменяемый снимок контента атомарно.
5. Сохранять согласованность статьи, списка блога, API и sitemap.
6. Возвращать предыдущий SHA и активный снимок при ошибке.

Ограничения:
- Не меняй код и production-инфраструктуру на этапе анализа.
- Не считай, что удаление prerender-файла автоматически включает SSR.
- Не ослабляй доступ к административным маршрутам и внутренним API.
- Не выдавай предполагаемую скорость за измеренный результат.

Формат ответа:
1. Текущий путь публикации.
2. Границы быстрого выпуска.
3. Предлагаемая архитектура.
4. Сценарии отказа и rollback.
5. План тестов и production-приёмки.
6. Открытые вопросы перед реализацией.

Как теперь публикуется статья

Быстрый выпуск получает полный 40-символьный SHA и выполняет несколько шагов:

1. Проверяет, что коммит совпадает с вершиной origin/main.

2. Подтверждает, что во всём наборе изменений есть только разрешённые Markdown-файлы.

3. Формирует полную проекцию блога для выбранного SHA.

4. Записывает её в неизменяемый файл.

5. Атомарно переключает активный указатель.

6. Открывает главную, блог, sitemap и изменённые статьи через HTTP.

Перед началом скрипт сохраняет исходный SHA и прежний активный указатель. Если синхронизация или HTTP-проверка завершается ошибкой, он возвращает оба значения назад. Читатель видит либо предыдущую целую версию сайта, либо новую.

Промпт: проверить выпуск перед подтверждением успеха

Проверь завершившийся content-only выпуск независимо от отчёта deploy-скрипта.

Входные данные:
- ожидаемый полный Git SHA: [SHA];
- список изменённых статей: [ФАЙЛЫ И URL];
- production host и публичный домен: [ЗНАЧЕНИЯ];
- имена основного приложения, renderer и gateway: [ИМЕНА].

Проверки:
1. Сверь ожидаемый SHA с `origin/main`, production HEAD
   и активным указателем контента.
2. Подтверди чистое состояние production checkout.
3. Открой изменённые статьи, главную, список блога, API и sitemap.
4. Для статьи проверь HTTP 200, заголовок, canonical, description,
   Open Graph и JSON-LD в полном HTML.
5. Сравни PID и счётчики перезапусков процессов до и после выпуска.
6. Убедись, что gateway отвечает через production-маршрут,
   а неизвестные и внутренние URL не перехвачены быстрым слоем.

Правила:
- Не считай статус workflow достаточным доказательством публикации.
- Не выводи секреты, environment и connection strings.
- Не исправляй production во время проверки.
- Если хотя бы одна обязательная проверка не прошла,
  не объявляй успех: покажи evidence и безопасный rollback.

Формат ответа:
1. Exact SHA и состояние Git.
2. Результаты HTTP-проверок.
3. Состояние процессов.
4. Проверка границ маршрутизации.
5. Итог: принят, отклонён или требуется rollback.

Где проходит граница

Быстрый путь разрешает добавлять, изменять и удалять только датированные файлы content/blog/*.md. Он проверяет весь diff от активной production-версии до запрошенного коммита.

Переименование, копирование, пустой diff, изменение кода или смешанный набор файлов отправляются в полный деплой. Если классификатор не может доказать, что перед ним только статьи, ускорения не будет.

Это ограничение важнее самой скорости. Без него отдельный путь постепенно превратился бы в запасной деплой для любых изменений.

Эта статья стала проверкой нового пути

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

Черновик родился в той же рабочей сессии с AI-агентом, где я вводил новую схему в production. В контексте ещё оставались исходная задача, неудачные проверки, откаты, команды и фактическая приёмка. Из этого журнала я собрал последовательный рассказ, а код и логи не позволили приписать системе то, чего она ещё не доказала.

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

Что показала первая публикация

Первый успешный выпуск этой статьи занял 21 секунду по времени GitHub Actions. Сам production-скрипт от начала проверки до завершения локальной приёмки отработал за 13,36 секунды.

Для сравнения я беру одинаковую внешнюю границу — длительность job в GitHub Actions. Полный workflow шёл 12 минут 53 секунды, быстрый — 21 секунду. В этой публикации выпуск ускорился в 36,8 раза.

Основной Nuxt-процесс, renderer и gateway не перезапускались: их PID и счётчики перезапусков до и после совпали. При этом сохранились проверка точного SHA, контроль набора файлов, согласованность маршрутов, HTTP-приёмка и автоматический откат.

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

Эта статья стала первой принятой проверкой быстрого пути. Два следующих обновления того же Markdown также прошли без полной сборки и перезапуска процессов. Быстрый выпуск теперь обслуживает обычные правки статей, а полный деплой остаётся для изменений в коде и включает актуальный контент в основной Nuxt-артефакт.

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