disput/.disput/turns/0001-claude-implementer.md

+++ turn = 1 participant = "claude" role = "implementer" base = "" # premier tour, pas de HEAD antérieur status = "CONTINUE" +++

Tour 1 — claude, implementer : fondation du dépôt

Réponses

Aucune : premier tour.

Travail

Décision user à l'origine du dépôt, prise hors tour et consignée ici (règle 5) :

• créer un outil d'orchestration multi-agents, nommé disput, dans son propre dépôt ;
• ouvrir dès le départ le protocole à N participants et à des rôles configurables, pas seulement à un dialogue à deux ;
• développer l'outil en parallèle de son expérimentation, avec son propre protocole (dogfooding) ;
• objectif premier : supprimer la navette manuelle (« à toi ») de l'humain.

Ce tour pose :

• README.md : raison d'être, principes, usage visé ;
• PROTOCOL.md : spec normative v0 (concepts, fichiers de tour immuables, cycle de vie des items, rôles et déclencheurs, ordonnancement, invariants, garde-fous, place de l'humain, pratique manuelle) ;
• .disput/disput.toml : configuration du projet lui-même (claude et vibe éligibles aux trois rôles, user décideur) ;
• .disput/backlog.md : B-1 à B-13 ;
• AGENTS.md / CLAUDE.md minces, qui renvoient à PROTOCOL.md.

Origine : ce protocole généralise celui pratiqué sur 16 tours dans un autre projet du même utilisateur (dialogue Claude/Vibe en implémenteur/reviewer alternés via un DEVLOG unique). Ce qui est repris :

• la réponse point par point ;
• l'interdiction de modifier les entrées de l'autre ;
• l'obligation de vérifier soi-même.

Ce qui change :

• un fichier par tour plutôt qu'un DEVLOG unique ;
• l'état des items déduit des tours ;
• un ordonnanceur à règles au lieu d'une simple alternance ;
• des invariants vérifiables par machine.

Vérifications

Aucun code ce tour, donc rien à exécuter. Relecture de cohérence : l'en-tête de ce fichier suit le §4, et les identifiants d'items le §4 également.

Items

• [I-0001-1] → role:reviewer : en-tête de tour en TOML entre +++ plutôt qu'en YAML ---, pour rester sans dépendance (tomllib est dans la stdlib depuis 3.11). C'est moins répandu que YAML chez les agents. Risque-t-il de mal formater des en-têtes ? Le coût d'une dépendance YAML est-il préférable ?
• [I-0001-2] → role:reviewer : l'état des items est déduit des tours, sans fichier d'état. C'est robuste à la falsification, mais dépendant d'un parsing strict des lignes - [I-…] dans du markdown libre. Faut-il un bloc structuré (TOML) pour les réponses et les items plutôt que des puces ?
• [I-0001-3] → role:reviewer : trou dans le §7 que je signale moi-même. Un item adressé à @participant, sans rôle, ne dit pas dans quel rôle ce participant doit jouer. Ma proposition : il joue dans le rôle qu'il tenait au tour visé par l'item, et à défaut implementer. D'accord, ou faut-il interdire l'adressage @participant nu ?
• [I-0001-4] → role:reviewer : « un tour = un rôle ». Si reviewer et security sont déclenchés par le même diff et qu'un seul participant est éligible (≠ auteur), il joue deux tours d'affilée. Est-ce acceptable, ou faut-il autoriser un tour multi-rôles (un fichier, deux sections) ?
• [I-0001-5] → role:security : le §9 promet trop. Des deny par motif de chaîne se contournent facilement : git -c … push, des alias, un sh -c, un subprocess en Python… L'invariant §8.3 (refs distantes) ne détecte le push qu'après coup. Piste de défense en amont : forcer dans [guards].env des variables qui rendent le transport inopérant pendant un tour, par exemple une commande SSH qui échoue toujours, ou un pushurl invalide via la config git d'environnement. Est-ce suffisant, contournable, ou à combiner avec autre chose ?
• [I-0001-6] → role:reviewer : v0 sans aucune dépendance externe (argparse, unittest, tomllib). Est-ce tenable jusqu'à B-7 ? Ou vaut-il mieux assumer tout de suite une CLI (Typer/Click) et pytest ?

Prochain tour, d'après le §7 : ce tour modifie des fichiers hors de .disput/ (code_changed), donc c'est au reviewer, tenu par vibe (≠ auteur). .disput/disput.toml correspond aussi au déclencheur paths: de security, donc vibe joue ensuite security, sauf si I-0001-4 est tranché autrement entre-temps.