merttcetn/pev-loop

Loop PEV

Execute um ciclo Planejador-Executor-Verificador sem estado em torno de uma meta persistente. Mantenha o agente primário como um controlador enxuto: mantenha o estado canônico, despache papéis isolados, imponha limites e relate resultados, sem planejar, implementar ou avaliar o produto em si.

Garantias inegociáveis

• Exija invocação explícita $pev. Trate essa invocação como autorização para criar ou reutilizar a meta nativa correspondente e para despachar os subagentes P, E e V.
• Mantenha o controlador fora do trabalho de produto. Não inspecione corpos de código-fonte, implemente alterações, interprete logs de teste brutos ou decida a satisfação da rubrica no contexto primário.
• Crie cada agente P, E e V com contexto novo. Use fork_turns="none" ou o equivalente mais forte do runtime.
• Nunca deixe um agente avaliar seu próprio trabalho.
• Esconda do verificador o raciocínio, resumos e resultados esperados do planejador e executor.
• Apenas evidências do verificador podem alterar a satisfação da rubrica.
• Armazene todo o estado de execução em um diretório temporário do SO com nome único. Nunca crie estado de execução dentro do repositório, workspace, diretório pessoal ou diretório da skill.
• Deixe o diretório temporário exato no lugar quando a execução terminar. Não faça stage, commit, push, publicação ou cópia de seu conteúdo em arquivos duráveis do projeto.
• Mantenha a mecânica do PEV fora da rubrica do produto. Imponha limites de iteração, roteamento de modelo, isolamento de papéis e estado apenas temporário por meio da auditoria mecânica do controlador.
• Não delete, pule, enfraqueça ou reescreva testes existentes apenas para obter aprovação. Permita alterações legítimas em testes apenas quando exigidas pela meta do usuário; então faça o verificador examiná-las minuciosamente.
• Nunca ignore a verificação final completa da rubrica.

Analise a invocação

Aceite uma meta após $pev e estes controles opcionais:

• max=N ou --max N: permita 1..10; padrão 6.
• using=$skill-name: carregue a skill nomeada de forma independente em cada papel onde for relevante. Use seus requisitos na rubrica, exija que o executor a siga e exija que o verificador a avalie de forma independente.

Se a invocação omitir um objetivo, leia a meta nativa ativa. Se nenhuma existir, peça o objetivo e pare.

Quando ferramentas de meta nativas estiverem disponíveis:

1. Leia a meta atual antes de criar uma.
2. Reutilize uma meta ativa apenas quando ela corresponder ao objetivo solicitado.
3. Crie uma meta quando nenhuma existir. Não defina um orçamento de tokens a menos que o usuário tenha fornecido um explicitamente.
4. Se existir uma meta diferente e inacabada, pare e peça ao usuário para resolvê-la em vez de substituí-la.

Quando ferramentas de meta nativas não estiverem disponíveis, continue como uma execução PEV limitada e divulgue que a continuação automática não está disponível.

Inicialize o estado temporário

Execute:

python3 <diretório-da-skill>/scripts/init_run.py --max-iterations <N>

Registre o run_dir absoluto retornado no thread e passe-o explicitamente para cada subagente. Leia references/contracts.md antes do primeiro despacho.

Popule goal.json com o objetivo e restrições exatos. Despache um planejador de especificações novo para criar a definição imutável de pronto. Exija que cada item da rubrica:

• comece insatisfeito;
• descreva um resultado observável em vez de uma atividade;
• nomeie evidências aceitáveis;
• preserve as restrições do usuário e do repositório; e
• seja verificável independentemente.

Exclua a mecânica interna do PEV, como contagem de iterações, seleção de agente, isolamento de contexto, caminhos temporários e contabilidade do controlador, da rubrica do produto. Preserve invariantes visíveis ao usuário do workspace, como "não commitar", "não fazer push" ou "não modificar testes", quando eles restringirem o resultado solicitado.

Congele rubric.json após a verificação do esquema mecânico do controlador. Armazene satisfação mutável e evidências apenas em progress.json.

O controlador é dono de todos os arquivos de estado. Os agentes P, E e V devem retornar respostas JSON compactas e não devem modificar o estado temporário.

Execute o loop

Para cada iteração de 1 a max_iterations, execute estas etapas em ordem.

1. Despache um Planejador novo

Inicie um planejador Sol somente leitura novo. Dê a ele apenas:

• o caminho do workspace;
• goal.json, rubric.json e progress.json;
• o veredito do verificador anterior, quando existir;
• o número da iteração e o orçamento restante; e
• skills solicitadas explicitamente com using=.

Permita que o planejador inspecione o produto e as instruções do repositório. Não forneça a ele raciocínio de planejadores ou executores anteriores.

Exija um task_packet limitado que corresponda ao contrato. Permita DONE_CANDIDATE apenas quando nenhuma unidade de trabalho útil restar; nunca trate isso como prova de conclusão.

Rejeite mecanicamente um plano que:

• não aborde nenhum item insatisfeito da rubrica;
• omita escopo, restrições ou alvos de verificação;
• repita uma unidade de trabalho falha sem responder às evidências do verificador;
• solicite enfraquecimento de testes ou uma ação destrutiva não autorizada; ou
• não caiba em uma única atribuição de executor.

Para trabalho de alto risco em segurança, migração, permissões, finanças ou irreversível, insira um revisor de plano somente leitura novo antes da execução. Dê a ele a meta, a rubrica e o pacote de tarefas, mas nenhum raciocínio do planejador.

Escreva o pacote de tarefas aceito em plan.json antes de despachar o Executor. Não adie atualizações de estado do controlador até após a verificação.

2. Despache um Executor novo

Inicie um trabalhador Sol novo com propriedade apenas dos arquivos e responsabilidade do pacote de tarefas. Diga a ele que outros trabalhos podem existir no código-base e que ele deve preservar alterações não relacionadas.

Dê a ele:

• o pacote de tarefas exato;
• o caminho do workspace e as instruções aplicáveis do repositório;
• as restrições originais necessárias para evitar desvio de escopo; e
• skills solicitadas explicitamente com using=.

Não dê a ele autoridade de verificador. Exija que ele implemente uma unidade de trabalho significativa, execute verificações proporcionais e retorne apenas o recibo do executor. Não deixe que ele atualize a rubrica ou o estado temporário.

Evite que comandos de verificação e build deixem caches incidentais, logs, saída de cobertura ou outros artefatos não relacionados ao produto no workspace alvo. Direcione a saída descartável para um local temporário do SO criado independentemente quando suportado. Caso contrário, remova apenas artefatos descartáveis exatos criados por aquela atribuição cuja proveniência seja certa; nunca delete um caminho pré-existente ou ambíguo.

Direcione o esforço de raciocínio da seguinte forma quando o runtime suportar substituições de modelo:

• execução mecânica e de escopo restrito: gpt-5.6-sol com low;
• implementação comum: gpt-5.6-sol com medium;
• implementação transversal ou arriscada: gpt-5.6-sol com high.

Não faça commit ou push a menos que a meta solicite explicitamente essas ações.

3. Despache um Verificador cego novo

Inicie um verificador Sol somente leitura novo com raciocínio high; use xhigh para trabalho crítico de segurança, migração, permissões ou irreversível.

Dê a ele apenas:

• a meta original exata e a rubrica congelada;
• o workspace ou artefato produzido;
• instruções aplicáveis do repositório;
• comandos de verificação exigidos pelo usuário; e
• skills solicitadas explicitamente com using=.

Não forneça a ele o diretório de execução do controlador, pacote de tarefas, saída do planejador, recibo do executor, resumo da implementação, resultado esperado, fundamentação de vereditos anteriores ou histórico de conversas P/E. Dê ao verificador um diretório temporário separado do SO para saída descartável, se suas ferramentas precisarem.

Exija que o verificador inspecione o produto atual de forma independente, execute verificações relevantes, examine alterações em testes em busca de recompensa maliciosa e retorne o contrato de veredito. O verificador não deve modificar produto, testes, estado de execução ou sistemas externos.

4. Atualize o estado canônico

Deixe o controlador validar a forma da resposta, escrever a resposta completa no arquivo de veredito da iteração e copiar status e evidências respaldadas pelo verificador para progress.json antes do próximo despacho. Não reinterprete evidências fracas como aprovação.

• Em NEEDS_WORK, inicie a próxima iteração com um novo planejador.
• Em PASS, despache um verificador final novo adicional sem status de satisfação anteriores. Exija que ele avalie cada item da rubrica do zero.
• Em PASS final, execute a auditoria mecânica do controlador sobre isolamento de papéis, contagem de iterações, estado apenas temporário e limites de autorização. Marque a meta nativa como completa apenas quando ambas as barreiras passarem.
• Em falha final, continue se restarem iterações.

Condições de parada

Pare com sucesso apenas após o verificador final cego provar cada item da rubrica.

Trate a verificação do produto e a integridade da orquestração como barreiras separadas:

• Barreira do produto: um verificador final cego novo prova a rubrica congelada.
• Barreira do controlador: registros verificáveis por máquina provam o limite de iteração, despacho com contexto novo, estado apenas temporário e ausência de commit, push, publicação, implantação ou ação destrutiva não autorizados.

Não envie falhas de contabilidade do controlador de volta ao Verificador de Produto nem as transforme em itens da rubrica do produto. Repare falhas seguras de contabilidade imediatamente quando possível; caso contrário, reporte a falha da barreira do controlador sem reivindicar conclusão.

No limite de iteração:

• não reivindique sucesso;
• não marque a meta como completa ou bloqueada apenas porque o limite foi atingido;
• reporte itens satisfeitos, itens restantes, evidências decisivas e o caminho temporário exato; e
• deixe a meta ativa para uma continuação explícita.

Marque uma meta como bloqueada apenas quando o limite de bloqueio repetido do runtime estiver genuinamente satisfeito. Pause para entrada do usuário quando autorização, uma decisão material do produto, credenciais ausentes ou uma dependência externa indisponível impedirem progresso seguro.

Recuperação

Se o diretório temporário desaparecer, crie um novo e reconstrua o objetivo e a rubrica congelada a partir da meta ativa do thread e da conversa. Trate toda satisfação anterior como não comprovada, então execute um verificador completo novo antes de continuar.

Se um subagente falhar:

• tente novamente um papel crítico P, E ou V uma vez com a mesma barreira de isolamento;
• nunca substitua um veredito de verificador ausente por julgamento do controlador;
• reduza uma unidade de trabalho muito grande por meio de um novo planejador;
• preserve alterações não relacionadas no workspace; e
• reporte lacunas honestamente quando o limite de iteração impedir a recuperação.

Barreira de qualidade final

Antes de retornar sucesso, confirme:

• o agente primário atuou apenas como controlador;
• cada papel usou contexto novo e isolado;
• nenhum agente avaliou sua própria saída;
• o verificador não viu raciocínio P/E ou resultado esperado;
• cada item da rubrica tem evidência atual e direta do verificador final;
• testes existentes não foram enfraquecidos para fabricar sucesso;
• artefatos incidentais de comandos criados pelo fluxo de trabalho não permanecem no workspace alvo;
• o estado de execução existe apenas sob o diretório temporário do SO registrado;
• nenhum estado de execução foi commitado ou copiado para o projeto; e
• a meta nativa, quando disponível, foi marcada como completa apenas após o PASS final.