Сервис продажи VPN двух брендов на одном бэкенде: Вейликс (dedicated, veilix.app) и ВейликсВПН (mass, veilixvpn.com). Карта документации — [docs/00-index.md](docs/00-index.md).
## 1. Порядок работы в сессии
1. Прочитай этот файл, затем [docs/00-index.md](docs/00-index.md) и файл текущего этапа в [docs/stages/](docs/stages/). Остальные документы — по ссылкам из файла этапа.
2. Перед началом работ сверь с пользователем план этапа: что делаем, что не делаем, какие вопросы открыты. Код не пишем, пока план этапа не подтверждён.
3. Нашлось противоречие между документами, макетом и задачей — сначала обсуждаем, потом делаем.
4. Есть отраслевой стандарт лучше предложенного решения или решение получается кастомным — обсуди с пользователем.
5. В конце этапа обнови документацию: статус этапа в [docs/00-index.md](docs/00-index.md), решения в [docs/decisions/](docs/decisions/), изменения модели данных в [docs/03-data-model.md](docs/03-data-model.md).
## 2. Общение
1. Язык — русский.
2. Нумерация пунктов в чате и в документации — только цифры и латинские буквы (1, 2, 3 и a, b, c). Кириллические буквы как маркеры не используем: не путаются латинская A и русская А, латинская B и русская В.
## 3. Сервер и права
1. Всё, что требует root (пакеты, nginx, сертификаты, роли PostgreSQL, Postfix, DNS, `loginctl`), делает пользователь. Сформулируй, что и зачем нужно сделать, и жди. Обходные пути внутри своего пользователя не ищем.
2. Окружения на одном сервере, под разными пользователями ОС:
a. dev — пользователь vx_dev (под ним работают сессии Claude): `/home/vx_dev/veilix_dev` (рабочая копия git), база `veilix_dev`, домены `dev.*`, порт 3100;
b. prod — пользователь vx_prod: `/home/vx_prod/veilix` (релизы и симлинк `current`), база `veilix_prod`, основные домены, порт 3000. У vx_dev доступа к prod нет.
3. Выкладка в prod — только по явной команде пользователя в текущей сессии и только командой выкладки ([docs/02-architecture.md](docs/02-architecture.md), раздел 5).
## 4. Технические правила
1. Стек и версии — [docs/02-architecture.md](docs/02-architecture.md). Payload 3.x; код пишем совместимо с Payload 4: в Local API всегда явно указываем `overrideAccess`.
2. ID — только UUID (`idType: 'uuid'`). Наружу не отдаём последовательных номеров: номера заказов, ключей и реферальные коды — случайные.
3. Деньги — целые числа в минимальных единицах (копейки, центы) плюс код валюты. Никаких float.
4. Секреты — только в `.env` вне git.
5. Тексты интерфейса — через next-intl, контент — локализованные поля Payload. Строк на одном языке в коде компонентов нет.
6. Макеты — в [design/handoff/project/](design/handoff/project/). Воспроизводим их по коду макетов (разметка, CSS-переменные), а не по скриншотам.
7. Коммиты и push в Gitea — по просьбе пользователя.
| `pnpm seed` | начальные данные dev; повторный запуск обновляет справочники и возвращает значения seed, а страницы и FAQ создаёт, только если их нет. `SEED_CONTENT=reset` — пересоздать страницы и FAQ, `SEED_ENV=prod` — данные prod |
| `pnpm generate:types` | типы Payload в `src/payload-types.ts` после изменения коллекций |
| `pnpm generate:importmap` | карта импортов админки после добавления своих компонентов |
| `pnpm db:reset` | очистить `veilix_dev` (только её), если push схемы задаёт вопросы (переименование, удаление): без терминала их некому подтвердить. Затем перезапуск dev-сервера и `pnpm seed` |
Проверка без nginx: `curl -A 'Mozilla/5.0' -H 'Host: dev.veilix.app' http://127.0.0.1:3100/…`. Без браузерного User-Agent curl считается ботом и не перенаправляется; заголовок `X-Geo-Country` так можно подставить, через nginx — нет.
