# Программа проверки и комплект поставки

Редакция 2026-09-15

Статус: Редакция 15 сентября 2026 года; состояние функций уточняется документом готовности

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

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

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

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

## Форма протокола
Для каждого испытания фиксируют ID, цель, версию, среду, предварительные условия, входные данные, шаги, ожидаемый результат, фактический результат, статус, дату и ссылку на доказательство. Если тест не проводился, это указывается прямо. Статус «не применимо» требует обоснованного исключения функции из профиля.

Доказательством может быть очищенный журнал, квитанция операции, созданный файл или запись последовательности действий. Скриншот интерфейса не доказывает сохранность данных после перезапуска. Текст модели о выполнении не подтверждает изменение внешней системы.

## Базовый рабочий сценарий
Создайте тестового сотрудника с ограниченной областью. Войдите в Штат, выберите назначенного агента, передайте разрешённый документ и задачу. Проверьте результат, происхождение важных фактов и фактическую доступность файла. Перезапустите выбранные компоненты и проверьте продолжение и повторное открытие данных.

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

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

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

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

Восстановите данные из копии на отдельном узле и измерьте время и возможную потерю данных. Сверьте историю, вложения, настройки и доступ. Значения RPO и RTO подтверждаются измерением; единичная успешная загрузка процесса этого не заменяет.

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

В частности, свежий веб-пилот уточняет старые записи «сайт не реализован», но не закрывает автоматически пункты корпоративной авторизации и полной поставки. Итоговый акт должен ссылаться на конкретный набор испытаний, а не на общий факт обновления сайта документации.

## Согласованная поставка клиентов
Принятая поставка фиксирует совместимые версии приложения, фоновой среды, расширения и серверной части. У каждого пакета есть происхождение, контрольная сумма и способ отката. Успех сборки или набора unit-тестов не подтверждает работу установленных на конкретном компьютере экземпляров.

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

Для общего продолжения между каналом, веб-Штатом и личным приложением требуется отдельный контракт идентичности работы. До его реализации успешные независимые разговоры не засчитываются как сквозной сценарий. Проверка Windows-клиента начнётся с выпуска соответствующей версии Штриха; сейчас поддерживаемая платформа приложения — macOS 15 и новее.

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

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