bachirandClaude Opus 5.5
59e046ad99
Disput-Turn: 0001 Disput-Participant: claude Disput-Role: implementer Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
70 lines
2.8 KiB
Markdown
70 lines
2.8 KiB
Markdown
# disput
|
|
|
|
> *disput*, de *disputatio* : la dispute scolastique, où chaque objection
|
|
> reçoit une réponse.
|
|
|
|
`disput` orchestre **plusieurs clients IA en ligne de commande** (Claude
|
|
Code, Mistral Vibe, puis d'autres) qui travaillent ensemble sur un même
|
|
dépôt git. Chaque participant y tient un **rôle** : implémenteur,
|
|
reviewer, auditeur sécurité… Le travail se fait **par tours**, sous un
|
|
protocole strict, et tout l'état du dialogue vit dans le dépôt.
|
|
|
|
`disput` ne remplace pas le harness de chaque agent : il **les fait
|
|
jouer à tour de rôle**, vérifie après chaque tour que les règles ont
|
|
été respectées, et ne rend la main à l'humain que lorsqu'une décision
|
|
lui revient.
|
|
|
|
## Pourquoi
|
|
|
|
Le protocole est né sur un projet réel, où Claude et Vibe alternaient
|
|
implémentation et review sévère. Sur 16 tours, la review croisée entre
|
|
modèles a attrapé de vrais bugs, que l'implémenteur avait pourtant
|
|
déclarés corrigés. Deux limites sont apparues :
|
|
|
|
- l'humain servait de **bus de messages** : il tapait « à toi » dans un
|
|
agent, puis dans l'autre ;
|
|
- les garde-fous (pas de prod, pas de push, pas de réécriture
|
|
d'historique) n'étaient que **déclaratifs**.
|
|
|
|
`disput` automatise le relais, impose les garde-fous et ouvre le
|
|
protocole à **N participants et à des rôles configurables**.
|
|
|
|
## Principes
|
|
|
|
1. **Le protocole d'abord, l'outil ensuite.** [`PROTOCOL.md`](PROTOCOL.md)
|
|
se suffit à lui-même : on peut le pratiquer à la main, en tapant
|
|
« à toi » à chaque agent. L'outil ne doit jamais devenir indispensable
|
|
pour avancer.
|
|
2. **Tout l'état est dans git.** Tours, objections, backlog, décisions :
|
|
des fichiers versionnés, lisibles par les humains comme par les
|
|
machines.
|
|
3. **Les garde-fous sont techniques.** Une règle que l'outil ne sait pas
|
|
vérifier ou bloquer n'est qu'un vœu.
|
|
4. **Pas de fonctionnalité sans besoin observé.** Une fonctionnalité
|
|
n'entre que si un projet réel en a eu besoin, et ce besoin est
|
|
consigné dans un tour.
|
|
5. **disput se développe avec disput.** Ce dépôt est son propre premier
|
|
projet client (voir `.disput/`).
|
|
|
|
## État
|
|
|
|
**Phase d'amorçage** : la spec existe, pas encore le code. Le
|
|
développement suit le protocole **à la main** jusqu'à ce que la v0 de
|
|
`disput run` sache prendre le relais. Voir
|
|
[`.disput/backlog.md`](.disput/backlog.md) et
|
|
[`.disput/turns/`](.disput/turns/).
|
|
|
|
## Utilisation visée (v0)
|
|
|
|
```bash
|
|
disput init # crée .disput/ dans un projet (config, backlog, tours)
|
|
disput status # qui joue ensuite, objections ouvertes, décisions en attente
|
|
disput run # enchaîne les tours jusqu'à DONE, USER ou un invariant violé
|
|
disput decide "texte" # enregistre la décision de l'humain et relance
|
|
disput lint # valide les fichiers de tour et la config
|
|
```
|
|
|
|
## Licence
|
|
|
|
À décider (voir le backlog, item `[USER]`).
|