fix(e2e): o CI cria o .env.e2e que a suíte passou a exigir

O PR protegeu a suíte contra escrever em produção — `playwright.config.ts`
exige um `.env.e2e` e falha alto quando falta. A proteção está certa; o que
saiu incompleto foi a outra ponta: `.github/workflows/e2e.yml` não foi
tocado. O job seguiu rodando `pnpm build` e chamando a suíte sem gerar nada,
e o e2e morreu em `Falta o .env.e2e` depois de 3m48s.

Três consertos, todos medidos:

1. O workflow gera o `.env.e2e` (`pnpm e2e:env`) depois de o stack local
   subir, e builda com `pnpm e2e:build` — não `pnpm build`. As três
   `NEXT_PUBLIC_*` são embutidas no BUNDLE durante o build: buildar com um
   env e trocar só no `next start` deixaria a URL errada dentro do
   JavaScript do browser. Medido: `==> OK (controle): o host local
   (127.0.0.1:54321) ESTÁ no bundle`.

2. `gerar-env-e2e.sh` usa o `supabase` do PATH quando existe (é o que o CI
   instala via supabase/setup-cli) e cai no `npx` só na máquina do dev. A
   CLI não é dependência deste projeto — insistir no `npx` custaria um
   download do registry em cada uma das três chamadas.

3. O heredoc que escreve o `.env.e2e` não é quotado, e um comentário dentro
   dele tem crases. O shell tentou EXECUTAR o que estava entre elas:

     scripts/gerar-env-e2e.sh: linha 79: credential_decrypt_failed:
     comando não encontrado

   Saía em stderr e o arquivo gerado perdia exatamente o identificador que
   o comentário existe para nomear (`# agente morria em , o que aparecia`).
   Varri o heredoc inteiro: as crases eram a única expansão indesejada, as
   `$VAR` são todas de propósito.

A guarda nova é sobre a ORDEM, não a presença: `tests/unit/
e2e-workflow-honra-o-env.test.ts` casa quem gera o arquivo contra quem o
consome e exige que o índice do primeiro seja menor. Sabotei as quatro
propriedades uma a uma — passo removido, ordem invertida, `pnpm build` de
volta, e a exigência sumindo do playwright.config (guarda de vacuidade) —
e cada uma vermelha o caso certo.

gov:verify: 0 erros de lint, 286 arquivos / 2931 testes (2927 + 4).
e2e:build: exit 0.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HstH7nNmrTvCtZsasppeHj

Author: melgarafael

.github/workflows/e2e.yml

@@ -85,8 +85,26 @@ jobs:
             echo "SUPABASE_SERVICE_ROLE_KEY=$(grep '^SERVICE_ROLE_KEY=' /tmp/sb.env | cut -d'"' -f2)"
           } >> "$GITHUB_ENV"
 
-      - name: Build de produção
-        run: pnpm build
+      # O `.env.e2e` é o ambiente da suíte, e ele NASCE aqui — não é opcional.
+      #
+      # `playwright.config.ts` passou a exigi-lo e a falhar alto quando falta,
+      # de propósito: sem ele o `next start` carrega o `.env.local`, que num
+      # checkout de trabalho aponta para PRODUÇÃO. O modo de falha que isso
+      # substitui é a suíte escrever organizações e usuários de teste no banco
+      # real, passando verde.
+      #
+      # No CI o `.env.local` aponta para o Supabase local, então o risco não é o
+      # mesmo — mas o contrato é único, e um workflow que contorna o gate seria
+      # o começo de ele não valer para ninguém.
+      - name: Gerar o .env.e2e (ambiente da suíte)
+        run: pnpm e2e:env
+
+      # `pnpm e2e:build`, não `pnpm build`: as três `NEXT_PUBLIC_*` são embutidas
+      # no BUNDLE durante o build. Buildar com um env e trocar só no `next start`
+      # deixaria a URL errada dentro do JavaScript que roda no browser — servidor
+      # falando com um banco e cliente com outro, no mesmo teste.
+      - name: Build de produção (com o ambiente do E2E)
+        run: pnpm e2e:build
         env:
           NEXT_TELEMETRY_DISABLED: "1"
 

scripts/gerar-env-e2e.sh

@@ -28,7 +28,14 @@ CHAVE_CPF=""; CHAVE_WAHA=""; CHAVE_AI=""
 
 cd "$(dirname "$0")/.."
 
-if ! npx supabase status >/dev/null 2>&1; then
+# `supabase` do PATH quando existe (é o que o CI instala, via supabase/setup-cli),
+# `npx supabase` como plano B para a máquina do dev. Insistir no `npx` custaria um
+# download do registry a cada uma das três chamadas abaixo — a CLI não é
+# dependência deste projeto.
+SUPABASE="supabase"
+command -v supabase >/dev/null 2>&1 || SUPABASE="npx supabase"
+
+if ! $SUPABASE status >/dev/null 2>&1; then
   echo "==> O Supabase local não está de pé. Rode 'npx supabase start' antes." >&2
   exit 1
 fi
@@ -45,7 +52,7 @@ fi
 [ "${#CHAVE_WAHA}" -ge 44 ] || CHAVE_WAHA="$(openssl rand -base64 32)"
 [ "${#CHAVE_AI}" -ge 44 ] || CHAVE_AI="$(openssl rand -base64 32)"
 
-ENVOUT="$(npx supabase status -o env 2>/dev/null)"
+ENVOUT="$($SUPABASE status -o env 2>/dev/null)"
 ler() { printf '%s\n' "$ENVOUT" | grep "^$1=" | cut -d= -f2- | tr -d '"'; }
 
 API_URL="$(ler API_URL)"
@@ -86,7 +93,7 @@ INTERNAL_SECRET=e2e-placeholder-nao-e-segredo
 # As três abaixo são chaves de CIFRA de verdade: o app exige 32 bytes e recusa
 # um rótulo. Medido — com o placeholder, criar credencial de IA devolvia 500
 # ("AI_CRED_AES_KEY deve ter exatamente 32 bytes (lido: 21)") e todo run do
-# agente morria em `credential_decrypt_failed`, o que aparecia como "o modelo
+# agente morria em \`credential_decrypt_failed\`, o que aparecia como "o modelo
 # não respondeu". Geradas na hora: são de teste, não precisam sobreviver.
 CPF_ENCRYPTION_KEY=$CHAVE_CPF
 WAHA_BYO_ENCRYPTION_KEY=$CHAVE_WAHA

tests/unit/e2e-workflow-honra-o-env.test.ts

@@ -0,0 +1,103 @@
+/**
+ * QUEM EXIGE O `.env.e2e` E QUEM O CRIA TÊM DE SER O MESMO CONTRATO.
+ *
+ * ## O defeito
+ *
+ * `playwright.config.ts` passou a EXIGIR um `.env.e2e` e a falhar alto quando
+ * ele falta — a proteção certa, pelo motivo certo: sem esse arquivo o
+ * `next start` carrega o `.env.local`, que num checkout de trabalho aponta para
+ * PRODUÇÃO, e a suíte semeia organizações e usuários de teste no banco real
+ * passando verde.
+ *
+ * O que saiu incompleto foi a outra ponta: o refactor mudou o contrato do
+ * ambiente e não mexeu em `.github/workflows/e2e.yml`. O job seguiu rodando
+ * `pnpm build` e chamando a suíte sem gerar nada, e o e2e do PR morreu em
+ * `Falta o .env.e2e` — 3m48s de CI para descobrir uma dependência que ninguém
+ * declarou em lugar nenhum.
+ *
+ * ## Por que uma guarda estática, e não "rodar o workflow"
+ *
+ * Este é um defeito de ACOPLAMENTO entre dois arquivos: um exige, o outro
+ * provê. A pergunta é sobre a relação, e ela é decidível lendo os dois. O único
+ * jeito de descobri-lo dinamicamente é gastar um job inteiro de CI, que é
+ * exatamente o custo que se está tentando não pagar de novo.
+ *
+ * ## O que se guarda
+ *
+ * A ORDEM, não a presença: existir um passo que gera o `.env.e2e` não adianta
+ * se ele vier depois de quem consome. Por isso a asserção é sobre índices.
+ */
+import { describe, expect, it } from "vitest";
+import * as fs from "node:fs";
+import * as path from "node:path";
+
+const RAIZ = path.resolve(__dirname, "../..");
+
+const workflow = fs.readFileSync(path.join(RAIZ, ".github/workflows/e2e.yml"), "utf8");
+const config = fs.readFileSync(path.join(RAIZ, "playwright.config.ts"), "utf8");
+const packageJson = JSON.parse(fs.readFileSync(path.join(RAIZ, "package.json"), "utf8")) as {
+  scripts: Record<string, string>;
+};
+
+/**
+ * Linhas de `run:` do workflow, na ordem em que o job as executa. É a unidade
+ * certa: o que importa é qual comando roda antes de qual, não como o passo se
+ * chama.
+ */
+const COMANDOS: string[] = workflow
+  .split("\n")
+  .filter((l) => !l.trim().startsWith("#"))
+  .map((l) => l.trim());
+
+/** Índice do primeiro comando que casa, ou -1. */
+function primeiroIndice(padrao: RegExp): number {
+  return COMANDOS.findIndex((l) => padrao.test(l));
+}
+
+const GERA_ENV = /pnpm (e2e:env|exec .*gerar-env-e2e)|bash scripts\/gerar-env-e2e\.sh/;
+const CONSOME_ENV = /pnpm (test:e2e|e2e:build)|playwright test/;
+
+describe("o workflow do e2e honra o contrato de ambiente que a suíte exige", () => {
+  it("a suíte de fato exige o .env.e2e (guarda de vacuidade)", () => {
+    // Sem isto, o dia em que `playwright.config.ts` parar de exigir o arquivo,
+    // os casos abaixo continuariam verdes vigiando uma regra que não existe
+    // mais — e o teste viraria peso morto que ninguém percebe.
+    expect(config).toMatch(/\.env\.e2e/);
+    expect(config, "a exigência tem de FALHAR, não avisar").toMatch(/throw new Error/);
+  });
+
+  it("o script que gera o arquivo existe e está no package.json", () => {
+    expect(packageJson.scripts["e2e:env"]).toBeTruthy();
+    expect(fs.existsSync(path.join(RAIZ, "scripts/gerar-env-e2e.sh"))).toBe(true);
+  });
+
+  it("algum passo do workflow gera o .env.e2e ANTES de qualquer passo que o consuma", () => {
+    const gera = primeiroIndice(GERA_ENV);
+    const consome = primeiroIndice(CONSOME_ENV);
+
+    // Sem consumidor nenhum o caso seria vácuo: nada a ordenar.
+    expect(consome, "nenhum passo do workflow roda a suíte — o padrão envelheceu").toBeGreaterThan(
+      -1,
+    );
+    expect(
+      gera,
+      "nenhum passo gera o .env.e2e; a suíte vai morrer em 'Falta o .env.e2e'",
+    ).toBeGreaterThan(-1);
+    expect(
+      gera,
+      "o .env.e2e é gerado DEPOIS de quem precisa dele — existir não basta, tem de vir antes",
+    ).toBeLessThan(consome);
+  });
+
+  it("o build do job é o que embute as NEXT_PUBLIC_* do ambiente de teste", () => {
+    // `pnpm build` puro deixaria a URL do `.env.local` dentro do bundle do
+    // browser: servidor falando com um banco e cliente com outro, no mesmo
+    // teste. O `e2e:build` existe para exportar o `.env.e2e` antes do build.
+    const buildPuro = COMANDOS.some((l) => /^run: pnpm build$/.test(l) || /^pnpm build$/.test(l));
+    expect(
+      buildPuro,
+      "o workflow do e2e builda com o env errado — use `pnpm e2e:build`",
+    ).toBe(false);
+    expect(packageJson.scripts["e2e:build"]).toBeTruthy();
+  });
+});