AI-powered web development platform

I have previously had two similar projects with their own pros and cons. I need to dig up both of them and put together a new template based on a haih agent.

Expand template

I've been thinking a lot about different mechanics in this direction, and so far using a TypeScript server seems like the most promising approach. Why? Because then we can operate not just with the files themselves and read them individually, but also analyze their dependencies. For example, we tell the agent to examine some component. It can simply use a special tool to get the entities that are there (variables, functions, imports, exports, etc.), as well as easily request the additional dependencies it needs without worrying about where they are located. But if it needs the final code of the required dependency, it can easily find out which file it is in and read it.&#x20;

Along the way, we probably need tools for reading files with a specified line range. After all, a code file can be large, and if TS immediately gives us information not only on where it is located, but also in which line range, we don't necessarily have to read the entire file.

Add code analysis features

It is necessary to provide a minimal project lifecycle:

* Creation from scratch or cloning of repository/repositories
* Launching separate environments (dev/stage/prod)
* Maintaining a single project knowledge base

Add minimal project management functionality

Need to see the project state, which files have been modified, commit, etc.
Without this, the agent simply cannot know what has already been done for the task and what hasn't.&#x20;

Need to add a Git integration resolver

Currently, the agent often forgets to log workloads, including what was done, how, and for which task, or records very little information. Instead, it simply tells the user about it verbally.

This is especially critical in research tasks, where it has to perform experimental actions and it is necessary to know exactly what it did, along with example queries, etc.

We haven't decided yet which exact tool to use for this, but there are several options. The most promising seems to be a post-agent that, after the response is completed, will look at what the user said, what the agent did, and log a complete report. However, this still leaves room for inaction. Alternatively, we could add stronger debugging directly into the tools themselves. We already have a reasoning field there where the agent indicates what and why it is doing, i.e., explaining why it is executing this tool. We could also add a task ID field, and if it is specified, automatically log the results. But this might turn out to be redundant.

We can also rely on the fact that the URL of the page from which the write is being made is passed in every request. If we are on a task page, this is an additional indicator, especially when we are working with multiple tasks at once. In principle, we could add a message-sending field directly to the task itself.&#x20;

But these are just ideas.&#x20;

Improve workload tracking

Currently, we output information like this:&#x20;


⏳ Calling Read Concepts...

⏳ Calling GraphQL Request...

⏳ Calling Shell Execute...

⏳ Calling Shell Execute...

I think it would be good to see exactly what queries and commands the agent writes and what responses come back.&#x20;

Develop more detailed logging of what the agent executes

Currently, there is a resolver for creating a project folder, but none for getting a list of folders, deletion, etc.

Add resolvers for working with project directories

We need the ability to generate both overall layouts and individual elements and components. We also need infographics with text, because text is traditionally problematic for image generation. However, it seems the latest Qwen was boasting about this capability.

Research which models generate layouts and infographics better

Add functionality to run MODX websites

Related to task [/tasks/cmqtqmj0m004wp50uccwvo4zh](/tasks/cmqtqmj0m004wp50uccwvo4zh).

## Objective

Extend `modx-docker` so that it can reproduce real legacy MODX projects, rather than just performing a clean installation of a specific MODX version from Git.

## Scenarios

Support at least four modes:

1. **Clean installation** — current scenario: checkout the required MODX ref, empty DB, unattended setup.
2. **Database only** — import the provided SQL dump, while preparing files/core separately.
3. **Files only** — use the provided set of project files, but create a new/clean DB.
4. **Full snapshot** — restore both project files and the DB for the most accurate reproduction of the site.

## Requirements

- File and DB sources must be set declaratively via configuration/environment variables.
- Do not modify source dumps/archives; perform any environment-specific changes on the working copy.
- After restoration, normalize the environment: DB connection parameters, hostname/domain, absolute paths, and other settings that hinder running inside Docker.
- If there is no DB dump, perform a standard MODX setup.
- If the core is missing from the provided files, provide the ability to retrieve the required MODX ref from Git.
- After restoration, clear the cache and perform environment readiness checks.
- Do not tie the implementation only to modern versions of MODX/PHP/MySQL: the primary motivation is the ability to reproduce legacy combinations.

## Context

For MODX, a significant portion of the project state lives in the DB (resources, templates, chunks, snippets, TVs, settings, package information), while another portion lives in the file system (assets, components, custom code, Extras files). Therefore, for a full reproduction of a real project, one must be able to independently or jointly restore both parts.

In the future, this mechanism should allow an agent to take an old MODX site, reproduce its original environment, investigate incompatibilities, and gradually migrate the project to newer runtime versions.

Support MODX deployment not only via clean installation, but also from a DB dump, project files, or a full snapshot.

Add restoration of MODX project from dumps and files

# 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](/tasks/cmuhtjmad02o4qw0rqomst183);
- [connecting an existing project](/tasks/cmuhtjmah02o6qw0rsgd1dgo3);
- [dev/stage/prod management](/tasks/cmuhtjmak02o8qw0rkl4ehm1z);
- [project state beyond source code](/tasks/cmuhtjman02oaqw0rb7yelmcy);
- [safe agent modification cycle](/tasks/cmuhtjmas02ocqw0r13pf4kpv);
- [deploy and rollback](/tasks/cmuhtjmav02oeqw0rtdqqrwaa);
- [backup and recovery](/tasks/cmuhtjs3j02okqw0r0d5kzdo5);
- [infrastructure observability](/tasks/cmuhtjs3o02omqw0rjwc1ot7h);
- [portability and transfer to the owner](/tasks/cmuhtjs3s02ooqw0rzbm9szlx);
- [secrets and external dependencies](/tasks/cmuhtjs3v02oqqw0rno085k70);
- [accelerated launch of new websites](/tasks/cmuhtjs3z02osqw0r9qb476ki).

The future direction of [portfolio management for multiple projects](/tasks/cmuhtjs4202ouqw0rk5tg1a0y) 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](/tasks/cmqpcbssv001op50usjjkcaqu), [Git](/tasks/cmqpcj6hi001sp50udi2qjlh8), [TypeScript code analysis](/tasks/cmqp7ckiq001gp50ug9mgq00f), [WorkLogs](/tasks/cmqpf6y5j001up50u0q50vxo1), [agent action logging](/tasks/cmqpfczbk001wp50uynu0g7kf), [MODX runtime](/tasks/cmqtqmj0m004wp50uccwvo4zh), and [MODX recovery from files/DB](/tasks/cmtngfoe204qdpf0qab6spl66).

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.

Research the minimal infrastructure that allows creating, accepting, reproducing, modifying, deploying, maintaining, and transferring websites and applications using an agent.

Develop full lifecycle infrastructure for websites and applications

# The Problem

Having source code is not enough to maintain an arbitrary website. The agent must be able to obtain a working environment where the project actually runs and behaves predictably.

The existing MODX runtime already points in a useful direction: a specific technology can have its own runtime adapter while project management remains generic. However, it is not yet clear which part of this approach should become a common infrastructure contract.

## What Needs to Be Understood

We need to define a minimal reproducible runtime description: which dependencies, services, versions, commands, and readiness indicators are actually required by the common platform, and which details should remain inside a specific project or adapter.

Docker looks like a natural means of unification and is already used in practice, but the task should not be prematurely reduced to a specific Docker Compose format. The important result is that the project can be predictably started, stopped, inspected, and restarted.

Related to [universal connection of an existing project](/tasks/cmuhtjmah02o6qw0rsgd1dgo3), [state beyond source code](/tasks/cmuhtjman02oaqw0rb7yelmcy), and the existing [MODX runtime](/tasks/cmqtqmj0m004wp50uccwvo4zh) task.

Understand how to describe and reproduce the project's execution environment without binding the entire platform to a single stack.

Develop a reproducible project runtime description

# Problem

The service must be able to accept not only projects created within its own system. Practical experience with MODX, Laravel, Ruby, and other stacks shows that a coding agent is capable of working with technologically diverse projects if it is provided with the source code and a working environment.

The main unknown is what minimum process turns an arbitrary project into a managed infrastructure object.

## Direction

It is necessary to research onboarding: obtaining the source code and state, launching or restoring the runtime, initial analysis of architecture and dependencies, health checks, capturing project knowledge, and preparing a secure working perimeter.

We should not prematurely require migrating the project to haih or another single stack. The value of a common infrastructure lies precisely in standardizing maintenance where it is useful, without needlessly standardizing the project itself.

Related to the [runtime description](/tasks/cmuhtjmad02o4qw0rqomst183), [reproducible state](/tasks/cmuhtjman02oaqw0rb7yelmcy), [agent modification cycle](/tasks/cmuhtjmas02ocqw0r13pf4kpv), and the existing task of [minimum project management](/tasks/cmqpcbssv001op50usjjkcaqu).

Investigate the process of onboarding an existing project regardless of its initial stack.

Develop a universal connection for an existing project

# Problem

Local project modifications are not enough for real-world operations. As a website matures, it develops a working environment, staging/preview, production, and the need to understand where a specific state is located at any given time.

The existing minimal project management task already assumes dev/stage/prod, but this part has not yet been elaborated as a standalone infrastructure problem.

## What to Investigate

We need to understand which environments are actually needed for different classes of projects, how code, data, configuration, and external services are connected between them, and what the safe path for changes to production should be.

We should not assume that three identical environments are mandatory for every website. A small informational site and a production service handling user data may require different levels of strictness.

Related to the [agentic change cycle](/tasks/cmuhtjmas02ocqw0r13pf4kpv), [deploy/rollback](/tasks/cmuhtjmav02oeqw0rtdqqrwaa), and the existing [project management](/tasks/cmqpcbssv001op50usjjkcaqu) task.

Understand the minimal infrastructure model for multiple project environments and the safe promotion of changes between them.

Develop environment management for dev, stage, and prod

# The Problem

A Git repository often contains only a part of a working system. A real-world website may depend on a database, uploaded files, object storage, users/Auth, runtime configuration, scheduled jobs, access policies, and the state of external services.

This is clearly visible in the previously researched MODX: a significant part of the website resides in the DB, and another part in the file system. The same issue arises when migrating modern AI-builder applications: having the source code does not yet mean having a reproducible system.

## What We Want to Achieve

We need to form a practical model of the **project state** that allows us to understand what needs to be saved, restored, or transferred so that the project continues to work regardless of the current infrastructure.

A single mandatory set for all websites is not assumed. The goal is to learn how to discover significant parts of the state and explicitly capture them.

Related to [runtime](/tasks/cmuhtjmad02o4qw0rqomst183), [backup/restore](/tasks/cmuhtjs3j02okqw0r0d5kzdo5), [secrets and external dependencies](/tasks/cmuhtjs3v02oqqw0rno085k70), and [project portability](/tasks/cmuhtjs3s02ooqw0rzbm9szlx). For MODX, a specific case is already being investigated in the task of [restoring from dumps and files](/tasks/cmtngfoe204qdpf0qab6spl66).

Determine what parts, other than Git, make up the portable and reproducible state of a real-world project.

Develop a reproducible project state beyond source code

# Problem

Giving a coding agent access to a project does not yet constitute a reliable service. The agent must understand the initial state, perform the modification in a controlled environment, verify the result, and leave enough traces for a human or another agent to continue the work.

The project already contains individual parts of this cycle: Git state, code analysis, WorkLogs, and the idea of detailed action logging. These need to be viewed as elements of a single infrastructure process.

## Direction

It is necessary to investigate the minimal secure modification lifecycle: capturing the initial state, working environment, modification, automated checks, result review, recording what was done, rollback capability, and transition to deploy.

The specific workflow should not be considered predetermined: different projects have different tests and risk levels. What matters is the ability to adapt the rigor of the process without losing observability.

Related to [Git resolver](/tasks/cmqpcj6hi001sp50udi2qjlh8), [code analysis](/tasks/cmqp7ckiq001gp50ug9mgq00f), [WorkLogs](/tasks/cmqpf6y5j001up50u0q50vxo1), [agent logging](/tasks/cmqpfczbk001wp50uynu0g7kf), [environments](/tasks/cmuhtjmak02o8qw0rkl4ehm1z), and [deploy/rollback](/tasks/cmuhtjmav02oeqw0rtdqqrwaa).

Investigate a secure and verifiable cycle in which an agent modifies a real project from task formulation to verified result.

Develop a secure agent project modification cycle

# Problem

For a managed service, it is not enough to be able to fix code locally. Changes must predictably reach the production system, and errors should not turn every deploy into a manual emergency operation.

## What to Investigate

It is necessary to understand what minimum deploy contract can be common across different projects: what is considered ready for publication, what checks are performed before and after, how the production version is recorded, and what rollback options are actually needed.

Do not build a universal CI/CD platform in advance. Some projects may use existing hosting/deployment solutions, while others use their own infrastructure. For the overall system, it is more important to understand and control the publication lifecycle.

Related to [environments](/tasks/cmuhtjmak02o8qw0rkl4ehm1z), [agent loop](/tasks/cmuhtjmas02ocqw0r13pf4kpv), [observability](/tasks/cmuhtjs3o02omqw0rjwc1ot7h), and [backup/restore](/tasks/cmuhtjs3j02okqw0r0d5kzdo5).

Understand the general infrastructural approach to publishing changes and returning to working condition upon failure.

Develop project deployment and rollback infrastructure

# Problem

A managed service assumes responsibility not only for modifying the website, but also for the ability to restore it after errors, data corruption, failed migrations, or infrastructure loss.

Standard Git is not enough when significant state resides in databases, files, object storage, or other systems.

## Direction

We need to determine what backup/restore levels are required for different projects, how to verify backup integrity, and to what extent recovery can be automated by an agent.

It is important to distinguish between having a backup and having proven recoverability. At the same time, there is no need to build a custom backup storage solution in advance if existing hosting/database tools solve the problem better.

Related to the [project state model](/tasks/cmuhtjman02oaqw0rb7yelmcy), [deploy/rollback](/tasks/cmuhtjmav02oeqw0rtdqqrwaa), and [portability](/tasks/cmuhtjs3s02ooqw0rzbm9szlx). A specific MODX scenario is already described in [restoring from dumps and files](/tasks/cmtngfoe204qdpf0qab6spl66).

Explore the general approach to saving and restoring the operational state of different project types.

Develop project backup and recovery strategy

# Problem

After a deploy, a project cannot be considered maintainable just because the process has started. You need to quickly understand whether the site is working, whether errors have appeared, and what has changed after a specific action.

## What to Investigate

It is necessary to determine the minimum useful signals: availability, health checks, application/runtime logs, errors, the state of key services, and other indicators depending on the project.

The goal is not to build your own equivalent of a large observability platform. The common infrastructure must be able to use available signals and show the agent enough context for diagnostics.

Related to the [agent loop](/tasks/cmuhtjmas02ocqw0r13pf4kpv), [deploy/rollback](/tasks/cmuhtjmav02oeqw0rtdqqrwaa), and the existing task for [detailed logging of agent actions](/tasks/cmqpfczbk001wp50uynu0g7kf).

Understand the minimal observability required for an agent and a specialist to safely maintain a running project.

Develop infrastructure observability for the project

# The Problem

The ability to download a repository is too weak a criterion for portability. A real project includes code, data, files, runtime, configuration, external dependencies, and knowledge required for operations.

If a client transfers a website to a service provider for maintenance, the service must not make the project's continued existence dependent on itself solely for customer retention.

## What to Investigate

It is necessary to determine what must be available to the owner for a real exit: what artifacts, state, instructions, and accesses allow another specialist or agent to reproduce and continue maintaining the system.

At the same time, portability does not mean that any project must run on any hosting without changes. The criterion must distinguish normal technological dependencies from artificial vendor lock-in.

Related to [project state](/tasks/cmuhtjman02oaqw0rb7yelmcy), [runtime](/tasks/cmuhtjmad02o4qw0rqomst183), [secrets and external dependencies](/tasks/cmuhtjs3v02oqqw0rno085k70), and [backup/restore](/tasks/cmuhtjs3j02okqw0r0d5kzdo5).

Formulate a practical criterion for the absence of infrastructure lock-in: the project can be handed over to the owner or another team as a working system.

Develop project porting and handoff to the owner

# The Problem

A significant part of the production system resides outside of Git: credentials, API keys, OAuth applications, DNS, email, payments, object storage, external databases, and other services. Without understanding these dependencies, it is impossible to fully restore the project or safely transfer it to another owner.

At the same time, secrets themselves cannot be turned into regular project data or copied mindlessly between environments.

## Direction

We need to explore a model where the infrastructure is aware of the existence and purpose of external dependencies, knows how to check their availability, and understands what credentials a specific environment needs without disrupting existing secret management mechanisms.

We do not assume building a custom secret store in advance: it is important to define requirements and boundaries of responsibility.

Related to [environments](/tasks/cmuhtjmak02o8qw0rkl4ehm1z), [project state](/tasks/cmuhtjman02oaqw0rb7yelmcy), and [portability](/tasks/cmuhtjs3s02ooqw0rzbm9szlx).

Investigate how to handle secrets, credentials, and external services to keep the project secure and reproducible.

Elaborate on secret management and external project dependencies

# Context

Currently, creating a full-fledged website already takes about a day, which is radically cheaper than previous development, but against the background of modern AI-builders, this is still a long time. The goal is to figure out whether the infrastructural part of the launch can be reduced to such an extent that creating dozens of new websites stops being organizationally expensive.

## Problem

A significant part of the time may be spent not on the unique logic of the website, but on repetitive actions: repository, runtime, environment, database if necessary, domain/SSL, deploy, basic observability, backups, and agent connection.

## Direction

It is necessary to measure the actual current launch path of several websites, find repetitive manual steps, and eliminate the most expensive ones one by one.

One should not build a huge universal scaffolding in advance. In accordance with the general philosophy of the project, it is more useful to automate specifically detected repetitions and keep the foundation understandable.

Connected with [runtime](/tasks/cmuhtjmad02o4qw0rqomst183), [environments](/tasks/cmuhtjmak02o8qw0rkl4ehm1z), [deploy](/tasks/cmuhtjmav02oeqw0rtdqqrwaa), [observability](/tasks/cmuhtjs3o02omqw0rjwc1ot7h), and the existing task of [minimal project management](/tasks/cmqpcbssv001op50usjjkcaqu).

Investigate which repetitive infrastructural operations prevent reducing the launch of a new website from a day to about an hour.

Work out accelerated launching of a new website from the standard infrastructural foundation

# Status

**Not a primary task.** First, we need to achieve a simple and reliable single-project lifecycle infrastructure. Portfolio management makes sense to develop on top of working primitives, rather than designing them for the sake of future centralization.

## Why the task should still be recorded

As the number of serviced websites grows, a distinct problem arises: mass updates, status checks, and exception searches must not require sequential manual traversal of each project.

In the future, a layer may be needed that is aware of available projects and their infrastructure capabilities, allowing an agent to address operations to multiple projects. However, the specific form of such a control plane is not yet defined and should not dictate the architecture of the core system.

## Principle

First:

`reliable Project lifecycle -> clear runtime/deploy/restore primitives`

And only then, once real operations reveal recurring needs:

`multiple Projects -> common orchestration/control layer`

Related to the main task of [lifecycle infrastructure](/tasks/cmuhtjma702o2qw0rtj2gm96e) and [accelerated launch of new websites](/tasks/cmuhtjs3z02osqw0r9qb476ki).

It is a non-priority to explore the future level of managing dozens and hundreds of projects through a common infrastructure loop.

Explore multi-project portfolio management through a unified infrastructure loop

The `running` state of the external DinD does not mean that the internal Compose has already built and the application is ready. A project-level state model of `building / starting / ready / failed` with a verifiable readiness criterion and an error cause is needed. It must be suitable for the API, the agent, and the GUI.

Separate the external container state from the actual readiness of the child application.

Add readiness state and project startup lifecycle

The pilot showed that the state of the external DinD is insufficient for diagnosis: actual errors occurred inside Compose (`N8N_ENCRYPTION_KEY`, `npm ci ECONNRESET`). A standard way is needed to retrieve build/start/runtime logs of the project and specific internal services without manual `docker exec`. Link this to the overall observability task.

Provide the API and agent with sufficient logs to diagnose a Docker Compose project within the runtime.

Add access to project startup and internal service logs

In the investigated `dockerContainer` API, start/stop/restart/remove and some auxiliary Docker resolvers do not enforce container ownership by the current user. `analyze*` accepts `projectRoot`. It is necessary to associate operations with project/user ownership and prevent access to other users' containers and paths regardless of the ID/path passed by the client.

Ensure server-side isolation of operations with containers and project paths before multi-user usage.

Restrict Docker and file resolver access rights by project owner

In the pilot, the `.env` file ended up in the external build context/image. Secrets must be stored and transmitted separately from the source code and images, while keeping the project reproducible and portable. Align the solution with the existing task of secret management and external dependencies.

Implement the transmission of runtime secrets separately from Git and the project image being built.

Remove project secrets from Docker build context and images

The pilot run was repeatedly downloading Docker images and npm dependencies; one run aborted at `npm ci` with an `ECONNRESET` error. Implement persistent Docker data/build cache and dependency cache so that subsequent builds/deploys are fast, while the state remains manageable and cleanable.

Eliminate the need to re-download images and dependencies on every new DinD run.

Save Docker and dependency cache between project runs

Each child project must remain a standalone Git/Docker Compose project: you can work with it through the platform, AI, or directly in files, and run it outside DinD using regular Docker. Figure out how dev/stage/prod map to explicit Git commits/branches/tags and how the platform displays which Git state is actually running in each environment. The goal is to simplify promotion, diffing, rollbacks, and portability without turning the platform into a mandatory project format.

Use the project's own Git as the primary source of history and environment state without platform lock-in.

Develop Git-native management of dev, stage, and prod for a standalone project

## Task

Create a minimal personal account for the Narasim system owner.

At the first stage, consider the owner as a superuser: they have access to all functionality for managing their projects. A multi-user model and granular access permissions are not being developed yet.

Minimal functionality:
- project management, where one project corresponds to one folder;
- viewing projects;
- starting a project container;
- stopping a container;
- deleting a container.

## Interface Priority

Narasim is primarily designed for agentic work via API. The personal account is secondary: it is needed for state visibility and direct manual control. There is no need to try to transfer all system capabilities into the GUI or build a complex administrative panel in advance.

Add a minimal UI for the Narasim owner on top of the existing project and container management functionality.