Пассажир
Создаёт заказ, видит собственные поездки, статусы и безопасные детали назначения.
- addresses
- airport points
- orders
- notifications
- referrals
02Operational Full Stack Platform
Operational flagship · AirCrew / 787 AirClub
787 AirClub — Airport Transfer Operations Platform
Web/PWA-платформа для закрытого контура аэропортовых трансферов: пассажиры, водители и операционная команда работают в связанных, но разделённых интерфейсах.
- Web/PWA
- 4 role contours
- Trip lifecycle
- Operations
- Production delivery
Краткое резюме проекта
- Продукт
- Airport transfer operations platform
- Контуры
- Passenger · Driver · Dispatcher · Admin
- Роль
- Product, Full Stack, data, integrations, delivery
- Статус кейса
- Public-safe · без production data
01 · Business problem
Связать self-service и операционный контроль
Операции аэропортовых трансферов нельзя свести к одной форме заказа: нужны разные права, статусы, правила назначения, тарифные справочники, уведомления и ручной контроль исключений.
- Дать пассажиру спокойный мобильный flow без внутренних операционных терминов.
- Дать водителю доступ только к подходящим свободным и собственным заказам.
- Сделать диспетчерские исключения и административные справочники наблюдаемыми.
- Сохранить целостность lifecycle, финансовых снимков и аудита действий.
02 · User roles
Четыре разделённых контура
Водитель
Управляет доступностью, берёт подходящий заказ и проходит разрешённые статусы поездки.
- availability
- order board
- assignment
- trip progress
- own finance
Диспетчерский контур
Наблюдает проблемные и ожидающие заказы и помогает разбирать исключения.
- operations queue
- assignment context
- exceptions
- notifications
Администратор
Управляет пользователями, водителями, зонами, аэропортовыми точками, тарифами и финансовым учётом.
- RBAC
- directories
- tariffs
- finance ledger
- audit
03 · Passenger flow
Заказ без внутренних операционных деталей
Пассажирский flow
Пассажир
- 01
Направление
В аэропорт или из аэропорта
- 02
Адрес и точка
Понятные пассажиру stops
- 03
Время и состав
Дата, время и пассажиры
- 04
Создание заказа
Серверная проверка и lifecycle
- 05
Статус
Ожидание, водитель найден, поездка
- 06
Завершение
История и уведомления
04 · Driver flow
Доступность, assignment и поездка
Водительский flow
Водитель
- 01
Доступность
Рабочий статус и зона
- 02
Доска заказов
Только доступный scope
- 03
Принять заказ
Проверка назначения
- 04
Подача
Разрешённый transition
- 05
В пути
Операционный статус
- 06
Завершить
Финансовый snapshot и audit
05 · Dispatcher & admin
Операции, справочники и исключения
Нормальные сценарии остаются self-service. Диспетчерский и административный контуры предназначены для видимости, настройки и исключений.
- сводка проблемных и ожидающих заказов
- назначение и освобождение водителя
- управление ролями и доступом
- зоны и аэропортовые точки
- тарифные правила
- финансы, отчёты и audit trail
06 · Ride lifecycle
Контролируемые переходы состояний
Пользовательские статусы выводятся из серверного состояния заказа, назначения водителя и audit events; интерфейс не создаёт декоративные состояния.
Lifecycle поездки
- 01
Создан
Заказ прошёл validation
- 02
Ожидаем водителя
Доступен подходящим водителям
- 03
Водитель найден
Assignment подтверждён
- 04
Подача
Водитель следует к пассажиру
- 05
В поездке
Активный маршрут
- 06
Завершён
Финальный статус и учёт
07 · Pricing & zones
Внутренние зоны, понятный пассажирский маршрут
Пассажир выбирает адрес и аэропортовую точку. Зоны остаются внутренними единицами matching, positioning и тарифной логики.
- канонические зоны и airport points
- направление и количество пассажиров
- server-side price/quote contracts
- admin-managed tariff rules
- никаких неподтверждённых цен в интерфейсе
- ручная корректировка только через контролируемый workflow
08 · Finance model
Снимки поездки и append-only ledger
Финансовый слой строится на зафиксированных снимках поездки и append-only ledger, а не на пересчёте истории в интерфейсе.
- fare, service commission и driver income snapshots
- personal/group/default commission source
- manual adjustment с обязательной причиной
- driver commission accrual/payment tracking
- read-only reports и CSV
- без acquiring, банковских выплат и налогового контура
09 · Architecture
Пять связанных слоёв платформы
Разделённые интерфейсы используют общие контракты application-слоя, единую реляционную модель и изолированные интеграционные адаптеры.
- 01
Experience
Passenger, driver, dispatcher и admin interfaces.
- Next.js
- React
- responsive PWA
- role-aware states
- 02
Application
Заказы, поездки, роли, назначения и переходы состояний.
- NestJS
- REST API
- RBAC
- validation
- Socket.IO
- 03
Data
Реляционные модели, миграции, audit и finance ledger.
- PostgreSQL
- Prisma
- migrations
- transactions
- indexes
- 04
Integrations
Уведомления, Telegram gateway и внешние provider boundaries.
- webhooks
- signed callbacks
- realtime
- provider adapters
- 05
Delivery
Сборка, проверки, release identity и эксплуатационные runbooks.
- Docker
- Linux
- CI/CD
- health checks
- backups
10 · Infrastructure
Delivery и поддерживаемая эксплуатация
Production delivery разделяет frontend, backend и data responsibilities, проверяет release identity и сохраняет воспроизводимые recovery steps.
- Next.js frontend и NestJS backend
- PostgreSQL/Prisma migrations
- Docker/Linux runtime
- HTTPS/reverse proxy boundary
- CI gates и immutable build identity
- live/ready health checks
- monitoring, backups и rollback documentation
11 · Responsibility
Product, Full Stack и release engineering
Моя зона ответственности охватывает продуктовые сценарии, full stack реализацию и безопасную доставку изменений.
- 01
Product model
Роли, пользовательские flows, truthful states и границы MVP.
- 02
Backend & data
API, business rules, Prisma models, migrations и audit.
- 03
Role interfaces
Passenger, driver, operations и admin UX.
- 04
Release engineering
Tests, builds, smoke, deployment и recovery evidence.
15 · Публичные интерфейсы
Ролевые интерфейсы платформы
Кадры из явно помеченного demo-окружения. Все значения синтетические; production data не использовались.
04 · Privacy reviewed
12 · Public boundary
Что намеренно остаётся закрытым
Публичный кейс показывает устройство продукта, но не открывает эксплуатационные данные или чувствительную конфигурацию.
- только synthetic/demo screenshots
- без реальных пассажиров, водителей и поездок
- без балансов, invite/referral codes и номеров машин
- без IP, доменов, credentials, logs и secrets
- без неподтверждённых метрик или fleet claims
- внутренние security/deployment детали обобщены