Pattern: Реєстрація — widget (авто phone або share)

Призначення

Перевірити реєстрацію нового користувача у widget каналі з двома гілками: телефон вже є в контексті або його потрібно ввести вручну/поділитися.

Опис патерну

Widget-реєстрація — це флоу, де бот спочатку перевіряє канал і наявність {{phone}}, а потім або запитує ім'я, або збирає телефон і вже після цього переходить до підтвердження та збереження.

Компоненти:

1. Entry + pre-check — entry_point → console_log → registered_users__get.
2. Start message — повідомлення “Пройдімо реєстрацію...”.
3. Channel switch — switch за {{channel}} (widget → перевірка phone).
4. Phone presence switch — switch за {{phone}} (є/немає).
5. Phone input (fallback) — input reg_phone з валідацією phone.
6. Name input — input reg_first_name.
7. Confirmation + persist — повідомлення підтвердження → set → console_log → registered_users__set.
8. Exit — connect_from у секцію 202 після реєстрації.

Workflow:

1. Запуск секції “Реєстрація”.
2. Перевірка існуючого користувача в registered_users.
3. Якщо зареєстрований — вихід у секцію 202.
4. Якщо новий — показ стартового повідомлення.
5. switch по channel == widget.
6. switch по наявності {{phone}}.
7. Якщо phone є — запит імені.
8. Якщо phone немає — запит телефону → запит імені.
9. Підтвердження, запис registration:*, збереження у registered_users, вихід.

Кроки оцінки

1. Аналіз гілок widget + phone

Що включає:

• Перевірка switch по {{channel}} та {{phone}}.
• Визначення гілок “phone є” та “phone немає”.

Оцінка: 0.5-1.0 години

Фактори:

• Додаткові канали в гілках: +0.5 год

2. Підготовка тестових сценаріїв

Що включає:

• Два стани контексту: з phone та без phone.
• Валідний та невалідний формат телефону.

Оцінка: 0.5-1.0 години

Фактори:

• Нестабільна ініціалізація контексту: +25%

3. Перевірка збереження та виходу

Що включає:

• Перевірка registration:phone, registration:UserID.
• Перевірка registered_users__set та переходу в секцію 202.

Оцінка: 0.5-1.0 години

Фактори:

• Додаткові перевірки через лог/API: +0.5 год

Типова структура оцінки

Базовий варіант

Ризиковий буфер: Medium Risk (+25%) = +0.5 год
Фінальна оцінка: 4.0 год

Невизначеності та ризики

Типові невизначеності:

• Формат phone, який підставляється автоматично у widget.
• Час появи phone у контексті від клієнта.

Ризики:

• Неконсистентний phone у widget: +25%
• Розходження в контексті channel: +15%

Рекомендації

1. Перевіряй обидві гілки phone (є/немає) як окремі кейси.
2. Валідність телефону тестуй через ручний ввід і авто-підстановку.
3. Фіксуй переходи у секцію 202 після успішної реєстрації.
4. Перевіряй, що registration:UserID відповідає {{chat_id}}.

Приклади використання

• engine_9_2026-01-21-10-27.json — секція 232 “Реєстрація” (widget шлях).

Пов'язані документи

• temp/actions/engine_9_2026-01-21-10-27.json — конфігурація бота, секція 232.

description: "Перевірка реєстрації нового користувача у widget з авто/шарингом телефону" alwaysApply: false

Pattern: Реєстрація — widget (авто phone або share)

Призначення

Перевірити реєстрацію нового користувача у widget каналі з двома гілками: телефон вже є в контексті або його потрібно ввести вручну/поділитися.

Опис патерну

Widget-реєстрація — це флоу, де бот спочатку перевіряє канал і наявність {{phone}}, а потім або запитує ім'я, або збирає телефон і вже після цього переходить до підтвердження та збереження.

Компоненти:

1. Entry + pre-check — entry_point → console_log → registered_users__get.
2. Start message — повідомлення “Пройдімо реєстрацію...”.
3. Channel switch — switch за {{channel}} (widget → перевірка phone).
4. Phone presence switch — switch за {{phone}} (є/немає).
5. Phone input (fallback) — input reg_phone з валідацією phone.
6. Name input — input reg_first_name.
7. Confirmation + persist — повідомлення підтвердження → set → console_log → registered_users__set.
8. Exit — connect_from у секцію 202 після реєстрації.

Workflow:

1. Запуск секції “Реєстрація”.
2. Перевірка існуючого користувача в registered_users.
3. Якщо зареєстрований — вихід у секцію 202.
4. Якщо новий — показ стартового повідомлення.
5. switch по channel == widget.
6. switch по наявності {{phone}}.
7. Якщо phone є — запит імені.
8. Якщо phone немає — запит телефону → запит імені.
9. Підтвердження, запис registration:*, збереження у registered_users, вихід.

Кроки оцінки

1. Аналіз гілок widget + phone

Що включає:

• Перевірка switch по {{channel}} та {{phone}}.
• Визначення гілок “phone є” та “phone немає”.

Оцінка: 0.5-1.0 години

Фактори:

• Додаткові канали в гілках: +0.5 год

2. Підготовка тестових сценаріїв

Що включає:

• Два стани контексту: з phone та без phone.
• Валідний та невалідний формат телефону.

Оцінка: 0.5-1.0 години

Фактори:

• Нестабільна ініціалізація контексту: +25%

3. Перевірка збереження та виходу

Що включає:

• Перевірка registration:phone, registration:UserID.
• Перевірка registered_users__set та переходу в секцію 202.

Оцінка: 0.5-1.0 години

Фактори:

• Додаткові перевірки через лог/API: +0.5 год

Типова структура оцінки

Базовий варіант

Ризиковий буфер: Medium Risk (+25%) = +0.5 год
Фінальна оцінка: 4.0 год

Невизначеності та ризики

Типові невизначеності:

• Формат phone, який підставляється автоматично у widget.
• Час появи phone у контексті від клієнта.

Ризики:

• Неконсистентний phone у widget: +25%
• Розходження в контексті channel: +15%

Рекомендації

1. Перевіряй обидві гілки phone (є/немає) як окремі кейси.
2. Валідність телефону тестуй через ручний ввід і авто-підстановку.
3. Фіксуй переходи у секцію 202 після успішної реєстрації.
4. Перевіряй, що registration:UserID відповідає {{chat_id}}.

Приклади використання

• engine_9_2026-01-21-10-27.json — секція 232 “Реєстрація” (widget шлях).

Пов'язані документи

• temp/actions/engine_9_2026-01-21-10-27.json — конфігурація бота, секція 232.