Из сводки банковской карты пользователь открывает выбранную категорию и видит расходы этой карты за период: общую сумму и список покупок.
Первая итерация — только просмотр внутри одной карты, без графиков и сравнения периодов.
Пользовательский сценарий
Пользователь выбирает период на странице карты.
Нажимает на категорию в сводке карты.
Открывается отдельная страница этой категории и карты с тем же периодом.
Пользователь просматривает сумму и расходы, при необходимости меняет период или страницу списка.
Ссылку можно скопировать или обновить: выбранные параметры восстанавливаются из URL.
Переход обратно на карту сохраняет выбранный период.
Содержимое страницы
Название категории и карты, ссылка возврата на карту.
Выбор периода.
Показатель «Расходы без учёта возвратов».
Список расходов: дата, описание при наличии и сумма.
Пагинация по существующему поведению журнала карты.
Возврат не показывается и не уменьшает итог: покупка 1 000 ₽ с возвратом 300 ₽ отображается как расход 1 000 ₽, итог — 1 000 ₽. Существующая сводка карты при этом может показывать 700 ₽. Подпись показателя должна явно объяснять различие.
Критерии приёмки
Категории в сводке конкретной карты открывают соответствующую страницу; навигация доступна с клавиатуры.
На странице всегда понятны выбранная карта и категория; фильтрация использует стабильные ID, а не названия.
Период переносится со страницы карты и доступен для самостоятельного изменения.
Границы периода включены; без периода в прямой ссылке используется текущий месяц.
Период и параметры пагинации хранятся в URL; обновление страницы, прямой переход и браузерная навигация восстанавливают соответствующее состояние.
Изменение периода возвращает список на первую страницу.
Ссылка возврата на карту сохраняет выбранный период.
Отображаются только расходы выбранной карты и категории. Нет возвратов, пополнений и переводов.
Итог берётся из серверной выборки за весь период и не пересчитывается по видимой странице списка.
Используется существующий порядок журнала карты; форматирование дат и денег соответствует приложению.
Переименование категории сохраняет работоспособность ссылки и отображает актуальное название; архивная карта доступна для просмотра.
Предусмотрены загрузка, ошибка с повтором, отсутствующая/недоступная карта или категория и пустой список с итогом 0 ₽.
Нет действий добавления, редактирования и удаления операций.
API-типы получены из предоставленного backend OpenAPI snapshot по принятому направлению генерации.
Документация банковских карт обновлена: описаны переход, URL/период, режим просмотра и отличие суммы от существующей сводки.
Проверка
Проверить переход с карты с выбранным диапазоном, изменение периода, обновление/прямую ссылку и браузерную навигацию; пагинацию с неизменным общим итогом; пример 1 000 ₽ + возврат 300 ₽ → 1 000 ₽; пустой период, ошибки и отсутствие действий записи.
Проверить интерфейс и клавиатурный переход. Выполнить применимые проверки по frontend/AGENTS.md и npm run verify; команды и результаты приложить к PR.
Точки входа в реализацию
src/pages/card/ui/CardPage.vm.ts — существующее состояние периода и пагинации.
## Задача
Из сводки банковской карты пользователь открывает выбранную категорию и видит расходы этой карты за период: общую сумму и список покупок.
Первая итерация — только просмотр внутри одной карты, без графиков и сравнения периодов.
## Пользовательский сценарий
1. Пользователь выбирает период на странице карты.
2. Нажимает на категорию в сводке карты.
3. Открывается отдельная страница этой категории и карты с тем же периодом.
4. Пользователь просматривает сумму и расходы, при необходимости меняет период или страницу списка.
5. Ссылку можно скопировать или обновить: выбранные параметры восстанавливаются из URL.
6. Переход обратно на карту сохраняет выбранный период.
## Содержимое страницы
- Название категории и карты, ссылка возврата на карту.
- Выбор периода.
- Показатель **«Расходы без учёта возвратов»**.
- Список расходов: дата, описание при наличии и сумма.
- Пагинация по существующему поведению журнала карты.
Возврат не показывается и не уменьшает итог: покупка 1 000 ₽ с возвратом 300 ₽ отображается как расход 1 000 ₽, итог — 1 000 ₽. Существующая сводка карты при этом может показывать 700 ₽. Подпись показателя должна явно объяснять различие.
## Критерии приёмки
- [ ] Категории в сводке конкретной карты открывают соответствующую страницу; навигация доступна с клавиатуры.
- [ ] На странице всегда понятны выбранная карта и категория; фильтрация использует стабильные ID, а не названия.
- [ ] Период переносится со страницы карты и доступен для самостоятельного изменения.
- [ ] Границы периода включены; без периода в прямой ссылке используется текущий месяц.
- [ ] Период и параметры пагинации хранятся в URL; обновление страницы, прямой переход и браузерная навигация восстанавливают соответствующее состояние.
- [ ] Изменение периода возвращает список на первую страницу.
- [ ] Ссылка возврата на карту сохраняет выбранный период.
- [ ] Отображаются только расходы выбранной карты и категории. Нет возвратов, пополнений и переводов.
- [ ] Итог берётся из серверной выборки за весь период и не пересчитывается по видимой странице списка.
- [ ] Используется существующий порядок журнала карты; форматирование дат и денег соответствует приложению.
- [ ] Переименование категории сохраняет работоспособность ссылки и отображает актуальное название; архивная карта доступна для просмотра.
- [ ] Предусмотрены загрузка, ошибка с повтором, отсутствующая/недоступная карта или категория и пустой список с итогом 0 ₽.
- [ ] Нет действий добавления, редактирования и удаления операций.
- [ ] API-типы получены из предоставленного backend OpenAPI snapshot по принятому направлению генерации.
- [ ] Документация банковских карт обновлена: описаны переход, URL/период, режим просмотра и отличие суммы от существующей сводки.
## Проверка
Проверить переход с карты с выбранным диапазоном, изменение периода, обновление/прямую ссылку и браузерную навигацию; пагинацию с неизменным общим итогом; пример 1 000 ₽ + возврат 300 ₽ → 1 000 ₽; пустой период, ошибки и отсутствие действий записи.
Проверить интерфейс и клавиатурный переход. Выполнить применимые проверки по frontend/AGENTS.md и npm run verify; команды и результаты приложить к PR.
## Точки входа в реализацию
- src/pages/card/ui/CardPage.vm.ts — существующее состояние периода и пагинации.
- src/pages/card/ui/CardPage.view.tsx — страница карты.
- BankSummaryView — существующие строки категорий сводки.
- Существующие bankPeriod и BankPeriodPicker — работа с периодом.
Переиспользовать подходящие владельцы и UI приложения. Не загружать весь журнал карты ради фильтрации и расчёта суммы в браузере.
## Вне объёма
Агрегация нескольких карт, графики, сравнения, бюджетирование, операции записи и изменение расчёта существующей сводки карты.
## Зависимость
Требуется [backend #16 — выборка расходов и сумма за период](https://git.personal.ksv741.ru/WealthLedger/backend/issues/16). Интеграция выполняется по предоставленному backend-контракту.
ksv741
was assigned by codex-bot2026-09-14 06:24:08 +03:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Задача
Из сводки банковской карты пользователь открывает выбранную категорию и видит расходы этой карты за период: общую сумму и список покупок.
Первая итерация — только просмотр внутри одной карты, без графиков и сравнения периодов.
Пользовательский сценарий
Содержимое страницы
Возврат не показывается и не уменьшает итог: покупка 1 000 ₽ с возвратом 300 ₽ отображается как расход 1 000 ₽, итог — 1 000 ₽. Существующая сводка карты при этом может показывать 700 ₽. Подпись показателя должна явно объяснять различие.
Критерии приёмки
Проверка
Проверить переход с карты с выбранным диапазоном, изменение периода, обновление/прямую ссылку и браузерную навигацию; пагинацию с неизменным общим итогом; пример 1 000 ₽ + возврат 300 ₽ → 1 000 ₽; пустой период, ошибки и отсутствие действий записи.
Проверить интерфейс и клавиатурный переход. Выполнить применимые проверки по frontend/AGENTS.md и npm run verify; команды и результаты приложить к PR.
Точки входа в реализацию
Переиспользовать подходящие владельцы и UI приложения. Не загружать весь журнал карты ради фильтрации и расчёта суммы в браузере.
Вне объёма
Агрегация нескольких карт, графики, сравнения, бюджетирование, операции записи и изменение расчёта существующей сводки карты.
Зависимость
Требуется backend #16 — выборка расходов и сумма за период. Интеграция выполняется по предоставленному backend-контракту.