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
-во время разработки. В runtime SPA вызывает API, а не генератор или OpenAPI
-endpoint. Форма запросов и ошибок описана в [HTTP API](http-api.md); направление
-генерации принято в [ADR 002](../adr/002-nest-generated-openapi-contract.md),
-а доверие frontend к предоставленному snapshot — в
-[ADR 014](../adr/014-trusted-openapi-input.md).
+Типизированный frontend-клиент производится из OpenAPI backend во время
+разработки. В runtime SPA вызывает API, а не генератор или OpenAPI endpoint.
+Форма запросов и ошибок описана в [HTTP API](http-api.md); направление
+генерации принято в [ADR 002](../adr/002-nest-generated-openapi-contract.md).

 ## Хранимые данные и границы доступа

@@ -3,9 +3,8 @@
 ## Источник контракта

 Backend генерирует OpenAPI из собственного публичного API. Frontend использует
-предоставленный OpenAPI snapshot как актуальный вход и локально генерирует
-типизированный клиент. Направление описано в
-[OpenAPI contract flow](../development/runtime-openapi-verification.md).
+производное описание контракта и типизированный клиент. Изменения проходят
+[contract workflow](../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, но сам по себе не доказывает
-результат каждого запроса. Безопасная обработка неожиданной ошибки проверяется
-отдельно. Валидация, доступ, статусы и cookie требуют проверки полного
-HTTP-потока; атомарность хранения — проверки с изолированной реальной базой.
+Сравнение OpenAPI подтверждает согласованность схем, а не результат каждого
+запроса. Безопасная обработка неожиданной ошибки проверяется отдельно.
+Валидация, доступ, статусы и cookie требуют проверки полного 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 согласно
-[OpenAPI contract flow](runtime-openapi-verification.md). Общего CI сейчас нет.
+Проверки приложений и документации дополняются
+[согласованием HTTP-контракта](runtime-openapi-verification.md), если он меняется.
+Общего 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 из публичного
-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).
+Проверка сравнивает OpenAPI, сформированный настроенным backend-приложением,
+с описанием API, на котором основан frontend. Backend остаётся единственным
+источником исполняемого HTTP-контракта; frontend-клиент является производным.
+Причины выбора описаны в [ADR 002](../adr/002-nest-generated-openapi-contract.md).

-Frontend не проверяет, что переданный snapshot совпадает с текущим backend
-runtime OpenAPI, не фиксирует пару frontend/backend SHA и не зависит от пути к
-соседнему backend checkout. Подготовка и доставка актуального OpenAPI-документа
-находятся вне frontend.
+Эта проверка подтверждает согласованность публичного контракта, но не заменяет
+проверки каждого приложения и наблюдаемого HTTP-поведения.

 ## Выбор и направление изменения

@@ -20,27 +16,28 @@ runtime OpenAPI, не фиксирует пару frontend/backend SHA и не
 статуса либо формы ошибки. Внутреннее изменение представления без изменения
 API не требует нового описания контракта.

-Направление согласования: публичный API backend → предоставленный OpenAPI →
-frontend snapshot → generated types. Две независимо редактируемые версии
+Направление согласования: публичный API backend → OpenAPI → производное
+описание и типизированный клиент frontend. Две независимо редактируемые версии
 контракта создавали бы риск расхождения. Перед изменением, влияющим на
 совместимость, учитываются существующие потребители и сохранность данных.
 Семантика запросов и ошибок описана в [HTTP API](../architecture/http-api.md).

 ## Границы и результат

-Frontend-команда генерации читает только committed snapshot и обновляет
-generated types. Frontend-проверка генерирует types из этого snapshot во
-временный каталог и сравнивает результат с committed generated artifact.
-Несовпадение означает, что snapshot и generated types в frontend расходятся.
+Сравнение выполняется на границе настроенного приложения, нормализует порядок
+ключей JSON-объектов и сохраняет порядок массивов. Оно не обновляет сравниваемые
+описания и клиент автоматически и не обращается к T-Bank или другим внешним
+источникам. Несовпадение указывает на рассогласование контракта.

-Эта проверка не доказывает актуальность snapshot относительно backend. Это
-принятое допущение, а не свойство frontend gate. Она также не доказывает
-фактическую работу валидации, авторизации, статусов, cookie и обработки ошибок:
-для этого нужны наблюдения полного HTTP-потока.
+Равенство схем не доказывает фактическую работу валидации, авторизации,
+статусов, cookie и обработки ошибок: для этого нужны наблюдения полного
+HTTP-потока. Согласованность описаний и функциональная корректность —
+разные доказательства.

-## Граница runtime
+## Граница e2e

-Работающий frontend использует сгенерированные types и обычные HTTP-запросы к
-API. Swagger или OpenAPI endpoint не являются runtime-зависимостью SPA.
-Полные HTTP-сценарии и хранение данных проверяются отдельными backend-gates;
-локальный frontend gate выполняется без backend.
+`npm run test:openapi-contract` подготавливает отдельную временную SQLite-базу
+через общий runner и выполняет только сравнение OpenAPI. Соседний frontend
+checkout нужен для snapshot. Полные HTTP-сценарии запускает `test:e2e`;
+миграция перед сравнением не подменяет проверку поведения приложения.
+Подробности — в [сквозной проверке](verification.md#известное-ограничение-сквозной-проверки).
@@ -25,13 +25,11 @@
 автоматическое форматирование выполняется отдельно и не является доказательством.
 Диагностика покрытия доступна без общего числового порога.

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

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