Matheus
4480e9265e
Fecha um risco documentado desde a PHASE 01: os dois processos de host (fora do Docker) não sobreviviam a um reboot da VM, precisando ser religados manualmente toda vez. Agora são b2bcall-api.service e b2bcall-frontend.service (infrastructure/systemd/), enabled, sobrevivem a reboot como os containers Docker já sobreviviam via restart: unless-stopped. Achado real resolvido antes de instalar: sem porta fixa, os dois disputavam a 3000 por padrão — quem perdesse crashava com EADDRINUSE em vez de cair pra 3001. Fixado API_PORT=3000 (.env) e PORT=3001 (Environment= direto na unit do frontend — confirmado que colocar em apps/frontend/.env.local não funciona, o CLI do Next.js decide a porta antes de aplicar esse arquivo). A ordem de start deixa de importar. Rodam em modo dev (pnpm dev), não build de produção — decisão deliberada documentada no README, virar produção é escopo maior. Testado ponta a ponta: units instaladas e habilitadas, subiram nas portas certas sem fallback nem crash, journalctl com logs limpos, smoke test de regressão nas 19 telas do tenant + platform via os processos supervisionados, todas 200. Achado incidental: as rotas do Next.js dev levam 10-15s pra compilar na primeira visita — explica os TimeoutError intermitentes do Puppeteer vistos ao longo da sessão, não é um bug. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BFaBaBSQGhyXGEgtTYZGV8
