Ворклог по задаче "Добавить минимальный функционал по управлению проектами"

Подтверждена универсальная схема размещения и маршрутизации дочерних проектов

Получен важный промежуточный результат по минимальному управлению проектами: экспериментально подтверждена схема, в которой платформа управляет проектом снаружи, а сам проект сохраняет полную самостоятельность внутри.

Дочерний проект успешно запускается в изолированном Docker-окружении без публикации собственного порта на хосте и становится доступен через единый общий Traefik платформы. Пилотный haih-site корректно открывается по выделенному ему hostname через общий вход платформы.

Что это даёт

Платформе не требуется знать внутренний стек каждого проекта. Внутри проекта могут находиться Node.js, PHP, базы данных, кеши, собственный reverse proxy и любые другие сервисы, которые описывает его Compose. Проект самостоятельно определяет свою внутреннюю архитектуру и остаётся переносимым: его окружение можно запускать независимо, а Narasim добавляет внешний слой управления и публикации.

Получается два уровня ответственности:

Internet / пользователь / агент
            ↓
общий Traefik платформы
            ↓
      выбранный проект
            ↓
внутренний proxy / Compose проекта
            ↓
    внутренние сервисы

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

Проверена корректная изоляция маршрутов

Отдельно устранён важный ложноположительный сценарий: запрос к отсутствующему дочернему проекту больше не маскируется основным приложением платформы. Основное приложение ограничено своим hostname, поэтому неизвестный или недоступный дочерний маршрут корректно приводит к 404 вместо открытия чужого сайта.

Это важно не только для UX, но и для будущей автоматической проверки запуска: сам факт получения HTTP-ответа от общего proxy ещё не означает, что запрошенный проект действительно работает.

Ценность для agent-driven платформы

Практически подтверждается нужная граница универсального project runtime. Агент может получить задачу, подготовить проект в подходящем ему стеке, запустить его как самостоятельную систему и предоставить пользователю рабочий адрес. Платформа при этом может ограничиться общими операциями жизненного цикла проекта вместо знания деталей каждой технологии.

Это создаёт основу для размещения множества независимых проектов за единым входом без выделения отдельного host-порта каждому проекту и без необходимости перестраивать общий proxy под внутреннее устройство приложения.

Что считаем доказанным сейчас

На текущем этапе подтверждена именно схема размещения и HTTP-маршрутизации:

• дочерний проект способен работать как самостоятельный Compose-стек;
• внешний контейнер проекта не требует опубликованного host-порта;
• общий Traefik способен маршрутизировать запрос на нужный проект по hostname;
• внутри проекта может существовать собственный proxy, отвечающий за его сервисы;
• основной сайт платформы не перехватывает отсутствующие дочерние маршруты;
• добавление такого проекта не требует знания его внутреннего технологического стека со стороны платформы.

Пока не считаем решёнными управляемое ожидание готовности приложения, полный lifecycle через API, диагностику стадий запуска, сохранение/восстановление данных, права доступа и полноценную изоляцию недоверенного кода. Привилегированный DinD удобен как техническая граница эксперимента, но сам по себе не является достаточной security-моделью для запуска произвольного недоверенного проекта.

Главный результат этапа: найдена и практически проверена архитектурная граница, позволяющая Narasim управлять независимыми проектами как целыми системами, не превращая платформу в универсальный installer для всех возможных стеков.