Auditoria de dados e integração da v1.9.6¶

Data da auditoria: 12 de julho de 2026

Branch auditada: main

Commit de referência inicial: 309f9662f1da410349d85fefdcacff8778cea51e Escopo: código Python, FastAPI, React, extensão, scripts, testes, documentação, stores locais e CI.

Método e limites¶

A auditoria comparou rotas, services, módulos, modelos, stores, frontend, testes e documentação. Também inspecionou somente a estrutura dos dados locais para contar registros, duplicatas e referências ausentes; nenhum conteúdo pessoal é reproduzido neste relatório.

As chaves expostas no prompt foram tratadas como comprometidas, não foram usadas, copiadas ou validadas. Os arquivos e endpoints de authenticated-browser foram protegidos por hash antes das mudanças e permaneceram fora do escopo de refatoração.

Estado inicial comprovado:

main, origin/main e a tag publicada anterior apontavam para o mesmo commit;
árvore limpa antes da implementação;
CI e documentação remotos verdes no último commit publicado;
nova tag ainda inexistente;
extensão no manifesto anterior e sem handshake formal;
secret scan do conteúdo rastreado sem padrão de chave Gemini/OpenAI.

Resumo executivo¶

O Perfil Profissional Universal era a fonte preferencial, mas não a única fonte operacional. O ProfileContextOrchestrator já o priorizava e recorria ao perfil legado quando vazio. Match, ATS, Tailor, Radar, Fontes, Tracker, GitHub e Editais consultavam Career Context em graus diferentes; Dashboard, Notificações, Currículo e Inteligência não tinham a mesma profundidade. O Local Companion mantinha ainda active-context.json para currículo/preferências explícitas.

Os maiores riscos encontrados foram stores JSON/JSONL sem schema ou transação cruzada, corrupção convertida silenciosamente em estado vazio, mesma vaga em vários stores sem vínculo, Tracker sem snapshots, eventos de etapa sobrescritos na memória, referências pouco granulares em Lattes/GitHub, fallback OpenAI registrado incorretamente, permissões de IA persistidas mas ignoradas e warnings/trace descartados pelo frontend.

A implementação desta entrega adiciona SQLite versionado, repositories, migração segura, backup/restore/health, snapshots imutáveis, vínculos do Tracker, AiRunStore, dedupe/proveniência reforçados, handshake/fila/snapshots da extensão, envelope de warnings no frontend e manifesto verificável. Stores legados continuam disponíveis e não são apagados.

Inventário de produção e consumo¶

Dado produzido	Persistência	Consumidores	UI	Contexto	Origem / `source_ref`	Dedupe	Snapshot	Teste	Status
Perfil Profissional Universal	`profile/profiles.json`; migração para `profiles`	Orchestrator, API Perfil, Lattes, extensão	Perfil	Sim	Sim	Sugestão conservadora	ResumeSnapshot quando usado	API/Perfil/Contexto	completo
`ProfileItem` confirmado	JSON + `profile_items`	Career Context, Match, ATS, Tailor, Radar, Editais	Perfil e revisão	Sim	Sim	Identidade por referência forte + título em containers	Indireto no currículo	Identidade/Perfil	completo
Candidato de Perfil	Resposta transitória até confirmação	Perfil, Lattes e bridge da extensão	Revisão da extensão/Lattes; GitHub web ainda parcial	Não antes de confirmar	Sim	Local	Não	Perfil/extensão	parcial
Perfil legado	`memory/career-profile.json`	Fallback do orchestrator e legado Streamlit	Legado	Sim, apenas quando necessário	Não por fato	Textual	Não	Builder/Contexto	legado
Memória de carreira	`career-memory.jsonl`; `memories`	RAG/Career Context	Inteligência/memória legada	Sim	Agora prioriza `source_refs`	Identidade e merge de refs	Não	Memória/RAG	parcial
Extração de currículo	Transitória	Match/ATS/Tailor ou Tracker quando enviada	Currículo	Não	Arquivo/tipo	Parser local	ResumeSnapshot no Tracker	Parser/API	parcial
Extração de vaga	Transitória	Match/Tracker/captura	Vaga	Não	URL opcional	URL canônica	JobSnapshot no Tracker/captura	Parser/API	parcial
Match	Resposta; snapshot no Tracker	ATS, Tailor e Tracker	Match	Sim	`evidence_used`	Hash do snapshot	AnalysisSnapshot	Match/API	completo
Revisão ATS	Resposta; snapshot no Tracker	Tracker e pessoa usuária	ATS	Sim, somente evidência confirmada	Evidências	Hash do snapshot	AnalysisSnapshot	ATS/API	completo
Tailor/variante	Resposta e Tracker	Currículo/Tracker	Tailor	Sim, somente evidência confirmada	Evidências	Hash de conteúdo	ResumeSnapshot	Tailor/Tracker	completo
Candidatura	JSON legado + `applications`	Tracker, Dashboard, Inteligência	Kanban	Sim	URL/captura/snapshots	Mesma vaga forte	Links para snapshots	Tracker/API	completo
Evento de candidatura	`application_events`	Histórico do Tracker	Tracker	Sinal histórico	`application_id`	Não colapsa eventos	Aplicação vinculada	Tracker/storage	completo
Oportunidade coletada	JSON legado + `opportunities`	Captura, Radar, Tracker	Fontes/Radar	Via memória/contexto	URL canônica	URL/empresa/cargo	JobSnapshot quando há texto	Identidade/fontes	parcial
Inbox de fontes	`sources/imports.json` + tabelas	Fontes, Vaga, Tracker	Fontes	Sim	Sim	`dedupe_key`	Ao importar	API Fontes	parcial
Histórico de lotes `imports`	`sources/imports.json`	Sem leitura de produto encontrada	Não	Não	Parcial	Não	Não	Indireto	órfão
Captura Companion	`captures.jsonl` + `captures`	Companion, API extensão, Vaga/Edital/GitHub/Tracker	Fontes	Sim	URL/capture ID	URL canônica	Sim	Companion/extensão	completo
Contexto ativo Companion	`active-context.json`	Companion	Configuração legada	Complementa Career Context	Singleton	Não	ResumeSnapshot na migração se há currículo	Companion	legado
Wishlist	`radar/radar.json` + `radar_wishlists`	Radar e scheduler	Radar	Sim	IDs locais	ID	Não	Radar/API	completo
Fonte do Radar	JSON + `radar_sources`	Runs agendados/manuais	Radar	Não	URL/source ID	ID/URL	Não	Radar	completo
Run/resultado do Radar	JSON + `radar_runs/results`	Alertas, Inbox e Tracker	Radar	Sim na análise	`run_id`, URL	URL/identidade	Ao salvar no Tracker	Radar/API	parcial
`SavedSearch`/`JobRadarProfile`	Modelo no estado legado	Sem fluxo real encontrado	Não	Não	Não	Não	Não	Não	órfão
Agendamento	`schedules.json` + `schedules`	Scheduler local	Radar	Sim	IDs	ID	Não	Scheduler/API	completo
Notificação local	`schedules.json` + `notifications`	Centro de notificações	Notificações	Indireto	`related_*` parcial	ID	Não	Notificações	parcial
Edital/cargo/requisito	`notices.json` + tabelas	Editais, Exam Fit, plano	Editais	Sim	URL/número/órgão/banca	Identidade oficial antes da URL	PublicExamSnapshot	Editais/API	completo
Exam Fit/plano de estudo	Resposta transitória	Pessoa usuária	Editais	Sim	Evidências e warnings	Não	Fundação ainda parcial	Editais	parcial
Projeto GitHub/portfólio	`project-analyses.jsonl` + `github_projects`	Perfil, memória, site/extensão	GitHub/Fontes	Sim	owner/repo/URL	Identidade canônica	AnalysisSnapshot na captura	GitHub/extensão	parcial
Análise GitHub direta do site	Resposta	Pessoa usuária	GitHub	Sim	Repositório + evidências	owner/repo	Não até salvar/Tracker	API GitHub	parcial
Trace de IA	`ai_runs`	Auditoria e health	Metadados nas respostas; dashboard futuro	Registra fontes	Sim	`input_hash`	AnalysisSnapshot separado	AiRun/API	completo
Configuração não secreta de IA	`settings/ai-settings.json`	Runtime e frontend	Configurações	Define permissões	N/A	Singleton	Não	Settings	completo
Chave de provider do app	`data/secrets/*.local.json`	Backend local	Apenas status mascarado	Nunca entra	N/A	N/A	Excluída	Segurança	completo
Chave própria da extensão	sessão ou cofre IndexedDB consentido	Service worker	Popup	Nunca entra no contexto	N/A	N/A	Excluída	Secret/package	completo
Fila offline da extensão	storage local sem segredo	Popup/service worker	Popup	Não	identidade de ação/URL	URL canônica	Captura gera snapshot	Harness Node	completo
Catálogo de modelos	cache local não secreto	Configuração/execução real	Site/extensão	Não	Provider	Modelo ID	Não	Settings/extensão	completo
Registro de prompts	Código Python	Orquestração de IA	Catálogo documental	N/A	`prompt_id/version`	ID+versão	Trace	Registry/gerador	parcial
Capabilities manifest	`config/capabilities.json`	Validadores e matriz	Documentação	N/A	Commit verificado	`capability_id`	N/A	Geradores	completo
Backup/export	ZIP + manifest/checksums	Restore e pessoa usuária	Privacidade	Não	Metadados seguros	Nome/data	Contém snapshots, não segredos	Storage/API/E2E	completo

Perguntas obrigatórias respondidas¶

O Perfil Universal é realmente a fonte central?¶

É a fonte central preferencial para fluxos novos, comprovado por modules/profile/orchestrator.py e modules/context/engine.py. Ainda existe fallback deliberado para career-profile.json, e active-context.json guarda o currículo explicitamente fornecido ao Companion. Portanto, a resposta é sim para fatos confirmados novos, com compatibilidade legada documentada, não uma exclusividade física de store.

Todos os fluxos consultam Career Context quando deveriam?¶

Match, ATS, Tailor, Radar, Wishlist, Fontes, GitHub, Tracker, extensão e Editais consultam finalidades específicas. Currículo e Vaga são extrações de entrada e não precisam do contexto completo. Dashboard agrega dados diretamente. Inteligência e Notificações ainda têm integração indireta; permanecem gaps parciais, não fluxos falsamente marcados como completos.

Existem fluxos que duplicam contexto?¶

Sim. O perfil legado e o Perfil Universal coexistem por compatibilidade; Companion mantém contexto ativo explícito; Tracker/Fontes também espelham sinais na memória. A correção evita tratar constraints reconstruídas como confirmadas e preserva origem/confiança, mas a eliminação completa do espelhamento legado exige migração gradual.

Existem dados salvos e nunca lidos?¶

Sim: SourceImportState.imports, saved_searches e JobRadarProfile não possuem consumidor de produto identificado. deduplication_reason e alguns metadados de merge possuem consumo principalmente diagnóstico. Estão marcados como órfãos/parciais, sem remoção destrutiva.

Existem campos retornados pela API e nunca exibidos?¶

O baseline descartava warnings/request ID do envelope, trace ATS, candidatos GitHub e contexto do Tracker. O client agora preserva envelope, trace, candidatos e contextos; ainda há metadados avançados de Radar, source_summaries e dedupe de Editais com exposição parcial.

Existem campos exibidos e nunca persistidos?¶

Match, ATS, Tailor, Exam Fit e plano podiam existir apenas na tela. Match/ATS/Tailor passam a ter snapshots quando vinculados ao Tracker; Exam Fit/plano continuam transitórios nesta fundação e estão documentados como parciais.

Existem candidatos de Perfil que nunca chegam à revisão?¶

O fluxo Lattes e a bridge da extensão chegam à revisão. A análise GitHub direta passou a preservar profile_evidence_candidates no client, mas sua apresentação/salvamento completo no fluxo GitHub web ainda é parcial.

Existem memórias gravadas e nunca recuperadas?¶

Sim. Reanálises antigas de projeto podiam ficar na memória depois de o store substituir o relatório, e eventos de Tracker eram sobrescritos por identidade. Eventos agora usam referências únicas e SQLite mantém application_events; memórias antigas permanecem para migração/health, sem apagamento automático.

Existem prompts registrados e nunca usados?¶

career_advice_v1 está registrado sem consumidor de produção. domain_classification_v1 possui implementação interna, mas não um fluxo integrado completo. Prompts documentais que não existem no registry foram removidos do catálogo gerado ou tratados como roadmap.

Existem providers ou modelos salvos e ignorados?¶

O modelo selecionado já era encaminhado ao provider. O baseline ignorava permissões de Perfil, Lattes, Extensão e Notificações e marcava OpenAI GitHub bem-sucedido como fallback. As permissões foram ligadas ao runtime e a comparação passou a usar o provider solicitado. O fallback agora é explícito.

Existem fallbacks silenciosos?¶

Existiam no fallback FastAPI→Companion da extensão e em mensagens hardcoded como Gemini. A extensão agora registra fallback_used/reason; mensagens do backend são neutras ao provider; AiRunStore e envelopes preservam warnings.

Existem endpoints sem cliente frontend?¶

Sim, sobretudo operações avançadas ou de manutenção, como detalhes/exclusão de alguns Editais, filtros avançados do Radar e endpoints legados. O manifesto diferencia endpoint existente de capacidade consumida; não se declara cobertura total apenas pela presença no OpenAPI.

Existem telas sem endpoint real?¶

O modo Demo é intencional e separado. No modo API Real, as capacidades principais do manifesto têm endpoint validado. Continuidade de alguns fluxos ainda exige seleção/colagem manual e aparece como gap na matriz.

Existem stores diferentes para a mesma entidade?¶

Sim. Uma vaga pode aparecer em oportunidades, Inbox, Radar, Companion, Tracker e memória. SQLite, snapshots e IDs cruzados reduzem a divergência, mas os stores legados permanecem durante a transição. Não há dual-write permanente imposto a todos os módulos.

Existem IDs incompatíveis para a mesma entidade?¶

Sim no baseline: URL, capture ID, Tracker ID, hash do Radar e source ID podiam representar a mesma vaga. normalize_entity_url, identidade canônica, source_refs, source_capture_id e snapshots criam vínculos estáveis; merges incertos continuam sugestões.

Existem documentos prometendo funções que o código não entrega?¶

A matriz anterior superestimava continuidade Currículo→Match, Vaga→Tracker, persistência GitHub, uso do Perfil por Inteligência e contexto completo da extensão. A nova matriz é gerada do manifesto e registra gaps. O documento anterior permanece como histórico, com aviso para consultar a matriz atual.

Existem screenshots antigas ou duplicadas?¶

Sim. A galeria mantém imagens históricas e as capturas de Editais e Editais com IA do baseline eram idênticas. Os scripts atuais usam nomes estáveis e incluem Privacidade/Data Health e diagnóstico da extensão; imagens históricas continuam arquivadas, mas não são a navegação principal.

Existem textos sem acento ou gramática ruim?¶

Sim, especialmente mensagens legadas e documentos antigos. README, roadmap, índices e documentação principal foram revisados em português. Corrigir todo o arquivo histórico não faz parte desta entrega e poderia apagar contexto original.

Existem versões divergentes?¶

No baseline, app/API/web estavam na versão publicada anterior e a extensão tinha ciclo próprio. O release atual alinha pyproject.toml, FastAPI, package web, mocks, documentação e testes; a extensão avança separadamente por conter handshake, snapshots, retry e JSON-LD.

Estrutura observada dos dados locais¶

Sem revelar conteúdo:

Tracker legado: 3 registros válidos, 1 sem URL e nenhum com snapshot/histórico estruturado;
memória: 112 linhas válidas, sem IDs repetidos;
memória: 5 grupos repetidos por kind + source_id e 7 grupos semânticos exatamente repetidos;
memória: 103 registros sem source_refs, embora vários possuam source_id;
portfólio: 2 registros válidos;
perfil legado e contexto ativo: válidos;
demais stores principais: ausentes no diretório local auditado.

Esses números servem apenas como dry-run da instalação auditada. A migração não deve inventar snapshots para os três registros legados do Tracker sem texto original e nunca deve apagar os JSON/JSONL.

Gaps corrigidos¶

repository abstraction e SQLite local versionado;
dry-run, backup prévio, importação transacional, verificação e idempotência;
backup/export sem secrets conhecidos, restore checksummed e data health;
snapshots imutáveis e relações de candidatura;
stage history sem sobrescrever eventos anteriores;
identidade de edital por número/órgão/banca antes de URL;
granularidade de Perfil para várias evidências no mesmo Lattes/repositório;
constraints com confiança, confirmação, sensibilidade e referência preservadas;
ATS/Tailor/Radar sem promover evidência não confirmada a fato seguro;
permissões de IA efetivamente consultadas;
OpenAI GitHub e mensagens de fallback corrigidos;
warnings, trace e contexto preservados pelo client;
handshake, compatibilidade, retry/backoff/limite/export/import e JSON-LD na extensão;
API/UI de data health, backup, export e restore;
manifesto e documentos técnicos gerados/verificados.

Pendências reais¶

executar a migração --apply nos dados pessoais é uma decisão local da pessoa usuária; o release valida dry-run e fixtures, não altera automaticamente o diretório pessoal;
expor revisão de candidatos no fluxo GitHub web direto;
persistir Exam Fit e plano de estudo como AnalysisSnapshot;
reduzir espelhamento entre Perfil legado, memória e contexto ativo após adoção comprovada do SQLite;
dar consumidor ou deprecar com migração SourceImportState.imports, SavedSearch e JobRadarProfile;
ampliar UI para metadados avançados de Radar, source_summaries e dedupe de Editais;
executar benchmark completo e baseline humano na etapa de avaliação de IA;
ampliar a ingestão documental além da interface/fundação atual.

Conclusão¶

A arquitetura deixa de depender apenas de arquivos mutáveis sem relação e passa a possuir uma trilha verificável entre origem, contexto, análise, snapshot e candidatura. A compatibilidade legada é mantida de forma explícita. O release pode ser fechado somente após a suíte completa, build estrita da documentação, pacote da extensão, secret scan, verificação dos hashes protegidos, CI remoto verde e publicação dos artefatos.