Gerador de Playbook de Qualidade

Visão Geral do Plano — leia isto primeiro, depois explique ao usuário

Antes de ler qualquer outra seção desta habilidade, entenda o plano e suas dependências. Cada fase produz artefatos dos quais a próxima fase depende. Pular ou apressar uma fase significa que todas as fases subsequentes trabalham com informações incompletas.

Fase 0 (Análise de Execução Anterior): Se houver execuções de qualidade anteriores, carregue suas descobertas como dados iniciais. Isso é automático e se aplica apenas a reexecuções.

Fase 1 (Explorar): Execute primeiro a ingestão de documentação v1.5.3 (python -m bin.reference_docs_ingest <target> para percorrer reference_docs/ — arquivos cite/ produzem registros quality/formal_docs_manifest.json; arquivos de nível superior são carregados como contexto de Nível 4 via reference_docs_ingest.load_tier4_context(<target>)). Em seguida, explore a base de código em três estágios: exploração aberta impulsionada pelo conhecimento do domínio, análise de risco baseada no conhecimento do domínio e padrões de exploração estruturada selecionados. Escreva todas as descobertas em quality/EXPLORATION.md. Este arquivo é a base — a Fase 2 o lê como sua entrada principal.

Fase 2 (Gerar): Leia EXPLORATION.md e produza os artefatos de qualidade: requisitos, constituição, testes funcionais, protocolo de revisão de código, testes de integração, protocolo de auditoria de especificação, protocolo TDD. (AGENTS.md na raiz do repositório do alvo é gerado pelo orquestrador APÓS a Fase 6, não por você na Fase 2 — veja "Arquivo 6" abaixo para o contrato.)

Fase 3 (Revisão de Código): Execute a revisão de código de três passagens contra o HEAD. Escreva testes de regressão para cada bug confirmado. Gere patches.

Fase 4 (Auditoria de Especificação): Três auditores de IA independentes revisam o código em relação aos requisitos. Triagem com sondas de verificação. Após a triagem, o mesmo Conselho executa a verificação de citação semântica v1.5.3 de Camada 2 — um prompt por revisor, vereditos estruturados por REQUISITO para cada citação de Nível 1/2, saída para quality/citation_semantic_check.json. Escreva testes de regressão para novas descobertas.

Fase 5 (Reconciliação): Feche o ciclo — cada bug da revisão de código e auditoria de especificação é rastreado, testado para regressão ou explicitamente isento. Execute o ciclo TDD vermelho-verde. Finalize o relatório de completude.

Fase 6 (Verificar): Execute benchmarks de autoverificação contra todos os artefatos gerados. Verifique a consistência interna, a correção da marcação de versão e a convergência.

Fase 7 (Apresentar, Explorar, Melhorar): Apresente os resultados ao usuário com uma tabela de resumo escaneável, ofereça detalhamento em qualquer artefato e forneça um menu de caminhos de melhoria (estratégias de iteração, refinamento de requisitos, ajuste de testes de integração). Esta é a fase interativa onde o usuário assume a propriedade do sistema de qualidade.

Todo bug encontrado remonta a um requisito, e todo requisito remonta a uma descoberta de exploração.

A cadeia crítica de dependência: Descobertas de exploração → EXPLORATION.md → Requisitos → Revisão de código + Auditoria de especificação → Descoberta de bugs. Uma exploração superficial produz requisitos abstratos. Requisitos abstratos perdem bugs. A fase de exploração é onde os bugs são ganhos ou perdidos.

AÇÃO OBRIGATÓRIA PRIMEIRO: Após ler e entender o plano acima, imprima a seguinte mensagem para o usuário, depois explique o plano com suas próprias palavras — o que você fará, o que cada fase produz e por que a fase de exploração é a mais importante. Enfatize que a exploração começa com investigação aberta orientada pelo domínio, seguida por análise de risco baseada no conhecimento do domínio que raciocina sobre o que dá errado em sistemas como este, depois suplementada por padrões estruturados selecionados. Não copie o plano textualmente; parafraseie-o para demonstrar compreensão.

Quality Playbook v1.5.6 — por Andrew Stellman https://github.com/andrewstellman/quality-playbook

Gere um sistema de qualidade completo e adaptado a uma base de código específica. Ao contrário dos geradores de "stubs" de teste que funcionam mecanicamente a partir do código-fonte, esta habilidade explora o projeto primeiro — entendendo seu domínio, arquitetura, especificações e histórico de falhas — depois produz um playbook de qualidade fundamentado no que encontra.

Como executar isto — contrato de invocação auto-codificado v1.5.4

Se o operador lhe entregar esta habilidade (ou apontá-lo para qualquer alvo instalado pelo QPB) e disser "Execute o Quality Playbook" — possivelmente com uma dica como "esta é uma execução de bootstrap" ou "execute em si mesmo" ou "auto-auditoria" — esta seção diz exatamente o que fazer. O operador não deve precisar fornecer instruções adicionais; a invocação canônica, os padrões, as salvaguardas e o contrato de saída vivem aqui.

…