proposta: teste por propriedade/fuzzing + fixtures com código real + revisão por invariante no prototype_gate

[wesleysimplicio]

Contexto

Ver simplicio-loop#579 (issue hub — raciocínio completo e os 2 bugs concretos motivadores, em simplicio-mapper e simplicio-dev-cli).

Este repo já tem seu próprio gate de qualidade (scripts/prototype_gate.py) — é o candidato natural pra incorporar esse padrão de "correção profunda" na variante OSS do loop, já que simplicio-loop-oss é descrito como "um loop de contribuição persistente e gated por qualidade" pra repositórios open-source.

Proposta concreta pra este repo

1. Hypothesis (Python) nos módulos de scripts/ que fazem parsing/transformação de dados estruturados (planos, relatórios de auditoria) — scripts/audit.py e scripts/prototype_gate.py são os candidatos mais óbvios.
2. Estender prototype_gate.py com uma verificação adicional (ou pelo menos um item de checklist documentado) cobrindo os 3 pontos da issue hub: propriedade/fuzzing pra lógica de transformação, fixtures com código real (não minimalista) quando o gate analisa código de terceiros, e a pergunta de invariante sobre funções que particionam a mesma coleção de formas diferentes.
3. tests/ — adicionar pelo menos um caso de teste rodando o gate contra um repositório real de terceiro (clonado ou fixture commitada), não só contra o próprio repo ou exemplos sintéticos, já que o produto inteiro deste repo é "operar sobre repositórios de terceiros" — é exatamente o cenário onde fixtures artificiais escondem bugs de formato real.
4. Como este repo já é o "loop pra repos OSS de terceiros", ele é o lugar mais natural do ecossistema pra provar que o gate de correção profunda funciona antes de propagar pra outros consumidores do loop principal.

Revisão complementar do projeto: simplicio-loop-oss

Responsabilidade avaliada: open source. Esta issue deve ser entendida no contexto da auditoria-mãe do repositório.

Objetivo específico

validar issue → plano → branch → patch → testes → PR

Fluxo de testes obrigatório

conflito, licença, segredo, dependência externa, rollback e escopo

1. Registrar SHA/branch, ambiente, dependências e configuração.
2. Executar o caminho feliz completo e capturar logs/receipts.
3. Injetar entrada inválida, timeout, falha externa ou permissão ausente aplicável.
4. Verificar retry, cancelamento, idempotência e rollback quando o fluxo suportar.
5. Executar testes unitários, integração, sistema/E2E, regressão, segurança e desempenho aplicáveis.
6. Reexecutar com os mesmos dados e comparar resultado/hashes.
7. Confirmar que falha nunca vira sucesso e que recursos são liberados.

Evidências obrigatórias

• PR/commit vinculado;
• comandos e versões;
• logs do caminho feliz e da falha;
• testes/coverage/benchmark aplicáveis;
• receipts, hashes e relatório de rollback;
• limitações e próximos passos.

Regra de encerramento

Não fechar sem todos os critérios desta issue e da auditoria-mãe atendidos. Se faltar implementação, marcar como NEEDS-IMPLEMENTATION ou BLOCKED, nunca como concluída.

Execução

• Implementar o objetivo descrito.
• Fazer a implantação aplicável.
• Executar e registrar os testes.