caohaotiantian/three-loop-workflow

Workflow en Trois Boucles

Planifier → Construire → Clore, à une profondeur choisie en fonction des enjeux.

Assumez l'implémentation assignée : son plan, ses modifications, ses preuves, sa relecture et ses réparations. L'implémenteur peut être le parent ou un exécuteur assigné. Lorsqu'un coordinateur existe, laissez-lui l'allocation des tâches, les dépendances, les interfaces partagées et la propriété de l'intégration. Demandez les rôles ou changements de planification nécessaires à ce coordinateur. Ne coordonnez pas récursivement d'autres tâches. Acheminez les demandes de décision utilisateur via le coordinateur. Sans coordinateur, gérez le changement et les rôles requis directement. La profondeur d'implémentation et le mode d'exécution sont séparés. L'exécution directe ne supprime pas la relecture requise.

Contraintes strictes, les seules règles qui ne sont pas des valeurs par défaut :

1. Un changement au-dessus de Direct est relu par un contexte qui ne l'a pas écrit ; uniquement si aucun n'est disponible, la passation le mentionne (section 5).
2. Exécutez les vérifications du projet. Une vérification qui n'a pas pu être exécutée n'est pas une vérification réussie.
3. La passation rapporte ce qui a été observé, pas ce qui était prévu.
4. Un changement concernant qui peut accéder à quoi (authentification, autorisation, secrets, un nouveau chemin pour une entrée non fiable) n'est jamais Direct.
5. Une action extérieure au dépôt qui ne peut pas être annulée attend l'utilisateur : pousser vers une branche partagée, déployer, écrire des données réelles, envoyer quoi que ce soit.

Tout le reste est une valeur par défaut : ne la quittez que pour une raison énoncée. Le guide du projet prime sur toute valeur par défaut, et les moyens sont les vôtres.

Lisez le guide du projet (AGENTS.md, CLAUDE.md) pour ses commandes de vérification et les fichiers qu'il traite comme des contrats ; s'il n'en nomme aucun, déduisez-les du dépôt et dites ce que vous avez inféré. Les vérifications proviennent de la configuration de build et de l'IC ; les contrats sont ce qui est consommé en dehors de ce dépôt ou persistant : API publiques, schémas, ILC, formats filaires, données stockées.

Appliquez les règles de type de texte, de langue et visuelles de references/writing.md à cette tâche d'écriture.

1. Profondeur

Prenez la profondeur la plus légère qui convient.

• Direct : une petite modification évidente dont l'exactitude est visible ou couverte par une vérification existante. Un changement de comportement non trivial est Standard ou Profond, même avec des tests. Une correction de faute de frappe peut être Directe. Un changement de valeur par défaut ne le peut pas. Effectuez la modification et exécutez les vérifications. Aucun plan ni relecteur n'est requis. Rapportez le changement, les vérifications, les résultats et l'absence de relecture en une ligne.

• Standard : la valeur par défaut pour les changements de comportement.

• Profond : uniquement lorsqu'un déclencheur se produit :

  1. un changement cassant d'un contrat consommé en dehors de ce dépôt ;
  2. un effet irréversible en dehors du dépôt : une migration de données persistantes, de l'argent, tout ce qui est envoyé à un tiers ;
  3. une règle modifiée dans un fichier que le projet traite comme un contrat ;
  4. des alternatives qui engagent à des structures différentes.

  Lisez alors references/deep.md.

Un coin risqué élève sa propre profondeur, jamais la profondeur de l'ensemble du changement. Élevez vous-même la profondeur, y compris lorsque la build révèle un déclencheur ; seul l'utilisateur la réduit. Avant de la réduire, recommandez votre profondeur. Pour quelqu'un de nouveau dans ce workflow, montrez ce que ce changement sauterait et l'échec laissé ouvert. S'ils insistent, suivez-les sans enfreindre une contrainte stricte.

2. Planifier

À Standard et Profond, avant la première modification, écrivez le But, les Non-buts auxquels vous avez été tenté, et Accepter, la preuve (section 4).

Adaptez le plan et la relecture au changement.

Ajoutez Décisions uniquement aux véritables bifurcations : les options, y compris la plus petite, et pourquoi la gagnante a gagné.

Écrivez-le dans .agent/<tache>/plan.md, un répertoire par tâche, et validez les fichiers avec le changement, sauf si le projet a sa propre convention. Si .agent est dans .gitignore, laissez cette entrée et n'ajoutez pas les fichiers de force.

Pour un travail assigné, utilisez le chemin de plan fourni et référencez la portée partagée et les critères d'acceptation. Conservez les détails d'implémentation là-bas. Laissez les enregistrements globaux de tâches au coordinateur. Préservez les répertoires de tâches canoniques existants. Pour les plans délégués, par défaut .agent/<tache>/tasks/<id-tranche>/plan.md.

Lorsque deux lectures de la demande nécessitent un travail différent, énoncez la vôtre dans le But, montrez-la ainsi que Accepter à l'utilisateur, et attendez ; si personne ne peut répondre, poursuivez sur votre lecture et marquez-la comme non confirmée dans la passation. Posez des questions sur les décisions réelles de produit, de portée ou de risque avec des options, une recommandation et une justification, ne décidez jamais en silence ; enregistrez la réponse dans le plan.

Lorsque la cause d'un défaut est inconnue, la trouver est la tâche : son Accepter est une reproduction ; planifiez la correction après.

3. Construire

• Chaque ligne modifiée découle du But ou d'une Décision. Pas d'abstraction, de configurabilité ou de gestion d'erreur dont personne n'a besoin.
• Si le code, ou une correction, contredit le plan, arrêtez-vous et corrigez le plan ouvertement, pas à la fin.
• Restez dans les fichiers et interfaces assignés. Si ceux-ci nécessitent des modifications, mettez en pause le travail affecté et demandez une réassignation révisée.
• Lecture parallèle, écriture isolée. Utilisez une arborescence de travail séparée pour chaque rédacteur simultané (references/parallel.md).
• Pour le travail d'intégration, exécutez les vérifications et la relecture sur le changement fusionné. La réussite des vérifications de tranche n'établit pas l'acceptation intégrée.
• Lorsqu'un document cite un chiffre qu'une commande produit, citez la commande à côté du chiffre, ou ayez une vérification qui le recalcule.

Pour un travail durable, stockez les résultats des vérifications dans evidence/checks.md à côté du plan. Enregistrez les critères, commandes, révisions, résultats, liens de preuve et conditions d'invalidation. Stockez les constatations, le triage, l'identité du relecteur et les cycles de réparation dans evidence/review.md.

4. Preuve

• Accepter nomme la preuve réelle la moins coûteuse qui échouerait sans le changement : une vérification existante qui devient verte, un nouveau test, ou le résultat observé. Dites à quoi ressemble l'échec.
• Aucun nouveau test unitaire n'est requis par défaut. Écrivez-en un lorsque le comportement est une logique qu'un test épingle à moindre coût et qu'une régression mérite d'être protégée. C'est la mauvaise vérification pour le rendu et la disposition d'interface utilisateur, le câblage et la colle, la configuration, les appels minces à des services externes, les scripts ponctuels et la prose : observez plutôt le résultat.
• Là où une personne clique, tape ou appelle, un contexte qui n'a pas écrit le changement le pilote et rapporte ce qu'il a vu. Donnez-lui le chemin et l'échec, pas le diff ni votre compte rendu. Une contradiction est une constatation. Aucun contexte de ce type : pilotez-le vous-même et collez ce que vous avez vu. Pilotez une surface interdite quelque part de sûr et nommez l'écart. Non piloté signifie non vérifié.
• Là où la sortie est lue plutôt qu'exécutée (documents, texte d'aide, une spécification), la preuve est une lecture à froid des fichiers finis par un lecteur sans le contexte du changement : lisez-le comme un produit, pas comme un diff.
• Un échec intermittent est lui-même une reproduction et la preuve discriminante. Ne réexécutez pas l'échec de ce changement jusqu'à ce qu'il réussisse, et n'exigez pas une reproduction déterministe avant de le traiter comme tel. Un échec que ce changement n'a pas causé est un suivi nommé, non corrigé dans ce changement.
• Exécutez les vérifications avant la relecture, celles couvrant le changement après chaque correction, et l'ensemble complet une fois avant la passation. Collez les lignes de réussite/échec, pas les journaux entiers. Tout ce qui est sauté, ou rendu vert en affaiblissant un test, n'est pas une réussite.

5. Relecture

Le relecteur reçoit l'intégralité du changement (ou, pour un changement construit par phases, la phase entière), le plan et le dépôt, pas votre résumé ni votre raisonnement. Intégralité signifie chaque fichier que le changement ajoute, modifie ou supprime, y compris les nouveaux fichiers non suivis ; une relecture d'un diff vide ou incomplet n'est pas une relecture propre. Direct n'a pas besoin de relecteur ; Standard en a un.

Relectures ou lectures indépendantes indisponibles : utilisez d'abord les contextes indépendants disponibles. Pour les rôles manquants, inspectez les artefacts complets spécifiés ci-dessus, pas votre souvenir du travail. Appliquez les consignes des rôles manquants en un seul passage d'auto-relecture. Étiquetez-le « auto-relecture, non indépendante » et rapportez les rôles indépendants manquants. Proposez à l'utilisateur les consignes pour les exécuter ailleurs. Ce repli ne remplace pas les exigences plus strictes de l'utilisateur, du projet ou de l'hôte.

Transmettez cette consigne textuellement :

Relisez ce changement par rapport à son plan. Signalez toute constatation avec fichier:ligne,
marquée bloquante (mauvais comportement, contrat cassé, travail en dehors du plan)
ou non bloquante. Ne modifiez pas le code.
1. Où cela casse-t-il ? Entrée inattendue, entrée hostile là où elle touche
   la confiance, échecs de ce qu'il appelle, faits supposés en dehors du diff.
2. Les tests existants ont-ils été affaiblis ?
3. Le nouveau comportement est-il démontré par une preuve, un test ou un résultat
   observé, qui échoue sans le changement ? Ne demandez rien de plus.
4. Y a-t-il quelque chose en dehors du But ou dans un Non-but ?
5. Le plan lui-même est-il erroné ?

Triage avant de corriger. Confirmez chaque constatation par rapport au code cité. Rejetez les mauvaises lectures, et les constatations demandant un travail qu'un Non-but exclut, une ligne chacune. Un test manquant est non bloquant sauf s'il protège un bogue d'exactitude confirmé. Le changement se clôt lorsqu'aucune constatation bloquante confirmée ne subsiste.

Relire le changement de quelqu'un d'autre : la même consigne, avec sa description comme plan ; les Non-buts manquants sont une constatation. Triagez, puis transmettez les constatations confirmées à l'auteur ; ne les corrigez pas.

6. Corriger et s'arrêter

• Une correction répare ce qu'une constatation confirmée cite, à sa cause racine, partout où le même défaut se produit.
• Un nouveau mécanisme est un nouveau travail : une nouvelle vérification, harnais, garde, abstraction ou fichier de test devient un suivi nommé, ne fait pas partie de la correction. Ajoutez un test échouant uniquement pour un bogue d'exactitude confirmé, et étendez un fichier de test existant.
• Après chaque correction, le relecteur ne revérifie que la correction : les constatations citées sont-elles résolues, et la correction a-t-elle introduit quelque chose ? Une correction plus sa revérification constitue un cycle.

Arrêtez-vous et demandez à l'utilisateur lorsqu'un cycle laisse les constatations confirmées inchangées, qu'une correction s'étend dans des fichiers ou mécanismes que le plan ne couvrait pas, ou que des constatations bloquantes subsistent après le troisième cycle. Apportez les constatations non résolues textuellement, ce qui a été essayé, où cela casse avec une sortie réelle, les options (réviser le plan, accepter un risque documenté, abandonner l'élément comme suivi, extraire le mécanisme) et votre recommandation. N'abaissez jamais la barre en silence.

7. Clore : la passation

La passation est la description finale du changement. Le HANDOFF.md d'un coordinateur fournit plutôt des instructions de reprise. Appliquez les règles de lectures sélectives et de cycle de vie des enregistrements dans references/writing.md. Avec un coordinateur, retournez les candidats de mémoire sourcée et laissez les mises à jour partagées avec lui.

À Standard et Profond, la description du changement comporte :

• le But, comme ce qu'un utilisateur peut maintenant faire, et les Non-buts ;
• Accepter, et ce que la preuve a réellement montré ;
• ce qui n'a pas pu être vérifié, et pourquoi ;
• qui l'a relu, ou « auto-relecture, non indépendante », ou qu'aucune relecture n'a eu lieu, et de même pour un chemin piloté par une personne ;
• une profondeur que l'utilisateur a réduite, et ce que vous lui avez montré avant qu'il n'insiste ;
• les constatations non bloquantes non corrigées, une ligne chacune ;
• le risque résiduel ;
• à Profond, le rollback tel qu'il se présente maintenant.

Pour un travail assigné, retournez les chemins et révisions des artefacts, les preuves, l'état de la relecture, les demandes non résolues, et les commandes de modification actives ou inconnues. Signalez l'achèvement local au coordinateur. Ne revendiquez pas l'achèvement de la tâche globale.

Les outils de relecture, sécurité ou d'orchestration que l'utilisateur ajoute complètent la relecture indépendante, ne la remplacent jamais.