Контекст

Цель инфраструктурного проекта — не сделать ещё один конструктор сайтов и не стандартизировать все проекты под один стек. Нужна простая система, через которую сильный специалист и AI-agent могут полноценно работать как с новыми, так и с существующими сайтами.

Практика уже показывает, что технологическая неоднородность стала менее дорогой: MODX, Laravel, Ruby и другие проекты во многих случаях сводятся к задаче воспроизвести рабочее окружение и дать агенту инструменты для исследования и изменения. При этом опыт с современными AI-builders показывает обратную проблему: получить исходный код недостаточно, если данные, Auth, Storage, конфигурация и production lifecycle остаются неявными или привязанными к платформе.

Эта задача должна собрать инфраструктурные проблемы в один lifecycle, но не утверждать заранее конкретную архитектуру решения.

Желаемый жизненный цикл

В общих чертах система должна со временем позволять:

создать или принять проект -> воспроизвести -> понять -> изменить -> проверить -> развернуть -> наблюдать -> восстановить при необходимости -> передать владельцу

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

Основные направления

• воспроизводимое описание runtime;
• подключение существующего проекта;
• управление dev/stage/prod;
• состояние проекта помимо исходного кода;
• безопасный агентный цикл изменения;
• deploy и rollback;
• backup и восстановление;
• инфраструктурная наблюдаемость;
• переносимость и передача владельцу;
• секреты и внешние зависимости;
• ускоренный запуск новых сайтов.

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

Уже существующие части

Проект не начинается с нуля. Уже есть или исследуются минимальное управление проектами, Git, анализ TypeScript-кода, WorkLogs, логирование действий агента, MODX runtime и восстановление MODX из файлов/БД.

Новые задачи должны помогать связать эти primitives в рабочий инфраструктурный lifecycle, а не заменить их новым большим framework.

Принцип разработки

Система должна расти от конкретных потребностей. Если очередной проект показывает, что отсутствует определённый primitive, нужно понять проблему и добавить максимально понятный компонент. Не стоит заранее реализовывать универсальную платформу на все возможные случаи.

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