# Что подтверждают проверки системы

Успешная сборка, запуск, равенство схем и прохождение пользовательского
сценария — разные доказательства. Выбор проверки зависит от наблюдаемого
риска: денежных вычислений, доступа, целостности данных или состояния интерфейса.
Общие основания описаны в [принципах сопровождения](engineering-governance.md#risk-based-testing).

## Интерфейс

Локальный gate frontend охватывает типы, статический анализ, автоматические
сценарии, зависимости и сборки приложения и UI-каталога. Он выполняется
без запущенного backend. Покрытие ограничивает регрессии, но не доказывает
правильность финансового расчёта, доступность и полный пользовательский сценарий.

[Каталог](ui-catalog.md) показывает существующие визуальные решения на
вымышленных данных. Широкий и узкий экран, клавиатурная навигация,
восстановление после ошибок и соответствие задаче проверяются в интерфейсе
отдельно от сборки. Изолированная тестовая среда не воспроизводит все свойства
браузера и живой интеграции.

## API и хранение данных

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

Равенство OpenAPI подтверждает согласованность публичного описания с клиентом.
Валидация, cookie, авторизация счёта, статусы и ошибки требуют полного HTTP-потока;
целостность и конкурентные изменения данных — проверки с изолированной реальной
базой. Подставной ответ базы не доказывает её транзакционные свойства.
Направление генерации и границы сравнения — в [проверке OpenAPI](runtime-openapi-verification.md).

### Известное ограничение сквозной проверки

Прежний blocker WL-P2-05 снят в конфигурации Prisma: на Node 22.21.0 /
Prisma 7.9.1 унаследованный `RUST_LOG=warn` или `error` воспроизводит пустой
`Schema engine error`, а отсутствие переменной позволяет fresh migration.
Backend Prisma config удаляет переменную в процессе CLI после загрузки `.env`;
это не меняет application logging. Версии зависимостей и SQL history сохранены.

`npm run test:e2e` применяет migrations и запускает каждую HTTP suite на отдельной
временной DB. Один URL передаётся Prisma и Jest; прямой запуск Jest без runner
отклоняется до DB-запросов. При ошибке и SIGINT/SIGTERM выполняется cleanup.
`npm run test:sqlite` выбирает auth/cards; `test:durability` отдельно проверяет
migration, restart, возврат предыдущего приложения и backup/restore.
Команды и runnable regression — в
[backend README](../../backend/README.md#реальная-sqlite-и-сохранность-данных),
фактические результаты — в
[registry](audit-remediation.md#2026-09-13--wl-p2-05-воспроизводимый-sqlite-e2e).

Backend `verify` остаётся статическим/unit/build gate; полный HTTP/DB scope
проверяется отдельным `test:e2e`. Успех этих команд не подтверждает доступность
внешнего T-Bank. HTTP tests требуют локальных портов, которые sandbox может
запрещать. Безопасное сохранение реальных данных — в
[локальном окружении](local-workspace.md).

## Где выполнять проверки

Команды и конкретные тестовые правила поддерживаются в локальных инструкциях
[frontend](../../frontend/AGENTS.md) и [backend](../../backend/AGENTS.md).
Проверки этой документации — в [CONTRIBUTING](../CONTRIBUTING.md#проверки).
Отчёт различает пройденную границу, оставшееся ограничение и проверяемое состояние;
успех одного gate не распространяется автоматически на весь workspace.