AI Platform Docs

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

Карта репозиториев

Репозиторий	Владеет	Не владеет
`ap-deploy`	Проект Garden, окружения, поставщики инфраструктуры, пространство имён, реестр, публичные адреса, общий Keycloak, базовая конфигурация `realm` и межрепозиторный граф	Продуктовый код, поведение компонентов и копии их Helm-чартов
`agent-platform`	Реализация основных компонентов, их образы, Helm-чарты, конфигурация идентификации и тестовые данные	Полная топология среды и реализация Low-code IDE
`langflow`	Реализация Low-code IDE и `lfx`, образы, Helm-чарт, конфигурация идентификации и принадлежащие компоненту тестовые данные	Общая топология Платформы ИИ

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

Где выполнять изменение

Изменение	Место
Поведение компонента	Репозиторий владельца компонента
`Dockerfile` компонента	Репозиторий владельца компонента
Helm-шаблон и нейтральные значения компонента	Репозиторий владельца компонента
Клиент, роли и отображения OIDC приложения	Репозиторий владельца компонента
Тестовые данные приложения	Репозиторий владельца компонента
Путь к kubeconfig, контекст, пространство имён и класс хранилища среды	`ap-deploy`
Публичные адреса, пути и родитель HTTPRoute	`ap-deploy`
Закреплённые версии исходных репозиториев	`ap-deploy`
Общий поставщик идентификации и базовая конфигурация `realm`	`ap-deploy`
Зависимость между компонентами	`ap-deploy` после проверки границы владения

У каждого Helm-релиза и Kubernetes-ресурса должен быть один владелец. Не создавайте вторую копию ресурса в репозитории композиции.

Локальная разработка нескольких репозиториев

Общие среды используют закреплённые Git SHA, а рабочая станция связывает действия Garden с соседними каталогами:

cd ap-deploy
python3 scripts/link_local_actions.py
garden get linked-repos --env dev-local

Скрипт связывает только заранее известные действия. Он не изменяет адрес удалённого репозитория Git, не переносит коммиты и не обновляет закреплённые версии.

Garden создаёт рабочие сборочные каталоги под .garden/build. Никогда не редактируйте их: содержимое создаётся заново из исходного репозитория и конфигурации действия.

Подготовка межрепозиторного изменения

Безопасная последовательность:

Определите владельца каждого изменяемого артефакта.
Измените продуктовый артефакт во владеющем репозитории.
Проверьте его через локальную связь Garden.
Создайте проверенный Git-коммит продуктового репозитория.
Обновите закреплённый SHA в ap-deploy.
Убедитесь, что предыдущая и новая композиция имеют рабочий путь обновления.
Выполните проверки графа и развёртывание по новому составу.

Не создавайте неатомарное несовместимое изменение, при котором ни предыдущая, ни новая версия композиции не способны развернуть работающую систему.

Дублирующие способы запуска

Платформенные файлы Docker Compose, отдельные скрипты ручного развёртывания и любой новый Garden Project в продуктовом репозитории создают вторую модель интегрированной среды. Они могут расходиться по следующим параметрам:

публичные адреса и порты;
издатель OIDC и адрес возврата;
постоянные тома;
версии и имена образов;
Keycloak и тестовые пользователи;
шлюзовая инфраструктура;
порядок готовности зависимостей.

Единственный источник истины интегрированной среды — ap-deploy. Standalone Garden Projects из agent-platform и langflow удалены после переноса их поддерживаемых сценариев. Не возвращайте их как локальное исключение: недостающий сценарий добавляется в общий граф либо оформляется отдельным изолированным verification capsule.

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

Проверка границы владения

Перед слиянием задайте четыре вопроса:

Может ли приложение развернуться без несвязанного рабочего каталога?
Не появился ли второй владелец существующего Kubernetes-ресурса?
Осталась ли конфигурация окружения в ap-deploy?
Зафиксированы ли совместимые Git SHA для общей среды?

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

Репозитории и владение