AMOLIE

SaaS-платформа онлайн-записи для мастеров индустрии красоты. Мастер получает страницу amolie.com/{slug}, публикует свободные окна и принимает записи; клиент записывается без регистрации, а после записи может завести кабинет — один список визитов ко всем мастерам на amolie.com/me.

Статус: Phase 1 пройдена, кроме писем о записях (SMS упирается в регистрацию компании, см. ARCHITECTURE.md §8). В продакшене работает всё: веб на Vercel, API на Fly.io (amolie-api.fly.dev) с базой в Supabase. Что сделано и что осталось — ROADMAP.md, задачи — TASKS.md.

Деплой не автоматический по обе стороны по-разному. Пуш в main выкатывает веб на Vercel сам; API на Fly требует ручного fly deploy, и порядок имеет значение: сначала API (миграции применяются release-командой до старта нового кода), потом пуш веба — иначе интерфейс обещает то, чего сервер ещё не умеет.

Запуск

pnpm install
docker compose up -d          # PostgreSQL и Redis
cp apps/api/.env.example apps/api/.env   # заполнить DATABASE_URL, JWT_SECRET
pnpm --filter @amolie/api exec drizzle-kit migrate
pnpm dev                      # web :3000, api :3001

Если окружение поднималось до переименования в AMOLIE, база называлась beauty_lv, а compose-проект — beauty-lv. API с новым DATABASE_URL такую базу не найдёт и упадёт; внешне это выглядит как 500 на странице мастера и в кабинете.

Postgres поднят локально (не в Docker) — база переименовывается на месте, со всеми данными:

psql -h localhost -U postgres -d postgres -c 'ALTER DATABASE beauty_lv RENAME TO amolie;'

Postgres из docker compose — переименовать нельзя: POSTGRES_DB применяется только к пустому тому. Новый контейнер поднимется с пустой базой amolie, ей нужны миграции и сид; том beauty_lv_postgres со старыми данными остаётся на диске и удалять его не обязательно:

docker compose up -d
pnpm --filter @amolie/api exec drizzle-kit migrate
pnpm --filter @amolie/api db:seed                         # демо-данные

Показательные данные для ручной проверки кабинета — заполненный соло-мастер и салон с командой. Оба скрипта идемпотентны (пересобирают своё с нуля), печатают входы и получают новый пароль на каждый запуск; в продовом окружении не нужны:

pnpm --filter @amolie/api db:demo         # соло-мастер Neve Ashgrove: услуги, клиенты, записи
pnpm --filter @amolie/api db:demo-salon   # салон Lumen Studio: владелица, администратор, три мастера

Проверки перед коммитом — все четыре, они же в CI:

pnpm lint && pnpm typecheck && pnpm test && pnpm build

Устройство

Монорепозиторий на pnpm workspaces + Turborepo.

Пакет	Что это
apps/web	Next.js (App Router): лендинг, публичная страница, кабинет мастера, кабинет клиента /me, админка
apps/api	NestJS + Drizzle + PostgreSQL
packages/shared-kernel	Доменные примитивы, общие для web и api: деньги, телефоны, слаги, темы, .ics

Браузер никогда не обращается к API напрямую: клиентские компоненты ходят через BFF-прокси /api/proxy, серверные — через serverApiFetch. Токен живёт в httpOnly-cookie и в JavaScript не попадает.

Документация

Читать в этом порядке — от «зачем» к «как»:

Документ	О чём
CONCEPT.md	Суть продукта за один проход — начинать отсюда
PRODUCT.md	Что это за продукт, для кого, чего в нём нет
PRD.md	Продуктовые требования
ROADMAP.md	Где мы сейчас и что дальше
TASKS.md	Задачи по эпикам со статусами
ARCHITECTURE.md	Стек, слои, защита от гонок, языки, что из стека реально подключено
DATABASE.md	Схема, индексы, миграции
API.md	Контракт: §6 описывает то, что действительно есть в коде
DESIGN_SYSTEM.md	Конституция визуального языка: принципы, токены, законы
UI_GUIDELINES.md	Дизайн-система кабинета и админки
DESIGN.md

Три правила, которые легко нарушить не зная

Флоу записи неприкосновенен. Порядок «услуги → допы → время → контакты» и подбор окон по суммарной длительности менять нельзя — переодевать визуально можно. Услуги идут раньше времени не по вкусу: длительность визита решает, какие окна вообще можно предложить.

Две темы публичной страницы правятся раздельно. Плакатная отвечает перед скиллом impeccable, мягкая — перед ui-ux-pro-max; правка одной не переносится на другую. Кабинет не принадлежит ни одной из них и судится по UI_GUIDELINES.md. Подробности — DESIGN.md.

Аккаунт клиента и карточка клиента — разные вещи. users — человек на платформе, один на всё; clients — его карточка в CRM конкретного мастера, с её заметками и её историей, жёстко в границах организации. Смешать их значит показать мастеру, что её клиент ходит ещё к кому-то, — или показать клиенту, как он у неё записан. Ни того, ни другого продукт делать не должен.