F07 — Acompanhar histórico e status de notificações
IT2 Concluída · Rastreabilidade: F07 · CP9 · OE3
Issue da Feature (GitHub): #179 — abrir no GitHub
Protótipo: Protótipo V2 (IT1) — está na seção de notificações do protótipo geral do painel administrativo.
Deploy: link a definir
Esta funcionalidade exige login de administrador.
E-mail: owner@crianex.com · Senha: Crianex@Owner1
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).
- RF46
- RF47
- RNF03
- RNF09
- DoR
- DoD
RF46 — Listar histórico de notificações
Critérios de aceite (BDD)
- Dado admin autenticado, quando acessar o painel de notificações, então o histórico é exibido ordenado por data/hora (mais recentes primeiro) com o status (lida/não lida) de cada notificação.
- Dado notificações não lidas, quando a central carrega, então um contador de não lidas é exibido refletindo exatamente a quantidade real.
- Dado nenhuma notificação registrada, quando a central carrega, então um estado vazio amigável é exibido sem erro.
- Dado requisição sem sessão válida ou sem privilégio, quando GET da listagem, então a API retorna 401/403 via RLS sem expor dados.
- Dado o volume de notificações, quando a central carrega, então a listagem responde em ≤ 2s em 95% das requisições.
Regras de negócio: RN13 — Geração automática de notificações por eventos-chave (nunca criadas manualmente)
Evidência (screenshot):

Deploy: link a definir
RF47 — Alterar status da notificação
Critérios de aceite (BDD)
- Dado notificação não lida, quando o admin a marca como lida, então o status passa a
readsem reload e o contador de não lidas decrementa (atualização otimista). - Dado notificação já lida, quando a ação é reenviada, então permanece
readsem erro nem alteração indevida (idempotência). - Dado falha de rede/servidor no PATCH, quando a atualização não confirma, então o estado é revertido na UI e uma mensagem de erro é exibida.
- Dado tentativa de alterar notificação de outro perfil, quando o PATCH chega à API, então o RLS bloqueia com 403.
Regras de negócio: —
Evidência (screenshot):

Deploy: link a definir
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 — 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
Definition of Ready — Evidências
Checklist do DoR aplicado à F07 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 #179 — 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 #179 — 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 |
Definition of Done — Evidências
Checklist do DoD verificado ao encerrar a F07. 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 #179 — evidências anexadas na descrição da issue |
| Testes automatizados passando (unitários + integração) | ✅ | Issue #179 — evidências anexadas na descrição da issue |
| Lint sem erros e formatação OK (ESLint + Prettier) | ✅ | Issue #179 — evidências anexadas na descrição da issue |
| CI verde (build + testes + lint) | ✅ | Issue #179 — evidências anexadas na descrição da issue |
| PR aprovado por Chief Programmer ou Project Manager | ✅ | Issue #179 — PR de resolução com approve registrado |
| Migration de banco aplicada | ✅ | Issue #179 — evidências anexadas na descrição da issue |
| Sem vulnerabilidades críticas (SAST/linting de segurança) | ✅ | Issue #179 — 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 #179 — fechada via merge do PR (closes #N) |