Направление работ: Mobile Код раздела: 1.2 Авторизация > Регистрация Статус: Готов Ответственный: Панкова Л.А. Версия: 0.1 Обновлено: 13.07.26
1. Назначение
Раздел описывает функциональные требования к регистрации пользователя в мобильном приложении МАРТ.
Интерфейс должен провести пользователя от ввода номера телефона до завершения обязательных шагов регистрации: подтверждения телефона SMS-кодом, опционального ввода пригласительного кода и установки пароля.
Документ предназначен для проектирования макета и фронтового сценария. Он не задает визуальное оформление, цвета, расположение элементов и backend-логику создания Аккаунта.
Раздел зависит от Back: 1.1 Организация аккаунтов и Back: 1.1.1 Регистрация.
2. Ключевые понятия
Регистрация в мобильном приложении — пользовательский сценарий создания активного Аккаунта через мобильный интерфейс.
SMS-код — 6-значный код подтверждения владения номером телефона.
Пригласительный код — необязательный код из цифр, который пользователь может указать во время регистрации или пропустить. Код выдается активным аккаунтом для приглашения нового пользователя и получения бонусов.
Соглашение — набор пользовательских документов, согласие с которыми фиксируется при запуске регистрации.
3. Scope
Входит
- Запуск регистрации из мобильного приложения
- Ввод и предварительная проверка номера телефона
- Отображение и открытие пользовательских соглашений
- Отправка SMS-кода подтверждения
- Ввод, проверка и повторная отправка SMS-кода
- Ввод, активация и пропуск пригласительного кода
- Установка и подтверждение пароля
- Переход к следующему шагу после успешной регистрации
- Состояния интерфейса и ошибки регистрации
Не входит
- Mobile: 1.2.1: Задать код пароль и биометрию
- Mobile: 1.2.2: Подтверждение почты
4. BR
Бизнес-правила и ограничения указаны в Back: 1.1 Организация аккаунтов и Back: 1.1.1 Регистрация.
В этом документе связи с BR указаны только при прямом соответствии фронтового требования backend-правилу.
5. Функциональные требования (UC + FR)
FR – functional requirements, что интерфейс должен уметь делать по определенному UC (триггеру).
| ID | Сценарий | Функциональное требование | BR | Вес | Статус |
|---|---|---|---|---|---|
| FR-1 | Пользователь открывает регистрацию | Интерфейс открывает старт регистрации и позволяет начать ввод номера телефона. На стартовом шаге пользователь должен видеть, что продолжение регистрации означает согласие с пользовательскими документами. | Back:1.1.1: | 1 | Реализовано |
| FR-2 | Пользователь вводит номер телефона | Интерфейс принимает номер телефона: только РФ, ровно 10 цифр после +7, код страны нередактируемый, лишние символы отбрасываются — другие страны/длины ввести нельзя. | Back: 1.1.1: | 1 | Частично \ #OQ1.2-2 \ #OQ1.2-11 \ #OQ1.2-13 |
| FR-3 | Пользователь открывает пользовательские документы | Интерфейс позволяет открыть соглашение, политику конфиденциальности и условия использования из текста согласия, а затем вернуться к регистрации без потери введенного телефона. | Back: 1.1.1: | 2 | Частично \ #OQ1.2-19 |
| FR-4 | Пользователь запрашивает SMS-код | Интерфейс отправляет номер телефона, источник регистрации Mobile и факт согласия на условия. При успешном ответе пользователь переводится на шаг подтверждения SMS-кодом. | Back: 1.1.1: Back: 1.1: | 1 | Частично \ #OQ1.2-10 |
| FR-5 | По номеру найден активный Аккаунт | Интерфейс не продолжает создание нового аккаунта и показывает пользователю возможность перейти ко входу или восстановлению доступа. | Back: 1.1.1: | 2 | Частично \ #OQ1.2-8 |
| FR-6 | По номеру найден неактивный Аккаунт | Интерфейс продолжает сценарий подтверждения телефона. | Back: 1.1.1: | 2 | Не реализовано \ #OQ1.2-17 |
| FR-7 | Пользователь вводит некорректный номер | Интерфейс показывает ошибку формата или ответа Back и остается на шаге ввода телефона, сохраняя возможность исправить номер и повторить запрос. | Back: 1.1.1: | 2 | Реализовано \ #OQ1.2-12 |
| FR-8 | Пользователь попадает на шаг SMS-кода | Интерфейс показывает, на какой номер отправлен код, поле ввода 6 цифр и таймер до возможности запросить новый код. | Back: 1.1.1: | 1 | Реализовано \ #OQ1.2-13 |
| FR-9 | Пользователь вводит SMS-код | Интерфейс принимает только 6 цифр и отправляет код на проверку. | Back: 1.1.1: | 1 | Реализовано \ #OQ1.2-20 |
| FR-10 | SMS-код подтвержден | Интерфейс переводит пользователя к шагу пригласительного кода. | Back: 1.1.1: | 1 | Реализовано \ #OQ1.2-21 |
| FR-11 | Пользователь ввел неверный SMS-код | Интерфейс показывает ошибку проверки кода и позволяет повторить ввод в пределах разрешенного лимита попыток. | Back: 1.1.1: | 2 | Реализовано \ #OQ1.2-3 |
| FR-12 | Срок действия SMS-кода истек | Интерфейс сообщает, что код устарел, и предлагает запросить новый код после доступности повторной отправки. | Back: 1.1.1: | 2 | Не реализовано \ #OQ1.2-4 |
| FR-13 | Пользователь запрашивает новый SMS-код | Интерфейс блокирует повторную отправку до завершения таймера, отправляет новый запрос после истечения таймера и перезапускает отсчет. | Back: 1.1.1: Back: 1.1: | 2 | Частично \ #OQ1.2-7 |
| FR-14 | Превышен лимит попыток SMS-кода | Интерфейс показывает состояние временного ограничения и не позволяет продолжать проверку до истечения ограничения, возвращенного Back. | Back: 1.1.1: Back: 1.1: | 2 | Реализовано \ #OQ1.2-3 |
| FR-15 | Пользователь попадает на шаг пригласительного кода | Интерфейс объясняет, что пригласительный код необязателен, и позволяет либо ввести код, либо продолжить регистрацию без него. | Back: 1.1.1: | 1 | Частично \ #OQ1.2-5 |
| FR-16 | Пользователь вводит пригласительный код | Интерфейс принимает 6 цифр пригласительного кода и активирует действие проверки только после ввода 6 цифр. | Back: 1.1.1: | 2 | Частично \ #OQ1.2-5 \ #OQ1.2-6 |
| FR-17 | Пользователь активирует пригласительный код | Интерфейс отправляет код на проверку. При успешной проверке код сохраняется в регистрационном сценарии, и пользователь переводится к установке пароля. При некорректности кода интерфейс выдает сообщение об ошибке. | Back: 1.1.1: | 2 | Частично \ #OQ1.2-6 \ #OQ1.2-18 |
| FR-18 | Пользователь попадает на шаг установки пароля | Интерфейс показывает поля ввода пароля и подтверждения пароля, а также позволяет скрывать и раскрывать введенные значения. | Back: 1.1.1: | 1 | Реализовано |
| FR-19 | Пользователь вводит пароль | Интерфейс проверяет пароль по обязательным правилам: минимальная длина, максимальная длина 50 символов, наличие заглавной и строчной букв, цифры и специального символа. Если правило нарушено, пользователь видит конкретную причину. | Back: 1.1.1: | 1 | Частично \ #OQ1.2-23 \ #OQ1.2-24 \ #OQ1.2-25 |
| FR-20 | Пользователь подтверждает пароль | Интерфейс сравнивает пароль и повтор пароля. Если значения не совпадают, продолжение регистрации недоступно до исправления. | – | 1 | Реализовано |
| FR-21 | Пользователь отправляет пароль | Интерфейс отправляет пароль на сохранение только после прохождения клиентских проверок и показывает результат ответа Back. | Back: 1.1.1: | 1 | Реализовано \ #OQ1.2-22 |
| FR-22 | Пароль не удалось сохранить | Интерфейс показывает ошибку сохранения пароля и позволяет повторить отправку после исправления причины или восстановления соединения. | Back: 1.1.1: | 2 | Реализовано |
| FR-23 | Во время регистрации нет интернет-соединения | Интерфейс показывает понятное состояние отсутствия соединения и позволяет пользователю повторить действие после восстановления сети без потери актуального контекста шага. | – | 2 | Частично \ #OQ1.2-15 |
| FR-24 | Back возвращает техническую ошибку | Интерфейс показывает общее сообщение о проблеме и не переводит пользователя на следующий шаг, пока действие не выполнено успешно. | – | 2 | Реализовано \ #OQ1.2-16 |
| FR-25 | Пользователь повторно нажимает действие во время запроса | Интерфейс предотвращает дублирование запроса: повторное нажатие недоступно или игнорируется до получения ответа. | Back: 1.1.1: | 2 | Частично \ #OQ1.2-14 |
| FR-26 | Пароль успешно установлен | Интерфейс завершает обязательную часть регистрации и переводит пользователя к следующему шагу, указанному продуктовым сценарием: биометрии и контактных данных. | Back: 1.1.1: | 1 | Не реализовано \ #OQ1.2-9 |
6. Открытые вопросы
Пин-контекст: BRD «1.2 Регистрация» v0.1 · репозиторий
booking.mobile.flutter· commit89ca502/ веткаdev· дата сверки 2026-07-15 · якорь:lib/src/feature/registration/**,lib/src/feature/auth/widget/reg_*.dart,lib/src/core/utils/widgets/auth_text_field.dartПереобход относительноdad0c65(2026-07-06): снято/закрыто — 1 (OQ1.2-1: клиентская валидация пароля реализована). Существенно продвинулось, но осталось Open — 4 (OQ1.2-6: кнопка «Активировать» перестала пропускать пустое поле, серверной проверки инвайта по-прежнему нет; OQ1.2-15: на шаге SMS появилось состояние «нет соединения» с повтором, на шагах телефона/пароля его нет; OQ1.2-16: на шаге пароля ошибка теперь берётся изmeta.textответа, но это по-прежнему текст сервера, а не общее сообщение; OQ1.2-18: на шаге инвайт-кода появился вывод ошибки, но только для пустого поля — проверки формата и серверной проверки нет). Осталось Open без изменений — 12 (OQ1.2-2, -3, -4, -5, -9, -10, -11, -12, -13, -14, -17, -19). Появилось новых — 4: OQ1.2-23 … OQ1.2-25 — по FR-19, как следствие новой валидации пароля; OQ1.2-26 — определение «SMS-код — 4-значный» в разделе 2 разошлось с исправленными FR-8/FR-9 (6 цифр) и с кодом. Ключевое: файлreg_phone_screen.dartв диапазонеdad0c65..89ca502не менялся, поэтому все вопросы по шагу телефона остаются в прежнем виде. Решения по OQ1.2-7 (интервалы 60 сек / 60 мин) и OQ1.2-8 (переход к восстановлению доступа) в коде пока не реализованы — сами вопросы остаются Closed (решение принято), но FR-13 и FR-5 держатся в статусе «Частично». Сводка: 26 вопросов — Open 20 (бизнесу 12, разработке 7, закрывает PM 1), Closed 6; подтверждено кодом без вопросов — FR-1, FR-18, FR-20, FR-22 и (в части своего предмета) FR-8, FR-9, FR-10, FR-21; находок обратного прохода отрезано — 0 (находка про максимальную длину пароля вынесена как OQ1.2-25). Оговорка об охвате: анализ статический, только Flutter-слой; маршрутизация без сверки с гайдбуком. Бизнес-правила бэка (формат телефона, TTL SMS, лимиты попыток, состав правил пароля) в коде клиента enforce-ятся лишь частично и делегированы серверу IdentityService — это зафиксировано как вопросы, а не как «в системе нет».
| ID | Источник | Вопрос | Кому | Статус | Рекомендации | Итоговое решение |
|---|---|---|---|---|---|---|
| #OQ1.2-1 | Код FR-19 | Требование говорит: при вводе пароля интерфейс проверяет обязательные правила — минимальная длина, заглавная буква, цифра, спецсимвол — и при нарушении показывает конкретную причину. В коде клиент не проверяет ни одно из правил: единственная проверка перед отправкой — совпадение пароля с повтором и запрет пробелов по краям. Кнопка «Продолжить» активна для любого непустого совпадающего пароля (даже «a»). \ registration_request.dart:24; reg_password_screen.dart:281-299,332-337 \ Переобход 89ca502: исправлено — клиентская валидация пароля реализована (вариант А): добавлены isPasswordStrong (длина ≥ 8, заглавная, строчная, спецсимвол) и isPasswordValid, гейт кнопки «Продолжить» и текст ошибки завязаны на них; пароль «a» больше не проходит \ registration_request.dart:30-49; reg_password_screen.dart:297-309,321-322,344-351. Остаточная дельта по составу правил и по гранулярности сообщения вынесена в OQ1.2-23, OQ1.2-24, OQ1.2-25. | Бизнес/Разработка | Closed | Состав правил пароля — бизнес-правило бэка, во фронте его нет; согласовать с Back: 1.1.1. (А, рекоменд.) реализовать клиентскую валидацию (длина/заглавная/цифра/спецсимвол) с конкретными сообщениями и гейтом кнопки, как требует FR-19; (Б) оставить проверку только на бэке и переписать FR-19 под «правила enforce-ит Back». Сейчас пользователь узнаёт о нарушении только от сервера после отправки. | Вариант А. От бизнеса: подготовить документ по нормам полей ввода и предоставить разработке к 27.07. Разработке: реализовать клиентскую валидацию с учетом этого документа. |
| #OQ1.2-2 | Код FR-2 | Требование говорит: номер телефона принимается «в формате, допустимом Back». В коде формат жёстко зашит: только РФ, ровно 10 цифр после +7, код страны нередактируемый, лишние символы отбрасываются — другие страны/длины ввести нельзя. BRD допустимый формат не фиксирует, код его жёстко ограничивает. \ auth_text_field.dart:16-25; registration_request.dart:23; reg_phone_screen.dart:36,111-126 \ Переобход 89ca502: не исправлено — reg_phone_screen.dart в диапазоне dad0c65..89ca502 не менялся; isPhoneValid по-прежнему требует ровно 10 цифр, код страны readOnly \ registration_request.dart:22; reg_phone_screen.dart:111. | Бизнес/Разработка | Closed | Допустимый формат телефона — правило бэка; согласовать с Back: 1.1.1. (А, рекоменд.) зафиксировать реальные форматы (только РФ 10 цифр?) и внести в BRD явным ограничением; (Б) если нужна мультистрана — привести клиент к согласованному правилу. Связать с OQ1.2-11 (тот же корень). | От бизнеса: поправили БРД. FR-2 изменено в соответствии с кодом: только РФ, ровно 10 цифр после +7, код страны нередактируемый, лишние символы отбрасываются — другие страны/длины ввести нельзя. |
| #OQ1.2-3 | Код FR-11, FR-14 | Требование говорит: при неверном коде — повтор в пределах лимита попыток; при превышении лимита — состояние временного ограничения до истечения, возвращённого Back. В коде понятий «лимит попыток» и «временное ограничение» нет: неверный код бесконечно очищается для повторного ввода, отдельной ветки на ответ Back о превышении нет — она попадёт в общий текст ошибки. \ reg_sms_screen.dart:90-104 \ Переобход 89ca502: не исправлено — экран SMS переписан (добавлена ветка «нет соединения»), но состояний «лимит попыток»/«временное ограничение» так и нет: неверный код по-прежнему только трясёт поле и очищает его; поиск лимит/attempt/429/retryAfter по фиче — совпадений нет \ reg_sms_screen.dart:110-122. | Бизнес/Разработка | Closed | Значение лимита и поведение ограничения — контракт бэка; согласовать с Back: 1.1. (А, рекоменд.) определить состояние «превышен лимит» как контракт Back (коды/поля ответа) и показать его на клиенте (покрывает FR-11/FR-14); (Б) признать зоной сервера и смягчить формулировки FR. | Лимит попыток и временное ограничение реализованы на бэкенде. Требуется тестирование: убедиться, что клиент корректно отображает ответ о превышении лимита. |
| #OQ1.2-4 | Код FR-12 | Требование говорит: при истёкшем сроке SMS-кода интерфейс сообщает, что код устарел, и предлагает запросить новый после доступности повторной отправки. В коде отдельной обработки «код устарел» нет — истечение придёт как обычная ошибка проверки и покажется общим текстом/тряской. \ reg_sms_screen.dart:90-104 \ Переобход 89ca502: не исправлено — при переписывании экрана SMS ветка «код устарел» не появилась; истечение TTL по-прежнему попадает в общую ветку ошибки; поиск устар/истек/expire по фиче — совпадений нет \ reg_sms_screen.dart:110-122. | Бизнес/Разработка | Closed | Признак «код устарел» — контракт бэка; согласовать с Back: 1.1.1 (различает ли ответ истёкший код). (А, рекоменд.) ввести это состояние в контракт и показать на клиенте; (Б) оставить общим текстом ошибки и смягчить FR-12. | От бизнеса: доработать после релиза, так как влияет на удовлетворенность пользователя и потенциально на конверсию в завершение регистрации. Доработка, вес 3 (после релиза). |
| #OQ1.2-5 | Код FR-15, FR-16 | Требование говорит: пригласительный код — код из цифр произвольной допустимой длины; шаг объясняет необязательность. В коде код жёстко ограничен ровно 6 цифрами (числовая клавиатура) — короче/длиннее или буквенные ввести нельзя. Длина «6» в BRD не зафиксирована. \ reg_invite_code_screen.dart:175,182 \ Переобход 89ca502: не исправлено — экран инвайт-кода доработан (см. OQ1.2-6), но length: 6 и числовая клавиатура остались; в BRD длина по-прежнему не зафиксирована \ reg_invite_code_screen.dart:204,213. | Бизнес/Разработка | Closed | Формат инвайт-кода — правило бэка; согласовать с Back: 1.1.1. (А, рекоменд.) зафиксировать (инвайт ровно 6 цифр?) и внести в BRD; (Б) если длина иная — привести клиент к правилу. | От бизнеса: внесли изменения в БРД. |
| #OQ1.2-6 | Код FR-16, FR-17 | Требование говорит: действие проверки инвайт-кода активируется только после ввода значения в допустимом формате, при активации код отправляется на проверку. В коде кнопка «Активировать» активна всегда (в т.ч. при пустом поле) и НЕ отправляет код на проверку сервером — лишь кладёт значение в состояние и переходит к паролю. Фактическая проверка инвайта — только на финальном шаге регистрации. \ reg_invite_code_screen.dart:89-108,33-42; registration_repository.dart:164-166 \ Переобход 89ca502: частично исправлено — «Активировать» больше не пропускает пустое поле: добавлен _onActivate с проверкой на пустоту, вибро-откликом, красной подсветкой поля и текстом «Введите пригласительный код» \ reg_invite_code_screen.dart:49-56,99-109,124,210. Осталось Open: проверка формата неполная (частично заполненный код короче 6 цифр проходит дальше — проверка только trim().isEmpty) и код по-прежнему НЕ отправляется на проверку сервером на своём шаге — фактическая проверка только в endRegistration \ reg_invite_code_screen.dart:35-43,51; registration_repository.dart:164-165. | Бизнес/Разработка | Open | Вопрос потока: проверять инвайт на его шаге или отложить на финал. (А, рекоменд.) валидировать формат и (по согласованию с Back) проверять код на шаге FR-16/FR-17 с выводом ошибки — соответствует FR-17; (Б) оставить отложенную проверку, переписав FR-16/FR-17 под фактический поток. Связать с OQ1.2-18. | Решение бизнеса: проверять сразу. Доработка, вес 2. |
| #OQ1.2-7 | Код FR-13 | Требование говорит: при повторном запросе кода интерфейс перезапускает отсчёт таймера. В коде таймер работает (блокирует до истечения, перезапускает), но длительность непоследовательна: первый отсчёт — 60 секунд, после «Отправить новый код» — 360 секунд. BRD единый интервал не задаёт. \ reg_phone_screen.dart:71; reg_sms_screen.dart:208 \ Переобход 89ca502: решение принято, но в коде пока не реализовано — интервалы прежние: первый отсчёт 60 секунд, повторный 360 секунд; логики «1-3-я попытки по 60 сек, 4-я и далее 60 минут» и счётчика попыток в коде нет \ reg_phone_screen.dart:71; reg_sms_screen.dart:311-314. Вопрос остаётся Closed (решение есть); реализация — задача разработки, FR-13 держится в статусе «Частично». | Бизнес (Герман) | Closed | Продуктовое/UX-решение: единый интервал или намеренно разные. (А, рекоменд.) привести оба к одному значению и зафиксировать в BRD; (Б) если интервалы намеренно разные — описать в FR-13. Политику повторной отправки при необходимости сверить с Back: 1.1. | Привести код к BRD: 1-й, 2-й и 3-й SMS-коды приходят через 60 секунд; на 4-ю и последующие попытки интервал составляет 60 минут. |
| #OQ1.2-8 | Код FR-5 | Требование говорит: при активном аккаунте по номеру интерфейс предлагает перейти ко входу или восстановлению доступа. В коде реализован только переход ко входу (кнопка «Войти» → экран входа), явного пункта «восстановление доступа» на этом шаге нет. \ reg_phone_screen.dart:201-208,222-224 \ Переобход 89ca502: решение принято, но в коде пока не реализовано — reg_phone_screen.dart не менялся, на шаге телефона по-прежнему только переход в LoginRoute, пункта «восстановление доступа» нет \ reg_phone_screen.dart:208. Вопрос остаётся Closed (решение есть); реализация — задача разработки, FR-5 держится в статусе «Частично». | Бизнес (Герман) | Closed | Продуктовое решение. (А, рекоменд.) добавить пункт «восстановление доступа» на шаге FR-5; (Б) если продукт ограничивается входом — скорректировать FR-5. Связать с OQ1.2-17. | Привести код к BRD: реализовать переход к восстановлению доступа. |
| #OQ1.2-9 | Код FR-26 | Требование говорит: после установки пароля интерфейс ведёт к следующему шагу продуктового сценария — настройке код-пароля/биометрии и подтверждению почты. В коде явный переход закомментирован: после успеха выполняется вход, дальнейшая навигация отдана глобальному auth-guard (на Home), а не последовательности «биометрия → почта». \ reg_password_screen.dart:63-67,82-96 \ Переобход 89ca502: не исправлено — переход к RegAskBiometricsRoute/SpheresRoute по-прежнему закомментирован, после успеха выполняется только вход \ reg_password_screen.dart:63-67,93-94. Примечание: в обновлении переработан экран биометрии и добавлен overlay-замок AppLockGate/PinLockView (код-пароль показывается поверх текущего экрана, без сброса стека), но в цепочку регистрации после установки пароля он не встроен — это относится к подстранице 1.2.1 \ app_lock_gate.dart:11-24; material_context.dart:142-146. | Бизнес/Разработка | Open | Продуктовое решение о целевой последовательности + восстановление навигации. (А, рекоменд.) восстановить явный переход к биометрии/почте по FR-26, если последовательность актуальна; (Б) если целевой сценарий — «сразу в приложение», актуализировать FR-26 и подстраницы 1.2.1/1.2.2. | От бизнеса: вариант А. Доработка, вес 1. |
| #OQ1.2-10 | Код FR-4 | Требование говорит: в запрос на SMS-код отправляются номер телефона, источник регистрации Mobile и факт согласия на условия. В коде в теле запроса есть номер, код страны и локаль, но нет явных полей «источник = Mobile» и «факт согласия»: признак Mobile закодирован лишь в имени метода, согласие клиентом не передаётся. \ registration_repository.dart:66-77 \ Переобход 89ca502: не исправлено — метод переименован SendCodeMobile → SendRegistrationCodeMobile, но тело запроса прежнее (phoneNumber, countryCode, locale), полей источника и согласия по-прежнему нет \ registration_repository.dart:66-77. | Бизнес/Разработка | Open | Контракт запроса — согласовать с Back: 1.1.1. (А, рекоменд.) уточнить, нужны ли поля источника и согласия в теле, привести код/BRD в соответствие; (Б) если источник определяется методом, а согласие фиксируется иначе — ослабить формулировку FR-4. | От бизнеса: реализовать полную работу требования. Доработка, вес 1. |
| #OQ1.2-11 | Код FR-2 | Требование говорит: не позволять отправить запрос, пока номер не заполнен до минимально допустимого формата. В коде кнопка гейтится на ровно 10 цифр и «чистоту» ввода — при стандартном вводе работает, но «минимально допустимый формат» жёстко равен 10 цифрам, без промежуточных состояний. \ registration_request.dart:22-23; reg_phone_screen.dart:192-208 \ Переобход 89ca502: не исправлено — isPhoneValid и гейт кнопки без изменений \ registration_request.dart:22-23; reg_phone_screen.dart:192. | Бизнес/Разработка | Open | Тот же корень, что OQ1.2-2 — гейт корректно применяет текущее правило (10 цифр), вопрос лишь в том, совпадает ли правило с Back. Решается вместе с OQ1.2-2 (формат согласовать с Back: 1.1.1). | От бизнеса: внесли изменения в БРД 1.1.1. |
| #OQ1.2-12 | Код FR-7 | Проблема: при некорректном номере ошибка формата показывается («Недопустимый формат номера»), но ветка ошибки ответа Back на экране телефона только пишет в консоль — пользователю ошибка ответа Back не отображается. \ reg_phone_screen.dart:148-158,80-82 \ Переобход 89ca502: не исправлено — ветка ErrorRegistrationState на экране телефона по-прежнему содержит только print, UI ошибки нет \ reg_phone_screen.dart:80-81. | Разработка | Closed | Чистый фронтовый дефект, продуктового выбора нет. Закрываю сам: выводить ошибку ответа Back на экране телефона (не глушить в print) → тикет в Bitrix. Родственно OQ1.2-15, OQ1.2-16 (единый слой ошибок). | Не является дефектом — вопрос закрыт, доработок не требуется. |
| #OQ1.2-13 | Код FR-2, FR-8 | Проблема: маска и сборка номера рассинхронизированы — форматтер даёт (XXX) XXX-XX-XX, а hint поля (___)___-__-__ (иные разделители); на экране SMS номер собирается ручными substring, что упадёт при длине номера < 10. \ auth_text_field.dart:37-46; reg_phone_screen.dart:132; reg_sms_screen.dart:126-127 \ Переобход 89ca502: не исправлено — форматтер по-прежнему даёт (XXX) XXX-XX-XX, hint остался (___)___-__-__, сборка номера на экране SMS по-прежнему через ручные substring(0,3)…(8,10) \ auth_text_field.dart:36-46; reg_phone_screen.dart:132; reg_sms_screen.dart:145. | Разработка | Closed | Чистый фронтовый дефект. Закрываю сам: синхронизировать hint с форматтером и заменить ручные substring на форматтер (устраняет расхождение и риск краша при коротком номере) → тикет в Bitrix. | Не является дефектом — вопрос закрыт, доработок не требуется. |
| #OQ1.2-14 | Код FR-25 | Требование говорит: интерфейс предотвращает дублирование запроса — повторное нажатие недоступно или игнорируется до ответа. В коде на шаге пароля повторное нажатие перекрыто блокирующим оверлеем, но на шагах телефона и SMS отдельного disabled-состояния кнопки на время запроса нет — защита держится на быстрой смене экрана. \ reg_password_screen.dart:29-37,69-71; reg_phone_screen.dart:192; reg_sms_screen.dart:196 \ Переобход 89ca502: не исправлено — на шаге пароля оверлей сохранён, на шагах телефона и SMS явного дизейбла по состоянию запроса по-прежнему нет: кнопка телефона гейтится только валидностью номера, кнопки SMS («Отправить новый код», «Повторить») — без условия на Processing \ reg_password_screen.dart:30-39,69-71; reg_phone_screen.dart:192; reg_sms_screen.dart:225,291. | Разработка | Closed | Фронтовый дефект/риск. Закрываю сам: явно дизейблить кнопку по состоянию запроса (Processing) на шагах телефона и SMS, не полагаясь на скорость навигации → тикет в Bitrix. | Доработать код: дизейблить кнопку на время ожидания ответа сервера на шагах телефона и SMS. |
| #OQ1.2-15 | Код FR-23 | Требование говорит: при отсутствии интернета интерфейс показывает понятное состояние и даёт повторить действие без потери контекста шага. В коде отдельной обработки offline/сетевой недоступности в фиче регистрации нет — сетевая ошибка попадёт в общий error-state и на экране телефона вообще не покажется. \ reg_phone_screen.dart:80-82 \ Переобход 89ca502: частично исправлено — на шаге SMS появилось состояние «нет соединения»: транспортные сбои отличаются от бизнес-ошибок по типу DioException, показывается текст «Ошибка соединения. Попробуйте ещё раз», введённый код НЕ очищается, а кнопка «Повторить» переотправляет его как есть — контекст шага сохранён \ reg_sms_screen.dart:20-23,105-109,187-197,211-247. Осталось Open: на шагах телефона и пароля отдельной обработки offline по-прежнему нет — на телефоне сетевая ошибка не показывается вовсе \ reg_phone_screen.dart:80-81; reg_password_screen.dart:275-291. | Разработка | Closed | FR-23 задаёт поведение, продуктового выбора нет. Закрываю сам: реализовать состояние offline с повтором действия на шагах регистрации → тикет в Bitrix. Родственно OQ1.2-12, OQ1.2-16. | Доработать код: реализовать состояние сетевой ошибки с возможностью повторить действие. |
| #OQ1.2-16 | Код FR-24 | Требование говорит: при технической ошибке Back показать общее сообщение и не переводить на следующий шаг. В коде на шагах пароля/SMS показывается сырое сообщение сервера, а не общее; на шаге телефона ошибка не показывается вовсе. \ reg_password_screen.dart:265-278; reg_phone_screen.dart:80-82 \ Переобход 89ca502: частично исправлено — на шаге пароля вывод ошибки стал аккуратнее: для GatewayException берётся пользовательский текст ответа (meta.text → meta.title → message), у прочих исключений отрезается технический префикс Exception: \ reg_password_screen.dart:275-291. Осталось Open: это по-прежнему текст, пришедший от сервера, а не «общее сообщение о проблеме», как требует FR-24; на шаге телефона ошибка не показывается вовсе \ reg_password_screen.dart:278-291; reg_phone_screen.dart:80-81. | Разработка | Closed | Фронтовый дефект. Закрываю сам: ввести единый слой отображения ошибок (общий текст для технических/сетевых, конкретный — для валидации) на всех трёх шагах → тикет в Bitrix. Общий корень с OQ1.2-12, OQ1.2-15. | От сервера приходят корректные сообщения — вопрос закрыт, доработок не требуется. |
| #OQ1.2-17 | Код FR-6 | Требование говорит: при неактивном аккаунте интерфейс продолжает сценарий подтверждения телефона. В коде различения «активный/неактивный» нет — клиент оперирует только булевым «уникален/занят»; «занят» трактуется как «войти», отдельной ветки «неактивный → продолжить» нет. \ registration_repository.dart:41-62; registration_bloc.dart:150-154; reg_phone_screen.dart:66-79,201-208 \ Переобход 89ca502: не исправлено — IsPhoneUnique по-прежнему возвращает bool, в блоке хранится только isUnique, ветки «неактивный → продолжить» нет \ registration_repository.dart:41-63; registration_bloc.dart:150-154. | Бизнес/Разработка | Open | Требует расширения контракта проверки телефона; согласовать с Back: 1.1.1. (А, рекоменд.) различать «активный/неактивный/свободный» и ветвить по FR-5/FR-6; (Б) если модель обходится «уникален/занят» — скорректировать FR-6. Связать с OQ1.2-8. | От бизнеса: привести код к BRD после реализации компонента Back 1.1. Доработка, вес 1. |
| #OQ1.2-18 | Код FR-17 | Проблема: на шаге инвайт-кода проверки формата и вывода ошибки нет вовсе — код лишь сохраняется и отправляется в составе финального запроса регистрации; ошибка некорректного инвайта всплывёт уже на шаге пароля. \ reg_invite_code_screen.dart:33-42,89-118; registration_repository.dart:164-166 \ Переобход 89ca502: частично реализовано — вывод ошибки на шаге появился: при пустом поле показывается «Введите пригласительный код» с красной подсветкой \ reg_invite_code_screen.dart:49-56,99-109. Проверка формата и серверная проверка инвайта на шаге по-прежнему отсутствуют; отправка — только в endRegistration \ registration_repository.dart:164-165. Требование «необходимо реализовать» из итогового решения выполнено лишь частично, поэтому вопрос остаётся Open; связанный поток — OQ1.2-6. | Бизнес/Разработка | Open | Зависит от решения по потоку инвайта (OQ1.2-6). (А, рекоменд.) валидировать формат и по согласованию проверять код на шаге FR-16/FR-17 с выводом ошибки; (Б) оставить отложенную проверку, переписав FR-16/FR-17. Связать с OQ1.2-6. | От бизнеса: доработка, вес 2. |
| #OQ1.2-19 | Код FR-3 | Требование говорит: из текста согласия можно открыть соглашение, политику конфиденциальности и условия использования и вернуться без потери телефона. В коде из текста согласия ведёт одна ссылка — только политика конфиденциальности; экраны «Пользовательское соглашение»/«Условия использования» в роутере есть, но с этого текста не открываются. Возврат без потери телефона обеспечен. \ reg_phone_screen.dart:45-52,244-256; app_router.dart:335-336 \ Переобход 89ca502: не исправлено — из текста согласия по-прежнему ведёт единственная ссылка на PrivacyPolicyRoute \ reg_phone_screen.dart:46,49-51. | Разработка | Open | Роуты уже есть, FR-3 требует три документа — продуктового выбора нет. Закрываю сам: вывести из текста согласия все три документа через существующие роуты → тикет в Bitrix. Если продукт объединяет документы в один — отметить в FR-3. | От бизнеса: реализовать, вес 1. |
| #OQ1.2-20 | Код FR-8, FR-9 | Что подтверждено: поле SMS-кода — ровно 4 цифры (Pinput length: 4), при заполнении код отправляется на проверку. FR-8 (поле 4 цифр) и FR-9 (принимает только 4 цифры, отправляет на проверку) выполнены. \ reg_sms_screen.dart:284-285,301-305 \ Переобход 89ca502: исправлено — поле SMS-кода приведено к 6 цифрам (Pinput length: 6), код по-прежнему уходит на проверку из валидатора при заполнении; код и исправленные FR-8/FR-9 (6 цифр) теперь согласованы \ reg_sms_screen.dart:396,411-420. Примечание: определение «SMS-код — 4-значный код» в разделе 2 «Ключевые понятия» осталось прежним и расходится и с FR-8/FR-9, и с кодом — вынесено как OQ1.2-26. | — | Closed | Расхождения нет. \ Подтверждение: FR-8/FR-9 подтверждены кодом, действий не требуется. | Исправили требования: в FR-8 и FR-9 указано 6 цифр. |
| #OQ1.2-21 | Код FR-10 | Что подтверждено: после подтверждения SMS-кода (smsCodeValid) выполняется переход (replace) на шаг пригласительного кода. FR-10 выполнен. \ reg_sms_screen.dart:91-93 \ Переобход 89ca502: подтверждено повторно — после переписывания экрана переход сохранён: при smsCodeValid выполняется replace на RegInviteCodeRoute \ reg_sms_screen.dart:102-104. | — | Closed | Расхождения нет. \ Подтверждение: FR-10 подтверждён кодом, действий не требуется. | Требование реализовано. |
| #OQ1.2-22 | Код FR-21 | Что подтверждено: финальный запрос (endRegistration) вызывается только при прохождении клиентских проверок (isValid — совпадение паролей + отсутствие крайних пробелов). FR-21 выполнен на уровне текущих проверок. \ reg_password_screen.dart:332-337 \ Переобход 89ca502: подтверждено повторно и усилено — набор клиентских проверок расширен: isValid теперь включает isPasswordValid (непустой, совпадение, ≤ 50 символов, isPasswordStrong) плюс запрет крайних пробелов; оговорка «набор проверок неполный» снята \ reg_password_screen.dart:318-322,344-351; registration_request.dart:39-49. | — | Closed | Расхождения по FR-21 нет. \ Подтверждение: отправка только после клиентских проверок подтверждена; полнота набора правил пароля — отдельный вопрос OQ1.2-1 (FR-19). | От разработки: реализовано. |
| #OQ1.2-23 | Код FR-19 | Требование говорит: пароль проверяется по правилам «минимальная длина, заглавная буква, цифра, спецсимвол». В коде (появилось в 89ca502) набор правил другой: длина ≥ 8, заглавная буква, строчная буква, спецсимвол. Проверки на цифру нет вообще — пароль Abcdefg! проходит; зато требуется строчная буква, которой в FR-19 нет — пароль ABCDEF1! не пройдёт, хотя все правила FR-19 выполняет. Текст ошибки на экране повторяет код, а не BRD: «Пароль должен содержать минимум 8 символов, строчную и прописную буквы и спецсимвол». \ registration_request.dart:32-45; reg_password_screen.dart:303-305 | Бизнес/Разработка | Closed | Новое расхождение, появилось вместе с реализацией валидации по OQ1.2-1. Состав правил — правило бэка; согласовать с Back: 1.1.1 и привести обе стороны к одному списку. (А, рекоменд.) взять состав правил из Back как источник истины, поправить клиент (добавить/убрать проверку цифры и строчной) и синхронно уточнить FR-19 и текст ошибки; (Б) если клиент уже соответствует Back — переписать FR-19 под фактические правила (8+, заглавная, строчная, спецсимвол). Отдельно подтвердить минимальную длину 8 — в BRD она не зафиксирована. | Доработать требования: добавить в FR-19 обязательную строчную букву — привести состав правил к коду. |
| #OQ1.2-24 | Код FR-19 | Требование говорит: если правило нарушено, пользователь видит конкретную причину. В коде (появилось в 89ca502) при нарушении любого из правил сложности показывается одно общее сообщение, перечисляющее сразу все правила, — какое именно нарушено, пользователь не видит; отдельные сообщения есть только у пробелов по краям и у несовпадения паролей. \ reg_password_screen.dart:300-309 | Разработка | Closed | Фронтовый дефект, продуктового выбора нет: правила уже вычисляются по отдельности (_hasUppercase/_hasLowercase/_hasSpecial/длина), не хватает только раздельного вывода. Закрываю сам: показывать конкретную нарушенную причину (или чек-лист правил с отметкой выполненных), как требует FR-19 → тикет в Bitrix. Решать вместе с OQ1.2-23 (сначала состав правил, затем тексты). | От бизнеса: внесли изменения в БРД. |
| #OQ1.2-25 | Код FR-19 | Обратный проход (код делает сверх BRD): в коде появилось ограничение максимальной длины пароля — 50 символов; оно enforce-ится и полями ввода (maxLength), и гейтом кнопки. В комментарии кода указано, что это «server-side max», но в BRD (FR-19 и Back: 1.1.1 в тексте раздела) максимальная длина не зафиксирована — FR-19 говорит только о минимальной. \ registration_request.dart:26-28,46-48; reg_password_screen.dart:135,208 | Бизнес/Разработка | Closed | Ограничение, которого нет в требованиях. (А, рекоменд.) подтвердить у Back: 1.1.1, что серверный максимум действительно 50, и внести его в FR-19 явным ограничением — тогда код и BRD сойдутся; (Б) если у сервера иной максимум (или его нет) — привести клиент к правилу Back. Пока значение не подтверждено, риск в том, что клиент отрежет пароль, который сервер бы принял. | От бизнеса: внесли изменения в БРД. |
| #OQ1.2-26 | Раздел 2, FR-8, FR-9 | Внутреннее противоречие BRD: в разделе 2 «Ключевые понятия» SMS-код определён как «4-значный код подтверждения владения номером телефона», тогда как FR-8 и FR-9 после решения по OQ1.2-20 говорят о 6 цифрах, и код на 89ca502 реализует 6 (Pinput length: 6). Определение в разделе 2 при правке FR-8/FR-9 не обновили. \ reg_sms_screen.dart:396 | Закрывает PM | Closed | Расхождение документа с самим собой и с кодом; продуктового выбора нет — решение уже принято в OQ1.2-20. Закрываю сам: привести определение в разделе 2 «Ключевые понятия» к 6 цифрам, синхронно с FR-8/FR-9. Правка текста BRD выходит за рамки сверки (в этом прогоне разделы 1–4 переносятся дословно) — вносится отдельной правкой документа. | Внесены изменения: в разделе 2 «Ключевые понятия» SMS-код исправлен на 6-значный — противоречие устранено. |