docs: simplify system documentation

2026-09-14 05:51:29 +03:00
parent 67f152d365
commit 9b19a5cf4d
30 changed files with 104 additions and 2445 deletions
@@ -2,13 +2,5 @@
  "config": {
    "MD013": false
  },
-  "customRules": ["markdownlint-rule-relative-links"],
+  "customRules": ["markdownlint-rule-relative-links"]
  "overrides": [
    {
      // Historical evidence records keep original source paths, outside the standalone book.
      "filter": ["development/completion-evidence.md", "development/audit-remediation.md"],
      "config": { "relative-links": false },
      "combine": "merge"
    }
  ]
 }
@@ -7,7 +7,7 @@
 Проверь существенные факты адресно по спецификациям, ADR и реализации с учётом
 веток и незакоммиченных изменений. Расхождение обозначь, не выбирая источник
 победителем автоматически. Перенос сохраняет полезное содержание и входящие
-ссылки; существующие исторические свидетельства остаются неизменными.
+ссылки. Docs описывает текущее устройство системы; история поставок остаётся в Git.
 Отчёты аудитов и исследований в docs не размещаются. Подтверждённые решения
 из исследований оформляются в ADR, системные знания — в тематических страницах.
@@ -16,10 +16,13 @@ Docs даёт самостоятельное понимание продукта
 | Размещение кода, conventions, команды разработки и проверки | Локальные инструкции frontend/backend |
 | Выбор репозитория и типа знания | Корневой [AGENTS](../AGENTS.md) |
 История поставок, аудитов и проверок остаётся в Git, Issues и PR.
 Процесс разработки и инструкции агентов принадлежат локальным инструкциям
 репозиториев. ADR фиксируют решения самой системы, а не организацию работы.
 Основные спецификации описывают и согласованное текущее поведение.
 Различие specs и docs не является разделением на будущее и настоящее.
 Docs объясняет смысл контракта, не вводя независимо редактируемые требования.
 OpenSpec применяется по явному запросу согласно [принятому процессу](development/openspec-authority-and-lifecycle.md).
 ## Потребность читателя и структура
@@ -152,8 +155,6 @@ npm run verify
 При изменениях соседних репозиториев выполни там `git diff --check` и проверь
 затронутые ссылки. Markdown-only правки не требуют тестов всего приложения.
 Точный scope исключений задан существующими `package.json` и конфигурацией lint:
 исторические свидетельства не обязаны разрешать прежние адреса.
 Правило relative-links не проверяет внешние URL и HTML-ссылки. Mermaid-рендер
 в gate не входит; используй доступный локальный рендерер без отправки материалов
 наружу, установки стека или добавления новых валидаторов. Публикационного
@@ -44,15 +44,9 @@ WealthLedger помогает частному инвестору понимат
 | Разобраться в системе | [Архитектура](architecture/README.md), нужная область выше, [внешние интеграции](integrations/README.md) |
 | Найти точные сведения | [Глоссарий](glossary.md), [показатели портфеля](domains/portfolio/data-reference.md), [HTTP API](architecture/http-api.md) |
 | Разобрать расхождение в суммах | [Диагностика портфеля](domains/portfolio/how-to/investigate-discrepancy.md) |
 | Проверить условия локальной работы | [Окружение и восстановление](development/local-workspace.md) |
 | Понять ошибку или старые данные | [Состояния интерфейса](architecture/cross-cutting/ui-resilience.md), [свежесть данных](architecture/cross-cutting/data-freshness.md) |
-| Найти визуальные роли и примеры | [Дизайн-система](development/design-system.md), [UI-каталог](development/ui-catalog.md) |
+| Понять визуальные роли и состояния | [Визуальные принципы](design/overview.md) |
 | Узнать причину архитектурного решения | [Журнал ADR](adr/README.md) |
 | Изменить или проверить систему | [Сопровождение](development/README.md), затем инструкции нужного репозитория |
 Практический tutorial первого инвестиционного сценария пока не подготовлен:
 он требует подключения брокера. Маршрут первого знакомства выше — чтение, не учебный запуск.
 UI-каталог содержит безопасные вымышленные примеры и поясняет границы их использования.
 ## Границы знаний
@@ -68,8 +62,8 @@ UI-каталог содержит безопасные вымышленные
 реализованную функцию; расхождение кода и требования требует разбора.
 Итоги исследований входят в ADR, когда принято значимое решение, и в тематические
 страницы, когда уточняют знания о системе. Исходные исследовательские отчёты
-в docs не хранятся. [Исторические свидетельства](development/README.md#исторические-свидетельства)
+в docs не хранятся. История изменений остаётся в Git; документация описывает
-сохраняют результаты своего времени и не заменяют текущее описание системы.
+текущее устройство системы и причины архитектурных решений.
 Правила изменения текста, диаграмм, ссылок и проверки docs-impact находятся
 в [CONTRIBUTING](CONTRIBUTING.md).
@@ -1,55 +0,0 @@
 ---
 status: accepted
 ---
 # Native OpenSpec SDD и минимальная local orchestration
 ## Статус: историческое решение
 [ADR 012](012-task-driven-development-with-scoped-context.md) отменяет обязательный
 SDD lifecycle. Native OpenSpec остаётся optional инструментом; repo gates сохраняются.
 ### Прежняя частичная замена
 [ADR 011](011-native-openspec-lifecycle-with-repository-gates.md) заменяет части
 этого решения о schema v3, custom verifiers и dispatcher. Выбор native OpenSpec,
 независимых repository gates и исходное rationale сохраняются. Ниже оставлено
 историческое описание прежней реализации; текущие принципы работы описаны
 в ADR 012. Version contract этим уточнением не меняется.
 ## Исторический контекст и решение
 На момент решения WealthLedger использовал проектную schema `wealth-ledger-sdd` version 3 с
 последовательностью `Proposal → Delta Specs → Design → Tasks → Apply`, один exact
 OpenSpec CLI contract и проверки без изменения проверяемых материалов. Это
 сохраняло единый источник правил жизненного цикла в хранилище спецификаций, выражало approval
 boundaries нативными extension points и не вводит второй workflow engine или
 monorepo control plane для четырёх независимых Git-репозиториев.
 ## Рассмотренные варианты
 - Встроенная `spec-driven` schema отклонена: она не выражает обязательный переход Specs перед Design и не задаёт Delivery Map или проектные роли артефактов.
 - Отдельный workflow engine или custom generator отклонён: он создал бы конкурирующий формат и lifecycle authority.
 - Nx, Turborepo, Bazel, Make или just отклонены для текущего масштаба: workspace не имеет общего dependency graph, build cache или CI, а репозитории уже владеют canonical gates.
 - Versioned source tree, patch-only, programmatic generator и symlink для root
  agent entrypoints отклонены для текущего масштаба: они добавляют отдельный
  projection lifecycle поверх уже достаточных schema, docs и scripts.
 ## Исторические последствия
 OpenSpec CLI закреплён exact version contract; новая stable release не включает
 auto-upgrade, а смена contract является отдельным SDD change со staged
 проверками совместимости. Локальная точка входа оставалась навигацией,
 а обязательные ограничения проверялись отдельно. Planning
 verifier до approval проверяет только детерминированную структуру: capability
 set, Delivery Map, rollback, task area и Requirement coverage. Он различает
 artifact-validation, неверный invocation и failure окружения, чтобы agent не
 переписывал planning artifact из-за сломанного вызова или prerequisite.
 Dispatcher знает четыре workspace area, но не реализует build или test logic:
 он делегирует repo-owned commands. Approval identity остаётся человеческим
 workflow constraint, потому что schema моделирует порядок артефактов, но не
 личность утвердившего. Semantic review по-прежнему не заменяется structural
 checks.
 Решение пересматривается, если OpenSpec перестанет поддерживать нужный artifact graph, появится обязательный общий CI/build graph или стоимость последовательной локальной orchestration станет существенной. В этих случаях новый ADR сравнивает native evolution с внешним engine либо monorepo platform.
@@ -1,58 +0,0 @@
 ---
 status: superseded
 ---
 # Native OpenSpec lifecycle и repository gates
 Обязательность описанной ниже процедуры заменена
 [ADR 012](012-task-driven-development-with-scoped-context.md). Текст сохраняет
 историческое решение; current policy — прямая работа по задаче.
 ## Контекст
 [ADR 010](010-native-openspec-sdd-and-local-orchestration.md) сохраняет rationale
 выбора native OpenSpec и независимых repository gates. Его описание schema v3,
 custom authority/planning verifiers и dispatcher относится к прежней реализации.
 На момент решения проектная schema `wealth-ledger-sdd`
 имела version 5 и граф `Proposal → Delta Specs → Design → Tasks → Apply`.
 Порядок работы определялся средствами OpenSpec и общими правилами проекта;
 дополнительные точки входа служили навигацией по единой процедуре.
 Версия OpenSpec CLI была зафиксирована как `1.10.0`.
 Версия schema и CLI contract — разные сведения. Фиксация версии
 не доказывает запуск прежних проверок; это решение не меняет CLI pin,
 version contract, schema или требования к tooling.
 ## Решение
 Частично заменить ADR 010 в части прежней schema version и orchestration.
 Единым хранилищем согласования оставался `wealth-ledger-specs`.
 Процедура разделяла следующие ответственности:
 - Согласование ролей, подтверждений, объёма поставки и обязательных проверок.
 - Планирование и применение изменений, структурную проверку и смысловое согласование требований.
 - Выбор и повторную сверку исходных знаний, восстановление контекста и повторное использование свидетельств.
 Native OpenSpec получает structure и contextFiles текущего artifact или Apply.
 Каждое изменяемое приложение владело своей проверкой качества. Выполнение
 процедуры не зависит от custom verifier, dispatcher, skill или session adapter;
 optional entrypoints остаются navigation, без второго workflow engine.
 ## Последствия
 Люди и автоматизированные инструменты следовали единой процедуре, а каждый
 репозиторий отвечал за собственные проверки. ADR фиксировал причину этого
 разделения ответственности. Исходные альтернативы и rationale остаются
 в ADR 010; historical archives, audits и evidence сохраняют описание своего времени.
 Structural success не подтверждает решение Change Owner, semantic compliance
 или независимый PASS. Approval bindings, полный применимый context/Design
 package, независимая Validation и отдельная Finalization сохраняются.
 Замена orchestration не ослабляет gates и не разрешает изменение незатронутых
 main-spec requirements о tooling.
 Текущие принципы сопровождения описаны в
 [engineering governance](../development/engineering-governance.md), роль
 сохранённых требований — в [OpenSpec](../development/openspec-authority-and-lifecycle.md).
 Эти материалы отражают последующее упрощение процесса, а не восстанавливают
 обязательность исторической процедуры.
@@ -1,33 +0,0 @@
 # 012. Прямая разработка с контекстом по задаче
 **Status:** Accepted; supersedes обязательный lifecycle из ADR 010/011.
 ## Context
 Обязательная цепочка OpenSpec artifacts не обеспечила соответствие исходному
 намерению: суженный change мог пройти все проверки, оставив backend и основные
 рекомендации исследований вне реализации. Владелец проекта выбрал прямую
 разработку без обязательного OpenSpec/SDD.
 ## Decision
 Задача пользователя определяет результат. Рабочий контекст выбирается по
 предмету изменения: локальные правила разработки отделены от проектных фактов,
 а тематические источники объясняют соответствующую область. Общие принципы
 и согласование контракта не дублируются в независимых описаниях.
 [Engineering governance](../development/engineering-governance.md) и
 [context discipline](../development/agent-token-efficiency.md) описывают текущую
 работу. Repo gates, trust-boundary checks, migration safety и semantic review
 сохраняются. OpenSpec используется только по явному запросу; history сохраняется.
 ## Consequences
 Обычная задача не требует planning artifacts, role handoffs, approval fingerprints
 и archive. Сложные public/security/data решения уточняются по существу до опасной
 операции. Правильность routing проверяется на задачах и counterexamples; качество
 агента оценивается по наблюдаемым outcomes, а не по числу файлов или checkboxes.
 Рекомендации исследований адаптируются к принятой архитектуре и существующим
 проверкам WealthLedger. Backend остаётся источником OpenAPI. Новые сервисы,
 общая инфраструктура и проверки не вводятся только ради организации контекста.
@@ -15,11 +15,6 @@
 Это давало частичное покрытие одного агентства без покупки доступа,
 но не рейтинг любой российской облигации и не стабильный контракт API.
 Основания выбора сохранены из исследования, а применение решения подтверждено
 backend-коммитом `235c179` (`feat: add bond details, yields and credit ratings`).
 Исходное исследование содержало также рекомендации; эта запись фиксирует
 выбранный подход, не объявляя все рекомендации реализованными.
 ## Решение
 Использовать публичный [реестр выпусков НКР](https://ratings.ru/ratings/issues/)
@@ -1,39 +1,27 @@
 # 014. Актуальная OpenAPI-схема как вход frontend
-**Статус:** принято 2026-09-13; docs, specs и frontend-инструкции приведены
+**Статус:** принято 2026-09-13.
 к решению. Настройка remote issues и branch protection выполняется отдельно.
 ## Контекст
-Frontend и backend — независимые репозитории. Знание путей и команд backend
+Frontend и backend — независимые репозитории. Зависимость frontend от путей
-в frontend связывает их внутреннее устройство. Для текущего процесса разработки
+и команд backend связывала бы их внутреннее устройство. Предоставленная
-владелец проекта принимает актуальность переданной OpenAPI-схемы как допущение;
+OpenAPI-схема служит границей между владельцем API и его потребителем.
 проверка пары revisions и дополнительное сравнение схем не требуются.
 ## Решение
-Backend остаётся источником HTTP-контракта согласно [ADR 002](002-nest-generated-openapi-contract.md).
+Backend остаётся источником HTTP-контракта согласно
 [ADR 002](002-nest-generated-openapi-contract.md).
 Frontend принимает предоставленную OpenAPI-схему как актуальную и генерирует
-из неё типы локально. Его команды не читают файлы соседнего backend checkout
+из неё типы локально, без доступа к соседнему backend checkout.
-и не запускают backend-скрипты. Подготовка и доставка схемы находятся вне frontend.
+Подготовка и доставка схемы находятся вне frontend.
 Не требуется фиксировать пару SHA frontend/backend или сравнивать frontend-схему
 с runtime OpenAPI backend. Локальная проверка соответствия generated types
 входной схеме сохраняется: она не проверяет актуальность схемы относительно backend.
 Обычные CI checks по-прежнему должны проверять текущий commit изменения.
 ## Последствия
-Задача frontend #3 ограничивается локальной генерацией из предоставленной схемы;
+Frontend зависит от публичного контракта, а не от внутреннего устройства
-экспорт backend не становится обязанностью frontend. Из frontend #2 исключается
+backend. Соответствие типов входной схеме не гарантирует её актуальность:
-требование проверки явно выбранной пары revisions. Требования безопасности
+рассинхронизацию предоставленной схемы и работающего API frontend не выявляет
-frontend #4 этим решением не меняются.
+сравнением схем. Актуальность входа остаётся принятым допущением.
 OpenAPI endpoint не является runtime-зависимостью SPA.
-Рассинхронизацию предоставленной схемы и backend отдельный gate не обнаруживает:
+Текущее взаимодействие описано в [HTTP API](../architecture/http-api.md).
 её отсутствие принято как допущение. Тесты HTTP-поведения, валидации и авторизации
 остаются нужны.
 Решение заменяет прежнее требование сравнения runtime OpenAPI с frontend
 snapshot в [OpenAPI contract flow](../development/runtime-openapi-verification.md)
 и [спецификации генерации API](../../specs/openspec/specs/api-contract-generation/spec.md).
 Связанные remote issues и настройки защиты ветки требуют отдельного обновления.
@@ -17,8 +17,5 @@
 - [007 — React Query fetch policy](007-react-query-fetch-policy.md)
 - [008 — Pino backend logging](008-pino-backend-logging.md)
 - [009 — Concurrent refresh rotation policy](009-concurrent-refresh-rotation-policy.md)
 - [010 — Native OpenSpec SDD и local orchestration](010-native-openspec-sdd-and-local-orchestration.md) — исторический; частично заменён ADR 011, обязательность SDD отменена ADR 012.
 - [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)
@@ -15,7 +15,7 @@
 | Что считается кэшем и когда прежние данные теряют право на повторное использование? | [Свежесть данных](cross-cutting/data-freshness.md) |
 | Как обрабатываются ошибки и ожидание? | [HTTP API и ошибки](http-api.md), [состояния интерфейса](cross-cutting/ui-resilience.md) |
 | Как связать ошибку с обработкой запроса? | [Наблюдаемость](http-api.md#наблюдаемость) |
-| Как устроено подтверждённое локальное окружение? | [Container](containers.md#представление-container), [локальная диагностика](../development/local-workspace.md) |
+| Как устроено подтверждённое локальное окружение? | [Container](containers.md#представление-container), [качество и ограничения](containers.md#качество-и-ограничения) |
 | Что означают предметные термины? | [Глоссарий](../glossary.md) |
 Эта карта покрывает вопросы архитектуры там, где о них есть подтверждённое
@@ -104,6 +104,20 @@ credentials не являются сохраняемым представлен
 [модель свежести](cross-cutting/data-freshness.md) отделяет это от хранения
 учётных данных.
 ## Сохранение и восстановление данных
 Резервная копия SQLite должна быть согласованной: для работающей базы
 используется SQLite backup API с учётом WAL. Несогласованное копирование
 файлов базы и WAL не сохраняет целостный снимок. Восстановление проверяется
 на отдельной копии. Ключ шифрования подключения хранится отдельно от базы;
 его потеря делает сохранённый T-Bank token нечитаемым.
 Откат приложения требует совместимости предыдущей версии с сохранённой
 схемой. Расширенная банковскими таблицами схема сохраняет пользователей,
 сессии и подключения. Возврат старого backup поверх новой истории удалил бы
 введённые банковские операции; откат приложения не равнозначен откату данных.
 Совместимость произвольных будущих версий этим не гарантируется.
 ## Стратегия решения и её основания
 Локальная база и Prisma дают типизированный доступ к локальному состоянию
@@ -137,8 +151,10 @@ access token и вращаемый refresh token. [Политика query-кэш
 и [HTTP API](http-api.md#error-contract).
 Подтверждённая топология — локальная SPA и локальный API с файлом SQLite.
-Origin браузера, адрес API и cookie policy должны быть согласованы; условия
+Origin браузера, адрес API и cookie policy должны быть согласованы.
-и диагностика описаны в [локальном окружении](../development/local-workspace.md).
+`localhost` и `127.0.0.1` задают разные browser-границы для cookie и CORS.
 Локальный HTTP поддерживается в development-режиме backend; в остальных
 режимах refresh-cookie имеет Secure flag и требует защищённого соединения.
 Наличие локального запуска не задаёт production-топологию или гарантии SLA.
 Кэши и лимитер T-Bank действуют на экземпляр backend. Ротация ключа шифрования
@@ -4,8 +4,10 @@
 Backend генерирует OpenAPI из собственного публичного API. Frontend использует
 предоставленный OpenAPI snapshot как актуальный вход и локально генерирует
-типизированный клиент. Направление описано в
+типизированный клиент. Backend владеет контрактом, а подготовка и доставка
-[OpenAPI contract flow](../development/runtime-openapi-verification.md).
+схемы находятся вне frontend. Это разделение принято в
 [ADR 002](../adr/002-nest-generated-openapi-contract.md) и
 [ADR 014](../adr/014-trusted-openapi-input.md).
 API имеет prefix `/api/v1`; Swagger публикуется для локальной разработки по
 environment policy, а не используется frontend в runtime.
@@ -54,15 +56,6 @@ T-Bank token failure и временная недоступность имеют
 [Connection API](../integrations/tbank.md#состояние-и-ошибки). Raw upstream/Prisma errors
 и secrets не передаются frontend.
 ## Граница доказательства
 OpenAPI snapshot задаёт frontend transport types, но сам по себе не доказывает
 результат каждого запроса. Безопасная обработка неожиданной ошибки проверяется
 отдельно. Валидация, доступ, статусы и cookie требуют проверки полного
 HTTP-потока; атомарность хранения — проверки с изолированной реальной базой.
 Известное ограничение сквозных проверок описано в
 [проверке backend](../development/verification.md).
 ## Наблюдаемость
 Backend пишет структурированные JSON-события в stdout через Pino. Обработка
@@ -0,0 +1,47 @@
 # Визуальные принципы WealthLedger
 Интерфейс использует общую визуальную основу на Mantine: цветовые роли,
 типографику, интервалы, радиусы, тени и адаптивные размеры.
 Поддерживается светлая схема; тёмная тема не заявлена.
 ## Семантические роли
 | Роль | Цветовая основа | Применение |
 | --- | --- | --- |
 | canvas | gray.2 | Фон приложения |
 | surface | white | Поверхности и формы |
 | subtle | gray.0 | Приглушённая поверхность |
 | text | dark.7 | Основной текст |
 | muted | gray.6 | Вторичный текст |
 | border | gray.3 | Граница поверхности |
 | primary | blue filled | Основное действие и активная навигация |
 | info | blue.6 | Информация |
 | positive | green.6 | Положительный результат с текстом или знаком |
 | negative | red.6 | Ошибка или отрицательный результат с текстом или знаком |
 | warning | yellow.6 | Предупреждение; не мелкий текст на белом |
 Цвет не заменяет подпись или знак. Палитра не гарантирует доступный контраст
 произвольного сочетания текста и фона. Дополнительные grape/orange и отдельные
 оформления карточек сохраняют предметный смысл соответствующего экрана;
 они не образуют универсальную финансовую классификацию всей системы.
 ## Состояния и действия
 Основное, вторичное и вспомогательное действия различаются по визуальному
 приоритету. Выполнение действия и его недоступность — разные состояния.
 Пустой результат и ошибка содержат заголовок, пояснение и действие, когда
 оно предусмотрено сценарием. Ошибка объявляется вспомогательным технологиям,
 а кнопка имеет доступное название.
 Первая загрузка показывает структуру ожидаемого содержимого, без вымышленных
 сумм; область обозначается как занятая, декоративные фигуры не получают фокус.
 Фоновое обновление сохраняет доступные данные с локальным индикатором.
 Подробные правила — в [состояниях интерфейса](../architecture/cross-cutting/ui-resilience.md).
 Финансовые значения сохраняют валюту, знак и различие между нулём и
 неизвестной суммой. Предметные представления раскрыты в
 [портфеле](../domains/portfolio/overview.md), [операциях](../domains/operations/overview.md)
 и [банковских картах](../domains/cards/overview.md).
 Согласованная общая основа описана в
 [спецификации дизайн-системы](../../specs/openspec/specs/frontend-design-system/spec.md).
@@ -1,21 +0,0 @@
 # Сопровождение системы
 Здесь описаны локальное окружение, согласованность компонентов, границы
 проверки и поддержание проектных знаний. Команды разработки и coding conventions
 принадлежат [frontend](../../frontend/AGENTS.md) и [backend](../../backend/AGENTS.md).
 - [Локальное окружение](local-workspace.md) — предпосылки работы, первый пользовательский сценарий и диагностика.
 - [Проверки системы](verification.md) — что доказывают проверки интерфейса, API и хранения данных, известные ограничения.
 - [HTTP contract](runtime-openapi-verification.md) — направление генерации OpenAPI и локальная проверка snapshot/types.
 - [Дизайн-система](design-system.md) / [UI-каталог](ui-catalog.md) — визуальные роли, реальные состояния и ограничения примеров.
 - [Принципы изменений](engineering-governance.md) — связность системы, риск и доказательства результата.
 - [Ведение документации](../CONTRIBUTING.md) — самостоятельные объяснения и их обновление вместе с системой.
 - [Контекст знаний](agent-token-efficiency.md) / [проверочные вопросы](agent-context-evals.md) — поиск ответа и обнаружение пробелов документации.
 - [OpenSpec](openspec-authority-and-lifecycle.md) — роль сохранённых требований и статус прежнего процесса.
 ## Исторические свидетельства
 [Remediation registry](audit-remediation.md) и [Completion Evidence](completion-evidence.md)
 сохраняют статусы, исходные адреса и результаты прежних проверок.
 Эти материалы не входят в самостоятельное описание текущей системы; их внутренние ссылки
 могут требовать архивного окружения и не являются условием чтения документации.
@@ -1,36 +0,0 @@
 # Проверка полноты проектных знаний
 Эти вопросы помогают оценить, объясняет ли документация систему без доступа
 к исходникам. Для каждого вопроса важны правильный ответ, существенное
 ограничение и отсутствие ошибочного вывода из похожего сценария.
 ## Cases
 | Вопрос | Объяснение | Существенная граница |
 | --- | --- | --- |
 | Кто подтверждает доступ к брокерскому счёту? | [Обзор](../overview.md#как-связаны-представления) | Сессия подтверждает пользователя, но идентификатор счёта не доказывает доступ |
 | Как меняются финансовые данные при замене token? | [Подключение](../integrations/tbank.md#граница-финансового-кэша) | Данные прежнего поколения не становятся сохранённым снимком нового подключения |
 | Что происходит при конкурентном refresh? | [Authentication](../domains/authentication/overview.md), [ADR 009](../adr/009-concurrent-refresh-rotation-policy.md) | Один победитель; заменённый token не отзывает его сессию сам по себе |
 | Как восстанавливается интерфейс после ошибки обновления? | [UI resilience](../architecture/cross-cutting/ui-resilience.md) | Фоновая ошибка отличается от первой загрузки и смены пользователя |
 | Чем будущая выплата отличается от дохода? | [События](../domains/income/upcoming-events.md), [доходы](../domains/income/overview.md) | Прогноз не подтверждает личное зачисление |
 | Можно ли складывать разные валюты или заменить неизвестное нулём? | [Money](../glossary.md#money) | Точность, валюта и отсутствие значения сохраняются отдельно |
 | Откуда рейтинг и доходность облигации? | [Bond detail](../domains/instruments/bonds.md) | Рейтинг эмитента не заменяет рейтинг выпуска; рыночная доходность не равна личному результату |
 | Доказывает ли OpenAPI правильность ошибки запроса? | [HTTP API](../architecture/http-api.md#error-contract) | Равенство схем не доказывает полный HTTP-поток |
 | Что гарантирует проверка хранения данных? | [Backend](verification.md#api-и-хранение-данных) | Проверка с подставными ответами не доказывает атомарность реальной базы |
 | Как ограничиваются обращения к внешнему сервису? | [T-Bank](../integrations/tbank.md#конфигурация-и-ограничения) | Повторы, очередь и лимит ограничены; TLS остаётся включённым |
 | Защищает ли фильтрация логов любое сообщение? | [ADR 008](../adr/008-pino-backend-logging.md) | Секрет в свободном тексте требует отдельной проверки |
 | Есть ли восстановление пароля по письму? | [Ограничения auth](../domains/authentication/overview.md#ограничения) | Пример будущего сценария не является поставленной возможностью |
 ## Что измерять
 Полезное объяснение позволяет найти ответ, назвать ограничение и связать его
 с другими сценариями. Оцениваются неверные выводы о доступе, деньгах, полноте
 данных и источниках, а также число уточнений до правильного понимания.
 Время поиска и объём чтения имеют смысл только вместе с точностью ответа.
 ## Изменение правил
 Если знание есть, но его трудно найти, уточняется навигация. Если документ
 найден, но не объясняет различие понятий или ограничение, уточняется объяснение.
 При конфликте источников сохраняется отметка о ручном решении; догадка не
 подменяет установленный факт.
@@ -1,42 +0,0 @@
 # Контекст знаний о системе
 Цель навигации — дать читателю знания, необходимые для конкретного вопроса,
 без предварительного чтения всей документации. Самостоятельное объяснение
 связывает понятия, сценарии и ограничения, а не воспроизводит устройство кода.
 ## Routing context
 [Тематическая карта](../README.md#предметные-области) направляет к нужному предмету:
 аутентификация связана с безопасностью и сессиями, денежный показатель —
 с его происхождением и валютой, ошибка интерфейса — с восстановлением данных.
 Вопрос о внешнем виде не требует автоматически изучать хранение данных.
 При обнаружении новой существенной границы расширяется и нужный контекст.
 ## Источники и конфликты
 Публичный HTTP-контракт описывается OpenAPI backend; документация объясняет
 систему, ADR сохраняют причины решений, исследования предлагают варианты.
 Существующее поведение не отменяет согласованное требование, а рекомендация
 из исследования не становится принятым решением автоматически.
 При расхождении возможны устаревшее объяснение, дефект реализации или
 незавершённое изменение. Неустановленный смысл, особенно в безопасности,
 данных и публичном контракте, явно отмечается для ручного решения.
 Карта ответственности за знания — [ведение документации](../CONTRIBUTING.md).
 ## Recovery и handoff
 Продолжение работы опирается на ожидаемый результат, выполненные изменения,
 оставшиеся вопросы, результаты проверок и ограничения. Дублирование требований
 в нескольких независимых пересказах создаёт риск расхождения. Исторические
 проверки сохраняют своё значение только для того состояния системы, в котором
 они выполнялись; секреты не являются допустимым содержимым свидетельств.
 ## Проверка эффективности
 [Проверочные вопросы](agent-context-evals.md) показывают, можно ли получить
 правильную модель системы и отличить близкие понятия. Качество оценивается по
 верности ответа, найденным ограничениям и необходимости дополнительных уточнений.
 Число документов, их краткость или успешная проверка Markdown сами по себе
 не доказывают полезность знания. Сравнение результатов требует одинаковых
 вопросов и сопоставимых условий.
@@ -1,579 +0,0 @@
 # Audit remediation registry
 ## Назначение
 Это единый versioned реестр текущего состояния remediation для findings из всех [технических audit snapshots](../audits/README.md). Каждый аудит — неизменяемый source of facts; этот документ хранит только текущий статус, путь продолжения и evidence последующих решений, не копируя полный текст finding.
 ## Правила работы
 - Каждая audit-derived запись имеет один статус: `planned`, `active`, `done`, `deferred` или `accepted`.
 - Каждое уникальное external claim дополнительно имеет независимый triage
  disposition: `confirmed`, `already-covered`, `rejected` или `deferred`.
  Повтор одного underlying claim в нескольких reports получает один Audit ID со
  ссылкой на каждый source. Disposition не является remediation status:
  `confirmed` ещё может быть active, а `rejected` — accepted как проверенное
  решение ничего не внедрять.
 - Одновременно допускается не более одного `active` remediation change. Пока он существует, продолжается только он. При наличии `planned` ровно одна запись отмечается следующей рекомендуемой задачей, но она не запускается параллельно active change.
 - Новая запись `done` требует даты и ссылки на фактически выполненную работу и её проверки (например, commit/PR или существующее evidence). OpenSpec archive не является обязательным; не создавайте отдельные artifacts только ради статуса.
 - `deferred` и `accepted` требуют даты, rationale и review trigger либо ссылки на явное решение владельца.
 - При смене статуса обновляется только этот реестр; versioned audit snapshot не редактируется.
 Текущая проверка результата определена в
 [engineering governance](engineering-governance.md#проверка-результата).
 Исторические записи
 ниже, прежние ссылки на `completion-evidence.md` в docs и датированные audit
 snapshots сохраняются без переноса или переписывания задним числом.
 Датированные dispositions ниже описывают проверки и решения своего времени;
 они не восстанавливают прежние SDD prerequisites. Live ссылки ведут к текущим
 owners, а историческое evidence сохраняется по исходным адресам.
 ## Текущее состояние workflow
 - Bootstrap change: [`2026-08-23-establish-audit-remediation-workflow`](../../specs/openspec/changes/archive/2026-08-23-establish-audit-remediation-workflow/) — `archived`; это process foundation и не закрывает ни одного Audit ID.
 - Последний завершённый audit remediation change: [`2026-09-06-complete-frontend-audit-remediation`](../../specs/openspec/changes/archive/2026-09-06-complete-frontend-audit-remediation/) — `archived`; FE26-02–FE26-18 закрыты, FE26-01 сохраняет прежнее evidence.
 - Единственный active change: отсутствует.
 ## Текущая задача
 Frontend audit remediation завершена; [Completion Evidence][FE26-E] содержит
 archive, delivery commits, verification и независимый verdict. Следующий
 remediation change создаётся после выбора владельцем продолжения.
 ## Следующая рекомендуемая задача
 `assess-auth-platform-options` для AUD24-02. Change применит Solution Assessment
 к существующей реализации и зрелым auth platforms, включая Better Auth, и не
 предрешает миграцию.
 ## Реестр findings
 ### Frontend audits: август 2026
 Источник: [три неизменяемых snapshots](../audits/2026-08-frontend-repository-audits/README.md).
 `G` — общий audit от 31 августа, `A28` — audit от 28 августа,
 `S` — structural audit от 31 августа. Все 22 source findings сопоставлены
 18 underlying claims ниже; одинаковые F IDs без source prefix неоднозначны.
 Дата сопоставления и закрытия FE26-02–FE26-18: 06.09.2026.
 [Completion Evidence][FE26-E] содержит общий archive path, delivery commits
 всех четырёх областей, точные commands/results и независимый PASS.
 `already-covered` обозначает прежнюю реализацию, подтверждённую текущей
 проверкой, без фиктивной повторной implementation task.
 Реализация прежних исправлений находится во frontend `c97f62b` и backend
 `55b100d`; эти идентификаторы не доказывают исторические approvals или gates.
 | Audit ID | Нормализованный claim | Sources | Disposition | Remediation status | Evidence / текущее состояние |
 | --- | --- | --- | --- | --- | --- |
 | FE26-01 | Общая граница финансового кэша при смене T-Bank connection. | [FE-A28] F1; [FE-S] F-01 | already-covered | done | 01.09.2026; [archive](../../specs/openspec/changes/archive/2026-09-01-harden-tbank-connection-cache-boundary/), delivery commits, gates и independent review — [существующее Completion Evidence](completion-evidence.md#2026-09-01-harden-tbank-connection-cache-boundary). |
 | FE26-02 | Проверять соответствие generated types OpenAPI snapshot. | [FE-A28] F2; [FE-G] F-01 | already-covered | done | 06.09.2026; [FE26-E]. [check-openapi](../../frontend/scripts/check-openapi.mjs) включён в [verify](../../frontend/package.json); snapshot/types проверяются offline. Pre-commit состав честно описан в conventions. |
 | FE26-03 | Events должен соблюдать принятую VM/view границу. | [FE-A28] F3 | confirmed | done | 06.09.2026; [FE26-E]. [Events VM](../../frontend/src/pages/account-events/ui/AccountEventsPage.vm.ts) владеет route/query/state/retry; [container](../../frontend/src/pages/account-events/ui/AccountEventsPage.tsx) использует прежние views. Остальные named pages уже разделены; см. FE26-13. |
 | FE26-04 | Покрыть успешный public login journey. | [FE-G] F-02 | already-covered | done | 06.09.2026; [FE26-E]. [AppRoutes tests](../../frontend/src/app/routes/AppRoutes.test.tsx): форма, нормализованные credentials, реальный AuthProvider/MSW и protected landing. |
 | FE26-05 | Безопасно отклонять невозможные календарные даты. | [FE-G] F-03 | already-covered | done | 06.09.2026; [FE26-E]. [Income VM](../../frontend/src/pages/account-income/ui/AccountIncomePage.vm.ts) проверяет finite date до ISO conversion; [regression tests](../../frontend/src/pages/account-income/ui/AccountIncomePage.test.tsx) покрывают invalid date и leap year. |
 | FE26-06 | Включить type-only dependencies в public API guardrail. | [FE-G] F-04 | already-covered | done | 06.09.2026; [FE26-E]. [dependency-cruiser](../../frontend/dependency-cruiser.cjs) включает tsPreCompilationDeps; [shared API](../../frontend/src/shared/api/index.ts) экспортирует paths. |
 | FE26-07 | Дать общим display/API primitives нейтральных владельцев. | [FE-G] F-05; [FE-S] F-07 | already-covered | done | 06.09.2026; [FE26-E]. [shared display](../../frontend/src/shared/lib/display.ts) владеет Money/date/logo; [apiErrorCode](../../frontend/src/shared/api/problem-details.ts) объединяет transport extraction. S F-07 расширяет тот же ownership claim API helper; повторной реализации нет. |
 | FE26-08 | Синхронизировать entrypoint docs с фактическими gates. | [FE-G] F-06 | already-covered | done | 06.09.2026; [FE26-E]. [Frontend README](../../frontend/README.md), [conventions](../../frontend/.ai/conventions/frontend-ui.md) и [workflow](frontend-workflow.md) описывают существующие команды, не обещая удалённые runtime/hygiene checks. |
 | FE26-09 | Убрать механическое обязательное дробление каждого component. | [FE-G] F-07 | already-covered | done | 06.09.2026; [FE26-E]. [UI pattern](../../frontend/.ai/conventions/frontend-ui.md) сохраняет semantic ownership и допускает tightly-coupled renderers; это guidance, а не line-count gate. Конкретное разделение крупных modules учтено отдельно FE26-13. |
 | FE26-10 | Объединить protected query policy и endpoint query identity ownership. | [FE-G] F-08; [FE-S] F-05 | already-covered | done | 06.09.2026; [FE26-E]. [App defaults](../../frontend/src/app/ui/App.tsx), [T-Bank VM](../../frontend/src/features/tbank-connection/ui/TbankConnectionSection.vm.ts) и entity-owned options operations/portfolio; status использует общий authenticated query seam. |
 | FE26-11 | Централизовать test cleanup и auth reset. | [FE-S] F-02 | already-covered | done | 06.09.2026; [FE26-E]. [Test setup](../../frontend/src/test/setup.ts): RTL cleanup, auth reset, MSW handler reset в общем afterEach. |
 | FE26-12 | Убрать повтор server identity из Income view/model. | [FE-S] F-03 | confirmed | done | 06.09.2026; [FE26-E]. [Backend income service](../../backend/src/modules/investments/income/income-analytics.service.ts) передаёт instrumentKey; [Income VM](../../frontend/src/pages/account-income/ui/AccountIncomePage.vm.ts) проверяет и группирует готовую связь, не вычисляя identity. |
 | FE26-13 | Выделить самостоятельные ответственности семи крупных TSX modules. | [FE-S] F-04 | already-covered | done | 06.09.2026; [FE26-E]. Income/Events/Accounts/Account state views, [route fallback](../../frontend/src/app/routes/RouteFallback.tsx), [guards](../../frontend/src/app/routes/RouteGuards.tsx), breadcrumbs и T-Bank loaded section выделены во frontend `c97f62b`. |
 | FE26-14 | Устранить повтор test client policy и нестабильный cache lifetime. | [FE-S] F-06 | confirmed | done | 06.09.2026; [FE26-E]. [Test query factory](../../frontend/src/test/query.tsx) используется оставшимися auth/T-Bank harnesses; [auth test](../../frontend/src/features/auth/model/auth.test.tsx) проверяет сохранение client и seeded cache при rerender. |
 | FE26-15 | Перенести компонентные стили из global CSS к владельцам. | [FE-S] F-08 | already-covered | done | 06.09.2026; [FE26-E]. [Global styles](../../frontend/src/shared/theme/styles.css) содержат базовые правила; AppShell, breadcrumbs и auth используют CSS Modules, StateView — Mantine props. |
 | FE26-16 | Исправить source connectedAt contract вместо String coercion. | [FE-S] F-09 | already-covered | done | 06.09.2026; [FE26-E]. [Backend DTO](../../backend/src/modules/investments/tbank-connection/tbank-connection.dto.ts) задаёт nullable date-time string; [frontend consumer](../../frontend/src/features/tbank-connection/ui/TbankConnectionSectionLoaded.tsx) не скрывает неверный transport type через String. |
 | FE26-17 | Перенести auth validation и payment invariants из JSX к model owners. | [FE-S] F-10 | already-covered | done | 06.09.2026; [FE26-E]. [Auth validation](../../frontend/src/features/auth/model/validation.ts), [ledger display](../../frontend/src/entities/broker-operation/model/display.ts) владеют соответствующими правилами. |
 | FE26-18 | Удалить redundant position modes и test-only proxy exports. | [FE-S] F-11 | already-covered | done | 06.09.2026; [FE26-E]. [PositionCard](../../frontend/src/pages/account/ui/components/PositionCard.view.tsx) выводит mode из kind; [StateView](../../frontend/src/shared/ui/StateView.tsx) не экспортирует Mantine Button; page barrels сохраняют product surface. |
 [FE26-E]: completion-evidence.md#2026-09-06-complete-frontend-audit-remediation
 [FE-G]: ../audits/2026-08-frontend-repository-audits/frontend-repository-audit.md
 [FE-A28]: ../audits/2026-08-frontend-repository-audits/frontend-repository-audit-2026-08-28.md
 [FE-S]: ../audits/2026-08-frontend-repository-audits/frontend-structural-maintainability-audit.md
 ### Повторный multi-source review WealthLedger SDD v2 26.08.2026
 Шесть исходных reports находятся в [immutable snapshot set](../audits/2026-08-26-wealth-ledger-sdd-v2-review/README.md).
 Сокращения: [D2] — DeepSeek, [G2] — Gemini, [Gr2] — Grok, [K2] — Kimi,
 [Q2] — Qwen, [Z2] — Z.AI. Оценки и предложенные patches не принимаются без
 сопоставления с воспроизводимым project invariant.
 | Audit ID | Нормализованный claim | Sources | Disposition | Remediation status | Evidence, rationale или review trigger |
 | --- | --- | --- | --- | --- | --- |
 | SDD26R2-01 | Сократить и визуально приоритизировать instructions, сохранив самодостаточные critical rules и единый основной язык. | [D2], [Gr2], [Z2] | confirmed | done | 2026-08-26; [archive](../../specs/openspec/changes/archive/2026-08-26-harden-openspec-sdd-agent-resilience/); specs `8462a3ba75d6dda491b9221699357c58d8f8e3cc`, `779a1e1305f8c209a4f98fae7f87718e48d61b37`; docs `d80e2e32b2ebadcd93a53105e1ac337fe2c1f4f6`; commands/results: [Completion Evidence](completion-evidence.md#2026-08-26-harden-openspec-sdd-agent-resilience). |
 | SDD26R2-02 | Delta Spec template не должен предрешать `ADDED` и должен показывать все допустимые operations без активных пустых sections. | [K2] | confirmed | done | 2026-08-26; тот же [archive](../../specs/openspec/changes/archive/2026-08-26-harden-openspec-sdd-agent-resilience/), delivery commits и [Completion Evidence](completion-evidence.md#2026-08-26-harden-openspec-sdd-agent-resilience). |
 | SDD26R2-03 | Planning verifier должен отличать defect артефакта от неверного invocation и failure окружения. | [Z2], [Q2] | confirmed | done | 2026-08-26; тот же [archive](../../specs/openspec/changes/archive/2026-08-26-harden-openspec-sdd-agent-resilience/), delivery commits и [Completion Evidence](completion-evidence.md#2026-08-26-harden-openspec-sdd-agent-resilience). Retry counter отклонён владельцем как лишнее состояние. |
 | SDD26R2-04 | Apply должен читать точные native `contextFiles` и локальные правила affected repositories. | [K2] | confirmed | done | 2026-08-26; тот же [archive](../../specs/openspec/changes/archive/2026-08-26-harden-openspec-sdd-agent-resilience/), delivery commits и [Completion Evidence](completion-evidence.md#2026-08-26-harden-openspec-sdd-agent-resilience); отдельный context mapping не введён. |
 | SDD26R2-05 | `N/A` rationale должно объяснять техническую необходимость, но его смысл нельзя надёжно валидировать простым text heuristic. | [Q2] | confirmed | done | 2026-08-26; тот же [archive](../../specs/openspec/changes/archive/2026-08-26-harden-openspec-sdd-agent-resilience/), delivery commits и [Completion Evidence](completion-evidence.md#2026-08-26-harden-openspec-sdd-agent-resilience); semantic sufficiency оставлена owner/reviewer. |
 | SDD26R2-06 | Граница mechanical Apply fix должна явно исключать Requirement, Scenario, architecture и Verification changes. | [Q2], [Z2] | confirmed | done | 2026-08-26; тот же [archive](../../specs/openspec/changes/archive/2026-08-26-harden-openspec-sdd-agent-resilience/), delivery commits и [Completion Evidence](completion-evidence.md#2026-08-26-harden-openspec-sdd-agent-resilience). |
 | SDD26R2-07 | Exact Requirement heading в `Covers` нужно копировать дословно и проверять детерминированно. | [Z2] | already-covered | accepted | 2026-08-26; SDD26-12 уже требует exact heading, а planning verifier отклоняет неизвестную reference и uncovered Requirement. Review trigger: удаление или ослабление exact-reference check. |
 | SDD26R2-08 | Добавить `Target Repositories` в Proposal или расширить owner area произвольными repository paths. | [G2], [Gr2] | rejected | accepted | 2026-08-26; Proposal сохраняет intent без implementation topology; фиксированная Delivery Map отражает фактические четыре repos. Пересмотреть только при добавлении новой delivery area в workspace. |
 | SDD26R2-09 | Хранить machine-readable approval markers внутри versioned artifacts. | [Gr2], [K2] | rejected | accepted | 2026-08-26; approval identity принадлежит разговору с Change Owner. Marker дублировал бы external state и мог бы ложно выглядеть действующим после upstream change. Review trigger: воспроизводимый случай ложного approval после потери conversation state. |
 | SDD26R2-10 | Добавить отдельные verify/archive/DoD artifacts или phase. | [Gr2], [K2] | already-covered | accepted | 2026-08-26; SDD26-11 уже закрыт dispatcher, semantic verification, independent review, hard archive blockers и post-archive Completion Evidence без второго workflow artifact. Review trigger: доказанный terminal gap, который эти gates не выражают. |
 | SDD26R2-11 | Ослабить последовательность Specs → Design для exploratory feasibility. | [Gr2] | rejected | accepted | 2026-08-26; production change сохраняет утверждённый behavior до architecture. Throwaway feasibility work допустима вне Apply, но не становится versioned parallel plan. Review trigger: повторяемый change, где безопасная feasibility work блокируется текущим graph. |
 | SDD26R2-12 | Вынести Solution Assessment в отдельный artifact. | [Gr2] | rejected | accepted | 2026-08-26; conditional section остаётся в Design, где сравнение вариантов непосредственно обосновывает architecture; отдельный artifact усложнил бы graph без нового invariant. Review trigger: появление independently reusable assessment с отдельным approval owner. |
 | SDD26R2-13 | Требовать отдельную workspace-task для semantic review каждого change. | [Gr2] | already-covered | accepted | 2026-08-26; terminal semantic verification и independent read-only review обязательны; workspace task создаётся в Tasks для orchestration, когда она нужна delivery plan. Review trigger: semantic review, пропущенный из-за отсутствия task-level representation. |
 | SDD26R2-14 | Добавить Success Metrics в Proposal. | [Gr2] | rejected | accepted | 2026-08-26; observable acceptance принадлежит Requirements и Scenarios. Универсальные metrics в intent artifact создавали бы неподтверждённые цели без измеримого project need. Review trigger: утверждённая product metric, которую нельзя выразить Requirements/Scenarios. |
 | SDD26R2-15 | Вести schema changelog рядом с version field. | [Gr2] | rejected | accepted | 2026-08-26; versioned Git history, OpenSpec change и archive уже фиксируют rationale и diff. Второй changelog не добавляет authority. Review trigger: наблюдаемая невозможность восстановить schema migration из canonical history. |
 | SDD26R2-16 | Добавить CI/CD validation. | [D2] | deferred | deferred | 2026-08-26; текущий contract сознательно использует canonical local gates под Node 22. Review trigger: появление project CI. |
 | SDD26R2-17 | Добавить dependencies между changes, sizing задач и commit convention. | [K2] | already-covered | accepted | 2026-08-26; dependencies остаются deferred в SDD26-15 до реального conflict; sizing отклонён в SDD26-16, commit convention — в SDD26-19. Review triggers наследуются из этих записей; повторный report не даёт нового evidence. |
 | SDD26R2-18 | Exact schema version и criteria Solution Assessment отсутствуют или недостаточны. | [D2] | already-covered | accepted | 2026-08-26; `.cli-version`, schema version, controlled upgrade contract и explicit assessment trigger areas уже закреплены schema/governance. Review trigger: assessment, для которого текущие trigger areas не дают однозначного решения. |
 [D2]: ../audits/2026-08-26-wealth-ledger-sdd-v2-review/deepseek-audit.md
 [G2]: ../audits/2026-08-26-wealth-ledger-sdd-v2-review/gemini-audit.md
 [Gr2]: ../audits/2026-08-26-wealth-ledger-sdd-v2-review/grok-audit.md
 [K2]: ../audits/2026-08-26-wealth-ledger-sdd-v2-review/kimi-audit.md
 [Q2]: ../audits/2026-08-26-wealth-ledger-sdd-v2-review/qwen-audit.md
 [Z2]: ../audits/2026-08-26-wealth-ledger-sdd-v2-review/zai-audit.md
 ### Multi-source assessment WealthLedger SDD 26.08.2026
 Raw external reports и checksums находятся в
 [immutable snapshot set](../audits/2026-08-26-wealth-ledger-sdd/README.md).
 Сокращения источников: [D] — DeepSeek, [G] — Gemini, [K] — Kimi, [Q] — Qwen,
 [Z] — Z.AI. Ни одна внешняя рекомендация сама по себе не является project
 authority.
 | Audit ID | Нормализованный claim | Sources | Disposition | Remediation status | Evidence, rationale или review trigger |
 | --- | --- | --- | --- | --- | --- |
 | SDD26-01 | Снизить instruction bloat и устранить конкурирующих владельцев общих правил. | [D], [G], [Q], [Z] | confirmed | done | 2026-08-26; [`2026-08-26-harden-openspec-sdd-quality`](../../specs/openspec/changes/archive/2026-08-26-harden-openspec-sdd-quality/): schema v2 владеет semantics, templates — shape, config — только facts/language, scripts — hard invariants; отдельный `_rules.md` не вводится. |
 | SDD26-02 | Проверять planning format машинно до approval и автоматически исправлять технические ошибки. | [D], [Z] | confirmed | done | 2026-08-26; stage-aware non-mutating verifier, controlled-invalid fixtures и format-only retry path поставлены в [`2026-08-26-harden-openspec-sdd-quality`](../../specs/openspec/changes/archive/2026-08-26-harden-openspec-sdd-quality/). |
 | SDD26-03 | Каждая task должна иметь однозначную delivery area; multi-repo implementation нужно разделять. | [D], [G], [Z] | confirmed | done | 2026-08-26; schema v2 использует `[frontend\|backend\|specs\|docs\|workspace]`; planning verifier отклоняет owner из `N/A` area. |
 | SDD26-04 | Добавить `Target Repositories` уже в Proposal. | [G] | rejected | accepted | 2026-08-26; Proposal остаётся owner-readable intent без implementation topology. Полный scope repositories определяется позже через обязательную Design Delivery Map. |
 | SDD26-05 | Явно координировать порядок и совместимость multi-repository delivery. | [D], [G] | already-covered | accepted | 2026-08-26; Delivery Map, Contract Gate Decision, Migration Plan и workspace dispatcher уже задают owners, порядок, совместимость API и canonical gates. |
 | SDD26-06 | Формализовать trigger для Solution Assessment. | [D] | already-covered | accepted | 2026-08-26; [engineering governance](engineering-governance.md#dependencies) и schema перечисляют auth, security, storage, integrations, observability, caching, concurrency и shared tooling. |
 | SDD26-07 | Не допускать Design/Apply по неутверждённым artifacts. | [D], [K], [Z] | already-covered | accepted | 2026-08-26; human approval хранится в разговоре, one-artifact entrypoints останавливаются, downstream approvals каскадно инвалидируются. Фиктивный `approval.md` или status field не создаётся. |
 | SDD26-08 | Разрешить partial/diff `MODIFIED` вместо полного requirement block. | [D] | rejected | accepted | 2026-08-26; native OpenSpec archive semantics требуют полного `MODIFIED`; собственный merge format создал бы второй transformation engine и риск потери scenarios. |
 | SDD26-09 | Дать компактные примеры сложных delta operations. | [D], [K] | confirmed | done | 2026-08-26; schema v2 добавляет `MODIFIED`, `REMOVED` и `RENAMED` examples, сохраняя minimal ADDED-first template. |
 | SDD26-10 | Генерировать в `spec.md` placeholders всех delta sections. | [K] | rejected | accepted | 2026-08-26; пустые sections повышают шум и риск неверной операции. Complex forms принадлежат instructions/examples, а template остаётся минимальным. |
 | SDD26-11 | Явно определить DoD, verification и archive после Apply. | [D], [K], [Q] | already-covered | accepted | 2026-08-26; [engineering governance](engineering-governance.md#проверка-результата), workspace dispatcher, semantic verification, independent review и hard archive blockers уже образуют terminal protocol. Completion Evidence создаётся после факта, не в Tasks. |
 | SDD26-12 | Связать каждую task с точными Delta Requirements и отклонять uncovered requirements. | [D], [K] | confirmed | done | 2026-08-26; schema v2 использует native identity `capability path — exact Requirement heading`; planning verifier проверяет ссылки и полное покрытие без собственного ID namespace. |
 | SDD26-13 | Добавить Fast Track или сокращённую вторую schema для мелких fixes. | [G] | rejected | accepted | 2026-08-26; один lifecycle сохраняет предсказуемые approvals и archive blockers. Пропорциональность обеспечивают `skip_specs`, conditional assessment/rollback и узкие tasks. |
 | SDD26-14 | Ограничивать agent context через tool-specific `.aiignore` и список repos из Proposal. | [G] | rejected | accepted | 2026-08-26; это не portable OpenSpec invariant. Context ограничивается Delivery Map, task owner и targeted reads; dependencies/build outputs уже исключаются локальными tool/repository rules. Пересмотреть при наблюдаемом context exhaustion. |
 | SDD26-15 | Ввести общий `blocked_by`/`blocks` graph между changes. | [K] | deferred | deferred | Review trigger: первый реальный случай двух одновременно необходимых changes с доказанной ordering dependency, которую нельзя выразить текущим single-active-remediation rule. |
 | SDD26-16 | Добавить priority и sizing в Tasks. | [K] | rejected | accepted | 2026-08-26; Tasks уже dependency-ordered и ограничены одной рабочей сессией. Оценочные points не защищают observable invariant и создают неподтверждённую точность. |
 | SDD26-17 | Для труднообратимых changes нужен проверяемый rollback contract. | [K] | confirmed | done | 2026-08-26; Design template и planning verifier требуют trigger/actions/data safety/verification для risk cases либо конкретный `N/A` reason. |
 | SDD26-18 | Добавить отдельный multi-repo context mapping file. | [K] | already-covered | accepted | 2026-08-26; native `openspec instructions ... --json` уже возвращает `planningHome`, `contextFiles`, `artifactPaths` и config context. Второй context map дублировал бы CLI state. |
 | SDD26-19 | Зафиксировать commit-message convention в schema. | [K] | rejected | accepted | 2026-08-26; commit style не меняет artifact correctness и принадлежит repository delivery policy только при появлении отдельного проверяемого требования. |
 | SDD26-20 | Сделать enterprise sections условными, чтобы снизить overhead. | [Q] | already-covered | accepted | 2026-08-26; Solution Assessment уже conditional, rollback допускает содержательный `N/A`; Delivery Map и Contract Gate Decision остаются обязательными, потому что защищают multi-repo scope. |
 | SDD26-21 | Добавить явный feedback loop из Design/Apply в ранний затронутый artifact. | [Q] | confirmed | done | 2026-08-26; schema v2 и agent entrypoints маршрутизируют intent→Proposal, behavior→Specs, architecture/rollback→Design, decomposition→Tasks и инвалидируют downstream approvals. |
 | SDD26-22 | Создавать `blocker.md` и `revision-request.md` при каждом blocker/revision. | [Q] | rejected | accepted | 2026-08-26; новые workflow artifacts не поддерживаются native schema и быстро устаревают. Наблюдаемое основание сообщается Change Owner в разговоре; durable artifact добавится только при реальном повторяемом trigger. |
 | SDD26-23 | Требовать regression test для любой изменённой логики и happy-path test для любой новой. | [Q] | already-covered | accepted | 2026-08-26; [risk-based testing](engineering-governance.md#risk-based-testing) требует tests для существенных рисков и regressions, но осознанно отклоняет универсальные малоценные tests ради каждого logic/file change. |
 | SDD26-24 | Добавлять Completion Summary в конец Tasks. | [Q] | rejected | accepted | 2026-08-26; Tasks содержат только planned work. Observed results и commits появляются после выполнения в verification/archive evidence, иначе checklist смешивает план и факты. |
 | SDD26-25 | Требовать точный текстовый `STOP_PROTOCOL` после каждого artifact. | [Z] | rejected | accepted | 2026-08-26; обязательная остановка и явный approval уже enforced entrypoints. Фиксация одной строки ответа хрупка и не усиливает identity или semantic approval. |
 | SDD26-26 | Сократить explanation `planningHome.root` до короткого imperative. | [Z] | rejected | accepted | 2026-08-26; пояснение предотвращает ошибочное вычисление path при store-backed и local modes OpenSpec 1.10. После удаления duplicate config rules instruction source остаётся приемлемым; пересмотреть при измеренном context regression. |
 | SDD26-27 | Добавить дополнительные contract gates вроде `internal-proto`. | [G] | deferred | deferred | Review trigger: появление второго реального межсервисного committed contract, для которого `runtime-openapi` и repository gates недостаточны. До этого generic gate будет speculative. |
 | SDD26-28 | Root project-owned agent projection должна восстанавливаться из versioned authority. | local triage | confirmed | done | 2026-08-26; superseded by follow-up cleanup: root `.opencode` остаётся local non-authority entrypoint без versioned projection source; hard constraints остаются в schema, docs и authority verifier. |
 | SDD26-29 | Exact OpenSpec version должна быть единым compatibility contract, а не вечным literal в scripts/fixtures. | local triage | confirmed | done | 2026-08-26; `.cli-version` остаётся единственным current contract; markers/verifiers выводят expected value из него, новая stable не включает auto-upgrade. |
 | SDD26-30 | Raw multi-source evidence и triage должны быть versioned раздельно. | local triage | confirmed | done | 2026-08-26; пять reports сохранены byte-for-byte в [snapshot set](../audits/2026-08-26-wealth-ledger-sdd/README.md); live registry хранит dispositions и statuses отдельно. |
 [D]: ../audits/2026-08-26-wealth-ledger-sdd/deepseek-result.md
 [G]: ../audits/2026-08-26-wealth-ledger-sdd/gemini-result.md
 [K]: ../audits/2026-08-26-wealth-ledger-sdd/kimi-result.md
 [Q]: ../audits/2026-08-26-wealth-ledger-sdd/qwen-result.md
 [Z]: ../audits/2026-08-26-wealth-ledger-sdd/zai-result.md
 ### Аудит 13.08.2026
 | Audit ID | Текущий статус | Связь и следующее действие | Terminal evidence или trigger |
 | --- | --- | --- | --- |
 | A-01 | done | См. WL-P2-03. | CAS rotation и regression test, 2026-08-23. |
 | A-02 | accepted | Ограниченная revocation model закреплена в ADR 006; access token живёт 15 минут. | Пересмотреть, если продукт потребует немедленный отзыв access token. |
 | A-03 | deferred | Production transport исключён из local MVP scope. | Пересмотреть перед hosted deployment или reverse-proxy contract. |
 | A-04 | done | `docs/features/tbank-connection.md` описывает поставленные Accounts, Portfolio, Ledger и Future Events. | Current-state docs проверены 2026-08-24. |
 | A-05 | done | См. WL-P1-03 и WL-P1-04. | Canonical root и hard archive lifecycle, 2026-08-23. |
 | A-06 | done | См. WL-P2-10. | Architecture/development onboarding и link review, 2026-08-24. |
 | A-07 | done | См. WL-P2-02. | P2002 mapping и concurrent registration regression, 2026-08-23. |
 | A-08 | planned | Объединить validation payload review с `tighten-backend-request-feedback`. | Готово к выбору после active change. |
 | A-09 | planned | Operations cache закрыт WL-P2-01; отдельно оценить session retention/index. | Создать scoped change после решения приоритета. |
 | A-10 | deferred | Текущая operational mitigation описана в T-Bank feature doc. | Пересмотреть при наблюдаемой потере metadata или новом large-portfolio SLA. |
 | A-11 | done | Исправлено и подтверждено самим snapshot 13.08.2026. | Transport tests и единый Bearer owner. |
 | A-12 | done | Исправлено в snapshot; дополнительно защищено WL-P3-03. | Dependency boundary fixture passed, 2026-08-24. |
 | A-13 | deferred | Frontend behavior закрыт; backend e2e зависит от WL-P2-05. | Тот же stable Prisma trigger, что у WL-P2-05. |
 | A-14 | done | [`2026-08-24-harden-agent-sdd-governance`](../../specs/openspec/changes/archive/2026-08-24-harden-agent-sdd-governance/). | 2026-08-24; canonical SDD governance, local guardrails and completion evidence protocol verified. |
 | A-15 | done | [`2026-08-24-harden-agent-sdd-governance`](../../specs/openspec/changes/archive/2026-08-24-harden-agent-sdd-governance/). | 2026-08-24; current-state ADR/spec contradictions fixed and strict specs passed. |
 | A-16 | done | [`2026-08-24-harden-agent-sdd-governance`](../../specs/openspec/changes/archive/2026-08-24-harden-agent-sdd-governance/). | 2026-08-24; layered AGENTS and onboarding verified. |
 | A-17 | deferred | Совпадает с accessibility scope WL-P3-04. | Пересмотреть при включении accessibility/second locale в MVP scope. |
 | A-18 | done | [`2026-08-24-harden-agent-sdd-governance`](../../specs/openspec/changes/archive/2026-08-24-harden-agent-sdd-governance/). | 2026-08-24; main spec H1 normalized and strict validation passed. |
 ### Аудит 24.08.2026
 | Audit ID | Цель | Статус | Связанный change | Следующее действие / evidence |
 | --- | --- | --- | --- | --- |
 | AUD24-01 | Ввести risk-based testing без тестов ради файла или coverage. | done | [`2026-08-24-harden-agent-sdd-governance`](../../specs/openspec/changes/archive/2026-08-24-harden-agent-sdd-governance/) | 2026-08-24; risk-based testing policy and gates recorded. |
 | AUD24-02 | Оценивать mature solutions и ретроспективно проверить auth platform. | planned | `assess-auth-platform-options` | Готово к созданию change; миграция не предрешена. |
 | AUD24-03 | Закрепить строгий artifact graph и роли OpenSpec. | done | [`2026-08-24-harden-agent-sdd-governance`](../../specs/openspec/changes/archive/2026-08-24-harden-agent-sdd-governance/) | 2026-08-24; one-artifact approvals, cascade reapproval and artifact roles verified. |
 | AUD24-04 | Синхронизировать agent projection и hard archive blockers. | done | [`2026-08-24-harden-agent-sdd-governance`](../../specs/openspec/changes/archive/2026-08-24-harden-agent-sdd-governance/) | 2026-08-24; project entrypoints and authority verifier reject bypass cases. |
 | AUD24-05 | Добавить canonical repo gates и workspace dispatcher. | done | [`2026-08-24-harden-agent-sdd-governance`](../../specs/openspec/changes/archive/2026-08-24-harden-agent-sdd-governance/) | 2026-08-24; workspace dispatcher ran all affected gates and runtime OpenAPI. |
 | AUD24-06 | Ввести docs-as-code gate и authoritative process policy. | done | [`2026-08-24-harden-agent-sdd-governance`](../../specs/openspec/changes/archive/2026-08-24-harden-agent-sdd-governance/) | 2026-08-24; docs `npm run verify` passed and engineering governance is durable docs. |
 | AUD24-07 | Сделать AGENTS компактными routing/enforcement layers. | done | [`2026-08-24-harden-agent-sdd-governance`](../../specs/openspec/changes/archive/2026-08-24-harden-agent-sdd-governance/) | 2026-08-24; root and repository AGENTS layers verified. |
 | AUD24-08 | Охватить одним registry все audit snapshots и исправить stale status. | done | [`2026-08-24-harden-agent-sdd-governance`](../../specs/openspec/changes/archive/2026-08-24-harden-agent-sdd-governance/) | 2026-08-24; registry covers all 53 audit IDs with one snapshot source each. |
 | AUD24-09 | Исправить current-state ADR/spec contradictions. | done | [`2026-08-24-harden-agent-sdd-governance`](../../specs/openspec/changes/archive/2026-08-24-harden-agent-sdd-governance/) | 2026-08-24; ADR/spec contradictions fixed without editing audit snapshots. |
 ### P1
 | Audit ID | Цель | Репозитории | Статус | Связанный change | Следующее действие | Terminal evidence |
 | --- | --- | --- | --- | --- | --- | --- |
 | WL-P1-01 | Один владелец React Query cache identity. | frontend | done | [`2026-08-23-stabilize-frontend-query-and-strict-contracts`](../../specs/openspec/changes/archive/2026-08-23-stabilize-frontend-query-and-strict-contracts/) | — | 2026-08-23; frontend `1250581`, specs `b8a3f96`; `npm run verify` — passed (16 files, 48 tests). |
 | WL-P1-02 | Сделать strict TypeScript исполняемым gate и устранить 16 ошибок. | frontend | done | [`2026-08-23-stabilize-frontend-query-and-strict-contracts`](../../specs/openspec/changes/archive/2026-08-23-stabilize-frontend-query-and-strict-contracts/) | — | 2026-08-23; frontend `1250581`, specs `b8a3f96`; strict typecheck and full `npm run verify` passed. |
 | WL-P1-03 | Установить единственный canonical OpenSpec root. | specs | done | [`2026-08-23-harden-openspec-authority-and-lifecycle`](../../specs/openspec/changes/archive/2026-08-23-harden-openspec-authority-and-lifecycle/) | — | 2026-08-23; frontend `d870d53`, backend `fee4f8c`, specs `51344d4`, docs `0bc8d1c`; authority verifier и 15 strict specs passed. |
 | WL-P1-04 | Сделать archive lifecycle доказательством завершённости. | specs, docs | done | [`2026-08-23-harden-openspec-authority-and-lifecycle`](../../specs/openspec/changes/archive/2026-08-23-harden-openspec-authority-and-lifecycle/) | — | 2026-08-23; frontend `d870d53`, backend `fee4f8c`, specs `51344d4`, docs `0bc8d1c`; hard archive gate и independent review passed. |
 | WL-P1-05 | Разделить non-mutating lint check и auto-fix backend. | backend | done | [`2026-08-23-make-local-verification-agent-safe`](../../specs/openspec/changes/archive/2026-08-23-make-local-verification-agent-safe/) | — | 2026-08-23; backend `71d57d6`, specs `72444db`, docs `293df9c`; `npm run lint`, app/test typecheck и 17 suites / 51 tests — passed. |
 ### P2
 | Audit ID | Цель | Репозитории | Статус | Связанный change | Следующее действие | Terminal evidence |
 | --- | --- | --- | --- | --- | --- | --- |
 | WL-P2-01 | Ограничить размер и eviction operations cache. | backend, specs, docs | done | [`2026-08-23-harden-auth-and-cache-concurrency`](../../specs/openspec/changes/archive/2026-08-23-harden-auth-and-cache-concurrency/) | — | 2026-08-23; backend `c77b3cf`, specs `6e20cdf`, docs `8568e7b`; Node 22 lint, app/test typecheck и 56 unit tests passed. |
 | WL-P2-02 | Вернуть предсказуемый 409 при конкурентной регистрации. | backend, specs, docs | done | [`2026-08-23-harden-auth-and-cache-concurrency`](../../specs/openspec/changes/archive/2026-08-23-harden-auth-and-cache-concurrency/) | — | 2026-08-23; backend `c77b3cf`, specs `6e20cdf`, docs `8568e7b`; P2002 mapping and barrier regression test passed. |
 | WL-P2-03 | Сделать refresh rotation атомарной. | backend, specs, docs | done | [`2026-08-23-harden-auth-and-cache-concurrency`](../../specs/openspec/changes/archive/2026-08-23-harden-auth-and-cache-concurrency/) | — | 2026-08-23; backend `c77b3cf`, specs `6e20cdf`, docs `8568e7b`; CAS one-winner regression test passed. |
 | WL-P2-04 | Синхронизировать runtime, OpenAPI и auth success statuses. | backend, frontend | done | [`2026-08-24-align-api-contract-and-client-resilience`](../../specs/openspec/changes/archive/2026-08-24-align-api-contract-and-client-resilience/) | — | 2026-08-24; backend `9bd3400`, frontend `6d892da`, specs `800450d`, docs `b91280c`; metadata regression, frontend OpenAPI check и runtime/snapshot SHA совпали. |
 | WL-P2-05 | Восстановить runnable backend e2e gate. | backend | done | — | — | 2026-09-13; унаследованный RUST_LOG изолирован в Prisma config, 3 последовательных и 2 параллельных полных e2e passed. [Результаты](#2026-09-13--wl-p2-05-воспроизводимый-sqlite-e2e). |
 | WL-P2-06 | Добавить проходящий app/test TypeScript gate backend. | backend | done | [`2026-08-23-make-local-verification-agent-safe`](../../specs/openspec/changes/archive/2026-08-23-make-local-verification-agent-safe/) | — | 2026-08-23; backend `71d57d6`, specs `72444db`, docs `293df9c`; `npm run typecheck:app` и `npm run typecheck:test` — passed. [2026-09-13: включён strict по P1-10](#2026-09-13--wl-p2-06-strict-typescript). |
 | WL-P2-07 | Сохранять cached data во время background refetch. | frontend | done | [`2026-08-24-align-api-contract-and-client-resilience`](../../specs/openspec/changes/archive/2026-08-24-align-api-contract-and-client-resilience/) | — | 2026-08-24; frontend `6d892da`, specs `800450d`, docs `b91280c`; observable Accounts/Portfolio refetch tests и `npm run verify` — passed (17 files, 55 tests). |
 | WL-P2-08 | Нормализовать cold-start refresh failure. | frontend | done | [`2026-08-24-align-api-contract-and-client-resilience`](../../specs/openspec/changes/archive/2026-08-24-align-api-contract-and-client-resilience/) | — | 2026-08-24; frontend `6d892da`, specs `800450d`, docs `b91280c`; cold-start и protected-401 transport-failure tests passed. |
 | WL-P2-09 | Проверять backend runtime OpenAPI против frontend snapshot. | backend, frontend | done | [`2026-08-23-make-local-verification-agent-safe`](../../specs/openspec/changes/archive/2026-08-23-make-local-verification-agent-safe/) | — | 2026-08-23; frontend `7a3048c`, backend `71d57d6`, specs `72444db`, docs `293df9c`; runtime и snapshot SHA-256 совпали, frontend `npm run openapi:check` — passed. |
 | WL-P2-10 | Актуализировать onboarding и постоянную документацию. | docs, frontend, backend, specs | done | [`2026-08-24-refresh-project-documentation-and-agent-entrypoints`](../../specs/openspec/changes/archive/2026-08-24-refresh-project-documentation-and-agent-entrypoints/) | — | 2026-08-24; frontend `be80ef2`, backend `fec542a`, specs `9f68ae5`, docs `88c0cd3`; OpenSpec/authority, link-path review и independent review passed. |
 | WL-P2-11 | Зафиксировать одинаковый local bootstrap frontend/backend. | frontend, backend, docs | done | [`2026-08-23-make-local-verification-agent-safe`](../../specs/openspec/changes/archive/2026-08-23-make-local-verification-agent-safe/) | — | 2026-08-23; frontend `7a3048c`, backend `71d57d6`, specs `72444db`, docs `293df9c`; Node 22 policy и `npm ci` guidance зафиксированы. |
 | WL-P2-12 | Проверить применимость high dependency advisories. | frontend, backend, specs, docs | done | [`2026-08-24-address-dependency-advisories-and-repo-hygiene`](../../specs/openspec/changes/archive/2026-08-24-address-dependency-advisories-and-repo-hygiene/) | — | 2026-08-24; frontend `826936c`, backend `6052565`, specs `8897bd9`, docs `60a1c33`; React Router обновлён, Prisma tooling risk принят с review trigger. |
 | WL-P2-13 | Дать одному agent workflow единый local verify interface. | frontend, backend, specs, docs | deferred | — | Вернуться после восстановления WL-P2-05 тем же Prisma trigger; затем выбрать минимальный общий interface. | 2026-08-23; полный общий verdict не может быть достоверно зелёным, пока обязательный backend e2e migration gate блокируется Prisma 7.9.1. |
 ### P3
 | Audit ID | Цель | Репозитории | Статус | Связанный change | Следующее действие | Terminal evidence |
 | --- | --- | --- | --- | --- | --- | --- |
 | WL-P3-01 | Сделать unknown request fields явной ошибкой или документированной policy. | backend | planned | `tighten-backend-request-feedback` (ещё не создан) | Выбрать validation policy. | — |
 | WL-P3-02 | Устранить shared i18n import cycle. | frontend | done | [`2026-08-24-tighten-frontend-quality-guardrails`](../../specs/openspec/changes/archive/2026-08-24-tighten-frontend-quality-guardrails/) | — | 2026-08-24; frontend `1fc269a`, specs `2029519`, docs `fa5db07`; Node 22 `npm run verify` — passed. |
 | WL-P3-03 | Восстановить FSD public API boundary. | frontend | done | [`2026-08-24-tighten-frontend-quality-guardrails`](../../specs/openspec/changes/archive/2026-08-24-tighten-frontend-quality-guardrails/) | — | 2026-08-24; frontend `1fc269a`, specs `2029519`, docs `fa5db07`; dependency fixture gate — passed. |
 | WL-P3-04 | Исправить базовые language/loading accessibility semantics. | frontend | deferred | — | Пересмотреть при включении accessibility в MVP scope. | 2026-08-24; текущий local MVP scope не включает accessibility remediation. |
 | WL-P3-05 | Ввести пропорциональный bundle regression budget. | frontend | done | [`2026-08-24-tighten-frontend-quality-guardrails`](../../specs/openspec/changes/archive/2026-08-24-tighten-frontend-quality-guardrails/) | — | 2026-08-24; frontend `1fc269a`, specs `2029519`, docs `fa5db07`; initial JS payload 509,165 B ≤ 512,000 B. |
 | WL-P3-06 | Добавить coverage ratchet только как regression signal. | frontend | done | [`2026-08-24-tighten-frontend-quality-guardrails`](../../specs/openspec/changes/archive/2026-08-24-tighten-frontend-quality-guardrails/) | — | 2026-08-24; frontend `1fc269a`, specs `2029519`, docs `fa5db07`; coverage 82.57/76.08/77.35/83.48% — passed. |
 | WL-P3-07 | Защитить рабочий `.env` от случайного commit. | frontend, specs, docs | done | [`2026-08-24-address-dependency-advisories-and-repo-hygiene`](../../specs/openspec/changes/archive/2026-08-24-address-dependency-advisories-and-repo-hygiene/) | — | 2026-08-24; frontend `826936c`, specs `8897bd9`, docs `60a1c33`; hygiene check passed. |
 | WL-P3-08 | Исключить runtime SQLite DB из Git. | backend, specs, docs | done | [`2026-08-24-address-dependency-advisories-and-repo-hygiene`](../../specs/openspec/changes/archive/2026-08-24-address-dependency-advisories-and-repo-hygiene/) | — | 2026-08-24; backend `6052565`, specs `8897bd9`, docs `60a1c33`; hygiene check passed. |
 ### 2026-09-13 — WL-P2-11: переход на Node 24 LTS
 Продолжение bootstrap policy из WL-P2-11, части 14.backend/frontend/docs
 [рабочего TODO](../../todo/wealthledger-engineering-improvements.md).
 Node 24.21.0 / npm 11.19.0 выбран по [официальному каталогу релизов](https://nodejs.org/dist/index.json)
 и [расписанию поддержки](https://github.com/nodejs/Release#release-schedule):
 ветка Krypton LTS поддерживается до 30.04.2028.
 `.nvmrc` frontend/backend/docs фиксируют 24.21.0, engines — 24.x.
 Backend `@types/node` обновлён до 24.13.3; runtime dependencies не обновлялись.
 Npm дополнил backend lockfile платформенными optional dependencies существующего
 resolver. Для npm 11.19 явно разрешены install scripts сборочных зависимостей
 с pin версий. Инструкция переустановки и отката — в
 [локальном окружении](local-workspace.md#версия-node).
 Specs продолжает наследовать frontend runtime; самостоятельный bootstrap CLI
 из части 14.specs и CI остаются отдельными незавершёнными задачами.
 Проверки относятся к frontend `53c852b`, backend `ce24a84`, docs `c74c573`,
 specs `834f2d1` с текущим diff перехода Node:
 - `npm ci` в frontend/backend/docs — PASS; backend native modules установлены
  под Node 24, `npm run build` с генерацией Prisma client — PASS.
 - Frontend `npm run verify` — PASS: 46 files, 268 tests, coverage, OpenAPI drift,
  TypeScript, Biome, Knip, dependency boundaries, приложение и Storybook.
  Прогон одновременно с установкой backend упирался в UI timeout; отдельный
  повтор полного gate прошёл без изменения тестов или их таймаутов.
 - Backend `npm run verify` — PASS: 35 suites, 257 tests, lint, оба typecheck и build.
 - Backend `npm run test:e2e` — PASS: 8 suites, 98 tests; новая SQLite и штатные
  migrations для каждой suite, включая runtime OpenAPI. Для HTTP-портов нужен
  запуск вне sandbox. Рабочая БД не использовалась.
 - Docs `npm run verify` — PASS: 54 Markdown-файла, 0 issues;
  `git diff --check` во всех четырёх repos — PASS.
 - OpenSpec CLI 1.10.0, существующая установка, исполненная Node 24.21.0:
  `schema validate wealth-ledger-sdd --verbose` и
  `validate --specs --strict --store wealth-ledger-specs` — PASS, 25 specs.
 ## История registry
 Terminal evidence добавляется сюда только после завершения соответствующего change.
 ### 2026-09-13 — WL-P2-05: воспроизводимый SQLite e2e
 Закрыты TODO 03 и 03.docs, повторно проверен SQLite scope 11. Backend
 `8637ad2` с текущим diff, Node 22.21.0 / Prisma 7.9.1. Schema, migrations,
 зависимости и HTTP-контракт не менялись.
 - До исправления fresh migration: `RUST_LOG=warn` и `error` — exit 1 с пустым
  `Schema engine error`; переменная отсутствует или равна `info` — exit 0.
  В исходном окружении было `RUST_LOG=warn`. Это воспроизведённая зависимость
  запуска от окружения, а не доказательство внутреннего дефекта Rust engine.
 - Prisma config исключает унаследованный `RUST_LOG` после dotenv. Общий runner
  даёт каждому suite свою DB и один URL для migration/Jest, отклоняет прямой
  Jest без изоляции и очищает каталог после ошибки или сигнала.
 - `npm run verify` — PASS: zero-warning lint, app/test types, 35 suites /
  257 unit tests, Prisma generation и build.
 - Docs `npm run verify` — PASS: Markdown, ссылки/якоря и `git diff --check`.
 - `npm run test:e2e` — PASS: 8 suites / 98 tests, включая runtime OpenAPI.
 - `node test/sqlite-regression.cjs` — PASS: три последовательных и два
  параллельных полных e2e (каждый 98 tests, всего 40 разных DB); внешний
  вымышленный файл неизменён. Недоступный schema engine возвращает exit 1;
  SIGINT/SIGTERM — 130/143. Все 43 созданных DB-каталога удалены.
 - `npm run test:durability -- /tmp/p111-baseline` — PASS: отдельная baseline
  сборка `8ec172f48eefa2237dc0c16919fbb2e726b39a65`, additive migration,
  сохранение User/Session/TbankConnection, банковской истории и защиты повторов,
  restart, откат приложения и backup/restore. `RUST_LOG=info` удалён из runner;
  для старого baseline унаследованная переменная также исключается.
 - HTTP/durability проверены вне sandbox после воспроизведения запрета локальных
  портов `EPERM`. Это ограничение среды, не failing migration. Пользовательская
  DB и `.env` не использовались как цель записи.
 Логи этой проверки: `/tmp/wl-sqlite-verify.log`, `/tmp/wl-sqlite-e2e-1.log`,
 `/tmp/wl-sqlite-regression.log`, `/tmp/wl-sqlite-durability.log`.
 Подробные regression logs сохранены в системном temp-каталоге
 `wealthledger-sqlite-regression-pSyuoe`, durability —
 `wealthledger-bank-durability-V0u1NA`. Эти локальные временные логи могут быть
 удалены системой; воспроизводимые команды и
 [матрица рисков](../../backend/README.md#реальная-sqlite-и-сохранность-данных)
 остаются в backend. Исторические evidence ниже сохранены без переписывания.
 ### 2026-09-13 — P1-12: backend responsibilities
 Статус: `done`. Backend commit `8ba0053`.
 BankCards разделён на services карт, операций и категорий, сценарий сводки и
 конкретный repository. Общая transaction/retry boundary, ownership, idempotency,
 optimistic concurrency и ограничения возвратов сохранены. Stock/bond services
 разделены по каталогу, рынку и доходам; связные operations и T-Bank client
 сохранены. Business modules отделены от integrations; сложные modules используют
 слои ответственности, компактные остаются плоскими.
 - `npm run verify` — passed: lint, app/test typecheck, 35 suites / 257 tests, build.
 - Восемь существующих HTTP/e2e suites выполнены временным runner
  `/tmp/wl-modular-http.cjs`: отдельная SQLite DB на suite, migrations с
  `RUST_LOG=info`, configured HTTP, 118 tests passed. OpenAPI совпадает с frontend
  snapshot. Общий e2e blocker и статус задачи 03 этим не закрываются.
 - Финальный перенос 47 файлов проверен сравнением 142 исходников/tests:
  различий кроме относительных путей и форматирования нет.
 - Formatter, docs `npm run verify`, lint backend conventions и `git diff --check`
  прошли. Новые dependencies и architecture tests не добавлены.
 ### 2026-09-13 — P1-11: реальная SQLite
 P1-11 поставлена в backend commit `7fde3ec`. Дополнено доказательство
 WL-P2-03; статус общего e2e WL-P2-05 не меняется. Команды и матрица рисков —
 [backend README](../../backend/README.md#реальная-sqlite-и-сохранность-данных).
 - `npm run test:sqlite` — два последовательных успешных запуска после фиксации
  loopback-listener: 8 auth и 21 карточный HTTP/SQLite test. Каждый suite получает
  собственную временную DB; Prisma не мокируется. Барьер перед CAS гарантирует,
  что оба refresh прочитали прежний hash; победившая сессия переживает replay.
 - Существующие карточные tests покрывают owner links, idempotency/tombstones,
  версии, конкурентные refund/archive/write, rollback source lock, атомарный
  перевод, точные суммы и FK/unique constraints. Новая тестовая платформа не нужна.
 - `npm run test:durability -- /tmp/p111-baseline` — PASS: migration, restart,
  previous-app rollback, backup/restore и чтение сохранённой финансовой истории.
  Baseline экспортирован из `8ec172f48eefa2237dc0c16919fbb2e726b39a65` и собран
  отдельно. Его lockfile совпадает с текущим; при этой проверке переиспользованы
  установленные node_modules. README также описывает независимый `npm ci`.
  Runner проверяет наличие build и неизменённый префикс migration history.
 - Node 22.21.0: `npm run verify` — PASS (35 suites, 257 unit tests, zero-warning
  lint, оба typecheck, Prisma generate и build).
 - Первые HTTP-запуски с автоматическим открытием/закрытием сервера Supertest
  дали плавающий 404. Suites теперь держат один loopback-listener до `app.close()`;
  повторные проверки прошли. Sandbox требует разрешения на локальный порт.
 - Миграции выполнены с `RUST_LOG=info`. Это подтверждение выбранных DB-сценариев,
  не снятие прежнего ограничения общего `test:e2e` и не выполнение задачи 03.
 ### 2026-09-13 — WL-P2-06: strict TypeScript
 Поставка backend: commit `346a6f0` (`refactor: enforce strict backend typing`).
 По продолжению P1-10 в [общем tsconfig](../../backend/tsconfig.json) включён
 `strict: true` без отключения отдельных strict-проверок;
 `noFallthroughCasesInSwitch` сохранён отдельно. Убраны избыточные настройки,
 которые теперь включает `strict`.
 После замечания владельца вариант с definite-assignment `!` заменён:
 в 14 файлах 315 полей DTO объявлены через `declare`. Заполнение входных DTO
 принадлежит Nest/class-transformer, ответные DTO описывают возвращаемые объекты.
 `declare` не генерирует поля со значением `undefined` и не подменяет проверку
 входных данных. Optional/nullable-типы, декораторы и валидация сохранены.
 В [TbankClient](../../backend/src/integrations/tbank/tbank.client.ts)
 `getOpenAccounts` и `getDividends` задают тип результата на `call<Response>`,
 как соседние RPC; тип параметра `.then` выводится из этого результата.
 В [ESLint](../../backend/eslint.config.mjs) включён
 `@typescript-eslint/no-non-null-assertion: error`. Он не охватывает `field!: Type`,
 поэтому `no-restricted-syntax` отдельно запрещает definite-assignment `!`
 в свойствах и переменных. Устранены также 51 прежний non-null assertion и
 четыре definite-assignment assertions в тестах: используются сужение типов,
 локальные значения, типизированные результаты фильтрации и runtime assertions
 в тестах. Транзакции, проверки доступа, cache generation и денежная точность
 сохранены; отсутствующая категория в сводке приводит к явной внутренней ошибке.
 Проверено на Node 22.21.0, backend `3cf883e` с указанными изменениями:
 - `npm run verify` — passed: lint без warnings, strict app/test typechecks,
  35 Jest suites / 257 tests, Prisma generation и production build.
 - `DATABASE_URL=file:/tmp/wealthledger-declared-dto-openapi-20260913.db npm run test:openapi-contract`
  — passed, 1 test; frontend snapshot не менялся.
 - TypeScript Compiler API подтвердил все strict options в app/test/build/dev
  configs. Каждый config отклоняет шесть примеров: неинициализированное поле,
  несовместимый callback, `null` вместо строки, implicit `any`/`this`, доступ
  к `unknown` в `catch` (TS2564, TS2345, TS2322, TS7006, TS2683, TS18046).
 - Проверка ESLint через `lintText` подтверждает ошибки для `value!`, `field!`
  и `let value!`; декларация DTO без `!` разрешена.
 - Новые тесты ValidationPipe проходят до и после замены деклараций:
  обязательные credentials, нормализация email, вложенные money DTO и
  обязательный version с optional-полями `PartialType`. Дополнены проверки
  инструментов без UID; отдельный тест проверяет имя категории и ошибку
  при нарушенной ссылке в банковской сводке.
 - `NODE_ENV=development NODE_OPTIONS=--experimental-vm-modules npx jest --config test/jest-e2e.json --runInBand bank-cards.e2e-spec.ts`
  с новой `DATABASE_URL=file:/tmp/bank-cards-*/test.db` — passed, 21 tests,
  включая реальные миграции, валидацию HTTP, права владельца, возвраты,
  транзакции и перезапуск. Runner использует `RUST_LOG=info` для миграций.
  Первый прогон дал 19 passed / 2 timeout в сценариях возвратов и потребовал
  остановки оставшегося Jest-процесса. Повтор на новой базе прошёл 21/21;
  исходный `3cf883e` в отдельной копии с теми же dependencies также прошёл
  21/21. Это не доказательство стабильности общего e2e gate.
 - Полный `strict` проходит; 317 diagnostics из предыдущей оценки устранены.
  Общий DB/e2e gate и ограничение WL-P2-05 остаются отдельной задачей.
 ### 2026-09-13 — WL-P2-06: backend TypeScript
 Выполнен пункт P1-10 списка инженерных улучшений от 13.09.2026
 как продолжение существующего TypeScript gate. В [общем tsconfig](../../backend/tsconfig.json)
 включены `noImplicitAny`, `strictBindCallApply`, `noFallthroughCasesInSwitch`;
 app/test typechecks, production и dev build наследуют эти настройки.
 Исходный код, зависимости, unsafe-checks и публичный API не менялись.
 Проверено на Node 22.21.0, backend `3cf883e` с указанным изменением tsconfig:
 - `npm run verify` до и после изменения — passed: zero-warning ESLint,
  оба TypeScript gate, 33 Jest suites / 253 tests, Prisma generation и build.
 - Проверка через TypeScript Compiler API с виртуальным ошибочным файлом для
  каждого из четырёх configs — passed: implicit-any параметр даёт TS7006,
  неверные аргументы `call`/`apply`/`bind` — TS2345/TS2322, проваливание `switch`
  — TS7029. Контроль с выключенными тремя flags принимает тот же файл.
 - `DATABASE_URL=file:/tmp/wealthledger-p1-10-openapi-20260913.db npm run test:openapi-contract`
  — passed, 1 test; runtime OpenAPI совпал с frontend snapshot.
 - `npx tsc --project tsconfig.typecheck.test.json --incremental false --strict --noImplicitAny --strictBindCallApply --noFallthroughCasesInSwitch --pretty false`
  — оценка полного `strict`: 317 diagnostics, из них 315 TS2564 для полей DTO
  и две TS2345 в `TbankClient.getOpenAccounts` / `getDividends` из-за callback
  для `Promise<unknown>`. Полный `strict` пока не включён; это отдельный этап.
 - Общий DB/e2e gate не запускался; WL-P2-05 сохраняет прежний статус.
 ### 2026-08-26 — SDD26-01–SDD26-03, SDD26-09, SDD26-12, SDD26-17, SDD26-21, SDD26-28–SDD26-30: done
 Change синхронизирован в canonical specs и архивирован в [`2026-08-26-harden-openspec-sdd-quality`](../../specs/openspec/changes/archive/2026-08-26-harden-openspec-sdd-quality/).
 - Delivery Map: frontend `N/A`, backend `N/A`, specs affected, docs affected; runtime OpenAPI contract gate `N/A`, потому что application runtime API и generated client не менялись.
 - Затронутые Git-репозитории: specs `a8b2c4eed988f7e1a7b3d6b7188bbe6791f00e2a` (`feat: harden OpenSpec SDD workflow`), docs delivery `72c3a8a6683b95f7e734044fdabe568668097c33` (`docs: record SDD audit remediation`); terminal evidence фиксируется следующим docs commit.
 - Pre-archive `bash specs/scripts/verify-workspace-change.sh harden-openspec-sdd-quality` под Node 22.21.0 — passed: Delivery Map verified frontend/backend `N/A`, specs/docs affected, runtime-openapi `N/A`; OpenSpec CLI 1.10.0 verified; planning coverage 9/9; schema valid; change valid; main specs 20/20; authority verified; docs `npm run verify` passed with 36 Markdown files and 0 issues.
 - Controlled fixture suites: `bash specs/scripts/verify-agent-projection.test.sh` — passed at delivery time; follow-up cleanup later removed the projection layer. `bash specs/scripts/verify-openspec-authority.test.sh` — passed with expected controlled-negative failures.
 - Archive: `openspec archive harden-openspec-sdd-quality -y --store wealth-ledger-specs` — updated `audit-remediation-workflow`, `engineering-change-governance`, `multi-repository-delivery` and `openspec-authority-and-lifecycle`; archived as `2026-08-26-harden-openspec-sdd-quality`.
 - Post-archive verification: `openspec validate --specs --strict --store wealth-ledger-specs` — 20 passed, 0 failed; `bash specs/scripts/verify-openspec-authority.sh` — passed; `openspec schema validate wealth-ledger-sdd --verbose` — passed; `PATH=/Users/ksv741/.nvm/versions/node/v22.21.0/bin:$PATH npm run verify` in `docs` — passed.
 - Semantic verification: Proposal, all 9 Delta Spec requirements, 28 scenarios, Design and 18/18 tasks matched implementation. Independent read-only review found no Critical or Important findings.
 ### 2026-08-24 — AUD24-01, AUD24-03–AUD24-09, A-14–A-16, A-18: done
 Change синхронизирован в canonical specs и архивирован в [`2026-08-24-harden-agent-sdd-governance`](../../specs/openspec/changes/archive/2026-08-24-harden-agent-sdd-governance/).
 - Delivery Map: frontend affected, backend affected, specs affected, docs affected; runtime OpenAPI contract gate required because frontend/backend contract verification pipelines changed. Workspace root `.opencode` projection and root `AGENTS.md` were updated locally; the workspace root is not a Git repository.
 - Затронутые Git-репозитории: frontend `11be786943024699a4eccf91a8d1ad32a6d29e5f` (`chore: codify frontend local verification`), backend `2772d53647132e6119e411c6d18234db4301e541` (`chore: codify backend local verification`), specs `0006aea56207ad2192c678ced562feabf1a21c45` (`chore: harden SDD governance workflow`), docs delivery `1944f2fc970db2bdc292981e01b1aca549f9ac52` (`docs: record AI governance audit`); terminal evidence фиксируется следующим docs commit.
 - `bash specs/scripts/verify-workspace-change.sh harden-agent-sdd-governance` под Node 22.21.0 — passed: Delivery Map verified for all four areas, OpenSpec CLI 1.10.0 verified, schema valid, change valid before archive, main specs 18/18 before sync, authority verified, frontend `npm run verify` passed (17 test files / 56 tests, coverage 82.57% statements / 76.08% branches / 77.35% functions / 83.48% lines, production build, initial JS 509,165 B), backend `npm run verify` passed (19 suites / 59 tests, build), docs `npm run verify` passed (34 Markdown files, 0 issues), runtime OpenAPI SHA-256 matched snapshot `96744da5f307b37ee3d9233b3259043425f65e49bcc60f78b46c585a78251db4`.
 - После sync/archive `openspec validate --specs --strict --store wealth-ledger-specs` — 20 passed, 0 failed; `git diff --check` в frontend, backend, specs и docs — exit 0 before delivery commits.
 - Semantic verification: Proposal, all 19 Delta Spec requirements, Design and 25/25 tasks matched implementation. Independent read-only re-review after fixes: Spec review 19/19, 0 Critical, 0 Important, 0 Minor semantic findings; Standards review final — no findings.
 ### 2026-08-24 — WL-P3-02, WL-P3-03, WL-P3-05, WL-P3-06: done
 Change синхронизирован в canonical specs и архивирован в [`2026-08-24-tighten-frontend-quality-guardrails`](../../specs/openspec/changes/archive/2026-08-24-tighten-frontend-quality-guardrails/).
 - Затронутые Git-репозитории: frontend `1fc269a` (`feat: enforce frontend quality guardrails`), specs `2029519` (`docs(specs): archive frontend quality guardrails`), docs `fa5db07` (`docs: activate frontend quality guardrails remediation`); terminal evidence фиксируется следующим docs commit.
 - Frontend под Node 22.21.0: `npm run verify` — passed: OpenAPI and hygiene checks, strict TypeScript, Biome, 17 test files / 56 tests, coverage all committed `src` 82.57% statements / 76.08% branches / 77.35% functions / 83.48% lines, Knip, dependency gate с четырьмя fixtures, production build и bundle gate. Initial JavaScript payload — 509,165 B при budget 512,000 B; committed lazy baselines включают все dynamic route boundaries, включая `ProtectedLayout`.
 - `openspec validate tighten-frontend-quality-guardrails --type change --strict --store wealth-ledger-specs` — passed до archive; после sync/archive `openspec validate --specs --strict --store wealth-ledger-specs` — 18 passed, 0 failed; `bash specs/scripts/verify-openspec-authority.sh` и `git diff --check` по затронутым repositories — passed.
 - `opsx-verify` не установлен как shell executable; выполнена эквивалентная процедура из `.opencode/skills/openspec-verify-change/SKILL.md`: completeness 21/21 tasks, 3 requirements / 7 scenarios, correctness и coherence — без blocking findings. Independent read-only review нашёл три Important guardrail gaps; после fixes re-review — без Critical или Important findings.
 - WL-P3-04 остаётся `planned` по явному решению owner: application accessibility semantics не входят в текущий MVP scope. Следующая единственная recommended задача — `tighten-backend-request-feedback` для WL-P3-01.
 ### 2026-08-24 — WL-P2-12, WL-P3-07, WL-P3-08: done
 Change синхронизирован в canonical specs и архивирован в [`2026-08-24-address-dependency-advisories-and-repo-hygiene`](../../specs/openspec/changes/archive/2026-08-24-address-dependency-advisories-and-repo-hygiene/).
 - Затронутые Git-репозитории: frontend `826936c` (`fix: harden frontend dependency and env hygiene`), backend `6052565` (`fix: harden backend runtime artifact hygiene`), specs `8897bd9` (`docs(specs): archive dependency hygiene remediation`), docs `60a1c33` (`docs: record dependency hygiene remediation evidence`).
 - Frontend под Node 22: `npm run verify` — passed: OpenAPI check, hygiene check, strict TypeScript check, Biome, 17 test files / 55 tests, coverage, Knip, dependency check и production build. `npm audit --omit=dev` — 0 vulnerabilities; прямой `react-router` обновлён с 7.9.6 до 7.18.2 для GHSA-2w69-qvjg-hvjx.
 - Backend под Node 22: `npm run hygiene:check`, `npm run lint`, `npm run typecheck:app`, `npm run typecheck:test` и `npm test -- --runInBand` — passed (19 suites, 59 tests). Runtime `dev.db` удалён из Git; intentional textual fixtures остаются versionable. `npm audit --omit=dev` всё ещё показывает три high по Prisma CLI path `prisma -> @prisma/config -> deepmerge-ts` для GHSA-ggr8-5vv4-36mx: public runtime path не найден, риск принят как tooling-only. Review trigger: совместимый stable Prisma release должен устранить `deepmerge-ts < 8.0.0`, либо появится доказуемый runtime call path.
 - `npm run test:e2e` остаётся deferred по WL-P2-05: `prisma migrate deploy` на чистой temporary SQLite DB завершается пустым `Schema engine error` до Jest. Это не менялось данным change.
 - `bash specs/scripts/verify-openspec-authority.sh` — passed; `openspec validate --specs --strict --store wealth-ledger-specs` — 17 passed, 0 failed; `git diff --check` по четырём репозиториям — passed. Эквивалентная `opsx-verify` процедура подтвердила 13/13 tasks, correctness и coherence. Независимый read-only review после исправлений — без Critical, Important или Minor findings.
 ### 2026-08-24 — WL-P2-10: done
 Change синхронизирован в canonical specs и архивирован в [`2026-08-24-refresh-project-documentation-and-agent-entrypoints`](../../specs/openspec/changes/archive/2026-08-24-refresh-project-documentation-and-agent-entrypoints/).
 - Затронутые Git-репозитории: frontend `be80ef2` (`docs: refresh frontend onboarding`), backend `fec542a` (`docs: refresh backend onboarding`), specs `9f68ae5` (`fix(specs): remove archived change duplicate` после archive commit `5b7bc0f`), docs `88c0cd3` (`docs: refresh project onboarding entrypoints`).
 - `npm run verify` в frontend под Node 22 — passed: OpenAPI check, strict TypeScript check, Biome, 17 test files / 55 tests, coverage, Knip, dependency check и production build.
 - Read-only link/path review — passed: 14 Markdown entrypoints без missing local links; `MVP.md` и `CONTEXT.md` удалены, а historical audit/archive references намеренно сохранены.
 - `openspec validate --all --strict --store wealth-ledger-specs` — 16 passed, 0 failed; `bash specs/scripts/verify-openspec-authority.sh` — passed; `git diff --check` по затронутым путям — passed.
 - Independent read-only standards/spec review выявил только Finder metadata и две неполные README links; metadata удалены, ссылки добавлены, re-review — passed. Эквивалентная `opsx-verify` процедура подтвердила completeness 16/16, correctness и coherence без blocking findings.
 ### 2026-08-24 — WL-P2-04, WL-P2-07, WL-P2-08: done
 Change синхронизирован в canonical specs и архивирован в [`2026-08-24-align-api-contract-and-client-resilience`](../../specs/openspec/changes/archive/2026-08-24-align-api-contract-and-client-resilience/).
 - Затронутые Git-репозитории: frontend `6d892da` (`fix: preserve cached data during refresh failures`), backend `9bd3400` (`fix: align auth success status contract`), specs `800450d` (`docs(specs): archive api contract resilience remediation`), docs `b91280c` (`docs: document auth and client refresh resilience`).
 - Frontend под Node 22: `npm run verify` — passed: OpenAPI check, strict TypeScript check, Biome, 17 test files / 55 tests, coverage, Knip, dependency check и production build.
 - Backend под Node 22: `npm run lint`, `npm run typecheck:app`, `npm run typecheck:test` и `npm test -- --runInBand` — passed (19 suites, 59 tests). `test:e2e` не запускался: WL-P2-05 остаётся deferred из-за Prisma migration gate.
 - `bash specs/scripts/verify-runtime-openapi.sh` — passed: runtime и snapshot SHA-256 `96744da5f307b37ee3d9233b3259043425f65e49bcc60f78b46c585a78251db4` совпали. `openspec validate --specs --strict --store wealth-ledger-specs` — 16 passed, 0 failed; authority verifier и `git diff --check` — passed.
 - `opsx-verify` выполнен эквивалентной процедурой из `.opencode/skills/openspec-verify-change/SKILL.md`: completeness 16/16 tasks, correctness и coherence — без blocking findings. Независимый read-only review не нашёл Critical, Important или Minor issues.
 ### 2026-08-23 — WL-P2-01, WL-P2-02, WL-P2-03: done
 Change синхронизирован в main specs и архивирован в [`specs/openspec/changes/archive/2026-08-23-harden-auth-and-cache-concurrency`](../../specs/openspec/changes/archive/2026-08-23-harden-auth-and-cache-concurrency/).
 - Затронутые Git-репозитории: backend `c77b3cf` (`fix: harden auth and cache concurrency`), specs `6e20cdf` (`docs(specs): archive auth and cache remediation`), docs `8568e7b` (`docs: record auth and cache concurrency policy`).
 - Backend под Node 22: `npm run lint`, `npm run typecheck:app`, `npm run typecheck:test` и `npm test -- --runInBand` — passed (18 suites, 56 tests). `test:e2e` не запускался: WL-P2-05 остаётся deferred из-за Prisma migration gate.
 - `openspec validate harden-auth-and-cache-concurrency --type change --strict --store wealth-ledger-specs` — passed до archive; после sync `openspec validate --specs --strict --store wealth-ledger-specs` — 15 passed, 0 failed; authority verifier и `git diff --check` — passed.
 - `opsx-verify` не установлен как shell executable; выполнена эквивалентная процедура из `.opencode/skills/openspec-verify-change/SKILL.md`: completeness 12/12 tasks, correctness и coherence — без blocking findings. Independent read-only review не нашёл Critical/Important findings.
 ### 2026-08-23 — WL-P1-05, WL-P2-06, WL-P2-09, WL-P2-11: done
 Change архивирован в [`specs/openspec/changes/archive/2026-08-23-make-local-verification-agent-safe`](../../specs/openspec/changes/archive/2026-08-23-make-local-verification-agent-safe/).
 - Затронутые Git-репозитории: frontend `7a3048c` (`docs: document runtime OpenAPI verification`), backend `71d57d6` (`fix: make backend local verification safe`), specs `72444db` (`docs(specs): archive local verification remediation`), docs `293df9c` (`docs: document local verification workflow`).
 - Backend под Node 22: `npm run lint`, `npm run typecheck:app`, `npm run typecheck:test` и `npm test -- --runInBand` — passed (17 suites, 51 tests).
 - `npm run openapi:check` в frontend — passed; `bash specs/scripts/verify-runtime-openapi.sh` — runtime и snapshot SHA-256 совпали.
 - `openspec validate make-local-verification-agent-safe --type change --strict --store wealth-ledger-specs` перед archive — passed; после sync `openspec validate --specs --strict --store wealth-ledger-specs` — 15 passed, 0 failed; authority verifier, `git diff --check` и independent read-only review — passed/no findings.
 ### 2026-08-23 — WL-P2-05, WL-P2-13: deferred
 Под Node 22 `prisma migrate deploy` 7.9.1 несколько раз завершается пустым
 `Schema engine error` на новых SQLite DB до запуска Jest; при включении engine
 diagnostics результат меняется. `npm view prisma version` вернул ту же
 published stable версию 7.9.1. Поэтому не вводится параллельный migration runner
 и не создаётся общий workspace verdict с ложным зелёным статусом. Review trigger
 для обоих findings: следующая stable Prisma должна трижды подряд применить
 существующие migrations к чистой SQLite DB на Node 22.
 ### 2026-08-23 — WL-P1-03, WL-P1-04: `harden-openspec-authority-and-lifecycle`
 Статус: `done`. Change синхронизирован в main specs и архивирован в [`specs/openspec/changes/archive/2026-08-23-harden-openspec-authority-and-lifecycle`](../../specs/openspec/changes/archive/2026-08-23-harden-openspec-authority-and-lifecycle/).
 - Затронутые Git-репозитории: frontend `d870d53` (`docs: define canonical OpenSpec store`); backend `fee4f8c` (`docs: define canonical OpenSpec store`); specs `51344d4` (`docs(specs): harden OpenSpec authority lifecycle`); docs `0bc8d1c` (`docs: document OpenSpec authority lifecycle`).
 - `bash specs/scripts/verify-openspec-authority.test.sh` — passed: positive fixture, второй OpenSpec root, implicit/conditional store selection, parenthesized invocation, archive override и framework planning location корректно отклоняются; `references/**` исключён.
 - `bash specs/scripts/verify-openspec-authority.sh` из workspace root и всех четырёх независимых repositories — `OpenSpec authority verified: wealth-ledger-specs at specs/openspec`.
 - `openspec validate harden-openspec-authority-and-lifecycle --type change --strict --store wealth-ledger-specs` — passed перед archive; `openspec validate --specs --strict --store wealth-ledger-specs` — 15 passed, 0 failed после sync/archive.
 - `git diff --check` в frontend, backend, specs и docs — exit 0 перед commits; независимый read-only review scope — Critical/Important findings отсутствуют.
 ### 2026-08-23 — WL-P1-01, WL-P1-02: `stabilize-frontend-query-and-strict-contracts`
 Статус: `done`. OpenSpec change синхронизирован в main specs и архивирован в [`specs/openspec/changes/archive/2026-08-23-stabilize-frontend-query-and-strict-contracts`](../../specs/openspec/changes/archive/2026-08-23-stabilize-frontend-query-and-strict-contracts/).
 - Затронутые Git-репозитории: frontend commit `1250581` (`fix: stabilize frontend query cache contracts`); specs commit `b8a3f96` (`docs(specs): archive frontend query remediation`).
 - `npm run verify` в `frontend` — passed: OpenAPI check, strict TypeScript check, Biome, 16 test files / 48 tests, coverage, Knip, dependency check и production build.
 - `openspec validate stabilize-frontend-query-and-strict-contracts --type change --store wealth-ledger-specs` — `Change 'stabilize-frontend-query-and-strict-contracts' is valid` перед archive.
 - `openspec validate --specs --store wealth-ledger-specs` — 14 specs passed, 0 failed перед archive.
 - `git diff --check` для staged OpenSpec archive/sync changes — exit 0.
 - Archive выполнен по явному разрешению владельца с одной незакрытой только административной задачей 4.2: она требует archive path и поэтому не могла быть закрыта до archive. Сразу после archive задача отмечена `[x]`; WL-P1-04 теперь `active` в `harden-openspec-authority-and-lifecycle`, чтобы убрать эту циклическую зависимость из будущего процесса.
 ### 2026-08-23 — bootstrap verification: `establish-audit-remediation-workflow`
 Этот process change не закрывает Audit ID. Перед archive выполнены следующие read-only checks:
 - `cmp -s audit-20-08-2026.md docs/audits/audit-20-08-2026.md` — exit 0; versioned snapshot byte-for-byte совпадает с исходной локальной копией.
 - `openspec validate establish-audit-remediation-workflow --type change --store wealth-ledger-specs` — `Change ... is valid`.
 - Структурная проверка registry — 26 records, 26 `planned`, 0 `active`, 0 `done`, одна «Следующая задача»; все четыре agent pointers и оба registry links разрешаются.
 - `git diff --check` в frontend, backend, specs и docs — exit 0.
 - Независимый read-only review registry-to-audit mapping, OpenSpec links, instruction discoverability и scope diff — `findings: none`.
 - `opsx-verify` доступен как OpenCode command, но не установлен как shell executable в этой среде; выполнена эквивалентная процедура из `.opencode/skills/openspec-verify-change/SKILL.md` с теми же dimensions completeness, correctness и coherence.
 - Change синхронизирован в main specs и архивирован в [`specs/openspec/changes/archive/2026-08-23-establish-audit-remediation-workflow`](../../specs/openspec/changes/archive/2026-08-23-establish-audit-remediation-workflow/).
@@ -1,88 +0,0 @@
 # Дизайн-система WealthLedger
 Приложение и UI-каталог используют одну визуальную основу: цветовые роли,
 типографику, интервалы, радиусы, тени и адаптивные размеры. Общая тема основана
 на Mantine; её значения не дублируются отдельно в каталоге.
 Поддерживается светлая схема, тёмная тема не заявлена.
 ## Тема и токены
 Опубликованная система включает восемь палитр по десять оттенков: blue, gray,
 dark, red, green, yellow, grape и orange; базовые white/black, оттенки
 по умолчанию и семантические роли. Общая гарнитура применяется и к заголовкам,
 стандартный радиус — средний. Настройки являются доверенной локальной частью
 приложения; загрузка внешних или пользовательских токенов не предусмотрена.
 | Роль | Цветовая основа | Применение |
 | --- | --- | --- |
 | canvas | gray.2 | Фон приложения |
 | surface | white | Поверхности и формы |
 | subtle | gray.0 | Приглушённая поверхность |
 | text | dark.7 | Основной текст |
 | muted | gray.6 | Вторичный текст |
 | border | gray.3 | Граница поверхности |
 | primary | blue filled | Основное действие и активная навигация |
 | info | blue.6 | Информация |
 | positive | green.6 | Положительный результат с текстом или знаком |
 | negative | red.6 | Ошибка или отрицательный результат с текстом или знаком |
 | warning | yellow.6 | Предупреждение; не мелкий текст на белом |
 Цвет не заменяет подпись или знак. Палитра не гарантирует доступный контраст
 произвольного сочетания текста и фона. Дополнительные grape/orange и отдельные
 оформления карточек сохраняют предметный смысл соответствующего экрана;
 они не образуют универсальную финансовую классификацию всей системы.
 Общие шкалы основаны на принятых значениях приложения и Mantine 9.5.1.
 Обновление библиотеки не заменяет их автоматически. Масштабируемые размеры,
 тени и адаптивные границы требуют сохранения единиц и визуальной проверки.
 Отдельные градиенты, тени и размеры экранов остаются локальными визуальными
 решениями; переход всех существующих значений в общую шкалу не завершён.
 Точные значения определены в [токенах приложения](../../frontend/src/shared/theme/tokens.json),
 согласованное поведение — в [спецификации дизайн-системы](../../specs/openspec/specs/frontend-design-system/spec.md).
 Эта страница объясняет их смысл, не вводя отдельную систему значений.
 ## Переносимый JSON
 Опубликованные токены представлены в собственном формате WealthLedger,
 версия 1. Это данные без исполняемого кода и зависимостей от runtime приложения.
 Совместимость с DTCG или импортом конкретного инструмента не заявлена.
 | Данные | Представление |
 | --- | --- |
 | Цвета | Hex, палитры оттенков 0–9 и именованные базовые цвета |
 | Семантические роли | Ссылка на цвет и оттенок, описание; отсутствие оттенка палитры означает основной оттенок светлой схемы |
 | Типографика | Наборы шрифтов, размеры в px, числовые веса и безразмерная высота строки |
 | Интервалы и радиусы | Именованные шкалы xs–xl в px и выбранный радиус по умолчанию |
 | Тени | Упорядоченные слои: смещения, размытие и растяжение в px, базовый цвет и непрозрачность |
 | Адаптивные границы | Именованные размеры xs–xl в em, независимые от масштаба интерфейса |
 Перенос в другую систему требует сопоставления единиц, шрифтов, слоёв теней
 и семантических ссылок. Само чтение JSON не обеспечивает такой совместимости.
 Несовместимое изменение формата требует новой версии; внешняя интеграция,
 генератор артефактов и публикация пакета пока не реализованы.
 ## Общие компоненты
 | Представление | Поведение и ограничения |
 | --- | --- |
 | Пустой результат или ошибка | Заголовок, пояснение и необязательное действие; ошибка объявляется вспомогательным технологиям, кнопка имеет доступное название |
 | Загрузка | Доступная область состояния занятости с пояснением и декоративными фигурами без фокуса; структура отражает ожидаемый экран |
 | Действия | Основной, вторичный и вспомогательный варианты; состояния выполнения и недоступности |
 Общие представления не получают финансовые данные и не управляют
 аутентификацией. Состояние выполнения действия отличается от загрузки всей
 страницы. При фоновом обновлении доступные данные сохраняются с локальным
 индикатором; правила восстановления описаны в
 [UI resilience](../architecture/cross-cutting/ui-resilience.md).
 Каркас с продуктовой навигацией не входит в заявленный общий набор.
 Предметные карточки и композиции представлены в [UI-каталоге](ui-catalog.md).
 ## Границы доказательств
 Каталог использует вымышленные данные и локальные действия без входа,
 сохранённого пользовательского состояния и application API. Проверки отделяют
 его от исполнения продуктовых запросов. Вид, размеры, фокус и взаимодействия
 проверяются в браузере; каталог не доказывает восстановление реального API
 или прохождение инвестиционного сценария.
@@ -1,82 +0,0 @@
 # Принципы изменения и проверки системы
 Ожидаемый результат определяется задачей пользователя. Сопровождение сохраняет
 ответственность подсистем, безопасность, точность данных и проверяемость результата.
 OpenSpec остаётся [необязательным средством согласования](openspec-authority-and-lifecycle.md);
 исторические свидетельства не становятся обязательной процедурой новой задачи.
 ## Выбор реализации
 Связное поведение принадлежит ответственной подсистеме. Существующая возможность
 используется повторно, если сохраняет нужный смысл и инварианты. Новая граница
 оправдана самостоятельной ответственностью, общей потребностью нескольких
 потребителей либо необходимостью отделить доступ и целостность данных.
 Простота оценивается по ясности всей системы и стоимости сопровождения,
 а не по размеру изменения. Предполагаемая будущая возможность сама по себе
 не оправдывает новую подсистему. Упрощение сохраняет валидацию, доступность,
 обработку ошибок и защиту от потери данных.
 ## Dependencies
 При выборе внешней зависимости учитываются текущая потребность, совместимость,
 поддержка, безопасность и стоимость сопровождения. Использование принятой
 платформы может быть проще собственной реализации; зависимость ради одной
 воображаемой будущей возможности не является самостоятельной потребностью.
 Новый сервис или общая инфраструктура должны решать актуальную задачу.
 ## Risk-based testing
 Изменения безопасности и приватности, денежных расчётов, целостности данных,
 миграций, конкурентного доступа, публичного контракта, критического сценария
 и подтверждённой регрессии требуют автоматической проверки соответствующего
 риска на наблюдаемой потребителем границе.
 Статические проверки не доказывают финансовую или функциональную корректность.
 Покрытие frontend служит ограничителем регрессий; для backend общего числового
 порога нет. Проверки поведения библиотеки или проценты сами по себе не заменяют
 проверку собственного инварианта системы.
 ## Проверка результата
 Результат оценивается по исходной задаче: сохранены ли смысл данных и контракты,
 правильно ли разграничен доступ, учтены ли ошибки и доступность интерфейса.
 При изменении HTTP-контракта backend обновляет публичный OpenAPI, а frontend
 проверяет соответствие generated types полученному snapshot согласно
 [OpenAPI contract flow](runtime-openapi-verification.md). Общего CI сейчас нет.
 Успешная проверка применима к тому состоянию системы и тем предпосылкам,
 на которых выполнена. При их изменении старое свидетельство не доказывает
 новый результат. Автоматическое исправление материалов и проверка без их
 изменения — разные действия.
 [Влияние на документацию](../CONTRIBUTING.md#обновление-вместе-с-кодом) входит
 в оценку результата: описанные понятия, сценарии, решения и ограничения
 обновляются вместе с системой. Отсутствие влияния может быть обоснованным
 результатом. Отчёт о поставке различает выполненное, проверенное и остающиеся
 ограничения; количество формальных отметок не заменяет смысловую проверку.
 ## Guardrails и local gates
 Автоматические проверки гарантируют только свойства, охваченные их областью.
 Смысловые требования — например, правильный владелец данных, авторизация,
 локализация и полезность выбранных проверок — требуют отдельной оценки.
 Предпочтение между равноценными вариантами отличается от обязательного
 инварианта. Новая автоматизация оправдана реальным риском или повторяющимся
 дефектом; её наличие само по себе не является целью.
 ## UI-решения
 Ожидаемые экраны, состояния, взаимодействия и поведение на разных размерах
 экрана определяются пользовательским сценарием. [Каталог](ui-catalog.md)
 и [дизайн-система](design-system.md) показывают существующую визуальную основу.
 Неоднозначный вариант можно оценить по конкретному примеру до реализации.
 Успешная сборка каталога не доказывает доступность и визуальное соответствие.
 ## Изменение опасного контракта
 Для публичного контракта, безопасности, данных, платежей и труднообратимого
 изменения существенная неопределённость разрешается до применения решения.
 Для миграции важны условия отката, сохранность уже созданных данных и проверка
 восстановления. Порядок разрешения конфликтов знаний описан в
 [контексте системы](agent-token-efficiency.md#источники-и-конфликты).
@@ -1,131 +0,0 @@
 # Локальное окружение и восстановление
 WealthLedger поставляется как локальное приложение: frontend работает
 в браузере, backend обслуживает API и обращается к SQLite и внешним источникам.
 Это описание предпосылок и ограничений работы, без привязки к устройству
 исходного кода. Описано локальное окружение; production-топология по нему
 не подтверждается.
 ## Версия Node
 Все локальные проверки используют Node 24 LTS; `.nvmrc` в frontend, backend
 и docs фиксирует 24.21.0. Specs использует frontend `.nvmrc`.
 По [официальному расписанию Node](https://github.com/nodejs/Release#release-schedule)
 поддержка Node 24 завершается 30.04.2028.
 В каждом npm-репозитории выполните `nvm install`, `nvm use --silent` и `npm ci`;
 в backend затем `npm run build` для генерации Prisma client.
 Поставляемый npm 11.19 запускает dependency install scripts только по
 `allowScripts` в package.json; разрешения привязаны к версиям сборочных
 зависимостей и пересматриваются при их обновлении.
 После смены major обязательна переустановка native modules через `npm ci`.
 Для отката верните прежние runtime/package/lockfile-конфигурации, выберите Node 22
 и повторите `npm ci` и backend build. Сам переход Node не меняет схему или данные.
 ## Подготовка backend
 Локальная серверная среда использует Node 24 и SQLite. Для работы нужны:
 | Параметр | Назначение и ограничение |
 | --- | --- |
 | Адрес локальной базы | Одинаковая база используется при подготовке схемы и работе приложения; относительный адрес зависит от рабочей директории процесса |
 | Разрешённый origin frontend | Определяет browser-источник, которому разрешён доступ к API с credentials |
 | Порт API | По умолчанию 3000 |
 | Секрет подписи сессий | Секрет не короче 32 символов; отличается от ключа шифрования подключения |
 | Ключ шифрования подключения | 32 байта в base64; требуется для чтения сохранённого T-Bank token |
 | Параметры интеграции | Адрес T-Bank, лимит запросов и при необходимости доверенный CA; [ограничения](../integrations/tbank.md#конфигурация-и-ограничения) |
 T-Bank token вводится пользователем через интерфейс после входа и не является
 общим параметром окружения. Существующая база и её ключ шифрования сохраняются
 при обновлении. До миграции необходима резервная копия; восстановление проверяется
 на отдельной копии. Потеря или замена ключа не является безвредным сбросом:
 прежнее подключение нельзя расшифровать новым ключом.
 После подготовки зависимостей и конфигурации примените штатные migrations:
 из backend после `nvm use --silent` выполните `npx prisma migrate deploy`.
 Для существующей базы сначала сохраните согласованный backup.
 На Node 22.21.0 / Prisma 7.9.1 обнаружена зависимость fresh migration от
 унаследованного `RUST_LOG=warn/error`. Backend Prisma config исключает эту
 переменную из процесса CLI; назначать `RUST_LOG=info` больше не требуется.
 Условия и доказательство — в
 [сквозной проверке](verification.md#известное-ограничение-сквозной-проверки).
 В development доступна [локальная Swagger UI](http://localhost:3000/api/docs)
 при стандартном порте API. Она показывает контракт, но не доказывает доступность
 T-Bank и не используется frontend как источник данных во время работы.
 ## Подготовка frontend
 Стандартные адреса: API `http://localhost:3000`, frontend `http://localhost:5173`.
 Адрес API в клиенте должен совпадать с работающим сервером, а разрешённый origin
 backend — с origin браузера. Смена порта требует согласованного изменения
 адресов. Смесь `localhost` и `127.0.0.1` меняет границу browser cookie и CORS.
 Локальный HTTP предполагает development-режим backend: в других режимах
 refresh-cookie получает Secure flag и требует защищённого соединения.
 Поведение сессии описано в [Authentication](../domains/authentication/overview.md).
 ## Первый сценарий
 1. Пользователь регистрируется или входит. Новый профиль получает сессию;
   после перезагрузки приложение пытается её восстановить.
 2. В настройках пользователь сохраняет собственный T-Bank Invest token.
   Успех означает проверенный доступ к брокеру и сохранённое подключение.
 3. В разделе «Счета» доступны отдельный и общий портфель. Отсутствие доступных
   счетов является допустимым пустым результатом.
 4. «Доходы» показывают полученные выплаты, «События» — будущие.
 5. При выходе локальная сессия и её клиентский кэш очищаются.
 Без T-Bank token доступны регистрация, вход, состояние отсутствующего
 подключения и [ручной банковский учёт](../domains/cards/overview.md).
 Банковский сценарий не подтверждает доступность инвестиционных поставщиков.
 ## Сохранение данных и откат
 Перед обновлением сохраняется согласованный SQLite backup; ключ шифрования
 T-Bank хранится отдельно. Для работающей базы используется SQLite backup API,
 который учитывает WAL. Несогласованное копирование файлов базы и WAL не является
 резервной копией. Восстановление сначала проверяется на отдельном файле.
 Банковская миграция добавляет таблицы, сохраняя User, Session и TbankConnection.
 При необходимости отката приложения сначала прекращаются новые записи и
 сохраняется актуальный снимок. Затем возвращается совместимая предыдущая версия
 backend при сохранении расширенной схемы. Старый backup не восстанавливается
 поверх новой истории: это удалило бы введённые банковские операции.
 Совместимость проверена с исходной версией backend
 `8ec172f48eefa2237dc0c16919fbb2e726b39a65`: она выполняла вход с расширенной
 схемой, а новая версия после возврата читала прежние карты и операции.
 Отдельно проверены перезапуск, служебные данные защиты повторов и приложение
 на восстановленной SQLite-копии. Это подтверждение конкретной пары версий,
 а не гарантия совместимости любого будущего изменения схемы.
 Проверка воспроизводится через
 [процессный сценарий](../../backend/test/bank-cards-durability.cjs)
 с каталогом отдельно собранного baseline: после активации backend `.nvmrc`
 выполнить `node test/bank-cards-durability.cjs <baseline-directory>`.
 Сценарий создаёт собственные временные базы и вымышленные данные. Migrations
 и HTTP/DB-ограничения описаны в [проверке системы](verification.md).
 ## Если запуск или сценарий не работает
 | Симптом | Проверка и безопасное восстановление |
 | --- | --- |
 | Порт занят | Адрес действующего процесса или выбранный свободный порт должен совпадать с настройками клиента и разрешённым origin |
 | Ошибка CORS или сессия теряется после reload | Согласованность адресов, hostname и режима cookie проверяется на стороне browser и backend |
 | Ошибка подготовки базы | Сохранить версию среды и текст ошибки; использовать backend Prisma config, не удалять пользовательскую базу и не обходить migrations |
 | `TBANK_NOT_CONNECTED` | Подключение создаётся в настройках текущего пользователя |
 | `INVALID_TBANK_TOKEN` | После проверки token и прав у брокера подключение заменяется через настройки |
 | `TBANK_UNAVAILABLE`, TLS или rate limit | Проверяются сеть, лимиты и доверенный CA; проверка TLS сохраняется |
 | НКР/MOEX недоступен при работающих остальных секциях | Состояние источника и повторная попытка относятся к конкретной секции; недоступность не означает отсутствия рейтинга |
 | Подключение не читается после смены ключа | Восстанавливается прежний ключ из защищённой копии; если он утрачен, собственный token вводится заново через настройки |
 HTTP-запросы связываются с безопасными журналами через `X-Request-ID`.
 Пароли, cookies, Authorization и broker token не включаются в диагностический
 отчёт. Ограничения журналирования — [ADR 008](../adr/008-pino-backend-logging.md).
 ## Проверка первого изменения
 Успешная сборка, запуск и прохождение сценария — разные доказательства.
 Границы [проверок системы](verification.md) и
 [OpenAPI contract flow](runtime-openapi-verification.md) рассматриваются отдельно.
 Завершённость результата учитывает фактические проверки и остающиеся ограничения.
@@ -1,31 +0,0 @@
 # OpenSpec: роль требований и история процесса
 Обязательный SDD lifecycle отменён для обычной разработки согласно
 [ADR 012](../adr/012-task-driven-development-with-scoped-context.md).
 Задача пользователя определяет ожидаемый результат; дополнительные planning
 artifacts и архивирование не являются условием её завершения.
 ## Существующие материалы
 Основные спецификации сохраняют согласованное проверяемое поведение, включая
 текущее. OpenSpec changes содержат предложения, их дизайн и задачи, архив —
 историю согласования. Store `wealth-ledger-specs` находится в `specs/openspec/`:
 основные спецификации — `specs/`, изменения — `changes/` внутри Store.
 [Предметный индекс](../../specs/AI_INDEX.md) ведёт к конкретным requirements/scenarios.
 Существующее описание изменения относится только к своему объёму и не доказывает
 готовность возможности. Docs объясняет систему и последствия правил;
 при расхождении со спецификацией нужно установить причину, а не объявлять
 реализацию или текст автоматически верным.
 ## Если OpenSpec запрошен явно
 OpenSpec остаётся необязательным средством согласования требований, дизайна
 и задач. Его собственная модель определяет состав и порядок артефактов;
 подтверждение человеком и смысловая проверка результата не выводятся из
 одного наличия файлов. Обновление требований и архивирование меняют историю,
 поэтому относятся к явно выбранной работе с этой историей.
 Причины прежнего процесса и его упрощения сохранены в
 [ADR 010](../adr/010-native-openspec-sdd-and-local-orchestration.md) и
 [ADR 011](../adr/011-native-openspec-lifecycle-with-repository-gates.md).
@@ -1,46 +0,0 @@
 # OpenAPI contract flow
 ## Назначение
 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).
 Frontend не проверяет, что переданный snapshot совпадает с текущим backend
 runtime OpenAPI, не фиксирует пару frontend/backend SHA и не зависит от пути к
 соседнему backend checkout. Подготовка и доставка актуального OpenAPI-документа
 находятся вне frontend.
 ## Выбор и направление изменения
 Изменением контракта считается изменение маршрута, входного или выходного поля,
 статуса либо формы ошибки. Внутреннее изменение представления без изменения
 API не требует нового описания контракта.
 Направление согласования: публичный API backend → предоставленный OpenAPI →
 frontend snapshot → generated types. Две независимо редактируемые версии
 контракта создавали бы риск расхождения. Перед изменением, влияющим на
 совместимость, учитываются существующие потребители и сохранность данных.
 Семантика запросов и ошибок описана в [HTTP API](../architecture/http-api.md).
 ## Границы и результат
 Frontend-команда генерации читает только committed snapshot и обновляет
 generated types. Frontend-проверка генерирует types из этого snapshot во
 временный каталог и сравнивает результат с committed generated artifact.
 Несовпадение означает, что snapshot и generated types в frontend расходятся.
 Эта проверка не доказывает актуальность snapshot относительно backend. Это
 принятое допущение, а не свойство frontend gate. Она также не доказывает
 фактическую работу валидации, авторизации, статусов, cookie и обработки ошибок:
 для этого нужны наблюдения полного HTTP-потока.
 ## Граница runtime
 Работающий frontend использует сгенерированные types и обычные HTTP-запросы к
 API. Swagger или OpenAPI endpoint не являются runtime-зависимостью SPA.
 Полные HTTP-сценарии и хранение данных проверяются отдельными backend-gates;
 локальный frontend gate выполняется без backend.
@@ -1,77 +0,0 @@
 # UI-каталог Storybook
 Storybook 10.6.0 показывает реальные представления WealthLedger на общей
 визуальной основе приложения без входа и подключения backend.
 ## Запуск и сборка
 Каталог работает как отдельная локальная витрина по адресу
 [localhost:6006](http://localhost:6006) либо как самостоятельная статическая
 сборка. Его примеры не входят в пользовательские маршруты приложения.
 Публикация отдельным сервисом не настроена.
 ## Компоненты и работа с примерами
 Каталог включает 14 групп и 54 примера:
 | Группа | Что показывает |
 | --- | --- |
 | Основы дизайн-системы | Палитры, семантические роли, типографику, интервалы, радиусы, тени и адаптивные размеры |
 | Пустой результат и ошибки | Четыре варианта с действием и без |
 | Загрузка | Доступную область занятости с нейтральными фигурами |
 | Кнопки | Основное, вторичное и вспомогательное действие, выполнение и недоступность, работу с клавиатурой |
 | Список счетов | Несколько счетов и валют, недоступную и пустую сводку, неоценённые бумаги, длинные названия и суммы |
 | Карточка позиции | Акцию с положительным результатом, облигацию с отрицательным, прочий инструмент и отсутствие оценки |
 | Ближайшие события | Успешный, загружаемый, ошибочный и пустой результат; неизвестную сумму и длинное название |
 | Обновление портфеля | Сохранённые суммы при обновлении и ошибке, локальную повторную попытку |
 | Загрузка страницы счёта | Контур ожидаемых заголовка, сводки и строк |
 | Структура портфеля | Валюты и типы активов, только деньги, пустую и неполную оценку, неизвестные и отрицательные значения |
 | Сводка банковских карт | Компактные расходы по категориям, отрицательный месяц возврата, известные нули, загрузку, ошибку, сохранённые суммы и длинные точные итоги |
 | Внешний вид банковской карты | Цвета банков, маскированный номер, платёжные системы, отсутствующие реквизиты и длинные названия в архиве |
 | Иконки банковских операций | Пиктограммы категорий расходов, общую иконку нестандартной категории и пополнение |
 | Поля банковской карты | Независимую рублёвую карту и недоступные финансовые поля архива |
 Каталог не перечисляет все элементы библиотеки или приложения. Отсутствие
 представления в витрине не означает его отсутствия в продукте. Основы показывают
 опубликованные шкалы и смысл ролей; особые размеры и тени конкретных экранов
 не объявляются общими токенами. Границы описаны в [дизайн-системе](design-system.md).
 Canvas показывает выбранный пример. Docs поясняет назначение и ограничения,
 Controls меняет доступные свойства, Actions показывает локальные действия.
 Наборы вымышленных данных и доступные Controls определяются конкретным
 примером; подготовленные варианты перечислены в историях. Свойства можно сбросить, пример —
 смонтировать заново; изменение размера просмотра не сбрасывает выбранные значения.
 Витрина и приложение используют одну тему. Примеры показываются по-русски
 в светлой схеме. Ошибка сохраняет доступное объявление, загрузка — состояние
 занятости; декоративные фигуры не получают фокус.
 ## Границы и сопровождение
 Все счета, позиции, события и суммы вымышлены. Каталог не читает сессии,
 cookies, секреты и реальные пользовательские данные. Вместо внешних логотипов
 показываются буквенные заглушки. Сама витрина может сохранять свои настройки;
 телеметрия отключена.
 Действия не обращаются к application API. Ссылки меняют только локальное
 состояние примера, не открывают продуктовую страницу назначения и не меняют
 адрес приложения. Повторная попытка демонстрирует локальное действие и не
 доказывает восстановление реального запроса.
 Сохранённые суммы иллюстрируют Client Cached Snapshot, но его жизненный цикл
 здесь не исполняется. В приложении первичная загрузка показывает контур
 ожидаемого содержимого, фоновое обновление сохраняет данные, а выполняемое
 действие имеет контекстный индикатор. Подробности —
 [состояния интерфейса](../architecture/cross-cutting/ui-resilience.md).
 Автоматические проверки frontend охватывают каталог и его изоляцию от
 продуктовых запросов. Примеры и их пояснения обновляются вместе с включёнными
 представлениями. Клавиатура, реальные размеры и визуальное соответствие
 проверяются в браузере; автоматической визуальной регрессии нет.
 ## Использование в UI задаче
 Каталог помогает сравнить существующие состояния с ожидаемым пользовательским
 сценарием. Он дополняет [принципы UI-решений](engineering-governance.md#ui-решения)
 конкретными примерами, но успешная сборка не доказывает доступность,
 визуальное соответствие и работу настоящего API.
@@ -1,66 +0,0 @@
 # Что подтверждают проверки системы
 Успешная сборка, запуск, равенство схем и прохождение пользовательского
 сценария — разные доказательства. Выбор проверки зависит от наблюдаемого
 риска: денежных вычислений, доступа, целостности данных или состояния интерфейса.
 Общие основания описаны в [принципах сопровождения](engineering-governance.md#risk-based-testing).
 ## Интерфейс
 Локальный gate frontend охватывает типы, статический анализ, автоматические
 сценарии, зависимости и сборки приложения и UI-каталога. Он выполняется
 без запущенного backend. Покрытие ограничивает регрессии, но не доказывает
 правильность финансового расчёта, доступность и полный пользовательский сценарий.
 [Каталог](ui-catalog.md) показывает существующие визуальные решения на
 вымышленных данных. Широкий и узкий экран, клавиатурная навигация,
 восстановление после ошибок и соответствие задаче проверяются в интерфейсе
 отдельно от сборки. Изолированная тестовая среда не воспроизводит все свойства
 браузера и живой интеграции.
 ## API и хранение данных
 Локальный gate backend объединяет статический анализ, типы приложения и тестов,
 автоматические сценарии и сборку. Он не исправляет исходные файлы;
 автоматическое форматирование выполняется отдельно и не является доказательством.
 Диагностика покрытия доступна без общего числового порога.
 Frontend OpenAPI check подтверждает только соответствие generated types
 сохранённому snapshot. Актуальность snapshot относительно backend принимается
 как входное допущение. Валидация, cookie, авторизация счёта, статусы и ошибки
 требуют полного HTTP-потока; целостность и конкурентные изменения данных —
 проверки с изолированной реальной базой. Подставной ответ базы не доказывает её
 транзакционные свойства. Направление генерации описано в
 [OpenAPI contract flow](runtime-openapi-verification.md).
 ### Известное ограничение сквозной проверки
 Прежний blocker WL-P2-05 снят в конфигурации Prisma: на Node 22.21.0 /
 Prisma 7.9.1 унаследованный `RUST_LOG=warn` или `error` воспроизводит пустой
 `Schema engine error`, а отсутствие переменной позволяет fresh migration.
 Backend Prisma config удаляет переменную в процессе CLI после загрузки `.env`;
 это не меняет application logging. Версии зависимостей и SQL history сохранены.
 `npm run test:e2e` применяет migrations и запускает каждую HTTP suite на отдельной
 временной DB. Один URL передаётся Prisma и Jest; прямой запуск Jest без runner
 отклоняется до DB-запросов. При ошибке и SIGINT/SIGTERM выполняется cleanup.
 `npm run test:sqlite` выбирает auth/cards; `test:durability` отдельно проверяет
 migration, restart, возврат предыдущего приложения и backup/restore.
 Команды и runnable regression — в
 [backend README](../../backend/README.md#реальная-sqlite-и-сохранность-данных),
 фактические результаты — в
 [registry](audit-remediation.md#2026-09-13--wl-p2-05-воспроизводимый-sqlite-e2e).
 Backend `verify` остаётся статическим/unit/build gate; полный HTTP/DB scope
 проверяется отдельным `test:e2e`. Успех этих команд не подтверждает доступность
 внешнего T-Bank. HTTP tests требуют локальных портов, которые sandbox может
 запрещать. Безопасное сохранение реальных данных — в
 [локальном окружении](local-workspace.md).
 ## Где выполнять проверки
 Команды и конкретные тестовые правила поддерживаются в локальных инструкциях
 [frontend](../../frontend/AGENTS.md) и [backend](../../backend/AGENTS.md).
 Проверки этой документации — в [CONTRIBUTING](../CONTRIBUTING.md#проверки).
 Отчёт различает пройденную границу, оставшееся ограничение и проверяемое состояние;
 успех одного gate не распространяется автоматически на весь workspace.
@@ -72,11 +72,11 @@ sequenceDiagram
 ## HTTP-граница
 Endpoints, статусы и формы публичных ответов определяет backend OpenAPI;
-согласование производного клиента описано в
+граница производного клиента описана в
-[contract workflow](../../development/runtime-openapi-verification.md).
+[HTTP API](../../architecture/http-api.md#источник-контракта).
 Refresh-cookie ограничена auth API. Признак Secure зависит от режима
-окружения: локальный HTTP предполагает development mode, см.
+окружения: в development допускается локальный HTTP, в остальных режимах
-[локальное окружение](../../development/local-workspace.md).
+Secure-cookie требует защищённого соединения.
 HTTP-ошибка и транспортная ошибка refresh одинаково завершают начальное
 восстановление готовым неавторизованным состоянием. При refresh после
@@ -136,10 +136,10 @@ JavaScript Number. Отдельный ввод ограничен signed64: на
 а форма сохраняет черновик и позволяет получить актуальную запись.
 При ошибке сохранения неподтверждённые суммы не выдаются за новый баланс.
-[Безопасное восстановление](../../development/local-workspace.md#сохранение-данных-и-откат)
+[Безопасное восстановление](../../architecture/containers.md#сохранение-и-восстановление-данных)
 сохраняет новую финансовую историю и при откате приложения. Устройство хранения
 описано в [контейнерах](../../architecture/containers.md#хранимые-данные-и-границы-доступа).
-Согласованный контракт этой поставки находится в
+Согласованный контракт банковского учёта находится в
 [manual-bank-cards](../../../specs/openspec/changes/add-manual-bank-cards/specs/manual-bank-cards/spec.md).
 Автоматическая загрузка банковских данных, кредитные карты, другие валюты,
 бюджеты и общий баланс банковских денег с инвестициями в эту версию не входят.
@@ -94,23 +94,6 @@ Frontend проверяет принадлежность выплат по по
 операций остаются отдельными строками; повторные вхождения учитываются раздельно, а изменение источника логотипа
 позволяет заново показать изображение после буквенной заглушки.
 ## Совместимость ответа
 При обновлении с версии без `instrumentKey` сначала обновляется backend:
 дополнительное поле совместимо с прежним
 frontend. Затем синхронизируются OpenAPI snapshot/generated types и обновляется
 клиент. При переключении клиент перезагружается, чтобы не переносить
 старые результаты в памяти и незавершённые запросы. Новый frontend требует новый
 backend; отсутствие ключа принадлежности не скрывается подстановкой прежней формулы.
 При регрессии сначала возвращается прежний frontend вместе с соответствующим
 snapshot/types и перезагружается клиент; затем при необходимости возвращается
 backend. Старый frontend может временно работать с новым ответом с добавленным полем.
 Календарные фильтры и отдельные карточки выплат используют тот же контракт и не требуют
 дополнительного обновления backend. Схема SQLite, учётные данные и сообщённые брокером
 операции не меняются: откат
 не удаляет данные, производные результаты запрашиваются заново.
 ## Будущие события и ограничения
 На странице дохода нет блоков «Динамика» и «Ближайший прогноз». Она не запрашивает
@@ -146,10 +146,12 @@ Backend хранит token в шифротексте AES-256-GCM с новым n
 metadata. При перегруженной очереди необязательные имена могут быть заменены
 идентификаторами; это не доказывает потерю самой позиции. Изменение локального
 лимита требует учёта разрешённой квоты T-Bank: оно не увеличивает квоту
-поставщика. Диагностика соединения описана в
+поставщика.
 [локальном окружении](../development/local-workspace.md).
-Ключ шифрования не ротируется автоматически. Лимитер и кэши принадлежат
+Ключ шифрования не ротируется автоматически. Новый ключ не расшифрует
 прежнее подключение: нужен исходный ключ либо повторный ввод собственного
 token через настройки. Правила [резервного копирования](../architecture/containers.md#сохранение-и-восстановление-данных)
 учитывают отдельное хранение ключа. Лимитер и кэши принадлежат
 одному экземпляру; изменения подключения не координируются между
 распределёнными экземплярами backend. Интеграция использует сохранённый
 protobuf-контракт T-Bank: обновление внешнего протокола и проверка