+++
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.