Começando

1. Clonar o repositório

   git clone <url-do-repo>
   cd simpe-ms

2. Instalar as dependências

   npm install

   Isso instala tudo, incluindo a CLI do Supabase como dev dependency — então não precisa instalar a CLI globalmente, embora o capítulo anterior recomende.

3. Subir o stack do Supabase

   supabase start

   Na primeira vez, baixa as imagens Docker. Pode demorar uns 5 minutos. Quando terminar, a CLI imprime um quadro com URLs e chaves do seu ambiente local — guarde, vamos usar agora.

   O que essa pousada de containers faz

   supabase start sobe Postgres, GoTrue (auth), PostgREST, Storage, Realtime, Edge Runtime, Studio (DB browser) e Mailpit (email capture) — tudo via Docker Compose. Migrations da pasta supabase/migrations/ são aplicadas automaticamente na primeira vez.

4. Configurar o .env

   Copie do exemplo e edite para usar o bloco Opção B (Supabase local). As chaves vêm do que supabase start imprimiu (ou rode supabase status a qualquer momento para vê-las de novo):

   cp .env.example .env
   supabase status   # mostra Publishable e Secret keys

   O .env deve ficar assim:

   NEXT_PUBLIC_SUPABASE_URL=http://127.0.0.1:54321
   NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY=sb_publishable_xxx...
   SUPABASE_SERVICE_ROLE_KEY=sb_secret_xxx...
   NEXT_PUBLIC_AMBIENTE_DE_TESTE=true

   Sobre as chaves locais

   Em versões antigas do CLI, as chaves eram fixas (JWTs compartilhados entre máquinas). Nas versões recentes (2.90+), elas são randomizadas por instância — sb_publishable_* e sb_secret_*. Por isso copiamos manualmente em vez de embedar no .env.example.

5. Aplicar o seed

   npm run db:reset

   Esse comando dropa o schema, reaplica todas as migrations (são mais de 100) e roda supabase/seed.sql. O seed cria 1 plano, 3 objetivos com hierarquia completa, ~30 entregas, 5 usuários, distribuição de semáforos, métricas e compromissos. Tudo sintético.

6. Subir o app

   npm run dev

   Acesse http://localhost:3000. Login com qualquer um destes usuários — senha senha123 para todos:

   Email	Role	Para o quê
   viz@local.test	Visualização	Testar o que um usuário read-only enxerga
   edicao@local.test	Edição	Permissões intermediárias de edição
   gestar@local.test	Gestar	Gestor com permissões amplas de planejamento
   admin@local.test	Admin	Permissões totais — o role usado pela SES (cliente)
   super@local.test	SuperAdmin	Mesmas permissões do Admin; existe só para distinguir staff Pacto da SES

Comando único (opcional)

Se preferir subir tudo — Supabase, Next e functions serve — com um comando só:

npm run dev:local

O dev:local roda supabase start (idempotente, então não repete trabalho), depois next dev e supabase functions serve em paralelo com prefixos coloridos. Quando vale: você está editando uma edge function e quer hot reload. Quando não vale: o supabase start sozinho já serve as edge functions a partir de supabase/functions/ sem hot reload — suficiente para uso normal.

URLs locais úteis

Comandos do dia a dia