Agnostic CLI

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

• Вам удобнее редактировать код в локальном редакторе.
• Нужно проверить изменения перед сборкой.
• Нужно работать только с конкретным Web или API, а не со всем внутренним проектом.

• Установите CLI одним из способов:
• через Homebrew на macOS или Linux: brew install newsmartpro/tap/agnostic-cli — Node.js установится автоматически, обновление — brew upgrade agnostic-cli;
• через npm: установите Node.js и npm, если их ещё нет на компьютере, затем выполните npm install -g @nsp-labs/agnostic-cli.
• Откройте проект и выберите нужный сервис или сайт.
• Один раз запустите agnostic login: CLI использует https://api.agn0.ru/ по умолчанию и откроет страницу подтверждения в браузере.
• Убедитесь, что у вас есть роль admin или developer, если нужно отправлять изменения.
• Роль platform_user может скачать рабочую копию, проверить status и выполнить pull; push, сборка и публикация ей недоступны.
• Если запускаете Agnostic локально, держите backend на localhost:3000, frontend на localhost:4200 и входите через agnostic login --api-url <адрес локального API>.

Перед входом проверьте версию Node.js и установленного CLI:

node --version
agnostic --version

CLI требует Node.js 18.18 или новее. Для установки выбирайте поддерживаемую LTS-версию Node.js. Если в этом терминале используется старая версия, CLI сообщит об этом до запуска команды и предложит обновить Node.js. После обновления откройте новый терминал или выберите новую версию своим менеджером Node.js, затем повторите обе проверки. Если Node.js отсутствует, сначала установите его выбранным способом установки CLI.

Чтобы узнать параметры нужной команды, добавьте --help:

agnostic --help
agnostic workspace push --help
agnostic agent setup --help

Справка выбранной команды показывает её аргументы, флаги и пример. Для просмотра версии и справки не нужны вход, проект или рабочая папка; эти команды не открывают браузер и не отправляют изменения. Возможность станет доступна после обновления CLI с этим изменением. Обычная npm-установка использует Node.js вашего терминала; отдельная поставка CLI с собственным Node.js пока не опубликована.

1. Откройте карточку нужного сервиса или сайта и в блоке Разработка выберите локальный способ.
2. Скопируйте подготовленные для этого ресурса команды.
3. Выполните вход в CLI, проверьте устройство, хост, профиль доступа, срок действия и разрешения на странице подтверждения.
4. Если браузер попросит войти в Agnostic, выберите обычный вход или доступный OAuth-провайдер. После входа браузер автоматически вернётся к подтверждению CLI.
5. Нажмите Разрешить доступ CLI, если вы сами запустили вход и согласны с разрешениями. Иначе выберите Отклонить. Выдача доступа не запускает сборку и не меняет production. Публикация подтверждается отдельно. После результата вернитесь в терминал: CLI продолжит подключение или сообщит об отказе. Отдельный ключ доступа получает CLI; браузер его не получает.
6. Склонируйте workspace выбранного сервиса или сайта.
7. Откройте созданную папку. В ней будут файлы выбранного сервиса или сайта без лишней вложенности.
8. Выполните npm install, чтобы установить зависимости проекта.
9. Запустите npm run dev и откройте локальный адрес из вывода команды.
10. Внесите изменения в редакторе и проверьте их локально.
11. В отдельном окне терминала проверьте status и перед отправкой подтяните актуальные изменения.
12. Выполните push с --build, если у вас есть право на изменение кода.

agnostic login
agnostic workspace clone <project-id> ./my-app --unit <unit> --unit-type <service-or-site>
cd my-app
npm install
npm run dev

После локальной проверки выполните в папке workspace:

agnostic workspace status
agnostic workspace pull
agnostic workspace diff --stat
agnostic workspace push --dry-run
agnostic workspace push -m "Обновить приложение" --build --json
agnostic build wait <build-id> --json

Из папки workspace посмотрите изменения относительно версии, которую вы скачали при clone или последнем успешном pull/push:

agnostic workspace diff --stat
agnostic workspace diff --patch
agnostic workspace diff --patch --json
agnostic workspace push --dry-run --json

--stat показывает добавленные, изменённые и удалённые файлы и их размеры. JSON также содержит контрольные суммы. --patch добавляет текст изменений. CLI получает исходный текст через Agnostic только из разрешённых файлов исходной версии workspace; локальный Git и отдельный доступ к репозиторию для этого не нужны. Для JSON-вывода добавьте --json; без --patch он содержит сведения о файлах, без их текста.

Текстовый просмотр ограничен: двоичные файлы и текст сверх лимита показываются как сведения о файле с причиной пропуска. Значения, похожие на учётные данные, скрываются; ограничение объёма также отмечается в ответе. Значения в кавычках скрываются целиком, включая экранированные кавычки, обратные косые черты и пробелы. Исходные файлы при этом не меняются. Такой patch предназначен для просмотра: скрытые и пропущенные фрагменты не позволяют использовать его как полный файл изменений для применения. Проверьте свои правки в редакторе перед отправкой. CLI сверяет полный список исходных файлов, их размеры и контрольные суммы с платформой перед просмотром. Если сохранённые сведения неполны или не совпадают, CLI остановит просмотр; выполните pull и разрешите возможные конфликты. Если JSON-ответ содержит код WORKSPACE_READ_UNAVAILABLE, исходная версия временно недоступна. Повторите чтение позже; проверка не меняет рабочие файлы.

push --dry-run читает и передаёт изменённые файлы в Agnostic для проверки путей, текущих прав, размеров, содержимого и исходной версии. Он не создаёт новую версию кода, не запускает сборку или публикацию и не меняет локальный workspace. Двоичные файлы тоже проверяются, даже когда их содержимое отсутствует в текстовом просмотре. Для проверки через CLI нужны разрешения на чтение и изменение workspace, а также роль admin или developer в проекте.

Проверка использует тот сервер, для которого вы выполнили вход. Адрес API в рабочей папке должен совпадать с сохранённым профилем CLI. Если задаёте токен через переменную окружения, укажите AGNOSTIC_API_BASE_URL сервера, который выдал токен и исходный workspace, либо используйте совпадающий сохранённый профиль. При несовпадении CLI остановится до передачи данных.

Успешная проверка относится к файлам и состоянию проекта в момент ответа. После новых правок или изменения версии на платформе повторите её. Если основа устарела, выполните pull, разрешите конфликты и проверьте изменения снова. Истёкшую привязку сначала обновите через agnostic workspace renew. Проверка не резервирует следующую отправку; обычный push повторит серверные проверки и может обнаружить изменения, появившиеся после dry-run.

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

agnostic workspace push -m "Обновить приложение" --build

Обычный push может сохранить ваши правки, даже если за время локальной работы кто-то обновил другой модуль проекта. Agnostic продолжит отправку, только когда подтвердит, что история проекта продолжается от вашей исходной версии, а все чужие изменения находятся вне разрешённой области workspace и общих пакетов. Новая версия сохранит изменения другого модуля и ваши отправленные файлы.

Изменение любого общего пакета, в том числе вне вашей рабочей папки, или общих служебных настроек сборки требует обновить исходную версию. Если затронут ваш модуль, версии разошлись или проверить историю не удалось, push остановится. Сохраните локальные правки отдельно, выполните agnostic workspace pull, разрешите возможные конфликты, снова посмотрите diff и повторите отправку. Agnostic не объединяет конфликтующие изменения файлов автоматически.

Если во время сохранения проект успел измениться ещё раз, отправка также остановится: повторите чтение актуального состояния и отправку после проверки. Чужие изменения не перезаписываются.

Если ускоренное продолжение временно недоступно, push может снова попросить выполнить pull даже после изменений в другом модуле. Это не повод обходить проверку или менять исходную версию вручную: сохраните свои правки и следуйте подсказке CLI.

Это продолжение относится к обычному push. Команда push --dry-run сохраняет строгую проверку исходной версии и может попросить выполнить pull даже после изменений в другом модуле. Она не обновляет рабочую папку или её исходную версию. Просмотр diff и проверка отправки остаются отдельными шагами.

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

Если проект состоит из API, сайта и фонового обработчика, объедините их локальные папки в один план. Вы увидите порядок зависимостей и выбранные окружения до отправки изменений. Для одного workspace эти настройки не нужны.

1. Подготовьте рабочие папки нужных модулей обычным способом через CLI.

Укажите корни поиска явно; папки могут находиться в разных каталогах.

1. Найдите рабочие папки одного проекта и создайте декларацию в общем каталоге:

Этот каталог должен существовать; повторный init не перезаписывает уже созданные настройки.

   agnostic project discover --root ./modules --root ../worker --project <проект> --json
   agnostic project init . --project <проект> --environment <окружение> --root ./modules --root ../worker

1. Проверьте найденные модули в agnostic.project.json. Заполните dependsOn

ключами модулей, которые должны идти раньше, и уточните releaseOrder. В releaseOrder каждая часть должна встречаться ровно один раз, после своих зависимостей. Зависимости при создании пусты: CLI не угадывает их по коду. Например, сайт и обработчик могут зависеть от API, а выбранный порядок — api, worker, site.

1. Проверьте декларацию и получите план:

   agnostic project validate --manifest ./agnostic.project.json
   agnostic release plan --manifest ./agnostic.project.json --json

agnostic.project.json хранит переносимые настройки проекта, модулей, зависимостей и окружений; его можно добавить в Git. Файл .agnostic/project.local.json хранит привязки рабочих папок этой машины, исключается из Git и может содержать абсолютные пути. Не добавляйте в эти файлы пароли или ключи. При переходе на другой компьютер подготовьте его workspace и локальные привязки отдельно.

По умолчанию все модули должны указывать одно окружение. Команда agnostic release plan --environment <окружение> меняет окружение по умолчанию только для модулей без собственного environmentId. Если у одного модуля явно указано другое окружение, команда остановится. Сверьте настройки; для намеренного смешанного плана добавьте --allow-mixed-environments. В результате останется предупреждение с выбранными окружениями: этот флаг не делает разные окружения одинаковыми.

На другой машине можно сохранить общий manifest и выполнить project init с папками её workspace: команда создаст недостающие локальные привязки, не меняя manifest. Проект, исходное окружение и все модули должны совпасть. Уже существующие локальные привязки не перезаписываются.

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

План целиком локальный: он не требует входа и не обращается к серверу. Поэтому успех не подтверждает текущие права, срок доступа или готовность окружений к выпуску. При дальнейшей работе отдельные команды выполнят свои обычные проверки. План не отправляет код, не запускает сборку и не публикует модули; исполнение общего выпуска пока не входит в эту команду.

Если вы используете общий контекст локального агента, храните его в корне проекта в .agnostic/agent-context.json. Для плана этот файл необязателен; копировать его в каждый модуль не требуется. Если он присутствует, проверка отклонит повреждённый файл или контекст другого проекта. Целый кэш другого окружения пропускается с предупреждением и не мешает выбрать нужное окружение. Устаревший, но целый контекст даст предупреждение; обновите его обычной командой получения контекста перед выполнением действий.

После проверки плана подготовьте связанный выпуск: он закрепляет конкретную версию каждого модуля и результат её сборки в одном сохранённом наборе. Новая успешная сборка не заменит выбранную версию незаметно для вас.

Готовые сборки в сохранённом наборе остаются привязанными к выбранным версиям, даже если после этого появилось много изменений в соседних модулях. Только по этой причине пересобирать их не нужно. Перед публикацией Agnostic всё равно проверяет исходники, доступ и выбранное окружение.

Для выпуска все модули должны указывать одно окружение. Разрешение смешанного read-only плана не разрешает выполнить такой набор: сначала исправьте окружения и повторите проверку.

Доступ, сборка и публикация подтверждаются для разных целей:

На странице публикации проверьте окружение и весь состав набора, а не только название проекта. Для Dev и Preview изменяется выбранное окружение; production остаётся прежним. Если окружение не определено, сначала уточните его — отсутствие сведений не означает, что production защищён от изменений.

Роль в проекте, возможность подготовить запрос и право подтвердить его показываются отдельно. Проверьте, какой аккаунт сейчас подтверждает действие и до какого времени действует запрос. Полученный доступ CLI не даёт ему права нажать подтверждение за вас. Если запрос истёк или текущий аккаунт не может его подтвердить, действие не разрешено этой страницей; получите допустимый запрос через исходный сценарий. Срок запроса отличается от срока доступа CLI.

1. Доставьте нужные изменения обычным способом через workspace CLI. Если

несколько модулей используют один репозиторий, отправляйте их последовательно и проверяйте результат каждого push. При конфликте остановитесь и обновите исходную версию перед повтором. Уже принятые изменения остальных модулей автоматически не откатываются. Перед сборкой CLI отдельно сверяет сохранённую версию каждого модуля: изменения соседнего модуля не заменяют её общей версией репозитория. Если выбранный модуль изменился после вашего скачивания, выполните agnostic workspace pull, проверьте файлы и создайте новый выпуск. Если сервер пока не умеет подтвердить точную версию модуля, CLI остановится до запроса платной сборки и предложит проверить совместимость сервера и CLI.

1. Запустите agnostic release build --wait, чтобы дождаться общего результата

сборок. Стоимость каждой сборки подтверждается обычным способом. Ожидание показывает состояние каждого модуля и само по себе не публикует проект. Сохраните возвращённый releaseId:

   agnostic release build --manifest ./agnostic.project.json --wait --json

Если локальные изменения ещё не отправлены, явно добавьте --push для их последовательной доставки перед сборкой нового выпуска. Без этого флага команда остановится. Для продолжения уже созданного выпуска используйте прежний идентификатор без --push:

   agnostic release build --release <UUID-выпуска> --wait --timeout-ms 600000 --json

После остановки ожидания можно прочитать свежий результат через agnostic release status --release <UUID-выпуска> --json. Чтение не продолжает сборки и не сохраняет комплект. Если ответ показывает ready, но bundleHash ещё пуст, завершите фиксацию прежней командой release build --release <UUID-выпуска> перед подготовкой публикации.

1. После успешных сборок подготовьте публикацию сохранённого набора командой

agnostic release prepare-deploy --release <UUID-выпуска>. На открывшейся странице проверьте окружение и версии всех модулей. Одно подтверждение относится только к этому набору; подготовленный запрос ещё не означает, что публикация началась.

1. Дождитесь проверенного результата всех модулей. Если часть действий не

завершилась, посмотрите, какие модули уже опубликованы, какие завершились ошибкой и какие ещё не выполнялись. Не объявляйте весь выпуск успешным по результату одного модуля.

   agnostic release status --release <UUID-выпуска> --json

Повтор после частичного сбоя использует тот же сохранённый набор версий. Сначала прочитайте его состояние: допустимые незавершённые шаги можно повторить, сохраняя результаты остальных. Если нужно изменить код, выбранную сборку или окружение, подготовьте новый выпуск и новое подтверждение. CLI не подбирает «последнюю успешную сборку» вместо подтверждённой версии.

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

agnostic release prepare-deploy --release <UUID-выпуска> --retry-action <UUID-действия>

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

Если срок подтверждения публикации истёк и публикация ещё не начиналась, подготовьте новое подтверждение того же готового выпуска с новым UUID запроса:

agnostic release prepare-deploy --release <UUID-выпуска> --request-id <новый-UUID-запроса>

CLI сначала проверит на сервере, что прежний запрос истёк без подтверждения и запуска. Готовые сборки сохранятся; новый запрос нужно подтвердить отдельно. Для продолжения новой попытки используйте тот же UUID запроса или повторите команду без --request-id. Если состояние прежней публикации неизвестно или она уже начиналась, новый UUID не разрешает начать её заново. Для частичного сбоя используйте описанный выше --retry-action.

Сведения о ходе работы сохраняются в .agnostic/releases/<releaseId>/state.json, а готовый набор — отдельно в bundle.json рядом с ним. Эти файлы относятся к этой машине и не добавляются в Git. Не изменяйте готовый набор вручную. --non-interactive позволяет получить ссылку подтверждения без открытия браузера; --timeout-ms ограничивает ожидание сборок, но не подтверждает действия за пользователя.

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

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

Профиль определяет назначение доступа:

Ориентируйтесь на полный список разрешений именно вашего запроса. Название профиля не заменяет этот список и не расширяет вашу роль в проекте.

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

После нажатия Разрешить доступ CLI или Отклонить дождитесь результата. Во время отправки решения кнопки недоступны. При ошибке отправки проверьте сообщение на экране и повторите нужное решение; прежний список разрешений остаётся видимым.

Добавляйте изображения, шрифты, PDF, архивы, видео и другие обычные файлы в рабочую папку сервиса или сайта. Для изображения сайта, например, используйте public/photo.jpg и обычную ссылку на него в коде.

agnostic workspace status
agnostic workspace push -m "Добавить изображения" --build

Код и файлы сохраняются одной версией. Clone и pull возвращают исходное содержимое; дополнительная настройка хранения крупных файлов не требуется. Поддержка подготовлена в CLI 0.13 / MCP 0.9 и станет доступна после выпуска пакетов и обновления сервера.

Одна отправка поддерживает до 5000 изменённых файлов и 1 ГиБ их содержимого; отдельный файл — до 512 МиБ. В рабочей папке также может быть до 5000 файлов и 1 ГиБ содержимого: push проверяет получившуюся версию, чтобы её можно было снова скачать. Служебные папки, зависимости и секреты остаются исключены из рабочего набора. Если проект исчерпал доступный объём временных загрузок, продолжите незавершённую отправку или дождитесь очистки временных файлов.

Большие файлы передаются частями. При обрыве связи выполните:

agnostic workspace push --resume

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

Если прервался clone, повторите исходную команду с той же папкой. Для прерванного pull повторите agnostic workspace pull. CLI продолжит скачивание и проверит все файлы перед заменой рабочей копии. Если после обрыва вы изменили затронутый файл, команда сообщит о конфликте и сохранит вашу правку. После долгого перерыва CLI получит свежую версию файлов с сервера; совпадающие частичные загрузки можно использовать повторно.

Из папки workspace выполните:

agnostic doctor --workspace --environment <environment-id> --json
agnostic doctor --workspace --environment <environment-id> --client codex --json

Doctor проверит текущие права на сервере и отдельно покажет готовность чтения, отправки кода, чтения сборок и подготовки публикации. Общий ready: true означает, что готовы все четыре операции. Проверка с --client дополнительно проверяет настройку выбранного MCP-клиента; доступны codex, claude и cursor. Обычная проверка не меняет локальные файлы. --fix обновляет только безопасный контекст выбранного окружения. Для замены учётных данных используйте вход или настройку агента по подсказке doctor.

Рабочая роль admin в MCP не гарантирует доступ к отправке: CLI-профиль должен разрешать изменение workspace, а привязка рабочей папки должна оставаться действительной. Ошибка теперь отдельно указывает на учётные данные, недостающие разрешения, роль или срок привязки.

Проверка и продление обращаются только к серверу сохранённого доступа. Адрес рабочей папки, профиль CLI и адрес выданной привязки должны совпадать. Изменение адреса в служебных файлах workspace не переносит доступ на другой сервер. При несовпадении CLI не отправит привязку другому серверу и отклонит обращение к workspace; проверьте адрес входа и заново подключитесь к нужному серверу, сохранив свои правки. Значения ключей доступа передавать в чат или поддержку не нужно.

Если используете AGNOSTIC_API_TOKEN или AGNOSTIC_TOKEN, явно задайте AGNOSTIC_API_BASE_URL того же сервера. Привязка, выданная более старым CLI без сохранённого адреса сервера, дополнительно требует совпадающий сохранённый профиль workspace. Один токен в переменной окружения не подтверждает адрес такой старой привязки; сначала выполните обычный вход для нужного сервера. Не исправляйте привязку вручную.

Если истёк только срок привязки, выполните:

agnostic workspace renew --json

Локальные изменения сохранятся. Renew продлевает привязку на семь дней, сохраняя исходную версию кода. При pull_required сначала выполните agnostic workspace pull и разрешите возможные конфликты. Успешные pull и push тоже продлевают срок привязки. CLI один раз автоматически продлевает её при точной ошибке истечения срока и повторяет исходный запрос. Отозванные права, неправильная подпись и изменившаяся область доступа требуют исправления причины.

Отдельные возможности восстановления или общей публикации могут быть временно недоступны для проекта. Код delivery_feature_unavailable означает такую паузу, а не потерю роли или необходимость нового токена. Сохраните локальные правки и состояние выпуска, проверьте статус уже начатой операции и дождитесь восстановления либо обратитесь к администратору проекта. Уже принятая операция может завершиться во время паузы. Не создавайте новый запрос вместо исходного, пока его результат неизвестен.

Команды status, pull и push запускаются из папки, созданной при clone. CLI использует сохраненный контекст этого workspace, поэтому для push не нужно повторно указывать проект, сервис или сайт. Push отправит изменения через Agnostic, а --build запустит сборку новой версии.

Push выполняется на платформе в фоне. CLI показывает ход работы короткими строками: В очереди, затем Отправляем изменения и в конце Готово. Пока идёт отправка, можно ничего не делать — команда сама дождётся результата.

По умолчанию CLI ждёт до 5 минут. Изменить ожидание можно флагом --timeout <секунды> — максимум час. Если время вышло, отправка не отменяется и не повторяется: изменения уже приняты платформой и продолжают отправляться. CLI подскажет, как дождаться результата:

agnostic workspace push --resume

Если связь с платформой пропала в момент отправки, CLI не бросает изменения: короткие сбои сети он переживает сам, а если ответ так и не пришёл — сохраняет незавершённую отправку и предлагает ту же команду --resume. Повторный запуск продолжит начатую отправку, а не создаст вторую.

Пока незавершённая отправка не закончится, новый push не запустится. Отменить ожидающую отправку можно так:

agnostic workspace push --cancel

Если платформа ещё не вернула идентификатор отправки, --cancel удаляет только локальную запись и больше не блокирует новый push. Это не доказывает, что платформа не успела принять изменения: уже начатая серверная операция может продолжить работу. Поэтому сначала безопаснее выполнить --resume. Для такой отправки команда повторит запрос с тем же идентификатором — платформа вернёт существующую операцию или создаст её один раз, не записывая изменения дважды.

Ctrl+C просит платформу отменить отправку. Если изменения уже начали отправляться, CLI подождёт до 15 секунд и завершит работу нормально: отмена в этот момент уже невозможна, а результат сохранится локально.

Команда agnostic workspace status показывает незавершённую отправку и её состояние. Если отправка успела завершиться, статус сам применит результат локально. Когда нет сети или вы вышли из аккаунта, статус честно сообщит, что проверить состояние сейчас нельзя, и напомнит команду продолжения. Неподтверждённая отправка тоже видна в статусе — с обеими подсказками: продолжить или отменить. Одни и те же изменения не отправляются дважды: платформа узнаёт повторный запрос и продолжает уже начатую отправку.

Сборка относится именно к версии, созданной этим push. Команда push вернёт идентификатор проверки сборки, а build wait дождётся её завершения и покажет безопасный статус с коротким фрагментом журнала без секретов и служебных ссылок. Ожидание длится до 10 минут по умолчанию; через --timeout <секунды> его можно увеличить максимум до часа. Команда build status остаётся для разовой проверки без ожидания.

Для привязки к версии из ответа push передайте --commit <commit> в build wait или build status. Если сервер вернёт другую версию или другую сборку, проверка завершится ошибкой. Успешный build wait означает, что сборка доступна для публикации; ошибка сборки или отсутствие готового результата возвращают код 6 и безопасный журнал. Таймаут возвращает код 7: продолжите ожидание той же сборки. Остановка build wait или agent wait прекращает только наблюдение, серверная работа продолжается.

Ожидание в обычном режиме выводит текущий этап в stderr. С --json этот прогресс включается явно через --progress:

agnostic build wait <build-id> --commit <commit> --json --progress
agnostic agent wait <action-id> --json --progress
agnostic workspace push -m "Обновить страницу" --build --json --progress

stdout содержит один итоговый JSON при успехе; stderr — сообщения прогресса по одному JSON на строку и итоговую ошибку, если она возникла. --quiet подавляет прогресс. Эти дополнения текущей разработки станут доступны в установленном CLI после выпуска и обновления пакета.

Сборка не публикует сайт или сервис автоматически. При ошибке исправьте код и создайте новый push. Если вы поручили публикацию локальному агенту, после успешной сборки он подготавливает отдельное действие публикации и следует действующему допуску или возвращает ссылку для вашего подтверждения. Вручную это можно сделать кнопкой Опубликовать на странице ресурса.

Для этих команд нужны CLI 0.6.0 / MCP 0.2.0 или новее и сервер с поддержкой Data read. Версии подготовлены к выпуску; до публикации установленный клиент может ещё не поддерживать команды. Чтение не создаёт миграций и ничего не изменяет.

Сначала разрешите только чтение структуры и сохраните полный снимок:

agnostic data login --access schema
agnostic data schema --project <project-id> --environment <environment-id> --out schema.json --json

В снимке есть таблицы, поля, индексы, их стабильные ID, целевая и применённая схемы. Это снимок для проверки, а не готовый план миграции. Выберите новое имя файла внутри текущей папки: существующий файл не перезаписывается.

Для записей требуется отдельное разрешение. Возьмите collectionId из снимка и явно укажите проект и окружение либо задайте их переменными AGNOSTIC_PROJECT_ID и AGNOSTIC_ENVIRONMENT_ID:

agnostic data login --access records
agnostic data records <collection-id> --project <project-id> --environment <environment-id> --input query.json --json
agnostic data count <collection-id> --project <project-id> --environment <environment-id> --json
agnostic data aggregate <collection-id> --project <project-id> --environment <environment-id> --input aggregate.json --json

Например, query.json может содержать {"fields":["name"],"limit":50}. Для следующей страницы передайте полученный nextCursor как cursor, сохранив остальные параметры запроса. Для агрегата используйте, например, {"metrics":[{"operation":"sum","field":"amount","as":"total"}]}. Содержимое файлов — UTF-8 JSON до 1 MiB. Большие целые числа передаются строками. При защищённых полях или превышении лимита команда возвращает ошибку, а не неполный успешный результат: выберите безопасные поля или меньшую страницу.

Если схема ещё не применена или история миграций повреждена, чтение записей блокируется; сначала проверьте состояние Data в выбранном окружении. Окружение production автоматически не выбирается. Доступ к другому адресу API нужно выдать отдельно через --api-url.

MCP использует тот же отдельный Data-доступ. После его выдачи обновите список инструментов или перезапустите клиент. Инструмент схемы возвращает краткую сводку и ссылку на полный снимок; чтение ссылки повторно проверяет доступ. Если схема изменилась, получите новую ссылку. Записи читаются только явным вызовом инструмента и не добавляются в контекст агента автоматически.

Для сохранения и запуска плана нужна роль администратора или разработчика и отдельно настроенный профиль Local Agent. Если он ещё не настроен, выполните agnostic agent setup для своего MCP-клиента. Разрешение Data read и обычный workspace-токен не дают право создавать планы.

Полный управляемый сценарий схемы и импорта требует CLI 0.7.0 / MCP 0.3.0 или новее. Публикация этих версий и включение совместимого сервера выполняются отдельно от установки кода.

Подготовьте desired-schema.json с environmentIds, режимом merge или reconcile и полным bundle. Сначала сохраните неизменяемый план:

agnostic data plan --project <project-id> --input desired-schema.json --json

Команда вернёт planId, полный sha256: hash, срок действия и точный diff, но ничего не применит. При необходимости перечитайте план:

agnostic data plan-status <plan-id> --project <project-id> --json

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

В режиме merge пропущенные объекты остаются без изменений. Режим reconcile задаёт полную структуру выбранного хранилища; пропущенные таблицы, поля и индексы попадают в список удалений. Для существующих объектов указывайте стабильные ID из снимка, а не только имена. Связи задаются явно стабильными ID исходной и целевой коллекции и поля; Agnostic не угадывает их по названию *_id. Поддерживаются ссылки «многие к одному» на ID цели и безопасное удаление restrict. Изменение готовой связи выполняйте как явное удаление и создание.

Проверьте список удалений, блокирующие причины и каждое выбранное окружение. Уже ожидающие миграции показаны отдельно: они тоже могут содержать удаления. Невыбранные окружения не изменяются и могут остаться позади целевой схемы. Если поле необходимо сохранённому представлению, сначала исправьте его настройки. Изменения типов, переименования и другие неподдержанные операции блокируются; автоматического пересоздания таблиц или отката нет.

В совместимой версии сервера можно добавить или удалить индекс существующей строковой коллекции через этот же подтверждаемый план. В indexes укажите техническое имя, упорядоченные columns и тип global для синхронного индекса. Замена состава индекса с тем же именем будет показана как удаление и создание; записи, поля и сохранённые представления при этом не пересоздаются. Для index-only шага сервер может сохранить ограниченное историческое расхождение nullable между ledger и физической таблицей: точная форма колонок фиксируется до DDL и должна без изменений подтвердиться после него. Это не исправляет расхождение и не делает поле необязательным на уровне приложения. Другое имя, тип, ключ, состав колонок или неподдерживаемая физическая схема по-прежнему блокируют задачу. Если прежний способ применения отказывается менять индекс, используйте план, а не повторную отправку старой операции. Если такой шаг уже попал в историю и раздел Данные показывает ошибку, сначала передайте её в поддержку: подготовка нового плана сама по себе не исправит застрявшую историю.

Индекс помогает точному поиску по первым указанным в нём полям. Подтверждённый синхронный индекс используется подходящими запросами списка, количества и агрегатов; асинхронные индексы автоматически не выбираются. Индекс не создаёт связь, не гарантирует уникальность и не заменяет проверку связанных записей. Он занимает место и добавляет работу при записи: создавайте его для частых запросов, а не для каждого поля. Неподдерживаемые настройки коллекции или неизвестный результат построения блокируют успешное завершение; дождитесь проверенного статуса задачи, не повторяя изменение вслепую.

Передайте CLI ровно тот planId и hash, который проверили:

agnostic data prepare <plan-id> --hash <sha256:...> --project <project-id> --json

Команда вернёт actionId и ссылку на экран подтверждения. Она не подтверждает и не запускает план. Повтор с тем же --request-id возвращает то же действие; другой план или hash под тем же ID отклоняется. План действует 15 минут с момента создания; повтор того же запроса не продлевает срок. Изменившуюся схему нужно проверить новым планом.

В окне подтверждения Agnostic показывает точные операции, полный список удалений, выбранные окружения, окружения, которые останутся позади, и технические planId/hash. Устаревший, просроченный или заблокированный план подтвердить нельзя. После подтверждения видны jobId, состояние и число проверенных шагов. Закрытие окна только прекращает наблюдение: серверная задача продолжает работу. Кнопка безопасной остановки существует отдельно и останавливает выполнение на границе между шагами; уже выполненные шаги автоматически не откатываются.

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

После подтверждения в браузере возьмите jobId из статуса действия или плана:

agnostic data job status <job-id> --project <project-id> --json
agnostic data job logs <job-id> --after 0 --limit 100 --project <project-id> --json
agnostic data job wait <job-id> --timeout 600 --project <project-id> --json
agnostic data job report <job-id> --project <project-id> --json

logs читает журнал страницами до 200 событий. report доступен после завершения и сверяет все страницы перед итогом. Таймаут или остановка локального wait только прекращает ожидание: серверная задача не отменяется. При потере ответа нельзя считать изменение отменённым и отправлять его повторно — сначала проверьте status, журнал и итоговый отчёт. Неизвестный результат не считается успехом.

Если схема занята задачей, дождитесь её проверенного результата. Сообщение об отмене не означает откат: уже выполненные шаги сохраняются. Неизвестный результат нельзя считать ни успехом, ни разрешением повторить запись.

Шаги могут завершаться отдельно: общая схема уже обновилась, а её сохранение или применение в окружении ещё не завершено. Это частичный результат, не успех всей операции. Если файлы схемы конфликтуют с черновиком, задача останавливается без удаления черновика. Разберите конфликт перед созданием нового плана; повтор не должен затирать несохранённые изменения.

Администратор или разработчик с настроенным профилем Local Agent может заранее проверить файл записей. На этом шаге записи в коллекции не создаются и не изменяются.

Подготовьте gzip-файл JSON Lines. Первая строка задаёт версию формата, проект, окружение и коллекцию; каждая следующая строка содержит sourceId и объект values. Большие целые и точные десятичные значения передавайте строками. Совместимый клиент может закрепить в первой строке sourceNamespace и sourceCollection; оба значения нужны вместе. Они отделяют одинаковые старые ID из разных исходных систем и коллекций. Agnostic не выводит исходные ID в журналы или отчёты.

В полях даты и времени указывайте существующий календарный день и время в UTC. Например, 31 сентября или 24:00 считаются ошибками, а не переносятся на следующий день. Файл с такими строками не готов к импорту: исправьте даты по отчёту и повторите проверку.

Если файл содержит ссылки между записями, каждая ссылка указывает relationId из текущей схемы и цель через sourceNamespace, sourceCollection, sourceId. Не передавайте новое значение поля связи внутри values: оно применяется отдельно после создания всех записей.

agnostic data import validate ./records.jsonl.gz \
  --project <project-id> \
  --environment <environment-id> \
  --collection <collection-id> \
  --source-namespace legacy-crm-2026-09 \
  --source-collection contacts \
  --json

CLI принимает только явно указанный обычный файл, не следует по символическим ссылкам и не печатает временный адрес загрузки. Максимальный размер gzip-файла — 100 MiB, после распаковки — 500 MiB; допускается до 1 000 000 строк и до 1 MiB на строку. Проверка ограничена пятью минутами. Временная загрузка действует 15 минут, корректный приватный артефакт — 24 часа.

Статус valid означает, что все строки соответствуют текущей схеме. Статус invalid показывает количество строк с ошибками; отчёт содержит только номер строки, поле и безопасный код без исходного значения. Если схема изменилась, создайте и проверьте новый файл. Проверка сама по себе не разрешает импорт и не является его подтверждением.

Для каждой принятой строки план сохраняет однозначное соответствие старого ID новому ID в выбранном окружении. Повтор старого ID с другим назначением блокируется как конфликт. Ссылка на запись из другого окружения также блокируется: Agnostic не переносит её автоматически.

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

agnostic data import plan <artifact-id> --json
agnostic data import plan-status <plan-id> --json
agnostic data import plan-links <plan-id> --after 0 --limit 100 --json

План показывает выбранные проект, окружение и коллекцию, число строк и ссылок, конфликты идентификаторов, активные автоматизации и контрольные суммы. Отчёт по ссылкам сообщает resolved, missing, ambiguous или cross_environment, но не раскрывает старые ID и значения полей. Любая неразрешённая ссылка блокирует весь план. Обязательные связи пока также блокируются: их нельзя безопасно заполнить после вставки записи с обязательным полем.

Если статус плана ready, подготовьте браузерное подтверждение точного hash:

agnostic data import prepare <plan-id> --hash <sha256> --json

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

На экране подтверждения проверьте точные проект, окружение и таблицу, количество строк и частей файла, число разрешённых ссылок, четыре предварительные проверки и строгую политику выполнения. Технический блок показывает planId, hash, артефакт и снимок схемы, но не показывает значения записей и старые исходные ID. Устаревший или заблокированный план нельзя подтвердить: нужно закрыть окно, устранить причину и создать новый план. Изменяемых полей на этом экране нет — кнопка подтверждает только показанный неизменяемый план.

Применение начинается только после подтверждения точного плана в браузере. Закрытие браузера или CLI не отменяет уже принятую серверную задачу. При обрыве сначала откройте её статус и построчный отчёт; не запускайте тот же файл заново. Строки с уже доказанной записью будут сверены и продолжены без дублирования, а несовпадающий занятый идентификатор остановит задачу как конфликт. Отчёт показывает номера строк, результаты и безопасные коды без значений полей. Связи создаются только после всех записей, поэтому циклы внутри одной коллекции и ссылка записи на себя поддерживаются. Ссылки в другую коллекцию требуют, чтобы целевая запись уже была успешно импортирована. Итог второго прохода читайте страницами:

agnostic data import job-links <job-id> --after 0 --limit 100 --json

Чтение структуры и содержимого данных требует отдельных разрешений. На экране подтверждения профиль «Структура данных — только чтение» открывает таблицы, поля и индексы, но не записи. Профиль «Данные — только чтение» также разрешает получать выбранные записи, количество и агрегаты: эти данные сможет получить подключённый агент. Оба профиля не разрешают запись, удаление, публикацию или подтверждение действий. Ранее выданный доступ не расширяется автоматически. Проверьте профиль перед разрешением; если чтение записей не нужно, отклоните такой запрос. Возможность зависит от версии подключённого клиента и сервера.

Активные токены CLI видны в профиле: Профиль -> Безопасность -> Agnostic CLI. Там можно проверить название устройства, префикс токена, разрешения, дату создания и последний доступ.

Повторно входить перед clone, pull или push не нужно. Если снова выполнить agnostic login на том же компьютере, CLI проверит сохранённый токен и продолжит использовать его без нового подтверждения. Команда agnostic login --force нужна только для намеренной смены аккаунта или перевыпуска токена.

Если устройство потеряно или доступ больше не нужен, отзовите токен в этом разделе. После отзыва команды workspace clone, workspace pull и workspace push с этим токеном перестанут работать; для продолжения выполните agnostic login заново.

CLI работает через Agnostic API. Он не получает прямой доступ к Git, служебным адресам репозитория, учетным данным, секретам или запрещенному содержимому файлов.

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

Проверяйте смысл каждого разрешения перед подтверждением. Если запрос локального агента показывает запись workspace, запуск сборки или неизвестное разрешение, отклоните его. Все изменения ресурсов по-прежнему потребуют отдельного подтверждения в браузере.

После подключения локальный агент может получить безопасный снимок выбранного проекта и окружения: доступные действия, структуру Data, опубликованные автоматизации, состояние App Auth и подключений, публичные адреса и текущую поверхность Runtime SDK. В снимок не входят значения переменных окружения, ключи, пароли, токены, служебные идентификаторы провайдера и прямой доступ к облачным ресурсам.

Время следующей проверки снимка напоминает клиенту свериться с сервером. Оно не выдаёт и не продлевает доступ. Если ресурсы и права не изменились, клиент продолжает работу с тем же контекстом. Перед подготовкой каждого действия сервер заново проверяет ваши права, окружение и актуальность ресурсов. Чтение контекста ничего не меняет в проекте; выполнение действия требует подходящего допуска сессии или отдельного подтверждения в Agnostic.

Чтобы подключить локальный агент, откройте терминал внутри клонированного workspace и выполните одну команду. Замените codex на claude или cursor, если используете другой клиент:

agnostic agent setup codex \
  --environment <environment-id>

CLI проверит проект workspace и окружение, откроет страницу выдачи отдельного доступа локальному агенту, создаст первый локальный контекст и подключит официальный MCP-сервер в пользовательских настройках клиента. Копировать токен или вручную редактировать MCP-конфиг не нужно. После успешной настройки перезапустите клиент.

Если доступ локального агента истёк, повторите agnostic agent setup codex в том же проекте и окружении. При обычном запуске, в том числе с --json, CLI сам откроет страницу подтверждения в браузере. Флаги --no-open и --non-interactive отключают автоматическое открытие. Вам нужно только подтвердить доступ на открывшейся странице; если браузер не открылся, ссылка останется в выводе команды. Локальный агент также может открыть для вас ссылку подтверждения действия, но само решение всегда принимаете вы.

До подключения можно безопасно посмотреть план без открытия браузера и записи файлов:

agnostic agent setup codex \
  --environment <environment-id> \
  --dry-run

Для диагностики подключения выполните:

agnostic agent doctor codex

Диагностика ничего не меняет и проверяет доступ к Agnostic, свежесть контекста, наличие MCP-сервера и настройки выбранного клиента.

Эта настройка подключает установленный Codex к Agnostic как локальный MCP-клиент. Вход через ChatGPT для Codex, который исполняется как агент на вашем устройстве, является отдельной настройкой. Он пока не доступен в опубликованном runtime: для него нужен проверенный выпуск Codex. Одноразовый код такого входа показывается только на устройстве, не в браузере Agnostic. Когда проверенный выпуск станет доступен, команда входа сможет работать и при запущенном локальном агенте: останавливать его ради входа не потребуется.

Setup создаёт локальный .agnostic/agent-context.json и понятные агенту Markdown-инструкции в .agnostic/context/. Это временный снимок: его не нужно коммитить, а workspace push полностью игнорирует .agnostic/**. API-токен, ключи подключений и runtime token туда не записываются. Доступ локального агента хранится отдельно от доступа к workspace, но в том же защищённом пользовательском хранилище Agnostic CLI.

Сначала агент читает .agnostic/context/AGENT_CONTEXT.md, затем карточку нужной таблицы, автоматизации, App Auth или подключения. Карточки показывают актуальные безопасные поля, состояние, ошибки и примеры реализации: запись в Data, запуск и ожидание автоматизации, проверку пользовательской сессии или переход в защищённую форму подключения. Доступные методы всегда сверяются с установленной версией Runtime SDK.

Обновлять только изменившийся контекст

После наступления времени следующей проверки CLI и MCP автоматически сверяют снимок с сервером перед подготовкой действия. Если контекст не изменился, карточки не создаются заново. При долгой работе с теми же ресурсами ручная синхронизация каждые несколько минут не нужна.

Чтобы проверить контекст сейчас и обновить только изменившиеся карточки, выполните в папке задачи:

agnostic context sync --changed-only

Команда сообщает, изменился ли контекст. Изменённые карточки обновляются, исчезнувшие ресурсы удаляются из снимка, а остальные карточки сохраняются. Новый снимок устанавливается целиком после проверки всех файлов. Если запись прервана или данные небезопасны либо слишком велики, предыдущий полный снимок сохраняется. Для полной пересборки локальных карточек выполните agnostic context sync без флага.

Если подготовка действия прервана во время проверки или обновления контекста, CLI не отправляет предложение на платформу. Уже принятое сервером действие проверяйте через agnostic agent status: остановка локальной команды его не отменяет.

Без связи с сервером уже сохранённые карточки можно читать как справку. Их актуальность не подтверждена; подготовка изменения требует успешной серверной проверки. Смена роли или окружения не обходится сохранённым снимком. Эти правила работают после обновления CLI, MCP-сервера и Agnostic.

После синхронизации проект и окружение читаются из снимка:

agnostic agent context --json
agnostic agent capabilities --json
agnostic agent prepare app.auth.configure --input ./action.json --json
agnostic agent status <action-id> --json
agnostic agent wait <action-id> --json

Файл для agent prepare содержит только параметры выбранного действия. Credential-поля, API keys, пароли, токены и зашифрованные secret payload запрещены. Если для подключения нужен ключ, результат содержит только безопасный переход в форму Agnostic.

agent prepare возвращает ссылку подтверждения и запрашивает её открытие в браузере, если действие ожидает решения и команда запущена без --non-interactive. Поле browserOpenRequested показывает, удалось ли передать ссылку браузеру; если нет, откройте её из ответа вручную. Открытие страницы не подтверждает действие: решение принимаете вы в Agnostic. agent wait ждёт итог после вашего решения. Для агента на вашем компьютере используйте --json: команда выведет один JSON-объект и откроет подтверждение, если оно нужно. Для фоновых сценариев используйте --non-interactive --json: ссылка останется в ответе, но браузер не откроется. --quiet полностью скрывает успешный вывод, но оставляет ошибки в stderr.

Основные exit codes:

| Код | Результат | | --: | --------------------------------------------------------- | | 0 | Команда или действие успешно завершены | | 2 | Ошибка параметров или credential-like input | | 3 | Действие отклонено | | 4 | Срок подтверждения истёк | | 5 | Действие отменено | | 6 | Подтверждённое исполнение завершилось ошибкой | | 7 | Истекло время ожидания | | 8 | Контекст изменился — повторите синхронизацию и подготовку | | 9 | Требуется обновить несовместимую версию CLI |

Проект можно передать через --project или AGNOSTIC_PROJECT_ID, окружение — через --environment или AGNOSTIC_ENVIRONMENT_ID. Внутри клонированного workspace project id также берётся из .agnostic/workspace.json; environment всё равно нужно выбрать при первой синхронизации.

Начните с короткого обзора ресурсов выбранного проекта и окружения. Чтобы ограничить его текущей задачей, укажите модуль через --unit и готовый вариант задачи через --task:

agnostic context cards --unit <unit-id> --task frontend --resource <resource-key>
agnostic context cards --task data --resource <resource-key>

Доступные варианты задачи: frontend, backend, data, auth, automation и delivery. Ключ нужного ресурса можно передать через --resource; параметр можно повторить для нескольких ресурсов. Выбор модуля относится к его workspace. Зависимости между модулями и другими ресурсами автоматически не угадываются: перечислите нужные ресурсы явно.

Откройте подробности отдельной карточки, когда они понадобятся:

agnostic context card <resource-key>

Команда принимает те же --unit, --task и --resource. Для чтения уже сохранённого снимка без сетевого запроса добавьте --offline к context cards или context card. Такой просмотр не подтверждает актуальность снимка и текущие права на изменение. Выбор --unit требует online-проверки привязки workspace и с --offline не совмещается.

Чтобы начальные инструкции локального агента тоже начинались с выбранного обзора, синхронизируйте контекст с теми же параметрами:

agnostic context sync --unit <unit-id> --task frontend --resource <resource-key>

Выбор карточек действует на текущую синхронизацию. Автоматическое обновление снова формирует обзор проекта; для повторения выборки передайте параметры ещё раз. Полный снимок для проверки актуальности сохраняется. Выбор карточек помогает сосредоточиться на задаче; доступ к ресурсам и разрешение действий по-прежнему проверяет сервер. Команда agnostic agent context --json сохраняет прежний формат полного ответа.

В карточках Data учитывайте показанные первичный ключ, обязательность полей, поля только для чтения, описания, варианты выбора и правила чтения, изменения и поиска записей. Название поля не добавляет ограничений. Связи между коллекциями, внешние ключи, уникальность и JSON-schema здесь не обещаются.

Собрать диагностику для поддержки

Для обращения по проблеме подключения или устаревшему контексту выполните:

agnostic support bundle
agnostic support bundle --output support-bundle.json

Команда выполняет только проверки чтения с ограниченным ожиданием. В JSON попадают версии клиента и среды выполнения, идентификаторы обращений для поддержки, сроки действия и статусы готовности. Ключи доступа, содержимое файлов, адреса сервисов, домашние пути и необработанные внутренние ошибки в диагностику не включаются.

--output принимает относительный путь внутри рабочей папки. Существующий файл или символическая ссылка не перезаписывается; выберите другое имя. Созданный файл доступен только его владельцу. Диагностика не продлевает доступ, не меняет код и не запускает сборку или публикацию.

Через MCP доступны agnostic_context_cards и agnostic_context_card для обзора и подробной карточки. agnostic_support_bundle возвращает JSON без создания локального файла. Новые команды и инструменты становятся доступны после обновления CLI, MCP-сервера и Agnostic.

Пошаговая настройка, примеры запросов агенту и полный список инструментов вынесены в отдельную статью «Как подключить Agnostic MCP к локальному агенту».

Если локальный coding agent поддерживает MCP, установите официальный stdio сервер рядом с CLI:

npm install -g @nsp-labs/agnostic-cli @nsp-labs/agnostic-mcp
cd <папка-workspace>
agnostic agent setup codex --environment <environment-id>

Для Claude Code используйте agnostic agent setup claude, для Cursor — agnostic agent setup cursor. Команда сама добавляет agnostic-mcp в пользовательские настройки клиента и не записывает туда токен. Существующие другие MCP-серверы сохраняются. Повторный запуск безопасен и не дублирует настройку.

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

MCP не умеет подтверждать действие, вводить секрет, напрямую вызывать provider API или публиковать ресурс без отдельного действия. После agnostic_action_prepare откроет полученную ссылку в браузере. Если browserOpenRequested=false, перейдите по ссылке из ответа. Подтвердите или отклоните предложение в интерфейсе Agnostic. Если клиент показывает MCP-инструмент для подтверждения, секретов или прямого provider-доступа, отключите этот сервер и проверьте его команду: официальный agnostic-mcp таких инструментов не публикует.

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

Когда Agnostic просит подтвердить публикацию, локальный агент открывает ссылку подтверждения и наблюдает за тем же действием. После нажатия кнопки в Agnostic не нужно отдельно писать агенту «подтвердил»: он увидит решение, дождётся результата и продолжит проверку опубликованной версии. Если вы отклоните действие или срок подтверждения истечёт, агент сообщит об этом без повторной публикации.

Когда локальный агент предлагает изменить Data, автоматизацию, App Auth или другой ресурс проекта, Agnostic сначала проверяет действие и возвращает ссылку на подтверждение. До вашего решения ресурс не меняется.

1. Перейдите на страницу подтверждения, которую открыл локальный агент. Если

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

1. Войдите в Agnostic, если сессия истекла.
2. В окне с названием действия проверьте, что произойдёт сразу после

подтверждения, а также выбранные проект и среду. Например, создание черновика автоматизации не запускает её автоматически.

1. При необходимости раскройте Технические детали: там находятся инициатор,

уровень риска, срок действия, неизменяемые параметры и план зависимых действий.

1. Нажмите кнопку с точным названием результата, например Создать черновик,

или выберите Отмена.

1. Дождитесь статуса Выполнено и проверено или безопасного сообщения об

ошибке. Для долгой операции экран сам обновляет состояние.

1. Вернитесь в локальный агент: он дождётся того же результата и обновит

контекст проекта.

Если действие завершилось ошибкой, экран покажет причину и строку Что сделать. При блокировке публикации из-за структуры данных откройте раздел Данные, завершите синхронизацию выбранного окружения, затем обновите контекст локального агента и подготовьте новое действие публикации. Не подтверждайте старый запрос повторно: он привязан к прежнему состоянию сборки и окружения.

Сводка неизменяема после подготовки. Если агент изменил параметры, окружение или версию действия, Agnostic потребует создать новое подтверждение. Ссылка действует ограниченное время. При изменении вашей роли, окружения или доступного бюджета уже подготовленное действие может быть отклонено при подтверждении.

Повторная отправка того же запроса безопасна и возвращает исходное действие. Запрос с тем же идентификатором, но изменёнными параметрами будет отклонён. Не вводите ключи, пароли и токены в чат локального агента: защищённые значения добавляются только через интерфейс Agnostic.

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

Для Data локальный агент может подготовить создание или изменение таблицы и поля, а также создание, изменение или удаление записи. После подтверждения он получает актуальную безопасную схему таблицы, новый отпечаток контекста и примеры Runtime SDK для чтения и записи. Попросите агента обновить локальный контекст перед следующим шагом. Raw SQL и YQL через этот сценарий не выполняются.

Для автоматизации локальный агент может создать или изменить черновик, проверить его, опубликовать выбранную версию и подготовить ручной запуск. Каждое из этих изменений требует отдельного подтверждения. Перед публикацией Agnostic повторно проверяет узлы, связи и доступность подключённых ресурсов в выбранной среде. Если версия или среда изменились после получения контекста, действие будет отклонено и агенту потребуется обновить снимок.

После успеха агент получает безопасную карточку автоматизации: текущую версию, результат проверки, ожидаемые входные данные, статус запуска и актуальные примеры Runtime SDK. Карточка не содержит ключи, пароли и значения подключений. Ручной запуск локального агента использует опубликованную версию именно выбранной среды.

Для App Auth локальный агент может подготовить включение или отключение входа, разрешённые origins и срок сессии. После подтверждения он получает безопасное состояние способов входа и примеры Runtime SDK. Участник платформы, пользователь публичного приложения и server runtime остаются разными субъектами; сессия пользователя приложения не даёт server runtime token.

Для нового подключения агент после подтверждения возвращает переход в защищённую форму с выбранными провайдером и окружением. Сам ключ вводите только там. До отправки формы секрет и интеграция не создаются, а CLI/MCP не получает значение, зашифрованный payload или ссылку на секрет. Открытые настройки существующего подключения агент может изменить по его логической ссылке после отдельного подтверждения.

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

• Как подключить Agnostic MCP к локальному агенту
• Runtime SDK
• Что нельзя класть в браузерный код

Если ответ о принятии push потерялся, выполните agnostic workspace push --resume. Можно продолжать редактировать файлы: продолжение отправит первоначальный снимок, а новые правки останутся локальными изменениями. Если команда отмены ещё не знает принятую операцию, она удаляет только локальную запись продолжения. Это не подтверждает отмену на сервере; чтобы узнать результат, сначала используйте --resume.

Предупреждение build_outcome_unknown означает, что изменения отправлены, но результат запуска сборки после сбоя не подтверждён. Проверьте существующие сборки перед повторным запуском, чтобы не создать лишнюю сборку.

После выдачи допуска сессии в Agnostic выполните в папке задачи:

agnostic agent session <session-id> --project <project-id> --environment <dev-environment-id>

Следующие agent prepare используют эту сессию. Для одного вызова доступен --session <session-id>. agnostic agent session --clear снимает привязку. Команды не выдают допуск и не расширяют права; сервер проверяет срок, область, бюджет и отзыв. Подробнее: разрешения сессии. Подключение ресурсов через agent setup не требует клонирования кода: укажите проект и окружение в отдельной папке задачи. Для отправки кода workspace нужен.