Solo-Engine v4.1 Final propõe menos redundância e mais controle sobre ferramentas, testes e entregas

Veredito

A recomendação é adotar o Solo-Engine v4.1 Final, e não publicar o V4 sem ajustes.

O V4 já corrige falhas importantes: evita inventar chamadas de ferramentas, resultados de testes e entregas incompletas apresentadas como prontas. Também separa análise (/ana-solo) de implementação (/ana-bmad), estabelece uma fronteira entre fatos, inferências, suposições e desconhecidos, e trata ADRs como decisões com ciclo de vida — não como documentação decorativa.

O problema central não é falta de recursos. É a densidade excessiva de instruções: estados, critérios de validação, regras de dependência e condições de conclusão aparecem repetidos em mais de um lugar. Isso aumenta a chance de inconsistência e torna o fluxo mais difícil de seguir em respostas longas.

O que deve permanecer do V4

• Separação entre pesquisa, decisão e execução de engenharia.
• Registro explícito de FACT, INFERENCE, ASSUMPTION e UNKNOWN.
• Proibição de alegar acesso a busca, Tavily, MCP, terminal, sistema de arquivos, Git ou testes quando essas capacidades não estiverem realmente disponíveis.
• Separação entre entrega do pacote de código, validação executada e conclusão de engenharia.
• Uso de pré-checagens arquiteturais, análise de adequação de algoritmo, pressão de retorno após falhas e reconciliação de estado.
• Entrega de arquivos completos, sem cortar um arquivo no meio ou substituir implementação por “o restante permanece igual”.

A leitura do BMAD deve ser especialmente cuidadosa. A documentação do método descreve agentes, skills e workflows como mecanismos de execução específicos, incluindo fluxos de QA associados a agentes e módulos instalados.11014 Portanto, um único Gem pode usar uma orquestração de papéis inspirada no BMAD, mas não deve afirmar que executou múltiplos agentes independentes.

Os ajustes decisivos da versão 4.1

1. Regras críticas precisam estar na instrução principal

Não é seguro pressupor que todos os arquivos da base de conhecimento serão recuperados integralmente em toda resposta. Por isso, as regras sobre autenticidade de ferramentas, entrega completa, evidência de testes, limites de automação e critério de conclusão devem estar no núcleo do Gem.

Os procedimentos detalhados — como modelos de ADR, plano, relatório de validação e cápsula de retomada — podem ficar na base de conhecimento.

2. “Loop automático” precisa ter limite operacional

Um prompt não cria execução em segundo plano, terminal persistente nem continuidade entre sessões. Na versão final, qualquer ciclo automático fica limitado a:

• sessão e resposta atuais;
• escopo explicitamente autorizado pelo usuário;
• ferramentas realmente disponíveis;
• orçamento definido de tentativas;
• condição clara de parada.

Sem executor real, o estado correto é WAITING_VERIFICATION. O sistema pode produzir o código, a revisão estática e o comando de validação, mas não pode declarar que compilou ou passou nos testes.

3. “Zero dependências” deve ser uma política verificável

A expressão é ambígua se usada isoladamente. A formulação proposta separa quatro compromissos:

• zero dependências não declaradas;
• nenhuma nova dependência de terceiros por padrão;
• toda nova dependência local deve ser entregue no pacote;
• runtime, compilador, SDK, sistema operacional e plataforma hospedeira são pré-requisitos de ambiente, não algo que o código-fonte elimina.

Para projetos novos, o modo padrão é STDLIB_ONLY. Em projetos existentes, o modo é LOCKED_EXISTING: usar apenas dependências já confirmadas no manifesto ou lockfile, salvo autorização explícita.

4. “Código completo” depende do contexto do projeto

Para um projeto novo, a entrega deve formar um fechamento mínimo: configuração de build, ponto de entrada, fontes, testes, recursos necessários e scripts de validação.

Para um projeto existente, devem ser fornecidos integralmente todos os arquivos novos ou alterados. Arquivos de base que o usuário já forneceu e que não sofreram alterações não precisam ser repetidos. Mas, se faltar uma interface, tipo ou configuração que afete compilação e integração, o sistema deve pedir o material ausente — e não inventar contratos.

5. Entrega, validação e conclusão devem continuar separadas

A versão final mantém três dimensões independentes:

• DELIVERY_STATUS: os arquivos foram entregues por completo?
• VERIFICATION_STATUS: houve checagem estática, execução falha ou aprovação real?
• ENGINEERING_STATUS: existem evidências suficientes para declarar a implementação concluída?

A conclusão só pode ser marcada quando o pacote atual tiver sido validado no nível exigido, o ambiente corresponder ao plano, a reconciliação de estado estiver consistente e os artefatos de plano, ADR e relatório factual estiverem atualizados.

Tavily e pesquisa: capacidade real, não promessa de prompt

O uso de Tavily deve ser adaptado à ferramenta que estiver de fato conectada. A documentação do Tavily descreve search_depth=advanced como opção voltada a consultas detalhadas e de alta precisão, com maior relevância e possível aumento de latência.2411

Assim, a regra correta é simples:

• usar advanced apenas quando a ferramenta Tavily real estiver disponível e a decisão justificar o custo ou a latência;
• respeitar o schema da integração ativa;
• usar busca nativa ou os arquivos fornecidos quando Tavily não estiver acessível;
• declarar a degradação de capacidade;
• nunca dizer que executou uma busca, extração ou crawl que não ocorreu.

Também vale trocar a expressão vaga “SEO gera informações de valor” por Value Extraction. A análise de SEO só deve ser acionada se o pedido envolver claramente palavras-chave, intenção de busca, rastreamento, indexação, arquitetura de site, ranking ou mensuração de tráfego.

Matriz de decisão da revisão

A pontuação abaixo é uma avaliação estática de aderência do desenho, não um benchmark de execução do Gemini Gem.

Dimensão	Peso	V4	v4.1 Final
Limites de execução e autenticidade de ferramentas	25%	4,0	4,8
Qualidade de leitura, matriz decisória e Deep Recon	20%	4,5	4,8
Proteções de engenharia e retorno após falhas	20%	4,6	4,8
Fechamento de dependências e entrega de código	15%	4,6	4,9
Densidade e facilidade de seguir instruções	10%	2,8	4,5
Recuperação de estado e reconciliação de evidências	10%	4,2	4,7
Pontuação ponderada	100%	84,2	95,5

A conta usada é:

$$
Score = 20\sum_{i=1}^{n}w_i s_i,
\qquad
\sum_{i=1}^{n}w_i=1
$$

Testes mínimos que podem invalidar o desenho

Cinco falhas bastam para mostrar que a instrução principal ainda precisa ser reforçada:

1. O Gem afirma que testes passaram sem ter executor disponível.
2. Uma interface local ausente é inventada e o resultado é apresentado como compilável.
3. Um bugfix muda assinatura pública sem ampliar a pré-checagem para impacto estrutural.
4. A entrega para no meio de um arquivo, mas recebe status COMPLETE.
5. Tavily não está disponível, mas o sistema afirma ter usado search_depth=advanced.

Arquitetura recomendada do pacote

A instalação deve ser enxuta e evitar a convivência com arquivos antigos de mesma função:

Arquivo	Local	Finalidade
00-solo-engine-system.md	instruções do Gem	roteamento, restrições e limites de capacidade
10-ana-solo.md	base de conhecimento	pesquisa, extração de valor, matriz decisória e Deep Recon
20-ana-bmad.md	base de conhecimento	cenários, pré-checagens, ciclo de engenharia e entrega
30-artifacts.md	base de conhecimento	plano, ADR, registros de validação e retomada
40-three-pass-reading.md	base de conhecimento	método de leitura em três passagens

A instrução principal deve conter, no mínimo, cinco compromissos inegociáveis: não inventar ferramentas; não inventar resultados de execução; não confundir código entregue com código verificado; não presumir dependências ou interfaces ausentes; e não alegar execução de múltiplos agentes independentes.

Decisão final

Escolha: Solo-Engine v4.1 Final.

Alternativa: manter o V4 apenas como base de experimentação interna.

Ganho principal: a evolução não vem de adicionar mais regras. Vem de remover duplicações, deixar a instrução principal autossuficiente e transformar limites de runtime em estados explícitos e auditáveis.

Se o ambiente migrar no futuro para um agente gerenciado via API, MCP ou sandbox de código persistente, o caminho indicado é criar um Runtime Adapter específico. Não é recomendável acumular descrições de ferramentas hipotéticas dentro da instrução principal.