# 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 и настройки защиты ветки требуют отдельного обновления.