heithmurray/agent-skills

bcp-finish (Conclusão-BCP)

A etapa de finalização para trabalhos reais. Um modelo construiu; um modelo diferente ataca; o Operador decide. Baseado no Protocolo Construtor-Desafiador v1.7 (https://github.com/heithmurray/builder-challenger-protocol, CC BY 4.0, Heith Murray).

Quando

• Execute antes de pedir aprovação de conclusão para qualquer trabalho além de uma alteração rápida. Não espere ser solicitado.
• Pule para trabalhos rápidos: óbvios, pequenos e fáceis de desfazer. Verificação focada é suficiente.
• Um tópico por execução: a alteração que você está prestes a entregar.

Papéis

• Construtor: você, o agente que fez o trabalho. Você corrige ou responde a cada objeção.
• Desafiador: um modelo diferente, executado como somente leitura. Ele encontra problemas; nunca edita arquivos nem escreve texto de entrega.
• Operador: o ser humano que é dono do trabalho. Apenas o Operador aprova, aceita um risco, estende o limite de rodadas, emite uma anulação de verdade ou REFRAME, ou decide sobre escopo. Você faz a ponte entre Construtor e Desafiador, e pode emitir um RESET — [instrução] padrão apenas para violações de formato.

Quem desafia quem

• O Desafiador é sempre de uma família de modelos diferente do Construtor, iniciado sem interface gráfica em modo somente leitura. Os pares e comandos exatos estão em references/tools.md.
• Use o modelo configurado padrão de cada ferramenta; não escolha um.
• Cada chamada é uma sessão nova, sem histórico compartilhado. Forneça a entrada completa da rodada a cada vez (veja Passagem).
• Permita até 10 minutos por chamada. Cada rodada geralmente leva de 1 a 5 minutos.

Passagem (o que o Desafiador recebe)

Cada rodada, escreva um prompt com estas partes, nesta ordem:

1. references/challenger-prompt.md, o arquivo inteiro (o papel, as regras e os formatos).
2. RODADA [n] — SAÍDA DO CONSTRUTOR — v1.[n-1].
3. Tópico: uma frase sobre o que esta alteração deve alcançar, nas palavras do Operador quando disponíveis, mais os critérios de aceitação.
4. Onde olhar: o caminho do repositório, commits base e cabeça, os comandos para ver o diff (por exemplo git diff <base>..<head>), e os arquivos importantes.
5. Evidência do Construtor: a verificação que você executou e seus resultados.
6. A partir da rodada 2: sua Resposta do Construtor (o Formato de Resposta do Construtor abaixo) e o último Registro de Objeções do Desafiador, na íntegra.

Nada mais. Nenhum comentário, nenhuma rodada anterior além do registro.

O Desafiador pode ler arquivos e executar comandos somente leitura para provar seus pontos. Níveis de evidência importam: executar o código ou a matemática supera citar uma fonte, que supera opinião.

O loop

O limite de rodadas é 5, a menos que o Operador tenha definido outro antes da rodada 1. Quando o limite for atingido sem APROVADO, pare e pergunte ao Operador. O Operador pode estendê-lo uma vez, com um motivo: EXTEND — [rodada atual] para [novo limite]. Motivo: [o trabalho específico ainda pendente]. Não há segunda extensão; atingir o limite novamente é um impasse.

1. Rodada 1: envie a passagem. Salve a resposta do Desafiador na íntegra como rodada 1.

2. Veredito REVISE ou FAIL: responda no Formato de Resposta do Construtor:

   • Resposta ao veredito.
   • Objeções aceitas (por ID): o que você alterou. Para cada uma: "Objeção [ID] era nível [X]. Minha revisão alterou [Y]. A proporção é apropriada porque [Z]."
   • Objeções rejeitadas (por ID): motivos, com evidências de nível igual ou superior.
   • Desafio de objeção fraca.
   • Respostas a suposições.
   • Revisões feitas.
   • Perguntas em aberto restantes.

   Faça as revisões e faça o commit na branch. Em seguida, envie a passagem da próxima rodada.

3. Uma objeção que mudaria escopo, comportamento ou design não é sua para corrigir silenciosamente. Pare e leve-a ao Operador como uma decisão, com o texto do Desafiador na íntegra.

   • Uma especificação ou plano que você mesmo escreveu não define escopo. Não rejeite uma objeção apontando para ela. Apenas as palavras do Operador ou uma especificação aprovada pelo Operador contam. Se escopo for o único motivo para rejeitar, reporte como "decisão de escopo do Operador necessária."

4. Veredito PASS conta apenas com uma Lista de Verificação de Aprovação concluída onde o número de pendências é zero e o veredito final é APROVADO. Caso contrário, trate como REVISE.

5. Limite de rodadas atingido sem APROVADO: pare e leve o registro aberto ao Operador. Se o Operador estender (uma vez), continue. Caso contrário, ou no limite estendido, é um impasse: peça ao Desafiador uma Declaração de Posição Final de um parágrafo, escreva a sua própria e leve ambas ao Operador.

6. SELF-FAIL: se a própria abordagem estiver quebrada, diga isso com as três partes necessárias: (a) o que está quebrado, (b) por que levou o desafio para aparecer, (c) o que faria uma abordagem diferente funcionar. Leve ao Operador.

Nunca edite, corte ou suavize uma resposta do Desafiador. Nunca afirme que uma objeção foi resolvida; apenas o registro do Desafiador pode marcá-la como resolvida.

Onde o registro vai

• Se o trabalho tem uma pasta de alteração ou registro de tarefa, salve as rodadas lá como BCP-LEDGER.md: cada resposta do Desafiador e cada Resposta do Construtor, em ordem.
• Caso contrário, salve-as em uma pasta temporária fora do repositório e inclua o registro final em seu relatório.
• Não crie novas pastas no nível superior para isso.

Relatório ao Operador (aprovação de conclusão)

• Os modelos usados como Construtor e Desafiador, e o número de rodadas.
• A versão final e o veredito final do Desafiador.
• O Registro de Objeções final, na íntegra.
• As concessões do Desafiador e sua auto-auditoria de riscos não levantados, na íntegra.
• Sua evidência de verificação.
• Cada interpretação que você fez onde o pedido era ambíguo (por exemplo "dias 6–29 não cobram nada"), para que o Operador possa confirmar ou corrigir.
• Qualquer coisa que precise da decisão do Operador: impasse, SELF-FAIL, decisões de escopo, objeções que mudam escopo, riscos a aceitar.
• Em seguida, peça aprovação ou rejeição. Envio, merge e publicação aguardam a aprovação do Operador.

Se o Desafiador não puder ser executado

1. Tente novamente uma vez. Se um erro de modelo mencionar um modelo não suportado, reporte; não troque de modelo silenciosamente.
2. Se a outra ferramenta ainda estiver indisponível, execute o mesmo loop com o comando de somente leitura sem interface gráfica da sua própria ferramenta como Desafiador (veja references/tools.md). É uma sessão nova, sem contexto compartilhado.
3. Rotule todo o resultado como SELF-CHALLENGE (AUTO-DESAFIO) no relatório, e diga por que o segundo modelo não estava disponível. Um auto-desafio compartilha os pontos cegos do Construtor, então o Operador deve ponderá-lo menos.
4. Nunca pule a etapa silenciosamente.