# frontend-data-resilience Specification

## Purpose

Определяет, когда frontend сохраняет последний успешный ответ на экране и как
сообщает пользователю о неудачном фоновом обновлении без искажения доменных
состояний Portfolio.

## 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** прежние личные данные скрываются, а позднее завершение старой загрузки не восстанавливает их

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