DZ Hub — MVP

Статус: договорились 2026-10-02. Здесь только то, что уже обсудили и приняли. Открытые вопросы собраны в конце.

Зачем

Сейчас аэродром работает через Telegram-группу и Excel. Анонс дня пишут в группу, люди ставят 👍, а чтобы узнать, есть ли место во взлёте, нужно спрашивать организатора.

DZ Hub делает это видимым для всех: парашютист сам видит прыжковый день и взлёты и записывается, а организатор управляет всем из одной панели.

Принципы

1. Система подсказывает, организатор решает. Допуск к прыжку даёт только организатор, он же несёт ответственность. Система лишь предупреждает по данным, которые у неё есть, и никогда не блокирует сама.
2. Данным системы нельзя доверять на 100%. Человек мог не пользоваться системой, данные могли устареть. Интерфейс показывает, насколько данные свежие.
3. Работает, даже если человек не зарегистрирован. Организатор сам добавляет любого (например, тандем-пассажира с улицы).
4. Всё по факту, никакой автоматики с людьми. Нет листа ожидания: если мест нет, человек ждёт следующий взлёт и записывается на него. Человек может проспать, поэтому решения принимаются на месте.
5. Сайт и Telegram на равных. Это два входа в одну систему, вся логика живёт в бэкенде.

Части системы

 Сайт ─┬─ кабинет парашютиста ──┐
       └─ панель организатора ──┼──► Бэкенд (API) ──► База данных
 Telegram-бот ──────────────────┘         └──► Уведомления (Telegram, email)

Словарь

Термин	В коде	Что это
Прыжковый день	jump_day	День полётов: дата, время начала, разрешённые типы прыжков
Взлёт	load	Один подъём самолёта в рамках прыжкового дня
Самолёт	aircraft	Название, бортовой номер, количество мест
Группа на борту	load_group	Кто прыгает вместе: соло, тандем, AFF
Тип прыжка	jump_type	solo, tandem, aff
Права	role	Что человек может делать в системе
Допуск	qualification	Что человек может делать в небе

Права и допуски

Это разные вещи: у одного человека одна роль в системе, но может быть несколько допусков.

Права в системе	Допуски
Организатор: управляет днями, взлётами, допуском	Тандем-мастер
Парашютист: записывается, видит свой кабинет	Инструктор AFF
	Коуч
	Видеооператор
	AFF-студент
	AFF соло (прошёл уровни AFF, прыгает сам, ещё без лицензии)
	Соло (с лицензией)

Допуск человек может указать сам, но в силу он вступает только после подтверждения организатором.

Истории MVP

1. Регистрация и вход. Через Telegram или по email. У человека один аккаунт с несколькими способами входа.
2. Права и допуски, как в таблице выше.
3. Прыжковый день. Организатор создаёт день: дата, время начала, разрешённые типы прыжков (например, сегодня только тандемы и соло). Участники получают уведомление.
4. Запись на день («я приеду») с выбором типа прыжка: кнопками под анонсом в Telegram или на сайте. Доступны только типы, разрешённые в этот день.
5. Самолёты. Организатор заводит самолёт в админке. Количество мест — настраиваемое.
6. Взлёт. Организатор создаёт взлёт в рамках дня с выбранным самолётом, парашютисты записываются на него.

Запись на взлёт

• Режим задаётся на прыжковый день, но для отдельного взлёта его можно поменять:
• автоматический: место сразу подтверждено, если оно есть;
• с подтверждением: запись ждёт решения организатора.
• Если мест нет, записаться нельзя.
• Организатор в любом режиме может снять человека или перенести на другой взлёт.
• Места занимает группа: соло — 1, тандем — 2 (+1 с видеооператором), AFF — студент и 1–2 инструктора.

 Авто:             запись ──(есть места)──► подтверждена
 С подтверждением: запись ──► ждёт решения ──► подтверждена / отклонена

Схема сущностей

erDiagram
    aircraft ||--o{ load : "летит"
    jump_day ||--o{ load : "состоит из"
    jump_day ||--o{ day_attendance : "«я приеду»"
    user ||--o{ day_attendance : ""
    load ||--o{ load_group : "на борту"
    load_group ||--o{ load_participant : ""
    user |o--o{ load_participant : "может быть без аккаунта"
    user ||--o{ qualification : "допуски"

Не входит в MVP

Оплата, учёт снаряжения и переукладок, погода, видео, статистика прыжков.

Открытые вопросы

1. Сколько мест в самолёте и сколько взлётов в день на нашем аэродроме (в системе это всё равно настраивается).
2. Что лежит в Excel организатора: стоит посмотреть вместе с ним.
3. Кто записывает тандем-пассажиров и AFF-студентов: организатор, инструктор или они сами?
4. Как показывать организатору предупреждения о допусках, если данных мало.

На будущее

Идеи и решения, которые обсудили, но отложили.

Очная верификация на дропзоне

В профиле человек пишет о себе что хочет: уровень, опыт, допуски. Но на каждой дропзоне он обязательно проходит очную проверку: пришёл, показал логбук и документы, организатор подтвердил анкету. Только после этого он числится на дропзоне со своим уровнем, количеством прыжков и ролями.

• Флоу на сайте: парашютист «стучится» в дропзону → его уровень и роли на этой дропзоне ждут подтверждения → организатор проходит визард ревью парашютиста.
• Дропзона хранит копию данных на момент проверки, а не ссылку на профиль. Если человек потом поменяет профиль, на дропзоне останутся проверенные значения; можно подсветить «профиль изменился после проверки».
• Модель профиля это уже учитывает: в skydiver_profiles и skydiver_ratings хранятся только заявленные данные, никаких полей «подтверждено».

Проверка, приезд и запись во взлёт

Обсудили 2026-10-04. Главный принцип: организатор видит только исключения. Всё, что система может проверить сама, проходит молча. В панель попадает только то, где нужно решение человека, и всегда с причиной.

 Первый приезд            Прыжковый день           Взлёт
 ─────────────            ──────────────           ─────
 «стучусь» в DZ    →      «я приеду»         →     запись
      │                        │                     │
 визард проверки:          отметка «на месте»:    все условия ок? ──да──► подтверждено
 профиль, допуски,         1 тап организатора        │нет
 логбук, предупреждения    или QR на стойке          ▼
      │                    манифеста             ждёт организатора
 approve / approve с                              (с причиной: «нет допуска AFF»,
 правками / reject                                 «перерыв 120 дней»)
      │
 снимок данных
 сохраняется на DZ

1. Проверка при первом приезде. Человек «стучится» в дропзону. Проверка проходит очно, визард только помогает: показывает профиль, допуски, логбук и предупреждения. В конце организатор выбирает approve, approve с правками или reject. При правках исправленные значения попадают в снимок дропзоны, профиль человека не меняется. В схеме это таблица dropzone_members: статус, снимок данных, кто проверил и когда.
2. Отметка «на месте». Запись на прыжковый день ещё не значит, что человек приехал. Отметка должна быть ненавязчивой: один тап организатора в списке дня или QR-код на стойке манифеста. Геолокацию не используем: она навязчивая и ненадёжная. В схеме это время отметки в записи на день (day_attendance).
3. Автоподтверждение во взлёт. Срабатывает, только если всё сошлось: человек проверен на этой дропзоне, отмечен сегодня, у него есть допуск под этот тип прыжка, нет долгого перерыва. Иначе запись ждёт организатора и показывает причину. Режим «только через организатора» остаётся настройкой дня или взлёта (см. «Запись на взлёт»).

Связь типа прыжка и роли в логбуке

Сейчас тип прыжка и роль в записи логбука не связаны: можно записать тандем с ролью «коуч». Идея — разрешать только подходящие роли. Черновик таблицы (нужно проверить):

Тип прыжка	Допустимые роли
aff, iad	студент, инструктор, видеооператор
static_line	студент
tandem	пассажир, тандем-инструктор, видеооператор
belly, freefly, tracking, wingsuit	участник, студент, коуч, видеооператор
hop_and_pop, accuracy	участник, студент
crw, canopy_piloting	участник, студент, коуч
other	любая

• Тип не указан → роль любая. PATCH проверяется по итоговому состоянию.
• Фронтенд берёт таблицу со справочного эндпоинта GET /api/v1/logbook/jump-types (один источник правды — бэкенд).
• Открытые вопросы: правильность таблицы; разрешать ли роль без типа; нужен ли токен для справочника.

Наземные и лётные роли

Укладчик, риггер, пилот — не обязательно парашютисты, поэтому им не нужен уровень licensed. Когда понадобятся, правило «допуск требует licensed» станет зависеть от роли.

Расхождения с USPA

Сравнили профиль, допуски и логбук с документами USPA. Нашли 10 расхождений: главное — licensed вместо классов лицензий A–D. Список и предложение по порядку — в USPA_GAPS.md, справка по правилам USPA — в USPA.md.

Слежение за новыми редакциями USPA

Запланированный агент раз в месяц проверяет uspa.org. Если вышла новая редакция SIM или IRM, он создаёт в Trello карточку «Обновить справочник»: сверить справочник терминов и USPA_GAPS.md с новой редакцией.

Подсказки по куполу

Отдельный инструмент: по весу парашютиста, числу прыжков и размеру купола подсказывать, подходит ли купол по нагрузке (таблица минимальных размеров USPA SIM 4-3 — в USPA.md). Для этого понадобится размер основного купола числом. Пока в логбуке снаряжение — только текстовое поле canopy (решено 2026-10-03, карточка «Add USPA-required fields to the logbook»).