Lovable — разработка проектов
шаг за шагом.

• 01Загрузите файл ТЗ во вложение к первому промпту Lovable.
• 02Попросите ИИ выполнить автоматическую декомпозицию: ключевая суть, технические требования, архитектурные нюансы и ограничения.
• 03Обязательно потребуйте сначала спроектировать структуру таблиц БД (например, для Supabase) в виде SQL — и утвердите схему до генерации интерфейса.
• 04ИИ должен вывести структурированный пошаговый план разработки прямо в чат.

• 01Загрузите ТЗ во вложение к текущему проекту с прототипом.
• 02Поставьте задачу на «оживление»: перевод статических компонентов на рабочую логику.
• 03Строго сохраняйте существующий визуал — допускаются только минимальные технические корректировки UI.

• Изучить предложенный ИИ план декомпозиции.
• Изучить предложенную структуру БД (таблицы, связи, ключевые поля).
• Вручную добавить бизнес-требования, которые ИИ упустил.

Настройка регистрации, авторизации и сессий — как правило, на базе Supabase Auth (внутри Lovable Cloud).

Разграничение прав доступа и ролевая модель: например, Пользователь / Модератор / Администратор. Роли всегда хранятся в отдельной таблице, а не на профиле.

• Статистика по зарегистрированным пользователям.
• Блокировка и удаление учётных записей.
• Ручное добавление пользователей при необходимости.

Подключение внешних API, предусмотренных проектом: Битрикс24, 1С, CRM-системы, платёжные шлюзы и прочие интеграции.

Если проект работает с нейросетями — подключение через прямой API-ключ (например, OpenAI) или через агрегатор OpenRouter.

После каждого успешно реализованного этапа (например, полностью настроена и проверена авторизация) делайте экспорт кода или коммит в подключённый GitHub-репозиторий. Если ИИ зайдёт в тупик — проще откатиться к рабочему коммиту, чем чинить руками.

• 01Если Lovable делает одну и ту же ошибку 3 раза подряд — остановите сессию.
• 02Удалите последний некорректно сгенерированный код.
• 03Вернитесь к стабильной точке из GitHub.
• 04Переформулируйте задачу, разбив её на более мелкие подзадачи.

• Пройти каждый пункт плана декомпозиции, утверждённого на этапе 2.
• Сверить кодовую базу и интерфейс с требованиями ТЗ.
• Убедиться, что все функциональные требования закрыты.

Лично прожмите каждую кнопку, форму, инпут, валидацию полей и ссылку в приложении. Никакой «выборочной» проверки — только сплошной проход.

• Фиксируйте все нестыковки, визуальные артефакты и логические ошибки.
• Помечайте критичность: блокер / критичный / средний / косметика.
• Сохраняйте сценарий воспроизведения — без него баг не баг.

Последовательно отправляйте логи ошибок в чат Lovable с требованием внести точечные правки — до тех пор, пока программа не начнёт работать полностью стабильно.

Lovable Cloud покрывает 90% задач: managed Supabase, edge-функции, деплой одной кнопкой. Переезд на self-hosted нужен только тогда, когда есть внешнее требование — политика клиента по хранению данных, корпоративный периметр, отдельный контур или экономика инфраструктуры на длинной дистанции.

• Вариант А — в проекте есть папка `supabase/` (миграции, edge-функции, `config.toml`). Стандартный маршрут: self-hosted Supabase на отдельном VPS + фронтенд на shared hosting.
• Вариант Б — папки `supabase/` нет, бэкенд свой (Node/Bun/Deno, TanStack SSR, Nitro и т.п.). Нестандартный случай: один VPS, Docker Compose, Caddy как reverse-proxy. Каждый такой проект собирается индивидуально под свой стек.

Lovable подключается к GitHub через GitHub App и коммитит каждое изменение в `main` от имени бота `gpt-engineer-app[bot]`. Пока проект живёт в редакторе Lovable, ветка `main` — это фактически лог правок в формате git. В коммит попадает весь код приложения, `supabase/migrations/*.sql`, `supabase/functions/*` и служебная папка `.lovable/`.

• 01В чате Lovable нажать «+» → пункт **Git** → **GitHub**.
• 02Подтвердить установку GitHub App и создание репозитория.
• 03Если репозиторий создаётся под корпоративным аккаунтом клиента — добавить свой личный GitHub в **Settings → Collaborators**, принять инвайт с почты.
• 04Клонировать репозиторий локально — дальше вся работа идёт из склонированной директории.

• Проверить лимит сайтов по тарифу, при необходимости расширить.
• Выбрать домен или создать поддомен на уже используемом домене — новые домены увеличивают счёт.
• Выпустить SSL-сертификат для домена/поддомена (Let's Encrypt в панели); применение может занять до нескольких часов.
• Создать сайт, привязать домен, включить редирект HTTP → HTTPS.
• Включить SSH/SFTP на аккаунте, зафиксировать логин/пароль/порт в защищённом хранилище (не в коде и не в этой инструкции).
• Создать почтовый ящик `noreply-<сервис>@домен` для SMTP приложения (подтверждения регистрации, сброс пароля).

• 01В облачной панели хостинга создать VPS из готового решения **Supabase** (Docker и compose уже подняты).
• 02Сохранить root-пароль сервера и креды админ-панели Supabase.
• 03Дать серверу говорящее имя, чтобы не путать с другими Supabase-инстансами на аккаунте.
• 04Сгенерировать отдельный SSH-ключ на проект (`~/.ssh/<project>/id_ed25519`), не смешивать с общим ключом.
• 05Добавить запись `Host <alias>` в `~/.ssh/config` с `HostName`, `Port`, `User root`, `IdentityFile` и `IdentitiesOnly yes`.

Host supabase_project_v1
    HostName 217.114.8.105
    Port 22
    User root
    IdentityFile ~/.ssh/projects/project/id_ed25519
    IdentitiesOnly yes

• `main` — чистый Lovable-sync. Только код приложения, миграции, функции. Все правки поведения приложения идут сюда первыми.
• `deploy` — это `main` + deploy-обвязка поверх: `Makefile`, `deploy.js`, `scripts/db-connect.sh`, `.htaccess`, реальный `.env` с self-hosted значениями, роутер edge-функций `supabase/functions/main/index.ts`.
• Направление одностороннее: `main → deploy`. Никогда не мержить `deploy` обратно в `main` целой веткой.

# правка → main (напрямую или через feature-ветку)
git checkout main
# ... коммит ...

git checkout deploy
git merge main
make deploy          # прогон этапов 5–7
git push origin main deploy

• Скилл сам вычитывает `ANON_KEY` и `API_EXTERNAL_URL` с сервера по SSH и переписывает `.env` в ветке `deploy` (`VITE_SUPABASE_URL`, `VITE_SUPABASE_PUBLISHABLE_KEY`).
• На стороне self-hosted Supabase донастраиваются `SITE_URL`, `ADDITIONAL_REDIRECT_URLS` и SMTP.
• После правки `.env` контейнер `auth` пересоздаётся `docker compose up -d` — `restart` не перечитывает `.env`.
• `.env.deploy` (SSH-пароли, пароль Postgres) хранится только локально и никогда не коммитится.

Скилл прогоняет `supabase/migrations/*.sql` по порядку через `make db-migrate-remote`, версии трекаются в `supabase_migrations.schema_migrations`. Дважды одну и ту же миграцию накатить нельзя.

Скилл синхронизирует `supabase/functions/` на сервер и пересоздаёт контейнер (`stop && rm -f && up -d`, а не `restart`). Дополнительно кладёт файл `supabase/functions/main/index.ts` — это роутер, без которого self-hosted edge-runtime падает при старте (`could not find an appropriate entrypoint`) и все функции отдают 503.

`make deploy` собирает статику (`npm ci && npm run build`), копирует `.htaccess` в `dist/` и синкает `rsync dist/ → сервер` (через `sshpass`, т.к. shared hosting обычно только пароль). `.htaccess` из шаблона решает SPA-роутинг (все запросы, кроме реальных файлов, ведут на `index.html`) и кэширование (`index.html` — `no-cache`, хэшированные ассеты — `immutable`).

curl -s https://<домен>/ | head -20
# Если хостинг ставит anti-bot cookie-челлендж (Beget: beget=begetok),
# добавьте куку в запрос — иначе кажется, что деплой не сработал.

• Регистрация нового пользователя.
• Письмо-подтверждение реально приходит на почту.
• Логин, основные разделы приложения, ключевые интеграции.
• Сброс пароля end-to-end — часто ловит редирект, уводящий мимо формы.
• Проверка истории git на утечку секретов: `git log -p -- .env.deploy` и grep по `service_role`.

• Кэширующий слой хостинга перед Apache (у Beget — `nginx-reuseport` + анти-бот прослойка) кэширует `index.html` независимо от `Cache-Control`. Диагностируется сравнением `Last-Modified`/`Date` в ответах с `Cache-Control: no-cache` и без него. Исправляется отключением «Ускорения сайта» в панели или ручной чисткой кэша после каждого деплоя.
• `docker compose restart` не перечитывает `.env` — только `up -d`.
• SMTP на Beget VPS: только порт 2525, 465/587 заблокированы.
• `ADDITIONAL_REDIRECT_URLS` в GoTrue — только с wildcard.
• В `Makefile` внутри `-F ~/.ssh/config` тильда не раскрывается в кавычках — используйте `$(HOME)/.ssh/config`.

Проекты со своим бэкендом (TanStack SSR/Nitro, Node/Bun и т.п.) переезжают на один VPS с Docker Compose: сервис `app` отдаёт и статику, и бэкенд одним процессом, сервис `caddy` — reverse-proxy с автоматическим Let's Encrypt SSL и security-заголовками. Процесс держится Docker'ом (`restart: unless-stopped`), отдельных systemd-юнитов на хосте нет.

• Скилл `setup-caddy` закрывает только reverse-proxy и SSL — остальное (`Dockerfile`, `docker-compose.yml`, `Makefile`) пишется вручную под конкретный стек проекта.
• Два SSH-алиаса: `..._ansible` (root, только для первичного бутстрапа) и `..._developer` (без sudo, в группе `docker`, для повседневных `make deploy`). Root-логин по паролю отключён.
• Ветки `main`/`deploy` — та же идея, но `merge=ours` защищает другой набор файлов: `Dockerfile`, `docker-compose.yml`, `Caddyfile`, `Makefile`, `.dockerignore`, self-hosted-специфичный код авторизации. `package.json` не защищён — обычный three-way merge.

Пакет `setup-deploy-supabase.zip` (Claude-скилл) создаёт ветку `deploy`, `Makefile`, `deploy.js`, `.gitattributes`, роутер edge-функций и `.htaccess` по шаблонам. Закрывает автоматикой этап 11 и частично 12–13. Устанавливается как глобальный скилл (`~/.claude/skills/`) или скилл проекта (`.claude/skills/`).

• Шаблоны внутри: `Makefile.template`, `deploy.js.template`, `db-connect.sh.template`, `functions-main.template`, `env-deploy-example.template`, `gitattributes.template`, `htaccess.template`, `gitignore-additions.txt`.
• Этапы 9 и 10 (sync с GitHub, выделение ресурсов) пока в скилл не входят — делаются руками по чек-листам выше.

Пакет `setup-caddy.zip` настраивает Caddy как reverse-proxy с автоматическим Let's Encrypt SSL для Docker-проектов. Закрывает только Caddy-часть Варианта Б — не весь деплой целиком. Внутри: `docker-compose.caddy.yml.template`, `Caddyfile.template`, `dockerignore-additions.txt`.