Comment dire à un agent IA ce que « terminé » veut dire ?

Écrivez ce que « terminé » veut dire sur la tâche elle-même, sous forme de liste markdown, avant que l'agent ne commence. Dans Done, c'est le champ acceptance_criteria de la tâche : une ligne par condition vérifiable, écrite « - [ ] les tests passent sur la pointe de la branche ». L'agent la lit d'abord, coche chaque ligne avec check_criterion quand il la satisfait réellement, puis demande la clôture. Tout cocher ne ferme pas la tâche : un humain approuve encore.

Pourquoi une bonne description de tâche ne suffit-elle pas ?

Une description dit à l'agent quoi faire. Elle ne dit pas à quoi ressemble un résultat fini, donc l'agent en décide seul, et un agent laissé à lui-même s'arrête souvent à la première sortie plausible. Les critères d'acceptation sont l'autre moitié : la barre vérifiable à laquelle le résultat est jugé, pas des instructions de plus. Les descriptions d'outils de Done tracent cette ligne et demandent à l'agent de confronter son travail à cette barre avant de proposer la clôture.

À quoi ressemble un critère exploitable par un agent ?

• Vérifiable par quelqu'un d'autre : « les tests passent sur la pointe de la branche », « la page charge en moins de 200 ms », « le résumé liste toutes les factures en retard ». « Ça a l'air bien » n'est pas une condition.
• Une ligne par condition, pour pouvoir les cocher une à une et qu'une tâche à moitié faite se lise 2/4 plutôt que rien.
• Écrivez-le en liste de cases markdown, lignes commençant par « - [ ] ». Une liste à puces ordinaire ou un paragraphe est bien enregistré, mais c'est de la prose pour Done : la tâche ne signale aucun critère et l'agent n'a rien à cocher.
• Mettez le comment dans notes_for_agent ou la description, et gardez le quoi dans les critères. Les mélanger fait bouger la barre avec les instructions.

Comment l'agent rend-il compte de sa progression sur les critères ?

Il appelle get_task, qui renvoie les critères avec met, total et l'index (à partir de zéro) de chaque élément, puis check_criterion avec l'id de la tâche et cet index à mesure qu'il satisfait chaque ligne. done:false décoche une ligne, et cocher une case déjà cochée ne change rien. Chaque changement réel laisse une ligne dans l'historique de la tâche, du genre « met 'tests pass' (2/4 criteria met) », si bien que vous voyez l'avancement sans commentaire en continu dans le fil. On ne peut cocher que sur les tâches de la voie de l'agent.

Cocher tous les critères termine-t-il la tâche ?

Non, et c'est voulu. check_criterion est un rapport d'avancement ; la réponse indique seulement à l'agent que tous les critères sont remplis et qu'il peut proposer la clôture. Fermer est un autre acte. Une tâche qui n'est pas agent_ok passe en pending_approval via propose_completion et attend votre décision ; seule une tâche agent_ok permet à l'agent d'appeler lui-même complete_task. La liste rend l'affirmation de l'agent plus facile à vérifier, et la porte d'approbation l'empêche d'être définitive.

L'agent peut-il réécrire ses propres critères ?

Il peut modifier le champ avec update_task, ce qui est précisément la raison de ne pas se fier à une liste entièrement cochée. Sur la tâche d'un humain, il peut plutôt utiliser propose_edit, qui vous montre le changement en diff actuel contre proposé que vous acceptez ou écartez champ par champ. À la relecture, get_evidence renvoie la progression des critères avec chaque reçu, livrable et trace d'exécution, plus l'historique des modifications et agent_edits_since_human, le nombre de modifications de l'agent depuis le dernier passage d'une personne. S'il n'est pas à zéro, relisez les critères avant de croire les cases cochées : des critères réécrits après le début du travail ne sont pas la barre convenue.