F19 — Gerenciar clientes e leads no CRM

IT2 Concluída · Rastreabilidade: F19 · CP1 · OE3

Issue da Feature (GitHub): #177 — abrir no GitHub

Protótipo: Protótipo CRM (IT2) — compartilhado entre F19, F20 e F21 (mesmo board Kanban).

Deploy: link a definir

Acesso para avaliação

Esta funcionalidade exige login de administrador.

E-mail: owner@crianex.com · Senha: Crianex@Owner1

Refinamento pós-implementação

RF60, RF61 e RF62 foram adicionados após a entrega inicial, a partir de uma auditoria de rastreabilidade — cobrem busca/filtros, exportação CSV e visualização em tabela/indicadores do funil, capacidades que faltavam além do CRUD básico de leads. Detalhamento completo em Resultados V&V da IT2 — MR.02.

Requisitos (evidências)

Selecione um requisito na navegação abaixo. Cada um traz seus critérios de aceite, regras de negócio e um espaço para o screenshot da funcionalidade em funcionamento (substitua a imagem de placeholder pela captura real).

RF37

RF37 — Cadastrar lead no CRM

Critérios de aceite (BDD)

• Dado admin autenticado com dados válidos, quando cadastrar lead, então um card é criado na coluna inicial com os dados persistidos.
• Dado campos obrigatórios vazios, quando submeter, então a validação impede a criação.
• Dado requisição sem permissão, quando POST do lead, então o RLS bloqueia com 403.

Regras de negócio: RN19 — Entrada do lead no funil (todo lead cadastrado entra na coluna inicial padrão)

Evidência (screenshot):

Deploy: link a definir

RF35

RF35 — Editar dados do cliente/lead

Critérios de aceite (BDD)

• Dado card existente, quando editar os dados do cliente/lead, então as alterações são persistidas sem duplicar o registro.
• Dado campos inválidos, quando submeter, então a validação impede e mantém os dados anteriores.
• Dado cliente/lead inexistente, quando editar, então retorna 404 sem efeito.

Regras de negócio: —

Evidência (screenshot):

Deploy: link a definir

RF36

RF36 — Inativar cliente/lead

Critérios de aceite (BDD)

• Dado cliente/lead ativo, quando inativar, então o registro passa a inactive e sai do fluxo ativo do funil.
• Dado cliente/lead inativo, quando reativar, então volta ao fluxo ativo.

Regras de negócio: RN20 — Inativação preserva o registro (soft-delete; cliente/lead sai do fluxo ativo mas não é excluído)

Evidência (screenshot):

Deploy: link a definir

RF41

RF41 — Atualizar dados operacionais dos cards

Critérios de aceite (BDD)

• Dado card no CRM, quando arrastar para outra coluna (drag-and-drop), então o estágio é atualizado em ≤ 1,5s sem reload.
• Dado card com dados visíveis, quando clicar, então os detalhes expandem sem redirecionamento de página.
• Dado falha ao persistir o novo estágio, quando o drag não confirma, então o card retorna à coluna de origem (rollback visual).

Regras de negócio: —

Evidência (screenshot):

Deploy: link a definir

RF60

RF60 — Filtrar e buscar leads no CRM

Novo — refinamento pós-implementação

Critérios de aceite (BDD)

• Dado leads cadastrados no funil, quando o admin digita um termo na busca, então os cards exibidos são filtrados por nome ou e-mail em tempo real, sem reload.
• Dado um produto selecionado no filtro, quando aplicado, então somente leads vinculados a esse produto são exibidos, com a contagem por produto refletida nos chips de filtro.
• Dado um responsável selecionado no filtro, quando aplicado, então somente leads atribuídos a esse responsável são exibidos.
• Dado múltiplos filtros combinados (produto + responsável + busca), quando aplicados, então os resultados atendem a todos os critérios simultaneamente (E lógico).

Regras de negócio: RN24 — Escopo de busca, filtros e exportação do CRM (opera somente sobre leads ativos)

Evidência (screenshot):

Deploy: link a definir

RF61

RF61 — Exportar leads do CRM em CSV

Novo — refinamento pós-implementação

Critérios de aceite (BDD)

• Dado leads visíveis após os filtros aplicados, quando o admin aciona "Exportar CSV", então um arquivo CSV é gerado e baixado contendo apenas os leads filtrados.
• Dado o arquivo exportado, quando aberto, então contém nome, e-mail, telefone, estágio, responsável, produto, status e última interação de cada lead.
• Dado nenhum filtro aplicado, quando exportado, então todos os leads ativos são incluídos.

Regras de negócio: RN24 — Escopo de busca, filtros e exportação do CRM (exportação reflete os filtros aplicados)

Evidência (screenshot):

Deploy: link a definir

RF62

RF62 — Visualizar leads em tabela e indicadores do funil

Novo — refinamento pós-implementação

Critérios de aceite (BDD)

• Dado leads no funil após os filtros aplicados, quando o admin acessa o CRM, então um painel exibe total de leads, leads sem interação há 7+ dias, total de interações registradas e número de colunas do pipeline.
• Dado um filtro aplicado (produto/responsável/busca), quando alterado, então os indicadores são recalculados imediatamente para refletir o subconjunto filtrado.
• Dado a visualização em Kanban, quando o admin alterna para o formato de tabela, então os mesmos leads filtrados são exibidos em linhas ordenáveis por nome, produto, estágio, responsável e atividade.

Regras de negócio: RN24 — Escopo de busca, filtros e exportação do CRM (indicadores refletem os filtros aplicados)

Evidência (screenshot):

Deploy: link a definir

RNF01

RNF01 — Isolamento de acesso administrativo

Classificação: Segurança
Descrição: Toda rota do painel administrativo é servida em endpoint/caminho distinto do site público e exige token de sessão (JWT) válido; requisições sem token válido recebem HTTP 401/403 e nunca renderizam dados administrativos, mesmo parcialmente.

Evidência (screenshot):

Verificação: Resultados V&V da IT2

RNF03

RNF03 — Tempo de resposta da área administrativa

Classificação: Eficiência
Descrição: 95% das operações de leitura no painel administrativo (listagens, dashboards, detalhes de registro) retornam em até 2 segundos, do disparo da requisição HTTP à resposta completa da API, sob carga normal de uso (≤ 10 usuários simultâneos).

Evidência (screenshot):

Verificação: Resultados V&V da IT2

RNF09

RNF09 — Controle de acesso por linha (RLS)

Classificação: Segurança
Descrição: Toda tabela com dados sensíveis (clientes, leads, notificações, membros) tem política de Row Level Security ativa no banco, restringindo leitura/escrita ao perfil autorizado mesmo em acesso direto ao banco; verificado por teste com credencial de perfil não autorizado.

Evidência (screenshot):

Verificação: Resultados V&V da IT2

RNF11

RNF11 — Conformidade parcial com LGPD

Classificação: Externo
Descrição: A captação de dados de leads/clientes exige consentimento explícito registrado antes da persistência, informa a finalidade do tratamento, coleta apenas dados estritamente necessários (minimização) e permite exclusão mediante solicitação em até 5 dias úteis.

Evidência (screenshot):

Verificação: Resultados V&V da IT2

RNF24

RNF24 — Cards do CRM resumidos e expansíveis

Classificação: Usabilidade
Descrição: Cada card de lead/cliente no board Kanban exibe, em estado resumido, nome, produto vinculado e responsável, sendo expansível (clique) para o detalhe completo e o histórico de interações sem redirecionamento de página.

Evidência (screenshot):

Verificação: Resultados V&V da IT2

RNF25

RNF25 — Atualização drag-and-drop dos cards do CRM

Classificação: Usabilidade
Descrição: Mover um card entre colunas do funil por arrastar-e-soltar atualiza visualmente a coluna do card em até 1,5s após soltar, sem recarregar a página; falha ao persistir retorna o card à coluna de origem (rollback visual).

Evidência (screenshot):

Verificação: Resultados V&V da IT2

DoR

Definition of Ready — Evidências

Checklist do DoR aplicado à F19 antes de entrar em execução. Todos os itens foram atendidos conforme o critério definido em DoR e DoD.

Critério DoR	Status	Evidência
Título no padrão FDD <ação> <resultado> <de/para/no/com> <objeto>	✅	Issue #177 — título conforme o padrão
Critérios de aceite escritos e verificáveis (Given/When/Then)	✅	Ver abas RF/RNF desta página — todos os cenários BDD documentados
Estimativa registrada: VB, CX e IP calculados	✅	Priorização do Backlog — coluna IP da tabela de features
Dependências identificadas; bloqueantes resolvidos	✅	Mapa de Dependências — IT2 — bloqueantes verificados antes do início
Class Owner designado e linkada à Feature parent e à CP de origem	✅	Issue #177 — assignees e labels de CP/Feature registrados
Protótipo revisado pelo cliente	✅	Protótipo CRM (IT2)
Technical Design Review (TDR) concluída	✅	Design Técnico IT2
Ao menos um critério de segurança ou usabilidade identificado	✅	Ver aba RNF desta página

DoD

Definition of Done — Evidências

Checklist do DoD verificado ao encerrar a F19. Todos os itens foram atendidos antes de mover a issue para Done no Kanban.

Critério DoD	Status	Evidência
Critérios de aceite validados (BDD cobertos)	✅	Issue #177 — evidências anexadas na descrição da issue
Testes automatizados passando (unitários + integração)	✅	Issue #177 — evidências anexadas na descrição da issue
Lint sem erros e formatação OK (ESLint + Prettier)	✅	Issue #177 — evidências anexadas na descrição da issue
CI verde (build + testes + lint)	✅	Issue #177 — evidências anexadas na descrição da issue
PR aprovado por Chief Programmer ou Project Manager	✅	Issue #177 — PR de resolução com approve registrado
Migration de banco aplicada	✅	Issue #177 — evidências anexadas na descrição da issue
Sem vulnerabilidades críticas (SAST/linting de segurança)	✅	Issue #177 — evidências anexadas na descrição da issue
Validação parcial do cliente registrada	✅	Validação Parcial IT2
Validação Formal aprovada pelo cliente	✅	Validação Formal IT2
Rastreabilidade atualizada	✅	Tabela de Requisitos — RF/RNF vinculados
Issue movida para Done no GitHub Projects	✅	Issue #177 — fechada via merge do PR (closes #N)