specs/openspec/changes/archive/2026-09-09-simplify-income-page/specs/brokerage-account-income-analytics/spec.md

REMOVED Requirements

Requirement: Analytics summary and trend remain readable per currency

Reason: По согласованному Proposal блок «Динамика» удаляется вместе со сценариями дневной, недельной и месячной группировки и переключения валюты графика. Сохранение этих сценариев требовало бы показывать удаляемый блок.

Migration: Требования к читаемым итогам, разделению валют и объяснению налоговой границы перенесены в Analytics summary remains readable per currency. Удаление визуализации не меняет денежные расчёты.

Requirement: Forecast is separate from realized income

Reason: По согласованному Proposal со страницы удаляется весь блок «Ближайший прогноз» вместе со сценариями отображения его сумм, событий и локальной ошибки.

Migration: Income page excludes upcoming forecasts сохраняет отделение будущих событий от полученного дохода, независимость аналитики от доступности прогноза и доступность самостоятельной страницы «Будущие события».

Requirement: Instrument breakdown is traceable to exact Ledger Entries

Reason: По уточнению владельца удаляются внешние карточки Instrument с subtotals, combined total и receipt count, а также валютные группы. Прежние scenarios группировочного breakdown больше не описывают требуемый UI.

Migration: Income payments remain traceable to exact Ledger Entries заменяет grouping UI плоским разделом «Выплаты», сохраняя точный состав entries, signed Money, повторяющиеся IDs и внутренние membership guards.

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

ADDED Requirements

Requirement: Income payments remain traceable to exact Ledger Entries

В разделе «Выплаты» страница MUST показывать единый список карточек точных исполненных Ledger Entries применённого периода в исходном серверном порядке entries. Каждая выплата MUST иметь собственную сразу видимую карточку с описанием, датой, доступной identity Instrument и signed Money в исходной валюте. Страница MUST NOT добавлять внешние группировочные карточки или заголовки по Instrument либо валюте, subtotals инструмента или количество выплат инструмента. Список MUST сохранять отрицательные корректировки и повторяющиеся operation IDs как отдельные записи и MUST NOT включать записи вне аналитического итога. Отказ от группировочного UI MUST NOT отменять проверки принадлежности entries к instrumentKey, валюты и receipt count ответа или приводить к пересчёту денежных итогов на клиенте.

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 страница показывает итоги и существующие сравнения, но не показывает блок «Динамика», график, его переключатель валюты или текстовый список временных buckets

Requirement: Income page excludes upcoming forecasts

Страница «Пассивный доход» MUST NOT показывать блок «Ближайший прогноз», его суммы, список будущих выплат, состояния загрузки, пустоты или ошибки. Forecast values MUST NOT входить в realized total, comparisons, 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 эта страница остаётся доступной с прежним поведением независимо от отсутствия прогноза на странице дохода