PRIME BarbershopАтлас приложения Редакция 02 / 2026
PRIME / 07

Граф сервиса

От команды до следующего визита. Четыре роли, общая ответственность.

186 / 377состояний / переходовМодель процесса · интеграции не подключены
Участник
Слой
J01 / Запуск

Владелец: от найма до открытия

Создать действующую команду и опубликовать запись только после проверки готовности.

Все 28 путей ↓
Объём
Показать
Пространственная карта18 узлов · 18 связей
Направленные переходы между действиямиПеретаскивание поворачивает карту, Shift и перетаскивание перемещают. Масштаб и поворот доступны кнопками. Все узлы доступны в списке под картой.
100%

Линия со стрелкой — переход. Квадрат — операция бэкенда. Пунктир — исключение. Поворот: перетаскивание; перемещение: Shift + перетаскивание. Идентификаторы плотной сети появляются при увеличении.

Узлы карты списком · 18
O00 · Подтвердить владениеВыберите действие на карте или начните путь
Шаги выбранного пути · 17
ВОРОНКИ / 28

Выберите человеческую ситуацию

ПРАВА

Один человек, разные контексты

Владелец

Организация и филиалы; найм, доступ, политики, финансы. Только подтверждённое владение.

Барбер

Свои смены и назначенные визиты; доступ к пожеланиям и фото только в рабочем контексте.

Гость

Анонимный просмотр, поиск, локальный черновик; без чужих визитов, токенов карт и staff API.

Клиент

Свои записи, способы оплаты, согласия, паспорт и клуб. Не получает staff-права через вход.

РЕШЕНИЯ / 16

Что задаёт правила пути

Предложения для утверждения. Примерные сроки и суммы не являются действующими условиями PRIME.

POL-01Организация и ролиВладелец

Одна организация PRIME с возможностью нескольких филиалов. Владелец может быть барбером и клиентом, но active context и API scope раздельны. Первого владельца заводит подтверждённая bootstrap-процедура.

POL-02Занятость и расчёт барбераВладелец

Тип договора, ставка, процент, база начисления, чаевые и правила перерасчёта не утверждены. В графе versioned offer и отдельный payroll ledger; приём оплаты клиента не выплачивает зарплату.

POL-03ПредоплатаВладелец

Проектная рекомендация: по умолчанию оплата на месте; предоплату включать по опубликованной политике услуги/клуба. Ставка configurable в basis points, default 0, не утверждённый тариф.

POL-04Удержание окнаВладелец

Демо-значение hold TTL 5 минут. Серверное время, ограниченные продления; expiry не забывает уже начатый платёж. Не совпадает с банковской авторизацией.

POL-05Перенос и отменаВладелец

Версия правил фиксируется в заказе. Автоматические штрафы и списание за no-show выключены. Любое удержание требует заранее принятых условий и отдельного решения о правомерности; причина болезни без диагноза.

POL-06ОпозданиеВладелец

Для демо grace 10 минут, не гарантия обслуживания. Решение: оставшееся время ≥ согласованная длительность + buffer и есть согласие мастера/клиента. Иначе перенос/отмена; следующий визит защищён.

POL-07УведомленияКлиент

Демо cadence 24 часа и 2 часа до визита, если ещё актуально; snooze ограничен. Канал opt-in, quiet hours и timezone; критичное изменение уходит в очередь владельца при недоставке. Маркетинг отдельно.

POL-08Лист ожиданияВладелец

Демо offer TTL 15 минут. Справедливое согласованное правило очереди, atomic claim, без auto-book; предложенное окно может истечь.

POL-09PRIME CLUBВладелец

Тарифы и остатки маркетолога — гипотеза. До утверждения плана purchase disabled. Раздельные entitlement, guest pass, mandate продления; неизменяемый ledger, не самодельный денежный кошелёк.

POL-10Фото и чувствительные пожеланияКлиент

Private passport по умолчанию, фото необязательны. Фото/портфолио/камера/маркетинг — разные разрешения. Retention, экспорт и удаление требуют конкретной матрицы до production; диагноз не собирать.

POL-11ЮKassa и чекиВладелец

Один merchant по исходной модели; multi-merchant/split выплат не предполагать. Режим оплаты, фискальная схема, ставки/предмет расчёта и возвраты утверждаются с ответственными до live.

POL-12Покупка для другого человекаВладелец

Payer ≠ recipient. Нельзя передавать историю по оплате. Возраст/законный представитель/согласия — открытое решение; сценарий несовершеннолетнего блокируется до конкретной политики.

POL-13Сроки и ручная поддержкаВладелец

Демо: unresolved финансовая операция после ограниченного retry budget создаёт urgent case; целевой первый ответ 30 минут в рабочее время, не обещанный SLA. После рабочего времени показать реальное время ответа.

POL-14Вход и платформыВладелец

Telegram/Яндекс — документированные flows, MAX — conditional handoff. Нужны зарегистрированные apps и secrets до интеграции; iOS alternative login/Apple guideline отдельно. Кнопки схемы не выполняют вход.

POL-15Рекомендации и чаевыеВладелец

Добровольный отзыв/рекомендация/чаевые. Rewards и tip provider включаются только после опубликованных правил и отдельного финансового потока; не награждать исключительно положительные отзывы.

POL-16Закрытие и сохранность обязательствВладелец

Закрытие филиала, уход сотрудника и удаление аккаунта не уничтожают payment/refund mappings. Ответственный case остаётся до authoritative решения; техническая очередь не считается завершённым возвратом.

ИСТОЧНИКИ

Концепция и интеграции

Основа — проверенный импорт маркетолога с Mac-mini--Milissa.local: Private Club × Style Lab, Arctic Black, 20 экранов. Роли владельца и гостя, операционные исключения и технические контракты развивают эту концепцию по вашему поручению.

TelegramЦелевой контракт

OIDC authorization code + PKCE S256. Backend проверяет подпись, iss/aud/exp и state; phone и bot_access запрашиваются только по необходимости. Вход и разрешение на сообщения разделены.

Официальная документация ↗Проверено 2026-09-27
Яндекс IDЦелевой контракт

Authorization code + PKCE S256 и state; токен обменивается сервером, redirect URI зарегистрирован. Минимальные scopes и доказанная identity вместо слияния по email.

Официальная документация ↗Проверено 2026-09-27
MAXТребуется проверка интеграции

Документирован mini-app initData с HMAC-SHA256 и auth_date. Для native PRIME нужен проверенный одноразовый handoff между mini-app и приложением. Самостоятельный MAX OIDC здесь не подтверждён; кнопку включать только после интеграционного spike, fallback Telegram/Яндекс.

Официальная документация ↗Проверено 2026-09-27
ЮKassa: состояния платежаЦелевой контракт

pending → waiting_for_capture/succeeded/canceled. succeeded и canceled финальны. expires_at авторизации берётся у провайдера; длинную запись нельзя обеспечивать бессрочным банковским hold. Возврат отдельным объектом.

Официальная документация ↗Проверено 2026-09-27
ЮKassa: сохранение картыЦелевой контракт

После отдельного согласия передать save_payment_method; сохранить идентификатор только при payment_method.saved=true. В PRIME — provider ID и маска, PAN/CVV не принимать. Первичная привязка в этой модели происходит при платеже; отдельная нулевая привязка требует проверки доступности магазина.

Официальная документация ↗Проверено 2026-09-27
ЮKassa: уведомленияЦелевой контракт

Входящий webhook — сигнал для обработки. Архитектурное решение PRIME: durable inbox, проверка актуального объекта authenticated GET, суммы/валюты/магазина, дедупликация и монотонное состояние. Browser return URL не подтверждает оплату.

Официальная документация ↗Проверено 2026-09-27
ЮKassa: идемпотентностьЦелевой контракт

Idempotence-Key повторяет одну операцию с теми же параметрами; гарантия провайдера ограничена 24 часами. PRIME хранит собственную operation identity дольше; после окна сначала сверка, не слепой повтор POST.

Официальная документация ↗Проверено 2026-09-27
ЮKassa: чекиЦелевой контракт

Фискальный сценарий выбирается с бухгалтерией и настройками магазина. В модели отдельные состояния чека оплаты, предоплаты/зачёта и возврата; сбой чека не запускает второй платёж.

Официальная документация ↗Проверено 2026-09-27
Apple: Login ServicesЦелевой контракт

Перед iOS release проверить применимость 4.8 при сторонних способах входа и добавить подходящий равноценный вариант, например Sign in with Apple. Выбор провайдеров в графе не подтверждает готовность к App Review.

Официальная документация ↗Проверено 2026-09-27

Граф проверяется на достижимость, отсутствие потерянных ссылок и выход из каждой нетерминальной ветви. Это структурная проверка модели, а не подтверждение работающей оплаты, авторизации или исчерпания всех сочетаний событий реальной жизни.