Context

The goal of the infrastructure project is not to build yet another website builder or standardize all projects under a single stack. We need a simple system through which a skilled specialist and an AI agent can fully work with both new and existing websites.

Practice already shows that technological heterogeneity has become less expensive: MODX, Laravel, Ruby, and other projects in many cases come down to the task of reproducing the working environment and giving the agent tools for exploration and modification. At the same time, experience with modern AI-builders shows the reverse problem: getting the source code is not enough if data, Auth, Storage, configuration, and production lifecycle remain implicit or tied to a platform.

This task should bring infrastructure problems into a single lifecycle, without pre-determining a specific solution architecture.

Desired Lifecycle

Broadly speaking, the system should eventually allow to:

create or accept a project -> reproduce -> understand -> modify -> verify -> deploy -> observe -> restore if necessary -> transfer to the owner

Specific technologies and the degree of automation for each step should be determined based on practical experience.

Main Directions

• reproducible runtime description;
• connecting an existing project;
• dev/stage/prod management;
• project state beyond source code;
• safe agent modification cycle;
• deploy and rollback;
• backup and recovery;
• infrastructure observability;
• portability and transfer to the owner;
• secrets and external dependencies;
• accelerated launch of new websites.

The future direction of portfolio management for multiple projects is noted separately, but it is not the current main line. First, we need to create a good lifecycle for a single project; centralized orchestration should emerge later from real repetitive operations.

Existing Parts

The project does not start from scratch. We already have or are researching minimal project management, Git, TypeScript code analysis, WorkLogs, agent action logging, MODX runtime, and MODX recovery from files/DB.

New tasks should help tie these primitives into a working infrastructure lifecycle, rather than replace them with a new large framework.

Development Principle

The system must grow from concrete needs. If a particular project shows that a certain primitive is missing, we need to understand the problem and add the most straightforward component possible. One should not implement a universal platform for all possible cases in advance.

The criterion of success is not the number of supported technologies or functions, but the reduction of the human cost of launching and maintaining real projects while preserving clarity, reproducibility, and the owner's freedom.