Список всех рабочих прототипов по задачам — чтобы не искать пути к файлам вручную. У каждого прототипа в шапке кликабельно лого — открывает требования по задаче.
Корзина и чекаут сегодня считают заказ единой неделимой поставкой — один адрес, один способ получения, одна дата на весь заказ.
С запуском маркетплейса товары в одной корзине смогут ехать от разных продавцов (DBS) — текущая модель для этого не подходит.
В корзине — выбор товаров флажками (что оформить сейчас) и группировка по продавцу. Чекаут дробится на независимые блоки доставки: один на «Холодильник.Ру» (наш склад) и по одному на каждого DBS-продавца — у каждого блока свой адрес, дата/время и способ получения. Оформление создаёт несколько независимых заказов, а не один заказ с несколькими поставками.
Конверсия оформления при дроблении на несколько блоков доставки против недробимого заказа; частота случаев, когда часть товаров исключается из заказа по способу оплаты. Точный состав метрик — на усмотрение дата-аналитика.
Флажок у каждого товара (по умолчанию все выбраны) плюс общий флажок «Все товары». Оформление и пересчёт суммы/бонусов идёт только по отмеченным. Невыбранные товары остаются в корзине.
Приглушённые карточки без флажка и степпера, под основным списком — никогда не попадают в оформление. Действия «в избранное»/«удалить» остаются активными.
Товары в корзине визуально сгруппированы по продавцу (свой склад / DBS), без дат и стоимости доставки — на этапе корзины ещё нет адреса, чтобы их честно посчитать.
«Способы получения заказа» — блок «Холодильник.Ру» плюс отдельный блок на каждого DBS-продавца. Показываются только блоки, чьи товары реально выбраны в корзине. Каждый блок визуально самостоятелен (не сливается с соседними) — как отдельный заказ.
Не один заказ с несколькими поставками — несколько независимых заказов, по одному на блок доставки.
Один адресный справочник (сохранённые адреса), но выбор конкретного адреса — отдельное состояние в каждом блоке доставки. Переключение адреса в одном блоке не влияет на другие.
Курьер/самовывоз — свойство конкретного продавца, не универсальный шаблон: у одних DBS-продавцов есть самовывоз (свои пункты выдачи, не пересекаются с сетью ХОЛОДИЛЬНИК.РУ), у других — только курьер. Детализация даты/времени тоже может различаться по продавцу (точный слот / только дата / только ориентировочный диапазон).
При выборе этого способа оплаты недоступные товары не пропадают из заказа молча — визуально помечаются в своём блоке доставки, исключаются из «Итого» вместе со стоимостью своих услуг, над сводкой появляется предупреждение. Если у блока не остаётся ни одного доступного товара — блок не скрывается, но перестаёт учитываться в доставке и становится полностью некликабельным.
Помимо нескольких способов на виду — попап «Все способы оплаты» (7 методов: СБП, Карта, Яндекс Сплит, СберСпасибо, Яндекс Пэй, При получении, По счету), с предупреждением об отключении бонусов ХОЛОДИЛЬНИК.РУ для части способов.
Между чекаутом и оплатой — экран подтверждения: та же группировка по блокам доставки, что и на чекауте, каждый блок подтверждается отдельно как отдельный будущий заказ. Состав, адрес, дата и стоимость доставки показаны, но уже не редактируются на этом экране.
Хотя оформление создаёт несколько независимых заказов (см. п.5), оплата одна общая на все — один переход к провайдеру, одна сумма, одно подтверждение. Отдельной оплаты на каждый заказ нет. Экран оплаты — нейтральная заглушка, не клонирует брендинг стороннего провайдера.
Так как оформление создаёт несколько независимых заказов (см. п.5), страница «Спасибо за заказ» показывает по одной карточке на каждый — свой номер заказа, состав, адрес и дата доставки. Общий статус пути один на всех, так как все заказы только что созданы одновременно.
Прикрепить ссылку/задачу на макеты.
OOK-696Внутренний журнал изменений по датам — не для дизайнера/аналитика, но полезен при дальнейших доработках. Актуальные требования — в соседнем документе «Требования к задаче».
As-is корзины — снимок текущего вида без новой функциональности: степпер не пересчитывает сумму, тумблеры допуслуг/бонусов/юрлица ничего не считают, промокод декоративен, назначение бейджа «0012» на строке рассрочки не выяснено.
As-is чекаута — копия чекаута OOK-275 как отправная точка, без изменений.
To-be корзина, первая версия: выбор товаров флажками (по умолчанию все выбраны) + общий флажок «Все товары», панель оплаты пересчитывается только по отмеченным. Группировка по продавцу — «Холодильник.Ру» (2 товара), два DBS-продавца (по 1 товару каждый), без дат/стоимости доставки. Блок «Товары не в наличии» отдельно, с приглушённым видом, без флажка/степпера. Переход в чекаут передаёт выбор через localStorage. Полноширинные карточки допуслуг заменены на компактный ряд чипов под товаром — позже в тот же день пересобран: чипы перенесены внутрь карточки товара (а не отдельным блоком со смещением), чтобы принадлежность товару считывалась из структуры разметки, а не из отступов. По отдельной просьбе убрано визуальное затемнение товара при снятии флажка — остаётся только изменение самого флажка.
To-be чекаут, первая версия: редактирование существующего сохранённого адреса (кнопки «Сохранить изменения»/«Отмена», отдельная ссылка «Сохранить как новый адрес»). Поле названия адреса стало везде необязательным (сверено с личным кабинетом OOK-275), термин «по умолчанию» унифицирован на «Основной».
Чекаут дробится на блоки: «Способы получения заказа» — уже не единый блок, а «Холодильник.Ру» (прежняя логика без изменений) плюс отдельный блок на каждого DBS-продавца со своей датой/временем/стоимостью доставки. Показываются только блоки с реально выбранными в корзине товарами. Адрес по умолчанию общий (из блока «Холодильник.Ру»), с возможностью указать другой адрес для конкретной доставки.
Блоки визуально стали отдельными заказами — раньше отличались только мелкой подписью продавца и сливались друг с другом (товары — мелкими иконками). Теперь каждый блок — отдельная карточка с крупным заголовком («Доставка от Холодильник.Ру» / «Доставка партнёром …») и товарами-чипами с полным названием.
Самовывоз — не у всех DBS-продавцов одинаковый: у одного есть вкладка «Курьером/Самовывоз» со своими пунктами выдачи (не пересекаются с сетью ХОЛОДИЛЬНИК.РУ, оба варианта бесплатны), у другого — только курьер, без переключателя.
Услуги перестали теряться при переходе в чекаут — раньше отмеченные в корзине допуслуги (гарантии/установка) не передавались дальше, их стоимость выпадала из суммы заказа. Теперь передаются вместе с товарами, в сводке — отдельная строка «Услуги».
Полный список способов оплаты — 4-я вкладка «Ещё» раньше ничего не делала (на мобильном её не было вовсе). По скриншоту реального сайта добавлен попап «Все способы оплаты» — 7 методов (СБП, Карта, Яндекс Сплит, СберСпасибо, Яндекс Пэй, При получении, По счету) с предупреждением об отключении бонусов для части способов. Одинаково на десктопе и мобильном, во всех 4 файлах чекаута (as-is/to-be × десктоп/моб.) — это не специфика дробления корзины, а закрытие общего пробела чекаута.
Не все товары доступны для «Яндекс Сплит»: из 4 демо-товаров недоступны 2 — один в DBS-блоке (единственный товар блока), один в блоке «Холодильник.Ру» (второй из двух товаров блока) — специально, чтобы показать оба случая: «блок теряет часть товаров» и «блок теряет все товары». При выборе «Яндекс Сплит» недоступные товары не пропадают молча — чип визуально приглушается + постоянно виден красный значок-восклицание с тултипом (изначально была текстовая подпись «· нет в Сплит», заменена на иконку — обрезалась многоточием при длинных названиях). Стоимость товара и его услуг исключается из «Итого», над сводкой — предупреждение. Если у блока не остаётся ни одного доступного товара — блок не скрывается, но его доставка перестаёт учитываться, появляется поясняющая строка, и весь блок становится приглушённым и полностью некликабельным (вкладки/дата/время/«Изменить» адрес не реагируют; заголовок блока остаётся читаемым). При возврате к другому способу оплаты всё восстанавливается.
Адрес стал независимым по блокам: раньше полноценный выбор адреса был только в блоке «Холодильник.Ру» — DBS-блоки лишь отражали его текстом с голым текстовым полем для «Другого адреса». Проблема: если в заказе нет товаров «Холодильник.Ру» (только DBS), блок «Холодильник.Ру» скрывается — а вместе с ним пропадал единственный способ выбрать/добавить адрес вообще. Решено: общий адресный справочник, но выбор в каждом блоке — независимое состояние; каждый блок свёрнут в компактную строку «Адрес: …» + «Изменить», открывающую общий попап (тот же паттерн, что «Все способы оплаты»).
Три бага, найденные при сквозном анализе прототипа: (1) редактирование общего адреса обновляло на экране только тот блок, из которого был открыт попап, хотя данные в справочнике менялись у всех — теперь перерисовываются все три блока; (2) переключение блока «Холодильник.Ру» на «Самовывoз» не обнуляло стоимость доставки в сводке (у DBS-блоков уже работало верно) — исправлено; (3) количество товара (степпер в корзине) полностью терялось при переходе в чекаут — всё считалось как за 1 штуку. Теперь степпер пересчитывает сумму на месте, количество передаётся в чекаут вместе с id товара, чип получает пометку «×N» при количестве больше 1. Цена услуги по-прежнему не масштабируется вместе с товаром — сознательно не в скоупе.
Блок «Холодильник.Ру» визуально выровнен с DBS-блоками — раньше дата/время доставки была вынесена в отдельную серую карточку под основной (унаследовано от OOK-275, где на чекауте был только один блок), тогда как у DBS всё было одним блоком. Причин оставлять так не нашлось — объединено, все три блока выглядят одинаково.
Детализация даты/времени у DBS-партнёров стала разной: один продавец — только выбор даты без слота (доставка стала бесплатной), другой — вообще без выбора, статичный ориентировочный диапазон. Получилась лестница уровней сервиса: «Холодильник.Ру» (дата + платный точный слот) → продавец A (только дата) → продавец B (только диапазон).
При разборе аналогичного вопроса в другой задаче (услуги как отдельные товары) решено: оформление создаёт несколько независимых заказов, а не один заказ с несколькими поставками — решение продиктовано ограничением стороннего подрядчика по услугам (не должен получать заказ до оплаты), но применено симметрично и к дроблению по продавцам, чтобы не поддерживать две разные модели дробления одновременно. Единый ответ для обоих случаев дробления корзины.
Задача создавалась до правил «три уровня документации» и «6 разделов требований» (появились 5 дней спустя, на OOK-834) и с тех пор не была приведена в соответствие — карточка не имела «Требования к задаче» вовсе, весь текст жил в 8 отдельных модалках прототипов вперемешку с датированными обновлениями и фразами «Статус: реализовано в прототипе». Проведён аудит, по итогам — полная пересборка.
Создан этот документ и «Требования к задаче» — по 6-разделному шаблону, синтез содержимого всех 8 модалок. Технические детали (localStorage, конкретные функции, CSS-классы) убраны из требований — остались в этом историческом документе, где они и были, и в самих модалках-комментариях (см. ниже). Открытые вопросы переведены на нумерованный список.
Закрыт устаревший открытый вопрос «один заказ или несколько поставок» — он числился открытым в требованиях корзины и чекаута, хотя решён ещё 2026-07-29 (см. выше) и записан в базе знаний. Заодно найдена и исправлена внутренняя нестыковка в самой базе знаний (internal/knowledge-base.html, раздел 11) — фраза «механика дробления всё ещё не спроектирована» оставалась в тексте, хотя весь остальной раздел эту механику подробно описывает; убрана как неактуальный остаток раннего черновика.
Модалки внутри каждого из 8 файлов прототипов сокращены до правила 4 — только то, что специфично для конкретного экрана/файла и не сказано в общем документе (мобильные отличия от десктопа, демо-упрощения конкретного файла), без пересказа бизнес-логики.
Проверено в браузере: все 8 файлов открываются без ошибок в консоли (кроме favicon), карточка на index.html показывает «Требования к задаче», требования открываются и структурированы по 6 разделам.
Пользователь попросил добавить в задачу два следующих шага воронки, указав, что as-is для них уже где-то есть — использовать. As-is этих двух экранов реального сайта уже был собран раньше в рамках OOK-836 (ook-836-checkout-confirm-asis.html/-mobile, ook-836-typ-asis.html/-mobile) — эти файлы генерические снимки реального сайта, не завязаны на специфику услуг OOK-836 (десктопный as-is подтверждения даже уже ссылался на ook-696-checkout-asis.html как на предыдущий шаг). Взяты за основу без пересъёмки: скопированы в 4 новых файла ook-696-checkout-confirm-asis.html/-mobile, ook-696-typ-asis.html/-mobile, с обновлением бейджа задачи и перекрёстных ссылок. Единственное отличие от исходников: кнопка «Перейти к оплате» сделана декоративной (data-decorative) вместо ссылки на несуществующий для этой задачи шаг оплаты.
To-be «Подтверждение заказа» (ook-696-checkout-confirm-tobe.html/-mobile) — по образцу того, как это уже сделано в OOK-836 (читает выбор из localStorage, группирует по тем же блокам, что чекаут, каждый блок — read-only карточка с составом/адресом/датой/стоимостью доставки), но с собственным каталогом OOK-696 (4 товара, 3 продавца — «Холодильник.Ру», КМ-Профиль, Новатек-Электро — вместо 2 продавцов + услуг OOK-836) и без отдельного блока услуг: услуги в OOK-696 — не свой блок доставки, а строка в сводке и подпись внутри блока владеющего товара (как уже сделано в самом чекауте OOK-696).
To-be «Спасибо за заказ» (ook-696-typ-tobe.html/-mobile) — здесь пришлось спроектировать заново, не просто скопировать паттерн OOK-836: его собственный TYP показывает один заказ с одним номером, хотя сама задача OOK-836 тоже создаёт несколько независимых заказов (услуги отдельно от товаров) — эта часть решения там осталась не визуализирована. Для OOK-696 экран показывает отдельную карточку на каждый созданный заказ (по одному на активный блок доставки корзины) — свой номер (сквозная демо-нумерация от 7387281), свой состав, свой адрес/дата, общий статус-путь один на всех. Заголовок и подзаголовок динамически меняются в зависимости от числа заказов («Заказ №N оформлен» при одном / «Заказ разделён на N поставки — оформлено N отдельных заказа» при нескольких).
Осознанно не строился отдельный шаг оплаты между подтверждением и «Спасибо за заказ» — пользователь просил ровно два шага. Кнопка «Перейти к оплате» на to-be подтверждении ведёт сразу на «Спасибо за заказ», зафиксировано как открытый пробел в «Что осознанно не проработано», а не тихо пропущено.
Карточка OOK-696 на index.html дополнена двумя группами кнопок (as-is и to-be), «Требования к задаче» — двумя новыми подразделами (10, 11) и обновлённым списком «Что осознанно не проработано»/«Открытые вопросы».
Проверено в браузере: все 8 новых файлов отдают 200 без ошибок в консоли (кроме favicon); to-be подтверждение и TYP на десктопе и мобильном корректно читают состав корзины и услуг из localStorage и строят блоки/карточки заказов; переход чекаут → подтверждение → «Спасибо за заказ» пройден целиком на обоих платформах.
Пользователь указал: попасть на «Подтверждение заказа» из корзины/чекаута нельзя, только по прямой ссылке. Проверка round 2 выше на самом деле открывала ook-696-checkout-confirm-tobe.html напрямую по URL, а не переходом по кнопке — кнопка «Далее» на чекауте (ook-696-checkout-tobe.html/-mobile-tobe.html) существовала с самого начала задачи (as-is, 2026-07-22) как обычная кнопка без обработчика клика ("пока ничего не валидирует и никуда не ведёт" — задокументированный открытый вопрос as-is) и осталась такой же в to-be, потому что в первой версии to-be чекаута (2026-07-24) дальше просто ничего не было. Когда OOK-836 форкнул себе копию чекаута, обработчик клика на «Далее» добавили только в форк (ook-836-checkout-tobe.html) — в оригинальный ook-696-checkout-tobe.html он так и не попал.
Исправлено: в ook-696-checkout-tobe.html и ook-696-checkout-mobile-tobe.html добавлен обработчик клика на #order-next-btn — переход на ook-696-checkout-confirm-tobe.html/-mobile соответственно. Кнопка по-прежнему блокируется (disabled), если все товары исключены выбранным способом оплаты — в этом состоянии клик и раньше ничего не делал, поведение не изменилось, просто в разблокированном состоянии клик теперь реально ведёт дальше. As-is (ook-696-checkout-asis.html/-mobile) не тронут — там «Далее ничего не делает» отражает реальный открытый вопрос о поведении настоящего сайта, а не пробел прототипа.
Проверено в браузере: полный клик-путь ook-696-cart-tobe.html → «Перейти к оформлению» → ook-696-checkout-tobe.html → «Далее» → ook-696-checkout-confirm-tobe.html → «Перейти к оплате» → ook-696-typ-tobe.html пройден кликами (не прямыми переходами по URL) на десктопе и повторно на мобильных файлах — на каждом шаге верно отражены все 3 блока доставки, товары и суммы.
Пользователь попросил добавить этап оплаты между подтверждением заказа и «Спасибо за заказ», уточнив: оплата единая для всех заказов разом, не по одной на заказ.
Собраны ook-696-payment-redirect.html/-mobile — по образцу уже принятой в проекте нейтральной заглушки (ook-836-payment-redirect.html, Правило 10 в базе знаний — чужой брендинг платёжного провайдера не клонируем): иконка, сумма к оплате, пояснительный текст, жёлтый блок «заказ уже создан со статусом «Не оплачен»», кнопка «Симулировать успешную оплату» (демо-механизм, не часть реального продукта) и ссылка назад к подтверждению.
Ключевое отличие от источника — сумма и подпись объединяют все активные блоки доставки корзины, а не один заказ: сумма читает ook696CartSelection/ook696ServicesSelection из localStorage и складывает товары + услуги + доставку по всем блокам разом (та же логика чтения данных, что уже в ook-696-checkout-confirm-tobe.html). Подпись над суммой динамическая: «Оплата заказа» при одном активном блоке, «Единая оплата за N заказа» при нескольких — чтобы явно показать, что несколько создаваемых заказов оплачиваются одним переходом, а не N отдельными.
Кнопка «Перейти к оплате» на подтверждении заказа (ook-696-checkout-confirm-tobe.html/-mobile) перенаправлена с прямого перехода на TYP (временное упрощение round 2) на новый шаг оплаты; кнопка «Симулировать успешную оплату» на шаге оплаты ведёт на TYP — восстановлена полная цепочка из 4 экранов. Пункт «шаг оплаты не спроектирован» убран из «Что осознанно не проработано», добавлен раздел 11 в требования и открытый вопрос про разнесение единой суммы по отдельным заказам во внутреннем учёте.
Проверено в браузере: полный клик-путь корзина → чекаут → «Далее» → подтверждение → «Перейти к оплате» → заглушка оплаты (верная объединённая сумма и подпись «Единая оплата за 3 заказа») → «Симулировать успешную оплату» → «Спасибо за заказ» пройден кликами на десктопе и мобильном, без ошибок в консоли на обоих новых файлах.
Пользователь заметил: на «Спасибо за заказ» нет статуса оплаты заказов, и спросил, потерян ли он или убран намеренно, с прямой просьбой перепроверить, не потеряно ли что-то ещё.
Подтверждено — это была потеря, не решение. В round 2 экран TYP пересобирался с нуля под мультизаказный макет (карточка на каждый независимый заказ вместо одной общей), и в процессе пересборки блок «Информация об оплате» — присутствовавший и в as-is (ook-696-typ-asis.html/-mobile), и в TYP OOK-836 (typ-payment-info) — никуда не был перенесён. Не было ни решения его убрать, ни упоминания в требованиях или истории round 2 — чистый недосмотр при переносе содержимого в новую структуру.
Сверка всех полей as-is TYP против нового to-be построчно (сравнение заголовков .typ-info-card-title) вскрыла ещё одну потерю того же рода — «Подъём товара» (была и в as-is, и в TYP OOK-836), тоже без следа в требованиях round 2. Третье поле as-is, «Комментарий для курьера» — отсутствует и в TYP OOK-836 тоже, то есть выпало ещё до этой задачи, не в рамках работы над OOK-696; решено не восстанавливать без отдельного запроса, только зафиксировано в ответе пользователю.
Оба поля возвращены с учётом того, что оплата теперь единая (round 4): «Информация об оплате» — одна карточка в сайдбаре (не по одной на заказ), сумма и статус читаются той же логикой, что на ook-696-payment-redirect.html (товары + услуги + доставка по всем активным блокам), формулировка склоняется по числу заказов («Заказ оплачен» / «Заказы оплачены Картой»). «Подъём товара» — наоборот, добавлено в каждую карточку заказа (это свойство конкретной доставки, не оплаты в целом), значение «Не требуется» как в источнике.
Проверено в браузере на десктопе и мобильном: карточка «Информация об оплате» показывает сумму, совпадающую с суммой на шаге оплаты; «Подъём товара» присутствует в каждой карточке заказа (проверено на сценарии с 2 и с 3 активными блоками).
По итогам round 5 пользователь предложил новое правило создания прототипов: в комментарии конкретного файла (клик по лого/заголовку) добавлять раздел «Инфоблоки» — что добавлено, что убрано, коротко, с укрупнением, и сверять список информации до/после при создании прототипа. Правило зафиксировано как Правило 13 в базе знаний (internal/knowledge-base.html, раздел «Подход к созданию прототипов») и в memory-конвенциях проекта — действует для всех будущих задач, не только этой.
Применено к этой задаче: раздел «Инфоблоки» добавлен во все 8 to-be файлов OOK-696, у которых есть as-is-предок для сравнения (корзина, чекаут, подтверждение заказа, TYP — десктоп и моб. каждый). Заглушка оплаты (ook-696-payment-redirect.html) не получила раздел — у неё нет as-is-предка по правилу 10 (не клонируем чужой брендинг), сравнивать не с чем. На мобильных файлах, где комментарий и так только отсылает к десктопной версии («логика идентична»), «Инфоблоки» — тоже однострочная отсылка, не дублирование списка.
Самое содержательное — TYP (ook-696-typ-tobe.html): «Инфоблоки» там прямо называет находку round 5 («Информация об оплате» и «Подъём товара» были случайно потеряны и восстановлены в этом же раунде) и отдельно — «Комментарий для курьера», отсутствующий и в TYP OOK-836, то есть выпавший ещё до этой задачи, не решение OOK-696. Именно такое разделение «наша потеря / унаследованный пробел» — и есть цель правила.
Проверено в браузере: requirements-модалка открывается на всех 8 файлов, раздел «Инфоблоки» рендерится корректно после существующих абзацев, без разрывов вёрстки.
Сегодня вход на сайт и в приложении работает по телефону с подтверждением 4-значным кодом из SMS. SMS стоит денег на каждый вход, и с ростом аудитории эти расходы растут пропорционально числу авторизаций.
Флешколл (подтверждение звонком вместо SMS) дешевле SMS и уже широко используется в похожих российских сервисах. Цель задачи — перевести основной поток авторизаций на флешколл, оставив SMS резервным способом там, где звонок не сработал.
Внедряем авторизацию через звонок (флешколл). Авторизацию через SMS-код оставляем, но деприоритизируем её в интерфейсе по сравнению со звонком.
Доля авторизаций через звонок против SMS, отдельно доля переходов на резервный SMS-код. При появлении входа через ЯндексID — дополнительно доля входов через него против телефона. Точный состав метрик — на усмотрение дата-аналитика.
Сервис Call Password ID, провайдер — компания «Раппорто». Абонент сам звонит на выданный сервисный номер (не наоборот) — звонок бесплатный, автоматически сбрасывается провайдером, отвечать не нужно. Факт входящего звонка с указанного номера подтверждает вход. Сервисный номер выдаётся провайдером на каждую попытку и имеет ограниченное время жизни.
Провайдер не различает причину, по которой подтверждение не пришло, — абонент не успел позвонить в срок или позвонил не с того номера; в обоих случаях просто нет подтверждения, без отдельного кода ошибки для этих случаев. По истечении времени действия номера пользователь запрашивает новый номер у провайдера либо переключается на резервный SMS-код.
SMS-код остаётся доступен, но только как явно запрошенный резервный способ — не равноценная кнопка выбора рядом со звонком.
Отдельного экрана-подтверждения после входа нет — реальный сайт перезагружает страницу, пользователь оказывается авторизован на том же месте. В прототипе это показано прелоадером с переходом на as-is референс главной страницы.
Прототипы сделаны в двух состояниях экрана входа — без ЯндексID (текущее) и с ним, по макету, который предоставил PM (переписка 2026-08-19). Логика самой авторизации звонком одинакова в обоих — различается только первый экран.
OOK-844Внутренний журнал изменений по датам — не для дизайнера/аналитика, но полезен при дальнейших доработках. Актуальные требования — в соседнем документе «Требования к задаче».
Задача поставлена коротко: перевести авторизацию на флешколл ради экономии на SMS, учитывая скорое появление входа через ЯндексID и СберID.
As-is не строился с нуля — переиспользована модалка входа по телефону+SMS, уже собранная в OOK-834 по реальным скриншотам сайта (ook-834-loyalty-gate.html/-mobile), вынесенная в отдельные самостоятельные файлы этой задачи без шага «вступление в программу лояльности» (специфика опросов OOK-834, не часть авторизации как таковой) — вместо него добавлен общий терминальный экран «Вы вошли».
To-be: шаг ввода телефона получил разделитель и две неактивные кнопки-заглушки «ЯндексID»/«СберID» с бейджем «Скоро». По клику «Войти» вместо экрана SMS-кода теперь показывается новый экран ожидания звонка (пульсирующая иконка, номер, пояснение не отвечать) с автопереходом к успеху через 4 секунды (демо-таймер) и ссылкой-фоллбэком «Получить код по SMS», ведущей на прежний экран ввода кода. Экран успеха показывает, каким способом подтверждён вход.
Ключевые предположения, зафиксированные как открытые вопросы (см. соседний документ): автоматическое определение звонка без ввода цифр (не подтверждено бэкендом), флешколл как способ по умолчанию для всех без авто-фоллбэка на SMS по типу номера/оператора, условный демо-тайминг ожидания.
Проверено в браузере: десктоп и моб. — ввод телефона → «Войти» → экран ожидания звонка → автопереход на «Вы вошли» (звонком); повторный проход → ссылка «Получить код по SMS» → ввод 4 цифр → «Вы вошли» (SMS-кодом); requirements-модалка открывается на всех 4 файлах; as-is версия (без флешколла) отдельно проверена тем же путём.
PM приложил реальный макет будущего экрана входа с приоритетным ЯндексID (продвигаем как бесплатный для бизнеса способ) и попросил разделить to-be на «до» и «после» внедрения ЯндексID, убрав из первой фазы заглушки ЯндексID/СберID.
Фаза 1 (ook-844-auth-tobe.html/-mobile-tobe.html) — из первой версии убран блок-разделитель с неактивными кнопками «ЯндексID»/«СберID» (весь CSS и разметка), сама логика флешколла не менялась.
Фаза 2 — два новых файла, ook-844-auth-yandexid-tobe.html/-mobile-tobe.html. Первым экраном модалки/шторки теперь стоит выбор способа входа, собранный по присланному макету: заголовок «Войти в аккаунт», крупная тёмная кнопка «Яндекс ID» (упрощённая иконка — кружок с буквой «Я», не официальный логотип), разделитель «или», две светло-голубые кнопки «Войти по номеру телефона» / «Войти по почте». Согласие на рассылки и легал-текст перенесены с шага ввода телефона на этот экран (в макете показаны один раз, до выбора способа). «Войти по номеру телефона» — единственный реально работающий путь, ведёт в уже построенный флешколл-флоу фазы 1 без изменений в его собственной логике; кнопки «Яндекс ID» и «Войти по почте» декоративны (data-decorative, тот же паттерн, что уже используется в проекте для нефункциональных демо-ссылок). Добавлен шаг «назад» с экрана телефона на экран выбора способа — раньше телефонный шаг был первым и кнопки назад не имел.
СберID не включён в фазу 2 — в присланном макете его нет, а собственного макета для него пока не появилось; вместо того чтобы додумывать его размещение, вопрос зафиксирован в требованиях как открытый, кнопка не добавлена ни в одну из фаз.
Замечено, но не изменено в рамках этой задачи: легал-текст на макете PM впервые явно упоминает «включая регистрацию в Программе Лояльности» при входе — это может отвечать на долго висящий открытый вопрос OOK-834 про автовступление в ПЛ при авторизации. Зафиксировано как открытый вопрос с указанием сверить с владельцем OOK-834, файлы OOK-834 не трогались.
Индекс: карточка OOK-844 на index.html — колонка To be разделена на две подгруппы «Фаза 1» и «Фаза 2» с отдельными кнопками Десктоп/Моб. каждая; требования переписаны под обе фазы (детальные требования 1–3 — фаза 1, 4 — фаза 2, 5 — общее для обеих).
Проверено в браузере: оба файла фазы 2 (десктоп и моб.) — открытие модалки/шторки на экране выбора способа → клик «Войти по номеру телефона» → переход на знакомый экран телефона с кнопкой «назад» → «Войти» → ожидание звонка → автопереход «Вы вошли»; клики по «Яндекс ID» и «Войти по почте» подтверждены как decorative (ничего не происходит); фаза 1 (десктоп) — подтверждено отсутствие блока ЯндексID/СберID визуально и в DOM; requirements-модалка проверена на обоих новых файлах.
Пользователь прислал техническую документацию провайдера Rapporto (сервис Call Password ID, версия 1.4 от 11.08.2026) на изучение с просьбой скорректировать прототипы при необходимости.
Обнаружена и исправлена ошибочная исходная гипотеза о направлении звонка. Первая версия прототипа (round 1) предполагала, что система звонит абоненту, а тот не отвечает — система якобы определяет сам факт входящего звонка автоматически. Реальная механика Call Password ID — обратная: Партнёр отправляет провайдеру номер абонента, провайдер в ответ выдаёт специальный сервисный номер, на который абонент сам должен позвонить; звонок автоматически сбрасывается на стороне провайдера, а верификация происходит по факту совпадения номера, с которого позвонили, с ранее указанным номером абонента. Это принципиально другое пользовательское действие (исходящий звонок абонента, а не пассивное ожидание).
Экран флешколла переделан во всех 4 to-be файлах (обе фазы, десктоп и моб.): вместо текста «Ждём звонка на [номер абонента]» теперь показан крупный кликабельный (tel:) сервисный номер для звонка, пояснение «позвоните со своего номера — бесплатно, сбросится автоматически», и статус-строка «Ждём звонка · номер действует ещё 00:59» с настоящим обратным отсчётом (по документации сервисный номер имеет ограниченное время жизни — в примере провайдера 62 секунды, взято близкое круглое значение 59). По истечении таймера — ссылка «Обновить номер», перезапускающая тот же таймер (демо-упрощение того же типа, что уже используется для «переотправки» SMS-кода — реального запроса нового номера у провайдера нет). Ссылка-фоллбэк на резервный SMS-код переименована из «Не дозвонились?» в «Не получилось?», так как «дозвониться» больше не описывает происходящее верно.
Сама демо-механика автоподтверждения не менялась — по-прежнему фиксированные 4 секунды до перехода на экран успеха, что на практике делает ветку «номер истёк» почти недостижимой при обычном клик-тестировании, хотя код для неё рабочий. Экран успеха и переход на SMS-резерв не потребовали изменений логики, только следствия (полная очистка обоих таймеров — callTimeout и нового callTimerInterval — при закрытии модалки, переходе назад и переходе на SMS-фоллбэк, иначе фоновый таймер продолжал бы тикать на скрытом экране).
Открытые вопросы пересобраны под факты из документации: снят вопрос «как система определяет звонок» (теперь известно и задокументировано); добавлены вместо него — что происходит при звонке с другого номера (отдельный сценарий сбоя по документации, не смоделирован отдельно в прототипе), и явно зафиксировано, что каскадная отправка (автоматический технический фолбэк) на стороне провайдера пока не реализована — переключение на SMS в прототипе исключительно наш собственный UI-механизм, не функция провайдера.
Проверено в браузере: десктоп и моб., обе фазы — клик «Войти» → отображается сервисный номер с рабочей tel:-ссылкой и запущенным обратным отсчётом → автопереход на «Вы вошли» через 4с (звонком); повторный проход → ссылка «Не получилось? Получить код по SMS» останавливает оба таймера и показывает знакомый экран ввода кода → 4 цифры → «Вы вошли» (SMS-кодом); кнопка «назад» с экрана флешколла останавливает таймер номера и не оставляет его тикать в фоне (проверено через getComputedStyle/DOM-инспекцию скрытого экрана).
Пользователь указал, что на реальном сайте модального окна-подтверждения после входа не бывает — успешная авторизация приводит к перезагрузке страницы, пользователь просто оказывается авторизован. Попросил заменить экран «Вы вошли» прелоадером (имитация перезагрузки) с переходом на прототип главной страницы, и сначала проверить, есть ли готовый as-is главной.
Найден готовый as-is: reference-homepage.html — полноценный референс главной страницы, ранее убранный из карточки на index.html в рамках OOK-834 round 12 («нам не нужна эта страница» — но файл был сознательно оставлен на диске, не удалён). У него нет мобильного варианта.
Мобильный редирект — временная заглушка, явный выбор пользователя. Спросил, как поступить с прелоадером на мобилке при отсутствии мобильного референса — пользователь выбрал прислать мобильный референс отдельно позже. До этого момента оба мобильных to-be файла временно ведут на десктопный reference-homepage.html (пометка // TODO в коде рядом со строкой редиректа + явная фраза в requirements-модалке каждого мобильного файла) — заменить строго на мобильный референс, когда он появится, не переносить остальную логику.
Реализация одинакова во всех 4 to-be файлах (обе фазы, десктоп и моб.): удалены разметка и стили блока #login-step-success («Вы вошли», кнопка «Готово»), добавлен полноэкранный оверлей-прелоадер .page-reload-overlay (белый фон, спиннер, position:fixed, z-index выше модалки) с классом .is-open для показа. Функция succeed() упрощена — раньше принимала параметр method (звонок/SMS) только чтобы подставить разный текст на экране успеха; так как экрана больше нет, параметр убран как мёртвый код на всех 4 вызовах (enterCallStep() и обработчик ввода кода). Новая логика: закрыть модалку (переиспользована существующая closeLoginModal() — она уже чистила все таймеры), показать прелоадер, через 1.2с — window.location.href на референс.
Проверено в браузере на всех 4 файлах: путь через флешколл (автоуспех 4с) и через SMS-фоллбэк оба корректно закрывают модалку, показывают прелоадер и переходят на reference-homepage.html; на мобильных файлах подтверждено, что редирект пока ведёт на десктопный референс (ожидаемо, задокументированная временная заглушка).
Пользователь прислал скриншот мобильной главной страницы реального сайта (Screenshot_20260819_164728_Chrome.jpg) и попросил свериться с правилами создания прототипов (найдено Правило 6 — «As-is по реальной странице: DOM + нарезанный скриншот вместе, всегда с прокрутки», tools/slice_screenshot.py), собрать полноценный as-is мобильной главной и подключить его к OOK-844 вместо временной заглушки на десктопный референс.
Скриншот нарезан — python3 tools/slice_screenshot.py Screenshot_20260819_164728_Chrome.jpg --outdir tools/tmp/ook844-homepage-mobile: исходник 540×11486px → 8 частей по 1500px, прочитаны все части подряд.
Собран новый файл reference-homepage-mobile.html (не привязан к OOK-844, общий референс — по аналогии с десктопным reference-homepage.html, тоже без своей задачи). Воспроизведено по скриншоту: верхняя строка адреса доставки + иконка чата; промо-баннер (статичный, с точками-индикатором и меткой «Реклама»); декоративная строка поиска «Найти в Холо»; горизонтальный ряд пилюль-акций; 7 карусельных секций товаров с реальными названиями/ценами/бонусами/скидками со скриншота («Режем ценники», «Вы недавно смотрели», «−12 999 ₽ на эти товары…», «Лучшее из Liebherr», «Любимое у покупателей», «Максимальные скидки», «В корзинах наших покупателей»); короткий SEO-блок; подвал-аккордеон из 14 секций (раскрыта только «Акции и бонусы» — единственная, что была раскрыта на скриншоте, с реальным списком из 14 пунктов; остальные — пустые аккордеоны, содержимое неизвестно, было свёрнуто на скриншоте); блок с телефоном/почтой/действиями и текстом «штрихкода»; плавающая кнопка чата; нижний таб-бар (Меню/Каталог/Избранное+6/Поиск/Корзина/Павел).
Важная находка — скриншот снят в авторизованном состоянии. Таб-бар на скриншоте показывает «Павел» вместо «Войти», а вкладка «Поиск» подсвечена активной. Это не подгонка под задачу — так было на самом скриншоте, воспроизведено как есть и отмечено как открытый нюанс (неясно, почему активна именно «Поиск» — возможно случайность конкретного захвата). Это заодно закрыло единственный оставшийся пробел OOK-844 из предыдущего раунда: авторизованное состояние на мобильном референсе теперь показано по-настоящему, не декоративно, в отличие от десктопного референса (там оно осталось декоративным — десктопный скриншот такой не давал).
Компоненты переиспользованы, а не изобретены заново: .mobile-tabbar/.mobile-tabbar-item (из OOK-836), .product-carousel/.product-card (общий компонент), .bonus-pill и .product-card-badge/.product-card-icons/.product-card-price-new/.product-card-discount-подобные классы (из OOK-836/OOK-834, скопированы как локальные для этого файла — те же паттерны не вынесены в components.css, консистентно с уже принятым в проекте подходом page-local стилей), .m-search-bar и аккордеон-подвал .m-footer/details (из OOK-834 мобильной посадочной).
OOK-844 переключён на новый референс: в обоих мобильных to-be файлах (обе фазы) строка редиректа в succeed() изменена с reference-homepage.html на reference-homepage-mobile.html, убран // TODO-комментарий и формулировка «временная заглушка» из requirements-модалок обоих файлов и из карточки на index.html — заменены на факт, что редирект ведёт на настоящий мобильный референс. Десктопные to-be файлы не тронуты (там и раньше был правильный десктопный референс).
Проверено в браузере: reference-homepage-mobile.html открывается без ошибок в консоли (кроме обычного favicon 404), requirements-модалка открывается по клику на блок адреса доставки, все 14 секций подвала кликабельны/раскрываются как аккордеон, «Акции и бонусы» открыта по умолчанию с 14 пунктами; оба мобильных to-be файла OOK-844 (обе фазы) — полный проход через флешколл и через SMS-резерв корректно приводят на новый мобильный референс.
Пользователь отметил, что симуляция звонка ощущается слишком быстрой (около 5 секунд с учётом последующего прелоадера) и попросил сделать 10 секунд.
Изменена константа в enterCallStep() — setTimeout(succeed, 4000) → setTimeout(succeed, 10000) — во всех 4 to-be файлах (обе фазы, десктоп и моб.). Обновлена requirements-модалка ook-844-auth-tobe.html (единственное место, где конкретное число секунд было текстом, а не только кодом) — «фиксированная задержка 4 секунды» → «10 секунд»; остальные 3 файла ссылаются на неё, а не дублируют цифру, править не потребовалось.
Проверено в браузере: на всех 4 файлах клик «Войти» → таймер номера тикает, автопереход на прелоадер/референс происходит около 10-й секунды, не раньше.
Пользователь дал ответы по каждому из 9 пунктов «Открытые вопросы».
Итог: список «Открытые вопросы» полностью опустел и удалён из требований как секция — при появлении новых вопросов в будущих раундах секцию нужно будет добавить заново, а не оставлять пустой.
Заодно обновлена соответствующая формулировка в requirements-модалке ook-844-auth-tobe.html: ссылка «Обновить номер» раньше описывалась как чисто декоративная деталь демо без продуктового смысла — теперь описана как реальное продуктовое поведение (повторный запрос номера у провайдера), в прототипе, естественно, всё ещё имитационная.
Пользователь дал предметную обратную связь по тому, как написаны «Требования к задаче» — не про содержание решения, а про то, как оно изложено. Шесть замечаний:
Документ пересобран целиком. «Описание решения» сокращено с трёх абзацев (с описанием обоих состояний экрана) до двух предложений. «Платформы» лишились всех пояснений («вопрос дизайнеру», «ожидается тот же сценарий» и т.п.) — теперь просто список со статусом. «Детальные требования» перегруппированы не по «фазам», а по темам (механика флешколла / обработка сбоя / SMS как резервный способ / успешный вход) и заметно сокращены — убрано пошаговое описание того, какой экран показывается после какого клика и что на нём написано (это и так видно в прототипе), осталось только то, что не считывается с прототипа напрямую: как на самом деле работает Call Password ID, что провайдер не различает причины сбоя, что после входа нет экрана-подтверждения. «Что осознанно не проработано» тоже подрезано — убраны детали конкретно про референс главной страницы (количество каруселей, свёрнутые пункты подвала), они и так есть в собственной requirements-модалке reference-homepage-mobile.html, дублировать в общем документе задачи не нужно. Деление на «Фазу 1»/«Фазу 2» убрано из всего текста задачи — карточка на index.html (подписи групп кнопок), requirements-модалки всех 4 to-be файлов (бейдж task-id и внутренний текст) переведены на нейтральные «без ЯндексID» / «с ЯндексID»; факт двух состояний макета остался только в разделе «Макеты» одной ремаркой.
Правила базы знаний обновлены, чтобы это не повторялось. Правило 4 дополнено конкретным примером (не упоминать итерации набросков). Правило 5 ужесточено: «Описание решения» по умолчанию — 1–2 абзаца, а не «максимум 4–5»; «Платформы» — без пояснений. Добавлено новое Правило 12 («Детальные требования» — бизнес-факты, не пересказ экранов; деление на фазы/этапы — только когда логика реально разная, и термин «Этап», не «Фаза»).
Проверено в браузере: requirements-модалка OOK-844 открывается, структура из 6 разделов сохранена, слова «СберID» и «Открытые вопросы» в документе не осталось (уже было убрано в раунде 7), слова «Фаза»/«фаза» в актуальном тексте задачи и во всех 4 requirements-модалках прототипов не осталось (в CSS-комментариях и истории разработки — не трогали, это не пользовательский текст задачи).
Пользователь указал: заголовок «Резервный способ: код по SMS» на экране ввода кода не должен так называться — пользователь не должен знать, что это резервный/запасной способ, для него это просто ещё один способ подтвердить вход.
Заголовок заменён на нейтральный «Код из SMS» во всех 4 to-be файлах (обе состояния, десктоп и моб.) — единственное место, где формулировка «резервный способ» была видна в самом интерфейсе. Внутренняя категоризация (SMS — деприоритизированный резервный способ относительно звонка) осталась как есть в требованиях и комментариях к прототипу — это бизнес-описание для PM/дизайнера/аналитика, не то, что видит пользователь на экране.
Проверено в браузере: экран ввода кода на всех 4 файлах показывает «Код из SMS».
OOK-839Клик «В корзину» на карточке товара (моб.) не даёт пользователю подтверждения добавления.
Момент сразу после решения о покупке не используется для допродажи услуг.
После клика «В корзину» на мобильной версии сайта открывается модальное окно:
Допродажа не должна конкурировать с переходом в корзину за главное действие.
Событие добавления услуги из этого окна.
Окно открывается по клику на «В корзину» в блоке покупки карточки товара.
Подтверждение — всегда. Карточки услуг — всегда, независимо от того, добавлена услуга или нет. Если подходящих услуг нет — блока допродажи нет, окно состоит из подтверждения и двух CTA.
Для каждой услуги: заголовок, 2–3 преимущества, цена, флажок-переключатель — тот же компонент, что и на карточке товара. Рейтинг/отзывы не показываются. Флажок по умолчанию снят. Блок скроллится внутри окна.
Включение флажка добавляет услугу, выключение — удаляет. Отдельной кнопки подтверждения нет. Услуги не исключают друг друга — можно включить обе. Переключатели в модалке и виджеты на карточке товара — общее состояние: изменение в одном месте отражается в другом.
«Перейти в корзину» — залитая кнопка, закреплена внизу окна, не скроллится. Скроллится только контент выше футера.
ook-839-product-card-mobile-tobe.html — новый экран, у задачи нет as-is.
Внутренний журнал изменений по датам — не для дизайнера/аналитика, но полезен при дальнейших доработках. Актуальные требования — в соседнем документе «Требования к задаче».
Задача поставлена коротко: добавить на мобильной версии сайта модальное окно после добавления товара в корзину, сохранив главный CTA перехода в корзину и добавив туда оффер услуги, которую нужно реально «продать» — с преимуществами, а не сухим переключателем.
Прежде чем строить прототип, обнаружена и исправлена нестыковка данных, унаследованная из более ранних раундов OOK-836. Карточка товара (ook-836-product-card-tobe.html/-mobile-tobe.html) с самого начала показывает реальный товар Indesit ITS 5200 NG Темно-серый (сверено с живым сайтом ещё в рамках as-is), а корзина/чекаут под тем же id fridge — Haier BCF5261WRU по цене 96 999 ₽, унаследованный ещё из демо-данных OOK-696 и никогда не сверенный с карточкой товара. Пока привязка услуги к товару была решена на уровне абстрактной категории, это расхождение было незаметно; с появлением реальной привязки к конкретному товару (доработка 10 задачи OOK-836) оно стало бы видно сразу — а новое модальное окно OOK-839 сделало бы его видимым немедленно и наглядно (пользователь видит «Indesit» на кнопке «В корзину», а в корзине — «Haier»). Исправлено во всех местах: ook-836-cart-tobe.html/-mobile-tobe.html, ook-836-checkout-tobe.html/-mobile-tobe.html (ITEM_CATALOG), ook-836-service-card-tobe.html/-mobile-tobe.html (подпись привязки) — название, цена (41 579 ₽), бонус (+415) и строка рассрочки товара с id fridge приведены к тем же значениям, что уже на карточке товара; суммы корзины/чекаута пересчитаны.
Прототип ook-839-product-card-mobile-tobe.html — построен поверх карточки товара OOK-836, без изменений там, кроме одного: кнопка «В корзину» в блоке покупки (была декоративной) теперь открывает модальное окно. Окно состоит из: подтверждения добавления (миниатюра/название/цена), блока допродажи услуги (заголовок-оффер «Доверьте установку профессионалам», 3 преимущества с иконками, рейтинг 4.9 · 8 отзывов, цена, кнопка «Добавить» в один тап) или компактной отметки «Установка уже в корзине», если услуга уже добавлена, и снизу — всегда видимого главного CTA «Перейти в корзину →» и вторичного «Продолжить покупки».
Добавление услуги из окна реально работает, не имитация: переиспользован контракт localStorage['ook836ServiceState'], уже созданный в OOK-836 для тумблера на карточке товара — привязка к тому же товару (linkedItemId: 'fridge'), только со своим значением addedVia: 'modal' для различения источника добавления в аналитике. При добавлении из окна тумблер виджета на этой же странице сразу отражает новое состояние (общий источник истины), а при переходе в корзину услуга корректно показывается вложенной в карточку товара — та же логика каскадного отображения, что уже была построена для виджета.
Найден и исправлен реальный CSS-баг того же типа, что уже несколько раз фиксировался в проекте (класс с безусловным display: flex перебивает браузерное правило [hidden]{display:none}): блок «уже в корзине» был виден одновременно с блоком-оффером услуги, хотя JS корректно выставлял атрибут hidden — обнаружено визуально на скриншоте, не по логам (JS-проверка самого атрибута hidden ничего не показывала, т.к. атрибут действительно стоял верно — проблема была именно в CSS-специфичности, а не в логике). Исправлено добавлением явных [hidden]{display:none}-переопределений для обоих блоков.
Проверено через Playwright: клик «В корзину» → окно открывается с оффером услуги (услуги ещё нет) → клик «Добавить» → оффер сменяется отметкой «уже в корзине», тумблер виджета на странице обновляется синхронно → переход в корзину → услуга корректно показана вложенной в карточку Indesit ITS 5200 NG, суммы верны (44 091 ₽) — без ошибок в консоли.
Правки по прямому запросу: (1) добавить в окно обе услуги — установку и гарантию; (2) добавление услуги — радиобаттонами; (3) кнопка «Перейти в корзину» не должна скроллиться вместе с контентом допродажи.
Вторая услуга — «Гарантия Премиум, 3 года», 8 730 ₽ (цифра взята из уже существующего на этой же странице декоративного виджета гарантии — единственный реальный референс цены в прототипе). Новый демо-артикул ГАР-ПРЕМ-3Y, до этого гарантия нигде в прототипах не была настоящим добавляемым в корзину товаром (только невживлённый тумблер). Блок допродажи в окне переведён с одной кнопки «Добавить» на пару радиокарточек (заголовок, преимущества, рейтинг, цена у каждой) плюс общая кнопка «Добавить услугу», активная только когда выбран один из вариантов — выбор взаимоисключающий сознательно, а не только по форме радиобаттонов: общее состояние ook836ServiceState, унаследованное из OOK-836, хранит ровно одну активную услугу, поэтому реально одновременно добавить обе через это окно и так было бы нельзя — ограничение архитектуры, а не искусственное сужение UI. Задокументировано как открытый вопрос в требованиях.
Закреплённый CTA: базовый компонент .modal-box скроллит целиком, включая футер — переопределено для этого окна: сам бокс стал flex-колонкой с overflow:hidden, контент (подтверждение + блок допродажи) вынесен в отдельный скроллящийся .ook839-modal-scroll, а футер с CTA — невскроллящийся flex-элемент с верхней границей, всегда виден.
Правки в соседних файлах, без которых вторая услуга работала бы нечестно: вложенный блок услуги в корзине (ook-836-cart-mobile-tobe.html) раньше был статичной вёрсткой с захардкоженным текстом «Установка встроенного холодильника» и проверкой state.itemId === 'install-haier' — если бы через это окно добавили гарантию, блок остался бы скрыт (услуга «пропадала» бы из корзины) либо показывал неверный текст. Переписано на заполнение title/артикула/цены из самого state и проверку по факту наличия состояния, а не по конкретному id услуги; текст каскадного тоста при удалении товара также стал общим («{название услуги} для «{товар}» удалена вместе с товаром» вместо захардкоженного «Установка для…»). В чекауте (ook-836-checkout-mobile-tobe.html) добавлена вторая запись в ITEM_CATALOG для warranty-premium — без неё чекаут молча игнорировал бы эту позицию, не выдавая ошибки, но и не показывая её (тот же паттерн блока seller:'services', что и у установки, обязательная предоплата онлайн работает автоматически). Десктопные версии cart/checkout и отдельная карточка услуги не тронуты — вторая услуга добавляется только через это мобильное окно, десктоп и карточка услуги остаются только про установку, вне скоупа OOK-839.
Пять точечных правок по прямому запросу, все — в пределах одного файла ook-839-product-card-mobile-tobe.html: (1) кнопка «Перейти в корзину» перестала переходить в прототип OOK-836 — просто ничего не делает по клику; (2) выбор услуг переведён с радиобаттонов на тот же флажок/слайдер, что у виджета на карточке товара (переиспользованы классы .m-addon-widget-toggle/.knob — тот же компонент один в один, не копия); (3) флажки услуг сняты по умолчанию — и на виджете карточки товара, и в модалке; (4) кнопка «Добавить услугу» и отдельное состояние окна «услуга уже в корзине» убраны — включённый флажок и есть добавление, выключенный — удаление, без промежуточных состояний; (5) рейтинг и отзывы убраны у обеих карточек услуг в модалке — у этих услуг их пока нет.
Взаимоисключение услуг сохранено, но перенесено с уровня контрола (радио) на уровень логики (JS): общее состояние ook836ServiceState по-прежнему хранит только одну активную услугу (архитектура OOK-836, не пересматривалась в этом раунде) — при включении флажка одной услуги обработчик читает состояние заново и снимает флажок другой, если он был включён; визуально это два независимых переключателя, поведенчески — честное отражение того, что реально может лежать в общем слоте состояния. То же самое автоматически синхронизирует тумблер «Установка» на самой странице карточки товара в обе стороны.
Дефолт снят — убрано сидирование демо-состояния: функция seedServiceStateIfNeeded() (унаследованная из OOK-836, подсаживала «Установка уже в корзине» при первом визите) удалена из этого файла вместе с вызовом — при пустом хранилище оба флажка в модалке и тумблер виджета показывают выключенное состояние. Убрано только в этом файле; собственные файлы OOK-836 (карточка товара, корзина, чекаут, карточка услуги) не тронуты и сидирование там не убиралось — не входило в запрос этого раунда.
Проверено через Playwright: очистка хранилища → и виджет, и оба флажка в модалке выключены → включение «Установка» пишет состояние и сразу синхронизирует тумблер на странице → включение «Гарантия» автоматически гасит «Установка» в модалке и на странице, пишет новое состояние → выключение активного флажка полностью очищает состояние → клик «Перейти в корзину» не меняет location.href — без ошибок в консоли (кроме не относящегося к делу 404 на favicon.ico).
Две правки по прямому запросу: (1) услуги должны быть выбираемы одновременно, а не одна вместо другой; (2) виджеты «Установка»/«Гарантия» на карточке товара и переключатели в модалке — одни и те же услуги, с наследованием «выбранности» в обе стороны.
Второй пункт оказался предпосылкой первого: до этой доработки второй виджет на странице («Гарантия», .m-addon-widget с тумблером «72 часа…») был чисто декоративным — тумблер ничего не писал в состояние, только визуально переключался. Подключен к тому же общему состоянию, что и «Установка»: добавлен id="m-warranty-toggle" и обработчик change, полностью симметричный уже существующему у install-тумблера.
Формат общего состояния ook836ServiceState изменён с одного объекта на список объектов — раньше слот вмещал ровно одну услугу (архитектурное решение самой задачи OOK-836, до сих пор державшееся все предыдущие доработки), теперь это массив, чтение сделано обратно совместимым (старый формат, единственный объект, читается как список из одного элемента — на случай, если в хранилище останется что-то, записанное непереписанным файлом). Единая точка синхронизации applyState() на каждое изменение перечитывает список и обновляет разом оба виджета на странице и оба переключателя в модалке — поэтому включение в любом из четырёх мест мгновенно отражается во всех остальных.
Побочная регрессия, найденная и исправленная в процессе, а не запрошенная напрямую: у файла корзины (ook-836-cart-mobile-tobe.html) осталась собственная функция сидирования демо-состояния по умолчанию (не убиралась в доработке 3, т.к. правка тогда была скопирована только в файл карточки OOK-839). Сидирование гейтится флагом ook836ServiceStateInitialized, который раньше выставляла любая из нескольких страниц семейства OOK-836 — но с доработки 3 карточка товара OOK-839 этот флаг больше не выставляет. В результате при переходе из OOK-839 (где реальный выбор пользователя уже записан) в корзину — корзина видела «флаг не стоит» и молча перезаписывала настоящий выбор своим дефолтом на одну услугу, теряя второй. Обнаружено вручную при проверке через Playwright (реальный выбор из двух услуг на входе в корзину превращался в одну). Исправлено удалением сидирования из файла корзины — тот же принцип «дефолт — пусто», что уже применён к карточке товара в доработке 3.
Отображение в корзине переведено с одного вложенного слота на два фиксированных (data-nested-slot="0" и "1"), каждый заполняется из своего элемента списка; обёртка использует display:flex с gap, а не margin между элементами — hidden-слот не участвует в раскладке flex, поэтому лишнего отступа нет, если показана только одна из двух услуг. Кнопка «Удалить» у отдельной услуги теперь снимает конкретный id, а не весь слот; «Удалить» у товара каскадно убирает все привязанные к нему услуги разом, тост называет каждую («Установка… и Гарантия… удалены» с правильным окончанием глагола). Чекаут (ook-836-checkout-mobile-tobe.html) не потребовал изменений — он уже строит список позиций по чекбоксам корзины через общий ITEM_CATALOG, а не через ook836ServiceState напрямую.
Сознательно не тронуто (задокументировано как открытый вопрос): десктопная карточка товара, отдельная мобильная карточка товара самой задачи OOK-836, десктопные корзина/чекаут и карточка услуги по-прежнему ожидают старый формат состояния (один объект). Полный перенос списочной модели во все файлы OOK-836 — отдельная, более крупная доработка, не входила в скоуп этого раунда.
Проверено через Playwright: включение «Установка» на виджете → сразу отражается в модалке; включение «Гарантия» в модалке (при уже включённой «Установка») → обе остаются включены везде (2 виджета + 2 переключателя модалки); выключение одной услуги не трогает другую; переход в корзину показывает оба вложенных слота с верными названием/артикулом/ценой, сумма корректна (52 821 ₽ / +528); каскадное удаление товара называет обе услуги во множественном числе и полностью очищает состояние; удаление одной услуги через кнопку «Удалить» у слота оставляет вторую нетронутой; чекаут показывает оба чипа услуг, итог верен (56 711 ₽ = 41 731 товары + 12 690 услуги + 2 290 доставка) — без ошибок в консоли на всех трёх файлах.
OOK-836Сегодня услуги установки существуют только как допродажа, привязанная к конкретному товару: виджет на карточке техники и чип в корзине не добавляют настоящий товар в заказ, а создают лид (заявку) в стороннюю компанию. У услуги нет собственной карточки, артикула и цены как у отдельного товара — её нельзя найти в каталоге, нельзя купить без покупки техники у нас, и её продажи невозможно нормально учитывать отдельно от товарных.
Бизнес хочет превратить услуги установки в полноценные товары каталога: со своей карточкой, ценой и артикулом, продаваемые как вместе с техникой, так и самостоятельно — с чистой передачей оплаченного заказа внешнему подрядчику (MyTech), который физически оказывает услугу.
Каждая услуга установки — отдельный товар (артикул) со своей ценой. Услуг много (порядка двадцати, список будет пополняться), каждая привязана к определённой категории/типу техники — например, «Установка встроенного холодильника» относится ко всем товарам категории «Встроенные холодильники». У услуги — собственная карточка товара (как у обычной техники) и отдельная ветка каталога «Услуги», через которую услугу можно найти и купить независимо, без покупки техники у нас — в том числе для техники, купленной не у нас, и для товаров сторонних DBS-продавцов (сами DBS-продавцы услуги не оказывают).
На карточке товара сохраняется существующий блок допродажи услуги, но меняется его механика: раньше клик создавал лид в стороннюю компанию, теперь — добавляет в корзину конкретный артикул услуги, соответствующий категории этого товара (та же услуга, что доступна и через отдельную карточку, не дублирующаяся сущность). Гарантия — второй существующий тип допуслуги — в эту задачу не входит и остаётся в прежней схеме. В прототипе гарантия дополнительно показана по тому же паттерну, что и установка, — как демонстрация масштабируемости решения на втором примере; включение гарантии в скоуп задачи бизнесом не подтверждено, это решение уровня прототипа.
Услуги требуют обязательной онлайн-предоплаты (в отличие от товаров, где доступна в том числе оплата при получении) — бизнес-ограничение, продиктованное подрядчиком MyTech: он не должен получать заказ на услугу до её фактической оплаты. Из-за этого заказ, содержащий и товары, и услуги, технически расщепляется на независимые заказы по типу блока — по аналогии с уже существующим дроблением по продавцам в рамках DBS: услуги всегда формируют отдельный блок «Услуги» с обязательной онлайн-предоплатой, а товарные блоки сохраняют текущий выбор способа оплаты, включая оплату при получении.
Услуги должны допродаваться по всей воронке, включая страницу «Спасибо за заказ» (TYP) — но в этой итерации TYP не проектируется полноценно: сначала нужно увидеть текущую реализацию страницы на сайте и в приложении и доработать её, а не проектировать заново.
Нужна аналитика по продажам услуг отдельно от товаров: сколько услуг продано и через какой канал (виджет на карточке товара / переход из каталога или карточки услуги / самостоятельная покупка без товара), конверсия виджета, средний чек услуги, доля заказов, содержащих услугу. Отдельно, когда будет спроектирован TYP, — конверсия допродажи услуги на этом экране. Точный состав метрик — на усмотрение дата-аналитика.
Каждая услуга — самостоятельный товар со своей карточкой (аналогично карточке техники): название, описание, цена, добавление в корзину. Услуга закреплена за определённой категорией/типом техники и не зависит от конкретной модели — цена фиксированная, как у любого другого товара со своим артикулом. Услуг порядка двадцати, список будет пополняться — карточки должны заводиться как обычные товары каталога, стандартным процессом, без отдельного инструмента.
Одна и та же услуга, купленная через виджет на карточке товара и отдельно через свою карточку, — два независимых элемента заказа, а не одна переиспользуемая позиция.
Прототип собран — см. Макеты. У экрана нет as-is (на реальном сайте такой карточки сегодня нет), поэтому важна не только сама вёрстка, но и обоснование, какие блоки карточки товара для услуги не нужны, а какие нужно добавить (оплата только онлайн, что входит в услугу, как проходит визит мастера, FAQ) — подробно в комментариях к прототипу.
На карточке товара (техники) сохраняется существующий блок предложения услуги — это основная точка её продажи. Меняется механика: клик добавляет в корзину конкретный артикул услуги, соответствующий категории этого товара, вместо создания лида в стороннюю компанию. У товара не может быть больше одной релевантной услуги установки одновременно — виджет не предлагает выбор между несколькими вариантами.
То же добавление доступно и прямо из корзины, если товар там уже есть, а услуга к нему ещё не добавлена, — не только с карточки товара.
Услуги собраны в отдельной ветке каталога «Услуги», не растащены по категориям техники, — самостоятельная точка входа, позволяющая купить услугу без привязки к покупке техники у нас, в том числе для техники, купленной не у нас, и для товаров DBS-продавцов. С учётом количества услуг (порядка двадцати и растёт) ветке, вероятно, нужны подкатегории по типу техники (холодильники / стиральные машины / …) — финальную структуру предстоит уточнить с дизайнером/категорийным менеджером.
Услуги требуют обязательной онлайн-предоплаты — товары в том же заказе сохраняют любой доступный способ оплаты, включая оплату при получении. Если в заказе одновременно есть товары и услуги, заказ технически расщепляется на независимые заказы по типу блока, по аналогии с дроблением по продавцам в рамках DBS: услуги всегда формируют один общий блок «Услуги» (независимо от того, у какого продавца куплен связанный товар — услугу в любом случае оказывает подрядчик ХЛД), с обязательной онлайн-предоплатой только на эту часть.
Рассмотренные и отклонённые альтернативы: (а) отключать оплату при получении для всего заказа целиком при наличии услуги — плохой UX, наказывает не связанную с услугой часть покупки, вероятная потеря конверсии на товарах; (б) один заказ с частичной предоплатой (услуга оплачена, товар — по факту) — избыточно сложная модель статуса оплаты, для которой пришлось бы городить отдельную статус-машину вместо переиспользования существующей модели «заказ оплачен / не оплачен».
Оформление в этом случае создаёт несколько независимых заказов, а не один заказ с несколькими поставками.
MyTech — внешний подрядчик, оказывающий услуги установки. Жёсткое бизнес-ограничение: подрядчик не должен получать заказ на услугу до момента её фактической оплаты клиентом. Сама интеграция (передача данных клиента и состава заказа услуги в MyTech после оплаты) — вне UI-скоупа прототипа, фиксируется как зависимость бэкенда.
Блок «Услуги» в чекауте — самостоятельный блок на уровне блоков доставки, наравне с блоком ХЛД и блоками DBS-продавцов, не вложен ни в один из блоков продавца: услугу в любом случае оказывает MyTech, независимо от того, у кого куплен связанный товар.
По умолчанию — один общий адрес и один слот времени на весь блок услуг, как один визит мастера; при необходимости пользователь может развернуть блок и задать отдельный адрес/время для конкретной услуги. Если в заказе только услуги без единого товара — блока доставки товара нет вообще, есть только блок услуг со своим адресом. Время оказания услуги выбирается тем же виджетом слотов, что уже используется для выбора времени доставки товара.
Услуги, не требующие визита мастера (например, гарантия), в этот адресный блок не попадают — они добавляются в заказ отдельной строкой стоимости при оформлении, без своего адреса и времени.
Открытый вопрос — не решено, в какой момент пробивается чек по услуге. См. открытые вопросы.
Позиции по услугам показываются в чеке отдельным блоком «ОТДЕЛИМЫЕ УСЛУГИ», не смешиваясь с товарными позициями.
Услуги допродаются на странице «Спасибо за заказ» (TYP). Экран показывает одно из двух состояний. Если в заказе нет услуги — блок допродажи, предлагающий добавить установку/гарантию к уже купленному товару. Если услуга в заказе уже есть — вместо допродажи показан статус каждой купленной услуги (что произойдёт дальше — например, что мастер свяжется для согласования визита); повторно эта же услуга не предлагается.
Между чекаутом (адрес/дата/способ оплаты) и страницей «Спасибо за заказ» — два промежуточных шага. «Подтверждение заказа» — read-only сводка выбранного на предыдущем шаге, с той же группировкой на независимые блоки, что и чекаут (ХЛД / DBS-продавец / услуги, см. п.4 и п.6): каждый блок подтверждается отдельно, как отдельный будущий заказ. Дальше — переход на страницу оплаты; заказ к этому моменту уже создан в системе со статусом «не оплачен» — его можно найти и оплатить позже в личном кабинете, если оплата не была завершена сразу.
Поверх обычных to-be-экранов собран прямой демо-путь по всей воронке — для отправки ссылкой человеку, который проходит его сам, без комментариев автора. Старт — карточка услуги «Установка встроенного холодильника», услуга ещё не в корзине. Дальше — корзина → чекаут → подтверждение заказа → оплата (заглушка, см. п.10) → «Спасибо за заказ», с минимумом развилок (по сути одна: добавить услугу или пропустить). Клик/тап мимо кликабельных зон на секунду подсвечивает то, что реально продолжает сценарий на этом экране — подробности подхода в базе знаний, Правило 11.
Два готовых пресета стартовых данных, каждый гарантированно стартует без добавленных услуг: «Один товар» — только свой товар, без DBS (десктоп / моб.); «Товар + DBS» — тот же товар плюс DBS-товар, показывает дробление корзины на независимые блоки (десктоп / моб.).
https://drugtolik.ru/holodilnik/index.html?task=OOK-836
Прикрепить ссылку/задачу на макеты
OOK-836Внутренний журнал изменений по датам — не для дизайнера/аналитика, но полезен при дальнейших доработках. Актуальные требования — в соседнем документе «Требования к задаче».
Постановка задачи разобрана по пунктам, продакт-менеджеру заданы уточняющие вопросы по каждому из девяти пунктов постановки плюс несколько дополнительных (перенос даты/времени услуги, отказ/возврат, статусы, слоты, DBS-продавцы). По итогам обсуждения:
ook-836-typ.html), доработка — после того как будет показана текущая реализация страницы.Оставлены открытыми: момент выдачи чека по услуге, отказ/возврат, статусы услуги в заказе, финальная структура подкатегорий ветки «Услуги», возможность одного визита мастера на несколько адресов, точная механика TYP.
Пользователь прислал полные скриншоты карточки товара (десктоп и моб.) реального сайта — товар «Двухкамерный холодильник Indesit ITS 5200 NG Темно-серый». Собраны ook-836-product-card-asis.html и ook-836-product-card-mobile-asis.html: галерея, блок покупки (рейтинг, артикул, цена/скидка, бонусы, рассрочка, кнопки «В корзину»/«Купить в 1 клик», доставка/самовывоз, блок продавца), «Часто покупают вместе», табы «Характеристики/Отзывы/Сертификаты», двухколоночный блок «Описание» + таблица характеристик, и полный набор каруселей товаров вплоть до «Аксессуары для…» — по подписям разделов, читаемым на скриншотах. Шапка/хлебные крошки/подвал переиспользованы почти дословно из ook-834-landing-bonus.html/-mobile (тот же паттерн «rich-header», уже сверенный со скриншотами в задаче OOK-834), а не собраны заново с нуля.
Открытый момент, важный для дальнейшей работы: на присланных скриншотах (сильно сжаты по высоте из-за длины страницы) не удалось однозначно разглядеть блок допродажи услуги установки, который по базе знаний (раздел 13) должен где-то на карточке присутствовать. В этом as-is он не смоделирован — сознательно, а не по недосмотру (см. requirements-modal обоих файлов). Прежде чем проектировать to-be с доработанным виджетом (пункт 2 требований OOK-836), нужен более чёткий/крупный скриншот именно блока покупки, либо явное подтверждение, где на карточке этот блок сейчас расположен.
Сознательные упрощения (обычная практика для as-is по скриншотам, см. пример OOK-834): значения таблицы характеристик — правдоподобные, но не сверенные посимвольно с реальным листингом (разрешение скриншота не позволило прочитать таблицу точно); товарные карточки во всех каруселях — переиспользуемый демо-набор в 8–10 товаров, не уникальный набор на каждую секцию; фото товара — заглушка-иконка вместо реальной фотографии; поиск, фильтры и табы — декоративны.
Пользователь честно указал, что доработка 2 «вообще не похожа на реальную карточку» — по существу верно: скриншоты были полными страницами очень большой высоты, сжатыми при отображении до ~2000px, и на таком масштабе текст/цвета/расположение блоков были не читаемы, а не просто «немного неточны». Прототип из доработки 2 был по факту не as-is, а обобщённая карточка товара «вообще», собранная по типовым паттернам e-commerce, а не по факту со скриншота — это было прямо признано пользователю.
После восстановления подключения Playwright MCP пользователь дал прямую ссылку на реальный товар — holodilnik.ru/refrigerator/two_chambered_refrigerators/beko/b1rcsk272w/ (Beko B1RCSK272W, не Indesit ITS 5200 NG из скриншотов — сознательная замена на полностью проверяемый источник). Both файла (ook-836-product-card-asis.html/-mobile-asis.html) пересобраны с нуля: accessibility-снимок DOM дал точный текст (заголовок, хлебные крошки, описание, полную таблицу характеристик, реальные позиции блока «Аксессуары для…»), getComputedStyle дал точные цвета (шапка/кнопка #00aaff/#079ff9, жёлтый бейдж скидки #ffea31, мятно-зелёные карточки услуг #b5f7e6/#09e5ac), прицельные скриншоты (не полностраничные) подтвердили вёрстку.
Главная находка — реальный виджет допродажи услуг (пункт 2 требований OOK-836) найден и воспроизведён 1:1, включая точную разметку: id="addon_installment_mytech_1" в атрибутах подтверждает, что MyTech уже сегодня технически зашит как провайдер услуги установки. Подробности — в базе знаний, раздел 17 «Отделимые услуги и MyTech». Это отменяет открытый вопрос из доработки 2 («не удалось разглядеть блок услуги») — блок найден, точная разметка задокументирована, и это прямая опора для будущего проектирования to-be.
Существенная правка состава страницы: каруселей «Рекомендуем также» / «Выбор клиентов» / «Часто покупают вместе» / «Вы недавно смотрели», придуманных в доработке 2 по аналогии с другой страницей сайта (категорийный листинг OOK-834), на реальной карточке товара нет. В этой же доработке 3 реально найдены и добавлены только 2 из 9 существующих каруселей («Покупают со скидкой до 15% бонусами», «В корзинах наших покупателей») — остальные 7 (класс .carousel-catalog-products) на момент доработки 3 ошибочно списаны на блокировку Mindbox-доменов в этой сети. Это исправлено в доработке 4 ниже — на самом деле дело было в ленивой подгрузке, не в блокировке.
Дополнительная реальная находка на мобильной версии: «Характеристики»/«Отзывы»/«Сертификаты» на мобильном — не горизонтальные табы (как на десктопе), а вертикальный аккордеон, свёрнутый по умолчанию; при этом виджеты услуг остаются компактными бок о бок, не раскладываются в стек. Это нельзя было бы узнать без прямого доступа к браузеру — на скриншоте эта деталь не была видна и не была бы угадана правильно.
Урок на будущее, зафиксирован явно пользователю и в этой записи: для as-is по реальному сайту скриншот полной страницы — плохой источник, если страница длинная; прямой доступ к браузеру (Playwright: DOM для текста, computed styles для цветов, точечные скриншоты для вёрстки) — кратно надёжнее и должен быть основным способом впредь, скриншоты — только как запасной вариант или для сверки конкретных небольших блоков.
Пользователь указал на два конкретных повода недовольства результатом доработки 3: (1) пропущено много блоков и (2) для страниц за авторизацией (например, личный кабинет) прямой доступ через Playwright вообще не сработает. По второму пункту обсуждён и зафиксирован отдельный подход (не в этой доработке — когда реально понадобится): тестовый/демо-аккаунт компании, если есть, либо пользователь сам копирует outerHTML из DevTools своего авторизованного сеанса — вводить реальный пароль в Playwright для этого не стоит, это чужие персональные данные (заказы, адреса, телефон).
По первому пункту — найдена и исправлена настоящая причина. В доработке 3 запрос к DOM (через textContent.includes() и точечные querySelector) выполнялся без предварительной полной прокрутки страницы — 7 из 9 карусельных блоков товаров подгружаются лениво по мере прокрутки и на момент запроса были пустыми контейнерами без заголовка. Это было ошибочно интерпретировано как блокировку Mindbox-доменов (реальная и отдельная проблема этой сети, но не имеющая отношения к этому случаю) — типичная ошибка «не нашёл → решил, что заблокировано», а не «не нашёл → проверил другую причину».
Правильная дисциплина, применённая в этой доработке: перед любым чтением DOM — механическая прокрутка всей страницы шагами по 800px с паузой между шагами до конца document.body.scrollHeight, чтобы гарантированно вызвать всю ленивую подгрузку; только после этого — инвентаризация блоков по классам (например, все элементы .carousel-catalog-products с их заголовками и позициями), а не точечные проверки по гипотезам вида «есть ли текст X». Это дало все 9 реальных каруселей с реальными товарами и ценами (были известны 2, добавлены ещё 7: «Новинки», «Лучшее по отзывам», «Ищут чаще всего», «Лучшее из Liebherr», «Любимое у покупателей», «Скидка -20% на три товара любых брендов», «Максимальные скидки») — добавлены в оба файла (ook-836-product-card-asis.html/-mobile-asis.html), заодно повторно подтверждено (после полной прокрутки, не до неё), что блока «Часто покупают вместе» на реальной странице по-прежнему нет — это не то же самое, что «не подгрузилось».
Общее правило на будущее, зафиксировано в памяти проекта: полная механическая прокрутка страницы до конца — обязательный первый шаг перед чтением DOM любой длинной страницы через Playwright, а не опциональная предосторожность.
Пользователь остался не удовлетворён и доработкой 4 — не разово по одной жалобе, а с конкретным конструктивным предложением: написать локальный инструмент, который режет длинный full-page скриншот на части фиксированной высоты (по умолчанию 1500px), чтобы каждая часть оставалась читаемой при просмотре, а не сжималась целиком. Создан tools/slice_screenshot.py (Python + Pillow, без внешних зависимостей кроме уже установленного Pillow) — принимает путь к файлу, режет на части с постфиксами _1, _2 и т.д., поддерживает свою высоту среза (--height) и папку назначения (--outdir). Проверен на синтетических изображениях перед использованием.
Инструмент подтвердил свою пользу сразу же. Пользователь дал два оригинальных full-page скриншота с рабочего стола (2880×26387 и 800×19941 — те самые, с которых начиналась работа над as-is в этой задаче) — тот же самый файл, что был нечитаем в доработке 2, после нарезки на 18 (десктоп) и 14 (моб.) частей оказался полностью читаем один в один.
Прочитаны все 18 десктопных частей — и это выявило то, чего не поймать было ни скриншотом целиком, ни точечными DOM-запросами доработки 3–4: на реальной карточке товара есть ещё 3 карусели, идущие ДО табов, сразу после виджетов услуг — «Рекомендуем также», «Выбор клиентов» и «Часто покупают вместе» — плюс «Вы недавно смотрели» после блока характеристик. Итого 13 реальных каруселей, не 9. Доработка 4 не нашла эти четыре, потому что искала по одному конкретному CSS-классу (.carousel-catalog-products) — эти четыре, судя по всему, используют другую разметку, то есть даже «правильная» дисциплина (сначала прокрутка, потом инвентаризация) может быть неполной, если инвентаризация ищет по одному заранее известному признаку, а не читает страницу целиком.
Ещё одна находка — «Часто покупают вместе» оказалось совсем не тем, чем его придумали в самой первой версии (доработка 1/2). Это обычная карусель товаров (стиральные и посудомоечные машины — сопутствующая техника), с той же структурой карточек, что у остальных каруселей — а не виджет с чекбоксами, миниатюрами и итоговой суммой, который был построен по одной лишь надписи на нечитаемом скриншоте. Фиктивный bundle-виджет из десктопной версии полностью убран.
Заодно выяснилась и причина путаницы: скриншоты в доработках 1–2 были сделаны для другого товара (Indesit ITS 5200 NG), а доработки 3–4 намеренно работали с Beko B1RCSK272W (выбранным как «полностью проверяемый источник» до появления инструмента нарезки). Теперь, когда скриншоты снова читаемы, вернулись к оригинальному товару пользователя — Indesit ITS 5200 NG Темно-серый — и картинки, и карточка снова говорят об одном и том же товаре. Оба файла (ook-836-product-card-asis.html/-mobile-asis.html) пересобраны: цена/скидка/бонусы/рассрочка/цены виджетов услуг (у гарантии цена зависит от цены товара — 8 730 ₽/243 ₽ в месяц против 6 610 ₽/184 ₽ у более дешёвого Beko), полное описание и таблица характеристик — всё по данным из нарезанных скриншотов, все 13 каруселей — с реальными товарами/ценами (кросс-сверено: 9 «поздних» каруселей совпадают между Beko и Indesit почти дословно — похоже, это общие/не персонализированные под конкретный товар блоки, а 4 «ранних» — товар-специфичны).
Итоговый урок, отличается от вывода доработки 4: дисциплина «сначала прокрутка, потом инвентаризация по known-классам» полезна, но недостаточна сама по себе — она может пропустить контент, использующий не тот класс, который вы искали. Нарезанные на читаемые части скриншоты — не запасной вариант «на крайний случай», а полноценный, взаимодополняющий метод: DOM/computed styles дают точный текст и цвета, но требуют знать, что искать; скриншот показывает всё, что физически есть на странице, независимо от разметки — вместе они кроют слепые зоны друг друга. Оба метода стоит использовать вместе для крупных as-is, не выбирать один вместо другого. Этот урок вынесен в базу знаний как «Правило 6» раздела «Подход к созданию прототипов» — не только частный вывод для этой задачи.
Две точечные правки по итогам просмотра пятой версии. Ни одна услуга не выбрана по умолчанию — раньше тумблер «72 часа на ремонт…» (гарантия) был включён по умолчанию (так было на реальном сайте на момент съёмки скриншота), но для прототипа это осознанно неверный дефолт: оба тумблера в обоих файлах (десктоп и моб.) теперь выключены изначально.
Все 14 каруселей (13 товарных + аксессуары) сделаны явно листаемыми — карточки продублированы (где нужно — с повторами, специально ради демонстрации самого факта прокрутки, а не уникальности содержимого) до 8 штук на десктопных каруселях и 7 на мобильных, так чтобы ряд карточек гарантированно не помещался в видимую область ни на десктопе, ни тем более на мобильном (там раньше было всего по 2 карточки — прокручивать было нечего). Заодно найден и исправлен баг: карусель «Аксессуары» использует свой класс .accessory-card/.m-accessory-card, а не общий .product-card — у него не было фиксированной ширины (flex: 0 0 …px), из-за чего даже 8 карточек просто сжимались, чтобы поместиться, вместо того чтобы вызвать прокрутку. Добавлена фиксированная ширина, проверено через scrollWidth > clientWidth на всех 14 каруселях в обоих файлах — все листаемые.
Собран базовый набор целевых (to-be) прототипов для всех трёх экранов задачи: ook-836-product-card-tobe.html/-mobile-tobe.html, ook-836-cart-tobe.html/-mobile-tobe.html, ook-836-checkout-tobe.html/-mobile-tobe.html. Карточка товара построена на структуре as-is (доработка 5–6); корзина и чекаут — не с нуля, а поверх существующего to-be OOK-696 (ook-696-cart-tobe.html/ook-696-checkout-tobe.html), поскольку у OOK-836 нет своего as-is этих двух экранов и оба напрямую наследуют DBS-механику дробления корзины/чекаута, разработанную в OOK-696.
Карточка товара: визуальных изменений почти нет (см. базу знаний, раздел 17 — реальный виджет уже выглядит как «добавить в корзину», разница только в данных). Включение тумблера «Профессиональная установка техники» теперь реально добавляет артикул услуги в корзину (счётчик в шапке растёт, под тумблером появляется зелёная отметка «Добавлено в корзину» вместо подписи про гарантию на работу, показан артикул). Виджет «Гарантия Премиум» не тронут — вне скоупа задачи.
Корзина: чип «Установка», ранее вложенный в карточку товара (.services-row внутри .cart-item-body, паттерн OOK-696), убран у товаров, где он был (Haier, Новатек-Электро) — установка теперь отдельная строка в новой группе «Услуги» под основным списком, оформленная как обычный товар (миниатюра/название/артикул/цена/«Удалить»), без степпера количества. Группа помечена бейджем «Оплата онлайн заранее» (мятный цвет, тот же, что у виджета на карточке). Чип «Гарантия «72 часа»» — без изменений, вне скоупа.
Чекаут: добавлен независимый блок «Установка техники» — не вложен ни в один блок продавца (ХЛД/DBS), появляется только если в заказе есть хотя бы одна услуга, содержит только адрес и время (без «Курьером/Самовывоз», без своей стоимости доставки — цена уже в самой услуге), с постоянно видимой мятной плашкой про обязательную предоплату онлайн (ограничение MyTech). Переиспользован существующий механизм блокировки товаров по способу оплаты (изначально сделанный в OOK-696 для «Яндекс Сплит»): при выборе оплаты «При получении»/«По счету» позиции блока «Установка техники» так же деактивируются (приглушение + красный значок с тултипом), исключаются из «Итого», появляется отдельное предупреждение — второй такой же компонент рядом с исходным алертом Яндекс-Сплит, не смешан с ним. Строка «Услуги» в сводке (существовала и раньше, для гарантии из чипов корзины, была скрыта по умолчанию) теперь суммирует ещё и артикулы установки — общая сумма «доплат за услуги», при этом «В корзине N товаров» и сумма товаров больше их не включают.
Сознательное упрощение, явно не реализованное: требования (п.6) допускают «развернуть» блок услуг и задать отдельный адрес/время для конкретной услуги, если их в заказе несколько с разными адресами, — в прототипе это не смоделировано, всегда один общий адрес/время на все услуги сразу. Причина — открытый вопрос «может ли один визит мастера покрыть услуги на товары из разных блоков доставки» всё равно не решён с MyTech, так что разворачивание пока негде было бы содержательно применить.
Проверено через Playwright: полный путь карточка → добавление услуги → корзина → чекаут → выбор способа оплаты «При получении» → корректное исключение услуг из «Итого» — без ошибок в консоли на всех шести файлах, суммы сходятся (товары/услуги/бонусы/итого пересчитываются верно в обоих направлениях — при исключении и при возврате). Карточка OOK-836 на index.html перестроена в .proto-versions (as is/to be колонки), по образцу карточки OOK-696.
ook-836-service-card-tobe.html/-mobile-tobe.html) — новый экран, п.1 требованийСобрана карточка отдельной услуги «Установка встроенного холодильника» (тот же артикул УСТ-247-ВСТР и цена 2 360 ₽, что уже фигурируют в виджете карточки товара, корзине и чекауте — единая демо-услуга через всю цепочку прототипов OOK-836). У экрана нет as-is: на реальном сайте отдельной карточки товара-услуги не существует, поэтому анализ строился не на сравнении со скриншотом, а на разборе карточки товара (ook-836-product-card-tobe.html) блок за блоком — что переносится, что убирается, что нужно добавить — с точки зрения пользователя, который решает, покупать ли услугу.
Убрано у карточки товара как не имеющее смысла для услуги: 360°-галерея с ракурсами (заменена на один статичный иллюстративный блок), рассрочка/бейдж Яндекс Сплит (прямо противоречит бизнес-правилу обязательной 100% предоплаты услуг), «Самовывоз из магазина»/«Доставка» (услугу не забирают и не привозят — её оказывает мастер по адресу заказа), виджет допродажи услуг (нельзя купить услугу к услуге), таблица физических характеристик (высота/цвет/энергокласс и т.п. неприменимы), строка бренда/скидка на товар.
Добавлено, обоснование — что важно человеку, который решает купить услугу: «Что входит в услугу» (чек-лист сразу у блока покупки — первый вопрос «а что конкретно сделает мастер»), «Как это работает» (4 шага — покупка услуги растянута во времени до визита мастера, в отличие от разовой покупки товара, шаги снимают тревожность), явная мятная плашка «Оплата онлайн заранее» прямо в блоке покупки (честно показано до клика «Добавить в корзину», а не сюрпризом на чекауте), FAQ (нужно ли быть дома, можно ли перенести время, что покрывает гарантия на работу — доверие к разовой услуге от постороннего человека дома ниже, чем к обычной покупке), отзывы (сохранены — качество работы мастера пользователь не может оценить заранее по фото), «Другие услуги» вместо каруселей случайных товаров (осмысленный кросс-селл только внутри самой категории «Услуги»), «Подходит для: Встроенные холодильники» — явный ответ на вопрос «а точно ли эта услуга мне нужна».
Одна из четырёх FAQ-карточек («Что если мастер не сможет начать работу?») намеренно оставлена как открытый вопрос с видимой красной пометкой прямо на странице — честного ответа для него пока нет; ответ про перенос даты/времени, наоборот, написан консистентно с уже зафиксированным фактом задачи (переносится напрямую с мастером/поддержкой, не через сайт).
Ссылка «Подробнее ›» у виджета «Профессиональная установка техники» на карточке товара (десктоп и моб.) обновлена — раньше вела в никуда (#), теперь ведёт на эту карточку услуги, замыкая цепочку карточка товара → карточка услуги → корзина → чекаут.
Попутно найден и исправлен реальный CSS-баг (тот же паттерн, что уже фиксировался в проекте: класс с безусловным display: flex перебивает браузерное правило [hidden]{display:none} по специфичности) — бейдж счётчика корзины в шапке (.hru-icon-badge) был виден сразу при загрузке страницы, хотя должен быть скрыт до первого добавления в корзину. Баг воспроизвёлся в обоих файлах, использующих этот класс, — ook-836-product-card-tobe.html и новой ook-836-service-card-tobe.html; исправлено добавлением явного .hru-icon-badge[hidden]{display:none} в оба. Проверено через Playwright (getComputedStyle до и после клика).
Открытые вопросы: содержание чек-листа/шагов/FAQ — правдоподобный, но придуманный для прототипа контент, реальный текст нужно согласовать с MyTech; страница-листинг ветки каталога «Услуги» (п.3 требований) не смоделирована — это только карточка одной услуги, ссылки на категорию и карусель «Другие услуги» ведут в #; возможность скидки/промо на услугу не проработана; кнопка «Добавить в корзину» на этой карточке — отдельная демо-реализация (свой счётчик), не связана через localStorage с остальными прототипами OOK-836.
По просьбе пользователя — три связанных правки, две механические (упрощение) и одна архитектурная (пересмотр способа привязки услуги к товару).
1. Упрощение демо-данных корзины и чекаута. Убран блок «Товары не в наличии» из корзины (2 позиции). Набор товаров сокращён до минимально необходимого для демонстрации механики: 1 товар «Холодильник.Ру» (Haier BCF5261WRU), 1 DBS-товар (болт КМ-Профиль), 1 услуга (Установка встроенного холодильника) — вместо прежних 4 товаров/2 DBS-продавцов/2 услуг. Titanium Masters, Новатек-Электро и вторая услуга убраны из ook-836-cart-tobe.html/-mobile-tobe.html и ook-836-checkout-tobe.html/-mobile-tobe.html (блок «Новатек-Электро» удалён из чекаута целиком, не просто скрыт). Вся убранная функциональность (несколько DBS-продавцов одновременно, блок недоступных товаров) по-прежнему полностью описана в базовом to-be OOK-696 — упрощение касается только демо-данных задачи OOK-836, не логики OOK-696. Попутно найден и исправлен реальный баг: после удаления блока «Новатек-Электро» строка сводки «Доставка: Новатек-Электро» осталась бы в DOM без обработчика видимости (JS больше не перебирает ключ novatek) и была бы видна вечно — убрана вместе с блоком.
2. Разобран вопрос: приводит ли добавление услуги через тумблер на карточке товара и через отдельную карточку услуги (ook-836-service-card-tobe.html) к одному и тому же результату в корзине/чекауте? До этой правки — нет: корзина писала под названием услуги «для Haier BCF5261WRU» (конкретный товар), при этом по требованиям (п.1) услуга привязана к категории техники, а не к модели, — то есть корзина утверждала связь, которой в модели данных не существует. При добавлении через отдельную карточку услуги эта информация в принципе недоступна (там нет контекста, из какой карточки товара пришёл пользователь), значит два способа добавления физически не могли бы давать одинаковый результат, пока в корзине жила строка про конкретную модель.
Решение: подпись артикула везде (виджет на карточке товара, корзина, чип на чекауте) переведена на уровень категории — «для категории «Встроенные холодильники»» вместо «для Haier BCF5261WRU». Теперь оба способа добавления услуги производят идентичный результат, потому что оба честно оперируют одним и тем же уровнем детализации, который реально есть в данных. Заодно исправлена реальная рассинхронизация цены: в корзине/чекауте артикул УСТ-247-ВСТР стоил 3 520 ₽, а на карточке товара и карточке услуги — 2 360 ₽; унифицировано до 2 360 ₽ везде.
3. Тумблер виджета установки на карточке товара заменён кнопкой «Добавить в корзину». Отдельно разобран вопрос: что делать с тем, что тумблер сбрасывается в выключенное положение при обновлении страницы карточки товара, даже если услуга уже лежит в корзине с прошлого раза (визуально врёт о состоянии)? Два варианта: (а) научить тумблер при загрузке проверять содержимое корзины и сразу показываться включённым, если услуга там уже есть; (б) убрать тумблер вообще. Выбран (б): тумблер как элемент управления семантически означает «локальное состояние здесь и сейчас» (как переключатель настройки), а не «положить товар в корзину навсегда» — это два разных действия, случайно упакованных в один визуальный компонент. Кнопка «Добавить в корзину → Перейти в корзину →» (один клик — необратимое действие, как у обычного товара) честнее отражает, что на самом деле происходит, и делает интерфейс идентичным кнопке на карточке услуги — теперь оба входа в добавление услуги выглядят и ведут себя одинаково. Виджет «Гарантия Премиум» не тронут — сохраняет свой тумблер, вне скоупа задачи.
Явно не решено этой заменой (зафиксировано как открытый вопрос в модалках обеих карточек товара): кнопка по-прежнему не проверяет at load, есть ли услуга уже в корзине — при обновлении страницы всегда возвращается в состояние «Добавить в корзину». Вариант (а) выше остаётся нерешённым вопросом для реальной реализации, не для этого прототипа — у статичных HTML-файлов нет общего состояния корзины, которое можно было бы проверить.
Проверено через Playwright: полный путь карточка → добавление услуги (кнопка меняется, счётчик растёт) → переход в корзину → корзина (2 товара + 1 услуга, суммы 99 511 ₽/+992 бонуса) → чекаут (блок Новатек-Электро отсутствует в DOM, суммы 103 401 ₽) → «При получении» (услуга корректно исключается из «Итого», сумма 101 041 ₽) — без ошибок в консоли на всех изменённых файлах (десктоп + моб.).
Пользователь прямо указал на цену решения доработки 9 (категорийная привязка + кнопка вместо тумблера): теряется возможность видеть услугу рядом с её товаром в корзине, а «одинаковый результат для двух путей добавления» на деле означало «тумблер тоже забывает, к какому товару он относится» — то есть решалась не та проблема. Задача — изучить мировую практику и предложить модель без костылей (обработки «а что если товар удалили» и т.п.), но с сохранением UX-пользы (услуга видна рядом с товаром) и высокой конверсией.
Разобрана практика Amazon (планы защиты Asurion), Best Buy (Geek Squad), IKEA (сборка мебели), Lowe's/Home Depot (установка техники), Apple (AppleCare+). Общий паттерн у всех: услуга при добавлении «в довесок» к товару получает реальную ссылку на конкретную строку заказа (не абстрактную категорию), показывается вложенной/сгруппированной с этим товаром, и удаление товара каскадно удаляет услугу (без блокирующего подтверждения — просто тихо + короткий тост). Apple отдельно показывает решение для случая «без товара» (услуга покупается позже, для уже купленного устройства) — не выдумывает мягкую привязку, а требует явную идентификацию (серийный номер); никто не размывает привязку до уровня категории.
Итоговая модель: общее состояние localStorage['ook836ServiceState'] (контракт: {itemId, linkedItemId, addedVia}), которое читают и пишут карточка товара, карточка услуги и корзина. linkedItemId — id товара в заказе, к которому привязана услуга, или null. addedVia — 'widget' (тумблер на карточке товара, который точно знает текущий товар) или 'catalog' (отдельная карточка услуги, у которой контекста товара нет вообще).
ook836ServiceState), а не сбрасывается. Включение/выключение реально добавляет/убирает услугу из корзины с привязкой к этому товару.Затронуты все шесть файлов задачи (карточка товара, карточка услуги, корзина — десктоп и моб.). Чекаут не менялся — он как читал выбор через ook696CartSelection/ITEM_CATALOG, так и продолжает, механизм сбора данных в корзине остался прежним (просто источник строки услуги в DOM теперь динамический, а не статичный).
Проверено через Playwright: тумблер на карточке товара честно отражает состояние при каждой загрузке в обе стороны (включил на карточке → виден вложенным в корзине; удалил в корзине → тумблер выключен при следующем визите на карточку); путь через карточку услуги добавляет без привязки, показывается отдельной группой; каскадное удаление корректно убирает только реально привязанную услугу и не трогает непривязанную; чекаут считает суммы верно после обоих путей добавления — без ошибок в консоли на всех шести файлах.
Пользователь пришёл к целевому виду всей задачи и попросил проверить и переделать все прототипы по пяти пунктам сразу: (1) нужны и виджет в карточке, и карточка отдельной услуги; (2) виджет нужен и в корзине; (3) в корзине услуга отображается двумя способами (вложенная/отдельная) — по способу добавления; (4) в корзине установка и гарантия должны выглядеть одинаково в виджете; (5) на чекауте каждая услуга — отдельный товар, в миничеке — отдельные строки «Установка»/«Гарантия»; отдельно — карточка услуги не должна радикально отличаться от карточки товара, «дорогие» решения (новая сетка) не нужны, «дешёвые» (убрать карусели) — да. Затронуты все восемь файлов задачи (карточка товара, карточка услуги, корзина, чекаут — десктоп и моб.).
Формат общего состояния ook836ServiceState перенесён на список услуг во всех файлах (было — только в мобильной корзине и мобильной карточке товара OOK-839, десктоп и остальные файлы OOK-836 ещё жили на старом формате «одна услуга»). Установка и гарантия теперь равноправные, не взаимоисключающие услуги — тот же контракт, что уже был обкатан в задаче OOK-839.
Легаси-чип «Гарантия «72 часа»» (унаследован из OOK-696, вне скоупа) убран только у Indesit ITS 5200 NG — заменён на настоящую «Гарантия Премиум» как отдельную услугу; у КМ-Профиль [болт] чип остался без изменений, эта задача его не касается. Держать на одном товаре одновременно два по-разному устроенных и по-разному оценённых «гарантия»-предложения было бы противоречиво.
Новый виджет добавления услуги прямо из корзины — если у товара нет одной или обеих услуг, вместо неё показывается предложение добавить (тот же мятный виджет с флажком-переключателем, что и на карточке товара), без перехода на другую страницу. Установка и гарантия используют один и тот же компонент .cart-addon-widget — визуально идентичны, как и просили.
Карточка услуги пересобрана с нуля. Прежняя версия (доработка 8) была отдельным дизайном — чек-лист «Что входит», 4-шаговый процесс, FAQ, отдельная секция отзывов. Новая версия — копия реальной карточки товара с минимальными отличиями: убраны карусели рекомендаций (единственное, что реально стоило убрать — не имеет смысла для услуги, дёшево), рассрочка/Сплит (противоречит правилу обязательной предоплаты), 360°-галерея (нечего фотографировать под разными ракурсами) и самовывоз/доставка (заменены на «дата и время визита» в том же визуальном слоте). Всё остальное — та же вёрстка, тот же грид, что у товара. Один файл на платформу обслуживает обе услуги через параметр ?service=install-haier / ?service=warranty-premium — «Подробнее ›» на обоих виджетах карточки товара ссылается на нужный вариант.
Чекаут: добавлена запись warranty-premium в десктопный ITEM_CATALOG (мобильный уже имел её после OOK-839). Комбинированная строка «Услуги» в миничеке разделена на три: новые «Установка» и «Гарантия» (по одной на каждую отдельную услугу-каталожную позицию, скрыты, если услуги нет в заказе) плюс оставшаяся строка легаси-чипов, переименованная в «Услуги (гарантия «72 часа»)», чтобы не путать с новой «Гарантия». Суммы не задваиваются — старая строка теперь считает только легаси-чипы.
Проверено через Playwright на обеих платформах: оба тумблера на карточке товара пишут в общий список; карточка услуги с параметром ?service= корректно показывает нужный вариант и состояние «в корзине»; виджет добавления в корзине показывает только недостающие услуги и пропадает, когда добавлены обе; оба вложенных слота отображаются идентично; легаси-чип виден только у болта; чекаут показывает три раздельные строки с верными суммами (установка 2 360 ₽, гарантия 8 730 ₽, легаси-чип 1 600 ₽), итог верен (56 711 ₽) — без ошибок в консоли на всех восьми файлах.
Пользователь посмотрел результат доработки выше и указал на 6 конкретных проблем. Разбор и правка каждой — ниже, в порядке пунктов из постановки.
1–4 (корзина) имели один и тот же корень: параллельное существование двух разных визуальных компонентов для «услуги ещё нет» (большой мятный .cart-addon-widget) и «услуга уже добавлена» (компактная .cart-item.is-nested) — само наличие двух состояний создавало и лишнюю визуальную тяжесть виджета, и почву для расхождения вида между блоками. Решение — не точечный фикс, а объединение: теперь под каждым товаром всегда показываются готовые компактные строки с флажком на каждую доступную услугу; флажок и есть факт присутствия услуги в корзине (включён = услуга в заказе и привязана к этому товару; выключение — полное удаление, не просто сокрытие). Тот же компонент, что раньше был только «уже добавлено», используется всегда — второй, более тяжёлый вариант вида убран полностью. Это заодно и есть ответ на п.4 («Гарантия» в блоке DBS должна выглядеть как в первом блоке) — раз компонент теперь один на все товары и обе услуги, расхождения по конструкции больше нет, различается только состав доступных услуг (у болта — только гарантия, у холодильника — установка и гарантия), не разметка.
Ради этого легаси-чип «Гарантия «72 часа»» (доработка 6, был сознательно оставлен только у болта) в этой правке всё-таки убран и там — держать одну и ту же гарантию в двух структурно разных представлениях на разных товарах стало прямо противоречить требованию «должно быть идентично». У болта теперь та же строка-с-флажком, тот же артикул warranty-premium, что и у холодильника.
Модель состояния обобщена с ключа «услуга» на составной ключ «услуга + к какому товару привязана». До этой правки setServiceActive()/удаление по факту дедуплицировали список только по itemId — это было незаметно, пока одна и та же услуга не могла одновременно относиться к двум разным товарам. Теперь, когда и холодильник, и болт предлагают «Гарантия Премиум», это стало реальной ситуацией: гарантия для холодильника и гарантия для болта — два независимых элемента заказа с одинаковым itemId, но разным linkedItemId. Все операции (проверка «активна ли», добавление, удаление) переведены на пару (itemId, linkedItemId) — исправлено в корзине (десктоп и моб.) и, отдельно, в карточке товара (десктоп и моб.), где та же дедупликация по одному itemId была бы тем же скрытым багом: включение гарантии на карточке холодильника стёрло бы гарантию, ранее привязанную к болту. Подтверждено через Playwright: гарантия к двум разным товарам одновременно — два отдельных элемента в состоянии, сумма считается верно (61 551 ₽ в тестовом сценарии), переключение одной не трогает другую.
2–3 (шильдик рассрочки «съезжает» к услуге; цена установки «похожа на холодильник») оказались одним и тем же CSS-багом, не двумя разными. .cart-item-side в общем компоненте задаёт justify-content: space-between, а .cart-item не переопределяет align-items (по умолчанию stretch) — пока строка была короткой, это было незаметно; как только строка товара выросла из-за вложенных строк услуг под ней, .cart-item-side растягивался на всю высоту и «раскидывал» своё содержимое (иконки/цена/шильдик рассрочки) по высоте — шильдик рассрочки холодильника оказывался визуально рядом с последней строкой услуги, а не с ценой холодильника. Прямая Playwright-проверка подтвердила: цена установки в DOM и так была верной (2 360 ₽) всё это время — «41 тысяча» была не багом расчёта, а зрительной иллюзией из-за смещённого шильдика. Исправлено одной строкой (.cart-item-side { justify-content: flex-start }) в десктопной корзине; в мобильной такая же строка уже была добавлена раньше.
На мобильной корзине при переходе на всегда-видимые строки услуг обнаружился отдельный, ранее скрытый баг вёрстки на узком экране (390px) — не то, о чём просил пользователь, но напрямую мешавшее выполнить п.1 («аккуратные строки»): у товара с длинным шильдиком рассрочки (холодильник) горизонтальное пространство настолько зажималось, что вложенные строки услуг схлопывались до нескольких пикселей ширины и текст названия наезжал на цену. Причина — тот же класс .installment-line без ограничения ширины предпочитал не переноситься (max-content), «съедая» почти всю строку на узком экране, а .cart-item-side с flex-shrink: 0 в базовом компоненте не уступал место. Для .cart-item.is-nested (вложенные строки услуг) вёрстка на мобильном переведена с флекса на CSS grid с именованными областями — чекбокс/название/цена больше не соревнуются за одну строку, цена уходит под название на новую строку внутри той же ячейки. Проверено визуально и через прямые замеры getBoundingClientRect() на нескольких промежуточных вариантах, пока наложение не исчезло полностью.
5. На чекауте гарантия по ошибке попадала в адресный блок «Установка техники» (требующий адрес/дату/время визита мастера) — потому что оба артикула-услуги имели один и тот же seller: 'services', а группировка по адресным блокам шла именно по seller. Гарантия визита мастера не требует. Решение: у каталожных записей появился отдельный признак isService: true (для «это услуга, не товар» — используется в подсчёте сумм и в мини-чеке), а seller у warranty-premium изменён на отдельное значение 'warranty', не входящее в перечень адресных блоков ['own', 'km-profil', 'services']; install-haier сохранил seller: 'services', так как визит мастера ему действительно нужен. Гарантия теперь видна только строкой «Гарантия» в мини-чеке справа. Заодно строки «Установка»/«Гарантия» в мини-чеке переведены с .find() на .filter().reduce() — раз услуга может встречаться по несколько раз (гарантия на холодильник и на болт одновременно), нужна сумма всех вхождений, а не первое найденное. Попутно убран весь легаси-код строки «Услуги (гарантия «72 часа»)» и связанного с ней ook696ServicesSelection — он читал чипы, которых с этой правки в корзине больше не существует ни у одного товара.
6. У карточки услуги убрано состояние «добавлена и привязана к товару». Раньше кнопка определяла «услуга уже в корзине» по одному itemId, без учёта linkedItemId — то есть если гарантия была добавлена через виджет на карточке холодильника, карточка услуги ошибочно считала себя «уже добавленной» и показывала, к какому товару услуга привязана. По требованию — это должны быть как бы две разные услуги: карточка услуги теперь ищет только запись с linkedItemId: null (свою, непривязанную), полностью игнорируя привязанные. При этом у самого добавления был реальный скрытый баг: фильтр очистки перед добавлением новой записи (filter(s => s.itemId !== SERVICE_ID)) удалил бы и привязанную запись тоже — исправлено на составной ключ, удаляется/заменяется только прежняя непривязанная запись. Проверено через Playwright: гарантия, привязанная к холодильнику, и гарантия, добавленная с карточки услуги, сосуществуют как два отдельных элемента списка одновременно, ни один клик на карточке услуги не трогает привязанную запись.
Проверено через Playwright на всех восьми файлах задачи (карточка товара, карточка услуги, корзина, чекаут — десктоп и моб.): без ошибок в консоли; строки услуг всегда видны и компактны без наложения текста на всех проверенных ширинах; шильдик рассрочки — рядом с ценой товара; гарантия визуально идентична в обоих блоках продавцов; чекаут не показывает гарантию в адресном блоке установки ни при одном, ни при двух одновременных вхождениях услуги; суммы в мини-чеке и общем итоге сходятся во всех сценариях, включая одновременную гарантию на два разных товара.
По просьбе перепроверить прототипы на соответствие последним требованиям — все 6 пунктов доработки 2 пройдены заново сквозными сценариями (реальные клики по чекбоксам/кнопкам/ссылкам, переход из корзины на чекаут и из карточки товара на карточку услуги по настоящим кнопкам и ссылкам, а не прямая запись в localStorage), на десктопе и мобильной версии. Все 6 пунктов подтверждены. Заодно найдены 2 реальных бага, не пойманных проверкой из доработки 2 — там сценарий с двумя одновременными непривязанными услугами не тестировался, ловятся оба только когда в блоке «Услуги» корзины остаётся ровно один из двух зарезервированных слотов.
Баг 1 (повтор уже известного в проекте паттерна): пустой второй слот блока «Услуги» был виден. Слот помечен атрибутом hidden, но общий класс .cart-item { display: flex } перебивает браузерное правило [hidden]{display:none} — авторские стили всегда сильнее правил браузера по умолчанию, независимо от специфичности. В результате при ровно одной непривязанной услуге второй слот отображался пустой рамкой с включённым чекбоксом. Исправлено явным .cart-item[hidden]{display:none} в обоих файлах корзины (десктоп и моб.).
Баг 2 (новый): иконка в слоте не зависела от того, какая услуга в нём оказалась. Иконки обоих слотов были жёстко зашиты в разметке (слот 0 — гаечный ключ установки, слот 1 — щит гарантии); JS-рендер обновлял текст/цену/чекбокс, но не иконку. При единственной непривязанной гарантии (которая попадает в первый свободный слот) показывалась иконка установки. Исправлено — иконка теперь берётся из каталога услуг по фактическому артикулу и подставляется при каждом рендере.
Проверено повторно после обеих правок: пустой слот полностью невидим (а не просто визуально пустая рамка), иконка верно соответствует услуге в любом из двух слотов, на обеих платформах.
Пользователь нашёл в живом использовании 4 новых дефекта, все — в корзине и на чекауте.
1. При увеличении количества товара цена рядом с привязанной к нему услугой перезаписывалась ценой товара. Причина — в JS-функции пересчёта цены строки (updateItemLinePrice) использовался item.querySelector('.cart-item-price') без ограничения поддерева: раз строки услуг находятся в разметке РАНЬШЕ собственной цены товара, такой запрос находил первую попавшуюся цену — цену вложенной услуги — вместо цены самого товара, и перезаписывал именно её. Исправлено ограничением поиска через :scope > — теперь функция берёт цену/чекбокс/количество строго у прямых потомков строки товара, не заходя во вложенные строки услуг.
2. У отдельно добавленной услуги (не привязанной к товару, из группы «Услуги» внизу корзины) не было переключателя количества вообще — в отличие от обычного товара. Добавлен тот же степпер количества, что у товаров; цена и передача количества на чекаут работают по той же схеме. Так как один и тот же слот при перерисовке может достаться другой услуге, количество сбрасывается в 1 только при смене услуги в слоте, а не при каждом обновлении.
3. На чекауте в блоке «Установка техники» строка адреса называлась «Адрес доставки» — неточно, установку никуда не доставляют, мастер приезжает оказать услугу по адресу. Переименовано в «Адрес оказания услуги» — только в этом блоке, у блоков реальной доставки (Холодильник.Ру, DBS-продавцы) подпись не менялась.
4. На мобильной корзине название вложенной в товар услуги переносилось на 3+ строки (иногда по слогам) — узкой была не сама строка услуги, а колонка, которую ей оставляла верстка: блок вложенных строк услуг жил внутри .cart-item-body товара и делил горизонтальное место с соседней колонкой цены/бейджа рассрочки этого же товара, а тем всегда не хватало ширины на узком экране. Решение — блок строк услуг вынесен из .cart-item-body наружу, стал прямым потомком строки товара и получил flex-basis: 100% при flex-wrap: wrap у родителя — теперь он всегда переносится на свою собственную строку на всю ширину карточки, не деля место с колонкой цены товара. Название на всех проверенных случаях умещается в одну строку.
Проверено через Playwright на десктопе и мобильной версии: увеличение количества товара больше не трогает цену услуг; количество отдельной услуги меняется, множится верно и корректно долетает до чекаута (проверено сквозным переходом «Перейти к оформлению»); подпись «Адрес оказания услуги» на чекауте в обоих файлах; название вложенной услуги на мобильной корзине — в одну строку с запасом по ширине; каскадное удаление товара по-прежнему корректно убирает вынесенный блок его услуг вместе с самим товаром — без ошибок в консоли.
1. После выноса блока строк услуг на всю ширину карточки (доработка 4, п.4) пропала визуальная связь с товаром — строки услуг выглядели как самостоятельный раздел, а не как часть конкретного товара. Сделан компромисс между старой версткой (строки услуг были вложены внутрь тела товара — связь была наглядной, но колонка была слишком узкой) и версией без отступа (широко, но не читалось, что услуги относятся к этому товару): добавлен отступ слева (64px, вместо прежних ~130px) и тонкая вертикальная линия-«ветка» рядом со строками услуг — читается как «эти пункты относятся к товару выше», при этом заголовку услуги по-прежнему хватает ширины на одну строку.
2. Новая логика: количество привязанной к товару услуги растёт вместе с количеством товара. Раньше у привязанной услуги количество всегда было 1 независимо от количества товара (своего переключателя количества у неё нет и не появилось — она относится к товару целиком, не покупается отдельными штуками). Степпер количества товара теперь при каждом изменении обновляет и цену, и «эффективное количество» каждой привязанной к этому товару услуги: 2 холодильника — 2 установки и 2 гарантии, с соответствующей ценой. Реализовано без изменения формата состояния — количество услуги, как и раньше у товаров, не хранится отдельно, а считывается «на лету» из степпера товара в момент любого пересчёта (в том числе при переходе на чекаут).
Проверено через Playwright на десктопе и мобильной версии: заголовок вложенной услуги — в одну строку, отступ и линия визуально связывают её с товаром выше, у обоих продавцов одинаково; увеличение количества товара до/после включения услуги — цена услуги пересчитывается верно в обоих случаях (было ли количество увеличено до или после включения услуги); уменьшение количества обратно возвращает цену услуги к исходной; сумма в мини-чеке и чекаут (включая чип с «×N» в адресном блоке услуги) считают верно; каскадное удаление и выбор «Все товары» не задеты правкой — без ошибок в консоли.
Пользователь прислал скриншоты реального сайта для шагов 2–4 воронки чекаута (после шага 1, уже покрытого прототипами OOK-836) и попросил собрать as-is по ним, затем to-be по образцу остальных экранов задачи. Скриншоты были высокими (до 4503px) — перед чтением нарезаны локальным инструментом tools/slice_screenshot.py на части по 1400px (база знаний, правило 6).
Шаг 2 — «Подтверждение заказа», новый экран. As-is (ook-836-checkout-confirm-asis.html) — read-only сводка выбранного на шаге 1: способ получения, дата, способ оплаты, «Перейти к оплате». To-be (ook-836-checkout-confirm-tobe.html) читает реальный выбор из корзины (ook696CartSelection) и группирует его в те же независимые блоки, что и сам чекаут (Холодильник.Ру / DBS-продавец / Установка техники) — каждый блок подтверждается отдельной карточкой. Кнопка «Далее» на чекауте (ook-836-checkout-tobe.html/моб.), которая раньше никуда не вела, теперь ведёт сюда.
Шаг 3 — переход к оплате, обобщённая заглушка (не as-is/to-be пара). Реальный шаг — переход на страницу стороннего платёжного провайдера (в присланном скриншоте — интерфейс СберБанка). Осознанное решение — не воспроизводить брендированный интерфейс чужого продукта: собрана нейтральная заглушка (ook-836-payment-redirect.html) на компонентах самого прототипа, с суммой заказа и кнопкой «Симулировать успешную оплату» для прохода демо-пути до конца. Зафиксирован факт (не отдельный прототип): к этому шагу заказ уже создан в системе со статусом «не оплачен» и доступен для повторной оплаты из личного кабинета — личный кабинет по прямому указанию пользователя не прорабатывается.
Шаг 4 — «Спасибо за заказ» (TYP), заполнена пустая заглушка, оставленная в самой первой версии задачи (2026-07-29) в ожидании реального референса. As-is (ook-836-typ-asis.html) собран по скриншоту один в один: статус-шаги заказа, способ получения/дата, информация об оплате, оценка удобства оформления, промо-баннер «Получайте подарки». To-be (ook-836-typ-tobe.html) отвечает на открытый вопрос, оставленный в исходной заглушке (п.9 требований): читает общее состояние услуг ook836ServiceState и показывает одно из двух состояний — если услуги в заказе нет, блок допродажи (установка/гарантия к уже купленному холодильнику); если услуга есть — статус каждой купленной услуги («мастер свяжется для согласования визита» и т.п.) вместо повторного предложения купить то, что уже куплено.
Проверено через Playwright сквозным сценарием на обеих платформах: карточка товара (включить услуги) → корзина → чекаут → «Далее» → подтверждение заказа (верно сгруппированные блоки, верные суммы) → «Перейти к оплате» → заглушка оплаты (та же сумма) → «Симулировать оплату» → TYP (корректно показывает купленные услуги и их статус, суммы сходятся на каждом шаге) — без единой ошибки в консоли на всех восьми новых файлах. Старая пустая заглушка ook-836-typ.html удалена, ссылки на index.html обновлены.
По прямому запросу опробован новый подход к презентации прототипов: обычный to-be рассчитан на то, что его показывает и комментирует автор (часть ссылок ведёт в никуда, нужный путь неочевиден постороннему), а для самостоятельного прохождения без сопровождения нужен один прямой путь с минимумом развилок и подсказкой, куда можно нажимать. Опробовано на полной воронке OOK-836 (задокументировано как новое общее правило — база знаний, Правило 11, раздел «Подход к созданию прототипов»).
Собран общий переиспользуемый механизм — components/guided-flow.js + стили в components.css: элементы, которые реально продолжают сценарий на экране, помечаются атрибутом data-flow-hotspot; клик/тап мимо них на секунду подсвечивает все помеченные элементы пульсирующей обводкой. Разметка не покрывает страницу целиком — шапка, футер, карусели и прочие декоративные href="#" остаются непомеченными, иначе подсказка теряет смысл (проверено: на карточке услуги 2 хотспота, на остальных экранах — по 1–2).
Сценарий: старт на карточке услуги «Установка встроенного холодильника» (услуга ещё не в корзине) — ook-836-service-card-tobe.html/-mobile-tobe.html. Дальше: корзина (можно включить/выключить ту же услугу нового — вложенным флажком под товаром) → чекаут → подтверждение заказа → оплата (заглушка, доработка 6) → «Спасибо за заказ» — без сопровождающих пояснений, только сама последовательность экранов.
Попутно найден и исправлен реальный пробел в UX мобильной карточки услуги (не только в демо-разметке): единственная кнопка «В корзину» вела дальше только после того, как услугу уже добавили («В корзине — перейти →»); если пользователь решал не добавлять услугу, продолжить путь на мобильной версии было физически некуда (на десктопе для этого служит иконка корзины в шапке, но на мобильной версии полной шапки нет). Добавлена всегда видимая ссылка «Перейти в корзину без услуги →».
Проверено через Playwright реальными кликами (не подстановкой в localStorage) на обеих платформах: подсветка появляется по клику мимо хотспотов и гаснет через ~0.9 с; полный путь пройден дважды — на десктопе с добавлением услуги на обоих шагах (карточка + корзина), на мобильной версии с пропуском на карточке услуги через новую ссылку и добавлением только в корзине — оба прогона без единой ошибки в консоли, суммы на «Спасибо за заказ» сходятся. Показ одной и той же услуги дважды на TYP при намеренном добавлении на обоих шагах — не баг, а задокументированное поведение архитектуры (см. требования OOK-836, п. «уточнение к п.1/2»): привязанный к товару и непривязанный экземпляры услуги — независимые позиции заказа.
Правка после показа: новая метка «▶ Пройти сценарий целиком» на index.html изначально была слишком длинной (с пояснением в скобках) и не переносилась по словам — не помещаясь по ширине, растягивала всю колонку To be и ломала выравнивание обеих колонок карточки задачи. Исправлено: текст метки сокращён, плюс на будущее в .proto-action-label добавлены max-width и перенос строк — чтобы длинная метка в любой будущей задаче переносилась, а не раздвигала колонку.
По итогу показа доработки 7 — запрос собрать что-то вроде «конфига прототипа»: для базового прохождения сценария DBS-товар в корзине не нужен и только отвлекает, но терять сценарий с DBS (демонстрирует дробление корзины) тоже не хочется. Решение — два именованных пресета, выбираемых параметром ?scenario= прямо в стартовой ссылке сценария.
Стартовый файл сценария (ook-836-service-card-tobe.html/-mobile-tobe.html), самым первым, до остальной логики страницы: если ?scenario= равен simple или full, один раз перезаписывает localStorage['ook696CartSelection'] нужным набором товаров и на всякий случай очищает ook836ServiceState (оба пресета должны стартовать без добавленных услуг, даже если в браузере осталось состояние от прошлого прохождения).
Обнаружилось, что этого недостаточно: ook696CartSelection — это то, что корзина записывает при переходе к оформлению, а не то, что она читает при отображении своего собственного списка товаров (оба товара в разметке корзины всегда присутствуют статически, чекбоксы только включают/выключают их в оформление). Поэтому пресет «без DBS» не убирал DBS-товар с самого экрана корзины — только из корзины/чекаута, если открыть их напрямую. Добавлена вторая, разовая метка ook836DemoScenario: корзина (ook-836-cart-tobe.html/-mobile-tobe.html) читает её при загрузке и, если сценарий «simple», прячет весь блок DBS-продавца (.seller-group[hidden]) — тем же способом, что уже используется при обычном удалении товара пользователем, поэтому счётчики и суммы (getActiveCheckboxes уже учитывает видимость) пересчитываются корректно без отдельной правки. Метка стирается сразу после чтения — обычный прямой заход в корзину (без повторного старта со сценарной ссылки) снова показывает оба товара, как раньше.
Пресет «Один товар» — только свой товар (fridge), без DBS. Пресет «Товар + DBS» — тот же товар плюс DBS-товар (bolt), для сценария с дроблением корзины на независимые блоки. На index.html — две отдельные ссылки вместо одной «▶ Пройти сценарий целиком». Проверено через Playwright на обеих платформах: пресет «simple» — DBS скрыт и в корзине, и в чекауте, суммы и счётчик товаров пересчитаны верно (1 из 1); пресет «full» — оба товара на месте (2 из 2); повторный прямой заход в корзину после прохождения сценария возвращает оба товара — без ошибок в консоли.
1. Даты/время доставки на мобильном чекауте — в одну горизонтальную свайпаемую строку. Раньше чипы переносились на несколько строк (flex-wrap: wrap), занимая много места по вертикали. В components.css добавлен опциональный модификатор .date-chip-row.is-scroll/.time-chip-row.is-scroll (flex-wrap: nowrap; overflow-x: auto) — опциональный, чтобы не задеть остальные задачи (OOK-275, OOK-696), которые используют тот же общий компонент чипов, но не подключали модификатор. Подключён только в ook-836-checkout-mobile-tobe.html, на всех пяти строках дат/времени (блоки «Холодильник.Ру», «КМ-Профиль», «Установка техники»).
2. Ссылка «Перейти в корзину без услуги →» на карточке услуги (моб.) заменена на нижний таббар — как на реальном сайте. Прежняя ссылка воспринималась как часть демо-разметки, а не элемент интерфейса. Добавлен переиспользуемый компонент .mobile-tabbar (6 пунктов: Меню / Каталог / Избранное / Поиск / Корзина / Павел — по образцу реального сайта) в components.css, подключён во все браузинговые экраны задачи: ook-836-product-card-mobile-asis.html (у экрана он тоже отсутствовал — реальный пробел в as-is, а не только in-scope правка), ook-836-product-card-mobile-tobe.html (синхронизировано с as-is) и ook-836-service-card-mobile-tobe.html. Пункт «Корзина» в последнем — обычная ссылка на корзину, помечена как хотспот демо-сценария (Правило 11) вместо прежней ссылки. Активный пункт таббара сознательно не проставлен ни на одном из экранов — карточка товара/услуги не соответствует напрямую ни одному из пяти разделов.
3. В корзине у строк услуг убран артикул (Артикул УСТ-247-ВСТР / Артикул ГАР-ПРЕМ-3Y) — не нужен пользователю, занимал место. Убрано у всех строк услуг (вложенных и в отдельной группе «Услуги») на десктопе и мобильной версии, включая JS-шаблон, которым заполняется слот отдельной группы.
4. Кнопка «Удалить» у товаров в мобильной корзине — исправлена реальная ошибка. Вместо иконки корзины/удаления на мобильной версии отображались три вертикальные точки (перепутанная иконка — скопирована иконка меню вместо иконки удаления, видимо, при более ранней адаптации вёрстки под мобильный экран). Заменено на ту же иконку урны, что и на десктопе, на всех четырёх кнопках удаления (товар «Холодильник.Ру», DBS-товар, обе строки отдельной группы «Услуги»). Заодно найден и исправлен второй, более старый баг того же места — кнопка удаления DBS-товара («КМ-Профиль») никогда не была подключена к обработчику ни на десктопе, ни на мобильной версии (не было ни id, ни вызова wireCascadeDelete) — визуально кликабельна, физически ничего не делала. Подключена на обеих платформах: wireCascadeDelete('delete-bolt', 'bolt').
Проверено через Playwright на обеих платформах: чипы дат/времени — в одну строку, реально скроллятся вбок (scrollWidth > clientWidth); клик по «Корзина» в таббаре карточки услуги без добавления услуги — переход в корзину, полный сценарий пройден до конца без ошибок; «Артикул» нигде не отображается; кнопка удаления DBS-товара реально убирает его из корзины и на десктопе, и на мобильной версии — без ошибок в консоли.
По итогу доработки 9 — на пункте «Корзина» нужен реальный счётчик, не просто иконка. Добавлен .mobile-tabbar-badge (тот же компонент, что уже использовался у «Избранное», раньше — статичная демо-цифра) на ook-836-product-card-mobile-tobe.html и ook-836-service-card-mobile-tobe.html: сумма товаров (ook696CartSelection, тот же дефолт-заглушка 2, что и на остальных экранах OOK-836, если ничего ещё не выбрано) и активных услуг (ook836ServiceState.length) — то же определение «количества товаров», что уже используют корзина и чекаут. Пересчитывается сразу при изменении состояния на самой странице (тумблеры на карточке товара, кнопка «В корзину» на карточке услуги), без перезагрузки.
На as-is (ook-836-product-card-mobile-asis.html) индикатор сознательно не добавлен — на реальном скриншоте-референсе (страница поиска/каталога) бейджа на «Корзина» не было, а моделировать реальное состояние аккаунта не задача as-is-экрана.
Проверено через Playwright: дефолт (ничего не выбрано) — бейдж «2» на обеих страницах; включение тумблера «Установка» на карточке товара — бейдж «3» сразу, без перезагрузки; клик «В корзину» на карточке услуги — бейдж «3» сразу; сценарий ?scenario=simple — бейдж «1» (только свой товар, без DBS), корректно отражает реально сиженное состояние — без ошибок в консоли.
По прямому запросу — сверка задачи с правилами 1–11 и исправление найденных нарушений. Разобрано подробно в отдельном разговоре с пользователем; здесь — сводка правок.
Правило 8 (открытые вопросы — всегда <ol>): в требованиях к задаче раздел «Открытые вопросы» был <ul> — исправлено на <ol>.
Правило 4 (требования — без дат, история — в «Историю разработки»): из требований убраны пять датированных <h3> (гарантия как вторая услуга, добавление из корзины, пересборка карточки услуги, «два независимых элемента заказа», гарантия без адресного блока) — эти факты уже задокументированы здесь, в истории. Актуальные на сегодня бизнес-факты из них перенесены без дат в соответствующие пункты «Детальных требований» (п.1, п.2, п.6) и в «Описание решения» (оговорка про гарантию как демонстрацию паттерна, не подтверждённый скоуп).
Правило 7 (без ссылок на другие задачи вне «Открытых вопросов»): в п.4 требований убрана ссылка на OOK-696 (базы знаний раздел 11) — оставлен только сам факт («оформление создаёт несколько независимых заказов»), без внешней привязки. Гораздо больше нарушений было в комментариях внутри прототипов — ook-836-cart-tobe.html и ook-836-checkout-tobe.html (десктоп и моб.) почти целиком пересказывали унаследованную логику и историю OOK-696 (блоки по продавцу, Яндекс-Сплит-исключение, самовывоз DBS, адресная независимость блоков, найденные в OOK-696 баги) вместо того чтобы просто сослаться на модалку OOK-696 и описать только собственную дельту OOK-836. Оба файла (и мобильные версии) радикально сокращены — оставлено только то, что реально добавляет OOK-836: блок «Установка техники», исключение услуг по способу оплаты, отдельные строки «Установка»/«Гарантия» в сводке, упрощённые демо-данные. Заодно это исправило и скрытое нарушение правила 2 (to-be-модалка не должна дублировать унаследованные требования) — обе модалки фактически предметом являлись пересказом требований OOK-696, а не только своей дельты.
Правило 9 (без технических имён — бизнес-язык вместо кода): по итогам обсуждения с пользователем — убраны все упоминания localStorage-ключей (ook836ServiceState, ook696CartSelection), полей состояния (linkedItemId, addedVia, itemId) и CSS-классов (.mobile-tabbar, .delivery-block-items) из требований и комментариев во всех файлах задачи. Заменены на бизнес-описание того же факта (например, «читают и пишут один и тот же список услуг» вместо ключа состояния) или на ссылку на видимый элемент интерфейса («кнопка «В корзину»» вместо id). Оставлены только по-настоящему видимые пользователю идентификаторы (артикулы УСТ-247-ВСТР/ГАР-ПРЕМ-3Y — реальные, показанные на странице) и параметры URL, которые нужны читателю операционно, чтобы воспользоваться демо-сценарием (?scenario=, ?service=) — без них нельзя было бы объяснить, какую ссылку отправить коллеге.
Проверено через Playwright: полный демо-сценарий (карточка услуги → корзина → чекаут → подтверждение → оплата → TYP) пройден заново на обеих платформах после всех правок — без ошибок в консоли; блоки доставки, кнопка «Далее», модалка требований (счётчик находок, нумерация вопросов) — всё работает как раньше.
OOK-834У holodilnik.ru уже есть бонусная программа и программа лояльности, но бонусы сейчас привязаны почти исключительно к заказам — пользователю негде получить бонус просто за лёгкое взаимодействие с сайтом вне покупки. Из-за этого нет простого, регулярного повода вернуться на сайт вечером, когда решение о покупке ещё не созрело.
Вечерний опрос — способ дать пользователю лёгкий, безрисковый повод провзаимодействовать с сайтом (один клик) и получить за это бонус, одновременно направляя его в каталог интересующей категории. Сами ответы на вопрос опроса не собираются и не анализируются — механика существует ради вовлечения, а не сбора данных.
Появляется новый раздел сайта — короткие «вечерние опросы». Каждый опрос — один вопрос с несколькими вариантами ответа в виде ссылок, без кнопки «Ответить»: клик по любому варианту сразу засчитывается как участие и ведёт на посадочную страницу с подборкой товаров по теме, а бонус начисляется отдельно.
Бонус за участие получают только участники программы лояльности. Если пользователь не авторизован или авторизован, но не в программе лояльности, — перед начислением бонуса ему нужно пройти вход по телефону и/или вступить в программу лояльности; для уже авторизованного участника программы лояльности всё происходит в один клик, без дополнительных экранов.
Об активных опросах пользователь узнаёт двумя способами: на самом сайте (отдельный раздел со списком опросов) и по email-рассылке — письмо не дублирует варианты ответа, а одной кнопкой ведёт на сайт, где и происходит участие.
Чтобы опросы могли появляться регулярно, бизнесу нужен инструмент для их самостоятельного создания — с указанием вопроса, вариантов ответа, срока действия и размера бонуса, без участия разработки в каждом конкретном опросе.
Нужна аналитика по каждому опросу: сколько пользователей его увидели (просмотры карточки в списке и/или страницы опроса) и сколько поучаствовали (клик по варианту ответа), с разбивкой по конкретным опросам. Точный состав метрик и способ сбора — на усмотрение дата-аналитика; предполагается, что аналитик либо составит по этому разделу своё отдельное ТЗ, либо настроит сбор самостоятельно.
Отдельная страница со списком всех опросов. У каждого опроса — статус (Активен / Вы уже участвовали / Опрос завершён), срок действия, вопрос и размер бонуса за участие. Клик по карточке открывает страницу опроса.
Список постраничный — по 20 опросов на страницу.
Вопрос и варианты ответа — в виде ссылок, без кнопки «Ответить»: клик по варианту сразу означает участие. Под вариантами — короткая подпись о том, что произойдёт после клика (начисление бонуса и переход на страницу с подборкой товаров по теме), чтобы переход не был неожиданностью.
У опроса три состояния: активен (можно ответить), уже отвечен (выбранный ранее вариант подсвечен, повторно бонус не начисляется), завершён (участие недоступно, варианты неактивны). Первый клик — финальный: изменить ответ или повторно поучаствовать в том же опросе нельзя. Завершённый опрос остаётся доступен по ссылке — вопрос и варианты можно посмотреть, просто нельзя ответить.
Важно для формулировок интерфейса: достоверно мы знаем только факт участия пользователя в опросе (что он уже отвечал), но не факт начисления бонуса — начисление происходит отдельно и не мгновенно (см. раздел 6). Интерфейс не должен утверждать «бонусы начислены» — только «вы уже участвовали»/«участие засчитано».
Клик по варианту ответа ведёт по одному из трёх путей, в зависимости от статуса пользователя:
Начисление бонуса за участие в опросе доступно только участникам программы лояльности — просто быть авторизованным пользователем недостаточно.
Вход происходит в модальном окне поверх текущей страницы (на мобильном — в шторке, выезжающей снизу экрана), без перехода на отдельную страницу. Вход только по номеру телефона, без пароля: пользователь вводит телефон, получает 4-значный код по SMS и вводит его — вход выполнен. Есть таймер повторной отправки кода и блок «Не приходит код авторизации?» со ссылкой на звонок в поддержку, чекбокс согласия на рекламные рассылки (по умолчанию отмечен) и ссылки на согласие по обработке персональных данных и пользовательское соглашение.
Отдельный шаг после авторизации (если пользователь ещё не участник программы лояльности) — короткий экран с объяснением, зачем это нужно, и кнопкой «Присоединиться к программе лояльности». Сама механика вступления (форма, условия и т.д.) здесь не проработана, показана только точка входа.
После успешного участия пользователь попадает на страницу с подборкой товаров по теме опроса. На странице явно и заметно показывается сообщение о начислении бонуса — в виде модального окна, которое открывается автоматически, чтобы его точно заметили.
Тот же опрос дублируется в email-рассылке — всегда в одном и том же виде, независимо от того, авторизован ли получатель на самом деле и состоит ли в программе лояльности: получатель письма считается уже авторизованным участником программы лояльности. Отдельного варианта письма для «гостя» нет и не нужно. В письме — вопрос и одна кнопка «Участвовать в опросе», которая ведёт на страницу опроса на сайте (в мобильную версию — расчёт на то, что письма чаще открывают с телефона). Кнопка в письме сознательно ведёт на сайт, а не начисляет бонус сразу по клику в самом письме — цель этой механики в целом не «пройденный опрос», а трафик на сайт.
Чтобы вечерние опросы вообще могли появляться на сайте, нужен отдельный раздел в админке для их создания и управления — прототип показывает только сторону пользователя (сайт, письмо), но не сторону того, кто эти опросы заводит и настраивает.
Минимально нужно уметь:
Отправка email-рассылки — сам процесс отправки нужно проработать отдельно. Рассылка отправляется через партнёра Mindbox — нужно выяснить, можно ли автоматизировать создание этих рассылок, или каждое письмо придётся готовить вручную.
Собрать требования по SEO.
https://drugtolik.ru/holodilnik/index.html?task=OOK-834
Прикрепить ссылку/задачу на макеты
OOK-834Внутренний журнал изменений по датам — не для дизайнера/аналитика, но полезен при дальнейших доработках, чтобы понимать, что и почему менялось. Актуальные требования — в соседнем документе «Требования к задаче».
Собраны первые прототипы по приложенной к задаче схеме (флоучарт от руки): листинг опросов, страница опроса с демо-переключателем персон (Гость / Авторизован без ПЛ / Авторизован с ПЛ), одно универсальное письмо, экран /usercp/loyalty/ (форма логин+пароль на отдельной странице — позже пересмотрено по реальным скриншотам), обобщённая посадочная страница с баннером начисления бонуса.
Посадочная страница пересобрана по реальным скриншотам категории «Двухкамерные холодильники» (десктоп и мобильная версии — отдельными файлами): шапка с поиском, хлебные крошки, фильтры, карточки товаров, пагинация, подборки, футер. Персона по умолчанию на странице опроса изменена с «Гость» на «Авторизован и в ПЛ» — чтобы первый клик сразу показывал самый простой сценарий. Письмо разделено на два файла для двух крайних сценариев получателя (авторизован+ПЛ / гость).
Ссылки в обоих письмах перенаправлены на мобильные версии страниц вместо десктопных. Для этого впервые появилась мобильная версия экрана /usercp/loyalty/. Расширенная шапка (с поиском), хлебные крошки и подвал добавлены также на листинг опросов и страницу опроса (раньше были только на посадочной странице). Сообщение о начислении бонуса переделано из закрываемого баннера в модальное окно, открывающееся автоматически при загрузке страницы.
В обоих письмах варианты ответа заменены на одну кнопку «Участвовать в опросе», ведущую на мобильную страницу опроса — собственно участие (клик по варианту, начисление бонуса) теперь происходит только на сайте, а не в письме.
По приложенным скриншотам реальной формы входа на holodilnik.ru экран авторизации полностью пересобран: вместо формы «логин/email + пароль» на отдельной странице — модальное окно (на мобильном — шторка снизу) с входом по телефону и SMS-кодом, без пароля. Модалка открывается прямо на странице опроса по клику на вариант ответа, а не уводит на отдельную страницу. Отдельные файлы экрана /usercp/loyalty/ сохранены как самостоятельные демо-страницы (доступны по прямой ссылке с index.html) — на них та же модалка открывается автоматически.
Задаче присвоен официальный номер OOK-834 (был плейсхолдер OOK-XXX) — переименованы все файлы прототипов и обновлены все ссылки. Документация задачи разделена на три уровня: «Требования к задаче» (для дизайнера/аналитика, без дат и техно-подробностей), «История разработки прототипа» (этот журнал) и комментарии внутри каждого отдельного прототипа (только специфичные для конкретного экрана детали, не дублирующие общие требования).
Продакт-менеджер прошёлся по списку открытых вопросов из «Требований к задаче» и закрыл большинство из них:
ook-834-email-guest.html удалён, ook-834-email-loyalty.html переименован в ook-834-email.html и остался единственным вариантом. На index.html — одна кнопка «Открыть письмо» вместо двух («Участник ПЛ» / «Гость»).В требованиях не было ни слова о том, как эти опросы вообще появляются на сайте — весь прототип описывает только пользовательскую сторону. Добавлен раздел 8 «Инструмент управления опросами (админка)»: что нужно уметь как минимум (создание опроса с вопросом/вариантами/целями ответов, срок действия, размер бонуса, публикация/черновик/досрочное завершение, планирование заранее), и отдельно — потенциальные потребности бизнеса, которые прямо из прототипа не следуют, но логично возникают (несколько одновременно активных опросов и их порядок, базовая статистика по участию, связь публикации с рассылкой письма, клонирование опроса как шаблона). Раздел собран по тому, что видно в прототипе (статусы, срок действия, бонус за опрос), плюс типовые потребности похожих админ-инструментов.
Также в открытые вопросы добавлен пункт про сценарий для пользователя с установленным мобильным приложением ХОЛОДИЛЬНИК.РУ — по просьбе пользователя, без проработки, обсуждение отложено на потом.
Продакт-менеджер закрыл вопросы из блока «Потенциальные потребности бизнеса» раздела 8:
Обсудили сценарий пользователя с установленным мобильным приложением (нативным, кроме корзины — вебвью, см. базу знаний, раздел 16). Цель бизнеса — реализовать вечерние опросы и на сайте, и в приложении, но по возможности разнести доработку по времени, начав с сайта. Технический риск в переходный период — это перехват ссылок на уровне ОС (Universal Links на iOS, App Links на Android): если раздел опросов (или домен целиком) зарегистрирован за приложением, переход по ссылке из письма на телефоне с приложением откроет не сайт, а приложение, и дальше всё зависит от того, что приложение делает с незнакомым путём (открывает вебвью того же URL — тогда всё работает, или падает в ошибку — тогда флоу ломается). Открытый вопрос в требованиях переформулирован в два конкретных технических пункта для проверки с мобильной командой, вместо общей формулировки «как это будет выглядеть».
По запросу продакт-менеджера прототипы и требования проанализированы «со стороны PM» и «со стороны аналитика разработки» на предмет пробелов. Из всего списка находок разобрали и закрыли следующее:
ook-834-surveys-list.html/-mobile, ook-834-survey.html/-mobile) — состояние «уже участвовали» утверждало «бонусы начислены» / «бонусы уже начислены», хотя достоверно системе известен только факт участия, а не факт зачисления бонуса (оно происходит отдельно и не мгновенно — раздел 6). Текст заменён на «Участие засчитано» / «Вы уже участвовали в этом опросе» без утверждения про начисление. В требования (раздел 2) добавлено явное правило для будущих формулировок интерфейса.ook-834-surveys-list.html/-mobile) добавлена некликабельная пагинация внизу списка — сами 20 карточек заводить не стали, это только визуальная демонстрация наличия пагинации.Установлено общее правило оформления документа «Требования к задаче» для всех будущих задач — 5 обязательных разделов в фиксированном порядке: «Исходная задача» (1–2 абзаца, в чём проблема и почему решили её делать), «Описание решения» (максимум 4–5 абзацев даже для сложных задач — что хотим сделать и что меняется в продукте), «Платформы» (десктоп / мобильная версия сайта / планшет / мобильное приложение — по умолчанию все четыре, но по факту задачи), «Метрики» (нужно ли что-то мониторить — по сути требования к дата-аналитику) и «Детальные требования» (всё остальное, с подразделами). Правило записано в базу знаний как «Правило 5» (раздел «Подход к созданию прототипов»).
Документ OOK-834 переструктурирован под этот шаблон: добавлены новые разделы «Исходная задача» (собран из ранее не сформулированной явно бизнес-мотивации), «Описание решения» (4 абзаца, собраны из уже существовавших разделов 1–3, 7–8 в сжатом виде), «Платформы» (десктоп и мобильная версия сайта — проработаны; планшет — не прорабатывался, вопрос дизайнеру; email — отдельный канал; мобильное приложение — в перспективе, не в этом релизе) и «Метрики» (перенесено и расширено из абзаца «Аналитика кликов и просмотров», который раньше был спрятан внутри раздела про админку). Уровень заголовков поправлен: пять основных раздела — <h2>, а прежние разделы 1–8 плюс «Открытые вопросы» и «Что осознанно не проработано» — стали подразделами «Детальных требований» на уровень ниже, <h3>.
Мобильное приложение включено в скоуп задачи. В разделе «Платформы» формулировка «предполагается в перспективе, но не в этом релизе» заменена на «включено в эту задачу»; при этом сохранён открытый вопрос про возможность разнести доработку сайта и приложения по времени (сайт — отдельным этапом вперёд) — с уточнением про Universal Links/App Links и риском для перехода по ссылке из письма у пользователей с установленным приложением.
Добавлен раздел «9. SEO» в «Детальные требования» — пока заглушка с пометкой «Собрать требования по SEO.» (класс .todo-note, красный текст).
Добавлен новый обязательный 6-й раздел «Макеты» — и в саму задачу OOK-834 (ссылка на прототип задачи https://drugtolik.ru/holodilnik/index.html?task=OOK-834 + заглушка красным «Прикрепить ссылку/задачу на макеты» под будущую ссылку на макеты дизайнера), и в общее правило — «Правило 5» в базе знаний переименовано в «6 обязательных разделов». Для заглушек введён общий CSS-класс .todo-note (components.css, красный жирный текст через var(--color-danger)) вместо инлайновых стилей.
Ссылка «🕘 История разработки прототипа» убрана из карточки задачи — по прямому указанию: эти данные должны оставаться только для внутреннего использования между сессиями и не показываться другим пользователям сайта. Сам <template id="ook-834-history"> (этот файл) не удалён и продолжает пополняться — просто без видимой ссылки-триггера в .proto-card-docs. Это же изменение внесено в общий шаблон для будущих задач и в «Правило 4» базы знаний как durable-конвенция.
Карточка «Референс: главная страница» убрана из раздела «Общее» — по указанию «нам не нужна эта страница». Убрана только карточка/ссылка; сам файл prototypes/reference-homepage.html на диске сохранён, не удалён.
Разработка задачи завершена, фича реально работает на сайте под названием «Вопрос дня» (не «Вечерний опрос» — так называлась только на этапе прототипа). На карточку задачи в index.html добавлен зелёный бейдж «✓ Внедрено» рядом с ID задачи, плюс пометка настоящего названия рядом с заголовком карточки. В базе знаний (#surveys, раздел 15) статус сменён с «В работе» на «Внедрено на сайте (MVP1)», с пояснением, что финальная реализация опиралась на отдельную, более подробную документацию аналитика, а не только на этот прототип, и что часть деталей (например, пагинация — 10 на странице, а не 20) в проде решена иначе, чем в прототипе. Также по просьбе пользователя подготовлено отдельное краткое описание сервиса для его личного пространства продакт-менеджера (не файл в этом репозитории) — что это, зачем нужно, из чего состоит, как управляется, без глубокой детализации.
По прямому запросу пользователя (готовит кроссзадачное демо целевого результата по всем задачам направления «Вопрос дня») нижний таббар добавлен в четыре мобильных файла этой задачи, где его раньше не было: ook-834-landing-bonus-mobile.html, ook-834-loyalty-gate-mobile.html, ook-834-survey-mobile.html, ook-834-surveys-list-mobile.html — та же разметка .mobile-tabbar, что уже используется в OOK-903/917/918, иконка «Павел» ведёт на to-be меню личного кабинета (ook-903-user-menu-mobile-tobe.html). Десктопные файлы задачи (ook-834-*.html без суффикса -mobile) не тронуты — нижний таббар специфичен для мобильной вёрстки, на десктопе такого элемента нет ни в одном прототипе проекта.
По прямому запросу подключён существующий общий механизм components/guided-flow.js (правило 11 базы знаний, ранее использовался только в демо-сценарии OOK-836) — теперь на всех страницах, а не только в одном линейном сценарии: клик мимо реального кликабельного элемента на секунду подсвечивает пульсирующей обводкой все элементы с атрибутом data-flow-hotspot на текущей странице. Атрибут добавлен на все содержательные ссылки/кнопки, ведущие на реальный экран или выполняющие реальное действие: обратные стрелки (там, где они ведут не на «#»), хлебные крошки на список опросов, карточки опросов в списке, кнопки ответа на вопрос дня, кнопка «Войти»/«Присоединиться к программе лояльности» в шторке входа, иконка «Павел» в таббаре.
Сознательно НЕ размечено (не считается «реальным» кликом для целей этой подсказки): декоративные ссылки href="#" без реального действия (остальные 5 пунктов таббара, футер, переключатель демо-персоны, кнопки «по почте»/чекбоксы согласия внутри модалок), а также содержимое модалок логина/вступления в программу лояльности, которые по умолчанию скрыты и открываются по клику на уже размеченный элемент (кроме ook-834-loyalty-gate-mobile.html — там модалка открыта по умолчанию, это и есть содержимое страницы, поэтому её кнопки размечены). Ссылки на документацию внутри скрытых <template id="requirements-content"> не размечены — они не видны на самой странице.
По прямому запросу («сделай список идентичным во всех задачах: OOK-834, OOK-903, OOK-917, OOK-918») содержимое (стили и разметка списка) файла ook-834-surveys-list-mobile.html заменено на канонический вариант, ранее собранный в OOK-918 (см. историю OOK-918, раунд с этой же датой) — теперь список показывает все 8 карточек, включая типы «Голосование» и «Клад», которых на реальном сайте (as-is) ещё нет. Это осознанное отступление от обычной as-is-дисциплины «показывать только то, что видел на сайте» — ради единого кроссзадачного демо-опыта; отступление явно задокументировано в комментарии самого файла (requirements-content), а не сделано молча. Собственный <title> файла сохранён.
Из карточки типа «Опрос» в ook-834-surveys-list-mobile.html убран статус-бейдж «Активен» — по прямому запросу, следом за уже убранным ранее «Активно» у «Голосование»/«Клад». Правка сделана в каноническом списке (см. историю OOK-918) и разошлась по всем 4 файлам.
По прямому запросу («список опросов оставляем только в задаче OOK-903, везде ссылаемся на него») файл ook-834-surveys-list-mobile.html удалён — из четырёх визуально идентичных копий списка (были в OOK-834/903/917/918) остаётся только копия задачи OOK-903, ook-903-surveys-list-mobile-tobe.html. Обе ссылки на список из файлов этой задачи (обратная стрелка и хлебная крошка «Вечерние опросы» в ook-834-survey-mobile.html) переключены на файл OOK-903. Настольный (десктопный) список ook-834-surveys-list.html не трогали — консолидация касалась только мобильных to-be копий.
По прямому запросу («доработай таббар... при клике по иконке «Поиск» открывался прототип «Главная с виджетом «Вопрос дня» — есть активный вопрос»») в трёх мобильных файлах этой задачи (ook-834-survey-mobile.html, ook-834-loyalty-gate-mobile.html, ook-834-landing-bonus-mobile.html) декоративная ссылка href="#" у пункта «Поиск» заменена на ook-903-question-widget-mobile-tobe.html, добавлен data-flow-hotspot. Раньше в таббаре реальной была только ссылка «Павел» (на меню личного кабинета) — теперь у пункта «Поиск» тоже есть реальная цель, что позволяет из любого экрана раздела вернуться на главную с виджетом одним кликом, замыкая кроссзадачное демо в кольцо.
Заполнить.
Заполнить.
Заполнить.
Заполнить.
Заполнить.
Прикрепить ссылку/задачу на макеты
OOK-903Внутренний журнал изменений по датам — не для дизайнера/аналитика, но полезен при дальнейших доработках, чтобы понимать, что и почему менялось. Актуальные требования — в соседнем документе «Требования к задаче».
Карточка и заглушка требований созданы по запросу пользователя, скоуп ещё не описан — продолжение задачи «Вопрос дня» (OOK-834), про точки входа в сервис (где на сайте пользователь узнаёт об активных опросах). Наполнение требований — следующим шагом.
Обсудили, на каких этапах пути пользователя можно вести трафик в раздел опросов: хедер/футер (постоянный пункт меню), промо-блок на главной (реальный референс главной показывает, что баннер там и так уже слайдер из нескольких промо — идея: добавить туда ещё один слайд, а не изобретать новый блок), «Мои заказы» (под активным заказом, один раз на странице, посыл «пока ждёшь — заработай бонусы»), «Мои бонусы». Зафиксировано, что для «Мои заказы» и «Мои бонусы» as-is не хватает — эти страницы не сняты ни в каком виде, без них нельзя решить точное место врезки блока.
Дальше скоуп задачи сместился: вместо точечных правок на 4 существующих экранах решили сначала сделать отдельный лендинг-хаб — общую точку входа сразу для всех активностей, дающих бонусы (а не только для опросов). Пользователь перечислил 5 механик: вопрос дня, ежедневная игра по типу Wordle (+50 Б за угаданное слово), подписка на push, добавление товаров в избранное, регулярный бonus за клики по push. Собран первый мобильный набросок — ook-903-bonus-hub-mobile-tobe.html: карточка баланса сверху, затем 5 плиток-способов. Для двух ежедневных механик (опрос, игра) намеренно показаны разные состояния — «доступно» и «уже сделано сегодня» — без переключателя, по образцу листинга опросов OOK-834, где то же самое сделано тремя статичными карточками.
Открыто: точные условия/размер бонуса за «Избранное» и за клики по push не уточнены с продуктом (в наброске — условные цифры); куда ведут остальные плитки (реальные экраны игры/избранного) не проработано — это набросок только самого хаба; как хаб встраивается в 4 ранее обсуждённые точки входа — отдельный следующий шаг, не сделано.
Собран отдельный набросок — ook-903-question-widget-mobile-tobe.html: виджет специально про вопрос дня (не про весь хаб), задуманный для встраивания на главную страницу. Логика по запросу пользователя: если есть активный вопрос дня с доступным бонусом — виджет ярко подсвечивает сам вопрос и зовёт ответить; если активного вопроса нет или он уже пройден — виджет не пустует, а приглушённо зовёт в общий хаб «Заработать бонусы» (round 2).
Первая версия показывала оба состояния друг под другом на самодельном обрезанном фрагменте главной (только хедер+поиск+плашки, дальше — текстовая заглушка «дальше обычные карусели»). По просьбе пользователя переделано: взята полная копия актуального as-is reference-homepage-mobile.html (весь список каруселей, футер, таб-бар — не обрезано), виджет вставлен в неё сразу под рядом промо-плашек, перед первой каруселью. Переключение между состояниями — через ?state= (по умолчанию есть вопрос; ?state=none — вопроса нет), а не визуальным стеком с подписями «Вариант А/Б» как в первой версии — тот же паттерн, что уже используется в OOK-836 (?scenario=) и OOK-834 (?state=). В requirements-комментарий файла добавлен раздел «Инфоблоки» (правило 13) — единственное добавление к as-is-предку — сам виджет, ничего не убрано.
Копия локальная, не общий компонент — при обновлении reference-homepage-mobile.html по новому скриншоту сюда правки не подтянутся автоматически. Место виджета (сразу под промо-плашками) и поведение состояния «вопроса нет» (звать в хаб, а не скрывать виджет) — решения уровня прототипа, с продуктом не сверены.
Работа над новым форматом вопроса дня — выбор между двумя вариантами по образцу уличных роликов «Это или Это» — велась в рамках этой задачи в раундах 4–10: первый набросок с 5 независимыми парами картинок, затем правки по фидбэку (порядок блоков, длина вопросов, размер прогресс-бара, формулировки), затем смена механики на единый вопрос с раундами на выбывание (победитель остаётся, проигравший заменяется новым претендентом, 5 раундов), убранная иконка-звезда и добавленная кнопка «Поделиться», и наконец багфикс «прыгающей» карточки победителя.
2026-09-08 эта ветка выделена в отдельную задачу OOK-917 «Вопрос дня. Голосования» — разрослась в самостоятельную работу с собственными раундами правок, файл переименован в ook-917-pair-choice-mobile-tobe.html. Полная построчная история раундов 4–10 перенесена в журнал разработки OOK-917, здесь оставлена только эта сводная запись для целостности хронологии.
Вернулись к виджету на главной (ook-903-question-widget-mobile-tobe.html, round 3) — по фидбэку «скромно смотрится». Раньше «+50 Б» был мелким полупрозрачным бейджем сбоку в одной строке с кнопкой «Ответить» — терялся на фоне остального. Пересобрано: бонус вынесен в отдельный крупный блок (30px, контрастный жёлто-золотой градиент вместо белого полупрозрачного) сразу под эйброу «🔥 Вопрос дня», текст вопроса — под ним, теперь визуально вторичный. Кнопка «Ответить» стала отдельной строкой на всю ширину карточки, а не втиснута рядом с бейджем. Порядок восприятия теперь явно «сначала сколько дадут, потом что за это нужно сделать» — то, что и просили. В приглушённом состоянии (активного вопроса нет) золотой блок не показывается — там нет конкретного бонуса, который можно было бы обещать прямо сейчас.
Уточнение по прошлому раунду: сделав текст вопроса вторичным, чтобы он не спорил визуально с золотым бонус-блоком, перегнули — пользователь должен одинаково ясно видеть и вопрос («что от него хотят»), и бонус («что за это будет»), а не только последнее. Текст вопроса возвращён к заголовочному начертанию (крупный, жирный — наравне по значимости с бонус-блоком, не мельче) и переставлен выше него. Порядок чтения в карточке теперь: «Вопрос дня» → сам вопрос → «+50 Б» → «Ответить» — сначала понятно, что нужно сделать, потом что за это будет, потом призыв к действию.
Новая ветка работы в рамках задачи: пользователь прислал скриншот реально отправленного письма «Вопрос дня» и данные — конверсия из открытия письма в переход по ссылке около 2%, попросил собрать as-is и погенерировать гипотезы, почему так низко.
Гипотезы, обсуждённые с пользователем (до сборки прототипов):
As is (ook-903-email-asis.html) — снят по присланному скриншоту: сумма бонуса в реальности 20, а не 50 (демо-цифра прототипов этой сессии не совпадала с реальной), нет фирменного хедера как в прототипе письма OOK-834, другая тема вопроса.
Три новых варианта — сумма бонуса не менялась нигде (+20, по прямому условию), каждый вариант целится в одну доминирующую гипотезу, чтобы результат теста был интерпретируем:
ook-903-email-variant-a-tobe.html) — дедлайн «до 23:59» + сумма бонуса прямо на кнопке («Ответить — забрать +20 Б →»). Проверяет гипотезы «срочность» и «конкретика у кнопки».ook-903-email-variant-b-tobe.html) — вопрос заменён на лёгкий, вкусовой («Какой холодильник вам ближе?»), всё остальное как в as-is. Проверяет гипотезу про тему вопроса.ook-903-email-variant-c-tobe.html) — варианты ответа кликабельны прямо в письме (без перехода на отдельную страницу опроса), плюс более фирменный, менее «рассылочный» визуальный стиль. Самый смелый вариант — явно пересматривает решение OOK-834 «письмо ведёт на сайт»; в комментарии к файлу отдельно зафиксировано, что если он выиграет по конверсии клика, встанет отдельный бизнес-вопрос про потерю трафика на сайт, который эта механика должна была генерировать — это решение уровня бизнеса, не дизайна.Все четыре файла используют общий паттерн вёрстки письма из ook-834-email.html (карточка .email-box, без табличной/инлайн-вёрстки, не production-ready — см. комментарий в исходном письме) — локальные копии, не общий компонент.
Пользователь отклонил все три варианта из round 13 целиком («все три прототипа письма плохие, можно удалять») — файлы ook-903-email-variant-a-tobe.html, -variant-b-tobe.html, -variant-c-tobe.html удалены. Три конкретных решения по фидбэку:
Прямой запрос: подойти радикальнее, вплоть до полного отказа от рамки «вопрос/опрос» в самом письме — заменить на «замануху» в духе прямого обещания бонуса за клик («20 бонусов за клик»). Собраны два новых, принципиально разных варианта:
ook-903-email-variant-d-tobe.html) — «мгновенный подарок, без слова „опрос“»: из письма убрано вообще всё, что называет механику опросом — только именное обращение с суммой («Павел, для вас — 20 бонусов») и кнопка. Реальный вопрос по-прежнему на сайте после клика, просто в письме о нём не говорится. В комментарии к файлу отдельно и честно зафиксирован компромисс: получатель не будет знать заранее, что нужно ответить на вопрос, чтобы получить бонус, — это не обман (переход ведёт на настоящую страницу с настоящим начислением), но осознанный отказ от полной прозрачности ради более высокого шанса на клик, который стоит одобрить осознанно, а не как побочный эффект.ook-903-email-variant-e-tobe.html) — «личное уведомление, а не рассылка», ещё более радикальная версия той же идеи: если контент 10 раз менялся без эффекта, возможно, дело в самом визуальном жанре «яркое промо-письмо» (баннер, эмодзи, крупная кнопка), а не в тексте внутри него. Вариант отказывается от промо-стилистики целиком в пользу вида простого личного/транзакционного уведомления — обычный текст на белом фоне, никакой карточки с тенью, ссылка вместо кнопки-заливки.Оба новых варианта: сумма бонуса не менялась (+20), голосования внутри письма нет (по прямому указанию), дедлайн сознательно не добавлен ни в один (решение по этому рычагу пользователь просил отложить). В комментарии к варианту Д отдельно отмечено, что формулировку «зарезервировано» стоит сверить с юристами/комплаенсом перед реальным использованием — это уже не чисто дизайнерский вопрос.
Пользователь посмотрел варианты Г и Д и дважды написал «не вкусно», без деталей. Вместо третьей попытки вслепую — уточняющий вопрос: оказалось, дело не в самой стратегии «не упоминать вопрос в письме» (её не отклонили), а в скудном визуальном исполнении — оба варианта были почти голым текстом без единого сильного визуального акцента.
Вариант Г — добавлена карточка-награда: тёплый золотой градиент, крупная цифра «20» и подпись «бонусов ХОЛОДИЛЬНИК.РУ», один крупный 🎁 сверху как единственный целенаправленный акцент (не россыпь мелких эмодзи по тексту, как в as-is).
Вариант Д — важное уточнение по ходу правки: его первая версия была буквально голым текстом на белом фоне, и минимализм прочитался как «недоделано», а не «сдержанно». Разница между этими двумя вещами — в качестве немногих оставленных деталей, а не в их количестве: крупная цифра «20» набрана акцентным шрифтом с засечками (отдельным от остального текста), тонкая золотая линия-разделитель, контурная кнопка вместо текстовой ссылки, мягкая тень и скруглённые углы у карточки, разрядка букв у бренда. Жанр «не похоже на рассылку» сохранён — просто исполнен так же тщательно, как яркий вариант Г, а не как черновик.
Ни в одном из вариантов не менялась стратегия (вопрос по-прежнему не упоминается в письме), сумма бонуса (+20), отсутствие голосования внутри и отсутствие дедлайна — правка была точечно про визуальное качество, по прямому уточнению пользователя.
По прямому запросу задача переименована из OOK-891 в OOK-903 (название «Вопрос дня. Точки входа» не менялось) — переименование сквозное: номер задачи обновлён во всех файлах прототипа (ook-891-* → ook-903-*) и во всех текстах, которые на неё ссылаются, включая истории задач OOK-917 и OOK-918 (обе выделились именно из этой задачи и упоминали её под старым номером). Тексты историй прошлых раундов внутри этого же документа (выше) также обновлены на новый номер — это чистое переименование одной и той же задачи, а не создание новой, поэтому исторические записи меняют номер вместе с ней, в отличие от происходившего ранее выделения OOK-917/OOK-918 в отдельные задачи (там номер предшественника в истории остаётся прежним, потому что предшественник — другая, самостоятельная задача).
Удалено по прямому запросу: состояние виджета «Вопрос дня» на главной для случая «вопроса нет» (было доступно через ?state=none, приглушённый вариант, звавший в общий хаб) — убрано из ook-903-question-widget-mobile-tobe.html целиком (разметка, CSS, скрипт-переключатель), экран теперь показывает только состояние «есть активный вопрос». Также удалены все три прототипа письма-рассылки: as-is (ook-891-email-asis.html) и оба радикальных варианта Г/Д (ook-891-email-variant-d-tobe.html, -variant-e-tobe.html) — вся ветка работы над письмом (раунды 13–15 выше) остаётся в истории как есть, только файлы и ссылки на них убраны из карточки задачи.
Новый второй вариант хаба «Заработать бонусы» — по прямому запросу «плиткой по две в ряд, чтобы смотрелось посочнее»: ook-903-bonus-hub-tiles-mobile-tobe.html. Тот же контент (баланс, 5 способов, суммы бонусов), что и в первом варианте-списке (ook-903-bonus-hub-mobile-tobe.html, не удалён, оба варианта сосуществуют), но в сетке 2×2 из цветных плиток — у каждой активной механики свой цвет-акцент (вопрос дня — синий, push-подписка — фиолетовый, избранное — розовый, уже сыгранная игра — зелёный с чек-маркой), крупная иконка в полупрозрачном круге, сумма — контрастной белой плашкой. Пятая, некликабельная плитка (пассивный бонус за клики по push) намеренно оставлена вне цветной сетки — растянута на всю ширину нейтральным серым блоком, чтобы не выглядеть ещё одним кликабельным способом заработать наравне с остальными. Открытый вопрос, зафиксированный в комментарии к файлу: цветовые акценты по механикам придуманы для прототипа, не закреплены как часть дизайн-системы.
Исправлена ссылка плитки «Вопрос дня» в обоих вариантах хаба (список и плитки) — раньше вела напрямую на конкретный вопрос (ook-834-survey-mobile.html), теперь — на общий список всех опросов ook-918-surveys-list-mobile-tobe.html (актуальный на сегодня список из трёх типов: опрос/голосование/клад), по прямому запросу «должна вести на разводящую вопроса дня — там, где список всех опросов». Текст плитки («Один клик — и бонус ваш») не менялся, хотя теперь строго не описывает результат клика буквально (ведёт на список, не сразу на вопрос) — не в рамках этой правки, только ссылка.
Два новых as-is экрана личного кабинета — по прямому запросу, со ссылкой на скриншоты с рабочего стола пользователя. Перед сборкой прочитана вся секция «Подход к созданию прототипов» базы знаний, в частности правило 6 (as-is по реальной странице: DOM + нарезанный скриншот вместе, всегда с прокрутки) — здесь доступен был только скриншот (не живой DOM), оба файла (378×3653 и 378×2377, выше порога 1500px) нарезаны инструментом tools/slice_screenshot.py и прочитаны целиком по частям перед вёрсткой, как предписывает правило.
Обнаружено и исправлено несоответствие в самом запросе пользователя: подписи и имена файлов в сообщении были перепутаны местами — «меню пользователя» было указано с файлом Мои бонусы.png, а раздел «Мои бонусы» — с файлом Меню пользователя.png. Проверено содержимым самих скриншотов (не только именами файлов): Меню пользователя.png реально показывает список пунктов меню личного кабинета (Корзина, Сравнение, Избранное, Мои заказы, Мои бонусы, Архив заказов и т.д.), а Мои бонусы.png — экран баланса и истории начислений/списаний. Собрано по фактическому содержимому скриншотов, а не по подписям в сообщении, с явным уведомлением пользователю об этом расхождении.
ook-903-user-menu-mobile-asis.html — 13 пунктов меню личного кабинета. Все ссылки декоративные (целевые экраны не сняты), кроме «Мои бонусы» — ведёт на реальный второй as-is (см. ниже), поскольку этот пункт меню и есть переход на тот самый экран. Имя пользователя «Акименко Павел» и другой номер телефона в подвале (8 (4732) 62-21-71 вместо 8 (495) 232-06-00 на главной) — реальные данные со скриншота, оставлены как есть, расхождение в номере зафиксировано как открытый вопрос в комментарии к файлу.
ook-903-my-bonuses-mobile-asis.html — баланс («Доступно для списания» / «Ждут активации»), правила программы, история начисления/списания на 7 строк (6 полей на строку: Дата, Наименование, Начислено, Списано, Активация, Сгорание), кнопка «Показать ещё», блок «Остались вопросы?» с тремя способами связи. Реальные данные истории сохранены как есть, включая дублирующуюся строку «Hol. Бонусы за опросы на сайте» (+20 Б, два раза подряд 03.09.2026) — не дедублировано, показано как на сайте; это же наименование транзакции подтверждает сумму +20 Б за прохождение вопроса дня, использованную ранее в прототипах письма-рассылки. Обнаружено ещё одно расхождение реальных данных: заголовок страницы на скриншоте — «Личный кабинет», не «Мои бонусы» (без хлебных крошек/подзаголовка раздела), и номер телефона в блоке «На связи с вами» (+7 495 232-06-00) отличается от номера в подвале той же страницы (8 (4732) 62-21-71) — оба зафиксированы в комментарии к файлу как есть, без исправления вручную.
Кнопка «Назад» на экране «Мои бонусы» ведёт на экран меню (реальная, не декоративная связь — соответствует пункту меню «Мои бонусы», который на него и ведёт). Скриншоты и нарезанные части удалены после чтения, как принято для рабочих скретч-файлов в проекте.
По прямому запросу нижний мобильный таббар (Меню / Каталог / Избранное / Поиск / Корзина / Павел — общий компонент .mobile-tabbar из components/components.css, разметка копируется по файлам как есть) добавлен во все пять мобильных прототипов задачи, где его раньше не было: оба варианта хаба «Заработать бонусы» (список и плитки) и оба as-is экрана личного кабинета (меню, «Мои бонусы»). В шестом файле, главной с виджетом «Вопрос дня» (ook-903-question-widget-mobile-tobe.html), таббар уже был — это полная копия as-is главной страницы, где таббар — часть исходного скриншота.
Иконка «Павел» — во всех шести файлах теперь ведёт на ook-903-user-menu-mobile-asis.html (раньше была декоративной ссылкой href="#" — так и оставалась на самой главной, единственном файле, где таббар существовал до этой правки). На самом файле меню личного кабинета ссылка формально ведёт сама на себя — так и должно быть, раз таббар одинаковый везде: пользователь, уже находящийся в меню, по клику на «Павел» остаётся там же.
Остальные пункты таббара (Меню, Каталог, Избранное, Поиск, Корзина) — не переведены на реальные экраны ни в одном из файлов, декоративные href="#", активный по умолчанию — «Поиск» (унаследовано из as-is главной страницы, не пересчитывалось по смыслу для каждого конкретного экрана — открытый вопрос, стоит ли поэкранно менять активную вкладку, например на «Павел» для экранов личного кабинета).
По прямому запросу карточка на index.html для пары «меню пользователя» / «Мои бонусы» переведена на парную вёрстку «As is / To be» (общий паттерн .proto-versions, тот же, что у OOK-696) вместо плоского списка кнопок — остальные прототипы задачи (хаб, виджет), не имеющие as-is-пары, остались в обычном .proto-actions над этим блоком.
ook-903-user-menu-mobile-tobe.html — to-be поверх as-is меню, добавлен один пункт «Заработать бонусы» сразу под «Мои бонусы» (иконка-подарок, золотистый акцентный цвет), ведёт на хаб-плитки (ook-903-bonus-hub-tiles-mobile-tobe.html). Остальное не менялось; собственная ссылка «Мои бонусы» в этом файле теперь ведёт на to-be версию раздела (не as-is) — обе to-be версии личного кабинета согласованы между собой.
ook-903-my-bonuses-mobile-tobe.html — полная пересборка вёрстки по прямому запросу «можешь полностью переделать, чтобы он был более красивым и читаемым», тот же набор реальных данных, что и в as-is. Явный заголовок «Мои бонусы» вместо унаследованного общего «Личный кабинет». Под карточкой баланса — крупная золотая кнопка «Заработать бонусы» (по прямому запросу), тоже ведёт на хаб-плитки. Правила программы сжаты в одну строку вместо трёх. Главное изменение — каждая операция истории показана одной компактной строкой (кружок-иконка +/− цветом, название, дата и срок действия одной подписью, сумма справа) вместо карточки из 6 подписанных полей друг под другом; поля «Активация» и «Дата» у всех операций начисления совпадали — оставлена одна дата плюс срок действия там, где он есть. Ни одна операция и ни одно число не потеряны при пересборке.
Таббар переключён на to-be версии — по прямому запросу «эти два to be прототипа используй для таббаров»: иконка «Павел» во всех семи мобильных файлах задачи (было шесть, стало семь с добавлением двух to-be и без вычитания as-is) теперь ведёт на ook-903-user-menu-mobile-tobe.html, а не на as-is версию, как было в предыдущем раунде. Внутренние ссылки самих as-is экранов друг на друга (as-is меню → as-is «Мои бонусы», кнопка «Назад» на as-is «Мои бонусы» → as-is меню) не менялись — as-is остаётся самодостаточным снимком реальной страницы, ссылается только на другой as-is; на to-be версию из as-is не ссылаемся, чтобы не смешивать статусы одной и той же пары экранов.
Ссылка «Другие способы заработать» — по прямому запросу везде, где она встречалась (4 места: обе версии голосования «Это или Это», два экрана состояния экрана «Клад» в OOK-918), теперь ведёт на ook-903-bonus-hub-tiles-mobile-tobe.html (вариант 2, плитки), а не на ook-903-bonus-hub-mobile-tobe.html (вариант 1, список), как было. Обратные стрелки в шапках тех же экранов по-прежнему ведут на вариант 1 — в запросе фигурировала именно ссылка «Другие способы заработать», обратные стрелки не переименовывались и не трогались, хотя формально это то же самое смысловое место назначения; несогласованность зафиксирована как заметка, не исправлена самостоятельно за пределами того, что попросили.
Подсветка кликабельных зон (guided-flow) — по прямому запросу подключён во все 7 файлов задачи существующий общий механизм components/guided-flow.js (правило 11 базы знаний): клик мимо реального кликабельного элемента на секунду подсвечивает пульсирующей обводкой все элементы страницы с атрибутом data-flow-hotspot. Атрибут добавлен на: реальные переходы между экранами (плитки/строки хаба, ссылка «Заработать бонусы» в меню и на экране «Мои бонусы», пункт «Мои бонусы» в меню, обратные стрелки, виджет «Вопрос дня» на главной), иконку «Павел» в таббаре везде. Декоративные href="#" (остальные пункты меню, остальные 5 иконок таббара, футер, «Показать ещё», кнопки «Онлайн-чат»/телефон/E-mail в блоке «Остались вопросы») и ссылки на документацию внутри скрытых <template id="requirements-content"> сознательно не размечены.
По прямому запросу («список опросов сделай идентичным во всех задачах: OOK-834, OOK-903, OOK-917, OOK-918») создан новый файл ook-903-surveys-list-mobile-tobe.html — точная копия канонического списка, собранного в OOK-918 (см. её историю), со своим <title> и отдельным текстом в requirements-content, объясняющим, зачем список продублирован по файлам задач, а не оставлен только в OOK-918. Обе плитки «Вопрос дня», раньше ведшие с хаба «Заработать бонусы» (оба варианта — список и плитки) на ook-918-surveys-list-mobile-tobe.html, переключены на этот новый файл своей же задачи.
Из карточки типа «Опрос» в ook-903-surveys-list-mobile-tobe.html убран статус-бейдж «Активен» — та же правка, что и в остальных трёх файлах, см. историю OOK-918.
Список опросов. По прямому запросу («список опросов оставляем только в задаче OOK-903, везде ссылаемся на него») три из четырёх визуально идентичных копий списка (OOK-834, OOK-917, OOK-918) удалены — ook-903-surveys-list-mobile-tobe.html остаётся единственным файлом списка на весь раздел «Вопрос дня». Все переходы к списку из других задач (хлебные крошки и обратные ссылки в OOK-834/917/918) переключены на этот файл, комментарий к файлу (requirements-content) переписан — раньше объяснял, зачем список продублирован по 4 файлам, теперь объясняет, что он единственный.
Хаб «Заработать бонусы». По прямому запросу («удали прототип „Хаб «Заработать бонусы» — вариант 1: список»") файл ook-903-bonus-hub-mobile-tobe.html (первый набросок-список) удалён — ook-903-bonus-hub-tiles-mobile-tobe.html (плитки 2×2) остаётся единственной версией хаба. Обратные стрелки на экранах голосования «Это или Это» и «Клада» (OOK-917/918), раньше по недосмотру всё ещё указывавшие на удалённый вариант-список (см. round 20 — тогда несогласованность зафиксировали, но не исправили, так как просили только про ссылку «Другие способы заработать»), теперь тоже ведут на плитки — деться было некуда, старой цели у ссылок больше не существует. На index.html действие карточки «Хаб «Заработать бонусы» — вариант 1: список» удалено, оставлено одно действие «Хаб «Заработать бонусы»».
По прямому запросу — скриншот реальной страницы «Вопрос дня» (/Users/pavel/Desktop/список опросов.png, 750×7045, нарезан на 5 частей инструментом tools/slice_screenshot.py по правилу 6 базы знаний, прочитан целиком перед вёрсткой) показал, что боевая карточка опроса выглядит совсем иначе, чем в прототипе: мягкий сиренево-голубой градиентный фон, пока опрос активен, тёмная статус-пилюля с обратным отсчётом «Осталось N часов/N дня/N дней» вместо абсолютного времени, отдельная синяя пилюля бонуса «Б +20» справа сверху, крупный жирный заголовок вопроса, мелкая дата под заголовком; прошедшие опросы — белая карточка с серой обводкой и приглушённым серым текстом, статус «Завершён». У прошедшего опроса убрана стрелка-шеврон справа (вся карточка кликабельна).
ook-903-surveys-list-mobile-tobe.html пересобран под этот визуал для всех трёх типов карточек (на боевом сайте сейчас есть только «Опрос» — Голосование и Клад существуют только в прототипе). Статус «Вы уже участвовали» (его нет на скриншоте, реальный пользователь не голосовал ни в одном активном опросе) сделан по аналогии с завершённым — белый фон, серая обводка, но статус-пилюля зелёная «Вы участвовали», чтобы отличать «поучаствовал» от «пропустил». Тип-пилюля («Опрос»/«Голосование»/«Клад») размещена слева в верхней строке карточки, статус и бонус — справа, как единый узел бейджей.
H1 и заголовок раздела приведены к боевому названию «Вопрос дня» — раньше топбар/крошки этого файла назывались «Вечерние опросы» (внутреннее рабочее название прототипа, отличное от пользовательского текста на сайте — см. историю OOK-834, где зафиксировано «на сайте — Вопрос дня»). Также добавлен явный H1 «Вопрос дня» на странице (раньше был только текст в шапке и интро без заголовка) и обновлён интро-текст, короче, по образцу боевого. Открытый вопрос: хлебные крошки, ведущие сюда с экранов опроса/голосования/«Клада» (OOK-834/917/918), всё ещё используют текст «Вечерние опросы» — решение о переименовании по всему разделу не принято, массово не исправлено.
По прямому запросу («доработай таббар... при клике по иконке «Поиск» открывался прототип «Главная с виджетом «Вопрос дня» — есть активный вопрос»») декоративная ссылка href="#" у пункта «Поиск» заменена на ook-903-question-widget-mobile-tobe.html с data-flow-hotspot — во всех семи мобильных файлах задачи (оба хаба нет, остался один — хаб-плитки, оба «Мои бонусы», оба меню личного кабинета, список опросов, сам файл главной с виджетом). На самом файле-цели (ook-903-question-widget-mobile-tobe.html) ссылка ведёт сама на себя — тот же приём, что уже применён для иконки «Павел» на файле меню личного кабинета: пользователь, уже находящийся на главной с виджетом, по клику на «Поиск» остаётся там же.
По прямому запросу («сделай там карусель из трёх активных опросов у пользователя в порядке, как в списке опросов: голосование, клад, Опрос... визуально оформить немного по-разному для каждого типа, чтобы смотрелось повеселее») ook-903-question-widget-mobile-tobe.html вместо одной синей карточки «Вопрос дня» показывает три карточки подряд — Голосование → Клад → Опрос (тот же порядок, что и в общем списке опросов), горизонтальная прокрутка со scroll-snap (карточка почти на всю ширину экрана, край следующей чуть виден) и точки-индикаторы под каруселью. Каждая карточка ведёт на свой реальный экран: ook-917-pair-choice-kettles-mobile-tobe.html, ook-918-treasure-cards-mobile-tobe.html, ook-834-survey-mobile.html.
Три разных цвета — по запросу «сделать повеселее». Опрос — синий (не менялся), Голосование — оранжево-золотой с чайником 🫖, Клад — фиолетовый с подарком 🎁 (оба цвета перекликаются с пилюлями типов в общем списке опросов); у каждой карточки крупный полупрозрачный эмодзи-«водяной знак» в углу, чисто декоративный.
Пойманный и исправленный баг при разработке: JS, подсвечивающий активную точку при скролле, изначально сравнивал scrollLeft карусели с offsetLeft карточек — но у .qday-carousel нет position: relative, поэтому offsetLeft детей считался от более дальнего позиционированного предка, а не от самой карусели, и число не совпадало с системой координат scrollLeft. На глаз в статике различия почти не было видно, баг проявился только при программной прокрутке через Playwright (симуляция свайпа) — точка показывала на одну карточку раньше, чем видно на экране. Исправлено на сравнение через getBoundingClientRect() (не зависит от того, кто у элемента offsetParent); после фикса все три позиции проверены и совпадают с видимой карточкой.
Размер уменьшен — по прямому запросу («доминирует на главной, должен быть заметно меньше главного баннера»). Ширина карточки — 62% экрана вместо 86%, паддинги/шрифты/бонус-бейдж/кнопка уменьшены пропорционально (вопрос — 13px вместо 18px, бейдж — 16px вместо 30px). Итоговая высота виджета теперь заметно ниже hero-баннера промо-акции (у него min-height: 160px) — карусель явно второстепенный элемент, а не доминирующий.
Добавлена 4-я плитка «Все способы заработать бонусы» — по прямому запросу, последней в карусели, ведёт на ook-903-bonus-hub-tiles-mobile-tobe.html (единственный оставшийся вариант хаба). В отличие от трёх игровых карточек — нейтральный тёмно-сине-серый цвет и без бонус-бейджа с суммой (это не конкретная активность с конкретной наградой, а точка входа «посмотреть остальное»), эмодзи-компас 🧭.
Отступы по краям — ещё один пойманный баг вёрстки. Отступы карусели изначально были заданы через padding на самом скроллящемся контейнере — в Chromium/WebKit это известная особенность: padding в начале (inline-start) скроллящегося flex-контейнера не рендерится как видимый отступ (виден только конечный), из-за чего первая карточка «прилипала» к левому краю экрана при загрузке, хотя в коде отступ был явно прописан. Исправлено: вместо padding — два невидимых flex-спейсера по краям списка карточек (по 16px), дающих реально видимый одинаковый отступ с обеих сторон.
Ещё один пойманный баг при доп. проверке добавленной 4-й плитки: эвристика активной точки («ближайшая к левому краю карточка») давала неверный результат на последней позиции — при упоре прокрутки в максимум (scrollLeft = maxScrollLeft) снап-позиция последней карточки физически недостижима (мешает хвостовой спейсер), и по «ближайшему краю» с небольшим отрывом побеждала предпоследняя карточка (135px против 139px), хотя на экране почти целиком видна последняя. Заменено на более надёжную эвристику «наибольшая видимая площадь пересечения с viewport» — она корректно обрабатывает и обычные снап-позиции, и этот краевой случай; после фикса проверены все 4 позиции карусели, включая упор в конец.
По прямому запросу («вопрос дня "продаём" как отдельный заголовок, под которым ровно тот же самый виджет с главной, но уже без плитки «Все способы заработать» — цель переиспользовать виджет») в ook-903-bonus-hub-tiles-mobile-tobe.html под всей сеткой плиток 2×2 добавлен заголовок «Вопрос дня» и точная копия карусели с главной (ook-903-question-widget-mobile-tobe.html): Голосование → Клад → Опрос, те же цвета/эмодзи/точки-индикаторы, тот же JS — без четвёртой плитки-хаба (она здесь не нужна, мы уже внутри хаба). Первая плитка «Вопрос дня» в самой сетке 2×2 не убрана — она остаётся компактной сводной точкой входа, карусель внизу добавляет более подробную витрину с превью каждого активного опроса по отдельности; осознанное дублирование входа в один и тот же раздел, задокументировано в комментарии к файлу.
Новая ветка работы над письмом-рассылкой — не продолжение вариантов А–Д из более ранних раундов этой задачи (round 13–15 выше): те три файла as-is/А/Б/В и оба радикальных Г/Д были удалены вместе с переименованием OOK-891→OOK-903, но не потому что признаны плохими — просто ветка не была доведена до конца. Пользователь дал детальный бриф по контенту и попросил собрать «Вариант 1» с нуля — новый файл ook-903-email-variant-1-tobe.html, подразумевающий, что дальше появятся другие пронумерованные варианты той же идеи.
Идея — личное письмо от конкретного человека, не рассылка. Отправитель по брифу — «Анастасия из Холодильник.ру» (anastasia.armeeva@holodilnik.ru), тема и прехедер оформлены как настоящее личное сообщение. Поскольку From/Subject/Preheader — метаданные письма, а не часть верстаемого тела, наверху страницы добавлен блок «Как выглядит во входящих» — имитация строки письма в инбоксе (аватар-инициал, имя+e-mail отправителя, тема, прехедер), иначе эти пункты брифа остались бы невидимыми в самом прототипе.
Тело письма без фирменного баннера-шапки — по духу «личного письма»: нет крупного цветного заголовка с логотипом, как в письме OOK-834 (ook-834-email.html) или в удалённых ранних вариантах этой же задачи. Вместо этого — маленькая подпись «ХОЛОДИЛЬНИК.РУ» мелким текстом в углу (на неё повешена пасхалка с требованиями). Кнопка «Ответить Насте» — настоящая кнопка с заливкой, а не просто ссылка: в round 15 истории письма зафиксирован фидбэк «визуально бедно» на полностью текстовый вариант Д, этот вариант сочетает личный тон с явным CTA.
Блок «про меня» — единственный цветной акцент, тёплый жёлто-персиковый градиент (не фирменный синий — сознательно другой оттенок). Кружок с лицом — эмодзи 🙂 (реального фото сотрудника нет). Эмодзи-реакции 👎/👍 кликабельны и по клику показывают текст благодарности — чисто демонстрационная интерактивность, ничего никуда не отправляется. Кнопка «Написать Насте лично» — настоящая mailto:-ссылка, как и просили («ссылка replyto»).
Подвал переработан и сокращён — по прямому запросу («не наш стандартный, а минимальный, убрать всю казёнщину»). Вместо юридического текста письма OOK-834 («Это письмо отправлено, потому что вы подписаны на рассылку… Отписаться · Настройки уведомлений») — одна тёплая строка от первого лица с единственной обязательной ссылкой отписки; отдельную ссылку «Настройки уведомлений» сочли частью той же «казёнщины» и не оставили.
Открытый вопрос: кнопка «Ответить Насте» ведёт на ook-834-survey-mobile.html для демонстрации живого клика на реальный прототип — текст вопроса там («Какой холодильник вам ближе?») не совпадает с вопросом в письме («Что чаще всего забываете выключить дома?»); расхождение оставлено осознанно, задокументировано в комментарии к файлу.
По прямому запросу («поправь письмо, используя оформление из дизайн системы») жёлто-оранжевый акцент письма (аватарка во «входящих», круглое лицо и фон блока «про меня», весь текст на цветном фоне), изначально придуманный на глаз (условные #ffcf7a/#ff9f4a/#6b4c00), заменён на реальную палитру System/Attention из библиотеки компонентов (см. её обновление — карточка «Библиотека компонентов» на index.html, components.css): фон блока и градиенты аватарок — тона Attention (10→20 для фона, Primary→Deep для круглых элементов), текст на цветном фоне — --color-attention-deep. Это то же сочетание «тонированный фон + текст Deep», что уже используется в кнопке .btn-attention-light библиотеки, — переиспользование уже проверенной пары, а не новое сочетание на глаз. Кнопка «Ответить Насте» намеренно осталась синей (.btn-primary = ДС «Accent») — Attention семантически означает предупреждение, а не приглашение к приятному действию.
Второй пронумерованный вариант письма-рассылки в той же серии — новый файл ook-903-email-variant-2-tobe.html, по прямому детальному брифу пользователя («тоже по дизайн системе»). В отличие от «варианта 1» (личное письмо от Насти, без шапки, тёплый жёлто-оранжевый акцент) — здесь противоположная гипотеза: обычное, честно узнаваемое сервисное уведомление, с фирменной шапкой, нейтральной статистикой и обычным юридическим подвалом, без персонажа.
Отправитель, тема и аватар — сервисные, без персоны. «Бонусы каждый день (Холодильник.ру)» / bonuses@holodilnik.ru вместо имени сотрудника; тема «Новых вопросов открыто: один (1)» и прехедер «Вам доступен новый вопрос» — сухие, информационные. Аватар во «входящих» — иконка подарка 🎁 на фирменном синем фоне, а не эмодзи-лицо.
Фирменная шапка с лого — тот же паттерн, что уже используется в письме OOK-834 (ook-834-email.html): цветной хедер (--color-header-bg) с текстовым лого, пасхалка с требованиями повешена на неё — в противовес маленькой подписи в углу у варианта 1.
Блок псевдо-статистики — 4 цифры по брифу (вопросов на сайте: 20, вопросов с участием получателя: 10, среднее число участников: 938, активных опросов: 7) в нейтральной сетке 2×2 на --color-surface-muted, без цветных акцентов — сознательно спокойнее эмоционального блока «про меня» из варианта 1. Кнопка «Посмотреть активные опросы» ведёт на общий список опросов (ook-903-surveys-list-mobile-tobe.html, «раздел в целом», как просили), оформлена обводкой (.btn-secondary), а не вторым синим CTA, чтобы в письме не было двух одинаково ярких кнопок подряд. «Полные правила акции» — декоративная текстовая ссылка, реальной страницы правил в прототипе нет.
Подвал — обычный, юридический — по прямому запросу («подвал обычный», в противовес переработанному минимальному в варианте 1) — дословно тот же текст и структура, что в письме OOK-834.
Цвета — из библиотеки компонентов, без придуманных на глаз оттенков с самого начала (в отличие от варианта 1, где сперва были кастомные hex, а потом их привели к ДС отдельной правкой): шапка — --color-header-bg (Sky/Deep), основная кнопка и цифры статистики — --color-primary (ДС «Accent»), фон карточек статистики — --color-surface-muted.
По прямому запросу («выгрузил в PDF одну из наших реальных рассылок... забери оттуда информацию из подвала и вставь в оба прототипа письма») пользователь прислал PDF-выгрузку настоящего письма holodilnik.ru «🎁 +500 бонусов» (переслано на свою же почту, видно в Gmail). Реальный подвал — ссылка «Политика обработки персональных данных», строка «Вы получите это письмо, потому что подписались на нашу рассылку.», ссылка отписки «нажмите сюда», копирайт «©2003–2026» и обязательная по закону о рекламе строка «Реклама. Рекламодатель ООО «ХОЛОДИЛЬНИК.РУ»» — этой рекламной маркировки не было ни в одном из прежних, придуманных на глаз подвалов проекта (ни в этом письме, ни в OOK-834).
В ook-903-email-variant-2-tobe.html (подвал «обычный») этот текст вставлен дословно и полностью, заменив собой ранее придуманные «Отписаться от опросов» / «Настройки уведомлений» (строка 1591 выше — устаревшее описание, оставлено как есть по правилу «история не переписывается задним числом», актуальное состояние см. в комментарии самого файла). В ook-903-email-variant-1-tobe.html (подвал «минимальный») та же обязательная информация вставлена под тёплой личной подписью Насти — визуально компактнее и мельче шрифтом, чем в варианте 2, но без потери юридической точности; сама эта юридическая часть не была затронута прошлым запросом «убрать казёнщину» — та правка касалась тона и лишних необязательных ссылок, а не фактической точности обязательных пунктов.
По прямому запросу («идём в задачу OOK-903. Удали прототипы писем — Письмо — вариант 1 / вариант 2») файлы ook-903-email-variant-1-tobe.html и ook-903-email-variant-2-tobe.html удалены вместе с их action-group ссылками на карточке задачи. Без объяснения причины — просто прямое указание удалить; вся ветка работы над письмом (обе итерации, интеграция дизайн-системы в них, подвал с реальной рассылки) остаётся в истории задачи выше как есть.
По прямому запросу («переделай прототип Хаб «Заработать бонусы». Делай по дизайн системе» + детальные уточнения по 6 механикам) файл ook-903-bonus-hub-tiles-mobile-tobe.html пересобран: было 5 позиций с цветами, придуманными на глаз (синий/фиолетовый/розовый/зелёный), не хватало «Авторизации» вообще. Теперь ровно 6 механик по брифу пользователя, каждая — своя строка бизнес-условия:
Цвета — три новых токена библиотеки компонентов (--color-violet/--color-flamingo/--color-mint + -deep), добавлены именно под эту задачу. В первом заходе интеграции ДС (см. историю выше) эти вторичные палитры были сознательно отложены — «нет ролей в UI, которые могли бы их использовать»; хаб с 6 разными механиками и стал той ролью. HEX сняты тем же способом, что и остальные цвета проекта, — пиксельно из Цвета.png. У них нет закреплённой семантики (в отличие от Success/Danger/Attention) — использованы для декоративного различения карточек одного уровня важности. Состояние «уже выполнено» (Авторизация, показана как выполненная — демо-пользователь Павел уже авторизован везде по остальным прототипам) — везде системный --color-success, это его прямая семантика, не декоративный выбор. Витрина библиотеки компонентов (components/library.html) дополнена образцами новых токенов.
По прямому запросу («убери внизу виджет «Вопрос дня». Вверху сделай красивую притягательную картинку, с балансом и призывом получить ещё бонусы — сейчас баланс слишком крупно, здесь главное — призыв заработать бонусы») карусель «Вопрос дня» под сеткой плиток (переиспользованный виджет с главной, добавленный в одном из более ранних раундов этой же задачи) убрана целиком — HTML, CSS и JS точек-индикаторов; плитка «Вопрос дня» в сетке 2×2 остаётся единственной точкой входа в эту механику на этом экране.
Верхний блок баланса пересобран: раньше самым крупным элементом (32px) была сама цифра баланса, а мелкий служебный текст снизу («Списать бонусы можно при оформлении заказа») не давал никакого повода зайти в раздел — сама возможность заработать в этом блоке не упоминалась вообще. Порядок значимости перевёрнут: баланс — компактный полупрозрачный бейдж сверху («💰 Баланс: 3 150 Б»), самое крупное и заметное — призывный заголовок «Зарабатывайте ещё больше бонусов каждый день!». Фон — фирменный градиент дизайн-системы --gradient-sky-1 (сняты пиксельно ещё в первом заходе интеграции ДС, но до этой правки нигде не применялись), декоративные полупрозрачные эмодзи 🎁/✨ по углам — для «красивой картинки», не несут информации.
Заполнить.
Заполнить.
Заполнить.
Заполнить.
Заполнить.
Прикрепить ссылку/задачу на макеты
OOK-917Внутренний журнал изменений по датам — не для дизайнера/аналитика, но полезен при дальнейших доработках, чтобы понимать, что и почему менялось. Актуальные требования — в соседнем документе «Требования к задаче».
Прототип нового типа вопроса дня «Это или Это» разрабатывался как условная часть OOK-903 «Вопрос дня. Точки входа» (см. её историю, round 4, где зафиксирована оговорка «если задачу заведут отдельно, файл стоит перенести»). Ветка разрослась в самостоятельную работу с собственными раундами правок — по запросу пользователя выделена в отдельную задачу OOK-917 «Вопрос дня. Голосования». Файл переименован из ook-903-pair-choice-mobile-tobe.html в ook-917-pair-choice-mobile-tobe.html, ссылки и requirements-комментарий в нём обновлены на новый номер задачи. Раунды 1–7 ниже — перенесённая без изменений по сути история из OOK-903 (там она была раундами 4–10), только перенумерована и переведена на новое имя файла.
Собран отдельный набросок — ook-917-pair-choice-mobile-tobe.html: новый формат самого вопроса дня (сейчас на сайте только текстовый вопрос с вариантами-ссылками, OOK-834) — пользователь выбирает одну из двух картинок, всего 5 пар подряд, строго последовательно (следующая пара показывается только после ответа на текущую). Клик по картинке сразу засчитывается выбором — без отдельной кнопки подтверждения, тот же принцип, что и в обычном вопросе дня. Над парой — прогресс-бар (заполняется на 20% за пару) и акцентная подпись «Осталось немного для получения бонуса» — по прямому запросу пользователя. После 5-й пары — экран с честной формулировкой «будут начислены бонусы» (не факт, а обещание — тот же принцип формулировок, что в обычном вопросе дня), CTA ведёт в хаб «Заработать бонусы» OOK-903.
Картинки — цветные плейсхолдеры с line-art иконкой, реальных фото для этого формата ещё нет. Открытый вопрос, зафиксированный в комментарии к файлу: акцентная подпись «Осталось немного» показана статично уже на первой из пяти пар, что может читаться как небольшое преувеличение — оставлено буквально по тексту запроса, но стоит решить осознанно (сделать подпись зависимой от прогресса или нет).
Три правки пользователя за один раунд. (1) Прогресс-бар перенесён — теперь под вопросом текущей пары, над самими картинками (раньше стоял выше всего, над заголовком). (2) Добавлена завлекаловка про бонус — тот же компонент .survey-bonus-tag, что и в обычном вопросе дня, с текстом «+50 бонусов ХОЛОДИЛЬНИК.РУ — пройдите все 5 пар» (не дословно текст обычного вопроса — там бонус даётся за один клик, здесь за прохождение всех 5 пар, поэтому формулировка адаптирована, а не скопирована один в один). (3) Экран теперь использует шапку (поиск + хлебные крошки «Вечерние опросы / Вопрос дня») и подвал-аккордеон, скопированные как есть из ook-834-survey-mobile.html, плюс тот же стиль статус-бейджа и заголовка вопроса (h1.survey-question) — по прямому запросу, чтобы новый тип вопроса выглядел частью того же раздела, а не отдельным изолированным экраном. Модалки входа/вступления в ПЛ и демо-переключатель персон из OOK-834 сознательно не перенесены — не были частью просьбы, увеличивали бы экран без необходимости.
Четыре точечные правки. (1) «Экран прыгает» — все 5 вопросов пар были разной длины, часть переносилась на вторую строку, из-за чего высота экрана скакала между парами. Все 5 текстов укорочены и выровнены по длине образца, уже проверенного в реальном продукте на этой же вёрстке — «Какой холодильник вам ближе?» (28 символов, OOK-834) — новые тексты не длиннее. Playwright не был подключён в исходной сессии, точный визуальный замер был недоступен, длина подобрана по числу символов. (2) Прогресс-бар сделан заметно крупнее — высота 8px → 16px, заливка градиентом вместо плоского цвета, добавлена рамка контейнера. (3) Бонус-тег («замануха про бонусы» из прошлого раунда) увеличен — крупнее шрифт и иконка, больше отступы, добавлена рамка, фон чуть насыщеннее. (4) Формулировка бонус-тега «пройдите все 5 пар» (по фидбэку — криво) заменена на «за прохождение» — по образцу уже существующего в обычном вопросе дня текста «за участие», короче и не дублирует то, что уже показывает прогресс-бар.
Две правки. (1) Слово «пар/пары» полностью убрано из пользовательского текста: подпись прогресса «Пара X из 5» заменена на «Вопрос X из 5» (в разметке и в JS-шаблоне) — заодно точнее по сути (пользователь отвечает на вопросы, не разглядывает пары), заголовок финального экрана «все 5 пар пройдены» тоже переписан заново (см. пункт 2). Слово осталось только в собственном комментарии к файлу (техническое описание механики для разработки, не то, что видит пользователь).
(2) Финальный экран пересобран: акцент смещён с факта прохождения на сам бонус, по прямому запросу — «в конце акцент на полученных бонусах, а не на "Пройдено"». Вместо заголовка про завершение — крупная цифра «+50 Б», под ней «Уже ваши!» (по духу предложенного «50 бонусов твои!», но на «вы», как везде на сайте), а факт прохождения понижен до мелкой серой подписи сверху. Иконка сменена с зелёной галочки (в вопросе дня она везде означает «подтверждено/готово» — здесь была бы путаница с этим же знаком) на золотую звезду (однозначно про награду). При этом сознательно сохранена честная формулировка про начисление — «Начислим их в течение нескольких минут», а не «начислены» — по тому же принципу, что уже закреплён для обычного вопроса дня: бонус не зачисляется мгновенно, интерфейс не должен утверждать факт. «Уже ваши» в заголовке — про то, что бонус гарантированно заработан самим фактом прохождения, а не про обновление баланса; это разграничение явно прописано в комментарии к файлу.
Существенная смена механики по прямому запросу пользователя: раньше это были 5 независимых вопросов с собственной парой вариантов у каждого; теперь — один вопрос на всю сессию («Какой цвет холодильника вам ближе?»), а меняются только сами варианты — по образцу уличных роликов в шортсах «Это или Это». Логика: пользователь выбирает между двумя вариантами (например, «Белый» / «Чёрный»); выбранный остаётся на экране слева и получает подпись «Лидирует», проигравший выбывает насовсем и его место справа занимает новый, ещё не показанный вариант («Зелёный», затем «Красный» и т.д.); так 5 раундов подряд на 6 вариантов всего (первая пара + 4 новых претендента). Финальный экран показывает не только бонус, но и сам вариант-победитель — цветной кружок и его название, как «объявление победителя» в конце ролика — прямо по запросу «подсвечиваем цвет-победитель».
Демо-тема осталась прежней (цвет холодильника), но теперь это не одна из пяти разных тем, а единственная сквозная — 6 демо-цветов: белый, чёрный, серебристый, красный, бежевый, синий. Раз варианты — буквально цвета, картинки-плейсхолдеры с line-art иконками из предыдущей версии убраны — карточки показывают просто цветной кружок без иконки, это честнее (иконка была условностью «представим, что тут фото», а для цвета сам цвет и есть содержание, подменять нечего). Прогресс-бар теперь считает раунды («Раунд X из 5»), а не вопросы — старая подпись «Вопрос X из 5» перестала быть точной, раз вопрос один.
Комментарий к файлу переписан заново (не продолжен построчно) — раньше он описывал старую, уже неактуальную механику 5 независимых вопросов; накопленная построчная история прошлых раундов остаётся здесь, в истории задачи, а сам файл описывает только текущее состояние — по духу правила 4 (короткие комментарии по актуальному экрану, история — отдельно).
Две точечные правки финального экрана. (1) Декоративная звезда над блоком бонуса убрана — цвет-победитель наверху экрана и крупная цифра «+50 Б» уже несут достаточный акцент, звезда была лишней. (2) Под основной кнопкой «Другие способы заработать» добавлена вторая кнопка «Поделиться» — вторичным стилем (secondary), явно не конкурирует с основным CTA, как и было явно оговорено в запросе. Расчёт на виральность самой механики (интересно поделиться, каким цветом холодильника «наградили» тебя после 5 раундов) — кнопка декоративная, реального шеринга нет.
Баг по фидбэку: победитель раунда всегда рендерился в левую позицию, независимо от того, с какой стороны его реально выбрали — если пользователь тапал по правой карточке, на следующем раунде она визуально «перепрыгивала» налево, а новый претендент появлялся справа. Исправлено: теперь отслеживается сторона победителя (championSide), и после раунда меняется содержимое только проигравшей стороны — выбранная карточка остаётся на месте, где по ней тапнули. Подпись «Лидирует» теперь тоже показывается на фактической стороне победителя, а не всегда слева. Логика проверена симуляцией нескольких последовательностей выбора (всё время «направо», и смешанная «налево-направо-налево-налево-направо») — во всех прогонах выбранная сторона не меняет содержимое на следующем раунде.
Три правки по прямому запросу пользователя. (1) Итоговая статистика по всем пользователям — на финальном экране, между «Начислим их в течение нескольких минут» и кнопкой «Другие способы заработать», добавлен блок со всеми 6 вариантами и процентом каждого (отсортированы по убыванию), свой выбор подсвечен акцентным цветом и подписью «Ваш выбор». Цифры — фиксированный демо-срез (VOTE_STATS в скрипте), не пересчитываются по реальным ответам. Открытый вопрос к продукту, зафиксированный в комментарии к файлу: считать агрегат по итоговому цвету-победителю каждого пользователя (как сделано здесь) или по каждой отдельной паре раундов — при 6 вариантах и разных путях по раундам у разных пользователей это разные способы посчитать одну и ту же статистику, и выбор между ними — решение бизнес-уровня.
(2) Баг прогресс-бара: бар был предзаполнен на 20% уже на первом раунде, до какого-либо ответа — по факту показывал текущий раунд, а не пройденный. Исправлено: заливка теперь считается по числу завершённых раундов (round - 1), при открытии экрана бар пустой, закрашивается только после ответа. Логика проверена симуляцией полного прохождения (5 раундов) — на старте 0%, после каждого ответа +20%.
(3) Общий список вопросов и голосований — собран новый прототип ook-917-surveys-list-mobile-tobe.html, to-be поверх as-is списка OOK-834 (ook-834-surveys-list-mobile.html): голосования «Это или Это» показаны в том же списке «Вечерние опросы» вперемешку с обычными вопросами дня, а не в отдельном разделе — по прямому запросу «это общий раздел, просто часть вопросов — это вопросы, а часть — голосовалки». Карточка-голосование отличается пилюлей «Голосование» рядом со статусом и формулировкой бонуса «за прохождение» (как на самом экране голосования) — у обычных вопросов эти элементы не менялись. В списке показаны оба статуса для обоих типов (активно/уже участвовал), плюс один завершённый обычный вопрос — для демонстрации, что статусы работают одинаково для обоих типов. Брейдкрамб на экране голосования теперь ведёт на этот новый общий список, а не на as-is список OOK-834.
Открытый вопрос, зафиксированный в комментарии к новому файлу: у экрана голосования пока нет состояния «уже проголосовали» с показом ранее выбранного варианта (в отличие от обычного вопроса дня, где такое состояние есть через ?state=answered) — карточка «Вы уже участвовали» для голосования в списке ведёт на тот же стартовый экран, а не на итоговый экран с результатом; полноценное состояние «просмотр своего прошлого голосования» не сделано.
Две правки по фидбэку. (1) В общем списке (ook-917-surveys-list-mobile-tobe.html) карточки обычных вопросов дня были без явной пилюли-типа — «Голосование» подписано, а «Опрос» подразумевался умолчанием, что не симметрично. Добавлена пилюля «Опрос» (синяя) для всех карточек-вопросов, наравне с «Голосование» (золотая) — теперь тип явно назван у каждой карточки, а не только у нового формата.
(2) Закрыт открытый вопрос из round 8 — у экрана голосования (ook-917-pair-choice-mobile-tobe.html) появилось состояние «уже проголосовали» через ?state=answered, по образцу того же параметра у обычного вопроса дня OOK-834. Вместо игры заново сразу показывается итоговый экран с демо-результатом прошлой сессии («Чёрный», раунды не разыгрываются) и статистикой по всем пользователям — тем же блоком, что и при свежем прохождении. Текст про бонус переведён в прошедшее время («Бонус начислен» / «Зачислен на баланс») вместо «Уже ваши! Начислим в течение нескольких минут» — по прошествии дня (карточка в списке показывает «Вчера») асинхронное начисление уже точно завершилось, честная формулировка про задержку тут неприменима и была бы неточной в другую сторону. Карточка «Вы уже участвовали» для голосования в общем списке обновлена — теперь ведёт на ?state=answered, а не на пустой стартовый экран, как раньше.
Поведение проверено симуляцией: бейдж, время, заголовок/подпись бонуса и итоговый цвет-победитель принимают ожидаемые значения при ?state=answered, экран игры скрыт, статистика рендерится с подсветкой «Ваш выбор» на нужном варианте.
По прямому запросу собрана вторая версия того же экрана «Это или Это» с другой темой — не абстрактный цвет, а настоящие товары. Перед тем как встраивать картинки, уточнил у пользователя, откуда их взять — генерировать или подбирать по ссылкам самостоятельно не стал (нет инструмента поиска/генерации изображений, а угадывать рабочие ссылки на конкретные фото ненадёжно и не соответствует конвенции проекта про нейтральные плейсхолдеры без стороннего контента). Пользователь прислал 6 прямых ссылок на CDN holod.ru/pics/... и одну реальную ссылку на карточку товара для итогов голосования.
Собран новый файл — ook-917-pair-choice-kettles-mobile-tobe.html: полная копия механики раундов, прогресс-бара, статус-бейджей и состояния «уже проголосовали» из исходного файла про цвета (без изменений по сути, отличается только контентом вариантов). Вопрос — «Выбираем самый красивый чайник» (дословно по тексту запроса, не в форме вопроса с знаком «?», как раньше). Каждый вариант — реальное фото чайника (внешний <img src> прямо на CDN холодильник.ру, не локальная копия) плюс короткая описательная подпись, придуманная по внешнему виду на фото (например, «Цветочный», «Стеклянный красный», «Туристический») — не официальные названия товаров. Каждое фото просмотрено (скачано во временную папку и открыто) перед тем, как писать подписи, чтобы они соответствовали содержимому карточек, а не были случайными.
Итоговая статистика — с миниатюрами-ссылками, по отдельному прямому запросу: строка статистики вместо цветного кружка показывает квадратную миниатюру фото чайника, и миниатюра, и текст названия — кликабельная ссылка на карточку товара. По прямому указанию пользователя («зашей для всех одну ссылку, прям как есть») на все 6 миниатюр стоит одна и та же настоящая ссылка (.../small_domestic/teapots/brayer/1083br_ye_2200_vt_1_7_l/), а не индивидуальные ссылки каждого товара — осознанное упрощение прототипа по прямой просьбе, зафиксировано в комментарии к файлу как открытый вопрос для реального продукта (там у каждого варианта должна быть своя карточка). Ссылки открываются в новой вкладке (target="_blank"), чтобы клик по демонстрационной статистике не уводил пользователя с прототипа совсем.
Проценты демо-статистики подобраны заново для нового набора вариантов (сумма 100%, от 30% у «Цветочного» до 6% у «С яркой ручкой») — та же условность, что и в версии с цветами, случайный правдоподобный срез, не реальные данные. Победитель на финальном экране и в состоянии ?state=answered теперь показывает не цветной кружок, а квадратную карточку с фото (крупнее, чем миниатюры статистики — 120×130px, чтобы фото читалось). Поведение проверено скриншотами Playwright: все 6 фото загружаются и видны на экране раундов, полное прохождение 5 раундов подряд корректно показывает финальную карточку-победителя с фото, статистика с миниатюрами и рабочими ссылками на реальный товар, состояние ?state=answered тоже показывает фото прошлого выбора.
Фидбэк: «убери названия для чайников — их никто добавлять не будет» — то есть в реальном продукте никто не будет вручную писать короткую подпись под каждым SKU в блоке статистики (в отличие от прототипа, где подписи придуманы на глаз по фото). Убраны и текст названия, и ссылка-подпись из каждой строки статистики — остаётся только кликабельная миниатюра (по-прежнему ведёт на карточку товара) и процент. Подпись «Ваш выбор» текстом тоже убрана вместе с названием; вместо неё своя строка отмечена акцентной рамкой вокруг миниатюры (тем же приёмом, что уже используется у фото победителя выше на этом же экране) и подсвеченными цветом бар/процент — тот же смысл, без текста.
Правка ограничена явно названным пользователем местом — «из результатов голосования» (блок статистики). Подписи под карточками во время самих раундов и имя чайника-победителя на финальном экране не трогали — та же логика («никто не будет добавлять названия») в равной мере применима и к ним, но это отдельное решение, не запрошенное в этой правке; зафиксировано в комментарии к файлу как открытый вопрос на будущее.
Проверено скриншотом Playwright после полного прохождения 5 раундов: строки статистики показывают только фото и процент, своя строка подсвечена рамкой и цветом без текста.
По прямому запросу пользователя (готовит кроссзадачное демо целевого результата по всем задачам направления «Вопрос дня») нижний таббар добавлен в три файла этой задачи: ook-917-pair-choice-mobile-tobe.html, ook-917-pair-choice-kettles-mobile-tobe.html, ook-917-surveys-list-mobile-tobe.html — та же разметка .mobile-tabbar, что уже используется в OOK-903/918, иконка «Павел» ведёт на to-be меню личного кабинета (ook-903-user-menu-mobile-tobe.html).
«Другие способы заработать» в обоих файлах голосования теперь ведёт на ook-903-bonus-hub-tiles-mobile-tobe.html вместо варианта-списка.
Убрано слово «Активно» — по прямому запросу («в списке опросов убери слово „Активно“, остальные метки оставляем») из статус-бейджа карточки-голосования в ook-917-surveys-list-mobile-tobe.html — раньше рядом с пилюлей «Голосование» стоял ещё и отдельный бейдж «Активно», теперь для активной голосовалки статус не показывается вообще (только тип и время), а бейджи «Вы уже участвовали» на других карточках того же списка не трогали.
Подсветка кликабельных зон (guided-flow) — по прямому запросу подключён во все 3 файла задачи существующий общий механизм components/guided-flow.js. Атрибутом data-flow-hotspot отмечены: обратная стрелка, хлебная крошка «Вечерние опросы», сами кнопки-варианты голосования (#pair-card-left/#pair-card-right — основная механика экрана), карточки опросов в общем списке, кнопка «Другие способы заработать», иконка «Павел» в таббаре. В варианте с чайниками дополнительно размечена миниатюра-ссылка на карточку товара в итоговой статистике (генерируется в рантайме через renderStats() — атрибут добавлен прямо в шаблон строки, а не только в статичную разметку). Декоративные «#»-ссылки (остальные пункты таббара, кнопка «Поделиться», ссылки на документацию внутри скрытых <template>) не размечены.
Ссылка «Голосование» — по прямому запросу обе карточки-голосования (активная и «уже участвовали») в ook-917-surveys-list-mobile-tobe.html теперь ведут на ook-917-pair-choice-kettles-mobile-tobe.html («вариант с реальными товарами: чайники»), а не на версию с цветом холодильника, как было. Заголовок карточки в списке обновлён на «Выбираем самый красивый чайник», чтобы соответствовать содержимому целевого экрана.
Список сделан идентичным во всех четырёх задачах (по прямому запросу) — стили и разметка ook-917-surveys-list-mobile-tobe.html приведены к каноническому виду, общему с OOK-834/903/918 (см. их истории), собственные <title> и текст requirements-content сохранены/переписаны под контекст именно этой задачи.
Из карточки типа «Опрос» в ook-917-surveys-list-mobile-tobe.html убран статус-бейдж «Активен» — та же правка, что и в остальных трёх файлах, см. историю OOK-918.
Своя копия списка опросов удалена. По прямому запросу («список опросов оставляем только в задаче OOK-903, везде ссылаемся на него») файл ook-917-surveys-list-mobile-tobe.html удалён — единственный оставшийся список живёт в OOK-903 (ook-903-surveys-list-mobile-tobe.html), обе хлебные крошки «Вечерние опросы» на экранах голосования (обычная тема и чайники) переключены на него. Действие «Общий список — вопросы и голосования вперемешку» на карточке OOK-903 в index.html теперь тоже ведёт туда.
Тема «цвет холодильника» удалена. По прямому запросу («удали прототип „Новый тип вопроса — «Это или Это» (тема: цвет холодильника)»") файл ook-917-pair-choice-mobile-tobe.html удалён — ook-917-pair-choice-kettles-mobile-tobe.html (тема с реальными чайниками) остаётся единственной версией механики «Это или Это». Комментарий к файлу-чайникам переписан — раньше сравнивал себя со «второй темой», теперь описывает себя как единственную. Обратная стрелка на этом же экране, раньше указывавшая на удалённый вариант-список хаба (см. round 21 OOK-903), теперь ведёт на хаб-плитки.
По прямому запросу (см. историю OOK-903, тот же раунд) в ook-917-pair-choice-kettles-mobile-tobe.html декоративная ссылка href="#" у пункта «Поиск» заменена на ook-903-question-widget-mobile-tobe.html с data-flow-hotspot.
По прямому запросу («под вариантами ответов и в фото-победителе убери подписи, например «Чайник стальной». Варианты ответов просто картинки, там названий не будет») из ook-917-pair-choice-kettles-mobile-tobe.html убран текстовый блок .pair-choice-label под каждой карточкой раунда и .pair-winner-name под фото победителя. Названия чайников (например, «Цветочный», «Стеклянный красный») остались только как внутренние данные — ключ сортировки/подсветки строки в итоговой статистике (не показывалась текстом уже раньше, по более раннему фидбэку) и как alt у изображений для доступности, невидимый на экране. Под фото победителя добавлен отступ вместо убранной подписи, чтобы разделительная линия не прижималась вплотную к картинке.
По прямому запросу («подгрузка картинок тормозит, нужна предзагрузка, чтобы всё было мгновенно») в <head> добавлены 6 тегов <link rel="preload" as="image"> — по одному на каждое фото чайника. Раньше браузер начинал качать фото нового претендента только в момент смены раунда (когда скрипт подставлял его в <img src>), отсюда заметная задержка перед показом на слабом соединении. link rel=preload запускает закачку сразу при разборе HTML, ещё до выполнения скрипта в конце страницы — проверено через сетевые запросы Playwright: все 6 файлов загружаются сразу при открытии экрана, а при переходе на следующий раунд повторного запроса к уже показанной или ещё не показанной картинке не происходит — файл берётся из кэша браузера. Список URL продублирован между <link> в head и массивом KETTLES в скрипте (общего компонента для синхронизации нет — при замене фото нужно поменять оба места). Первый (более простой) вариант реализации — предзагрузка через скрытые JS-объекты new Image() — был заменён на link rel=preload, так как последний запускается раньше (до выполнения скрипта) и ускоряет в том числе самую первую пару, а не только последующие раунды; дублирование убрано, оставлен один механизм.
Заполнить.
Заполнить.
Заполнить.
Заполнить.
Заполнить.
Прикрепить ссылку/задачу на макеты
OOK-918Внутренний журнал изменений по датам — не для дизайнера/аналитика, но полезен при дальнейших доработках, чтобы понимать, что и почему менялось. Актуальные требования — в соседнем документе «Требования к задаче».
Третий тип вопроса дня в разделе (после обычного текстового OOK-834 и голосования «Это или Это» OOK-917) — по образцу игры «найди приз под карточкой»: ook-918-treasure-cards-mobile-tobe.html. 12 закрытых карточек в сетке 3×4, за одной спрятан приз-бонус, у пользователя 5 попыток «перевернуть» карточку (клик — 3D-переворот CSS-трансформацией). Открытая карточка без приза помечается «Пусто» и выбывает из игры, попытка списывается; счётчик попыток показан текстом («Осталось попыток: N») и рядом кружками-индикаторами, которые гаснут по мере расходования попыток. Нашёл приз раньше, чем кончились попытки, — мгновенная победа, неиспользованные попытки не играют роли. Кончились попытки без находки — поражение; карточка с призом автоматически переворачивается, чтобы показать, где он был, дальнейший клик по сетке блокируется.
Бонус — только за угадывание, не за факт участия (+100 Б при победе, ничего при поражении, только текст «В этот раз не повезло») — прямое отличие от остальных форматов раздела, где бонус гарантирован уже самим участием. Реализовано буквально по формулировке запроса («угадал — получил бонусы, не угадал — „в следующий раз“»), но зафиксирован открытый вопрос к продукту в комментарии к файлу: не разойдётся ли это с ожиданиями пользователей, привыкших в этом разделе к правилу «участие = бонус», и не стоит ли предусмотреть небольшой утешительный бонус за поражение.
Расположение приза — фиксированное демо-значение в скрипте (PRIZE_INDEX, карточка №8), не рандомизируется; в реальном продукте позиция должна выбираться сервером на каждый день/пользователя, иначе повторный заход по одному URL всегда даст один и тот же результат — тоже отмечено как открытый вопрос.
Два состояния «уже участвовал» — по прямому запросу пользователя, через ?state=won и ?state=lost (по образцу параметра ?state= у OOK-834/OOK-917): статус-бейдж меняется на «Вы уже участвовали», часть карточек показана уже перевёрнутой демо-набором прошлых попыток, приз автоматически раскрыт, повторная игра недоступна. Текст результата — в прошедшем времени («Бонус начислен» / «Зачислен на баланс»), без обещания «начислим в течение» — по тому же принципу, что и в OOK-917: по прошествии дня асинхронное начисление уже завершилось. Вся логика (счётчик попыток, победа/поражение, оба демо-состояния «уже участвовал») проверена симуляцией: сценарии «5 промахов подряд», «промах, затем находка», ?state=won и ?state=lost — во всех случаях счётчик, текст результата и раскрытие карточки приза дают ожидаемые значения.
По прямому запросу собран новый снимок общего списка — ook-918-surveys-list-mobile-tobe.html, продолжение списка OOK-917 (ook-917-surveys-list-mobile-tobe.html, который сам не удалён и остаётся снимком на момент, когда типов было два). Добавлены 2 карточки типа «Клад» (активная и «уже участвовали, не нашли») с новой сиреневой пилюлей-типом — теперь в списке ровно три типа пилюль («Опрос», «Голосование», «Клад»), у каждой карточки одна. Бонус-строка у активной карточки клада — условная формулировка «+100 бонусов, если угадаете»; у карточки с проигрышем — приглушённый (но не зачёркнутый, в отличие от завершённых опросов) текст «Клад не найден»: зачёркивание в этом списке означает «упущенная и более недоступная возможность», а здесь пользователь просто не выиграл в честной игре — по смыслу другое состояние, решили не путать одним стилем.
Пользователь сообщил: «карточки сливаются с фоном, нет переворачивания». Диагностировано через Playwright (был переподключён в этой сессии) — скриншот подтвердил, что видны только полупрозрачные «?» и номера, ни фон-«рубашка», ни рамки карточек не отрисовывались. Причина — оболочка карты (.mem-card-inner) была построена на <span> с position: relative, а строчные элементы (display: inline, значение по умолчанию для <span>) игнорируют проценты в width/height — оболочка схлопывалась в нулевой размер, обе грани карточки (лицевая «?» и обратная «Пусто»/«Клад!») позиционировались абсолютно относительно вырожденного контейнера и были фактически невидимы, а 3D-переворот (rotateY) происходил, но неразличимо на вырожденном элементе.
Исправлено добавлением display: block на .mem-card-inner (плюс на всякий случай -webkit-appearance: none; appearance: none; на саму кнопку карточки, чтобы нативные стили кнопки не мешали в других браузерах). Проверено скриншотами Playwright по всем сценариям: сетка из 12 видимых голубых карточек с номерами; клик по кладу — переворот, золотая карточка «Клад!», экран победы; клик по пустой — переворот, серая карточка «Пусто», счётчик попыток и точки-индикаторы уменьшаются; полное поражение (5 промахов) — клад автоматически раскрывается, остальные закрытые карточки гаснут; оба состояния ?state=won/?state=lost — корректно показывают демо-историю прошлой игры. Общий список (ook-918-surveys-list-mobile-tobe.html) тоже проверен скриншотом — багов вёрстки не найдено, три типа пилюль отображаются корректно.
Три правки по прямому запросу. (1) На бонус-баннере сверху («+100 бонусов ХОЛОДИЛЬНИК.РУ, если угадаете») иконка-часы заменена на иконку-фейерверк 🎉 — «сразу» подаёт информацию о бонусе живее. (2) При живой победе перевёрнутая карточка с кладом теперь сама показывает иконку 🎉 и «+100 Б» вместо иконки подарка и надписи «Клад!» — награда видна прямо на месте находки. Раз награда уже показана на карточке, отдельный текстовый блок с описанием под сеткой для победы стал не нужен и убран — остаётся только кнопка «Другие способы заработать». Для живого поражения этот блок (🙈 «В этот раз не повезло» + кнопка) не трогали — там нет карточки-победителя, на которой можно было бы показать итог.
(3) Состояния «уже участвовал» (?state=won/?state=lost) пересобраны по важному уточнению пользователя: место клада в реальном продукте будет случайным и не будет запоминаться по пользователям — «слишком накладно». Значит, прототип не должен изображать, какие именно карточки пользователь трогал в прошлом или где лежал клад, — таких данных в системе просто не будет. Убран весь код переворота конкретных карточек (демо-набор «неправильных попыток» и автораскрытие клада); вместо этого — новый блок-сводка над сеткой (иконка + «Бонус начислен»/«В тот раз не повезло» + подпись), сразу под ним кнопка «Другие способы заработать», а вся сетка из 12 карточек показывается целиком, единообразно задизейбленной (потускневшей, лицом вниз, некликабельной), без какой-либо анимации. Бонус-баннер сверху и счётчик попыток в этих состояниях скрыты — они актуальны только для ещё не сыгранной партии. Заодно из текста ушли выдуманные подробности вроде «угадали с N-й попытки» — раз таких данных не будет, честнее не показывать их и в прототипе.
Поведение проверено скриншотами Playwright по всем сценариям: активный экран с иконкой-фейерверком; живая победа — золотая карточка «🎉 +100 Б» + только кнопка снизу, остальные карточки притушены; живое поражение — блок с обезьянкой не изменился; оба состояния ?state=won/?state=lost — блок-сводка сверху, кнопка под ним, вся сетка задизейблена и не перевёрнута.
Пять точечных правок по фидбэку. (1) Зелёный бонус-баннер сверху убран целиком («+100 бонусов ХОЛОДИЛЬНИК.РУ, если угадаете», добавленный только в прошлом раунде) — по прямому запросу, чтобы сохранить интригу насчёт того, что именно спрятано в кладе. До открытия карточек пользователь теперь не видит сумму нигде на активном экране, только заголовок «Клад спрятан под одной из карточек — найдите его!». Побочный эффект, зафиксированный в комментарии к файлу как открытый вопрос: карточка этого же опроса в общем списке (ook-918-surveys-list-mobile-tobe.html) по-прежнему пишет сумму прямым текстом («+100 бонусов, если угадаете») — не согласовано с новой интригой на самом экране игры, но правка касалась только «страницы с опросом» по формулировке запроса, список не трогали.
(2) Эмоции на карточке-победителе — вместо сухого «🎉 +100 Б» карточка с кладом теперь показывает «🎉 Ура! Ты нашёл клад! +100 бонусов» (четыре строки: иконка, восклицание, факт находки, сумма). Заодно исправлена аббревиатура «Б» на полное слово «бонусов» — по прямому указанию пользователя.
(3) Четвёртое состояние экрана — «не участвовал, но опрос уже завершён»: добавлен ?state=closed, по образцу статуса «Опрос завершён» из OOK-834 — серый статус-бейдж (новый CSS-модификатор .is-closed, которого раньше не было в этом файле), время в формате диапазона («Вчера, 20:00–08:00»), в блоке-сводке иконка ⌛ и текст «Время вышло» / «Участие и начисление бонусов больше недоступны». Технически переиспользует ту же инфраструктуру блока-сводки, что и won/lost — функция showPastState(won) обобщена до showInactiveState(mode) с тремя веткам вместо двух.
(4) Отступ после кнопки в неактивных состояниях — по фидбэку «сливается с карточками»: кнопка «Другие способы заработать» в блоке-сводке шла впритык к сетке карточек сразу под ней. Добавлен margin-bottom на весь блок #mem-past-summary — теперь везде, где он показывается (все три неактивных состояния), между кнопкой и первым рядом карточек есть заметный зазор.
(5) Сумма в состоянии «бонус начислен» — заголовок блока-сводки для ?state=won заменён с общего «Бонус начислен» на «+100 бонусов начислено», явно называя количество, плюс подпись уточнена: «Клад найден — бонусы уже на балансе, можно потратить на покупки».
Поведение проверено скриншотами Playwright по всем пяти пунктам: активный экран без зелёного баннера; живая победа — карточка с полным эмоциональным текстом умещается без обрезки на плитке 3-колоночной сетки; новое состояние ?state=closed — серый бейдж, часы-⌛, задизейбленная сетка; ?state=won — явная сумма в заголовке и видимый отступ перед сеткой; ?state=lost — тот же отступ, текст не менялся.
По прямому запросу TOTAL_CARDS изменён с 12 на 9 — сетка теперь ровно 3×3 (была 4 строки по 3, стала 3 строки по 3), правка одной константой в скрипте: вся остальная логика (рендер сетки, счётчик попыток, определение победы/поражения, все три неактивных состояния) уже была написана через TOTAL_CARDS/cards.forEach, а не захардкожена на 12, поэтому обошлось без переписывания — поменялось только число и текст в комментарии к файлу.
Позиция клада (PRIZE_INDEX = 7) не менялась — индекс 7 остаётся валиден и для 9 карточек (0–8), это по-прежнему предпоследняя карточка сетки, теперь в нижнем ряду по центру-слева вместо середины предпоследнего ряда 4×3-сетки. Отмечено как открытый вопрос в комментарии к файлу: при тех же 5 попытках уменьшение сетки с 12 до 9 карточек заметно повышает шанс угадать клад (было 5 попыток из 12, стало 5 из 9) — баланс сложности/вероятности выигрыша не пересматривался, изменили только размер сетки, как попросили.
Проверено на всех состояниях: активная игра, живые победа и поражение, ?state=won, ?state=lost, ?state=closed — везде рендерится сетка 3×3 из 9 карточек, счётчик попыток и текст неактивных состояний работают без изменений.
По прямому запросу пользователя (готовит кроссзадачное демо целевого результата по всем задачам направления «Вопрос дня») нижний таббар добавлен в оба файла этой задачи: ook-918-surveys-list-mobile-tobe.html, ook-918-treasure-cards-mobile-tobe.html — та же разметка .mobile-tabbar, что уже используется в OOK-903/917, иконка «Павел» ведёт на to-be меню личного кабинета (ook-903-user-menu-mobile-tobe.html). Проверено на всех пяти состояниях экрана «Клад» (активное, живые победа/поражение, ?state=won/lost/closed) — таббар отображается везде одинаково, не мешает существующей вёрстке.
«Другие способы заработать» в ook-918-treasure-cards-mobile-tobe.html (оба места — живое поражение и оба неактивных состояния won/lost/closed, использующие общий блок) теперь ведёт на ook-903-bonus-hub-tiles-mobile-tobe.html вместо варианта-списка.
Убрано слово «Активно» — по прямому запросу из статус-бейджей активных карточек «Голосование» и «Клад» в ook-918-surveys-list-mobile-tobe.html (2 карточки) — теперь у активных голосования и клада статус не показывается (только тип-пилюля и время), у остальных карточек списка (опросы, «уже участвовали», «завершён») бейджи не трогали.
Подсветка кликабельных зон (guided-flow) — по прямому запросу подключён во оба файла задачи существующий общий механизм components/guided-flow.js. В списке размечены все 7 карточек-переходов и иконка «Павел». На экране «Клад» размечены: обратная стрелка, хлебная крошка, обе кнопки «Другие способы заработать», иконка «Павел» — и, что технически интереснее, все 9 карточек сетки, создаваемых в рантайме функцией buildCard() (атрибут data-flow-hotspot проставляется через setAttribute сразу при создании каждой карточки, а не в статичной HTML-разметке, которой для сетки просто не существует). Декоративные «#»-элементы (остальные 5 иконок таббара) и ссылки внутри скрытых <template> не размечены.
Список опросов — канонический источник для остальных трёх задач. По прямому запросу («сделай список идентичным во всех задачах: OOK-834, OOK-903, OOK-917, OOK-918») ссылки «Голосование» в ook-918-surveys-list-mobile-tobe.html (активная и «уже участвовали») переведены с версии с цветом холодильника на ook-917-pair-choice-kettles-mobile-tobe.html («вариант с реальными товарами: чайники»), заголовок карточки обновлён на «Выбираем самый красивый чайник». Получившийся файл (стили + разметка) стал каноническим источником, скопированным затем в ook-834-surveys-list-mobile.html, ook-917-surveys-list-mobile-tobe.html и новый ook-903-surveys-list-mobile-tobe.html — везде сохранены собственные <title> и переписанный под контекст задачи текст requirements-content, чтобы честно объяснять причину совпадения, а не молчать о нём. См. также истории OOK-834/903/917.
Поражение в «Кладе» теперь тоже открывает карточку с призом — по прямому запросу («если пользователь не угадал, надо её открыть, но не с надписью „Ура, ты нашёл клад"»). Добавлена функция revealPrizeAfterLoss(): при исчерпании попыток карточка с кладом автоматически переворачивается и показывает «🎁 Клад был тут» — честно, без интонации победы (раньше при поражении карточка с кладом оставалась закрытой наравне с остальными, приз никак не раскрывался на сетке). Остальное поведение поражения (блок «В этот раз не повезло» под сеткой, блокировка дальнейших кликов) не менялось. Комментарий к файлу (requirements-content) обновлён — прежний абзац ошибочно утверждал, что при поражении «нет карточки-победителя, на которой можно было бы это показать», это исправлено на описание нового поведения.
По прямому запросу («в общем списке опросов убери слово „Активен" — оно осталось у текстового опроса») из карточки типа «Опрос» убран статус-бейдж survey-status-badge is-active с текстом «Активен» — раньше он убирался только у активных «Голосование»/«Клад» (round 4), карточка-опрос осталась не замечена. Теперь у активной карточки любого типа статус не показывается вообще (только пилюля-тип и время) — согласовано между всеми тремя типами. Правка внесена в канонический список и распространена на все 4 файла (ook-834-surveys-list-mobile.html, ook-903-surveys-list-mobile-tobe.html, ook-917-surveys-list-mobile-tobe.html, этот файл) — см. их истории.
По прямому запросу («список опросов оставляем только в задаче OOK-903, везде ссылаемся на него») файл ook-918-surveys-list-mobile-tobe.html удалён вместе с копиями в OOK-834 и OOK-917 — из четырёх идентичных копий остаётся только ook-903-surveys-list-mobile-tobe.html. Хлебная крошка «Вечерние опросы» и упоминание списка в комментарии экрана «Клад» (ook-918-treasure-cards-mobile-tobe.html) переключены на файл OOK-903 (содержимое то же самое, менялось только имя файла). Обратная стрелка на этом же экране, раньше указывавшая на удалённый вариант-список хаба «Заработать бонусы», теперь ведёт на хаб-плитки (см. историю OOK-903, тот же раунд).
По прямому запросу (см. историю OOK-903, тот же раунд) в ook-918-treasure-cards-mobile-tobe.html декоративная ссылка href="#" у пункта «Поиск» заменена на ook-903-question-widget-mobile-tobe.html с data-flow-hotspot.