Как устроена публикация в этом блоге — один git-коммит вместо CMS

У этого блога нет админки, логина и кнопки «опубликовать». Вместо этого — папка src/content/articles/ в git-репозитории и обычный git push.

Как это работает

Статья пишется как MDX-файл — это markdown с фронтматтером (заголовок, описание, дата, теги) сверху.
Файл коммитится в репозиторий на GitHub.
Vercel подхватывает пуш и пересобирает сайт автоматически — статическая сборка на Astro, без сервера и базы данных под статьи.
Сборка сама обновляет список статей, страницу статьи и sitemap — руками ничего не трогаю.

Итог: «опубликовать» — это буквально git commit + git push. Черновик просто лежит с draft: true в фронтматтере и не попадает в сборку, пока флаг не снят.

Почему не обычная CMS

Мне не нужна отдельная база данных ради десятка статей, и не нужен ещё один логин/пароль, который будут воровать боты. Весь контент — текстовые файлы, у которых есть история изменений (это и есть git), бэкап (это тоже git — репозиторий целиком) и возможность откатить правку одной командой.

Плюс это ровно та же модель, по которой я уже пишу посты в Telegram-канал и сценарии для агентов — весь контент-конвейер живёт в одном формате, а не размазан по трём разным интерфейсам.

Где здесь агент

Сама статья чаще всего не написана мной с нуля — черновик собирает контент-агент по банку тем (что важно сказать, какой сегмент читателя, какой тон), я его правлю и коммичу. Технически агенту для «публикации» не нужно ничего, кроме доступа к репозиторию — ни API, ни кнопок в интерфейсе. Это и есть весь смысл git-based подхода: публикация — это просто ещё один файл в папке, а не отдельная система, которую надо переизобретать для агента.