| OQ4.2.1-1 | FR4.2.1-1 | Требование говорит: для отклоненной заявки открывается экран «Информация о заявке» (с тем же составом информации, что и у архивного бронирования). В коде экран один, и его заголовок жестко задан строкой «Информация о бронировании» — независимо от статуса записи; никакого экрана или заголовка «Информация о заявке» в приложении нет. \ lib/src/feature/orders_tab/order_room/order_room_screen.dart:150 | Разработка | Open | Либо сделать заголовок зависимым от статуса заказа (отклоненная заявка → «Информация о заявке»), либо, если для бизнеса разница только в названии, зафиксировать это в BRD одной строкой и не плодить второй экран. | Вопрос к бизнесу. Состав экрана и так одинаковый — нужен ли вообще отдельный заголовок? Проще зафиксировать в BRD один «Информация о бронировании» и не трогать код. |
| OQ4.2.1-2 | FR4.2.1-1 | Требование говорит: экран запрашивает сохраненные данные выбранной записи. В коде при открытии карточки заново загружаются актуальные справочники — описание площадки, текущий каталог оборудования, список опций, промокоды; сохраненным из заказа берется только состав, даты и суммы. Если оборудование, которое было в архивном заказе, уже удалено из каталога площадки, позиция молча выбрасывается из списка (в лог пишется предупреждение, клиенту она просто не показывается). \ lib/src/feature/orders_tab/order_room/cubit/order_room_cubit.dart:130-173, :99-106 | Бизнес | Open | Решить, что клиент должен видеть в архиве: снимок заказа на момент оказания услуги или актуальное состояние площадки. Если снимок — нужно требование к бэкенду отдавать сохраненные названия/цены позиций в самом заказе, иначе архивная карточка со временем «худеет». | Вопрос к бизнесу. Снимок или актуалка? Если снимок — это задача на бэк (заказ должен отдавать сохранённые названия и цены позиций), на клиенте не решается. От ответа зависит OQ4.2.1-28. |
| OQ4.2.1-3 | FR4.2.1-2, FR4.2.1-14 | Требование говорит: все блоки экрана доступны только для просмотра, комментарий — без возможности редактирования. В коде признак «комментарий неизменяем» сначала правильно включается для любого незарезервированного (то есть архивного) заказа, но следующие же строки безусловно перезаписывают его: в обеих ветках итогового условия он выставляется в «изменяем». В результате на архивной карточке поле комментария остается редактируемым, а по потере фокуса отправляется обновление заказа. \ lib/src/feature/orders_tab/order_room/cubit/order_room_cubit.dart:388-399, lib/src/feature/orders_tab/order_room/widget/actullity/comment_widget.dart:46-53, lib/src/feature/orders_tab/order_room/cubit/order_room_cubit.dart:627 | Разработка | Open | Похоже на ошибку порядка условий: второй блок должен выполняться только для заказов в статусе «резерв». Проверить на архивном заказе, что клавиатура не открывается и запрос обновления не уходит. | Чиним. Баг подтверждён: обе ветки второго if ставят флаг в false, блок выше мёртвый. Правка мелкая. |
| OQ4.2.1-4 | FR4.2.1-2, FR4.2.1-16 | Требование говорит: переключатель применения М-баллов на архивном заказе неактивен и лишь отражает сохраненное состояние. В коде переключатель отображает сохраненное состояние верно, но остается рабочим: обработчик переключения вызывает обновление модели заказа, которое немедленно отправляет запрос на сохранение заказа. То есть клиент может переключить М-баллы у завершенного или отмененного заказа. \ lib/src/feature/orders_tab/order_room/widget/actullity/mpoints_widget.dart:89-93, lib/src/feature/orders_tab/order_room/cubit/order_room_cubit.dart:609-627 | Разработка | Open | Передавать в блок М-баллов признак «только просмотр» и отключать переключатель для архивных заказов. Отдельно проверить, что бэкенд отклоняет изменение завершенного заказа, — иначе это не только UI-дефект. | Чиним, гасим переключатель на архиве. Бэку — отдельная задача проверить, что update завершённого заказа отклоняется. |
| OQ4.2.1-5 | FR4.2.1-2, FR4.2.1-13 | Требование говорит: промокод на архивном заказе доступен только для просмотра. В коде блок промокода на архивной карточке не может показать детализацию (нужен расчет, которого для архива нет) и вместо нее выводит активную кнопку «Промокод», открывающую модальное окно подбора и применения промокода к этому заказу. \ lib/src/feature/orders_tab/order_room/widget/actullity/discount_widget.dart:104-110, :32-92 | Разработка | Open | Для архивных заказов показывать код и сумму скидки текстом, а кнопку подбора промокода не выводить вовсе. | Чиним по-простому: на архиве кнопку подбора промокода просто не показываем. |
| OQ4.2.1-6 | FR4.2.1-2 | Что нашли: в коде есть параметр экрана «поля неизменяемы», он вычисляется при загрузке заказа, но нигде не читается — ни один блок карточки на него не опирается. Единого выключателя режима «только просмотр» у экрана фактически нет, каждый блок решает сам за себя (и, как видно из вопросов выше, решает по-разному). \ lib/src/feature/orders_tab/order_room/model/screen_parameters.dart:10, lib/src/feature/orders_tab/order_room/cubit/order_room_cubit.dart:390-403 (присваивается, но не используется) | Разработка | Open | Ввести один явный признак «архивный заказ / только просмотр» и протянуть его во все блоки, вместо разрозненных условий по статусу оплаты и типу вкладки. Это закроет разом вопросы OQ4.2.1-3, -4, -5. | Заводим один isArchived по статусу заказа. Без большого рефакторинга — точечно, только чтобы закрыть -3, -4, -5. Подтверждаю: isUnModifierFields реально нигде не читается. |
| OQ4.2.1-7 | FR4.2.1-3 | Требование говорит: кнопка возврата возвращает клиента в раздел «Список архивных заказов». В коде возврат открывает раздел «Мои заказы» заново, а он всегда стартует на первой вкладке — «Текущие». То есть клиент, вышедший из архивного заказа, попадает не в «Историю», а в список текущих заказов. Дополнительно экран не закрывается, а добавляется новый поверх стека. \ lib/src/feature/orders_tab/order_room/order_room_screen.dart:96-118, lib/src/feature/orders_tab/order_screen.dart:31-46 | Разработка | Open | Возвращаться закрытием экрана (pop), а не открытием нового раздела; если открытие раздела необходимо — передавать в него нужную вкладку. | Чиним: pop вместо push. Мелочь на одну строку. |
| OQ4.2.1-8 | FR4.2.1-4 | Требование говорит: в свернутом блоке площадки показываются название площадки, название партнерской зоны и сохраненная стоимость времени. В коде выводятся название комнаты, стоимость времени и название базы; название партнерской зоны не выводится вообще, а в модели экрана оно жестко записано строкой «Unknown» — то есть на клиенте его попросту нет. \ lib/src/feature/orders_tab/order_room/widget/actullity/title_card_widget.dart:55, :63, :84; lib/src/feature/orders_tab/order_room/cubit/order_room_cubit.dart:267 | Разработка | Open | Уточнить у бэкенда, приходит ли название партнерской зоны в данных заказа; если да — заполнить поле вместо заглушки и вывести в блоке. Если название зоны бизнесу здесь не нужно — снять его из требования. | Вопрос к бизнесу. Название базы уже выводится — зона тут реально нужна? Если нет, убираем из требования. На клиенте сейчас заглушка «Unknown», тянуть её с бэка — отдельная возня. |
| OQ4.2.1-9 | FR4.2.1-5 | Требование говорит: при раскрытии блока площадки показываются в том числе расстояние. В коде в раскрытом блоке есть площадь, метро, видеомаршрут, карта, адрес и обе кнопки, но расстояния нет: значение загружается и кладется в модель экрана, однако ни один элемент карточки его не отображает. \ lib/src/feature/orders_tab/order_room/widget/actullity/title_card_widget.dart:100-447, lib/src/feature/orders_tab/order_room/cubit/order_room_cubit.dart:283 | Разработка | Open | Либо добавить строку с расстоянием (значение уже есть на клиенте), либо согласовать с бизнесом, что для архивного заказа расстояние не показывается, и убрать его из требования. | Вопрос к бизнесу. Заказ уже прошёл — расстояние до площадки тут зачем? Предлагаем убрать из требования. Если всё же надо — значение на клиенте есть, добавим строку. |
| OQ4.2.1-10 | FR4.2.1-6 | Требование говорит: нажатие на название площадки переводит в раздел «Информация о площадке/услуге». В коде нажатие на название площадки раскрывает и сворачивает блок площадки; переход к описанию площадки повешен на отдельную кнопку «К площадке» внутри раскрытого блока. \ lib/src/feature/orders_tab/order_room/widget/actullity/title_card_widget.dart:74-79, :380-415, :30-44 | Бизнес | Open | Развести два действия: решить, что делает тап по названию — раскрывает блок (как сейчас) или уводит на площадку. Сейчас поведение осмысленное, но противоречит BRD; дешевле поправить требование, чем ломать привычный жест раскрытия. | Вопрос к бизнесу. Предлагаем поправить BRD под код: тап раскрывает блок, переход — кнопкой «К площадке». Ломать привычный жест ради буквы требования смысла нет. |
| OQ4.2.1-11 | FR4.2.1-7 | Требование говорит: нажатие на видеомаршрут открывает соответствующий материал. В коде «Видеомаршрут» — это неинтерактивная плашка с текстом и иконкой, обработчика нажатия у нее нет; поле со ссылкой на видеомаршрут в модели экрана объявлено, но нигде не заполняется и не используется. Карта, «Как нас найти» и «К площадке» при этом работают. \ lib/src/feature/orders_tab/order_room/widget/actullity/title_card_widget.dart:136-171 (нет обработчика), :179-203 (карта), :338-350 («Как нас найти»), :382-412 («К площадке»); lib/src/feature/orders_tab/order_room/model/order_screen_dto.dart:58 (поле не используется) | Разработка | Open | Подключить видеомаршрут к данным площадки и открывать его так же, как в разделе 2.4, либо временно скрыть плашку, чтобы она не выглядела кликабельной. | Прячем плашку. Обработчика нет, ссылка в модели не заполняется — сейчас это мёртвый элемент, который выглядит кликабельным. Подключим, если бэк начнёт отдавать ссылку. |
| OQ4.2.1-12 | FR4.2.1-9 | Требование говорит: интерфейс показывает сохраненное значение опций заказа. В коде блок опции выводит название опции и ее значение по умолчанию из справочника опций, а не значение, сохраненное в заказе; сохраненное значение заказа в модели экрана есть, но в блок не передается. \ lib/src/feature/orders_tab/order_room/order_room_screen.dart:494-508, lib/src/core/components/repositories/partner_zone_service/models/option_model.dart:13 (defaultValue — справочное), lib/src/feature/orders_tab/order_room/model/order_screen_dto.dart:115 (range — из заказа, не выводится) | Разработка | Open | Проверить на заказе, где значение опции отличается от умолчания: если на экране показывается умолчание — выводить сохраненное значение из заказа. | Чиним: выводим сохранённое значение из заказа вместо умолчания из справочника. Значение уже в модели, надо просто прокинуть. |
| OQ4.2.1-13 | FR4.2.1-10 | Требование говорит: в свернутом блоке «Дополнительные позиции» видны типы добавленных позиций («Оборудование и услуги») и их сохраненная общая стоимость. В коде в свернутом виде есть только заголовок «Дополнительные позиции» и статичная строка «Дополнительно» со стрелкой: типы позиций не перечисляются, а сумма выводится только при наличии результата расчета заказа, которого для архивных заказов нет (расчет намеренно не запрашивается). \ lib/src/feature/orders_tab/order_room/widget/actullity/equip_service_widget.dart:62-105, :69-76; lib/src/feature/orders_tab/order_room/cubit/order_room_cubit.dart:292-308 | Разработка | Open | Брать сохраненную стоимость позиций из данных заказа, а не из онлайн-расчета, и подписывать свернутый блок фактическими типами позиций. Общая причина — см. OQ4.2.1-28. | Сумму сделаем в рамках OQ4.2.1-28. По перечислению типов — вопрос к бизнесу: хватит ли суммы, или реально нужен список типов в свёрнутом виде? |
| OQ4.2.1-14 | FR4.2.1-11 | Требование говорит: при раскрытии для каждой позиции показываются изображение, название, стоимость и количество в заказе. В коде в режиме просмотра (архив) выводятся изображение, название и «В заказе N», а строка со стоимостью позиции показывается только в режиме редактирования — то есть на архивной карточке цены позиции клиент не видит. Группировка при этом есть, но подписи разделов — «Оборудования» и «Услуги». \ lib/src/feature/orders_tab/order_room/widget/actullity/equipment_cell_widget.dart:68-80, lib/src/feature/orders_tab/order_room/widget/actullity/equip_service_widget.dart:126, :146 | Разработка | Open | Показывать стоимость позиции и в режиме просмотра. Заодно поправить подпись «Оборудования» → «Оборудование» в соответствии с BRD. | Чиним: показываем стоимость и в просмотре, «Оборудования» → «Оборудование». Обе правки копеечные. |
| OQ4.2.1-15 | FR4.2.1-12 | Требование говорит: если в архивном заказе сохранен сбор, показывается блок «Сбор» с суммой и основанием. В коде блок «Сбор» отрисовывается только при условии, что сумма сбора пришла в результате онлайн-расчета заказа, а этот расчет для архивных заказов сознательно не выполняется — значит, на карточке архивного заказа блок «Сбор» не появится никогда, даже если сбор в заказе есть (сумма сбора при этом лежит в данных заказа отдельным полем и используется только в диалогах отмены). \ lib/src/feature/orders_tab/order_room/order_room_screen.dart:530-547, lib/src/feature/orders_tab/order_room/cubit/order_room_cubit.dart:292-308, :284 (forfeitSum из заказа) | Разработка | Open | Показывать блок по сохраненной в заказе сумме сбора, а не по результату расчета. Требование веса 1 — проверить в первую очередь на отмененном с нарушением правил заказе. | Чиним: рисуем блок по forfeitSum из заказа. Вес 1, берём. Проверять на отменённом с нарушением правил. |
| OQ4.2.1-16 | FR4.2.1-12 | Требование говорит: при раскрытии блока «Сбор» отображаются основания, суммы и периоды действия. В коде в заказ подставляются все сборы клиента по данной партнерской зоне, а не сборы этого заказа (фильтр только по партнерской зоне, рядом стоит пометка разработчика «Фильтровать fees»); в раскрытом виде для каждого сбора выводится текст основания и интервал заказа, к которому сбор относится, — суммы по каждому сбору нет. \ lib/src/feature/orders_tab/order_room/cubit/order_room_cubit.dart:226-233, :198; lib/src/feature/orders_tab/order_room/widget/actullity/forfeit_block_widget.dart:112-132 | Разработка | Open | Фильтровать сборы по идентификатору заказа и выводить сумму каждого сбора. Сейчас клиент может увидеть в архивном заказе чужие сборы той же площадки. | Чиним фильтр по orderId. Поправка к формулировке: сборы не чужие — метод отдаёт сборы самого клиента, так что в карточку лезут его же сборы по другим заказам той же зоны. Утечки нет, но путаница есть. |
| OQ4.2.1-17 | FR4.2.1-13 | Требование говорит: для примененного промокода показываются код, общая сумма скидки и детализация по времени и дополнительным позициям (цена после скидки, зачеркнутая исходная, процент). В коде вся эта детализация построена на результате онлайн-расчета заказа, которого для архивных заказов нет, поэтому ветка с кодом, суммой и процентами на архивной карточке не выполняется — вместо нее показывается кнопка подбора промокода (см. OQ4.2.1-5). \ lib/src/feature/orders_tab/order_room/widget/actullity/discount_widget.dart:104-105, :112-194; lib/src/feature/orders_tab/order_room/cubit/order_room_cubit.dart:292-308 | Разработка | Open | Выводить сохраненные в заказе суммы до и после скидки вместо пересчета. Общая причина — см. OQ4.2.1-28. | Вопрос к бизнесу. Полная детализация с процентами и зачёркнутыми ценами в архиве точно нужна? Дешевле показать код + сумму скидки. Если да — делаем в рамках OQ4.2.1-28. |
| OQ4.2.1-18 | FR4.2.1-14 | Требование говорит: длинный комментарий отображается в пределах блока до трех строк и при превышении сокращается. В коде комментарий выводится в многострочном поле фиксированной высоты 100 точек без ограничения по числу строк и без сокращения — длинный текст просто прокручивается внутри поля. \ lib/src/feature/orders_tab/order_room/widget/actullity/comment_widget.dart:45-61 | Разработка | Open | Для архивной карточки заменить поле ввода на текст с ограничением в три строки и многоточием (как это сделано в блоке оснований сбора). | Чиним вместе с -3: на архиве вместо поля ввода Text с тремя строками и многоточием. |
| OQ4.2.1-19 | FR4.2.1-15 | Требование говорит: клиент видит сохраненный для заказа способ оплаты. В коде блок «Способ оплаты» строит список из доступных способов, полученных в онлайн-расчете; для архивного заказа расчет не выполняется, список пуст, и клиенту показывается текст «Нет доступных способов оплаты». Сохраненный в заказе способ оплаты при этом не выводится. \ lib/src/feature/orders_tab/order_room/widget/actullity/payment_type_widget.dart:42, :120-127; lib/src/feature/orders_tab/order_room/cubit/order_room_cubit.dart:292-308, :360-384 | Разработка | Open | Показывать на архивной карточке сохраненный способ оплаты из данных заказа (текстом, без выбора). Сейчас в завершенном оплаченном заказе клиент видит «Нет доступных способов оплаты» — это выглядит как ошибка. Требование веса 1. | Чиним: выводим сохранённый способ текстом. Сейчас в оплаченном заказе висит «Нет доступных способов оплаты» — выглядит как поломка. Вес 1, берём. |
| OQ4.2.1-20 | FR4.2.1-17 | Требование говорит: клиент может открыть сохраненные условия отмены заказа. В коде кнопка «Условия отмены» выводится только для карточки текущего заказа; на карточке архивного заказа этого блока нет. \ lib/src/feature/orders_tab/order_room/order_room_screen.dart:600-619 | Разработка | Open | Решить с бизнесом, нужны ли условия отмены в архиве (для отмененного заказа это объяснение удержанной суммы). Если нужны — снять ограничение по типу карточки; текст условий уже собирается отдельной функцией. | Вопрос к бизнесу. Нужны ли условия отмены в архиве? Наше мнение — только для отменённых (объясняют удержанную сумму), для завершённых смысла нет. Технически снять ограничение дёшево. |
| OQ4.2.1-21 | FR4.2.1-18 | Требование говорит: нажатие на текст согласия открывает экран правил площадки и показывает сохраненный факт согласия клиента. В коде строка «С правилами площадки соглашаюсь» на карточке заказа выводится без обработчика нажатия на текст — экран правил не открывается (на экране оформления заказа такой обработчик есть, здесь его не передали). Сам чекбокс отображается всегда отмеченным и активным по виду: значение жестко задано как «да», обработчик переключения пустой, то есть согласие не читается из данных заказа. \ lib/src/feature/orders_tab/order_room/order_room_screen.dart:645-669, lib/src/feature/rooms_search/widget/rooms_filter_modal_old.dart:59-70 (текст кликабелен только при переданном обработчике), lib/src/feature/order_result/widget/order_result_screen.dart:1516-1591 (как сделано на оформлении) | Разработка | Open | Передать обработчик открытия правил площадки и брать состояние согласия из заказа, а не из константы. Уточнить у бэкенда, хранится ли факт согласия в заказе, — если нет, вопрос уходит бизнесу. | Вопрос к бизнесу. Факт согласия на бэке скорее всего не хранится (в заказе поля нет) — предлагаем просто убрать чекбокс из архивной карточки, он всё равно захардкожен в «да» и вводит в заблуждение. Обработчик открытия правил прокинем, это дёшево. |
| OQ4.2.1-22 | FR4.2.1-19 | Требование говорит: на архивной карточке доступно действие «Связаться с площадкой» с «Написать» и «Позвонить». В коде блок «Связаться с площадкой» выводится только для карточки текущего заказа; на архивной карточке его нет, и в нижней панели действий вариант «Связаться» тоже недоступен (он предусмотрен только для абонементов). \ lib/src/feature/orders_tab/order_room/order_room_screen.dart:620-643, lib/src/feature/orders_tab/utils/conditions_btns_util.dart:57-58 | Разработка | Open | Снять ограничение по типу карточки — телефоны и почта площадки уже загружаются и лежат в модели экрана, панель связи переиспользуется без доработок. | Вопрос к бизнесу. Связь с площадкой по завершённому заказу — по какому поводу? Если сценарий есть, сделаем (дёшево, панель переиспользуется). Если нет — убираем из требования. |
| OQ4.2.1-23 | FR4.2.1-20, FR4.2.1-21 | Что подтверждено: действие «История изменений» и экран истории операций заказа в коде отсутствуют полностью — поиск по проекту не находит ни такого действия, ни обращения к истории операций. Это совпадает с пометкой самих требований «(на будущую реализацию)». \ поиск по lib/ — совпадений нет; раздел карточки: lib/src/feature/orders_tab/order_room/order_room_screen.dart:316-702 | Разработка | Подтверждено | Расхождения нет: требования веса 3 помечены как будущие. Держать статус «Не реализовано» до появления раздела 9.2 «История операций с сущностями». | Расхождений нет, ждём 9.2. Ничего не делаем. |
| OQ4.2.1-24 | FR4.2.1-22 | Требование говорит: в нижней панели архивного заказа показываются действия «Оценить» и «Повторить». В коде обе кнопки показываются только если с окончания заказа прошло не больше 14 дней и отзыв по нему еще не оставлен; иначе остается одна кнопка «Повторить». Кроме того, состав панели считается по статусу заказа и оплаты, а не по вкладке: заказ в статусе «резерв», попавший в «Историю», получит кнопки «Отменить»/«Оплатить». Элементы переноса на архивной карточке действительно скрыты. \ lib/src/feature/orders_tab/utils/conditions_btns_util.dart:49-88, :97; lib/src/core/config/app_config.dart:56 (14 дней); lib/src/feature/orders_tab/order_room/widget/actullity/buttons_panel_widget.dart:137-150, :196-227 | Бизнес | Open | Зафиксировать в BRD правило доступности оценки (окно 14 дней, один отзыв на заказ) — сейчас требование сформулировано безусловно, а код ограничивает. Отдельно уточнить, какие кнопки должны быть у отклоненной заявки. | Вопрос к бизнесу. Предлагаем просто дописать в BRD текущее поведение: окно 14 дней + один отзыв на заказ. Отдельно — какие кнопки у отклонённой заявки и у «резерва», попавшего в историю. Код не трогаем до ответа. |
| OQ4.2.1-25 | FR4.2.1-23 | Что подтверждено: нажатие «Оценить» передает выбранный заказ (идентификаторы заказа, комнаты, базы и партнерской зоны) и открывает форму оценки и отзыва. Форма открывается модальным окном поверх карточки, а не отдельным экраном. \ lib/src/feature/orders_tab/order_room/widget/actullity/buttons_panel_widget.dart:203-219, lib/src/feature/add_review/add_review_screen.dart:20-45 | Разработка | Подтверждено | Расхождения по сути нет. Если для бизнеса важна форма подачи (модальное окно против отдельного экрана) — уточнить в разделе 4.2.3. | Расхождений нет. Модалка vs экран — если важно, уточняем в 4.2.3, здесь не трогаем. |
| OQ4.2.1-26 | FR4.2.1-24 | Требование говорит: «Повторить» передает данные архивного заказа и открывает раздел «Повтор заказа». В коде у одной и той же кнопки две разные реализации в зависимости от состава панели: когда рядом есть «Оценить» — открывается карточка площадки (выбор времени начинается заново); когда кнопка одна — открывается экран выбора времени, причем с признаком сценария переноса заказа, а не создания нового. \ lib/src/feature/orders_tab/order_room/widget/actullity/buttons_panel_widget.dart:220-224 и :140-146; lib/src/feature/orders_tab/order_room/utils/order_utils.dart:49-94 и :110-171 | Разработка | Open | Свести обе ветки к одному сценарию повтора и не передавать признак переноса там, где заказ создается заново, — иначе поведение «Повторить» зависит от того, доступна ли еще оценка. | Чиним: сводим к одному сценарию, признак переноса при создании нового заказа не передаём. То, что поведение кнопки зависит от доступности оценки, — точно баг. |
| OQ4.2.1-27 | Обратный проход | Что нашли: карточка архивного заказа — это тот же экран, что и карточка текущего заказа, но ветвление идет не по признаку «архивный», а по типу вкладки, с которой открыт заказ (order / pastOrder / abonement), и дополнительно по статусу заказа и статусу оплаты. Признак isArchived в модели площадки к архивности заказа отношения не имеет — это флаг архивности справочника характеристик площадки. \ lib/src/feature/orders_tab/utils/conditions_btns_util.dart:17 (тип страницы), lib/src/feature/orders_tab/widget/booking_list.dart:73-77 (вкладка задает тип), lib/src/feature/orders_tab/order_room/order_room_screen.dart:600, :620, :645-648 (ветвления); lib/src/feature/orders_tab/order_room/model/room_details_mobile.dart:50, :66 (isArchived относится к характеристикам площадки) | Разработка | Подтверждено | Факт зафиксирован для последующих сверок: «архивность» на этом экране определяется вкладкой и статусом заказа. Отсюда же расхождения OQ4.2.1-20, -22, -24: часть блоков привязана к типу вкладки, часть — к статусам, и эти два признака расходятся. | Факт принят. Единый признак из OQ4.2.1-6 это и лечит. |
| OQ4.2.1-28 | Обратный проход | Что нашли: одна общая причина у четырех расхождений веса 1–2 (FR4.2.1-10, -12, -13, -15). Онлайн-расчет заказа намеренно не выполняется, если заказ не в статусе «резерв», — то есть для всех архивных заказов результата расчета нет. При этом блоки «Дополнительные позиции» (сумма), «Сбор», детализация промокода и «Способ оплаты» берут данные именно из расчета, а не из сохраненных полей заказа, и поэтому на архивной карточке пустуют или показывают заглушку. \ lib/src/feature/orders_tab/order_room/cubit/order_room_cubit.dart:292-308 (расчет отключен для архива), lib/src/feature/orders_tab/order_room/order_room_screen.dart:530, lib/src/feature/orders_tab/order_room/widget/actullity/equip_service_widget.dart:69, lib/src/feature/orders_tab/order_room/widget/actullity/discount_widget.dart:105, lib/src/feature/orders_tab/order_room/widget/actullity/payment_type_widget.dart:42 | Разработка | Open | Решать одной задачей: для архивной карточки источником сумм должны быть сохраненные в заказе значения, а не онлайн-расчет. Это закроет OQ4.2.1-13, -15, -17, -19 разом. | Берём одной задачей, это корень -13, -15, -17, -19. Для архива источник сумм — сохранённые поля заказа. Подтверждаю: расчёт требует статус «резерв», для архива его нет by design. |
| OQ4.2.1-29 | FR4.2.1-8 | Что подтверждено: блок даты и времени архивного заказа показывает дату и день недели («14 июля, вторник») и временной интервал с длительностью («15:00-16:00, 1ч») — то есть все четыре элемента требования. \ lib/src/feature/orders_tab/order_room/order_room_screen.dart:327-335, lib/src/core/utils/utils.dart:710-745 | Разработка | Подтверждено | Расхождений нет, действий не требуется. | Расхождений нет, ничего не делаем. |