DenisSergeevitch/repo-task-proof-loop

Boucle de Preuve de Tâche de Dépôt

Utilisez cette compétence lorsque l'utilisateur souhaite un workflow d'implémentation reproductible et auditable pour une tâche de codage non triviale, en particulier une fonctionnalité, une refonte, une migration ou une correction de bogue qui doit laisser une preuve locale au dépôt dans .agent/tasks/<TASK_ID>/.

Tous les artefacts de tâche créés par ce workflow doivent rester à l'intérieur du dépôt.

Lorsque les exemples ci-dessous mentionnent scripts/task_loop.py, ce chemin est relatif à la racine de cette compétence. Exécutez-le pendant que votre répertoire de travail shell se trouve à l'intérieur du dépôt cible.

Ce que fait cette compétence

1. Initialise un dossier de tâche strictement local au dépôt sous .agent/tasks/<TASK_ID>/
2. Génère ou met à jour les fichiers d'artefact requis
3. Installe les modèles de sous-agents Codex et Claude à l'échelle du projet dans .codex/agents/ et .claude/agents/
4. Met à jour le fichier de base AGENTS.md de Codex à la racine du dépôt ainsi que le fichier de guide Claude du dépôt (CLAUDE.md ou .claude/CLAUDE.md) avec un bloc géré qui explique le workflow
5. Guide l'agent à travers une boucle stricte :
   • gel des spécifications
   • implémentation du constructeur
   • conditionnement des preuves
   • vérification fraîche
   • correction minimale
   • nouvelle vérification fraîche jusqu'à PASS

Voir :

• references/REFERENCE.md
• references/COMMANDS.md
• references/SUBAGENTS.md
• references/SCHEMAS.md

Commandes prises en charge par cette compétence

Traitez les mots suivants comme des commandes lorsque l'utilisateur invoque cette compétence :

• init <TASK_ID> : créer .agent/tasks/<TASK_ID>/, installer ou actualiser les modèles de sous-agents, et mettre à jour AGENTS.md ainsi que le fichier de guide Claude du dépôt
• freeze <TASK_ID> : créer ou affiner spec.md à partir de la tâche utilisateur, du fichier de tâche et des directives du dépôt
• build <TASK_ID> : implémenter la tâche par rapport aux spécifications gelées
• evidence <TASK_ID> : créer ou actualiser evidence.md, evidence.json et les artefacts bruts sans modifier le code de production
• verify <TASK_ID> : exécuter un passage de vérificateur frais et écrire verdict.json, plus problems.md si nécessaire
• fix <TASK_ID> : appliquer le plus petit ensemble de corrections sûr à partir de problems.md, puis actualiser le lot de preuves
• run <TASK_ID> : exécuter la boucle complète du gel des spécifications à la vérification
• status <TASK_ID> : résumer l'état actuel des artefacts

Si l'utilisateur ne fournit pas de commande, déduire l'étape suivante de l'état du dépôt :

• Si le dossier de tâche n'existe pas, exécuter init en premier. Si l'utilisateur veut clairement uniquement l'initialisation, s'arrêter là. Sinon, après que init a réussi et que .agent/tasks/<TASK_ID>/spec.md existe, continuer en réévaluant l'état du dépôt dans le même tour. Ne pas superposer init avec freeze, build, evidence, verify, fix, validate, status ou le travail de sous-agent.
• Si spec.md est manquant ou contient uniquement un espace réservé, faire freeze
• Si l'implémentation n'est pas encore terminée, faire build
• Si la preuve est obsolète ou manquante, faire evidence
• Si aucun verdict frais n'existe, faire verify
• Si le verdict n'est pas PASS, faire fix

Étape d'initialisation

Exécutez l'initialiseur inclus depuis la racine du dépôt ou le répertoire de travail actuel à l'intérieur du dépôt :

scripts/task_loop.py init --task-id <TASK_ID>

Initialisation optionnelle de la tâche :

scripts/task_loop.py init --task-id <TASK_ID> --task-file chemin/vers/tache.md
scripts/task_loop.py init --task-id <TASK_ID> --task-text "Texte de la tâche utilisateur"

L'initialiseur va :

• résoudre la racine du dépôt
• créer .agent/tasks/<TASK_ID>/
• créer tous les artefacts requis, y compris les espaces réservés sous raw/
• installer les fichiers de sous-agents à l'échelle du projet
• insérer ou actualiser les blocs de workflow gérés dans AGENTS.md et le fichier de guide Claude du dépôt

Pour Codex, l'initialiseur conserve son bloc de workflow géré dans AGENTS.md à la racine du dépôt. Codex prend également en charge AGENTS.override.md et les noms de fichiers de guide de secours configurés ; les fichiers imbriqués plus proches du code ont toujours priorité, et cette compétence ne les écrase pas intentionnellement. Si init crée ou réécrit AGENTS.md pendant une session Codex en cours, démarrez une nouvelle session Codex avant de vous fier aux instructions mises à jour. Codex capture les directives du guide de projet au début de la session.

Pour Claude Code, l'initialiseur conserve son bloc de workflow géré dans CLAUDE.md à la racine du dépôt. Claude Code prend également en charge .claude/CLAUDE.md, .claude/rules/*.md et CLAUDE.local.md, mais cette compétence traite CLAUDE.md à la racine comme le guide de projet principal car Claude le présente directement.

Dans Claude Code, si init vient d'écrire ou d'actualiser .claude/agents/* pendant la session en cours, ne supposez pas que ces agents mis à jour sont déjà disponibles en milieu de session.

Traitez init comme un prérequis en série. Ne le superposez jamais avec freeze, build, evidence, verify, fix, validate, status ou le lancement d'agents enfants.

Workflow par défaut pour les tâches lourdes

Pour les tâches volumineuses, gardez la demande de l'utilisateur simple. Dans Codex, continuez en série sauf si l'utilisateur demande explicitement la délégation ou un travail parallèle d'agent ; après cette autorisation, la compétence peut choisir la configuration interne enfant automatiquement lorsque la surface produit actuelle prend en charge la délégation et que la forme de la tâche le justifie.

Séquence déléguée préférée

1. Exécutez init <TASK_ID> si nécessaire. Attendez qu'il se termine, puis confirmez que .agent/tasks/<TASK_ID>/spec.md et la structure de tâche locale au dépôt existent avant de continuer.
2. Uniquement après que init est terminé, lancez exactement un sous-agent de gel des spécifications et attendez-le
3. Lancez exactement un sous-agent constructeur et laissez-le implémenter
4. Continuez avec la même session de constructeur pour le conditionnement des preuves
5. Lancez exactement un sous-agent de vérification fraîche et attendez-le
6. Si le verdict n'est pas PASS, lancez exactement un sous-agent correcteur
7. Lancez à nouveau un sous-agent de vérification fraîche
8. Répétez les étapes 6 à 7 jusqu'à ce que le vérificateur retourne PASS ou que l'utilisateur arrête la boucle

Déploiement adaptatif Codex

Utilisez ceci uniquement après que l'utilisateur a explicitement autorisé la délégation Codex et que la tâche est suffisamment large pour bénéficier d'un travail parallèle limité. Utilisez la séquence en série plus simple ci-dessus pour les tâches étroites.

Bonnes correspondances :

• plusieurs questions de base de code indépendantes doivent être répondues avant que les spécifications soient stables
• l'implémentation peut être divisée en portées d'écriture disjointes
• la preuve nécessite plusieurs vérifications en lecture seule indépendantes sur différentes surfaces

Modèle Codex :

1. init reste en série.
2. Si la tâche est encore ambiguë, déployez jusqu'à 3 enfants explorer intégrés en parallèle. Donnez à chacun une seule question, sous-système ou portée de chemin. Attendez-les, puis gelez les spécifications.
3. Lancez un enfant de gel des spécifications et attendez-le.
4. Lancez un enfant task-builder comme propriétaire de l'intégration.
5. Si l'implémentation se divise proprement, le parent peut également lancer un nombre limité d'enfants worker intégrés en parallèle. Chaque travailleur doit avoir une propriété explicite de fichier ou de module et ne doit pas écrire evidence.md, evidence.json, verdict.json ou problems.md.
6. Utilisez send_input ou la surface de suivi équivalente pour garder le constructeur d'intégration actif pour le conditionnement des preuves. Le constructeur reste le seul propriétaire du lot de preuves.
7. Si une preuve supplémentaire est nécessaire, le parent peut déployer un petit ensemble limité d'enfants explorer en lecture seule pour réexécuter des vérifications disjointes ou inspecter des lacunes de preuve séparées en parallèle. Ces enfants peuvent rapporter des commandes, des sorties et des résultats, mais ils n'écrivent pas verdict.json.
8. Exécutez exactement un enfant de vérification fraîche pour chaque passage de vérification.

Comportement de la plateforme

• Dans Codex, gardez le chemin normal en série et en mode automatique en premier après init. Évitez de révéler les détails de délégation sauf s'ils affectent matériellement le travail.
• Dans Codex, lancez des sous-agents limités uniquement lorsque l'utilisateur demande explicitement des sous-agents, une délégation ou un travail d'agent parallèle.
• Dans Codex, une fois la délégation autorisée, la compétence peut choisir les rôles enfants correspondants et s'il faut rester à un enfant à la fois ou utiliser un déploiement limité. L'utilisateur n'a pas besoin de nommer des rôles enfants spécifiques ou des commandes slash.
• Dans Codex, le lancement d'enfants reste une action explicite de l'orchestrateur parent. Si la surface Codex actuelle bloque la délégation, dites-le brièvement uniquement lorsqu'elle affecte matériellement le travail, puis continuez en série.
• Dans Codex, gardez l'arbre de tâches peu profond. La session parent doit lancer les enfants de recherche, constructeur, correcteur et vérificateur directement au lieu de demander à un enfant de tâche personnalisé d'orchestrer davantage d'enfants.
• Dans Codex, une fois la délégation autorisée, choisissez entre la délégation à un enfant à la fois et le déploiement limité à partir des spécifications gelées, de la forme du dépôt et de la surface de délégation actuelle. Gardez init, la propriété des preuves et chaque passage de vérificateur sérialisés dans les deux cas.
• Dans Codex, gardez le déploiement d'aide modeste et basé sur des vagues. Préférez jusqu'à 3 enfants d'aide parallèles à la fois, attendez que cette vague se termine, puis décidez de la phase suivante.
• Dans Codex, explorer intégré est le premier choix pour la découverte de dépôt en lecture seule et les sondes de preuve. worker intégré est approprié pour une implémentation disjointe limitée ou des réexécutions de vérification lorsque vous pouvez attribuer une propriété explicite.
• Dans Codex, réutilisez l'enfant constructeur actif pour le conditionnement des preuves en lui envoyant une instruction de suivi. Les passages de vérificateur doivent utiliser un enfant frais ou une session fraîche ; ne satisfaites pas la fraîcheur du vérificateur en reprenant un vérificateur antérieur. Les enfants constructeur et correcteur peuvent être réutilisés ou repris lorsque vous voulez intentionnellement ce contexte de retour.
• Dans Codex, inspectez la liste actuelle des threads enfants avant de réutiliser ou reprendre un enfant. Utilisez /agent dans Codex CLI ou toute surface d'inventaire de threads enfants équivalente disponible dans la surface produit Codex actuelle.
• Dans Codex, l'interface utilisateur de la liste de plan/todo de update_plan est une directive de session facultative uniquement. Elle est utile pour l'affichage de progression en direct, mais ce n'est pas la source de vérité pour ce workflow.
• Dans Claude Code, la compétence doit décider si elle reste sur le thread principal ou laisse la session principale Claude auto-déléguer la phase actuelle à un sous-agent intégré ou de projet correspondant après init. L'utilisateur n'a pas besoin de demander un sous-agent Claude spécifique ou un mode de délégation séparément.
• Dans Claude Code, TodoWrite ou l'interface utilisateur visible de tâche/todo est un affichage de progression facultatif limité à la session uniquement. Cela peut aider au suivi en direct dans la session actuelle, mais ce n'est pas la source de vérité pour ce workflow.
• Dans Claude Code, préférez les sous-agents de projet installés depuis .claude/agents/, avec des descriptions écrites comme conditions de déclenchement proactives pour la phase correspondante de la boucle de preuve. La session principale de Claude achemine par la demande de tâche, les descriptions des sous-agents et le contexte actuel, donc gardez chaque invite de phase claire en langage naturel. Réutilisez le même enfant constructeur pour l'étape de preuve par défaut. Ne lancez un nouveau constructeur en mode preuve uniquement que si la session du constructeur d'origine est indisponible ou que vous l'avez intentionnellement rejetée. Si init vient d'actualiser .claude/agents/* pendant la session Claude actuelle, revenez au thread principal ou aux agents déjà visibles au lieu de supposer que les agents actualisés sont immédiatement disponibles.
• Dans Claude Code, gardez l'orchestration plate : l'auto-délégation de la session principale est acceptable, mais les agents de workflow de la boucle de preuve sont eux-mêmes des rôles feuilles. La session parent doit posséder les transitions de phase de la boucle de preuve au lieu de demander à un agent de tâche personnalisé d'en lancer un autre.
• Dans Claude Code, l'état durable canonique est toujours l'ensemble d'artefacts local au dépôt sous .agent/tasks/<TASK_ID>/, en particulier spec.md, evidence.md, evidence.json, verdict.json et problems.md.
• Si les sous-agents sont indisponibles, préservez la même séparation de rôles à travers des sessions séparées ou des changements de mode clairs dans la session actuelle.

Utilisez les invites de rôle exactes à partir de references/COMMANDS.md.

Exigences de gel des spécifications

spec.md doit contenir au moins :

• la déclaration de tâche d'origine
• des critères d'acceptation explicites étiquetés AC1, AC2, ...
• des contraintes
• des non-objectifs

Il peut également inclure :

• des sources de directives du dépôt
• un plan de vérification
• des hypothèses résolues de manière étroite à partir de la demande de l'utilisateur

Ne modifiez pas le code de production pendant le gel des spécifications.

Exigences de conditionnement des preuves

evidence.md et evidence.json doivent juger chaque critère d'acceptation indépendamment avec l'un des :

• PASS
• FAIL
• UNKNOWN

Le conditionnement des preuves peut exécuter des vérifications manquantes, mais il ne doit pas continuer à modifier le code de production.

Chaque PASS doit citer une preuve concrète telle que :

• des chemins de fichiers
• des commandes exécutées
• des codes de sortie
• des résumés de sortie
• des chemins d'artefacts sous raw/

Ne revendiquez pas un PASS global dans le lot de preuves sauf si chaque critère d'acceptation est PASS.

Exigences de vérification fraîche

Le vérificateur doit être une session fraîche ou un sous-agent frais. Dans Codex, ne satisfaites pas cette exigence en reprenant un enfant vérificateur antérieur.

Le vérificateur doit juger l'état actuel du dépôt et les résultats de réexécution actuels, pas le récit du constructeur.

Le vérificateur écrit :

• .agent/tasks/<TASK_ID>/verdict.json
• .agent/tasks/<TASK_ID>/problems.md uniquement lorsque le verdict global n'est pas PASS

problems.md doit inclure, pour chaque critère non PASS :

• identifiant et texte du critère
• statut
• pourquoi il n'est pas prouvé
• étapes de reproduction minimales
• attendu vs réel
• fichiers affectés
• correction la plus petite et sûre
• indice correctif en 1 à 3 phrases

Le vérificateur ne doit pas modifier le code de production ni remplir rétroactivement le lot de preuves.

Exigences du correcteur

Le correcteur lit uniquement :

• spec.md
• verdict.json
• problems.md

Le correcteur doit :

• reconfirmer chaque problème listé dans la base de code avant de modifier
• effectuer le plus petit ensemble de changements sûr
• éviter de régresser les critères déjà réussis
• régénérer evidence.md, evidence.json et les artefacts bruts
• s'arrêter sans écrire de validation finale

Validation

Avant de prétendre que le workflow est correctement initialisé ou que l'ensemble d'artefacts est complet, exécutez :

scripts/task_loop.py validate --task-id <TASK_ID>

Exécutez validate uniquement après que init a complètement terminé. S'il signale une initialisation en cours, attendez et réexécutez-le au lieu de traiter ce résultat comme un échec de tâche stable.

Pour un résumé rapide :

scripts/task_loop.py status --task-id <TASK_ID>

Exécutez status uniquement après que init a complètement terminé lorsque vous avez besoin d'un état de tâche stable. S'il signale init_in_progress: true, traitez cela comme une condition de réessayer plus tard.

Garde-fous

• Gardez .agent/tasks/<TASK_ID>/ à l'intérieur du dépôt
• Traitez l'interface utilisateur todo/checklist de Codex comme une progression éphémère uniquement ; l'état durable est l'ensemble d'artefacts
• ... (tronqué pour la traduction)