Auditoria de hardening, ingestão e Resume Studio — v1.9.9¶

Baseline verificável¶

Auditoria iniciada em 2026-08-03, antes de qualquer alteração funcional, diretamente em main. A árvore estava limpa e HEAD, origin/main e v1.9.8 apontavam para c21549c2fca2e9019d49797ab73f13fe47cabbd7. A aplicação estava em 1.9.8, a extensão em 0.9.4 e o schema SQLite em 5. As tags e releases v1.9.8.1 e v1.9.9 não existiam local ou remotamente. CI, CodeQL e Docs do baseline estavam verdes.

O inventário inicial encontrou 1.230 arquivos rastreados: 258 em modules/, 45 em apps/api/, 104 em apps/web/src/, 21 na extensão, 20 scripts, 257 testes, 433 arquivos de documentação, dois arquivos em config/ e quatro workflows. O scan inicial examinou 1.868 arquivos nos caminhos de código, dados, build, site, outputs e benchmarks e não encontrou padrão de chave de provider.

As variáveis temporárias de teste foram verificadas exclusivamente pela presença booleana, sem imprimir nem persistir valores. Gemini, OpenAI e Ollama estavam ausentes. Assim, suites externas não podem ser classificadas como aprovadas nesta máquina; o fallback local continua obrigatório e qualquer ausência será registrada como não executável.

Limite protegido¶

Os fluxos de navegador autenticado permanecem fora do escopo e devem conservar estes hashes SHA-256 até o fechamento da release:

Arquivo	SHA-256 inicial	Classificação
`apps/api/routes/sources.py`	`396957E3286618E2B1327DB681F66F6269690E2BFD907D8E97714B5D4C7024FF`	`PUBLIC_API` protegido
`modules/scraping/browser_session.py`	`4B7454A581C32D6E88777C408C9F1F8F928F3F56B579E0035F07028B4EB37B65`	`ACTIVE` protegido
`modules/scraping/connectors/authenticated_browser.py`	`4F7E41BFF478873EF7D3E90AE67BCD6FF284FB4CBE36C70D217F3CD234264AB3`	`ACTIVE` protegido

Fontes de verdade e integração real¶

Domínio	Fonte de verdade atual	Integração observada	Lacuna de release
Perfil/evidência	SQLite gradual e stores legados de compatibilidade	Career Context propaga `source_ref` e `confirmed_by_user`	`source_ref` ainda pode ser confundido com confirmação; faltam estado de revisão e escopo imutável
Candidaturas	tabela `applications` e eventos, com adaptação do `JobTracker`	Tracker cria snapshots e vínculos	há caminhos de escrita dupla; a unidade transacional precisa ser única
Application Lab	tabelas do schema 5	sessão, readiness, sugestões, variante, kit e plano são retomáveis	o orquestrador não chama Match/ATS/Tailor e fabrica campos de Tracker a partir de readiness
Snapshots	tabelas SQLite imutáveis	vaga, currículo, análise e edital têm hash	snapshot mestre usa identidade de variante incorreta; artefatos não guardam dependency hash completo
Currículo/exports	entidades do Lab no SQLite	JSON Resume existe	PDF/DOCX são anunciados como pendentes e não partem de uma árvore canônica única
Ingestão documental	parser local transitório	TXT/PDF/DOCX básicos	faltam limites fortes, provenance por bloco, detecção de PDF imagem e revisão determinística
Outcomes	`outcome_events`/`outcome_metrics`	agregados locais exploratórios	denominador inclui candidaturas não submetidas e `no_response` não tem janela explícita
Companion	JSONL local compatível	captura pública e handshake	corrupção vira lista vazia silenciosa; autenticação é opcional e CORS é irrestrito
API local	FastAPI/SQLite	frontend consome rotas reais	não há autenticação, pairing, validação de Host/Origin, rate limit ou limites de corpo
Extensão	service worker e `chrome.storage`	captura, fila e ponte local	token opcional fica em `storage.local`; pairing e sessão efêmera não existem

Riscos priorizados¶

P0¶

Uma página pública pode alcançar serviços localhost sem autenticação obrigatória; a API também aceita por padrão uma origem remota de GitHub Pages.
Proveniência e confirmação não são estados independentes, permitindo evidência não revisada em fluxos de decisão ou IA externa.
Requisitos não possuem unknown; métricas de match, ATS, readiness, fit, cobertura, confiança e risco não são contratos independentes em todo o fluxo.
O Application Lab não orquestra diretamente os motores existentes e salva métricas derivadas sob nomes incompatíveis no Tracker.
Mudanças em vaga, currículo, evidência ou template não invalidam todos os artefatos dependentes; conflito de diff pode ser contado como aplicado.
Escritas relacionadas não formam uma única transação SQLite e JSON corrompido pode ser silenciosamente tratado como estado vazio.

P1¶

ingestão profissional sem árvore canônica e provenance granular;
PDF/DOCX reais ausentes e fidelidade semântica não testada;
lifecycle de Professional Assets e Application Kit incompleto;
extensão monolítica, token persistente e contratos de pairing ausentes;
modo Demo/API Real não persistido nem suficientemente explícito;
Radar precisa de retenção, paginação, quarentena e lock idempotente;
documentação e capability matrix descrevem parcialmente mais do que o código entrega.

P2¶

monólitos de frontend, rotas e repositórios elevam custo de revisão;
nomes duplicados de stores/modelos exigem classificação antes de remoção;
benchmark final, screenshots e walkthrough precisam ser regenerados somente após estabilizar contratos e UI.

Decisões de implementação¶

v1.9.8.1 não será criada; o hardening planejado para ela será integrado diretamente em v1.9.9 e citado apenas no histórico da release.
segurança local será segura por padrão, com token aleatório por instalação, pairing curto, sessão delimitada, origins/hosts estritos e health público sem segredos;
SQLite será a fonte de verdade para entidades operacionais; JSON ficará restrito a importação, exportação ou compatibilidade com quarentena explícita;
EvidenceReviewStatus e EvidenceScope serão contratos canônicos; somente evidência confirmada, selecionada, não sensível e com opt-in poderá seguir para provider externo;
um ApplicationAnalysisBundle preservará as saídas reais e separadas de Match, ATS, readiness e Tailor, sem renomear cobertura;
a mesma árvore documental canônica alimentará editor, preview, JSON Resume, DOCX, PDF, snapshot, diff e hash;
nenhuma capability será marcada como completa sem teste executável e artefato verificável.

Critério de saída¶

A publicação depende de todos os P0 fechados, migration única de 5 para 6 validada, testes de segurança/semântica/integração/exportação aprovados, fallback local comprovado, suites externas classificadas honestamente conforme a disponibilidade de credenciais, scan final limpo, hashes protegidos idênticos, frontend/extensão empacotados, CI/CodeQL/Docs verdes e clean install real.