День 7 - Настроил Codex и подключил его к проекту

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

Что именно сделал

1. Подключил Codex к текущему серверу по SSH (site) и проверил фактический доступ.
2. Прошел по рабочим каталогам проекта:
3. /opt/homelab-site
4. /opt/homelab-app
5. Разобрал реальный пайплайн публикации, который уже используется в проде:
6. render_post.py <input.md> <output.html>
7. update_posts_index.py
8. publish.sh
9. Проверил связанные компоненты, от которых зависит стабильность:
10. server.js
11. rebuild_all.sh
12. render_md.py, render_homepage.py
13. update_notes_index.py, update_homepage_lists.py
14. шаблоны и ассеты
15. systemd-юнит homelab-app.service
16. nginx-конфиг домена homelab.kobelkov.ru

Что понял по архитектуре

Сайт работает как связка Node.js + статическая генерация HTML:

Схема: компоненты и связи

Internet
  |
  v
nginx (TLS + BasicAuth zones)
  | proxy -> 127.0.0.1:3000
  v
node/express (homelab-app)
  | serves static from /opt/homelab-site
  | APIs: /addpost, /edit, /api/edit, /api/delete
  v
static html + assets

publish pipeline:
  posts/*.md -> render_post.py -> posts/*.html
            -> update_posts_index.py -> posts/index.html + index.json
            -> publish.sh -> systemd/nginx reload

• Node-приложение (/opt/homelab-app/server.js) слушает 127.0.0.1:3000.
• Nginx проксирует внешний трафик на этот backend.
• Контент хранится в markdown (posts/*.md, notes/*.md) и рендерится в HTML Python-скриптами.
• Индексы и главная обновляются отдельными утилитами.

Это хороший гибрид: просто сопровождать, быстро публиковать, легко откатывать через git.

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

1. Пишется markdown-файл поста.
2. render_post.py генерирует HTML поста.
3. update_posts_index.py обновляет список постов.
4. publish.sh дособирает остальное, коммитит изменения и применяет публикацию.

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

Почему это важно

Раньше сайт уже падал из-за типичных операционных ошибок:

• неверные права
• запуск не тем пользователем
• рискованные правки backend
• невалидный markdown
• неосторожные изменения главной
• запуск публикации из web-запроса без защиты

Поэтому приоритет теперь такой:

1. безопасность,
2. предсказуемость,
3. минимальные обратимые изменения.

Что дальше

Дальше работа в режиме сопровождения:

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

Если есть несколько вариантов, выбираем самый консервативный. Цель — стабильный сайт, а не «громкая переделка».