Pular para conteúdo

Baseline e registro de riscos da v1.9.9

Auditoria iniciada em 3 de agosto de 2026 sobre main, no commit c21549c0fb8cbfe507860e820b7c271a2729a977. A baseline encontrada era app 1.9.8, extensão 0.9.4 e schema SQLite 5. A tag/release intermediária v1.9.8.1 não existia e foi deliberadamente descartada; seu hardening foi incorporado à v1.9.9.

Condições observadas antes da implementação

Prioridade Risco de baseline Critério de encerramento
P0 API/Companion localhost sem autenticação, pairing, Host/Origin e limites obrigatórios sessão efêmera, CSRF, token de instalação, origins/hosts estritos, rate/body/depth/batch limitados
P0 proveniência confundida com confirmação EvidenceReviewStatus e EvidenceScope independentes de ponta a ponta
P0 cobertura, confiança, risco, ATS e readiness misturados contratos e denominadores separados; unknown e not_applicable explícitos
P0 Lab fabricava resultados derivados em vez de consumir motores reais bundle imutável com Match, ATS, readiness e Tailor independentes
P0 writes parciais, JSON corrompido interpretado como vazio e stores divergentes transações, idempotência, quarantine e SQLite como verdade operacional
P1 ingestão sem limites/proveniência granular e PDF/DOCX finais ausentes PDF/DOCX/HTML/TXT/JSON Resume locais, árvore canônica e exports reais
P1 lifecycle de Professional Assets/Kit incompleto estados persistidos, stale, revisão por item, undo e export apenas do aceito/editado
P1 extensão persistia contexto demais e não possuía idempotência de handoff token em storage.session, IDs no handoff e chave idempotente vinculada ao corpo

O levantamento detalhado, com mapa inicial de módulos e riscos, permanece em auditoria de hardening, ingestão e Resume Studio.

Restrições de execução

  • os três arquivos do fluxo authenticated-browser foram registrados por SHA-256 e são protegidos por comparação byte a byte no gate final;
  • apenas a presença booleana de SOTUHIRE_TEST_GEMINI_API_KEY e SOTUHIRE_TEST_OPENAI_API_KEY foi inspecionada; ambas estavam ausentes;
  • suites externas devem ser classificadas como não executáveis, sem chave falsa e sem alegar sucesso; mock, golden local e release-smoke local continuam obrigatórios;
  • nenhum dado pessoal foi migrado automaticamente. Apply/rollback usa somente fixtures sintéticas; dados locais reais recebem apenas dry-run e health check.