spec: require RUB-only behavior (WealthLedger/main#55) (#86 )

spec: plan investment performance vs Moscow Exchange index (WealthLedger/main#54) (#85 )
chore(release): 0.2.1
2026-11-11 09:20:25 +03:00 · 2026-11-08 16:30:32 +03:00 · 2026-11-06 07:41:32 +03:00 · 2026-11-05 07:16:08 +03:00 · 2026-11-03 14:07:42 +03:00 · 2026-11-03 07:45:09 +03:00
184 changed files with 14341 additions and 2977 deletions
@@ -0,0 +1,12 @@
+---
+name: Bug Report
+about: Неверное поведение
+---
+## Проблема и шаги воспроизведения
+
+## Факт / ожидание
+
+## Acceptance Criteria
+- [ ]
+
+## Окружение / ссылки (если применимо)
@@ -0,0 +1,10 @@
+---
+name: Engineering Task
+about: CI, тесты, документация, процесс и прочее
+---
+## Контекст и результат
+
+## Scope / связанные Issues (если есть)
+
+## Acceptance Criteria
+- [ ]
@@ -0,0 +1,12 @@
+---
+name: Feature Request
+about: Новое наблюдаемое поведение
+---
+## Зачем и какой результат
+
+## Ожидаемое поведение
+
+## Acceptance Criteria
+- [ ]
+
+## Зависимости / связанные Issues (если есть)
@@ -0,0 +1,12 @@
+---
+name: Refactoring / Technical Debt
+about: Улучшение без нового поведения
+---
+## Проблема и результат
+
+## Сохраняемые инварианты / границы
+
+## Acceptance Criteria
+- [ ]
+
+## Зависимости / ссылки (если есть)
@@ -0,0 +1,11 @@
+## Summary
+
+## Linked Issue
+Refs
+
+## Changes
+
+## Verification
+- Команда / результат / ограничения:
+
+## Breaking Changes (если есть)
@@ -4,6 +4,10 @@ on:
  pull_request:
    types: [opened, synchronize, reopened, edited]

+concurrency:
+  group: specs-commits-${{ gitea.event.pull_request.number }}
+  cancel-in-progress: true
+
 jobs:
  commits:
    runs-on: ubuntu-latest
@@ -23,4 +27,8 @@ jobs:
          HEAD_SHA: ${{ github.event.pull_request.head.sha }}
        run: |
          printf '%s\n' "$PR_TITLE" | npm run commitlint -- --strict
-          npm run commitlint -- --strict --from "$BASE_SHA" --to "$HEAD_SHA"
+          if [[ "$PR_TITLE" =~ ^chore\(release\):\ [0-9]+\.[0-9]+\.[0-9]+$ ]]; then
+            npm run commitlint -- --strict --from "$HEAD_SHA^" --to "$HEAD_SHA"
+          else
+            npm run commitlint -- --strict --from "$BASE_SHA" --to "$HEAD_SHA"
+          fi
@@ -2,12 +2,16 @@ name: Specs security

 on:
  push:
-    branches:
-      - '**'
+    branches: [develop, main]
  pull_request:
+    types: [opened, synchronize, reopened]
  schedule:
    - cron: '17 5 * * *'

+concurrency:
+  group: specs-security-${{ gitea.event_name }}-${{ gitea.event.pull_request.number || gitea.ref }}
+  cancel-in-progress: true
+
 jobs:
  security:
    runs-on: ubuntu-latest
@@ -2,16 +2,52 @@ name: Specs verify

 on:
  push:
-    branches: ['**']
+    branches: [develop, main]
  pull_request:
+    types: [opened, synchronize, reopened]
+
+concurrency:
+  group: specs-verify-${{ gitea.event_name }}-${{ gitea.event.pull_request.number || gitea.ref }}
+  cancel-in-progress: true

 jobs:
  verify:
    runs-on: ubuntu-latest
    steps:
      - uses: https://github.com/actions/checkout@v4
+        with:
+          fetch-depth: 0
+      - name: Check whitespace in committed range
+        env:
+          PR_BASE: ${{ github.event.pull_request.base.sha }}
+          PR_HEAD: ${{ github.event.pull_request.head.sha }}
+          PUSH_BEFORE: ${{ github.event.before }}
+          PUSH_AFTER: ${{ github.sha }}
+        run: |
+          if [ -n "$PR_HEAD" ]; then
+            range="$PR_BASE...$PR_HEAD"
+          elif [ -n "$PUSH_BEFORE" ] && ! expr "$PUSH_BEFORE" : '0*$' >/dev/null; then
+            range="$PUSH_BEFORE..$PUSH_AFTER"
+          else
+            # New branch / unknown before: only the pushed commit; full tree would hit read-only archives.
+            range="$PUSH_AFTER^..$PUSH_AFTER"
+          fi
+          echo "Checked revision: $(git rev-parse HEAD); range: $range"
+          git diff --check "$range"
      - uses: https://github.com/actions/setup-node@v4
        with:
          node-version-file: .nvmrc
-      - run: npm ci
-      - run: npm run verify
+      - name: Install OpenSpec CLI and lychee 0.24.2
+        run: |
+          npm install -g @fission-ai/openspec
+          openspec store register .
+          curl --fail --location --silent --show-error https://github.com/lycheeverse/lychee/releases/download/lychee-v0.24.2/lychee-x86_64-unknown-linux-gnu.tar.gz -o /tmp/lychee.tar.gz
+          echo '1f4e0ef7f6554a6ed33dd7ac144fb2e1bbed98598e7af973042fc5cd43951c9a  /tmp/lychee.tar.gz' | sha256sum --check
+          tar -xzf /tmp/lychee.tar.gz -C /tmp
+          echo /tmp/lychee-x86_64-unknown-linux-gnu >> "$GITHUB_PATH"
+        env:
+          OPENSPEC_TELEMETRY: '0'
+      - name: Validate schemas, specs, changes and local links
+        run: npm run validate
+        env:
+          OPENSPEC_TELEMETRY: '0'
@@ -1 +1 @@
-24.21.0
+24.22.1
@@ -2,8 +2,11 @@

 Репозиторий содержит существующие behavioral specifications и SDD history.
 Для обычной разработки не создавай и не обновляй planning artifacts ради
-процесса. Требование пользователя определяет работу; OpenSpec применяется
-только по явному запросу.
+процесса. До edits найди/создай подходящую Gitea Issue, проверь AC и ветку;
+чтение допускается без Issue. Выбор lightweight/SDD — по
+[Engineering Workflow](https://git.personal.ksv741.ru/WealthLedger/main/src/commit/03b3b59e6ff2ba391f9dfc42a039a96d0d84c1c9/.ai/conventions/engineering-workflow.md)
+(main#28; после merge — актуальная версия `develop`);
+OpenSpec lifecycle начинается только после явного решения Change Owner.

 Если нужна существующая behavioral spec, выбери точный target через
 [AI_INDEX](AI_INDEX.md). Specs не являются вторым editable HTTP OpenAPI:
@@ -11,16 +14,25 @@ HTTP-провайдер публикует контракт, а потребит
 и локально проверяет generated types. Specs фиксируют behavioral requirements;
 другие checkout не нужны для чтения и native validation этого store.

-Архивы и чужие active changes сохраняй. Для правки индекса проверь targets,
-anchors и `git diff --check`; application gates принадлежат affected repos.
+Архивы и чужие active changes сохраняй. Для правки индекса или specs выполни
+`npm run validate` (targets/anchors, native checks) и `git diff --check`;
+application gates принадлежат affected repos.
 Если явно запрошена работа через OpenSpec, следуй
 [локальным инструкциям OpenSpec](README.md#начало-работы)
 и используй store `wealth-ledger-specs`. Перед Node-командами активируй
-местную `.nvmrc` через `nvm use --silent`.
+местную `.nvmrc`: если `nvm` не загружен в non-interactive shell, загрузи
+установленный `$HOME/.nvm/nvm.sh`, затем выполни `nvm use --silent` из specs.
+Если `nvm.sh` недоступен, остановись; не используй системный Node.

 ## Ветки и релизы

-Работа — в отдельной ветке от `develop`, затем PR в `develop`; в `main` напрямую
-не пушить. Release/hotfix и синхронизация веток — по [README](README.md#релизы).
-Commits и заголовки PR — Conventional Commits; для спецификаций допустим `spec:`.
+Работа — в issue-linked ветке от `develop`, затем PR в `develop`; в `main` напрямую
+не пушить. PR сливается squash или rebase-merge; merge-коммит не используется.
+`main` обновляется только fast-forward из `develop`, поэтому `origin/main`
+всегда предок `origin/develop`:
+`git merge-base --is-ancestor origin/main origin/develop`. Срочный fix —
+обычная ветка `fix/*` от `develop`; пути hotfix от `main` нет.
+Релиз — по [README](README.md#релизы).
+Commits и заголовки PR — Conventional Commits со ссылкой на Issue (кроме release);
+для спецификаций допустим `spec:`.
 Перед подготовкой релиза прочитай местный README; версии вручную не повышать.
@@ -12,24 +12,40 @@ HTTP OpenAPI имеет единственный editable source в backend, а
 Потребитель доверяет предоставленному artifact и локально проверяет generated
 types. CI каждого участника использует только его собственные входы.

-| Тема / trigger | Existing spec |
-| --- | --- |
-| Auth/session/refresh/error contract | [User authentication](openspec/specs/user-authentication/spec.md) |
-| T-Bank connection/security/cache generation | [T-Bank connection](openspec/specs/tbank-connection/spec.md) |
-| Счета/сводки | [Brokerage accounts](openspec/specs/brokerage-accounts/spec.md) |
-| Portfolio positions/totals/stale | [Portfolio](openspec/specs/portfolio-view/spec.md) |
-| Операции/cursor/filters | [Account ledger](openspec/specs/brokerage-account-ledger/spec.md) |
-| Будущие выплаты | [Upcoming events](openspec/specs/brokerage-account-upcoming-events/spec.md) |
-| Доходы и периоды | [Income analytics](openspec/specs/brokerage-account-income-analytics/spec.md) |
-| Shared tokens/theme | [Design system](openspec/specs/frontend-design-system/spec.md) |
-| Каталог компонентов | [UI catalog](openspec/specs/frontend-ui-catalog/spec.md) |
-| Loading/skeleton | [Loading presentation](openspec/specs/frontend-loading-presentation/spec.md) |
-| UI error/recovery | [UI resilience](openspec/specs/frontend-ui-resilience/spec.md) |
-| Query coherence/cache | [Query coherence](openspec/specs/frontend-query-coherence/spec.md), [data resilience](openspec/specs/frontend-data-resilience/spec.md) |
-| OpenAPI generation | [API contract generation](openspec/specs/api-contract-generation/spec.md) |
-| Logging/request context | [Structured logging](openspec/specs/backend-structured-logging/spec.md) |
-| Breadcrumb/navigation | [Breadcrumbs](openspec/specs/app-breadcrumb-navigation/spec.md) |
+Specs сгруппированы по доменам: `openspec/specs/<domain>/<capability>/spec.md`.
+Новая capability кладётся в существующий домен; новый домен — только для
+отдельного бизнес-контекста. Процессные правила сюда не входят.

-Process specs, active changes и archives сохраняют историю прежнего SDD workflow.
-Они не являются обязательной процедурой текущей задачи. Для явно запрошенной
-работы с OpenSpec используй [отдельный вход](AGENTS.md).
+| Домен | Тема / trigger | Existing spec |
+| --- | --- | --- |
+| identity | Auth/session/refresh/error contract | [User authentication](openspec/specs/identity/user-authentication/spec.md) |
+| tbank | T-Bank connection/security/cache generation | [T-Bank connection](openspec/specs/tbank/tbank-connection/spec.md) |
+| tbank | Владелец синхронизации T-Bank, scheduling/priority | [T-Bank data sync](openspec/specs/tbank/tbank-data-sync/spec.md) |
+| tbank | Часовой обход, результат последней попытки | [Hourly investment sync](openspec/specs/tbank/hourly-investment-sync/spec.md) |
+| brokerage | Счета/сводки | [Brokerage accounts](openspec/specs/brokerage/brokerage-accounts/spec.md) |
+| brokerage | Операции/cursor/filters | [Account ledger](openspec/specs/brokerage/brokerage-account-ledger/spec.md) |
+| brokerage | Будущие выплаты | [Upcoming events](openspec/specs/brokerage/brokerage-account-upcoming-events/spec.md) |
+| brokerage | Доходы и периоды | [Income analytics](openspec/specs/brokerage/brokerage-account-income-analytics/spec.md) |
+| portfolio | Portfolio positions/totals/stale | [Portfolio](openspec/specs/portfolio/portfolio-view/spec.md) |
+| portfolio | Вкладка «Концентрация»: топ-5 акций/облигаций/секторов/эмитентов | [Portfolio concentration](openspec/specs/portfolio/portfolio-concentration/spec.md) |
+| portfolio | История стоимости Portfolio | [Portfolio value history](openspec/specs/portfolio/portfolio-value-history/spec.md) |
+| instruments | Справочные сведения/поиск инструментов (online-only) | [Online instrument information](openspec/specs/instruments/online-instrument-information/spec.md) |
+| instruments | Календарь купонов/дивидендов инструмента | [Instrument income schedules](openspec/specs/instruments/instrument-income-schedules/spec.md) |
+| instruments | Скринер акций | [Stock screener](openspec/specs/instruments/stock-screener/spec.md) |
+| banking | Ручные дебетовые карты | [Manual bank cards](openspec/specs/banking/manual-bank-cards/spec.md) |
+| frontend-platform | Каркас приложения, маршруты MVP | [App shell](openspec/specs/frontend-platform/app-shell/spec.md) |
+| frontend-platform | Shared tokens/theme | [Design system](openspec/specs/frontend-platform/frontend-design-system/spec.md) |
+| frontend-platform | Каталог компонентов | [UI catalog](openspec/specs/frontend-platform/frontend-ui-catalog/spec.md) |
+| frontend-platform | Loading/skeleton | [Loading presentation](openspec/specs/frontend-platform/frontend-loading-presentation/spec.md) |
+| frontend-platform | UI error/recovery | [UI resilience](openspec/specs/frontend-platform/frontend-ui-resilience/spec.md) |
+| frontend-platform | Тихое чтение и редкие уведомления | [User feedback](openspec/specs/frontend-platform/frontend-user-feedback/spec.md) |
+| frontend-platform | Query coherence/cache | [Query coherence](openspec/specs/frontend-platform/frontend-query-coherence/spec.md), [data resilience](openspec/specs/frontend-platform/frontend-data-resilience/spec.md) |
+| frontend-platform | Breadcrumb/navigation | [Breadcrumbs](openspec/specs/frontend-platform/app-breadcrumb-navigation/spec.md) |
+| frontend-platform | Structural boundaries/bundle size/coverage | [Quality guardrails](openspec/specs/frontend-platform/frontend-quality-guardrails/spec.md) |
+| backend-platform | `/api/v1`, CORS, безопасные ошибки | [HTTP API foundation](openspec/specs/backend-platform/http-api-foundation/spec.md) |
+| backend-platform | OpenAPI generation | [API contract generation](openspec/specs/backend-platform/api-contract-generation/spec.md) |
+| backend-platform | Logging/request context | [Structured logging](openspec/specs/backend-platform/backend-structured-logging/spec.md) |
+
+Active changes и archives сохраняют историю прежнего SDD workflow. Они не
+являются обязательной процедурой текущей задачи. Для явно запрошенной работы
+с OpenSpec используй [отдельный вход](AGENTS.md).
@@ -1,5 +1,101 @@
 # Changelog

+## [0.2.1](https://git.personal.ksv741.ru/WealthLedger/specs/compare/v0.2.0...v0.2.1) (2026-11-06)
+
+### Specifications
+
+* align Events and CURRENCY portfolio behavior (WealthLedger/specs[#60](https://git.personal.ksv741.ru/WealthLedger/specs/issues/60)) ([142f7aa](https://git.personal.ksv741.ru/WealthLedger/specs/commit/142f7aa225b4c9ca478ca9b350649df6746d6bf4))
+* allow warning and retry after exhausted read retries (WealthLedger/specs[#79](https://git.personal.ksv741.ru/WealthLedger/specs/issues/79)) ([#80](https://git.personal.ksv741.ru/WealthLedger/specs/issues/80)) ([0469756](https://git.personal.ksv741.ru/WealthLedger/specs/commit/0469756d3bc983e32811470b671d743cd5009739))
+* treat MOEX response without requested block as source failure (WealthLedger/specs[#76](https://git.personal.ksv741.ru/WealthLedger/specs/issues/76)) ([#77](https://git.personal.ksv741.ru/WealthLedger/specs/issues/77)) ([aa1a57a](https://git.personal.ksv741.ru/WealthLedger/specs/commit/aa1a57ac202eed8352ffed29296432afca56a3e9))
+
+### Refactoring
+
+* group canonical specs by domain and archive account-top-positions ([#74](https://git.personal.ksv741.ru/WealthLedger/specs/issues/74)) ([3821d9e](https://git.personal.ksv741.ru/WealthLedger/specs/commit/3821d9ed587e71e3da662e9b84f0c27bd32ce977))
+
+### CI
+
+* check whitespace in committed PR/push range (WealthLedger/specs[#2](https://git.personal.ksv741.ru/WealthLedger/specs/issues/2)) ([7f73de7](https://git.personal.ksv741.ru/WealthLedger/specs/commit/7f73de76ac0e54327745cad61043922047c421ec))
+* run native OpenSpec and local link validation in verify (WealthLedger/specs[#2](https://git.personal.ksv741.ru/WealthLedger/specs/issues/2)) ([1fd7e6a](https://git.personal.ksv741.ru/WealthLedger/specs/commit/1fd7e6ad974193eca3390cf41749368c5c318858))
+
+### Maintenance
+
+* **deps:** set Renovate release age, PR limit and update groups (WealthLedger/main[#6](https://git.personal.ksv741.ru/WealthLedger/specs/issues/6)) ([#81](https://git.personal.ksv741.ru/WealthLedger/specs/issues/81)) ([8fc8e0a](https://git.personal.ksv741.ru/WealthLedger/specs/commit/8fc8e0a750a561b54251add5bac03d5ef58a94e3))
+* drop OpenSpec CLI version pin and strict validation (WealthLedger/specs[#67](https://git.personal.ksv741.ru/WealthLedger/specs/issues/67)) ([#78](https://git.personal.ksv741.ru/WealthLedger/specs/issues/78)) ([8b2b742](https://git.personal.ksv741.ru/WealthLedger/specs/commit/8b2b742e52773ee3ab21fafaf6043420927640ac))
+
+## [0.2.0](https://git.personal.ksv741.ru/WealthLedger/specs/compare/v0.1.6...v0.2.0) (2026-11-01)
+
+### Features
+
+* add experimental wealth-ledger-sdd-lab OpenSpec schema ([#61](https://git.personal.ksv741.ru/WealthLedger/specs/issues/61)) ([322ddf6](https://git.personal.ksv741.ru/WealthLedger/specs/commit/322ddf6a7f9b3309a875e17ee37a574c8decb1b0))
+
+### Specifications
+
+* archive group-account-rows-by-instrument and sync canonical specs (WealthLedger/main[#47](https://git.personal.ksv741.ru/WealthLedger/specs/issues/47)) ([#65](https://git.personal.ksv741.ru/WealthLedger/specs/issues/65)) ([a2d2df3](https://git.personal.ksv741.ru/WealthLedger/specs/commit/a2d2df3b5a7fc7f72bdd82ab42bb0ae25debfffe))
+* plan grouping of all-account rows by instrument (WealthLedger/main[#47](https://git.personal.ksv741.ru/WealthLedger/specs/issues/47)) ([#64](https://git.personal.ksv741.ru/WealthLedger/specs/issues/64)) ([f3a6b78](https://git.personal.ksv741.ru/WealthLedger/specs/commit/f3a6b78461408083f0ad04bdfe64634c09f53be2))
+* record account-top-positions planning and implementation (WealthLedger/main[#48](https://git.personal.ksv741.ru/WealthLedger/specs/issues/48)) ([#69](https://git.personal.ksv741.ru/WealthLedger/specs/issues/69)) ([c66a5cd](https://git.personal.ksv741.ru/WealthLedger/specs/commit/c66a5cd962fd265c3365e8c396a7958ba307bac0))
+
+### Refactoring
+
+* make sdd-lab review-driven (WealthLedger/specs[#66](https://git.personal.ksv741.ru/WealthLedger/specs/issues/66)) ([b9ec11f](https://git.personal.ksv741.ru/WealthLedger/specs/commit/b9ec11f5ba193dc851c79908c5ed8accc34e2e54))
+
+## [0.1.6](https://git.personal.ksv741.ru/WealthLedger/specs/compare/v0.1.5...v0.1.6) (2026-10-24)
+
+### Maintenance
+
+* bump Node to 24.22.1 (WealthLedger/backend[#122](https://git.personal.ksv741.ru/WealthLedger/specs/issues/122)) ([c5b9cad](https://git.personal.ksv741.ru/WealthLedger/specs/commit/c5b9cadbbd2dfbb6f139bc71851117d81c0e7c6d))
+* **deps:** update non-major dependencies (WealthLedger/specs[#56](https://git.personal.ksv741.ru/WealthLedger/specs/issues/56)) ([08646ff](https://git.personal.ksv741.ru/WealthLedger/specs/commit/08646ff505eed501e54314c07ca4d1076a4c37dd))
+
+## [0.1.5](https://git.personal.ksv741.ru/WealthLedger/specs/compare/v0.1.4...v0.1.5) (2026-10-18)
+
+### Specifications
+
+* add five capability entries to AI_INDEX (WealthLedger/specs[#28](https://git.personal.ksv741.ru/WealthLedger/specs/issues/28)) ([d5d5480](https://git.personal.ksv741.ru/WealthLedger/specs/commit/d5d5480eedbc25c77c52b3b477de37e373beb8d9))
+* align user-authentication password requirement with ASCII 8-72 policy (WealthLedger/specs[#46](https://git.personal.ksv741.ru/WealthLedger/specs/issues/46)) ([#47](https://git.personal.ksv741.ru/WealthLedger/specs/issues/47)) ([1bd6181](https://git.personal.ksv741.ru/WealthLedger/specs/commit/1bd618158588871f1801bfc6bead82fba31ce0ae))
+* archive quiet-user-feedback and sync canonical specs ([#50](https://git.personal.ksv741.ru/WealthLedger/specs/issues/50)) ([f0478c6](https://git.personal.ksv741.ru/WealthLedger/specs/commit/f0478c6d6b5a5f259ea766276295758b34d240b3))
+* archive three completed changes (main[#33](https://git.personal.ksv741.ru/WealthLedger/specs/issues/33), frontend[#63](https://git.personal.ksv741.ru/WealthLedger/specs/issues/63), screener) ([6efb989](https://git.personal.ksv741.ru/WealthLedger/specs/commit/6efb989ed9051981a314c8eb5714dffa88195a80))
+* clarify SDD applies only on explicit request (WealthLedger/specs[#1](https://git.personal.ksv741.ru/WealthLedger/specs/issues/1)) ([7ebfc51](https://git.personal.ksv741.ru/WealthLedger/specs/commit/7ebfc510afb7440f85ecf95e2891d84c1b8ad843))
+* fix upcoming events date filter default and picker bounds (WealthLedger/frontend[#63](https://git.personal.ksv741.ru/WealthLedger/specs/issues/63)) ([b4c0589](https://git.personal.ksv741.ru/WealthLedger/specs/commit/b4c0589745e0d1fb6b482addbea82d06c4924dad))
+* reconcile quiet-user-feedback with source-state requirements ([#50](https://git.personal.ksv741.ru/WealthLedger/specs/issues/50)) ([5a7e319](https://git.personal.ksv741.ru/WealthLedger/specs/commit/5a7e319cafd8d9b6861b5a6bab7085bb57b08576))
+* unify income payment cards and drop period comparisons (WealthLedger/main[#33](https://git.personal.ksv741.ru/WealthLedger/specs/issues/33)) ([#37](https://git.personal.ksv741.ru/WealthLedger/specs/issues/37)) ([6c858a8](https://git.personal.ksv741.ru/WealthLedger/specs/commit/6c858a8858dfdfc5c9607b3f925de5900ef1c903))
+
+### CI
+
+* rerun commits proof on PR title edit (WealthLedger/specs[#30](https://git.personal.ksv741.ru/WealthLedger/specs/issues/30)) ([4e3855f](https://git.personal.ksv741.ru/WealthLedger/specs/commit/4e3855fc3526e2b0b7ba80fd23b996d9993edcf5))
+
+### Maintenance
+
+* adopt linear git model in specs instructions ([#48](https://git.personal.ksv741.ru/WealthLedger/specs/issues/48)) ([06d08e2](https://git.personal.ksv741.ru/WealthLedger/specs/commit/06d08e29724e6cbe95eeca5ee1e6af7ec365a559))
+* make OpenSpec toolchain explicit and diagnosable (WealthLedger/specs[#4](https://git.personal.ksv741.ru/WealthLedger/specs/issues/4)) ([#43](https://git.personal.ksv741.ru/WealthLedger/specs/issues/43)) ([7da2f90](https://git.personal.ksv741.ru/WealthLedger/specs/commit/7da2f90e0a6a7e0e5cb40b371c965a772aaa5db2))
+
+## [0.1.4](https://git.personal.ksv741.ru/WealthLedger/specs/compare/v0.1.3...v0.1.4) (2026-10-12)
+
+### Bug Fixes
+
+* align specs commitlint workflow (WealthLedger/main[#27](https://git.personal.ksv741.ru/WealthLedger/specs/issues/27)) ([a29cbf6](https://git.personal.ksv741.ru/WealthLedger/specs/commit/a29cbf6aae7ebe48a51ae1979ff3f30b9fa8e305))
+
+### Documentation
+
+* clarify specs Node bootstrap ([18518e0](https://git.personal.ksv741.ru/WealthLedger/specs/commit/18518e0d2daecb843fea1b4d55d1c7d2cabf24f6))
+* pin specs workflow reference (WealthLedger/main[#27](https://git.personal.ksv741.ru/WealthLedger/specs/issues/27)) ([7f12327](https://git.personal.ksv741.ru/WealthLedger/specs/commit/7f12327c37055ba903f962b1220138da9c7edd06))
+
+### Specifications
+
+* add harden-hourly-sync-lifecycle change (WealthLedger/backend[#56](https://git.personal.ksv741.ru/WealthLedger/specs/issues/56)) ([14174a7](https://git.personal.ksv741.ru/WealthLedger/specs/commit/14174a7bb335152c8cc76d9a6bbaefaaaa58b22f))
+* add stock screener ([951f1a9](https://git.personal.ksv741.ru/WealthLedger/specs/commit/951f1a9a20a09695e2ff85d1ee96632e98a202d8))
+* address hourly-sync review findings (WealthLedger/backend[#56](https://git.personal.ksv741.ru/WealthLedger/specs/issues/56)) ([77b2111](https://git.personal.ksv741.ru/WealthLedger/specs/commit/77b211186c297df4187e044804786ffc9096ce19))
+* archive harden-hourly-sync-lifecycle change (WealthLedger/backend[#56](https://git.personal.ksv741.ru/WealthLedger/specs/issues/56)) ([fe295aa](https://git.personal.ksv741.ru/WealthLedger/specs/commit/fe295aa73ab5bc9d826067892930b7161fb4f1b9))
+* define hourly portfolio sync history ([b24a686](https://git.personal.ksv741.ru/WealthLedger/specs/commit/b24a6861887e831ef2d73a97f36cc213be2be0b8))
+* finalize wealth-ledger SDD migration ([329d66e](https://git.personal.ksv741.ru/WealthLedger/specs/commit/329d66e767f7e89a40b96bb8e5b499f39f67feb6))
+
+### CI
+
+* avoid duplicate PR checks ([c132770](https://git.personal.ksv741.ru/WealthLedger/specs/commit/c132770fbb4a4e48cae0a4ceca7407bb6a768ded))
+* skip checks on PR metadata edits ([fcdc805](https://git.personal.ksv741.ru/WealthLedger/specs/commit/fcdc805f6c1b3be6a20a7e858e3e80cbd83a9121))
+
+### Maintenance
+
+* align specs engineering workflow (WealthLedger/main[#27](https://git.personal.ksv741.ru/WealthLedger/specs/issues/27)) ([a441b08](https://git.personal.ksv741.ru/WealthLedger/specs/commit/a441b083785d8f50c42dea543e684b23f27732a2))
+
 ## [0.1.3](https://git.personal.ksv741.ru/WealthLedger/specs/compare/v0.1.2...v0.1.3) (2026-10-07)

 ### Bug Fixes
@@ -4,7 +4,7 @@

 ## Начало работы

-OpenSpec применяется по явному запросу согласно [AGENTS](AGENTS.md). Для команд, читающих или изменяющих change, явно передавайте `--store wealth-ledger-specs`. Структурная готовность CLI не означает approval: перед каждым downstream artifact нужно явное решение Change Owner.
+OpenSpec применяется после явного решения Change Owner согласно [AGENTS](AGENTS.md). Для команд, читающих или изменяющих change, явно передавайте `--store wealth-ledger-specs`. Структурная готовность CLI не означает approval: перед каждым downstream artifact нужно явное решение Change Owner.

 | Change | Lifecycle |
 | --- | --- |
@@ -18,54 +18,88 @@ OpenSpec применяется по явному запросу согласн
 Для native validation из этого репозитория:

 ```bash
-openspec schema validate wealth-ledger-sdd --verbose
-openspec schema validate wealth-ledger-sdd-v2 --verbose
-openspec status --change <change> --store wealth-ledger-specs
-openspec validate <change> --type change --strict --store wealth-ledger-specs
-openspec validate --specs --strict --store wealth-ledger-specs
+npm run validate
 ```

-Версия OpenSpec CLI не закреплена отдельным файлом: при обновлении проверяйте обе
-schema, затронутые changes и canonical specs, фиксируя `openspec --version` вместе
-с результатами проверок. Structural validation не заменяет semantic verification
-и independent read-only review перед archive.
+Одна команда, её же вызывает CI `verify`: `openspec schema validate` (все schemas),
+`openspec validate --all` (specs и active changes) и [lychee](https://lychee.cli.rs/) 0.24.2 `--offline
+--include-fragments` для относительных ссылок и anchors в корневых `*.md`
+(включая `AI_INDEX`) и `openspec/specs`. Архивы и внешние URL не проверяются.
+В чистой среде один раз: `openspec store register .`; lychee ставится
+отдельно (например, `brew install lychee`). Для отдельного change:
+`openspec status --change <change> --store wealth-ledger-specs`.
+
+OpenSpec CLI ставится глобально (`npm install -g @fission-ai/openspec`) и не закрепляется
+ни в `package.json` (его транзитивная зависимость `braces` имеет advisory без исправления
+в 3.x), ни отдельным файлом версии: CI ставит актуальный выпуск. `validate` не использует
+`--strict`: с 1.15 предупреждение о длинных требованиях (>500 символов) считается ошибкой
+в strict-режиме. Structural validation не заменяет semantic verification и independent
+read-only review перед archive.

 Node задаётся собственной `.nvmrc`; после `nvm use --silent` выполните `npm ci`.
-`npm run verify` проверяет diff. OpenSpec validation остаётся отдельной проверкой
-при изменениях требований. История релизов — [CHANGELOG](CHANGELOG.md).
+`npm run verify` локально проверяет whitespace в незакоммиченном diff; CI `verify`
+выполняет тот же `git diff --check` по коммитам PR (merge-base→head) или push
+(before→after, для новой ветки — последний коммит). Это структурная проверка
+whitespace. Ни whitespace, ни structural validation не заменяют semantic review.
+История релизов — [CHANGELOG](CHANGELOG.md).

 ## Релизы

 Репозиторий выпускается независимо. `develop` — интеграция, `main` — принятые
-релизы. Работа: `codex/<task>` от актуального `develop`, PR в `develop`.
-Обычные PR допускают squash; release и обратная синхронизация сохраняют историю.
-Commits и PR titles — Conventional Commits, включая `spec:`. Версии вручную не повышай.
+релизы. Обычная работа: issue-linked ветка от актуального `develop`, PR в
+`develop`; общие правила — в Engineering Workflow по ссылке из AGENTS.
+PR сливается squash или rebase-merge; merge-коммит не используется. `main`
+обновляется только fast-forward из `develop`, поэтому история линейна:

-1. Получи `main`, `develop` и теги: `git fetch origin --tags`. Убедись, что
-   `develop` содержит последний релиз. Создай `release/<name>` от проверенного
-   `develop`; `nvm use --silent`, `npm ci`. Hotfix начинается от `main` в
-   `release/hotfix-<name>` и проходит тот же процесс.
+```text
+<type>/<issue>-<slug> --squash--> develop --ff-only--> main --> tag vX.Y.Z
+```
+
+Инвариант: `origin/main` всегда предок `origin/develop`. Проверка:
+
+```bash
+git fetch -q origin
+git merge-base --is-ancestor origin/main origin/develop && echo ok || echo BROKEN
+```
+
+Commits и PR titles — Conventional Commits со ссылкой на Issue (кроме release),
+включая `spec:`. Версии вручную не повышай.
+
+1. Получи `main`, `develop` и теги: `git fetch origin --tags`. Проверь
+   инвариант. Создай `release/X.Y.Z` от проверенного `develop`;
+   `nvm use --silent`, `npm ci`.
 2. На чистой ветке выполни `npm run release:preview`, просмотри версию/changelog,
   затем `npm run release:prepare`. Команда создаёт `chore(release): X.Y.Z`,
   обновляет manifest/lockfile/CHANGELOG; тег и push не выполняет. Не обходи
   guards ветки, чистого дерева, отсутствующих тегов или уже подготовленной версии.
 3. Проверь diff и штатные gates этого репозитория. Отправь только release-ветку,
-   открой PR в `main` с заголовком `chore(release): X.Y.Z`. После зелёных
-   `verify`, `security`, `commits` выполни fast-forward-only merge. Если `main`
-   изменился, согласуй историю и повтори проверки кандидата.
-4. Получи удалённый `main`, сравни его HEAD с проверенным release SHA и версией
+   открой PR в **`develop`** с заголовком `chore(release): X.Y.Z`. После зелёных
+   `verify`, `security`, `commits` выполни fast-forward-only merge. Если
+   `develop` изменился, обнови release-ветку и повтори проверки кандидата.
+4. Открой PR `develop → main` с тем же заголовком и слей fast-forward-only.
+5. Получи удалённый `main`, сравни его HEAD с проверенным release SHA и версией
   manifest/lockfile. Создай аннотированный `vX.Y.Z` именно на этом SHA:
   `git tag -a vX.Y.Z <release-sha> -m "Release X.Y.Z"`, затем отправь только
   `git push origin refs/tags/vX.Y.Z`. Не запускай release-it повторно на `main`.
-5. Верни release-коммит через PR `main → develop` без squash/rebase; проверь,
-   что `develop` содержит тег. Опубликованные теги не перемещай. При сбое после
-   merge создай отсутствующий тег без нового bump; до merge исправь и проверь
-   существующий кандидат без повторного повышения версии.
+
+Обратная синхронизация не нужна: release-коммит попал в `develop` на шаге 3.
+Опубликованные теги не перемещай. При сбое после merge создай отсутствующий тег
+без нового bump; до merge исправь и проверь существующий кандидат без
+повторного повышения версии.
+
+Freeze релиза не поддерживается: пока открыт релизный PR, `develop` не двигают.
+Срочный fix — обычная ветка `fix/*` от `develop` с последующим релизом;
+пути от `main` нет, он сделал бы `main` не-предком `develop`. Исключение
+требует явного решения: `release/hotfix-<name>` от `main`, PR в `main`, тег,
+затем merge `main → develop` для восстановления инварианта.

 `feat:` повышает minor, `fix:`/`perf:` и прочие разрешённые типы — patch;
 `!`/`BREAKING CHANGE:` — major, включая версии до 1.0. `chore(release):`
 исключён из рекомендации и changelog. Конфигурация — `.release-it.json`.
 В Gitea для `main`/`develop` должны быть запрещены прямой/force push и обход
-администратором, обязательны `verify`, `security`, `commits`; теги `v*` защищены.
+администратором, включена блокировка устаревшей ветки, обязательны `verify`,
+`security`, `commits`; теги `v*` защищены. Линейность обеспечивают merge styles
+репозитория: merge-коммиты и rebase `--no-ff` выключены, доступны squash,
+rebase-merge и fast-forward-only; стиль по умолчанию — squash.
 Workflow сам не включает эти настройки. Отдельное review approval для одного
 владельца не требуется. Npm publishing, deploy и Gitea Releases не включены.
@@ -1,4 +1,12 @@
 module.exports = {
  extends: ["@commitlint/config-conventional"],
-  rules: { "type-enum": [2, "always", ["feat", "fix", "perf", "docs", "spec", "refactor", "build", "ci", "test", "style", "chore", "revert"]] },
+  defaultIgnores: false,
+  ignores: [
+    message => /^chore\(release\): \d+\.\d+\.\d+$/.test(message.trim()),
+    message => /^Merge pull request ['"].+['"] \(#\d+\) from .+ into .+$/.test(message.trim()),
+  ],
+  rules: {
+    "type-enum": [2, "always", ["feat", "fix", "perf", "docs", "spec", "refactor", "build", "ci", "test", "style", "chore", "revert"]],
+    "references-empty": [2, "never"],
+  },
 };
@@ -0,0 +1,2 @@
+schema: wealth-ledger-sdd-v2
+created: 2026-11-07
@@ -0,0 +1,261 @@
+# Design
+
+Issue: WealthLedger/main#54
+
+## Context and Constraints
+
+- Backend: NestJS, Prisma + SQLite. Деньги — точная BigInt-арифметика
+  (`src/common/decimal.ts`: `add`, `subtract`, `multiply`, `divide`,
+  `compare`). Возведения в дробную степень нет.
+- Операции T-Bank уже сохраняются синхронизацией. Покрытие и граница истории
+  вычисляются в `operations/domain/operations-coverage.ts`. Доступ и режим
+  `all` проверяет `TbankAccessService.local`. Последний Portfolio отдаёт
+  `PortfolioService.saved` (`portfolio.api.ts`).
+- Признак полной оценки Portfolio сейчас записан прямо в
+  `portfolio.repository.ts:141-146` и нигде больше не используется.
+- MOEX-клиент (`integrations/moex/moex.client.ts`) использует fetch с
+  таймаутом 10 с и умеет читать ISS-блоки и cursor-пагинацию. Он отдаёт
+  только данные облигаций.
+- Frontend: вкладки счёта — Mantine `Tabs` с `keepMounted={false}`, состояние
+  во VM. Данные берутся из entity-хуков на `openapi-react-query`. Графики —
+  `@mantine/charts` (`AreaChart` в `InstrumentChart`). Компоненты разбиты на
+  container / `vm` / `view`. Строки интерфейса лежат в `ru.ts`.
+
+## Technical Goals / Non-Goals
+
+**Goals:** реализовать утверждённый контракт и спецификации. Расчёт
+выполняется на backend и сверяется с независимым эталоном XIRR. Вкладка
+«Результат» соответствует варианту A прототипа.
+
+**Non-Goals:**
+- общий финансовый движок «на будущее» (TWR, периоды);
+- фоновая синхронизация индексов;
+- изменения синхронизации T-Bank;
+- новая зависимость ради XIRR.
+
+## Implementation Impact Map
+
+| Area | Статус | Outcome |
+| --- | --- | --- |
+| `main` | N/A | Нет изменений compose, env или релиза. MOEX ISS уже используется без конфигурации |
+| `backend` | affected | Модуль `performance`, хранилище и клиент истории индексов, миграция, маршруты, обновлённый `openapi.json` |
+| `frontend` | affected | Обновлённый OpenAPI snapshot, entity `performance`, вкладка «Результат» |
+| `qa` | N/A | Отдельного QA-репозитория нет |
+
+## Decisions
+
+### backend
+
+1. **Модуль `src/modules/investments/performance/`** устроен по образцу
+   `income`:
+   - контроллер с маршрутом `all/performance` перед `:accountId/performance`;
+   - application-сервис;
+   - чистый `domain/`: потоки, XIRR, теневой портфель, причины.
+
+   Сервис зависит от `TbankAccessService`, `BrokerageOperationsService` (чтение
+   сохранённых операций и покрытия), `PortfolioService.saved` и
+   `MarketIndexHistoryService`. *Отклонено:* расширять `income` — это другой
+   предметный смысл, а там запрещён термин «доходность».
+2. **Признак полной оценки** выносится в чистую функцию
+   `isCompleteValuation(snapshot)` в portfolio domain и экспортируется через
+   `portfolio.api.ts`. Его используют и `portfolio.repository.ts`, и расчёт
+   результата. Так у «полной оценки» одно правило.
+3. **XIRR на `number`, деньги — на `Decimal`.** Агрегаты, потоки, units и
+   стоимость теневого портфеля считаются точно. Ставка — итерационное
+   приближение, точная десятичная степень для неё бессмысленна. Поэтому
+   решатель работает на float64 и выдаёт результат до 6 знаков (точности
+   хватает с запасом).
+   - При обычном наборе потоков с одной сменой знака по датам Descartes'
+     rule доказывает единственность корня: уточнить его бисекцией в
+     `[−0.9999, 100]` до |NPV| ≤ 0,01 ₽. Нет корня → `NO_SOLUTION`.
+     При нескольких сменах знака нет доказательства единственности — пока
+     консервативно вернуть `AMBIGUOUS_RETURN`, даже если фактически корень
+     единственный. Полное выделение всех корней добавлять только при
+     подтверждённой потребности.
+   - *Отклонено:* Ньютон от одного старта и проверка только знаков на концах:
+     они не выявляют несколько решений. Новая зависимость не нужна.
+4. **Переводы в `all`.** Деньги и бумаги сопоставляются в domain только
+   для выявления кандидатов (сумма/время либо инструмент/количество).
+   Кандидат без независимого признака связи не исключается из потоков:
+   затронутые счета исключаются из результата `all` с причиной
+   `UNCONFIRMED_TRANSFER`. Существующий T-Bank contract не даёт такого
+   признака, поэтому автоматически подтверждённых пар сейчас нет.
+5. **История индексов: `MarketIndexHistoryService`** в
+   `src/modules/investments/market-index/`. В `MoexClient` добавляется метод
+   `indexHistory(secid, from, till)` с пагинацией по `history.cursor`. Если
+   страница не проходит валидацию, вся загрузка считается сбоем, а частичные
+   строки не сохраняются.
+   - Single-flight: `Map<secid, Promise>` с удалением в `finally`, по
+     образцу существующего `pending` map.
+   - Время последней попытки хранится в БД, а не в памяти: правило «не чаще
+     раза в час» переживает рестарт.
+6. **Расчёт без кэша.** Каждый GET пересчитывает результат из сохранённых
+   данных, это O(операций + дней). Кэш результата не нужен, пока ответ
+   укладывается в 1 с (см. NFR).
+7. **Маппинг типов операций** — единая таблица в domain (enum T-Bank → роль
+   `deposit | withdrawal | securitiesTransfer | internal`) рядом с
+   существующим `brokerage-operation.mapper.ts`. Существующие категории
+   журнала не меняются.
+
+### frontend
+
+1. **Entity `src/entities/performance/`**: хук `usePerformance(accountId)`
+   на `apiQueryClient.queryOptions("get", "/api/v1/brokerage-accounts/{accountId}/performance")`
+   с `meta.accessGroup: "brokerage"` и `staleTime: 30_000`. Для `all`
+   передаётся литерал пути, как в income.
+2. **Вкладка `performance`** («Результат») — последняя в
+   `AccountPageLoaded.view.tsx`. Панель — самостоятельный container
+   `PerformanceTab` в `src/pages/account/ui/AccountPage/components/Performance/`.
+   Хук вызывается внутри панели, поэтому запрос уходит только при открытой
+   вкладке (`keepMounted={false}`). Ошибка вкладки не задевает остальные
+   вкладки.
+3. **VM (`Performance.vm.ts`)** переводит ответ в состояние вкладки:
+   - `loading`, `error`;
+   - `unavailable`: причины из `meta.unavailable`;
+   - `ready`: KPI, график, предупреждения.
+
+   Вне VM доли не превращаются в проценты. Подпись берётся из
+   `return.basis` и `period.days`. Тон: `> 0` — positive, `< 0` — negative,
+   `0` — neutral. Неизвестный `UnavailableReason` показывается общей
+   формулировкой.
+4. **Форматирование.** Добавить в `shared/lib/display.ts`:
+   - `formatSignedPercent(rate)`: доля → «+15,1 %», 1 знак;
+   - `formatPercentagePoints(rate)`: «+4,3 п.п.».
+
+   Используется минус «−» (U+2212), как в прототипе. Суммы со знаком
+   выводятся через `formatMoney`.
+5. **График** — `@mantine/charts` `LineChart`:
+   - серии: `netInvested` (`curveType="stepAfter"`), `benchmarkValue`,
+     `referenceValue` (`strokeDasharray`);
+   - текущая стоимость — `ReferenceDot` из recharts в дату `period.to`;
+   - пользовательский tooltip — по образцу `PortfolioStructure`.
+
+   Текстовая альтернатива: `aria-label` с итогами плюс скрытая визуально
+   таблица итоговых значений. Полной таблицы точек нет: она вне scope, как
+   и таблица потоков. Если `series` пуст, графика нет, вместо него текст о
+   недоступности индекса.
+6. **Строки интерфейса** — в `ru.ts`, namespace `portfolio.performance.*`,
+   включая тексты причин и блок «Как считали».
+7. **Hint «?»** — Mantine `Tooltip` с `events={{ hover: true, focus: true, touch: true }}`
+   на `ActionIcon` с `aria-label`.
+
+## Cross-cutting Implementation
+
+- **Безопасность.** До чтения данных — `TbankAccessService.local`. Счета без
+  доступа не попадают ни в расчёт, ни в `meta.unavailable`.
+- **Логирование.** `integration.moex.index_history.succeeded/failed` (secid,
+  from, till, pages, durationMs). Расчёт пишет debug
+  `performance.calculated` (accountsIncluded, accountsExcluded, durationMs)
+  без сумм.
+- **Конкурентность.** Single-flight догрузки на каждый индекс. Upsert по
+  `(secid, tradeDate)` идемпотентен.
+- **Ошибки.** Сбой MOEX ловится в `MarketIndexHistoryService` и
+  превращается в результат «недостаточно покрытия». Наружу как 503 он не
+  выходит.
+
+## Data / Storage Changes
+
+Аддитивная миграция `prisma/migrations/<ts>_add_market_index_history`:
+
+```prisma
+model MarketIndexDailyClose {
+  secid     String   // MCFTRR | IMOEX
+  tradeDate String   // YYYY-MM-DD, Europe/Moscow
+  close     String   // точная десятичная строка
+  createdAt DateTime @default(now())
+  @@id([secid, tradeDate])
+}
+
+model MarketIndexSyncState {
+  secid         String    @id
+  lastAttemptAt DateTime?
+  lastSuccessAt DateTime?
+}
+```
+
+- Данные публичные, к пользователю не привязаны. Удаление подключения их не
+  трогает.
+- Backfill не нужен. Откат — drop двух таблиц; пользовательские данные не
+  затрагиваются.
+- Миграция проверяется на одноразовой копии БД по `.ai/conventions/data.md`.
+
+## Contract Implementation
+
+- DTO повторяют
+  `system-analysis/contracts/investment-performance.openapi.yaml`;
+  `UnavailableReason` — экспортируемый enum.
+- После `npm run openapi:generate` полученный `openapi.json` сверяется с
+  целевым контрактом по ключевым свойствам: маршруты, required-поля,
+  nullable, enum, форматы `Rate`/`Decimal`. Расхождение возвращает change
+  в System Analysis.
+- `npm run openapi:check` входит в gates.
+- Frontend копирует новый `openapi.json` в `src/shared/api/spec/` и
+  перегенерирует типы (`openapi:generate`). `openapi:check` входит в его
+  `verify`.
+
+## Developer Verification Strategy
+
+**backend:**
+- unit-тесты domain:
+  - XIRR на эталонных наборах: значения считаются заранее независимо, в
+    LibreOffice `XIRR` или Python `scipy.optimize`, и записываются как
+    константы с допуском 1e-6;
+  - примеры из спецификации: 10 % на 730 дней, 110 000 ₽ по индексу;
+  - `basis = period`, `NO_SOLUTION`, `AMBIGUOUS_RETURN` (несколько корней), поток в выходной;
+  - кандидаты на переводы без подтверждённой связи, порядок причин;
+- тест клиента MOEX: пагинация, невалидная страница, таймаут — на
+  подменённом fetch, как в `moex.client.spec.ts`;
+- e2e на SQLite: маршрут, доступ, `all`, сбой MOEX с сохранённой и без
+  сохранённой истории;
+- `npm run verify`, `npm run openapi:check`.
+
+**frontend:**
+- тесты VM: состояния, подписи basis, тоны, неизвестная причина;
+- тесты view через RTL + MSW: обгоняю, отстаю, меньше года, неполный,
+  недоступно, загрузка, ошибка;
+- browser-тест вёрстки 390px;
+- `npm run verify`.
+
+## UI/UX Package
+
+**new.** Источник —
+`prototype/index.html` (sha256
+`b7d69ecb4e905350f30d41f89c9f7f5431101edba59478159cd88b761517f0b0`), вариант
+A. Решения Change Owner от 2026-11-07: таблицы потоков нет, коды индексов
+только в «Как считали».
+
+- **Экран:** вкладка «Результат» на `/accounts/:accountId` (и `all`).
+- **Состояния:** загрузка (skeleton из 4 карточек и графика), обгоняю,
+  отстаю, меньше года (info-alert и «за N дн.»), неполный (warning-alert со
+  списком исключённых счетов), недоступно (центрированный блок с причиной),
+  ошибка (существующий паттерн ошибки секции с повтором), индекс недоступен
+  (KPI без сравнения, текст вместо графика).
+- **Компоненты:** сетка из 4 KPI-карточек (`SimpleGrid` cols 1/2/4, как
+  `CurrencyCards`), `Paper` с графиком, `Accordion` «Как считали». Цвета —
+  токены `--wl-color-positive/negative`, серии — `blue.6` (индекс),
+  `dark.4` (вложено), `gray.5` пунктир (без дивидендов).
+- **Responsive.** На 390px одна колонка карточек, нет горизонтальной
+  прокрутки, у графика `h={220}`.
+- **A11y:**
+  - смысл передаётся знаком и текстом, а не только цветом;
+  - hint доступен с клавиатуры;
+  - у графика есть текстовая альтернатива;
+  - alert'ы имеют `role="status"`;
+  - анимация skeleton уважает `prefers-reduced-motion` (Mantine по
+    умолчанию).
+
+## Rollout / Rollback
+
+Один релиз backend и frontend; backend выкатывается первым (новые маршруты
+аддитивны). Feature flag не нужен. Откат: frontend без вкладки, затем
+backend — маршруты и drop таблиц индексов.
+
+## Technical Risks
+
+- **Неподтверждённые переводы** делают результат `all` неполным. Меры:
+  показать исключённые счета и причину; проверить на реальных данных,
+  появится ли надёжный признак связи.
+- **Неоднозначность XIRR** при крупных выводах (несколько корней). Мера:
+  поиск возможных корней и `AMBIGUOUS_RETURN`, а не произвольный корень.
+- **Формат ISS** может измениться. Мера: строгий разбор, сбой вместо
+  частичных данных, сохранённая история остаётся.
@@ -0,0 +1,64 @@
+# Docs Impact
+
+Issue: WealthLedger/main#54
+
+## Summary
+
+Обновление долговременной документации нужно. Появляется новое понятие
+«Результат инвестирования» с методикой. Из-за него снимается общий запрет
+на термин «доходность», и это архитектурно значимое решение: оно требует
+ADR. Ещё добавляются новый источник данных (индексы MOEX), сохраняемая
+публичная история и новые маршруты HTTP API. Существующие формулировки
+«не доходность» для других понятий сохраняются, но получают ссылку на новое
+понятие.
+
+## Documentation Changes
+
+| Action | Path | Content | Source | Reason |
+| --- | --- | --- | --- | --- |
+| create | `docs/adr/023-investment-performance-vs-index.md` | Решение: XIRR как «доходность»; сравнение с теми же потоками в MCFTRR (PME по Long–Nickels), IMOEX только для справки; только RUB; «за N дн.» при истории меньше года; отклонены простой ROI, TWR без истории стоимости, ценовой IMOEX как ориентир и конвертация валют; сохранение публичных закрытий индексов как исключение из ADR 019; оговорка о налоговых ставках MCFTRR и условиях ISS | proposal, system-analysis «Расчёт», «Индексы MOEX», design Decisions backend 3, 5 | Архитектурно значимое решение о методике и хранимых данных |
+| create | `docs/domains/portfolio/investment-performance.md` | Что показывает вкладка «Результат», внешние и внутренние потоки, смысл прибыли, доходности и «тех же денег в индексе», опережение и отставание, правило меньше года, «Все счета» и переводы между своими счетами, причины недоступности и неполноты, отсутствие линии прошлой стоимости, ссылки на спецификацию и HTTP API | specs `investment-performance`, system-analysis «Маппинг операций», «Переводы», «Причины недоступности» | Новая долговременная предметная область |
+| update | `docs/glossary.md` | Новые термины: «Результат инвестирования», «Доходность (XIRR)», «Те же деньги в индексе Мосбиржи», «Опережение рынка», «Внешний денежный поток», каждый с _Не использовать_. У «Точки истории стоимости портфеля» и «Realized Income Analytics» вместо запрета «доходность» — уточнение «не является результатом инвестирования» со ссылкой | specs, ADR 023 | Терминология и снятие конфликтующего запрета |
+| update | `docs/overview.md` | Вкладка «Результат» в списке возможностей; абзац «что есть сейчас / что исполнено…» дополнить вопросом «как сработали вложенные деньги». Оговорка, что выплаты сами по себе не равны доходности, сохраняется | proposal | Обзор продукта |
+| update | `docs/domains/portfolio/overview.md` | Строки 3–6 и 31: снимок по-прежнему не является расчётом полной доходности; полная доходность считается в «Результате инвестирования» (ссылка) | specs | Устранить противоречие |
+| update | `docs/domains/portfolio/all-accounts.md` | «Результат» в режиме «Все счета»: исключение счетов с пометкой о неполноте, переводы между включёнными счетами | specs | Поведение режима `all` |
+| update | `docs/domains/portfolio/data-reference.md` | Поля результата: доли (`Rate`), `basis`, `UnavailableReason` и их отображение; деньги в RUB | system-analysis «Contracts» | Справочник смысла данных |
+| update | `docs/domains/income/overview.md` | Строка 97: вместо «не рассчитывает доходность» — «не рассчитывает доходность; её показывает Результат инвестирования» (ссылка) | specs | Навигация и отсутствие противоречия |
+| update | `docs/integrations/moex.md` | Раздел «Индексы»: MCFTRR и IMOEX, маршрут ISS history, пагинация, догрузка при чтении не чаще раза в час, локальное хранение закрытий, поведение при недоступности, события лога, условия использования данных ISS | system-analysis «Индексы MOEX», design 5 | Новый поток интеграции |
+| update | `docs/architecture/context.md` | Строка 34: MOEX поставляет также дневные закрытия индексов Мосбиржи | system-analysis | Контекст системы |
+| update | `docs/architecture/http-api.md` | Маршруты `GET /brokerage-accounts/{accountId\|all}/performance`: смысл `data: null`, `meta.unavailable`, `completeness`; ссылка на backend-generated OpenAPI, без копии схемы | contract | Описание HTTP API |
+| update | `docs/adr/README.md` | Строка индекса ADR 023 | ADR 023 | Навигация |
+
+## Diagrams
+
+Отдельная диаграмма не переносится. Последовательности чтения и догрузки
+остаются в архивированном change. В `docs/integrations/moex.md` достаточно
+текстового описания догрузки.
+
+## ADR
+
+- **Создать** ADR 023 (см. таблицу), статус Accepted. Ссылки: Issue
+  WealthLedger/main#54 и этот change.
+- ADR 019 не переписывается: ADR 023 явно дополняет его исключением для
+  публичной истории индексов, по образцу ADR 022.
+
+## Non-Changes
+
+- `docs/domains/instruments/bonds.md`, `stocks.md`: «открытый результат не
+  является доходностью к погашению» — другое понятие, текст не меняется.
+- `docs/architecture/containers.md`: состав контейнеров не меняется (MOEX
+  уже есть).
+- `docs/architecture/deployment.md`: конфигурация и сеть не меняются.
+- `docs/design/`: новых долговременных визуальных принципов нет; вкладка
+  использует существующие паттерны.
+- `docs/domains/operations/`: журнал операций не меняется; маппинг типов на
+  потоки описывается в новой странице результата.
+
+## Verification
+
+- После `[docs]` tasks выполнить `npm run verify` в `docs/` (markdownlint
+  с проверкой относительных ссылок и `git diff --check`).
+- Термин «доходность» в `docs/` встречается только в значении «Результат
+  инвестирования» или в явных оговорках «не является»:
+  `grep -rn "доходност" docs/`.
+- Ссылки на specs и OpenAPI ведут на commit после merge реализации.
@@ -0,0 +1,121 @@
+# Proposal
+
+Issue: WealthLedger/main#54
+
+## Why
+
+Пользователь хочет знать, насколько хорошо у него получается инвестировать.
+Конкретно: какой процент приносят вложенные деньги и обгоняет ли он индекс
+Московской биржи. Сейчас приложение показывает только нереализованный результат
+открытых позиций относительно средней цены покупки. Этот показатель не учитывает:
+
+- когда и сколько денег вносилось и выводилось;
+- результат закрытых позиций;
+- купоны, дивиденды, налоги и комиссии.
+
+Поэтому из него нельзя получить ни честный процент годовых, ни сравнение с
+рынком. Текущие принципы продукта прямо запрещают называть показатели
+«доходностью», потому что честного расчёта не было. Это изменение вводит
+такой расчёт с явной методикой.
+
+## What Changes
+
+- Для брокерского счёта и режима «Все счета» появляется результат
+  инвестирования за всё время. В него входят:
+  - **прибыль** в рублях: текущая стоимость минус чистые внешние пополнения;
+  - **доходность** с учётом сумм и дат пополнений и выводов (money-weighted, XIRR).
+- Появляется сравнение с альтернативой «те же деньги в индексе Мосбиржи». Те же
+  пополнения и выводы в те же даты применяются к индексу Мосбиржи с учётом
+  дивидендов после налогов. Показываются его стоимость, его доходность и
+  **опережение или отставание** пользователя в процентных пунктах и рублях.
+- Привычный ценовой индекс Мосбиржи (без дивидендов) показывается только для
+  справки и в сравнении не участвует.
+- Пока история короче года, проценты показываются за фактический период, без
+  пересчёта в годовые.
+- Когда честный расчёт невозможен, результат помечается как «недоступно» или
+  «неполный» с конкретной причиной, а не показывается нулём или
+  приблизительным числом.
+- На странице счёта появляется вкладка «Результат»: ключевые показатели,
+  график «вложено / те же деньги в индексе / справочный индекс / текущая
+  стоимость» и пояснение «Как считали». Утверждённый вид — вариант A прототипа
+  `prototype/index.html`.
+- Термин «доходность» разрешается для этой метрики с точным определением.
+  Остальные запреты на этот термин сохраняются.
+
+## Scope
+
+### In Scope
+
+- Результат за всё время для одного брокерского счёта и для «Все счета».
+- Только рублёвые счета и потоки. В «Все счета» счёт, который нельзя посчитать,
+  исключается с явной пометкой о неполноте результата. Если не осталось ни
+  одного счёта, который можно посчитать, результат «недоступен».
+- Переводы денег и бумаг между счетами, включёнными в «Все счета», не считаются
+  внешними пополнениями и выводами.
+- Получение и локальное хранение дневной истории двух индексов Мосбиржи: с
+  дивидендами после налогов и ценового. Недоступность источника не мешает
+  остальным разделам счёта.
+- Нормативное поведение, публичный контракт для интерфейса, вкладка
+  «Результат», методика и глоссарий в документации.
+
+### Out of Scope / Non-Goals
+
+- Доходность, взвешенная по времени (TWR), периоды «с начала года», «за год» и
+  произвольные, а также восстановление прошлой стоимости портфеля. Линия
+  стоимости портфеля в прошлом на графике не появляется.
+- Валютная конвертация и счета с потоками или позициями не в рублях.
+- Выбор другого ориентира (облигации, инфляция, депозит, составной индекс).
+- Доходность отдельных позиций, налоговый расчёт, прогнозы, риск-метрики,
+  доказательство «альфы».
+- Таблица пополнений и выводов с расчётом паёв индекса.
+- Изменение существующих показателей «нереализованный результат» и «Доход».
+
+## Capabilities
+
+### New Capabilities
+
+- `specs/portfolio/investment-performance/spec.md`: результат инвестирования
+  счёта и «Все счета», сравнение с индексом Мосбиржи, состояния неполноты и
+  недоступности, вкладка «Результат».
+- `specs/instruments/market-index-history/spec.md`: получение и хранение
+  дневной истории индексов Мосбиржи и поведение при недоступности источника.
+
+### Modified Capabilities
+
+Нет. Существующие требования к портфелю, доходу и истории оценок не меняются.
+
+## Impact
+
+- **Пользователь:** получает ответ на вопросы «сколько % годовых» и «обгоняю ли
+  я рынок» на странице счёта.
+- **Домены:** портфель (новая метрика), операции брокерского счёта (источник
+  внешних денежных потоков), инструменты и рыночные данные (история индексов).
+- **Внешние системы:** новая зависимость от публичных исторических данных
+  Московской биржи (индексы) и от полноты истории операций T-Bank.
+- **Затрагиваемые области:** behavioral specs, backend (расчёт, данные индексов,
+  публичный контракт), frontend (вкладка), docs (ADR о методике и термине,
+  глоссарий, домены, интеграция с биржей).
+
+## Success Criteria
+
+- Для рублёвого счёта с известным началом истории пользователь видит прибыль,
+  доходность, результат «тех же денег в индексе» и опережение. Значения
+  совпадают с независимым расчётом XIRR на тех же потоках с точностью до 0,1 п.п.
+- При истории короче года ни один процент не подписан как «годовых».
+- Ни в одном из случаев «начало истории неизвестно», «операции не в рублях»,
+  «ввод бумаг без денежной оценки», «расчёт не сходится», «история индекса
+  недоступна» не показывается число, выдаваемое за результат. Причина видна
+  пользователю.
+- Отказ источника индексов не ломает другие вкладки счёта.
+
+## Assumptions / Dependencies
+
+- История операций T-Bank с даты открытия счёта содержит все пополнения и
+  выводы рублей. Это проверяется на реальных данных первым запуском.
+- Индекс с дивидендами после налогов рассчитан по налоговым ставкам для
+  организаций, а не по НДФЛ физлица. Это ориентир альтернативы, а не точная
+  модель налогов пользователя. Это фиксируется в методике.
+- Публичные данные Мосбиржи используются в личном локальном приложении
+  с указанием источника. Публичное распространение не планируется.
+- Текущая стоимость портфеля берётся из последней полной оценки. Если
+  оценка неполная, результат недоступен.
@@ -0,0 +1,265 @@
+<!doctype html>
+<html lang="ru">
+<head>
+<meta charset="utf-8">
+<meta name="viewport" content="width=device-width, initial-scale=1">
+<title>Прототип: вкладка «Результат» (WealthLedger/main#54)</title>
+<style>
+	/* Значения взяты из frontend/packages/tokens/tokens.json */
+	:root {
+		--canvas: #e9ecef; --surface: #fff; --subtle: #f8f9fa; --text: #242424; --muted: #495057;
+		--border: #dee2e6; --primary: #2563eb; --primary-0: #eff6ff; --positive: #237032; --positive-0: #ebfbee;
+		--negative: #c92a2a; --negative-0: #fff5f5; --warning: #fab005; --warning-0: #fff9db;
+		--c-portfolio: #2563eb; --c-index: #f76707; --c-imoex: #adb5bd; --c-invested: #495057;
+		--r: 8px; --sp-xs: 10px; --sp-sm: 12px; --sp-md: 16px; --sp-lg: 20px; --sp-xl: 32px;
+	}
+	* { box-sizing: border-box; }
+	body { margin: 0; background: var(--canvas); color: var(--text);
+		font: 16px/1.55 -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, sans-serif; }
+	.toolbar { position: sticky; top: 0; z-index: 5; display: flex; flex-wrap: wrap; gap: var(--sp-md);
+		align-items: center; padding: var(--sp-sm) var(--sp-lg); background: #212529; color: #fff; font-size: 14px; }
+	.toolbar fieldset { border: 0; margin: 0; padding: 0; display: flex; flex-wrap: wrap; gap: 4px; align-items: center; min-width: 0; }
+	.toolbar legend { float: left; margin-right: 8px; color: #adb5bd; }
+	.toolbar label { padding: 4px 10px; border-radius: 4px; cursor: pointer; background: #343a40; }
+	.toolbar input { position: absolute; opacity: 0; }
+	.toolbar input:checked + span { color: #fff; }
+	.toolbar label:has(input:checked) { background: var(--primary); }
+	.toolbar label:has(input:focus-visible) { outline: 2px solid #93c5fd; }
+	main { max-width: 1040px; margin: 0 auto; padding: var(--sp-lg); }
+	h1 { font-size: 26px; line-height: 1.35; margin: 0 0 4px; }
+	.sub { color: var(--muted); font-size: 14px; margin: 0 0 var(--sp-md); }
+	.tabs { display: flex; gap: 2px; border-bottom: 2px solid var(--border); margin-bottom: var(--sp-lg); overflow-x: auto; }
+	.tabs span { padding: 8px 14px; font-size: 14px; color: var(--muted); white-space: nowrap; }
+	.tabs .active { color: var(--primary); font-weight: 600; border-bottom: 2px solid var(--primary); margin-bottom: -2px; }
+	.paper { background: var(--surface); border: 1px solid var(--border); border-radius: var(--r); padding: var(--sp-md); }
+	.stack { display: grid; gap: var(--sp-md); grid-template-columns: minmax(0, 1fr); }
+	.grid { display: grid; gap: var(--sp-sm); grid-template-columns: repeat(auto-fit, minmax(210px, 1fr)); }
+	.kpi { margin: 0; }
+	.kpi dt { font-size: 14px; color: var(--muted); display: flex; gap: 6px; align-items: center; }
+	.kpi dd { margin: 2px 0 0; font-size: 26px; font-weight: 700; line-height: 1.3; font-variant-numeric: tabular-nums; }
+	.kpi .note { font-size: 13px; color: var(--muted); font-weight: 400; }
+	.pos { color: var(--positive); } .neg { color: var(--negative); }
+	.badge { display: inline-block; padding: 2px 8px; border-radius: 4px; font-size: 13px; font-weight: 600; }
+	.badge.pos { background: var(--positive-0); } .badge.neg { background: var(--negative-0); }
+	.badge.muted { background: var(--subtle); color: var(--muted); border: 1px solid var(--border); }
+	.hint { display: inline-grid; place-items: center; width: 16px; height: 16px; border-radius: 50%;
+		border: 1px solid var(--muted); font-size: 11px; cursor: help; color: var(--muted); }
+	.section-title { font-size: 18px; font-weight: 600; margin: 0 0 var(--sp-xs); }
+	.legend { display: flex; flex-wrap: wrap; gap: var(--sp-md); font-size: 13px; color: var(--muted); margin-bottom: 6px; }
+	.legend i { display: inline-block; width: 14px; height: 3px; vertical-align: middle; margin-right: 6px; border-radius: 2px; }
+	.legend i.dash { background: repeating-linear-gradient(90deg, var(--c-imoex) 0 4px, transparent 4px 7px); }
+	svg { width: 100%; height: auto; display: block; }
+	.chart-wrap { position: relative; }
+	.tooltip { position: absolute; pointer-events: none; background: #212529; color: #fff; font-size: 12px; padding: 6px 8px;
+		border-radius: 4px; white-space: nowrap; transform: translate(-50%, -110%); display: none; font-variant-numeric: tabular-nums; }
+	details { font-size: 14px; } summary { cursor: pointer; font-weight: 600; }
+	details ul { margin: 8px 0 0; padding-left: 20px; color: var(--muted); }
+	.alert { border-radius: var(--r); padding: var(--sp-sm) var(--sp-md); font-size: 14px; border: 1px solid; }
+	.alert.warn { background: var(--warning-0); border-color: #ffe066; }
+	.alert.info { background: var(--primary-0); border-color: #bfdbfe; }
+	.alert b { display: block; margin-bottom: 2px; }
+	.skeleton { background: linear-gradient(90deg, #f1f3f5, #e9ecef, #f1f3f5); background-size: 200% 100%;
+		animation: sh 1.2s infinite; border-radius: 4px; }
+	@keyframes sh { to { background-position: -200% 0; } }
+	@media (max-width: 48em) {
+		.kpi dd { font-size: 22px; } main { padding: var(--sp-sm); }
+	}
+	@media (prefers-reduced-motion: reduce) { .skeleton { animation: none; } }
+</style>
+</head>
+<body>
+<form class="toolbar" id="controls" aria-label="Настройки прототипа">
+	<fieldset><legend>Состояние</legend>
+		<label><input type="radio" name="state" value="ahead" checked><span>Обгоняю</span></label>
+		<label><input type="radio" name="state" value="behind"><span>Отстаю</span></label>
+		<label><input type="radio" name="state" value="short"><span>&lt; 1 года</span></label>
+		<label><input type="radio" name="state" value="partial"><span>Неполные данные</span></label>
+		<label><input type="radio" name="state" value="unavailable"><span>Недоступно</span></label>
+		<label><input type="radio" name="state" value="loading"><span>Загрузка</span></label>
+	</fieldset>
+</form>
+
+<main>
+	<h1>Все счета</h1>
+	<p class="sub">Брокерский счёт · ИИС · T-Bank</p>
+	<nav class="tabs" aria-label="Разделы счёта">
+		<span>Позиции</span><span>Концентрация</span><span>Деньги</span><span>Операции</span><span>События</span><span>Доход</span>
+		<span class="active" aria-current="page">Результат</span>
+	</nav>
+	<div id="root" aria-live="polite"></div>
+</main>
+
+<script>
+// ---------- Моковые данные ----------
+const DAY = 864e5;
+const d = (s) => new Date(s + 'T00:00:00Z');
+const NOW = d('2026-11-06');
+
+// Детерминированный ПСЧ (генератор псевдослучайных чисел), чтобы ряд индекса был одинаковым при каждой загрузке
+function rng(seed) { return () => (seed = (seed * 16807) % 2147483647) / 2147483647; }
+
+// Ряд индекса MCFTRR, IMOEX ≈ MCFTRR без дивидендов (~6%/год)
+function makeIndex(from, to, drift, seed) {
+	const r = rng(seed), raw = []; let noise = 0;
+	for (let t = from.getTime(); t <= to.getTime(); t += DAY) {
+		const wd = new Date(t).getUTCDay(); if (wd === 0 || wd === 6) continue;
+		noise += (r() - 0.5) * 0.026 + (t > d('2025-06-01').getTime() && t < d('2025-09-01').getTime() ? -0.0018 : 0);
+		raw.push({ t, noise });
+	}
+	// Шум нормируется так, чтобы итоговый рост ряда точно совпал с drift: годовых для MCFTRR, drift − 6 % для IMOEX
+	const end = raw[raw.length - 1], years = (end.t - raw[0].t) / (365 * DAY);
+	return raw.map(({ t, noise: n }) => {
+		const f = (t - raw[0].t) / (end.t - raw[0].t), wiggle = n - f * end.noise;
+		return { t, mcftrr: 7000 * Math.pow(1 + drift, f * years) * Math.exp(wiggle), imoex: 3000 * Math.pow(1 + drift - 0.06, f * years) * Math.exp(wiggle) };
+	});
+}
+
+const SCENARIOS = {
+	ahead:   { start: '2023-03-14', flows: [['2023-03-14', 300000], ['2023-09-01', 150000], ['2024-02-10', 200000], ['2024-08-20', 100000], ['2025-03-05', 250000], ['2025-10-01', -120000], ['2026-04-15', 180000]], value: 1536400, drift: 0.13 },
+	behind:  { start: '2023-03-14', flows: [['2023-03-14', 300000], ['2023-09-01', 150000], ['2024-02-10', 200000], ['2024-08-20', 100000], ['2025-03-05', 250000], ['2025-10-01', -120000], ['2026-04-15', 180000]], value: 1172400, drift: 0.13 },
+	short:   { start: '2026-02-02', flows: [['2026-02-02', 400000], ['2026-05-12', 150000], ['2026-08-03', 100000]], value: 688900, drift: 0.11 },
+	partial: { start: '2023-03-14', flows: [['2023-03-14', 300000], ['2023-09-01', 150000], ['2024-02-10', 200000], ['2024-08-20', 100000], ['2025-03-05', 250000], ['2025-10-01', -120000], ['2026-04-15', 180000]], value: 1536400, drift: 0.13,
+		warnings: ['Счёт «Валютный» исключён: есть операции в USD. Результат посчитан по 2 из 3 счетов.'] },
+};
+
+// ---------- Расчёт: та же методика, что предлагается для backend ----------
+// XIRR: найти r, при котором Σ CF_i·(1+r)^(-(t_i−t0)/365) = 0. Пополнение со знаком «−» (деньги ушли от инвестора), текущая стоимость со знаком «+».
+function npv(rate, cfs) { const t0 = cfs[0].t; return cfs.reduce((s, c) => s + c.amount / Math.pow(1 + rate, (c.t - t0) / (365 * DAY)), 0); }
+function xirr(cfs) {
+	let lo = -0.9999, hi = 10; let flo = npv(lo, cfs), fhi = npv(hi, cfs);
+	if (flo * fhi > 0) return null; // ponytail: бисекция; Ньютон + бисекция как запасной вариант в backend, если важна скорость
+	for (let i = 0; i < 200; i++) { const m = (lo + hi) / 2, fm = npv(m, cfs); if (Math.abs(fm) < 1e-6) return m; (flo * fm < 0) ? (hi = m) : (lo = m, flo = fm); }
+	return (lo + hi) / 2;
+}
+const periodReturn = (annual, days) => Math.pow(1 + annual, days / 365) - 1;
+
+function compute(sc) {
+	const idx = makeIndex(d(sc.start), NOW, sc.drift, 42);
+	const flows = sc.flows.map(([s, a]) => ({ t: d(s).getTime(), amount: a }));
+	// Теневой портфель: каждое пополнение покупает «паи» индекса по закрытию дня, вывод их продаёт
+	let units = 0, unitsImoex = 0, invested = 0, fi = 0; const series = [];
+	for (const p of idx) {
+		while (fi < flows.length && flows[fi].t <= p.t) { invested += flows[fi].amount; units += flows[fi].amount / p.mcftrr; unitsImoex += flows[fi].amount / p.imoex; fi++; }
+		series.push({ t: p.t, invested, shadow: units * p.mcftrr, imoex: unitsImoex * p.imoex });
+	}
+	const last = series[series.length - 1];
+	const netInvested = flows.reduce((s, f) => s + f.amount, 0);
+	const cfs = (end) => [...flows.map((f) => ({ t: f.t, amount: -f.amount })), { t: NOW.getTime(), amount: end }];
+	const days = Math.round((NOW - d(sc.start)) / DAY);
+	const you = xirr(cfs(sc.value)), shadow = xirr(cfs(last.shadow)), imoex = xirr(cfs(last.imoex));
+	return { series, days, netInvested, value: sc.value, profit: sc.value - netInvested,
+		shadowValue: last.shadow, imoexValue: last.imoex, you, shadow, imoex, short: days < 365, warnings: sc.warnings || [], start: sc.start };
+}
+
+// ---------- Форматирование (ru-RU, как в shared/lib) ----------
+const rub = (v, sign) => (sign && v > 0 ? '+' : v < 0 ? '−' : '') + Math.abs(Math.round(v)).toLocaleString('ru-RU') + ' ₽';
+const pct = (v, sign) => (sign && v > 0 ? '+' : v < 0 ? '−' : '') + Math.abs(v * 100).toLocaleString('ru-RU', { minimumFractionDigits: 1, maximumFractionDigits: 1 }) + ' %';
+const pp = (v) => (v > 0 ? '+' : v < 0 ? '−' : '') + Math.abs(v * 100).toLocaleString('ru-RU', { minimumFractionDigits: 1, maximumFractionDigits: 1 }) + ' п.п.';
+const date = (t) => new Date(t).toLocaleDateString('ru-RU', { day: 'numeric', month: 'short', year: 'numeric', timeZone: 'UTC' });
+const tone = (v) => v > 0 ? 'pos' : v < 0 ? 'neg' : '';
+const esc = (s) => String(s).replace(/[&<>]/g, (c) => ({ '&': '&amp;', '<': '&lt;', '>': '&gt;' }[c]));
+
+// Пока история короче года, показываем доходность за период, а не годовую
+function rate(m, key) {
+	const a = m[key]; if (a == null) return { text: '—', label: '' };
+	return m.short ? { v: periodReturn(a, m.days), text: pct(periodReturn(a, m.days), true), label: `за ${m.days} дн.` }
+		: { v: a, text: pct(a, true), label: 'годовых' };
+}
+function delta(m) { const y = rate(m, 'you'), s = rate(m, 'shadow'); return { pp: y.v - s.v, rub: m.value - m.shadowValue }; }
+
+// ---------- График (inline SVG, в production — Mantine AreaChart/LineChart) ----------
+function chart(m, { height = 260 } = {}) {
+	const W = 960, H = height, P = { l: 70, r: 16, t: 12, b: 28 };
+	const s = m.series, xs = (t) => P.l + (t - s[0].t) / (s[s.length - 1].t - s[0].t) * (W - P.l - P.r);
+	const max = Math.max(...s.map((p) => Math.max(p.shadow, p.invested, p.imoex)), m.value) * 1.05;
+	const ys = (v) => P.t + (1 - v / max) * (H - P.t - P.b);
+	const line = (k) => s.map((p, i) => (i ? 'L' : 'M') + xs(p.t).toFixed(1) + ' ' + ys(p[k]).toFixed(1)).join('');
+	const step = s.map((p, i) => (i ? `H${xs(p.t).toFixed(1)}V${ys(p.invested).toFixed(1)}` : `M${xs(p.t).toFixed(1)} ${ys(p.invested).toFixed(1)}`)).join('');
+	const ticks = [0, .25, .5, .75, 1].map((f) => max * f);
+	const years = [...new Set(s.map((p) => new Date(p.t).getUTCFullYear()))];
+	const ex = xs(s[s.length - 1].t), ey = ys(m.value);
+	return `<div class="chart-wrap">
+	<div class="legend" aria-hidden="true">
+		<span><i style="background:var(--c-invested)"></i>Вложено (нетто)</span>
+		<span><i style="background:var(--c-index)"></i>Те же деньги в индексе Мосбиржи</span>
+		<span><i class="dash"></i>Индекс Мосбиржи без дивидендов</span>
+		<span><i style="background:var(--c-portfolio);height:10px;width:10px;border-radius:50%"></i>Ваш портфель сейчас</span>
+	</div>
+	<svg viewBox="0 0 ${W} ${H}" role="img" aria-label="Вложено ${rub(m.netInvested)}, те же деньги в индексе Мосбиржи стоили бы ${rub(m.shadowValue)}, ваш портфель ${rub(m.value)}">
+		${ticks.map((v) => `<line x1="${P.l}" x2="${W - P.r}" y1="${ys(v)}" y2="${ys(v)}" stroke="#f1f3f5"/><text x="${P.l - 8}" y="${ys(v) + 4}" font-size="12" text-anchor="end" fill="#868e96">${(v / 1e6).toLocaleString('ru-RU', { maximumFractionDigits: 2 })} млн</text>`).join('')}
+		${years.map((y) => { const t = Math.max(d(y + '-01-01').getTime(), s[0].t); return `<text x="${xs(t)}" y="${H - 8}" font-size="12" fill="#868e96">${y}</text>`; }).join('')}
+		<path d="${line('shadow')} V${ys(0)} H${P.l} Z" fill="var(--c-index)" opacity=".08"/>
+		<path d="${line('imoex')}" fill="none" stroke="var(--c-imoex)" stroke-width="1.5" stroke-dasharray="4 3"/>
+		<path d="${line('shadow')}" fill="none" stroke="var(--c-index)" stroke-width="2"/>
+		<path d="${step}" fill="none" stroke="var(--c-invested)" stroke-width="2"/>
+		<line x1="${ex}" x2="${ex}" y1="${ys(m.shadowValue)}" y2="${ey}" stroke="var(--c-portfolio)" stroke-dasharray="2 2"/>
+		<circle cx="${ex}" cy="${ey}" r="6" fill="var(--c-portfolio)" stroke="#fff" stroke-width="2"/>
+		<rect class="hit" x="${P.l}" y="${P.t}" width="${W - P.l - P.r}" height="${H - P.t - P.b}" fill="transparent"/>
+	</svg><div class="tooltip"></div></div>
+	<p class="sub" style="margin:6px 0 0">Линии стоимости вашего портфеля в прошлом нет: история стоимости ещё не накоплена. Точка справа — текущая оценка.</p>`;
+}
+function bindTooltip(m) {
+	document.querySelectorAll('.chart-wrap').forEach((w) => {
+		const svg = w.querySelector('svg'), tip = w.querySelector('.tooltip'), s = m.series;
+		svg.addEventListener('mousemove', (e) => {
+			const r = svg.getBoundingClientRect(), f = Math.min(1, Math.max(0, ((e.clientX - r.left) / r.width * 960 - 70) / (960 - 86)));
+			const p = s[Math.round(f * (s.length - 1))];
+			tip.style.display = 'block'; tip.style.left = (e.clientX - r.left) + 'px'; tip.style.top = (e.clientY - r.top) + 'px';
+			tip.innerHTML = `${date(p.t)}<br>Вложено: ${rub(p.invested)}<br>В индексе: ${rub(p.shadow)}<br>Без дивидендов: ${rub(p.imoex)}`;
+		});
+		svg.addEventListener('mouseleave', () => (tip.style.display = 'none'));
+	});
+}
+
+// ---------- Общие блоки ----------
+const methodology = (m) => `<details class="paper"><summary>Как считали</summary><ul>
+	<li>Период: с ${date(d(m.start))} (начало истории счёта) по ${date(NOW)}, ${m.days} дн.</li>
+	<li>Учтены пополнения и выводы рублей. Купоны, дивиденды, комиссии и налоги уже входят в текущую стоимость портфеля.</li>
+	<li><b>Доходность (XIRR)</b> учитывает, когда и сколько вы вносили. ${m.short ? 'История меньше года, поэтому процент показан за период, а не в годовых.' : 'Процент годовых.'}</li>
+	<li><b>Те же деньги в индексе Мосбиржи</b>: каждое пополнение в тот же день «покупает» индекс Мосбиржи с учётом дивидендов после налогов (MCFTRR), каждый вывод его «продаёт».</li>
+	<li>Привычный индекс Мосбиржи (IMOEX) не учитывает дивиденды, поэтому показан на графике только для справки и в сравнении не участвует.</li>
+	<li>Цены индексов — MOEX ISS, закрытие дня. Это не налоговый расчёт.</li></ul></details>`;
+const warnings = (m) => m.warnings.map((w) => `<div class="alert warn" role="status"><b>Результат неполный</b>${esc(w)}</div>`).join('');
+const shortNote = (m) => m.short ? `<div class="alert info"><b>История меньше года</b>Проценты показаны за ${m.days} дн. без пересчёта в годовые: короткий срок даёт неустойчивые годовые значения.</div>` : '';
+const hint = (t) => `<span class="hint" tabindex="0" title="${t}" aria-label="${t}">?</span>`;
+
+// ---------- Вариант A (выбран Change Owner 2026-11-07) ----------
+function variantA(m) {
+	const y = rate(m, 'you'), s = rate(m, 'shadow'), dl = delta(m);
+	return `<div class="stack">${warnings(m)}${shortNote(m)}
+	<div class="grid">
+		<dl class="paper kpi"><dt>Доходность ${hint('XIRR: ставка, при которой ваши пополнения и выводы дают текущую стоимость')}</dt><dd class="${tone(y.v)}">${y.text}</dd><dd class="note">${y.label}</dd></dl>
+		<dl class="paper kpi"><dt>Прибыль</dt><dd class="${tone(m.profit)}">${rub(m.profit, true)}</dd><dd class="note">${rub(m.value)} сейчас · вложено ${rub(m.netInvested)}</dd></dl>
+		<dl class="paper kpi"><dt>Те же деньги в индексе Мосбиржи ${hint('Если бы каждое пополнение в тот же день вкладывалось в индекс Мосбиржи с учётом дивидендов после налогов')}</dt><dd>${s.text}</dd><dd class="note">${s.label} · стоили бы ${rub(m.shadowValue)}</dd></dl>
+		<dl class="paper kpi"><dt>${dl.pp >= 0 ? 'Опережение рынка' : 'Отставание от рынка'}</dt><dd class="${tone(dl.pp)}">${pp(dl.pp)}</dd><dd class="note"><span class="badge ${tone(dl.rub)}">${rub(dl.rub, true)}</span> к индексу</dd></dl>
+	</div>
+	<section class="paper"><h2 class="section-title">Ваш портфель против индекса</h2>${chart(m)}</section>
+	${methodology(m)}</div>`;
+}
+
+// ---------- Состояния без данных ----------
+const unavailable = () => `<div class="stack"><div class="paper" style="text-align:center;padding:var(--sp-xl)">
+	<div class="section-title">Доходность недоступна</div>
+	<p class="sub" style="max-width:520px;margin:8px auto">Для счёта «ИИС» неизвестна дата открытия. Без полной истории пополнений нельзя честно посчитать доходность: показали бы неверное число вместо нуля.</p>
+	<span class="badge muted">Причина: начало истории неизвестно</span>
+	<p class="sub" style="margin-top:var(--sp-md)">Другие возможные причины: операции не в рублях · ввод или вывод ценных бумаг без денежной оценки · расчёт не сходится · история индекса MOEX временно недоступна.</p>
+	</div></div>`;
+const loading = () => `<div class="stack"><div class="grid">${'<div class="paper"><div class="skeleton" style="height:14px;width:60%"></div><div class="skeleton" style="height:30px;width:80%;margin-top:8px"></div></div>'.repeat(4)}</div>
+	<div class="paper"><div class="skeleton" style="height:240px"></div></div></div>`;
+
+// ---------- Отрисовка ----------
+const form = document.getElementById('controls'), root = document.getElementById('root');
+const cache = {};
+function render() {
+	const state = form.state.value;
+	if (state === 'unavailable') return (root.innerHTML = unavailable());
+	if (state === 'loading') return (root.innerHTML = loading());
+	const m = cache[state] ||= compute(SCENARIOS[state]);
+	root.innerHTML = variantA(m);
+	bindTooltip(m);
+}
+form.addEventListener('change', render);
+render();
+</script>
+</body>
+</html>
@@ -0,0 +1,139 @@
+# QA Analysis
+
+Issue: WealthLedger/main#54
+
+## Verification Scope
+
+**In:**
+- все Requirements и Scenarios `portfolio/investment-performance` и
+  `instruments/market-index-history`;
+- контракт `investment-performance.openapi.yaml`;
+- семантика ошибок System Analysis.
+
+**Out:**
+- TWR, периоды, валютная конвертация;
+- корректность самой синхронизации T-Bank (покрыта её спецификациями);
+- точность значений MCFTRR у источника.
+
+## Coverage Matrix
+
+| Requirement / Scenario | Проверка на уровне системы |
+| --- | --- |
+| Результат счёта: рублёвый счёт с известным началом | API: ответ 200 со всеми полями; значения совпадают с эталоном (ниже) |
+| Результат счёта: счёт недоступен через подключение | API: чужой `accountId` → 404, в теле нет финансовых полей |
+| Внешние потоки: пополнения, вывод, дивиденды | Эталонный счёт A: `netInvested = 130000`, `profit = 10000` |
+| Внешние потоки: кандидат на перевод между счетами в `all` | Счета B и C с равными суммами в пределах 5 минут исключаются с `UNCONFIRMED_TRANSFER`, а не объявляются внутренней парой |
+| Внешние потоки: перевод на счёт вне результата | Счёт B исключён (USD), его пополнение от C → вывод у C в `all` |
+| Доходность: период больше года | Счёт D: 100 000 → 121 000 за 730 дн. → `return.value = 0.1`, `basis = annual` |
+| Доходность: меньше года | Счёт E, 200 дн.: `basis = period`; в UI нет слова «годовых» ни в одном значении |
+| Доходность: нет решения | Счёт F (текущая стоимость 0 после пополнений, без выводов): `NO_SOLUTION`, `profit` доступен, `outperformance = null` |
+| Доходность: несколько решений | Набор потоков с двумя корнями XIRR: `AMBIGUOUS_RETURN`, прибыль доступна, `outperformance = null` |
+| Индекс: пополнение и рост индекса | Подменённая история (1 000 → 1 100) или ручной расчёт по реальным закрытиям: `benchmark.value = 110000`, `outperformance.money = 5000` |
+| Индекс: поток в выходной | Пополнение в субботу → используется закрытие пятницы (проверяется по `series` в день потока) |
+| Индекс: отставание | Счёт со стоимостью ниже теневой: отрицательные `percentagePoints` и `money`, в UI «Отставание от рынка» |
+| Справочный индекс недоступен | IMOEX нет, MCFTRR есть: `reference.unavailableReason` задан, `benchmark` и `outperformance` есть, в UI нет пунктирной линии |
+| Недоступно: неизвестная дата открытия | Счёт с `historyBoundary = unknown`: `data: null`, `HISTORY_START_UNKNOWN`; в UI «Доходность недоступна», нет нулей |
+| USD-поток игнорируется | Счёт с пополнением в USD: результат считается по рублёвым потокам, `excludedAccounts` пуст |
+| Недоступно: даты оценок в `all` различаются | Последние оценки A и B в разные московские дни → `data: null`, `ACCOUNT_VALUATION_DATES_DIFFER`; стоимость не складывается |
+| Недоступно: индекс недоступен | MOEX заблокирован и истории нет: `profit` есть, `benchmark.unavailableReason = INDEX_HISTORY_UNAVAILABLE`, `series = []` |
+| Недоступно: остальные причины | Перевод бумаг без пары → `UNVALUED_SECURITIES_TRANSFER`; позиция без цены → `PORTFOLIO_VALUATION_INCOMPLETE`; незавершённая синхронизация → `OPERATIONS_HISTORY_INCOMPLETE` |
+| Вкладка: обгоняю, меньше года, неполный, недоступный, методика | UI по соответствующим данным; формулировки и тоны как в UI/UX Package; «Как считали» содержит все пункты спецификации |
+| Вкладка: загрузка, ошибка не ломает другие вкладки | Задержка ответа → skeleton без чисел; 500 на `/performance` → ошибка только во вкладке, остальные вкладки работают |
+| График: наведение, отсутствие прошлой стоимости | Наведение и фокус показывают дату и 3 значения; есть пояснение под графиком; `aria-label` с итогами |
+| История индексов: первое получение, выходной | После первого чтения есть закрытия торговых дней без дубликатов; повторное чтение не меняет число записей; субботних дат нет |
+| История индексов: источник недоступен, история есть / нет | Блокировка `iss.moex.com` после первичной загрузки → результат полный; на чистой БД → `INDEX_HISTORY_UNAVAILABLE`, остальные вкладки работают |
+
+**Эталон.** Для счетов A–F и реальных данных пользователя XIRR
+пересчитывается независимо (LibreOffice `XIRR` по тем же потокам и
+`currentValue` в дату `to`). Допуск — 0,1 п.п., по Success Criteria.
+
+## Cross-system Verification
+
+- **Контракт.** Ответы обоих маршрутов валидируются по
+  `investment-performance.openapi.yaml`: required, nullable, enum, шаблон
+  `Decimal`. Неизвестное значение `UnavailableReason`, подставленное в ответ
+  через прокси или мок, UI показывает общей недоступностью без падения.
+- **Ошибки доступа.** 401 без сессии; 503 `TBANK_NOT_CONNECTED` без
+  подключения; 404 для счёта не из подключения. `all` без подключения тоже
+  503.
+- **Таймаут MOEX.** Ответ ISS задерживается больше 10 с: результат приходит
+  с сохранённой историей или с `INDEX_HISTORY_UNAVAILABLE`. Время ответа —
+  не больше ~10 с плюс время расчёта, без бесконечного ожидания.
+- **Параллельные чтения.** Два одновременных GET на чистой БД дают одну
+  серию запросов к ISS и одинаковые ответы.
+- **Частота догрузки.** Повторное чтение в течение часа после сбоя не
+  обращается к ISS (проверяется по логам).
+- **Порядок данных.** Пополнение, исполненное после `fetchedAt` Portfolio, в
+  потоки не входит.
+
+## Risk-based Priorities
+
+1. **Критично — деньги.** Значения прибыли, XIRR и опережения совпадают с
+   эталоном. Ни один недоступный случай не показывает число.
+2. **Критично — доступ.** Нет утечки чужих счетов в `all` и `meta.unavailable`.
+3. **Высокий риск — переводы в `all`** (эвристика парности) и счета с
+   реальной историей пользователя.
+4. **Высокий риск — меньше года.** Ни одного «годовых».
+5. **Средний риск — устойчивость к MOEX**, график и a11y.
+
+## Test Data and Environment Needs
+
+- Пользователь с подключением T-Bank и наборами счетов:
+  - A — пополнения, вывод, дивиденды;
+  - B — USD;
+  - C — перевод с B и C;
+  - D — 730 дн.;
+  - E — 200 дн.;
+  - F — нет решения;
+  - G — `historyBoundary = unknown`;
+  - H — перевод бумаг без пары;
+  - I — позиция без цены.
+
+  Если sandbox T-Bank такие данные не даёт, их записывают напрямую в
+  одноразовую SQLite-копию.
+- Возможность блокировать `iss.moex.com` (сеть или прокси) и задерживать
+  его ответы.
+- Чистая БД и БД с предзагруженной историей индексов.
+- Реальные данные Change Owner для финальной приёмки.
+
+## Manual / Exploratory Scope
+
+- Реальные счета пользователя:
+  - правдоподобие результата;
+  - парность переводов между своими счетами;
+  - какие счета исключаются и почему.
+- Вёрстка 390px и desktop; клавиатурная навигация (вкладка, hint, «Как
+  считали», график); экранный диктор читает итоги графика.
+- Переключение счёт ↔ `all` и обратно: нет устаревших данных другого счёта.
+
+## Automation Candidates
+
+- Black-box API-проверки контракта и сценариев A–I: deferred until QA repo
+  exists.
+- E2E вкладки «Результат» (состояния ready, unavailable, incomplete,
+  error): deferred until QA repo exists.
+
+## Observability Verification
+
+- `integration.moex.index_history.succeeded` / `.failed` появляются при
+  догрузке и сбое; в них есть secid, диапазон, pages, durationMs и нет
+  данных пользователя.
+- В логах расчёта нет сумм и идентификаторов операций.
+
+## Regression Impact
+
+- Вкладки счёта: позиции, концентрация, деньги, операции, события, доход —
+  переключение и загрузка не меняются.
+- Запись истории оценки Portfolio после выноса признака полной оценки
+  (`portfolio-value-history`): полные оценки по-прежнему создают точки,
+  неполные — нет.
+- Существующие запросы к MOEX по облигациям.
+- `openapi:check` обоих репозиториев.
+
+## Gaps / Blockers
+
+- **Подтверждение переводов** отсутствует в текущем контракте T-Bank.
+  Routing: System Analysis при появлении нового признака связи; до этого
+  кандидаты исключаются с явной причиной, не выдавая сомнительный процент.
+- **Sandbox T-Bank** может не воспроизвести все наборы. Routing: Test Data —
+  наполнение одноразовой SQLite-копии; не блокирует.
@@ -0,0 +1,26 @@
+## Purpose
+Определяет получение и локальное хранение дневной истории индексов Московской биржи, нужных для сравнения результата инвестирования, и поведение при недоступности источника.
+
+## ADDED Requirements
+
+### Requirement: Дневная история индексов Мосбиржи
+Система SHALL получать из публичных исторических данных Московской биржи и хранить локально значения закрытия торговых дней двух индексов: индекса с дивидендами после налогов (MCFTRR) и ценового индекса (IMOEX). Значение MUST храниться точно, с датой торгового дня по Europe/Moscow. Повторное получение того же дня MUST NOT создавать дубликат. Отсутствие торгов в день MUST NOT заполняться выдуманным значением.
+
+#### Scenario: Первое получение истории
+- **WHEN** результату нужен период, не покрытый сохранённой историей индекса
+- **THEN** система получает недостающие торговые дни и сохраняет их без дубликатов
+
+#### Scenario: Выходной день
+- **WHEN** в календарный день не было торгов
+- **THEN** для этого дня не сохраняется никакое значение индекса
+
+### Requirement: Свежесть и недоступность истории индексов
+Сохранённая история MUST переиспользоваться без повторного получения уже сохранённых дней. История MUST дополняться до последнего доступного торгового дня не реже раза в сутки при запросе результата. Недоступность или ошибка источника MUST NOT удалять сохранённую историю и MUST NOT задерживать или ломать другие ответы системы. Если сохранённая история не покрывает нужный период, потребитель MUST получить явную недоступность индекса, а не неполные значения, выдаваемые за полные.
+
+#### Scenario: Источник недоступен, история сохранена
+- **WHEN** источник Московской биржи недоступен, а сохранённая история покрывает период результата до предыдущего торгового дня
+- **THEN** результат рассчитывается по сохранённой истории
+
+#### Scenario: Источник недоступен, истории нет
+- **WHEN** источник Московской биржи недоступен и история индекса за период не сохранена
+- **THEN** сравнение с индексом недоступно с причиной «история индекса недоступна», а остальные разделы счёта работают без изменений
@@ -0,0 +1,152 @@
+## Purpose
+Определяет результат инвестирования брокерского счёта и режима «Все счета» за всё время: прибыль, доходность с учётом сумм и дат пополнений и сравнение с теми же деньгами в индексе Мосбиржи.
+
+## ADDED Requirements
+
+### Requirement: Результат инвестирования выбранного счёта
+Система SHALL предоставлять аутентифицированному User результат инвестирования за всё время для открытого поддерживаемого Brokerage Account, доступного через текущий T-Bank connection User, и для режима «Все счета» (`all`). История операций MUST быть полной с известной даты начала истории счёта; период результата MUST начинаться с даты первого внешнего потока и заканчиваться датой последней полной оценки Portfolio. Даты MUST определяться календарными днями по Europe/Moscow. Результат MUST рассчитываться только в RUB без валютной конвертации.
+
+#### Scenario: Рублёвый счёт с известным началом истории
+- **WHEN** User открывает результат рублёвого счёта с известным началом истории, полной историей операций и полной текущей оценкой Portfolio
+- **THEN** система возвращает период результата, чистые внешние вложения, текущую стоимость, прибыль, доходность, результат тех же денег в индексе и опережение
+
+#### Scenario: Счёт недоступен через текущее подключение
+- **WHEN** User запрашивает результат счёта, недоступного через текущий T-Bank connection
+- **THEN** система не раскрывает никаких значений результата этого счёта
+
+### Requirement: Внешние денежные потоки
+Внешним денежным потоком MUST считаться только пополнение счёта рублями (положительный поток) и вывод рублей со счёта (отрицательный поток) на дату исполнения. Пополнения и выводы не в RUB MUST NOT учитываться и MUST NOT делать результат недоступным: система поддерживает только RUB и не конвертирует валюты. Сделки, купоны, дивиденды, погашения, амортизация, налоги и комиссии MUST NOT считаться внешними потоками: их влияние входит в текущую стоимость. В режиме `all` переводы денег и бумаг между счетами, входящими в результат, MUST NOT считаться внешними потоками. Чистые внешние вложения MUST равняться точной сумме внешних потоков периода. Прибыль MUST равняться точной разности текущей стоимости и чистых внешних вложений.
+
+#### Scenario: Пополнения, вывод и дивиденды
+- **WHEN** на счёт внесено 100 000 RUB и 50 000 RUB, выведено 20 000 RUB, получены дивиденды 3 000 RUB, а текущая стоимость Portfolio 140 000 RUB
+- **THEN** чистые внешние вложения равны 130 000 RUB, прибыль равна 10 000 RUB, а дивиденды не учитываются как отдельный поток
+
+#### Scenario: Подтверждённый перевод между счетами в режиме «Все счета»
+- **WHEN** в режиме `all` источник однозначно подтверждает перевод 50 000 RUB со счёта A на счёт B, и оба счёта входят в результат
+- **THEN** перевод не меняет чистые внешние вложения и доходность режима `all`
+
+#### Scenario: Перевод на счёт вне результата
+- **WHEN** в режиме `all` деньги переведены на счёт, не входящий в результат
+- **THEN** перевод учитывается как вывод в дату исполнения
+
+#### Scenario: Совпадение операций не доказывает перевод
+- **WHEN** в режиме `all` вывод на одном счёте и пополнение другого совпадают по сумме и времени, но источник не подтверждает связь между ними
+- **THEN** система не объявляет их внутренним переводом, исключает затронутые счета из рассчитанной части результата и показывает причину неполноты; если не осталось счетов для расчёта, результат недоступен
+
+### Requirement: Доходность с учётом сумм и дат потоков
+Доходность MUST быть годовой ставкой r, при которой сумма всех внешних потоков, дисконтированных по фактическому числу дней от начала периода по формуле `(1 + r)^(дни / 365)`, и текущей стоимости равна нулю (XIRR). Пополнения MUST входить в расчёт как вложение User, выводы и текущая стоимость — как возврат. Если продолжительность периода меньше 365 дней, система MUST возвращать и показывать доходность за период `(1 + r)^(дни / 365) − 1` с явным числом дней и MUST NOT показывать годовое значение. Если единственное решение не найдено, доходность MUST быть недоступной с причиной «расчёт не сходится», а не нулём.
+
+#### Scenario: Период больше года
+- **WHEN** 100 000 RUB внесены ровно 730 дней назад, других потоков не было, а текущая стоимость 121 000 RUB
+- **THEN** доходность равна 10,0 % годовых
+
+#### Scenario: Период меньше года
+- **WHEN** период результата составляет 200 дней
+- **THEN** доходность показывается как процент за 200 дней, и ни одно значение результата не подписано как «годовых»
+
+#### Scenario: Первое пополнение позже открытия счёта
+- **WHEN** счёт открыт 300 дней назад, 100 000 RUB внесены 100 дней назад, а текущая стоимость 110 000 RUB
+- **THEN** период равен 100 дням, а доходность показывается как +10,0 % за 100 дней
+
+#### Scenario: Нет решения
+- **WHEN** набор потоков и текущая стоимость не дают ни одной ставки, обнуляющей сумму
+- **THEN** доходность и опережение недоступны с причиной «расчёт не сходится», а прибыль остаётся доступной
+
+#### Scenario: Несколько ставок
+- **WHEN** набор потоков допускает более одной ставки доходности
+- **THEN** доходность и опережение недоступны с причиной «расчёт неоднозначен», а прибыль остаётся доступной
+
+### Requirement: Те же деньги в индексе Мосбиржи
+Система SHALL рассчитывать альтернативный результат: каждый внешний поток в ту же дату применяется к индексу Мосбиржи с учётом дивидендов после налогов (MCFTRR) по значению закрытия этого дня. Если в дату потока не было торгов, MUST использоваться последнее предшествующее закрытие. Стоимость альтернативы MUST равняться остатку условных паёв индекса, умноженному на последнее закрытие не позже конца периода. Доходность альтернативы MUST считаться той же методикой и за тот же период, что и доходность User. Опережение MUST равняться разнице доходностей User и альтернативы в процентных пунктах и разнице текущей стоимости и стоимости альтернативы в RUB. Отрицательное опережение MUST называться отставанием.
+
+#### Scenario: Пополнение и рост индекса
+- **WHEN** 100 000 RUB внесены в день, когда закрытие индекса было 1 000, к концу периода закрытие индекса 1 100, а текущая стоимость Portfolio 115 000 RUB
+- **THEN** стоимость тех же денег в индексе равна 110 000 RUB, а опережение составляет +5 000 RUB
+
+#### Scenario: Поток в неторговый день
+- **WHEN** пополнение исполнено в субботу
+- **THEN** для него используется закрытие индекса последнего торгового дня до этой субботы
+
+#### Scenario: Отставание от индекса
+- **WHEN** доходность User ниже доходности тех же денег в индексе
+- **THEN** результат показывается как отставание с отрицательными значениями в процентных пунктах и RUB
+
+### Requirement: Справочный индекс без дивидендов
+Система SHALL дополнительно рассчитывать тот же альтернативный результат по ценовому индексу Мосбиржи (IMOEX) только для справки. Справочный индекс MUST NOT участвовать в опережении и отставании. Его недоступность MUST NOT делать недоступным основной результат.
+
+#### Scenario: Справочный индекс недоступен
+- **WHEN** история ценового индекса недоступна, а история индекса с дивидендами доступна
+- **THEN** основной результат и опережение показываются, а справочная линия отсутствует с пометкой о недоступности
+
+### Requirement: Недоступный и неполный результат
+Система MUST NOT возвращать числовой результат, выдаваемый за доходность, если его нельзя рассчитать честно. Для одного счёта результат MUST быть недоступным с машиночитаемой причиной, если:
+- начало истории операций неизвестно;
+- есть ввод или вывод ценных бумаг без денежной оценки, а в режиме `all` — неподтверждённый кандидат на перевод между своими счетами;
+- текущая оценка Portfolio неполная;
+- история операций не получена полностью.
+
+Если история индекса с дивидендами не покрывает период, доступными MUST оставаться только чистые вложения, текущая стоимость и прибыль, а доходность альтернативы и опережение MUST быть недоступны с причиной. В режиме `all` счёт с причиной недоступности MUST исключаться из результата, а результат MUST помечаться как неполный с перечнем исключённых счетов и причин. Если не осталось ни одного счёта, результат режима `all` MUST быть недоступным.
+
+#### Scenario: Неизвестная дата открытия
+- **WHEN** у счёта неизвестно начало истории операций
+- **THEN** результат счёта недоступен с причиной «начало истории неизвестно», и ни одно значение не показывается как ноль
+
+#### Scenario: Пополнение в USD не учитывается
+- **WHEN** у рублёвого счёта есть пополнение в USD
+- **THEN** результат рассчитывается только по рублёвым пополнениям и выводам, без причины недоступности
+
+#### Scenario: Счета оценены в разные московские дни
+- **WHEN** в режиме `all` последние полные оценки включённых счетов относятся к разным московским календарным дням
+- **THEN** сводный результат недоступен с причиной «оценки счетов на разные даты»; последние стоимости не складываются как одновременные
+
+#### Scenario: Индекс недоступен
+- **WHEN** история индекса с дивидендами не получена за период результата
+- **THEN** прибыль показывается, а результат тех же денег в индексе и опережение недоступны с причиной «история индекса недоступна»
+
+### Requirement: Вкладка «Результат» на странице счёта
+Страница брокерского счёта и режима «Все счета» SHALL содержать вкладку «Результат», которая показывает:
+- доходность с подписью «годовых» либо «за N дн.»;
+- прибыль в RUB с текущей стоимостью и чистыми вложениями;
+- «Те же деньги в индексе Мосбиржи» с доходностью и стоимостью;
+- «Опережение рынка» либо «Отставание от рынка» в процентных пунктах и RUB;
+- график;
+- раскрываемый блок «Как считали».
+
+Положительные значения MUST выделяться положительным тоном, отрицательные — отрицательным, и смысл MUST NOT передаваться только цветом (знак «+» или «−» и текст обязательны). Технические коды индексов MUST NOT использоваться как основные подписи и MAY приводиться только в блоке «Как считали». Пока результат загружается, вкладка MUST показывать skeleton без чисел. Ошибка загрузки результата MUST NOT влиять на другие вкладки счёта.
+
+#### Scenario: Пользователь обгоняет рынок
+- **WHEN** доходность User выше доходности тех же денег в индексе
+- **THEN** вкладка показывает «Опережение рынка» со значениями «+N п.п.» и «+N ₽» в положительном тоне
+
+#### Scenario: История меньше года
+- **WHEN** период результата короче 365 дней
+- **THEN** вкладка показывает пояснение, что проценты даны за период без пересчёта в годовые, и подписывает каждый процент «за N дн.»
+
+#### Scenario: Неполный результат
+- **WHEN** результат режима `all` неполный
+- **THEN** над показателями отображается предупреждение «Результат неполный» с исключёнными счетами и причинами
+
+#### Scenario: Недоступный результат
+- **WHEN** результат недоступен
+- **THEN** вкладка вместо показателей показывает «Доходность недоступна» и понятное описание причины, без нулевых значений
+
+#### Scenario: Пояснение методики
+- **WHEN** User раскрывает «Как считали»
+- **THEN** видны период, учтённые потоки, смысл доходности, правило «тех же денег в индексе», пометка о справочном характере индекса без дивидендов, источник данных индексов и оговорка, что это не налоговый расчёт
+
+### Requirement: График результата
+График вкладки «Результат» SHALL показывать за период результата:
+- ступенчатую линию чистых внешних вложений;
+- линию стоимости тех же денег в индексе Мосбиржи по закрытиям торговых дней;
+- справочную линию тех же денег в индексе без дивидендов;
+- отдельную отметку текущей стоимости Portfolio на конец периода.
+
+График MUST NOT показывать прошлую стоимость Portfolio User и MUST сообщать, что её линия отсутствует. Значения при наведении или фокусе MUST показывать дату и все значения линий на эту дату. У графика MUST быть текстовая альтернатива с итоговыми значениями.
+
+#### Scenario: Наведение на дату графика
+- **WHEN** User наводит курсор на дату графика
+- **THEN** показываются дата, чистые вложения, стоимость в индексе и стоимость в индексе без дивидендов на эту дату
+
+#### Scenario: Отсутствие прошлой стоимости Portfolio
+- **WHEN** график отображается
+- **THEN** стоимость Portfolio показана только отметкой на конце периода, а под графиком есть пояснение об отсутствии линии прошлой стоимости
@@ -0,0 +1,244 @@
+# System Analysis
+
+Issue: WealthLedger/main#54
+
+## Requirement Coverage
+
+| Нормативная область | Поток и контракт |
+| --- | --- |
+| `investment-performance`: результат счёта и `all`, доступ | [performance-read.mmd](sequences/performance-read.mmd), [contract](contracts/investment-performance.openapi.yaml) `Performance`, `PerformanceResource` |
+| `investment-performance`: внешние потоки, переводы в `all` | [Маппинг операций](#маппинг-операций-t-bank), [Переводы в all](#переводы-между-счетами-в-all) |
+| `investment-performance`: доходность, basis annual/period, нет решения | [Расчёт](#расчёт), `ReturnValue` |
+| `investment-performance`: те же деньги в индексе, неторговый день, отставание | [Расчёт](#расчёт), `IndexResult`, `Outperformance` |
+| `investment-performance`: справочный индекс | `reference`, `SeriesPoint.referenceValue` |
+| `investment-performance`: недоступный и неполный результат | [Причины недоступности](#причины-недоступности), `UnavailableReason`, `excludedAccounts`, `meta.unavailable` |
+| `investment-performance`: вкладка и график | `series`, `period.days`, `return.basis`; поведение UI — в Design |
+| `market-index-history`: хранение, свежесть, недоступность | [index-refresh.mmd](sequences/index-refresh.mmd), [Индексы MOEX](#индексы-moex) |
+
+## Systems and Responsibilities
+
+- **Frontend**: вкладка «Результат». Делает один GET на страницу счёта или
+  `all`, сам ничего финансово не рассчитывает. Отличает загрузку,
+  HTTP-ошибку, `data: null` (недоступно) и `completeness: incomplete`.
+  Форматирует доли в проценты и п.п., подпись берёт из `return.basis` и
+  `period.days`.
+- **Backend**: единственный владелец расчёта. Проверяет доступ, отбирает
+  счета для расчёта, выделяет внешние потоки из сохранённых операций, берёт
+  последнюю полную оценку Portfolio, считает XIRR и теневой портфель, хранит и
+  догружает историю индексов.
+- **Сохранённые данные T-Bank** (существующая синхронизация): операции,
+  граница истории и покрытие счёта, последний Portfolio. Новых вызовов T-Bank
+  нет.
+- **MOEX ISS**: публичный источник дневных закрытий MCFTRR и IMOEX.
+  Вызывается только backend.
+
+## Interaction Flows
+
+- [performance-read.mmd](sequences/performance-read.mmd): чтение результата
+  со всеми ветками доступа, недоступности и сбоя индекса.
+- [index-refresh.mmd](sequences/index-refresh.mmd): догрузка истории индекса
+  при чтении, пагинация, сбой источника.
+
+Фоновой задачи нет: история индекса догружается при чтении результата.
+Однодневная свежесть (требование `market-index-history`) обеспечивается тем,
+что каждое чтение проверяет покрытие до `period.to`.
+
+## Contracts
+
+| Producer → Consumer | Операция | Схема | Совместимость |
+| --- | --- | --- | --- |
+| Backend → Frontend | `GET /api/v1/brokerage-accounts/{accountId}/performance`, `GET /api/v1/brokerage-accounts/all/performance` (HTTP/JSON, сессия как у остальных `/api/v1`) | [investment-performance.openapi.yaml](contracts/investment-performance.openapi.yaml) | Новые маршруты, аддитивно. Enum `UnavailableReason` расширяемый: неизвестное значение клиент показывает как общую недоступность |
+| MOEX ISS → Backend | `GET https://iss.moex.com/iss/history/engines/stock/markets/index/securities/{MCFTRR\|IMOEX}.json?from&till&start&iss.meta=off&history.columns=TRADEDATE,CLOSE` | Блок `history` (TRADEDATE `YYYY-MM-DD`, CLOSE число), `history.cursor` (INDEX, TOTAL, PAGESIZE = 100) | Внешний, без версии. Неожиданная форма ответа считается сбоем источника, частичный разбор запрещён |
+
+- HTTP-ошибки — существующий `ProblemDetailsDto` и коды `UNAUTHORIZED`,
+  `NOT_FOUND`, `TBANK_NOT_CONNECTED`, `TBANK_UNAVAILABLE`,
+  `INTERNAL_SERVER_ERROR`. Новых problem codes нет.
+- Недоступность расчёта не является HTTP-ошибкой: ответ 200, а причина в
+  `UnavailableReason`. `MOEX_UNAVAILABLE` в HTTP-ответе не возвращается:
+  сбой индекса превращается в `INDEX_HISTORY_UNAVAILABLE` внутри
+  `benchmark`/`reference`.
+- Числа: деньги — `MoneyDto` (RUB, десятичная строка, округление до копеек
+  half away from zero, как общий decimal helper); доли (`Rate`) — десятичная строка до 6 знаков, `0.151` = 15,1 %;
+  точки `series` — десятичные RUB до копеек.
+- Идемпотентность: GET без побочных эффектов, кроме догрузки истории индекса.
+  Её повтор безопасен (upsert по индексу и торговому дню).
+
+## Data and State Semantics
+
+### Источники правды
+
+| Данные | Владелец | Используемое значение |
+| --- | --- | --- |
+| Внешние потоки | Сохранённые операции T-Bank (EXECUTED) | `type`, `occurredAt`, `payment` (знак и валюта) |
+| Начало истории | Граница истории счёта | `historyBoundary = known` → `historyFrom` |
+| Полнота операций | Покрытие операций счёта | `historyState = complete` от `historyFrom` до времени оценки |
+| Текущая стоимость | Последний сохранённый Portfolio | `totalsByCurrency[RUB]`, `fetchedAt` |
+| Закрытия индексов | Новое локальное хранилище истории индексов | (индекс, торговый день) → точное CLOSE |
+
+### Маппинг операций T-Bank
+
+| Тип `OPERATION_TYPE_*` | Роль |
+| --- | --- |
+| `INPUT`, `INPUT_ACQUIRING`, `INPUT_SWIFT`, `INP_MULTI` | Внешнее пополнение: `+|payment|` |
+| `OUTPUT`, `OUTPUT_ACQUIRING`, `OUTPUT_SWIFT`, `OUT_MULTI` | Внешний вывод: `−|payment|` |
+| `INPUT_SECURITIES`, `OUTPUT_SECURITIES`, `TRANS_IIS_BS`, `TRANS_BS_BS` | Перевод бумаг: у отдельного счёта всегда `UNVALUED_SECURITIES_TRANSFER`; в `all` — см. ниже |
+| Сделки, купоны, дивиденды, погашения, амортизация, налоги, комиссии (включая `OUT_FEE`, `OUTPUT_PENALTY`), прочие | Внутренние, в потоки не входят |
+
+- Поток в валюте, отличной от RUB, не учитывается (RUB-only, WealthLedger/main#55).
+- Учитываются только операции с `occurredAt ≤ fetchedAt` Portfolio этого
+  счёта. Иначе пополнение после оценки исказит результат.
+- Дата потока — календарный день `occurredAt` в Europe/Moscow.
+
+### Переводы между счетами в `all`
+
+T-Bank не передаёт в операции счёт-контрагента. Совпадение операций —
+лишь кандидат на перевод, а не подтверждение. Не объявлять кандидата
+внутренним потоком без независимого признака связи.
+
+- **Деньги.** Вывод на счёте A и пополнение на счёте B равной суммы RUB
+  в пределах 5 минут — только кандидат. Пока нет подтверждения связи,
+  оба счёта исключаются из расчётной части `all` с причиной
+  `UNCONFIRMED_TRANSFER`. Без кандидата операция остаётся внешним потоком.
+- **Бумаги.** `OUTPUT_SECURITIES` / `TRANS_*` на счёте A и
+  `INPUT_SECURITIES` / `TRANS_*` на счёте B с тем же инструментом и
+  количеством в тот же день — только кандидат; оба счёта исключаются.
+  Для одиночного ввода или вывода применяется `UNVALUED_SECURITIES_TRANSFER`.
+
+В текущем контракте T-Bank нет признака, подтверждающего пару. Полностью
+корректное включение счетов с переводами в `all` отложено до появления
+подтверждённой связи; не вычислять процент на предположении.
+
+### Причины недоступности
+
+Причины проверяются по каждому счёту в таком порядке; используется первая
+сработавшая:
+
+1. `HISTORY_START_UNKNOWN`: `historyBoundary = unknown`.
+2. `OPERATIONS_HISTORY_INCOMPLETE`: покрытие не `complete`.
+3. `PORTFOLIO_VALUATION_INCOMPLETE`: нет Portfolio или у ненулевой позиции
+   нет вычислимой стоимости (то же правило, что у `portfolio-value-history`).
+4. `UNVALUED_SECURITIES_TRANSFER`.
+5. `UNCONFIRMED_TRANSFER` (только `all`, когда есть кандидат на внутренний
+   перевод без доказанной связи).
+
+Как причины попадают в ответ:
+
+- Для отдельного счёта любая причина даёт `data: null` и одну запись в
+  `meta.unavailable`.
+- В `all` исключённые счета перечисляются в `excludedAccounts`, а
+  `completeness = incomplete`. Если не осталось ни одного счёта, ответ
+  `data: null`, а `meta.unavailable` содержит все счета.
+- `NO_SOLUTION` и `AMBIGUOUS_RETURN` бывают только в `return`
+  (пользователя или индекса) и не
+  исключает счёт.
+- Если даты последних полных оценок оставшихся счетов `all` в Москве
+  различаются, сводка целиком `data: null` с причиной
+  `ACCOUNT_VALUATION_DATES_DIFFER` в `meta.unavailable` для каждого
+  затронутого счёта: суммы разных дат не складываются.
+- `INDEX_HISTORY_UNAVAILABLE` бывает только в `benchmark` / `reference`.
+
+### Расчёт
+
+- **Период.** `from` — дата первого внешнего потока по Москве (решение
+  Change Owner: не дата открытия счёта). Полнота истории по-прежнему
+  проверяется от `historyFrom`. `to` — дата по Москве `fetchedAt`; для `all` она общая
+  только когда все включённые счета оценены в один московский день.
+  `days = to − from` в календарных днях.
+  `basis = annual` при `days ≥ 365`, иначе `period`.
+- **Агрегаты.** `netInvested = Σ потоков`,
+  `currentValue = Σ totalsByCurrency[RUB]`,
+  `profit = currentValue − netInvested`. Точная десятичная арифметика,
+  финальное округление до копеек.
+- **XIRR.** Найти r из `Σ CFᵢ / (1 + r)^((dᵢ − d₀) / 365) = 0`, где
+  пополнение входит как `−`, вывод — как `+`, а `currentValue` — как `+` в
+  дату `to`. d₀ — дата первого потока. Корень ищется на `(−0.9999, 100]`.
+  - Нет корня или корень не найден с точностью |NPV| ≤ 0,01 ₽ →
+    `NO_SOLUTION`. Если решений более одного — `AMBIGUOUS_RETURN`,
+    произвольный корень не выбирается. Смена знака на концах диапазона
+    не доказывает единственность решения.
+  - Нет потоков → `NO_SOLUTION`.
+  - Для `basis = period` значение равно `(1 + r)^(days / 365) − 1`.
+- **Теневой портфель.** Для каждого потока берётся закрытие индекса на дату
+  потока или на последнюю торговую дату до неё:
+  `units += CF / close` (масштаб 12 знаков).
+  `benchmark.value = units × close(asOf)`, где `asOf` — последнее закрытие
+  `≤ to`. XIRR индекса считается на тех же потоках с `benchmark.value` в
+  дату `to`.
+- **Опережение.**
+  `outperformance.percentagePoints = return.value − benchmark.return.value`
+  (одинаковый `basis`), `outperformance.money = currentValue − benchmark.value`.
+  Если любая из сторон `null`, `outperformance = null`.
+- **Series.** Одна точка на торговый день MCFTRR в `[from, to]`:
+  - `netInvested` — накопленная сумма потоков к этому дню;
+  - `benchmarkValue` — `units × close` на этот день;
+  - `referenceValue` — то же для IMOEX, `null` при его недоступности.
+
+  Около 250 точек в год, без прореживания.
+
+### Индексы MOEX
+
+- Хранится (индекс, торговый день по Москве) → точное CLOSE, upsert.
+  Нерабочие дни не хранятся.
+- **Свежесть.** Расширение диапазона назад загружается сразу; хвост до
+  `to`, где закрытия ещё нет, перепроверяется не чаще раза в час после
+  успешной проверки; повтор после неудачной попытки — не чаще раза в час.
+  На каждый индекс
+  одновременно идёт не больше одной догрузки, повторные чтения ждут её
+  результат. Первая загрузка начинается с `from − 10 дней`, чтобы было
+  закрытие для потока в выходной.
+- **Достаточное покрытие.** Есть закрытие `≤` даты первого потока,
+  подтверждённый диапазон доходит до даты последнего потока и
+  последнее закрытие `≥ to − 10` календарных дней. 10 дней покрывают
+  новогодние каникулы биржи. Иначе `INDEX_HISTORY_UNAVAILABLE`.
+- **Лицензия.** ISS бесплатно отдаёт данные для ознакомления. Приложение
+  личное, локальное и не распространяет данные. Источник указывается в
+  «Как считали».
+
+## Error and Recovery Semantics
+
+| Ситуация | Тип | Ответ | Восстановление |
+| --- | --- | --- | --- |
+| Нет сессии / нет подключения / счёт не найден или недоступен | Доступ | 401 / 503 `TBANK_NOT_CONNECTED` / 404 | Существующие сценарии счёта |
+| Причина недоступности счёта | Бизнес | 200, `data: null` или `excludedAccounts` | Исчезает после синхронизации или изменения данных |
+| XIRR не сходится или неоднозначен | Бизнес | 200, `return.unavailableReason = NO_SOLUTION` либо `AMBIGUOUS_RETURN` | Нет |
+| MOEX недоступен, сохранённой истории хватает | Технический | 200, полный результат | Догрузка при следующем чтении (не чаще раза в час) |
+| MOEX недоступен, истории не хватает | Технический | 200, `benchmark.unavailableReason = INDEX_HISTORY_UNAVAILABLE`, `series: []` | То же |
+| Сбой хранилища или непредвиденная ошибка | Технический | 500 Problem Details | Повтор из UI; другие вкладки не затронуты |
+
+Таймаут MOEX — 10 с на запрос, как у существующего клиента. Повторных
+попыток внутри одного чтения нет. Сбой догрузки не удаляет сохранённые
+закрытия.
+
+## Non-Functional and Operational Constraints
+
+- **Ответ.** Без догрузки индекса — меньше 1 с для 10 лет истории (~2 500
+  точек на индекс, до нескольких тысяч операций). С холодной догрузкой —
+  до `ceil(дней_торгов / 100)` запросов к ISS (~25 на 10 лет на индекс).
+- **Наблюдаемость.** События `integration.moex.index_history.succeeded` и
+  `.failed` с индексом, диапазоном, числом страниц и длительностью. Счёт и
+  суммы в логи не пишутся.
+- **Безопасность.** Значения отдаются только после подтверждения доступа,
+  как у остальных инвестиционных ресурсов. В MOEX не уходят данные
+  пользователя.
+
+## Compatibility and Migration
+
+- Новые маршруты и новое хранилище; существующие контракты не меняются.
+- Миграция данных не нужна: история индекса заполняется при первом чтении.
+- Откат: удалить маршруты и хранилище. Пользовательские данные не
+  затрагиваются.
+
+## Open Questions / Assumptions
+
+- **Assumption.** Окно 5 минут и правила парности переводов соответствуют
+  реальным операциям T-Bank. Проверяется на данных пользователя до закрытия
+  change; при расхождении правило уточняется здесь.
+- **Assumption.** Остаток в валюте до 1 единицы (например, копейки USD
+  после конвертации) всё равно даёт `NON_RUB_ACTIVITY`. Порог не вводится,
+  пока такой случай не встретится на реальных данных.
+- **Elaboration.** Для `market-index-history` уточнены параметры: окно
+  покрытия 10 дней и интервал повторных попыток 1 час. Новое поведение они
+  не вводят.
+- **Spec alignment.** Формулировка причины уточнена: «ввод или вывод ценных
+  бумаг без денежной оценки». В delta spec и прототипе текст обновлён: вывод
+  бумаг без оценки так же искажает расчёт.
@@ -0,0 +1,191 @@
+openapi: 3.1.0
+info:
+  title: WealthLedger investment performance (target contract, WealthLedger/main#54)
+  version: 1.0.0
+  description: |
+    Целевой контракт новых маршрутов. После реализации исполняемым источником
+    становится backend-generated OpenAPI, который MUST быть семантически
+    совместим с этим файлом. Общие схемы `MoneyDto`, `ProblemDetailsDto` и
+    `InvestmentDependencyDto` остаются в опубликованном OpenAPI и здесь только
+    упоминаются.
+paths:
+  /api/v1/brokerage-accounts/{accountId}/performance:
+    get:
+      operationId: getBrokerageAccountPerformance
+      summary: Результат инвестирования счёта за всё время
+      parameters:
+        - name: accountId
+          in: path
+          required: true
+          schema: { type: string, minLength: 1 }
+      responses:
+        '200': { $ref: '#/components/responses/Performance' }
+        '401': { $ref: '#/components/responses/Problem' }
+        '404': { $ref: '#/components/responses/Problem' }
+        '503': { $ref: '#/components/responses/Problem' }
+  /api/v1/brokerage-accounts/all/performance:
+    get:
+      operationId: getAllBrokerageAccountsPerformance
+      summary: Результат инвестирования режима «Все счета»
+      responses:
+        '200': { $ref: '#/components/responses/Performance' }
+        '401': { $ref: '#/components/responses/Problem' }
+        '503': { $ref: '#/components/responses/Problem' }
+components:
+  responses:
+    Problem:
+      description: Ошибка доступа, подключения или технический сбой (существующий Problem Details; коды из PROBLEM_CODES)
+      content:
+        application/problem+json:
+          schema: { $ref: 'openapi.json#/components/schemas/ProblemDetailsDto' }
+    Performance:
+      description: Результат либо явная недоступность. Недоступность расчёта — не ошибка HTTP.
+      content:
+        application/json:
+          schema: { $ref: '#/components/schemas/PerformanceResource' }
+  schemas:
+    Decimal:
+      type: string
+      pattern: '^-?(0|[1-9][0-9]*)(\.[0-9]*[1-9])?$'
+      description: Точное десятичное значение без экспоненты и незначащих нулей
+    Rate:
+      allOf: [{ $ref: '#/components/schemas/Decimal' }]
+      description: Доля, не проценты. 0.151 = 15,1 %. Округление до 6 знаков, half away from zero.
+    Money:
+      $ref: 'openapi.json#/components/schemas/MoneyDto'
+    UnavailableReason:
+      type: string
+      enum:
+        - HISTORY_START_UNKNOWN
+        - OPERATIONS_HISTORY_INCOMPLETE
+        - UNVALUED_SECURITIES_TRANSFER
+        - UNCONFIRMED_TRANSFER
+        - ACCOUNT_VALUATION_DATES_DIFFER
+        - PORTFOLIO_VALUATION_INCOMPLETE
+        - NO_SOLUTION
+        - AMBIGUOUS_RETURN
+        - INDEX_HISTORY_UNAVAILABLE
+      description: |
+        Новые значения MAY добавляться; клиент MUST показывать неизвестное
+        значение как общую недоступность, а не как ошибку.
+    ReturnValue:
+      type: object
+      required: [value, basis, unavailableReason]
+      properties:
+        value:
+          oneOf: [{ $ref: '#/components/schemas/Rate' }, { type: 'null' }]
+        basis:
+          type: string
+          enum: [annual, period]
+          description: annual при period.days >= 365, иначе period (доля за весь период)
+        unavailableReason:
+          oneOf: [{ $ref: '#/components/schemas/UnavailableReason' }, { type: 'null' }]
+    IndexResult:
+      type: object
+      required: [code, value, return, asOf, unavailableReason]
+      properties:
+        code:
+          type: string
+          enum: [MCFTRR, IMOEX]
+        value:
+          oneOf: [{ $ref: '#/components/schemas/Money' }, { type: 'null' }]
+          description: Стоимость тех же потоков в индексе на конец периода (RUB)
+        return: { $ref: '#/components/schemas/ReturnValue' }
+        asOf:
+          oneOf: [{ type: string, format: date }, { type: 'null' }]
+          description: Дата последнего использованного закрытия индекса (Europe/Moscow)
+        unavailableReason:
+          oneOf: [{ $ref: '#/components/schemas/UnavailableReason' }, { type: 'null' }]
+    Outperformance:
+      type: object
+      required: [percentagePoints, money]
+      properties:
+        percentagePoints:
+          $ref: '#/components/schemas/Rate'
+          description: Разница долей return пользователя и benchmark (того же basis)
+        money: { $ref: '#/components/schemas/Money' }
+    SeriesPoint:
+      type: object
+      required: [date, netInvested, benchmarkValue, referenceValue]
+      properties:
+        date: { type: string, format: date }
+        netInvested: { $ref: '#/components/schemas/Decimal' }
+        benchmarkValue: { $ref: '#/components/schemas/Decimal' }
+        referenceValue:
+          oneOf: [{ $ref: '#/components/schemas/Decimal' }, { type: 'null' }]
+      description: Значения RUB на торговый день MCFTRR; валюта точки всегда RUB
+    ExcludedAccount:
+      type: object
+      required: [accountId, name, reason]
+      properties:
+        accountId: { type: string }
+        name: { type: string }
+        reason: { $ref: '#/components/schemas/UnavailableReason' }
+    Performance:
+      type: object
+      required:
+        - accountId
+        - period
+        - netInvested
+        - currentValue
+        - profit
+        - return
+        - benchmark
+        - reference
+        - outperformance
+        - series
+        - completeness
+        - excludedAccounts
+        - calculatedAt
+      properties:
+        accountId: { type: string, description: 'id счёта или all' }
+        period:
+          type: object
+          required: [from, to, days]
+          properties:
+            from: { type: string, format: date }
+            to: { type: string, format: date, description: 'дата последней полной оценки Portfolio' }
+            days: { type: integer, minimum: 0 }
+        netInvested: { $ref: '#/components/schemas/Money' }
+        currentValue: { $ref: '#/components/schemas/Money' }
+        profit: { $ref: '#/components/schemas/Money' }
+        return: { $ref: '#/components/schemas/ReturnValue' }
+        benchmark:
+          allOf: [{ $ref: '#/components/schemas/IndexResult' }]
+          description: code = MCFTRR
+        reference:
+          allOf: [{ $ref: '#/components/schemas/IndexResult' }]
+          description: code = IMOEX; только справка
+        outperformance:
+          oneOf: [{ $ref: '#/components/schemas/Outperformance' }, { type: 'null' }]
+          description: null, если недоступен return пользователя или benchmark
+        series:
+          type: array
+          items: { $ref: '#/components/schemas/SeriesPoint' }
+          description: Пусто, если benchmark недоступен
+        completeness:
+          type: string
+          enum: [complete, incomplete]
+        excludedAccounts:
+          type: array
+          items: { $ref: '#/components/schemas/ExcludedAccount' }
+          description: Только для all; incomplete <=> непустой массив
+        calculatedAt: { type: string, format: date-time }
+    PerformanceResource:
+      type: object
+      required: [data, meta]
+      properties:
+        data:
+          oneOf: [{ $ref: '#/components/schemas/Performance' }, { type: 'null' }]
+          description: null, если результат недоступен целиком
+        meta:
+          type: object
+          required: [dependencies, unavailable]
+          properties:
+            dependencies:
+              type: array
+              items: { $ref: 'openapi.json#/components/schemas/InvestmentDependencyDto' }
+            unavailable:
+              type: array
+              description: Непусто <=> data = null; причины по каждому счёту
+              items: { $ref: '#/components/schemas/ExcludedAccount' }
@@ -0,0 +1,25 @@
+sequenceDiagram
+    participant API as WealthLedger backend
+    participant Idx as Saved index history
+    participant MOEX as MOEX ISS
+    API->>Idx: Последняя сохранённая дата, время последней попытки (по индексу)
+    alt Покрыто до дня `to` или попытка была < 1 ч назад
+        Idx-->>API: Сохранённые закрытия
+    else Нужна догрузка (одна одновременная попытка на индекс)
+        loop Страницы по 100 строк (start = 0, 100, …) до TOTAL
+            API->>MOEX: GET /iss/history/engines/stock/markets/index/securities/{SECID}.json<br/>?from&till&start&iss.meta=off&history.columns=TRADEDATE,CLOSE
+            alt 200 с валидными строками
+                MOEX-->>API: TRADEDATE, CLOSE + history.cursor(INDEX,TOTAL,PAGESIZE)
+                API->>Idx: Upsert (индекс, торговый день) → точное закрытие
+            else Таймаут 10 с / не-2xx / невалидный ответ
+                MOEX-->>API: сбой
+                Note over API: Прервать догрузку; сохранённое не удалять;<br/>лог integration.moex.index_history.failed
+            end
+        end
+        Idx-->>API: Сохранённые закрытия
+    end
+    alt Последнее закрытие ≥ to − 10 календарных дней
+        Note over API: Покрытие достаточно; asOf = последняя дата закрытия
+    else Иначе
+        Note over API: INDEX_HISTORY_UNAVAILABLE для этого индекса
+    end
@@ -0,0 +1,38 @@
+sequenceDiagram
+    actor User
+    participant UI as WealthLedger frontend
+    participant API as WealthLedger backend
+    participant Store as Saved investment data
+    participant Idx as Saved index history
+    participant MOEX as MOEX ISS
+    User->>UI: Открывает вкладку «Результат» (accountId | all)
+    UI->>API: GET /brokerage-accounts/{accountId|all}/performance
+    API->>Store: Сессия, connection, доступ к счёту(ам)
+    alt Нет сессии / нет подключения / счёт недоступен
+        API-->>UI: Problem Details 401 / 503 TBANK_NOT_CONNECTED / 404
+        UI-->>User: Существующие состояния ошибки счёта
+    else Доступ подтверждён
+        API->>Store: Граница истории, покрытие операций, последняя полная оценка Portfolio
+        Note over API: По каждому счёту: причины недоступности<br/>(HISTORY_START_UNKNOWN, OPERATIONS_HISTORY_INCOMPLETE,<br/>NON_RUB_ACTIVITY, UNVALUED_SECURITIES_TRANSFER,<br/>PORTFOLIO_VALUATION_INCOMPLETE, UNCONFIRMED_TRANSFER)<br/>all: ACCOUNT_VALUATION_DATES_DIFFER<br/>XIRR: NO_SOLUTION / AMBIGUOUS_RETURN
+        alt Не осталось счетов для расчёта
+            API-->>UI: 200 {data: null, meta.unavailable: [...]}
+            UI-->>User: «Доходность недоступна» + причина
+        else Есть счета для расчёта
+            API->>API: Внешние потоки по дате, чистые вложения, прибыль, XIRR
+            API->>Idx: Закрытия MCFTRR, IMOEX за [from, to]
+            opt История не покрывает период (см. index-refresh.mmd)
+                Idx->>MOEX: Догрузка недостающих торговых дней
+            end
+            alt MCFTRR покрывает период
+                API->>API: Теневой портфель, XIRR индекса, опережение, series
+            else MCFTRR недоступен
+                API->>API: benchmark/outperformance недоступны (INDEX_HISTORY_UNAVAILABLE), series = []
+            end
+            API-->>UI: 200 {data: Performance, meta.dependencies}
+            UI-->>User: Показатели, график, «Как считали», предупреждение о неполноте
+        end
+    end
+    alt Технический сбой backend
+        API-->>UI: Problem Details 5xx
+        UI-->>User: Ошибка только во вкладке «Результат», с повтором
+    end
@@ -0,0 +1,108 @@
+# Tasks
+
+Issue: WealthLedger/main#54. Ветки в каждом repo:
+`feature/54-investment-performance-vs-index` от актуального `develop`.
+
+## 1. Backend: история индексов
+
+- [x] 1.1 [backend] Хранилище дневных закрытий индексов и состояния догрузки (аддитивная миграция)
+  - **Covers:** `instruments/market-index-history` — `Дневная история индексов Мосбиржи`
+  - **Source:** design «Data / Storage Changes»
+  - **Verification:** `npx prisma migrate dev` на одноразовой копии БД; `npm run verify`
+  - **Depends on:** none
+- [x] 1.2 [backend] `MoexClient.indexHistory(secid, from, till)`: пагинация `history.cursor`, строгий разбор, сбой без частичных строк
+  - **Covers:** `instruments/market-index-history` — `Дневная история индексов Мосбиржи`
+  - **Source:** system-analysis «Contracts» (MOEX ISS), [index-refresh.mmd](system-analysis/sequences/index-refresh.mmd); design backend 5
+  - **Verification:** `moex.client.spec.ts`: несколько страниц, невалидная страница, таймаут, не-2xx
+  - **Depends on:** none
+- [x] 1.3 [backend] `MarketIndexHistoryService`: покрытие периода, догрузка не чаще раза в час, single-flight, upsert, лог `integration.moex.index_history.*`, сбой → недостаточно покрытия
+  - **Covers:** `instruments/market-index-history` — `Дневная история индексов Мосбиржи`, `Свежесть и недоступность истории индексов`
+  - **Source:** system-analysis «Индексы MOEX», «Error and Recovery Semantics»; design backend 5, «Cross-cutting Implementation»
+  - **Verification:** unit-тесты сервиса (покрытие ±10 дн., час, параллельные вызовы, сбой с историей и без); `npm run verify`
+  - **Depends on:** 1.1, 1.2
+
+## 2. Backend: расчёт результата
+
+- [x] 2.1 [backend] Вынести `isCompleteValuation(snapshot)` в portfolio domain и использовать его при записи истории оценки
+  - **Covers:** `portfolio/investment-performance` — `Недоступный и неполный результат`
+  - **Source:** design backend 2; qa-analysis «Regression Impact»
+  - **Verification:** существующие тесты `portfolio-value-history` и новые unit-тесты функции проходят; `npm run verify`
+  - **Depends on:** none
+- [x] 2.2 [backend] Domain: маппинг типов операций → роли, внешние потоки по дате Europe/Moscow, отсечка по `fetchedAt`, кандидаты на переводы в `all` без автоматического подтверждения, причины недоступности в порядке приоритета
+  - **Covers:** `portfolio/investment-performance` — `Внешние денежные потоки`, `Недоступный и неполный результат`
+  - **Source:** system-analysis «Маппинг операций T-Bank», «Переводы между счетами в all», «Причины недоступности»; design backend 4, 7
+  - **Verification:** unit-тесты: счёт A (130 000 / 10 000), `UNCONFIRMED_TRANSFER` при совпадении операций, перевод на исключённый счёт, бумаги без пары, USD, порядок причин
+  - **Depends on:** none
+- [x] 2.3 [backend] Domain: XIRR (Ньютон + бисекция, проверка знака), basis annual/period, теневой портфель MCFTRR/IMOEX, опережение, series
+  - **Covers:** `portfolio/investment-performance` — `Доходность с учётом сумм и дат потоков`, `Те же деньги в индексе Мосбиржи`, `Справочный индекс без дивидендов`, `График результата`
+  - **Source:** system-analysis «Расчёт»; design backend 3
+  - **Verification:** unit-тесты с эталонными константами (LibreOffice/scipy, допуск 1e-6): 10 % за 730 дн., 110 000 ₽ по индексу, поток в выходной, `NO_SOLUTION`, `AMBIGUOUS_RETURN`, period basis, отставание
+  - **Depends on:** none
+- [x] 2.4 [backend] Модуль `performance`: маршруты `GET /brokerage-accounts/{accountId|all}/performance`, доступ, сборка ответа, DTO, `UnavailableReason`, лог `performance.calculated`
+  - **Covers:** `portfolio/investment-performance` — `Результат инвестирования выбранного счёта`, `Недоступный и неполный результат`; `instruments/market-index-history` — `Свежесть и недоступность истории индексов`
+  - **Source:** contract [investment-performance.openapi.yaml](system-analysis/contracts/investment-performance.openapi.yaml), [performance-read.mmd](system-analysis/sequences/performance-read.mmd); design backend 1, 6
+  - **Verification:** e2e на SQLite (`npm run test:sqlite`): 200 ready, `data: null`, `all` incomplete, 401/404/503, MOEX недоступен с историей и без; `npm run verify`
+  - **Depends on:** 1.3, 2.1, 2.2, 2.3
+- [x] 2.5 [backend] Обновить generated OpenAPI и сверить его с целевым контрактом
+  - **Covers:** `portfolio/investment-performance` — `Результат инвестирования выбранного счёта`
+  - **Source:** design «Contract Implementation»
+  - **Verification:** `npm run openapi:generate`; `npm run openapi:check`; построчная сверка маршрутов, required, nullable, enum и форматов с `investment-performance.openapi.yaml`, результат — в описании PR
+  - **Depends on:** 2.4
+
+## 3. Frontend
+
+- [x] 3.1 [frontend] Обновить OpenAPI snapshot и типы, entity `performance` с `usePerformance(accountId)`
+  - **Covers:** `portfolio/investment-performance` — `Результат инвестирования выбранного счёта`
+  - **Source:** design frontend 1, «Contract Implementation»
+  - **Verification:** `npm run openapi:generate`; `npm run openapi:check`; `npm run typecheck`
+  - **Depends on:** 2.5
+- [x] 3.2 [frontend] Форматтеры `formatSignedPercent`, `formatPercentagePoints` (знак U+2212, 1 знак)
+  - **Covers:** `portfolio/investment-performance` — `Вкладка «Результат» на странице счёта`
+  - **Source:** design frontend 4
+  - **Verification:** unit-тесты: положительное, отрицательное, ноль, округление
+  - **Depends on:** none
+- [x] 3.3 [frontend] Вкладка «Результат»: container, VM, view, KPI, alerts, недоступно, skeleton, ошибка секции, «Как считали», hint, строки `portfolio.performance.*`
+  - **Covers:** `portfolio/investment-performance` — `Вкладка «Результат» на странице счёта`, `Недоступный и неполный результат`
+  - **Source:** design frontend 2, 3, 6, 7, «UI/UX Package»; prototype вариант A
+  - **Verification:** тесты VM и view (RTL + MSW): обгоняю, отстаю, меньше года, неполный, недоступно, неизвестная причина, загрузка, ошибка только во вкладке; `npm run verify`
+  - **Depends on:** 3.1, 3.2
+- [x] 3.4 [frontend] График результата: LineChart с тремя сериями и точкой текущей стоимости, tooltip, текстовая альтернатива, пояснение об отсутствии прошлой стоимости, состояние без series
+  - **Covers:** `portfolio/investment-performance` — `График результата`, `Справочный индекс без дивидендов`
+  - **Source:** design frontend 5, «UI/UX Package»
+  - **Verification:** тесты view: серии, `aria-label` с итогами, отсутствие референсной линии, пустой series; browser-тест на 390px без горизонтальной прокрутки; `npm run verify`
+  - **Depends on:** 3.3
+
+## 4. Docs
+
+- [x] 4.1 [docs] ADR 023 и строка в `adr/README.md`
+  - **Covers:** `N/A` — документация решения
+  - **Source:** docs-impact: `docs/adr/023-investment-performance-vs-index.md`, `docs/adr/README.md`
+  - **Verification:** `npm run verify`
+  - **Depends on:** none
+- [x] 4.2 [docs] Страница `domains/portfolio/investment-performance.md` и обновления `all-accounts.md`, `data-reference.md`, `portfolio/overview.md`
+  - **Covers:** `N/A` — документация текущего поведения
+  - **Source:** docs-impact: соответствующие строки таблицы
+  - **Verification:** `npm run verify`; сверка с реализованным поведением 2.4 и 3.3
+  - **Depends on:** 2.4, 3.3, 4.1
+- [x] 4.3 [docs] Глоссарий, `overview.md`, `income/overview.md`: новые термины и снятие конфликтующих запретов
+  - **Covers:** `N/A` — терминология
+  - **Source:** docs-impact: `docs/glossary.md`, `docs/overview.md`, `docs/domains/income/overview.md`
+  - **Verification:** `npm run verify`; `grep -rn "доходност" .` — только новое значение или оговорки «не является»
+  - **Depends on:** 4.1
+- [x] 4.4 [docs] `integrations/moex.md` (раздел «Индексы»), `architecture/context.md`, `architecture/http-api.md`
+  - **Covers:** `N/A` — документация интеграции и API
+  - **Source:** docs-impact: соответствующие строки таблицы
+  - **Verification:** `npm run verify`; сверка с generated OpenAPI из 2.5
+  - **Depends on:** 2.5
+
+## 5. Завершение
+
+- [x] 5.1 [specs] Commit planning artifacts и прототипа; PR в `develop`
+  - **Covers:** `N/A` — поставка planning artifacts
+  - **Source:** engineering workflow
+  - **Verification:** `npm run validate`; `git diff --check`
+  - **Depends on:** none
+
+Ручная приёмка на реальных данных Change Owner (парность переводов,
+правдоподобие результата) и semantic verify/archive выполняются по
+qa-analysis до закрытия Issue. Это не implementation task.
@@ -0,0 +1,2 @@
+schema: wealth-ledger-sdd-v2
+created: 2026-10-12
@@ -0,0 +1,220 @@
+# Engineering Design
+
+## Context and Constraints
+
+- Один backend-процесс; durable fence — reservation попытки в SQLite; таймер
+  процесса только предлагает работу (существующий инвариант, комментарии в
+  `tbank-hourly.scheduler.ts`).
+- Итог попытки пишется CAS-обновлением только из состояния `running`:
+  устаревшая публикация после появления преемника уже отклоняется существующим
+  fence (`settleHourly` where `state: 'running'`; `read()` при несовпадении
+  `progress.attempts` помечает шаг `cancelled`).
+- Сегодня итог вычисляется по in-memory списку ошибок walk (пуст при
+  исключении — ложный `succeeded`), ошибка `settleHourly` подавляется
+  `.catch(() => undefined)`, `settledWorks` поллит без deadline, а id строк
+  шагов не персистятся на hourly-попытке (`progress: { sections: [] }`).
+- Финализаторы enrichment/operations могут очистить память без durable finish —
+  шаг остаётся `running`.
+- Топология не меняется: без lease и мультреплик; CAS-ограничения
+  `attempt`/`revision`/`source` не ослабляются.
+
+## Technical Goals / Non-Goals
+
+**Goals**
+
+- Итог попытки выводится из durable-состояния шагов; ложный `succeeded`
+  невозможен ни на одном error-пути.
+- Каждая попытка достигает терминального итога в ограниченное время
+  (ограничение ожидания на каждый шаг).
+- Попытка с утраченным выполнением закрывается диагностируемо (`INTERRUPTED`)
+  и не блокирует следующий обход дольше обычного часового срока.
+- Поздняя публикация шага текущей попытки сохраняется до фиксации итога;
+  после появления преемника отклоняется существующим fence.
+
+**Non-Goals**
+
+- Lease, очередь, вторая реплика, параллельный scheduler.
+- Отмена уже начатых обращений к T-Bank.
+- Новый публичный статус попытки и изменения HTTP contract.
+- Graceful drain — только если тест контролируемой остановки докажет
+  необходимость.
+
+## Implementation Impact Map
+
+### main
+
+`N/A` — workspace/dev/release orchestration не меняется.
+
+### frontend
+
+`N/A` — публичный словарь состояний и форма `meta` не меняются.
+
+### backend
+
+`affected` — координатор `tbank-hourly.scheduler.ts` (walk/settle/
+settledWorks/launch), `tbank-sync.repository.ts` (`reserveHourly`/
+`settleHourly`), персист id шагов на попытке, durable finish в финализаторах
+`catalog-enrichment.service.ts` и `brokerage-operations-sync.service.ts`,
+изолированные SQLite-тесты reservation/coordinator.
+
+### qa
+
+`N/A` — QA repository не существует; системная верификация остаётся ручной по
+QA Analysis.
+
+## Decisions
+
+### backend
+
+1. **Итог выводится из durable-состояния шагов (корневой фикс).**
+   `settleHourly` в одной транзакции читает строки шагов попытки и вычисляет
+   итог: `succeeded` — только когда каждый обязательный шаг успешен и закрытие
+   инициировано нормальным завершением walk; `partial` — успешны некоторые;
+   `failed` — ни один. Вызывающие больше не передают результат и список
+   ошибок; walk передаёт максимум `cause: 'INTERRUPTED'` (закрытие до
+   нормального завершения), который капит итог до `partial`. Исключение —
+   обязательные секции, чей dispatch не создал durable-строку шага: walk
+   передаёт их как дополнительные problem-записи (наблюдаемый факт
+   диспатча, не результат), иначе попытка могла бы получить ложный успех.
+   Альтернатива
+   «прокидывать настоящий failures-map в catch» отклонена: не закрывает
+   lost-settle и краш-пути — каждый error-путь требовал бы своего guard.
+   Отдельный janitor-сервис отклонён: issue требует чинить существующих
+   владельцев, не вводить параллельный scheduler.
+
+2. **Id шагов персистятся на попытке в момент dispatch.** `progress`
+   hourly-попытки переиспользует существующую форму `children: string[]` +
+   `attempts: { [id]: attemptId }` (паттерн `ScreenProgress`/`progress()`).
+   Walk записывает id каждой строки шага сразу после dispatch, до ожидания —
+   иначе recovery после краша не знает множество шагов попытки, а шаг, упавший
+   в dispatch, исчезает из множества.
+
+3. **Ограниченное ожидание на каждый шаг.** `settledWorks` получает per-id
+   deadline: константа `WORK_WAIT_BOUND_MS = 15 * 60 * 1000`; истёкший id
+   возвращается как проблемный шаг с причиной `DEADLINE`. Тем же bound покрыты
+   и ожидания walk до появления durable-строк шагов (review-замечание,
+   follow-up WealthLedger/backend#78): `membership.request`/`member.done`,
+   `access.local` и dispatch `portfolio`/`operations`/`events.refresh` гоняются
+   с `WORK_WAIT_BOUND_MS` через race; истечение трактуется как проблемная
+   секция (как failed dispatch), для `access.local` — как закрытие
+   `INTERRUPTED`. Вызов не отменяется; поздняя durable-строка fenced по
+   `attemptId`, как любая поздняя публикация. Управляемые часы в
+   тестах — jest fake timers, инъекция clock в production-код не вводится.
+   RPC не отменяется; поздний результат шага сохраняется его собственной
+   строкой — учтён ли он в итоге, решает fence и момент фиксации.
+
+4. **In-memory активные обходы + recovery на существующем tick.**
+   `TbankHourlyScheduler` держит `active: Set<string>` (attemptId): добавление
+   в начале `walk`, удаление в `finally`. `launch()` перед `reserveHourly`
+   вызывает `recoverAbandoned(userId)`: если строка hourly `running`,
+   `processRunId` свой и attemptId не в `active` — попытка потеряла settle и
+   закрывается через `settleHourly` с `cause: 'INTERRUPTED'` (итог из детей,
+   максимум `partial`). Это же закрывает застрявшие legacy-строки `running`.
+   Новых таймеров и санитаров нет — восстановление едет на существующем
+   минутном tick.
+
+5. **Restart-ветка `reserveHourly` закрывает попытку итогом.** Существующая
+   ветка «running + чужой `processRunId`» вместо голой записи
+   `state: 'cancelled'` выполняет тот же derived settle с
+   `cause: 'INTERRUPTED'` внутри транзакции reservation; далее прежний
+   `due`-гейт: новый обход — не ранее следующего часового срока от начала
+   попытки. `cancelled` для hourly-строк перестаёт писаться; существующие
+   маппинги `cancelled` в `hourly()`/`hourlyAttempt()` остаются толерантным
+   чтением и не удаляются.
+
+6. **Причина прерывания — в существующем поле `errorCode`.** `INTERRUPTED` —
+   уровень попытки (закрытие до нормального завершения); `DEADLINE` — уровень
+   шага (истечение ожидания), попадает в `errorCode` попытки как первая ошибка
+   секции по существующему precedence. Коды ошибок шагов остаются в
+   `progress.sections[].errorCode`. Поле — открытое строковое: форма ответа и
+   enum `TbankErrorCode` не расширяются (маркеры жизненного цикла — не ошибки
+   T-Bank).
+
+7. **Durable finish в дочерних финализаторах.** Внешний catch финализаторов
+   (enrichment, operations drain/step) обязан перед возвратом или пробросом
+   записать терминальный неуспешный результат своей строки шага существующим
+   путём записи ошибки, а не только очистить память. Иначе шаг остаётся
+   `running`, и попытка не проходит terminal barrier.
+
+## Cross-cutting Implementation
+
+- Подавление ошибки `settleHourly` (`.catch(() => undefined)`) допустимо только
+  как пара к решению 4: `walk` удаляет attemptId из `active` в `finally`, и
+  следующий tick закрывает строку recovery. Ошибка фиксируется существующим
+  структурным логом.
+- Новых фоновых таймеров, очередей и таблиц нет; concurrency не меняется
+  (один walk на подключение).
+
+## Data / Storage Changes
+
+- Миграции нет: `children`/`attempts` живут в существующем JSON `progress`
+  строки `tbankSyncWork`; поле `errorCode` уже в схеме
+  (`20260924170000_persist_tbank_data/migration.sql:177`).
+- Legacy-застрявшие `running` строки закрываются первым recovery-проходом
+  (итог из детей + `INTERRUPTED`); чтение уже закрытых строк не меняется.
+
+## Contract Implementation
+
+- HTTP contract не меняется: форма `meta` и словарь состояний
+  (`running`/`succeeded`/`partial`/`failed`) прежние; `cancelled` остаётся в
+  enum DTO как толерантное чтение.
+- До закрытия change: backend-generated OpenAPI проверяется на семантическую
+  совместимость с текущим контрактом — изменения формы не ожидаются; новые
+  значения существуют только внутри открытого строкового поля диагностики и
+  в hourly-read наружу не попадают.
+
+## Developer Verification Strategy
+
+- Изолированные SQLite-тесты reservation/coordinator (не stub
+  `upcoming-events`): ветки `first`, `not-due`, `running`, `restart`,
+  `partial`; итог проверяется после terminal barrier.
+- Инъекция ошибок отдельно в дочерние шаги и в родительский settle;
+  восстановление после ошибки сохранения; защита от overlap и от поздней
+  публикации; controlled stop/restart — нет бесконечного drain, после
+  остановки новые reservations не создаются.
+- Управляемые часы — jest fake timers.
+- Сохранить существующие наборы auth/money/publication; полный
+  `backend verify` на финальном diff.
+- Graceful drain не добавляется, пока тест остановки не покажет
+  необходимость.
+
+## UI/UX Package
+
+`N/A` — UI не меняется; новый mockup не требуется.
+
+## Risks / Trade-offs
+
+- Derivation зависит от полноты `children`: пропуск записи id при dispatch
+  делает шаг невидимым для итога. Митигируется решением 2 (запись до await) и
+  тестом инъекции ошибки в dispatch.
+- Per-step deadline может закрыть попытку как `partial` при медленном, но
+  живом шаге; поздний результат сохраняется строкой шага, данные не теряются.
+- In-memory `active` не переживает рестарт — этот случай закрывает
+  restart-ветка reservation (решение 5).
+- Константа 15 минут без конфигурации: потолок опыта одного процесса
+  (`ponytail:` вынести в конфиг, если медленные шаги станут регулярными).
+
+## Migration / Rollout / Rollback
+
+- Rollout: один PR в backend; миграций и флагов нет; следующий tick после
+  деплоя закрывает застрявшие строки.
+- Rollback contract: `N/A` — нет миграции, security или public contract
+  изменения; откат — revert кода, уже закрытые recovery строки остаются в
+  корректном терминальном виде.
+
+## Solution Assessment
+
+Обязателен (concurrency/recovery). Варианты:
+
+- (a) Root-cause: settle выводит итог из durable-детей; recovery на
+  существующем tick/reservation; один guard в общей точке.
+- (b) Минимальный патч: настоящий failures-map в catch плюс guard в каждом
+  вызывающем.
+- (c) Отдельный janitor/очередь с lease.
+
+Выбор — (a): закрывает все error-пути одной точкой (exception, lost settle,
+краш, deadline), переиспользует существующие fence и `progress`-паттерн, без
+новых компонентов. (b) оставляет открытыми lost-settle и краш — каждый новый
+error-путь снова требует своего guard, что и есть текущий баг. (c) отклонён:
+issue явно запрещает параллельный scheduler, lease не даёт выгоды в
+одно-процессной топологии, а стоимость нового компонента выше фикса.
@@ -0,0 +1,43 @@
+# Documentation Impact
+
+## Summary
+
+Durable docs update нужен ограниченно: наблюдаемая семантика итога часовой
+попытки уже описана в AS-IS, но правила вывода итога, ограниченного ожидания и
+восстановления после сбоя сохранения/перезапуска в docs отсутствуют. Переносится
+только это знание; migration history остаётся в archived change.
+
+## Documentation Changes
+
+| Action | Target | Category | Resulting AS-IS | Source | Verification |
+|---|---|---|---|---|---|
+| update | `docs/architecture/cross-cutting/data-freshness.md` | cross-cutting | Рядом со словарём `lastAttempt` (`none`, `running`, `succeeded`, `partial`, `failed`): итог попытки выводится из фактических результатов её шагов; попытка, не завершившая обязательный шаг, не обозначается полным успехом; ожидание шага ограничено, зависший шаг учитывается как проблемный; попытка, потерявшая выполнение (сбой сохранения, остановка процесса), закрывается частичным успехом либо неуспехом и не блокирует следующий обход дольше обычного срока | System Analysis — Data and State Semantics, Error and Recovery Semantics; Design 1–5 | Страница не противоречит canonical spec `hourly-investment-sync` и фактическому поведению `meta` |
+| update | `docs/integrations/tbank.md` | integration | В разделе «Состояние и ошибки»: диагностические причины жизненного цикла попытки (`INTERRUPTED` — прервана до нормального завершения, `DEADLINE` — истечение ожидания шага) — внутренняя диагностика, не ошибки T-Bank; в hourly-read наружу не попадают, начатые обращения к T-Bank не отменяются | System Analysis — Observability Semantics; Design 3, 6 | Раздел различает ошибки подключения/external-коды и внутренние причины жизненного цикла |
+
+PR реализации: WealthLedger/docs#37 (open) — обе страницы обновлены, diff
+соответствует таблице выше (задачи 6.1 и 6.2 верифицируемы по нему).
+
+## Diagram Promotion
+
+Не переносить. Sequence-диаграммы (`hourly-attempt-terminal-barrier.mmd`,
+`hourly-bounded-wait.mmd`, `hourly-recovery.mmd`) — planning evidence этого
+change; AS-IS достаточно текстового описания семантики в `data-freshness.md`.
+
+## ADR Decision
+
+`N/A` — архитектурно значимого решения с новыми alternatives/consequences нет:
+чинятся существующие владельцы строк в прежней одно-процессной топологии,
+без новых компонентов и контрактов (Solution Assessment остаётся в archived
+change).
+
+## Glossary / Navigation Impact
+
+Нет: новые термины (`terminal barrier`, преемник попытки) — внутренние;
+публичный словарь состояний не расширяется, navigation не меняется.
+
+## No-Change Rationale
+
+`docs/architecture/containers.md` не меняется: раздел «Сохранение и
+восстановление данных» описывает backup/restore уровня базы, а не восстановление
+попытки приложением. Остальные AS-IS страницы не затрагиваются: HTTP contract
+и словарь состояний не изменились.
@@ -0,0 +1,114 @@
+# Proposal
+
+## Why
+
+Почасовая синхронизация T-Bank может завершиться в неконсистентном состоянии
+после ошибки сохранения: незавершённая попытка записывается как полный успех,
+ошибка финализации либо подавленная ошибка закрытия оставляет попытку в
+состоянии выполнения навсегда, а локальная reservation не позволяет запустить
+следующий обход в том же процессе. Пользователь видит ложный успех и перестаёт
+получать обновления до перезапуска backend, а неудавшееся ожидание дочерних
+шагов может ждать без ограничения. Механизм подтверждён статически (BE-002,
+BE-015, RISK-001, RISK-002, TQ-003); частота проявления в production пока не
+установлена.
+
+## What Changes
+
+- Итог попытки определяется фактическим результатом каждого обязательного шага:
+  невыполненный шаг даёт частичный успех либо неуспех, но не полный успех, а
+  уже полученные успехи отдельных счетов и разделов сохраняются.
+- Прерванная попытка (ошибка, сбой сохранения, остановка процесса, истечение
+  ожидания) обозначается частичным успехом либо неуспехом и не получает нового
+  публичного состояния; причина прерывания фиксируется существующим
+  диагностическим полём.
+- Попытка достигает итога в ограниченное время: ожидание дочернего шага
+  ограничено, а зависшая попытка не остаётся в выполнении бесконечно.
+- Состояние в SQLite восстанавливается после сбоя сохранения: брошенная попытка
+  закрывается диагностируемым итогом, ожидание завершается, следующая
+  допустимая попытка может стартовать без перезапуска процесса.
+- Восстановление не создаёт перекрытия обходов и не принимает устаревшие
+  результаты: поздняя публикация относительно актуального преемника
+  отклоняется.
+
+## Scope
+
+### In Scope
+
+- Итоговый статус попытки часового обхода и обработка ошибок в дочерних
+  финализаторах.
+- Ограниченное ожидание дочерних шагов и восстановление после ошибок
+  завершения шага, публикации результата и закрытия попытки.
+- Защита от перекрытия обходов и от поздней публикации устаревших данных при
+  восстановлении.
+- Контролируемая остановка и перезапуск процесса и их влияние на незавершённую
+  попытку, подтверждённые тестами.
+- Наблюдаемый результат попытки: время начала, состояние, безопасный перечень
+  проблемных счетов и разделов.
+
+### Out of Scope / Non-Goals
+
+- Распределённая очередь, lease, поддержка нескольких реплик и изменение
+  топологии deployment.
+- Удаление данных.
+- Ослабление существующих ограничений CAS для попытки, ревизии подключения и
+  источника данных.
+- Новый публичный статус попытки и изменения HTTP contract.
+- Новый параллельный scheduler или замена владельцев строк синхронизации.
+- Проверка часовой cadence и cleanup workflow — независимые задачи.
+
+## Capabilities
+
+### New Capabilities
+
+- Нет.
+
+### Modified Capabilities
+
+- `hourly-investment-sync`: итог попытки из фактических результатов шагов,
+  ограниченное ожидание шага, диагностируемое закрытие брошенной попытки,
+  отсутствие перекрытий и устаревшей публикации.
+
+## Impact
+
+- **Пользователь**: достоверный статус последнего обхода вместо ложного успеха
+  и бесконечного «выполняется» после сбоя сохранения; обновления продолжаются
+  без перезапуска процесса.
+- **Backend**: координатор часового обхода, дочерние финализаторы обновления
+  данных и reservation попытки в SQLite.
+- **Frontend**: не затрагивается — наблюдаемый словарь состояний и форма
+  ответов не меняются.
+- **Внешняя система T-Bank**: contract не меняется; начатые запросы к T-Bank
+  могут завершаться поздно и должны корректно отклоняться как устаревшие.
+- **Процессы**: диагностика причин прерывания попыток и восстановление после
+  ошибок сохранения.
+
+## Success Criteria
+
+- Попытка с невыполненным обязательным шагом никогда не наблюдается как полный
+  успех; частичные успехи счетов и разделов остаются видимыми.
+- После однократной ошибки завершения шага, публикации результата либо закрытия
+  попытки и последующего восстановления ожидание завершается, а следующая
+  допустимая попытка стартует.
+- Устаревшая попытка наблюдается относительно актуального преемника; поздняя
+  публикация старого процесса отклоняется и не меняет данные.
+- Координатор различает состояния `first`, `not-due`, `running`, `restart` и
+  `partial`; итог проверяется после terminal barrier.
+- Сценарий остановки и перезапуска доказан тестами: нет бесконечного ожидания,
+  после остановки новые попытки не создаются.
+- Сохранены существующие наборы проверок auth/money/publication, полный
+  `backend verify` на финальном изменении зелёный.
+
+## Assumptions / Dependencies
+
+- Топология остаётся одно-процессной; межпроцессный lease и мультреплики не
+  требуются.
+- Истечение ожидания не отменяет уже начатый запрос к T-Bank; защита
+  опирается на существующие ограничения CAS и правило срока следующего обхода.
+- Причина прерывания фиксируется существующим диагностическим полём, поэтому
+  HTTP contract и публичный словарь состояний не меняются; упомянутое в задаче
+  состояние `interrupted` реализуется как частичный успех либо неуспех.
+- Graceful drain добавляется только если тест контролируемой остановки докажет
+  такую необходимость.
+- Правило устаревшей публикации относится к итогу попытки и данным её шагов;
+  существующие требования `tbank-data-sync` уже запрещают выдавать неполный или
+  продолжающийся результат за полный, поэтому их изменение не планируется.
@@ -0,0 +1,90 @@
+# QA Analysis
+
+## Verification Scope
+
+### In Scope
+
+- Дельта `hourly-investment-sync`: «Последний результат обхода доступен только
+  для наблюдения» (MODIFIED) и ADDED «Каждая попытка обхода достигает итога в
+  ограниченное время», «Восстановление после сбоя сохранения не блокирует
+  последующие обходы», «Устаревшая публикация не влияет на актуальную попытку».
+- Системные проверки через resource GET `meta` и durable-состояние попытки
+  после контролируемых действий backend (инъекции сбоев, остановка/запуск
+  процесса).
+
+### Out of Scope
+
+- Внутренние unit/component тесты — developer-owned, определены Design.
+- Неизменяемые поведения `tbank-data-sync`/`tbank-connection` — только
+  regression.
+- Проверка часовой cadence (T03) и cleanup workflow — независимые задачи.
+
+## Coverage Matrix
+
+| Requirement / Scenario | Системная проверка |
+| --- | --- |
+| Последний результат… — Сбой после частичного обновления | Инъекция сбоя шага после успешного обновления Portfolio одного счёта: GET обозначает частичный успех с проблемным шагом, данные первого счёта остаются обновлёнными |
+| Последний результат… — Сбой до первого обновления | Инъекция сбоя до завершения любого шага: GET обозначает неуспех, не полный успех |
+| Последний результат… — Частичный успех / Наблюдение не запускает обход / Старая граница подключения | Regression существующего поведения `meta` |
+| Каждая попытка… — Шаг не завершается | Зависший шаг с управляемыми часами: попытка достигает терминального итога в ограниченное время, шаг учтён как проблемный |
+| Каждая попытка… — Наблюдение не ждёт без ограничения | Наблюдение результата получает итоговое состояние, а не бесконечное «выполняется» |
+| Восстановление… — Потерянное закрытие попытки | Ошибка закрытия при живом процессе: следующий проход закрывает попытку диагностируемо, следующая допустимая попытка стартует |
+| Восстановление… — Перезапуск процесса | Остановка процесса во время обхода и повторный запуск: брошенная попытка закрыта, новый обход не ранее следующего часового срока, перекрытия нет |
+| Устаревшая публикация… — После появления преемника | Позднее завершение шага старой попытки после запуска следующей: данные не изменились, итог актуальной попытки не изменился |
+| Устаревшая публикация… — До фиксации итога | Позднее завершение шага до фиксации итога попытки: результат сохранён и учтён в итоге |
+
+## Cross-system Verification
+
+- T-Bank upstream не отменяется при истечении ожидания; поздний ответ после
+  появления преемника не изменяет данные (проверяется на симулированном
+  upstream в контролируемой среде backend-тестов).
+- Внешние ошибки шагов отображаются только безопасным перечнем проблемных
+  счетов/разделов; причины `INTERRUPTED`/`DEADLINE` не раскрывают наружу
+  ничего сверх существующей формы `meta`.
+
+## Risk-based Priorities
+
+- **Critical**: ложный полный успех (целостность данных), бесконечное
+  «выполняется», перекрытие обходов, порча данных устаревшей публикацией.
+- **Compatibility**: публичный словарь состояний `meta` неизменен;
+  `cancelled` в enum остаётся толерантным значением.
+- **Money/data integrity**: успешные результаты шагов не теряются при сбоях
+  остальных.
+
+## Test Data and Environment Needs
+
+- Изолированный backend на SQLite с управляемыми часами и симулированным
+  upstream T-Bank (контролируемая тестовая среда; внутренние mocks — на
+  усмотрение разработчиков по Design).
+- Подключение с не менее чем двумя доступными счетами для сценариев частичного
+  успеха.
+
+## Manual / Exploratory Scope
+
+- Ручная проверка отображения результата последнего обхода на инвестиционных
+  экранах после симулированного сбоя сохранения.
+- Exploratory: повторные остановки процесса в разных фазах обхода; наблюдение
+  результата сразу после старта процесса.
+
+## Automation Candidates
+
+- Black-box API-кандидаты (GET `meta` после инъекций сбоев, контролируемая
+  остановка) — `deferred until QA repo exists`.
+
+## Observability Verification
+
+- Причины `INTERRUPTED`/`DEADLINE` наблюдаются в durable-диагностике попытки,
+  а не в публичном API; подавленная ошибка закрытия фиксируется структурным
+  логом backend.
+
+## Regression Impact
+
+- Существующие наборы auth/money/publication и полный `backend verify`.
+- Happy path часового обхода, первый обход после подключения, скрытие
+  результата прежней границы подключения.
+
+## Gaps / Blockers
+
+- Gaps нет. Graceful drain остаётся условным: добавляется только если
+  controlled-stop тест докажет необходимость (routing: пересмотр Design/QA
+  после теста).
@@ -0,0 +1,59 @@
+## MODIFIED Requirements
+
+### Requirement: Последний результат обхода доступен только для наблюдения
+Система SHALL предоставлять авторизованному User результат последнего обхода только в границе его текущего подключения: время начала, состояние выполнения, полного успеха, частичного успеха либо неуспеха и безопасный перечень проблемных счетов или разделов. Это состояние MUST быть доступно в `meta` каждого затронутого resource read вместе с freshness, полнотой и доступностью его `data`. Успех одного счёта или раздела MUST сохраняться независимо от ошибки другого; ошибка MUST NOT заменять его последнее успешное состояние или время. Итог попытки MUST определяться фактическим результатом каждого обязательного шага обхода: попытка, не завершившая обязательный шаг, MUST обозначаться частичным успехом либо неуспехом и MUST NOT обозначаться полным успехом. Отсутствие состоявшейся попытки MUST отличаться от успешной попытки. Наблюдение результата MUST NOT предоставлять способ начать личную синхронизацию.
+
+#### Scenario: Частичный успех
+- **WHEN** Portfolio одного доступного счёта обновился, а другого не обновился
+- **THEN** новый Portfolio первого сохраняется, прежний успешный Portfolio второго остаётся доступным, а результат обхода обозначает частичный успех и проблемный счёт
+
+#### Scenario: Наблюдение не запускает обход
+- **WHEN** User запрашивает результат последнего обхода
+- **THEN** система возвращает доступный сохранённый результат без нового обращения к T-Bank
+
+#### Scenario: Старая граница подключения
+- **WHEN** User заменил либо удалил подключение и запрашивает результат прежнего обхода
+- **THEN** система не раскрывает результат прежней границы подключения
+
+#### Scenario: Сбой после частичного обновления
+- **WHEN** попытка прервана ошибкой либо сбоем сохранения после обновления Portfolio одного доступного счёта
+- **THEN** результат попытки обозначает частичный успех с проблемными шагами, а не полный успех, а обновлённый Portfolio сохраняется
+
+#### Scenario: Сбой до первого обновления
+- **WHEN** попытка прервана до обновления любого обязательного шага
+- **THEN** результат попытки обозначает неуспех, а не полный успех
+
+## ADDED Requirements
+
+### Requirement: Каждая попытка обхода достигает итога в ограниченное время
+Каждая начатая попытка часового обхода MUST достигать итогового состояния в ограниченное время. Ожидание завершения каждого обязательного шага MUST быть ограничено; шаг, не завершившийся в это ограничение, MUST быть учтён как проблемный, а попытка MUST быть закрыта частичным успехом либо неуспехом после того, как каждый обязательный шаг достиг терминального результата либо был учтён как проблемный. Истечение ограничения MUST NOT отменять уже начатые шаги.
+
+#### Scenario: Шаг не завершается
+- **WHEN** обязательный шаг не покидает состояние выполнения дольше ограничения ожидания
+- **THEN** шаг учитывается как проблемный, попытка закрывается частичным успехом либо неуспехом, а её состояние перестаёт быть выполняющимся
+
+#### Scenario: Наблюдение не ждёт без ограничения
+- **WHEN** попытка не может завершиться из-за незавершённых шагов
+- **THEN** наблюдение результата получает итоговое состояние в ограниченное время и не ожидает завершения бесконечно
+
+### Requirement: Восстановление после сбоя сохранения не блокирует последующие обходы
+Если попытка осталась в состоянии выполнения после сбоя завершения шага, публикации результата либо закрытия попытки, система MUST привести её к диагностируемому итоговому состоянию: частичный успех либо неуспех с сохранёнными результатами шагов, а не полный успех. Последующий обход MUST становиться допустимым по обычному правилу срока, отсчитанному от начала этой попытки. Восстановление MUST NOT создавать перекрывающийся обход и MUST NOT повторять уже полученные результаты шагов.
+
+#### Scenario: Потерянное закрытие попытки
+- **WHEN** закрытие попытки не сохранилось, а процесс продолжает работать
+- **THEN** система закрывает попытку итогом из фактических результатов шагов, наблюдение получает итоговое состояние, а следующая допустимая попытка может стартовать
+
+#### Scenario: Перезапуск процесса
+- **WHEN** процесс остановился после начала попытки и запускается снова
+- **THEN** брошенная попытка обозначается частичным успехом либо неуспехом с сохранёнными результатами шагов, а новый обход начинается не ранее следующего часового срока от её начала
+
+### Requirement: Устаревшая публикация не влияет на актуальную попытку
+Результат шага попытки, у которой появился преемник, MUST отклоняться как устаревший: он MUST NOT обновлять данные и MUST NOT учитываться в итоге актуальной попытки. Шаг устаревшей попытки MUST наблюдаться как устаревший относительно актуального преемника. Результат шага текущей попытки, полученный до фиксации её итога, MUST сохраняться и учитываться в этом итоге независимо от того, наступил ли он до или после истечения ограничения ожидания.
+
+#### Scenario: Поздняя публикация после появления преемника
+- **WHEN** шаг старой попытки завершается после запуска следующей попытки
+- **THEN** его результат отклоняется как устаревший, данные не обновляются, а итог актуальной попытки не меняется
+
+#### Scenario: Поздняя публикация до фиксации итога
+- **WHEN** шаг завершился после истечения ограничения ожидания, но итог его попытки ещё не зафиксирован
+- **THEN** его результат сохраняется и учитывается при выводе итога этой попытки
@@ -0,0 +1,140 @@
+# System Analysis
+
+## Requirement Coverage
+
+| Requirement / Scenario | Flow | Contract / Semantics |
+| --- | --- | --- |
+| Последний результат обхода… — Сбой после частичного обновления | `hourly-attempt-terminal-barrier.mmd` | Outcome derivation, terminal barrier |
+| Последний результат обхода… — Сбой до первого обновления | `hourly-attempt-terminal-barrier.mmd` | Outcome derivation |
+| Последний результат обхода… — Частичный успех | `hourly-attempt-terminal-barrier.mmd` | Step results preserved |
+| Каждая попытка обхода достигает итога в ограниченное время — Шаг не завершается | `hourly-bounded-wait.mmd` | Bounded wait per required step |
+| Каждая попытка обхода достигает итога в ограниченное время — Наблюдение не ждёт без ограничения | `hourly-bounded-wait.mmd` | Bounded terminal outcome |
+| Восстановление после сбоя сохранения… — Потерянное закрытие попытки | `hourly-recovery.mmd` | Recovery of lost settle |
+| Восстановление после сбоя сохранения… — Перезапуск процесса | `hourly-recovery.mmd` | Recovery of abandoned attempt |
+| Устаревшая публикация… — Поздняя публикация после появления преемника | `hourly-recovery.mmd` | Successor fencing |
+| Устаревшая публикация… — Поздняя публикация до фиксации итога | `hourly-bounded-wait.mmd` | Late publication counts before outcome is recorded |
+
+## Systems and Responsibilities
+
+- **Hourly walk coordinator** (backend): резервирует попытку часового обхода для
+  текущего подключения, запускает обязательные шаги, ждёт их терминального
+  результата с ограничением, выводит итог попытки и закрывает её.
+- **Durable attempt status** (SQLite): единственная durable-запись попытки
+  (состояние, диагностическая причина, результаты шагов) и источник итога для
+  наблюдения и восстановления.
+- **Child step owners**: шаги membership, Portfolio, операций и будущих событий
+  публикуют свой полный результат в durable-хранилище и обозначают свой
+  терминальный результат; финализатор шага обязан фиксировать результат даже
+  при ошибке.
+- **T-Bank и публичные источники**: внешние данные; начатые обращения не
+  отменяются по внутреннему ограничению ожидания.
+- **Resource GET observer**: читает сохранённые данные и `meta` с состоянием
+  последней попытки; наблюдение не запускает обход.
+
+## Interaction Flows
+
+- `sequences/hourly-attempt-terminal-barrier.mmd` — попытка, шаги, terminal
+  barrier и вывод итога из фактических результатов шагов.
+- `sequences/hourly-bounded-wait.mmd` — ограничение ожидания шага, закрытие
+  попытки по его истечении и учёт позднего результата до появления преемника.
+- `sequences/hourly-recovery.mmd` — восстановление после сбоя сохранения и
+  после перезапуска процесса, отклонение устаревшей публикации.
+
+## Contracts
+
+- Новых и изменённых межсистемных HTTP/event contracts нет. Публичный словарь
+  состояний последней попытки (`выполнение`, `полный успех`, `частичный успех`,
+  `неуспех`) и форма `{ data, meta }` не меняются.
+- Машинно-читаемый target contract в `system-analysis/contracts/` не создаётся:
+  изменения ограничены уточнением значений внутри существующих полей.
+- Диагностическое поле причины остаётся открытым строковым полем; значения
+  причин прерывания (`INTERRUPTED` — ошибка, сбой сохранения, остановка
+  процесса; `DEADLINE` — истечение ограничения ожидания шага) дополняют
+  существующие коды ошибок шагов и не требуют изменения формы ответа.
+- Compatibility check до закрытия change: backend-generated OpenAPI остаётся
+  семантически совместимым с текущим контрактом (ожидаются только дополнительные
+  значения открытого строкового поля диагностики).
+
+## Data and State Semantics
+
+- **Попытка**: `running` → терминальный итог (`succeeded` | `partial` | `failed`).
+  Попытка, не завершившая обязательный шаг, не может получить `succeeded`.
+- **Terminal barrier**: итог попытки выводится только после того, как каждый
+  обязательный шаг достиг терминального результата либо учтён как истёкший по
+  ограничению ожидания. Итог не вычисляется по неполному списку шагов.
+- **Вывод итога**: `succeeded` — только когда все обязательные шаги успешны и
+  координатор сам зафиксировал закрытие попытки; `partial` — успешны некоторые
+  шаги; `failed` — не успешен ни один. Успешные результаты шагов сохраняются
+  независимо от итога.
+- **Причина прерывания**: попытка, закрытая до нормального завершения всех
+  шагов, сохраняет причину прерывания в диагностическом поле и не превышает
+  `partial`.
+- **Internal coordinator decisions** `first`, `not-due`, `running`, `restart`,
+  `partial`: внутренние метки решения о запуске и проверки итога после terminal
+  barrier; в HTTP contract не входят и публично не наблюдаемы.
+- **Шаги**: каждый шаг владеет своей durable-строкой результата; строка шага
+  устаревшей попытки помечается устаревшей относительно преемника.
+
+## Error and Recovery Semantics
+
+- **Сбой шага** (внешняя ошибка T-Bank): шаг фиксирует терминальный неуспех со
+  своим кодом ошибки; остальные шаги продолжаются; итог — `partial` или `failed`.
+- **Сбой сохранения** (завершение шага, публикация результата, закрытие
+  попытки): ошибка не подавляется молча в durable-состоянии; попытка, оставшаяся
+  `running`, закрывается восстановлением по фактическим результатам шагов.
+- **Остановка процесса**: начатая попытка остаётся `running` в SQLite;
+  следующий запуск процесса закрывает её как прерванную (`partial` или `failed`
+  с сохранёнными результатами шагов) и не создаёт перекрывающийся обход.
+- **Ограничение ожидания**: истечение ограничивает только ожидание шага; уже
+  начатое обращение к T-Bank не отменяется. Его поздний результат сохраняется и
+  учитывается при выводе итога своей попытки, если итог ещё не зафиксирован, и
+  отклоняется как устаревший после появления преемника.
+- **Повтор**: неуспешная попытка не повторяется ранее следующего часового срока,
+  отсчитанного от начала этой попытки; восстановление не сокращает и не
+  продлевает этот срок.
+- **Overlapping**: следующая попытка не резервируется, пока предыдущая не
+  терминальна; восстановление обязано сначала закрыть предыдущую.
+
+## Observability Semantics
+
+- Наблюдаемый итог попытки и безопасный перечень проблемных счетов/разделов —
+  существующее обязательство; значения итога не расширяются.
+- Семантические коды причин: `INTERRUPTED` — попытка прервана до нормального
+  завершения (ошибка, сбой сохранения, остановка процесса); `DEADLINE` — шаг не
+  завершился в ограничение ожидания. Коды сохраняются в диагностическом поле
+  попытки и/или шага и дополняют коды ошибок шагов без изменения формы `meta`.
+- SDK/exporter/logger — вне границ этого изменения; используется существующий
+  структурный лог backend.
+
+## Security and NFR at System Boundaries
+
+- Граница наблюдения попытки остаётся границей текущего подключения: результат
+  прежней границы не раскрывается (существующее обязательство).
+- Ограниченное время достижения итога попытки — наблюдаемое обязательство
+  надёжности: ожидание шага и ожидание наблюдателя ограничены.
+- Новых trust boundaries, authn/authz требований нет.
+
+## Compatibility / Migration
+
+- Схема данных и HTTP contract не меняются; миграция не требуется.
+- Уже застрявшие строки попыток в состоянии выполнения закрываются первым
+  проходом восстановления по правилам этого изменения: итог из фактических
+  результатов шагов, причина прерывания, без полного успеха. Это ожидаемое
+  разовое приведение legacy-состояния к диагностируемому виду.
+- Совместимость с одно-процессной топологией сохраняется; межпроцессный lease
+  не требуется.
+
+## Durable Documentation Candidates
+
+- `docs/integrations/tbank.md` (раздел «Состояние и ошибки»): итог часовой
+  попытки, причины прерывания и правило ограниченного ожидания как часть
+  наблюдаемого состояния интеграции.
+- `docs/architecture/containers.md` (раздел «Сохранение и восстановление
+  данных»): восстановление попытки после сбоя сохранения и после перезапуска
+  процесса как durable-свойство системы.
+- Итоговое решение о переносе принимает `docs-impact`.
+
+## Open Questions
+
+- Нет блокирующих вопросов. Частота проявления механизма в production остаётся
+  не установленной и не влияет на contract.
@@ -0,0 +1,23 @@
+sequenceDiagram
+  participant Coordinator
+  participant DB as Durable attempt status
+  participant Steps as Child step owners
+  participant TB as T-Bank and public sources
+  participant API as Resource GET
+
+  Coordinator->>DB: Reserve attempt for current connection
+  DB-->>Coordinator: Attempt with connection revision
+  Coordinator->>Steps: Run required steps (membership, portfolios, operations, events)
+  Steps->>TB: Fetch missing data
+  Steps->>DB: Publish complete successful step result
+  Steps->>DB: Record terminal step result (success or failure with code)
+  Coordinator->>DB: Read step results after terminal barrier
+  alt All required steps succeeded
+    Coordinator->>DB: Settle succeeded
+  else Some required steps succeeded
+    Coordinator->>DB: Settle partial with safe problem sections
+  else No required step succeeded
+    Coordinator->>DB: Settle failed with safe problem sections
+  end
+  API->>DB: Read last attempt result
+  DB-->>API: Time, outcome, safe problem list
@@ -0,0 +1,24 @@
+sequenceDiagram
+  participant Coordinator
+  participant DB as Durable attempt status
+  participant Steps as Child step owners
+  participant TB as T-Bank and public sources
+
+  Coordinator->>Steps: Run required steps
+  Steps->>TB: Start upstream call
+  Coordinator->>Coordinator: Wait for step result within bound
+  alt Step reaches terminal result in time
+    Steps->>DB: Publish complete result
+    Coordinator->>DB: Settle attempt after terminal barrier
+  else Wait bound expires
+    Note over Coordinator,TB: Upstream call is not cancelled
+    Coordinator->>DB: Record step problem cause DEADLINE
+    Coordinator->>DB: Settle partial or failed after terminal barrier
+    Steps->>TB: Upstream call completes later
+    Steps->>DB: Publish late result for the same attempt
+    alt Outcome not recorded yet and no successor
+      DB-->>Steps: Late result is preserved and counts at outcome derivation
+    else Successor attempt already started
+      DB-->>Steps: Publication rejected as stale
+    end
+  end
@@ -0,0 +1,23 @@
+sequenceDiagram
+  participant Coordinator
+  participant DB as Durable attempt status
+  participant Steps as Child step owners
+
+  Note over Coordinator,DB: Attempt is still running but its walk no longer executes
+  Coordinator->>DB: Detect running attempt without active walk
+  alt Process still alive after lost settle
+    Coordinator->>DB: Read actual step results
+    Coordinator->>DB: Close attempt as partial or failed with cause INTERRUPTED
+  else Process restarted after stop
+    Coordinator->>DB: Read actual step results
+    Coordinator->>DB: Close abandoned attempt as partial or failed with cause INTERRUPTED
+  end
+  DB-->>Coordinator: Attempt is terminal, no overlap possible
+  Coordinator->>DB: Reserve next attempt at next hourly term from attempt start
+  alt Next term reached
+    DB-->>Coordinator: Successor attempt starts
+    Steps->>DB: Late publication from previous attempt
+    DB-->>Steps: Publication rejected as stale relative to successor
+  else Next term not reached
+    DB-->>Coordinator: No work (not-due)
+  end
@@ -0,0 +1,111 @@
+# Tasks
+
+## 1. Данные попытки и вывод итога
+
+- [x] 1.1 [backend] `settleHourly` выводит итог попытки из durable-строк шагов
+  в одной транзакции; `cause: 'INTERRUPTED'` капит итог до `partial`;
+  вызывающие не передают результат и список ошибок
+  - **Covers:** `hourly-investment-sync` — «Последний результат обхода доступен только для наблюдения»
+  - **Source:** Design — Decisions 1, 6; System Analysis — Data and State Semantics
+  - **Verification:** изолированный SQLite-тест: сбой после частичного обновления даёт `partial` с сохранённым успехом; сбой до первого шага даёт `failed`; ложный `succeeded` невозможен ни на одном error-пути
+  - **Depends on:** none
+- [x] 1.2 [backend] id строк шагов персистятся в `progress` hourly-попытки
+  (`children` + `attempts`) в момент dispatch, до ожидания шага
+  - **Covers:** `hourly-investment-sync` — «Восстановление после сбоя сохранения не блокирует последующие обходы», «Устаревшая публикация не влияет на актуальную попытку»
+  - **Source:** Design — Decisions 2, 5
+  - **Verification:** SQLite-тест: после потери выполнения попытки множество шагов восстанавливается из `progress`, включая шаг, упавший в dispatch
+  - **Depends on:** 1.1
+
+## 2. Ограниченное ожидание и восстановление
+
+- [x] 2.1 [backend] ограничение ожидания на каждый шаг в `settledWorks`
+  (константа ~15 минут, per-id deadline); истёкший шаг учитывается проблемным
+  с причиной `DEADLINE`; начатые обращения к T-Bank не отменяются; часы в
+  тестах — jest fake timers без инъекции clock в production-код
+  - **Covers:** `hourly-investment-sync` — «Каждая попытка обхода достигает итога в ограниченное время»
+  - **Source:** Design — Decision 3; System Analysis — Error and Recovery Semantics
+  - **Verification:** SQLite-тест с зависшим шагом на fake timers: попытка терминальна в ограниченное время, наблюдение не ждёт бесконечно
+  - **Depends on:** 1.1
+- [x] 2.2 [backend] in-memory `active`-реестр обходов + `recoverAbandoned`
+  перед reservation: running-попытка своего `processRunId` без активного walk
+  закрывается derived settle с `INTERRUPTED`; застрявшие legacy-строки
+  закрываются первым проходом
+  - **Covers:** `hourly-investment-sync` — «Восстановление после сбоя сохранения не блокирует последующие обходы» (Потерянное закрытие попытки)
+  - **Source:** Design — Decisions 4, 6; System Analysis — Error and Recovery Semantics
+  - **Verification:** SQLite-тест: подавленная ошибка закрытия при живом процессе — следующий проход закрывает попытку, следующая допустимая попытка стартует
+  - **Depends on:** 1.1, 1.2
+- [x] 2.3 [backend] restart-ветка `reserveHourly` закрывает чужую running-попытку
+  derived settle с `INTERRUPTED` вместо голого `cancelled`; `due`-гейт и
+  защита от overlap прежние
+  - **Covers:** `hourly-investment-sync` — «Восстановление после сбоя сохранения не блокирует последующие обходы» (Перезапуск процесса)
+  - **Source:** Design — Decision 5
+  - **Verification:** SQLite-тест перезапуска процесса: брошенная попытка закрыта `partial`/`failed` с сохранёнными результатами шагов, новый обход не ранее следующего часового срока, перекрытия нет
+  - **Depends on:** 1.1, 1.2
+
+- [x] 2.4 [backend] ожидания walk до durable-строк шагов
+  (`membership.request`/`member.done`, `access.local`, dispatch
+  `portfolio`/`operations`/`events.refresh`, post-wait `events.get`)
+  ограничены тем же `WORK_WAIT_BOUND_MS` через race; истечение — проблемная
+  секция либо `INTERRUPTED`-закрытие без отмены вызова
+  (WealthLedger/backend#78)
+  - **Covers:** `hourly-investment-sync` — «Каждая попытка обхода достигает итога в ограниченное время»
+  - **Source:** Design — Decision 3; review specs#33 (CRITICAL)
+  - **Verification:** SQLite-тесты с никогда не завершающимися dispatch/membership/`done`/`get`: попытка терминальна в ограниченное время, поздние вызовы не отменяются
+  - **Depends on:** 2.1
+
+## 3. Финализаторы шагов
+
+- [x] 3.1 [backend] внешний catch финализаторов шагов (enrichment, operations
+  drain/step) записывает терминальный неуспешный результат своей строки шага
+  существующим путём записи ошибки перед возвратом или пробросом
+  - **Covers:** `hourly-investment-sync` — «Каждая попытка обхода достигает итога в ограниченное время» (шаг покидает running)
+  - **Source:** Design — Decision 7
+  - **Verification:** SQLite-тест с инъекцией ошибки финализатора: строка шага терминальна, попытка проходит terminal barrier
+  - **Depends on:** none
+
+## 4. Поздняя публикация
+
+- [x] 4.1 [backend] подтверждено fence-поведение публикации шага: результат до
+  фиксации итога попытки сохраняется и учитывается в итоге; после появления
+  преемника — отклоняется без изменения данных и итога актуальной попытки
+  - **Covers:** `hourly-investment-sync` — «Устаревшая публикация не влияет на актуальную попытку»
+  - **Source:** Design — Decisions 1–3; System Analysis — Error and Recovery Semantics
+  - **Verification:** SQLite-тесты поздней публикации: до фиксации итога — учтён; после successor — данные и итог актуальной попытки не изменились
+  - **Depends on:** 1.1, 1.2, 2.1
+
+## 5. Системная верификация backend
+
+- [x] 5.1 [backend] полный набор изолированных SQLite-тестов coordinator:
+  ветки `first`, `not-due`, `running`, `restart`, `partial`, итог после
+  terminal barrier; инъекции ошибок отдельно в дочерние шаги и родительский
+  coordinator; controlled stop/restart без бесконечного drain и без новых
+  reservations после остановки; scheduler stub `upcoming-events` не является
+  единственным доказательством
+  - **Covers:** `hourly-investment-sync` — все Requirements дельты
+  - **Source:** Design — Developer Verification Strategy; QA Analysis — Coverage Matrix, Risk-based Priorities
+  - **Verification:** полный `backend verify` зелёный на финальном diff; наборы auth/money/publication сохранены
+  - **Depends on:** 1.1, 1.2, 2.1, 2.2, 2.3, 3.1, 4.1
+- [x] 5.2 [backend] backend-generated OpenAPI семантически совместим с
+  текущим контрактом: форма `meta` и словарь состояний не изменились, новые
+  значения только внутри открытого строкового поля диагностики
+  - **Covers:** `N/A` — защита контракта (изменений контракта нет)
+  - **Source:** Design — Contract Implementation; System Analysis — Contracts
+  - **Verification:** diff сгенерированного OpenAPI до/после изменения не содержит shape-изменений
+  - **Depends on:** 1.1, 1.2, 2.1, 2.2, 2.3, 3.1, 4.1
+
+## 6. Canonical documentation
+
+- [x] 6.1 [docs] обновить `data-freshness.md`: вывод итога из фактических
+  результатов шагов, ограниченное ожидание шага, закрытие брошенной попытки
+  без блокировки расписания — рядом со словарём `lastAttempt`
+  - **Covers:** `N/A` — docs promotion
+  - **Source:** docs-impact — Documentation Changes, строка 1
+  - **Verification:** страница не противоречит canonical spec `hourly-investment-sync` и фактическому поведению `meta`
+  - **Depends on:** 5.1
+- [x] 6.2 [docs] обновить раздел «Состояние и ошибки» `tbank.md`: причины
+    жизненного цикла `INTERRUPTED`/`DEADLINE` — внутренняя диагностика, не
+    ошибки T-Bank; начатые обращения не отменяются
+  - **Covers:** `N/A` — docs promotion
+  - **Source:** docs-impact — Documentation Changes, строка 2
+  - **Verification:** раздел различает ошибки подключения/external-коды и внутренние причины жизненного цикла
+  - **Depends on:** 5.1
@@ -0,0 +1,2 @@
+schema: wealth-ledger-sdd-v2
+created: 2026-10-14
@@ -0,0 +1,63 @@
+# Design: Upcoming events date filter
+
+## Context and Constraints
+
+The account-events page already has a URL-backed filter with draft, Apply,
+Reset, and date validation. Its view model currently exposes a `maxDate` set to
+today, which blocks forecast dates; the date picker has no lower bound. The
+shared `defaultPeriod()` currently subtracts six elapsed 24-hour intervals and
+formats both instants as Moscow calendar dates, which can collapse to fewer
+than seven dates around local midnight.
+
+The `useUrlPeriod()` hook already supplies a default when the URL has no range,
+preserves valid URL dates (including past dates), and strips invalid or reversed
+range parameters. Preserve these semantics. The API already supports requested
+date windows; no API or persistence changes are needed.
+
+## Technical Goals / Non-Goals
+
+### Goals
+
+- Compute the exact seven-date default using Moscow calendar-date boundaries.
+- Let the date picker select today and future dates only.
+- Preserve valid past URL periods and existing Apply/Reset behavior.
+- Keep malformed, impossible, and reversed URL periods on the default path.
+
+### Non-Goals
+
+- Change backend event filtering, UTC inclusivity, or saved forecast window
+  intersection behavior.
+- Remove the page filter or turn the page into a read-only forecast list.
+- Reject valid past dates at the URL/API boundary.
+
+## Design
+
+Use the shared calendar utility as the owner of the default range. Derive the
+current Moscow calendar date, then calculate the inclusive end as six calendar
+days later using calendar arithmetic rather than elapsed milliseconds. Keep
+the output as `YYYY-MM-DD`, matching existing URL and API parameter formats.
+
+In the account-events page view model, expose today's date as the picker's
+minimum selectable date and remove the upper date bound. The picker constraint
+is presentation-only: do not add a future/past check to `isValidPeriod()` or
+`useUrlPeriod()`. That keeps valid direct URLs independent of what can be newly
+selected from the UI.
+
+Keep URL normalization and Apply/Reset ownership where they are. Invalid URL
+periods continue to be removed with replacement navigation and resolve to the
+same default range; valid one-sided periods retain current behavior.
+
+## Data and State
+
+No new state or API fields are needed. Existing URL parameters remain the
+applied state; the view model retains draft state until Apply. Today's picker
+minimum is refreshed when opening the calendar, consistent with the existing
+today-bound refresh behavior.
+
+## Verification
+
+Verify the default range spans seven distinct dates at ordinary times and
+around Moscow midnight, picker bounds allow future dates and block past dates,
+valid past URL periods are preserved, and malformed/impossible/reversed ranges
+fall back to the default. Existing history, Apply, and Reset behavior must
+remain intact. Use the frontend repository's local verification commands.
@@ -0,0 +1,24 @@
+# Docs Impact: Upcoming events date filter
+
+## Decision
+
+Update the existing canonical page `docs/domains/income/upcoming-events.md`
+after implementation. It already documents the date filter and URL behavior,
+so no new documentation page is needed.
+
+## Durable Information to Promote
+
+Clarify the user-visible default as seven calendar dates inclusive of today,
+and explain that the date picker permits today and future dates while valid
+past ranges remain usable when supplied through a direct URL. Invalid date
+ranges continue to fall back to the default.
+
+## Not Required
+
+No API reference, architecture page, glossary, or ADR change is expected: the
+API contract and forecast-window semantics do not change.
+
+## Verification
+
+After implementation, confirm the existing upcoming-events domain page matches
+the shipped default range, picker bounds, and URL compatibility behavior.
@@ -0,0 +1,40 @@
+# Fix upcoming events date filter
+
+## Why
+
+Страница «Будущие события» предназначена для просмотра прогноза, но календарь
+сейчас запрещает выбрать будущие даты и разрешает выбирать прошедшие. Значение
+периода по умолчанию также должно соответствовать прогнозному горизонту:
+семь календарных дат, начиная с сегодняшней.
+
+## What Changes
+
+- Оставить URL-backed фильтр периода и действия Apply/Reset.
+- По умолчанию показывать семь календарных дат включительно: от сегодняшней даты
+  до шестого следующего календарного дня.
+- В календаре разрешить даты начиная с сегодняшней; не ограничивать доступные
+  даты сверху.
+- Сохранять валидные периоды из URL, включая прошедшие даты. Некорректный формат,
+  невозможную календарную дату или обратный диапазон нормализовать к периоду по
+  умолчанию.
+
+## Capabilities
+
+- `brokerage-account-upcoming-events`
+
+## Impact
+
+- `frontend/`: фильтр и URL-период страницы будущих событий.
+- `specs/`: уточнение пользовательского поведения периода по умолчанию и
+  календарных ограничений существующей capability.
+
+Изменение сохраняет выбор владельца из frontend Issue #63: фильтр остаётся.
+Оно не переводит страницу в режим read-only списка исходного прогноза.
+
+## Success Criteria
+
+- При первом открытии без параметров период включает сегодня и следующие шесть
+  календарных дат.
+- Пользователь может выбирать будущие даты и не может выбрать даты до сегодня.
+- Прямой URL с валидными прошедшими датами сохраняет указанный период.
+- Некорректный URL-период заменяется периодом по умолчанию.
@@ -0,0 +1,37 @@
+# QA Analysis: Upcoming events date filter
+
+## Verification Scope
+
+In scope: `brokerage-account-upcoming-events` — **User can filter upcoming
+events by a forecast date range** and its four scenarios in the delta spec.
+
+Out of scope: backend date-window behavior, event calculations, forecast
+freshness, and API error mapping; these are unchanged by this frontend date
+filter adjustment.
+
+## Coverage Matrix
+
+| Requirement / Scenario | Risk | Verification |
+| --- | --- | --- |
+| Default range starts today and spans seven calendar dates | Off-by-one or local-midnight error yields the wrong period | Check that the inclusive range contains today and the next six distinct Moscow calendar dates, including when opened around Moscow midnight. |
+| Future dates can be selected and past dates cannot | Incorrect picker bounds preserve the reported defect or block forecast dates | Open the date picker; confirm yesterday is unavailable and today plus later dates are selectable. Apply a future range and confirm the displayed period reflects it. |
+| Valid past URL range is preserved | UI restriction is accidentally enforced on deep links | Open a valid past range directly and confirm the same dates remain applied and in the URL. |
+| Invalid URL range falls back to the default | Malformed or impossible dates leak into requests or remain in navigation state | Open malformed, impossible, and reversed ranges; confirm the default range is applied and invalid range parameters are removed. |
+
+## Test Data and Boundaries
+
+- Use a controlled current date and include a case near the Europe/Moscow
+  calendar-date boundary.
+- Cover exactly today, the sixth following calendar date, and a later future
+  date in the picker.
+- For URL normalization, include invalid syntax, an impossible date such as
+  February 30, and `from` later than `to`.
+- Include a valid past range to distinguish URL compatibility from picker
+  restrictions.
+
+## Risks and Limitations
+
+The calendar is a visual interaction, so system-level verification should use
+the existing browser-capable UI validation available to the frontend project.
+If only component-level verification is available, it can establish URL and
+range state but cannot fully prove the rendered calendar's disabled dates.
@@ -0,0 +1,41 @@
+# Delta for Brokerage Account Upcoming Events
+
+## ADDED Requirements
+
+### Requirement: User can filter upcoming events by a forecast date range
+
+The events page MUST retain its URL-backed date-range filter. When the URL has
+no `from` or `to` parameters, the applied range MUST include the current date
+and the following six calendar dates. The page MUST allow selecting today and
+future dates in its date picker and MUST prevent selecting dates before today.
+
+The date-picker restriction MUST NOT invalidate or rewrite a valid past date
+range supplied directly in the URL. A malformed date, impossible calendar date,
+or reversed range MUST be normalized to the default range, removing invalid
+`from` and `to` parameters from the URL. Applying and resetting the filter MUST
+continue to use the existing URL-backed period behavior.
+
+#### Scenario: Default range starts today and spans seven calendar dates
+
+- **WHEN** the user opens the events page without `from` or `to` parameters
+- **THEN** the applied range starts on the current calendar date
+- **AND** the inclusive end date is six calendar dates after the start date
+
+#### Scenario: Future dates can be selected and past dates cannot
+
+- **WHEN** the user opens the date picker
+- **THEN** today and later dates are selectable
+- **AND** dates before today are not selectable
+
+#### Scenario: Valid past URL range is preserved
+
+- **WHEN** the user opens the events page with valid `from` and `to` dates in
+  the past and `from` is not after `to`
+- **THEN** the page applies that URL range without clamping or replacing it
+
+#### Scenario: Invalid URL range falls back to the default
+
+- **WHEN** the URL contains a malformed date, an impossible calendar date, or
+  a range whose `from` date is after its `to` date
+- **THEN** the page applies the default seven-calendar-date range
+- **AND** invalid `from` and `to` parameters are removed from the URL
@@ -0,0 +1,61 @@
+# System Analysis: Upcoming events date filter
+
+## Scope and ownership
+
+This change affects the frontend events page and its existing date-range
+contract. The backend API already accepts optional `from` and `to` dates and
+returns events for the requested range; the canonical
+`brokerage-account-upcoming-events` capability defines inclusive UTC date
+bounds and behavior for invalid request ranges. No backend/API contract change
+is needed.
+
+The frontend owns picker availability, URL normalization, and the default
+range. The user-approved product decision is to retain the filter (rather than
+replace it with an unfiltered saved-forecast list, as considered by frontend
+Issue #63).
+
+## Observable flow
+
+```text
+URL query parameters
+        |
+        v
+validate calendar dates and ordering
+        | valid                    | invalid
+        v                           v
+preserve supplied range       remove invalid range
+        |                           |
+        +------------+--------------+
+                     v
+       no range -> seven dates from today
+                     |
+                     v
+       GET events with inclusive range
+```
+
+The date picker prevents new selection of dates before today, but this UI
+constraint is intentionally not a validation rule for a valid URL-provided
+past range. API date serialization and existing inclusive-boundary semantics
+remain unchanged.
+
+## Time-zone and calendar semantics
+
+The existing frontend date utilities represent calendar dates in the
+`Europe/Moscow` zone. The default must be computed as calendar-date arithmetic
+in that same zone, not by subtracting elapsed 24-hour durations from the
+current instant; elapsed-time arithmetic can yield the wrong number of distinct
+dates around a local midnight or daylight offset change. The current-date
+boundary used by the picker and default must be consistent with this existing
+frontend calendar convention.
+
+## Failure and compatibility behavior
+
+- Valid past query ranges remain accepted even though the picker will not
+  create them.
+- Malformed, impossible, or reversed ranges follow the existing URL
+  normalization path and resolve to the default period.
+- One-sided valid ranges keep their existing supported behavior; this change
+  does not require both query parameters to be present.
+- Apply and Reset retain their existing URL/history semantics.
+- Backend `INVALID_EVENTS_PERIOD`, request parameters, and saved forecast window
+  intersection behavior are outside this change.
@@ -0,0 +1,11 @@
+# Tasks: Upcoming events date filter
+
+- [x] 1.1 [frontend] Implement the seven-calendar-date default and date-picker bounds while preserving URL period normalization and Apply/Reset behavior.
+  - **Covers:** `brokerage-account-upcoming-events` — `User can filter upcoming events by a forecast date range`.
+  - **Source:** Proposal **What Changes**; Specs scenarios **Default range starts today and spans seven calendar dates**, **Future dates can be selected and past dates cannot**, **Valid past URL range is preserved**, and **Invalid URL range falls back to the default**; Design **Design**.
+  - **Verification:** Frontend owner runs relevant existing page/calendar tests and confirms Moscow-midnight default, future/past picker bounds, valid past URL preservation, and invalid URL fallback.
+
+- [x] 1.2 [docs] Update the canonical upcoming-events page to document the shipped default range and picker/URL behavior.
+  - **Covers:** `brokerage-account-upcoming-events` — `User can filter upcoming events by a forecast date range`.
+  - **Source:** Docs Impact **Durable Information to Promote**.
+  - **Verification:** Confirm `docs/domains/income/upcoming-events.md` describes seven inclusive calendar dates from today, picker restrictions, valid past URL behavior, and invalid-range fallback.
@@ -0,0 +1,2 @@
+schema: wealth-ledger-sdd-v2
+created: 2026-10-13
@@ -0,0 +1,208 @@
+# Engineering Design
+
+## Context and Constraints
+
+Аналитика дохода использует выбранный период, отдельные previous/year диапазоны
+и публикует их через DTO и metadata; план синхронизации также запрашивает эти
+диапазоны. Frontend строит блоки сравнений из ответа и показывает исполненные
+операции через `LedgerEntryRow`. Полный журнал, недавние записи и личная история
+бумаги используют этот же ряд; прогноз использует `BrokerageEventCard`;
+календарные карточки акции и облигации реализованы внутри соответствующих
+страниц. Все уже используют `EntryCard` либо существующие Mantine primitives,
+но это не один предметный компонент выплаты.
+
+Граница реализации — утверждённые Delta Specs и
+[System Analysis](system-analysis/analysis.md), включая
+[целевой контракт](system-analysis/contracts/income-analytics-response.schema.json).
+Доступ, деньги, полнота периода, порядок записей и формы остальных API
+сохраняются. Клиент получает публичный OpenAPI artifact явно.
+
+## Technical Goals / Non-Goals
+
+- Исключить сравнения из чтения, синхронизации, API и UI без изменения итогов
+  выбранного периода.
+- Один компонент для купона/дивиденда в исполненной операции, прогнозе и
+  графике бумаги; режим определяется источником, а не знаком или датой.
+- Не преобразовывать график в личный доход и не объединять чужие деньги,
+  прогноз и сумму на бумагу. Не удалять `buckets` или `instruments` из API.
+
+## Implementation Impact Map
+
+### main
+
+N/A: нет изменений workspace, Compose, release orchestration или конфигурации.
+
+### frontend
+
+Affected: страница дохода и её display model, компонент записи операций,
+компонент будущего события, календарные карточки акций/облигаций, локальная
+копия публичного OpenAPI и генерируемые типы. Владельцы экранов сохраняют
+свои списки, фильтры и локальные состояния.
+
+### backend
+
+Affected: расчёт и планирование income периода, чтение операций для
+income-analytics, DTO ответа и план фонового получения выбранного интервала.
+Источник исполненных операций и агрегация selected остаются владельцами денег.
+
+### qa
+
+N/A: самостоятельного репозитория QA нет; системные проверки описывает
+`qa-analysis.md` без введения несуществующей инфраструктуры.
+
+## Decisions
+
+### main
+
+Изменения не требуются: координация ссылками на Issue/Change, без workspace
+автоматизации ради одного API перехода.
+
+### frontend
+
+Один предметный `PayoutCard` разместить на уровне `entities`, доступном
+страницам и компонентам других slices через public export. Он использует
+существующий `EntryCard` как визуальную основу; `EntryCard` не становится
+владельцем финансовой семантики. Презентационные данные передаются явным
+discriminated union по происхождению `executed | forecast | schedule`:
+исполненная запись содержит signed payment и точный timestamp; прогноз —
+nullable projected amount, dateKind и дату; график — nullable per-security
+сумму, отдельную nullable оценку и доступные даты/параметры выпуска. Ветка
+графика показывает дополнительные условия купона и дивиденда без размножения
+карточек. У отсутствующих значений текстовый fallback, ноль форматируется
+отдельно от неизвестного. Не вводить один универсальный произвольный набор
+optional props, допускающий ложную комбинацию «исполнено + оценка».
+
+Владельцы исходных данных адаптируют типизированный ответ непосредственно на
+границе использования либо через узкий mapper сущности для повторных callers:
+`LedgerEntryRow` передаёт точные купоны/дивиденды в `PayoutCard`, прочие
+операции оставляет на прежнем пути; `BrokerageEventCard` делает то же для
+coupon/dividend, сохраняя maturity/offer; страницы графиков заменяют только
+содержимое календарной карточки. Доход продолжает вызывать `LedgerEntryRow`,
+сохраняя `wrap`, HTML-список и occurrence key. Личная история инструмента
+сохраняет quantity/price/account details там, где они доступны. Ключи списков
+и порядок определяются caller, не самим компонентом.
+
+Удалить comparison-only display model, компонент блока, подписи и стили,
+относящиеся только к сравнениям. Не удалять предупреждение неполного
+selected или сохранённого snapshot. Обновить текущие fixtures и регрессии
+после передачи OpenAPI; генерация типов потребителя берёт только его
+локальную копию artifact.
+
+Альтернатива с одинаковым CSS для трёх существующих компонентов отвергнута:
+не обеспечивает фактическое переиспользование. Альтернатива с общим DTO
+backend отвергнута: источники и денежные смыслы различны, wire-контракт
+остальных API не меняется.
+
+### backend
+
+Сократить план income-analytics до selected: сервис запрашивает один диапазон,
+не конструирует comparison totals/availability; план экранной синхронизации
+не включает предыдущий год и месяц. Сохранить независимый план current-month
+summary и серверный выбор точных типов купона/дивиденда. В DTO удалить
+`previous`, `yearComparison`, comparison DTO при отсутствии других callers;
+`dependencies` сохранить в исходной форме с единственной ролью `selected`.
+Текущий shared operations range reader использует индексированные имена
+resource keys для трёх периодов; после одного диапазона оставить корректную
+идентичность selected и убрать устаревший индексированный список. Сохраняем
+status/coverage/freshness и публикацию подтверждённого периода. Дневные/
+недельные/месячные buckets остаются, так как их удаление не согласовано.
+
+Не вводить миграцию БД: убираются чтения и поля ответа, а не сохранённые
+операции или подтверждённое покрытие. Никакой пересборки прошлого дохода.
+
+## Cross-cutting Implementation
+
+Существующая проверка пользователя/счёта и очистка личного query cache при
+смене подключения остаются на местах. Изменение количества планируемых
+диапазонов не добавляет work и не меняет поведение hourly attempt для других
+экранов. Существующие request ID, metadata попытки и статусы дают достаточную
+диагностику; новых событий или полей логирования не требуется. Пересчёта
+денег, валютной конвертации и нового кэша нет.
+
+## Data / Storage Changes
+
+N/A: Prisma/SQLite schema и исторические записи не меняются; выбранное
+покрытие продолжает подтверждаться до публикации окончательного результата.
+
+## Contract Implementation
+
+Backend обновляет DTO и исполняемый generated OpenAPI. Для обоих
+income-analytics маршрутов проверить отсутствие `previous`/`yearComparison`
+и наличие только `selected` в dependency role при сохранении nullable `data`,
+остальных полей и Problem Details. Сверить обе схемы 200 с
+[target JSON Schema](system-analysis/contracts/income-analytics-response.schema.json)
+семантически, а не только с TypeScript shape; существующую проверку parity
+runtime OpenAPI также сохранить. Передать созданный backend artifact frontend
+явно; frontend обновляет snapshot и generated types штатной локальной
+процедурой, без чтения соседнего checkout в сборке. Прежний клиент,
+требующий удалённых полей, несовместим.
+
+## Developer Verification Strategy
+
+Backend: адресные проверки планирования только выбранного интервала, чтения
+income summary/analytics, точных signed сумм и недоступного selected;
+проверка HTTP контракта и OpenAPI parity. Frontend: наблюдаемое отсутствие
+блоков сравнений в loaded/loading/error/empty; сохранение period URL,
+порядка/повторов выплат и корректные режимы общего компонента на всех
+потребителях. После локальных узких проверок выполнить обязательный verify
+каждого изменённого implementation repo. Это developer-owned проверки;
+системная матрица отдельно в `qa-analysis.md`.
+
+## UI/UX Package
+
+**Applicability and scope:** changed UI; пакет полностью inline, новых
+изображений и assets не требуется. Один approval Design относится к этой
+ревизии и приведённому ниже точному источнику переиспользования.
+
+**Package revision:** `1`, change `unify-income-payment-cards`.
+
+**Screens, states and interactions:** доход — фильтр, итоги, плоский список
+исполненных выплат, без сравнений; прогноз на странице событий/превью —
+пометка «Прогноз», неизвестная сумма отлична от нуля, дата реестра помечена;
+графики акции/облигации — «Событие по графику», разные подписи per-share/
+per-bond и личной оценки. В истории операций карточка сохраняет описание,
+дату и доступную identity инструмента, signed Money и детали там, где были.
+Loaded, empty, loading, error и обновление старого snapshot сохраняют текущие
+локальные границы экранов. Оферта, погашение, сделка и налог не получают
+режим выплаты. Компонент сам не переключает состояние и не инициирует запрос.
+
+**Responsive behavior:** однотактный проход по карточкам без горизонтального
+overflow при узкой ширине и длинных значениях; labels, значения и статусы
+читаются текстом и клавиатурой, цвет остаётся дополнительным признаком.
+Сохраняются доступные имена региона и фокус элементов фильтра.
+
+**Reused source and differences:** immutable locator
+`wealth-ledger-specs:openspec/changes/archive/2026-09-09-simplify-income-page/design.md`
+(секция «Одна карточка соответствует одной выплате») — плоский income список,
+одна карточка на запись, signed Money и сохранение порядка. Дополнить
+только единым предметным presentation для прогнозов/графиков с явными
+подписями происхождения; не переносить прогноз внутрь income страницы.
+Визуальная основа реализации — существующий `EntryCard`; его геометрия
+остаётся общим стилем, а не заменой `PayoutCard`. Пакет целиком inline.
+
+## Risks / Trade-offs
+
+- Разные даты и null-поля трёх источников провоцируют неверные labels при
+  слишком широком mapper: явные варианты данных и локальные проверки экранов
+  важнее экономии нескольких props.
+- Для календаря бумаги нет логотипа/тикера в каждой записи: владелец страницы
+  передаёт известную identity, не создавая новый запрос.
+- Меньше загружаемых диапазонов снижает объём работы, но отсутствие сравнения
+  может изменить порядок фонового покрытия старых периодов; цель сохранения
+  другой независимой истории остаётся прежней.
+
+## Migration / Rollout / Rollback
+
+Сначала обновить backend DTO/логику и получить опубликованный OpenAPI, затем
+передать artifact frontend и обновить UI/типизацию; согласованно поставить
+две стороны breaking ответа. Не выпускать старый frontend против нового
+backend как поддерживаемую комбинацию. При rollback вернуть согласованную
+предыдущую пару backend/frontend и прежний OpenAPI snapshot; сохранённые
+операции и покрытие не требуют data rollback. Синхронизация canonical specs
+и AS-IS docs выполняется по отдельным approved tasks после реализации.
+
+## Solution Assessment
+
+N/A: не создаётся новая инфраструктура, интеграция, storage, кэш или система
+аутентификации. Существующие `EntryCard`, owner-slices и DTO сохраняются;
+сопоставление альтернатив общего UI дано в решении frontend.
@@ -0,0 +1,50 @@
+# Documentation Impact
+
+## Summary
+
+Обновление canonical AS-IS нужно: документы сейчас прямо описывают сравнения
+дохода и три разных формы карточек выплат. После поставки описание должно
+отражать только выбранный период и единое представление купонов/дивидендов
+с разной степенью подтверждения. Целевые страницы уже существуют; новых
+разделов навигации не требуется.
+
+## Documentation Changes
+
+| Action | Target | Category | Resulting AS-IS | Source | Verification |
+| --- | --- | --- | --- | --- | --- |
+| update | `docs/domains/income/overview.md` | domain | Удалены блоки и расчёт comparisons, а также сведения о comparison coverage и процентах; income API содержит только данные выбранного периода, buckets сохраняются; плоский список фактических выплат использует общее представление купона/дивиденда. | `specs/brokerage-account-income-analytics/spec.md`; `system-analysis/analysis.md` §§ Contracts, Data and State Semantics | Сверить текст о расчёте, полноте, пустоте и карточках с двумя income API ответами и фактической страницей. |
+| update | `docs/domains/portfolio/all-accounts.md` | domain | Для `all` доход учитывает доступные счета, выбранный период, source currencies и принадлежность entries без годового/предыдущего сравнения. | `specs/brokerage-account-income-analytics/spec.md`; `system-analysis/analysis.md` §§ Contracts, Security and NFR at System Boundaries | В документе нет правил year comparison; данные `all` соответствуют ответу и интерфейсу. |
+| update | `docs/domains/operations/overview.md` | domain | Купоны/дивиденды в полном журнале, пяти недавних операциях и истории инструмента показаны одним предметным представлением исполненной выплаты; не-доходные операции сохраняют прежнюю семантику и детали. | `specs/brokerage-account-ledger/spec.md`; `design.md` § Decisions/frontend | Сопоставить три экрана, знак, исходную валюту, описание и дополнительную историю инструмента. |
+| update | `docs/domains/income/upcoming-events.md` | domain | Полный прогноз и превью используют общее представление купона/дивиденда с пометкой прогноза, nullable Money и датой реестра для dividend; offer/maturity сохраняют смысл. | `specs/brokerage-account-upcoming-events/spec.md`; `system-analysis/analysis.md` § Data and State Semantics | Сверить оба экрана с типизированным ответом, неизвестной суммой, dateKind и отсутствием фактического дохода в прогнозе. |
+| update | `docs/domains/instruments/stocks.md` | domain | Будущий и прошедший дивидендный график используют общую карточку с пометкой события по графику; сумма на акцию, оценка и дата реестра не выдаются за личное зачисление. История личных операций остаётся отдельной. | `specs/instrument-income-schedules/spec.md`; `design.md` §§ Decisions/frontend, UI/UX Package | Сверить разные деньги/даты и границу между графиком и операцией на странице акции. |
+| update | `docs/domains/instruments/bonds.md` | domain | Купонный календарь и прошлые события используют общую карточку с суммой на облигацию, отдельной оценкой и известными параметрами; исполнение подтверждает только личная история. | `specs/instrument-income-schedules/spec.md`; `design.md` §§ Decisions/frontend, UI/UX Package | Сверить ближайший/прошлый/недатированный купон и неизвестную сумму на странице облигации. |
+| update | `docs/architecture/http-api.md` | architecture | Зафиксировать, что оба income-analytics ответа больше не содержат данных сравнения; публичный контракт остаётся backend-generated OpenAPI, frontend получает обновлённый snapshot отдельно. Не дублировать машинную схему. | `system-analysis/analysis.md` §§ Contracts, Compatibility / Migration | Сверить описание с опубликованным OpenAPI и отсутствием comparison fields/roles. |
+
+## Diagram Promotion
+
+Не переносить `system-analysis/sequences/income-period.mmd` и
+`system-analysis/sequences/payment-sources.mmd`: устойчивые инварианты
+помещаются в тематические страницы; подробный сценарный flow полезен в
+архиве change, а не как параллельная AS-IS диаграмма.
+
+## ADR Decision
+
+N/A: изменяется продуктовый UI и ответ income API, не вводится новое
+долгоживущее архитектурное правило или интеграция. Существующий
+`docs/adr/017-local-tbank-reads-and-background-sync.md` — исторический
+принятый документ о старом поведении; не переписывать старое решение
+задним числом. Актуальный текст о выбранном периоде должен жить в
+`docs/domains/income/overview.md` и cross-cutting AS-IS при необходимости.
+
+## Glossary / Navigation Impact
+
+Новых терминов или маршрутов нет. Существующие значения «выплата», «прогноз»,
+«операция» и «событие графика» разъясняются в тематических страницах.
+`docs/overview.md` сохраняет существующую ссылку на доход.
+
+## No-Change Rationale
+
+Не создавать новую страницу `docs/design/`, не переносить target JSON Schema
+и не менять интеграционные описания T-Bank/MOEX: данные их источников и
+вычисления не изменяются. Остальные docs/ и исторические ADR не требуют
+обновления.
@@ -0,0 +1,90 @@
+# Proposal
+
+## Why
+
+Сравнения с предыдущим периодом и годом ранее не помогают пользователю решить
+основную задачу страницы «Пассивный доход»: увидеть фактически полученные купоны
+и дивиденды за выбранный период. Они усложняют экран и требуют получения данных
+за дополнительные периоды. Купоны и дивиденды в истории операций, прогнозах и
+календарях инструментов представлены разными карточками; сходный вид при этом
+не обеспечивает единого представления выплаты и ясной границы между полученными
+деньгами и ожидаемым событием.
+
+## What Changes
+
+- **BREAKING**: сравнения дохода с предыдущим периодом и годом ранее перестают
+  рассчитываться, загружаться и предоставляться потребителям аналитики.
+- Страница «Пассивный доход» показывает выбранный период, итоги по исходным
+  валютам и все включённые исполненные выплаты без блоков сравнений и их состояний.
+- Купоны и дивиденды во всех существующих местах показа выплат используют одно
+  предметное представление. Оно явно различает исполненную выплату, прогноз и
+  запись графика инструмента, сохраняя смысл дат и денежных величин.
+
+## Scope
+
+### In Scope
+
+- Аналитика дохода одного счёта и режима «Все счета»: удаление сравнения
+  периодов из результата и связанных чтений, при сохранении дохода выбранного
+  периода и самостоятельной сводки текущего месяца.
+- Карточки купонов и дивидендов в доходе, журнале и недавних операциях,
+  личной истории инструмента, полном списке и превью будущих событий,
+  календарях и истории выплат акций и облигаций.
+- Обновление нормативного поведения и согласование изменённого публичного
+  контракта с потребителями.
+
+### Out of Scope / Non-Goals
+
+- Возврат графика динамики либо прогноза на страницу дохода; удаление иных
+  исторических данных аналитики, не относящихся к сравнению периодов.
+- Изменение отбора исполненных операций, расчёта итогов, налоговой трактовки,
+  прогноза или правил происхождения календарных событий.
+- Унификация карточек сделок, налогов, комиссий, погашений и оферт.
+
+## Capabilities
+
+### New Capabilities
+
+- `specs/instrument-income-schedules/spec.md` — различимое представление
+  будущих и прошедших событий графиков выплат акций и облигаций, не выдаваемых
+  за подтверждённое личное зачисление.
+
+### Modified Capabilities
+
+- `specs/brokerage-account-income-analytics/spec.md` — результат без сравнений
+  и единое представление исполненных выплат.
+- `specs/brokerage-account-ledger/spec.md` — то же представление купонов и
+  дивидендов в полном журнале, недавних операциях и истории инструмента.
+- `specs/brokerage-account-upcoming-events/spec.md` — то же представление
+  прогнозных купонов и дивидендов на странице событий и в превью.
+
+## Impact
+
+Пользователь видит более короткую страницу дохода и узнаваемую карточку
+купона или дивиденда на смежных экранах. Аналитика прекращает запрос
+дополнительных периодов для сравнения, меняется публичный ответ и его
+потребители. Исполненные операции, будущие события и графики инструментов
+сохраняют разные источники и статус достоверности. Затронуты поведение
+интерфейса, инвестиционная аналитика, публикация контракта и документация
+дохода и событий.
+
+## Success Criteria
+
+- На странице дохода нет сравнений и сообщений об их недоступности; выбранный
+  период, итоги, налоговое пояснение и отдельная карточка каждой фактической
+  выплаты доступны как прежде.
+- Чтение и синхронизация дохода не требуют периодов сравнения, а ответ
+  аналитики их не предоставляет. Полнота выбранного периода и итоги сохраняются.
+- Купон и дивиденд на перечисленных экранах представлены одним предметным
+  компонентом; полученная сумма имеет исходный знак и валюту, прогноз может
+  не иметь суммы, а календарное событие не называется полученным доходом.
+- Остальные типы операций и будущих событий не теряют своего представления.
+
+## Assumptions / Dependencies
+
+- Изменение публичного ответа согласуется с его потребителями при поставке;
+  удаление сравнений намеренно несовместимо с прежней формой ответа.
+- Одна карточка может показывать данные разной природы без ложного обещания
+  зачисления: исполненная операция, прогноз и график остаются различимыми.
+- Планирование и реализация связаны с координирующей Issue
+  `WealthLedger/main#33`.
@@ -0,0 +1,99 @@
+# QA Analysis
+
+## Verification Scope
+
+### In Scope
+
+Удаление сравнения дохода по `brokerage-account-income-analytics` и
+семантика выплаты на экранах дохода, журнала, истории инструмента,
+будущих событий и графиков акций/облигаций по четырём delta capabilities.
+Проверяется поведение пользователя и публичного API как системы.
+
+### Out of Scope
+
+Пересмотр правил расчёта купонов/дивидендов брокером, налоговая оценка,
+удаление buckets, новые типы событий, компонентные и внутренние тесты
+реализации, несуществующий QA репозиторий.
+
+## Coverage Matrix
+
+| Requirement / Scenario из Delta Specs | Наблюдаемая системная проверка |
+| --- | --- |
+| `brokerage-account-income-analytics` — removed `Period comparisons preserve calendar and currency meaning`; `Analytics summary remains readable per currency / Динамика отсутствует для периода любой длительности` | На коротком/многолетнем периоде нет comparison UI или состояний; 200 ответ обоих income-analytics маршрутов не содержит comparison fields/roles, и чтение не инициирует дополнительные диапазоны ради сравнения. |
+| `User explicitly applies an analytics period represented in the URL / Черновик периода не применён`, `Применение периода`, `Восстановление применённого периода из URL`, `Сброс периода`, `Недопустимый черновик периода` | Итоги и карточки меняются только после применения; URL/back/reset, неверные даты и доступность ввода сохраняют поведение без блоков сравнений. |
+| `Realized analytics never presents an incomplete result as complete / Все страницы операций успешно получены`, `Одна из страниц операций недоступна`, `В периоде нет купонов и дивидендов` | Выбранный период с полной историей показывает итог; отсутствие или ошибка покрытия не выглядит нулём; подтверждённый пустой период отличим. |
+| `Income payments remain traceable to exact Ledger Entries / Каждая выплата показана отдельной карточкой`, `Отрицательная корректировка и повторяющиеся IDs сохраняются`, `Валюта видна в сумме каждой выплаты` | Порядок и количество карточек равны серверным entries; повторы и минус в исходной валюте сохранены; нет внешних групп. |
+| `Income page excludes upcoming forecasts / Данные будущих событий недоступны` | Недоступный прогноз не скрывает полный полученный доход и не возвращает прогнозный блок. |
+| `brokerage-account-ledger` — `Full ledger presents compact rows / Отображение купона`, `Отображение дивиденда`, `Подпись типа не дублируется`; `Account overview includes recent ledger events / Отображение последних событий` | Полный журнал, превью и история инструмента используют одну карточку выплаченного купона/дивиденда, сохраняют signed Money, детали и fallback; другие операции сохраняют ряд. |
+| `brokerage-account-upcoming-events` — `Account page presents an upcoming events list / Просмотр ближайших событий`, `Прогнозный дивиденд с неизвестной суммой`; `Account overview includes upcoming events / Отображение ближайших событий` | Та же карточка для прогноза в списке и превью, «прогноз», дата реестра и отсутствие суммы не превращаются в исполнение/ноль; offer/maturity не становятся выплатой. |
+| `instrument-income-schedules / Будущий купон с известными условиями`, `Прошедший дивиденд без подтверждённой операции`, `Неизвестные условия графика` | На страницах бумаг та же карточка, но пометка графика, отдельные сумма на бумагу и оценка; прошлое событие не названо полученным, null не превращён в ноль. |
+
+## Cross-system Verification
+
+Сравнить оба 200 ответа income-analytics с
+`system-analysis/contracts/income-analytics-response.schema.json` и
+опубликованным OpenAPI; проверить отсутствие comparison ranges в запросах
+при чтении и планировании income, не запрещая независимый запрос прошлого
+периода пользователем. Проверить неполный/ошибочный selected, недоступный счёт,
+новое подключение и поздний ответ старого без утечки дохода. Порядок и
+повторение ID проверить на ответе нескольких операций; нулевая сумма и
+отсутствующая сумма должны иметь разные значения. Фоновые HTTP ошибки
+прогноза и календаря не должны менять исполненную выплату. Отдельных
+callback и новых timeout контрактов нет.
+
+## Risk-based Priorities
+
+1. Точность финансового смысла и граница доступа: исправления с отрицательным
+   знаком, мультивалютность, «прошлый график» против факта, нет ложного нуля.
+2. Breaking ответ и избыточная загрузка: оба маршрута, отсутствие comparison
+   fields/dependencies, синхронизация только выбранного периода.
+3. Регрессии соседних экранов: предложенные выплаты, maturity/offer, trades,
+   текущий месяц на обзоре, back/forward и сохранённый snapshot.
+
+## Test Data and Environment Needs
+
+Тестовый доступный и недоступный счёт, режим `all`, завершённый и неполный
+периоды; coupon/dividend одной и нескольких валют, отрицательная корректировка,
+повтор operation ID, подтверждённо пустой период. Прогноз с известной/нулевой/
+неизвестной суммой, dividend с датой реестра; расписание с per-security Money,
+отдельной оценкой и отсутствующими датами. Управляемая доступность источника
+и возможность наблюдать только показанные запросы/ресурсные metadata.
+
+## Manual / Exploratory Scope
+
+Пройти страницу дохода с клавиатуры и узкого viewport, проверить доступные
+подписи, перенос длинных сумм и отсутствие горизонтальной прокрутки; перейти
+между income, журналом, личной историей инструмента, будущими событиями и
+календарём выпуска. Сравнить смысл подписи в трёх режимах при одинаковой
+дате и тикере. Отдельно проверить empty/loading/error/recovery и preview.
+
+## Automation Candidates
+
+Black-box API: сравнение фактического schema обоих маршрутов с target,
+успешный/ошибочный/пустой selected и отсутствие запросов к comparison ranges.
+Сквозные journeys: переход от аккаунта через income/ledger к событию прогноза
+и календарю инструмента с проверкой подписей и денег. Repository automation:
+`deferred until QA repo exists`; текущее подтверждение возможно вручную и
+через existing system-level HTTP/browser runners без требования нового repo.
+
+## Observability Verification
+
+По metadata ответа различить complete, pending, failed selected; запрос
+исторического периода не должен сопровождаться comparison-only dependencies.
+На отказе проверить корреляцию HTTP request ID и безопасного ответа, не
+ожидая новых событий журналирования или передачи личных данных в лог.
+
+## Regression Impact
+
+Полный журнал, недавние операции, страница акции/облигации и их фильтры,
+превью/полный прогноз, summary текущего месяца, мультивалютность и
+независимые loading/error states. Затронутые публичные потребители
+income-analytics требуют обновления контракта как пары backend/frontend.
+
+## Gaps / Blockers
+
+Блокирующих semantic gaps после утверждения Specs/System Analysis нет.
+Если опубликованный backend OpenAPI не удовлетворяет target либо картинка
+«получено» появляется на графике, маршрутизировать несовпадение в System
+Analysis/Delta Specs до принятия реализации; внутреннюю стратегию исправления
+определяют владельцы реализации.
@@ -0,0 +1,138 @@
+## REMOVED Requirements
+
+### Requirement: Period comparisons preserve calendar and currency meaning
+
+**Reason**: Сравнения с предыдущим периодом и годом ранее больше не входят в
+назначение аналитики полученного дохода и требуют избыточной загрузки истории.
+
+**Migration**: Пользователь видит только итоги и состав выплат применённого
+периода; потребители ответа аналитики больше не получают данные сравнений и
+состояния их доступности. Исторический период можно по-прежнему применить
+самостоятельно, но система не сопоставляет его с другим периодом автоматически.
+
+## MODIFIED Requirements
+
+### Requirement: User explicitly applies an analytics period represented in the URL
+
+Страница выбранного Brokerage Account «Пассивный доход» MUST позволять User редактировать черновик `from` и `to`, не изменяя видимую аналитику до явного применения. Верхний блок фильтров MUST предоставлять два подписанных календарных поля начала и окончания периода с тем же взаимодействием выбора даты, что в истории событий портфеля, и отображением дат в формате `ДД.ММ.ГГГГ`. Поля и действия применения и сброса MUST быть доступны с клавиатуры. Явное применение MUST заменить применённый период, загрузить соответствующий результат и представить применённые даты в URL страницы. Недопустимый черновик MUST показывать ошибку соответствующего поля и MUST NOT заменять последний применённый период. Сброс MUST немедленно вернуть применённый период к текущему месяцу по сегодняшний день и синхронизировать URL. Перезагрузка или открытие URL с допустимым периодом MUST восстановить тот же применённый период. Страница MUST NOT дублировать период отдельной подписью под блоком фильтров. Действие перехода на страницу MUST быть доступно из выбранного Brokerage Account, а не из глобальной навигации.
+
+#### Scenario: Черновик периода не применён
+
+- **WHEN** User изменяет черновик `from` или `to`, но не применяет его
+- **THEN** видимые итоги и карточки выплат остаются основанными на последнем применённом периоде
+
+#### Scenario: Выбор дат в верхнем блоке
+
+- **WHEN** User выбирает начало и окончание периода через календарные поля
+- **THEN** выбранные даты отображаются в подписанных полях в формате `ДД.ММ.ГГГГ`, а изменение остаётся черновиком до явного применения
+
+#### Scenario: Управление фильтрами с клавиатуры
+
+- **WHEN** User управляет верхним блоком фильтров с клавиатуры
+- **THEN** он может последовательно перейти к обоим полям дат, изменить период и выполнить применение или сброс без мыши
+
+#### Scenario: Применение периода
+
+- **WHEN** User явно применяет допустимый черновик периода
+- **THEN** страница загружает аналитику этого периода и отражает применённые `from` и `to` в URL
+
+#### Scenario: Недопустимый черновик периода
+
+- **WHEN** User пытается применить черновик с отсутствующей, некорректной или будущей датой либо с `from` после `to`
+- **THEN** страница показывает ошибку соответствующего поля и сохраняет последний применённый период, его URL и видимую аналитику
+
+#### Scenario: Восстановление применённого периода из URL
+
+- **WHEN** User открывает URL страницы с допустимыми `from` и `to`
+- **THEN** страница показывает аналитику за указанный применённый период
+
+#### Scenario: Сброс периода
+
+- **WHEN** User сбрасывает пользовательский период
+- **THEN** страница немедленно применяет период от первого дня текущего месяца по Europe/Moscow до сегодняшнего дня и синхронизирует URL
+
+### Requirement: Realized analytics never presents an incomplete result as complete
+
+Система MUST формировать выбранный результат, его trend buckets, instrument breakdown и drill-down только после успешного получения всех необходимых cursor pages исполненных операций выбранного периода. Ошибка любой необходимой страницы MUST завершать расчёт восстанавливаемой ошибкой и MUST NOT возвращать частичные totals, buckets или breakdown как полный результат. Успешный период без подходящих выплат MUST возвращать нулевой результат и отображаться с явным объяснением пустого состояния. Система MUST NOT загружать другие периоды ради сравнения полученного дохода с выбранным периодом.
+
+#### Scenario: Все страницы операций успешно получены
+
+- **WHEN** для расчёта требуется несколько cursor pages и каждая страница успешно получена
+- **THEN** система формирует результат по всем подходящим Ledger Entries со всех страниц выбранного периода без расчёта сравнений с другими периодами
+
+#### Scenario: Одна из страниц операций недоступна
+
+- **WHEN** получение любой необходимой cursor page завершается ошибкой
+- **THEN** страница показывает восстанавливаемую ошибку и не показывает частичный результат как полный
+
+#### Scenario: В периоде нет купонов и дивидендов
+
+- **WHEN** все необходимые операции успешно получены, но среди них нет подходящих coupon или dividend Ledger Entries
+- **THEN** страница показывает нулевой результат и объясняет, что за выбранный период купоны и дивиденды не найдены
+
+### Requirement: Income payments remain traceable to exact Ledger Entries
+
+В разделе «Выплаты» страница MUST показывать единый список карточек точных исполненных Ledger Entries применённого периода в исходном серверном порядке entries. Каждая выплата MUST иметь собственную сразу видимую карточку с описанием, датой исполнения, доступной identity Instrument и signed Money в исходной валюте. Купоны и дивиденды MUST использовать то же представление выплаты, что и на экранах журнала, прогноза и графиков инструментов, при этом карточка MUST обозначать эту сумму именно как фактически исполненную, а не прогнозную. Страница MUST NOT добавлять внешние группировочные карточки или заголовки по Instrument либо валюте, subtotals инструмента или количество выплат инструмента. Список MUST сохранять отрицательные корректировки и повторяющиеся operation IDs как отдельные записи и MUST NOT включать записи вне аналитического итога. Backend MUST обеспечивать согласованность entries, instrumentKey, валюты и receipt count при формировании ответа из одного набора записей. Frontend SHALL доверять типизированному contract без второго runtime consistency validator и MUST NOT пересчитывать денежные итоги.
+
+#### Scenario: Каждая выплата показана отдельной карточкой
+
+- **WHEN** выбранный период содержит несколько включённых Ledger Entries одного или разных Instrument
+- **THEN** раздел «Выплаты» сразу показывает отдельную карточку каждой записи в исходном порядке без внешних группировочных блоков, раскрытия, итогов инструмента и receipt count на UI
+
+#### Scenario: Список воспроизводит точный состав дохода
+
+- **WHEN** User просматривает загруженный раздел «Выплаты»
+- **THEN** он видит все и только включённые coupon и dividend Ledger Entries применённого периода с датой, описанием, доступной identity и исходной суммой, обозначенной как исполненная выплата
+
+#### Scenario: Отрицательная корректировка и повторяющиеся IDs сохраняются
+
+- **WHEN** доход содержит отрицательную корректировку либо несколько включённых entries с одинаковым operation ID
+- **THEN** каждая запись остаётся отдельной карточкой, а корректировка отображается с исходным знаком
+
+#### Scenario: Валюта видна в сумме каждой выплаты
+
+- **WHEN** подходящие выплаты одного Instrument представлены в нескольких исходных валютах
+- **THEN** каждая карточка показывает свою Money с исходной валютой, без отдельного заголовка валютной группы или объединённого мультивалютного итога
+
+### Requirement: Analytics summary remains readable per currency
+
+Страница MUST обозначать фактический результат как «Получено купонами и дивидендами» и для каждой исходной валюты показывать total, coupon subtotal и dividend subtotal выбранного периода. Она MUST объяснять, что tax operations не включены, не называя фактический результат gross, net, суммой до налогов, суммой после налогов или налоговым расчётом. Значения MUST оставаться доступными как читаемый текст, не только как графика, цвет или положение. Страница MUST NOT показывать блок «Динамика», его график, переключатель валюты графика или текстовый список временных buckets независимо от длительности выбранного периода. Страница MUST NOT показывать блоки «Предыдущий период» и «Годом ранее» или сообщения о недоступности сравнений.
+
+#### Scenario: Итоги дохода доступны как текст
+
+- **WHEN** выбранный период содержит исполненные купонные или дивидендные выплаты
+- **THEN** страница показывает читаемые total, coupon subtotal и dividend subtotal с обозначением фактически полученного дохода и объяснением исключения tax operations
+
+#### Scenario: Итоги нескольких валют остаются разделёнными
+
+- **WHEN** результат содержит подходящие выплаты в нескольких исходных валютах
+- **THEN** страница показывает отдельные читаемые итоги каждой валюты без конвертации и общего итога разных валют
+
+#### Scenario: Динамика отсутствует для периода любой длительности
+
+- **WHEN** User открывает аналитику или применяет допустимый период любой длительности
+- **THEN** страница показывает итоги и выплаты без динамики, сравнений периодов и состояний их доступности
+
+### Requirement: Income page excludes upcoming forecasts
+
+Страница «Пассивный доход» MUST NOT показывать блок «Ближайший прогноз», его суммы, список будущих выплат, состояния загрузки, пустоты или ошибки. Forecast values MUST NOT входить в realized total, trend buckets или instrument breakdown. Доступность данных Future Cash Events MUST NOT влиять на отображение успешно загруженной realized analytics. Существующая самостоятельная страница «Будущие события» и её доступность из выбранного Brokerage Account MUST сохраняться.
+
+#### Scenario: Известные будущие выплаты не появляются на странице дохода
+
+- **WHEN** для выбранного Brokerage Account известны будущие coupon или dividend события с суммой или без неё либо maturity или offer события
+- **THEN** страница дохода не показывает блок «Ближайший прогноз» и не включает эти будущие события в фактически полученный доход
+
+#### Scenario: Изменение исторического периода не возвращает прогноз
+
+- **WHEN** User применяет допустимый исторический период или сбрасывает фильтры
+- **THEN** страница показывает соответствующую realized analytics без блока «Ближайший прогноз»
+
+#### Scenario: Данные будущих событий недоступны
+
+- **WHEN** realized analytics успешно загружена, а данные Future Cash Events недоступны
+- **THEN** итоги и карточки выплат остаются доступными, а страница дохода не показывает состояние ошибки или загрузки прогноза
+
+#### Scenario: Самостоятельная страница будущих событий сохраняется
+
+- **WHEN** User переходит из выбранного Brokerage Account на существующую страницу «Будущие события»
+- **THEN** эта страница остаётся доступной с прежним поведением независимо от отсутствия прогноза на странице дохода
@@ -0,0 +1,59 @@
+## MODIFIED Requirements
+
+### Requirement: Account overview includes recent ledger events
+
+Обзор счёта MUST показывать пять последних исполненных записей журнала этого счёта и действие перехода к его полному журналу. Каждая показанная запись MUST иметь ту же визуальную идентичность инструмента и семантику денежного движения, что и запись полного журнала. Исполненные купоны и дивиденды MUST иметь то же представление выплаты, что и на других экранах с купонами и дивидендами; остальные операции сохраняют представление записи журнала. Неуспешный или пустой запрос последних записей MUST оставаться локальным состоянием блока последних событий и MUST NOT заменять успешно отображённый обзор Portfolio.
+
+#### Scenario: Отображение последних событий
+
+- **WHEN** загружается обзор счёта и его журнал содержит исполненные операции
+- **THEN** обзор показывает не более пяти последних записей и ссылку на полный журнал, а купоны и дивиденды узнаваемы по тому же представлению выплаты
+
+#### Scenario: Последние записи недоступны
+
+- **WHEN** обзор счёта успешно загружается, но запрос последних записей завершается ошибкой
+- **THEN** обзор Portfolio остаётся доступным, а блок последних событий отображает собственное состояние восстановления
+
+#### Scenario: Последняя запись не содержит visual metadata инструмента
+
+- **WHEN** одна из последних записей не имеет доступной presentation metadata инструмента
+- **THEN** обзор показывает для неё понятный текстовый fallback и сохраняет дату, тип, инструмент и денежное изменение записи доступными для чтения
+
+### Requirement: Full ledger presents compact rows
+
+Страница полного журнала MUST показывать для каждой записи дату, тип операции, инструмент и денежное изменение в исходной валюте в компактной структурированной строке. При доступной presentation metadata инструмента строка MUST показывать его визуальную идентичность; при её отсутствии MUST использовать понятный текстовый fallback. Для купонных и дивидендных операций на странице полного журнала и в личной истории инструмента MUST использоваться то же представление выплаты, что в доходе, прогнозе и графиках инструментов, с обозначением исполненного движения. Для каждой записи денежное изменение в исходной валюте MUST сопровождаться подписью конкретного типа события и знаком: для купонной операции — «Купон», для дивидендной — «Дивиденд», для остальных записей — подпись их категории («Сделка», «Налог», «Комиссия», «Перевод», «Прочее»). Строка MUST NOT повторять подпись типа события во вторичной метадате записи. Знак «+» / «−» и семантический цвет MUST оставаться носителями направления и MUST NOT заменяться только текстом. Страница MUST обозначать записи без движения денег нейтрально и MUST NOT показывать цену или количество.
+
+#### Scenario: Отображение записи только с инструментом
+
+- **WHEN** полный журнал отображает запись без денежной выплаты
+- **THEN** страница определяет её как запись без движения денег
+
+#### Scenario: Отображение поступления
+
+- **WHEN** полный журнал отображает запись с положительной денежной выплатой
+- **THEN** строка явно показывает поступление знаком и подписью конкретного типа события («Купон», «Дивиденд» или категории) и его денежное изменение в исходной валюте, не полагаясь только на цвет
+
+#### Scenario: Отображение списания
+
+- **WHEN** полный журнал отображает запись с отрицательной денежной выплатой
+- **THEN** строка явно показывает списание знаком и подписью конкретного типа события («Купон», «Дивиденд» или категории) и его денежное изменение в исходной валюте, не полагаясь только на цвет
+
+#### Scenario: Отображение купона
+
+- **WHEN** полный журнал или личная история инструмента отображает исполненную операцию с upstream-типом купона
+- **THEN** запись показывает подпись «Купон» и исполненную сумму в том же представлении выплаты, что на других экранах
+
+#### Scenario: Отображение дивиденда
+
+- **WHEN** полный журнал или личная история инструмента отображает исполненную операцию с upstream-типом дивиденда
+- **THEN** запись показывает подпись «Дивиденд» и исполненную сумму в том же представлении выплаты, что на других экранах
+
+#### Scenario: Подпись типа не дублируется
+
+- **WHEN** полный журнал отображает запись с типом события и вторичной метадатой
+- **THEN** подпись типа события присутствует в строке один раз и не повторяется во вторичной метадате записи
+
+#### Scenario: Отсутствует visual metadata инструмента
+
+- **WHEN** полный журнал отображает запись без доступной presentation metadata инструмента
+- **THEN** строка показывает понятный текстовый fallback без подмены или сокрытия доступных данных инструмента
@@ -0,0 +1,59 @@
+## MODIFIED Requirements
+
+### Requirement: Account page presents an upcoming events list
+
+Страница Brokerage Account MUST предоставлять read-only действие перехода на отдельную страницу «Будущие события». Эта страница MUST показывать события сохранённого полного прогноза компактным списком без фильтров, пагинации, суммарного итога или действия ручной синхронизации, с датой, типом, инструментом и прогнозной суммой в исходной валюте, если она известна. Купоны и дивиденды MUST использовать то же представление выплаты, что и исполненные купоны, дивиденды и события графика инструмента, но MUST быть явно обозначены как прогноз, а не полученные деньги. Дата дивиденда MUST быть обозначена как дата реестра. Страница MUST показывать `calculatedAt`, исходное окно прогноза и наблюдаемые freshness, полноту, время последнего успешного прогноза, последнюю часовую попытку и доступность из `meta` понятным текстом или иконкой с доступным именем, а не только цветом. Она MUST объяснять, что прогноз рассчитан по количеству бумаг на `calculatedAt`, а показанные события дополнительно ограничены запрошенным включительным UTC-окном; прогноз указан до налогов и может быть неполным из-за доступности данных источника. Открытие страницы и повтор HTTP-чтения MUST NOT запускать личную синхронизацию.
+
+#### Scenario: Просмотр ближайших событий
+
+- **WHEN** User открывает «Будущие события» из обзора Brokerage Account
+- **THEN** он видит отсортированный read-only список событий сохранённого 30-календарного окна и `calculatedAt`, где купоны и дивиденды представлены как прогнозные выплаты, а offer обозначен без суммы
+
+#### Scenario: Прогнозный дивиденд с неизвестной суммой
+
+- **WHEN** прогноз содержит дивиденд с известной датой реестра, но без суммы
+- **THEN** его карточка обозначает дату как дату реестра и сумму как неизвестную, не показывает нулевую или полученную выплату
+
+#### Scenario: Пустое состояние страницы
+
+- **WHEN** запрос будущих событий успешно возвращает пустой список
+- **THEN** страница сообщает, что в сохранённом окне прогноза событий не найдено, показывает `calculatedAt` и объясняет ограничения покрытия источника
+
+#### Scenario: Первая загрузка либо ошибка без сохранённого прогноза
+
+- **WHEN** запрос будущих событий возвращает `data: null`, а `meta` обозначает выполнение первой загрузки либо её неуспех
+- **THEN** страница показывает доступное состояние загрузки либо ошибки без частичного списка и предоставляет при ошибке действие повторить только HTTP-чтение
+
+#### Scenario: Ошибка страницы
+
+- **WHEN** запрос будущих событий завершается ошибкой
+- **THEN** страница не показывает частичный список и предоставляет действие повторить только HTTP-чтение
+
+#### Scenario: Ошибка обновления при сохранённом прогнозе на странице
+
+- **WHEN** запрос будущих событий возвращает последний полный прогноз вместе с ошибкой его обновления
+- **THEN** страница показывает этот прогноз с его исходными `calculatedAt` и окном, отдельно сообщает об ошибке обновления и предоставляет действие повторить только HTTP-чтение
+
+### Requirement: Account overview includes upcoming events
+
+Обзор Brokerage Account MUST показывать не более пяти ближайших Future Cash Event сохранённого полного прогноза в применённом запрошенном окне, его `calculatedAt`, исходное окно, наблюдаемую freshness, полноту, последнюю часовую попытку и доступность из `meta`, а также действие перехода на read-only полную страницу «Будущие события». Купоны и дивиденды MUST быть представлены той же карточкой выплаты, что на полной странице событий и остальных экранах, с явным обозначением прогнозного статуса; погашение и оферта сохраняют своё значение. Статус MUST быть понятен текстом или иконкой с доступным именем, а не только цветом. Неуспешное обновление при сохранённом прогнозе MUST оставаться локальным состоянием блока, сохранять показанные события и их исходное окно и MUST NOT заменять успешно отображённый Portfolio. Если полного прогноза нет, неуспешное обновление MUST оставаться локальным состоянием блока без частичного списка. Обзор MUST NOT предоставлять действие ручной синхронизации; его повтор MUST выполнять только HTTP-чтение.
+
+#### Scenario: Отображение ближайших событий
+
+- **WHEN** обзор счёта успешно загружен и сохранённый прогноз содержит будущие события
+- **THEN** обзор показывает первые пять событий в порядке даты, `calculatedAt` и действие перехода к полной странице, используя единое представление для прогнозных купонов и дивидендов
+
+#### Scenario: Ближайшие события недоступны без сохранённого прогноза
+
+- **WHEN** обзор счёта успешно загружен, а события возвращают `data: null` и `meta` обозначает выполнение первой загрузки либо её неуспех
+- **THEN** Portfolio остаётся доступным, а блок будущих событий отображает собственное доступное состояние загрузки либо ошибки без частичного списка
+
+#### Scenario: Ближайшие события недоступны
+
+- **WHEN** обзор счёта успешно загружен, но запрос будущих событий завершается ошибкой
+- **THEN** Portfolio остаётся доступным, а блок будущих событий отображает собственную ошибку
+
+#### Scenario: Неуспешное обновление не скрывает сохранённый прогноз
+
+- **WHEN** обзор счёта получает сохранённый полный прогноз вместе с ошибкой его обновления
+- **THEN** Portfolio и события сохранённого окна остаются доступными, а блок отдельно обозначает ошибку и предлагает повторить только HTTP-чтение
@@ -0,0 +1,25 @@
+## Purpose
+
+Позволяет отличать опубликованные календарные сведения о купонах и дивидендах
+инструмента от фактически полученных личных выплат и прогноза по позиции.
+
+## ADDED Requirements
+
+### Requirement: Instrument payout schedules do not imply executed income
+
+На страницах акций и облигаций известные будущие, прошедшие и недатированные события графика дивидендов или купонов MUST использовать то же представление выплаты, что и купоны/дивиденды других экранов, но MUST обозначать их как события графика, не подтверждающие фактическое зачисление. Доступные дата реестра, дата выплаты, сумма на одну бумагу и отдельная личная оценка MUST сохранять свои подписи и смысл; неизвестная сумма или дата MUST NOT подменяться нулём или вымышленной датой. Исполненная личная операция MUST оставаться отличимой от события графика, даже когда их даты совпадают.
+
+#### Scenario: Будущий купон с известными условиями
+
+- **WHEN** User просматривает будущий купон облигации с известными датой выплаты, суммой на облигацию и оценкой для позиции
+- **THEN** единое представление показывает купон как событие графика, сохраняет обе разные суммы и дату и не называет оценку полученными деньгами
+
+#### Scenario: Прошедший дивиденд без подтверждённой операции
+
+- **WHEN** User просматривает в истории акции событие дивидендного графика с прошедшей датой реестра
+- **THEN** представление показывает его как событие графика с суммой на акцию, а не как исполненную выплату пользователю
+
+#### Scenario: Неизвестные условия графика
+
+- **WHEN** в купонном или дивидендном графике отсутствует дата выплаты либо денежное значение
+- **THEN** представление сохраняет известные сведения и явно различает неизвестное значение и ноль без вымышленной даты зачисления
@@ -0,0 +1,123 @@
+# System Analysis
+
+## Requirement Coverage
+
+| Нормативная область | Поток и контракт |
+| --- | --- |
+| `brokerage-account-income-analytics`: удаление `Period comparisons preserve calendar and currency meaning`, выбранный период, полнота, читаемые итоги, отсутствие прогноза | [income-period.mmd](sequences/income-period.mmd), [target schema](contracts/income-analytics-response.schema.json) |
+| `brokerage-account-income-analytics`: точные карточки выплат | [payment-sources.mmd](sequences/payment-sources.mmd), существующая форма entries |
+| `brokerage-account-ledger`: журнал, недавние операции и история инструмента | [payment-sources.mmd](sequences/payment-sources.mmd), существующий ответ операций |
+| `brokerage-account-upcoming-events`: полный список и превью | [payment-sources.mmd](sequences/payment-sources.mmd), существующий ответ событий |
+| `instrument-income-schedules`: будущее, прошлое, неопределённая дата/сумма | [payment-sources.mmd](sequences/payment-sources.mmd), существующие ответы календарей |
+
+## Systems and Responsibilities
+
+- Пользователь выбирает применённый период и отличает исполненные выплаты от
+  возможных поступлений и условий выпуска.
+- Frontend хранит применённые даты в URL, показывает только финансовые значения
+  их собственного источника и использует один предметный компонент для
+  купонов/дивидендов всех трёх режимов. Он не выводит исполнение из календаря.
+- Backend проверяет доступ, период и покрытие операций; формирует точные
+  source-currency итоги и записи выбранного периода. Для income-analytics не
+  запрашивает предыдущий или годовой период ради сравнения.
+- Сохранённые операции T-Bank остаются источником фактических выплат; прогноз
+  основан на позиции, календарь бумаги — на опубликованных условиях T-Bank/MOEX.
+  Они не становятся взаимозаменяемыми при объединении представления.
+
+## Interaction Flows
+
+- [Доход выбранного периода](sequences/income-period.mmd): доступ, полнота,
+  успешный/пустой результат и неполное покрытие без запросов сравнения.
+- [Три источника карточки выплаты](sequences/payment-sources.mmd): подтверждённая
+  операция, будущий прогноз и событие календаря; остальные типы сохраняют
+  существующее представление.
+
+## Contracts
+
+| Производитель → потребитель | Транспорт / операция | Целевой контракт |
+| --- | --- | --- |
+| Backend → frontend | `GET /api/v1/brokerage-accounts/{accountId}/income-analytics`, `GET /api/v1/brokerage-accounts/all/income-analytics`, `application/json` 200 | [JSON Schema ограничений ответа](contracts/income-analytics-response.schema.json) поверх текущего backend-generated OpenAPI: убрать `data.previous`, `data.yearComparison`, comparison roles в `meta.dependencies`; оставить выбранный период и все прочие поля и ошибки в исходном смысле. |
+| Backend → frontend | Income summary, операции, события, календари акций/облигаций | Без изменений wire-формы; типизированные исходные данные адаптируются к общему представлению купона/дивиденда на границе UI. |
+
+Целевой schema-файл описывает *изменение* ответа и не подменяет полную схему
+неизменённых полей; при согласовании используется вместе с предоставленным
+OpenAPI snapshot. `meta.dependencies` содержит только зависимость выбранного
+периода с ролью `selected`; это не новая причина загрузки другого периода.
+Существующие auth, invalid-period и resource errors не меняются. Отсутствуют
+новые операции/версии и callback-протоколы. Порядок entries и повторяющиеся ID
+сохраняются; повторный HTTP read не должен создавать второе зачисление.
+
+## Data and State Semantics
+
+- `data: null` с незавершённым покрытием выбранного периода не становится
+  нулевым доходом. Успешный полный период без qualifying entries — доступный
+  нулевой результат. Свежесть и попытка обновления относятся к выбранному
+  результату, не к удалённым comparison-периодам.
+- Купоны/дивиденды фактического дохода — точные исполненные операции с
+  исходным знаком, валютой и timestamp; календарное событие с прошедшей датой
+  не доказывает их наличие.
+- Forecast projected amount может быть `null`; для dividend `dateKind=registry`
+  означает дату реестра, не зачисления. График хранит per-share/per-bond Money,
+  опциональную оценку по позиции, известные даты и время источника отдельно от
+  `payment` исполненной операции. Неизвестное не становится нулём.
+- Общий предметный компонент получает явный режим происхождения данных;
+  адаптация не пересчитывает backend totals и не меняет source identity.
+
+## Error and Recovery Semantics
+
+- Некорректный черновик остаётся на клиенте с ошибкой поля; серверный invalid
+  period и отказ доступа сохраняют действующие ответы без fallback на другой
+  период или чужой счёт.
+- Ошибка получения страницы исполненных операций не завершает покрытие
+  выбранного периода и не публикует частичный итог как полный. Последний
+  подтверждённый результат и его исходное время остаются независимыми от
+  неуспеха последней попытки.
+- Ошибка прогноза не скрывает уже загруженный доход; отсутствие оценки,
+  логотипа либо даты в календаре не создаёт ложного исполнения или нуля.
+- Поздний ответ прежнего подключения не должен восстановить личные данные
+  нового/недоступного подключения; граница доступа сохраняется.
+
+## Observability Semantics
+
+- Существующие status результата, `meta` полноты/попытки и request correlation
+  позволяют отличить полный выбранный период, pending и failure.
+- Событие синхронизации выбранного периода не включает comparison-only
+  dependencies; получение прошлого/годового интервала для иных самостоятельных
+  запросов не считается сравнением дохода.
+- Новых аналитических событий или чувствительных атрибутов не требуется.
+
+## Security and NFR at System Boundaries
+
+- Bearer-сессия, текущее подключение и доступ к выбранному счёту проверяются
+  до выдачи личных операций; `all` ограничен доступными счетами.
+- Даты остаются включительными календарными датами Europe/Moscow, без
+  максимальной длительности; валюты не конвертируются. Не вводится новый SLA.
+
+## Compatibility / Migration
+
+Удаление `previous` и `yearComparison` из ответа намеренно breaking для
+потребителя старой формы. Backend публикует обновлённый исполняемый OpenAPI;
+frontend получает его как явный artifact и обновляет локальные типы прежде,
+чем интеграция начнёт опираться на новую форму. Строгая semantic compatibility
+между новым OpenAPI и target schema проверяется до поставки. При поставке
+backend и frontend согласуются как пара, без обещания одновременной
+совместимости со старым потребителем. Существующие поля buckets/instruments,
+запросы сводки/журнала/прогноза и их доступность не меняются.
+
+## Durable Documentation Candidates
+
+- `docs/domains/income/overview.md`: отсутствие сравнений и загрузки чужих
+  периодов, только полнота выбранного периода.
+- `docs/domains/portfolio/all-accounts.md`,
+  `docs/adr/017-local-tbank-reads-and-background-sync.md`: проверить
+  упоминания приоритета и смысла удалённых comparisons; ADR хранить как
+  историческое решение, не переписывать как AS-IS.
+- `docs/domains/income/upcoming-events.md`, `docs/domains/instruments/stocks.md`,
+  `docs/domains/instruments/bonds.md`, `docs/domains/operations/overview.md`:
+  общая карточка при сохранении границы между исполнением, прогнозом и графиком.
+
+## Open Questions
+
+Нет блокирующих вопросов в утверждённом scope. Детали визуальной композиции
+общего компонента остаются за Engineering Design при сохранении нормативных
+различий денежного и календарного смысла.
@@ -0,0 +1,46 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "https://wealthledger.local/contracts/unify-income-payment-cards/income-analytics-response.schema.json",
+  "title": "Целевое изменение ответа income-analytics",
+  "description": "Ограничения поверх неизменённых свойств текущего backend-generated OpenAPI: точный контракт остальных полей остаётся у опубликованного OpenAPI. Применяется к 200 application/json обоих маршрутов income-analytics.",
+  "type": "object",
+  "required": ["data", "meta"],
+  "properties": {
+    "data": {
+      "anyOf": [
+        { "type": "null" },
+        {
+          "type": "object",
+          "required": [
+            "accountId",
+            "period",
+            "totalsByCurrency",
+            "calculatedAt",
+            "bucketGranularity",
+            "buckets",
+            "instruments",
+            "entries"
+          ],
+          "properties": {
+            "previous": false,
+            "yearComparison": false
+          }
+        }
+      ]
+    },
+    "meta": {
+      "type": "object",
+      "required": ["dependencies"],
+      "properties": {
+        "dependencies": {
+          "type": "array",
+          "items": {
+            "type": "object",
+            "required": ["role"],
+            "properties": { "role": { "const": "selected" } }
+          }
+        }
+      }
+    }
+  }
+}
@@ -0,0 +1,26 @@
+sequenceDiagram
+    actor User
+    participant UI as WealthLedger frontend
+    participant API as WealthLedger backend
+    participant Store as Saved investment data
+    participant Broker as T-Bank
+    User->>UI: Open income page / apply from,to
+    UI->>API: GET income-analytics(accountId or all, from, to)
+    API->>Store: Verify session, membership, selected-period coverage and operations
+    alt Access denied or invalid period
+        API-->>UI: Problem Details (access/input error)
+        UI-->>User: Account/period error; preserve last applied data on invalid draft
+    else Selected period complete
+        Store-->>API: Confirmed selected operations and source state
+        API-->>UI: data with selected totals/entries + meta(selected)
+        UI-->>User: Totals and executed payment cards, no comparisons
+    else Selected period missing or incomplete
+        Store-->>API: Incomplete coverage + resource state
+        API-->>UI: data null + meta(selected)
+        UI-->>User: Loading or recoverable error, no partial final totals
+        opt First read of missing historical interval
+            API->>Broker: Begin bounded acquisition of missing selected interval
+            Broker-->>Store: Publish only confirmed complete result
+        end
+    end
+    Note over API,Store: No previous/year-ago interval is requested for comparison
@@ -0,0 +1,22 @@
+sequenceDiagram
+    actor User
+    participant UI as WealthLedger frontend
+    participant API as WealthLedger backend
+    participant Source as Broker / market source
+    alt Executed coupon or dividend
+        Source-->>API: Confirmed operation with signed payment and timestamp
+        API-->>UI: Ledger/income entry with original Money and instrument identity
+        UI-->>User: Shared payout card - executed, original signed amount
+    else Upcoming coupon or dividend
+        Source-->>API: Forecast event based on position at calculatedAt
+        API-->>UI: Future event, date kind and nullable projected Money
+        UI-->>User: Same payout card - forecast, registry date where applicable
+    else Instrument schedule event
+        Source-->>API: Published coupon/dividend terms, possibly undated/unknown
+        API-->>UI: Per-security amount, optional estimate and dates
+        UI-->>User: Same payout card - schedule, not a confirmed receipt
+    else Other operation or future event
+        API-->>UI: Trade/tax/fee/maturity/offer data
+        UI-->>User: Existing non-payout representation
+    end
+    Note over UI,User: Same payout presentation; source and certainty remain explicit
@@ -0,0 +1,67 @@
+# Tasks
+
+## 1. Удаление сравнений и поставка контракта дохода
+
+- [x] 1.1 [backend] Оставить для дохода только выбранный период в чтении и планировании фоновой загрузки; сохранить точные итоги, signed entries, полноту, текущую месячную сводку и существующие buckets.
+  - **Covers:** `brokerage-account-income-analytics` — `Period comparisons preserve calendar and currency meaning` (удаление); `brokerage-account-income-analytics` — `Realized analytics never presents an incomplete result as complete`; `brokerage-account-income-analytics` — `Realized income analytics is account-scoped and period-bound`; `brokerage-account-income-analytics` — `Account overview has an independent current-month income summary`.
+  - **Source:** `design.md` §§ Decisions/backend, Data / Storage Changes; `system-analysis/analysis.md` §§ Interaction Flows, Data and State Semantics.
+  - **Verification:** адресные backend tests: один выбранный диапазон в аналитике и screen sync, без previous/year; полные, неполные, пустые, многостраничные и signed-мультивалютные результаты; неизменная current-month summary.
+  - **Depends on:** none
+
+- [x] 1.2 [backend] Удалить comparison-only поля и роли из обоих публичных income-analytics ответов и опубликовать обновлённый backend-generated OpenAPI как явный контракт для frontend.
+  - **Covers:** `brokerage-account-income-analytics` — `Period comparisons preserve calendar and currency meaning` (удаление); `brokerage-account-income-analytics` — `Realized analytics never presents an incomplete result as complete`.
+  - **Source:** `system-analysis/analysis.md` §§ Contracts, Compatibility / Migration; `system-analysis/contracts/income-analytics-response.schema.json`; `design.md` § Contract Implementation.
+  - **Verification:** `npm run openapi:generate`, `npm run test:openapi-contract` и сопоставление 200 response schema обоих маршрутов с утверждённым target: отсутствуют `previous`, `yearComparison` и роли `previous`/`year`, остальные данные/ошибки сохранены; релевантные HTTP checks и `npm run verify` в backend.
+  - **Depends on:** 1.1
+
+- [x] 1.3 [frontend] Обновить полученный OpenAPI snapshot и generated types, удалить UI, display-only расчёты и состояния сравнений на странице дохода, сохранив фильтры, итоги, налоговое пояснение, плоские выплаты и состояния выбранного периода.
+  - **Covers:** `brokerage-account-income-analytics` — `Period comparisons preserve calendar and currency meaning` (удаление); `brokerage-account-income-analytics` — `User explicitly applies an analytics period represented in the URL`; `brokerage-account-income-analytics` — `Analytics summary remains readable per currency`; `brokerage-account-income-analytics` — `Income page excludes upcoming forecasts`; `brokerage-account-income-analytics` — `Realized analytics never presents an incomplete result as complete`.
+  - **Source:** `design.md` §§ Decisions/frontend, Contract Implementation, UI/UX Package; `system-analysis/analysis.md` § Contracts.
+  - **Verification:** frontend behavior checks для applied/draft периода, URL/back/reset, неполного/пустого/ошибочного selected и отсутствия comparison headings/notices во всех состояниях; локальные typecheck и `npm run verify` на итоговом frontend diff.
+  - **Depends on:** 1.2
+
+## 2. Одна предметная карточка купона и дивиденда
+
+- [x] 2.1 [frontend] Предоставить единый публичный компонент выплаты с явными режимами исполнения, прогноза и графика, сохранив исходную валюту, знак, отсутствие данных и различимые подписи суммы/дат.
+  - **Covers:** `brokerage-account-income-analytics` — `Income payments remain traceable to exact Ledger Entries`; `brokerage-account-ledger` — `Full ledger presents compact rows`; `brokerage-account-upcoming-events` — `Account page presents an upcoming events list`; `instrument-income-schedules` — `Instrument payout schedules do not imply executed income`.
+  - **Source:** `design.md` §§ Decisions/frontend, UI/UX Package; `system-analysis/analysis.md` § Data and State Semantics.
+  - **Verification:** frontend checks разных source modes с signed Money, нулём против неизвестного, registry date и separate per-security/position amounts; `npm run deps`, `npm run typecheck`.
+  - **Depends on:** none
+
+- [x] 2.2 [frontend] Использовать единый компонент для исполненных купонов/дивидендов в доходе, полном журнале, недавних операциях и личной истории инструментов; сохранить порядок, повторы и представление остальных операций.
+  - **Covers:** `brokerage-account-income-analytics` — `Income payments remain traceable to exact Ledger Entries`; `brokerage-account-ledger` — `Account overview includes recent ledger events`; `brokerage-account-ledger` — `Full ledger presents compact rows`.
+  - **Source:** `design.md` §§ Decisions/frontend, UI/UX Package; `qa-analysis.md` § Coverage Matrix.
+  - **Verification:** frontend checks для одного и того же типа карточки во всех перечисленных местах, повторов IDs, исправлений с минусом, fallback identity, деталей личной истории и неизменённых trade/tax rows.
+  - **Depends on:** 2.1
+
+- [x] 2.3 [frontend] Использовать тот же компонент в полном прогнозе и его превью только для купонов/дивидендов, обозначить прогноз и дату реестра дивиденда, сохранить offer/maturity.
+  - **Covers:** `brokerage-account-upcoming-events` — `Account page presents an upcoming events list`; `brokerage-account-upcoming-events` — `Account overview includes upcoming events`.
+  - **Source:** `design.md` §§ Decisions/frontend, UI/UX Package; `system-analysis/analysis.md` § Data and State Semantics.
+  - **Verification:** frontend checks для известной, нулевой и неизвестной projected amount, registry date, preview/full list, offer/maturity и локальных ошибок источника.
+  - **Depends on:** 2.1
+
+- [x] 2.4 [frontend] Использовать тот же компонент в будущих и прошедших графиках акций/облигаций с отдельными подписями условий на бумагу и оценки без приписывания личного зачисления.
+  - **Covers:** `instrument-income-schedules` — `Instrument payout schedules do not imply executed income`.
+  - **Source:** `design.md` §§ Decisions/frontend, UI/UX Package; `system-analysis/analysis.md` § Data and State Semantics.
+  - **Verification:** frontend checks для будущего купона, прошлого дивиденда, недатированного/неизвестного условия, разных сумм на бумагу и позицию; проверка узкого viewport и клавиатуры, `npm run verify` на итоговом frontend diff.
+  - **Depends on:** 2.1
+
+## 3. Актуальная документация после подтверждения целевого поведения
+
+- [x] 3.1 [docs] Привести страницы дохода одного и всех счетов к состоянию без сравнений и описать прежнюю полноту выбранного периода.
+  - **Covers:** `brokerage-account-income-analytics` — `Period comparisons preserve calendar and currency meaning` (удаление); `brokerage-account-income-analytics` — `Analytics summary remains readable per currency`; `brokerage-account-income-analytics` — `Realized analytics never presents an incomplete result as complete`.
+  - **Source:** `docs-impact.md` § Documentation Changes — `docs/domains/income/overview.md`, `docs/domains/portfolio/all-accounts.md`.
+  - **Verification:** сопоставление двух страниц с согласованными ответами income API, UI и проверка ссылок/Markdown средствами docs repo.
+  - **Depends on:** 1.2, 1.3
+
+- [x] 3.2 [docs] Зафиксировать одинаковую карточку исполненной выплаты, прогнозного события и графика с разными финансовыми смыслами на существующих тематических страницах.
+  - **Covers:** `brokerage-account-income-analytics` — `Income payments remain traceable to exact Ledger Entries`; `brokerage-account-ledger` — `Full ledger presents compact rows`; `brokerage-account-ledger` — `Account overview includes recent ledger events`; `brokerage-account-upcoming-events` — `Account page presents an upcoming events list`; `brokerage-account-upcoming-events` — `Account overview includes upcoming events`; `instrument-income-schedules` — `Instrument payout schedules do not imply executed income`.
+  - **Source:** `docs-impact.md` § Documentation Changes — `docs/domains/operations/overview.md`, `docs/domains/income/upcoming-events.md`, `docs/domains/instruments/stocks.md`, `docs/domains/instruments/bonds.md`.
+  - **Verification:** сверить текст четырёх страниц с экранами и публичными исходными данными, проверить ссылки/Markdown средствами docs repo.
+  - **Depends on:** 2.2, 2.3, 2.4
+
+- [x] 3.3 [docs] Обновить описание HTTP income analytics без дублирования машинной схемы.
+  - **Covers:** `brokerage-account-income-analytics` — `Period comparisons preserve calendar and currency meaning` (удаление).
+  - **Source:** `docs-impact.md` § Documentation Changes — `docs/architecture/http-api.md`; `system-analysis/analysis.md` § Contracts.
+  - **Verification:** сопоставить текст с опубликованным backend OpenAPI обоих маршрутов и target schema, проверить ссылки/Markdown средствами docs repo.
+  - **Depends on:** 1.2
@@ -0,0 +1,2 @@
+schema: wealth-ledger-sdd
+created: 2026-10-04
@@ -0,0 +1,70 @@
+# Completion Evidence — quiet-user-feedback
+
+Факты поставки, наблюдённые 2026-10-17 перед native archive. Все 31 task
+отмечены выполненными; реализация и документация проверены по состоянию
+`origin/develop` соответствующих репозиториев, а не по отметкам в `tasks.md`.
+
+Change координировался между тремя репозиториями. Delivery шла не в одном
+потоке: `frontend` поставлен 2026-10-06, `specs` и `docs` отстали и были
+завершены 2026-10-17 по `WealthLedger/specs#50` и `WealthLedger/docs#51`.
+
+## Delivery Map
+
+| Область | Поставленный scope | Коммит |
+| --- | --- | --- |
+| frontend | Тихое чтение: удалены ручное обновление и повтор на экранах просмотра, индикатор фоновой работы и предупреждение о синхронизации. Добавлены ограниченный retry GET и модель первичного ожидания. | `5b30bb8` |
+| specs | Delta-спецификации согласованы с canonical specs после часовой синхронизации; новый spec `frontend-user-feedback`. | `6682f0c`, merge `5a7e319` |
+| docs | ADR 021 о тихом чтении; `ui-resilience` и затронутые `domains/**` приведены к AS-IS. | merge `e8e3ef6` |
+
+## Нормативное поведение
+
+Решение определено по фактической реализации. Два независимых изменения
+оказались совместимы и вместе образуют принятое поведение:
+
+- `frontend 5b30bb8` (2026-10-06) убрал индикацию собственного чтения клиента
+  и ручные действия повтора.
+- `frontend 3c226f8` (2026-10-09, `WealthLedger/main#22`) добавил показ
+  состояния источника из `meta`: время последнего успеха, устаревание, исход
+  последней часовой попытки и неполноту.
+
+Запрет change относится к индикации собственного чтения клиента и ручному
+повтору. Состояние источника — свойство данных, а не отчёт о техническом
+процессе, и остаётся видимым. Ошибки явных действий пользователя сохраняются.
+
+## Проверки
+
+| Проверка | Результат |
+| --- | --- |
+| `npx openspec validate quiet-user-feedback --strict` | valid |
+| `npx openspec archive quiet-user-feedback --yes` | `Totals: + 9, ~ 12, - 0, → 0` |
+| Сохранность 10 сценариев, которые удалили бы исходные `MODIFIED`-блоки | 10/10 присутствуют в canonical specs после archive |
+| specs `npm run verify`, `npm run check:openspec` | pass; `openspec 1.13.1 on Node 24.21.0` |
+| docs `npm run verify` | exit 0, новый ADR охвачен gate |
+| specs PR #51, docs PR #52 | по 3/3 required checks |
+
+Код-основание нормативного поведения, снятое с `frontend/origin/develop`:
+
+```
+retry actions в src/pages/**              0
+Button/onClick в SourceSyncStatus.tsx     0
+sourceTime + attempt renders              3
+GET_DEADLINE_MS                           15_000
+RETRY_DELAYS_MS                           [1000, 2000]
+INITIAL_WAIT_BUDGET_MS                    10_000
+```
+
+## Ограничения
+
+Отметки `[x]` задач 8.1–8.4 были проставлены 2026-10-06 без фактической работы
+в `docs`: ADR отсутствовал, а `ui-resilience.md` описывал отменённое ручное
+обновление. Расхождение обнаружено при подготовке archive и устранено в
+`WealthLedger/docs#51`; archive до этого не выполнялся. `[x]` в `tasks.md`
+этого change не является доказательством поставки.
+
+Исходные delta-блоки устарели относительно canonical specs и при archive
+удалили бы 10 принятых сценариев. Они переписаны в `6682f0c` до archive.
+
+`frontend` gates в рамках завершения не перезапускались: реализация принята
+в `develop` 2026-10-06 и работами 2026-10-17 не изменялась. Независимая QA
+по schema `wealth-ledger-sdd` не требуется; semantic review выполнен по
+фактическому коду и состоянию документации.
@@ -0,0 +1,424 @@
+## Context
+
+Frontend уже разделяет получение данных, page VM и presentation. TanStack
+Query хранит успешные результаты; инвестиционные ресурсы дополнительно
+возвращают `data` и `meta` с полнотой, свежестью и состоянием источника.
+`useResourceQuery` сохраняет общую query identity обычного чтения и наблюдения,
+а `useScreenSync` наблюдает известную работу и предоставляет ручные действия.
+На счетах и портфеле используются `InvestmentRefreshState` и
+`SourceSyncStatus`; сходные элементы встроены в остальные finance views.
+
+Сейчас query retries и focus refetch отключены, ошибка status GET прекращает
+наблюдение, а `observe()` также запрещает retry. В банковских формах отдельно
+существуют технические повторы загрузки справочников и перечитывание записи
+после конфликта версий. Это разные случаи: удаление всех обработчиков с именем
+`retry` или `onReload` без сохранения их ответственности недопустимо.
+
+Предоставленный frontend OpenAPI уже содержит обычное чтение ресурсов,
+`sync=observe`, status GET и принудительный screen refresh. Дополнительная
+сверка реализации показала: обычное чтение запрашивает missing/stale источники,
+свежие полные источники переиспользуются, существующая running work объединяется.
+Принудительный refresh обходит freshness и охватывает зависимости экрана.
+Поэтому он не подходит для автоматического восстановления обычного чтения.
+
+Основные specs текущего store отстают от части реализованной синхронизации.
+Есть пересечение с active change `persist-tbank-data`; его старые UI-требования
+не используются как новая норма поверх согласованных quiet Delta Specs.
+Это различие учитывается в порядке согласования требований ниже.
+
+## Goals / Non-Goals
+
+**Goals:**
+
+- Сосредоточить transport recovery в существующем query layer, а восстановление
+  инвестиционной работы — у существующего владельца `useScreenSync`.
+- Упростить presentation interface: view получает готовое содержимое,
+  недоступность или необходимое пользовательское действие, а не набор
+  технических статусов и callbacks повторной загрузки.
+- Сохранить один финансовый кэш, действующую отмену запросов, границы доступа
+  и точные серверные финансовые результаты.
+- Встроить редкие уведомления в существующие Mantine theme и i18n.
+
+**Non-Goals:**
+
+- Новый query client, offline-хранилище, event bus или универсальный scheduler.
+- Автоматическое повторение мутаций, изменение auth refresh или правил
+  разрешения конфликтов пользовательских данных.
+- Новые endpoints, удаление существующего refresh endpoint, изменение DTO,
+  серверных TTL, алгоритмов расчёта или схемы хранения.
+- Переработка композиции финансовых страниц и диаграмм.
+
+## Decisions
+
+### 1. Два владельца восстановления вместо одного глобального retry
+
+`shared/api` владеет классификацией transport errors, ограниченным retry и
+deadline application GET. Существующие authenticated query hooks применяют
+общую политику к чтению карт, справочников и статуса подключения. Auth bootstrap
+и пользовательские mutations сохраняют текущую отдельную политику.
+
+`useResourceQuery` использует тот же transport recovery, но жизненный цикл
+инвестиционной работы остаётся в `features/tbank-connection`. `useScreenSync`
+становится автоматической orchestration текущего экрана: его callers больше
+не передают `refresh`/`retry` в UI. Page VM продолжает владеть смыслом готовности
+конкретного результата, выбранными параметрами и доступными действиями.
+
+Альтернативы: глобальный retry всех запросов и mutations нарушает границы
+записи и доступа; независимые timers каждой страницы размножают политику.
+Собственный универсальный recovery service дублирует Query lifecycle.
+
+### 2. Конечная transport policy
+
+Для application GET принимаются следующие параметры:
+
+| Параметр | Решение |
+| --- | --- |
+| HTTP deadline | 15 секунд на попытку, включая чтение тела ответа |
+| Автоматические повторы | Не более двух после исходного запроса |
+| Паузы | 1 и 2 секунды; серия не перезапускается от render |
+| Временные ошибки | Подтверждённая transport/network failure, timeout, HTTP 408, 500, 502, 503, 504, `TBANK_UNAVAILABLE` |
+| Не повторять | Отмена, ошибки ввода, 401/403/404, известные access/domain failures, 409, неизвестный постоянный исход |
+| Rate limiting | 429 не повторяется короткой серией без доступного корректного `Retry-After`; наличие серверной отсрочки исключает более ранний повтор |
+| Новая серия | Новый актуальный запрос, возвращение сети или возвращение пользователя на экран |
+
+Классификация использует существующие `ApiErrorCode` и структурированный
+Problem Details status, с приоритетом отказа доступа над общим HTTP status.
+Отсутствие известного code само по себе не означает временную ошибку.
+Transport failure маркируется там, где выполняется GET: ошибка render,
+`select` или преобразования данных не превращается в network failure.
+Если `Retry-After` используется, его transport metadata сохраняется локально
+в ошибке клиента, без нового поля публичного DTO.
+
+Deadline применяется только к application GET, не к auth endpoints и не к
+mutations. Сигнал Query объединяется с сигналом timeout; исходная отмена
+сохраняет причину и не повторяется. Существующий единственный auth refresh
+не дублируется query retry. Восстановление GET после исчерпанного auth refresh
+не допускается до восстановления сессии.
+
+Для обычных authenticated reads применяются штатные Query focus/reconnect
+events и текущие entity `staleTime`. На инвестиционных ресурсах обработка этих
+событий координируется `useScreenSync`: параллельный автоматический refetch
+тех же ресурсов из второго владельца выключен. Lifecycle события берутся
+из Query focus/online managers, без второго набора browser listeners.
+
+Уход последнего consumer отменяет запрос и его retries через существующий
+AbortSignal. Imperative чтение, начатое screen owner, также прекращается
+при его cleanup, если у запроса не осталось других активных consumers.
+
+### 3. Восстановление источника — обычным GET, наблюдение — только observe
+
+Для инвестиционного ресурса разделяются три ситуации:
+
+| Ситуация | Действие владельца |
+| --- | --- |
+| Не получен HTTP-ответ | Ограниченный transport retry того же режима чтения |
+| Известна running work | Status GET и чтение проекции с `sync=observe` |
+| Необходимые данные missing/stale, а work failed/cancelled либо отсутствует | Ограниченный повтор обычного GET ресурса без `sync=observe` |
+
+Успешный HTTP `200` с `data: null` или `sync.state: failed` не считается
+успешным восстановлением источника. Источники определяются из `meta` и
+`meta.dependencies`; `unavailableReason` и предметные ограничения не считаются
+временным сбоем. Неудачная прежняя принудительная сверка уже полного свежего
+результата не запускается заново только ради удаления её внутреннего статуса.
+
+После terminal source failure допускаются две повторные обычные загрузки
+нуждающегося в данных ресурса: через 5 и 15 секунд после соответствующего
+неуспеха. Бюджет относится к активации текущей выборки, а не к ID очередной
+серверной попытки. Новый ID работы, успешное чтение failed metadata и повторный
+render не обнуляют бюджет. После его исчерпания следующий запуск возможен
+при новом lifecycle событии восстановления или выборе новой выборки.
+
+Transport retry и source recovery не вкладываются бесконтрольно: следующая
+source attempt начинается только после завершения предыдущего GET и его
+transport retries. Для одной серии это не более трёх обычных загрузок ресурса,
+каждая не более чем с тремя HTTP-попытками. Наблюдение running work не является
+новой source attempt и никогда не вызывает принудительный POST refresh.
+
+Status observation сохраняет существующий интервал 1 секунда при активном
+экране и известной running work. Повторный tick не отменяет выполняющееся
+чтение или его retry. После terminal status выполняется заключительное
+observe-чтение; если другое чтение ещё идёт, заключительное выполняется после
+него, а не теряется. После ухода, потери сессии или terminal status периодический
+опрос соответствующей работы прекращается. В скрытой вкладке и offline
+новые циклы приостанавливаются; возвращение возобновляет актуальную работу.
+
+`404` status ID не означает автоматически потерю доступа ко всем счетам:
+ресурс перечитывается по действующему адресу, где проверяется текущий доступ.
+Подтверждённые access errors ресурса либо статуса подключения сохраняют
+существующую invalidation личных данных. Коды отказа из metadata также не
+должны маскироваться успешным HTTP-ответом.
+
+Обычное чтение и observe остаются в одной generated query identity. Внутри
+владельца режим запроса задаётся явно; observe не оставляет постоянный
+observe-only queryFn для последующего обычного восстановления. При чтении
+проверяется фактическое in-flight состояние Query, а не только снимок props.
+Повторный event не создаёт второй запрос того же key. Переход на новую выборку
+отменяет старые timers и не позволяет late response менять новую область.
+
+### 4. UI readiness отдельно от query status
+
+Page VM выбирает presentation в следующем порядке:
+
+1. Подтверждённый access failure: скрытые личные данные и необходимое действие.
+2. Доступный результат текущей выборки: loaded, partial или подтверждённый empty.
+3. Отсутствие результата: первоначальный skeleton либо unavailable.
+
+Loaded view не получает `isFetching`, время получения и callbacks технического
+повтора. Технические metadata остаются у data owner для восстановления и
+определения полноты. Не вводится второй кэш успешных финансовых payload.
+
+Первичное ожидание области ограничивается 10 секундами. Ошибка завершившегося
+получения или истечение этого срока переводит её в unavailable. Это UI budget,
+а не отмена полезной source work: поздний успешный результат заменяет состояние
+автоматически. Одна общая небольшая presentation-функция/hook в `shared/lib`
+владеет временем ожидания и latch unavailable для identity области. Она
+не выполняет запросы, не знает T-Bank и не копирует финансовые данные.
+Page VM передаёт readiness и identity; смена выборки сбрасывает ожидание,
+очередная попытка той же выборки не вызывает мигание skeleton.
+
+Доступность проверяется явно, а не через truthiness суммы. `data: []` и полный
+пустой Portfolio — успешные результаты; `data: null` не равен пустому результату.
+Для неполных totals/comparisons выводится `—` с доступной подписью
+«Итог пока недоступен»/«Сравнение пока недоступно». Для неполного списка
+допустима подпись «Показана часть операций», без статуса синхронизации.
+
+Ключи loaded containers не зависят от `isFetching`, revision или времени ответа.
+Фильтры, локальные раскрытия, формы и focus сохраняют существующих владельцев.
+В банковской пагинации прежняя страница не используется как placeholder новой:
+текущий `placeholderData`, допускающий иной page, убирается для этого перехода.
+Сохранение данных при refetch той же страницы обеспечивается самим Query.
+
+`InvestmentRefreshState` и `SourceSyncStatus` удаляются вместе с их callers
+и ненужными presentation props. Общие `StateView` и page skeleton переиспользуются;
+нейтральная недоступность не требует нового компонента-обёртки. Ошибки форм,
+валидация и сообщения, объясняющие финансовый смысл, не удаляются поиском строк.
+
+### 5. Формы и конфликты сохраняют самостоятельное подтверждение
+
+Запросы категорий, исходной покупки возврата и текущей версии записи получают
+обычную политику чтения. Временный refetch не очищает ранее доступные варианты
+и ввод. Когда необходимые данные отсутствуют, соответствующее сохранение
+недоступно; отмена и выход из формы остаются доступны.
+
+После `BANK_VERSION_CONFLICT` или аналогичного предметного конфликта существующая
+invalidation автоматически получает актуальную запись. VM использует этот
+результат вместо отдельной кнопки перечитывания. Пользователь по-прежнему
+видит конфликт, сохраняет ввод и явно принимает новую версию перед повторным
+сохранением или удалением. Фоновый ответ не принимает версию за него.
+Пока новая версия неизвестна, повтор опасной записи заблокирован, но форма
+не находится в бесконечном submit и допускает закрытие.
+
+Создание и правка карт/операций, удаление, категории и изменение подключения
+сохраняют `retry: false`, version и существующие intent IDs. Общая read policy
+не означает автоматического повторения неуспешной записи.
+
+### 6. Mantine Notifications с явным владельцем сообщения
+
+Используется `@mantine/notifications` **9.6.1**, согласованный с установленными
+`@mantine/core` и `@mantine/hooks` 9.6.1. Registry подтверждает эту версию и
+peer requirements React/React DOM `^19.2.0`, совместимые с manifest проекта.
+Стили пакета подключаются после Mantine core; один `Notifications` host
+находится в application composition под MantineProvider.
+
+Параметры: `limit=2`, `autoClose=4000`, desktop `bottom-right`, narrow viewport
+`bottom-center`; видимая кнопка закрытия имеет русское доступное имя. Сообщение
+не получает отдельный заголовок «Успех» и не переносит focus. Текст принадлежит
+существующему i18n; имя пользователя, token и необработанный error в него не входят.
+Очередь очищается при завершении или смене пользовательской сессии.
+
+Уведомление вызывается из одного обработчика успешного действия в его VM,
+не из `useEffect` по `isSuccess` и не из глобального query/mutation interceptor.
+ID относится к выполнению действия, а не к названию операции вообще. Повторное
+завершение того же выполнения подавляется у владельца и получает тот же ID;
+следующее отдельное действие имеет новый ID. Не создаётся постоянный журнал
+показанных сообщений.
+
+Решение о необходимости подтверждения принадлежит VM, знающей оставшийся
+экран. Критерий проверяется по фактически видимой выборке, а не по одному
+наличию успешного HTTP-ответа:
+
+| Действие и оставшийся контекст | Обратная связь |
+| --- | --- |
+| Созданная/изменённая карта или операция видна в обновлённом списке | Содержимое подтверждает результат, toast отсутствует |
+| Успешная операция не видна из-за периода, страницы, фильтра или другого счёта | Одно «Операция сохранена» после закрытия формы |
+| Удалённая запись исчезла из видимого списка | Toast отсутствует |
+| Запись удалена, но оставшийся экран не отражает её исчезновение | Одно «Операция удалена» |
+| Создание/удаление подключения меняет видимый статус | Toast отсутствует |
+| Замена token при прежнем статусе «Подключён» | Одно «Подключение обновлено» |
+| Категория появилась или изменена в открытом списке/поле | Toast отсутствует |
+| Сохранение успешно, но связанное чтение не подтвердило результат на экране | Краткое подтверждение сохранения без сообщения о сбое чтения |
+
+VM получает outcome связанного обновления от существующего владельца
+invalidation; её решение о подтверждении выполняется один раз для action ID.
+Успех записи отделён от успеха последующего GET: ошибка чтения не становится
+ошибкой сохранения и не предлагает повторить уже выполненную запись.
+Получение видимого подтверждения ограничено тем же 10-секундным UI budget;
+после него при отсутствии подтверждения используется одно уведомление.
+Отдельный глобальный наблюдатель mutation results для этого не вводится.
+
+Альтернатива `react-toastify` добавляет вторую визуальную систему без нужной
+дополнительной функции. Собственный toast из Mantine `Notification` потребовал
+бы обслуживать очередь, timers и доступность; готовый пакет дешевле.
+
+## UI/UX Applicability and Package
+
+**Applicability and scope:** `new/changed` — меняются feedback и состояния
+существующих экранов, а не их финансовая композиция.
+
+**Package revision:** `quiet-user-feedback-ui-v1`.
+
+Пакет полностью inline. Отдельные PNG/SVG не нужны: новая геометрия страниц,
+иллюстрации и визуализация финансовых данных не вводятся. Следующие описания
+и схемы входят в единое Design approval.
+
+**Screens, states and interactions:**
+
+| Область | Loaded / background failure | Нет результата | Действия |
+| --- | --- | --- | --- |
+| Счета, портфель, режим всех счетов | Заголовок сразу переходит в карточки и содержимое; строки синхронизации отсутствуют | Page-owned skeleton → нейтральная недоступность | Открыть счёт, перейти в раздел, настроить отсутствующее подключение |
+| Операции, доход, события | Фильтры и доступный результат сохраняются; даты событий остаются | Недоступность только текущей выборки или расчёта | Применить/сбросить фильтры, сменить страницу, навигация |
+| Поиск и детали инструментов | Поиск, график и доступные секции без технических controls | Незагруженная секция сохраняет свой заголовок и локальное состояние | Поиск, выбор инструмента и диапазона |
+| Карты, сводки и история | Данные и пользовательские controls сохраняются | Локальная недоступность без ложного нулевого остатка | Добавить/изменить, фильтры, страницы |
+| Настройки подключения | Статус и введённый token сохраняются при временном сбое чтения | Нет формы до первого подтверждённого статуса | Подключить/заменить/отключить после получения статуса |
+| Формы и подтверждения удаления | Локальное ожидание явного действия; ошибки у владельца | Недоступность нужного справочника или актуальной версии | Сохранить/отменить; явное принятие новой версии при конфликте |
+
+Схема loaded портфеля:
+
+```text
+Счета / Основной счёт
+Основной счёт
+
+[ ₽ 125 000,50 ]  [ $ 320,00 ]
+Структура портфеля
+Позиции / Деньги / Последние операции / Доход
+```
+
+Между заголовком и содержимым нет зарезервированного места под удалённые
+кнопки, даты и баннеры. Temporary refetch failure имеет тот же вид, что loaded.
+
+Схема локальной недоступности:
+
+```text
+Получено купонами и дивидендами
+Пока недоступно
+
+Открыть пассивный доход →
+```
+
+Ссылка присутствует только там, где у блока уже есть предметная навигация.
+Нет дополнительного «Попробуйте позже», countdown или обещания завершения.
+Для основной страницы сохраняются shell и существующие пути навигации.
+Нейтральное состояние — читаемый текст, не warning/error Alert. Символ `—`
+для отсутствующей суммы всегда имеет доступное объяснение.
+
+Схема редкого подтверждения:
+
+```text
+                         Операция сохранена   ×
+```
+
+Нотификация объявляется ненавязчиво, не закрывает modal, не переводит фокус
+и не является единственным носителем ошибки или необходимого действия.
+При отображении над формой учитывается её focus trap; закрытие уведомления
+не отбирает доступ к кнопкам формы. Повторные фоновые попытки не создают
+live-announcements. Skeleton busy остаётся только у реально ожидающей области.
+
+**Responsive behavior:** существующие layout и semantic tokens сохраняются.
+При ширине 320–767 px нейтральные состояния занимают ширину области; toast
+располагается снизу по центру с отступами и учётом safe area, без горизонтального
+скролла. От 768 px — справа снизу. Сообщения переносятся, кнопка закрытия
+остаётся доступной. Контейнер уведомлений не блокирует pointer events вне
+самих сообщений и не перекрывает единственный путь к основным controls.
+Появление учитывает reduced motion.
+
+**Reused source and differences:** формального reuse чужого SDD UI package нет.
+Применяются текущие Mantine theme, `StateView` и page-owned skeleton; их
+ответственность сохраняется. Отдельная новая theme или макет неизменяемых
+финансовых секций не создаются.
+
+## Delivery Map
+
+| Area | Status | Architectural outcome or N/A reason |
+| --- | --- | --- |
+| frontend | `affected` | Query recovery, автоматическое наблюдение ресурсов, упрощённые VM/views, сохранение form conflict flow, Mantine Notifications, согласованные UI/data conventions и каталог состояний |
+| backend | `N/A` | Существующие обычные GET, observe и server-side work deduplication достаточны; DTO, force endpoint, TTL, хранение и серверные повторы не меняются |
+| specs | `affected` | Согласованные Delta Specs заменяют старые UI/retry obligations; новое правило feedback входит в canonical specs и индекс; пересечение с persist lifecycle разрешается без переписывания чужого active change |
+| docs | `affected` | As-built объяснение тихой загрузки, восстановления и уведомлений заменяет описание ручного refresh в UI resilience, data freshness и затронутых предметных страницах; принятое сквозное решение фиксируется в журнале ADR |
+
+## Solution Assessment
+
+Обязательный trigger — изменение общей политики caching/recovery и
+координации concurrent reads; дополнительно выбирается общий механизм уведомлений.
+
+| Вариант | Fit и зрелость | Security и ограничения | Operating / migration cost | Решение |
+| --- | --- | --- | --- | --- |
+| Существующий TanStack Query + текущие resource/screen owners | Уже владеет cache, retry, cancellation, focus/online events; domain metadata остаётся отдельной | Сохраняет session cancellation; требует отличать read failure от failed work и запретить retries mutations | Без новой runtime-инфраструктуры; изменения сосредоточены в существующих owners | Выбран |
+| Новый scheduler или state-machine runtime | Потребовал бы повторить текущий query lifecycle | Добавляет второе состояние и риск late-response/cache рассогласования | Новая dependency и миграция всех consumers без текущей необходимости | Отклонён |
+| Периодический force refresh | Не соответствует ограниченному recovery текущих missing/stale данных | Повторяет внешнюю работу и игнорирует freshness | Лишние RPC и нагрузка; усложняет rate limiting | Отклонён |
+| Mantine Notifications 9.6.1 | Зрелый companion текущей UI-системы; очередь, lifecycle, responsive position | Только доверенные локализованные тексты, без HTML/error payload | Один согласованный пакет; нет нового сервиса или отдельной темы | Выбран |
+| React-Toastify | Зрелый самостоятельный механизм, но дополнительная функция не нужна | Потребует отдельно согласовывать styling и accessibility | Вторая UI-интеграция и её поддержка | Отклонён |
+| Собственная очередь над Mantine Notification | Встроенный primitive есть, готовой очереди в core нет | Собственные timers, focus/live-region и cleanup повышают риск | Собственный код дороже готового companion | Отклонён |
+
+Выбор опирается на текущие исходники и публичную документацию
+[Query retries](https://tanstack.com/query/latest/docs/framework/react/guides/query-retries),
+[Query cancellation](https://tanstack.com/query/latest/docs/framework/react/guides/query-cancellation),
+[focus refetch](https://tanstack.com/query/latest/docs/framework/react/guides/window-focus-refetching)
+и [Mantine Notifications](https://mantine.dev/x/notifications/).
+Документация объясняет возможности библиотек; domain recovery и UI-пакет
+полностью определены здесь и не зависят от доступа к этим ссылкам.
+
+## Risks / Trade-offs
+
+- **Тишина не означает актуальность в реальном времени.** TTL сам не создаёт
+  расписание; после исчерпания recovery budget новая серия ждёт lifecycle
+  event. Это ограничивает нагрузку ценой возможного ожидания следующего
+  возвращения на экран при долгой недоступности источника.
+- **Короткий UI budget и долгая история.** Через 10 секунд может появиться
+  «Пока недоступно», хотя работа продолжается. Готовый результат заменяет
+  это состояние; уже доступные области не ждут чужой истории.
+- **Умножение повторов.** Transport, status polling и source recovery имеют
+  разных владельцев и конечные бюджеты. Новые source IDs и failed metadata
+  не запускают неограниченную серию.
+- **Access loss важнее cached content.** Ошибки доступа проверяются до loaded
+  presentation. Status ID not found не смешивается с account not found.
+- **Конфликт версии не является ошибкой чтения.** Автоматическое получение
+  новой версии не подтверждает её принятие и не повторяет запись.
+- **Уведомления могут дублировать содержимое.** Решение остаётся у action VM,
+  где известна видимая выборка; глобальный toast на каждый success исключён.
+- **Исходные ветки не равны новой canonical норме.** Существующие local
+  изменения переноса PortfolioStructure сохраняются; design не требует их
+  отката. Удалённая актуальность specs ранее не была подтверждена из-за DNS;
+  фактическая база поставки требует сверки перед её объединением.
+
+## Migration Plan
+
+1. Сохранить текущую canonical базу quiet change и порядок требований:
+   утверждённое quiet-поведение заменяет старые обязательства показывать
+   статусы и ручной retry. Технические возможности уже предоставленного API
+   используются без автоматического переноса всех artifacts `persist-tbank-data`.
+   Его последующий sync/archive не должен восстанавливать отменённые UI-правила:
+   пересекающийся change требует отдельного rebase и approval до своего archive.
+   Если он попадает в canonical specs раньше quiet, quiet deltas адаптируются
+   к новой базе с сохранением согласованного поведения и повторным approval
+   затронутых artifacts. Чужие active artifacts сейчас не переписываются.
+2. Ввести recovery у существующих владельцев чтения и отделить presentation
+   readiness от transport status. Сохранить текущие auth/access/invalidation
+   semantics и различие обычного чтения и observe.
+3. Перевести экраны и формы на тихую presentation, убрать ручные технические
+   controls и сохранить предметные conflict actions. Подключить единый host
+   уведомлений и явные action outcomes. Эти части выпускаются одним frontend
+   изменением: удаление recovery-кнопок не поставляется отдельно от замены.
+4. Согласовать новые conventions и presentation states, затем обновить
+   as-built docs и canonical specs по принятому lifecycle. Серверный rollout
+   и миграция данных для этого решения не требуются.
+
+### Rollback Contract
+
+| Field | Decision |
+| --- | --- |
+| Status | `required` |
+| Reason | Recovery касается сохранения личных снимков, access invalidation и взаимодействия с финансовыми mutations |
+| Trigger | Новая политика показывает данные прежней границы, создаёт неконтролируемые запросы, повторяет запись или ломает восстановление без ручных controls |
+| Actions | Вернуть предыдущую frontend-поставку целиком: старые query policies вместе с прежними UI recovery controls; не откатывать только автоматическое восстановление под уже тихим UI |
+| Data safety | Не менять БД, серверные данные, connection revision, intent IDs и versions; не повторять пользовательские mutations для компенсации; при подозрении на неправильный показ завершить локальную сессию и очистить её кэш |
+| Verification | После отката данные разделены по сессии и подключению, временный сбой имеет прежний доступный recovery path, чтение ограничено прежней политикой, сохранение и удаление требуют явного действия |
@@ -0,0 +1,102 @@
+## Why
+
+Пользователь WealthLedger хочет видеть свои финансы, а не обслуживать получение
+данных. Сейчас сообщения «Источник не удалось обновить», «Сохранённые данные
+не изменены», время последней загрузки и действия «Обновить»/«Повторить»
+перекладывают на него контроль технической работы приложения. Эти элементы
+повторяются на разных экранах и отвлекают от содержимого.
+
+Простого удаления надписей недостаточно: восстановление после временного сбоя
+не должно зависеть от исчезнувшей кнопки. Нужен единый принцип:
+тихое чтение и обновление, самостоятельное восстановление и понятный результат
+явных действий пользователя.
+
+## What Changes
+
+- На экранах просмотра приложение сохраняет доступные данные при фоновом
+  обновлении и временном сбое, не показывает технические предупреждения,
+  индикаторы фоновой работы, отметки времени получения и элементы ручного
+  обновления или повторной загрузки. Это относится к счетам, портфелю, операциям,
+  доходам, событиям, инструментам, поиску, картам и чтению состояния подключения.
+  Те же сообщения не переносятся во всплывающие уведомления или подсказки.
+- После временных сбоев приложение самостоятельно возвращается к нормальной
+  работе, не требуя от пользователя повторять загрузку или перезагружать страницу.
+- Первичное ожидание сохраняет понятную структуру будущего содержимого. При
+  затянувшейся недоступности вместо бесконечной загрузки показывается спокойное
+  локальное состояние «Пока недоступно» без технического повтора. После
+  восстановления содержимое появляется автоматически. Сбой одного блока не
+  скрывает остальные доступные блоки.
+- Отсутствие данных, подтверждённая пустота и неполный финансовый результат
+  остаются различимыми. Неизвестные суммы не становятся нулями, незавершённый
+  расчёт не выдаётся за окончательный, а незагруженный список — за отсутствие
+  операций. Неполнота передаётся состоянием конкретного результата без отчёта
+  о процессе синхронизации. Даты операций, выплат и выбранных периодов сохраняются.
+- Редкие краткие уведомления подтверждают завершённые действия пользователя,
+  когда результат иначе легко пропустить. Очевидные изменения экрана не
+  сопровождаются дублирующим уведомлением. Фоновая загрузка не порождает
+  уведомлений об успехе или ошибке, а повтор одного события — каскад сообщений.
+- Ошибки ввода и неуспешное сохранение остаются у соответствующего поля или
+  формы с сохранением ввода. Действия, необходимые от пользователя, например
+  вход или восстановление подключения, остаются понятными и доступными.
+  Исчезающее уведомление не является единственным сообщением о таком препятствии.
+- Обновление данных не сбрасывает выбранные счёт, инструмент, период, фильтры
+  и не прерывает работу пользователя. Личные данные остаются доступны только
+  тому, кто имеет право их просматривать.
+
+Ожидаемый результат: пользователь видит устойчивое финансовое содержимое,
+не управляет загрузкой и получает обратную связь только там, где она помогает
+понять результат его действия или необходимый следующий шаг.
+
+Non-goals:
+
+- Скрывать неуспешные изменения данных или выдавать их за сохранённые.
+- Менять финансовые расчёты, валютный смысл, даты событий и правила доступа.
+- Добавлять центр уведомлений, историю сообщений или уведомления вне приложения.
+- Обещать актуальность данных в реальном времени.
+
+## Capabilities
+
+### New Capabilities
+
+- `specs/frontend-user-feedback/spec.md`: единая политика редких уведомлений
+  о действиях пользователя, локальных ошибок и отсутствия технического шума
+  на всех экранах приложения, включая карты и инструменты.
+
+### Modified Capabilities
+
+- `specs/frontend-data-resilience/spec.md`: тихое сохранение доступного
+  результата и самостоятельное восстановление вместо предупреждений
+  и ручного повтора; защита границ личных данных сохраняется.
+- `specs/frontend-loading-presentation/spec.md`: отсутствие индикации фонового
+  обновления при доступных данных и переход от первичного ожидания к устойчивому
+  локальному состоянию недоступности; явные действия сохраняют обратную связь.
+- `specs/frontend-ui-resilience/spec.md`: ожидаемые состояния не требуют
+  предупреждения об устаревании и ручного повтора; навигация после
+  аварийной ошибки и действия восстановления доступа остаются доступными.
+- `specs/brokerage-accounts/spec.md`: тихое отображение сохранённого списка,
+  автоматическое восстановление временных ошибок и отсутствие ручной загрузки.
+- `specs/portfolio-view/spec.md`: показ портфеля без времени получения,
+  предупреждений об обновлении и кнопок повтора, с автоматическим восстановлением
+  и сохранением корректного смысла доступных финансовых значений.
+- `specs/brokerage-account-ledger/spec.md`: локальное тихое восстановление
+  последних операций и журнала без технических действий пользователя.
+- `specs/brokerage-account-upcoming-events/spec.md`: сохранение доступных событий
+  при временной ошибке и локальное автоматическое восстановление вместо ручного
+  повтора и технической ошибки блока.
+- `specs/brokerage-account-income-analytics/spec.md`: локальная недоступность
+  незавершённого расчёта и автоматическое восстановление дохода и его сводки
+  без выдачи неполного результата за окончательный.
+- `specs/tbank-connection/spec.md`: автоматическое восстановление чтения статуса
+  без кнопки повтора; ошибки создания, замены и удаления подключения сохраняют
+  явную обратную связь и введённые данные.
+
+## Impact
+
+Изменение охватывает просмотр счетов, портфеля, операций, доходов, будущих
+событий, инструментов и карт, поиск и настройки подключения.
+
+Пользователю больше не нужно следить за обновлением данных и устранять
+временные сбои загрузки вручную. Интерфейс становится спокойнее, а сообщения
+помогают понять результат собственного действия или необходимый следующий шаг.
+Финансовый смысл данных, понятность ошибок сохранения и защита личной
+информации сохраняются.
@@ -0,0 +1,82 @@
+## MODIFIED Requirements
+
+### Requirement: Realized analytics never presents an incomplete result as complete
+
+Система MUST формировать итог выбранного периода, его trend buckets,
+instrument breakdown и drill-down только после успешного получения всех
+необходимых cursor pages исполненных операций этого периода. Каждое comparison
+MUST дополнительно требовать полного результата соответствующего периода
+сравнения. Ошибка любой необходимой страницы MUST NOT возвращать частичные
+totals, comparisons, buckets или
+breakdown как полный результат. При временной недоступности клиент MUST
+сохранять предыдущий полный результат той же выборки либо показывать
+нейтральную недоступность соответствующего расчёта без технических сообщений
+и ручного повтора. Восстановление SHALL выполняться автоматически по
+`frontend-data-resilience`.
+
+Доступные независимые части MUST оставаться видимыми; неполное сравнение MUST
+обозначаться как недоступное без нулевой базы и окончательной разницы. Успешный
+полный период без подходящих выплат MUST возвращать нулевой результат и
+отображаться с объяснением пустого состояния. Неизвестный результат MUST NOT
+подменяться таким нулевым результатом.
+
+#### Scenario: Все страницы операций успешно получены
+- **WHEN** для расчёта требуется несколько cursor pages и каждая страница успешно получена
+- **THEN** система формирует результат по всем подходящим Ledger Entries со всех страниц
+
+#### Scenario: Одна из страниц операций недоступна
+- **WHEN** получение любой необходимой cursor page завершается временной ошибкой
+- **THEN** страница сохраняет предыдущий полный результат той же выборки либо показывает нейтральную недоступность расчёта без ручного повтора и не выдаёт частичный результат за полный
+
+#### Scenario: В периоде нет купонов и дивидендов
+- **WHEN** все необходимые операции успешно получены, но среди них нет подходящих coupon или dividend Ledger Entries
+- **THEN** страница показывает нулевой результат и объясняет, что за выбранный период купоны и дивиденды не найдены
+
+#### Scenario: Основной период готов, сравнение пока нет
+- **WHEN** выбранный период полностью рассчитан, а необходимый период сравнения ещё не получен
+- **THEN** основной доход остаётся доступным, сравнение обозначается как недоступное без нулевой базы, частичной разницы и сообщения о синхронизации
+
+### Requirement: Account overview has an independent current-month income summary
+
+Обзор выбранного Brokerage Account MUST показывать компактный source-currency
+summary «Получено купонами и дивидендами» за период от первого дня текущего
+месяца по Europe/Moscow до сегодняшнего дня включительно и действие перехода
+на страницу «Пассивный доход». Summary MUST всегда использовать этот current-month
+период и MUST NOT наследовать последний пользовательский период страницы аналитики.
+Пустой или неуспешный расчёт MUST оставаться локальным состоянием блока и
+MUST NOT заменять успешно отображённый Portfolio или другие блоки обзора.
+Временная ошибка обновления MUST сохранять доступную сводку той же выборки без
+предупреждения и ручного повтора. При отсутствии результата SHALL показываться
+нейтральная недоступность после первичного ожидания с автоматическим восстановлением.
+
+#### Scenario: Обзор показывает доход текущего месяца
+- **WHEN** обзор Brokerage Account загружен и current-month analytics успешно рассчитана
+- **THEN** он показывает отдельные source-currency итоги с начала текущего месяца по сегодняшний день и переход к полной аналитике
+
+#### Scenario: Пользовательский период не влияет на обзор
+- **WHEN** User ранее применил на странице аналитики период, отличный от текущего месяца
+- **THEN** summary обзора по-прежнему рассчитывается от первого дня текущего месяца по сегодняшний день
+
+#### Scenario: Current-month summary недоступен
+- **WHEN** Portfolio обзора успешно загружен, но расчёт current-month summary завершается временной ошибкой
+- **THEN** Portfolio и остальные блоки остаются доступными, а summary сохраняет предыдущий результат той же выборки либо показывает нейтральную недоступность без ручного повтора
+
+## ADDED Requirements
+
+### Requirement: Доход обновляется без технических сообщений
+
+Страница дохода MUST сохранять применённый период, черновик фильтров и
+доступный результат при фоновом обновлении. Временная ошибка SHALL
+восстанавливаться автоматически без кнопок обновления и повтора, времени
+получения данных и уведомлений об их загрузке. Изменение периода MUST NOT
+подписывать прежний результат новыми датами. Ошибки пользовательского периода
+MUST оставаться у полей и MUST NOT запускать автоматический повтор ошибочного
+ввода. Подтверждённая потеря доступа MUST скрывать личные результаты.
+
+#### Scenario: Доход обновляется при редактировании периода
+- **WHEN** пользователь редактирует черновик дат, а фоновое обновление применённого периода завершилось
+- **THEN** черновик и фокус сохраняются, результат относится к прежнему применённому периоду и техническое уведомление не появляется
+
+#### Scenario: Новый период пока недоступен
+- **WHEN** пользователь применил другой допустимый период, но его расчёт ещё не получен
+- **THEN** страница показывает ожидание или недоступность нового результата, не выдаёт прежние суммы за доход нового периода и восстанавливается автоматически
@@ -0,0 +1,46 @@
+## MODIFIED Requirements
+
+### Requirement: Account overview includes recent ledger events
+
+Обзор счёта MUST показывать пять последних исполненных записей журнала этого
+счёта и действие перехода к его полному журналу. Каждая запись MUST иметь ту же
+визуальную идентичность инструмента и семантику денежного движения, что и запись
+полного журнала. Неуспешный или пустой запрос MUST оставаться локальным состоянием
+блока и MUST NOT заменять успешно отображённый Portfolio. При временном сбое
+обновления блок MUST сохранять доступные записи без технического предупреждения
+или ручного повтора. При отсутствии результата он SHALL показывать первичное
+ожидание либо нейтральную недоступность, автоматически восстанавливая чтение.
+Неподтверждённая пустота MUST NOT представляться отсутствием операций.
+
+#### Scenario: Отображение последних событий
+- **WHEN** загружается обзор счёта и его журнал содержит исполненные операции
+- **THEN** обзор показывает не более пяти последних записей и ссылку на полный журнал
+
+#### Scenario: Последние записи недоступны
+- **WHEN** обзор счёта успешно загружается, но запрос последних записей завершается временной ошибкой
+- **THEN** Portfolio остаётся доступным, а блок сохраняет прежние записи либо показывает нейтральную недоступность без технического повтора и восстанавливается автоматически
+
+#### Scenario: Последняя запись не содержит visual metadata инструмента
+- **WHEN** одна из последних записей не имеет доступной presentation metadata инструмента
+- **THEN** обзор показывает для неё понятный текстовый fallback и сохраняет дату, тип, инструмент и денежное изменение записи доступными для чтения
+
+## ADDED Requirements
+
+### Requirement: Журнал восстанавливает чтение без ручного обновления
+
+Страница журнала SHALL сохранять записи текущей выборки при временном сбое
+обновления и восстанавливать чтение автоматически по `frontend-data-resilience`.
+Период, категории и выбранная страница MUST сохраняться; результат другой
+выборки MUST NOT подменять текущую. Страница MUST NOT показывать время получения,
+технические статусы или действия ручного повтора. Даты операций, фильтры,
+действия их применения и переходы по страницам MUST оставаться доступными.
+При отсутствии результата SHALL применяться первичное ожидание и нейтральная
+недоступность, а не сообщение об отсутствии операций до подтверждения полноты.
+
+#### Scenario: Обновление журнала временно не удалось
+- **WHEN** для применённого периода и страницы уже есть записи, а обновление завершается временной ошибкой
+- **THEN** записи и параметры просмотра сохраняются без предупреждения и кнопки повтора до автоматического восстановления
+
+#### Scenario: Следующая страница ещё не получена
+- **WHEN** пользователь перешёл к следующей странице, но её загрузка временно не удалась
+- **THEN** область новой страницы показывает ожидание или нейтральную недоступность, не выдаёт прежние записи за новую страницу и восстанавливает чтение автоматически
@@ -0,0 +1,73 @@
+## MODIFIED Requirements
+
+### Requirement: Account page presents an upcoming events list
+
+Страница Brokerage Account MUST предоставлять действие перехода на отдельную
+страницу «Будущие события». Эта страница MUST показывать все полученные события
+компактным списком без фильтров, пагинации и суммарного итога, с датой, типом,
+инструментом и прогнозной суммой в исходной валюте, если она известна. Страница
+MUST объяснять, что прогноз основан на позиции счёта, указан до налогов и может
+быть неполным из-за доступности данных источника. Это предметное ограничение
+прогноза MUST NOT превращаться в отчёт о технической синхронизации.
+
+При временном сбое обновления страница MUST сохранять ранее доступный результат
+той же выборки с его исходными `calculatedAt` и окном, без индикации
+собственного чтения и ручного повтора. Состояние источника из `meta`, включая
+неуспех последней часовой попытки и неполноту, MUST представляться по
+`frontend-data-resilience`. При отсутствии результата SHALL показываться
+первичное ожидание либо нейтральная недоступность с автоматическим
+восстановлением по `frontend-data-resilience`. Подтверждённая потеря доступа
+MUST скрывать личные данные независимо от наличия сохранённого результата.
+
+#### Scenario: Просмотр ближайших событий
+- **WHEN** User открывает «Будущие события» из обзора Brokerage Account
+- **THEN** он видит отсортированный список событий ближайших 30 дней, где offer обозначен без суммы
+
+#### Scenario: Пустое состояние страницы
+- **WHEN** запрос будущих событий успешно возвращает полный пустой список
+- **THEN** страница сообщает, что на ближайшие 30 дней событий не найдено, и объясняет предметные ограничения покрытия источника
+
+#### Scenario: Ошибка страницы
+- **WHEN** запрос будущих событий завершается временной ошибкой
+- **THEN** страница сохраняет доступный результат той же выборки либо показывает нейтральную недоступность без ручного повтора, восстанавливая чтение автоматически и не выдавая частичные данные за полный прогноз
+
+#### Scenario: Прогнозный дивиденд с неизвестной суммой
+- **WHEN** прогноз содержит дивиденд с известной датой реестра, но без суммы
+- **THEN** его карточка обозначает дату как дату реестра и сумму как неизвестную, не показывает нулевую или полученную выплату
+
+#### Scenario: Ошибка обновления при сохранённом прогнозе на странице
+- **WHEN** запрос будущих событий возвращает последний полный прогноз вместе с ошибкой его обновления
+- **THEN** страница показывает этот прогноз с его исходными `calculatedAt` и окном и отдельно обозначает неуспех обновления источника, не предлагая ручной повтор
+
+#### Scenario: Первая загрузка либо ошибка без сохранённого прогноза
+- **WHEN** запрос будущих событий возвращает `data: null`, а `meta` обозначает выполнение первой загрузки либо её неуспех
+- **THEN** страница показывает доступное состояние первичного ожидания либо нейтральной недоступности без частичного списка и восстанавливает чтение автоматически
+
+### Requirement: Account overview includes upcoming events
+
+Обзор Brokerage Account MUST показывать не более пяти ближайших Future Cash
+Event и действие перехода на полную страницу «Будущие события». Неуспешный
+или пустой запрос этого блока MUST оставаться локальным состоянием блока и
+не заменять успешно отображённый Portfolio. При временном сбое обновления
+блок MUST сохранять доступные события сохранённого окна без индикации
+собственного чтения; при отсутствии результата SHALL показываться нейтральная
+недоступность после первичного ожидания. Состояние источника из `meta` MUST
+представляться по `frontend-data-resilience`. Восстановление MUST выполняться
+автоматически без ручного повтора и без подмены неизвестного результата
+подтверждённой пустотой.
+
+#### Scenario: Отображение ближайших событий
+- **WHEN** обзор счёта успешно загружен и календарь содержит будущие события
+- **THEN** обзор показывает первые пять событий в порядке даты и действие перехода к полной странице
+
+#### Scenario: Ближайшие события недоступны
+- **WHEN** обзор счёта успешно загружен, но запрос будущих событий завершается временной ошибкой
+- **THEN** Portfolio остаётся доступным, а блок сохраняет прежние события либо показывает нейтральную недоступность без технической ошибки и ручного повтора
+
+#### Scenario: Ближайшие события недоступны без сохранённого прогноза
+- **WHEN** обзор счёта успешно загружен, а события возвращают `data: null` и `meta` обозначает выполнение первой загрузки либо её неуспех
+- **THEN** Portfolio остаётся доступным, а блок будущих событий отображает собственное доступное состояние первичного ожидания либо нейтральной недоступности без частичного списка
+
+#### Scenario: Неуспешное обновление не скрывает сохранённый прогноз
+- **WHEN** обзор счёта получает сохранённый полный прогноз вместе с ошибкой его обновления
+- **THEN** Portfolio и события сохранённого окна остаются доступными, а блок отдельно обозначает неуспех обновления источника, не предлагая ручной повтор
@@ -0,0 +1,116 @@
+## MODIFIED Requirements
+
+### Requirement: Экран списка брокерских счетов
+
+Клиент SHALL загружать список при открытии защищённого маршрута `/accounts`
+без ручного обновления. Клиент MUST использовать успешный frontend-кэш списка
+в течение 60 секунд. После истечения этого срока открытие или возвращение
+на экран SHALL инициировать получение актуального списка; имеющийся Client
+Cached Snapshot MUST оставаться видимым во время обновления и после временной
+ошибки без индикации собственного чтения и действий повтора.
+Автоматическое восстановление SHALL соответствовать `frontend-data-resilience`.
+Открытый экран MAY периодически перечитывать backend-результат, сохраняя
+видимый snapshot, и MUST NOT создавать импорт T-Bank. Состояние источника из
+`meta` MUST представляться по `frontend-data-resilience`.
+
+При успешном непустом ответе клиент MUST отобразить адаптивный одноколоночный
+список широких интерактивных карточек счетов с локализованными типом и, если
+доступна, датой открытия без времени; каждая карточка MUST ясно показывать тип,
+имя, финансовую сводку, вторичные метаданные и заметное действие открытия счёта,
+вести на `/accounts/:accountId` по всей области и сохранять доступное
+клавиатурное состояние. После успешной замены или удаления T-Bank connection
+клиент MUST инвалидировать список счетов.
+
+Для доступной `portfolioSummary` карточка MUST показывать не более двух
+Money-итогов в исходных валютах и обозначать наличие остальных валют, если
+они есть; она MUST NOT показывать или подразумевать FX-конвертацию,
+межвалютный агрегированный итог либо Cash Balance как отдельный второй итог.
+При `portfolioSummary: null` карточка MUST показывать локальное нейтральное
+состояние недоступности сводки, сохраняя метаданные счёта и возможность открыть
+его. При доступной пустой сводке карточка MUST не выдавать отсутствие итогов
+за временную ошибку.
+
+#### Scenario: Пользователь открывает счёт из списка
+- **WHEN** клиент успешно загрузил непустой список и User выбирает карточку счёта
+- **THEN** клиент переходит на `/accounts/:accountId` с `id` выбранного счёта
+
+#### Scenario: Список пуст
+- **WHEN** клиент получает успешный полный пустой массив
+- **THEN** клиент показывает штатное сообщение об отсутствии инвестиционных счетов T-Bank
+
+#### Scenario: Список берётся из свежего frontend-кэша
+- **WHEN** User повторно открывает список в течение 60 секунд после успешной загрузки
+- **THEN** клиент показывает сохранённые счета без нового API-запроса
+
+#### Scenario: Устаревший список загружается повторно
+- **WHEN** User открывает список после истечения 60 секунд frontend-кэша и уже существует последний успешный список
+- **THEN** клиент оставляет этот список видимым во время нового запроса без индикации фонового обновления
+
+#### Scenario: Открытый экран перечитывает список
+- **WHEN** экран Accounts остаётся открытым 30 минут после последнего успешного HTTP-чтения
+- **THEN** клиент выполняет фоновое HTTP-перечитывание backend-результата, сохраняет видимый snapshot и не запускает импорт T-Bank
+
+#### Scenario: Последняя попытка неуспешна после полного списка
+- **WHEN** клиент получает полный `data` списка и `meta` с неуспехом последней часовой попытки
+- **THEN** клиент сохраняет список видимым, показывает его исходное время и текстовое либо доступно именованное предупреждение о неуспешной попытке, не предлагая ручной повтор
+
+#### Scenario: Первая загрузка списка выполняется или неуспешна
+- **WHEN** клиент получает `data: null`, а `meta` обозначает выполнение первой загрузки либо её неуспех
+- **THEN** клиент показывает соответственно доступное состояние загрузки либо локальной недоступности без карточек счетов и без представления частичного списка как полного
+
+#### Scenario: Ошибка фонового обновления не скрывает snapshot
+- **WHEN** обновление устаревшего списка завершается временной ошибкой при наличии последнего успешного Client Cached Snapshot
+- **THEN** клиент сохраняет snapshot видимым без предупреждения и ручного повтора и восстанавливает получение данных автоматически
+
+#### Scenario: Карточка ограничивает валютные итоги
+- **WHEN** доступная сводка счёта содержит итоги в трёх или более валютах
+- **THEN** карточка показывает не более двух исходных валютных итогов и обозначает наличие остальных без общего сконвертированного значения
+
+#### Scenario: Недоступность сводки локальна карточке
+- **WHEN** клиент получает список, в котором `portfolioSummary` одного счёта равна `null`
+- **THEN** он показывает нейтральную недоступность только этой сводки, не скрывает остальные карточки и сохраняет переход на детали счёта
+
+#### Scenario: Пустая сводка не является ошибкой
+- **WHEN** клиент получает доступную `portfolioSummary` с пустым `totalsByCurrency`
+- **THEN** он показывает нейтральное состояние отсутствия финансовых итогов, а не состояние временной ошибки
+
+### Requirement: Клиентские состояния ошибки списка счетов
+
+Клиент SHALL автоматически восстанавливать временно неуспешное чтение списка
+по правилам `frontend-data-resilience` без кнопок обновления и повтора. При
+`TBANK_NOT_CONNECTED` клиент MUST показать необходимость подключения и действие
+открытия настроек T-Bank. При `INVALID_TBANK_TOKEN` клиент MUST показать
+необходимость восстановить подключение и то же действие. Эти подтверждённые
+состояния MUST скрывать личный список и MUST NOT запускать автоматические повторы.
+
+При временной недоступности, включая `TBANK_UNAVAILABLE`, клиент MUST сохранять
+успешный результат текущей границы доступа без предупреждений. Если результата
+нет, после первичного ожидания клиент SHALL показать спокойную локальную
+недоступность без технических подробностей. Неизвестная ошибка MUST получать
+безопасное локальное представление; отсутствие известного кода MUST NOT
+разрешать бесконечные повторы или обход доступа. Временный сбой MUST NOT
+предлагать перенастройку действующего подключения как способ повторить загрузку.
+
+#### Scenario: Подключение требуется
+- **WHEN** клиент получает `TBANK_NOT_CONNECTED`
+- **THEN** клиент не показывает список и предлагает открыть настройки T-Bank
+
+#### Scenario: Известная ошибка не повторяется автоматически
+- **WHEN** запрос списка завершается подтверждённой ошибкой подключения или доступа, требующей действия пользователя
+- **THEN** клиент не выполняет автоматических повторов и предлагает соответствующее действие вместо технической повторной загрузки
+
+#### Scenario: Token требует внимания
+- **WHEN** клиент получает `INVALID_TBANK_TOKEN`
+- **THEN** клиент скрывает личный список и предлагает восстановить подключение в настройках T-Bank
+
+#### Scenario: Временная ошибка T-Bank
+- **WHEN** клиент получает `TBANK_UNAVAILABLE` без доступного результата списка
+- **THEN** клиент автоматически восстанавливает получение и после первичного ожидания показывает нейтральную недоступность без повторной загрузки и предложения перенастроить подключение
+
+#### Scenario: Неизвестная ошибка загрузки
+- **WHEN** клиент получает ошибку без известного кода списка счетов и без доступного результата
+- **THEN** клиент показывает безопасное нейтральное состояние без технического сообщения или кнопки повтора, применяя только допустимое ограниченное восстановление
+
+#### Scenario: Известная ошибка при сохранённом snapshot
+- **WHEN** фоновое обновление списка с последним успешным Client Cached Snapshot получает `TBANK_UNAVAILABLE`
+- **THEN** клиент сохраняет snapshot видимым без предупреждения, времени получения и ручных действий восстановления
@@ -0,0 +1,138 @@
+## MODIFIED Requirements
+
+### Requirement: Client Cached Snapshot остаётся доступным при обновлении Accounts и Portfolio
+
+Frontend MUST сохранять последний успешный результат списка Brokerage Accounts,
+Portfolio и других экранов чтения при фоновом обновлении и временной ошибке
+для того же пользователя, подключения и набора данных. Подтверждённый пустой
+результат MUST также считаться успешным. Смена счёта, инструмента, поискового
+запроса, страницы или применённого периода MUST NOT представлять данные прежней
+выборки как результат новой.
+
+Доступный результат MUST оставаться видимым без индикаторов фонового чтения
+клиента, технических предупреждений об этом чтении и действий ручного повтора.
+Frontend MUST NOT подменять внутренние признаки свежести и полноты, успешное
+время источника или ошибку обновления только ради отсутствия их отображения.
+Client Cached Snapshot MUST оставаться отличным от server-side fallback;
+ошибка чтения MUST NOT изменять `Portfolio.isStale`.
+
+Состояние источника из `meta` — время последнего успешного результата, признак
+устаревания, исход последней часовой попытки и неполнота — MUST представляться
+текстом либо доступно именованным элементом, а не только цветом, и MUST
+различать отсутствие попытки, выполнение, полный успех, частичный успех и
+неуспех. Это состояние принадлежит источнику данных, а не собственному чтению
+клиента, и MUST NOT требовать от пользователя действия.
+
+Обновление MUST сохранять выбранные фильтры, период, открытые разделы, ввод,
+фокус и положение просмотра, пока соответствующее содержимое существует.
+При logout, смене подключения или подтверждённом отказе доступа личные данные
+прежней границы MUST перестать отображаться; поздний результат прежней загрузки
+MUST NOT возвращать их на экран.
+
+#### Scenario: Список Brokerage Accounts обновляется в фоне
+- **WHEN** экран Accounts уже показывает Client Cached Snapshot и начинается фоновое обновление того же списка
+- **THEN** frontend оставляет список видимым без индикации собственного чтения и технических действий
+
+#### Scenario: Resource сохраняется после неуспешной часовой попытки
+- **WHEN** response содержит полный `data` и `meta`, обозначающий неуспех последней часовой попытки
+- **THEN** frontend сохраняет `data` и его исходное время видимыми и отдельно обозначает неуспех попытки, не предлагая ручной повтор
+
+#### Scenario: Обновление Portfolio завершается ошибкой после успешного ответа
+- **WHEN** экран Brokerage Account уже показывает Client Cached Snapshot Portfolio, а последующее обновление этого же Portfolio завершается временной ошибкой
+- **THEN** frontend сохраняет Portfolio видимым без предупреждения и ручного повтора, а восстановление выполняется автоматически
+
+#### Scenario: Server-side fallback и client cached snapshot различаются
+- **WHEN** backend возвращает Portfolio с `isStale` либо фоновое обновление Client Cached Snapshot завершается временной ошибкой
+- **THEN** frontend сохраняет доступные данные без технических сообщений и не подменяет один внутренний вид состояния другим
+
+#### Scenario: Подтверждённая пустота переживает фоновую ошибку
+- **WHEN** текущая выборка ранее успешно вернула полный пустой результат, а её обновление временно не удалось
+- **THEN** подтверждённое пустое состояние сохраняется без предупреждения и не заменяется первичной загрузкой
+
+#### Scenario: Изменились параметры выборки
+- **WHEN** пользователь применил другой период или открыл другой счёт, а данных новой выборки ещё нет
+- **THEN** экран показывает ожидание или недоступность новой выборки и не подписывает прежние суммы новым периодом или счётом
+
+#### Scenario: Обновление не сбрасывает работу пользователя
+- **WHEN** пользователь раскрыл раздел, выбрал фильтры или вводит данные, а фоновое чтение завершилось
+- **THEN** обновление не сбрасывает эти действия, не переносит фокус и не возвращает пользователя в начало сохранившегося содержимого
+
+#### Scenario: Изменился доступ к личным данным
+- **WHEN** пользователь вышел, успешно сменил подключение либо получил подтверждённый отказ доступа к текущим данным
+- **THEN** прежние личные данные скрываются, а позднее завершение старой загрузки не восстанавливает их
+
+## ADDED Requirements
+
+### Requirement: Временные сбои чтения восстанавливаются автоматически
+
+Frontend SHALL автоматически повторять временно неуспешное чтение и восстанавливать
+получение необходимых текущему экрану данных без ручного обновления. Повторы
+одной попытки MUST иметь конечный предел и паузы, исключающие непрерывную
+череду запросов. При исчерпании предела доступные данные SHALL сохраняться,
+а при их отсутствии SHALL показываться локальная недоступность. Возвращение сети,
+возвращение пользователя к открытому экрану и повторное открытие экрана MUST
+возобновлять получение отсутствующих или требующих обновления данных без
+перезагрузки страницы. Свежий полный результат MUST NOT требовать обращения
+к источнику только из-за такого события.
+
+Восстановление MUST учитывать сбой чтения результата и сбой самого получения
+данных из источника, даже если чтение состояния завершилось успешно. Наблюдение
+уже выполняющейся работы MUST NOT запускать её повторно. Уход с экрана MUST
+прекращать новые попытки его восстановления; это не требует отменять уже начатую
+работу источника. Автоматическое восстановление MUST NOT повторять запросы,
+требующие исправления ввода, входа или восстановления доступа, и MUST NOT
+переносить старые параметры в новую пользовательскую выборку.
+
+#### Scenario: Кратковременный сбой чтения
+- **WHEN** чтение текущей выборки временно не удалось, а следующая разрешённая автоматическая попытка успешна
+- **THEN** экран самостоятельно показывает результат без ручного действия и без сообщения о сбое или восстановлении
+
+#### Scenario: Источник завершил работу ошибкой
+- **WHEN** чтение сохранённых данных успешно, но получение необходимых новых данных из источника временно не удалось
+- **THEN** приложение применяет ограниченное автоматическое восстановление к неуспешной работе, а не считает успешное чтение доказательством её успеха
+
+#### Scenario: Повторы исчерпаны
+- **WHEN** временная недоступность сохраняется после конечного предела автоматических попыток
+- **THEN** приложение прекращает серию повторов, сохраняет доступный результат либо локальную недоступность без бесконечной загрузки и ожидает следующего события восстановления
+
+#### Scenario: Сеть или пользователь вернулись
+- **WHEN** после временного сбоя восстановилась сеть либо пользователь вернулся к экрану с отсутствующим или требующим обновления результатом
+- **THEN** получение данных возобновляется автоматически для текущей выборки и при успехе заменяет состояние недоступности содержимым
+
+#### Scenario: Несколько событий восстановления совпали
+- **WHEN** сеть восстановилась одновременно с возвращением пользователя на экран
+- **THEN** приложение не запускает дублирующую работу получения одного набора данных
+
+#### Scenario: Работа источника ещё выполняется
+- **WHEN** приложение восстанавливает чтение состояния уже выполняющейся работы
+- **THEN** оно продолжает получение её результата без повторного запуска той же работы
+
+#### Scenario: Пользователь покинул экран
+- **WHEN** пользователь ушёл со страницы с ожидающим восстановлением
+- **THEN** новые попытки для покинутого экрана прекращаются, а уже начатая работа не изменяет содержимое другой выборки
+
+#### Scenario: Ошибка требует действия пользователя
+- **WHEN** подтверждены недействительное подключение, отсутствие доступа или некорректный ввод
+- **THEN** автоматическая серия повторов прекращается и появляется соответствующее действие или локальная ошибка без технической кнопки повторной загрузки
+
+### Requirement: Неполный результат не выдаётся за окончательный
+
+Frontend MUST различать неизвестный результат, доступную часть данных и
+подтверждённую пустоту. Неполные суммы и сравнения MUST NOT показываться как
+окончательные или заменяться нулями. Доступные записи MAY оставаться видимыми,
+но их список MUST NOT представляться полным при неподтверждённой полноте.
+Состояние SHALL относиться к содержимому конкретной области, например
+недоступному итогу, без отчёта о прогрессе синхронизации. Готовая область MUST
+NOT ждать догрузки истории, которая не влияет на её результат.
+
+#### Scenario: Итог ещё не определён
+- **WHEN** часть данных, необходимых для суммы или сравнения, отсутствует
+- **THEN** соответствующее значение обозначается как недоступное без вымышленного нуля или окончательного частичного итога
+
+#### Scenario: Пустота ещё не подтверждена
+- **WHEN** записи не получены и полнота выбранного периода неизвестна
+- **THEN** экран не сообщает об отсутствии операций или выплат за этот период
+
+#### Scenario: Период готов раньше остальной истории
+- **WHEN** данные показанного периода полны, а не влияющая на него история ещё загружается
+- **THEN** пользователь видит готовый результат без сообщения о догрузке остальной истории
@@ -0,0 +1,52 @@
+## MODIFIED Requirements
+
+### Requirement: Контекстная индикация действий и фонового обновления
+
+Frontend MUST сохранять уже доступное содержимое или элемент управления
+основным контекстом, когда выполняется пользовательское действие либо фоновое
+обновление Client Cached Snapshot. Явное действие пользователя SHALL иметь
+компактную индикацию ожидания рядом с соответствующим элементом управления.
+Фоновое обновление при доступном результате MUST проходить без индикаторов,
+технических сообщений и объявлений о ходе работы. В обоих случаях frontend
+MUST NOT заменять уже доступный контекст skeleton placeholders.
+
+#### Scenario: Выполняется пользовательское действие
+- **WHEN** User запустил действие и его результат ещё ожидается
+- **THEN** frontend сохраняет соответствующий элемент управления или окружающий контекст видимым, показывает компактную индикацию процесса и не заменяет интерфейс skeleton placeholders
+
+#### Scenario: Обновляется уже показанный snapshot
+- **WHEN** frontend обновляет данные при наличии видимого Client Cached Snapshot
+- **THEN** frontend оставляет snapshot видимым без индикации фонового обновления и без замены snapshot skeleton placeholders
+
+## ADDED Requirements
+
+### Requirement: Первичное ожидание не становится бесконечной загрузкой
+
+При отсутствии результата frontend SHALL сначала показывать структурное
+ожидание соответствующей области. После неуспешного завершения получения
+либо истечения ограниченного времени первичного ожидания область MUST переходить
+в спокойное локализованное состояние недоступности без технических подробностей
+и ручного повтора. Это состояние MUST NOT утверждать, что результат пустой,
+или требовать перезагрузки страницы. Продолжающееся автоматическое восстановление
+MUST NOT заставлять область постоянно переключаться между недоступностью и
+skeleton. После успешного получения содержимое SHALL появляться автоматически.
+
+Отсутствие результата одной области MUST NOT скрывать остальные доступные
+области. Первичная загрузка MUST сохранять доступное обозначение занятости,
+а состояние недоступности MUST NOT продолжать объявляться бесконечно занятым.
+
+#### Scenario: Первый результат успешно получен
+- **WHEN** экран ожидает первый результат и получает его в пределах первоначального ожидания
+- **THEN** структурные placeholders сменяются содержимым либо подтверждённым пустым состоянием
+
+#### Scenario: Первое получение данных не удалось
+- **WHEN** у области нет результата и первоначальная загрузка завершилась ошибкой или превысила ограниченное время ожидания
+- **THEN** область показывает нейтральную недоступность без кнопки повтора, вымышленных данных и бесконечного индикатора занятости
+
+#### Scenario: Восстановление продолжается после недоступности
+- **WHEN** область уже показывает недоступность и выполняется очередная разрешённая попытка восстановления
+- **THEN** область сохраняет устойчивое состояние без мигания skeleton и автоматически показывает содержимое после успеха
+
+#### Scenario: Один блок недоступен
+- **WHEN** основной результат загружен, а дополнительный блок не получил данных
+- **THEN** состояние недоступности ограничено этим блоком и не заменяет доступное содержимое страницы
@@ -0,0 +1,20 @@
+## MODIFIED Requirements
+
+### Requirement: Ожидаемые finance states не становятся route failures
+
+Frontend SHALL сохранять локальное отображение известных состояний Brokerage
+Account, Portfolio и T-Bank connection. Эти состояния MUST NOT заменяться
+глобальным fallback. Временная ошибка фонового чтения MUST сохранять доступный
+результат без предупреждения об устаревании, технической ошибки и ручного
+повтора. При отсутствии результата SHALL показываться локальная недоступность
+с автоматическим восстановлением. Подтверждённая необходимость входа,
+восстановления подключения или выбора доступного счёта MUST сохранять понятное
+объяснение и соответствующее действие, не маскируясь сохранёнными личными данными.
+
+#### Scenario: Portfolio Snapshot устарел
+- **WHEN** frontend получает устаревший Portfolio Snapshot в действующей границе доступа
+- **THEN** frontend отображает Portfolio без предупреждения об устаревании и без глобального fallback
+
+#### Scenario: Ошибка T-Bank connection
+- **WHEN** запрос T-Bank connection завершается известной ошибкой
+- **THEN** frontend сохраняет локальное состояние: временный сбой чтения восстанавливается автоматически, а подтверждённая необходимость действия пользователя сопровождается этим действием вместо глобального fallback
@@ -0,0 +1,112 @@
+## Purpose
+
+Определяет спокойную и понятную обратную связь во всех разделах WealthLedger:
+пользователь видит финансовые данные и результат своих действий, а не состояние
+внутреннего процесса получения данных.
+
+## ADDED Requirements
+
+### Requirement: Чтение данных не требует внимания к техническим состояниям
+
+На экранах счетов, портфеля, операций, доходов, событий, инструментов, поиска,
+карт и настроек подключения приложение MUST NOT показывать время получения
+данных, признаки их технического устаревания, ход фонового обновления и сообщения
+об успехе либо временной ошибке такого обновления. Приложение MUST NOT предоставлять
+кнопки или иные действия ручного обновления и повторной загрузки, включая их
+иконные варианты. Эти сведения MUST NOT переноситься в уведомления, подсказки
+или объявления вспомогательных технологий. Даты операций, выплат, открытия
+счёта и выбранных периодов MUST сохранять свой предметный смысл.
+
+Запрет технических действий MUST NOT удалять применение фильтров, переходы между
+страницами, поиск, отправку формы, вход, подключение банка или безопасную навигацию.
+После неуспешного сохранения пользователь SHALL иметь возможность вновь отправить
+сохранённый ввод обычным действием формы.
+
+#### Scenario: Фоновая загрузка завершилась ошибкой
+- **WHEN** на любом из перечисленных экранов уже есть доступный результат и его фоновое обновление временно не удалось
+- **THEN** результат остаётся видимым без предупреждения, времени получения, индикатора, уведомления и действия ручного повтора
+
+#### Scenario: Фоновая загрузка завершилась успешно
+- **WHEN** приложение получает обновлённые данные без явного действия сохранения со стороны пользователя
+- **THEN** содержимое обновляется без сообщения об успешной загрузке и без переноса фокуса
+
+#### Scenario: Просмотр списка карт и операций карты
+- **WHEN** временная ошибка возникает при обновлении уже показанных карт, сводки или операций выбранной карты
+- **THEN** соответствующий результат остаётся доступным без технического предупреждения и ручного повтора, а действия работы с картой сохраняются
+
+#### Scenario: Поиск или новый диапазон инструмента пока недоступен
+- **WHEN** пользователь изменил поисковый запрос либо диапазон графика, а соответствующий результат ещё не получен
+- **THEN** экран показывает ожидание или локальную недоступность нового результата без кнопки повтора и не выдаёт результат прежнего запроса или диапазона за новый
+
+#### Scenario: Предметные даты остаются видимыми
+- **WHEN** экран показывает дату операции, выплаты или выбранный период
+- **THEN** эти даты остаются доступны независимо от отсутствия времени технического получения данных
+
+### Requirement: Краткое уведомление подтверждает неочевидный результат действия
+
+Приложение SHALL показывать краткое локализованное уведомление об успешном
+явном действии пользователя, если после завершения на экране отсутствует
+однозначное подтверждение результата. Если результат уже очевиден по состоянию
+формы или содержимого, приложение MUST NOT дублировать его уведомлением.
+Уведомление MUST описывать выполненное действие, а не внутренний процесс.
+Ожидание действия MUST NOT представляться его успешным завершением.
+
+#### Scenario: Результат действия иначе легко пропустить
+- **WHEN** действие успешно завершилось, его форма закрылась, а оставшийся экран не подтверждает результат однозначно
+- **THEN** пользователь получает одно краткое уведомление о выполненном действии
+
+#### Scenario: Результат уже очевиден
+- **WHEN** успешное сохранение оставляет на экране явное подтверждение результата
+- **THEN** приложение не добавляет дублирующее уведомление
+
+#### Scenario: Приём действия ещё не означает успех
+- **WHEN** приложение только начало выполнение действия и окончательный результат неизвестен
+- **THEN** оно не показывает уведомление об успешном завершении
+
+### Requirement: Уведомления не мешают работе и не дублируются
+
+Уведомления MUST быть доступны как текст, не полагаться только на цвет и не
+перехватывать клавиатурный фокус. Подтверждение успеха SHALL автоматически
+закрываться и позволять доступное ручное закрытие. Повторная обработка одного
+результата MUST NOT создавать повторное уведомление. Приложение MUST ограничивать
+число одновременно видимых уведомлений и MUST NOT создавать каскад сообщений
+из-за фонового восстановления данных.
+
+#### Scenario: Один результат обработан повторно
+- **WHEN** приложение повторно обрабатывает результат того же пользовательского действия
+- **THEN** пользователь не получает второе уведомление об этом результате
+
+#### Scenario: Работа с клавиатурой продолжается
+- **WHEN** уведомление появляется во время ввода или навигации с клавиатуры
+- **THEN** текущий фокус сохраняется, текст уведомления доступен вспомогательным технологиям, а действие закрытия имеет понятное доступное имя
+
+#### Scenario: Несколько действий завершились рядом по времени
+- **WHEN** несколько различных действий успешно завершаются за короткое время
+- **THEN** уведомления соблюдают конечный предел одновременного показа и не блокируют доступ к содержимому и действиям страницы
+
+### Requirement: Ошибки действий и препятствия доступа остаются понятными
+
+Ошибка ввода MUST показываться у соответствующего поля. При неуспешном
+сохранении приложение MUST сохранять ввод и показывать понятную локальную ошибку
+в контексте действия, не объявляя его успешным. Если продолжение требует входа,
+подключения банка или другого действия пользователя, объяснение и применимое
+действие MUST оставаться доступны в соответствующей области. Исчезающее
+уведомление MUST NOT быть единственным способом сообщить такое препятствие.
+Приложение MUST NOT самостоятельно повторять изменение пользовательских данных
+только потому, что включено автоматическое восстановление чтения.
+
+#### Scenario: Операция не сохранилась
+- **WHEN** пользователь отправил форму операции, а сохранение завершилось ошибкой
+- **THEN** введённые значения остаются в форме вместе с локальной ошибкой, обычное действие сохранения снова доступно и подтверждение успеха отсутствует
+
+#### Scenario: Поле содержит недопустимое значение
+- **WHEN** пользователь пытается отправить форму с недопустимым значением
+- **THEN** ошибка относится к этому полю и не заменяется общим всплывающим уведомлением
+
+#### Scenario: Требуется восстановить доступ
+- **WHEN** приложение подтвердило необходимость входа или восстановления подключения
+- **THEN** соответствующая область предлагает необходимое действие и сохраняет объяснение до устранения препятствия или ухода пользователя
+
+#### Scenario: Ответ на изменение данных не получен
+- **WHEN** соединение прервалось после отправки пользовательского изменения и результат неизвестен
+- **THEN** приложение не объявляет успех и не повторяет изменение автоматически как обычную загрузку данных
@@ -0,0 +1,83 @@
+## MODIFIED Requirements
+
+### Requirement: Состояния и ошибки Portfolio на клиенте
+
+Клиент SHALL загружать Portfolio при открытии защищённого маршрута
+`/accounts/:accountId` и использовать успешный ответ в течение 30 секунд.
+Временные сбои и возвращение к экрану с требующими обновления данными SHALL
+обрабатываться автоматическим восстановлением по `frontend-data-resilience`.
+Клиент MUST NOT предоставлять ручное обновление или повторную загрузку.
+
+При первичной загрузке без успешного результата того же Brokerage Account
+клиент MUST показывать структурный skeleton ожидаемого содержимого, включая
+сводку, без вымышленных сумм. Область MUST иметь доступное обозначение занятости;
+skeleton MUST NOT быть интерактивным или получать фокус. Неуспешное или
+затянувшееся первичное получение SHALL переходить в локальную недоступность
+по `frontend-loading-presentation`, а не в бесконечную загрузку.
+
+Истечение срока свежести MUST NOT скрывать доступный Client Cached Snapshot.
+При обновлении и временной ошибке клиент MUST сохранять данные того же
+Portfolio, включая валютные итоги, без индикации фоновой работы собственного
+чтения, технических предупреждений об этом чтении и уведомлений. Исходное
+`lastSuccessfulAt` и `isStale` MUST сохранять внутренний смысл: их показ или
+скрытие MUST NOT делать сохранённый снимок новым успешным результатом или
+подтверждением текущего доступа. Server-side stale и ошибка клиентского чтения
+MUST NOT подменять друг друга.
+
+Состояние источника из `meta` — время последнего успешного результата, признак
+устаревания и исход последней часовой попытки — не относится к собственному
+чтению клиента: клиент MUST представлять его текстом либо доступно именованным
+элементом по `frontend-data-resilience`, не превращая в действие пользователя.
+
+Клиент MUST показывать штатное empty-состояние только при подтверждённом полном
+результате с пустыми `positions` и `cashBalances`, без вымышленных нулевых карточек.
+Неполный итог MUST NOT выдаваться за окончательный; доступные независимые данные
+MUST сохраняться на экране. При подтверждённом `404` клиент MUST скрыть личный
+Portfolio и предложить возврат к списку счетов. При `TBANK_NOT_CONNECTED` или
+`INVALID_TBANK_TOKEN` он MUST скрыть личные данные и предложить восстановление
+подключения. Эти состояния MUST NOT маскироваться сохранённым снимком или
+вызывать техническую повторную загрузку.
+
+#### Scenario: Показ устаревшего Portfolio
+- **WHEN** клиент получает успешный ответ с `isStale: true` в действующей границе доступа
+- **THEN** клиент показывает позиции, остатки и доступные валютные итоги и обозначает устаревание источника текстом либо доступно именованным элементом, без ручного обновления
+
+#### Scenario: Неуспешная последняя попытка сохраняет Portfolio
+- **WHEN** клиент получает полный Portfolio и `meta` с неуспехом последней часовой попытки
+- **THEN** он сохраняет Portfolio и исходное время видимыми и отдельно показывает текстовое либо доступно именованное предупреждение о неуспехе попытки, не предлагая ручной повтор
+
+#### Scenario: Недоступный счёт на клиенте
+- **WHEN** клиент получает подтверждённый `404` текущего Portfolio
+- **THEN** клиент не показывает личный Portfolio, включая ранее сохранённый, и предлагает вернуться к списку Brokerage Account без действия повтора
+
+#### Scenario: Первичная загрузка Portfolio
+- **WHEN** клиент ожидает Portfolio этого Brokerage Account без ранее полученного успешного ответа
+- **THEN** он показывает структурный skeleton, включая место сводки, с доступным обозначением загрузки, без вымышленных или нулевых сумм и без фокусируемых placeholders
+
+#### Scenario: Обновление после истечения срока свежести
+- **WHEN** срок свежести показанного Portfolio истёк и началось фоновое обновление данных того же Brokerage Account
+- **THEN** клиент сохраняет прежние валютные итоги без индикации обновления и не заменяет доступный состав и сводку skeleton-состоянием
+
+#### Scenario: Ошибка обновления после успешного ответа
+- **WHEN** клиент уже показывает Client Cached Snapshot Portfolio, а обновление этих же данных завершается временной ошибкой
+- **THEN** клиент сохраняет данные и суммы без предупреждения и действия повтора; ошибка не делает снимок свежим и не изменяет `isStale`
+
+#### Scenario: Ошибка клиентского обновления при server-side stale
+- **WHEN** клиент показывает Portfolio с `isStale: true`, а фоновое обновление этого же Portfolio завершается временной ошибкой
+- **THEN** прежние суммы остаются видимыми без технических предупреждений и ручных действий, сохраняя различие внутренних состояний
+
+#### Scenario: Повторное обновление успешно
+- **WHEN** после временной ошибки автоматическое восстановление получает успешный Portfolio Snapshot
+- **THEN** до ответа прежние суммы остаются видимыми, затем клиент показывает новый результат без уведомления об обновлении и без переноса пользовательского фокуса
+
+#### Scenario: Штатный пустой Portfolio на клиенте
+- **WHEN** успешно полученный полный Portfolio содержит пустые `positions` и `cashBalances`
+- **THEN** клиент показывает существующее empty-состояние без валютных карточек с вымышленными нулевыми итогами
+
+#### Scenario: Первичный Portfolio пока недоступен
+- **WHEN** данных Portfolio нет, а первичное получение не удалось или превысило ограниченное время ожидания
+- **THEN** клиент показывает нейтральную недоступность без кнопки повтора и автоматически заменяет её содержимым после успешного восстановления
+
+#### Scenario: Требуется восстановить подключение
+- **WHEN** клиент получает `TBANK_NOT_CONNECTED` или `INVALID_TBANK_TOKEN` при наличии сохранённого личного Portfolio
+- **THEN** личные данные скрываются, а клиент предлагает необходимое действие подключения без технической повторной загрузки
@@ -0,0 +1,45 @@
+## MODIFIED Requirements
+
+### Requirement: Управление подключением в настройках
+
+Клиент SHALL показывать в настройках статус T-Bank connection, текст о
+необходимости read-only T-Bank Invest token, поле token и действие подключения
+либо замены. Для существующего подключения клиент MUST показывать действие
+удаления с modal-подтверждением. Во время создания, замены или удаления все
+действия секции подключения и действия modal MUST быть отключены. После
+успешного создания или замены клиент MUST очистить поле token и обновить статус;
+при ошибке token MUST остаться в поле.
+
+Временный сбой чтения статуса SHALL восстанавливаться автоматически без кнопки
+повтора и технического предупреждения. Пока первый статус неизвестен, клиент
+MUST NOT показывать форму как подтверждённое отсутствие подключения: после
+первичного ожидания SHALL отображаться нейтральная недоступность секции. Если
+статус уже известен для текущей сессии, временный сбой его фонового чтения MUST
+NOT скрывать доступную секцию или очищать ввод. Подтверждённое изменение
+сессии или доступа MUST NOT маскироваться старым статусом.
+
+Ошибки создания, замены и удаления MUST оставаться локальными, сохранять ввод
+и возвращать применимые действия формы. Эти действия MUST NOT повторяться
+автоматически как чтение статуса. Подтверждения успеха SHALL следовать
+`frontend-user-feedback`: очевидное изменение статуса не требует дублирующего
+уведомления, неочевидный результат получает одно краткое подтверждение.
+
+#### Scenario: Пользователь подтверждает удаление
+- **WHEN** User подтверждает удаление в modal
+- **THEN** клиент блокирует действия секции до результата и после успешного ответа показывает состояние без подключения
+
+#### Scenario: Ошибка загрузки статуса
+- **WHEN** клиент временно не может получить статус подключения
+- **THEN** он автоматически восстанавливает чтение, сохраняет известный статус текущей сессии либо показывает нейтральную недоступность после первичного ожидания без формы и кнопки повтора
+
+#### Scenario: Ошибка проверки token в клиенте
+- **WHEN** создание или замена получает `INVALID_TBANK_TOKEN` либо `TBANK_UNAVAILABLE`
+- **THEN** клиент показывает соответственно локализованное сообщение о token и правах либо о временной недоступности T-Bank в контексте формы, возвращает интерактивность и сохраняет введённый token
+
+#### Scenario: Фоновое чтение не сбрасывает ввод
+- **WHEN** пользователь редактирует token в доступной секции, а фоновое чтение статуса временно не удалось
+- **THEN** ввод и доступная секция сохраняются без технического предупреждения или уведомления
+
+#### Scenario: Удаление не удалось
+- **WHEN** пользователь подтвердил удаление подключения, а действие завершилось ошибкой
+- **THEN** клиент не показывает успех, сохраняет известный статус и локальную ошибку, возвращает применимые действия и не повторяет удаление автоматически
@@ -0,0 +1,159 @@
+# Implementation tasks
+
+Основание: согласованные Delta Specs и [Design](design.md), включая inline
+UI/UX package `quiet-user-feedback-ui-v1` и Solution Assessment.
+
+Задачи выполняются по порядку групп и пунктов. Каждая задача имеет одного
+владельца репозитория; технические проверки выполняет implementer. Проверки
+сети используют synthetic fixtures и существующий MSW, а не реальный T-Bank.
+Перед Node-командами в каждом репозитории выполняется `nvm use --silent`.
+Указанные ниже проверки — план, а не свидетельство выполненной реализации.
+
+Перед изменениями сохраняются чужие staged/unstaged/new files, в частности
+перенос PortfolioStructure. База требований сверяется по Migration Plan Design:
+изменение порядка интеграции `persist-tbank-data` требует согласования
+затронутых artifacts, а не молчаливого перезаписывания active change.
+Recovery и удаление ручных controls поставляются вместе. Backend и workspace
+не получают implementation tasks: они не входят в affected Delivery Map.
+
+## 1. Принятые решения и зависимости
+
+- [x] 1.1 [frontend] Применить Solution Assessment: оставить TanStack Query и существующих resource/screen owners, добавить exact `@mantine/notifications@9.6.1` с согласованным lockfile без второго query runtime или toast framework.
+  - **Covers:** `N/A` — dependency preparation не вводит отдельного пользовательского поведения; реализует выбранные средства из Design §1 и §6 до custom recovery work.
+  - **Verification:** `npm ci`; `npm ls @mantine/core @mantine/hooks @mantine/notifications react react-dom`; сверить exact versions, peer compatibility и отсутствие посторонних dependency changes.
+
+## 2. Ограниченное восстановление чтения
+
+- [x] 2.1 [frontend] В существующем `shared/api` реализовать классификацию временных GET failures, 15-секундный deadline с отменой чтения тела и до двух повторов с паузами 1/2 секунды; исключить auth endpoints, mutations, access/domain errors и отмену.
+  - **Covers:** `frontend-data-resilience` — `Временные сбои чтения восстанавливаются автоматически`; `frontend-user-feedback` — `Ошибки действий и препятствия доступа остаются понятными`.
+  - **Verification:** MSW-проверки через public client/query interface: recovery после network/timeout/503, конечное число запросов, прерванное чтение тела, отсутствие retries для 401/403/404/409 и malformed result, поведение 429 и серверной отсрочки по Design; `npm run test:run -- src/shared/api`.
+
+- [x] 2.2 [frontend] Подключить read policy к authenticated query hooks и `useResourceQuery`, сохранив одну generated cache identity, независимые ordinary/observe режимы и существующие session/access fences; убрать локальные запреты retry только там, где они заменяются принятой политикой.
+  - **Covers:** `frontend-data-resilience` — `Client Cached Snapshot остаётся доступным при обновлении Accounts и Portfolio`; `frontend-data-resilience` — `Временные сбои чтения восстанавливаются автоматически`.
+  - **Verification:** Расширить resource lifecycle MSW-сценарии: cached snapshot при ошибке, `data: null` при HTTP success, ordinary GET после observe, unmount/cancel и late response после logout/connection replacement; `npm run test:run -- src/shared/api src/features/tbank-connection/model/connection-boundary`.
+
+- [x] 2.3 [frontend] Перевести `useScreenSync` на ограниченное восстановление failed/cancelled missing/stale источников обычным GET: две дополнительные source attempts с паузами 5/15 секунд, бюджет на текущую выборку и отсутствие автоматического force POST.
+  - **Covers:** `frontend-data-resilience` — `Временные сбои чтения восстанавливаются автоматически`; `frontend-data-resilience` — `Неполный результат не выдаётся за окончательный`.
+  - **Verification:** MSW + управляемое время: failed source при HTTP 200, новая work ID без сброса бюджета, исчерпание серии, fresh complete после неудачного force, permanent unavailableReason; проверить число ordinary GET и отсутствие POST `/api/v1/tbank-sync`; `npm run test:run -- src/features/tbank-connection/model`.
+
+- [x] 2.4 [frontend] Согласовать status observation и заключительное observe-чтение с in-flight запросами, сохранив интервал 1 секунда только для running work; различить status ID not found и подтверждённый отказ доступа к ресурсу.
+  - **Covers:** `frontend-data-resilience` — `Временные сбои чтения восстанавливаются автоматически`; `frontend-data-resilience` — `Client Cached Snapshot остаётся доступным при обновлении Accounts и Portfolio`.
+  - **Verification:** MSW-сценарии: медленное observe не отменяется каждым tick, terminal status не теряет заключительное чтение, HTTP/status failure не запускает force sync, `404` work ID перечитывает ресурс, access loss очищает личный snapshot; `npm run test:run -- src/features/tbank-connection/model/screen-sync.test.tsx src/shared/api/resource-query.test.tsx`.
+
+- [x] 2.5 [frontend] Подключить единый lifecycle recovery на focus/reconnect и смену выборки: обычные reads используют штатную Query policy, инвестиционные — screen owner; отменять неактуальные timers и не дублировать восстановление при совпадении событий.
+  - **Covers:** `frontend-data-resilience` — `Временные сбои чтения восстанавливаются автоматически`; `frontend-data-resilience` — `Client Cached Snapshot остаётся доступным при обновлении Accounts и Portfolio`.
+  - **Verification:** Через Query focus/online managers и MSW проверить fresh/stale/missing results, offline/hidden pause, одновременный reconnect/focus, повторное открытие, переход на другой счёт/период и уход последнего consumer; `npm run test:run -- src/shared/api src/features/tbank-connection/model`.
+
+## 3. Состояния ожидания и доступного результата
+
+- [x] 3.1 [frontend] Реализовать общую presentation-only модель ограниченного первичного ожидания в `shared/lib`: 10-секундный budget, устойчивый unavailable latch для identity области и автоматический переход к результату; применить её к существующим loading/state presentation без второго кэша.
+  - **Covers:** `frontend-loading-presentation` — `Первичное ожидание не становится бесконечной загрузкой`; `frontend-loading-presentation` — `Контекстная индикация действий и фонового обновления`.
+  - **Verification:** Минимальная runnable проверка собственного state transition: skeleton → timeout/error unavailable → loaded, отсутствие мигания при retry, сброс только при новой выборке, cleanup и доступное busy-состояние; `npm run test:run -- src/shared/lib` и `npm run typecheck`.
+
+- [x] 3.2 [frontend] В общих investment section models разделить readiness, полноту и access failure: успешные пустые данные не теряются, missing/partial не становятся нулевым итогом, а технические metadata остаются у владельца данных.
+  - **Covers:** `frontend-data-resilience` — `Неполный результат не выдаётся за окончательный`; `frontend-ui-resilience` — `Ожидаемые finance states не становятся route failures`.
+  - **Verification:** Проверки через потребляющие views: `null` против полного `[]`, partial rows против полного empty, недоступный total/comparison, independent ready section и access failure при cached content; `npm run test:run -- src/features/instrument-details src/pages/account-income`.
+
+## 4. Инвестиционные экраны без технических controls
+
+- [x] 4.1 [frontend] Перевести Accounts и AccountPage, включая «Все счета», на новые состояния: убрать даты получения, refresh/retry и технические предупреждения, сохранить валютные итоги, доступные snapshots, контекст и предметную навигацию.
+  - **Covers:** `brokerage-accounts` — `Экран списка брокерских счетов`; `brokerage-accounts` — `Клиентские состояния ошибки списка счетов`; `portfolio-view` — `Состояния и ошибки Portfolio на клиенте`; `frontend-data-resilience` — `Client Cached Snapshot остаётся доступным при обновлении Accounts и Portfolio`; `frontend-ui-resilience` — `Ожидаемые finance states не становятся route failures`.
+  - **Verification:** RTL/MSW: initial/loaded/empty/partial/unavailable, quiet refetch failure, сохранение раскрытий и focus, отсутствие вымышленных нулей, `404` и invalid token скрывают снимок; `npm run test:run -- src/pages/accounts src/pages/account src/app/routes/AppRoutes/AllAccounts.test.tsx`.
+
+- [x] 4.2 [frontend] Перевести полный журнал и recent operations на локальное тихое восстановление; сохранить применённые фильтры, cursor navigation, даты и смысл строк, не подменять новую страницу прежней.
+  - **Covers:** `brokerage-account-ledger` — `Account overview includes recent ledger events`; `brokerage-account-ledger` — `Журнал восстанавливает чтение без ручного обновления`.
+  - **Verification:** RTL/MSW: background failure с прежними записями, missing новой страницы, отсутствие false empty и retry, локальный сбой preview не скрывает Portfolio; `npm run test:run -- src/pages/account-operations src/pages/account`.
+
+- [x] 4.3 [frontend] Перевести страницу будущих событий и preview на сохранение доступного результата и нейтральную локальную недоступность; убрать технические статусы, сохранив даты и ограничения финансового прогноза.
+  - **Covers:** `brokerage-account-upcoming-events` — `Account page presents an upcoming events list`; `brokerage-account-upcoming-events` — `Account overview includes upcoming events`.
+  - **Verification:** RTL/MSW: cached events при временной ошибке, неизвестный результат против полного empty, offer без суммы, потеря доступа и независимость preview; `npm run test:run -- src/pages/account-events src/entities/brokerage-event src/pages/account`.
+
+- [x] 4.4 [frontend] Перевести доход и current-month summary на тихое обновление; оставить независимые готовые результаты, недоступные comparisons без нулевой базы и неизменный пользовательский черновик периода.
+  - **Covers:** `brokerage-account-income-analytics` — `Realized analytics never presents an incomplete result as complete`; `brokerage-account-income-analytics` — `Account overview has an independent current-month income summary`; `brokerage-account-income-analytics` — `Доход обновляется без технических сообщений`; `frontend-data-resilience` — `Неполный результат не выдаётся за окончательный`.
+  - **Verification:** RTL/MSW: полный старый результат при временном сбое, missing/partial текущего периода, готовый доход с недоступным сравнением, смена периода без переименования прежних сумм, сохранение черновика; `npm run test:run -- src/pages/account-income src/pages/account`.
+
+- [x] 4.5 [frontend] Убрать refresh/retry из поиска акций и облигаций, связав VM с автоматическим recovery и ожиданием текущего debounced query; сохранить фильтры и отсутствие подмены результата прежним запросом.
+  - **Covers:** `frontend-user-feedback` — `Чтение данных не требует внимания к техническим состояниям`; `frontend-loading-presentation` — `Первичное ожидание не становится бесконечной загрузкой`.
+  - **Verification:** RTL/MSW: смена query во время запроса, delayed/failed поиск с последующим восстановлением, отсутствие false no-results и технических controls; `npm run test:run -- src/features/instrument-search src/pages/stocks src/pages/bonds`.
+
+- [x] 4.6 [frontend] Перевести детали акции/облигации и их секции на readiness текущей выборки: график, личные позиции, история, сведения и выплаты сохраняют доступное содержимое без технических дат и действий.
+  - **Covers:** `frontend-user-feedback` — `Чтение данных не требует внимания к техническим состояниям`; `frontend-data-resilience` — `Неполный результат не выдаётся за окончательный`; `frontend-ui-resilience` — `Ожидаемые finance states не становятся route failures`.
+  - **Verification:** RTL/MSW: independent sections, новый диапазон свечей и instrument ID не показывают прежний результат как новый, partial history не является полной; `npm run test:run -- src/features/instrument-details src/pages/stock src/pages/bond`.
+
+## 5. Карты, формы и настройки подключения
+
+- [x] 5.1 [frontend] Перевести CardsPage, CardPage и BankSummary на тихое чтение, ограниченное ожидание и сохранение текущей выборки; удалить placeholder прежней страницы при переходе к другой странице банковских операций.
+  - **Covers:** `frontend-user-feedback` — `Чтение данных не требует внимания к техническим состояниям`; `frontend-data-resilience` — `Client Cached Snapshot остаётся доступным при обновлении Accounts и Portfolio`; `frontend-loading-presentation` — `Первичное ожидание не становится бесконечной загрузкой`.
+  - **Verification:** RTL/MSW: карты/summary/history при refetch failure, `page` и период меняются без подмены данных, полный empty отличается от missing, формы не размонтируются из-за фоновой ошибки; `npm run test:run -- src/pages/cards src/pages/card/ui/CardPage src/entities/bank-card/api`.
+
+- [x] 5.2 [frontend] Сохранить ввод и предметные действия BankCardForm и CategoryManager, заменив техническое перечитывание автоматической загрузкой; актуальную версию после конфликта принимать только явно, не повторяя запись.
+  - **Covers:** `frontend-user-feedback` — `Ошибки действий и препятствия доступа остаются понятными`; `frontend-loading-presentation` — `Контекстная индикация действий и фонового обновления`.
+  - **Verification:** RTL/MSW: field errors, сохранённый ввод при network failure, version conflict → автоматическое чтение → явное принятие версии, доступная отмена при unavailable, отсутствие второго mutation request; `npm run test:run -- src/entities/bank-card/ui`.
+
+- [x] 5.3 [frontend] Перевести чтение категорий, исходной покупки и версий OperationForm/DeleteOperation на автоматическое восстановление; сохранить intent ID, refund constraints, явное подтверждение версии и недопущение повторной финансовой записи.
+  - **Covers:** `frontend-user-feedback` — `Ошибки действий и препятствия доступа остаются понятными`; `frontend-loading-presentation` — `Контекстная индикация действий и фонового обновления`.
+  - **Verification:** RTL/MSW: сбой зависимого GET без потери ввода, отсутствие ложного empty для расходов, конфликт удаления/правки, network loss после submit без auto-resubmit, сохранность version/intent при ручной повторной отправке; `npm run test:run -- src/pages/card/ui/OperationForm src/pages/card/ui/DeleteOperation src/entities/bank-card/api/banking.test.tsx`.
+
+- [x] 5.4 [frontend] Перевести чтение T-Bank connection status на тихое восстановление: не показывать форму до первого известного статуса, сохранять уже открытую секцию и token при временном GET failure, оставить явные локальные ошибки mutations.
+  - **Covers:** `tbank-connection` — `Управление подключением в настройках`; `frontend-user-feedback` — `Ошибки действий и препятствия доступа остаются понятными`; `frontend-ui-resilience` — `Ожидаемые finance states не становятся route failures`.
+  - **Verification:** RTL/MSW: initial unavailable → loaded, сохранность ввода при фоновом сбое, single mutation на submit/delete, ошибки token и удаления, новая cache boundary только после успешной mutation; `npm run test:run -- src/features/tbank-connection`.
+
+## 6. Редкие подтверждения действий
+
+- [x] 6.1 [frontend] Подключить один Mantine Notifications host с общей темой, styles и i18n: limit 2, autoClose 4000 ms, desktop/mobile positions, доступное закрытие, reduced motion и очистка очереди при смене/завершении сессии.
+  - **Covers:** `frontend-user-feedback` — `Уведомления не мешают работе и не дублируются`.
+  - **Verification:** Проверить application-owned cleanup при logout/смене сессии через RTL; выполнить `npm run typecheck`; конфигурацию third-party limit/timer не дублировать unit-тестами библиотеки, доступность и размещение проверить в задаче 7.3.
+
+- [x] 6.2 [frontend] В action VMs карт, операций и категорий отделить успех записи от последующего чтения и реализовать однократное подтверждение по таблице Design: видимый результат без toast, неочевидный — краткое сообщение с action ID и ограниченным ожиданием подтверждения.
+  - **Covers:** `frontend-user-feedback` — `Краткое уведомление подтверждает неочевидный результат действия`; `frontend-user-feedback` — `Уведомления не мешают работе и не дублируются`; `frontend-user-feedback` — `Ошибки действий и препятствия доступа остаются понятными`.
+  - **Verification:** RTL/MSW: сохранённая запись внутри/вне видимой выборки, удаление видимой/невидимой записи, успешная запись с неуспешным GET, 10-секундный предел подтверждения, повторный callback того же action ID и отдельное следующее действие; `npm run test:run -- src/entities/bank-card/ui src/pages/card src/pages/cards`.
+
+- [x] 6.3 [frontend] В VM подключения добавить одно подтверждение успешной замены token при неизменном видимом статусе; создание/удаление с очевидным изменением статуса и все фоновые чтения оставить без toast.
+  - **Covers:** `tbank-connection` — `Управление подключением в настройках`; `frontend-user-feedback` — `Краткое уведомление подтверждает неочевидный результат действия`; `frontend-user-feedback` — `Чтение данных не требует внимания к техническим состояниям`.
+  - **Verification:** RTL/MSW: create/delete без дублирующего подтверждения, replace с единственным toast, failure без success, background recovery без notifications, сообщение без token; `npm run test:run -- src/features/tbank-connection/ui`.
+
+## 7. Завершение frontend и UI-проверки
+
+- [x] 7.1 [frontend] После миграции consumers удалить InvestmentRefreshState, SourceSyncStatus, неиспользуемые props/exports/строки и их устаревшие stories; проверить оставшиеся технические actions во всём scope без удаления предметных form/access controls.
+  - **Covers:** `frontend-user-feedback` — `Чтение данных не требует внимания к техническим состояниям`; `frontend-loading-presentation` — `Контекстная индикация действий и фонового обновления`.
+  - **Verification:** Проверить callers и i18n keys, отсутствие видимых/иконных/tooltip/live-region замен удалённых статусов; `npm run knip`; `npm run deps`; `npm run test:run -- src/test/storybook.test.tsx`; убедиться, что внутренние metadata и серверный контракт не удалены.
+
+- [x] 7.2 [frontend] Обновить UI/data/testing conventions и значимые presentation stories под UI package v1: тихий loaded, нейтральный unavailable, partial без ложного итога и редкое подтверждение; сохранить изоляцию Storybook от application API/auth/query.
+  - **Covers:** `N/A` — conventions и каталог закрепляют уже утверждённую архитектуру и UI-пакет, не вводя отдельного поведения; необходимы для согласованной frontend delivery из Design.
+  - **Verification:** Сверить локальные инструкции с новыми retry/focus policies, примеры и ссылки; `npm run deps:storybook`; `npm run build:catalog`; проверить достижимость stories и отсутствие устаревшего обещания ручного retry.
+
+- [x] 7.3 [frontend] Выполнить implementation-owned browser review состояний и interactions UI package v1 на 320, 768 и 1440 px: страницы чтения, partial/unavailable, формы, notification host и восстановление контекста.
+  - **Covers:** `frontend-user-feedback` — `Уведомления не мешают работе и не дублируются`; `frontend-user-feedback` — `Чтение данных не требует внимания к техническим состояниям`; `frontend-loading-presentation` — `Первичное ожидание не становится бесконечной загрузкой`; `frontend-data-resilience` — `Client Cached Snapshot остаётся доступным при обновлении Accounts и Portfolio`.
+  - **Verification:** В браузере проверить Tab/focus, modal trap и доступное закрытие, busy/live announcements, reduced motion, длинный текст, safe area, отсутствие перекрытых controls/горизонтального скролла, сохранение scroll и раскрытий; presentation states воспроизвести synthetic stories, runtime lifecycle — приложением и RTL/MSW, без browser MSW worker.
+
+- [x] 7.4 [frontend] Завершить Boy Scout review затронутого diff и выполнить полный canonical frontend gate после всех production, test, dependency и convention изменений.
+  - **Covers:** `N/A` — финальная проверка frontend delivery по Design, без нового observable behavior; targeted tests не заменяют canonical gate.
+  - **Verification:** `npm ci` и `npm run verify`; отдельно сверить сохранность чужого PortfolioStructure diff, отсутствие generated/OpenAPI drift, дублированных query owners и global toast interception; записать фактические результаты и ограничения.
+
+## 8. As-built документация
+
+- [x] 8.1 [docs] После frontend delivery оформить принятое решение о тихом чтении и редких уведомлениях в существующем журнале ADR, с причинами, альтернативами, последствиями и связью с предыдущим решением о background sync.
+  - **Covers:** `N/A` — ADR фиксирует rationale уже утверждённого Design и выполненной delivery, а не создаёт новую behavioral spec; docs отмечен affected в Delivery Map.
+  - **Verification:** Проверить номер по актуальному `adr/README.md`, самостоятельность текста, связь с ADR 017 и сохранность его исторического содержания; новый ADR описывает реализованный механизм и не обещает непоставленное поведение.
+
+- [x] 8.2 [docs] Обновить объяснения UI resilience, data freshness и visual states, убрав описание обязательных предупреждений/ручного обновления и объяснив ограниченное автоматическое восстановление, первичную недоступность и сохранение ошибок действий.
+  - **Covers:** `N/A` — as-built тематические страницы объясняют согласованные требования и технические решения; это documentation outcome Design, без самостоятельного нового поведения.
+  - **Verification:** Сверить `architecture/cross-cutting/ui-resilience.md`, `architecture/cross-cutting/data-freshness.md` и `design/overview.md` с реализованным flow, исключить противоречия между freshness, completeness и UI; проверить локальные ссылки и предметные даты.
+
+- [x] 8.3 [docs] Согласовать затронутые предметные описания счетов, портфеля, операций, дохода, событий, инструментов и карт с тихим UI; обновить только фрагменты, описывающие изменённые состояния и recovery.
+  - **Covers:** `N/A` — предметная документация устраняет устаревшие инструкции пользователю после frontend delivery; область и поведение уже заданы Design и Delta Specs.
+  - **Verification:** Пройти маршруты README к затронутым domains; сверить упоминания refresh/retry, времени получения и ошибок с приложением, сохранив полезные финансовые пояснения, ограничения прогнозов и входящие ссылки.
+
+- [x] 8.4 [docs] Выполнить semantic/link review обновлённой документации и canonical docs gate с учётом новых файлов.
+  - **Covers:** `N/A` — проверка документационной delivery из Design; не является новой пользовательской capability.
+  - **Verification:** `npm ci` при отсутствии установленных dependencies, затем `npm run verify`; проверить ADR index, новые локальные anchors и пользовательские маршруты чтения; если затронуты диаграммы, отдельно проверить их рендер доступным средством.
+
+## 9. Canonical specifications и итоговые gates
+
+- [x] 9.1 [specs] После подтверждения реализации перенести согласованные quiet Delta Requirements в canonical specs через OpenSpec sync workflow и добавить `frontend-user-feedback` в AI_INDEX; учесть порядок пересечения с persist по Design, сохраняя несвязанные требования.
+  - **Covers:** `N/A` — canonical publication не вводит поведения сверх утверждённых Delta Specs; реализует обязательный specs outcome Delivery Map и сохраняет единственный источник требований.
+  - **Verification:** Сравнить перенесённые Requirement blocks со всеми десятью delta paths, проверить отсутствие восстановления старых UI/retry obligations и потери несвязанных scenarios; проверить новый target в AI_INDEX; при изменившейся базе вернуть затронутые artifacts на согласование до переноса.
+
+- [x] 9.2 [specs] Выполнить canonical specs gate, native schema/change/spec validation и итоговую сверку трассировки с реально выполненными задачами.
+  - **Covers:** `N/A` — проверка полноты и согласованности specs delivery, обязательная по Design и местным правилам; нового observable behavior нет.
+  - **Verification:** `npm run verify`; `openspec schema validate wealth-ledger-sdd --verbose`; `openspec validate quiet-user-feedback --type change --strict --store wealth-ledger-specs`; `openspec validate --specs --strict --store wealth-ledger-specs`; проверить новые файлы и их diff отдельно, а checklist отмечать только по наблюдённым результатам.
@@ -0,0 +1,2 @@
+schema: wealth-ledger-sdd-lab
+created: 2026-10-29
@@ -0,0 +1,216 @@
+# Engineering Design
+
+## Inputs
+
+- Change: `wealth-ledger-specs`, `openspec/changes/group-account-rows-by-instrument/`.
+- Утверждённые входы: `proposal.md`, `ux-design.md`, `specs/brokerage-account-ledger/spec.md`, `specs/brokerage-account-upcoming-events/spec.md`, `specs/brokerage-account-income-analytics/spec.md` относительно change.
+- Issue: `WealthLedger/main#47`; рабочая ветка specs: `feature/47-group-rows-by-instrument`. При различии формулировки ISIN в Issue и утверждённых входов используется identity Instrument из входов.
+- Проверенные источники реализации: `frontend/src/shared/api/generated/schema.d.ts`, `frontend/AGENTS.md`, `frontend/.ai/architecture.md`, conventions `engineering.md`, `typescript-react.md`, `ui.md`, `data.md`, `testing.md`.
+- Ниже пути `src/` и `packages/` относятся к `frontend/`; этот документ не изменяет код. UX остаётся владельцем flows, визуальных решений и a11y.
+
+## Architecture Drivers
+
+- `brokerage-account-ledger` — `All-accounts ledger groups same-day entries of one instrument`: точный ключ, минимум две записи, отсутствие изменений single-account.
+- `brokerage-account-ledger` — `All-accounts ledger group shows each entry and an exact total`: сохранение каждого денежного движения, точность и запрет ложного итога.
+- `brokerage-account-ledger` — `All-accounts ledger grouping preserves order and limits`: серверный порядок и только показанные записи.
+- `brokerage-account-upcoming-events` — `All-accounts upcoming events group same-day events of one instrument`: дата вместе с `dateKind`, identity и точный тип.
+- `brokerage-account-upcoming-events` — `All-accounts upcoming event group shows each event and a forecast total`: неизвестный прогноз и неподтверждённая полнота не превращаются в ноль.
+- `brokerage-account-upcoming-events` — `All-accounts upcoming event grouping preserves order and limits`: ограничение превью до группировки.
+- `brokerage-account-income-analytics` — `Income payments remain traceable to exact Ledger Entries`: визуальная агрегация не заменяет записи или серверные аналитические итоги.
+- Ограничения: существующие API и query lifecycle, локальный FSD profile, без новых runtime dependencies и без хранения производного состояния.
+
+## Technical Goals / Non-Goals
+
+- Реализовать одну чистую операцию группировки и переиспользуемую точную decimal-арифметику; предметные ключи остаются у владельцев сущностей/страницы.
+- Сохранить число исходных записей, знаки, валюты, порядок, provenance и прежние ветки одиночных карточек.
+- Не менять backend, фильтры, cursor protocol, аналитические totals, доступ, синхронизацию, URL или часовые пояса текущего отображения.
+- Не вводить межстраничное накопление, поиск identity через сеть, валютную конвертацию, новый feature/widget или универсальный aggregation framework.
+
+## Implementation Impact Map
+
+| Area | Affected | Outcome or N/A reason |
+| --- | --- | --- |
+| main | Нет | Issue уже существует; workspace и tooling не меняются. |
+| frontend | Да | Shared grouping/decimal, entity presentation, четыре page slices и EntryCard workspace package. |
+| backend | Нет | DTO и envelope достаточны; endpoints и вычисления сервера остаются прежними. |
+| docs | Да, после реализации | Уточнить AS-IS представление списков и границу клиентских итогов; точные страницы ниже. |
+| specs | Да | Этот design; утверждённые proposal/specs/UX не переписываются. |
+
+## Decisions
+
+### D1. Одна чистая группировка, предметные ключи снаружи
+
+Драйвер: `brokerage-account-ledger` — `All-accounts ledger grouping preserves order and limits`.
+В `src/shared/lib/group-items.ts` разместить `groupItems<T>(items: readonly T[], keyOf: (item: T) => string | null)`.
+Результат — discriminated union: single с исходным item либо group с key и исходными items (не менее двух).
+Функция не знает DTO, денег, счетов, React и режима маршрута; `null` всегда оставляет самостоятельный single.
+Map сохраняет позицию первого появления ключа; последующие совпадения добавляются к его записям без сортировки.
+Вход не мутируется; ссылки на записи сохраняются, записи одного счёта не схлопываются. Сложность O(n), память O(n).
+Три независимых реализации отклонены из-за дублирования инварианта; framework с reducers/plugins — избыточен.
+
+### D2. Ключи соответствуют реально отображаемому дню
+
+Драйверы: `brokerage-account-ledger` — `All-accounts ledger groups same-day entries of one instrument`; `brokerage-account-upcoming-events` — `All-accounts upcoming events group same-day events of one instrument`.
+
+| Список | День | Identity: первое непустое поле | Тип и дополнительные поля |
+| --- | --- | --- | --- |
+| Журнал и последние операции | Локальный календарный день `occurredAt` в timezone браузера | `instrumentUid`, затем `figi` | Исходный `type` без нормализации |
+| Выплаты | Тот же локальный день `occurredAt` | `instrumentUid`, затем `figi` | Исходный `type` |
+| События и их превью | `date`, отображаемая через `formatDate` в UTC | `instrumentUid`, затем `figi`, затем `isin` | Исходный `type` и `dateKind` |
+
+`LedgerEntryRow` передаёт `formatSnapshotTime(occurredAt)` и в обычную карточку, и в executed PayoutCard; formatter содержит дату и время без `timeZone` (`src/shared/lib/display.ts:132–139`).
+Добавить рядом day-only formatter с тем же timezone браузера: использовать календарные части, не полную строку с временем и не `occurredAt.slice(0, 10)`.
+`formatDate` уже фиксирует UTC (`display.ts:19–38`); для date-only события его ISO-дата достаточна как ключ.
+`moscowDate` из `src/shared/lib/calendar.ts` обслуживает периоды/границы фильтров; не подменяет день отображения выплат.
+Identity кодируется парой namespace/value; весь ключ — сериализованный tuple дня, identity, type и, для события, dateKind.
+`account.id`, валюта, category, ticker, description и logo не входят в ключ. Пустая identity возвращает null.
+`IncomeAnalyticsEntryDto.instrumentKey` — opaque membership аналитики, не доказанная identity Instrument: не использовать как fallback и не парсить.
+Это подтверждает existing test `AccountIncomePage.test.tsx`, «opaque membership rather than instrument identity»: один instrumentKey допускает разные UID.
+Сопоставление UID одной записи с FIGI другой через словарь aliases не вводится: нет авторитетного локального соответствия; одинаковый ticker не доказывает одну бумагу.
+
+### D3. Точное сложение и отдельная политика допустимости итога
+
+Драйверы: `brokerage-account-ledger` — `All-accounts ledger group shows each entry and an exact total`; `brokerage-account-income-analytics` — `Income payments remain traceable to exact Ledger Entries`.
+В `shared/lib` сейчас есть string-formatting, проверка нуля и BigInt-округление, но нет экспортированного exact add.
+Однако `src/pages/account/model/positions.ts:41–64,170–179` уже содержит decimal parse/serialize и точную сумму scaled BigInt.
+Выделить только эту арифметику в `src/shared/lib/decimal.ts`, перевести существующего owner на неё; расчёт процентов и округление портфеля оставить локальными.
+Публичная минимальная операция `sumDecimalStrings(values)` возвращает decimal string; внутри выравниваются scales и складываются signed BigInt, без Number/parseFloat и без округления.
+Предусмотреть пустой ввод → `"0"`, канонический ноль без минуса, дробную часть любой поддержанной контрактом длины; не вводить библиотеку decimal.
+Чистая `sumMoneyByCurrency` в shared принимает структурные `{ currency, value } | null`, возвращает список сумм либо недоступность; Map сохраняет первое появление валюты.
+Если хотя бы один исходный amount отсутствует (а для журнала и «Выплат» также если он численно равен нулю), скрывается весь итог, а не только проблемная валюта. Некорректная decimal-строка также не превращается в ноль.
+Только `meta?.completeness === "complete"` разрешает показ результата; отсутствие meta и `incomplete` запрещают его. Это predicate владельца ресурса, не арифметики.
+Для ledger/income источник — только `payment`, не price/quantity/commission; для событий — `projectedAmount`, null означает неизвестный прогноз, включая offer.
+Компенсация ненулевых слагаемых до нуля допустима: `+100 + (-100)` даёт видимый нейтральный ноль, в отличие от нулевого исходного amount.
+Финальное представление — `formatMoney` с `withSign: true`, без `withRoundedCents`; серверные `totalsByCurrency`, buckets и instruments не пересчитываются.
+
+### D4. Граница группировки — текущая выборка, не query cache
+
+Драйверы: `brokerage-account-ledger` — `All-accounts ledger grouping preserves order and limits`; `brokerage-account-upcoming-events` — `All-accounts upcoming event grouping preserves order and limits`.
+`src/entities/broker-operation/model/useBrokerageOperationHistory.ts` хранит стек cursors и читает одну страницу: `onNext` добавляет cursor, `onPrevious` снимает его.
+Это previous/next pagination, не infinite append: группировать только текущие `operations.data.items`; не объединять cached pages.
+Тем самым «собирается только из показанных записей» выполняется буквально; `hasNext` не означает partial и не скрывает итог текущей группы.
+Превью операций получает `limit: 5` в `AccountPage.vm.ts`; событий — `slice(0, RECENT_EVENTS_LIMIT)` в `pages/account/model/previews.ts`.
+Группировать после этих ограничений; никогда не добирать шестую запись ради пары. При смене периода/счёта/cursor результат вычисляется заново.
+
+### D5. Композиция вместо новых разновидностей каждой карточки
+
+Драйверы: `brokerage-account-ledger` — `Full ledger presents compact rows`; `brokerage-account-income-analytics` — `Income payments remain traceable to exact Ledger Entries`.
+Общий недоменный `EntryGroup` в `src/shared/ui/EntryGroup/` принимает готовый header, accessible label и children; он владеет только композицией группы.
+Предметные `LedgerEntryGroup` и `LedgerAccountRow` принадлежат `entities/broker-operation/ui`; `BrokerageEventGroup` и `BrokerageEventAccountRow` — `entities/brokerage-event/ui`.
+Account row лёгкий, без вложенного полноценного LedgerEntryRow/Avatar; у выплат его существующие данные отображаются в карточном варианте, у остальных — строковом.
+В `packages/ui/src/EntryCard/EntryCard.tsx` расширить только value slot с string до ReactNode (включая null); сохранить string callers и прежний DOM для них.
+Слот допускает несколько самостоятельно оформленных валютных значений и отсутствие видимого значения; общий tone карточки не должен перекрашивать все валюты одним знаком.
+Для одной внешней рамки использовать существующий `details` slot EntryCard под содержимое группы, не вкладывать вторую Paper вокруг целой карточки.
+Singleton продолжает вызывать `LedgerEntryRow` либо `BrokerageEventCard`, а через них существующий `PayoutCard`; его API не расширяется ради grouping.
+Альтернативы — копировать EntryCard или добавлять group/account варианты в PayoutCard — увеличивают дублирование либо смешивают ответственности.
+
+### D6. Явный all-mode на границе page
+
+Драйвер: `brokerage-account-ledger` — `All-accounts ledger groups same-day entries of one instrument`.
+Page VM читает route param и передаёт `isAllAccounts = accountId === "all"`; это существующий sentinel, например `pages/account/ui/AccountPage/components/AccountHeading.view.tsx`.
+При false сохраняется прежний flat-render path без вызова группировки и новой политики сумм. Наличие account у записи не используется как определение режима.
+Не извлекать режим из URL внутри entity, имени счёта, количества счетов или query result.
+
+## Components and Responsibilities
+
+| Owner / путь | Ответственность и направление зависимостей |
+| --- | --- |
+| `shared/lib/group-items.ts`, `decimal.ts` | Недоменная чистая механика; экспорт через `shared/lib/index.ts`. |
+| `entities/broker-operation/model/display.ts` | Ключ операции и group presentation; reuse `paymentPresentation`, `isIncomePayment`, `operationLabelKey`, а не category как type. |
+| `entities/brokerage-event/model/event-key.ts` | Добавить отдельный grouping key; `brokerageEventKey` оставить ключом исходного события, не заменять им группировку. |
+| `entities/*/ui/*Group`, `*AccountRow` | Преобразование предметных данных в shared UI; без queries и зависимости сущностей друг от друга. |
+| `pages/account-income/model/display.ts` | Сохранить occurrence keys каждой выплаты, сформировать grouped sequence только в all; income DTO структурно подходит operation renderer. |
+| `pages/account-operations`, `pages/account-events` | VM передаёт all и подтверждение полноты; loaded view выбирает single/group. |
+| `pages/account/model/previews.ts` | Передать all/completeness каждого собственного ресурса после ограничения записей. |
+| `RecentOperations.view.tsx`, `BrokerageEventsPreview.tsx` | Композиция preview single/group; состояния блоков не подменяют основной портфель. |
+
+Импорты через public `index.ts`; page не импортирует соседнюю page. Компонент с тестом/CSS живёт в `Component/Component.tsx`, `.test.tsx`, `.module.css` по UI conventions; чистые тесты colocated `.test.ts`.
+
+## Data / Storage Changes
+
+N/A: новые данные не сохраняются. Группы и BigInt существуют только при вычислении presentation; ни localStorage, ни второй query cache, ни миграции БД не нужны.
+
+## Contract Implementation
+
+N/A для изменения контракта: проверены следующие существующие поля `src/shared/api/generated/schema.d.ts`.
+
+| DTO | Счёт / дата / тип | Identity | Деньги |
+| --- | --- | --- | --- |
+| `BrokerageOperationDto` (1087) | `account?`, `occurredAt`, `type` | nullable `instrumentUid`, `figi`; ISIN нет | nullable `payment`, `price`, `accruedInterest`, `commission` |
+| `UpcomingEventDto` (1229) | `account?`, `date`, `dateKind`, `type` | nullable `instrumentUid`, `figi`, `isin` | nullable `projectedAmount` |
+| `IncomeAnalyticsEntryDto` (1158) | `account?`, `occurredAt`, `type` | nullable `instrumentUid`, `figi`, opaque `instrumentKey` | nullable `payment` и остальные поля операции |
+
+`MoneyDto` содержит string `value` и `currency`; resource envelopes несут meta. Полей достаточно для алгоритма без нового endpoint, enrichment и ручных правок generated types.
+Optional `account` нужен для single-account DTO; all-response должен фактически содержать `{id,name}` согласно `docs/domains/portfolio/all-accounts.md`. Типы сами эту гарантию не доказывают: проверить fixture/response на consumer boundary.
+При отсутствующем account не угадывать происхождение и не строить ссылку из `all`; это нарушение данных, а не повод менять API в данном change.
+
+## Cross-cutting Implementation
+
+`src/shared/api/resource-query.ts:128–147` раскрывает data и meta одного envelope. Entity hooks и useScreenSync остаются владельцами загрузки и обновления.
+Operations/events VM уже передают `source: query.meta` и `partial`; для итога использовать source.completeness, не инверсию partial.
+Income VM сейчас передаёт только `partial: analytics.meta?.completeness === "incomplete"`; добавить явный `totalsAllowed` от meta и провести через loaded view в IncomePayments.
+`previews.ts` теряет подтверждение complete при сведении к loaded/partial: добавить `totalsAllowed` отдельно для operations/events; meta портфеля здесь не подходит.
+Stale/refresh failure не равны incomplete: сохранённые данные продолжают отображаться по прежней policy; новая группа не хранит собственный snapshot.
+React keys групп — tuple-key; строки — прежняя identity с account и occurrence для повторений. Не дедуплицировать совпадающие события; индекс допустим лишь как occurrence внутри идентичного ключа.
+Переводы и озвучивание остаются в presentation; shared арифметика не импортирует i18n. Новых telemetry, запросов и зависимостей нет.
+
+## UI Implementation
+
+Композиция: route → existing query/VM → текущие ограниченные items + all + totalsAllowed → pure grouping → entity single/group → shared EntryCard/EntryGroup.
+Производные группы не помещаются в useState/effect; существующие состояния запроса и pagination остаются источником истины.
+Ниже привязка к состояниям `ux-design.md#ui-states`, без переопределения их представления:
+
+| UX state | Как производится |
+| --- | --- |
+| Одиночная запись | Single ветка результата или прежний single-account path. |
+| Группа с итогом / мультивалютный итог | Два и более items; totalsAllowed; успешная сумма по валютам, переданная value slot. |
+| Итог скрыт | Неподтверждённая completeness либо недопустимый amount; null visual value и перевод для accessible name. |
+| Нулевой итог | Все слагаемые допустимы, точная сумма равна нулю; neutral presentation без знака. |
+| Offer без сумм | Null projectedAmount; event-row использует существующий `events.noAmount`. |
+| Прогноз | Event presenter использует `payout.forecast`, независимо от знака и числа валют. |
+| Строка без денег | Existing payment semantics, нулевой/null amount; group total недоступен. |
+| Обзор, 5 записей / граница страницы | D4; состав определяется до группировки, никаких additional fetch. |
+| Loading / empty / error / partial-Alert | Existing VM/view guards; группировка только доступного массива, прежние alerts и SourceSyncStatus сохраняются. |
+
+В all-ветке контейнеры loaded lists получают list semantics из UX; account-row использует данные счёта, не делает lookup через другой entity.
+Подписи/дата/лого заголовка берутся из предметного presenter первой записи; у событий dateKind общий благодаря ключу.
+EntryCard value slot и CSS module EntryGroup реализуют responsive/a11y контракт UX; отдельный локальный state раскрытия не создаётся.
+
+## Developer Verification Strategy
+
+Test Intent: доказать сохранение записей и денежных значений при изменении только композиции; риск — ложный итог, смешение типов/дней, межстраничная агрегация.
+- Unit grouping: пустой список, одиночный ключ, null identity, не соседние совпадения, один счёт дважды, порядок первого появления и children, отсутствие мутации.
+- Unit key adapters: разные type внутри одной category; UID/FIGI/ISIN priority; отсутствие identity; разный dateKind; одинаковый день с разным временем, граница суток в разных timezone.
+- Unit decimal/money: разные scales, отрицательные дроби, значения больше safe integer, `0.1 + 0.2`, несколько валют, точная компенсация до нуля, null/zero/negative-zero, malformed input, пустой ввод.
+- Regression выделенной арифметики: существующие `pages/account/model/positions.test.ts` и display tests проходят без изменения портфельных результатов.
+- Component/route tests: все четыре поверхности all, singleton и single-account, account provenance, partial и отсутствующая meta, complete zero, unknown forecast; серверные income totals неизменны.
+- Pagination через MSW: next/previous, тот же ключ на двух страницах, reset фильтра и invalid cursor; после перехода нет строк предыдущей страницы.
+- Preview test: пять исходных записей, шестая не подтягивается; UI group не считается одной записью лимита. React keys не теряют повторные выплаты.
+- RTL semantic queries проверяют nested lists, доступные имена и отсутствие ложного итога; browser proof — переносы, 320 px, 200% zoom и focus согласно UX, не проверки CSS через JSDOM.
+- После загрузки `$HOME/.nvm/nvm.sh` и `nvm use --silent` из frontend: адресный `npm run test:run -- <path>`, `npm run typecheck`, `npm run lint`; на итоговом code diff — один `npm run verify`.
+- Verify уже включает offline `openapi:check`, coverage, Knip, dependency boundaries, app/catalog build; отдельный runner или CI pipeline не добавлять. Для одного этого Markdown — semantic review и `git diff --check`, без application build.
+
+## Migration / Rollout / Rollback
+
+Сначала выделить арифметику с regression checks; затем pure grouping и entity composition; затем подключить all-ветки и провести meta до потребителей.
+Существующие EntryCard callers сохраняют совместимость; выпуск возможен одним frontend build без координации backend или миграции cache/data.
+Откат — предыдущий frontend build либо возврат flat-render all-веток; серверные данные и API не затронуты, feature flag ради этого change не нужен.
+
+## Solution Assessment
+
+N/A: нет новых auth, storage, integrations, caching, concurrency или shared tooling; изменение локально и обратимо. Риски точной арифметики и UI описаны проверками выше.
+
+## Risks / Trade-offs
+
+- В UX есть неоднозначность: Accessibility требует account links в строках вообще, Presentation Decisions п. 4 исключает обзор/события. До реализации ссылок владелец UX должен подтвердить область применения; дизайн её молча не меняет.
+- UTC календарь событий, browser timezone исполненных записей и Moscow период аналитики различаются уже сейчас; намеренно не исправляем их этим change.
+- Отсутствие общей identity или account нельзя восстановить из названия; проверка фактических all fixtures обязательна. instrumentKey не устраняет этот риск.
+- Canonical «Account page presents an upcoming events list» говорит «без фильтров», а страница уже фильтрует период. Этот drift существовал до change и записан в WealthLedger/specs#63; фильтры в рамках группировки не трогаются.
+
+## ADR Candidates
+
+Отдельный ADR не требуется: API, архитектурный стиль и технологии не меняются; локальные обратимые решения D1–D6 достаточно сохранить в этом change.
+
+## Docs Impact
+
+Цели и итоговый AS-IS перечислены в разделе `## Docs Impact` в tasks.md, docs-impact не выбран. `docs/design/overview.md` не меняется.
@@ -0,0 +1,64 @@
+# Process Record
+
+**Mode:** lab
+**Class:** standard
+**Issue:** https://git.personal.ksv741.ru/WealthLedger/main/issues/47
+
+## Change Profile
+
+| Artifact | Selected | Reason |
+| --- | --- | --- |
+| research | no | Это потребность самого Change Owner, а as-is уже разобран и записан в Proposal Evidence. Рынок и альтернативы изучать не нужно. |
+| ux-design | yes | Trigger: на четырёх экранах режима «все счета» появляется новый паттерн представления (заголовок группы, итог, разбивка по счетам), и он должен уживаться с существующими карточками событий и операций. |
+| system-analysis | no | Не trigger: межсистемный contract, data ownership и интеграции не меняются. Это представление уже полученных данных внутри frontend. |
+| data-mapping | no | Модуль требует system-analysis, а она не выбрана. Ключ группы, правило итога и запрет смешивания валют задаются Requirements в specs и проверяются в test-cases. |
+| failure-model | no | Нет внешней интеграции, фоновой синхронизации и многошаговой записи. Состояния загрузки и ошибок списков не меняются. |
+| nfr | no | Группировка охватывает уже загруженные строки списка. Значимых ограничений по performance, availability или capacity нет. |
+| observability | no | Клиентское представление без фоновых процессов. Оператору нечего отличать. |
+| security-analysis | no | Модель доступа, trust boundaries и состав раскрываемых данных не меняются: показываются те же записи текущего User. |
+| test-cases | yes | Trigger: денежные итоги групп, граничные случаи ключа (тип, дата, отсутствие Instrument, один счёт, разные валюты) и стык загруженных страниц. Для их проверки нужны конкретные данные и oracle. |
+| docs-impact | no | Обновляются только AS-IS страницы доменов (4 файла в `docs/domains/`). ADR, architecture- и integration-страниц нет. Цели перечислены в `## Docs Impact` в tasks.md. |
+
+## Gate Log
+
+| Gate | Date | Scope | Validation | Findings | Decision |
+| --- | --- | --- | --- | --- | --- |
+| G1 | 2026-10-29 | proposal, change-profile | `check.cjs plan` OK; `openspec validate` — ожидаемая ошибка «no deltas» до specs; G1 review product-analyst | 2 blocker, 5 major, 1 minor — закрыты решениями владельца в Proposal | approved "все ок, идем дальше" |
+| G2 | 2026-10-29 | specs | `openspec validate --strict` valid; `check.cjs plan` OK; G2 review qa-engineer + independent-reviewer | 2 blocker, 6 major, 8 minor — закрыты правками specs и решением владельца (итог скрыт при `partial`) | approved "да, все ок, идем дальше" |
+| G2 | 2026-10-29 | specs | — | UX нашёл 2 пробела в specs: итог при неполном прогнозе; нулевая сумма | invalidated: решения владельца в текущей сессии («Скрывать, как в журнале», «Скрывает итог») изменили Requirements об итоге группы журнала и событий |
+| G2 | 2026-10-29 | specs | `openspec validate --strict` valid; `check.cjs plan` OK | Правки по 2 UX findings внесены в specs | approved "да, все ок" |
+| G3 | 2026-10-29 | design, ux-design, qa-analysis, test-cases, tasks | `openspec validate --strict` valid; `check.cjs plan` planning complete; `git diff --check` clean; G3 review independent-reviewer | 3 major, 5 minor — исправлены | approved "да, давай дальше" |
+| G4 | 2026-10-29 | implementation, review, QA, docs | frontend `npm run verify` exit 0 (530 tests, coverage 92.35%); docs `npm run verify` OK; independent review; QA в браузере (18 TC/сценариев pass); openspec-verify-change: 0 critical, все warnings закрыты; `check.cjs apply` OK | Review 3 major + 5 minor, verify 2 warning + 2 suggestion; всё исправлено. Flaky `screen-sync.test.tsx` есть и до change, файл не менялся | approved "да, все ок, давай коммититься" |
+
+## Descoped Work
+
+| Task | Reason | Gate |
+| --- | --- | --- |
+
+## Lab Journal
+
+| Stage | Role / subagent | Unique findings | Decisions | Risks found / excluded | Handoff issues | Skills | Cost | Transferable |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| proposal + change-profile | product-analyst (G1 review) | Режим «Все счета» потерян в canonical ledger/income; запрет frontend-пересчёта итогов в «Выплатах»; неоднозначности даты и типа, порядка, лимита превью | 7 решений Change Owner внесены в Proposal | blocker ×2, major ×5, minor ×1; все закрыты | Ответ сабагента дважды обрезался, пришлось запрашивать продолжение | openspec-new-change | 3 вызова сабагента | Делать G1 review до показа владельцу: он нашёл canonical drift |
+| specs | qa-engineer, independent-reviewer (G2 review) | Затронутые canonical блоки (compact rows, обзор, список событий без итога) нужно было модифицировать; восстановление `all` было неполным относительно archive; конфликт итога с frontend-data-resilience; ключ «точный тип» неоднозначен для покупки и продажи | Итог скрывается при `partial` (решение владельца); граница страницы — явное исключение; блоки восстановлены из archive целиком | 2 blocker, 6 major, 8 minor; все закрыты правками. Вне scope: canonical drift persist-tbank-data шире двух восстановленных блоков | Ответы сабагентов трижды обрезались | openspec-new-change | 4 вызова сабагентов | Ревьюеру консистентности давать список canonical блоков, которые затрагивает UI-изменение |
+| design + ux-design + qa-analysis + test-cases + tasks | ux-designer, solution-architect, qa-engineer, independent-reviewer (G3 review) | UX: 2 пробела в specs (неполный прогноз, нулевая сумма), из-за них G2 переутверждён. Design: `instrumentKey` не является identity, у журнала пагинация назад/вперёд, а не дописывание, BigInt-decimal уже есть в `positions.ts`. Review: test-cases ссылались на несуществующие сценарии, неверные oracle в TC-PAG | Ссылки на счёт оставлены текстом, как сейчас; лимит превью считается по записям; Docs Impact перенесён в tasks | G3 review: 3 major, 5 minor, все исправлены. Вне scope: drift с фильтрами событий записан в specs#63 | qa-engineer сначала выдал 46 TC вместо case-only; сабагенты обрезались | — | 7 вызовов сабагентов | Давать QA правило «case только сверх Scenario» сразу; проверять ссылки на сценарии через grep |
+| apply + G4 checks | frontend-engineer, documentation-engineer, independent-reviewer, qa-engineer | Review: имя группы для скринридера неполное, у выплат терялись occurrence keys, выплаты в группе не были карточками, ссылки на счета появились вопреки UX. QA: 18 проверок pass в браузере со stubbed API | Все findings исправлены. QA D1 (заголовок «Дивиденд») — артефакт заглушки с `type: "Купон"` вместо `OPERATION_TYPE_COUPON`, не дефект. D2 опровергнут кодом: `aria-label` стоит на вложенном `ul` по UX | Flaky `screen-sync.test.tsx` есть и до change, файл не менялся; на baseline 3/3 pass | Исполнитель дважды молча отклонился от UX; поймано review | — | ~9 вызовов сабагентов | Давать исполнителю явный список Presentation Decisions; QA строить заглушки только из enum generated types |
+| verify (openspec-verify-change) | основной агент | Строка записи в группе журнала показывала дату вместо подписи типа (расхождение с `Full ledger presents compact rows`); у сценариев BUY/SELL, «итог в нескольких валютах» для событий и «оферта» не было автотестов | Исправлено: подпись типа в строке, `aria-label` у карточки-строки, 4 новых теста | 0 critical, 2 warning, 2 suggestion; все закрыты | — | openspec-verify-change | 1 проход | Verify по сценариям находит то, что пропустили review и QA |
+
+## Retrospective
+
+**Факты**
+- 4 gate, 1 инвалидация G2: UX нашёл 2 пробела в specs (итог при неполном прогнозе, нулевая сумма).
+- Независимый review находил реальные дефекты на каждом gate:
+  - G1: в canonical specs потерян режим `all`; спека «Выплат» запрещала frontend считать итоги.
+  - G2: группировка нарушала canonical requirements, которые change не модифицировал.
+  - G3: test-cases ссылались на несуществующие сценарии, а oracle пагинации были неверны.
+  - G4: имя группы для скринридера, повторные ключи выплат, ссылки на счета вопреки UX.
+- Verify по сценариям нашёл расхождение, которое пропустили review и QA: в строке группы не было подписи типа.
+- Побочный результат — WealthLedger/specs#63: canonical drift после archive `persist-tbank-data`.
+- Стоимость: около 25 вызовов сабагентов. Ответы часто обрезались, так что прятались продолжения.
+
+**Оценка**
+- Окупились: G1/G2 review (без них delta строилась бы на неполном каноне), ux-design (нашёл пробелы в specs), verify по сценариям.
+- Избыточным для standard UI-change оказался первый вариант QA-артефактов: 46 TC вместо cases «сверх Scenario». Пришлось переписать.
+- Изменить в schema: в instruction для qa-analysis/test-cases явно требовать ссылки на существующие `#### Scenario` и проверку их grep-ом. В brief для исполнителя передавать Presentation Decisions из ux-design как обязательный список.
@@ -0,0 +1,79 @@
+# Proposal
+
+Issue: WealthLedger/main#47
+
+## Why
+
+В режиме «Все счета» события и операции показываются плоским списком: одна строка — одна запись одного счёта. Одна и та же бумага часто есть сразу на брокерском счёте и на ИИС. В этом случае выплаты по ней в один день разбросаны по отдельным строкам, и пользователю приходится самому связывать их и сравнивать суммы по счетам.
+
+## What Changes
+
+- В режиме «Все счета» записи с одним днём, одним Instrument и одним точным типом события или операции объединяются в одну визуальную группу.
+- В заголовке группы — бумага, тип и итог. Итог — точная сумма записей группы, отдельно по каждой валюте и со знаком. Под заголовком всегда раскрыта разбивка: каждая запись остаётся отдельной строкой со своим счётом и суммой (например, «Брокерский — 200 ₽», «ИИС — 100 ₽»).
+- Группировка применяется к предстоящим событиям и к исполненным операциям любой категории, если у записи есть identity Instrument.
+- Группа образуется из двух и более записей с одинаковым ключом, даже если все они относятся к одному счёту.
+- Группа стоит на месте своей первой записи в серверном порядке. Записи внутри группы и остальные строки сохраняют относительный серверный порядок.
+- Режим одного счёта, записи без Instrument и одиночные записи не меняются.
+- В нормативные specs журнала и аналитики дохода возвращается уже существующий режим «Все счета». Он был утрачен при синхронизации canonical specs; поведение при этом не меняется.
+- Для «Выплат» в режиме «Все счета» вводится исключение из действующих запретов: группировочные карточки по Instrument и вычисление итога группы на клиенте разрешены. Аналитические итоги дохода по-прежнему приходят с сервера и не пересчитываются.
+
+## Scope
+
+### In Scope
+
+- Страница предстоящих событий в режиме «Все счета».
+- Страница журнала операций в режиме «Все счета».
+- Превью ближайших событий и последних операций на обзоре в режиме «Все счета». Лимит считается по записям, как сейчас.
+- Раздел «Выплаты» на странице доходов в режиме «Все счета».
+- Восстановление в canonical specs журнала и дохода нормативного описания режима «Все счета» в его текущем поведении.
+
+### Out of Scope / Non-Goals
+
+- Режим одного счёта.
+- Группировка за пределами одного дня, по эмитенту или между разными типами: покупка ≠ продажа, купон ≠ налог с купона, налог с купона ≠ налог с дивиденда.
+- Изменение состава, фильтрации, серверного порядка, пагинации, лимитов превью или денежных значений, которые возвращает сервер.
+- Записи без identity Instrument.
+- Сворачивание групп и пометка, что группа может быть неполной.
+- Аналитические итоги дохода и их пересчёт.
+
+## Capabilities
+
+### New Capabilities
+
+Нет.
+
+### Modified Capabilities
+
+- `specs/brokerage-account-upcoming-events/spec.md`: представление событий (страница и превью) в режиме «Все счета».
+- `specs/brokerage-account-ledger/spec.md`: восстановление режима «Все счета», представление журнала и превью операций в этом режиме.
+- `specs/brokerage-account-income-analytics/spec.md`: восстановление режима «Все счета», раздел «Выплаты» в этом режиме с исключением из запретов на группировку и клиентский итог.
+
+## Impact
+
+- Пользователи с несколькими счетами, которые смотрят режим «Все счета».
+- Меняется только представление уже полученных данных. Источники данных, серверные ответы и интеграция с T-Bank остаются прежними.
+- Вероятно затрагиваются клиентское представление списков и AS-IS документация экранов.
+
+## Success Criteria
+
+- Купоны по одной облигации за один день (200 ₽ на брокерском счёте и 100 ₽ на ИИС) в режиме «Все счета» видны одной группой с итогом 300 ₽ и отдельной строкой для каждого счёта.
+- Записи разных типов или дней по одной бумаге не объединяются.
+- Итог группы точен, показывается отдельно по каждой валюте и учитывает знак записей.
+- В режиме одного счёта и для записей без Instrument списки выглядят как раньше.
+
+## Evidence
+
+- [F] В режиме «Все счета» страницы событий, операций, превью обзора и «Выплаты» показывают плоский список, по строке на запись, со счётом в каждой строке. Группировки по Instrument нет. Источник: AS-IS frontend, разбор кода 2026-10-29.
+- [F] Canonical `brokerage-account-income-analytics` («Income payments remain traceable to exact Ledger Entries») запрещает группировочные карточки и subtotals по Instrument в «Выплатах» и пересчёт денежных итогов на frontend. Источник: canonical spec, archive `2026-10-14-unify-income-payment-cards`.
+- [F] Режим «Все счета» для журнала и дохода описан в delta specs archive `2026-10-09-persist-tbank-data`, но отсутствует в текущих canonical specs `brokerage-account-ledger` и `brokerage-account-income-analytics`. В `brokerage-account-upcoming-events` он есть. Источник: specs store, G1 review 2026-10-29.
+- [F] Потребность: одна облигация на брокерском счёте и ИИС, выплаты по ней в один день нужно видеть рядом с суммой по каждому счёту. Источник: запрос Change Owner, WealthLedger/main#47.
+- [H] Сервер в режиме «Все счета» уже возвращает для каждой записи счёт, дату, тип, identity Instrument и точную сумму. Подтверждается в Design.
+
+## Assumptions / Dependencies
+
+- День записи берётся тот же, что строка уже показывает на этом экране. Часовой пояс отображения не меняется.
+- Группа собирается только из записей, показанных на текущей странице журнала или в превью. При переходе на другую страницу группы собираются заново из её записей, поэтому группа на границе страницы может быть неполной.
+
+## Open Decisions
+
+Нет. Change Owner принял в текущей сессии: ключ (день как на экране, identity Instrument, точный тип), клиентский итог по валютам, позиция группы на месте первой записи, лимит превью по записям, неполная группа без пометки, строка на каждую запись, восстановление режима «Все счета» в этом change.
@@ -0,0 +1,89 @@
+# QA Analysis
+
+Объект проверки: frontend-only изменение группировки строк по Instrument в режиме «Все счета» (журнал, обзор, будущие события, «Выплаты»). Backend и API не меняются; контракт используется как есть.
+
+## Risk Assessment
+
+| Risk | Affected requirements | Likelihood | Impact | Verification depth |
+| --- | --- | --- | --- | --- |
+| Неверный ключ группы: объединение записей разных типов/дней или не-объединение одинаковых | ledger/upcoming `groups same-day…` | Средняя | Высокая | Полный перебор граничных комбинаций ключа (тип, день, Instrument, один счёт) |
+| Неверный итог: конвертация/округление валют, потеря знака, итог при отсутствии/нулевой сумме, при `partial` | ledger/upcoming `group shows each entry and …` | Средняя | Высокая | Мультивалютные, знаковые, нулевые и запрещающие сценарии итога; сверка с серверными суммами |
+| Нарушен серверный порядок или лимит (5 записей обзора, пагинация журнала) из-за группировки | `preserves order and limits` | Средняя | Средняя | Проверка позиций групп, границы страницы, состава «последних 5» |
+| Группировка случайно применяется в режиме одного счёта или к записям без Instrument | `groups same-day…`, MODIFIED «Full ledger…» | Низкая | Высокая | Регрессионная проверка одиночного режима и записей без Instrument |
+| «Выплаты»: группировка нарушает запреты одиночного режима или подменяет аналитические итоги | `Income payments remain traceable…` | Средняя | Высокая | Проверка обоих режимов, неизменности серверных аналитических итогов |
+| Пропадание записей внутри группы (свернуто, скрыто) или потеря fallback при отсутствии metadata | `group shows each entry…`, MODIFIED `Full ledger…`, MODIFIED overview | Низкая | Высокая | Визуальная проверка разбивки без раскрытия, fallback-представление |
+| Обзор «Все счета»: режим не открывается / принадлежность счёту потеряна (восстановление режима `all`) | MODIFIED `User can retrieve an account ledger`, MODIFIED overview, MODIFIED upcoming list | Средняя | Средняя | Проверка доступности и контента режима `all`, `partial`-поведение |
+
+## Coverage Matrix
+
+| Requirement | Check | Level | Test cases |
+| --- | --- | --- | --- |
+| `brokerage-account-ledger` — `User can retrieve an account ledger` | Режим `all` доступен; принадлежность записей; `partial`; пустая незагруженная часть | System / E2E | Scenario: Получение журнала с периодом по умолчанию; Scenario: Общий журнал сохраняет принадлежность записей; Scenario: Общий журнал содержит неполный счёт; Scenario: Пустая загруженная часть не доказывает отсутствие операций |
+| `brokerage-account-ledger` — `Account overview includes recent ledger events` | Группы в обзоре «Все счета»; лимит 5; fallback без metadata | System / E2E | Scenario: Отображение последних событий; Scenario: Последняя запись не содержит visual metadata инструмента; Scenario: Группировка в последних записях обзора; TC-PAG-002, TC-PAG-003 |
+| `brokerage-account-ledger` — `Full ledger presents compact rows` | Строка в группе: счёт, сумма, знак, подпись типа; заголовок группы; fallback | System / E2E | Scenario: Запись внутри группы режима «Все счета»; Scenario: Подпись типа не дублируется; Scenario: Отсутствует visual metadata инструмента; TC-GRP-001, TC-TOT-001 |
+| `brokerage-account-ledger` — `All-accounts ledger groups same-day entries of one instrument` | Ключ группы: два счёта, один счёт, разные типы, покупка/продажа, разные дни, без Instrument, один счёт | System / E2E | Scenario: Купоны одной облигации на двух счетах; Scenario: Две операции одного типа на одном счёте; Scenario: Разные типы по одной бумаге не объединяются; Scenario: Покупка и продажа не объединяются; Scenario: Разные дни не объединяются; Scenario: Запись без Instrument; Scenario: Режим одного счёта не меняется; TC-GRP-001, TC-GRP-002, TC-GRP-003, TC-GRP-004 |
+| `brokerage-account-ledger` — `All-accounts ledger group shows each entry and an exact total` | Точный итог: мультивалюта, знак, ноль, без изменения, `partial`; разбивка всегда видна | System / E2E | Scenario: Итог по нескольким валютам; Scenario: Итог со знаком; Scenario: Нулевой итог; Scenario: Группа с записью без денежного изменения; Scenario: Запись с нулевой суммой скрывает итог; Scenario: Итог скрыт при неполном периоде; TC-TOT-001, TC-TOT-002, TC-TOT-003, TC-TOT-004 |
+| `brokerage-account-ledger` — `All-accounts ledger grouping preserves order and limits` | Позиция группы; граница страницы; лимит 5 обзора | System / E2E | Scenario: Позиция группы в списке; Scenario: Группа на границе страницы; TC-PAG-001, TC-GRP-002 |
+| `brokerage-account-upcoming-events` — `Account page presents an upcoming events list` | Страница в `all`; групповой итог ≠ итог списка; дисклеймер | System / E2E | Scenario: Просмотр ближайших событий; Scenario: Пустое состояние страницы; Scenario: Прогнозный дивиденд с неизвестной суммой |
+| `brokerage-account-upcoming-events` — `All-accounts upcoming events group same-day events of one instrument` | Группы событий: два счёта, разные типы/даты, без Instrument, один счёт | System / E2E | Scenario: Прогноз купонов одной облигации на двух счетах; Scenario: Разные типы или даты не объединяются; Scenario: Событие без Instrument; Scenario: Режим одного счёта не меняется; TC-GRP-005 |
+| `brokerage-account-upcoming-events` — `All-accounts upcoming event group shows each event and a forecast total` | Прогнозный итог: неизвестная сумма, оферта, мультивалюта, неполный прогноз, дата реестра | System / E2E | Scenario: Событие с неизвестной суммой в группе; Scenario: Оферта без сумм; Scenario: Прогнозный итог по нескольким валютам; Scenario: Прогнозный итог скрыт при неполном прогнозе; Scenario: Группа дивидендов по дате реестра; TC-GRP-005, TC-TOT-005 |
+| `brokerage-account-upcoming-events` — `All-accounts upcoming event grouping preserves order and limits` | Позиция группы событий; ближайшие события обзора | System / E2E | Scenario: Позиция группы событий; Scenario: Группировка в ближайших событиях обзора; TC-PAG-002 (по аналогии для событий обзора) |
+| `brokerage-account-income-analytics` — `Realized income analytics is account-scoped and period-bound` | Режим `all` в аналитике; полнота всех счетов; периоды | System / E2E | Scenario: Общий доход требует полноты всех счетов; Scenario: Открыт ещё не загруженный период (изменение frontend не затрагивает — smoke) |
+| `brokerage-account-income-analytics` — `Income payments remain traceable to exact Ledger Entries` | «Выплаты»: одиночный режим без групп; группы в `all`; итог при неполноте; аналитика не пересчитана; корректировки и дубли ID | System / E2E | Scenario: Каждая выплата показана отдельной карточкой; Scenario: Список воспроизводит точный состав дохода; Scenario: Отрицательная корректировка и повторяющиеся IDs сохраняются; Scenario: Выплаты одной бумаги на двух счетах в режиме «Все счета»; TC-GRP-006, TC-TOT-004 (правило скрытия итога) |
+
+## Negative and Boundary Focus
+
+- Ключ группы: разные точные upstream-типы, покупка vs продажа, разные экранные дни, отсутствие identity Instrument, одна запись (нет пары), все записи на одном счёте.
+- Итог: мультивалюта без конвертации; копеечные суммы без округления (+150.10 −50.05); нулевой итог без знака; запись без денежного изменения; нулевая сумма; `partial`-период; неполный прогноз; событие с неизвестной суммой; оферта без сумм.
+- Порядок и лимиты: группа из записей первой и следующей страницы журнала; лимит 5 записей обзора (считается по записям, не по группам); позиция группы по первой записи.
+- Режимы: один счёт — полное отсутствие группировки; записи без Instrument не сливаются.
+
+## Cross-system Verification
+
+system-analysis не выбран, backend и API в рамках change не меняются — отдельная кросс-системная проверка не требуется. Существующие серверные данные проверяются как вход: реальные ответы API (`{ data, meta }`, принадлежность записей счёту, `partial`-состояние, серверные аналитические итоги, порядок entries) используются как эталон, с которым сверяется клиентское представление (состав групп, суммы, порядок). Ключевой инвариант: аналитические денежные итоги и receipt count приходят только с сервера и не пересчитываются; единственный клиентский расчёт — итог визуальной группы, который сверяется с суммой серверных записей группы.
+
+## Test Data and Environment Needs
+
+Локальный frontend + локальный backend с сохранёнными данными (или stubbed API в браузере через devtools/сервис-воркер-заглушку). Фикстуры:
+
+- Два счёта (брокерский + ИИС) с одной и той же облигацией: исполненные купоны в один день (+200 RUB и +100 RUB) — базовая группа.
+- Мультипанель: одна группа с записями в RUB и USD; выплаты одной бумаги в разных валютах.
+- Граничные суммы: +150.10 / −50.05 / −150.10; запись с нулевой суммой; запись без денежного изменения; отрицательная корректировка.
+- Разнообразие типов: купон + налог в один день, покупка + продажа одной бумаги в один день, две покупки на одном счёте, купоны в разные (экранные) дни.
+- Записи без identity Instrument (например, переводы) — два в один день одного типа.
+- Записи без presentation metadata инструмента — fallback.
+- `partial`: счёт с незагруженным интервалом в запрошенном периоде; пустая сохранённая часть при неполном покрытии.
+- Граница страницы: настройки пагинации журнала так, чтобы записи одной группы попали на разные страницы; подтверждённо полный период.
+- Будущие события: купон на двух счетах в одну дату; дивиденды по дате реестра (известная и неизвестная суммы); оферта на двух счетах; события без суммы; неполный прогноз.
+- Обзор: ровно 5 последних записей, среди которых пара с одинаковым ключом.
+- Режим одного счёта с теми же данными (два купона одной бумаги в один день).
+
+Источник: подготовленные фикстуры в локальной БД тестового backend; при отсутствии — заглушка API-ответов в браузере с теми же контрактными envelope.
+
+Примечания по окружению (не блокеры): тестовые данные границы страницы строятся вокруг фактического размера страницы, который возвращает сервер (TC-PAG-001 фиксирует конкретное содержимое страниц в момент прогона); состояние `partial` и неполный прогноз воспроизводятся заглушкой API-ответа в браузере (MSW / Playwright route) с `meta` partial.
+
+## Manual / Exploratory Scope
+
+- Визуальное чтение группы без раскрытия: разбивка всегда видна, заголовок не дублирует подпись типа в строках, знак и семантический цвет не единственные носители направления.
+- Устойчивость к обновлению: приход `partial` → подтверждённой полноты — итог появляется/исчезает корректно; фоновая догрузка не меняет состав и порядок показанных записей.
+- Переходы между режимами «Все счета» ↔ один счёт на одних данных: группировка появляется/исчезает целиком.
+- Прокрутка/пагинация журнала в `all`: стабильность позиций групп между страницами.
+- Consent-контент: дивидендные группы с датой реестра, оферта без итога — читаемость при отсутствии сумм.
+
+## Automation Candidates
+
+Black-box E2E (Playwright, режим «Все счета»): TC-GRP-001, TC-GRP-002, TC-GRP-005, TC-GRP-006, TC-TOT-001, TC-TOT-002, TC-TOT-003, TC-TOT-004, TC-TOT-005, TC-PAG-001, TC-PAG-002, TC-PAG-003 — стабильные контрактные сценарии групп, итогов и порядка. TC-GRP-003 и TC-GRP-004 — ручные до уточнения Specs. Статус всех: **deferred until QA repo exists**.
+
+## Regression Impact
+
+- Режим одного счёта: журнал, обзор, «Будущие события», «Выплаты» — полное отсутствие группировки (Scenario-блоки требований; ручная регрессия).
+- Существующие карточки и строки журнала вне групп: представление выплаты купона/дивиденда, подписи типов, знаки, fallback без metadata — без изменений.
+- Состояния загрузки/пустоты/ошибки: первичное ожидание, нейтральная недоступность, сохранение прежнего результата при временном сбое, `partial` и пустая-но-неполная выборка — не деградируют из-за группировки.
+- Восстановленный режим `all` в specs журнала и аналитики — поведение не меняется, только smoke доступности (Scenario: Получение журнала с периодом по умолчанию; Scenario: Общий доход требует полноты всех счетов).
+- Аналитические итоги дохода и receipt count — только серверные, отсутствие клиентского пересчёта (TC-GRP-006).
+
+## Gaps / Blockers
+
+Нет. Два вопроса из test design закрыты без изменения specs:
+- Identity-ключ: specs требуют одинаковую identity Instrument; design D2 определяет её как первый непустой идентификатор, а записи, равенство которых не доказано, не объединяются (TC-GRP-003).
+- День: specs задают «день, как на экране»; oracle — показанная в строке дата (TC-GRP-004).
@@ -0,0 +1,64 @@
+## MODIFIED Requirements
+
+### Requirement: Realized income analytics is account-scoped and period-bound
+
+Система MUST предоставлять аутентифицированному User аналитику фактически полученного дохода выбранного открытого поддерживаемого Brokerage Account либо существующего режима «Все счета» (`all`) из счетов, доступных через текущий T-Bank connection User. В режиме `all` система MUST проверять доступ каждого входящего счёта и подтверждать полноту каждого исходного периода по всем входящим счетам; отсутствующий вклад счёта MUST NOT заменяться нулём. Применённый период MUST задаваться включительными календарными датами `from` и `to` в Europe/Moscow, MUST NOT начинаться после своего окончания, MUST NOT содержать будущую дату. Система MUST NOT ограничивать максимальную длительность периода. При отсутствии применённого периода система MUST использовать интервал от первого дня текущего месяца до сегодняшнего дня включительно.
+
+Чтение MUST использовать сохранённые операции текущего подключения и локальное подтверждение доступа без синхронного запроса T-Bank. Ответ MUST иметь envelope `{ data, meta }` по `tbank-data-sync`. Полнота MUST определяться для выбранного периода и каждого необходимого периода сравнения отдельно. Запрос MUST приоритетно загружать их пропуски до фоновой догрузки остальной истории; известные правила календарных дат MUST сохраняться.
+
+#### Scenario: Аналитика за период по умолчанию
+
+- **WHEN** аутентифицированный User запрашивает аналитику доступного Brokerage Account без периода
+- **THEN** система рассчитывает результат от первого дня текущего месяца по Europe/Moscow до сегодняшнего дня включительно
+
+#### Scenario: Аналитика за допустимый пользовательский период
+
+- **WHEN** User применяет включительный период любой длительности, в том числе более 366 дней, без будущих дат
+- **THEN** система рассчитывает аналитику доступного Brokerage Account за все календарные даты этого периода по Europe/Moscow
+
+#### Scenario: Отклонение недопустимого периода
+
+- **WHEN** User запрашивает период с некорректной или будущей датой либо с `from` после `to`
+- **THEN** система отклоняет запрос и не возвращает результат для другого или усечённого периода
+
+#### Scenario: Отклонение недоступного счёта
+
+- **WHEN** User запрашивает аналитику Brokerage Account, который не является открытым поддерживаемым счётом, доступным через его текущий T-Bank connection
+- **THEN** система возвращает существующий ответ о недоступности счёта и не раскрывает его доход или операции
+
+#### Scenario: Общий доход требует полноты всех счетов
+- **WHEN** User запрашивает режим `all` и выбранный период одного доступного счёта ещё не загружен полностью
+- **THEN** система не возвращает окончательные общие суммы, сохраняет раздельное состояние покрытия счетов и запрашивает недостающую разрешённую историю
+
+#### Scenario: Открыт ещё не загруженный период
+- **WHEN** запрошенный допустимый период ещё не имеет сохранённых операций или подтверждённого полного пустого покрытия
+- **THEN** система отвечает `200` со статусом первичной загрузки или частичного покрытия, запрашивает нужные интервалы и не выдаёт нулевой окончательный доход
+
+### Requirement: Income payments remain traceable to exact Ledger Entries
+
+В разделе «Выплаты» страница MUST показывать единый список карточек точных исполненных Ledger Entries применённого периода в исходном серверном порядке entries. Каждая выплата MUST иметь собственную сразу видимую карточку с описанием, датой исполнения, доступной identity Instrument и signed Money в исходной валюте. Купоны и дивиденды MUST использовать то же представление выплаты, что и на экранах журнала, прогноза и графиков инструментов, при этом карточка MUST обозначать эту сумму именно как фактически исполненную, а не прогнозную. В режиме одного Brokerage Account страница MUST NOT добавлять внешние группировочные карточки или заголовки по Instrument либо валюте, subtotals инструмента или количество выплат инструмента. В режиме «Все счета» записи раздела «Выплаты» MUST группироваться по тем же правилам ключа, состава, порядка и итога, что и записи журнала по Requirements «All-accounts ledger groups same-day entries of one instrument», «All-accounts ledger group shows each entry and an exact total» и «All-accounts ledger grouping preserves order and limits» capability `brokerage-account-ledger`. Каждая запись при этом MUST оставаться отдельной сразу видимой карточкой внутри группы, а итог группы MUST NOT показываться, пока полнота периода не подтверждена; заголовки валютных групп и receipt count MUST NOT добавляться. Список MUST сохранять отрицательные корректировки и повторяющиеся operation IDs как отдельные записи и MUST NOT включать записи вне аналитического итога. Backend MUST обеспечивать согласованность entries, instrumentKey, валюты и receipt count при формировании ответа из одного набора записей. Frontend SHALL доверять типизированному contract без второго runtime consistency validator и MUST NOT пересчитывать аналитические денежные итоги. Единственное исключение — итог визуальной группы режима «Все счета»: это точная сумма показанных записей группы по каждой валюте, и он MUST NOT подменять аналитические итоги.
+
+#### Scenario: Каждая выплата показана отдельной карточкой
+
+- **WHEN** в режиме одного Brokerage Account выбранный период содержит несколько включённых Ledger Entries одного или разных Instrument
+- **THEN** раздел «Выплаты» сразу показывает отдельную карточку каждой записи в исходном порядке без внешних группировочных блоков, раскрытия, итогов инструмента и receipt count на UI
+
+#### Scenario: Список воспроизводит точный состав дохода
+
+- **WHEN** User просматривает загруженный раздел «Выплаты»
+- **THEN** он видит все и только включённые coupon и dividend Ledger Entries применённого периода с датой, описанием, доступной identity и исходной суммой, обозначенной как исполненная выплата
+
+#### Scenario: Отрицательная корректировка и повторяющиеся IDs сохраняются
+
+- **WHEN** доход содержит отрицательную корректировку либо несколько включённых entries с одинаковым operation ID
+- **THEN** каждая запись остаётся отдельной карточкой, а корректировка отображается с исходным знаком
+
+#### Scenario: Валюта видна в сумме каждой выплаты
+
+- **WHEN** подходящие в режиме одного Brokerage Account выплаты одного Instrument представлены в нескольких исходных валютах
+- **THEN** каждая карточка показывает свою Money с исходной валютой, без отдельного заголовка валютной группы или объединённого мультивалютного итога
+
+#### Scenario: Выплаты одной бумаги на двух счетах в режиме «Все счета»
+
+- **WHEN** в режиме «Все счета» за один день получены купон по облигации на брокерском счёте +200 RUB и купон по той же облигации на ИИС +100 RUB
+- **THEN** раздел «Выплаты» показывает их одной группой с итогом +300 RUB, внутри которой видны отдельные карточки каждого счёта, а аналитические итоги страницы не меняются
@@ -0,0 +1,170 @@
+## MODIFIED Requirements
+
+### Requirement: User can retrieve an account ledger
+Система MUST предоставлять аутентифицированный журнал только для чтения выбранного Brokerage Account либо существующего режима «Все счета» (`all`) в границах текущего User и его T-Bank connection. В режиме `all` доступ MUST проверяться для каждого входящего счёта, операции MUST сохранять принадлежность исходному счёту, а полнота периода MUST учитывать покрытие каждого входящего счёта. Журнал MUST содержать только исполненные операции T-Bank и при отсутствии периода по умолчанию охватывать интервал от начала текущего календарного года в UTC до момента запроса.
+
+Система MUST читать сохранённые операции и локальное подтверждение доступа текущего подключения без синхронного обращения к T-Bank, включая запрос списка счетов. Ответ MUST содержать envelope `{ data, meta }` по `tbank-data-sync`, отражающий полноту запрошенного периода независимо от текущей страницы. Отсутствующие данные MUST возвращаться с `data: null` и состоянием загрузки, а частично сохранённый период MUST обозначаться как `partial`. Только подтверждённо полный пустой период MUST обозначать отсутствие операций.
+
+#### Scenario: Получение журнала с периодом по умолчанию
+- **WHEN** аутентифицированный User запрашивает журнал принадлежащего ему Brokerage Account без периода
+- **THEN** система возвращает сохранённые исполненные операции в `data` и полноту периода в `meta` за период от начала текущего календарного года в UTC до момента запроса, запрашивая отсутствующие интервалы в фоне
+
+#### Scenario: Отклонение недоступного счёта
+- **WHEN** аутентифицированный User запрашивает журнал счёта, для которого локальные данные текущего подключения подтверждают отсутствие доступа либо неподдерживаемое или закрытое состояние
+- **THEN** система возвращает существующий ответ о недоступности счёта и не раскрывает операции
+
+#### Scenario: Общий журнал сохраняет принадлежность записей
+- **WHEN** аутентифицированный User запрашивает журнал в режиме `all`
+- **THEN** система возвращает исполненные операции доступных ему счетов, и каждая запись указывает свой исходный счёт
+
+#### Scenario: Общий журнал содержит неполный счёт
+- **WHEN** User запрашивает режим `all` и у одного из разрешённых счетов есть незагруженный интервал периода
+- **THEN** система возвращает только разрешённые сохранённые записи с принадлежностью счёту и обозначает общий период неполным, не подменяя отсутствующий вклад пустым счётом
+
+#### Scenario: Пустая загруженная часть не доказывает отсутствие операций
+- **WHEN** в сохранённой части периода нет записей, но покрытие периода не завершено
+- **THEN** ответ обозначает неполноту и запрошенную загрузку, а интерфейс не сообщает, что операций за период нет
+
+### Requirement: Account overview includes recent ledger events
+
+Обзор счёта MUST показывать пять последних исполненных записей журнала этого
+счёта, а в режиме «Все счета» — пять последних записей всех входящих счетов, и действие перехода к его полному журналу. Каждая запись MUST иметь ту же
+визуальную идентичность инструмента и семантику денежного движения, что и запись
+полного журнала; в группе режима «Все счета» визуальная идентичность, дата и тип
+показываются в заголовке группы. Неуспешный или пустой запрос MUST оставаться локальным состоянием
+блока и MUST NOT заменять успешно отображённый Portfolio. При временном сбое
+обновления блок MUST сохранять доступные записи без технического предупреждения
+или ручного повтора. При отсутствии результата он SHALL показывать первичное
+ожидание либо нейтральную недоступность, автоматически восстанавливая чтение.
+Неподтверждённая пустота MUST NOT представляться отсутствием операций.
+
+#### Scenario: Отображение последних событий
+- **WHEN** загружается обзор счёта и его журнал содержит исполненные операции
+- **THEN** обзор показывает не более пяти последних записей и ссылку на полный журнал
+
+#### Scenario: Последние записи недоступны
+- **WHEN** обзор счёта успешно загружается, но запрос последних записей завершается временной ошибкой
+- **THEN** Portfolio остаётся доступным, а блок сохраняет прежние записи либо показывает нейтральную недоступность без технического повтора и восстанавливается автоматически
+
+#### Scenario: Последняя запись не содержит visual metadata инструмента
+- **WHEN** одна из последних записей не имеет доступной presentation metadata инструмента
+- **THEN** обзор показывает для неё понятный текстовый fallback и сохраняет дату, тип, инструмент и денежное изменение записи доступными для чтения
+
+### Requirement: Full ledger presents compact rows
+
+Страница полного журнала MUST показывать для каждой записи дату, тип операции, инструмент и денежное изменение в исходной валюте в компактной структурированной строке. При доступной presentation metadata инструмента строка MUST показывать его визуальную идентичность; при её отсутствии MUST использовать понятный текстовый fallback. Для купонных и дивидендных операций на странице полного журнала и в личной истории инструмента MUST использоваться то же представление выплаты, что в доходе, прогнозе и графиках инструментов, с обозначением исполненного движения. Для каждой записи денежное изменение в исходной валюте MUST сопровождаться подписью конкретного типа события и знаком: для купонной операции — «Купон», для дивидендной — «Дивиденд», для остальных записей — подпись их категории («Сделка», «Налог», «Комиссия», «Перевод», «Прочее»). Строка MUST NOT повторять подпись типа события во вторичной метадате записи. Знак «+» / «−» и семантический цвет MUST оставаться носителями направления и MUST NOT заменяться только текстом. Страница MUST обозначать записи без движения денег нейтрально и MUST NOT показывать цену или количество. В группе режима «Все счета» дата, тип операции, инструмент и его визуальная идентичность MUST показываться один раз в заголовке группы, а строка каждой записи группы MUST показывать её счёт и денежное изменение с подписью типа и знаком.
+
+#### Scenario: Отображение записи только с инструментом
+
+- **WHEN** полный журнал отображает запись без денежной выплаты
+- **THEN** страница определяет её как запись без движения денег
+
+#### Scenario: Отображение поступления
+
+- **WHEN** полный журнал отображает запись с положительной денежной выплатой
+- **THEN** строка явно показывает поступление знаком и подписью конкретного типа события («Купон», «Дивиденд» или категории) и его денежное изменение в исходной валюте, не полагаясь только на цвет
+
+#### Scenario: Отображение списания
+
+- **WHEN** полный журнал отображает запись с отрицательной денежной выплатой
+- **THEN** строка явно показывает списание знаком и подписью конкретного типа события («Купон», «Дивиденд» или категории) и его денежное изменение в исходной валюте, не полагаясь только на цвет
+
+#### Scenario: Отображение купона
+
+- **WHEN** полный журнал или личная история инструмента отображает исполненную операцию с upstream-типом купона
+- **THEN** запись показывает подпись «Купон» и исполненную сумму в том же представлении выплаты, что на других экранах
+
+#### Scenario: Отображение дивиденда
+
+- **WHEN** полный журнал или личная история инструмента отображает исполненную операцию с upstream-типом дивиденда
+- **THEN** запись показывает подпись «Дивиденд» и исполненную сумму в том же представлении выплаты, что на других экранах
+
+#### Scenario: Подпись типа не дублируется
+
+- **WHEN** полный журнал отображает запись с типом события и вторичной метадатой
+- **THEN** подпись типа события присутствует в строке один раз и не повторяется во вторичной метадате записи
+
+#### Scenario: Отсутствует visual metadata инструмента
+
+- **WHEN** полный журнал отображает запись без доступной presentation metadata инструмента
+- **THEN** строка показывает понятный текстовый fallback без подмены или сокрытия доступных данных инструмента
+
+#### Scenario: Запись внутри группы режима «Все счета»
+
+- **WHEN** полный журнал в режиме «Все счета» показывает запись в составе группы
+- **THEN** её дата, тип и инструмент читаются из заголовка группы, а строка записи показывает счёт и денежное изменение со знаком и подписью типа
+
+## ADDED Requirements
+
+### Requirement: All-accounts ledger groups same-day entries of one instrument
+В режиме «Все счета» полный журнал и последние записи обзора MUST объединять в визуальную группу две и более показанных записи с одинаковыми днём (как на экране), identity Instrument и точным upstream-типом операции, даже если они на одном счёте. Записи без Instrument или без пары MUST показываться как раньше. В режиме одного Brokerage Account группировка MUST NOT применяться.
+
+#### Scenario: Купоны одной облигации на двух счетах
+- **WHEN** в режиме «Все счета» журнал показывает за один день купон по облигации на брокерском счёте +200 RUB и купон по той же облигации на ИИС +100 RUB
+- **THEN** они показаны одной группой с облигацией, типом «Купон» и итогом +300 RUB, а под заголовком видны строки «брокерский счёт +200 RUB» и «ИИС +100 RUB»
+
+#### Scenario: Две операции одного типа на одном счёте
+- **WHEN** в режиме «Все счета» журнал показывает за один день две покупки одной бумаги на одном счёте
+- **THEN** они показаны одной группой, где каждая покупка остаётся отдельной строкой со своим денежным изменением
+
+#### Scenario: Разные типы по одной бумаге не объединяются
+- **WHEN** в режиме «Все счета» за один день по одной облигации есть купон и налог с этого купона
+- **THEN** купоны и налоги показаны раздельно, и ни одна группа не содержит записи разных типов
+
+#### Scenario: Покупка и продажа не объединяются
+- **WHEN** в режиме «Все счета» за один день показаны покупка и продажа одной бумаги
+- **THEN** они не входят в одну группу
+
+#### Scenario: Разные дни не объединяются
+- **WHEN** в режиме «Все счета» купоны по одной облигации на двух счетах датированы на экране разными днями
+- **THEN** они показаны отдельными записями без группы
+
+#### Scenario: Запись без Instrument
+- **WHEN** в режиме «Все счета» за один день показаны две записи одного типа без identity Instrument
+- **THEN** они показаны отдельными записями так же, как без группировки
+
+#### Scenario: Режим одного счёта не меняется
+- **WHEN** User открывает журнал или обзор одного Brokerage Account, где есть два купона по одной облигации за один день
+- **THEN** записи показаны отдельными строками без группы, как до изменения
+
+### Requirement: All-accounts ledger group shows each entry and an exact total
+Заголовок группы журнала MUST показывать дату, Instrument с визуальной идентичностью, подпись типа операции, как в строке журнала, и итог. Под ним MUST всегда быть видна, без раскрытия, отдельная строка каждой записи со счётом и денежным изменением. Итог SHALL быть точной суммой со знаком по каждой исходной валюте без конвертации и округления. Итог MUST NOT показываться, если у записи группы нет денежного изменения (включая нулевое) или полнота периода не подтверждена.
+
+#### Scenario: Итог по нескольким валютам
+- **WHEN** группа содержит записи с денежными изменениями в RUB и в USD
+- **THEN** заголовок показывает отдельный точный итог в RUB и отдельный в USD, без конвертации
+
+#### Scenario: Итог со знаком
+- **WHEN** группа содержит поступление +150.10 RUB и отрицательную корректировку −50.05 RUB
+- **THEN** итог группы равен +100.05 RUB, а обе записи видны отдельными строками со своими знаками
+
+#### Scenario: Нулевой итог
+- **WHEN** группа содержит +150.10 RUB и −150.10 RUB
+- **THEN** заголовок показывает итог 0 RUB без знака направления, а обе записи видны со своими знаками
+
+#### Scenario: Группа с записью без денежного изменения
+- **WHEN** у одной из записей группы нет денежного изменения
+- **THEN** заголовок группы не показывает итог, а записи остаются видны отдельными строками
+
+#### Scenario: Запись с нулевой суммой скрывает итог
+- **WHEN** группа содержит запись +100 RUB и запись с денежным изменением 0 RUB
+- **THEN** заголовок группы не показывает итог, а запись с нулём обозначена как запись без движения денег
+
+#### Scenario: Итог скрыт при неполном периоде
+- **WHEN** журнал в режиме «Все счета» показывает группу, а период обозначен как `partial`
+- **THEN** заголовок группы не показывает итог, а записи группы остаются видны со своими суммами
+
+### Requirement: All-accounts ledger grouping preserves order and limits
+Группа журнала MUST занимать позицию своей первой записи в серверном порядке; записи внутри группы и остальные строки MUST сохранять относительный серверный порядок. Группировка MUST NOT менять состав, фильтрацию, пагинацию или лимит обзора, который считается по записям. Группа собирается только из показанных записей; это осознанное исключение: её итог относится только к ним и не сопровождается пометкой о неполноте.
+
+#### Scenario: Позиция группы в списке
+- **WHEN** серверный порядок записей A, B, C, где A и C образуют группу, а B не входит ни в одну группу
+- **THEN** список показывает группу (A, C) на месте A, затем B
+
+#### Scenario: Группа на границе страницы
+- **WHEN** записи одной группы попадают на текущую и на ещё не показанную страницу журнала при подтверждённой полноте периода
+- **THEN** группа на текущей странице содержит только её показанные записи, итог равен их сумме, и заголовок не содержит пометки о неполноте
+
+#### Scenario: Группировка в последних записях обзора
+- **WHEN** в режиме «Все счета» среди пяти последних записей есть две записи с одинаковым ключом
+- **THEN** блок обзора показывает те же пять записей, что и без группировки, две из них одной группой
@@ -0,0 +1,100 @@
+## MODIFIED Requirements
+
+### Requirement: Account page presents an upcoming events list
+
+Страница Brokerage Account MUST предоставлять действие перехода на отдельную
+страницу «Будущие события». Эта страница MUST показывать все полученные события
+компактным списком без фильтров, пагинации и суммарного итога списка, с датой, типом,
+инструментом и прогнозной суммой в исходной валюте, если она известна. Прогнозный итог
+визуальной группы режима «Все счета» не является суммарным итогом списка. Страница
+MUST объяснять, что прогноз основан на позиции счёта, указан до налогов и может
+быть неполным из-за доступности данных источника. Это предметное ограничение
+прогноза MUST NOT превращаться в отчёт о технической синхронизации.
+
+При временном сбое обновления страница MUST сохранять ранее доступный результат
+той же выборки с его исходными `calculatedAt` и окном, без индикации
+собственного чтения и ручного повтора. Состояние источника из `meta`, включая
+неуспех последней часовой попытки и неполноту, MUST представляться по
+`frontend-data-resilience`. При отсутствии результата SHALL показываться
+первичное ожидание либо нейтральная недоступность с автоматическим
+восстановлением по `frontend-data-resilience`. Подтверждённая потеря доступа
+MUST скрывать личные данные независимо от наличия сохранённого результата.
+
+#### Scenario: Просмотр ближайших событий
+- **WHEN** User открывает «Будущие события» из обзора Brokerage Account
+- **THEN** он видит отсортированный список событий ближайших 30 дней, где offer обозначен без суммы
+
+#### Scenario: Пустое состояние страницы
+- **WHEN** запрос будущих событий успешно возвращает полный пустой список
+- **THEN** страница сообщает, что на ближайшие 30 дней событий не найдено, и объясняет предметные ограничения покрытия источника
+
+#### Scenario: Ошибка страницы
+- **WHEN** запрос будущих событий завершается временной ошибкой
+- **THEN** страница сохраняет доступный результат той же выборки либо показывает нейтральную недоступность без ручного повтора, восстанавливая чтение автоматически и не выдавая частичные данные за полный прогноз
+
+#### Scenario: Прогнозный дивиденд с неизвестной суммой
+- **WHEN** прогноз содержит дивиденд с известной датой реестра, но без суммы
+- **THEN** его карточка обозначает дату как дату реестра и сумму как неизвестную, не показывает нулевую или полученную выплату
+
+#### Scenario: Ошибка обновления при сохранённом прогнозе на странице
+- **WHEN** запрос будущих событий возвращает последний полный прогноз вместе с ошибкой его обновления
+- **THEN** страница показывает этот прогноз с его исходными `calculatedAt` и окном и отдельно обозначает неуспех обновления источника, не предлагая ручной повтор
+
+#### Scenario: Первая загрузка либо ошибка без сохранённого прогноза
+- **WHEN** запрос будущих событий возвращает `data: null`, а `meta` обозначает выполнение первой загрузки либо её неуспех
+- **THEN** страница показывает доступное состояние первичного ожидания либо нейтральной недоступности без частичного списка и восстанавливает чтение автоматически
+
+## ADDED Requirements
+
+### Requirement: All-accounts upcoming events group same-day events of one instrument
+В режиме «Все счета» страница «Будущие события» и ближайшие события обзора MUST объединять в визуальную группу два и более показанных Future Cash Event с одинаковыми датой и видом даты (как на экране), identity Instrument и типом события, даже если они на одном счёте. События без Instrument или без пары MUST показываться как раньше. В режиме одного Brokerage Account группировка MUST NOT применяться.
+
+#### Scenario: Прогноз купонов одной облигации на двух счетах
+- **WHEN** в режиме «Все счета» на одну дату ожидается купон по облигации на брокерском счёте 200 RUB и купон по той же облигации на ИИС 100 RUB
+- **THEN** они показаны одной группой с облигацией, типом «Купон» и прогнозным итогом 300 RUB, а под заголовком видны строки «брокерский счёт 200 RUB» и «ИИС 100 RUB»
+
+#### Scenario: Разные типы или даты не объединяются
+- **WHEN** в режиме «Все счета» по одной облигации ожидаются купон и погашение на одну дату либо купоны на разные даты
+- **THEN** ни одна группа не содержит события разных типов или разных дат
+
+#### Scenario: Событие без Instrument
+- **WHEN** в режиме «Все счета» на одну дату показаны два события одного типа без identity Instrument
+- **THEN** они показаны отдельными строками без группы
+
+#### Scenario: Режим одного счёта не меняется
+- **WHEN** User открывает «Будущие события» одного Brokerage Account
+- **THEN** события показаны отдельными строками без группы, как до изменения
+
+### Requirement: All-accounts upcoming event group shows each event and a forecast total
+Заголовок группы событий MUST показывать дату (для дивиденда — как дату реестра, если она такая), Instrument, тип и прогнозный итог. Под ним MUST всегда быть видна, без раскрытия, отдельная строка каждого события со счётом и прогнозной суммой (или пометкой о неизвестной сумме). Итог SHALL быть точной суммой со знаком по каждой валюте без конвертации и округления. Итог MUST NOT показываться, если у события группы нет суммы или полнота прогноза не подтверждена.
+
+#### Scenario: Событие с неизвестной суммой в группе
+- **WHEN** в режиме «Все счета» группа содержит дивиденд на одном счёте с известной суммой и дивиденд по той же бумаге на ту же дату на другом счёте без суммы
+- **THEN** заголовок группы не показывает итог, а строка второго счёта обозначает сумму как неизвестную
+
+#### Scenario: Оферта без сумм
+- **WHEN** в режиме «Все счета» на одну дату ожидается оферта по одной облигации на двух счетах
+- **THEN** они показаны одной группой без итога, и каждая строка показывает свой счёт
+
+#### Scenario: Прогнозный итог по нескольким валютам
+- **WHEN** группа содержит дивиденд 10 USD на одном счёте и дивиденд 200 RUB по той же бумаге на ту же дату на другом счёте
+- **THEN** заголовок показывает отдельные прогнозные итоги 10 USD и 200 RUB без конвертации
+
+#### Scenario: Прогнозный итог скрыт при неполном прогнозе
+- **WHEN** в режиме «Все счета» прогноз обозначен неполным, и на странице есть группа событий с известными суммами
+- **THEN** заголовок группы не показывает итог, а строки событий остаются видны со своими суммами
+
+#### Scenario: Группа дивидендов по дате реестра
+- **WHEN** группа содержит дивиденды, датированные датой реестра
+- **THEN** заголовок обозначает дату как дату реестра
+
+### Requirement: All-accounts upcoming event grouping preserves order and limits
+Группа событий MUST занимать позицию своего первого события в порядке ответа; события внутри группы и остальные строки MUST сохранять относительный порядок ответа. Группировка MUST NOT менять состав, окно, порядок по дате или лимит обзора, который считается по событиям; группы собираются только из показанных событий.
+
+#### Scenario: Группировка в ближайших событиях обзора
+- **WHEN** в режиме «Все счета» среди пяти ближайших событий есть два события с одинаковым ключом
+- **THEN** блок обзора показывает те же пять событий, что и без группировки, два из них одной группой
+
+#### Scenario: Позиция группы событий
+- **WHEN** порядок ответа содержит события A, B, C, где A и C образуют группу, а B не входит ни в одну группу
+- **THEN** список показывает группу (A, C) на месте A, затем B
@@ -0,0 +1,73 @@
+# Tasks
+
+## 1. Общая механика и ключи
+
+- [x] 1.1 [frontend] Implementation: чистая группировка `groupItems` и точное десятичное сложение по валютам в `shared/lib` с unit-тестами
+  - **Covers:** `brokerage-account-ledger` — `All-accounts ledger grouping preserves order and limits`, `brokerage-account-ledger` — `All-accounts ledger group shows each entry and an exact total`
+  - **Source:** design.md — D1, D3; Developer Verification Strategy (unit grouping, unit decimal/money)
+  - **Verification:** `npm run test:run -- src/shared/lib src/pages/account/model`; `npm run typecheck`
+  - **Depends on:** none
+- [x] 1.2 [frontend] Implementation: ключи группы и правило показа итога для операций и событий (день как на экране, identity, точный тип, `dateKind`), unit-тесты key adapters
+  - **Covers:** `brokerage-account-ledger` — `All-accounts ledger groups same-day entries of one instrument`, `brokerage-account-upcoming-events` — `All-accounts upcoming events group same-day events of one instrument`, `brokerage-account-upcoming-events` — `All-accounts upcoming event group shows each event and a forecast total`
+  - **Source:** design.md — D2, D3; Components and Responsibilities (`entities/broker-operation/model/display.ts`, `entities/brokerage-event/model/event-key.ts`)
+  - **Verification:** `npm run test:run -- src/entities/broker-operation src/entities/brokerage-event`
+  - **Depends on:** 1.1
+
+## 2. Представление групп
+
+- [x] 2.1 [frontend] Implementation: компоненты группы и строки счёта для операций и событий по ux-design (заголовок, вложенный список, скрытый итог, доступные имена), с component-тестами
+  - **Covers:** `brokerage-account-ledger` — `Full ledger presents compact rows`, `brokerage-account-ledger` — `All-accounts ledger group shows each entry and an exact total`, `brokerage-account-upcoming-events` — `All-accounts upcoming event group shows each event and a forecast total`
+  - **Source:** design.md — UI Implementation; ux-design.md — Information Architecture, UI States, Accessibility
+  - **Verification:** `npm run test:run -- src/entities packages/ui`; проверка в браузере на 320 px и при zoom 200%
+  - **Depends on:** 1.2
+- [x] 2.2 [frontend] Implementation: группировка в режиме `all` на страницах журнала и «Будущие события». Полнота берётся из `meta`, путь одного счёта не меняется. Route-тесты, включая pagination через MSW
+  - **Covers:** `brokerage-account-ledger` — `User can retrieve an account ledger`, `brokerage-account-ledger` — `All-accounts ledger grouping preserves order and limits`, `brokerage-account-upcoming-events` — `Account page presents an upcoming events list`, `brokerage-account-upcoming-events` — `All-accounts upcoming event grouping preserves order and limits`
+  - **Source:** design.md — D4, Components and Responsibilities (`pages/account-operations`, `pages/account-events`)
+  - **Verification:** `npm run test:run -- src/pages/account-operations src/pages/account-events`
+  - **Depends on:** 2.1
+- [x] 2.3 [frontend] Implementation: группировка в превью обзора `/accounts/all` после лимита в 5 записей, с preview-тестами
+  - **Covers:** `brokerage-account-ledger` — `Account overview includes recent ledger events`, `brokerage-account-ledger` — `All-accounts ledger grouping preserves order and limits`, `brokerage-account-upcoming-events` — `All-accounts upcoming event grouping preserves order and limits`
+  - **Source:** design.md — Components and Responsibilities (`pages/account/model/previews.ts`, `RecentOperations.view.tsx`, `BrokerageEventsPreview.tsx`)
+  - **Verification:** `npm run test:run -- src/pages/account`
+  - **Depends on:** 2.1
+- [x] 2.4 [frontend] Implementation: группировка «Выплат» в режиме `all`. Ключи повторных выплат сохраняются, серверные аналитические итоги не меняются. Route-тесты
+  - **Covers:** `brokerage-account-income-analytics` — `Income payments remain traceable to exact Ledger Entries`, `brokerage-account-income-analytics` — `Realized income analytics is account-scoped and period-bound`
+  - **Source:** design.md — Components and Responsibilities (`pages/account-income/model/display.ts`)
+  - **Verification:** `npm run test:run -- src/pages/account-income`
+  - **Depends on:** 2.1
+- [x] 2.5 [frontend] Verification: полный набор frontend gates на итоговом diff
+  - **Covers:** N/A — сводная проверка задач 1.1–2.4
+  - **Source:** design.md — Developer Verification Strategy
+  - **Verification:** `npm run verify` (после `nvm use --silent`)
+  - **Depends on:** 2.2, 2.3, 2.4
+
+## 3. Документация
+
+- [x] 3.1 [docs] Docs: обновить AS-IS страниц операций, будущих событий, дохода и режима «Все счета»
+  - **Covers:** N/A — docs отражают реализованное поведение
+  - **Source:** tasks.md — Docs Impact
+  - **Verification:** semantic review против реализации; локальные проверки docs-репозитория по его AGENTS
+  - **Depends on:** 2.5
+
+## 4. Приёмка
+
+- [x] 4.1 [frontend] Independent Review: read-only review кода против specs, ux-design и design
+  - **Covers:** N/A — проверка реализации всех ADDED и MODIFIED Requirements
+  - **Source:** process-record.md — протокол G4
+  - **Verification:** отчёт independent-reviewer без открытых blocker и major
+  - **Depends on:** 2.5
+- [x] 4.2 [frontend] QA Verification: системная проверка по qa-analysis и test-cases на локальном стенде
+  - **Covers:** N/A — проверка всех ADDED и MODIFIED Requirements по Coverage Matrix
+  - **Source:** qa-analysis.md — Coverage Matrix; test-cases/*.md
+  - **Verification:** отчёт qa-engineer по каждому TC и Scenario из матрицы
+  - **Depends on:** 2.5
+
+## Docs Impact
+
+Обновляются AS-IS страницы в `docs` (по design.md — Docs Impact):
+- `docs/domains/operations/overview.md`: группы журнала и превью; точный клиентский итог по показанным записям.
+- `docs/domains/income/upcoming-events.md`: группы полного списка и превью, `dateKind`, когда показывается прогнозный итог.
+- `docs/domains/income/overview.md`: группировка «Выплат» в режиме `all`; визуальный итог группы отдельно от серверной аналитики.
+- `docs/domains/portfolio/all-accounts.md`: группировка в общих списках только в пределах страницы, cursor protocol прежний.
+
+`docs/design/overview.md` не меняется: граница между UI foundation и предметным представлением остаётся прежней. ADR не требуется.
@@ -0,0 +1,69 @@
+# Test Cases — grouping
+
+## TC-GRP-001 — Интерливинг трёх записей одной группы в серверном порядке
+
+**Verifies:** `brokerage-account-ledger` — `All-accounts ledger groups same-day entries of one instrument` (new combination: порядок внутри группы из 3+ записей с интерливингом чужих записей)
+**Risk / Priority:** Высокий / High
+**Preconditions:** Режим «Все счета»; брокерский счёт и ИИС доступны; период подтверждённо полный.
+**Test Data:** Серверный порядок записей одного дня: A1 (купон X, Брокерский, +200 RUB), B (перевод, без Instrument), A2 (купон X, ИИС, +100 RUB), C (купон Y, Брокерский, +50 RUB), A3 (купон X, Брокерский, +150 RUB).
+**Steps:**
+1. Открыть полный журнал в режиме «Все счета» за этот день.
+2. Зафиксировать порядок групп и записей.
+**Expected Results:** Группа X (A1+A2+A3) стоит на месте A1 — до B; внутри группы порядок A1, A2, A3; затем B, затем C. Относительный порядок B и C сохранён. Итог группы +450 RUB.
+**Automation Candidate:** yes (E2E)
+
+## TC-GRP-002 — Две разные группы, записи которых чередуются
+
+**Verifies:** `brokerage-account-ledger` — `All-accounts ledger groups same-day entries of one instrument` / `All-accounts ledger grouping preserves order and limits` (new combination)
+**Risk / Priority:** Высокий / High
+**Preconditions:** Режим «Все счета», полный период.
+**Test Data:** Порядок: X1 (купон X), Y1 (дивиденд Y), X2, Y2, X3. X — облигация, Y — акция; купоны X по 100 RUB (Брокерский, ИИС, Брокерский), дивиденды Y по 50 RUB (ИИС, Брокерский).
+**Steps:**
+1. Открыть журнал «Все счета» за день.
+**Expected Results:** Две группы: группа X на месте X1 с итогом +300 RUB, группа Y на месте Y1 с итогом +100 RUB; порядок групп X → Y; внутри каждой — серверный порядок записей.
+**Automation Candidate:** yes (E2E)
+
+## TC-GRP-003 — Одна и та же бумага: figi-only identity против instrumentUid — не смешивать разные идентичности
+
+**Verifies:** `brokerage-account-ledger` — `All-accounts ledger groups same-day entries of one instrument` (new combination: строгость identity-ключа)
+**Risk / Priority:** Средний / High
+**Preconditions:** Режим «Все счета», полный период.
+**Test Data:** В один день: купон облигации Z на счёте 1 (+100 RUB, identity по figi), купон облигации Z на счёте 2 (+100 RUB, identity по instrumentUid без figi); и купон облигации W на двух счетах (+100 RUB и +50 RUB), где обе записи имеют одинаковый identity.
+**Steps:**
+1. Открыть журнал «Все счета» за день.
+**Expected Results:** Облигация W образует группу с итогом +150 RUB. Две записи облигации Z показаны отдельно: равенство identity не доказано, ключ строится по первому непустому идентификатору (design D2), а группировка без доказанного равенства не выполняется.
+**Automation Candidate:** yes (E2E со stubbed API, отложено до появления QA repo)
+
+## TC-GRP-004 — Граница дня около полуночи местного времени
+
+**Verifies:** `brokerage-account-ledger` — `All-accounts ledger groups same-day entries of one instrument` (new combination: экранный день в местном времени)
+**Risk / Priority:** Средний / Medium
+**Preconditions:** Режим «Все счета», полный период.
+**Test Data:** Купон X +100 RUB с execution time 23:59:30 Europe/Moscow и купон X +100 RUB с execution time 00:00:30 следующего календарного дня Europe/Moscow.
+**Steps:**
+1. Открыть журнал «Все счета», охватывающий оба момента.
+**Expected Results:** Экранный день определяется так же, как дата, которую строка показывает на этом экране (spec: «как на экране», design D2 — локальная timezone браузера). При timezone браузера Europe/Moscow записи показаны в разных днях и группу не образуют. Oracle — дата, показанная в строке, а не UTC-дата `occurredAt`.
+**Automation Candidate:** yes (E2E с фиксированной timezone браузера, отложено до появления QA repo)
+
+## TC-GRP-005 — Прогноз: неизвестная сумма + известные суммы в двух валютах в одной группе
+
+**Verifies:** `brokerage-account-upcoming-events` — `All-accounts upcoming event group shows each event and a forecast total` (new combination)
+**Risk / Priority:** Высокий / High
+**Preconditions:** Режим «Все счета», страница «Будущие события».
+**Test Data:** Дивиденд D: событие на Брокерском 10 USD (известно), событие на ИИС 200 RUB (известно), событие на третьем счёте без суммы; все — одна дата реестра, один точный тип.
+**Steps:**
+1. Открыть «Будущие события» в режиме «Все счета».
+**Expected Results:** Одна группа из трёх событий; строка без суммы показывает «неизвестно»; итог группы скрыт, потому что у одного события сумма неизвестна (прогноз полный, но не полностью известен по суммам); известные 10 USD и 200 RUB показаны отдельными строками, без конвертации и без общего итога. Дата в заголовке обозначена как дата реестра.
+**Automation Candidate:** yes (E2E)
+
+## TC-GRP-006 — «Выплаты» в `all`: отрицательная корректировка и дубли operation IDs внутри одной группы, аналитические итоги не меняются
+
+**Verifies:** `brokerage-account-income-analytics` — `Income payments remain traceable to exact Ledger Entries` / Scenario: Отрицательная корректировка и повторяющиеся IDs сохраняются (new combination: то же внутри группы `all`)
+**Risk / Priority:** Высокий / High
+**Preconditions:** Режим «Все счета», раздел «Выплаты», период подтверждённо полный.
+**Test Data:** За один день по облигации X: купон +200 RUB (Брокерский, opId=77), купон +100 RUB (ИИС, opId=77 — дубликат), корректировка −50 RUB (Брокерский, тот же тип). Аналитические итоги страницы зафиксированы до.
+**Steps:**
+1. Открыть «Выплаты» в режиме «Все счета» за период.
+2. Сравнить аналитические итоги с зафиксированными.
+**Expected Results:** Одна группа из трёх карточек; обе записи opId=77 — отдельные карточки; корректировка со знаком «−»; итог группы +250 RUB; валютные заголовки групп и receipt count отсутствуют; аналитические итоги страницы не пересчитаны и не изменились.
+**Automation Candidate:** yes (E2E)
@@ -0,0 +1,38 @@
+# Test Cases — pagination
+
+## TC-PAG-001 — Группа, разрезанная границей страницы журнала: конкретное содержимое страниц и переходы
+
+**Verifies:** `brokerage-account-ledger` — `All-accounts ledger grouping preserves order and limits` / Scenario: Группа на границе страницы (new combination: конкретное содержимое страниц, next/prev)
+**Risk / Priority:** Высокий / High
+**Preconditions:** Режим «Все счета»; полный период; тестовые данные строятся вокруг фактического размера страницы N, который возвращает сервер (фиксируется в момент прогона).
+**Test Data:** Серверный порядок: p1..p5 (прочие записи), X1 (купон X, +100 RUB), X2 (купон X, +150 RUB), X3 (купон X, +50 RUB), p9..p12. Размер страницы N — как у сервера; данные готовятся так, чтобы X1 был последней записью страницы 1, а X2, X3 — началом страницы 2.
+**Steps:**
+1. Открыть страницу 1 журнала; зафиксировать состав.
+2. Перейти на страницу 2.
+3. Вернуться на страницу 1.
+**Expected Results:** Страница 1 заканчивается записью X1 как обычной строкой: группы нет (для группы нужно ≥2 показанных записей), итог не показывается. Страница 2 начинается группой X2+X3 (итог +200 RUB, разбивка X2/X3), затем p9…. Возврат на страницу 1 воспроизводит тот же состав. Серверный относительный порядок нигде не нарушен; записи одной группы не «стягиваются» через границу страницы.
+**Automation Candidate:** yes (E2E)
+
+## TC-PAG-002 — Обзор «Все счета»: пять записей, шестая подходящая существует, но не показана
+
+**Verifies:** `brokerage-account-ledger` — `Account overview includes recent ledger events` / Scenario: Отображение последних событий (new combination: группа на границе лимита 5)
+**Risk / Priority:** Высокий / High
+**Preconditions:** Обзор «Все счета».
+**Test Data:** Последние 6 записей в серверном порядке (свежая → старая): X1 (купон X, ИИС, +100 RUB), p2, p3, p4, p5, X0 (купон X, Брокерский, +200 RUB — шестая, за пределами выборки). X1 и X0 приходятся на один и тот же экранный день и один точный тип — по ключу они образовали бы группу, но X0 не входит в выборку обзора.
+**Steps:**
+1. Открыть обзор «Все счета».
+2. Перейти в полный журнал.
+**Expected Results:** В обзоре ровно 5 записей; X1 не образует группу (второй записи с тем же ключом в выборке нет) и показан отдельной строкой; X0 в обзоре отсутствует. Полный журнал показывает группу X0+X1 с итогом +300 RUB на месте своей первой записи.
+**Automation Candidate:** yes (E2E)
+
+## TC-PAG-003 — Обзор «Все счета»: лимит 5 считается по записям, группа занимает одну визуальную позицию
+
+**Verifies:** `brokerage-account-ledger` — `Account overview includes recent ledger events` / Scenario: Группировка в последних записях обзора (new combination: счётчик лимита)
+**Risk / Priority:** Средний / Medium
+**Preconditions:** Обзор «Все счета».
+**Test Data:** Последние записи (свежая → старая): p1, X1 (купон X, +100 RUB), X0 (купон X, +200 RUB, тот же экранный день и точный тип), p4, p5, p6.
+**Steps:**
+1. Открыть обзор «Все счета».
+2. Посчитать визуальные позиции и проверить отсутствие p6.
+**Expected Results:** Лимит 5 считается по записям: показаны записи p1, X1, X0, p4, p5 — это 4 визуальные позиции: p1, группа X (на месте X1, итог +300 RUB, разбивка X1/X0), p4, p5. Запись p6 не показана: она шестая по счётчику записей, свободной позиции от лимита нет.
+**Automation Candidate:** yes (E2E)
@@ -0,0 +1,58 @@
+# Test Cases — totals
+
+## TC-TOT-001 — Мультивалютная группа со смешанными знаками и большой разрядностью: точный десятичный оракул
+
+**Verifies:** `brokerage-account-ledger` — `All-accounts ledger group shows each entry and an exact total` (new combination: calculated oracle)
+**Risk / Priority:** Высокий / High
+**Preconditions:** Режим «Все счета», полный период.
+**Test Data:** Один день, облигация X, точный тип «купон»: +0.1 RUB (Брокерский), +0.2 RUB (ИИС), −1500000.45 RUB (Брокерский, корректировка того же типа), +200 RUB (ИИС); плюс в той же группе день выплат USD: +0.01 USD и −0.02 USD.
+**Steps:**
+1. Открыть журнал «Все счета» за день.
+2. Прочитать итог группы по каждой валюте.
+**Expected Results:** Итог RUB = −1499800.15 (точная десятичная сумма: 0.1+0.2−1500000.45+200), без плавающей точки артефактов (не −1499800.1499999); итог USD = −0.01; два отдельных итога, без конвертации и без общего итога; каждая строка показывает свою сумму со знаком.
+**Automation Candidate:** yes (E2E)
+
+## TC-TOT-002 — Разное число знаков после запятой у записей группы
+
+**Verifies:** `brokerage-account-ledger` — `All-accounts ledger group shows each entry and an exact total` (new combination)
+**Risk / Priority:** Средний / High
+**Preconditions:** Режим «Все счета», полный период.
+**Test Data:** Группа купонов X: +100.5 RUB, +49.50 RUB, +0.005 RUB (если сервер отдаёт такую точность).
+**Steps:**
+1. Открыть журнал, прочитать итог.
+**Expected Results:** Итог = 150.005 RUB ровно, без округления до 2 знаков и без потери младшего разряда; строки показывают суммы как отданы сервером.
+**Automation Candidate:** yes (E2E)
+
+## TC-TOT-003 — Нулевой итог и запись без денежного изменения в одной группе
+
+**Verifies:** `brokerage-account-ledger` — `All-accounts ledger group shows each entry and an exact total` / Scenario: Нулевой итог; Scenario: Группа с записью без денежного изменения (new combination: обе записи в одной группе)
+**Risk / Priority:** Средний / Medium
+**Preconditions:** Режим «Все счета», полный период.
+**Test Data:** Группа X: +150.10 RUB, −150.10 RUB, запись без денежного изменения (например, только количество бумаг).
+**Steps:**
+1. Открыть журнал, прочитать группу.
+**Expected Results:** Итог группы скрыт; запись без изменения обозначена как «без движения», а не как 0 RUB; строки остаются видимыми.
+**Automation Candidate:** yes (E2E)
+
+## TC-TOT-004 — `partial` → подтверждённая полнота: итог появляется
+
+**Verifies:** `brokerage-account-ledger` — `All-accounts ledger group shows each entry and an exact total` / Scenario: Итог скрыт при неполном периоде (new combination: смена состояния)
+**Risk / Priority:** Высокий / High
+**Preconditions:** Режим «Все счета»; заглушка API (MSW/Playwright route) с управляемым `meta`.
+**Test Data:** Группа X: +200 RUB и +100 RUB. Первый ответ — `meta` с `partial` для одного из счетов; второй ответ — подтверждённая полнота.
+**Steps:**
+1. Открыть журнал с partial-ответом; зафиксировать группу.
+2. Подтвердить полноту (повторный запрос/фоновая догрузка с полной `meta`).
+**Expected Results:** При `partial`: строки видны, итог скрыт. После полноты: появляется точный итог +300 RUB; состав и порядок строк не изменились.
+**Automation Candidate:** yes (E2E)
+
+## TC-TOT-005 — Прогнозный итог при частично неизвестных суммах скрыт, при полной известности — показан по валютам
+
+**Verifies:** `brokerage-account-upcoming-events` — `All-accounts upcoming event group shows each event and a forecast total` (new combination)
+**Risk / Priority:** Средний / High
+**Preconditions:** Режим «Все счета», «Будущие события».
+**Test Data:** Два соседних дня: день 1 — купоны X на двух счетах по 100 RUB (обе суммы известны); день 2 — купоны X на двух счетах, у одной суммы нет.
+**Steps:**
+1. Открыть «Будущие события».
+**Expected Results:** Группа дня 1: итог +200 RUB. Группа дня 2: итог скрыт, строка без суммы обозначена как неизвестная. Итоги списком не сводятся.
+**Automation Candidate:** yes (E2E)
@@ -0,0 +1,211 @@
+# UX Design
+
+Задача пользователя: в режиме «Все счета» (`/accounts/all/...`) быстро увидеть, что
+несколько записей — это один и тот же факт (один день, одна бумага, один тип), понять
+общую сумму и при этом сразу видеть вклад каждого счёта. Нормативное поведение
+(ключ группы, состав, порядок, правила итога) задано в `proposal.md` и трёх spec;
+этот документ его не повторяет и не меняет, а только определяет представление.
+
+Допущение: design system — Mantine + `@wealthledger/ui` по `docs/design/overview.md`
+(семантические роли, направление несут знак и текст, не только цвет).
+
+## Requirements Covered
+
+- `brokerage-account-ledger` — `Full ledger presents compact rows` (MODIFIED, группа в полном журнале)
+- `brokerage-account-ledger` — `Account overview includes recent ledger events` (MODIFIED, группа в обзоре)
+- `brokerage-account-ledger` — `User can retrieve an account ledger` (MODIFIED, режим `all`, `partial`)
+- `brokerage-account-ledger` — `All-accounts ledger groups same-day entries of one instrument`
+- `brokerage-account-ledger` — `All-accounts ledger group shows each entry and an exact total`
+- `brokerage-account-ledger` — `All-accounts ledger grouping preserves order and limits`
+- `brokerage-account-upcoming-events` — `Account page presents an upcoming events list` (MODIFIED, прогнозный итог группы)
+- `brokerage-account-upcoming-events` — `All-accounts upcoming events group same-day events of one instrument`
+- `brokerage-account-upcoming-events` — `All-accounts upcoming event group shows each event and a forecast total`
+- `brokerage-account-upcoming-events` — `All-accounts upcoming event grouping preserves order and limits`
+- `brokerage-account-income-analytics` — `Realized income analytics is account-scoped and period-bound` (MODIFIED, режим `all`)
+- `brokerage-account-income-analytics` — `Income payments remain traceable to exact Ledger Entries` (MODIFIED, «Выплаты» в режиме `all`)
+
+## User Flows
+
+Цель пользователя — «что и сколько пришло/придёт по бумаге X и с каких счетов».
+
+1. **Просмотр списка.** Пользователь открывает любой из 4 списков в режиме «Все счета» →
+   видит заголовок группы (дата, бумага, тип, итог) → читает строки счетов под ним,
+   раскрывать ничего не нужно.
+2. **Переход к счёту.** Из строки группы (журнал, выплаты) пользователь открывает
+   `/accounts/{id}` по имени счёта; возврат — кнопкой «Назад» браузера, список и позиция
+   восстанавливаются как сейчас.
+3. **Листание журнала.** «Назад/Вперёд» меняют страницу; группа собирается заново из показанных
+   записей страницы. Пользователь не получает пометок о неполноте на границе страницы.
+4. **Обзор.** На `/accounts/all` в блоках «Ближайшие события» и «Последние операции» группа
+   занимает место первой записи; блок по-прежнему содержит не более 5 записей/событий, как сейчас.
+5. **Одиночная запись / одиночный счёт.** Запись без пары, без Instrument или любой список в
+   режиме одного счёта выглядят как сейчас; пользовательский путь не меняется.
+
+Ветвление по итогу: итог известен → показан в заголовке; итог скрыт (см. UI States) →
+пользователь складывает строки сам или смотрит на состояние страницы (`partial`-Alert).
+
+## Information Architecture
+
+Группа — один визуальный блок (рамка `Paper withBorder`) внутри существующего списка, на
+месте первой записи. Состав блока: заголовок + вложенный список строк счетов. Заголовок
+повторяет композицию текущей карточки (иконка/логотип | название и метаданные | значение),
+строка счёта — компактнее, без логотипа.
+
+Лейблы заголовка: заголовок = «`<тип>` · `<инструмент>`» (как в карточках событий/выплат),
+метаданные = дата (+ «дата реестра» для дивиденда по реестру), значение = итог,
+подпись значения = подпись типа (в событиях — «Прогноз»).
+
+### Журнал (`/accounts/all/operations`, обзор «Последние операции»)
+
+```
+┌──────────────────────────────────────────────────────────┐
+│ [logo]  Купон · X                        +300 RUB        │  заголовок
+│         12 мая 2026                      Купон           │
+│ ──────────────────────────────────────────────────────── │
+│    Брокерский                           +200 RUB  Купон │  строка
+│    ИИС                                  +100 RUB  Купон │  строка
+└──────────────────────────────────────────────────────────┘
+```
+
+Строка: имя счёта слева; справа денежное изменение со знаком и подпись типа
+(по `Full ledger presents compact rows`). Количество и цена в строках группы не показываются (Presentation Decisions, п. 3).
+Имя счёта — обычный текст во всех списках, как в текущей метадате строки (`withDetails` в этих списках не используется).
+
+### События (`/accounts/all/events`, обзор «Ближайшие события»)
+
+```
+┌──────────────────────────────────────────────────────────┐
+│ [logo]  Дивиденд · X                     10 USD          │
+│         12 мая 2026 · дата реестра       200 RUB         │  итоги по валютам
+│                                          Прогноз         │
+│ ──────────────────────────────────────────────────────── │
+│    Брокерский                            10 USD          │
+│    ИИС                                   Сумма неизвестна│
+└──────────────────────────────────────────────────────────┘
+```
+
+Пример выше показывает два разных состояния сразу; на практике итог при строке
+«Сумма неизвестна» скрыт (см. UI States). Строки счёта в событиях — только текст (ссылки
+на счёт в текущей карточке события нет).
+
+### Выплаты (`/accounts/all/income`)
+
+```
+┌──────────────────────────────────────────────────────────┐
+│ [logo]  Купон · X                        +300 RUB        │
+│         Исполнено 12 мая 2026            Купон           │
+│ ──────────────────────────────────────────────────────── │
+│ ┌──────────────────────────────────────────────────────┐ │
+│ │ Брокерский                            +200 RUB      │ │  отдельная карточка
+│ └──────────────────────────────────────────────────────┘ │  внутри группы
+│ ┌──────────────────────────────────────────────────────┐ │
+│ │ ИИС                                   +100 RUB      │ │
+│ └──────────────────────────────────────────────────────┘ │
+└──────────────────────────────────────────────────────────┘
+```
+
+В «Выплатах» spec требует «отдельную сразу видимую карточку» записи внутри группы:
+вложенные карточки без логотипа и с границей, но визуально легче внешней. Подпись «Исполнено»
+сохраняет различие факта и прогноза.
+
+Размещение в 4 списках: страница журнала и «Выплаты» — вертикальный стек с зазором `sm`;
+страница событий — тот же стек; блоки обзора — тот же компонент группы без дополнительной
+рамки блока. Позиция — по правилам порядка из spec (группа на месте первой записи).
+
+## UI States
+
+| Состояние | Представление |
+| --- | --- |
+| Одиночная запись | Как сейчас: текущая карточка, без группы и вложенного списка |
+| Группа с итогом | Заголовок с итогом `+300 RUB` (тон по знаку), строки счетов |
+| Мультивалютный итог | В заголовке столбец значений: по строке на валюту, `+150 RUB` над `+10 USD`; порядок — по первому появлению валюты в записях группы (Presentation Decisions, п. 2); без конвертации и общей суммы |
+| Итог скрыт | Значение в заголовке отсутствует; строки счетов видны. Причина: запись без суммы / событие с неизвестной суммой / период `partial`. Для экранных дикторов — скрытый текст «Итог недоступен» (без различения причин) |
+| Нулевой итог | `0 RUB` без знака, нейтральный тон; строки с их знаками |
+| Offer без сумм | Группа без итога; строки: имя счёта + «Сумма не определена» (существующий текст `events.noAmount`) |
+| Прогноз | Итог и суммы строк в событиях несут подпись «Прогноз» (существующий `payout.forecast`); тон нейтральный, как у текущей карточки прогноза |
+| Строка без денег (ledger) | Нейтральный текст `payout.noMoney`/«без движения денег» как в одиночной записи; итог группы скрыт |
+| Обзор, 5 записей | Не более 5 записей/событий, как сейчас; группа может занимать часть из них, например 2 из 5; кнопка «Все …» ведёт на полную страницу |
+| Граница страницы журнала | Группа из показанных записей, без пометки о неполноте и без «ещё N на другой странице» |
+| Loading / empty / error / partial-Alert | Не меняются: `LoadingSkeleton`, `StateView`, `Alert` и `SourceSyncStatus` из существующих страниц; группы строятся только для загруженных данных |
+
+Знак: «+» и «−» всегда в тексте; цвет (positive/negative/neutral) — дополнение.
+
+## Visual Package
+
+Решение: **reuse + один новый тонкий контейнер**. Изображения (PNG/SVG) не создаются:
+изменение — повторная композиция существующих карточек, а структура и тексты описаны
+текстовыми макетами выше; отдельный макет дал бы расхождение с живыми компонентами и
+токенами Mantine.
+
+Переиспользуется:
+
+- `EntryCard` (`@wealthledger/ui`) — заголовок группы: логотип/инициал, `title`, `metadata`
+  (дата), `value` (итог), `valueLabel` (тип/«Прогноз»), `tone`. Отличие: в `value` нужно
+  выводить несколько значений для нескольких валют (сейчас одна строка) и допустить
+  отсутствие значения.
+- `LedgerEntryRow` / `PayoutCard` (executed) — единичные записи и карточки внутри группы
+  выплат; в группе опускаются логотип, дата и название инструмента (они в заголовке).
+- `BrokerageEventCard` / `PayoutCard` (forecast) — единичные события; тексты
+  `events.type.*`, `events.noAmount`, `payout.forecast`.
+- Форматирование: `formatMoney`, `formatDate`, `instrumentLogoUrl`; тексты `ledger.noInstrument`,
+  `payout.noMoney`.
+- Токены: `--wl-color-border`, `--wl-color-subtle`, `--wl-color-surface`, `Paper withBorder`.
+
+Новое (предложение, с обоснованием «нужно показать иерархию заголовок → строки»):
+
+- Контейнер группы (рамка, заголовок, вложенный список) и компактная строка счёта
+  (имя счёта слева, сумма справа, без `Avatar`). `EntryCard` всегда рисует `Avatar`, поэтому
+  для строки счёта нужна его облегчённая форма либо отдельная разметка; выбор — за реализацией.
+  Отступ строк слева — под текстовым блоком заголовка (≈ 40 px аватар + `sm`), либо без
+  отступа на узкой ширине.
+
+## Responsive
+
+- Базовый макет — mobile-first: заголовок — сетка из трёх колонок как `EntryCard`
+  (`auto | 1fr | auto`).
+- **≥ 768 px**: заголовок в одну строку; строки счетов — имя слева, сумма и подпись справа.
+- **< 576 px (узкий мобильный)**: колонка значения заголовка переносится под название
+  (название и метаданные — вверху, итог — следующей строкой справа/слева), мультивалютный итог
+  — столбцом; название инструмента и имя счёта переносятся (`wrap`, без `lineClamp`),
+  отступ строк слева убирается. Строка счёта: имя счёта сверху, сумма с подписью типа ниже, если
+  вместе не помещаются; длинное имя счёта не обрезается.
+- Никакого горизонтального скролла; минимальная ширина — 320 px.
+- Ввод: touch и мышь; в группе нет новых целей нажатия.
+
+## Accessibility
+
+Ориентир — WCAG 2.2 AA.
+
+- **Семантика списка.** Внешний список — `<ul>`; каждая одиночная запись и каждая группа — `<li>`.
+  Внутри группы-`<li>` заголовок (обычный блок, не `<h*>`, чтобы не засорять навигацию по
+  заголовкам страницы) и вложенный `<ul>` со строками-`<li>`. Группы в обзоре — внутри уже
+  существующих секций с их заголовками.
+- **Доступное имя группы.** Вложенный `<ul>` получает `aria-label` вида: «Купон, X, 12 мая 2026,
+  итог +300 RUB» (дата, инструмент, тип, итог, мультивалютный итог — через запятую). При скрытом
+  итоге — «… итог недоступен». Для знаков в озвучке: «плюс 300 рублей», «минус …» — через
+  `aria-label` значения либо скрытый текст; сам знак в тексте остаётся.
+- **Итог скрыт.** Визуально значения нет; в DOM есть `visually-hidden` текст «Итог недоступен» и
+  он включён в имя группы. Причина скрытия `partial` уже объявляется существующим `Alert role="status"`.
+- **Фокус.** Заголовок и строки группы не фокусируемы: новых интерактивных элементов нет. Если одиночная карточка содержит ссылку, она остаётся как есть, а порядок Tab совпадает с порядком DOM.
+- **Не только цвет.** Направление передаёт знак «+»/«−» (минус как «−»), подпись типа и слова
+  «Прогноз»/«Исполнено»; цвет только усиливает. Контраст текста ≥ 4.5:1 (dimmed `gray.6` на `subtle`
+  проверить), границы групп ≥ 3:1 не требуются — это декор, смысл не теряется без границы.
+- **Динамика.** Смена страницы журнала не перемещает фокус неожиданно; пагинация — как сейчас.
+- **Масштаб.** Текст масштабируется до 200 % без потери информации (перенос строк).
+
+## Presentation Decisions
+
+Решения, которые относятся только к представлению и не меняют поведение по specs:
+
+1. **Видимая причина скрытого итога.** Видимого маркера нет. Скринридер получает текст «Итог недоступен». Строки с суммами остаются видны, так что отсутствие итога не выглядит пустотой.
+2. **Несколько валют в заголовке.** Каждая валюта на отдельной строке, в порядке первого появления в записях группы.
+3. **Количество и цена в строках сделок.** Не показываются, как и в несгруппированном журнале. Specs требуют только счёт и денежное изменение.
+4. **Ссылка на счёт.** Сохраняется текущее поведение: имя счёта — текст во всех четырёх списках.
+5. **Подпись «Исполнено» / «Прогноз».** Ставится у итога в заголовке. В строках событий подпись остаётся у суммы, как в одиночной карточке.
+6. **Дата реестра.** Применяется только к группам прогнозных событий. Исполненные выплаты датируются датой исполнения.
+
+## Findings → Specs
+
+Нет. Два пробела, найденных при проектировании, закрыты решением Change Owner и внесены в specs, G2 инвалидирован:
+- прогнозный итог скрывается, если полнота прогноза не подтверждена;
+- запись с нулевой суммой считается записью без денежного изменения и скрывает итог.
@@ -0,0 +1,2 @@
+schema: wealth-ledger-sdd-lab
+created: 2026-10-30
@@ -0,0 +1,145 @@
+# Маппинг данных
+
+## Источник и цель
+
+Документ не выбирает внутренний способ загрузки и хранения. Обозначения **PC**, **PVΔ** и правило нумерации строк — в [system-analysis.md](system-analysis.md). Requirements: `specs/openspec/changes/account-top-positions/specs/portfolio/portfolio-concentration/spec.md` (28) и `specs/openspec/changes/account-top-positions/specs/portfolio/portfolio-view/spec.md` (4). Решения владельца: [3081](https://git.personal.ksv741.ru/WealthLedger/main/issues/48#issuecomment-3081), [3082](https://git.personal.ksv741.ru/WealthLedger/main/issues/48#issuecomment-3082). Исходы получения (когда поле заменяется, сохраняется или становится `null`, когда отсчёт 24 часов начинается заново) определяет таблица PVΔ:156; здесь она не пересказывается.
+
+| Mapping | Источник (владелец) | Цель (владелец) | Направление | Trigger |
+| --- | --- | --- | --- | --- |
+| M1: сектор | `sector` Share / Bond / Etf (T-Bank) | `positions[].sector` (backend) | T-Bank → хранимое значение → HTTP Portfolio | Часовой обход по условию PVΔ:141 |
+| M2: эмитент | `asset_uid` инструмента → `AssetFull.brand.uid` / `name` (T-Bank) | `positions[].issuer` (backend) | T-Bank → хранимое значение → HTTP Portfolio | То же |
+| M3: проекция | Полный ответ Portfolio (backend — владелец API) | Разрезы, суммы, доли, подписи, имя эмитента (frontend) | HTTP Portfolio → вычисляемая проекция | Получение ответа, смена разреза или валюты; обращений к T-Bank нет |
+
+Финансовый источник не меняется: количество и цена из GetPortfolio, деньги из GetPositions; sector и issuer деньги не пересчитывают (`backend/src/modules/investments/portfolio/application/portfolio.service.ts:263-315`; `backend/src/modules/investments/portfolio/infrastructure/tbank-portfolio.mapper.ts:33-55,63-98`).
+
+### Источники-кандидаты в T-Bank
+
+Выбор между точечным запросом и пригодными ранее сохранёнными данными — design: Specs его не определяют. Сопоставление идёт по instrument UID, затем по FIGI (PVΔ:3); эмитент по названию, тикеру или ISIN не определяется.
+
+| Потребность | Кандидат и поля ответа | Подтверждение / ограничения |
+| --- | --- | --- |
+| STOCK: sector, asset UID | `ShareBy(InstrumentRequest)` → `Share.sector`, `Share.asset_uid` | RPC `backend/src/integrations/tbank/proto/contracts/instruments.proto:65`; поля `:760,:776` |
+| BOND: sector, asset UID | `BondBy(InstrumentRequest)` → `Bond.sector`, `Bond.asset_uid` | RPC `instruments.proto:24`; поля `:525,:543` |
+| FUND: sector, asset UID | `EtfBy(InstrumentRequest)` → `Etf.sector`, `Etf.asset_uid` | RPC `instruments.proto:42`; поля `:644,:657` |
+| Общая идентичность | `GetInstrumentBy` → `Instrument.uid`, `figi`, `asset_uid` | `asset_uid` есть (`instruments.proto:971`); поля `sector` в `Instrument` нет, поэтому им одним сектор не получить |
+| Бренд актива | `GetAssetBy(AssetRequest{id: asset_uid})` → `AssetFull.brand.uid`, `brand.name` | `instruments.proto:1030-1036,1051-1068,1220-1229`; `asset_uid` — ключ запроса, не значение `issuer.id` |
+| Список активов | `GetAssets` → `Asset[]` | У `Asset` нет `brand` (`instruments.proto:1075-1080`); для `issuer` не подходит |
+
+### Что уже есть в коде
+
+- GetInstrumentBy по UID и FIGI даёт общую metadata. Его `brand` — `BrandData` (`logo_name`, цвета), не `Brand` с `uid`/`name` (`backend/src/integrations/tbank/tbank.client.ts:293-305,493-509`; `backend/src/integrations/tbank/proto/contracts/common.proto:120-124`). Эмитента из `logoName` или названия инструмента получить нельзя.
+- Каталог акций и облигаций получает `ShareBy`/`BondBy` и переносит `sector`/`assetUid`; типы `TbankShare`/`TbankBond` их содержат (`backend/src/modules/investments/instruments/application/catalog-enrichment.service.ts:341-351`; `backend/src/modules/investments/instruments/application/public-instrument.ts:6-23`; `backend/src/integrations/tbank/tbank-market.types.ts:8-23,48-61`). Это отдельный источник, и пользователь не должен сначала открывать карточку инструмента.
+- `GetAssetBy` уже вызывается ради `description`; `brand` из ответа не передаётся (`backend/src/integrations/tbank/tbank.client.ts:420-429`; `backend/src/modules/investments/instruments/application/catalog-enrichment.service.ts:431-437`). `GetAssets` в TypeScript интеграции не используется.
+- **Расхождения AS-IS с нормами, которые закрывает реализация** (это требования, а не выбор):
+  - запись общей metadata считается свежей по факту завершённого lookup, без возраста (`backend/src/integrations/tbank/instrument-metadata.repository.ts:314-323`) — норма PVΔ:141 требует срок от последнего успешного получения;
+  - клиент превращает NOT_FOUND в `NotFoundException` только для `shareBy` и `getInstrumentBy`, остальные методы дают Unavailable (`backend/src/integrations/tbank/tbank.client.ts:577-583`) — по PVΔ:156 «не найдено» относится к исходу «значения нет», а не к «иной ошибке».
+
+## Маппинг полей
+
+В колонке «При ошибке» исход определяется таблицей PVΔ:156; «не найдено» и «значения нет» — один исход. Колонка не повторяет решений таблицы.
+
+| Поле цели | Поля источника | Преобразование | Единица / валюта / scale | Nullability | Default | Валидация | При ошибке |
+| --- | --- | --- | --- | --- | --- | --- | --- |
+| `position.sector` | `Share.sector` / `Bond.sector` / `Etf.sector` по типу STOCK / BOND / FUND | Обрезать пробелы по краям; пусто или только пробелы → «значения нет»; остальное как получено, без lowercase, перевода и классификации | Код, без валюты | string или null | `null` | Строка; ответ принадлежит запрошенному инструменту | По PVΔ:156; `issuer` и финансы не затрагиваются |
+| `position.sector` у остальных типов | — | Всегда `null`, получение не нужно | — | `null` | `null` | Тип позиции из нормализации | — |
+| `position.issuer.id` | `AssetFull.brand.uid` | Обрезать пробелы; перенос без перекодирования | Непрозрачный идентификатор | Только внутри объекта | Весь `issuer` = `null` | Непусто после обрезки; `AssetFull.uid` совпадает с запрошенным `asset_uid` | По PVΔ:156 |
+| `position.issuer.name` | `AssetFull.brand.name` | Обрезать пробелы; не `brand.company`, не `asset.name` | Текст | Только внутри объекта | Весь `issuer` = `null` | Непусто после обрезки | По PVΔ:156 |
+| `position.issuer` | Предыдущие две строки одного ответа | `{id, name}` только если оба пригодны, иначе «значения нет»; STOCK / BOND / FUND, включая FUND; прочие типы `null` | Объект | object или null | `null` | Частичный объект запрещён | По PVΔ:156, объект целиком |
+| Время последнего успешного получения | Исход получения | Меняется и не меняется по таблице PVΔ:156; читается условием PVΔ:141; ведётся отдельно для `sector` и `issuer` (исходы двух запросов могут различаться) | Момент времени | Нет значения до первого успешного получения | Нет | — | — |
+| Новые ключи старого Snapshot | Отсутствуют | Отдавать как `null` | — | как в контракте | `null` | Отличать от отсутствия полного Portfolio | Snapshot не отбрасывать |
+| Название сектора | `position.sector` | Точное совпадение с PC:374 → подпись; иное непустое значение → как получено; `null` → «Сектор не указан» | Текст отображения | Название непустое | Группа «Сектор не указан» | Ключ группировки — код, не подпись | Неизвестный код не объединять с `null` |
+| Название эмитента | `issuer.name` позиции с наибольшим `currentValue` среди учитываемых позиций одного `issuer.id` в выбранной валюте | Группировать по `issuer.id`; при равных наибольших значениях — меньшее название по алфавитному порядку PC:274; `null` → «Эмитент не указан» | Текст отображения | Название непустое | Группа «Эмитент не указан» | Одинаковое `name` при разных `id` не объединяет | Нет |
+| Сумма элемента / разреза | `currentValue`, `type`, `sector`, `issuer.id` | Отбор → сумма по ключу; без округления | Десятичная строка Money, одна валюта | Для учтённых элементов | Пустое состояние | Не смешивать валюты | Непригодные sector/issuer меняют группу, не сумму |
+| Доля элемента, метрика топ-5 | Сумма элемента, сумма разреза | Точное отношение; метрика — сумма точных долей первых пяти; округление только при показе | Доля → % | Нет при пустом разрезе | Пустое состояние | Знаменатель > 0 | Не делить на ноль, не выдавать NaN |
+
+**Нормализация строк.** Источник правил — PVΔ:3: сектор «как определяет T-Bank, без перекодирования», края обрезаются, значение из одних пробелов отсутствует. Регистр не меняется: `energy` и `Energy` — разные коды (PC:364 запрещает объединять разные `sector`). Для `issuer.id` Specs требуют непустоту после обрезки; обрезка возвращаемого `id` следует решению 3081 «Пробелы обрезать» и нужна, чтобы идентификатор не расщеплял группу.
+
+**Что считается «значения нет».** Таблица PVΔ:156 использует понятие, но не перечисляет признаки; mapping задаёт их для полей этого документа: нет поля `sector`, `asset_uid`, `brand` в ответе; пустая строка либо только пробелы после обрезки; пара `brand.uid` / `brand.name` непригодна. Ответ о другом инструменте или активе распознаётся несовпадением UID / FIGI / `asset_uid` с запросом (проверка UID в AS-IS: `backend/src/integrations/tbank/instrument-metadata.service.ts:141-160`).
+
+**Подписи секторов.** Нормативный справочник — PC:374: consumer, energy, financial, health_care, industrials, it, materials, real_estate, telecom, utilities, government. Это только отображение; `Brand.sector` как источник не используется. `other` остаётся `other` (PC:364).
+
+### Применимость по типу позиции
+
+| Portfolio type | `sector` | `issuer` | Участие в разрезах |
+| --- | --- | --- | --- |
+| STOCK | `Share.sector` | `AssetFull.brand` или `null` | Акции, Секторы, Эмитенты |
+| BOND | `Bond.sector` | `AssetFull.brand` или `null` | Облигации, Секторы, Эмитенты |
+| FUND | `Etf.sector` | `AssetFull.brand` или `null`; **заполняется** (PVΔ:3, решение 3081) | Только Секторы; разрез «Эмитенты» фонд отбрасывает (PC:69) |
+| CURRENCY, FUTURE, OPTION, STRUCTURED_NOTE, DIGITAL_FINANCIAL_ASSET, OTHER | Всегда `null` | Всегда `null` | Ни в одном из четырёх разрезов |
+
+Типы share → STOCK, bond → BOND, etf → FUND нормализуются mapper'ом (`backend/src/modules/investments/portfolio/infrastructure/tbank-portfolio.mapper.ts:22-31`); sector и issuer тип не меняют.
+
+## Инварианты
+
+| ID | Правило | Защищаемое Requirement |
+| --- | --- | --- |
+| I1 | Обогащение не удаляет, не объединяет и не переставляет позиции; одинаковый FIGI не означает дубликат | PVΔ:3 |
+| I2 | quantity, `currentValue`, `averagePurchasePrice`, `absoluteReturn`, `cashBalances` и агрегаты не зависят от sector/issuer; `null` не делает стоимость неизвестной. Исключение — отказ token (PVΔ:104) | PVΔ:3; PC:484 |
+| I3 | В одном разрезе позиция участвует не более одного раза; фонд попадает в «Секторы», но не в «Акции», «Облигации», «Эмитенты» | PC:69 |
+| I4 | Учитываются только позиции с `currentValue` > 0 в выбранной валюте; отрицательные и неоценённые исключаются, не берутся по модулю | PC:129 |
+| I5 | Знаменатель = сумма учитываемых позиций разреза в выбранной валюте = сумма элементов; Cash Balance и `totalsByCurrency` не участвуют; `null`-группа входит в сумму | PC:289, PC:349 |
+| I6 | «Сектор не указан» и «Эмитент не указан» ранжируются наравне с остальными, не подменяются кодом T-Bank и не сливаются с реальным значением | PC:349 |
+| I7 | До 6 элементов — все строки; от 7 — пять и «Прочее» (сумма остальных, число остальных); метрика «доля топ-5» — только при ≥ 6 элементах | PC:229, PC:324 |
+| I8 | Порядок: сумма по убыванию; при равенстве — название (цифры, латиница, кириллица), затем порядок первой позиции. Название эмитента — по позиции с наибольшим `currentValue`, при равных — меньшее по алфавиту; сумму и группировку оно не меняет | PC:274, PC:114 |
+| I9 | Точные доли дают ровно 100 %; «Прочее» = сумма долей остальных; округление только при показе; сумма показанных долей может не быть 100 % | PC:289, PC:304 |
+| I10 | Список, диаграмма и центр используют одни суммы; раскрытие «Прочее» не меняет диаграмму; в центре — сумма разреза и, при метрике, «Топ-5 · N %» | PC:254, PC:402, PC:415 |
+| I11 | Валюты вкладки — ненулевые оценки STOCK/BOND/FUND (включая отрицательные), по ISO; выбора нет при ≤ 1 валюте | PC:169, PC:184 |
+| I12 | N сноски = позиции разреза с `currentValue` `null` в любой валюте + отрицательные в выбранной; нулевые и отрицательные другой валюты не считаются; `null` sector/issuer не считается | PC:144 |
+| I13 | Название — представление, не идентификатор: разные `issuer.id` и разные `sector` не объединяются при одинаковой подписи | PC:96, PC:364 |
+| I14 | Нет учтённых элементов — пустое состояние без долей и диаграммы; сноска и выбор валюты сохраняются | PC:451 |
+| I15 | `sector` и `issuer` отличны от `null` только у STOCK/BOND/FUND; значения обрезаны; `issuer` — пара целиком | PVΔ:3 |
+| I16 | Поле и отсчёт 24 часов после получения определяются только таблицей PVΔ:156: ни один исход, кроме строк «Получено значение» и «Ответ „не найдено“ или значения нет», не меняет значение и не сдвигает отсчёт | PVΔ:156, PVΔ:141 |
+
+Доля может быть периодической дробью. Требование 100 % относится к точным суммам, а не к сумме показанных процентов; последнюю долю подгонять нельзя. Текущий frontend helper использует `Number` (`frontend/src/entities/portfolio/model/display.ts:7-24`): он задаёт стиль показа, но не доказывает достаточную точность. Способ точного расчёта — design.
+
+## Риски двойного учёта и классификации
+
+| Ситуация | Риск | Правило |
+| --- | --- | --- |
+| Обыкновенная акция, привилегированная акция и облигации с одним `brand.uid` | Разные компании либо слияние самих позиций | В «Эмитентах» суммируется один `id`; в «Акциях» и «Облигациях» позиции остаются отдельными |
+| Одна компания под разными брендами | Занижение концентрации | Разные `id` не объединять; эмитент — бренд T-Bank, а не юридическое лицо. Покрытие — Q-D1 |
+| Разные бренды с одинаковым `name` | Слияние по подписи | Два элемента (PC:96) |
+| Один `brand.uid`, разные `name` у позиций | Неоднозначное имя | Имя позиции с наибольшим `currentValue` в выбранной валюте; при равных — меньшее по алфавиту (PC:114) |
+| Фонд с тем же `brand.uid`, что у акции | Повторный учёт или учёт фонда как компании | `issuer` фонда есть в API, но «Эмитенты» его отбрасывают; в сумму эмитента фонд не входит |
+| Фонд с `sector` | Раскладка состава фонда | Используется только `Etf.sector` позиции; состав, `focus_type`, название и управляющая компания не используются |
+| Один бренд, разные сектора у акции и облигации | Подмена сектора эмитента | Каждая позиция в своём `sector`; сектор из `issuer` не выводится |
+| Государственная облигация | Классификация по типу или названию | «Государственный сектор» только при `sector` = `government` |
+| Cash, `CURRENCY` и денежный фонд | Двойной учёт денег | Cash и `CURRENCY` вне концентрации; фонд — по общим правилам |
+| Повторяющийся FIGI | Дедупликация настоящих строк | Позиции не удаляются; повтор строки upstream и повтор доставки lookup — разные явления |
+| Одна позиция в четырёх разрезах | Общий итог разрезов | Разрезы независимы, между ними не складывать |
+| Раскрытое «Прочее» | Двойной учёт остатка | Детализация той же суммы, не новые сегменты |
+
+## Ошибки преобразования
+
+| Ошибка | Распознавание | Данные |
+| --- | --- | --- |
+| Нет надёжного UID/FIGI | Отсутствие ключа | Значение не присваивается; поле остаётся прежним или `null` |
+| Ответ другого инструмента или актива | Несовпадение UID / FIGI / `asset_uid` с запросом | Исход «ответ о другом инструменте или активе» по PVΔ:156 |
+| Пустой / только пробелы `sector` | Результат обрезки | Признак «значения нет» |
+| Новый неизвестный непустой `sector` | Вне таблицы PC:374 | Не ошибка: код сохраняется и показывается как есть |
+| Нет `asset_uid`, актива или бренда | Отсутствие звена цепочки | Признак «значения нет» |
+| Пустые `brand.uid` или `brand.name` после обрезки | Непригодная пара | Признак «значения нет» для `issuer` целиком |
+| `Brand.sector` использован вместо `Share/Bond/Etf.sector` | Нарушение M1 | Ошибка маппинга, даже если значения совпадают |
+| Приведение кода к lowercase, перевод кода при выдаче | Изменённый ключ | Ошибка контракта; перевод только в подписи frontend |
+| Старый JSON без ключей | Ключей нет | `null` на HTTP-границе |
+| Потеря точности суммы, доля после округления | Нарушение I5, I9 | Округлённые подписи не служат источником данных |
+| Тип вне STOCK/BOND/FUND имеет `sector`/`issuer` | Нарушение I15 | Принудительно `null` |
+
+Сетевые ошибки, повторы, сроки и восстановление — [failure-model.md](failure-model.md).
+
+## Открытые вопросы
+
+Закрыто решениями владельца ([3081](https://git.personal.ksv741.ru/WealthLedger/main/issues/48#issuecomment-3081), [3082](https://git.personal.ksv741.ru/WealthLedger/main/issues/48#issuecomment-3082)):
+
+- Пробелы — края обрезаются, значение из одних пробелов отсутствует (PVΔ:3; 3081).
+- `issuer` у фонда — заполняется для STOCK/BOND/FUND (PVΔ:3), разрез фонд отбрасывает (PC:69) (3081).
+- Разные названия одного бренда — название позиции с наибольшим `currentValue`; при равных — по алфавиту (PC:114; 3081, 3082).
+- «Не найдено» от T-Bank — как «значения нет» (PVΔ:156; 3082).
+- Исключение из правила «справочные сведения онлайн» для сектора и бренда (PVΔ:104; 3082).
+
+Остаётся неизвестным. Это факты данных, они проверяются при реализации и решения владельца не требуют.
+
+| ID | Что неизвестно | Чем проверяется |
+| --- | --- | --- |
+| Q-D1 | Доля позиций STOCK / BOND / FUND, у которых есть пригодная пара `brand.uid` / `brand.name`; совпадает ли `brand.uid` у акций, префов и облигаций одной компании | Одноразовая read-only проверка на реальном Portfolio владельца в начале реализации: доля позиций с непустой парой и таблица «эмитент → типы бумаг». Низкое покрытие scope не меняет (`proposal.md:17`), но определяет, как будет выглядеть разрез на реальных данных |
+| Q-D2 | Какие `sector` реально отдаются для фондов и государственных облигаций | Та же проверка: список различных значений `sector` по типам со счётчиками; сверка с таблицей PC:374. Неизвестные коды обрабатываются по PC:364 и решения не требуют |
--- a/Show More
+++ b/Show More
Author	SHA1	Message	Date
codex-bot	b6a9ff2d10	spec: require RUB-only behavior (WealthLedger/main#55) (#86 ) Specs security / security (push) Successful in 8s Details Specs verify / verify (push) Successful in 11s Details	2026-11-11 09:20:25 +03:00
codex-bot	892800301b	spec: plan investment performance vs Moscow Exchange index (WealthLedger/main#54) (#85 ) Specs security / security (push) Successful in 8s Details Specs verify / verify (push) Successful in 11s Details	2026-11-08 16:30:32 +03:00
ksv741	1b20067ca7	chore(release): 0.2.1 Conventional commits / commits (pull_request) Successful in 9s Details Specs security / security (pull_request) Successful in 6s Details Specs verify / verify (pull_request) Successful in 9s Details Specs security / security (push) Successful in 6s Details Specs verify / verify (push) Successful in 9s Details	2026-11-06 07:41:32 +03:00
codex-bot	142f7aa225	spec: align Events and CURRENCY portfolio behavior (WealthLedger/specs#60 ) Specs security / security (push) Successful in 6s Details Specs verify / verify (push) Successful in 11s Details	2026-11-05 07:16:08 +03:00
codex-bot	8fc8e0a750	chore(deps): set Renovate release age, PR limit and update groups (WealthLedger/main#6) (#81 ) Specs security / security (push) Successful in 7s Details Specs verify / verify (push) Successful in 10s Details	2026-11-03 14:07:42 +03:00
codex-bot	0469756d3b	spec: allow warning and retry after exhausted read retries (WealthLedger/specs#79) (#80 ) Specs security / security (push) Successful in 7s Details Specs verify / verify (push) Successful in 10s Details	2026-11-03 07:45:09 +03:00
codex-bot	8b2b742e52	chore: drop OpenSpec CLI version pin and strict validation (WealthLedger/specs#67) (#78 ) Specs security / security (push) Successful in 6s Details Specs verify / verify (push) Successful in 9s Details Conventional commits / commits (pull_request) Canceled after 0s Details Specs security / security (pull_request) Canceled after 0s Details Specs verify / verify (pull_request) Canceled after 0s Details	2026-11-03 06:52:48 +03:00
codex-bot	aa1a57ac20	spec: treat MOEX response without requested block as source failure (WealthLedger/specs#76) (#77 ) Specs security / security (push) Successful in 7s Details Specs verify / verify (push) Successful in 12s Details	2026-11-03 06:12:27 +03:00
codex-bot	3821d9ed58	refactor: group canonical specs by domain and archive account-top-positions (#74 ) Specs security / security (push) Successful in 7s Details Specs verify / verify (push) Successful in 14s Details	2026-11-02 21:50:49 +03:00
codex-bot	1fd7e6ad97	ci: run native OpenSpec and local link validation in verify (WealthLedger/specs#2 ) Specs security / security (push) Successful in 8s Details Specs verify / verify (push) Successful in 15s Details npm run validate: toolchain check, openspec schema validate, openspec validate --all --strict, lychee --offline --include-fragments for root *.md and openspec/specs. CI verify installs the pinned CLI and sha256-pinned lychee and runs it. Closes #2	2026-11-02 21:06:17 +03:00
codex-bot	7f73de76ac	ci: check whitespace in committed PR/push range (WealthLedger/specs#2 ) Specs security / security (push) Successful in 7s Details Specs verify / verify (push) Successful in 3s Details verify ran git diff --check on a clean checkout (always no-op). Now checks PR merge-base..head or push before..after; zero before falls back to the last commit. Node setup removed from the git-only job.	2026-11-02 20:36:58 +03:00
ksv741	97f358545f	chore(release): 0.2.0 Conventional commits / commits (pull_request) Successful in 9s Details Specs security / security (pull_request) Successful in 7s Details Specs verify / verify (pull_request) Successful in 8s Details Specs security / security (push) Successful in 7s Details Specs verify / verify (push) Successful in 8s Details	2026-11-01 19:34:04 +03:00
codex-bot	c66a5cd962	spec: record account-top-positions planning and implementation (WealthLedger/main#48) (#69 ) Specs security / security (push) Successful in 7s Details Specs verify / verify (push) Successful in 9s Details	2026-11-01 19:29:11 +03:00
codex-bot	b9ec11f5ba	refactor: make sdd-lab review-driven (WealthLedger/specs#66 ) Specs security / security (push) Successful in 8s Details Specs verify / verify (push) Successful in 10s Details Replace executable schema checks with explicit review-driven readiness, add a requirement-writing profile, and incorporate review clarifications for source traceability and comparative validation.	2026-10-30 13:35:39 +03:00
codex-bot	a2d2df3b5a	spec: archive group-account-rows-by-instrument and sync canonical specs (WealthLedger/main#47) (#65 ) Specs security / security (push) Successful in 6s Details Specs verify / verify (push) Successful in 7s Details	2026-10-30 07:35:30 +03:00
codex-bot	f3a6b78461	spec: plan grouping of all-account rows by instrument (WealthLedger/main#47) (#64 ) Specs security / security (push) Successful in 7s Details Specs verify / verify (push) Successful in 9s Details	2026-10-30 07:28:31 +03:00
codex-bot	322ddf6a7f	feat: add experimental wealth-ledger-sdd-lab OpenSpec schema (#61 ) Specs security / security (push) Successful in 6s Details Specs verify / verify (push) Successful in 7s Details	2026-10-29 05:58:29 +03:00
ksv741	093185d44d	chore(release): 0.1.6 Conventional commits / commits (pull_request) Successful in 10s Details Specs security / security (pull_request) Successful in 8s Details Specs verify / verify (pull_request) Successful in 10s Details Specs security / security (push) Successful in 7s Details Specs verify / verify (push) Successful in 9s Details	2026-10-24 19:15:05 +03:00
renovate-bot	08646ff505	chore(deps): update non-major dependencies (WealthLedger/specs#56 ) Specs security / security (push) Successful in 16s Details Specs verify / verify (push) Successful in 11s Details Co-authored-by: renovate-bot <renovate-bot@ksv741.ru>	2026-10-24 19:04:54 +03:00
codex-bot	c5b9cadbbd	chore: bump Node to 24.22.1 (WealthLedger/backend#122 ) Specs security / security (push) Successful in 10s Details Specs verify / verify (push) Successful in 13s Details	2026-10-23 16:20:01 +03:00
ksv741	ab24ccc32b	chore(release): 0.1.5 Conventional commits / commits (pull_request) Successful in 10s Details Specs security / security (pull_request) Successful in 8s Details Specs verify / verify (pull_request) Successful in 10s Details Specs security / security (push) Successful in 7s Details Specs verify / verify (push) Successful in 11s Details	2026-10-18 16:24:55 +03:00
codex-bot	f0478c6d6b	spec: archive quiet-user-feedback and sync canonical specs (#50 ) Specs security / security (push) Successful in 8s Details Specs verify / verify (push) Successful in 10s Details Native archive применил 9 added и 12 modified требований без удалений; все 10 сценариев сохранены. Новый canonical spec frontend-user-feedback внесён в AI_INDEX.	2026-10-17 22:18:27 +03:00
codex-bot	5a7e319caf	spec: reconcile quiet-user-feedback with source-state requirements (#50 ) Specs security / security (push) Successful in 9s Details Specs verify / verify (push) Successful in 10s Details Переносит change quiet-user-feedback в develop и согласует его delta-блоки с текущими canonical specs. Нормативное поведение: тихое чтение клиента и видимое состояние источника из meta.	2026-10-17 21:46:58 +03:00
codex-bot	06d08e2972	chore: adopt linear git model in specs instructions (#48 ) Specs security / security (push) Successful in 7s Details Specs verify / verify (push) Successful in 10s Details	2026-10-17 14:14:17 +03:00
codex-bot	1bd6181585	spec: align user-authentication password requirement with ASCII 8-72 policy (WealthLedger/specs#46) (#47 ) Specs security / security (push) Successful in 8s Details Specs verify / verify (push) Successful in 10s Details	2026-10-16 10:47:41 +03:00
codex-bot	0a1db52baf	Merge pull request 'chore: synchronize release 0.1.4 into develop (WealthLedger/main#30)' (#45 ) from chore/30-sync-release into develop Specs security / security (push) Successful in 6s Details Specs verify / verify (push) Successful in 9s Details	2026-10-16 07:48:20 +03:00
codex-bot	5ca44d16b1	Merge pull request 'chore: bring develop into release sync branch (WealthLedger/main#30)' (#44 ) from develop into chore/30-sync-release Conventional commits / commits (pull_request) Successful in 10s Details Specs security / security (pull_request) Successful in 7s Details Specs verify / verify (pull_request) Successful in 9s Details	2026-10-16 07:41:05 +03:00
codex-bot	7da2f90e0a	chore: make OpenSpec toolchain explicit and diagnosable (WealthLedger/specs#4) (#43 ) Specs security / security (push) Successful in 7s Details Specs verify / verify (push) Successful in 11s Details Conventional commits / commits (pull_request) Successful in 10s Details Specs security / security (pull_request) Successful in 7s Details Specs verify / verify (pull_request) Successful in 9s Details	2026-10-15 06:34:41 +03:00
codex-bot	7ebfc510af	spec: clarify SDD applies only on explicit request (WealthLedger/specs#1 ) Specs security / security (push) Successful in 8s Details Specs verify / verify (push) Successful in 10s Details	2026-10-14 22:43:01 +03:00
codex-bot	d5d5480eed	spec: add five capability entries to AI_INDEX (WealthLedger/specs#28 ) Specs security / security (push) Canceled after 0s Details Specs verify / verify (push) Canceled after 0s Details	2026-10-14 22:43:00 +03:00
codex-bot	4b2806ead5	Merge pull request 'spec: archive three completed changes (main#33, frontend#63, screener)' (#40 ) from specs/archive-three-changes into develop Specs security / security (push) Successful in 17s Details Specs verify / verify (push) Successful in 10s Details	2026-10-14 21:46:55 +03:00
ksv741	6efb989ed9	spec: archive three completed changes (main#33, frontend#63, screener) Conventional commits / commits (pull_request) Successful in 13s Details Specs security / security (pull_request) Successful in 8s Details Specs verify / verify (pull_request) Successful in 12s Details	2026-10-14 21:40:26 +03:00
codex-bot	0ed462d157	Merge pull request 'spec: fix upcoming events date filter default and picker bounds (WealthLedger/frontend#63)' (#39 ) from specs/63-upcoming-events-date-filter into develop Specs security / security (push) Successful in 9s Details Specs verify / verify (push) Successful in 12s Details	2026-10-14 21:35:02 +03:00
ksv741	b4c0589745	spec: fix upcoming events date filter default and picker bounds (WealthLedger/frontend#63 ) Conventional commits / commits (pull_request) Successful in 14s Details Specs security / security (pull_request) Successful in 9s Details Specs verify / verify (pull_request) Successful in 11s Details	2026-10-14 21:24:13 +03:00
codex-bot	6c33c770db	Merge pull request 'ci: rerun commits proof on PR title edit (WealthLedger/specs#30)' (#38 ) from fix/30-commits-workflow-edited into develop Specs security / security (push) Successful in 34s Details Specs verify / verify (push) Successful in 11s Details	2026-10-13 20:33:44 +03:00
ksv741	4e3855fc35	ci: rerun commits proof on PR title edit (WealthLedger/specs#30 ) Conventional commits / commits (pull_request) Successful in 12s Details Specs security / security (pull_request) Successful in 8s Details Specs verify / verify (pull_request) Successful in 14s Details	2026-10-13 20:18:57 +03:00
codex-bot	6c858a8858	spec: unify income payment cards and drop period comparisons (WealthLedger/main#33) (#37 ) Specs security / security (push) Successful in 9s Details Specs verify / verify (push) Successful in 12s Details spec: unify income payment cards and drop period comparisons (WealthLedger/main#33)	2026-10-13 18:16:27 +03:00
ksv741	aae23d86f0	ci: validate release PR commits independently (WealthLedger/main#30 ) Specs security / security (push) Successful in 7s Details Specs verify / verify (push) Successful in 9s Details Conventional commits / commits (pull_request) Successful in 10s Details Specs security / security (pull_request) Successful in 6s Details Specs verify / verify (pull_request) Successful in 10s Details	2026-10-12 23:39:30 +03:00
ksv741	ebc9ca872c	chore(release): 0.1.4 Conventional commits / commits (pull_request) Failing after 11s Details Specs security / security (pull_request) Successful in 7s Details Specs verify / verify (pull_request) Successful in 10s Details	2026-10-12 23:19:12 +03:00
ksv741	fe295aa73a	spec: archive harden-hourly-sync-lifecycle change (WealthLedger/backend#56 ) Conventional commits / commits (pull_request) Successful in 10s Details Specs security / security (pull_request) Successful in 8s Details Specs verify / verify (pull_request) Successful in 9s Details Specs security / security (push) Successful in 7s Details Specs verify / verify (push) Successful in 11s Details	2026-10-12 22:52:44 +03:00
ksv741	e8e68a7ed6	Merge pull request 'spec: add harden-hourly-sync-lifecycle change (WealthLedger/backend#56)' (#33 ) from fix/56-harden-hourly-sync-lifecycle into develop Specs security / security (push) Successful in 7s Details Specs verify / verify (push) Successful in 10s Details Reviewed-on: #33	2026-10-12 22:29:16 +03:00
ksv741	77b211186c	spec: address hourly-sync review findings (WealthLedger/backend#56 ) Conventional commits / commits (pull_request) Successful in 14s Details Specs security / security (pull_request) Successful in 9s Details Specs verify / verify (pull_request) Successful in 11s Details	2026-10-12 22:19:03 +03:00
ksv741	14174a7bb3	spec: add harden-hourly-sync-lifecycle change (WealthLedger/backend#56 ) Conventional commits / commits (pull_request) Successful in 12s Details Specs security / security (pull_request) Successful in 7s Details Specs verify / verify (pull_request) Successful in 10s Details	2026-10-12 20:28:58 +03:00
codex-bot	78f01066d2	Merge pull request 'chore: align specs engineering workflow (WealthLedger/main#27)' (#32 ) from chore/27-engineering-workflow into develop Specs security / security (push) Successful in 7s Details Specs verify / verify (push) Successful in 10s Details	2026-10-12 11:00:37 +03:00
ksv741	7f12327c37	docs: pin specs workflow reference (WealthLedger/main#27 ) Conventional commits / commits (pull_request) Successful in 10s Details Specs security / security (pull_request) Successful in 8s Details Specs verify / verify (pull_request) Successful in 10s Details	2026-10-12 10:22:13 +03:00
ksv741	a29cbf6aae	fix: align specs commitlint workflow (WealthLedger/main#27 ) Conventional commits / commits (pull_request) Canceled after 0s Details Specs security / security (pull_request) Canceled after 0s Details Specs verify / verify (pull_request) Canceled after 0s Details	2026-10-12 10:21:32 +03:00
ksv741	a441b08378	chore: align specs engineering workflow (WealthLedger/main#27 ) Conventional commits / commits (pull_request) Successful in 11s Details Specs security / security (pull_request) Successful in 7s Details Specs verify / verify (pull_request) Successful in 9s Details	2026-10-12 09:21:12 +03:00
codex-bot	ea7beea863	Merge pull request 'docs: clarify specs Node bootstrap' (#31 ) from codex/issue-24-process into develop Specs security / security (push) Successful in 6s Details Specs verify / verify (push) Successful in 9s Details	2026-10-11 23:23:10 +03:00
ksv741	18518e0d2d	docs: clarify specs Node bootstrap Conventional commits / commits (pull_request) Successful in 11s Details Specs security / security (pull_request) Successful in 8s Details Specs verify / verify (pull_request) Successful in 11s Details	2026-10-11 23:06:51 +03:00
codex-bot	0b23fc3013	spec: add stock screener Specs security / security (push) Successful in 7s Details Specs verify / verify (push) Successful in 11s Details	2026-10-11 11:45:09 +03:00
ksv741	fcdc805f6c	ci: skip checks on PR metadata edits Conventional commits / commits (pull_request) Successful in 11s Details Specs security / security (pull_request) Successful in 6s Details Specs verify / verify (pull_request) Successful in 8s Details	2026-10-11 11:36:51 +03:00
ksv741	c132770fbb	ci: avoid duplicate PR checks Specs security / security (pull_request) Successful in 7s Details Specs verify / verify (pull_request) Successful in 8s Details Conventional commits / commits (pull_request) Successful in 9s Details	2026-10-11 11:24:57 +03:00
ksv741	951f1a9a20	spec: add stock screener Specs security / security (push) Successful in 7s Details Specs verify / verify (push) Successful in 9s Details Conventional commits / commits (pull_request) Successful in 12s Details Specs security / security (pull_request) Successful in 7s Details Specs verify / verify (pull_request) Successful in 9s Details	2026-10-11 11:18:21 +03:00
ksv741	329d66e767	spec: finalize wealth-ledger SDD migration Specs security / security (push) Successful in 8s Details Specs verify / verify (push) Successful in 11s Details	2026-10-09 21:14:22 +03:00
codex-bot	90edab6e33	Merge pull request 'spec: define hourly portfolio sync history' (#25 ) from release/0.1.3 into develop Specs security / security (push) Successful in 7s Details Specs verify / verify (push) Successful in 9s Details Merge hourly portfolio sync history specs	2026-10-09 09:19:38 +03:00
@@ -1 +1 @@
 .21.0
 .22.1