specs/openspec/specs/banking/manual-bank-cards/spec.md

# manual-bank-cards Specification

## Purpose
Позволяет пользователю вручную вести дебетовые банковские карты в рублях:
сохранять операции, видеть независимые балансы, исправлять записи и оценивать
месячные расходы по категориям с учётом возвратов.

## Requirements

### Requirement: Отдельный раздел ручного учёта банковских карт

Система SHALL предоставлять авторизованному пользователю раздел банковских
карт на `/cards` и просмотр отдельной своей карты на `/cards/:id`.
Раздел MUST работать без подключения T-Bank и не зависеть от доступности
инвестиционных данных. Банковские карты MUST NOT становиться брокерскими
счетами, а банковские суммы и операции MUST NOT включаться в инвестиционный
портфель, пассивный доход или прогноз выплат.

Первая версия SHALL поддерживать только ручной учёт дебетовых карт в RUB.
Автоматическая загрузка из банков, кредитные карты, другие валюты, общий
денежный баланс нескольких карт, прогнозы и бюджеты не входят в возможность.

#### Scenario: Работа без инвестиционного подключения

- **WHEN** пользователь с действующей локальной сессией, но без подключения T-Bank, открывает раздел карт
- **THEN** он может просматривать и вести свои банковские карты без перехода к подключению брокера

#### Scenario: Независимость от инвестиционных данных

- **WHEN** пользователь сохраняет банковское пополнение или расход, а инвестиционные данные временно недоступны
- **THEN** банковская операция сохраняется по правилам ручного учёта и не меняет инвестиционные суммы или пассивный доход

### Requirement: Ручное добавление независимых банковских карт

Система SHALL позволять пользователю добавить карту с названием, начальным
остатком и датой начала учёта. Название MUST содержать от 1 до 100 символов
после удаления внешних пробелов. Название банка необязательно и MUST содержать
не более 100 символов после удаления внешних пробелов. Последние четыре цифры
карты необязательны; указанное значение MUST состоять ровно из четырёх цифр.
Полный номер карты, срок действия, PIN и код безопасности не запрашиваются
и не сохраняются как реквизиты этой возможности.

Каждая карта MUST иметь собственную идентичность, баланс и историю независимо
от совпадения банка, названия или последних цифр. Пользователь SHALL иметь
возможность изменить указанные сведения о своей карте с теми же ограничениями.
Финансовые изменения начального остатка и даты начала подчиняются отдельным
требованиям исправления и архива.

#### Scenario: Добавление карты с начальным остатком

- **WHEN** пользователь сохраняет карту с допустимым названием, датой начала учёта и начальным остатком 10 000 ₽
- **THEN** карта появляется в его списке с балансом 10 000 ₽ и без вручную внесённых операций

#### Scenario: Необязательные сведения не заполнены

- **WHEN** пользователь добавляет карту без названия банка и последних четырёх цифр
- **THEN** отсутствие этих сведений не препятствует сохранению карты при корректности обязательных значений

#### Scenario: Несколько карт одного банка

- **WHEN** пользователь добавляет две карты одного банка с одинаковым названием и начальными остатками 1 000 ₽ и 2 000 ₽
- **THEN** система сохраняет две самостоятельные карты с раздельными балансами и историей

#### Scenario: Некорректные сведения карты

- **WHEN** название после удаления внешних пробелов пустое или длиннее 100 символов, название банка длиннее 100 символов либо указанные последние цифры не состоят ровно из четырёх цифр
- **THEN** система отклоняет сохранение, объясняет ошибку соответствующего поля и не создаёт или не изменяет карту

### Requirement: Точные денежные значения и проверка до сохранения

Система MUST принимать денежные значения только в RUB, с точностью не более
двух знаков после десятичного разделителя, без округления введённой суммы.
Сумма расхода, пополнения, перевода или возврата MUST быть строго положительной
и не превышать 92 233 720 368 547 758,07 ₽. Начальный остаток MUST находиться
в диапазоне от −92 233 720 368 547 758,08 ₽ до 92 233 720 368 547 758,07 ₽
включительно; ноль и отрицательный начальный остаток допустимы.

Значение, не представляющее корректную денежную сумму, неподдерживаемая
валюта, лишние десятичные знаки или выход за диапазон MUST приводить
к понятной ошибке без частичного сохранения. Применение ограничения
к каждому денежному вводу MUST NOT приводить к округлению, переполнению
или ограничению точного результата сложения уже сохранённых сумм.

#### Scenario: Нулевой и отрицательный начальный остаток

- **WHEN** пользователь сохраняет отдельные карты с начальными остатками 0 ₽ и −100 ₽
- **THEN** система сохраняет обе карты и показывает соответствующие известные балансы

#### Scenario: Неположительная сумма операции

- **WHEN** пользователь пытается внести операцию с суммой 0 ₽ или −1 ₽
- **THEN** система отклоняет операцию, сохраняя прежние историю, балансы и сводки

#### Scenario: Точность не исправляется округлением

- **WHEN** пользователь пытается сохранить начальный остаток или операцию со значением 1,001 ₽
- **THEN** система сообщает о допустимых двух десятичных знаках и не заменяет введённое значение на 1 ₽

#### Scenario: Границы денежных значений

- **WHEN** пользователь указывает верхнюю допустимую сумму операции или нижний допустимый начальный остаток
- **THEN** сами эти граничные значения принимаются, а выход за соответствующую границу на одну копейку отклоняется без изменения данных

#### Scenario: Некорректная сумма или валюта

- **WHEN** поступает попытка сохранить нечисловую сумму либо сумму в валюте, отличной от RUB
- **THEN** система объясняет ошибку и не сохраняет карту, операцию или изменение существующих данных

### Requirement: Даты начала учёта и ручных операций

Дата начала учёта и дата операции MUST быть существующими календарными датами
без времени. Сегодня определяется по Europe/Moscow. Дата начала учёта
MUST NOT быть позже сегодняшней даты. Начальный остаток означает деньги
до всех вручную внесённых операций начиная с указанной даты включительно.

Дата операции MUST находиться между датой начала учёта затронутой карты
и сегодняшним днём включительно. Для перевода ограничение MUST выполняться
для обеих карт. Ввод прошедших операций внутри этого интервала SHALL быть
доступен. Необязательное описание операции MUST содержать не более
500 символов. Сохранённая календарная дата MUST NOT сдвигаться при смене
часового пояса устройства.

#### Scenario: Операция в первый день учёта

- **WHEN** при начальном остатке 1 000 ₽ на 1 сентября пользователь вносит расход 100 ₽ с датой 1 сентября
- **THEN** расход учитывается после начального остатка и баланс становится 900 ₽

#### Scenario: Прошедшая операция

- **WHEN** пользователь вносит операцию задним числом не раньше начала учёта и не позже сегодняшнего дня
- **THEN** операция сохраняется с указанной датой и изменяет текущий баланс и сводку соответствующего месяца

#### Scenario: Недопустимая дата или описание

- **WHEN** дата не существует, находится до начала учёта или в будущем либо описание длиннее 500 символов
- **THEN** система объясняет ошибку и не сохраняет изменение

#### Scenario: Перевод до начала учёта получателя

- **WHEN** дата перевода допустима для карты-источника, но предшествует началу учёта карты-получателя
- **THEN** перевод отклоняется без изменения обеих карт

#### Scenario: Московская календарная граница

- **WHEN** на устройстве ещё предыдущий день, а в Europe/Moscow уже наступил следующий
- **THEN** допустимая сегодняшняя дата и текущий месяц определяются по Europe/Moscow, а сохранённые даты операций остаются прежними

### Requirement: Баланс определяется начальным остатком и внесёнными операциями

Баланс карты MUST равняться начальному остатку плюс денежное влияние всех
её сохранённых и не удалённых операций: пополнение и возврат увеличивают
баланс, расход уменьшает, перевод уменьшает баланс источника и увеличивает
баланс получателя. Начальный остаток MUST учитываться ровно один раз
и MUST NOT считаться расходом, возвратом или пополнением.

Баланс MUST рассчитываться точно и может быть отрицательным. Недостаточный
учётный остаток MUST NOT препятствовать сохранению корректного расхода
или перевода. Баланс MUST NOT зависеть от выбранного месяца, категории,
показанной страницы истории или нахождения карты в архиве.

Система SHALL представлять баланс как результат ручного учёта и MUST NOT
выдавать его за подтверждённый банком остаток или обещать полноту невнесённых
операций. Отдельной произвольной операции корректировки баланса SHALL NOT быть.

#### Scenario: Последовательные расходы с копейками

- **WHEN** при начальном остатке 1 ₽ сохраняются расходы 0,10 ₽ и 0,20 ₽
- **THEN** баланс составляет ровно 0,70 ₽

#### Scenario: Полное расходование и отрицательный остаток

- **WHEN** при балансе 100 ₽ пользователь сохраняет расход 100 ₽, затем расход 50 ₽
- **THEN** первая операция даёт известный баланс 0 ₽, вторая сохраняется и даёт баланс −50 ₽

#### Scenario: Начальный остаток и страница истории

- **WHEN** при начальном остатке 1 000 ₽ и расходах 100 ₽ и 200 ₽ пользователь повторно открывает карту и видит только расход 200 ₽
- **THEN** текущий баланс остаётся 700 ₽: учитываются обе операции, а начальный остаток не добавляется повторно

#### Scenario: Итог превышает границу отдельного ввода

- **WHEN** на карту с начальным остатком 92 233 720 368 547 758,07 ₽ сохраняется пополнение 0,01 ₽
- **THEN** баланс составляет точно 92 233 720 368 547 758,08 ₽ без переполнения, округления или ограничения верхней границей ввода

### Requirement: Ручное внесение расходов и пополнений

Система SHALL позволять вручную внести расход или пополнение по своей активной
карте с суммой, датой и необязательным описанием. Расход MUST иметь категорию;
если пользователь не выбирает другую, применяется его категория по умолчанию.
После успешного сохранения операция MUST появиться в истории соответствующей
карты и ровно один раз изменить её баланс.

Расход SHALL уменьшать баланс на свою сумму, пополнение SHALL увеличивать.
Категория MUST NOT изменять денежное влияние расхода. Пополнение MUST NOT
включаться в расходы, возвраты или пассивный инвестиционный доход.

#### Scenario: Расход с категорией

- **WHEN** при балансе 10 000 ₽ пользователь сохраняет расход 500 ₽ с категорией «Кафе»
- **THEN** история показывает расход 500 ₽ с этой категорией, а баланс составляет 9 500 ₽

#### Scenario: Категория по умолчанию

- **WHEN** пользователь сохраняет расход, не выбрав другую категорию
- **THEN** расход сохраняется с принадлежащей пользователю категорией по умолчанию и отображается под её текущим названием

#### Scenario: Пополнение карты

- **WHEN** при балансе −500 ₽ пользователь сохраняет пополнение 2 000 ₽
- **THEN** баланс становится 1 500 ₽, история содержит пополнение, а расходы и возвраты не меняются

#### Scenario: Независимость другой карты

- **WHEN** при балансах A 1 000 ₽ и B 2 000 ₽ пользователь сохраняет расход 125,50 ₽ по A
- **THEN** баланс A становится 874,50 ₽, а баланс и история B остаются прежними

### Requirement: Перевод между своими картами как одно действие

Система SHALL позволять одним действием внести перевод между двумя разными
активными картами одного пользователя. Сумма перевода MUST одинаково уменьшать
баланс источника и увеличивать баланс получателя. История каждой стороны
MUST показывать направление и другую карту этого перевода.

Перевод MUST сохраняться, исправляться и удаляться целиком для обеих сторон.
Нельзя сохранять только одну сторону, переводить на ту же или чужую карту.
Перевод MUST NOT увеличивать расходы или возвраты в сводках одной или всех карт.

#### Scenario: Перевод между картами

- **WHEN** при балансах A 5 000 ₽ и B 1 000 ₽ пользователь сохраняет перевод 2 000 ₽ из A в B
- **THEN** баланс A становится 3 000 ₽, баланс B — 3 000 ₽, обе истории показывают стороны одного перевода, а расходы не меняются

#### Scenario: Недостаточный остаток источника

- **WHEN** при балансах A 100 ₽ и B 0 ₽ пользователь сохраняет перевод 150 ₽ из A в B
- **THEN** перевод сохраняется целиком, баланс A становится −50 ₽, а баланс B — 150 ₽

#### Scenario: Недопустимый получатель

- **WHEN** получателем указана та же карта или карта другого пользователя
- **THEN** система отклоняет перевод без изменения историй, балансов и сводок

#### Scenario: Сбой сохранения перевода

- **WHEN** перевод не удаётся сохранить
- **THEN** система не подтверждает успех и не оставляет сохранённой только одну его сторону

### Requirement: Возврат связан с исходным расходом

Возврат SHALL ссылаться на существующий не удалённый расход той же карты.
При внесении возврата пользователь SHALL иметь возможность выбрать исходный
расход карты за любой период учёта, независимо от месяца открытого журнала.
Частичные и несколько возвратов допустимы; сумма всех не удалённых возвратов
MUST NOT превышать текущую сумму исходного расхода. Дата возврата MUST быть
не раньше даты расхода и соответствовать общим ограничениям даты карты.
При редактировании возврата проверка общей возвращённой суммы MUST заменять
его прежнюю сумму новой, не учитывая обе версии одновременно.

Возврат MUST увеличивать баланс карты и наследовать категорию исходного
расхода. Отдельный выбор категории возврата SHALL NOT предоставляться.
Изменение категории исходного расхода MUST менять категорию связанных
возвратов и результаты затронутых месячных сводок, сохраняя их суммы и даты.

#### Scenario: Частичные возвраты

- **WHEN** по расходу 1 000 ₽ пользователь последовательно сохраняет возвраты 300 ₽ и 700 ₽
- **THEN** оба возврата связаны с расходом, увеличивают баланс суммарно на 1 000 ₽ и используют его категорию

#### Scenario: Выбор покупки прошлого месяца

- **WHEN** пользователь открывает сентябрьский журнал и вносит возврат по августовской покупке
- **THEN** форма позволяет найти и выбрать исходный августовский расход этой карты без ограничения сентябрьским журналом

#### Scenario: Исправление полностью возвращённой покупки

- **WHEN** по расходу 500 ₽ сохранён единственный возврат 500 ₽ и пользователь изменяет только описание возврата
- **THEN** исправление сохраняется: общая возвращённая сумма остаётся 500 ₽, а прежняя и новая версии не складываются как два возврата

#### Scenario: Превышение возвращаемой суммы

- **WHEN** при расходе 1 000 ₽ и сохранённом возврате 800 ₽ пользователь пытается сохранить ещё 300 ₽
- **THEN** система отклоняет новый возврат без изменения существующих записей и сумм

#### Scenario: Недопустимая связь или дата возврата

- **WHEN** возврат ссылается на удалённую операцию, операцию другого вида или другой карты либо датирован раньше расхода
- **THEN** система отклоняет возврат без изменения истории, баланса и сводок

#### Scenario: Изменение категории покупки

- **WHEN** пользователь меняет категорию расхода с «Покупки» на «Здоровье», а возврат по нему произошёл в другом месяце
- **THEN** расход и возврат учитываются в категории «Здоровье» в своих месяцах с прежними денежными суммами

### Requirement: Общие для пользователя категории расходов

Система SHALL предоставлять каждому пользователю собственный общий для всех
его карт список категорий: «Продукты», «Кафе», «Такси», «Транспорт», «Жильё»,
«Здоровье», «Покупки», «Развлечения», «Другое». «Другое» является начальной
категорией по умолчанию. Категории MUST быть доступны до первого расхода.
Начальный набор MUST создаваться при успешном добавлении первой карты
пользователя и не дублироваться при добавлении следующих карт.

Пользователь SHALL иметь возможность добавлять и переименовывать любые свои
категории, включая начальные. Название MUST содержать от 1 до 80 символов
после удаления внешних пробелов и быть уникальным среди категорий пользователя
без учёта регистра. Переименование MUST сохранять идентичность категории:
все старые расходы, возвраты и сводки показывают её текущее название.
Переименование категории по умолчанию MUST сохранять её роль.
Удаление категорий и вложенные подкатегории SHALL NOT предоставляться в V1.

#### Scenario: Начальный набор и повторный вход

- **WHEN** пользователь сохраняет первую карту, затем добавляет следующую карту и повторно входит в приложение
- **THEN** после первой карты ему доступен начальный набор категорий до первого расхода, а дальнейшие действия не создают дубликатов

#### Scenario: Категория доступна на всех своих картах

- **WHEN** пользователь создаёт категорию «Питомец»
- **THEN** она доступна для расходов по всем его картам и не появляется у другого пользователя

#### Scenario: Переименование используемой начальной категории

- **WHEN** пользователь переименовывает категорию «Другое» в «Остальное»
- **THEN** прежние записи отображаются как «Остальное», суммы не меняются, а новые расходы без другого выбора используют ту же категорию «Остальное»

#### Scenario: Дублирующееся или недопустимое название

- **WHEN** пользователь пытается добавить « кафе » при существующей «Кафе», сохранить пустое после удаления пробелов название или название длиннее 80 символов
- **THEN** система объясняет ошибку и не изменяет список категорий

### Requirement: Исправление и удаление операций с согласованным пересчётом

Пользователь SHALL иметь возможность изменить сумму, дату, описание
и применимые реквизиты сохранённой операции либо удалить её. Вид операции
и связь возврата с исходным расходом MUST быть неизменны после создания.
Все затронутые карты MUST быть активны; каждое исправление MUST соблюдать
те же денежные, календарные и пользовательские ограничения, что и создание.

Обычный расход или пополнение SHALL быть переносимы на другую свою активную
карту. Расход с не удалёнными возвратами MUST NOT переноситься на другую карту,
удаляться, уменьшаться ниже суммы возвратов или сдвигаться на дату позже
любого связанного возврата. Для такого действия сначала исправляются
или удаляются мешающие возвраты. Возврат остаётся на карте исходного расхода.

Исправление или удаление MUST пересчитать балансы, историю и все затронутые
месячные сводки; изменение даты переносит влияние между соответствующими
месяцами. Исправление сторон перевода MUST учитывать его прежние и новые
карты. Удаление перевода MUST удалять обе стороны одним действием.
Повторное удаление уже удалённой собственной операции SHALL быть
безрезультатным успешным действием без повторного денежного влияния.

#### Scenario: Изменение суммы и месяца расхода

- **WHEN** пользователь меняет расход 100 ₽ за август на 150 ₽ за сентябрь
- **THEN** баланс дополнительно уменьшается на 50 ₽, август перестаёт учитывать 100 ₽, а сентябрь учитывает 150 ₽

#### Scenario: Перенос пополнения на другую карту

- **WHEN** пользователь переносит пополнение 500 ₽ с A на свою активную B с допустимой датой
- **THEN** баланс A уменьшается на 500 ₽, баланс B увеличивается на 500 ₽, а запись относится к B

#### Scenario: Изменение получателя перевода

- **WHEN** перевод 200 ₽ из A в B исправляется на перевод 300 ₽ из A в C и все три карты активны
- **THEN** прежнее влияние на B отменяется, A уменьшается дополнительно на 100 ₽, C увеличивается на 300 ₽, а обе стороны исправленного перевода сохраняются согласованно

#### Scenario: Исправление расхода ограничено возвратами

- **WHEN** для расхода 1 000 ₽ существует возврат 600 ₽ и пользователь пытается удалить расход, перенести его на другую карту, уменьшить до 500 ₽ или сдвинуть позже даты возврата
- **THEN** система отклоняет действие и объясняет необходимость сначала исправить связанные возвраты

#### Scenario: Удаление возврата и затем расхода

- **WHEN** пользователь удаляет все возвраты расхода, а затем сам расход
- **THEN** влияние каждой удалённой записи отменяется в балансе и в её месячной сводке, а ограничение удаления исходного расхода больше не действует

#### Scenario: Удаление перевода из любой стороны

- **WHEN** пользователь удаляет перевод из истории получателя и затем повторяет удаление
- **THEN** обе стороны удаляются при первом действии, денежное влияние отменяется один раз, а повторное удаление ничего не меняет

#### Scenario: Смена вида или исходного расхода

- **WHEN** пользователь пытается превратить расход в пополнение либо связать существующий возврат с другим расходом
- **THEN** изменение отклоняется без подмены вида операции или её исходной связи

### Requirement: Исправление начала ручного учёта

Пользователь SHALL иметь возможность изменить начальный остаток и дату начала
учёта активной карты. Изменение MUST проверять всю затронутую сохранённую
историю, включая стороны переводов и связанные возвраты, и отклоняться
без частичного результата, если после него какая-либо операция нарушает
действующие ограничения. Удалённые операции не ограничивают новую дату.

Изменение начального остатка SHALL пересчитывать текущий баланс, сохраняя
суммы, даты и категории операций. Оно MUST NOT создавать отдельную операцию
или изменять месячные расходы и возвраты. Пропущенное движение SHALL
исправляться внесением реальной операции с допустимой датой.

#### Scenario: Исправление начального остатка

- **WHEN** при начальном остатке 1 000 ₽ и расходах 300 ₽ пользователь меняет начальный остаток на 1 200 ₽
- **THEN** баланс становится 900 ₽, история операций не пополняется корректировкой, а месячные расходы остаются 300 ₽

#### Scenario: Новое начало противоречит истории

- **WHEN** пользователь переносит дату начала учёта с 1 на 10 сентября, а по карте сохранён расход или перевод от 5 сентября
- **THEN** система отклоняет изменение и сохраняет прежние дату, баланс и всю историю

### Requirement: Архив карт сохраняет историю

Пользователь SHALL иметь возможность архивировать свою карту при любом
балансе, включая положительный, нулевой и отрицательный, и вернуть её
из архива. Архивация MUST NOT менять деньги или операции. Обычный список
SHALL показывать активные карты; переключатель архива SHALL открывать
архивные карты и их историю.

Пока карта архивна, система MUST запрещать создание, редактирование
и удаление затрагивающих её операций, а также изменение начального остатка
и даты начала учёта. Для исправления или новой операции карту сначала
возвращают из архива. Перевод или возврат MUST требовать активного состояния
всех затронутых карт. Изменение описательных сведений карты само по себе
не является финансовой операцией.

Архивная карта MUST продолжать участвовать в исторических сводках «Все карты».
Безвозвратное удаление карты SHALL NOT предоставляться в первой версии.

#### Scenario: Архивирование с ненулевым остатком

- **WHEN** пользователь архивирует карту с балансом −500 ₽ и сохранённой историей
- **THEN** карта скрывается из обычного списка, остаётся доступной через переключатель архива с теми же балансом и историей и сохраняет вклад в сводки всех карт

#### Scenario: Финансовое действие по архивной карте

- **WHEN** пользователь пытается внести, исправить или удалить операцию либо изменить начало учёта архивной карты
- **THEN** система отклоняет действие без изменения данных и объясняет необходимость вернуть карту из архива

#### Scenario: Возврат или перевод затрагивает архив

- **WHEN** возврат относится к расходу архивной карты либо хотя бы одна прежняя или новая сторона изменяемого перевода архивна
- **THEN** финансовое действие отклоняется до возвращения всех затронутых карт из архива

#### Scenario: Возвращение карты

- **WHEN** пользователь возвращает карту из архива
- **THEN** она снова видна в обычном списке с сохранёнными данными и допускает финансовые действия по общим правилам

### Requirement: Месячный журнал и сводка расходов по категориям

Система SHALL показывать историю и месячную сводку выбранной карты, а также
месячную сводку всех банковских карт пользователя. По умолчанию выбирается
текущий месяц Europe/Moscow; пользователь SHALL иметь возможность явно выбрать
другой месяц. История карты и её сводка MUST использовать один выбранный месяц.
Операции SHALL отображаться по убыванию календарной даты со стабильным порядком
внутри даты при повторном чтении неизменившихся данных и доступом к следующим
страницам истории.

Сводка MUST показывать расходы, возвраты и итог после возвратов, а также
соответствующие суммы по категориям. Расход входит в месяц собственной даты,
возврат — в месяц даты возврата, даже если покупка была раньше.
Итог MUST равняться расходам минус возвраты и может быть отрицательным.
Начальные остатки, пополнения и переводы MUST NOT включаться в эти суммы.

Сводка MUST учитывать все подходящие не удалённые записи, а не только
текущую страницу истории. «Все карты» MUST включать активные и архивные карты
владельца. Выбор месяца и охвата MUST NOT изменять текущие балансы.
При отсутствии расходов и возвратов SHALL показываться известные нули.

#### Scenario: Месяц по умолчанию и переключение

- **WHEN** пользователь открывает карту в сентябре по Europe/Moscow и затем выбирает август
- **THEN** сначала история и сводка относятся к сентябрю, после выбора обе относятся к августу, а текущий баланс остаётся прежним

#### Scenario: Сводка расходов и переводов

- **WHEN** в месяце сохранены расходы «Кафе» 500 ₽ и «Такси» 300 ₽, пополнение 2 000 ₽ и перевод 1 000 ₽ без возвратов
- **THEN** сводка показывает расходы 800 ₽, возвраты 0 ₽, итог 800 ₽ и категории 500 ₽ и 300 ₽ без включения пополнения или перевода

#### Scenario: Возврат покупки прошлого месяца

- **WHEN** расход «Покупки» 1 000 ₽ совершён в августе, возврат 600 ₽ — в сентябре и других операций этих видов нет
- **THEN** август показывает расходы 1 000 ₽, возвраты 0 ₽ и итог 1 000 ₽, а сентябрь — расходы 0 ₽, возвраты 600 ₽ и итог −600 ₽ в той же категории

#### Scenario: Все карты включают архивные

- **WHEN** расходы активной A за месяц составили 800 ₽, архивной B — 200 ₽, а между ними ранее был перевод 1 000 ₽
- **THEN** общая сводка показывает расходы 1 000 ₽ и не добавляет перевод, независимо от переключателя архива в списке карт

#### Scenario: Несколько страниц и равные даты

- **WHEN** операции выбранного месяца занимают несколько страниц и часть операций имеет одинаковую дату
- **THEN** пользователь может просмотреть все страницы в стабильном порядке, а сводка и баланс учитывают все соответствующие записи независимо от открытой страницы

### Requirement: Изоляция пользовательских финансовых данных

Карты, категории, операции и связи между ними MUST принадлежать локальному
пользователю WealthLedger. Система MUST предоставлять чтение, создание,
изменение, удаление, архив и восстановление только владельцу с действующей
сессией. Идентификатор сам по себе MUST NOT подтверждать доступ.

Проверка владельца MUST распространяться на каждую упомянутую карту,
категорию и операцию, включая обе стороны перевода, исходный расход возврата
и новые связи при редактировании. Отказ MUST NOT раскрывать чужие финансовые
сведения или менять данные любой стороны. Сводки MUST включать только
данные текущего пользователя.

#### Scenario: Нет действующей сессии

- **WHEN** пользователь без действующей сессии пытается прочитать карты, сводку или изменить финансовые данные
- **THEN** система отказывает в доступе без раскрытия и изменения сохранённых данных

#### Scenario: Чужая карта или категория

- **WHEN** пользователь обращается к чужой карте или пытается назначить своей операции чужую категорию
- **THEN** система отклоняет действие, не раскрывает чужие сведения и не меняет баланс, историю или категории

#### Scenario: Чужая связь перевода или возврата

- **WHEN** пользователь подставляет чужую карту в перевод или чужой расход в возврат при создании либо редактировании
- **THEN** система отклоняет всё действие без сохранения частичного результата и без раскрытия данных другого пользователя

#### Scenario: Чужие исправления и архив

- **WHEN** пользователь пытается изменить или удалить чужую операцию, переименовать чужую категорию либо архивировать или восстановить чужую карту
- **THEN** система отказывает и сохраняет все данные владельца без изменений

### Requirement: Согласованные изменения и защита повторной отправки

Успешное финансовое изменение MUST согласованно сохранять операции, связи,
денежное влияние и пересчитанные результаты для всех затронутых карт.
Система MUST NOT подтверждать успех несохранённого действия или оставлять
частичный результат. Независимые одновременные операции MUST сохранять
влияние каждой успешной записи, не затирая друг друга.

Повторная отправка одного намерения создать карту или операцию с тем же
содержанием MUST приводить не более чем к одному соответствующему результату
и однократному учёту начального остатка или денежного влияния операции.
Иное содержание при повторном использовании того же намерения MUST приводить
к конфликту без изменения данных. После исправления или удаления результата
поздняя повторная отправка исходного создания MUST NOT восстанавливать
старые значения, удалённую запись или её денежное влияние.
Ответ на повтор MUST показывать актуальное состояние ранее созданной карты
или операции либо сообщать, что операция удалена, не выдавая старые данные
за текущий результат. Уже сохранённое намерение MUST NOT проверяться
как новая финансовая запись и повторно расходовать доступную сумму возврата.
Архивирование ранее созданной карты MUST NOT превращать повтор её создания
в создание другой карты или возвращение из архива.

Редактирование или удаление существующей операции и изменение карты,
основанные на её устаревшем состоянии, MUST завершаться понятным конфликтом
без перезаписи более свежих изменений. Повторное удаление уже удалённой
операции не считается перезаписью и остаётся безрезультатным действием.
Проверки суммы возвратов, состояния архива, дат и других ограничений
MUST сохраняться при одновременных действиях.

#### Scenario: Повтор после потерянного ответа

- **WHEN** создание расхода 100 ₽ успешно сохранено, ответ потерян и пользователь повторяет то же намерение с тем же содержанием
- **THEN** история содержит один расход, баланс изменён один раз, а повтор не создаёт дубликат

#### Scenario: Повтор создания карты после архивации

- **WHEN** карта с начальным остатком 1 000 ₽ создана, ответ потерян, карта затем архивирована и приходит повтор её исходного создания
- **THEN** система показывает актуальную архивную карту, не создаёт вторую карту, не дублирует начальный остаток и не возвращает карту из архива

#### Scenario: Повтор полного возврата

- **WHEN** возврат 500 ₽ полностью покрывает расход 500 ₽, успешно сохранён, но ответ потерян и пользователь повторяет то же намерение создания возврата
- **THEN** система возвращает сохранённый возврат без новой записи, повторного изменения баланса или ошибки о превышении суммы покупки

#### Scenario: Изменённое содержание того же намерения

- **WHEN** после сохранения расхода 100 ₽ повтор того же намерения содержит сумму 200 ₽
- **THEN** система сообщает о конфликте и сохраняет исходный результат без дополнительной операции

#### Scenario: Позднее создание после исправления или удаления

- **WHEN** сохранённый расход 100 ₽ исправлен на 150 ₽ или удалён, после чего приходит повтор его исходного создания
- **THEN** система показывает актуальный расход 150 ₽ либо сообщает об удалении; прежняя сумма или удалённая запись не восстанавливаются и дополнительного денежного влияния нет

#### Scenario: Два независимых расхода

- **WHEN** при балансе 1 000 ₽ расходы 100 ₽ и 200 ₽ успешно сохраняются одновременно как разные намерения
- **THEN** история содержит оба расхода, а баланс составляет 700 ₽

#### Scenario: Два возврата превышают покупку вместе

- **WHEN** для расхода 1 000 ₽ одновременно сохраняются независимые возвраты 600 ₽ и 600 ₽
- **THEN** система не допускает общей сохранённой суммы 1 200 ₽: конфликтующее действие отклоняется без частичного результата

#### Scenario: Исправление по устаревшим данным

- **WHEN** операция или карта изменилась после того, как пользователь начал её редактирование, а он отправляет изменение прежнего состояния
- **THEN** система сообщает о конфликте, сохраняет более свежие данные и позволяет получить актуальное состояние для нового исправления

#### Scenario: Удаление по устаревшим данным

- **WHEN** пользователь пытается удалить существующую операцию, которую другой успешный запрос уже изменил
- **THEN** система отклоняет устаревшее удаление без потери более свежего исправления

#### Scenario: Архивирование одновременно с финансовым изменением

- **WHEN** архивирование карты пересекается с созданием или исправлением затрагивающей её операции
- **THEN** результаты соответствуют последовательному выполнению допустимых действий и не допускают финансовую запись, выполненную после вступившего в силу архива

### Requirement: Сохранённый ручной учёт переживает повторный вход и перезапуск

Успешно сохранённые карты, начальные остатки, даты начала, операции,
категории, архивное состояние и связи возвратов и переводов MUST оставаться
доступными владельцу после обновления страницы, выхода, повторного входа
и обычного перезапуска приложения. Эти действия MUST NOT создавать
дубликаты, восстанавливать удалённые операции или сбрасывать балансы.
Защита повторной отправки сохранённых намерений MUST сохранять действие
после этих переходов.

#### Scenario: Повторный вход

- **WHEN** пользователь выходит и снова входит после сохранения карты с начальным остатком 1 000 ₽ и расходом 100 ₽
- **THEN** он видит ту же карту, дату начала, расход с его текущей категорией и баланс 900 ₽

#### Scenario: Перезапуск с переводом, возвратом и архивом

- **WHEN** приложение перезапускается после сохранения переводов, связанных возвратов, переименования категорий и архивирования карты
- **THEN** владелец получает прежние связи, названия, архивное состояние и рассчитанные суммы без дубликатов или потери истории

#### Scenario: Повтор создания после перезапуска

- **WHEN** после перезапуска повторяется намерение создания ранее сохранённой, а затем удалённой операции
- **THEN** удалённая операция и её денежное влияние не восстанавливаются

### Requirement: Доступные формы и различимые состояния без ложного успеха

Раздел SHALL различать отсутствие карт, отсутствие операций за месяц,
известный нулевой баланс, загрузку и ошибку получения данных. Ошибка
MUST NOT подменяться пустым списком или нулевой суммой. Пользователь SHALL
иметь возможность повторить неуспешную загрузку.

Формы карт, операций, исправлений и категорий MUST иметь доступные названия
полей и действий, управление с клавиатуры и понятные ошибки, связанные
с соответствующим полем или действием. Обязательность, направление денег
и ошибки MUST NOT передаваться только цветом.

Во время сохранения, ошибки и конфликта введённый черновик MUST оставаться
доступным до явного закрытия или успешного завершения. Пока результат
сохранения не подтверждён, система MUST NOT показывать введённую сумму
как подтверждённый новый баланс или выдавать действие за успешное.
При неопределённом результате после потери ответа повтор SHALL использовать
защиту того же намерения создания. После подтверждённого изменения
отображаемые история, балансы и сводки MUST согласовываться с сохранёнными
данными всех затронутых карт.

#### Scenario: Пустой список

- **WHEN** раздел успешно загружен и у пользователя ещё нет карт
- **THEN** система показывает штатное пустое состояние с доступным действием добавления карты

#### Scenario: Нет операций при ненулевом балансе

- **WHEN** в выбранном месяце нет операций, но текущий баланс карты составляет 10 000 ₽
- **THEN** история сообщает об отсутствии операций за месяц, сводка содержит нули, а текущий баланс остаётся 10 000 ₽

#### Scenario: Ошибка загрузки

- **WHEN** загрузка карт, истории или сводки завершается ошибкой
- **THEN** система показывает ошибку и действие повтора, не выдавая её за отсутствие данных или нулевой результат

#### Scenario: Доступный ввод и проверка

- **WHEN** пользователь управляет формой с клавиатуры или средством чтения экрана и вводит некорректную сумму
- **THEN** названия полей и действий доступны, ошибка суммы определима без цвета, а введённые значения остаются для исправления

#### Scenario: Ожидание и неопределённый результат

- **WHEN** пользователь отправляет перевод и ответ ещё не получен либо потерян
- **THEN** черновик сохраняется, неподтверждённые балансы не выдаются за сохранённые, а повтор того же создания не порождает второй перевод

#### Scenario: Ошибка или конфликт исправления

- **WHEN** сохранение исправления отклоняется из-за ошибки или устаревшего состояния
- **THEN** пользователь видит причину, сохраняет черновик и может получить актуальные данные для следующего действия без перезаписи чужого успешного изменения