merttcetn/pev-loop

Boucle PEV

Exécuter une boucle Planificateur-Exécuteur-Vérificateur sans état autour d'un objectif persistant. Maintenir l'agent principal en tant que contrôleur léger : gérer l'état canonique, dispatcher des rôles isolés, appliquer les limites, et rapporter les résultats sans planifier, implémenter ou évaluer le produit lui-même.

Garanties non négociables

• Exiger une invocation explicite de $pev. Considérer cette invocation comme une autorisation pour créer ou réutiliser l'objectif natif correspondant et pour dispatcher les sous-agents P, E et V.
• Maintenir le contrôleur en dehors du travail sur le produit. Ne pas inspecter le code source, implémenter des modifications, interpréter des journaux de test bruts, ni décider de la satisfaction du référentiel dans le contexte principal.
• Créer chaque agent P, E et V avec un contexte frais. Utiliser fork_turns="none" ou l'équivalent le plus strict du runtime.
• Ne jamais laisser un agent évaluer son propre travail.
• Cacher le raisonnement, les résumés et les résultats attendus du planificateur et de l'exécuteur au vérificateur.
• Seule la preuve du vérificateur peut modifier la satisfaction du référentiel.
• Stocker tout l'état d'exécution dans un seul répertoire temporaire OS nommé de manière unique. Ne jamais créer d'état d'exécution sous le dépôt, l'espace de travail, le répertoire personnel ou le répertoire de la compétence.
• Laisser le répertoire temporaire exact en place à la fin de l'exécution. Ne pas préparer, commiter, pousser, publier ni copier son contenu dans des fichiers de projet durables.
• Garder la mécanique PEV en dehors du référentiel produit. Appliquer les limites d'itération, le routage des modèles, l'isolement des rôles et l'état temporaire uniquement via l'audit mécanique du contrôleur.
• Ne pas supprimer, ignorer, affaiblir ou réécrire des tests existants uniquement pour obtenir une réussite. Permettre des modifications légitimes des tests uniquement lorsqu'elles sont requises par l'objectif utilisateur, puis faire en sorte que le vérificateur les examine minutieusement.
• Ne jamais contourner la vérification finale complète du référentiel.

Analyser l'invocation

Accepter un objectif après $pev et ces contrôles optionnels :

• max=N ou --max N : autoriser 1..10 ; par défaut à 6.
• using=$skill-name : charger la compétence nommée de manière indépendante dans chaque rôle où elle est pertinente. Utiliser ses exigences dans le référentiel, exiger que l'exécuteur la suive, et exiger que le vérificateur l'évalue indépendamment.

Si l'invocation omet un objectif, lire l'objectif natif actif. Si aucun n'existe, demander l'objectif et s'arrêter.

Lorsque les outils d'objectif natif sont disponibles :

1. Lire l'objectif actuel avant d'en créer un.
2. Réutiliser un objectif actif uniquement lorsqu'il correspond à l'objectif demandé.
3. Créer un objectif lorsqu'aucun n'existe. Ne pas définir de budget de jetons sauf si l'utilisateur en a explicitement fourni un.
4. Si un objectif différent non terminé existe, s'arrêter et demander à l'utilisateur de le résoudre au lieu de le remplacer.

Lorsque les outils d'objectif natif ne sont pas disponibles, continuer en tant qu'exécution PEV bornée et divulguer que la continuation automatique est indisponible.

Amorcer l'état temporaire

Exécuter :

python3 <chemin-de-la-competence>/scripts/init_run.py --max-iterations <N>

Enregistrer le run_dir absolu retourné dans le fil de discussion et le passer explicitement à chaque sous-agent. Lire references/contracts.md avant le premier dispatch.

Remplir goal.json avec l'objectif et les contraintes exacts. Dispatcher un planificateur de spécifications frais pour créer la définition immuable de ce qui est fait (definition of done). Exiger que chaque élément du référentiel :

• commence insatisfait ;
• décrive un résultat observable plutôt qu'une activité ;
• nomme des preuves acceptables ;
• préserve les contraintes utilisateur et du dépôt ; et
• soit vérifiable de manière indépendante.

Exclure les mécaniques internes PEV telles que le nombre d'itérations, la sélection d'agent, l'isolement du contexte, les chemins temporaires et la comptabilité du contrôleur du référentiel produit. Préserver les invariants de l'espace de travail visibles par l'utilisateur tels que "ne pas commiter", "ne pas pousser", ou "ne pas modifier les tests" lorsqu'ils contraignent le résultat demandé.

Figer rubric.json après le schéma mécanique du contrôleur. Stocker la satisfaction et les preuves mutables uniquement dans progress.json.

Le contrôleur possède chaque fichier d'état. Les agents P, E et V doivent retourner des réponses JSON compactes et ne doivent pas modifier l'état temporaire.

Exécuter la boucle

Pour chaque itération de 1 à max_iterations, exécuter ces étapes dans l'ordre.

1. Dispatcher un planificateur frais

Démarrer un planificateur Sol frais en lecture seule. Lui donner uniquement :

• le chemin de l'espace de travail ;
• goal.json, rubric.json et progress.json ;
• le verdict précédent du vérificateur, s'il en existe un ;
• le numéro d'itération et le budget restant ; et
• les compétences using= explicitement demandées.

Permettre au planificateur d'inspecter le produit et les instructions du dépôt. Ne pas lui donner le raisonnement du planificateur ou de l'exécuteur précédents.

Exiger un task_packet borné conforme au contrat. Permettre DONE_CANDIDATE uniquement lorsqu'aucune unité de travail utile ne reste ; ne jamais le traiter comme une preuve d'achèvement.

Rejeter mécaniquement un plan qui :

• n'adresse aucun élément insatisfait du référentiel ;
• omet le scope, les contraintes ou les cibles de vérification ;
• répète une unité de travail échouée sans répondre aux preuves du vérificateur ;
• demande un affaiblissement des tests ou une action destructive non autorisée ; ou
• ne peut pas tenir dans une seule affectation d'exécuteur.

Pour les travaux à haut risque (sécurité, migration, permissions, financier ou irréversible), insérer un relecteur de plan frais en lecture seule avant l'exécution. Lui donner l'objectif, le référentiel et le paquet de tâches, mais aucun raisonnement du planificateur.

Écrire le paquet de tâches accepté dans plan.json avant de dispatcher l'exécuteur. Ne pas différer les mises à jour de l'état du contrôleur jusqu'après la vérification.

2. Dispatcher un exécuteur frais

Démarrer un travailleur Sol frais avec la propriété uniquement des fichiers et de la responsabilité du paquet de tâches. Lui dire que d'autres travaux peuvent exister dans la base de code et qu'il doit préserver les modifications non liées.

Lui donner :

• le paquet de tâches exact ;
• le chemin de l'espace de travail et les instructions applicables du dépôt ;
• les contraintes originales nécessaires pour éviter la dérive de scope ; et
• les compétences using= explicitement demandées.

Ne pas lui donner l'autorité de vérificateur. Exiger qu'il implémente une unité de travail significative, exécute des vérifications proportionnées, et retourne uniquement le reçu de l'exécuteur. Ne pas le laisser mettre à jour le référentiel ou l'état temporaire.

Empêcher les commandes de vérification et de construction de laisser des caches, journaux, sorties de couverture ou autres artefacts non produits dans l'espace de travail cible. Router la sortie jetable vers un emplacement temporaire OS créé indépendamment lorsque c'est possible. Sinon, supprimer uniquement les artefacts jetables exacts créés par cette affectation et dont la provenance est certaine ; ne jamais supprimer un chemin préexistant ou ambigu.

Router l'effort de raisonnement comme suit lorsque le runtime prend en charge les surcharges de modèle :

• exécution mécanique et étroitement ciblée : gpt-5.6-sol avec low ;
• implémentation ordinaire : gpt-5.6-sol avec medium ;
• implémentation transverse ou risquée : gpt-5.6-sol avec high.

Ne pas commiter ni pousser sauf si l'objectif demande explicitement ces actions.

3. Dispatcher un vérificateur aveugle frais

Démarrer un vérificateur Sol frais en lecture seule avec un raisonnement high ; utiliser xhigh pour les travaux critiques de sécurité, migration, permissions ou irréversibles.

Lui donner uniquement :

• l'objectif original exact et le référentiel figé ;
• l'espace de travail ou l'artefact produit ;
• les instructions applicables du dépôt ;
• les commandes de vérification imposées par l'utilisateur ; et
• les compétences using= explicitement demandées.

Ne pas lui donner le répertoire d'exécution du contrôleur, le paquet de tâches, la sortie du planificateur, le reçu de l'exécuteur, le résumé d'implémentation, le résultat attendu, la justification du verdict précédent, ni l'historique de conversation P/E. Donner au vérificateur un répertoire temporaire OS séparé si ses outils ont besoin de sortie jetable.

Exiger que le vérificateur inspecte le produit actuel de manière indépendante, exécute les vérifications pertinentes, examine les modifications des tests pour détecter un contournement (reward hacking), et retourne le contrat de verdict. Le vérificateur ne doit pas modifier le produit, les tests, l'état d'exécution ni les systèmes externes.

4. Mettre à jour l'état canonique

Laisser le contrôleur valider la forme de la réponse, écrire la réponse complète dans le fichier de verdict de l'itération, et copier les statuts et preuves soutenus par le vérificateur dans progress.json avant tout prochain dispatch. Ne pas réinterpréter une preuve faible comme une réussite.

• Sur NEEDS_WORK, commencer l'itération suivante avec un nouveau planificateur.
• Sur PASS, dispatcher un vérificateur final frais supplémentaire sans aucun statut de satisfaction précédent. Exiger qu'il évalue chaque élément du référentiel à partir de zéro.
• Sur PASS final, exécuter l'audit mécanique du contrôleur concernant l'isolement des rôles, le nombre d'itérations, l'état temporaire uniquement et les limites d'autorisation. Marquer l'objectif natif comme terminé uniquement lorsque les deux portes sont franchies.
• Sur échec final, continuer s'il reste des itérations.

Conditions d'arrêt

S'arrêter avec succès uniquement après que le vérificateur final frais a prouvé chaque élément du référentiel.

Traiter la vérification du produit et l'intégrité de l'orchestration comme des portes séparées :

• Porte produit : un vérificateur final frais aveugle prouve le référentiel figé.
• Porte contrôleur : des enregistrements vérifiables par machine prouvent la limite d'itération, le dispatch avec contexte frais, l'état temporaire uniquement et l'absence de commit, push, publication, déploiement ou action destructive non autorisés.

Ne pas renvoyer les échecs de comptabilité du contrôleur au vérificateur produit ni les transformer en éléments du référentiel produit. Réparer immédiatement la comptabilité sûre lorsque c'est possible ; sinon signaler l'échec de la porte contrôleur sans revendiquer l'achèvement.

À la limite d'itération :

• ne pas revendiquer le succès ;
• ne pas marquer l'objectif comme terminé ou bloqué simplement parce que la limite a été atteinte ;
• rapporter les éléments satisfaits, les éléments restants, les preuves décisives et le chemin temporaire exact ; et
• laisser l'objectif actif pour une continuation explicite.

Marquer un objectif comme bloqué uniquement lorsque le seuil de blocage répété du runtime est véritablement satisfait. Faire une pause pour l'entrée utilisateur lorsque l'autorisation, une décision produit matérielle, des identifiants manquants ou une dépendance externe indisponible empêchent une progression sûre.

Récupération

Si le répertoire temporaire disparaît, en créer un nouveau et reconstruire l'objectif et le référentiel figé à partir de l'objectif du fil de discussion actif et de la conversation. Considérer toute satisfaction antérieure comme non prouvée, puis exécuter un vérificateur frais complet avant de continuer.

Si un sous-agent échoue :

• réessayer un rôle critique P, E ou V une fois avec la même frontière d'isolement ;
• ne jamais remplacer un verdict de vérificateur manquant par le jugement du contrôleur ;
• réduire une unité de travail trop volumineuse via un nouveau planificateur ;
• préserver les modifications non liées de l'espace de travail ; et
• rapporter honnêtement les lacunes lorsque la limite d'itération empêche la récupération.

Porte de qualité finale

Avant de retourner le succès, confirmer :

• l'agent principal a agi uniquement en tant que contrôleur ;
• chaque rôle a utilisé un contexte frais isolé ;
• aucun agent n'a évalué sa propre sortie ;
• le vérificateur n'a vu aucun raisonnement P/E ni résultat attendu ;
• chaque élément du référentiel dispose de preuves actuelles et directes du vérificateur final ;
• les tests existants n'ont pas été affaiblis pour fabriquer un succès ;
• les artefacts de commande incidents créés par le flux de travail ne restent pas dans l'espace de travail cible ;
• l'état d'exécution existe uniquement sous le répertoire temporaire OS enregistré ;
• aucun état d'exécution n'a été commité ni copié dans le projet ; et
• l'objectif natif, lorsqu'il est disponible, a été marqué comme terminé uniquement après le PASS final.