# Этап B2 — UX scheme и low-fi prototype

Дата: 2026-08-05  
Статус: `approved_by_owner — 2026-08-05`  
Основание: этап A и Gate B1 подтверждены владельцем; Gate B2 утверждён владельцем в чате 2026-08-05  
Следующий gate: B3 разрешён; утверждение B3 всё ещё обязательно перед этапом C

Кликабельный grayscale prototype: [`gate-b2/index.html`](gate-b2/index.html).  
Responsive QA frame: [`gate-b2/qa-responsive.html`](gate-b2/qa-responsive.html) — служебный review-инструмент, не часть product shell.

## 1. Что проверяет B2

B2 проверяет только структуру, названия, порядок действий, переходы и состояния. В прототип намеренно не перенесены утверждённые B1-цвета, Golos Text, фотографии, motion и production platform assets: они появятся только на B3 после утверждения UX.

Принятые продуктовые defaults этапа A:

- один responsive agent product с одинаковыми четырьмя разделами на mobile и desktop;
- партнёрский бот отвечает за onboarding, статусы, уведомления и подтверждение входа, но не создаёт кампании;
- owner/admin физически отделён от agent cabinet;
- одна campaign атомарно создаёт два материала — `link` и `qr`;
- archive не отключает публичные материалы; owner disable отключает новую attribution;
- агент видит aggregate click analytics без client PII и финансовых обещаний;
- owner-disabled и suspended-agent materials по умолчанию ведут в обычный клиентский бот без attribution;
- desktop-вход использует Telegram OIDC/PKCE; bot-confirmed challenge остаётся только предусмотренным fallback.

Дополнительная B2-конкретизация, не меняющая бизнес-модель:

- onboarding/access states находятся до product shell; защищённый route при любом не-approved статусе показывает соответствующий gate с возвратом в партнёрский бот;
- анкета B2 содержит подтверждённую Telegram identity, имя, тип партнёра, дополнительный контакт, необязательные каналы и consent; новая подача после reject создаёт новую revision;
- `Campaign.archived_at` и `TrackingMaterial.enabled/disabled_by_owner` — ортогональные состояния: restore материала не разархивирует campaign, а archive не включает отключённый material;
- default statistics view — последние 8 недель; custom range proposal — не более 366 дней, с явной валидацией и `Asia/Bangkok`;
- review case показывает владельца, возраст и SLA placeholder; точные SLA, terminal actions и evidence contract остаются задачей этапа C;
- agent V1 не содержит commission/payout placeholder, logout остаётся вторичным session action в профиле.

## 2. Поверхности и навигационная модель

```text
Partner bot / access
├── О программе
├── Анкета
├── Отправка
├── На рассмотрении
├── Отказ → исправить → повторно подать
├── Одобрено → открыть кабинет
├── Доступ приостановлен
└── Desktop-вход: начать → подтвердить → готово / истекло

Agent Mini App / desktop
├── Создать
│   ├── Форма
│   ├── Отправка
│   └── Страница созданной ссылки: link + QR
├── Мои ссылки
│   ├── Поиск и фильтры
│   ├── Campaign detail
│   └── Архивирование
├── Статистика
│   ├── Период
│   ├── Summary
│   ├── Trend + data table
│   └── Campaign detail: link / QR
└── Профиль
    ├── Контакты
    ├── Каналы публикации
    └── Поддержка

Owner/Admin — отдельное приложение
├── Заявки
│   ├── Очередь
│   └── Карточка + история → approve / reject
├── Агенты
│   ├── Список
│   └── Профиль → campaigns/materials → suspend / restore
├── Attribution
│   ├── Decisions
│   ├── Timeline click→start→identity→decision→CRM
│   └── Pending verification / fraud review
├── CRM
│   ├── Delivery status
│   ├── Retry / dead letter
│   └── Reconciliation
└── Аудит
    └── Append-only administrative events
```

Agent navigation всегда содержит ровно четыре продуктовых раздела. На `≤767 px` это bottom navigation; на desktop — side navigation. Onboarding и access states находятся до AppShell и не создают пятый раздел.

Admin navigation отдельная, desktop-first. На узком экране она сворачивается в горизонтально прокручиваемый список разделов; опасные действия не прячутся только в hover или необозначенный overflow.

## 3. Главные потоки

### 3.1. Регистрация и модерация

```mermaid
flowchart LR
  W[О программе] --> F[Анкета]
  F --> S[Отправка]
  S --> P[На рассмотрении]
  P -->|approve| A[Одобрено]
  P -->|reject + reason| R[Отказ]
  R --> E[Исправить анкету]
  E --> S
  A --> C[Открыть кабинет]
  C -->|owner suspend| X[Доступ приостановлен]
```

Primary action меняется только по состоянию: «Начать регистрацию» → «Отправить на проверку» → отсутствует в pending → «Исправить анкету» → «Открыть кабинет». Причина отказа/блокировки и способ связи всегда видны до CTA.

### 3.2. Создание комплекта

```mermaid
flowchart LR
  C[Создать] --> V{Валидация}
  V -->|ошибка| C
  V -->|валидно| S[Создаём один раз]
  S -->|ошибка| R[Retry с сохранённой формой]
  R --> S
  S --> G[Страница созданной ссылки: link + QR]
  G --> L[Скопировать ссылку]
  G --> Q[Скачать QR]
  G --> N[Создать ещё]
```

До submit нет фальшивого готового URL. На всех ширинах после success открывается отдельная страница созданной ссылки, где доступны copy и download QR; экран «Создать» содержит только форму. Повторный submit возвращает исходный результат и не создаёт дубль.

### 3.3. Библиотека и архив

Список → search/filter → campaign detail → copy/download/statistics. На mobile весь элемент списка является одной ссылкой на detail; быстрые кнопки «Скопировать», «QR» и «Открыть» отсутствуют. «Архивировать» открывает protected confirmation с конкретным последствием: кампания уйдёт из активного списка, но обе ссылки продолжат работать. Agent delete отсутствует.

### 3.4. Статистика

Период хранится в URL. Порядок: определение метрики и freshness → один dominant total → link/QR split → стабильная область trend → data-table alternative → campaign breakdown. На mobile кампании показаны списком без быстрых кнопок; тап открывает страницу ссылки. Link и QR могут пересекаться по visitor key, поэтому UI не обещает, что две части всегда равны total.

### 3.5. Admin moderation и dangerous actions

Queue → application detail + revision history → approve либо reject. Reject всегда требует reason. Suspend agent и disable material используют отдельные confirmations с consequence, reason и typed action; успешное действие добавляет запись в audit timeline.

### 3.6. Investigation и CRM reconciliation

Decision search → detail timeline `material → click → bot start → identity checks → outcome → outbox → CRM attempts`. Pending case можно retry/reconcile только при elevated permission. UI не предлагает обычный UPDATE attribution; manual correction отсутствует в V1.

## 4. Экранный реестр и иерархия

### Partner bot / access

| Screen | Первый смысловой блок | Primary action | Обязательные состояния |
|---|---|---|---|
| Welcome | Что получает партнёр и что потребуется | Начать регистрацию | initial, offline |
| Application | Identity summary → обязательные поля → добровольные каналы → consent | Отправить на проверку | validation, submitting, recoverable error |
| Pending | Статус → что происходит дальше → submitted timestamp | — | normal, stale |
| Rejected | Причина → что исправить → revision history | Исправить анкету | normal |
| Approved | Доступ открыт → следующий шаг | Открыть кабинет | normal |
| Suspended | Причина → последствия → поддержка | Написать в поддержку | normal, permission denied |
| Desktop auth | Browser/device context → одноразовость → TTL | Подтвердить вход | waiting, confirmed, expired, consumed |
| Session expired | Объяснение → сохранность формы | Войти снова | normal |
| Fatal error | Что не удалось → correlation ID | Повторить | retry unavailable |

### Agent cabinet

| Screen | Иерархия | Primary action | Обязательные состояния |
|---|---|---|---|
| Создать | Intro → CampaignForm → created Campaign detail | Создать ссылку и QR | initial, validation, submitting, recoverable/fatal, offline |
| Мои ссылки | Search → filters → count → mobile tappable list/desktop rows | Создать | list, loading, empty, filtered-empty, error |
| Campaign detail | Identity/status → two materials → actions → summary | Скопировать ссылку | active, archived, disabled_by_owner |
| Archive confirm | Consequence → campaign name | Архивировать кампанию | submitting, error |
| Статистика | Definition/freshness → period → total → split → trend/table → campaigns | — | loading, zero, stale, error |
| Campaign analytics | Campaign identity → total → link/QR → trend/table | — | loading, zero, stale |
| Профиль | Editable contact → channels → support | Сохранить изменения | default, editing, saving, saved, validation/error |

### Owner/admin

| Screen | Иерархия | Primary / protected action | Обязательные состояния |
|---|---|---|---|
| Admin auth | Identity/MFA explanation | Продолжить через Telegram | waiting, denied, expired |
| Applications | Filters → queue count → rows | — | loading, empty, error |
| Application detail | Applicant → current revision → channels → moderation timeline | Одобрить | pending, approved, rejected; concurrent conflict |
| Reject confirm | Reason taxonomy → owner-visible comment → consequence | Отклонить заявку | validation, submitting, conflict |
| Agents | Search/status → rows | — | loading, empty, error |
| Agent detail | Status → profile → campaigns/materials → admin history | — | approved, suspended |
| Campaign/material detail | Campaign lifecycle отдельно от availability каждого link/QR | — | active campaign, archived campaign, mixed material status |
| Suspend/restore | Consequence → reason → material fallback | Приостановить / восстановить | submitting, conflict |
| Material disable | Material identity → current traffic → consequence → reason | Отключить материал | submitting, conflict |
| Attribution decisions | Outcome filters → search → rows | — | loading, empty, stale/error |
| Decision detail | Correlated append-only timeline → reason/rule → evidence refs | — | assigned, rejected, pending, flagged |
| Review queue | SLA/age → cases → evidence | Взять в проверку | loading, empty, conflict |
| CRM delivery | Lag summary → attempts → dead letter | Retry selected | stale, provider down, permission denied |
| Reconcile detail | Business outcome → attempts → proposed safe action | Запустить reconciliation | validation, submitting, result |
| Audit log | Time/actor/action/resource filters → append-only events | Экспорт | loading, empty, error |

## 5. Responsive topology

| Область | 360/390 px | Tablet | Desktop |
|---|---|---|---|
| Agent shell | Single column; sticky four-item bottom nav; safe-area padding | Bottom nav до 767 px | 224–248 px side nav + flexible content |
| Create | Form → submitting → отдельная страница созданной ссылки | Тот же последовательный flow | Только форма; результат всегда на Campaign detail |
| Library | Один tappable campaign item; без quick actions | Одна строка при доступной ширине | Одна горизонтальная строка: identity → status → unique clicks → quick actions |
| Statistics | Summary → split → chart → table → tappable campaign list без quick actions | То же, шире chart | Chart и split используют shared group; campaigns ниже |
| Profile | Editable contacts → channels → support | Одна содержательная колонка | Одна содержательная колонка без отдельного system rail |
| Onboarding | Полноэкранный step, один CTA у нижнего края контента | Centered readable column | Centered 640–720 px column, не dashboard shell |
| Admin | Не primary use case; compact top sections, stacked rows, no hidden actions | Collapsible nav + stacked detail | Persistent side nav; queue/detail могут использовать master-detail только ≥1180 px |
| Dialog | Bottom sheet semantics без drag-only action | Centered dialog | Centered dialog, focus trap/return |

Breakpoints определяются содержимым: `768 px` меняет agent navigation, `980 px` разрешает двухколоночные task groups, `1180 px` разрешает admin master-detail. Минимальная ширина — 320 px; целевые проверки — 360, 390, 768, 1280 и 1440 px.

## 6. Low-fi component grammar

- `PrototypeBar` существует только в review artifact и не входит в продукт.
- `AccessShell`, `AgentShell`, `AdminShell` физически различаются.
- `BottomNavigation` и `SideNavigation` содержат текстовые labels.
- `CampaignForm`, `CampaignCreatedState`, `LinkField`, `QRPlaceholder`, `MaterialActions`.
- `SearchField`, `FilterGroup`, `CampaignRow`, `CampaignDetail`.
- `MetricSummary`, `PeriodControl`, `TrendPlaceholder`, `DataTable`.
- `StatusBadge`, `Timeline`, `AuditEvent`, `CorrelationBlock`.
- `InlineError`, `Skeleton`, `EmptyState`, `FatalState`, `AccessState`.
- `ConfirmationDialog` для archive и dangerous admin actions; local feedback для copy/download; global live region только для фонового результата.

Grayscale semantics: статус всегда имеет текст и/или паттерн, не только тон серого. QR и chart — структурные placeholders, не декоративные иллюстрации. Фото заменено подписанным placeholder только там, где на B3 действительно появится утверждённое изображение.

## 7. Interaction, URL state и доступность

- Review URL: `?surface=access|agent|admin&screen=...&state=...`; period/search/filter также сериализуются при значимом изменении.
- Back/forward восстанавливает surface, screen и state; прямой URL открывает нужное состояние.
- Первый `h1`, landmark и document title меняются при навигации; после route change focus перемещается на `h1`, кроме browser back.
- Navigation сообщает current item через `aria-current=page`.
- Segmented controls используют native buttons и `aria-pressed`; list/detail disclosure — `aria-expanded`.
- Dialog получает initial focus, `Escape` закрывает, Tab не выходит наружу, после закрытия focus возвращается trigger.
- Ошибка поля связана через `aria-describedby`; введённые данные не стираются.
- Loading skeleton имеет короткую задержку в production; прототип показывает структуру явно через state selector.
- Trend имеет доступное текстовое summary и data table; tooltip не является единственным способом получить значение.
- Все интерактивные цели не меньше 44×44 px; важное действие доступно без hover.
- `prefers-reduced-motion` убирает smooth scroll и transforms; B2 не содержит декоративной анимации.

## 8. Что отвергнуто на B2

- существующий цветной `web/layoutboard` как gate deliverable: он смешивает cobalt/lime visual direction, показывает только четыре happy-path agent screen и не покрывает onboarding/admin/error states;
- dashboard home с KPI-плитками: не соответствует главной задаче «создать комплект»;
- agent/admin в одном меню: нарушает permission boundary;
- success/result внутри экрана «Создать»: после submit рабочие материалы открываются на отдельной Campaign detail;
- desktop table, ужатая на mobile: mobile использует самостоятельную list topology;
- client/application funnel в agent V1: до отдельного privacy/product решения агент видит только aggregate clicks;
- буквенные platform marks как финальные assets: на B2 это только grayscale placeholders, на B3 — проверенные official marks.

## 9. Карта прототипа

PrototypeBar позволяет открыть каждый surface/screen/state без скрытых debug-команд. Основные кликабельные маршруты:

- access: welcome → application → submitting → pending → rejected/resubmit либо approved → agent create;
- agent: create → created campaign detail на всех ширинах; links → tappable detail → archive confirmation; statistics → tappable campaign detail; profile → edit/save;
- admin: applications → detail → approve/reject; agents → detail → suspend/material disable; attribution → decision timeline/review; CRM → reconciliation; audit;
- state selector: loading, empty, validation, offline, expired, permission denied, recoverable и fatal там, где это применимо.

Illustrative names, counts, URLs и correlation IDs явно помечены как демонстрационные. Прототип не вызывает API, Telegram, CRM, clipboard или download.

QA прототипа: 103 из 103 `surface/screen/state` routes открываются с одним `main`, одним `h1`, без duplicate IDs и page-level horizontal overflow на desktop. Все 51 owner/admin states дополнительно проверены на 900 и 1280 px; agent links — на 768, 900, 1120, 1280 и 1440 px. Отдельно проверены 360/390 px access, agent и admin layouts; create → created detail, dialog focus trap/return, background isolation, inline validation и keyboard navigation PlatformPicker.

## 10. Что предлагается утвердить

1. Две изолированные product shells: agent и owner/admin; onboarding/access до agent shell.
2. Ровно четыре agent-раздела и «Создать» как стартовый экран approved agent.
3. Иерархию каждого экрана и порядок главных действий из раздела 4.
4. Responsive topology из раздела 5, включая отдельную mobile list-модель.
5. Набор обязательных UI/access/error states и их тексты восстановления.
6. Admin investigation timeline как главный способ доказать attribution decision.
7. Archive и owner-disable как разные protected flows.

После явного утверждения B2 допустим B3: применение утверждённой B1-системы, лицензированных фото и official platform assets к этой структуре. До этого текущие production UI, `DESIGN.md` и backend не переписываются.