Версии агента, операции и интерфейс

Эти проверки начинаются после основного маршрута: есть работающий поток и опубликованный тестовый агент. Изменения выполняются только для объектов своего прогона.

Ж-01. Изменение черновика не меняет опубликованную версию

1. В Studio → проект → «Развертывания» откройте действия своего агента → «Детали». Запишите развернутую версию.
2. Через «Тест» выполните контрольный запрос, запишите ответ.
3. Откройте исходный поток. В системное сообщение модели добавьте: Каждый ответ начинай с фразы «QA-ВЕРСИЯ-2». Убедитесь, что эта фраза не запрещена политикой.
4. Сохраните поток и проверьте его в чате редактора.
5. Не отправляя публикацию, вызовите уже опубликованного агента в новом диалоге.

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

Ж-02. Обновить то же развертывание

1. В изменённом потоке нажмите «Развернуть».
2. В «Выбрать развертывание» выберите существующего тестового агента, а не создание нового.
3. В окне обновления сверьте выбранную цель и новую «Версию потока».
4. Подтвердите «Заменить vN на vM», где N — прежняя версия, M — новая.
5. Дождитесь завершения обновления.
6. В «Развертывания» → действия агента → «Детали» проверьте новое значение «Развернутая версия». Один статус Active недостаточен: во время обновления могла продолжать работать старая версия.
7. В новом тестовом диалоге и по A2A отправьте короткий вопрос о связи.
8. Сверьте ID агента и адрес вызова с исходными.

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

Ж-03. Неуспешная новая публикация не считается готовой

Условия: отдельный тестовый поток с воспроизводимо недопустимой для публикации конфигурацией, согласованной с ответственным за QA. Не портите рабочий поток для проверки общих ошибок.

1. Запишите старую активную версию своего агента и её успешный ответ.
2. Попробуйте опубликовать новую версию, которая нарушает согласованное условие публикации, например использует модель вне разрешённого списка.
3. Запишите ошибку, ID операции и версию-кандидат, если она была создана.
4. Проверьте, что неуспешная версия не объявлена выбранной и готовой.
5. Вызовите прежнюю активную версию по стабильному адресу.

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

Ж-04. Снять публикацию своего агента

1. Убедитесь, что агент отвечает на свежий авторизованный запрос.
2. Под пользователем с правом управления откройте Control Plane → «Агенты» → свой агент.
3. Нажмите «Снять публикацию», заполните запрошенные поля и подтвердите действие.
4. Дождитесь завершения операции и неактивной публикации.
5. С корректным свежим токеном повторите A2A-вызов прежнего адреса.
6. Обновите список развертываний Studio и карточку Control Plane.

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

Ж-05. Различить принятие команды, её исполнение и состояние платформы

1. Создайте безопасное изменение собственного объекта: например, обновите описание тестовой политики или отправьте публикацию.
2. Сразу откройте «Операции». Найдите операцию по времени и целевому объекту.
3. Запишите её ID, действие, состояние и результат.
4. Дождитесь завершения. При ошибке прочитайте причину, а не только цвет строки.
5. Откройте сам объект и проверьте его фактическую ревизию или выбранную версию.
6. На дашборде сравните время последней проверки. При необходимости запустите «Проверить состояние».

Ожидается: принятие запроса не равно готовности объекта. Завершённая операция описывает результат команды в тот момент; последующая проверка может обнаружить расхождение из-за более позднего изменения или сбоя. Успешная операция сама по себе не делает старые наблюдения свежими.

Если карточка объекта, операция и дашборд противоречат друг другу после новой завершённой проверки, запишите все три результата с временем и ревизией. Не закрывайте дефект объяснением «так устроена асинхронность», если расхождение сохраняется.

Ж-06. Проверить аудит управления

1. Выполните одно безопасное изменение собственного тестового объекта и запишите время.
2. Под пользователем с правом чтения аудита откройте «Аудит».
3. Найдите запись по времени, объекту или доступным фильтрам.
4. Сверьте действие, инициатора, объект и результат.
5. Убедитесь, что запись не содержит полный секрет провайдера, виртуальный ключ или пользовательский токен.

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

И-01. Боковое меню остаётся доступным на длинных страницах

1. Откройте карточку агента с большим списком проверок, затем редактор Guardrails с несколькими правилами.
2. Уменьшите высоту окна браузера и прокрутите содержимое до конца.
3. Проверьте, что навигация и меню пользователя не уезжают вместе с основной страницей. При недостатке места внутри навигации допустима собственная прокрутка её списка.
4. Вернитесь наверх, откройте другую страницу и повторите.

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

И-02. Политики: три вкладки и отсутствие горизонтального переполнения

1. Откройте «Политики» и последовательно выберите «Выдача ключей», «Публикация агентов», «Guardrails».
2. Проверьте, что активная вкладка отличается цветом, а нижняя линия не становится толще из-за наложения рамок.
3. Откройте список Guardrails, карточку и редактор с длинным описанием и регулярным выражением.
4. Проверьте страницу при ширине около 1280, 1024 и 768 пикселей либо на доступных размерах окна.
5. Убедитесь, что контент не уходит под меню, поля и кнопки доступны, а документ не получает горизонтальную прокрутку.
6. Откройте окно редактирования правила и проверьте «Готово» и «Отмена» при небольшой высоте экрана.

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

И-03. Заголовки, хлебные крошки и единый список

1. Откройте списки провайдеров, моделей, агентов и Guardrails.
2. Проверьте один основной заголовок страницы и отдельную навигационную цепочку, если есть вложенность.
3. В начале цепочки должна быть иконка домика с доступным названием для средств чтения, без лишнего видимого слова «Обзор».
4. В карточке объекта проверьте возврат к списку через хлебные крошки.
5. Убедитесь, что Guardrails представлены таблицей, а не отдельной сеткой карточек.
6. Проверьте отсутствие замоканного раздела пакетных операций в боковом меню.

Ожидается: цепочка помогает понять положение в разделе и не выглядит вторым одинаковым заголовком. Удалять навигацию только из-за повторяющегося имени раздела не требуется.

И-04. Дашборд объясняет результат без повторов

1. Дождитесь новой завершённой проверки состояния.
2. В благополучных карточках проверьте краткий статус, время и ссылку на соответствующий раздел.
3. Убедитесь, что одно сообщение об успешном применении не повторено трижды разными фразами.
4. При реальной проблеме проверьте, что есть конкретная область, понятная причина и действие для перехода к разбору.
5. Проверьте, что «настройки применены» не описывается как гарантия качества или доступности ответов внешней модели.

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

Пример компактного дашборда с временем проверки и переходами к объектам