docs(specs): archive documentation entrypoints remediation

openspec/specs/project-documentation/spec.md

@@ -48,3 +48,44 @@
 #### Scenario: Agent планирует незавершённый change
 - **WHEN** агент создаёт requirements, design или tasks для незавершённого изменения
 - **THEN** он сохраняет их под `specs/openspec` и не создаёт framework-specific planning document в `docs`
+
+### Requirement: Устойчивая документация имеет доступные фактические точки входа
+Репозиторий `docs` SHALL содержать indexes архитектуры, разработки и фич,
+которые ведут разработчика или AI-агента к фактической устойчивой документации
+без обращения к архивированному change или корневому delivery-plan файлу.
+Архитектурная документация MUST содержать system overview поставленных
+возможностей и локальных границ, канонический domain glossary, а также
+Mermaid-диаграммы потоков auth/session и T-Bank → клиент. Feature documentation
+MUST предоставлять index поставленных фич и MUST NOT описывать поставленные
+Brokerage Accounts, Portfolio, Account Ledger или Future Cash Events как
+отложенные.
+
+#### Scenario: Новый участник находит поставленную систему
+- **WHEN** новый участник открывает устойчивую документацию
+- **THEN** он может перейти из index к system overview, glossary, документам
+  поставленных фич и соответствующему development workflow
+
+#### Scenario: Участник различает близкие доменные понятия
+- **WHEN** участнику нужно описать cached portfolio data или account operation
+- **THEN** канонический glossary различает Client Cached Snapshot и Portfolio
+  Snapshot, а также Future Cash Event и Ledger Entry
+
+### Requirement: README репозиториев являются компактными onboarding entrypoints
+Репозитории frontend и backend SHALL предоставлять русскоязычные README
+entrypoints, которые указывают Node 22, lockfile-safe bootstrap, локальные
+non-mutating verification commands, требуемую локальную configuration и ссылки
+на authoritative или just-in-time documentation. README MUST различать deferred
+check и passing verification gate, а detailed rationale deferred Prisma e2e и
+его review trigger MUST быть ссылкой на remediation registry, а не дублироваться.
+
+#### Scenario: Участник bootstrap-ит application repository
+- **WHEN** участник открывает frontend или backend README на чистой локальной
+  машине
+- **THEN** он может определить требуемый runtime, подготовить local
+  configuration, установить зависимости из lockfile и запустить
+  документированные local gates без угадывания
+
+#### Scenario: Участник видит ограничение backend e2e
+- **WHEN** участник читает backend onboarding instructions
+- **THEN** он узнаёт, что Prisma e2e gate отложен, и может перейти к
+  remediation registry за его точным статусом и review trigger

openspec/specs/project-foundation/spec.md

@@ -7,26 +7,46 @@
 ## Requirements
 
 ### Requirement: Репозитории содержат локальные инструкции для AI-агентов
-Система SHALL содержать обзорный `AGENTS.md` в корне рабочей области и отдельный `AGENTS.md` в репозиториях frontend, backend, specs и docs. Инструкции MUST описывать назначение области, локальные команды проверки, границы ответственности и связь с SDD-артефактами. Каждая инструкция MUST объявлять `wealth-ledger-specs` и `specs/openspec` как canonical OpenSpec authority, требовать явный `--store wealth-ledger-specs` для поддерживаемых OpenSpec операций и запрещать versioned framework-specific planning artifacts вне canonical store. Локальные инструкции MUST направлять агента к durable remediation registry, когда задача связана с findings технического аудита. Backend instructions MUST различать non-mutating verification commands и явные auto-fix commands.
+Система SHALL содержать обзорный `AGENTS.md` в корне рабочей области и
+отдельный `AGENTS.md` в репозиториях frontend, backend, specs и docs.
+Инструкции MUST описывать назначение области, локальные команды проверки,
+границы ответственности и связь с SDD-артефактами. Каждая инструкция MUST
+объявлять `wealth-ledger-specs` и `specs/openspec` как canonical OpenSpec
+authority, требовать явный `--store wealth-ledger-specs` для поддерживаемых
+OpenSpec операций и запрещать versioned framework-specific planning artifacts
+вне canonical store. Локальные инструкции MUST направлять агента к durable
+documentation, относящейся к его области, и к durable remediation registry,
+когда задача связана с findings технического аудита. Backend instructions MUST
+различать non-mutating verification commands и явные auto-fix commands.
 
 #### Scenario: Агент начинает работу в отдельном репозитории
-- **WHEN** агент открывает любой из репозиториев frontend, backend, specs или docs
-- **THEN** он может определить локальные правила работы, canonical OpenSpec authority и источник связанных спецификаций из `AGENTS.md` этого репозитория
+- **WHEN** агент открывает любой из репозиториев frontend, backend, specs или
+  docs
+- **THEN** он может определить локальные правила работы, canonical OpenSpec
+  authority, источник связанных спецификаций и относящийся к области durable
+  documentation из `AGENTS.md` этого репозитория
 
 #### Scenario: Агент получает audit-derived задачу из отдельного репозитория
 - **WHEN** задача ссылается на finding технического аудита
-- **THEN** локальный `AGENTS.md` указывает на remediation registry и canonical OpenSpec workflow с явным store selection до начала изменения кода
+- **THEN** локальный `AGENTS.md` указывает на remediation registry и canonical
+  OpenSpec workflow с явным store selection до начала изменения кода
 
 #### Scenario: Агент выбирает backend quality gate
 - **WHEN** агент читает backend instructions перед локальной проверкой
-- **THEN** он запускает документированные non-mutating lint/typecheck commands и не получает auto-fix как неявный quality gate
+- **THEN** он запускает документированные non-mutating lint/typecheck commands
+  и не получает auto-fix как неявный quality gate
 
-### Requirement: Локальный план MVP не является источником спецификации
-Система SHALL содержать корневой локальный `MVP.md` с границами MVP, принятыми решениями, порядком поставок и критериями готовности. Требования к функциональности MUST храниться в OpenSpec, а устойчивая документация MUST храниться в репозитории docs. Frontend и backend MUST требовать Node 22 и документировать lockfile-safe bootstrap через `npm ci`.
+### Requirement: Корень рабочей области не хранит delivery-plan файл
+Корень рабочей области MUST NOT содержать `MVP.md` или другой versioned
+delivery-plan файл как источник требований, порядка поставки или фактического
+поведения. Требования SHALL оставаться в OpenSpec, а delivered system overview
+и долговечные ограничения SHALL находиться в `docs`. Frontend и backend MUST
+требовать Node 22 и документировать lockfile-safe bootstrap через `npm ci`.
 
-#### Scenario: Решение уточняется во время SDD-изменения
-- **WHEN** изменение уточняет наблюдаемое поведение системы
-- **THEN** оно фиксируется в OpenSpec и соответствующей документации, а `MVP.md` остается компактной картой поставки
+#### Scenario: Агент определяет границы поставленной системы
+- **WHEN** агент начинает работу и ищет актуальные границы WealthLedger
+- **THEN** он находит их в durable documentation и canonical OpenSpec, а не в
+  корневом delivery-plan файле
 
 #### Scenario: Агент bootstrap-ит application repository
 - **WHEN** агент начинает локальную проверку frontend или backend на чистой машине