> Пометка Claude, 12.10.2026 — перед передачей в разработку. Текст ТЗ — как утвердил основатель > (из переписки с ChatGPT, «Штаб» → «Закулисье»). Реальное состояние на сегодня: > сайта с формами и базой пока нет. Есть статические прототипы (шаблоны/Лендинг.html, > Страница мастер-класса.html, Стать наставницей.html, Команда.html) и пульт на обычном хостинге > (rusgoncharov.ru/svetlitsa/, Timeweb). Формы никуда не отправляют данные, авторизации и сервера приложения нет. > Поэтому этап 0 «Аудит» начинается с решения основателя: где живут данные — свой сервер (PHP/Python + база > на хостинге в РФ), готовый сервис (Camp Control и т. п.) или на самом старте таблица. Связано с пунктом роудмэпа > «Подключить формы записи к базе» и с юр. пакетом (юр/, согласия; данные граждан РФ хранятся в РФ). > Отдельно нужны: домен Светлицы и выбор платёжного сервиса с чеками.
Проект: Светлица Тип системы: внутренняя административная панель, интегрированная с существующим сайтом. Статус: MVP для запуска первых мастер-классов. Главный принцип: минимальная сложность при достаточной функциональности.
«Закулисье Светлицы» — небольшая внутренняя система, позволяющая команде самостоятельно организовывать мастер-классы, принимать регистрации, учитывать оплаты, работать с участницами и их родителями, фиксировать посещения и сохранять историю взаимодействия с семьями.
Система должна быть непосредственно связана с существующим сайтом «Светлицы».
На сайте уже существуют:
Перед разработкой необходимо изучить существующий код, архитектуру, используемый стек и способ хранения данных.
Не создавать новый сайт. Не переписывать существующие компоненты без необходимости.
На данном этапе не требуется:
Система состоит из двух частей.
Существующий сайт «Светлицы»:
Административная панель «Закулисье Светлицы».
Доступна только авторизованным участницам команды.
Предлагаемая структура:
Сайт → Регистрация → Хранилище данных → Закулисье Светлицы.
При подключении оплаты:
Регистрация → Платёжный сервис → Подтверждение оплаты → Обновление записи в Закулисье.
Использовать существующий технологический стек сайта.
Не вводить отдельный сервер или сложную инфраструктуру, если текущая архитектура позволяет обойтись без этого.
Предпочтительны:
Допускается использование SQLite или существующей базы данных проекта, если это соответствует инфраструктуре и предполагаемой нагрузке.
Не создавать отдельный микросервис без необходимости.
Не использовать локальное хранилище браузера как основное место хранения заявок.
Данные должны сохраняться на сервере и быть доступны авторизованной команде с разных устройств.
Главное архитектурное решение:
Семья → Дети → Регистрации → Мероприятия.
Это позволяет избежать создания новой независимой карточки человека при каждом посещении.
Основная единица клиентской базы.
Поля:
На первом этапе достаточно одного основного контактного лица.
В будущем допускается добавление второго родителя.
Каждая девочка привязана к семье.
Поля:
В карточке ребёнка автоматически отображается история посещений.
Не собирать медицинские, психологические и другие чувствительные сведения без отдельной обоснованной необходимости и надлежащего оформления.
Поля:
Статусы:
Связующая сущность между ребёнком и мероприятием.
Поля:
Важно: статус регистрации, статус оплаты и статус посещения должны храниться отдельно.
Например, девочка может быть зарегистрирована и оплатить участие, но не прийти.
Или семья может отменить регистрацию после оплаты.
Система должна предотвращать случайное создание двух активных регистраций одного ребёнка на одно мероприятие.
После авторизации пользователь попадает на главную страницу.
Отображаются:
Ближайшие мероприятия
Для каждого:
Новые заявки
Количество необработанных регистраций.
Краткая статистика
Не создавать сложные графики.
Главная задача дашборда — за несколько секунд понять, что происходит в проекте.
Отображать мероприятия в виде карточек или таблицы.
Фильтры:
Команда должна самостоятельно создавать новое мероприятие.
Не требуется участие разработчика.
При создании указываются основные поля мероприятия.
Дополнительно желательно предусмотреть возможность дублирования существующего мероприятия.
Например:
«Каллиграфия. 15 ноября» → «Каллиграфия. 29 ноября».
При дублировании копируются основные настройки, но не регистрации и оплаты.
Главный рабочий экран организатора.
В верхней части:
Ниже — показатели:
Записано: 12 / 15
Оплачено: 9
Ожидают оплаты: 3
Далее — список участниц.
Колонки:
| Девочка | Родитель | Контакт | Оплата | Посещение | Комментарий |
|---|---|---|---|---|---|
Действия:
Обязательная функция.
Например, мама позвонила и попросила записать дочь.
Или захотела привести сестру.
Организатор должен иметь возможность:
Если семья новая — создать её прямо в процессе.
Не заставлять организатора переходить через множество экранов.
Родитель открывает страницу мастер-класса.
Нажимает кнопку «Записаться».
Заполняет форму.
Минимальные поля:
Email — необязательное поле, если он не требуется для выбранного способа оплаты и отправки документов.
После отправки:
Отправка формы не означает автоматического подтверждения оплаты.
На странице необходимо чётко сообщать статус записи.
Например:
«Ваша заявка получена. Для подтверждения участия необходимо оплатить мастер-класс».
Текст должен соответствовать реальной схеме регистрации.
Если телефон уже есть в базе, система должна попытаться найти существующую семью.
Не создавать автоматически новую семью при каждом обращении.
При этом нельзя раскрывать историю семьи или персональные данные только на основании введённого номера телефона.
При неоднозначном совпадении необходимо предусмотреть ручную проверку организатором.
Если родитель хочет записать двух сестёр, система должна поддерживать две регистрации на одно мероприятие, привязанные к одной семье.
На первом этапе допустимо добавлять вторую девочку через административную панель.
В публичной форме возможность записи нескольких детей можно реализовать позднее.
Не разрабатывать собственный платёжный механизм.
Использовать существующий или выбранный платёжный сервис.
Система должна учитывать:
Не хранить реквизиты банковских карт.
Допускается ручное подтверждение оплаты уполномоченным сотрудником после сверки с платёжным сервисом или банком.
Это позволяет запустить систему без сложной интеграции.
При этом сам приём платежей должен осуществляться законным способом с необходимой фискализацией и выдачей чеков.
Если выбранный платёжный сервис поддерживает API и webhook, реализовать автоматическое обновление статусов.
Обязательные требования:
После успешной оплаты родитель должен попадать на страницу подтверждения.
На ней:
Если подтверждение от платёжного сервиса ещё не поступило, отображать статус «Проверяем оплату», а не «Оплачено».
Отображать:
Поиск по имени и телефону.
В карточке:
Контакты
Имя родителя, телефон, email, предпочтительный способ связи.
Дети
Список девочек, привязанных к семье.
История участия
Все регистрации на мероприятия.
Комментарии
Краткие заметки команды.
Например:
«Интересуются летним лагерем».
«Понравилась каллиграфия, хотят прийти на следующий мастер-класс».
«Удобнее мероприятия по выходным».
Комментарии должны быть доступны только уполномоченным сотрудникам.
Не использовать карточку семьи для хранения необоснованных субъективных характеристик родителей или детей.
Команда должна самостоятельно:
Удаление или объединение записей должно быть защищено от случайных действий.
На первом этапе не требуется интеграция с мессенджерами.
В карточке семьи предусмотреть удобные действия:
Ссылки должны открывать соответствующее приложение или интерфейс.
Не предполагать, что по одному номеру телефона всегда можно открыть диалог в конкретном мессенджере.
На первом этапе достаточно комментариев.
Например:
«12 ноября — отправили информацию о мастер-классе».
«13 ноября — мама подтвердила участие».
Автоматическую синхронизацию переписок не делать.
Предусмотреть несколько готовых текстов с возможностью копирования:
Шаблоны должны быть доступны команде для редактирования без изменения кода.
Автоматические рассылки на первом этапе не требуются.
Рекламные и информационные сообщения отправлять с учётом необходимых согласий и применимых правил коммуникации.
Поскольку на сайте уже существует форма для потенциальных наставниц, необходимо обеспечить сохранение таких заявок.
Создать отдельный простой раздел «Команда».
Поля:
Статусы:
Не создавать полноценную HR-систему.
Необходимые показатели:
На первом этапе это показатели движения денег по мероприятиям, а не полноценный бухгалтерский или управленческий финансовый отчёт.
Расходы допускается учитывать отдельно.
Не создавать сложную финансовую модель внутри системы.
Минимальные роли:
Администратор
Организатор
На первом этапе не создавать более сложную ролевую систему.
Однако доступ к контактам семей, данным детей и платежам должен предоставляться только тем участникам команды, кому он необходим.
Обязательные требования:
Не допускать доступ к административной панели через простой секретный URL без авторизации.
Обязательные требования:
Для персональных данных необходимо определить законное основание обработки, необходимые согласия, сроки хранения, порядок удаления и права доступа. Также проверить применимые требования к размещению и обработке данных граждан РФ.
Стиль:
Основной сценарий — работа с ноутбука.
Обязательно обеспечить удобное использование со смартфона.
Особенно важно на телефоне:
Не создавать отдельное мобильное приложение.
Любая типовая операция должна выполняться быстро и без необходимости обращаться к разработчику.
Перед написанием кода:
Не начинать переписывать архитектуру до завершения аудита.
Реализовать:
Это первая рабочая версия.
На основании реального использования:
Не добавлять функции только потому, что их легко реализовать.
Рассмотреть:
Реализовывать только при подтверждённой необходимости.
MVP считается готовым, если команда без участия разработчика может выполнить следующие действия.
Мама впервые открывает сайт, записывает дочь на мастер-класс.
Заявка появляется в Закулисье.
Организатор видит контакт и статус регистрации.
Мама записывает ту же девочку на другое мероприятие.
Система связывает регистрацию с существующей семьёй.
История посещений сохраняется.
Мама хочет записать двух дочерей.
Организатор создаёт две регистрации, связанные с одной семьёй.
Мама оплачивает мероприятие через согласованный платёжный сервис.
Организатор видит подтверждение оплаты или вручную отмечает его после проверки.
Система не считает неоплаченную заявку оплаченной.
Организатор открывает список участниц со смартфона.
Отмечает, кто пришёл.
При необходимости открывает контакт родителя.
Родитель отменяет участие.
Организатор изменяет статус регистрации.
При необходимости отдельно отражает возврат средств.
Место освобождается в соответствии с правилами регистрации.
Организатор самостоятельно создаёт новый мастер-класс.
Публикует его на сайте.
Открывает регистрацию.
Для этого не требуется участие разработчика.
Организатор находит семьи, которые уже посещали мероприятия.
Просматривает историю.
Связывается с родителями через доступный согласованный канал.
Администратор может получить экспорт основных данных.
При техническом сбое предусмотрен проверенный порядок восстановления.
Приоритет — не максимальная функциональность, а быстрый запуск устойчивой минимальной системы.
Разработчику запрещается без отдельного согласования:
Если требование можно реализовать простым способом, предпочтение отдаётся простому способу.
Если функция существенно увеличивает сроки или сложность, предложить упрощённую альтернативу.
«Закулисье Светлицы» должен быть достаточно простым, чтобы команда могла самостоятельно работать в нём уже после первого знакомства.
Система должна помогать проводить мероприятия, сохранять отношения с семьями и улучшать продукт.
Она не должна становиться отдельным большим IT-проектом.
Команда способна самостоятельно:
Создать мероприятие → Принять регистрации → Организовать оплату → Провести мероприятие → Отметить посещения → Сохранить историю → Пригласить семьи снова.
Без постоянного участия основателя.
Перед реализацией:
Не начинай масштабную разработку, пока не согласован план.
После согласования:
Конечный результат — работающая минимальная система, а не демонстрационный прототип.