US3.3

Geração Automática de Certificado Digital (RF15)

História de Usuário

Como estudante, quero receber meu certificado digital em PDF ao concluir uma atividade de voluntariado.

Rastreabilidade

Item	Código / Referência
User Story	US3.3
Requisito Funcional	RF15 — Emitir certificado
Característica de Produto	CP03 — Acompanhamento e Certificação Acadêmica
Requisitos Não-Funcionais	RNF08 (imutabilidade de certificados), RNF09 (UUIDs para certificados)
Release Planejada	R4 — Certificação

Descrição

Permitir a emissão de um certificado digital em PDF a partir do registro de frequência do estudante numa atividade de voluntariado. O certificado reúne os dados do estudante (nome), da atividade (título, carga horária atestada) e da organização (nome, CNPJ), recebe um código de validação único e fica disponível para o estudante. É o objetivo final da plataforma: transformar horas de voluntariado em documento comprobatório com validade acadêmica.

Critérios de Aceite (BDD / Gherkin)

Cenário 1: Geração do certificado após registro de frequência

Dado que a organização registrou a presença da estudante "Maria Silva" com 20 horas cumpridas na atividade "Apoio em Eventos"
Quando a frequência é confirmada
Então o sistema gera um certificado digital em PDF contendo nome da estudante, título da atividade, carga horária de 20 horas, nome e CNPJ da organização, data de emissão, código de validação único e QR Code com link de validação

Cenário 2: Certificado disponível para o estudante

Dado que o certificado da atividade "Apoio em Eventos" foi gerado para "Maria Silva"
Quando a estudante acessa seus certificados
Então o sistema exibe apenas os certificados dela, com a opção de visualizar ou baixar o PDF

Cenário 3: Certificado não gerado sem frequência registrada

Dado que a estudante "Maria Silva" foi aprovada para a vaga "Aulas de Reforço", mas a organização ainda não registrou sua presença
Quando se tenta emitir o certificado
Então o sistema impede a emissão, pois não há frequência confirmada

Cenário 4: Imutabilidade do certificado após emissão

Dado que o certificado de "Maria Silva" para "Apoio em Eventos" já foi emitido com 20 horas
Quando se tenta alterar os dados do certificado já emitido
Então o sistema bloqueia a alteração e mantém o certificado original

Cenário 5: Dados corretos no PDF

Dado que o certificado foi gerado para "Maria Silva"
Quando o PDF é aberto
Então o documento exibe layout padronizado com identidade visual do Liaison, todos os dados legíveis, e o QR Code que direciona ao portal de validação

Cenário 6: Emissão única por atividade

Dado que "Maria Silva" já tem certificado emitido para "Apoio em Eventos"
Quando se tenta emitir um segundo certificado para a mesma estudante e atividade
Então o sistema impede a emissão duplicada

Regras de Negócio

O certificado digital é emitido a partir do registro de presença do estudante numa atividade de voluntariado.
Cada certificado recebe um código único de validação, gerado na emissão, que permite a verificação pública de autenticidade.
Conteúdo obrigatório: nome completo do estudante, título da atividade, carga horária atestada, nome e CNPJ da organização e data de emissão.
Uma vez emitido, o certificado é imutável: nenhum dado do certificado pode ser alterado.
Há no máximo um certificado por estudante e atividade.

Requisitos Técnicos

Backend: Django + DRF. Modelo Certificate 1:1 com Application — student/opportunity/organization são acessados via certificate.application.* (sem tabela Attendance; frequência é estado da Application). Campos: id (UUID PK), application (OneToOneField, PROTECT), hours (snapshot da carga atestada), pdf_file (FileField), validation_uuid (UUIDField, unique, default=uuid4), issued_at (auto_now_add), revoked_at (nullable). Imutabilidade pós-emissão no save() (só pdf_file/revoked_at mutáveis).
Geração de PDF: reportlab (pip puro, sem deps de sistema). QR Code via qrcode[pil] apontando para {CERT_VALIDATION_BASE_URL}/{validation_uuid}. Layout com identidade visual do Liaison (Figma node 654:2).
Geração síncrona, sem Celery. PDF de 1 página gera em ~200 ms; Celery seria desproporcional. RNF07 segue "Won't Have". Lógica isolada em services.py/pdf.py — ponto único de troca se surgir necessidade de lote.
Storage: pdf_file em storage local ou S3 conforme USE_S3.
Endpoints: GET /api/v1/certificates/ (lista do próprio estudante); GET /api/v1/certificates/{id}/download/ (download, dono only). POST /api/v1/certificates/issue/ (org dona da vaga) — temporário até #27 plugar o trigger no mesmo service issue_certificate(application, hours).
Frontend: fora do escopo desta issue (cai em #34).
Testes: pytest cobrindo emissão via service (PDF não-vazio + dados presentes), unicidade de UUID, imutabilidade, list só-do-dono, download dono/não-dono e o endpoint issue/.

Referências de Design

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

Dependências

Relacionada a: #27 (Registro de Frequência — RF14/US3.2), #26 (Listagem de Aprovados — RF13/US3.1), #30 (Portal de Validação — RF17/US3.7)
Bloqueia: #32 (Exportação de Certificado — RF15/US3.4), #30 (Validação de Certificado — RF17/US3.7), #33 (Histórico de Horas — RF16/US3.5), #34 (Download de Certificados — RF16/US3.6)

Notas

ICE Score: I=10 C=5 E=3 = 150 | MoSCoW: Must | Quadrante: Plan
RF15 é um dos itens mais críticos do backlog — objetivo final da plataforma (I=10).

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)

Geração após presença confirmada: Assim que a organização registra a presença do estudante, o sistema gera um certificado em PDF com: nome do estudante, título da atividade, carga horária, nome e CNPJ da organização, data de emissão, código de validação único e QR Code.
Certificado acessível pelo estudante: O estudante acessa a lista de seus certificados e consegue visualizar ou baixar o PDF da atividade concluída. Ele só vê seus próprios certificados.
Sem presença, sem certificado: Se a organização ainda não tiver registrado a presença, o sistema impede a emissão do certificado.
Imutabilidade: Um certificado já emitido não pode ter seus dados alterados.
PDF correto: O documento exibe layout padronizado com identidade visual do Liaison, com todos os dados legíveis e o QR Code funcional.
Unicidade: Não é possível emitir um segundo certificado para o mesmo estudante na mesma atividade.

Acesso & Evidência

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