[Giomoret]

Descrição

Implementa a S2-23 e corrige os problemas encontrados na revisão. Relatórios concluídos do RepoAnalyzer entram automaticamente no acervo do projeto, sem novo upload manual.

Alterações

• Indexação pelo pipeline de documentos da S2-01/S2-02.
• Enfileiramento na mesma transação que salva o relatório.
• Validação do projeto e documento retornados pela IA.
• Preservação de URL, execução, commit/ref disponíveis, caminhos citados e versão do relatório.
• Reprocessamento sem duplicação, com tentativas automáticas e nova tentativa pela interface.
• Remoção dos trechos antigos ao alterar o relatório, excluir a análise ou arquivar o projeto.
• Resultados pesquisáveis com navegação para a execução correta e identificação da origem no chat.
• OpenAPI e documentação atualizadas.

A entrega indexa somente o relatório; não ingere os arquivos brutos do repositório.

Validação

• Backend: 363 testes aprovados.
• Frontend: 297 testes aprovados.
• Python: 92 testes aprovados.
• PostgreSQL: 32 testes de integração aprovados.
• Builds e verificação de tipos aprovados.
• Auditorias sem vulnerabilidades.
• Fluxo integrado até busca e chat aprovado, incluindo isolamento entre projetos, recuperação de falhas e idempotência.
• Regressão do copiloto no navegador aprovada.

Os testes integrados usam respostas simuladas do Ollama. A qualidade semântica do modelo local ainda precisa de conferência. Há testes condicionais ignorados conforme a configuração das suítes.

[LoadCG]

Revisão QA — S2-23 indexação de relatórios

Revisei o diff desta PR e os checks disponíveis no commit 13b8832. Backend, frontend, validação de workflows/Docker, scripts Windows, testes do serviço de IA e E2E estão verdes. Isso é um bom sinal para a integração, mas ainda há pontos de autorização e governança que precisam ser resolvidos antes do merge.

Bloqueadores de revisão

1. A ação de reprocessar aparece para desenvolvedores, mas a API só autoriza PO/admin. Em ProjectDetail, canStart={!archived} é passado como controle de acesso; esse valor representa apenas se o projeto está arquivado, não o papel do usuário. Com isso, um dev em projeto ativo vê “Reprocessar relatório”, clica e recebe 403 do endpoint, que permite apenas admin e po. Ajuste a visibilidade/habilitação para refletir a autorização efetiva e adicione teste de UI cobrindo pelo menos PO/admin e dev. Confira também os estados de loading e erro.

2. O trigger indexa automaticamente conteúdo produzido pelo RepoAnalyzer no acervo e o torna recuperável pelo chat sem aceite humano explícito. A migration também enfileira relatórios concluídos que já existiam. O contexto canônico exige que saídas de IA sejam rascunhos/sugestões até ação humana explícita de aceitar, editar ou descartar; respostas do chat devem citar evidências. A indexação automática pode transformar análise gerada por IA, ainda não revisada, em conhecimento institucional apresentado como evidência. Precisamos de um gate de aprovação humana/proveniência antes de indexar, ou de uma decisão de produto explícita que mantenha esses itens marcados como gerados por IA e não revisados, com essa condição visível na busca e nas citações do chat. Inclua também uma política segura para o backfill dos relatórios existentes; não os publique implicitamente como conteúdo validado.

Ajustes de segurança e robustez no harness de validação

3. O mock do Ollama é escutado em todas as interfaces e lê o corpo sem limite. O servidor temporário em validate-harness.mts usa 0.0.0.0; o handler acumula o request inteiro em memória antes de fazer parse, sem limite de tamanho. Durante a execução, outro processo/host alcançável pela rede pode enviar payload arbitrariamente grande ou interferir nas respostas do mock. Restrinja o bind à interface necessária (por exemplo, loopback ou rede privada isolada do container) e imponha limite explícito de bytes ao corpo, retornando erro controlado ao exceder. O harness deve continuar validando a integração real sem abrir uma superfície de rede desnecessária.

Cobertura de QA a completar

4. O teste de banco descrito como atômico deve comprovar a atomicidade do fluxo real: dentro de uma transação, atualizar um relatório concluído deve enfileirar a indexação e substituir/remover chunks conforme o trigger; depois de rollback, status e chunks anteriores devem permanecer intactos. O teste atual faz um update genérico e rollback, sem validar esses efeitos.

5. Adicione um teste concorrente de dois workers reivindicando itens pendentes para demonstrar que ambos recebem trabalhos distintos e que não há dupla reivindicação. O caminho usa SKIP LOCKED/lease, então vale proteger esse contrato contra regressões.

Próximas tasks do Giovanni

Depois de endereçar os itens acima e atualizar os checks, avance com as tasks já levantadas:

• QA visual autenticado de S2-05 e S2-08: validar expurgo do contexto do projeto e resultados da busca na UI; confirmar isolamento por projeto, comportamento após exclusão, snippet, origem/citação e navegação até a fonte.
• Diagnóstico reprodutível de S2-03/S2-04: exercitar indexação idempotente, remoção/reabertura/arquivamento e qualquer falha residual em PostgreSQL; registrar passos, logs relevantes e evidência automatizada.
• S2-13/S2-14 Copilot: cobrir aceite, edição e descarte explícitos, proveniência persistida, papel autorizado e comportamento quando o serviço de IA está indisponível.
• S2-06/S2-17 relevância: pode preparar dados e execução, mas não declarar concluído até PO/time revisar a divergência GRF-01/08, acordar critérios de relevância e aprovar a nova avaliação.

Por favor, responda nesta PR com o commit que corrige os bloqueadores e evidências dos testes adicionados.