[DASHBOARD Q.A - DASHBOARD ] - Telas de baixa fidelidade da visualização e triagem de relatos pendentes

[GabrielAderaldo]

Este card trata da construção das telas de baixa fidelidade (wireframes) para a área de triagem de relatos pendentes no painel do QA. Essa funcionalidade é onde o QA visualiza os relatos recém-submetidos pelos usuários e toma decisões sobre o que será transformado em um bug oficial.

A tela deve conter todos os caminhos possíveis que o relato pode seguir, garantindo uma representação funcional completa da jornada do QA ao lidar com relatos pendentes. Aqui já devemos prever integrações futuras com WebSocket e elementos que indiquem mudanças em tempo real.

---

🎯 Objetivo:

• Criar wireframes completos para todos os fluxos possíveis da triagem
• Mapear e desenhar os estados de erro, sucesso, vazio e carregamento
• Antecipar a dinâmica com novos relatos chegando via WebSocket
• Representar visualmente os 3 caminhos possíveis: aprovar, duplicado, descartar

---

🧠 Fluxo Escrito com Base no Sistema:

1. O usuário final envia um relato por formulário
2. O backend salva esse relato com o status pendente
3. O sistema dispara um WebSocket para atualizar o dashboard do QA
4. O QA vê o novo relato na interface
5. O QA pode aplicar filtros, clicar em um relato e tomar uma decisão:
   • Aprovar como bug → Cria bug oficial, envia para GitHub, Google Sheets e Discord
   • Marcar como duplicado → Apenas arquiva como duplicado, sem notificar sistemas externos
   • Descartar relato → Relato descartado e arquivado internamente
6. Após qualquer ação, o dashboard atualiza automaticamente

---

🎯 Fluxograma atualizado (estilo Mermaid):

flowchart TD
    A[Usuário envia relato] --> B[Relato salvo no banco como 'pendente']
    B --> C[WebSocket atualiza dashboard QA]
    C --> D[QA visualiza relato no painel]
    D --> E{QA toma decisão}

    E --> F1[Aprovar como bug]
    E --> F2[Marcar como duplicado]
    E --> F3[Descartar relato]

    F1 --> G1[Backend cria bug oficial]
    G1 --> H1[Envia para GitHub, Sheets e Discord]

    F2 --> G2[Relato marcado como duplicado]
    G2 --> H2[Atualiza dashboard, mas não cria bug]

    F3 --> G3[Relato descartado]
    G3 --> H3[Atualiza dashboard e arquiva relato]

Loading

---

🧱 Elementos obrigatórios no wireframe:

Elemento	Observação
Lista de relatos pendentes	Pode ser em cards ou tabela
Três ações visuais por relato	Aprovar, Duplicado, Descartar
Representação de tempo real	Placeholder para novo relato chegar
Estado de erro	Algo deu errado ao carregar
Estado vazio	"Nenhum relato no momento"
Estado de carregamento	Spinner ou esqueleto
Placeholder para filtros	Visual simples, mas claro
Contador de relatos pendentes	Sempre visível no topo da tela

---

📎 Critérios de Aceite:

Critério	Avaliação
Todos os estados (erro, vazio, carregando, sucesso) estão mapeados	✅
Todas as ações possíveis do QA estão representadas visualmente	✅
Há indicação clara de que o sistema é atualizado por WebSocket	✅
A estrutura do layout já considera expansão e filtros	✅
Wireframe é funcional, claro e 100% sem estilo visual	✅
Card validado pelo P.O antes de seguir para média fidelidade	✅

---

Tip

A ideia aqui é prever o funcionamento real, não a aparência. Imagine que esse wireframe fosse a única fonte de verdade para o dev começar a implementar a feature — tudo precisa estar ali (menos estilo).

Warning

Se faltar qualquer estado, ação ou interação principal, o QA deve reprovar esse card imediatamente.

Note

Se houver dúvida, leia o EPICO PAI ou fale com o P.O (Gabriel).

---