RFC: reavaliar todos os status e transições do funil de candidaturas #108

Contexto

Reavaliar todos os status do funil de candidaturas no Applywell antes de qualquer refatoração. Esta é uma issue de análise/RFC, não uma autorização para migrar dados ou alterar regras agora.

Um caso real em 09/11/2026 expôs ambiguidade: ~30 candidaturas foram enviadas automaticamente por e-mail (DevScout). Inicialmente ficaram em Pending HR Response, embora não tivesse ocorrido triagem, contato ou avanço. A interpretação correta no modelo atual é RH = candidatura enviada (Applied). Após correção, 29 registros ficaram em RH e um em Rejected por incompatibilidade geográfica.

Outro caso: a Vetta cancelou a vaga por razões internas, mas como não existe status Cancelled, ficou em Rejected com observação, distorcendo o significado de rejeição do candidato.

Status atuais (revisar todos)

• RH
• Pending HR Response
• Pending Hiring Manager Response
• Technical Test
• Pending Technical Test Response
• Offer Negotiation
• Ghosting
• Rejected
• Approved

Perguntas para a avaliação

• RH deveria ser renomeado para Applied / Candidatura enviada? É preciso um estado anterior para prospecção / rascunho / não enviado?
• O que caracteriza contato efetivo de recrutador, triagem de RH, espera de resposta do RH e avanço para hiring manager? Quais eventos documentam uma transição?
• Teste técnico recebido, em andamento, enviado e aguardando avaliação devem ser status separados ou eventos/atributos?
• Como modelar entrevistas agendadas/realizadas (inclusive múltiplas) sem confundir com status e sem inflar contagem?
• Approved significa proposta recebida, aprovada em etapa ou contratado? Como distinguir Offer Negotiation, oferta aceita/recusada e contratação?
• Rejected, Cancelled / vaga encerrada, desistência do candidato, falta de aderência e Ghosting são resultados diferentes. Ghosting deveria ser status terminal ou derivado de ausência de resposta por prazo?
• Como manter archived independente de estágio/resultado? Como tratar datas, lembretes e rastreabilidade?
• Quais status são necessários para candidaturas automáticas e para múltiplas inscrições na mesma empresa?

Escopo da revisão

1. Documentar semântica de cada status, grupos (pré-candidatura, seleção, espera, terminal), critérios objetivos de entrada e saída e transições válidas.
2. Propor nomes PT-BR/UI + identificadores estáveis para API, banco, MCP e integrações externas; avaliar evitar status display name como identificador persistido.
3. Definir tabela de transições com evidência necessária (e-mail enviado, resposta explícita, convite, teste, entrevista, rejeição, cancelamento), sem assumir avanço só por envio ou confirmação automática.
4. Avaliar separar status/stage, resultado/encerramento, eventos no histórico e atributos (entrevista, lembrete, follow-up).
5. Planejar migração retrocompatível dos registros existentes, incluindo históricos RH, Pending HR Response, Ghosting, Rejected e mapeamentos incorretos de cancelamento, sem apagar histórico, alterar entrevista ou arquivamento silenciosamente.
6. Mapear impactos no backend Spring Boot, frontend React, ferramentas MCP, filtros, relatórios, estatísticas, notificações e automações (n8n/ChatGPT).
7. Especificar testes para idempotência, deduplicação, regras de transição, importação de e-mails e workflows de rejeição/cancelamento.

Critérios de conclusão desta issue de análise

• Matriz atual vs. proposta para todos os nove status, com exemplos reais e casos-limite.
• Fluxograma/tabela de transições, incluindo os estados terminais.
• Distinção inequívoca entre Applied, contato com RH e Hiring Manager.
• Estratégia para cancelamento de vaga e falta de retorno, sem contar como rejeição pessoal.
• Impactos e migração detalhados em backend, frontend, MCP e automações, sem perda de dados.
• Decisão do mantenedor sobre implementação e eventual desdobramento em issues menores.

Nota: não implementar mudanças de status automaticamente ao fechar esta issue; primeiro validar a proposta de produto e a migração.