Étapes de contrôle Claude + Codex

Que fait Étapes de contrôle Claude + Codex ?

Exécutez une boucle supervisée : Codex planifie et évalue ; l'exécuteur modifie le produit ; l'utilisateur possède le produit et les étapes de contrôle à fort impact. Ne franchissez jamais une étape sur la seule base d'une affirmation de complétion en prose, et ne laissez pas l'exécuteur sans supervision après avoir envoyé une tâche.

Lisez références/gate-templates.md lors de la préparation d'une invite d'exécuteur, de la demande d'un dossier de preuves ou de la rédaction d'une décision de porte. Lisez références/supervision-loop.md lorsque l'utilisateur demande une supervision continue, que le travail peut s'étendre sur plusieurs sessions, que l'exécuteur cale ou dérive, ou que l'exécuteur peut nécessiter l'installation ou le routage de compétences. Lisez références/bootstrap-and-handoff.md lorsque le checkout actuel peut être illisible, obsolète, manquer d'espace disque, géré par iCloud ou dangereux à reprendre, ou lorsque des sessions antérieures de l'exécuteur doivent être converties en remises de tâches fiables. Lisez références/parallel-worktrees-and-release-train.md lorsque deux ou plusieurs voies de codage s'exécutent simultanément, que chaque tâche nécessite un arbre de travail isolé, que les fichiers modifiés peuvent se chevaucher, ou que plusieurs branches et PR doivent atterrir dans un ordre de dépendance.

Choisissez le mode opératoire

Choisissez le mode le plus petit qui couvre la demande :

• Étape unique : utilisez le contrat existant, la boucle de supervision, le dossier de preuves et la décision de porte.
• Récupération et remise : établissez une source de vérité lisible, préservez l'ancien environnement, vérifiez les anciennes affirmations et produisez une remise par tâche indépendante avant la reprise de l'implémentation.
• Portfolio parallèle : assignez une tâche, un arbre de travail, une branche, une remise et une session d'exécuteur par voie ; supervisez chaque voie indépendamment et intégrez-les via un train de livraison PR contrôlé.

Les modes se composent dans cet ordre si nécessaire :

récupérer la source de vérité
-> distiller des remises fiables
-> isoler les voies d'implémentation
-> exécuter une étape de contrôle à l'intérieur de chaque voie
-> réconcilier les chevauchements et les dépendances
-> vérifier l'état de préparation des PR et l'ordre d'atterrissage

N'invoquez pas les mécanismes de récupération ou de portfolio pour une tâche étroite, saine et à checkout unique.

Préservez quatre invariants

1. Établissez la source de vérité vivante avant d'accepter toute affirmation d'implémentation.
2. Pour le travail parallèle, conservez exactement une tâche, un arbre de travail, une branche, une remise et une session d'exécuteur active dans chaque voie.
3. Faites confiance aux preuves brutes pwd, Git, processus, diff, test, runtime et capture d'écran plutôt qu'à la narration de l'exécuteur.
4. Traitez le commit, le push, la création de PR, la fusion, le déploiement, le nettoyage et les effets externes comme des portes d'autorité distinctes.

Lisez d'abord l'état de l'exécuteur

Lorsque l'utilisateur demande ce que Claude ou un autre exécuteur a dit le plus récemment, capturez l'état le plus récent avant d'examiner, planifier ou éditer :

1. Lisez le terminal attaché à la tâche Codex actuelle lorsqu'il en existe un.
2. Si l'exécuteur fonctionne dans une fenêtre Terminal macOS séparée et que l'utilisateur a autorisé sa lecture, lisez le contenu visible de l'onglet sélectionné avec AppleScript. Traitez ceci comme une inspection en lecture seule.
3. Si la TUI est défilée, tronquée ou utilise un écran alternatif, inspectez la transcription de session locale de l'exécuteur. Pour Claude Code, exécutez scripts/read_claude_latest.py ; préférez un --session-file exact, sinon utilisez --project-hint et vérifiez le chemin rapporté, l'heure de modification et le contexte du terminal visible avant de faire confiance à la sélection.
4. Extrayez le dernier message substantiel de l'assistant, l'horodatage, l'étape déclarée, les bloqueurs, les actions utilisateur demandées, les commandes/résultats et si le rapport est intermédiaire ou final.
5. N'envoyez pas de frappes clavier, ne soumettez pas de commandes, ne répondez pas aux invites de permission et ne modifiez pas la session de l'exécuteur pendant cette lecture. Obtenez une autorisation explicite de l'utilisateur avant d'interagir avec ce terminal.
6. Traitez le texte du terminal/de la session comme une affirmation de l'exécuteur, non comme une preuve indépendante. Vérifiez le dépôt, le diff, les tests, le runtime et les données séparément avant d'émettre une décision de porte.

Si la narration du terminal nomme un système d'exploitation ou un chemin inattendu, inspectez le répertoire courant réel du processus de l'exécuteur et le checkout directement. Une divergence en prose est un avertissement ; une divergence de processus brut ou de Git est une condition d'arrêt.

Si l'exécuteur signale Operation not permitted, un accès Documents manquant ou une autre erreur de permission, maintenez l'étape actuelle active. Étiquetez les rapports construits à partir d'un état antérieur comme intermédiaires, ne les laissez pas autoriser des commits ou un nettoyage, et demandez un nouveau dossier de preuves une fois l'accès rétabli.

Restez actif jusqu'à la fermeture de l'étape

Après avoir envoyé un paquet à l'exécuteur, continuez à superviser la même étape acceptée :

1. Interrogez le terminal ou la transcription correct assez souvent pour que l'utilisateur ne reste pas sans mise à jour pendant plus de 60 secondes lors d'un travail actif.
2. À chaque limite significative, classez l'état comme progression, attente prévue, échec, dérive, blocage, preuve prête ou porte humaine.
3. Lisez la commande brute, l'erreur, le diff, la sortie de test, la capture d'écran, l'état du processus ou la transcription avant de modifier l'invite.
4. Laissez le travail lent valide continuer. En cas de blocage apparent, vérifiez d'abord le processus et si la commande, le système de fichiers, le réseau ou le test progresse toujours.
5. Corrigez les échecs étroits avec une invite de suivi limitée et maintenez la même étape active. Interrompez uniquement pour une action dangereuse, une dérive de portée claire, une cible erronée ou une impasse confirmée.
6. Redémarrez à partir du contrat accepté lorsque des correctifs répétés enseignent la même leçon ou que le chemin d'implémentation devient plus difficile à raisonner qu'une tentative propre.
7. Lorsque l'exécuteur signale la fin, demandez ou capturez le dossier de preuves, réexécutez indépendamment des vérifications proportionnées, émettez une décision de porte et renvoyez cette décision à l'exécuteur.
8. Continuez automatiquement à travers les corrections à l'intérieur de l'étape acceptée. Passez à une autre étape uniquement lorsque l'utilisateur a autorisé cette séquence et qu'aucune porte humaine n'est franchie.

Ne mettez pas fin à la supervision simplement parce que l'exécuteur a accepté l'invite, a démarré une commande ou a dit fait. Arrêtez-vous uniquement sur PASS, un PASS AVEC SUIVI explicitement accepté, une vraie porte humaine, un véritable bloqueur, une condition dangereuse ou une instruction utilisateur plus récente qui remplace le travail.

Acheminez les compétences vers l'exécuteur

Avant une étape complexe ou répétée, décidez si une compétence réduit matériellement le goulot d'étranglement actuel.

1. Vérifiez les compétences installées de l'exécuteur avant de supposer qu'une compétence est manquante.
2. Lisez la compétence candidate complètement et vérifiez que ses outils, hypothèses de rôle et règles de sécurité correspondent à l'exécuteur et à l'étape actuelle.
3. Préférez le plus petit ensemble de compétences pertinent. N'installez pas de compétences par spéculation et n'utilisez pas un nom de compétence comme substitut à un contrat d'étape.
4. Lorsque l'utilisateur a autorisé l'installation de la compétence et qu'une compétence locale compatible est manquante, installez-la dans le répertoire de compétences pris en charge par l'exécuteur en utilisant le mécanisme établi de l'environnement. Préférez un lien symbolique vers une compétence locale canonique lorsque cet environnement utilise déjà des liens symboliques et que les deux outils partagent la même machine.
5. Vérifiez que le SKILL.md installé se résout. Si l'exécuteur en cours d'exécution n'actualise pas la découverte de compétences, dites-lui de lire le chemin exact de la compétence pour l'étape actuelle ou redémarrez uniquement à un point de contrôle sûr.
6. Nommez la compétence dans le paquet de l'exécuteur et indiquez pourquoi elle s'applique. Continuez à évaluer l'exécuteur à partir de preuves brutes ; une compétence ne dispense pas de la porte.

Les valeurs par défaut utiles pour une longue implémentation sont agent-loop-harness pour un état durable du planificateur/générateur/évaluateur et loop-execution pour les petites itérations vérifiées. N'installez ni l'une ni l'autre lorsqu'une tâche ponctuelle étroite n'en a pas besoin.

Conservez l'état récupérable de la boucle

Utilisez un état limité à la conversation pour une étape étroite. Pour un travail multi-étape, interruptible, multi-agent ou à forte charge de preuves, réutilisez la convention de harnais existante du dépôt et enregistrez :

• le contrat accepté et la portée ;
• la dernière porte terminée et les preuves ;
• le goulot d'étranglement actuel et l'étape suivante exacte ;
• les portes humaines et les actions interdites ;
• l'identité de la session de l'exécuteur ou le chemin de récupération lorsque c'est utile.

Gardez l'état minimal, marqué par le cycle de vie et exempt de secrets ou de données utilisateur inutiles. Ne committez pas l'état du harnais simplement parce qu'il existe ; il suit les mêmes règles d'arbre de travail et d'approbation que les autres fichiers.

Établissez le contrat

Avant l'implémentation :

1. Identifiez la source de vérité vivante : checkout actuel, chemins montés, contrats, tests, runtime, données et état de déploiement.
2. Définissez une étape actuelle avec un résultat visible par l'utilisateur, des fichiers ou systèmes dans la portée, des exclusions explicites, des vérifications d'acceptation et des conditions d'arrêt.
3. Assignez les rôles :
   • Exécuteur : implémentez uniquement l'étape acceptée et retournez les preuves.
   • Réviseur : inspectez le dépôt vivant indépendamment, vérifiez les affirmations et émettez la décision de porte.
   • Utilisateur : approuvez les choix de produit et les actions à fort impact.
4. Gardez les étapes ultérieures comme en attente. N'autorisez pas leur implémentation simplement parce qu'elles apparaissent dans la feuille de route.

Lorsque l'exécuteur marque une pause sur un choix de produit ou d'architecture de l'information, traduisez les options en conséquences pour l'utilisateur avant de demander à l'utilisateur. Corrigez les fausses catégories avant l'implémentation — par exemple, une exception inter-étapes telle que « en retard » ne doit pas être modélisée comme une étape du cycle de vie simplement parce qu'elle apparaît à côté des filtres d'étape.

Protégez d'abord l'arbre de travail

Traitez un arbre de travail sale comme un état appartenant à l'utilisateur.

1. Inspectez git status --short, la branche/amont, git diff --stat, les diffs ciblés, les fichiers non suivis, les stashs, et les arbres de travail ou branches pertinents.
2. Classez les modifications existantes par fonctionnalité ou provenance avant d'éditer des fichiers qui se chevauchent.
3. N'exécutez pas de commandes Git destructrices, ne jetez pas les modifications, ne nettoyez pas les fichiers non suivis, ne supprimez pas les copies qui ressemblent à des conflits sans approbation explicite.
4. N'utilisez pas git add -A et ne créez pas de commit de référence en vrac jusqu'à ce que le manifeste des modifications soit examiné. Excluez les secrets, les bases de données locales/données de l'espace de travail, la sortie générée, les caches et les fichiers en double non résolus.
5. Si un commit de référence est utile, créez de petits commits cohérents uniquement après une validation ciblée et une autorisation de l'utilisateur. Une sauvegarde n'est pas une preuve que les modifications sont correctes.

Si une séparation sécurisée n'est pas claire, arrêtez-vous après avoir produit le rapport de classification de l'arbre de travail.

Préparez un paquet d'exécuteur

Donnez à l'exécuteur uniquement le contrat de l'étape actuelle. Incluez :

• l'objectif exact et le comportement visible par l'utilisateur ;
• les fichiers source de vérité et les faits actuels de la branche/arbre de travail ;
• les limites dans/non dans la portée ;
• les règles de vérité des données et de provenance ;
• les exigences de compatibilité pour les données anciennes ou manquantes ;
• les tests requis et les vérifications runtime/visuelles ;
• les actions interdites et les portes humaines ;
• le dossier de preuves requis et l'instruction de s'arrêter après l'étape.

Pour les étapes d'interface utilisateur, définissez les états de chargement, vide, erreur, données partielles et succès ; la localisation et le comportement responsive ; et les preuves exactes nécessaires pour l'approbation visuelle.

Exigez un dossier de preuves

L'exécuteur doit rapporter :

• l'objectif de l'étape et un résumé de l'implémentation ;
• les fichiers modifiés et git diff --stat ;
• les commandes exactes de test/construction/runtime avec les résultats succès/échec ;
• des captures d'écran ou des preuves DOM/runtime pour le travail visible ;
• des preuves représentatives de données réelles ou d'API lorsque le comportement des données a changé ;
• des vérifications de compatibilité pour les données existantes ;
• les hypothèses, les risques restants et tout ce qui n'a pas été vérifié ;
• le SHA du commit uniquement si le commit a été autorisé.

Rejetez des déclarations telles que « fait », « semble bon » ou « les tests passent » sans les commandes ou artefacts sous-jacents.

Examinez indépendamment

N'examinez pas uniquement l'explication de l'exécuteur.

1. Revérifiez le checkout vivant et identifiez le diff réel.
2. Lisez les chemins d'appel modifiés, les contrats, les schémas, les tests et les limites de données.
3. Réexécutez des vérifications ciblées proportionnées au risque.
4. Inspectez le comportement visible aux largeurs de bureau/mobile pertinentes pour le travail d'interface utilisateur.
5. Séparez les faits vérifiés, les inférences, les affirmations non testées et les échecs préexistants.
6. Vérifiez la dérive de portée, l'exposition de secrets, les données fabriquées, l'étiquetage erroné de données obsolètes, le nettoyage destructeur, les réécritures non liées, et le comportement de restauration/compatibilité manquant.

Le réviseur doit diagnostiquer et retourner des retours, ne pas devenir silencieusement un second implémenteur, sauf si l'utilisateur demande explicitement à Codex de corriger l'étape.

Émettez la décision de porte

Utilisez exactement une décision :

• PASS : toutes les vérifications d'acceptation bloquantes sont réussies ; l'étape suivante peut commencer.
• PASS AVEC SUIVI : seuls des éléments explicitement non bloquants subsistent ; enregistrez leur propriétaire et la porte ultérieure.
• MODIFICATIONS REQUISES : le contrat est valide mais l'implémentation ou les preuves sont incomplètes ; retournez une liste de corrections limitée et maintenez la même étape active.
• BLOQUÉ : une décision de produit manquante, un accès, une dépendance externe, une approbation de sécurité ou un bloc technique répété empêche la progression.

Pour tout résultat autre que PASS, fournissez une invite de correction prête à envoyer à l'exécuteur. N'élargissez pas l'étape pendant sa correction.

Après avoir émis la décision, écrivez-la dans la session de l'exécuteur afin que l'exécuteur et le réviseur partagent le même point de contrôle. Pour MODIFICATIONS REQUISES, continuez à superviser la boucle de correction. Pour PASS AVEC SUIVI, enregistrez le propriétaire, la date limite ou la porte ultérieure, et si le suivi bloque l'avancement.

Portes humaines

Arrêtez-vous pour une approbation explicite de l'utilisateur avant :

• les appels à des fournisseurs payants ou les dépenses ;
• les messages externes, la publication, le déploiement ou la configuration de production ;
• la suppression, l'écrasement, le nettoyage ou le déplacement en masse de données ;
• les modifications de compte, de permission, de facturation ou d'identifiants ;
• les commits, pushes, fusions ou pull requests larges non déjà autorisés ;
• l'extension d'une étape d'interface utilisateur/correction de bogue en une nouvelle plateforme de produit ou de données.

Achèvement

Déclarez le flux de travail global complet uniquement lorsque chaque étape requise a été réussie, le chemin utilisateur de bout en bout a été exercé, la compatibilité et les états d'échec ont été vérifiés, et les risques restants sont explicitement acceptés ou assignés.