docs: trust supplied OpenAPI snapshot

development/README.md

@@ -6,7 +6,7 @@
 
 - [Локальное окружение](local-workspace.md) — предпосылки работы, первый пользовательский сценарий и диагностика.
 - [Проверки системы](verification.md) — что доказывают проверки интерфейса, API и хранения данных, известные ограничения.
-- [HTTP contract](runtime-openapi-verification.md) — направление генерации OpenAPI и проверка совместимости.
+- [HTTP contract](runtime-openapi-verification.md) — направление генерации OpenAPI и локальная проверка snapshot/types.
 - [Дизайн-система](design-system.md) / [UI-каталог](ui-catalog.md) — визуальные роли, реальные состояния и ограничения примеров.
 - [Принципы изменений](engineering-governance.md) — связность системы, риск и доказательства результата.
 - [Ведение документации](../CONTRIBUTING.md) — самостоятельные объяснения и их обновление вместе с системой.

development/engineering-governance.md

@@ -41,9 +41,9 @@ OpenSpec остаётся [необязательным средством со
 
 Результат оценивается по исходной задаче: сохранены ли смысл данных и контракты,
 правильно ли разграничен доступ, учтены ли ошибки и доступность интерфейса.
-Проверки приложений и документации дополняются
-[согласованием HTTP-контракта](runtime-openapi-verification.md), если он меняется.
-Общего CI сейчас нет.
+При изменении HTTP-контракта backend обновляет публичный OpenAPI, а frontend
+проверяет соответствие generated types полученному snapshot согласно
+[OpenAPI contract flow](runtime-openapi-verification.md). Общего CI сейчас нет.
 
 Успешная проверка применима к тому состоянию системы и тем предпосылкам,
 на которых выполнена. При их изменении старое свидетельство не доказывает

development/local-workspace.md

@@ -127,5 +127,5 @@ HTTP-запросы связываются с безопасными журна
 
 Успешная сборка, запуск и прохождение сценария — разные доказательства.
 Границы [проверок системы](verification.md) и
-[HTTP-контракта](runtime-openapi-verification.md) рассматриваются отдельно.
+[OpenAPI contract flow](runtime-openapi-verification.md) рассматриваются отдельно.
 Завершённость результата учитывает фактические проверки и остающиеся ограничения.

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.

development/verification.md

@@ -25,11 +25,13 @@
 автоматическое форматирование выполняется отдельно и не является доказательством.
 Диагностика покрытия доступна без общего числового порога.
 
-Равенство OpenAPI подтверждает согласованность публичного описания с клиентом.
-Валидация, cookie, авторизация счёта, статусы и ошибки требуют полного HTTP-потока;
-целостность и конкурентные изменения данных — проверки с изолированной реальной
-базой. Подставной ответ базы не доказывает её транзакционные свойства.
-Направление генерации и границы сравнения — в [проверке OpenAPI](runtime-openapi-verification.md).
+Frontend OpenAPI check подтверждает только соответствие generated types
+сохранённому snapshot. Актуальность snapshot относительно backend принимается
+как входное допущение. Валидация, cookie, авторизация счёта, статусы и ошибки
+требуют полного HTTP-потока; целостность и конкурентные изменения данных —
+проверки с изолированной реальной базой. Подставной ответ базы не доказывает её
+транзакционные свойства. Направление генерации описано в
+[OpenAPI contract flow](runtime-openapi-verification.md).
 
 ### Известное ограничение сквозной проверки