# 00 — Arquitetura: Sistema de Briefing de Site

## Objetivo
Cliente se cadastra (pessoa física ou empresa) → faz login → preenche o briefing de 19 seções (149 perguntas) com rascunho automático e botão Ajuda por pergunta → envia → Tiago visualiza, exporta e muda o status no painel admin.

## Fluxos
1. **Cadastro:** Nome completo, CPF, WhatsApp, E-mail, senha. Se "É para empresa?": Razão Social, CNPJ, Endereço (CEP, logradouro, número, complemento, bairro, cidade, UF). Aceite de LGPD obrigatório.
2. **Login / recuperação de senha** por e-mail.
3. **Meus briefings:** o cliente cria um briefing (um cliente pode ter mais de um, ex.: um site por empresa) e continua de onde parou.
4. **Preenchimento:** tela por seção, barra de progresso, botão Ajuda por pergunta (popup), autosave, anexos na seção 19.
5. **Envio:** confirmação do cliente (texto da seção "Confirmação do cliente") → status ENVIADO, bloqueia edição (admin pode reabrir).
6. **Admin:** lista de clientes e briefings, detalhe com todas as respostas e anexos, mudança de status, exportação PDF, edição das perguntas/ajudas.

## Decisão central: formulário dirigido por dados
Seções, perguntas e textos de ajuda ficam no banco e vêm do arquivo `briefing-seed.json` (gerado dos .docx originais: 19 seções, 149 perguntas, todas com ajuda). O frontend renderiza o formulário a partir desses dados; nada de 149 campos escritos à mão.

Tipos de pergunta (`TipoPergunta`): `TEXTAREA` (117), `RADIO` (11), `CHECKBOX` (6), `ANEXO` (15, seção 19). Toda pergunta tem também um campo opcional de **complemento** em texto (o documento original permite escrever junto das caixas marcadas, ex.: "Outro: qual?").

## Modelo de dados (Prisma, resumo)
- `User` (id, email único, senhaHash, papel: CLIENTE | ADMIN, criadoEm)
- `Cliente` (userId único, nomeCompleto, cpfCifrado, cpfHash único, whatsapp, tipo: PF | PJ, razaoSocial?, cnpj?, cep?, logradouro?, numero?, complemento?, bairro?, cidade?, uf?, lgpdAceiteEm)
- `Secao` (id, ordem, titulo, descricao, ativo)
- `Pergunta` (id, secaoId, ordem, rotulo, dica, tipo, opcoes Json, obrigatoria default false, permiteComplemento, ativo)
- `Ajuda` (perguntaId único, oQueResponder, porQuePerguntamos, miniExemplo)
- `Briefing` (id, clienteId, titulo, status: RASCUNHO | ENVIADO | EM_ANALISE | CONCLUIDO, confirmadoEm?, enviadoEm?, criadoEm, atualizadoEm)
- `Resposta` (briefingId, perguntaId, texto?, selecionadas Json?, único por briefing+pergunta)
- `Anexo` (briefingId, perguntaId, nomeOriginal, caminho, mime, tamanho, criadoEm)
- `PasswordResetToken` (userId, tokenHash, expiraEm, usadoEm?)

## Princípios (do padrão SeConectai)
- **Nunca apagar dados históricos:** briefing enviado não é deletado; reabrir muda o status, não perde respostas.
- **Dados sensíveis por desenho:** CPF cifrado (AES-256-GCM, chave em variável de ambiente) + `cpfHash` (HMAC-SHA256) para unicidade/busca. CPF nunca vai para log nem para o JSON de listagens.
- **Validação dupla:** Zod no cliente e no servidor (server actions / route handlers).
- **Permissões:** cliente só enxerga os próprios briefings; admin enxerga todos. Toda leitura/escrita checa o dono no servidor.
- **Incremental:** mudanças futuras via migrations Prisma numeradas, sem reescrever o schema base.

## Estrutura de pastas alvo
```
/app
  /(publico)/cadastro, /login, /recuperar-senha, /redefinir-senha
  /(cliente)/briefings, /briefings/[id], /briefings/[id]/[secao], /briefings/[id]/revisao
  /(admin)/admin, /admin/clientes, /admin/briefings/[id], /admin/perguntas
  /api/anexos/[id]  (download autenticado)
/components  (ui shadcn, form/, ajuda/)
/lib  (auth, db, crypto, validators, storage, pdf, mail)
/prisma  (schema.prisma, seed.ts, briefing-seed.json)
/storage/uploads  (volume Docker, fora de /public)
```

## Ordem de execução
01 setup → 02 schema → 03 seed → 04 auth/cadastro → 05 motor do formulário → 06 popup de ajuda → 07 rascunho e envio → 08 anexos → 09 painel admin → 10 PDF e notificações → 11 LGPD/segurança → 12 deploy. Acompanhar em `99-progresso.md`.