Ключевая идея, стоящая за проектом, — предоставить готовую серверную основу для приложений, в которых AI-агент формирует интерфейс с помощью A2UI.
Разработчик берёт сервер, подключает готовый адаптер агента или пишет свой, создаёт фронтенд и запускает собственный A2UI-проект. Авторизация, управление диалогами и обмен сообщениями между клиентом и агентом организованы на стороне сервера через общие интерфейсы.
Сначала описаны идея, сценарии и роли частей. Ниже — текущая реализация, запуск и подключение своего проекта. Это первая рабочая версия, подключаемая из исходников; опубликованного npm-пакета пока нет.
Проект рассчитан на приложения, в которых способ представления результата зависит от запроса пользователя. Для одного вопроса достаточно текста, для другого удобнее список с фильтрами, карточка с подробностями или форма уточнения. Агент выбирает подходящие элементы из доступного каталога и связывает их с полученными данными.
Например, пользователь может описать условия поиска обычным сообщением, получить несколько вариантов в карточках, выбрать один кнопкой и продолжить обсуждение выбранного результата. Текстовый диалог и действия в интерфейсе становятся двумя способами работать с одной задачей.
Такая основа может использоваться для помощника по каталогу, поиска по базе знаний или просмотра данных из нескольких сервисов. Особенности предметной области задаются инструментами, инструкциями и компонентами конкретного проекта. Общая работа с пользователями, диалогами и выполнением запросов остаётся на сервере.
Сервер должен предоставить готовый путь от пользовательского запроса до отображённого результата и следующего действия. Разработчик подключает источник данных через инструмент, описывает агенту задачу приложения и выбирает компоненты, которыми тот может пользоваться. Для нового проекта сохраняются те же правила отправки сообщений, обработки ошибок и восстановления интерфейса.
На стороне приложения остаются предметная логика и оформление: какие данные доступны пользователю, как устроен поиск, какие действия разрешены, как выглядят компоненты и что означает результат. Эти решения оформляются в подключаемых обработчиках и клиенте. Сервер проверяет владельца диалога и активность запуска. Обработчик инструмента получает проверенный контекст владельца запуска и сигнал отмены; доступ к конкретным предметным данным проверяет сам обработчик. Этот контракт описан в инструкции подключения.
Универсальность проекта должна проявляться в возможности заменить одну из этих частей через её контракт. Другой источник данных подключается инструментом, другой агент — адаптером, другой способ отображения — клиентом с совместимым каталогом. Реальная совместимость каждой новой интеграции подтверждается рабочим примером и проверками.
Приложение может отправить один запрос и получить интерфейс как самостоятельный результат. Такая генерация не продолжает предыдущие разговоры: сервер выполняет отдельное задание, сохраняет его результат для доставки и применяет обычные правила доступа и ограничения.
Для последовательной работы используется диалог. В нём агент получает предыдущие сообщения, состояние задачи и показанный интерфейс. Нажатие кнопки или отправка формы становится следующим шагом того же диалога. Это позволяет начать с текстового запроса, перейти к выбору в интерфейсе и затем снова уточнить задачу сообщением.
- Развернуть сервер и настроить авторизацию.
- Выбрать готовый адаптер агента или реализовать свой по общему контракту.
- Подключить каталог компонентов и инструкции для агента.
- Написать фронтенд с A2UI-рендерером и подключить его к API сервера.
- При необходимости добавить инструменты для работы с данными и внешними сервисами.
Клиент отправляет запрос пользователя, сервер передаёт его агенту через адаптер. Агент возвращает сообщения A2UI, сервер проверяет их и передаёт клиенту. Рендерер на фронтенде отображает компоненты, а действия пользователя возвращаются агенту через тот же сервер.
Фронтенд ↔ API сервера ↔ адаптер ↔ агент
Рассмотрим поиск в каталоге товаров. Пользователь пишет: «Покажи настольные лампы с тёплым светом». Сервер связывает запрос с его диалогом и передаёт агенту условия поиска, доступные инструменты и описание компонентов интерфейса.
Агент вызывает инструмент поиска. Обработчик обращается к каталогу и возвращает подходящие товары с их идентификаторами и характеристиками. На основе этих данных агент формирует A2UI: например, список карточек с названием, кратким описанием и кнопкой «Подробнее». Сервер проверяет описание интерфейса, сохраняет его и передаёт клиенту для отображения.
Нажатие «Подробнее» возвращается на сервер вместе с данными выбранного элемента. Агент получает это действие в контексте диалога, запрашивает подробности через инструмент и обновляет показанный результат. Пользователь также может написать «Покажи похожие, но компактнее» — выбранный элемент и предыдущие условия помогают продолжить ту же задачу.
Если источник данных недоступен, приложение должно объяснить, что получить результат не удалось, и дать возможность повторить запрос. Пустой результат поиска, ошибка источника и отмена пользователем имеют разный смысл. Агенту нужны эти различия, чтобы корректно объяснить произошедшее, а клиенту — чтобы показать состояние работы.
При повторном открытии страницы сервер возвращает сохранённый интерфейс. Это восстановление ранее показанного результата; для получения свежих данных пользователь отправляет новый запрос или предусмотренное приложением действие обновления.
Сервер связывает клиент, агента и инструменты в одно приложение. Он принимает пользовательские запросы, подготавливает контекст для агента, управляет выполнением и доставляет результат на фронтенд. Благодаря этому разработчику не нужно заново собирать эту связку для каждого проекта.
Фронтенд работает с понятными операциями: создать диалог, отправить сообщение, передать действие компонента, получить состояние или отменить запрос. Эти операции одинаковы независимо от того, какой агент подключён на сервере и каким способом он запускается.
Через API можно подключить веб-интерфейс, мобильное приложение или несколько клиентов одного проекта. Каждый клиент отвечает за своё оформление и отображение компонентов. Сервер отвечает за обработку запросов и единый формат ответов: сообщения A2UI, текст, состояние выполнения и ошибки.
Для диалога выбираются совместимые версия A2UI и каталог компонентов. Это позволяет передать агенту описание именно тех элементов, которые клиент умеет отображать. Повторное подключение или открытие диалога на другом устройстве не должно незаметно менять уже выбранный каталог.
Сервер определяет пользователя по проверенным учётным данным и связывает с ним диалоги. При чтении истории, отправке сообщений, взаимодействии с интерфейсом и вызове инструментов проверяются права на соответствующую операцию.
Идентификатор диалога служит адресом, а не разрешением на доступ. Подмена ID в запросе не позволяет получить чужую историю или продолжить чужой диалог. Проверка предметных прав внутри инструмента — отдельная задача интеграции: принимать userId из аргументов агента как подтверждение доступа нельзя.
Сервер организует контекст диалога и передаёт его выбранному агенту. Новое сообщение связано с предыдущими условиями и результатами, поэтому агент может продолжать начатую работу. Если адаптер использует собственную сессию агента, её связь с диалогом и способ восстановления должны быть определены явно.
При этом история разговора, состояние текущей задачи и состояние интерфейса разделены. Для продолжения запроса агенту может быть достаточно текущих условий и последних сообщений. Если пользователь ссылается на показанную карточку или выбранный элемент, сервер добавляет сведения о соответствующем результате.
Пользователь может начать новый диалог с новым контекстом. В дальнейшем можно добавить переход к новому контексту внутри существующего диалога, в том числе по запросу агента через управляющий инструмент. Для такого перехода потребуется определить, какие данные сохраняются и как пользователь взаимодействует с прежними результатами.
Хранение состояния также позволяет восстанавливать интерфейс после переподключения клиента. Сервер сохраняет уже принятый результат, чтобы для повторного открытия экрана не требовалось заново обращаться к агенту. История и состояние интерфейса должны переживать перезапуск сервера; продолжение прерванной работы агента рассматривается отдельно.
Сервер обращается к агентам через общий интерфейс адаптеров. Он собирает контекст и передаёт выбранному адаптеру запрос вместе с инструкциями, каталогом компонентов и доступными инструментами. Codex запускается заново для каждой команды; продолжение обеспечивает серверная история.
Адаптер преобразует этот вызов в операции конкретной CLI, SDK или API, а полученный ответ приводит к событиям, понятным ядру. Клиенту не нужно знать команды запуска агента или особенности формата его вывода.
Смена агента должна происходить на уровне конфигурации и адаптера, сохраняя контракт клиентского API. При этом сервер учитывает различия в возможностях: например, отсутствие потоковых ответов или поддержки отмены. Перенос внутренней сессии между разными агентами не предполагается автоматическим — при переключении может потребоваться новый контекст, собранный из состояния диалога.
Сервер принимает сообщения A2UI от агента, проверяет их структуру, версию протокола и соответствие разрешённому каталогу. Из принятых сообщений он собирает и сохраняет актуальное состояние интерфейса. Корректные изменения передаются клиенту в нужном порядке, чтобы рендерер мог создавать и обновлять компоненты.
Если агент прислал некорректное обновление, сервер сообщает ему об ошибке и может дать ограниченную попытку исправления. Уже показанный результат не должен незаметно исчезать или выдаваться за завершённый, если дальнейшая обработка оборвалась.
Обратный путь проходит через тот же сервер. Нажатие кнопки, отправка формы или выбор элемента превращаются в событие, связанное с конкретным диалогом и состоянием UI. Сервер проверяет событие и передаёт его агенту для следующего шага.
Для меняющегося интерфейса важно учитывать версию показанного результата. Если пользователь отправил форму со старого экрана, сервер должен уметь обнаружить это и запросить обновление вместо выполнения действия с устаревшими данными.
Проверка формата A2UI подтверждает корректность сообщения, но не заменяет проверку прав или достоверности данных. Эти проверки остаются в серверной логике и обработчиках инструментов.
Запрос к агенту может выполняться долго, завершиться ошибкой или быть отменён пользователем. Сервер отслеживает его состояние и сообщает клиенту, что происходит: запрос принят, выполняется, завершён, отменён или завершился с ошибкой.
Внутри одного диалога запросы обрабатываются последовательно, чтобы конкурирующие ответы не перезаписывали контекст и интерфейс. Если диалог занят, клиент получает явный ответ о том, что нужно дождаться завершения или отменить текущую работу. Независимые диалоги могут выполняться параллельно в пределах настроенных ограничений.
Повторная отправка того же запроса после потери соединения не должна запускать агента второй раз. Клиент и сервер различают новую команду и повтор уже принятой, сохраняя связь с её результатом.
Сервер задаёт ограничения размера входных данных, времени выполнения и количества одновременных запросов. При отмене он вызывает соответствующую операцию адаптера и освобождает ресурсы. Если агент не поддерживает фактическую остановку, это ограничение учитывается явно, а поздний ответ не должен изменять уже отменённый результат.
При поддержке потоковой передачи сервер может доставлять сообщения по мере появления. Если агент возвращает только готовый ответ, адаптер передаёт его после завершения обработки. Для клиента оба варианта используют одну модель диалогов и событий. Разрыв соединения сам по себе не отменяет работу: после переподключения клиент получает пропущенные изменения.
Сервер может выступать общей точкой подключения инструментов проекта. Он предоставляет агенту их описания и организует выполнение: проверяет аргументы и разрешения, вызывает обработчик или внешний сервис, возвращает данные либо понятную ошибку.
Логика работы с конкретным источником данных находится в подключаемом инструменте. Ядру не нужно знать устройство внешнего API, а адаптеру агента — реализовывать одну и ту же интеграцию заново. Ключи доступа и другие необходимые учётные данные хранятся на стороне исполнителя.
Такой подход позволяет независимо развивать три части проекта: менять фронтенд, подключать других агентов и добавлять новые инструменты. Сервер сохраняет общий порядок их взаимодействия и правила доступа.
Адаптер связывает сервер с конкретным агентом через CLI, SDK или API. Для подключения собственного агента разработчик реализует общий интерфейс адаптера.
Контракт должен определять:
- Как принять подготовленный сервером контекст и начальные инструкции.
- Как обработать сообщение или действие интерфейса в этом контексте.
- Как получить ответ и привести события агента к формату сервера.
- Как сообщить об ошибке или завершении обработки.
- Как отменить запрос и освободить ресурсы сессии.
Контракт различает адаптер модели и адаптер готового агента. При работе с моделью через API сервер организует цикл: передаёт запрос, получает предложенные вызовы инструментов, выполняет их и возвращает результаты модели. Готовый агент, такой как Codex CLI, ведёт этот цикл сам; его адаптер управляет процессом и подключением инструментов. Для одного запуска выбирается один владелец цикла, чтобы сервер и агент не дублировали управление. Сервер при этом остаётся владельцем прав доступа, состояния диалога и правил выполнения. Адаптер не изменяет историю и интерфейс в обход ядра.
Текущий контракт различает kind: agent и kind: model, передаёт контекст и AbortSignal, возвращает итоговый ответ. Реестра возможностей и потокового host API пока нет. Возможности конкретной интеграции проверяются её тестами; методы describe() или host.emitText() не являются частью доступного интерфейса.
Разработчик самостоятельно определяет внешний вид и устройство приложения. Для работы с сервером фронтенд должен соблюдать контракт API, отображать сообщения через совместимый A2UI-рендерер и передавать события пользователя обратно серверу.
Каталог, доступный агенту, должен соответствовать компонентам, реализованным на клиенте. Сервер передаёт описание интерфейса, а отрисовку выполняет фронтенд.
Вокруг области A2UI приложение сохраняет обычную оболочку: вход, список диалогов, поле сообщения, состояние выполнения и кнопку отмены. Её поведение определяет разработчик. Агент формирует содержимое выделенной области, а клиент отвечает за то, чтобы пользователь мог ориентироваться в приложении даже во время ожидания или ошибки.
Каталог описывает, какие элементы агент может использовать, какие данные они принимают и какие действия предоставляют. Инструменты отвечают на другой вопрос: откуда получить данные и какие операции доступны. Например, инструмент возвращает найденные товары, а каталог позволяет представить их в виде текста, списка и кнопок.
Каталог является самостоятельной частью проекта. Его можно загрузить из локального документа, зарегистрированного удалённого источника или через MCP. Сервер проверяет документ и сохраняет выбранную версию вместе с диалогом или заданием генерации. Кэш и явное обновление позволяют обращаться к источнику при подготовке конфигурации, а не заново для каждого сообщения.
Инструкции проекта связывают эти возможности с задачей приложения. В них разработчик объясняет, когда нужно запросить данные, какие условия уточнить у пользователя и как представить результат. Названия и характеристики товаров в примере должны опираться на ответ инструмента; оформление и порядок представления агент выбирает в пределах каталога.
Расширение интерфейса требует согласованных изменений: описание нового компонента становится доступно агенту и серверной проверке, а его реализация — клиентскому рендереру. Поэтому каталог является частью версии приложения. Простого упоминания нового элемента в промпте недостаточно, чтобы клиент смог его отобразить.
Перед обращением к агенту сервер собирает выбранную версию A2UI, описание каталога, инструкции проекта, состояние задачи, актуальный UI и сообщение пользователя. Для диалога добавляется его история, для разового задания — только данные этого задания. Оба вида адаптеров получают AgentContext; Codex упаковывает его в текст через server/prompt.ts. Публичного API изменения состояния задачи пока нет.
Служебные credentials и полномочия на вызов инструментов передаются отдельно. Они не становятся частью сообщения пользователя или описания интерфейса. Структурированный JSON в ответе проверяется как A2UI по схемам протокола и компонентов, а затем относительно уже существующего состояния UI.
Сервер предоставляет зарегистрированные разработчиком инструменты через служебный MCP endpoint /internal/mcp и выполняет их в контексте активного запуска.
Разработчик регистрирует описание инструмента, схему аргументов и обработчик либо подключение к внешнему исполнителю. Агент получает доступные инструменты, вызывает нужный, а сервер проверяет вызов, запускает обработчик или передаёт запрос исполнителю и возвращает результат.
Агент ↔ MCP-коннектор ↔ инструменты сервера ↔ API и внешние сервисы
Так можно подключать источники данных и действия приложения отдельно от адаптера агента. Сервер контролирует доступ к инструментам и хранит необходимые для их выполнения учётные данные. В первой версии этот путь используется адаптером Codex CLI: агент получает инструменты проекта через внутреннее MCP-подключение. MCP также может выступать источником каталога компонентов. Это отдельное подключение: чтение описания интерфейса и выполнение инструментов приложения имеют разные настройки и полномочия. Подключение произвольных внешних инструментов можно добавить позднее.
Для работы с A2UI уже существуют библиотеки на стороне клиента и агента. Сервер должен использовать подходящие готовые реализации протокола, оставляя в собственном ядре управление приложением: пользователями, диалогами, выполнением и инструментами.
Клиентский SDK или рендерер принимает сообщения A2UI, поддерживает состояние компонентов, отображает интерфейс и сообщает о действиях пользователя. Он подключается на фронтенде, а сервер доставляет ему сообщения и принимает обратные события.
В этом checkout проверен официальный Lit-рендерер @a2ui/lit@0.14.0. Другой рендерер должен поддерживать выбранные протокол и каталог; его совместимость здесь не проверялась. Документация рендереров.
Собственный клиентский SDK сервера отвечает за другую часть работы: отправку запросов, подписку на события, отмену и восстановление соединения. Его можно использовать вместе с подходящим рендерером, независимо от устройства остального приложения.
Агентский SDK помогает передавать модели описание каталога и разбирать её ответы в сообщения A2UI. Он может использоваться внутри подключаемого агента или сервиса, с которым работает адаптер.
Agent SDK не является самостоятельной моделью и не заменяет адаптер конкретного агента. Адаптер по-прежнему отвечает за запуск, передачу запросов, управление контекстом и приведение событий к контракту сервера. Если используется готовый CLI-агент, возможность подключения SDK зависит от его интерфейсов; установить библиотеку рядом с CLI недостаточно.
Агент с Agent SDK или собственной поддержкой A2UI
↕
Адаптер
↕
Сервер приложения и инструменты
↕
Клиентский SDK и A2UI-рендерер
Собственная ценность проекта — общий контракт адаптеров, проверка доступа, управление контекстом и выполнением, восстановление состояния и подключение инструментов. Генерацию и отображение сообщений протокола можно поручить существующим библиотекам.
- Официальный сайт и документация — описание протокола, спецификации и руководства по интеграции.
- Репозиторий A2UI — исходный код, рендереры и примеры приложений.
- Анонс A2UI от Google — исходная идея проекта и задачи, которые он решает.
- Официальный Quickstart — запуск примера приложения с агентом и A2UI-рендерером.
Реализована первая рабочая версия: сервер, хранение в PostgreSQL, OIDC-вход, клиент с официальным Lit-рендерером, адаптер Codex CLI и демонстрационные инструменты. Доступны диалоги и разовая генерация. Описание выше задаёт общую идею проекта; текущая реализация проверяет её на небольшом приложении каталога.
Первая версия рассчитана на один самостоятельно размещаемый проект с несколькими пользователями и личными диалогами. Один процесс сервера управляет запросами и запускает Codex CLI в дочерних процессах, а PostgreSQL хранит историю, команды и состояние интерфейса.
Первый адаптер работает с Codex CLI в неинтерактивном режиме. Сервер передаёт ему запрос и контекст диалога, получает события выполнения и проверяет итоговый A2UI перед передачей клиенту. Инструменты проекта доступны Codex через MCP и на этом этапе только читают данные.
Для клиента выбраны Lit и A2UI 0.9.1. Вход пользователей, отмена запроса с остановкой процесса CLI, защита от повторной отправки и восстановление интерфейса входят в первую версию. Авторизация Codex настраивается оператором на сервере отдельно от входа пользователей приложения.
Редактируемый каталог UI находится в catalog/: отдельные JSON-схемы компонентов и примеры допустимых и ошибочных значений. Эти схемы получает агент, по ним сервер проверяет ответ. Команда make test-components проверяет каталог без PostgreSQL и обращения к модели; полный CI запускает эти же тесты вместе с остальными.
Собственный каталог подключается профилем: описание JSON Schema, серверная модель SDK и реализация компонентов в клиенте. Минимальный пример StatusBadge показывает все три части. Диалог сохраняет выбранный документ, а сервер проверяет дальнейшие ответы по его профилю даже после смены каталога для новых диалогов.
Очередь ограничивается как на пользователя, так и на весь сервер. Политика хранения истории, команд и завершённых runtime Codex настраивается отдельно; очистка выключена по умолчанию и имеет предварительный просмотр. Параметры и порядок запуска — в docs/OPERATIONS.md.
Другие адаптеры, внешние MCP-сервисы, изменяющие инструменты с подтверждением, несколько организаций, вложения и кластерное развёртывание остаются направлениями дальнейшего развития. Их добавление должно опираться на уже проверенный общий контракт.
В первой версии Codex используется как готовый агент, который получает задачу, выбирает инструменты и составляет описание интерфейса. Адаптер управляет его запуском и приводит результат к общему формату сервера. Доступ к данным приложения проходит через зарегистрированные MCP-инструменты; разработка и редактирование исходников приложения не являются задачей этого агента.
Для каждой новой команды сервер подготавливает контекст из сохранённого диалога и запускает отдельную сессию Codex. Продолжение разговора обеспечивается серверной историей и состоянием интерфейса. Благодаря этому восстановление страницы и чтение прежних результатов не зависят от работающего процесса CLI.
Первая реализация передаёт клиенту состояние выполнения во время работы, а готовый A2UI — после получения и проверки итогового ответа. Постепенное появление интерфейса по ходу генерации можно развивать отдельно. Для первого рабочего цикла важнее проверить получение данных, корректность результата и обработку следующего действия пользователя.
Для подключения Codex CLI используется официальный Codex TypeScript SDK, пакет @openai/codex-sdk. Спасибо команде OpenAI и участникам openai/codex за открытый SDK, на котором построена эта интеграция.
SDK запускает CLI и разбирает поток его событий. Наш адаптер передаёт контекст и MCP-настройки, проверяет итоговый ответ и сохраняет ограничения выполнения. Небольшой модуль запуска добавляет режим без сохранения сессии, отключение пользовательской конфигурации и правил, лимит вывода и остановку группы процессов. Проверка A2UI и права доступа остаются на сервере.
Все файлы примера находятся в demo/: клиент, каталог ламп, инструменты, тестовый адаптер, инструкции агенту, конфигурации и команды запуска. Общее серверное ядро остаётся в server/, общие пакеты — в packages/.
Эталонное приложение реализует описанный выше поиск по товарам на небольшом демонстрационном каталоге. Оно должно показать подключение Codex, инструментов и рендерера через общие интерфейсы сервера и служить основой для проверки следующих адаптеров.
Данные поставляются вместе с примером и явно отмечены как демонстрационные. Покупки и изменение каталога в сценарий не входят. Пример должен проверить весь путь от запроса до действия пользователя, а также ошибки, отмену и переподключение.
Для своего проекта используйте startServer из server/index.ts: передайте адаптер из server/adapters/codex/, собственный ToolRegistry, инструкции и при необходимости путь к собранному фронтенду. Helper выполняет миграции, получает блокировку, запускает приложение и закрывает ресурсы. Авторизацию существующего проекта можно подключить через AuthProvider в режиме custom. Штатные make run и pnpm start запускают именно пример из demo/.
Пошаговое подключение с полной точкой входа и остановкой сервера находится в docs/INTEGRATION.md. Там же описаны регистрация инструментов, подключение клиента, ограничения авторизации и нового адаптера. HTTP-тела, cookie/CSRF, курсор SSE и действия — в docs/API.md. Агентам-разработчикам начинать с AGENTS.md.
После запуска сервер предоставляет Swagger UI на /docs/ и автоматически собранный OpenAPI на /openapi.json. В спецификацию входят запросы, ответы, ошибки, авторизация и SSE. Экспорт без БД и модели: pnpm openapi > /tmp/a2ui-openapi.json. Порядок входа и выполнения запросов через Swagger — в описании API.
Прикладной Codex получает инструкции из options.instructions и PROJECT_INSTRUCTIONS_FILE, каталог и данные из контекста. AGENTS.md предназначен для агента, который разрабатывает интеграцию; изолированный CLI автоматически его не читает.
Пример личных заметок использует собственную сессию приложения и фильтрует данные по серверному ToolContext.userId. Тесты проверяют его также в отдельном Node-процессе вне cwd сервера.
Связка Codex CLI → MCP → серверная проверка A2UI проверена реальным запросом. Версии @a2ui/lit и @a2ui/web_core закреплены на 0.14.0. Демонстрационный клиент показывает форму, возвращает её действие на сервер и восстанавливает результат после перезагрузки. Проверки ядра и адаптеров дополнены транзакционными сценариями PostgreSQL.
Полный детерминированный прогон содержит 156 тестов в 15 файлах, включая 53 проверки компонентов. Проверяется различие битого JSON и невалидного A2UI, одна попытка исправления и сохранение прежнего UI при повторной ошибке. Отдельно проверяются отмена и остановка процесса Codex, зависшие обработчики, повторы команд после 5xx, собственные каталоги, гонки за квоты, очистка данных и генерация OpenAPI.
Это версия для одного процесса и одного проекта. Другая библиотека renderer, готовые предметные ACL, несколько организаций, записывающие действия с подтверждением, пагинация истории и нагрузочная проверка требуют отдельной доработки. Первая версия не объявляется готовой публичной платформой для произвольных проектов.
Подробный выбор технологий, контракт адаптера, состояния выполнения, правила повторных команд и проверки описаны в STACK.md. Команды запуска и настройки находятся в demo/README.md, границы модулей — в docs/ARCHITECTURE.md, результаты проверок — в docs/VALIDATION.md.
В Gitea Actions настроен CI для main: отдельная job с PostgreSQL проверяет типы, форматирование и тесты; после её успеха другая job собирает тот же commit. Секреты модели не используются. CD будет подключён после подготовки серверных зависимостей. Подробнее — docs/CI.md.
Нужны Node.js 24+, pnpm, Make и PostgreSQL. Для локального запуска с Codex:
make setup
# Укажите DATABASE_URL и CODEX_PROFILE_DIR в demo/.env
make db # если PostgreSQL ещё не запущена отдельно
make runПо умолчанию приложение доступно на http://localhost:3100. make run собирает клиент и запускает сервер с Codex и локальным входом без OIDC. make start использует авторизацию из demo/.env, make demo запускает тестовый адаптер без модели. Остальные команды — make help. Служебный профиль Codex должен быть авторизован заранее; подробности — в инструкции запуска.
Для проверки без модели выполните make test-components; для полного прогона с отдельной PostgreSQL — TEST_DATABASE_URL=… pnpm test. В VS Code используйте расширение Vitest. Публикация и запуск стенда по push сейчас отключены.