docs: trust supplied OpenAPI snapshot

development/runtime-openapi-verification.md

@@ -1,14 +1,18 @@
-# Проверка runtime OpenAPI
+# OpenAPI contract flow
 
 ## Назначение
 
-Проверка сравнивает OpenAPI, сформированный настроенным backend-приложением,
-с описанием API, на котором основан frontend. Backend остаётся единственным
-источником исполняемого HTTP-контракта; frontend-клиент является производным.
-Причины выбора описаны в [ADR 002](../adr/002-nest-generated-openapi-contract.md).
+Backend остаётся источником HTTP-контракта и формирует OpenAPI из публичного
+API. Frontend принимает предоставленный `openapi.json` как актуальный вход,
+хранит его snapshot и генерирует из него transport types локально. Причины
+выбора backend-generated контракта описаны в
+[ADR 002](../adr/002-nest-generated-openapi-contract.md), отказ от frontend
+проверки backend runtime-схемы — в [ADR 014](../adr/014-trusted-openapi-input.md).
 
-Эта проверка подтверждает согласованность публичного контракта, но не заменяет
-проверки каждого приложения и наблюдаемого HTTP-поведения.
+Frontend не проверяет, что переданный snapshot совпадает с текущим backend
+runtime OpenAPI, не фиксирует пару frontend/backend SHA и не зависит от пути к
+соседнему backend checkout. Подготовка и доставка актуального OpenAPI-документа
+находятся вне frontend.
 
 ## Выбор и направление изменения
 
@@ -16,28 +20,27 @@
 статуса либо формы ошибки. Внутреннее изменение представления без изменения
 API не требует нового описания контракта.
 
-Направление согласования: публичный API backend → OpenAPI → производное
-описание и типизированный клиент frontend. Две независимо редактируемые версии
+Направление согласования: публичный API backend → предоставленный OpenAPI →
+frontend snapshot → generated types. Две независимо редактируемые версии
 контракта создавали бы риск расхождения. Перед изменением, влияющим на
 совместимость, учитываются существующие потребители и сохранность данных.
 Семантика запросов и ошибок описана в [HTTP API](../architecture/http-api.md).
 
 ## Границы и результат
 
-Сравнение выполняется на границе настроенного приложения, нормализует порядок
-ключей JSON-объектов и сохраняет порядок массивов. Оно не обновляет сравниваемые
-описания и клиент автоматически и не обращается к T-Bank или другим внешним
-источникам. Несовпадение указывает на рассогласование контракта.
+Frontend-команда генерации читает только committed snapshot и обновляет
+generated types. Frontend-проверка генерирует types из этого snapshot во
+временный каталог и сравнивает результат с committed generated artifact.
+Несовпадение означает, что snapshot и generated types в frontend расходятся.
 
-Равенство схем не доказывает фактическую работу валидации, авторизации,
-статусов, cookie и обработки ошибок: для этого нужны наблюдения полного
-HTTP-потока. Согласованность описаний и функциональная корректность —
-разные доказательства.
+Эта проверка не доказывает актуальность snapshot относительно backend. Это
+принятое допущение, а не свойство frontend gate. Она также не доказывает
+фактическую работу валидации, авторизации, статусов, cookie и обработки ошибок:
+для этого нужны наблюдения полного HTTP-потока.
 
-## Граница e2e
+## Граница runtime
 
-`npm run test:openapi-contract` подготавливает отдельную временную SQLite-базу
-через общий runner и выполняет только сравнение OpenAPI. Соседний frontend
-checkout нужен для snapshot. Полные HTTP-сценарии запускает `test:e2e`;
-миграция перед сравнением не подменяет проверку поведения приложения.
-Подробности — в [сквозной проверке](verification.md#известное-ограничение-сквозной-проверки).
+Работающий frontend использует сгенерированные types и обычные HTTP-запросы к
+API. Swagger или OpenAPI endpoint не являются runtime-зависимостью SPA.
+Полные HTTP-сценарии и хранение данных проверяются отдельными backend-gates;
+локальный frontend gate выполняется без backend.