exams

O submódulo Exams é dividido em três controllers que, juntos, cobrem a autoria e a realização de exames. O `ExamController` (`/lms/exams`) é dono das definições de exame — título, código, limite de pontuação, limite de tempo, flags de embaralhamento/visibilidade do gabarito, nível e status — além de uma superfície aninhada de gerenciamento de questões para adicionar, editar, remover e reordenar as questões de cada exame. Cinco tipos de questão são suportados: multiple_choice e true_false são corrigidos automaticamente contra as alternativas marcadas como corretas (true_false exige estritamente exatamente duas), essay é armazenada sem correção para revisão manual, fill_blank é corrigida por correspondência exata insensível a maiúsculas/minúsculas contra uma ou mais respostas aceitas, e matching é corrigida por comparação exata do conjunto de pares esquerda/direita. Uma escolha de design pequena mas fácil de perder: o `GET /lms/exams/:id` retorna `null` em vez de um 404 quando o exame não existe, e vários endpoints de gerenciamento de questões (excluir, reordenar) são no-ops em vez de erros quando o alvo não existe ou o conjunto de IDs enviado não corresponde — os chamadores devem verificar o formato da resposta em vez de confiar puramente no status HTTP.

O `QuestionController` (`/lms/questions`) é um banco de questões avulso, separado e mais plano — questões criadas aqui não são vinculadas a nenhum exame no momento da criação, útil para construir um banco de itens reutilizável antes de montar exames, ou para outras partes da plataforma que precisam de questões corrigidas ad-hoc fora do fluxo de tentativa de exame.

O `ExamAttemptController` (também sob `/lms/exams`) é a metade voltada ao aluno: iniciar uma tentativa, salvar respostas em andamento e submeter para correção. O `GET /:id/attempt` finaliza automaticamente uma tentativa se seu limite de tempo tiver silenciosamente expirado, e resolve a qual registro `person` a tentativa pertence via uma cadeia de fallback — sobrescrita explícita por `studentId`, depois person correspondente por e-mail, e então (como último recurso) criando automaticamente um novo registro de person para o usuário chamador, o que é um efeito colateral notável que vale conhecer antes de fazer scripts contra este endpoint com uma service account recém-criada. Iniciar uma nova tentativa é idempotente em relação a uma tentativa em andamento existente e não expirada, e a submissão publica um evento de integração `lms.exam.attempt.submitted` carregando a pontuação final e o resultado de aprovação/reprovação para consumidores downstream (por exemplo, concessão de conquistas ou relatórios de licença corporativa) reagirem.