AI Platform Docs

1. Общие положения

Продукт: Платформа ИИ

Версия: 3.5

Дата: 2026-10-15

Настоящий документ определяет программу и методику испытаний (ПМИ) кандидата на первую поставку — Платформы ИИ версии 3.5. ПМИ охватывает пользовательские тестовые кейсы для проверки основных сценариев использования пяти компонентов поставки:

Agent Registry — каталог агентов;
Low-code Конструктор — визуальный редактор Flow;
Low-code Runtime — среда исполнения Flow;
Platform RAG — сервис извлечения знаний;
Memory Service — управляемый слой персистентной памяти.

1.2. Область применения

Испытания проводятся для подтверждения работоспособности пользовательских сценариев: создание агента в Low-code Конструкторе, его проверка и публикация из интерфейса Конструктора, обнаружение в каталоге, поиск и вызов агента, а также использование сервисов Platform RAG и Memory Service.

1.3. Состав компонентов

Компонент	Назначение
Low-code Конструктор	Создание, сохранение, проверка и публикация Flow агента (исходный код — LangFlow)
Low-code Runtime	Исполнение неизменяемого Flow через A2A и MCP
Agent Registry	Автоматическое обнаружение агентов, каталог, поиск с правами доступа
Platform RAG	Извлечение знаний: коллекции, приём документов, гибридный поиск
Memory Service	Персистентная память: извлечение фактов, поиск, CRUD, рабочая память сессий

1.4. Роли пользователей

Роль	Основная задача	Используемый компонент
Автор Low-code-агента	Создаёт, сохраняет, проверяет и публикует схему в визуальном редакторе	Low-code Конструктор
Пользователь каталога	Просматривает и ищет доступных агентов	Agent Registry
Потребитель агента	Вызывает выбранного агента по разрешённому интерфейсу	Platform Agent Gateway, Low-code Runtime
Владелец знаний	Управляет коллекциями RAG	Platform RAG, Platform SDK
Пользователь агента	Видит, что агент о нём помнит; редактирует и удаляет записи	Memory Service, T1GPT

1.5. Предварительные условия

Для выполнения пользовательских тестовых кейсов необходимо:

Развёрнутые среды с компонентами Платформа ИИ 3.5;
Действующие учётные записи с SSO-входом;
Настроенные права доступа к рабочим областям;
Готовый к использованию Agent Registry с обнаруженными агентами;
Доступ к платформе публикации: работающий Control Plane и Publisher для развёртывания workload в Kubernetes;
Доступ к Platform RAG и Memory Service.

2. Тестовые кейсы

2.1. Low-code Конструктор

ТК-001. Вход в Low-code Конструктор через SSO

№	Модуль (компонент)	Функциональность	Название сценария	Действия – Шаги сценария	Ожидаемый результат
1	Low-code Конструктор	Авторизация пользователя	Вход через SSO	1. Открыть адрес Low-code Конструктора, предоставленный администратором. 2. Ввести учётные данные через сервис SSO платформы. 3. Подтвердить вход.	Пользователь перенаправлен в Low-code Конструктор. Отображается разрешенная рабочая область и палитра компонентов.

ТК-002. Создание нового Flow

№	Модуль (компонент)	Функциональность	Название сценария	Действия – Шаги сценария	Ожидаемый результат
1	Low-code Конструктор	Создание Flow	Создание минимального Flow	1. Открыть Low-code Конструктор. 2. Создать новый пустой рабочий Flow. 3. Задать понятное название и описание назначения агента. 4. Добавить компонент входа сообщения. 5. Добавить компонент `PlatformLLM` и выбрать разрешённый профиль модели. 6. Соединить выход модели с компонентом ответа. 7. Проверить типы входных и выходных данных каждого соединения.	Flow создан. Все соединения корректны, типы данных совместимы. Компоненты доступны в палитре. Компоненты `PlatformRAG` и `PlatformMemory` в палитре отсутствуют.

ТК-003. Сохранение рабочей версии

№	Модуль (компонент)	Функциональность	Название сценария	Действия – Шаги сценария	Ожидаемый результат
1	Low-code Конструктор	Сохранение версии	Сохранение Flow	1. Открыть существующий Flow. 2. Ввести название, отражающее назначение агента. 3. Нажать «Сохранить». 4. Зафиксировать идентификатор, номер рабочей версии, время сохранения. 5. Повторно сохранить неизменённую версию.	Рабочая версия сохранена. Возвращены: идентификатор, номер версии, время сохранения, применённая политика компонентов, версия Low-code Конструктора. Повторное сохранение даёт одинаковую контрольную сумму SHA-256.

ТК-004. Проверка Flow — успешный сценарий

№	Модуль (компонент)	Функциональность	Название сценария	Действия – Шаги сценария	Ожидаемый результат
1	Low-code Конструктор	Проверка схемы	Успешная проверка	1. Открыть сохранённый Flow. 2. Запустить серверную проверку. 3. Дождаться итогового состояния.	Проверка подтверждает: корректность структуры, наличие обязательных полей, соответствие политике компонентов, отсутствие секретов, совместимость с `lfx`, согласованность входных/выходных данных. Результат содержит версию проверяющего модуля, версию политики и SHA-256 исходных данных.

ТК-005. Проверка Flow — запрещённый компонент

№	Модуль (компонент)	Функциональность	Название сценария	Действия – Шаги сценария	Ожидаемый результат
1	Low-code Конструктор	Проверка схемы	Ошибка component_not_allowed	1. Открыть Flow с компонентом, отсутствующим в действующей политике. 2. Запустить проверку. 3. Дождаться итогового состояния.	Проверка возвращает ошибку `component_not_allowed`. Схему нельзя публиковать. Необходимо удалить компонент или выбрать разрешённую платформенную замену.

ТК-006. Проверка Flow — секрет в исходных данных

№	Модуль (компонент)	Функциональность	Название сценария	Действия – Шаги сценария	Ожидаемый результат
1	Low-code Конструктор	Проверка схемы	Обнаружение секрета	1. Вставить ключ API или токен в текстовое поле узла Flow. 2. Запустить проверку.	Проверка обнаруживает значение, похожее на секрет. Требуется удалить значение и использовать профиль Vault.

ТК-007. Публикация агента из интерфейса Конструктора

№	Модуль (компонент)	Функциональность	Название сценария	Действия – Шаги сценария	Ожидаемый результат
1	Low-code Конструктор	Публикация агента	Публикация проверенной версии Flow	1. Убедиться, что рабочая версия прошла серверную проверку и не содержит ручных правок компонентов вне политики. 2. Открыть сохранённую рабочую версию и вызвать публикацию в интерфейсе. 3. Дождаться ответа на публикацию. 4. Отслеживать статус операции публикации до конечного состояния.	Система экспортирует Flow в канонический формат `platform.low-code.flow/v2` и вызывает Control Plane. Операция публикации принимается ответом `202 Accepted`, создаются запись агента и версии. Изменяемые поля `Flow.data` в публикацию не попадают.

ТК-008. Публикация агента — отклонение схемы

№	Модуль (компонент)	Функциональность	Название сценария	Действия – Шаги сценария	Ожидаемый результат
1	Low-code Конструктор	Публикация агента	Отклонение изменённого компонента	1. После успешной проверки вручную изменить компонент в JSON схемы. 2. Вызвать публикацию.	Публикация отклоняется с ошибкой: состояние проверки отменено. Требуется повторный прогон проверки.

ТК-009. Проверка результата публикации — обнаружение агента

№	Модуль (компонент)	Функциональность	Название сценария	Действия – Шаги сценария	Ожидаемый результат
1	Agent Registry	Поиск агента	Нахождение агента в каталоге	1. После достижения операцией публикации конечного успешного статуса открыть Agent Registry. 2. Найти агента по названию и типу реализации `low-code`. 3. Сравнить опубликованную версию с рабочей версией схемы.	Агент обнаружен в каталоге со статусом `active`. Опубликованная версия совпадает с рабочей версией схемы.

2.2. Agent Registry

ТК-010. Просмотр списка агентов

№	Модуль (компонент)	Функциональность	Название сценария	Действия – Шаги сценария	Ожидаемый результат
1	Agent Registry	Просмотр списка	Получение списка разрешённых агентов	1. Открыть Agent Registry (Swagger UI). 2. Нажать Authorize, выбрать `oauth2Password`, ввести логин и пароль. 3. Выполнить `GET /api/v2/agents?limit=20`.	Возвращается страница разрешённых агентских записей в состоянии `active`. Каждая запись содержит безопасные сведения: название, версия, протокол, состояние, владелец. В каждом ответе присутствует `traceId`.

ТК-011. Фильтрация списка агентов

№	Модуль (компонент)	Функциональность	Название сценария	Действия – Шаги сценария	Ожидаемый результат
1	Agent Registry	Фильтрация	Поиск по протоколу, типу реализации и владельцу	1. Выполнить `GET /api/v2/agents?protocol=a2a&implementationType=low-code&ownerType=principal&ownerIssuer={issuer}&ownerSubject={subject}&limit=20`. 2. Перейти на следующую страницу с курсором из ответа.	Возвращаются агенты, соответствующие всем указанным фильтрам: протокол `a2a`, тип реализации `low-code`, владелец. Курсор зашифрован и привязан к удостоверению и набору фильтров; запрос с курсором другого пользователя или с изменёнными фильтрами отклоняется с `cursor_invalid`.

ТК-012. Просмотр одной записи агента

№	Модуль (компонент)	Функциональность	Название сценария	Действия – Шаги сценария	Ожидаемый результат
1	Agent Registry	Получение записи	Просмотр карточки агента	1. Выполнить `GET /api/v2/agents/{agentId}` с валидным UUID. 2. Проверить возвращаемые поля.	Возвращается безопасная карточка: имя, описание, идентификаторы агента и версии, владелец, рабочая область, состояние, протокол, тип реализации. Ответ не содержит внутренний адрес службы, полную исходную карточку, закрытые диагностические данные и учетные данные. Поле интерфейса вызова возвращается только при выполнении четырёх условий: версия готова, отношения доступа согласованы, публичный маршрут принят, у пользователя есть право `invoke`.

ТК-013. Поиск агентов — успешный сценарий

№	Модуль (компонент)	Функциональность	Название сценария	Действия – Шаги сценария	Ожидаемый результат
1	Agent Registry	Гибридный поиск	Поиск по тексту	1. Выполнить `POST /api/v2/agents/search` с текстом запроса, рабочей областью, фильтрами протокола и типа реализации. 2. Указать `topK` и необязательный порог `minScore`.	Возвращаются разрешённые совпадения выше порога. Смысловая и лексическая оценки не обходят проверку прав: каждый кандидат фильтруется по праву просмотра. Поля `userId`, роли и готовое решение о доступе в запросе запрещены. Текст запроса не сохраняется в журналах.

ТК-014. Поиск агентов — пустая выдача

№	Модуль (компонент)	Функциональность	Название сценария	Действия – Шаги сценария	Ожидаемый результат
1	Agent Registry	Гибридный поиск	Отсутствие совпадений	1. Выполнить `POST /api/v2/agents/search` с текстом запроса, для которого нет разрешённых агентов.	Возвращается HTTP `200` и пустой массив `matches: []`.

ТК-015. Получение записи отсутствующего агента

№	Модуль (компонент)	Функциональность	Название сценария	Действия – Шаги сценария	Ожидаемый результат
1	Agent Registry	Получение записи	Запрос к отсутствующему агенту	1. Выполнить `GET /api/v2/agents/{nonexistent-uuid}`. 2. Выполнить `GET /api/v2/agents/{agentId}` для агента, на который нет права просмотра.	В обоих случаях возвращается одинаковый ответ HTTP `404`. Система не раскрывает, отсутствующий агент это или скрытый.

ТК-016. Переход к вызову агента

№	Модуль (компонент)	Функциональность	Название сценария	Действия – Шаги сценария	Ожидаемый результат
1	Agent Registry	Получение интерфейса вызова	Использование URL вызова	1. Найти агента с полем интерфейса в Agent Registry. 2. Использовать только URL из карточки — канонический HTTPS-адрес Platform Agent Gateway для конкретного агента и версии — без подмены агента, версии или внутренней службы через заголовок, параметр или тело. 3. Выполнить вызов через Platform Agent Gateway.	Platform Agent Gateway повторно проверяет токен и право на вызов `agent#invoke`, затем заменяет исходный пользовательский токен на короткоживущее удостоверение, связанное с конкретным агентом. Вызов выполняется успешно при наличии прав; известный URL без права не позволяет обойти шлюз.

ТК-017. Состояния агента

№	Модуль (компонент)	Функциональность	Название сценария	Действия – Шаги сценария	Ожидаемый результат
1	Agent Registry	Отображение состояний	Проверка состояний агентов	1. Открыть список агентов. 2. Проверить, что в каталоге видны только записи в состоянии `active`. 3. Убедиться, что записи `degraded`, `removed`, `rejected` в обычную выдачу не попадают.	В каталоге отображаются только активные записи. `active` — версия прошла проверку и показана при наличии прав. `degraded` — агент существует, но нет пригодного эндпоинта; запись скрыта из каталога, вызов недоступен. `removed` — агент подтверждённо удалён. `rejected` — карточка не прошла проверку, запись не активируется.

ТК-018. Ошибки Agent Registry

№	Модуль (компонент)	Функциональность	Название сценария	Действия – Шаги сценария	Ожидаемый результат
1	Agent Registry	Обработка ошибок	Коды ошибок API	1. Выполнить запрос с неверной формой (400/422). 2. Выполнить запрос без токена (401). 3. Выполнить запрос без права (403). 4. Выполнить запрос к отсутствующему агенту (404). 5. Вызвать конфликт неизменяемой идентичности (409). 6. Превысить ограничение частоты (429). 7. Запросить при недоступной авторизации (503).	Возвращаются соответствующие HTTP-коды и структурированные ошибки с `traceId`. Тело ошибки не раскрывает токен, внутренний URL, текст запроса или карточки и существование запрещённого кандидата. При 503 просмотр списка и одной записи может продолжать работать.

2.3. Platform RAG

ТК-020. Создание коллекции

№	Модуль (компонент)	Функциональность	Название сценария	Действия – Шаги сценария	Ожидаемый результат
1	Platform RAG	Управление коллекциями	Создание новой коллекции	1. Выполнить `POST /v1/collections` с именем, профилем эмбеддинга, моделью ACL и стратегией чанкинга. 2. Указать `X-Tenant-Id` и `X-User-Id`.	Возвращается HTTP `201 Created`. Коллекция создана с уникальным `collection_id`, статус `created`.

ТК-021. Просмотр коллекции

№	Модуль (компонент)	Функциональность	Название сценария	Действия – Шаги сценария	Ожидаемый результат
1	Platform RAG	Управление коллекциями	Получение карточки коллекции	1. Выполнить `GET /v1/collections/{collection_id}`. 2. Проверить статус и параметры коллекции.	Возвращается HTTP `200`. Статус коллекции — `ready` (после индексации первых документов). Отображаются `doc_count` и `chunk_count`.

ТК-022. Приём документов

№	Модуль (компонент)	Функциональность	Название сценария	Действия – Шаги сценария	Ожидаемый результат
1	Platform RAG	Приём документов	Отправка канонического документа	1. Выполнить `POST /v1/documents:submit` с каноническим документом (содержимое, метаданные, ACL, хеш, ключ идемпотентности).	Возвращается HTTP `202 Accepted`. Задание зарегистрировано со статусом `PENDING`.

ТК-023. Проверка статуса задания приёма

№	Модуль (компонент)	Функциональность	Название сценария	Действия – Шаги сценария	Ожидаемый результат
1	Platform RAG	Приём документов	Отслеживание статуса ingest	1. Получить `job_id` из ответа приёма. 2. Периодически запрашивать `GET /v1/jobs/{job_id}`. 3. Дождаться перехода статуса в `DONE`.	Цепочка статусов: `PENDING` → `RUNNING` → `DONE`. После `DONE` документ доступен для поиска.

ТК-024. Идемпотентность приёма

№	Модуль (компонент)	Функциональность	Название сценария	Действия – Шаги сценария	Ожидаемый результат
1	Platform RAG	Приём документов	Повторная отправка с тем же хешем	1. Повторно отправить документ с тем же `content_hash` и `idempotency_key`.	Возвращается статус `DEDUPLICATED`. Документ не дублируется.

ТК-025. Гибридный поиск

№	Модуль (компонент)	Функциональность	Название сценария	Действия – Шаги сценария	Ожидаемый результат
1	Platform RAG	Поиск	Гибридный запрос по коллекции	1. Выполнить `POST /v1/query` с именем коллекции, текстом запроса, режимом `hybrid`. 2. Указать `top_k` и `rerank: true`.	Возвращаются цитаты с `doc_id`, `chunk_id`, `source_url`, `title`, `content`, `score`. Результаты ранжированы по семантике и BM25 слиянием RRF.

ТК-026. Фильтрация поиска по правам

№	Модуль (компонент)	Функциональность	Название сценария	Действия – Шаги сценария	Ожидаемый результат
1	Platform RAG	Поиск	Поиск с ACL-фильтрацией	1. Выполнить поиск от имени пользователя без прав на документ. 2. Сравнить результаты с поиском от имени пользователя с правом `group:hr`.	Пользователь без прав получает пустой `items` (или без закрытого документа). Пользователь с правами получает цитаты.

ТК-027. Упаковка контекста

№	Модуль (компонент)	Функциональность	Название сценария	Действия – Шаги сценария	Ожидаемый результат
1	Platform RAG	Поиск	Упаковка под бюджет токенов	1. Выполнить `POST /v1/retrieve_and_pack` с `token_budget`.	Возвращается упакованный текстовый контекст, количество токенов, режим и массив цитат, вошедших в контекст.

ТК-028. Переиндексация коллекции

№	Модуль (компонент)	Функциональность	Название сценария	Действия – Шаги сценария	Ожидаемый результат
1	Platform RAG	Управление коллекциями	Запуск переиндексации	1. Выполнить `POST /v1/collections/{collection_id}:reindex`.	Возвращается HTTP `202 Accepted`. Новая версия индекса создаётся атомарно. Старая версия сохраняется до завершения.

ТК-029. Пустой ACL в приватной коллекции

№	Модуль (компонент)	Функциональность	Название сценария	Действия – Шаги сценария	Ожидаемый результат
1	Platform RAG	Приём документов	Документ без ACL	1. Отправить документ с пустым `acl` в приватную коллекцию с политикой `reject`.	Возвращается HTTP `400` `invalid_document`. Документ отклонён.

2.4. Memory Service

ТК-030. Подключение памяти к агенту — добавление памяти

№	Модуль (компонент)	Функциональность	Название сценария	Действия – Шаги сценария	Ожидаемый результат
1	Memory Service	Запись памяти	Добавление фактов из диалога	1. Выполнить `POST /v1/memories` с сообщениями диалога, `agent_id`, `run_id`. 2. Указать `infer: true`.	Возвращается HTTP `202 Accepted` с `event_id` и статусом `PENDING`. Извлечение фактов выполняется асинхронно.

ТК-031. Проверка статуса события добавления

№	Модуль (компонент)	Функциональность	Название сценария	Действия – Шаги сценария	Ожидаемый результат
1	Memory Service	Статус события	Ожидание завершения извлечения	1. Получить `event_id` из ответа добавления. 2. Периодически запрашивать `GET /v1/events/{event_id}`. 3. Дождаться статуса `SUCCEEDED`.	Цепочка статусов: `PENDING` → `SUCCEEDED`. При `SUCCEEDED` возвращаются `memory_ids`.

ТК-032. Поиск памяти

№	Модуль (компонент)	Функциональность	Название сценария	Действия – Шаги сценария	Ожидаемый результат
1	Memory Service	Поиск памяти	Мультисигнальный поиск по фильтру	1. Выполнить `POST /v1/memories/search` с запросом, фильтрами (scope + составные условия), `top_k`, `token_budget`.	Возвращаются ранжированные результаты с `score`, `score_details` (semantic, bm25), `created_at`. Результаты уложены в бюджет токенов.

ТК-033. Список записей памяти

№	Модуль (компонент)	Функциональность	Название сценария	Действия – Шаги сценаря	Ожидаемый результат
1	Memory Service	Список памяти	Получение списка по агенту	1. Выполнить `GET /v1/memories?agent_id={agent_id}&page_size=20`.	Возвращается HTTP `200` с `count` и массивом записей (`id`, `memory`, скоупы, `created_at`).

ТК-034. Получение одной записи

№	Модуль (компонент)	Функциональность	Название сценария	Действия – Шаги сценария	Ожидаемый результат
1	Memory Service	Управление записями	Просмотр конкретной записи	1. Выполнить `GET /v1/memories/{memory_id}`.	Возвращается HTTP `200` с полями: `id`, `memory`, `user_id`, `agent_id`, `categories`, `hash`, `created_at`, `updated_at`, `role`.

ТК-035. Обновление записи памяти

№	Модуль (компонент)	Функциональность	Название сценария	Действия – Шаги сценария	Ожидаемый результат
1	Memory Service	Управление записями	Изменение текста факта	1. Выполнить `PUT /v1/memories/{memory_id}` с новым текстом.	Возвращается HTTP `200` с обновлённой записью. Изменения немедленно отражаются в поиске.

ТК-036. Удаление записи памяти

№	Модуль (компонент)	Функциональность	Название сценария	Действия – Шаги сценария	Ожидаемый результат
1	Memory Service	Управление записями	Soft-delete одной записи	1. Выполнить `DELETE /v1/memories/{memory_id}`.	Возвращается HTTP `200` с сообщением «Memory deleted successfully».

ТК-037. Право на забвение — удаление по фильтру

№	Модуль (компонент)	Функциональность	Название сценария	Действия – Шаги сценария	Ожидаемый результат
1	Memory Service	Право на забвение	Удаление всех записей по фильтру	1. Выполнить `DELETE /v1/memories?agent_id={agent_id}`. 2. Проверить ответ.	Возвращается HTTP `200` с `deleted_count` и `confirmation_id` для аудита. Удаление необратимо.

ТК-038. История изменений записи

№	Модуль (компонент)	Функциональность	Название сценария	Действия – Шаги сценария	Ожидаемый результат
1	Memory Service	История записей	Просмотр журнала изменений	1. Выполнить `GET /v1/memories/{memory_id}/history`.	Возвращается HTTP `200` и массив записей с событиями `ADD`, `UPDATE`, `DELETE`.

ТК-039. Рабочая память сессии — сохранение

№	Модуль (компонент)	Функциональность	Название сценария	Действия – Шаги сценария	Ожидаемый результат
1	Memory Service	Рабочая память сессии	Сохранение чекпоинта	1. Выполнить `POST /v1/sessions/{session_id}/state` с состоянием и `ttl_seconds`.	Возвращается HTTP `200` с `session_id`, `state`, `updated_at`, `ttl_remaining_seconds`.

ТК-040. Рабочая память сессии — восстановление

№	Модуль (компонент)	Функциональность	Название сценария	Действия – Шаги сценария	Ожидаемый результат
1	Memory Service	Рабочая память сессии	Восстановление чекпоинта	1. Выполнить `GET /v1/sessions/{session_id}/state`.	Возвращается HTTP `200` с восстановленным состоянием. При отсутствии — HTTP `404`.

ТК-041. Негативные проверки Memory Service

№	Модуль (компонент)	Функциональность	Название сценария	Действия – Шаги сценария	Ожидаемый результат
1	Memory Service	Обработка ошибок	Отсутствие обязательных параметров	1. Выполнить `POST /v1/memories` без `agent_id` и `run_id`. 2. Выполнить `GET /v1/memories` без фильтров. 3. Выполнить `DELETE /v1/memories` без фильтра. 4. Запросить чужой `user_id` при delete. 5. Запросить несуществующее событие.	1. HTTP `400` — отсутствует скоуп. 2. HTTP `400` — отсутствует скоуп. 3. HTTP `400` — отсутствует фильтр. 4. HTTP `403` `Wrong user ID`. 5. HTTP `404`.

2.5. Сквозные пользовательские сценарии

ТК-050. Сквозной путь: создание агента и вызов

№	Модуль (компонент)	Функциональность	Название сценария	Действия – Шаги сценария	Ожидаемый результат
1	Low-code Конструктор	Создание и проверка агента	Полный путь автора	1. Войти в Low-code Конструктор через SSO. 2. Создать пустой Flow. 3. Добавить компонент входа, `PlatformLLM`, выход. 4. Сохранить рабочую версию. 5. Запустить серверную проверку. 6. Дождаться успешного результата (SHA-256, версия политики).	Flow создан, сохранён и проверен.
2	Low-code Конструктор	Публикация	Публикация из интерфейса	1. Вызвать публикацию в интерфейсе Low-code Конструктора. 2. Дождаться ответа `202 Accepted`. 3. Отслеживать статус операции публикации до конечного успешного состояния. 4. Publisher собирает артефакт и разворачивает экземпляр в Kubernetes.	Low-code Runtime развёрнут и готов. Операция публикации достигла конечного успешного статуса.
3	Agent Registry	Обнаружение	Автоматическое обнаружение	1. Agent Registry обнаруживает развёрнутый workload в Kubernetes. 2. Формирует карточку агента и авторизационные данные. 3. Добавляет активную запись в каталог.	Агент появляется в каталоге со статусом `active` и типом реализации `low-code`. Появление не мгновенно — после завершения операции публикации и взаимодействия с Kubernetes.
4	Agent Registry	Поиск	Нахождение агента пользователем	1. Пользователь открывает Agent Registry. 2. Находит агента по названию. 3. Проверяет наличие права на вызов.	Агент найден. Интерфейс вызова присутствует при наличии права.
5	Platform Agent Gateway	Вызов	Выполнение вызова агента	1. Пользователь вызывает агента через Platform Agent Gateway. 2. Gateway проверяет токен и право `agent#invoke`. 3. Заменяет токен на короткоживущее удостоверение. 4. Передаёт запрос в Low-code Runtime.	Вызов выполняется. Исходный токен не передаётся в Low-code Runtime.

ТК-051. Сквозной путь: использование Platform RAG

№	Модуль (компонент)	Функциональность	Название сценария	Действия – Шаги сценария	Ожидаемый результат
1	Platform RAG	Создание коллекции	Настройка базы знаний	1. Создать коллекцию через Platform SDK или Control Plane. 2. Указать имя, профиль эмбеддинга, модель ACL, стратегию чанкинга.	Коллекция создана, статус `created`.
2	Platform RAG	Приём документов	Загрузка документов	1. Отправить канонический документ через `submit_documents`. 2. Дождаться статуса `DONE`.	Документ проиндексирован и доступен для поиска.
3	Platform RAG	Поиск	Запрос с цитатами	1. Выполнить `POST /v1/query` с текстом запроса. 2. Проверить наличие цитат (ссылки на источник).	Результаты содержат `doc_id`, `chunk_id`, `source_url` для проверки достоверности.
4	Platform RAG	Упаковка контекста	Передача в LLM	1. Выполнить `POST /v1/retrieve_and_pack` с `token_budget`.	Возвращён упакованный контекст, укладывающийся в заданный бюджет токенов.

ТК-052. Сквозной путь: использование Memory Service

№	Модуль (компонент)	Функциональность	Название сценария	Действия – Шаги сценария	Ожидаемый результат
1	Memory Service	Добавление памяти	Сохранение фактов о пользователе	1. Отправить ход диалога через `POST /v1/memories`. 2. Дождаться статуса `SUCCEEDED`.	Факт извлечён, проведена дедупликация, проиндексирован.
2	Memory Service	Поиск памяти	Получение релевантных фактов	1. Выполнить `POST /v1/memories/search` перед вызовом LLM. 2. Проверить ранжирование и бюджет токенов.	Возвращены релевантные факты, ранжированные по семантике и BM25.
3	Memory Service	Управление записями	Редактирование факта	1. Отредактировать запись через интерфейс T1GPT или API. 2. Проверить поиск после изменения.	Изменения немедленно отражаются в поиске.
4	Memory Service	Право на забвение	Удаление своих записей	1. Пользователь открывает экран «Память агента» в T1GPT. 2. Просматривает записи. 3. Удаляет неверную запись.	Запись удалена. Возвращён `confirmation_id` для аудита.

2.6. Активность и потребление Control Plane

Эти сценарии описывают проверку нового функционала CORE-1980. Их наличие в программе не означает успешное выполнение или подпись комиссии. Проверки Activity в локальном контуре завершены 26 сентября 2026 года; их измеренные результаты и границы приведены в руководстве по эксплуатации. Они не заменяют приёмку всего выпуска комиссией.

Проверка	Действия	Ожидаемый результат
`AU-01`: потребление	Выполнить известный набор LLM-запросов через платформенный ключ, затем выбрать его и точный период	Число запросов и наблюдаемые токены совпадают с независимым набором; состояния полноты отражены явно
`AU-02`: разрезы	Выбрать один ключ фильтром и сгруппировать токены по моделям	Группы и «Остальные» согласованы с итогом; фильтр и разрез выполняют разные действия
`AU-03`: диагностика	Открыть запрос из журнала, проверить ошибку и задержку	Карточка соответствует запросу; нет текстов диалогов и секретов; неизвестные измерения не заменены нулями
`AU-04`: права	Сравнить администратора, владельца ключа и постороннего; отозвать право у открывшего карточку	Выборки ограничены текущими правами; недоступная карточка возвращает 404, включая повторное чтение после отзыва
`AU-05`: агенты	Вызвать агента и открыть отдельную статистику его HTTP-обращений	HTTP-исход не выдаётся за успешность всей задачи; пользователь не приписывается служебному LLM-ключу
`AU-06`: недоступность	В изолированном контуре временно прервать запись в ClickHouse и восстановить её	Подтверждённая дисковая очередь доставляется в пределах проверяемых ограничений; повторы не удваивают расход
`AU-07`: срок хранения	Сравнить записи внутри и за границей 30 суток	История старше окна недоступна через API, журнал, справочники и карточки независимо от задержки физического удаления

Воспроизводимые команды и границы проверок: эксплуатация Activity, известные ограничения.

3. Правила проведения испытаний

3.1. Порядок выполнения

Испытания проводятся в среде, идентичной целевой по составу компонентов и зависимостей.
Каждый тестовый кейс выполняется последовательно. Пропуск предыдущего кейса допускается только с документированным обоснованием.
Результат каждого кейса фиксируется как «Прошёл» или «Не прошёл» с указанием причины неудачи.
При неудаче ключевого кейса (ТК-004, ТК-050) испытания приостанавливаются до устранения причины.

3.2. Критерии приёмки

Испытания считаются пройденными, если:

Все тестовые кейсы из раздела 2 выполнены.
Ключевые сценарии (ТК-001 — ТК-007, ТК-010 — ТК-018, ТК-020 — ТК-029, ТК-030 — ТК-041, ТК-050 — ТК-052) прошли успешно.
Негативные проверки (ТК-005, ТК-006, ТК-029, ТК-041) подтверждают корректную обработку ошибок.
Сквозные сценарии (ТК-050 — ТК-052) воспроизводят полный пользовательский путь.

3.3. Документирование результатов

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

номер и название тестового кейса;
дату и исполнителя;
результат (прошёл / не прошёл);
при неудаче — описание расхождения с ожидаемым результатом;
ссылки на журналы и traceId.

4. Ограничения испытаний

Испытания версии 3.5 проводятся с учётом известных ограничений:

Промышленная готовность семантического поиска не подтверждена — он не проверен на настоящих AI Gateway и OpenSearch, проверяется только совместимость интерфейсов.
Промышленная среда не реализована — испытания проводятся в средах разработки.
Platform RAG и Memory Service поставляются как самостоятельные сервисы и не интегрированы с другими компонентами Платформы ИИ — компоненты PlatformRAG и PlatformMemory отсутствуют в палитре Low-code Конструктора, доступ к сервисам у агентов только через Platform SDK.

Приложение 1. Протокол испытаний

Испытания проведены объединенной комиссией в составе:

От Заказчика: [ФИО, должность]

От Исполнителя: [ФИО, должность]

Объект испытаний: Платформа ИИ

Протокол испытаний исходной версии 3.5

№	Тестовый кейс	Название сценария	Результат
1	ТК-001	Вход в Low-code Конструктор через SSO	Успешно
2	ТК-002	Создание минимального Flow	Успешно
3	ТК-003	Сохранение Flow	Успешно
4	ТК-004	Успешная проверка	Успешно
5	ТК-005	Ошибка component_not_allowed	Успешно
6	ТК-006	Обнаружение секрета	Успешно
7	ТК-007	Публикация проверенной версии Flow	Успешно
8	ТК-008	Отклонение изменённого компонента	Успешно
9	ТК-009	Нахождение агента в каталоге	Успешно
10	ТК-010	Получение списка разрешённых агентов	Успешно
11	ТК-011	Поиск по протоколу, типу реализации и владельцу	Успешно
12	ТК-012	Просмотр карточки агента	Успешно
13	ТК-013	Поиск по тексту	Успешно
14	ТК-014	Отсутствие совпадений	Успешно
15	ТК-015	Запрос к отсутствующему агенту	Успешно
16	ТК-016	Использование URL вызова	Успешно
17	ТК-017	Проверка состояний агентов	Успешно
18	ТК-018	Коды ошибок API	Успешно
19	ТК-020	Создание новой коллекции	Успешно
20	ТК-021	Получение карточки коллекции	Успешно
21	ТК-022	Отправка канонического документа	Успешно
22	ТК-023	Отслеживание статуса ingest	Успешно
23	ТК-024	Повторная отправка с тем же хешем	Успешно
24	ТК-025	Гибридный запрос по коллекции	Успешно
25	ТК-026	Поиск с ACL-фильтрацией	Успешно
26	ТК-027	Упаковка под бюджет токенов	Успешно
27	ТК-028	Запуск переиндексации	Успешно
28	ТК-029	Пустой ACL в приватной коллекции	Успешно
29	ТК-030	Добавление фактов из диалога	Успешно
30	ТК-031	Ожидание завершения извлечения	Успешно
31	ТК-032	Мультисигнальный поиск по фильтру	Успешно
32	ТК-033	Получение списка по агенту	Успешно
33	ТК-034	Просмотр конкретной записи	Успешно
34	ТК-035	Изменение текста факта	Успешно
35	ТК-036	Soft-delete одной записи	Успешно
36	ТК-037	Удаление всех записей по фильтру	Успешно
37	ТК-038	Просмотр журнала изменений	Успешно
38	ТК-039	Сохранение чекпоинта	Успешно
39	ТК-040	Восстановление чекпоинта	Успешно
40	ТК-041	Отсутствие обязательных параметров	Успешно
41	ТК-050	Полный путь автора	Успешно
42	ТК-051	Настройка базы знаний	Успешно
43	ТК-052	Сохранение фактов о пользователе	Успешно

Программа и методика испытаний ИС "Платформа ИИ"

На этой странице