BRD Mobile 4.1 Мои заказы > Список текущих заказов
Направление работ: Mobile Код раздела: 4.1 Раздел: Мои заказы > Список текущих заказов Статус: Черновик Ответственный: Панкова Л.А. Версия: 0.1 Обновлено: 14.08.26
1. Назначение
Раздел обеспечивает клиенту мобильного приложения просмотр всех активных бронирований, заявок и абонементов в одном списке.
Клиент отслеживает текущий статус, оплату и условия бесплатной отмены, переходит к подробной информации об отдельном заказе или группе заказов и при доступности онлайн-платежа запускает оплату.
Состав и состояния карточек зависят от процессинга бронирований, заявок и групп заказов, условий оплаты и правил отмены, описанных в связанных Back BRD.
2. Ключевые понятия
Экран «Список текущих заказов» — раздел мобильного приложения с активной вкладкой «Текущие», в котором клиент видит активные бронирования, заявки и абонементы.
Бронирование — форма заказа, которая резервирует выбранное время за клиентом и проходит состояния оплаты и завершения.
Заявка — предварительная форма заказа для площадки с форматом работы «По заявке», которая ожидает обработки партнером и после подтверждения преобразуется в бронирование.
Абонемент — группа связанных заказов, для которой в списке показываются состав, период действия и сводное состояние оплаты.
Условие оплаты — настройка партнера, определяющая необходимость и доступность онлайн-оплаты заказа.
Срок бесплатной отмены — момент, до которого клиент может отменить бронирование без начисления сбора.
3. Scope
Входит
S1: Открытие списка текущих заказов, загрузка данных и отображение пустого состояния
S2: Просмотр карточек активных бронирований, их статусов, оплаты и условий бесплатной отмены
S3: Просмотр карточек активных заявок и их статусов обработки
S4: Просмотр карточек активных абонементов, состава и сводного состояния оплаты
S5: Переходы к информации о заказе, группе заказов и списку архивных заказов
Не входит
- Mobile: 4.1.1 Информация о текущем заказе — подробная информация и управление отдельным активным заказом.
- Mobile: 4.1.2 Перенос и отмена заказа — изменение параметров и отмена активного заказа.
- Mobile: 4.2 Список архивных заказов — отображение отмененных бронирований, отклоненных заявок и других архивных заказов.
- Mobile: 4.3 Информация о группе заказов — подробная информация об абонементе и входящих в него заказах.
4. BR
Указаны в пункте 4 разделов Back: 3.1 Состав заказа, Back: 3.2 Процессинг заказов, Back: 3.2.2 Заявки, Back: 3.3 Группы заказов, Back: 2.4.2 Условия оплаты и Back: 2.4.3 Правила отмены.
5. Функциональные требования (UC + FR)
FR — functional requirements, что интерфейс должен уметь делать по определенному UC.
| ID | Сценарий | Функциональное требование | BR | Вес | Статус |
|---|---|---|---|---|---|
| S1: FR4.1-1 | Клиент открывает раздел «Мои заказы» | Интерфейс открывает экран со вкладками «Текущие» и «История»; по умолчанию активна вкладка «Текущие». | 1 | Реализовано OQ4.1-1 | |
| S1: FR4.1-2 | Система загружает текущие заказы | До получения данных интерфейс показывает skeleton-состояние карточек списка. | 2 | Не реализовано OQ4.1-2 | |
| S1: FR4.1-3 | Система получила активные заказы клиента | Интерфейс показывает в одном списке все активные бронирования, заявки и абонементы клиента. Отмененные бронирования и отклоненные заявки в текущий список не включаются. | 1 | Частично OQ4.1-3, OQ4.1-4 | |
| S1: FR4.1-4 | У клиента нет активных заказов | Интерфейс показывает заглушку с заголовком «У вас пока нет активных заказов» и пояснением «Здесь будут отображаться все ваши бронирования и заявки». | 1 | Реализовано OQ4.1-5 | |
| S2: FR4.1-5 | Клиент просматривает карточку активного бронирования | Интерфейс показывает изображение, название партнерской зоны, название площадки, дату, временной интервал, статус, стоимость и доступные действия. | 1 | Частично OQ4.1-6 | |
| S2: FR4.1-6 | Клиент просматривает статус бронирования | Интерфейс показывает одно из состояний: «Зарезервирован» — бронь создана и ожидает оплаты; «Ожидает оплаты» — партнер настроил обязательную предоплату, но она еще не внесена; «Оплачен» — внесена полная оплата; «Частично оплачен» — внесена предоплата и остается сумма к оплате. | 1 | Частично OQ4.1-7 | |
| S2: FR4.1-7 | Для бронирования доступна бесплатная отмена | Интерфейс показывает срок в формате «Бесплатная отмена доступна до: {время} {дата}». | 2 | Реализовано | |
| S2: FR4.1-8 | Срок бесплатной отмены бронирования истек | Интерфейс показывает сообщение «Бесплатная отмена недоступна» и время истечения срока, включая относительное время и дату истечения. | 2 | Частично OQ4.1-8 | |
| S2: FR4.1-9 | Бронирование оплачено не полностью | Если партнер настроил прием онлайн-платежей, интерфейс показывает кнопку «Оплатить»; если заказ оплачивается на месте или уже оплачен полностью, кнопка не отображается. Нажатие запускает доступный для заказа сценарий онлайн-оплаты. | 1 | Частично OQ4.1-9 | |
| S3: FR4.1-10 | Клиент просматривает карточку активной заявки | Интерфейс показывает изображение, название партнерской зоны, название площадки, дату, временной интервал, статус заявки, стоимость и действие «Подробнее». Кнопка оплаты до подтверждения заявки не отображается. | 1 | Частично OQ4.1-6 | |
| S3: FR4.1-11 | Клиент просматривает статус заявки | Интерфейс показывает одно из состояний: «Заявка отправлена» — заявка создана и ожидает обработки; «Обработка задерживается» — партнер не обработал заявку в установленный срок; «Заявка в работе» — партнер начал обработку заявки. Состояние «Заявка отклонена» в текущем списке не отображается. | 1 | Частично OQ4.1-10 | |
| S3: FR4.1-12 | Партнер подтвердил заявку | Интерфейс показывает созданное на основании заявки бронирование в статусе «Зарезервирован» и далее применяет к карточке статусы, условия оплаты и бесплатной отмены обычного бронирования. | 1 | Частично OQ4.1-11 | |
| S4: FR4.1-13 | Клиент просматривает карточку активного абонемента | Интерфейс показывает изображение, название партнерской зоны, название и количество заказов в абонементе, период действия, статус оплаты и общую стоимость. | 1 | Частично OQ4.1-12 | |
| S4: FR4.1-14 | Клиент просматривает состав абонемента | Интерфейс показывает блок «Состав» со сгруппированными по объектам площадками. | 2 | Реализовано OQ4.1-13 | |
| S4: FR4.1-15 | Клиент просматривает состояние оплаты абонемента | Если один или несколько заказов внутри абонемента не оплачены, интерфейс показывает статус «Не оплачен», сумму «Оплачено» и остаток «К оплате». Если все включенные заказы оплачены, интерфейс показывает статус «Оплачен», полную оплаченную сумму и нулевой остаток. | 1 | Частично OQ4.1-14 | |
| S4: FR4.1-16 | Абонемент оплачен не полностью | Интерфейс показывает дедлайн в формате «Оплатить до: {дата}». Если для включенных заказов доступна онлайн-оплата, интерфейс показывает кнопку «Оплатить»; после полной оплаты кнопка не отображается. Нажатие запускает доступный сценарий онлайн-оплаты. | 1 | Частично OQ4.1-15 | |
| S5: FR4.1-17 | Клиент нажимает карточку бронирования или заявки либо кнопку «Подробнее» | Интерфейс переходит в раздел Mobile: 4.1.1 Информация о текущем заказе. | 1 | Реализовано OQ4.1-16 | |
| S5: FR4.1-18 | Клиент нажимает карточку абонемента или кнопку «Подробнее» | Интерфейс переходит в раздел Mobile: 4.3 Информация о группе заказов. | 1 | Реализовано OQ4.1-17 | |
| S5: FR4.1-19 | Клиент нажимает вкладку «История» | Интерфейс переходит в раздел Mobile: 4.2 Список архивных заказов. | 1 | Реализовано OQ4.1-18, OQ4.1-19 |
6. Открытые вопросы
| ID | Источник | Вопрос | Кому | Статус | Рекомендации | Итоговое решение |
|---|---|---|---|---|---|---|
| OQ4.1-1 | FR4.1-1 | Что подтверждено: экран «Мои заказы» открывается двумя вкладками «Текущие» и «История», активной по умолчанию открывается «Текущие» (контроллер вкладок создается без явного начального индекса, то есть встает на первую). \ lib/src/feature/orders_tab/order_screen.dart:31-45, пункт нижнего меню «Мои заказы» — lib/src/feature/home/screen/home_screen.dart:69; поведение закреплено автотестом test/feature/orders_tab/orders_screen_integration_test.dart:130-177 | Бизнес | Подтверждено | Расхождений нет, действий не требуется. | — |
| OQ4.1-2 | FR4.1-2 | Требование говорит: до получения данных интерфейс показывает skeleton-состояние карточек списка. В коде на время загрузки список целиком заменяется полноэкранной анимацией (Lottie) — ни skeleton-карточек, ни каркаса списка нет; та же анимация показывается и при обновлении «потянуть вниз», из-за чего уже загруженные карточки на время обновления пропадают с экрана. \ lib/src/feature/orders_tab/widget/booking_list.dart:55-61, обновление списка через полное состояние загрузки — lib/src/feature/orders_tab/bloc/orders_bloc.dart:173-190 | Бизнес | Open | Подтвердить, остается ли skeleton обязательным требованием (тогда это задача на доработку) или полноэкранная анимация принимается как реализация. Отдельно решить, должен ли pull-to-refresh скрывать уже показанные карточки. | Бизнесовый вопрос. |
| OQ4.1-3 | FR4.1-3 | Требование говорит: отмененные бронирования и отклоненные заявки в текущий список не включаются. В коде приложение само ничего не фильтрует: оно передает на сервер признак «показать текущие» и выводит ровно то, что вернул сервер; при этом в отрисовке статусов есть готовые ярлыки «Отменена» и «Отклонена», то есть такие карточки отобразятся, если сервер их вернет. Проверить фактическое поведение сервера в этом репозитории нельзя. \ lib/src/core/components/repositories/order_service/orders_service_repository.dart:63-89, lib/src/feature/orders_tab/widget/status_badges.dart:21-34 | Разработка | Open | Подтвердить контракт метода GetMyOrdersIdsMobile (showCurrent = true) на бэкенде: гарантирует ли он исключение отмененных заказов и отклоненных заявок. Если гарантии нет — либо закрепить ее на бэкенде, либо добавить фильтрацию на клиенте. | Вся ответсвенность в данном случае на бэке |
| OQ4.1-4 | FR4.1-3 | Что нашли: список грузится страницами по 4 элемента, поэтому «все активные заказы» клиент видит только после нескольких догрузок при прокрутке. При этом в блоке заказов объявлена константа размера страницы 10, которая нигде не используется — фактический размер задается другой константой. \ lib/src/feature/orders_tab/bloc/models/pagination_data.dart:6, неиспользуемая константа — lib/src/feature/orders_tab/bloc/orders_bloc.dart:14 | Разработка | Open | Убрать неиспользуемую константу и согласовать реальный размер страницы (4 выглядит как отладочное значение). Подтвердить у бизнеса приемлемый размер первой выдачи. | Какой реальный размер стрницы? Сколько в среднем у пользователся заказов? |
| OQ4.1-5 | FR4.1-4 | Что подтверждено: при отсутствии активных заказов показывается заглушка с заголовком «У вас пока нет активных заказов» и пояснением «Здесь будут отображаться все ваши бронирования и заявки» — тексты совпадают с требованием дословно. \ lib/src/feature/orders_tab/widget/booking_list.dart:89-103, верстка заглушки — lib/src/feature/orders_tab/widget/empty_orders.dart:31-71; поведение закреплено автотестом test/feature/orders_tab/orders_screen_integration_test.dart:180-204 | Бизнес | Подтверждено | Расхождений нет, действий не требуется. | — |
| OQ4.1-6 | FR4.1-5, FR4.1-10 | Требование говорит: карточка бронирования и карточка заявки показывают название партнерской зоны и название площадки. В коде в карточке выводятся название площадки (заголовок) и название объекта (подзаголовок), а название партнерской зоны не выводится вовсе — в модели заказа есть только идентификатор партнерской зоны, без названия. Остальной состав карточки (изображение, дата и интервал, статус, стоимость, кнопки) присутствует. \ lib/src/feature/orders_tab/widget/tiles/order_tile.dart:218-274, модель заказа — lib/src/core/components/repositories/order_service/model/order_list_model.dart:21-31 (в карточке абонемента название партнерской зоны, напротив, есть — lib/src/feature/orders_tab/widget/tiles/abonement_tile.dart:90-93) | Бизнес | Open | Уточнить, что именно должно стоять в шапке карточки заказа: название партнерской зоны (тогда нужно добавить поле в ответ сервера) или связка «площадка + объект», как сейчас. Тогда же поправить формулировку требования. | название партнерской зоны = название базы? Нет? |
| OQ4.1-7 | FR4.1-6 | Требование говорит: четыре состояния бронирования — «Зарезервирован», «Ожидает оплаты», «Оплачен», «Частично оплачен». В коде ярлыки называются иначе — «Резерв», «Ожидает оплаты», «Оплачено», «Частично оплачена». Кроме того, для зарезервированного заказа ярлык «Резерв» недостижим: при полной оплате показывается «Оплачено», а при частичной оплате и при ее отсутствии одинаково показывается «Ожидает оплаты» — то есть «Частично оплачена» для бронирования не показывается никогда (этот ярлык используется только для абонементов). \ lib/src/feature/orders_tab/widget/status_badges.dart:9-20 и :114-126, перечень состояний оплаты — lib/src/core/components/repositories/order_service/model/order_list_model.dart:102-111 | Бизнес | Open | Утвердить финальные тексты ярлыков и правило: должен ли зарезервированный неоплаченный заказ показываться как «Зарезервирован» или как «Ожидает оплаты», и нужно ли отдельное состояние «Частично оплачен» для бронирования. После утверждения — задача разработке на исправление отображения. | Бизнес pls help! Как должен отображаться заказ с оплатой наличными в данном случае? |
| OQ4.1-8 | FR4.1-8 | Требование говорит: при истекшем сроке показать «Бесплатная отмена недоступна» плюс относительное время и дату истечения. В коде это два разных, невзаимозаменяемых состояния: если бесплатная отмена не разрешена правилом — выводится только фраза «Бесплатная отмена недоступна» без времени; если срок истек — выводится только строка вида «истекла 2д назад 15:00 29.07», без фразы «Бесплатная отмена недоступна». Совмещения текста и времени, как в требовании, нет ни в одном случае. \ lib/src/feature/orders_tab/widget/tiles/order_tile.dart:145-178, определение состояния — lib/src/feature/orders_tab/utils/conditions_btns_util.dart:164-192, формат относительного времени — lib/src/feature/orders_tab/utils/conditions_btns_util.dart:239-247 | Бизнес | Open | Развести два случая в требовании: «отмена правилом не предусмотрена» и «срок бесплатной отмены истек», и для каждого зафиксировать точный текст. | Вопрос к бизнесу. Стоит ли менять? |
| OQ4.1-9 | FR4.1-9 | Требование говорит: кнопка «Оплатить» показывается только при доступной онлайн-оплате и скрывается при оплате на месте и при полной оплате. В коде правило в основном соблюдено, но есть две особенности: 1) сценарий оплаты подтягивается отдельным пакетным запросом, и пока он не получен или запрос упал, кнопка «Оплатить» показывается по умолчанию — то есть у заказа с оплатой на месте кнопка может появиться; 2) при сценарии «оплата по инструкции» кнопка тоже показывается и открывает ссылку-инструкцию, а не платежную страницу. \ lib/src/feature/orders_tab/utils/conditions_btns_util.dart:194-212, поведение по умолчанию — lib/src/feature/orders_tab/widget/tiles/order_tile.dart:24-27, выбор ссылки — lib/src/feature/orders_tab/utils/payment_order_service.dart:9-21 | Разработка | Open | Сменить поведение по умолчанию на «кнопку не показывать, пока сценарий оплаты не определен» либо показывать для нее состояние загрузки. Отдельно согласовать с бизнесом, корректно ли называть кнопку «Оплатить» для сценария «по инструкции». | С текущими реализациями апи можно сделать только так как есть сейчас. |
| OQ4.1-10 | FR4.1-11 | Требование говорит: статусы заявки — «Заявка отправлена», «Обработка задерживается», «Заявка в работе». В коде таких текстов нет: заявка показывается как «Новая», «В процессе» и «В работе» соответственно; в коде даже оставлен комментарий, что «В процессе» — это «Обработка задержится». Также существует ярлык «Отклонена», который отобразится, если сервер вернет отклоненную заявку в текущий список. \ lib/src/feature/orders_tab/widget/status_badges.dart:25-34 и :114-126 | Бизнес | Open | Утвердить финальные тексты статусов заявки и передать их в разработку. Вопрос про отклоненные заявки в текущем списке решается вместе с OQ4.1-3. | исправить i guess |
| OQ4.1-11 | FR4.1-12 | Требование говорит: после подтверждения заявки партнером карточка показывается как бронирование в статусе «Зарезервирован». В коде механика подхватывается автоматически (правила оплаты и бесплатной отмены применяются, как только заказ приходит в состоянии «резерв»), но сам ярлык будет другим: для состояния «подтверждена» показывается «Подтверждена», для состояния «резерв» без оплаты — «Ожидает оплаты». Текста «Зарезервирован» в приложении нет. \ lib/src/feature/orders_tab/widget/status_badges.dart:9-34, правила бесплатной отмены и кнопки оплаты — lib/src/feature/orders_tab/utils/conditions_btns_util.dart:170-172 и :204-209 | Бизнес | Open | Решается вместе с OQ4.1-7: зафиксировать, какой ярлык видит клиент сразу после подтверждения заявки, и не остается ли карточка в промежуточном состоянии «Подтверждена». | вопрос к бизнесу |
| OQ4.1-12 | FR4.1-13 | Требование говорит: карточка абонемента показывает изображение, название партнерской зоны, название и количество заказов в абонементе, период, статус оплаты и общую стоимость. В коде есть все, кроме названия абонемента: вместо него жестко выводится строка вида «Абонемент: 8 заказов». Кроме того, в «общую стоимость» добавляется сумма штрафа, чего требование не описывает. \ lib/src/feature/orders_tab/widget/tiles/abonement_tile.dart:104-111 (название и количество), :54-56 и :140-148 (стоимость со штрафом), :151-158 (период), :131-134 (статус) | Бизнес | Open | Подтвердить, есть ли у абонемента собственное название, которое нужно показывать, и должна ли отображаемая стоимость включать штраф. | |
| OQ4.1-13 | FR4.1-14 | Что нашли: блок состава реализован и группирует площадки по объектам, как требует BRD, но заголовок блока написан с латинской буквой «C» — «Cостав:» вместо «Состав:». Визуально неотличимо, но ломает поиск по тексту, автотесты и будущую локализацию. Рядом — второй риск: при сборке состава названия объекта и площадки берутся с принудительным раскрытием, и заказ без названия площадки уронит карточку абонемента. \ lib/src/feature/orders_tab/widget/tiles/abonement_tile.dart:329-335 (заголовок), :292-306 (группировка и принудительное раскрытие названий) | Разработка | Open | Исправить букву в заголовке и заменить принудительное раскрытие на безопасное значение по умолчанию. | Никогда бы не узнал об этом)) Исправить. |
| OQ4.1-14 | FR4.1-15 | Требование говорит: при наличии неоплаченных заказов внутри абонемента показывается статус «Не оплачен», а при полной оплате — «Оплачен». В коде статуса «Не оплачен» не существует: неоплаченный абонемент показывается как «Частично оплачена», «Ожидает оплаты» или «Резерв» в зависимости от суммы оплат и признака доступности оплаты, а полностью оплаченный — как «Оплачено». Блоки «Оплачено» и «К оплате» выводятся всегда, включая случай нулевого остатка, — это соответствует требованию. \ lib/src/feature/orders_tab/widget/status_badges.dart:42-54, блоки сумм — lib/src/feature/orders_tab/widget/tiles/abonement_tile.dart:175-195 | Бизнес | Open | Утвердить перечень и тексты статусов абонемента: нужен ли единый «Не оплачен» или сохраняем текущую градацию из трех состояний. | Бизнес |
| OQ4.1-15 | FR4.1-16 | Требование говорит: для не полностью оплаченного абонемента показывается дедлайн «Оплатить до: {дата}» и кнопка «Оплатить», которая после полной оплаты не показывается. В коде кнопки «Оплатить» в карточке абонемента в списке нет вообще — единственная кнопка «Подробнее», а оплата доступна уже на экране «Информация об абонементе». Строка «Оплатить до: {дата}» при этом выводится всегда, в том числе для полностью оплаченного абонемента. \ lib/src/feature/orders_tab/widget/tiles/abonement_tile.dart:199-211 (дедлайн без условия), :215-230 (единственная кнопка «Подробнее»), оплата на экране абонемента — lib/src/feature/orders_tab/abonement_composition_page/abonement_composition_page.dart:76 и :229 | Бизнес | Open | Решить, нужна ли кнопка оплаты прямо в списке или достаточно перехода в карточку абонемента, и скрывать ли дедлайн «Оплатить до» при полной оплате. По итогам скорректировать требование или завести доработку. | Вопрос. Как вообще создается абонемент, как он может оказаться не оплачен? |
| OQ4.1-16 | FR4.1-17 | Что подтверждено: нажатие на карточку бронирования или заявки, как и нажатие кнопки «Подробнее», открывает экран информации о заказе (раздел 4.1.1) — оба действия ведут в один и тот же переход. \ lib/src/feature/orders_tab/widget/tiles/order_tile.dart:36-39 (переход), :205-209 (нажатие на карточку), :72-81 (кнопка «Подробнее») | Бизнес | Подтверждено | Расхождений нет, действий не требуется. | — |
| OQ4.1-17 | FR4.1-18 | Что подтверждено: нажатие на карточку абонемента и кнопка «Подробнее» открывают экран «Информация об абонементе» — раздел 4.3. \ lib/src/feature/orders_tab/widget/tiles/abonement_tile.dart:59-66 и :215-230, заголовок целевого экрана — lib/src/feature/orders_tab/abonement_composition_page/abonement_composition_page.dart:76 | Бизнес | Подтверждено | Расхождений нет, действий не требуется. | — |
| OQ4.1-18 | FR4.1-19 | Что подтверждено: по нажатию вкладки «История» клиент видит архивные заказы (раздел 4.2). Реализовано как переключение вкладки внутри того же экрана, а не как переход на отдельный экран, — для клиента результат тот же. \ lib/src/feature/orders_tab/order_screen.dart:42-57, обе вкладки строятся одним компонентом списка с разным признаком — lib/src/feature/orders_tab/widget/booking_list.dart:13-16 и :67-82 | Бизнес | Подтверждено | Расхождений нет. При желании уточнить формулировку требования: это переключение вкладки, а не переход в отдельный раздел. | — |
| OQ4.1-19 | Обратный проход | Что нашли: при открытии раздела приложение сразу грузит оба списка — и текущие заказы, и историю — одним параллельным запросом, еще до того как клиент нажал вкладку «История». BRD описывает загрузку только текущих заказов. Это лишний трафик и задержка первой отрисовки. \ lib/src/feature/orders_tab/bloc/orders_bloc.dart:303-329 | Разработка | Open | Обсудить ленивую загрузку истории по первому открытию вкладки. Если предзагрузка сделана намеренно (мгновенное переключение вкладок) — зафиксировать это в BRD 4.1 и 4.2. | так надо. оставляем. |
| OQ4.1-20 | Обратный проход | Что нашли: порядок карточек в списке BRD не задает, а код склеивает выдачу так, что все абонементы страницы идут перед заказами, и клиентской сортировки по дате нет — порядок внутри групп полностью определяется сервером. При догрузке следующей страницы порядок повторяется: снова сначала абонементы, потом заказы. \ lib/src/feature/orders_tab/bloc/orders_bloc.dart:412-427 и :494-506 | Бизнес | Open | Зафиксировать в BRD правило сортировки списка (например, по дате ближайшего заказа) и внести его отдельным требованием. | Зафиксировать в BRD правило сортировки списка |
| OQ4.1-21 | Обратный проход | Что нашли: в коде есть состояние ошибки загрузки списка — экран «Что-то пошло не так» с текстом «Проверьте соединение с интернетом или повторите попытку позднее» и обновлением жестом «потянуть вниз». В BRD этот сценарий не описан. \ lib/src/feature/orders_tab/widget/booking_list.dart:149-156, текст ошибки — lib/src/feature/orders_tab/bloc/orders_bloc.dart:362-368 | Бизнес | Open | Добавить в BRD требование на состояние ошибки загрузки списка и утвердить тексты. | Добавить в BRD требование на состояние ошибки загрузки списка и утвердить тексты. |
| OQ4.1-22 | Обратный проход | Что нашли: ошибка в догрузке списка истории — при подгрузке следующей страницы истории пагинация берется из счетчика текущих заказов, а не из счетчика истории. Рядом — два несовместимых расчета признака «есть ли еще страницы» (в одном месте страница сравнивается с общим числом страниц, в другом — с числом страниц минус один), причем сохраненный признак фактически не используется как условие догрузки. Следствие: история может недогружаться или зацикливаться на повторной загрузке. \ lib/src/feature/orders_tab/bloc/orders_bloc.dart:460-464 (подмена счетчика), :143-147 против :430-438 (два расчета), :260-262 (какой расчет реально используется) | Разработка | Open | Исправить подмену счетчика пагинации для истории и свести расчет «есть ли еще страницы» к одной формуле; покрыть догрузку истории тестом. | Исправить подмену счетчика пагинации |
| OQ4.1-23 | Обратный проход | Что нашли: два риска падения и лишней работы при загрузке списка: 1) обработчик догрузки приводит состояние к «загружено» без проверки — если клиент долистает до конца, пока идет обновление или после ошибки, приложение упадет; 2) команда первичной загрузки отправляется прямо из построения экрана, то есть повторяется при каждой перерисовке (сейчас спасает только внутренняя проверка «состояние еще начальное»). \ lib/src/feature/orders_tab/bloc/orders_bloc.dart:255 и :442, повторная отправка — lib/src/feature/orders_tab/order_screen.dart:25 и :29 | Разработка | Open | Заменить приведение состояния на безопасную проверку и перенести первичную загрузку из построения экрана в инициализацию. | костыль, переделать |
| OQ4.1-24 | Обратный проход | Что нашли: стоимость в карточках считается и форматируется по-разному: у заказа выводится «сырая» сумма без разделителя разрядов и без штрафа, у абонемента — сумма с разделителем разрядов и с добавленным штрафом. Для клиента это выглядит как разные правила отображения цены в одном списке. \ lib/src/feature/orders_tab/widget/tiles/order_tile.dart:194-198 против lib/src/feature/orders_tab/widget/tiles/abonement_tile.dart:54-56 и :140-148 | Бизнес | Open | Утвердить единое правило отображения суммы в списке (разделитель разрядов, включать ли штраф) и отразить его в требованиях FR4.1-5 и FR4.1-13. | исправить |
| OQ4.1-25 | Обратный проход | Что нашли: в рабочем коде списка осталась отладочная печать в консоль — в том числе печать признака вкладки, высоты пустого экрана и данных пагинации (в блоке заказов таких вызовов 12). На поведение не влияет, но замусоривает логи сборки и продакшена. \ lib/src/feature/orders_tab/widget/booking_list.dart:27, lib/src/feature/orders_tab/widget/empty_orders.dart:24, lib/src/feature/orders_tab/bloc/orders_bloc.dart:144, :253, :263-264, :278 | Разработка | Open | Убрать отладочную печать или перевести на штатный логгер с уровнями. | это только в дебаг сборках |
BRD 4.1 v0.1 · booking.mobile.flutter · commit 9db8346/dev · 17.08.26 · якоря
lib/src/feature/orders_tab/(order_screen.dart, widget/booking_list.dart, widget/empty_orders.dart, widget/status_badges.dart, widget/tiles/, bloc/, utils/conditions_btns_util.dart, utils/payment_order_service.dart),lib/src/core/components/repositories/order_service/,lib/src/core/utils/utils.dart,lib/src/core/utils/app_router.dart,lib/src/feature/home/screen/home_screen.dartТребований: 19 — Реализовано 7, Частично 11, Не реализовано 1. Открытых вопросов: 25 — Open 20 (Бизнес 12, Разработка 8), Подтверждено 5. Скоуп сверки: список заказов (вкладки, состав карточки в списке, порядок, пустое состояние, загрузка, пагинация, переходы). Содержимое карточки заказа (4.1.1) и перенос/отмена (4.1.2) не проверялись. Маршрутизация без сверки с гайдбуком (гайдбук не передавался).