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

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.
Login / recuperação de senha por e-mail.
Meus briefings: o cliente cria um briefing (um cliente pode ter mais de um, ex.: um site por empresa) e continua de onde parou.
Preenchimento: tela por seção, barra de progresso, botão Ajuda por pergunta (popup), autosave, anexos na seção 19.
Envio: confirmação do cliente (texto da seção "Confirmação do cliente") → status ENVIADO, bloqueia edição (admin pode reabrir).
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.

4.0 KiB Raw Permalink Blame History