[🤖] Je ne faisais pas confiance au coordinateur, alors j’ai surveillé chaque session

✨ Résumé de GPT-5.6 Sol

En répartissant une brochure entre plusieurs sessions Codex, j’ai craint que les rapports n’ensevelissent encore le contexte. J’ai modifié le flux pour que mon intervention directe n’efface ni les instructions ni la propriété du travail.

Je me suis inquiété dès que j’ai donné l’ordre

Aujourd’hui, on m’a confié au travail la création d’une brochure. Comme je n’en avais jamais réalisé, je me suis dit qu’un coordinateur capable de lire les documents concernés, de répartir les tâches et de coordonner plusieurs sessions Codex serait utile. Je voulais lui faire lire toutes les conversations du projet en cours afin qu’il indique à chaque session ce qu’elle devait faire.

Mais je me suis inquiété dès que j’ai donné l’ordre.

Et s’il se contentait encore de recevoir des rapports, perdait le contexte et finissait par raconter n’importe quoi ?

Cette inquiétude n’était pas une méfiance vague. J’avais déjà séparé coordinateur et workers, puis vu les rapports submerger la conversation du coordinateur. C’est ce qui m’avait conduit à reconstruire le Skill custom-coordinate-parallel-workers autour de rapports stockés dans des fichiers et de checkpoints. J’avais également testé l’outil d’état local, mais je n’avais pas mené l’ensemble du workflow jusqu’au bout avec plusieurs vraies sessions Codex.

Cette fois, j’avais une tâche réelle : la brochure. Pourtant, au moment de confier de nouveau ce rôle au coordinateur, j’ai compris qu’une accumulation propre de rapports dans des fichiers ne résolvait pas tout. Pendant que le coordinateur lit les rapports et distribue le travail, je ne suis pas du genre à rester assis à observer. Je vais continuer à ouvrir les différentes sessions, corriger immédiatement une mauvaise direction, fournir des documents supplémentaires et modifier les priorités.

Pour fonctionner correctement, le coordinateur devait conserver son état de coordination même lorsque j’intervenais directement dans d’autres sessions.

Je devais pouvoir parler directement dans ces sessions

La première version mise à jour du Skill ressemblait encore à une structure dans laquelle je donnais mes ordres au coordinateur avant d’observer les autres sessions exécuter ses instructions. Je l’ai aussitôt répété.

Il faut aussi que je puisse donner toutes sortes d’ordres dans ces sessions.

Je ne voulais pas d’une structure dans laquelle le coordinateur monopolisait tout pouvoir d’instruction. Il lui suffit de gérer l’objectif global, la propriété du travail, les dépendances et l’ordre d’intégration. Mais la personne qui regarde le résultat concret dans chaque session de travail et prend les décisions reste moi. Si je demande à un worker de corriger une formulation ou de changer le résultat dans le périmètre courant, il doit l’appliquer immédiatement. À l’inverse, si cette instruction touche les fichiers d’une autre session, un contrat partagé, un déploiement ou un état externe, il ne doit pas élargir silencieusement son périmètre. Il doit préserver le résultat demandé et s’arrêter pour permettre au coordinateur de réorganiser le travail.

C’est selon ce principe que j’ai ordonné une nouvelle modification de custom-coordinate-parallel-workers. Même après la fin d’une tâche, une instruction supplémentaire de ma part ne pouvait plus être écrasée dans un résumé de 256 caractères. Le résultat voulu, les éléments à préserver, les fichiers concernés, les effets externes et la session d’origine de l’instruction devaient être enregistrés séparément. Même si le coordinateur perdait la mémoire de la conversation, il devait pouvoir retrouver mon instruction dans les fichiers.

J’ai également empêché le coordinateur de fermer une demande de modification en écrivant seulement qu’elle était « acceptée ». Une demande ne peut être considérée comme terminée tant qu’elle n’est pas reliée à un nouveau rapport contenant la véritable modification ou à une nouvelle assignment. Comme une simple liaison ne garantit pas non plus que le contenu soit correct, j’ai conservé une étape obligeant le coordinateur à comparer le résultat demandé et les conditions de préservation avec le diff réel.

L’important n’était pas l’augmentation du nombre de fichiers d’état. Il s’agissait d’empêcher mon instruction de disparaître lorsque je parlais directement à n’importe quelle session, sans pour autant lui permettre de briser silencieusement la propriété globale.

Les fusionner ne faisait que brouiller leurs rôles

Pendant la modification, je me suis aussi demandé si custom-coordinate-parallel-workers ne jouait pas en pratique le même rôle que le Graph Engineering Gate Skill créé la veille. Son nom était alors custom-graph-engineering-gate. Les deux géraient plusieurs sessions et des états de review, alors les fusionner semblait plausible.

Cette fois, je ne les ai pas fusionnés immédiatement. J’ai utilisé custom-deliberate pour soumettre cette idée à une critique approfondie. La conclusion fut de les séparer.

custom-coordinate-parallel-workers relève du contrôle d’exécution : il gère la propriété des fichiers entre sessions de travail, les instructions de l’utilisateur, les rapports, le Git index, l’ordre d’intégration et les effets externes. Le Skill d’audit, lui, inspecte dans une session séparée et privée du contexte antérieur un résultat déjà intégré et gelé. Lorsque le coordinateur examine les rapports, il décide si le travail peut être intégré. Il s’agit d’une review d’intégration, pas du jugement d’un auditeur indépendant.

Les fusionner pouvait attacher automatiquement une session d’audit à chaque travail parallèle. Cela pouvait aussi faire passer une review ordinaire du coordinateur pour un audit indépendant. J’ai donc gardé les deux Skills séparés et rendu explicite uniquement leur frontière. Une session d’audit indépendante ne doit s’ouvrir que lorsqu’un résultat en a réellement besoin, après que le coordinateur a gelé ce résultat.

J’ai décidé de ne pas confondre une structure plus grande avec une structure plus sûre. Les rôles nécessaires doivent être reliés, mais pas fusionnés sous prétexte qu’ils seraient identiques.

Je ne me suis pas contenté d’énoncer des principes. J’ai rédigé et donné à la session du coordinateur une longue instruction de transition exigeant qu’elle reconstruise d’abord l’état des fichiers actuels et des sessions existantes, qu’elle classe les conflits, puis seulement qu’elle émette des assignments. J’y ai réuni toutes les exigences : ne pas supprimer négligemment les modifications existantes, préserver les instructions données directement par l’utilisateur dans chaque session, limiter chaque worker à ses propres paths et réserver l’intégration ainsi que le travail Git au coordinateur.

Le texte original contenait des détails permettant d’identifier le travail et les documents réels, je ne l’ai donc pas publié tel quel. Je joins seulement une copie publique où le nom de l’entreprise, le domaine d’activité, les noms des clients et des dossiers de référence, les services précis et les paths locaux personnels ont été remplacés par des formulations génériques.

Voir l’instruction publique et expurgée de transition du coordinateur

Le vrai travail sur la brochure décidera si cela suffit

Plus utile qu’un inventaire de vérifications automatiques fut la découverte d’une faille permettant au coordinateur d’écrire « acceptée » et de clore ma demande sans correction réelle. Je l’ai fermée, mais j’ignorais encore si la structure résisterait à une longue tâche réelle.

Malgré tout, j’ai reposé la question.

Est-ce suffisamment amélioré ?

La réponse fut que c’était suffisant pour lancer un pilot contrôlé, mais pas pour affirmer que le dispositif avait été prouvé dans plusieurs sessions Codex réelles. Cette conversation était une side session : elle ne pouvait pas ouvrir de vrais workers et tester en même temps la livraison des notifications, l’intervention de l’utilisateur et la récupération du coordinateur. Une machine à états locale qui passe n’est pas la même preuve qu’un coordinateur interprétant et intégrant correctement mes instructions pendant une tâche longue.

J’ai donc décidé de ne pas imaginer davantage de règles à ajouter ici. Dans la session du coordinateur, je répartirai réellement le travail sur la brochure, j’observerai moi-même chaque session et je donnerai aussi des instructions intermédiaires. Je vérifierai jusqu’au bout si le coordinateur perd mes instructions, empiète sur la propriété d’une autre session ou reste capable de retrouver l’objectif initial et l’action suivante malgré l’accumulation des rapports. Si le résultat arrive aujourd’hui, j’écrirai la suite aujourd’hui ; s’il arrive demain, je pourrai continuer demain.

Après avoir terminé l’article, j’ai également reconsidéré le nom du Skill d’audit. L’ancien nom, custom-graph-engineering-gate, décrivait le concept de départ, mais n’indiquait pas du tout ce que faisait réellement le Skill.

L’action réelle consiste à arrêter un résultat de travail et à ouvrir une session d’audit séparée. J’ai donc renommé le Skill custom-open-audit-session. L’ancien nom reste dans les archives de l’époque, mais c’est désormais le seul nom à invoquer.

Il n’est cependant pas nécessaire de repousser aussi la conclusion de cet article. Aujourd’hui, je n’ai pas décidé de faire confiance au coordinateur. J’ai clairement posé comme condition que la structure ne s’effondre pas même si j’interviens directement dans chaque session et, au lieu d’affirmer que tout était suffisant, j’ai laissé un E2E à vérifier dans le travail réel.

Ce ne sont ni les explications ni le nombre de tests qui décideront si cette structure mérite ma confiance, mais le véritable travail sur la brochure que j’observerai moi-même.