fix(auth): access token de 15min para 8h

Usuário pediu explicitamente pelo menos 8h. O TTL curto original era
deliberado (ADR-0003, reduzir janela de token vazado), mas o frontend
nunca implementou refresh silencioso — na prática o usuário era
derrubado no meio do trabalho sem nenhuma renovação automática. 8h é
um paliativo real, documentado como tal num adendo na própria ADR-0003
(com a mitigação que já existe — revogação de sessão continua granular
— e o que resolveria isso de verdade sem abrir mão de segurança:
refresh silencioso no frontend).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

apps/api/src/auth/token.service.ts

@@ -9,7 +9,16 @@ export interface AccessTokenPayload {
   app: "core" | "reseller" | "subscriber";
 }
 
-const ACCESS_TOKEN_TTL_SECONDS = 15 * 60; // 15 min — ADR-0003
+/**
+ * 8h — revisado a partir dos 15min originais da ADR-0003 (ver o adendo no
+ * próprio documento): o frontend não implementa refresh silencioso ainda
+ * (`AuthContext.tsx`, `session.ts` — "No refresh-token rotation in this
+ * leva"), então um access token de 15min derrubava o usuário no meio do
+ * trabalho. 8h cobre um expediente inteiro sem exigir login de novo;
+ * revogação continua granular via a tabela `sessions` (logout/"encerrar
+ * todas as sessões" não dependem da expiração do JWT).
+ */
+const ACCESS_TOKEN_TTL_SECONDS = 8 * 60 * 60;
 const REFRESH_TOKEN_TTL_DAYS = 30;
 const MFA_CHALLENGE_TTL_SECONDS = 2 * 60;
 const MFA_CHALLENGE_PURPOSE = "mfa_challenge" as const;

docs/adr/0003-auth-sessions.md

@@ -7,7 +7,7 @@ Aceito
 O legado usa JWT HS256 com payload mínimo (`sub`, `ver`), expiração fixa de 30 dias, sem refresh token, invalidação via `token_version` incremental (derruba todas as sessões de uma vez, nunca uma só). O Master Prompt (§5.3) pede explicitamente uma evolução: access token curto + refresh token rotativo (ou sessão server-side segura), refresh tokens armazenados em hash, histórico de sessões/dispositivos, "encerrar todas as sessões", MFA/TOTP preparado.
 
 ## Decisão
-- **Access token**: JWT de vida curta (15 min), payload mínimo (`sub`, sessão id), assinado (algoritmo a confirmar em ADR de criptografia geral — HS256 mantém paridade com o legado, RS256 fica em aberto se houver necessidade de verificação por serviço externo).
+- **Access token**: JWT de vida curta, payload mínimo (`sub`, sessão id), assinado (algoritmo a confirmar em ADR de criptografia geral — HS256 mantém paridade com o legado, RS256 fica em aberto se houver necessidade de verificação por serviço externo). TTL original 15min, revisado para 8h — ver adendo 2026-09-18.
 - **Refresh token**: opaco, alta entropia (≥256 bits), **rotativo a cada uso** (um novo é emitido e o antigo invalidado), armazenado só como hash no banco (nunca em claro) — mesma filosofia do token de link público do legado.
 - **Tabela `sessions`** (não só um contador `token_version`): permite listar sessões/dispositivos ativos e revogar individualmente **ou** todas de uma vez (superset da capacidade do legado, que só permitia "todas").
 - **Vínculo por aplicação**: uma sessão registra explicitamente para qual aplicação (`core`/`reseller`/`subscriber`) foi emitida — nunca inferir pelo papel do usuário (Master Prompt §5.1).
@@ -19,3 +19,9 @@ O legado usa JWT HS256 com payload mínimo (`sub`, `ver`), expiração fixa de 3
 - Positivo: access token de vida curta reduz janela de uso de token vazado sem exigir consulta ao banco a cada request (mesma vantagem de performance que o legado tinha com JWT, mas com menor exposição).
 - Negativo: mais complexidade que o modelo legado (rotação de refresh token exige lógica de "replay detection" — se um refresh token já usado for reapresentado, é sinal de token roubado; a sessão inteira deve ser revogada nesse caso).
 - Migração: nenhuma — é um sistema novo, não há sessões legadas para migrar.
+
+## Adendo — 2026-09-18: TTL do access token revisado de 15min para 8h
+
+O frontend nunca implementou refresh silencioso (`apps/core-web/src/lib/auth/AuthContext.tsx`/`session.ts` documentam isso explicitamente: "No refresh-token rotation in this leva"). Na prática, 15min derrubava o usuário no meio de um cadastro/edição em uso normal do backoffice — usuário pediu explicitamente pelo menos 8h. `ACCESS_TOKEN_TTL_SECONDS` em `apps/api/src/auth/token.service.ts` ajustado para `8 * 60 * 60`.
+
+Isso é uma troca deliberada de exposição por conveniência — o risco que a decisão original mitigava (janela de uso de um token vazado) fica maior. Mitigado por: a arquitetura de `sessions` já permite revogar uma sessão específica ou todas a qualquer momento (login com nova senha após reset já revoga tudo — `password-reset.spec.ts`), então um access token vazado ainda pode ser cortado sem esperar o TTL expirar, só não automaticamente. **Trabalho futuro real, não feito agora**: implementar refresh silencioso no frontend (ex. renovar o access token em background antes de expirar, ou reagir a um 401 chamando `/auth/refresh` e repetindo a requisição) permitiria voltar a um TTL curto sem prejudicar a UX — o TTL de 8h é um paliativo, não a solução definitiva.

docs/progress.md

@@ -731,3 +731,34 @@ Data: 2026-09-18. Usuário pediu: "primeiro vem os dados PJ depois vem os sócio
 
 ### Verificação
 `pnpm turbo run typecheck build` 28/28. Suíte 100/100 (inalterada — mudança é só de frontend). Testado ao vivo em navegador real via Playwright: ordem das seções confirmada por leitura do DOM (`Status, Dados PJ, Sócios, Endereço, Contatos`) e por screenshot; ciclo completo com CNPJ real (Petrobras) mostrando os 10 sócios na nova posição; salvamento testado preenchendo um campo de cada `<form>` e confirmando após reload que os dois persistiram. Cadastro de teste desativado ao final.
+
+---
+
+## Access token: 15min → 8h
+
+Data: 2026-09-18. Usuário pediu diretamente: "ajuste o tempo de acesso do token preciso que seja no mínimo 8 horas". Implementado diretamente (mudança pequena, uma constante).
+
+`ACCESS_TOKEN_TTL_SECONDS` em `apps/api/src/auth/token.service.ts`: `15 * 60` → `8 * 60 * 60`. Achado ao investigar antes de mudar: o TTL curto original era uma decisão deliberada e documentada (ADR-0003, motivada pelo Master Prompt §5.3 — reduzir a janela de uso de um token vazado), mas o frontend nunca implementou refresh silencioso (`AuthContext.tsx`/`session.ts` documentam isso explicitamente: "No refresh-token rotation in this leva") — na prática, 15min derrubava o usuário no meio do trabalho, sem nenhum mecanismo automático de renovação. 8h é um paliativo real pro problema real, não só "afrouxar por afrouxar": documentado como tal num adendo na própria ADR-0003, com a mitigação que já existe (revogação de sessão continua granular, não depende do TTL do JWT) e o trabalho futuro real que resolveria isso sem abrir mão de segurança (refresh silencioso no frontend).
+
+### Verificação
+`pnpm turbo run typecheck build` 28/28. Suíte completa 106/106 (após a leva de Revenda abaixo, rodada em conjunto). Testado ao vivo: login real devolve `expiresIn: 28800` (exatamente 8h).
+
+---
+
+## Cadastro de Revenda — mesma expansão do Cadastro de Cliente (CNPJ, campos, reordenação)
+
+Data: 2026-09-18. Usuário pediu pra aplicar em Revenda a mesma coisa feita em Cliente: "fazer a busca automática de cnpj e expandir campos de cadastro e reordenar os campos". A tabela `resellers` até agora era minimalista (`name`/`document`/`contact_email`/`active`, sem endereço, sem sócios, sem os campos PJ que `client_registrations` já tinha).
+
+### Backend (agente `eden-commercial`)
+
+Migration `packages/database/migrations/1789700000000_resellers-expansion.cjs`: `resellers` ganha `trade_name`, `state_registration`, `municipal_registration`, `opening_date`, `legal_nature`, `cnpj_situation`, `main_activity`, `address_*`, `contact_principal/financial/technical_*` — mesmo shape de `client_registrations`, sem o prefixo `pj_` (não existe ambiguidade PF/PJ aqui — decisão deliberada: revenda não ganhou um `person_type`, é sempre tratada como PJ). Tabela nova `reseller_partners`, mesmo shape de `client_registration_partners`.
+
+Endpoints novos em `resellers.controller.ts`: `GET/POST /v1/resellers/:id/partners`, `PATCH /v1/resellers/:id/partners/:partnerId`, e `POST /v1/resellers/:id/cnpj-lookup` — **reaproveitando o adapter `lookupCnpj` já existente** (`@eden/integrations`, construído pra Cliente), mesma mecânica exata (servidor sempre reconsulta a fonte autoritativa, `COALESCE` em tudo que a API pode não trazer, dedup de sócios por `document`, `source: 'cnpj_lookup'`).
+
+**Decisão deliberada, diferente de Cliente**: `document` continua livremente editável via `PATCH` genérico — ao contrário de `pj_cnpj` em `client_registrations` (que é bloqueado de propósito, só a ação dedicada de lookup grava). Aqui a busca de CNPJ é só uma conveniência adicional, não uma trava nova.
+
+### Verificação
+`pnpm db:migrate`/`down`/`migrate` de novo — limpo. `pnpm turbo run typecheck build` 28/28. Suíte 106/106 (100→106, 6 testes novos). Testado ao vivo contra CNPJ real (Petrobras): nome/nome fantasia/inscrição estadual/endereço/10 sócios corretos, reexecução sem duplicar, `PATCH` manual em `document` confirmado ainda funcionando depois do lookup.
+
+### Pendências
+UI ainda não construída — só o backend nesta leva (frontend é o próximo passo natural, mesmo padrão de Cliente: Dados PJ → Sócios → Endereço → Contatos, já direto na ordem certa desta vez, sem precisar de uma segunda leva de reordenação).