US2.10

Notificações de Status de Candidatura (RF12)

História de Usuário

Como usuário, quero receber notificações sobre mudanças de status de candidaturas para me manter informado em tempo hábil sobre o andamento das minhas inscrições e das vagas que publico.

Rastreabilidade

Item	Código / Referência
User Story	US2.10
Requisito Funcional	RF12 — Acompanhar candidatura
Característica de Produto	CP02 — Ciclo de Vagas e Engajamento
Requisitos Não-Funcionais	RNF04 (responsivo iOS/Android)
Release Planejada	R2 — Perfis e Conexão

Descrição

Implementar o sistema de notificações sobre mudanças de situação das candidaturas. O estudante deve ser notificado quando sua candidatura for aprovada ou recusada pela organização. A organização deve ser notificada quando receber uma nova candidatura em uma de suas vagas. As notificações devem ser visíveis em um centro de notificações dentro da plataforma. Esta funcionalidade compõe, juntamente com US2.9 (cancelamento), o módulo de acompanhamento de candidaturas (RF12). O escopo é full-stack.

Critérios de Aceite (BDD / Gherkin)

Cenário 1: Notificação de candidatura aprovada

Dado que a organização aprovou a candidatura da estudante "Maria Silva" para a vaga "Apoio em Eventos"
Quando a avaliação é registrada no sistema
Então o sistema gera uma notificação para Maria com o texto "Sua candidatura para Apoio em Eventos foi aprovada!" e a exibe no centro de notificações

Cenário 2: Notificação de candidatura recusada

Dado que a organização recusou a candidatura do estudante "João Souza"
Quando a avaliação é registrada
Então o sistema gera uma notificação para João com o texto "Sua candidatura para a vaga foi recusada" e a exibe no centro de notificações

Cenário 3: Notificação de nova candidatura para a organização

Dado que a estudante "Maria Silva" se candidatou à vaga "Apoio em Eventos" da organização "ONG Esperança"
Quando a candidatura é registrada
Então o sistema gera uma notificação para a organização com o texto "Nova candidatura: Maria Silva se candidatou para Apoio em Eventos"

Cenário 4: Centro de notificações com indicador de não lidas

Dado que o estudante "João Souza" possui 3 notificações não lidas
Quando acessa a plataforma
Então o sistema exibe um indicador com o número 3 no ícone de notificações e, ao abrir o centro de notificações, lista as notificações com destaque visual para as não lidas

Cenário 5: Marcar notificação como lida

Dado que o estudante possui notificações não lidas no centro de notificações
Quando clica em uma notificação específica ou no botão "Marcar todas como lidas"
Então o sistema atualiza o estado das notificações para lidas e remove o indicador numérico

Regras de Negócio

As notificações devem ser geradas automaticamente quando ocorrerem os seguintes eventos: aprovação de candidatura, recusa de candidatura e recebimento de nova candidatura pela organização.
Cada notificação deve conter: o tipo de evento, o título da vaga relacionada, o nome do estudante ou organização envolvida, a data e o horário do ocorrido e um indicador se já foi lida ou não.
O centro de notificações deve exibir um contador de notificações não lidas, visível em toda a plataforma enquanto houver notificações pendentes.
As notificações devem ser apresentadas em ordem cronológica inversa, das mais recentes para as mais antigas.
Notificações antigas (com mais de 90 dias) podem ser removidas automaticamente do centro de notificações para manter a interface organizada.

Requisitos Técnicos

Backend: Django + DRF. Criar modelo Notification com campos: recipient (FK → User), type (choices: application_approved, application_rejected, new_application), title, message, related_opportunity (FK → Opportunity, nullable), related_application (FK → Application, nullable), is_read, created_at.
Endpoint: GET /api/v1/notifications/ — listar notificações do usuário. PATCH /api/v1/notifications/{id}/read/ — marcar como lida. PATCH /api/v1/notifications/read-all/ — marcar todas como lidas.
Gatilhos: Criar notificações nos signals/eventos de: Application.status alterado para approved, Application.status alterado para rejected, nova Application criada.
Frontend: React Native + Expo + NativeWind. Ícone de sino com badge numérico no header, centro de notificações com lista de cards, ação de marcar como lida com toque.
Responsividade: Layout adaptável a iOS e Android (RNF04).
Testes: pytest para testar geração automática de notificações nos eventos de candidatura, listagem, marcação como lida e permissão de acesso.

Referências de Design

Protótipo Figma (Geral): https://www.figma.com/design/f6bQuVohTvZLF5WWPEbNob/Liaison?node-id=647-2&t=Bn4zGHNjZFTDPrK5-0

Dependências

Relacionada a: #22 (Candidatura — RF10/US2.7), #24 (Avaliação de Candidaturas — RF11/US2.8)
Bloqueada por: #22 (RF10 — Realizar candidatura), #24 (RF11 — Avaliar candidatura)
Bloqueia: N/A

Notas

ICE Score: I=8 C=7 E=6 = 336 | MoSCoW: Must | Quadrante: Quick Win
RF12 (US2.10) complementa US2.9 (cancelamento de candidatura). Enquanto US2.9 tem complexidade majoritariamente de backend, US2.10 adiciona também a camada de frontend para o centro de notificações.
No MVP, as notificações serão apenas internas (in-app). Notificações push e por e-mail podem ser consideradas como melhoria futura.
Os gatilhos de notificação devem ser implementados preferencialmente via Django Signals para desacoplamento do código de avaliação de candidaturas.

Definição de Preparado (DoR)

Item de Verificação (Universal)	Evidência / Rastreabilidade	Situação
A história está bem descrita e com critérios de aceite?	Documentada e alinhada com o escopo do MVP.	✔ Sim
Possui protótipos de interface necessários?	Interface mapeada e disponível no Figma da equipe.	✔ Sim
A história é independente o suficiente para ser entregue?	Cadeia de dependências resolvida (vide Matriz MVP).	✔ Sim
Foi estimada pela equipe?	Estimada utilizando o método ICE Score.	✔ Sim

Definição de Pronto (DoD)

Pergunta Fundamental (Universal)	Evidência de Implementação	Status
O código foi implementado e revisado?	Pull Request aprovado e fundido na branch principal.	✔ Sim
Coerente com o protótipo validado?	O layout segue os componentes e tokens de design.	✔ Sim
Passou nos testes necessários?	Testes (unitários/integração) executados e aprovados.	✔ Sim
A documentação está atualizada?	Atualizada no repositório de requisitos.	✔ Sim

Critérios de Aceitação (CA)

Candidatura aprovada: Quando a organização aprova uma candidatura, o estudante recebe uma notificação: "Sua candidatura para [nome da vaga] foi aprovada!"
Candidatura recusada: Quando a organização recusa, o estudante recebe notificação informando que foi recusado.
Nova candidatura recebida: Quando um estudante se candidata a uma vaga, a organização recebe notificação: "Nova candidatura: [nome do estudante] se candidatou para [nome da vaga]".
Indicador de não lidas: O usuário vê um número no ícone de notificações indicando quantas ainda não foram lidas.
Marcar como lida: O usuário consegue marcar notificações individualmente ou todas de uma vez como lidas, removendo o indicador numérico.*

Acesso & Evidência

Código Homologado: Repositório Principal
Status de Conclusão: 100% Entregue (conforme Matriz de Completude).