merttcetn/pev-loop

Bucle PEV

Ejecuta un bucle Planificador-Ejecutor-Verificador sin estado alrededor de un objetivo persistente. Mantén al agente principal como un controlador delgado: mantener el estado canónico, despachar roles aislados, aplicar límites y reportar resultados sin planificar, implementar ni calificar el producto en sí.

Garantías no negociables

• Exigir invocación explícita de $pev. Tratar esa invocación como autorización para crear o reutilizar el objetivo nativo coincidente y despachar los subagentes P, E y V.
• Mantener al controlador fuera del trabajo del producto. No inspeccionar cuerpos de código fuente, implementar cambios, interpretar registros de prueba sin procesar ni decidir la satisfacción de rúbricas en el contexto primario.
• Crear cada agente P, E y V con contexto fresco. Usar fork_turns="none" o el equivalente más fuerte del entorno de ejecución.
• No permitir nunca que un agente califique su propio trabajo.
• Ocultar el razonamiento, resúmenes y resultados esperados del planificador y ejecutor al verificador.
• Permitir que solo la evidencia del verificador cambie la satisfacción de la rúbrica.
• Almacenar todo el estado de ejecución en un directorio temporal del SO con nombre único. Nunca crear estado de ejecución bajo el repositorio, espacio de trabajo, directorio personal o directorio de la skill.
• Dejar el directorio temporal exacto en su lugar cuando termine la ejecución. No almacenar, confirmar, enviar, publicar ni copiar su contenido en archivos duraderos del proyecto.
• Mantener la mecánica de PEV fuera de la rúbrica del producto. Aplicar límites de iteración, enrutamiento de modelos, aislamiento de roles y estado solo temporal a través de la auditoría mecánica del controlador.
• No eliminar, omitir, debilitar ni reescribir pruebas existentes solo para obtener un aprobado. Permitir cambios legítimos en las pruebas solo cuando los exija el objetivo del usuario, luego hacer que el verificador los analice.
• Nunca eludir la verificación final completa de la rúbrica.

Analizar la invocación

Acepta un objetivo después de $pev y estos controles opcionales:

• max=N o --max N: permitir 1..10; por defecto 6.
• using=$skill-name: cargar la skill nombrada de forma independiente en cada rol donde sea relevante. Usar sus requisitos en la rúbrica, exigir que el ejecutor la siga y exigir que el verificador la evalúe de forma independiente.

Si la invocación omite un objetivo, leer el objetivo nativo activo. Si no existe ninguno, preguntar por el objetivo y detenerse.

Cuando las herramientas de objetivo nativo estén disponibles:

1. Leer el objetivo actual antes de crear uno.
2. Reutilizar un objetivo activo solo cuando coincida con el objetivo solicitado.
3. Crear un objetivo cuando no exista ninguno. No establecer un presupuesto de tokens a menos que el usuario lo haya proporcionado explícitamente.
4. Si existe un objetivo diferente sin finalizar, detenerse y pedir al usuario que lo resuelva en lugar de reemplazarlo.

Cuando las herramientas de objetivo nativo no estén disponibles, continuar como una ejecución PEV acotada e informar que la continuación automática no está disponible.

Inicializar estado temporal

Ejecutar:

python3 <directorio-de-la-skill>/scripts/init_run.py --max-iterations <N>

Registrar el run_dir absoluto devuelto en el hilo y pasarlo explícitamente a cada subagente. Leer references/contracts.md antes del primer despacho.

Poblar goal.json con el objetivo y las restricciones exactas. Despachar un planificador de especificaciones fresco para crear la definición inmutable de "hecho". Exigir que cada elemento de la rúbrica:

• comience insatisfecho;
• describa un resultado observable en lugar de una actividad;
• nombre la evidencia aceptable;
• preserve las restricciones del usuario y del repositorio; y
• sea verificable de forma independiente.

Excluir la mecánica interna de PEV como el número de iteración, selección de agente, aislamiento de contexto, rutas temporales y contabilidad del controlador de la rúbrica del producto. Preservar invariantes del espacio de trabajo visibles para el usuario como "no confirmar", "no enviar" o "no modificar pruebas" cuando limiten el resultado solicitado.

Congelar rubric.json después de la compuerta de esquema mecánico del controlador. Almacenar satisfacción y evidencia mutables solo en progress.json.

El controlador posee todos los archivos de estado. Los agentes P, E y V deben devolver respuestas JSON compactas y no deben modificar el estado temporal.

Ejecutar el bucle

Para cada iteración desde 1 hasta max_iterations, ejecutar estas etapas en orden.

1. Despachar un Planificador fresco

Iniciar un planificador Sol de solo lectura fresco. Darle solo:

• la ruta del espacio de trabajo;
• goal.json, rubric.json y progress.json;
• el veredicto del verificador anterior, cuando exista;
• el número de iteración y el presupuesto restante; y
• las skills solicitadas explícitamente con using=.

Permitir que el planificador inspeccione el producto y las instrucciones del repositorio. No darle razonamientos previos del planificador o ejecutor.

Exigir un task_packet acotado que coincida con el contrato. Permitir DONE_CANDIDATE solo cuando no quede ninguna unidad de trabajo útil; nunca tratarlo como prueba de finalización.

Rechazar mecánicamente un plan que:

• no aborde ningún elemento insatisfecho de la rúbrica;
• omita alcance, restricciones o objetivos de verificación;
• repita una unidad de trabajo fallida sin responder a la evidencia del verificador;
• solicite debilitamiento de pruebas o una acción destructiva no autorizada; o
• no pueda caber dentro de una asignación de ejecutor.

Para trabajo de alto riesgo en seguridad, migración, permisos, financiero o irreversible, insertar un revisor de plan de solo lectura fresco antes de la ejecución. Darle el objetivo, la rúbrica y el paquete de tareas, pero no el razonamiento del planificador.

Escribir el paquete de tareas aceptado en plan.json antes de despachar al Ejecutor. No posponer las actualizaciones de estado del controlador hasta después de la verificación.

2. Despachar un Ejecutor fresco

Iniciar un trabajador Sol fresco con propiedad solo de los archivos y la responsabilidad del paquete de tareas. Decirle que puede existir otro trabajo en la base de código y que debe preservar los cambios no relacionados.

Darle:

• el paquete de tareas exacto;
• la ruta del espacio de trabajo y las instrucciones aplicables del repositorio;
• las restricciones originales necesarias para evitar la desviación del alcance; y
• las skills solicitadas explícitamente con using=.

No darle autoridad de verificador. Exigir que implemente una unidad de trabajo significativa, ejecute comprobaciones proporcionadas y devuelva solo el recibo del ejecutor. No permitirle actualizar la rúbrica ni el estado temporal.

Evitar que los comandos de verificación y compilación dejen cachés incidentales, registros, cobertura de salida u otros artefactos no relacionados con el producto en el espacio de trabajo de destino. Dirigir la salida desechable a una ubicación temporal del SO creada de forma independiente cuando sea compatible. De lo contrario, eliminar solo los artefactos desechables exactos creados por esa asignación cuyo origen sea seguro; nunca eliminar una ruta preexistente o ambigua.

Dirigir el esfuerzo de razonamiento de la siguiente manera cuando el entorno de ejecución admita anulaciones de modelo:

• ejecución mecánica y de alcance limitado: gpt-5.6-sol con low;
• implementación ordinaria: gpt-5.6-sol con medium;
• implementación transversal o riesgosa: gpt-5.6-sol con high.

No confirmar ni enviar a menos que el objetivo lo solicite explícitamente.

3. Despachar un Verificador ciego fresco

Iniciar un verificador Sol de solo lectura fresco con razonamiento high; usar xhigh para trabajo crítico de seguridad, migración, permisos o irreversible.

Darle solo:

• el objetivo original exacto y la rúbrica congelada;
• el espacio de trabajo o el artefacto producido;
• las instrucciones aplicables del repositorio;
• los comandos de verificación exigidos por el usuario; y
• las skills solicitadas explícitamente con using=.

No darle el directorio de ejecución del controlador, el paquete de tareas, la salida del planificador, el recibo del ejecutor, el resumen de implementación, el resultado esperado, la justificación del veredicto anterior ni el historial de conversación de P/E. Dar al verificador un directorio temporal separado del SO si sus herramientas necesitan salida desechable.

Exigir que el verificador inspeccione el producto actual de forma independiente, ejecute las comprobaciones relevantes, examine los cambios en las pruebas para detectar manipulación de recompensas y devuelva el contrato de veredicto. El verificador no debe modificar el producto, las pruebas, el estado de ejecución ni los sistemas externos.

4. Actualizar el estado canónico

Permitir que el controlador valide la forma de la respuesta, escriba la respuesta completa en el archivo de veredicto de la iteración y copie los estados y la evidencia respaldados por el verificador en progress.json antes del siguiente despacho. No reinterpretar evidencia débil como un aprobado.

• En NEEDS_WORK, iniciar la siguiente iteración con un nuevo planificador.
• En PASS, despachar un verificador final fresco adicional sin estados de satisfacción previos. Exigir que evalúe cada elemento de la rúbrica desde cero.
• En PASS final, ejecutar la auditoría mecánica del controlador sobre el aislamiento de roles, el recuento de iteraciones, el estado solo temporal y los límites de autorización. Marcar el objetivo nativo como completo solo cuando ambas compuertas pasen.
• En fallo final, continuar si quedan iteraciones.

Condiciones de parada

Detenerse con éxito solo después de que el verificador final fresco demuestre cada elemento de la rúbrica.

Tratar la verificación del producto y la integridad de la orquestación como compuertas separadas:

• Compuerta de producto: un verificador final ciego fresco demuestra la rúbrica congelada.
• Compuerta de controlador: registros verificables por máquina demuestran el límite de iteración, el despacho de roles frescos, el estado solo temporal y la ausencia de confirmación, envío, publicación, despliegue o acción destructiva no autorizados.

No enviar fallos de contabilidad del controlador al Verificador de Producto ni convertirlos en elementos de la rúbrica del producto. Reparar la contabilidad segura de inmediato cuando sea posible; de lo contrario, informar el fallo de la compuerta del controlador sin reclamar finalización.

En el límite de iteración:

• no reclamar éxito;
• no marcar el objetivo como completo o bloqueado solo porque se alcanzó el límite;
• informar los elementos satisfechos, los elementos restantes, la evidencia decisiva y la ruta temporal exacta; y
• dejar el objetivo activo para una continuación explícita.

Marcar un objetivo como bloqueado solo cuando el umbral de bloqueo repetido del entorno de ejecución esté genuinamente satisfecho. Pausar para entrada del usuario cuando la autorización, una decisión material del producto, credenciales faltantes o una dependencia externa no disponible impidan un progreso seguro.

Recuperación

Si el directorio temporal desaparece, crear uno nuevo y reconstruir el objetivo y la rúbrica congelada a partir del objetivo del hilo activo y la conversación. Tratar toda satisfacción previa como no probada, luego ejecutar un verificador completo fresco antes de continuar.

Si un subagente falla:

• reintentar un rol crítico P, E o V una vez con el mismo límite de aislamiento;
• nunca reemplazar un veredicto de verificador faltante con el juicio del controlador;
• reducir una unidad de trabajo demasiado grande a través de un nuevo planificador;
• preservar los cambios no relacionados en el espacio de trabajo; y
• informar las brechas honestamente cuando el límite de iteración impida la recuperación.

Compuerta de calidad final

Antes de devolver éxito, confirmar:

• el agente principal actuó solo como controlador;
• cada rol usó contexto fresco aislado;
• ningún agente calificó su propia salida;
• el verificador no vio razonamiento de P/E ni resultado esperado;
• cada elemento de la rúbrica tiene evidencia actual y directa del verificador final;
• las pruebas existentes no se debilitaron para fabricar éxito;
• los artefactos de comandos incidentales creados por el flujo de trabajo no permanecen en el espacio de trabajo de destino;
• el estado de ejecución existe solo bajo el directorio temporal del SO registrado;
• ningún estado de ejecución fue confirmado o copiado en el proyecto; y
• el objetivo nativo, cuando esté disponible, se marcó como completo solo después del PASS final.