Repository navigation
Add plagiarism/similarity detection for submissions (JPlag-style) #42
Description
Summary
microHelium has no way to detect copied/near-identical submissions across teams. For academic/school-hosted contests (a real use case given this platform's Portuguese-language, education-oriented context) this is a meaningful gap.
Inspiration
cd-moj/cdmoj (a Brazilian online judge, "MOJ") runs JPlag (an open-source, language-aware source-code similarity detector) as a background job over each user's latest Accepted submission per problem/language, and surfaces pairwise similarity scores in an admin UI per problem.
Current state in microHelium
Run(app/Models/Run.php) storessource_fileper submission andsource_hash(currently only used for duplicate-submission detection inSubmitController).- No comparison across different users' submissions exists anywhere.
Suggested scope
- A queued job (
App\Jobs\RunPlagiarismCheckJobor similar), triggered per-problem (on demand from an admin screen, not automatically on every submission -- JPlag comparisons are O(n²) per problem and only useful once a problem has enough submissions). - Shell out to the JPlag JAR (add it as a judge-container dependency, similar to how
tools/safeexec.cis already vendored and compiled inDockerfile.judge) against each team's latest Accepted run's source file per language. - Store pairwise results (
problem_id,run_id_a,run_id_b,similarity_score) in a new table. - Admin view listing pairs above a configurable similarity threshold, linking to both submissions' source.
Why this matters
Academic contests in particular need a documented, defensible way to flag suspected copying; without it, the only recourse today is a human judge eyeballing source code by hand.
Activity
matbrgz commentedon Sep 11, 2026
Vou assumir o frontend e a especificação de integração desta issue, conforme solicitado pelo mantenedor, na worktree isolada
feat/issue-frontends-specs, baseada emmasterapós o PR #35.Tela administrativa de similaridade: seleção de problema/linguagem, solicitação de análise, acompanhamento do processamento e pares com links para as duas submissões. A interface tratará similaridade como indício para revisão humana. Spec: snapshot das últimas AC por equipe, contrato assíncrono, permissões, limites e erros do JPlag.
Antes da implementação, registro a divisão: minhas mudanças serão interfaces, rotas GET de apresentação, testes de frontend e specs em
docs/specs/. Models, migrations, jobs, regras de domínio e endpoints de dados/mutação ficam com o time de backend. As interfaces só habilitarão ações quando o contrato real estiver disponível; haverá estado de indisponibilidade, sem confirmação fictícia de sucesso.Critérios de aceite do frontend: navegação por teclado, labels visíveis, feedback de processamento/erro, cores sem significado exclusivo, layout responsivo e testes dos fluxos principais. Vou vincular o PR e os contratos finais aqui; esta entrega não encerra a implementação de backend da issue.
matbrgz commentedon Sep 11, 2026
Entrega publicada no PR #70: #70
Spec desta issue · Índice dos contratos
Frontend implementado com estados de carregamento, vazio, erro e permissões. Os endpoints de dados/mutação ainda dependem da implementação do contrato pelo backend; nenhuma confirmação de sucesso é simulada.
Validação da branch: 604 testes PHP (3248 assertions), 26 testes de frontend e build aprovados. Fluxos Vue foram testados com contratos de teste; integração funcional exige endpoints reais. Revisão visual de biblioteca/enunciado feita no navegador, incluindo 375 px; telas administrativas tiveram revisão de código/componentes, com conferência visual limitada por bloqueio de outra extensão no Chrome.
As responsabilidades e critérios de aceite estão na spec. Este PR não encerra o trabalho pendente do backend.
Normalize payload key order before hashing in IdempotencyStore (#75)
Similarity analysis backend (issue #42) (#74)