Задачи

Сделать админку управления пользователями и заложить UI-основу для последующего управления JWT-токенами идентификации пользователей.

Минимальный виджет для подключения к сайтам через центральный агент с потоковым ответом и Stop.

Единый внутренний каталог подключённых сайтов и их агентов.

Личный кабинет для просмотра диалогов и участия человека.

Сделать простой способ подключения наших сайтов к центральному сервису.

Проверить, можно ли вынести генерацию изображений из Codex/ChatGPT в локальный ComfyUI, оставив агенту постановку задачи, промпты и vision-проверку, чтобы снизить расход токенов и зависания при работе с изображениями.

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

Сделать простой вход в managed-service: клиент указывает URL существующего сайта и email, а на выходе получает подготовленный и опубликованный новый сайт.

Добавить минимальный UI для владельца Narasim поверх существующего функционала управления проектами и контейнерами.

Использовать собственный Git проекта как основной источник истории и состояния окружений без платформенного lock-in.

Убрать повторную загрузку образов и зависимостей при каждом новом DinD-запуске.

Реализовать передачу runtime secrets отдельно от Git и собираемого образа проекта.

Перед многопользовательским использованием обеспечить серверную изоляцию операций с контейнерами и проектными путями.

Дать API и агенту достаточные журналы для диагностики Docker Compose проекта внутри runtime.

Отделить состояние внешнего контейнера от реальной готовности дочернего приложения.

Исследовать представление всего пула задач как единого графа с AI-свёрткой до обозримой человеком картины.

Неприоритетно исследовать будущий уровень управления десятками и сотнями проектов через общий инфраструктурный контур.

Исследовать, какие повторяемые инфраструктурные операции мешают сократить запуск нового сайта с дня до порядка часа.

Исследовать, как учитывать secrets, credentials и внешние сервисы так, чтобы проект оставался безопасным и воспроизводимым.

Сформулировать практический критерий отсутствия инфраструктурного lock-in: проект можно передать владельцу или другой команде как работоспособную систему.