Add renovate.json

2026-09-13 14:02:30 +00:00
9 changed files with 43 additions and 91 deletions
@@ -1,39 +0,0 @@
 # 014. Актуальная OpenAPI-схема как вход frontend
 **Статус:** принято 2026-09-13; docs, specs и frontend-инструкции приведены
 к решению. Настройка remote issues и branch protection выполняется отдельно.
 ## Контекст
 Frontend и backend — независимые репозитории. Знание путей и команд backend
 в frontend связывает их внутреннее устройство. Для текущего процесса разработки
 владелец проекта принимает актуальность переданной OpenAPI-схемы как допущение;
 проверка пары revisions и дополнительное сравнение схем не требуются.
 ## Решение
 Backend остаётся источником HTTP-контракта согласно [ADR 002](002-nest-generated-openapi-contract.md).
 Frontend принимает предоставленную OpenAPI-схему как актуальную и генерирует
 из неё типы локально. Его команды не читают файлы соседнего backend checkout
 и не запускают backend-скрипты. Подготовка и доставка схемы находятся вне frontend.
 Не требуется фиксировать пару SHA frontend/backend или сравнивать frontend-схему
 с runtime OpenAPI backend. Локальная проверка соответствия generated types
 входной схеме сохраняется: она не проверяет актуальность схемы относительно backend.
 Обычные CI checks по-прежнему должны проверять текущий commit изменения.
 ## Последствия
 Задача frontend #3 ограничивается локальной генерацией из предоставленной схемы;
 экспорт backend не становится обязанностью frontend. Из frontend #2 исключается
 требование проверки явно выбранной пары revisions. Требования безопасности
 frontend #4 этим решением не меняются.
 Рассинхронизацию предоставленной схемы и backend отдельный gate не обнаруживает:
 её отсутствие принято как допущение. Тесты HTTP-поведения, валидации и авторизации
 остаются нужны.
 Решение заменяет прежнее требование сравнения runtime OpenAPI с frontend
 snapshot в [OpenAPI contract flow](../development/runtime-openapi-verification.md)
 и [спецификации генерации API](../../specs/openspec/specs/api-contract-generation/spec.md).
 Связанные remote issues и настройки защиты ветки требуют отдельного обновления.
@@ -21,4 +21,3 @@
 - [011 — Native OpenSpec lifecycle и repository gates](011-native-openspec-lifecycle-with-repository-gates.md) — заменён ADR 012 в части обязательного lifecycle.
 - [012 — Прямая разработка с контекстом по задаче](012-task-driven-development-with-scoped-context.md)
 - [013 — НКР как первый источник кредитных рейтингов облигаций](013-nkr-bond-credit-ratings.md)
 - [014 — Актуальная OpenAPI-схема как вход frontend](014-trusted-openapi-input.md)
@@ -53,12 +53,10 @@ T-Bank в форме и отправляет его для сохранения,
 загрузка публичного изображения из CDN не проходит через эту финансовую
 границу.
-Типизированный frontend-клиент производится из предоставленного OpenAPI snapshot
+Типизированный frontend-клиент производится из OpenAPI backend во время
-во время разработки. В runtime SPA вызывает API, а не генератор или OpenAPI
+разработки. В runtime SPA вызывает API, а не генератор или OpenAPI endpoint.
-endpoint. Форма запросов и ошибок описана в [HTTP API](http-api.md); направление
+Форма запросов и ошибок описана в [HTTP API](http-api.md); направление
-генерации принято в [ADR 002](../adr/002-nest-generated-openapi-contract.md),
+генерации принято в [ADR 002](../adr/002-nest-generated-openapi-contract.md).
 а доверие frontend к предоставленному snapshot — в
 [ADR 014](../adr/014-trusted-openapi-input.md).
 ## Хранимые данные и границы доступа
@@ -3,9 +3,8 @@
 ## Источник контракта
 Backend генерирует OpenAPI из собственного публичного API. Frontend использует
-предоставленный OpenAPI snapshot как актуальный вход и локально генерирует
+производное описание контракта и типизированный клиент. Изменения проходят
-типизированный клиент. Направление описано в
+[contract workflow](../development/runtime-openapi-verification.md).
 [OpenAPI contract flow](../development/runtime-openapi-verification.md).
 API имеет prefix `/api/v1`; Swagger публикуется для локальной разработки по
 environment policy, а не используется frontend в runtime.
@@ -56,10 +55,10 @@ T-Bank token failure и временная недоступность имеют
 ## Граница доказательства
-OpenAPI snapshot задаёт frontend transport types, но сам по себе не доказывает
+Сравнение OpenAPI подтверждает согласованность схем, а не результат каждого
-результат каждого запроса. Безопасная обработка неожиданной ошибки проверяется
+запроса. Безопасная обработка неожиданной ошибки проверяется отдельно.
-отдельно. Валидация, доступ, статусы и cookie требуют проверки полного
+Валидация, доступ, статусы и cookie требуют проверки полного HTTP-потока;
-HTTP-потока; атомарность хранения — проверки с изолированной реальной базой.
+атомарность хранения — проверки с изолированной реальной базой.
 Известное ограничение сквозных проверок описано в
 [проверке backend](../development/verification.md).
@@ -6,7 +6,7 @@
 - [Локальное окружение](local-workspace.md) — предпосылки работы, первый пользовательский сценарий и диагностика.
 - [Проверки системы](verification.md) — что доказывают проверки интерфейса, API и хранения данных, известные ограничения.
- [HTTP contract](runtime-openapi-verification.md) — направление генерации OpenAPI и локальная проверка snapshot/types.
+- [HTTP contract](runtime-openapi-verification.md) — направление генерации OpenAPI и проверка совместимости.
 - [Дизайн-система](design-system.md) / [UI-каталог](ui-catalog.md) — визуальные роли, реальные состояния и ограничения примеров.
 - [Принципы изменений](engineering-governance.md) — связность системы, риск и доказательства результата.
 - [Ведение документации](../CONTRIBUTING.md) — самостоятельные объяснения и их обновление вместе с системой.
@@ -41,9 +41,9 @@ OpenSpec остаётся [необязательным средством со
 Результат оценивается по исходной задаче: сохранены ли смысл данных и контракты,
 правильно ли разграничен доступ, учтены ли ошибки и доступность интерфейса.
-При изменении HTTP-контракта backend обновляет публичный OpenAPI, а frontend
+Проверки приложений и документации дополняются
-проверяет соответствие generated types полученному snapshot согласно
+[согласованием HTTP-контракта](runtime-openapi-verification.md), если он меняется.
-[OpenAPI contract flow](runtime-openapi-verification.md). Общего CI сейчас нет.
+Общего CI сейчас нет.
 Успешная проверка применима к тому состоянию системы и тем предпосылкам,
 на которых выполнена. При их изменении старое свидетельство не доказывает
@@ -127,5 +127,5 @@ HTTP-запросы связываются с безопасными журна
 Успешная сборка, запуск и прохождение сценария — разные доказательства.
 Границы [проверок системы](verification.md) и
-[OpenAPI contract flow](runtime-openapi-verification.md) рассматриваются отдельно.
+[HTTP-контракта](runtime-openapi-verification.md) рассматриваются отдельно.
 Завершённость результата учитывает фактические проверки и остающиеся ограничения.
@@ -1,18 +1,14 @@
-# OpenAPI contract flow
+# Проверка runtime OpenAPI
 ## Назначение
-Backend остаётся источником HTTP-контракта и формирует OpenAPI из публичного
+Проверка сравнивает OpenAPI, сформированный настроенным backend-приложением,
-API. Frontend принимает предоставленный `openapi.json` как актуальный вход,
+с описанием API, на котором основан frontend. Backend остаётся единственным
-хранит его snapshot и генерирует из него transport types локально. Причины
+источником исполняемого HTTP-контракта; frontend-клиент является производным.
-выбора backend-generated контракта описаны в
+Причины выбора описаны в [ADR 002](../adr/002-nest-generated-openapi-contract.md).
 [ADR 002](../adr/002-nest-generated-openapi-contract.md), отказ от frontend
 проверки backend runtime-схемы — в [ADR 014](../adr/014-trusted-openapi-input.md).
-Frontend не проверяет, что переданный snapshot совпадает с текущим backend
+Эта проверка подтверждает согласованность публичного контракта, но не заменяет
-runtime OpenAPI, не фиксирует пару frontend/backend SHA и не зависит от пути к
+проверки каждого приложения и наблюдаемого HTTP-поведения.
 соседнему backend checkout. Подготовка и доставка актуального OpenAPI-документа
 находятся вне frontend.
 ## Выбор и направление изменения
@@ -20,27 +16,28 @@ runtime OpenAPI, не фиксирует пару frontend/backend SHA и не
 статуса либо формы ошибки. Внутреннее изменение представления без изменения
 API не требует нового описания контракта.
-Направление согласования: публичный API backend → предоставленный OpenAPI →
+Направление согласования: публичный API backend → OpenAPI → производное
-frontend snapshot → generated types. Две независимо редактируемые версии
+описание и типизированный клиент frontend. Две независимо редактируемые версии
 контракта создавали бы риск расхождения. Перед изменением, влияющим на
 совместимость, учитываются существующие потребители и сохранность данных.
 Семантика запросов и ошибок описана в [HTTP API](../architecture/http-api.md).
 ## Границы и результат
-Frontend-команда генерации читает только committed snapshot и обновляет
+Сравнение выполняется на границе настроенного приложения, нормализует порядок
-generated types. Frontend-проверка генерирует types из этого snapshot во
+ключей JSON-объектов и сохраняет порядок массивов. Оно не обновляет сравниваемые
-временный каталог и сравнивает результат с committed generated artifact.
+описания и клиент автоматически и не обращается к T-Bank или другим внешним
-Несовпадение означает, что snapshot и generated types в frontend расходятся.
+источникам. Несовпадение указывает на рассогласование контракта.
-Эта проверка не доказывает актуальность snapshot относительно backend. Это
+Равенство схем не доказывает фактическую работу валидации, авторизации,
-принятое допущение, а не свойство frontend gate. Она также не доказывает
+статусов, cookie и обработки ошибок: для этого нужны наблюдения полного
-фактическую работу валидации, авторизации, статусов, cookie и обработки ошибок:
+HTTP-потока. Согласованность описаний и функциональная корректность —
-для этого нужны наблюдения полного HTTP-потока.
+разные доказательства.
-## Граница runtime
+## Граница e2e
-Работающий frontend использует сгенерированные types и обычные HTTP-запросы к
+`npm run test:openapi-contract` подготавливает отдельную временную SQLite-базу
-API. Swagger или OpenAPI endpoint не являются runtime-зависимостью SPA.
+через общий runner и выполняет только сравнение OpenAPI. Соседний frontend
-Полные HTTP-сценарии и хранение данных проверяются отдельными backend-gates;
+checkout нужен для snapshot. Полные HTTP-сценарии запускает `test:e2e`;
-локальный frontend gate выполняется без backend.
+миграция перед сравнением не подменяет проверку поведения приложения.
 Подробности — в [сквозной проверке](verification.md#известное-ограничение-сквозной-проверки).
@@ -25,13 +25,11 @@
 автоматическое форматирование выполняется отдельно и не является доказательством.
 Диагностика покрытия доступна без общего числового порога.
-Frontend OpenAPI check подтверждает только соответствие generated types
+Равенство OpenAPI подтверждает согласованность публичного описания с клиентом.
-сохранённому snapshot. Актуальность snapshot относительно backend принимается
+Валидация, cookie, авторизация счёта, статусы и ошибки требуют полного HTTP-потока;
-как входное допущение. Валидация, cookie, авторизация счёта, статусы и ошибки
+целостность и конкурентные изменения данных — проверки с изолированной реальной
-требуют полного HTTP-потока; целостность и конкурентные изменения данных —
+базой. Подставной ответ базы не доказывает её транзакционные свойства.
-проверки с изолированной реальной базой. Подставной ответ базы не доказывает её
+Направление генерации и границы сравнения — в [проверке OpenAPI](runtime-openapi-verification.md).
 транзакционные свойства. Направление генерации описано в
 [OpenAPI contract flow](runtime-openapi-verification.md).
 ### Известное ограничение сквозной проверки