ariekogan/ateam-mcp

Аутентификация с A-Team. Требуется перед любой операцией, учитывающей тенант (чтение решений, развертывание, тестирование и т. д.). Пользователь может получить свой API-ключ по адресу https://mcp.ateam-ai.com/get-api-key. Только глобальные конечные точки (spec, examples, validate) работают без аутентификации. ВАЖНО: Даже если настроены переменные окружения (ADAS_API_KEY), вы ОБЯЗАНЫ явно вызывать ateam_auth - только env vars недостаточно. Для кросс-тенантных административных операций используйте master_key вместо api_key.

ОБЯЗАТЕЛЬНАЯ точка входа для A-Team MCP. ДОЛЖНА вызываться, когда пользователь приветствует, говорит «привет», спрашивает, что это, просит помощи, изучает возможности или при первом подключении MCP. Возвращает объяснение платформы, примеры решений и инструкции по поведению ассистента. НЕ импровизируйте с приветствием, вместо этого вызывайте этот инструмент.

РАЗВЕРНУТЬ ТЕКУЩУЮ ВЕТКУ MAIN НА A-TEAM CORE. ⚠️ САМАЯ ТЯЖЕЛАЯ ОПЕРАЦИЯ (60-180 с): проверяет solution+skills → разворачивает все connectors+skills на Core (пересоздаёт MCP серверы) → проверяет здоровье → опционально запускает warm test → автоматически пушит в GitHub. 🌳 DEV/PROD РАБОЧИЙ ПРОЦЕСС: 1. Редактировать файлы → ateam_github_patch (по умолчанию пишет в ветку dev) 2. (Опционально) Посмотреть, что скоро отправится → ateam_github_diff 3. Отправить dev → main → ateam_github_promote (слияние + автоматический тег prod-YYYY-MM-DD-NNN) 4. Развернуть main на Core → ateam_build_and_run Этот инструмент ВСЕГДА разворачивает ветку main — параметра ref нет. Чтобы развернуть незаконченную dev-работу, сначала продвигайте её. АВТОМАТИЧЕСКИ ОПРЕДЕЛЯЕТ GitHub репозиторий: если опустить mcp_store и репозиторий существует, код коннектора автоматически подтягивается из main. При первом развертывании требуется mcp_store. После этого редактируйте через ateam_github_patch + promote, затем build_and_run. Для небольших изменений предпочтительнее ateam_patch (быстрее, инкрементально). Требуется аутентификация.

SLIM chain status — молниеносный опрос на чипе. Принимает chain_id (из ateam_conversation), дёшево возвращает агрегированный статус ВСЕЙ ЦЕПОЧКИ: chain_status + chain_done (true только когда ВСЯ цепочка — корневая задача + каждый handoff + подвызов askAnySkill — находится в терминальном состоянии), а также pending_question, result и короткую строку прогресса. Это то, что вы опрашиваете в цикле после ateam_conversation — НЕ ateam_get_chain (она возвращает полное дерево; слишком тяжелая для периодического опроса). Отдельная задача может завершиться, пока цепочка ещё выполняется, поэтому опрашивайте chain_done, а не статус задачи. Цикл: вызывайте каждые ~2 с, пока chain_done === true (или не установлен pending_question — ассистент ждёт ответа от пользователя). Затем прочитайте result / получите полное дерево один раз через ateam_get_chain, если нужны детали по каждой задаче.

Читает, что процесс коннектора на самом деле ВЫВЕЛ в stderr. Это единственное место, где виден внутренний сбой коннектора: инструмент, который перехватывает собственную ошибку, всё равно возвращает ok:true, и виджет затем отображает пустое состояние, которое выглядит как реальные данные. Реальный случай (2026-08-11): у коннектора дашборда ledger.getData получил 401 Authentication required от Core, проглотил его, вернул пустой ledger и отобразил 0.00 везде — при этом загрузка сказала ok, инструмент сказал ok:true, а поверхностный зонд сказал surface_ok. Слово 'Authentication' появилось ТОЛЬКО здесь. ИСПОЛЬЗУЙТЕ ЕГО всякий раз, когда инструмент успешен, но данные пустые, неверные или нулевые — такая комбинация является признаком проглоченной ошибки, и 'вызов вернул ok' не является доказательством, что он сработал. Передавайте возвращённый cursor обратно как since, чтобы читать только то, что появилось с момента вашего последнего просмотра, так вы сможете обрамить действие и увидеть, что именно он вывел. Только коннекторы stdio (решение) передают stderr через Core; коннектор platform/HTTP отвечает ok:false с причиной.

Отправляет сообщение развернутому решению и возвращает результат. skill_id не нужен — система сама направляет запрос нужному навыку. Поддерживает многошаговые диалоги: передайте actor_id из предыдущего ответа, чтобы продолжить беседу (например, ответить на подтверждение). Каждый вызов создает новое задание, но один и тот же actor_id сохраняет контекст разговора.

Создаёт каркас нового MCP-коннектора с server.js + package.json + README. Устраняет ~50% идентичного шаблонного кода (настройка MCP-сервера, регистрация инструментов, stdio-транспорт). Затем вы заполняете реализации инструментов. Установите ui_capable=true, чтобы включить заглушки ui.listPlugins / ui.getPlugin (файлы исходников плагинов добавляются отдельно через ateam_create_plugin). После создания каркаса файлы загружаются в Core по тому же пути, что и ateam_upload_connector.

Создай каркас UI-плагина (iframe HTML, React Native TSX или оба варианта) внутри существующего коннектора. Это устраняет ~50% однотипного шаблонного кода (импорты, хуки темы/моста, протокол postMessage, форма экспорта по умолчанию). Остаётся только написать тело компонента. Используй kind='iframe' только для веба, 'rn' только для мобильных, 'adaptive' для обоих. Автообнаружение (Phase 5 of the strip) подхватит новый плагин при следующем деплое без объявления манифеста.

⚠️ КАСКАДНОЕ ВОЗДЕЙСТВИЕ — любой навык, у которого engine.bootstrap_tools или tools[] ссылаются на инструмент из этого коннектора, ПРОВАЛИТ своё следующее выполнение. Останавливает и удаляет коннектор из A-Team Core; удаляет ссылки из определения решения (grants, platform_connectors, ui_plugins id, начинающиеся с mcp:<connector-id>:*) и определения навыка (массив connectors); очищает файлы mcp-store. ТАКЖЕ УДАЛЯЕТ ИСХОДНЫЙ КОД: connectors/<id>/ удаляется из репозитория (одновременно main И dev) в том же вызове, поэтому удаление НЕОБРАТИМО. Это ИЗМЕНИЛОСЬ 23 августа 2026 года: раньше исходный код сохранялся, и можно было вызвать ateam_build_and_run(github:true), чтобы восстановить коннектор. Из-за этого удаление отменяло само себя при последующей публикации, причём только в некоторых состояниях, поскольку массив connectors[] собирается из ключей mcp_store ТОЛЬКО когда он пуст. Если хотите сохранить код, скопируйте его (ateam_get_connector_source) ДО удаления. Если удаление из репозитория не удалось, ответ сообщит об этом в поле github — Core чист, но исходный код всё ещё на месте. ТРЕБУЕТ confirm:true.

⚠️ НЕОБРАТИМО в Core + Builder FS — убивает работающий процесс MCP, удаляет из реестра навыков, удаляет запись в Mongo, убирает из solution.skills[] и solution.linked_skills, а также удаляет файлы навыка из Builder FS. ТРЕБУЕТ confirm:true. ВОССТАНОВЛЕНИЕ: навык остаётся в GitHub — ateam_github_pull пересобирает всё решение (отдельного пути восстановления навыка нет).

⚠️ НЕОБРАТИМО — уничтожает состояние Mongo, запущенные MCP-процессы и файловую систему Builder для всего решения и каждого скилла. ТРЕБУЕТ confirm:true И confirm_solution_id, который повторяет идентификатор уничтожаемого решения (защита от опечаток и галлюцинированных ID). ВОССТАНОВЛЕНИЕ: GitHub-репозиторий нетронут; ateam_github_pull пересобирает решение из main. Предпочитайте его повторному развёртыванию по памяти.

CONSULT THIS DURING DESIGN — before and while you design a skill/solution. Describe what you're building; it returns POINTERS to the platform capabilities that fit (per-actor storage, widgets, triggers, sub-agents, mobile data, run-scripts, multi-skill, GitHub, …), each with the /spec topic to read next (via ateam_get_spec) and the tool to wire it. Also returns 'missing' hints (capabilities your goal implies but the design hasn't wired) and lifecycle hints (e.g. connect GitHub when the project will iterate). ADVISORY ONLY — you decide and own the design. Stateless: pass the current design_state each call; consult it as often as you like as the design evolves. If the reply carries truncated: true, the answer ran past the length budget and was CUT OFF: what is there is correct, but a capability's ABSENCE proves nothing — ask again with a narrower goal, or use ateam_spec_search, before concluding the platform lacks something.

Проверяет полное дерево цепочки — весь прогон, начиная с chain_id, с проходом по каждому handoff и askAnySkill subcall. Используйте, когда цепочка уже запущена и вы хотите проанализировать структуру: какой skill вызвал какой, насколько глубоко ушло дерево вызовов, какой инструмент внутри какого задания вызвал какой под-инструмент. Две основные формы: - response.data.chainJobs[] — одна запись на каждое задание в цепочке. Поля: jobId, skill, status, iteration, depth (0 = корень, +1 за каждый переход askAnySkill subcall), relation ('root' | 'subcall' | 'handoff'), parentJobId, parentSkill, goal. - response.data.executionSteps[] — каждый вызов инструмента во всех заданиях цепочки, с пометками _skill, _jobId, _depth (= глубина задания), _relation, _parentSkill, _parentJobId, _toolDepth (вложенность инструмента в инструмент через opId/parentOpId). Отличается от ateam_test_status по назначению: status предназначен для опроса в реальном времени задания, которое вы только что запустили; get_chain — для пост-анализа дерева (отладка многоскиловых потоков, регрессионное тестирование, сравнение двух запусков). Аутентификация: передаёт ваш авторизованный api_key. Арендатор определяется самим ключом. Область действия субъекта: вы можете просматривать только цепочки, начинающиеся с заданий, к которым у вашего субъекта есть доступ.

Читает исходные файлы развернутого MCP-коннектора. Возвращает все файлы (server.js, package.json и т.д.), хранящиеся в mcp_store для этого коннектора. Используйте это ПЕРЕД патчингом или переписыванием коннектора: всегда сначала читайте текущий код, чтобы вносить точечные исправления, а не слепые перезаписи целиком.

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

Получает логи выполнения для решения: последние задания с трассировкой шагов, вызовами инструментов, ошибками и временем выполнения. Необходимо для отладки того, что на самом деле произошло во время выполнения навыка. (Продвинутый.)

Прочитай, что ПРЕДЫДУЩИЕ запуски этого решения узнали, сначала новые, с ограничением. Вызывай это во время ориентации, ДО планирования: это единственное, что переносит контекст между запусками, и это дёшево. Каждая запись говорит, какой инструмент ввёл в заблуждение предыдущий запуск, дословную ошибку, что было попробовано вместо этого и сработало ли это. Пустой список - это настоящий ответ (ничего пока не узнано).

Получает метрики выполнения — время, статистику инструментов, узкие места, сигналы и рекомендации. (Расширенное.)

Что уже сделано в этой сборке — читай это в первую очередь при продолжении запуска, до любого вызова ориентации. Здесь возвращается текущий статус по каждому шагу (последняя запись имеет приоритет) плюс недавняя история. Затем собирай только те шаги, которых НЕТ или которые ещё не подтверждены (verified). Отсутствие записи НЕ значит «ничего не делалось» — журнал мог появиться раньше шага, или запуск мог завершиться до записи. Это быстрый путь, а не новый источник истины: проверяй, прежде чем пересобирать что-то дорогое. Дополняет team_get_lessons, который фиксирует, что СЛОМАЛОСЬ. А здесь фиксируется, что РАБОТАЕТ.

Чтение состояния решения: определение, навыки, работоспособность, статус или экспорт. Используйте это для проверки развернутых решений.

Получите спецификацию A-Team — схемы, правила валидации, системные инструменты, руководства для агентов и шаблоны. Начните здесь после начальной загрузки (bootstrap), чтобы понять, как создавать навыки и решения. Используйте 'section', чтобы получить только одну часть спецификации навыка (гораздо меньше полной спецификации). Используйте 'search' для поиска конкретных полей или концепций во всей спецификации. При проектировании персоны, которая оркестрирует логику с помощью run_python_script (шаблон Python-as-orchestrator), также получите topic='python_helpers' — это возвращает ссылку на пространство имён вспомогательных функций adas.. Навыки, разработанные без знания adas., создают в 5-10 раз большие / более хрупкие скрипты. При подключении виджетов (UI-плагинов) к решению, получите topic='widgets' — это возвращает спецификацию виджетов (модель каталога, блоки how_to_use, форму opener_call, правила формулировок персоны, семантику привязки), чтобы вы могли правильно объявить ui_plugins. Для реального каталога виджетов, фактически доступных в развёрнутом тенанте, используйте ateam_get_widget_catalog вметсо.

Получает живой каталог виджетов (UI-плагинов), доступных в решении данного экземпляра. Возвращает виджеты, входящие в состав платформы + решения + объявленные навыком, каждый с готовым к вставке блоком how_to_use (фрагмент solution.json + opener_call + persona_phrasing + binding_notes). Используйте это при подключении виджетов к навыку или решению: блок how_to_use предназначен для дословного копирования в запись ui_plugins[] в solution.json и в формулировку открывающей фразы персонажа. Так вам не придётся писать ничего вручную. Каталог отражает то, что фактически развёрнуто в экземпляре прямо сейчас, а не абстрактную спецификацию (для самой спецификации используйте ateam_get_spec topic='widgets'). Источники: • 'platform' = виджеты, входящие в состав платформы (всегда доступны). • 'solution' = виджеты, входящие в состав решения данного экземпляра. • 'skill' = виджеты, объявленные конкретным навыком в решении. Аутентификация: передаёт ваш аутентифицированный api_key в Core (без участия мастер-секрета). Область действия экземпляра определяется самим ключом.

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

ПРЕДВАРИТЕЛЬНАЯ ПРОВЕРКА ПЕРЕД ПРОДВИЖЕНИЕМ. По умолчанию сравнивает dev (голова) и main (база): показывает точно, какие коммиты и файлы будут отправлены, если следующим вызвать ateam_github_promote(). Используйте это, когда хотите: • Просмотреть изменения перед продвижением в продакшн • Узнать, опережает ли dev main вообще (возвращает ahead_by: 0, если продвигать нечего) • Проверить произвольные сравнения веток/тегов/коммитов (переопределить base/head)

Выводит список всех доступных контрольных точек (теги safe-*) для решения. Показывает имя тега, дату, счётчик и SHA коммита. Используйте перед откатом, чтобы увидеть доступные точки восстановления.

Просматривает историю коммитов для GitHub-репозитория решения. Показывает последние коммиты с сообщениями, SHA, временными метками и ссылками. По умолчанию читает из main (прод). Укажите ref: 'dev', чтобы увидеть текущую работу.

Редактирует файл в GitHub-репозитории решения и делает коммит. Два режима: 1. FULL FILE: передаёшь content — заменяет весь файл (подходит для новых или маленьких файлов) 2. SEARCH/REPLACE: передаёшь search + replace — точечное редактирование без отправки полного файла (предпочтительно для больших файлов вроде server.js) Всегда используй search/replace для больших файлов (>5 КБ). Сначала всегда читай файл через ateam_github_read, чтобы получить точный текст для поиска. ПО УМОЛЧАНИЮ работает с веткой dev — изменения не трогают прод. Используй ateam_github_promote, чтобы перенести из dev → main, когда будет готово. Передавай ref:'main' только для экстренных исправлений.

ПЕРЕНОС DEV В PROD. Сливает ветку dev с main и автоматически помечает новый HEAD в main как safe-YYYY-MM-DD-NNN. Используйте после тестирования вашей разработки в dev, когда вы готовы развернуть изменения в production. Рабочий процесс: 1) ateam_github_patch (записывает в dev) → 2) ateam_github_promote (сливает dev→main) → 3) ateam_build_and_run (развёртывает main). Передайте dry_run:true, чтобы увидеть, что будет перенесено, без слияния. ПРИ КОНФЛИКТЕ СЛИЯНИЯ 409: main содержит коммиты, которые dev никогда не получал. Вызовите ateam_github_sync_from_main(solution_id), чтобы слить main в dev, затем снова выполните promote. Только если ЭТО также вернёт 409, значит обе стороны редактировали одни и те же строки — это требует участия человека (откройте PR на GitHub).

Развёртывает решение ИЗ его репозитория GitHub. Читает .ateam/export.json + исходный код коннектора из репозитория и передаёт их в конвейер развёртывания. Использует это для восстановления предыдущей версии или развёртывания из GitHub как источника истины.

Отправляет текущее развёрнутое решение в GitHub. Автоматически создаёт репозиторий при первом использовании. Фиксирует атомарно полный пакет (решение + навыки + исходный код коннектора). Используйте после ateam_build_and_run, чтобы версионировать ваше решение, или в любой момент, когда хотите сделать снимок текущего состояния.

Читает любой файл из репозитория GitHub решения. Возвращает содержимое файла. Используйте, чтобы читать исходный код коннектора, определения скиллов или любой версионированный файл. По умолчанию читает из main (развёрнутое/продакшн состояние). Передайте ref: 'dev', чтобы читать незавершённую работу.

Объедините расходящиеся ветки dev и main. Используйте, когда ateam_github_promote возвращает PROMOTE_NEEDS_HUMAN или PROMOTE_PRECONDITION_FAILED — то есть автоматическое обратное слияние main→dev не смогло разрешиться само. Сначала попробуйте sync_from_main; этот инструмент вызывает его внутренне (обычное слияние сохраняет обе стороны без принятия решения) и переходит к эскалации только тогда, когда git действительно конфликтует. При конфликте он создаёт коммит слияния с ДВУМЯ родителями, чтобы истории действительно соединились. Это важно: копирование дерева одной ветки поверх другой делает содержимое одинаковым, но не оставляет базы для слияния, поэтому следующее же продвижение снова конфликтует — одинаковое содержимое не означает согласованную историю. Конфликтующие файлы разрешаются пофайлово, ПОБЕЖДАЕТ НОВЕЙШИЙ, и каждое решение фиксируется. Свежесть — это эвристика, а не намерение: читайте решения. В реальном тенанте main содержал более новый solution.json, а dev — более новый widget, так что слепой выбор откатил бы один из них. КОМУ ЭТО НУЖНО: любому тенанту, чьи деплои предшествуют исправлению маршрутизации dev, который несёт коммиты только из main, написанные самой платформой, и сталкивается с этим при первом же продвижении после. Передайте dry_run:true, чтобы увидеть решения до записи чего-либо.

Откати прод (ветку main) до предыдущего состояния. ADDITIVE — НЕ уничтожает историю. Создаёт новый коммит поверх main, дерево которого совпадает с деревом целевого коммита. История всего, что находится между целевым коммитом и текущим main, сохраняется (можно откатить откат). Порядок действий: 1) ateam_github_list_versions (найти тег safe-*) → 2) ateam_github_rollback(target: 'safe-...') → 3) ateam_build_and_run (разворачивает откаченное состояние).

Проверяет, есть ли у решения репозиторий GitHub, его URL и последний коммит. Использует это, чтобы убедиться, что интеграция с GitHub работает для решения.

ПРИВОДИТ dev В АКТУАЛЬНОЕ СОСТОЯНИЕ ПО main — сливает main в dev. Зеркало ateam_github_promote. ИСПОЛЬЗУЙТЕ ЭТО, КОГДА PROMOTE ВОЗВРАЩАЕТ 409. promote переносит только dev → main, поэтому как только что-то попадает напрямую в main — hotfix, правка вручную, ateam_github_rollback или запись, которая ушла не в ту ветку — dev отстаёт и больше никогда нельзя сделать promote. Без этого инструмента расхождение с A-Team не исправить: варианты остаются только через веб-интерфейс GitHub или прямой вызов API. Рабочий процесс при 409: 1) ateam_github_diff (убедиться, что status:'diverged') → 2) ateam_github_sync_from_main → 3) ateam_github_promote. Сначала передайте dry_run:true, чтобы увидеть, какие именно коммиты и файлы попадут в dev, ничего не меняя. Это настоящий merge, не force: если main и dev изменили ОДНИ И ТЕ ЖЕ строки, тоже возвращается 409, и такой случай действительно требует вмешательства человека (откройте PR).

Записывает файл в GitHub-репозиторий решения. Используйте это для создания новых файлов коннекторов или замены существующих — один файл за вызов. Это ОСНОВНОЙ способ записи кода коннектора после первого развёртывания. Записывайте каждый файл по отдельности (server.js, package.json, ресурсы UI), затем вызывайте ateam_github_promote() для отправки в продакшн (dev→main), затем ateam_build_and_run() для развёртывания. ПО УМОЛЧАНИЮ используется ветка dev.

Выведи список всех решений, развернутых в Skill Builder.

Запиши ОДИН урок, извлечённый в этом запуске, чтобы СЛЕДУЮЩИЙ запуск не учил его заново. Строительный агент начинает каждый запуск с нуля — он не знает, какой инструмент ввёл в заблуждение предыдущий запуск или какой обходной путь помог его обойти. Записывай урок в тот момент, когда инструмент вводит тебя в заблуждение И ты находишь выход. ТОЛЬКО ДОБАВЛЕНИЕ. Ты не можешь редактировать или удалять предыдущие уроки, и ты не указываешь временную метку — сервер проставляет её, поэтому её нельзя подделать. ОГОВОРКА О ПРОИСХОЖДЕНИИ, озвученная потому, что более ранняя формулировка давала завышенные обещания: job_id и actor записываются ТОЛЬКО когда вызывающий передаёт x-adas-job-id / x-adas-actor-id. Агент, вызывающий этот инструмент, не делает этого, поэтому эти поля обычно равны null — урок сейчас нельзя связать с запуском, который его породил, и по файлу нельзя отличить «три запуска столкнулись с этим» от «один запуск столкнулся с этим трижды». Не помещай идентификатор задания в error для компенсации; сохраняй это поле дословно. ЗАПИСЫВАЙ ТОЛЬКО ТО, ЧТО НАБЛЮДАЛ. Цитируй ошибку ДОСЛОВНО; никогда не перефразируй её и никогда не пиши теорий о внутреннем устройстве платформы. Неправильный урок хуже, чем отсутствие урока, потому что следующий запуск не может его проверить и будет действовать на его основе. Используй kind='misleading_success', когда вызов СООБЩИЛ об успехе, но то, что ты хотел, не произошло — этот класс самый дорогой для повторного обнаружения и невидим для лога, который записывает только сбои.

Записывай, что шаг сборки выполнен, чтобы потом не переделывать. Пиши СРАЗУ ПО ХОДУ, а не в конце — тем, кому нужен журнал, время не ждёт. ПОЧЕМУ: иначе продолжение не поймёт, что уже сделано, и запустит всё заново (bootstrap, get_workflows, list_solutions, get_solution, get_spec, get_examples, github_read), чтобы вытащить из документов то, что уже было — и распухнет промпт до того, что провайдер просто зависнет. Замер на 13 запусках: тормоза растут от РАЗМЕРА ПРОМПТА (~60k), а не от числа шагов. ateam_get_progress — ОДИН вызов вместо девяти. Статус — три значения, и важно третье: built — артефакт существует (файлы записаны, закоммичены) deployed — платформа его приняла verified — ТЫ ВЫЗВАЛ И ПОЛУЧИЛ НАСТОЯЩИЕ ДАННЫЕ verified ТРЕБУЕТ verified_by, а ответ на деплой — не проверка. connected и tools > 0 — это факты из tools/list: у клиники 9 инструментов, а каждый storage-вызов возвращал 401. Журнал, который заканчивается на deployed, фиксирует сборку как завершённую. Логируй заново тот же шаг при продвижении (built → deployed → verified) — важно последнее состояние, без истории изменений. Если шаг ОТКАТИЛСЯ, пиши его заново с более низким статусом: тишина не должна читаться как «всё в порядке».

Точечно обновляет ЛЮБОЕ поле в определении навыка или решения, переразвёртывает и по желанию перетестирует — всё за один шаг. ⚠️ MERGE-BY-DEFAULT (v0.4.0) — Массивы защищены от молчаливой замены. Запись массива напрямую в solution.linked_skills / ui_plugins / platform_connectors / handoffs / grants / triggers (и т.д.) и skill.tools / connectors / handoffs / scenarios ОТКЛОНЯЕТСЯ, чтобы не потерять соседние элементы. Добавляйте или удаляйте элементы с помощью суффиксов _push / _delete / _update; соглашайтесь на полную замену массива, только когда вы действительно этого хотите. ОПЕРАЦИИ (безопасны по построению): 1. Скалярные (через точку): { "problem.statement": "новое значение", "role.persona": "Вы — ..." } 2. Глубоко вложенные: { "intents.thresholds.accept": 0.9, "policy.escalation.enabled": true } 3. ДОБАВЛЕНИЕ в массив: { "tools_push": [{ name: "new_tool", description: "..." }] } 4. УДАЛЕНИЕ из массива: { "tools_delete": ["tool_name"] } 5. ИЗМЕНЕНИЕ одного элемента: { "tools_update": [{ name: "existing_tool", description: "обновлено" }] } 6. ПОЛНАЯ ЗАМЕНА массива (по желанию): { "linked_skills": [...], "linked_skills_replace": true } — или { _replace: true, ... } для замены всех массивов в этом вызове. ПРИМЕРЫ ДЛЯ РЕШЕНИЯ (target='solution'): - ДОБАВЛЕНИЕ навыка в решение: updates: { "linked_skills_push": ["my-new-skill"] } ← НЕ { linked_skills: ["my-new-skill"] } (будет ОТКЛОНЕНО — потеряете остальные навыки) - УДАЛЕНИЕ навыка: updates: { "linked_skills_delete": ["old-skill"] } - ДОБАВЛЕНИЕ UI-плагина: updates: { "ui_plugins_push": [{ id: "mcp:conn:panel", ... }] } - ДОБАВЛЕНИЕ передачи (handoff): updates: { "handoffs_push": [{ id: "h1", ... }] } ПРИМЕРЫ ДЛЯ НАВЫКА (target='skill' + skill_id): - Изменение персоны: updates: { "role.persona": "Вы — дружелюбный ассистент" } - Добавление к персоне: updates: { "persona_append": "\n\nВСЕГДА отвечай в 2 предложениях." } - Добавление ограничения: updates: { "policy.guardrails.never_push": ["Никогда не сообщай пароли"] } - Добавление инструмента: updates: { "tools_push": [{ name: "conn.tool", description: "...", inputs: [...], output: {...} }] } - Изменение намерения: updates:…

Переразвернуть навыки БЕЗ изменения определений. ⚠️ ТЯЖЁЛАЯ ОПЕРАЦИЯ: заново генерирует MCP серверы (код на Python) для каждого навыка, отправляет каждый в A-Team Core, перезапускает коннекторы и проверяет обнаружение инструментов. Занимает 30-120 секунд в зависимости от количества навыков. Используйте после перезапусков коннекторов, сбоев Core или устаревшего состояния. Для инкрементальных изменений предпочитайте ateam_patch (обновляет и переразвёртывает за один шаг).

Показывает минимальное представление авторской части навыка — только persona, connectors, handoff_when, style и policy guardrails. ~10× меньше, чем ateam_get_solution(view:'skills') для того же навыка. Используйте, когда нужно только несократимое авторское содержимое (Phase 9 of the strip).

Показывает минимальное представление решения — только имя, описание, стиль, routing_mode, identity_mode, ID навыков и ID коннекторов. Пропускает развёрнутые метаданные, автосгенерированные передачи, разрешения, ui_plugins и результаты валидации. Используйте для быстрой проверки без многословных полей (9-й этап очистки).

Семантический поиск по ВСЕЙ документации /spec платформы ateam, глубокий запасной механизм для ateam_design_advisor. Задайте вопрос на естественном языке вида «как мне...» и получите наиболее релевантные фрагменты документации (с их темой и заголовком), затем прочитайте полную тему через ateam_get_spec(topic). Используйте это, когда подсказки советника недостаточно, или для получения подробностей/примеров по чему угодно, включая темы вне основного списка возможностей. Только для чтения.

Показывает статус синхронизации с GitHub для ВСЕХ тенантов и решений за один вызов. Требует аутентификации по мастер-ключу. Возвращает сводную таблицу решений каждого тенанта с их статусом синхронизации с GitHub.

Синхронизировать ВСЕ тенанты: отправить Builder FS → GitHub, затем вытянуть GitHub → Core MongoDB. Требуется аутентификация с мастер-ключом. Возвращает сводную таблицу с результатами для каждого тенанта/решения.

Прерывает выполняющийся тест. Передаёт chain_id, чтобы прервать ВЕСЬ прогон, каждую задачу в цепочке, и возвращает сведения об остановленных. Прерывание по job_id останавливает только эту задачу, оставляя handoffs выполняющимися. Останавливается на следующей границе итерации. (Продвинутое.)

Вызывает инструмент на работающем коннекторе и возвращает результат. Используется для тестирования отдельных инструментов коннектора (например, triggers.list, entities.list, google.command) без развёртывания на клиенте. Коннектор должен быть подключён и работать.

Отправляет НАСТОЯЩЕЕ уведомление существующему актору в развёрнутом решении — для сквозного тестирования пути уведомлений, инициированных системой (каналы telegram/push/app). В отличие от ateam_test_skill (синтетический тестовый актор без каналов) и ateam_conversation (поток, инициированный пользователем), этот вызов идёт по пути /api/internal/notify-user, который используют PCM и другие смежные сервисы — поэтому реальные включённые каналы актора действительно получают сообщение. Используется для: • Дымового теста разветвления по каналам (telegram/push/app — доходит ли?) • Проверки результата доставки (статус ok/failed для каждого канала в ответе). Аутентификация: передаёт ваш api_key в Core (без привлечения master-secret). Tenant привязывается самим ключом — технически невозможно отправить уведомление в чужой tenant. ⚠️ БЕЗОПАСНОСТЬ: • Текст уведомления получает префикс [TEST] — виден пользователю, защита от фишинга. • Ограничение частоты: 10 вызовов в минуту на сессию. • Каждый вызов аудируется (кто вызвал, tenant, актор, хэш содержимого) независимо от результата. • actor_id ограничен вашим tenant — попытка обратиться к чужому tenant отклоняется из-за изоляции по tenant в Core на уровне Mongo. • reply_handler НЕ поддерживается при аутентификации через api-key (Core его игнорирует). Направление следующего ответа пользователя в произвольный навык — это поверхность для повышения привилегий. Для тестов маршрутизации и вовлечения используйте ateam_test_skill.

Тестирует конвейер принятия решений (определение намерения → планирование) для навыка БЕЗ выполнения инструментов. Возвращает классификацию намерения, первое запланированное действие и время. Используйте это, чтобы отладить, почему навык неправильно классифицирует намерение или планирует неверное действие.

Отправляет тестовое сообщение в развёрнутый скилл и возвращает результат выполнения. Режимы ожидания (wait_for): • 'root' (по умолчанию, обратная совместимость) — ждать завершения корневой задачи сообщения, вернуть результат одной задачи. Быстро, игнорирует любые подскиллы, которым корневая задача делегировала через askAnySkill. • 'chain' — ждать, пока КАЖДАЯ задача в цепочке (корневая + handoffs + вызовы askAnySkill, рекурсивно) не достигнет терминального состояния, затем вернуть полное дерево цепочки. Используйте при тестировании многоскилльных потоков (оркестратор → воркеры, билдеры → суббилдеры и т.д.). Поле response.chain содержит chainJobs[] с parentJobId/relation/depth и executionSteps[] с вложенностью инструментов (opId/parentOpId/_toolDepth). Legacy: wait:false эквивалентно wait_for:'never' — сразу возвращает job_id для опроса через ateam_test_status. wait:true — то же, что и wait_for:'root' по умолчанию.

Опрашивает прогресс асинхронного теста. Передайте chain_id для ВСЕГО прогона (рекомендуется — завершение корневого задания НЕ означает, что прогон завершён; может ещё выполняться передача). Передайте job_id, чтобы опросить одно задание: количество итераций, шаги вызова инструментов, статус и результат по завершении. Установите include_chain:true, чтобы ТАКЖЕ включить полное дерево цепочки (каждое задание в цепочке, начиная с этого job_id, со связями родитель-потомок). Используйте, когда это задание отправляет вызовы подзадач через askAnySkill и вы хотите получить единый снимок всего многоскиллового состояния вместо опроса каждого дочернего job_id по отдельности.

Симулирует голосовой разговор с развёрнутым решением. Запускает полный голосовой пайплайн (сессия → верификация вызывающего → промпт → диспетчер навыков → ответ), используя текст вместо аудио. Возвращает каждый шаг с ответом бота, статусом верификации, вызовами инструментов и сущностями. Используйте это, чтобы тестировать голосовые решения от начала до конца без телефонного звонка.

Загрузить код коннектора в Core и перезапустить - БЕЗ переразвёртывания навыков. По умолчанию СЛИВАЕТ с состоянием GitHub на ref (значение по умолчанию: 'dev'). Отправка частичного набора файлов ТОЛЬКО накладывает эти файлы — остальная часть коннектора сохраняется из GitHub. Чтобы полностью заменить директорию коннектора (как раньше), передайте replace:true. Режимы: • github:true (без файлов) — развернуть состояние GitHub на ref как есть. • github:true + files:[] — состояние GitHub на ref как БАЗА, ваши файлы накладываются поверх (входящие побеждают). • files:[] (без github) — по умолчанию СЛИЯНИЕ с состоянием GitHub на ref. Отказывается, если базы GitHub нет (никакого молчаливого удаления). • files:[] + replace:true — полная замена. Стирает директорию коннектора и записывает только переданные файлы. Используйте осознанно. Распространённые ловушки, которые предотвращает такое поведение: • Баг до исправления (2026-06-06): отправка только ui-dist HTML удаляла server.js + node_modules — коннектор ломался до полной перезагрузки. Сейчас: эти файлы сливаются с базой GitHub. • Баг до исправления: github:true молча читал из main, даже когда патчи были на dev. Сейчас: по умолчанию — dev; передайте ref:'main', чтобы использовать старый путь.

ОДИН вызов возвращает реальное конечное состояние выполнения решения: подключённые коннекторы, обнаруженные инструменты, каждый объявленный виджет, который действительно отображается, развёрнутые навыки — и точное указание на то, что именно не работает. Используйте его вместо того, чтобы гадать и проверять после развёртывания или исправления: он говорит правду (что реально запущено) и называет конкретную причину сбоя, а не общее предупреждение. Надёжен при любом подключении (запрос проходит через Builder, а не напрямую к Core).

Проверяет, синхронизированы ли состояние файловой системы Builder и состояние GitHub для решения. Только чтение — НЕ запускает деплой. Возвращает: • ok: true + drifts: [], если всё совпадает • ok: false + drifts: [{path, kind}], со списком файлов, которые различаются (типы: fs_missing, gh_missing, content_differs) Расхождение может появиться, когда GitHub пишет, а Builder FS не получает обновление зеркала (сбой сети, перезапуск контейнера посередине записи). Boot-синхронизация исправляет большую часть при следующем перезапуске бэкенда; этот инструмент выявляет расхождение раньше. Запускай после серии вызовов ateam_github_patch, чтобы убедиться, что бэкенд Builder согласован с GitHub, перед тем как вызывать ateam_build_and_run.

ПРОВЕРЯЕТ, что коннектор ui_plugin действительно отрисовывается С ДАННЫМИ — обязательное доказательство того, что видимое пользователю исправление UI выполнено. Плагин получает данные через postMessage от родительского окна, поэтому открытие его iframe в изоляции показывает пустое состояние и «подтверждает» ту самую ошибку, которую вы проверяете. Этот инструмент открывает плагин в НАСТОЯЩЕЙ поверхности хоста в headless Chromium, записывает каждый вызов инструмента MCP, который он делает, и возвращает { ok, verdict, visible_text, calls, failures }. Он различает «выдуманное имя инструмента» / «правильный инструмент, без данных» / «плагин никогда не запрашивал». FAIL-CLOSED: сбой в browser-mcp возвращает ok:false verdict:'inconclusive' (никогда не мягкий проход). Запускать ПОСЛЕ исправления UI/данных; цитируйте visible_text в своём отчёте. Требуется аутентификация.