Выпуск приложения

Целевая схема: Vercel для Next.js, Supabase для Auth/PostgreSQL/Storage, Cloudflare для DNS домена foliovera.app.

В Vercel корень приложения — apps/web. Установка выполняется из monorepo с pnpm и lockfile. Переменные production задаются в защищённых настройках проекта:

Переменная	Назначение
`APP_ORIGIN`	`https://foliovera.app`
`SUPABASE_URL`	URL целевого Supabase проекта
`NEXT_PUBLIC_SUPABASE_URL`	Тот же публичный API URL
`NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY`	Publishable key
`ENABLE_EXPERIMENTAL_COREPACK`	`1`, выбор закреплённой версии pnpm

Перед применением миграций следует проверить точный project ref и резервную копию существующей базы. Начальный seed не должен создавать тестовых пользователей в production. Вход ограничен приглашёнными членами семьи.

Работающее приложение использует publishable key и пользовательскую сессию; права ограничиваются RLS. Административный ключ не нужен в Vercel для обычных экранов и API. Он требуется только отдельной операции первичного создания участников; храните его в защищённом окружении этой операции.

Production SMTP настроен через Resend с отправителем login@foliovera.app, сервером smtp.resend.com, портом 465 и отдельным ключом отправки только для этого домена. DKIM, SPF и MX подтверждены. Это подтверждает конфигурацию, но не заменяет проверку доставки magic link и входа на production-домене.

Миграции запускаются официальным Supabase CLI с проверкой сертификата и имени узла. Прямое подключение недоступно: на машине оператора нет маршрута IPv6, — поэтому используется session pooler.

Первичное развёртывание пришлось выполнить через migration endpoint Supabase Management API: CLI падал на создании журнала миграций в пустой базе (supabase/cli#6393). API сам присваивает версии с точностью до секунды, поэтому имена локальных файлов приведены к версиям из его ответа; SQL не менялся. Журнал теперь существует, и обход больше не нужен — CLI работает, и все последующие выпуски идут им.

Не изменяйте журнал применённых миграций вручную. Перед выпуском сверяйте историю: pnpm db:prod:status показывает, что применено и что ждёт.

Docker задаёт BUILD_TARGET=docker для standalone-сборки. Vercel использует свой штатный адаптер Next.js без standalone-режима.

Что чем запускается

Выпуском считается мердж релизной ветки в main. release.yml читает версию из package.json, ставит тег, публикует релиз на GitHub с текстом из ченджлога и только после этого запускает production-раскатку. Обычный мердж без смены версии релиза не создаёт.

Проверки идут на машине разработчика, в pre-push; отдельного прогона в Actions нет намеренно — он повторял бы уже сделанное.

Схему базы не двигает ни то ни другое. Миграции применяет человек командой pnpm db:prod:apply — до мерджа, потому что все миграции аддитивны и работающая версия переживает новую схему, а обратное неверно. Полный порядок выпуска и откат — в docs/release.md.

Подключение к production-базе: scripts/production-database.mjs. Прямой хост недоступен без IPv6-маршрута, поэтому используется session pooler; TLS проверяется по закреплённому сертификату из infrastructure/certificates, а не отключается. Пароль берётся из игнорируемого корневого .env и вырезается из всего, что скрипт печатает или записывает.

В Supabase настраиваются Site URL, точный callback /auth/callback, Google OAuth и SMTP для magic link. Google Cloud OAuth использует callback проекта Supabase. Секреты OAuth и SMTP не коммитятся. Публичная форма входа не показывает пароль.

После выпуска проверяются TLS, Google-вход, получение magic link, отказ постороннему пользователю, права ученика, загрузка закрытого файла и выход из системы. Production считается готовым только после успешной проверки всех критериев .agent/tasks/foliovera-mvp/spec.md.

Текущий проверенный статус выпуска хранится в evidence и verdict внутри задачи; наличие этой инструкции само по себе не означает выполненный деплой.