URL:     https://linuxfr.org/users/gracefullight/journaux/conserver-son-agent-de-code-et-verifier-les-resultats-le-cas-d-oma
Title:   Conserver son agent de code et vérifier les résultats : le cas d’OMA
Authors: gracefullight
Date:    2026-10-04T07:51:00+02:00
License: CC By-SA
Tags:    claude, spam, logiciel_libre, développement, tests, intelligence_artificielle et slop
Score:   -20


Dans sa session du 12 août 2026, Lauren Tan aborde les compétences de vérification et les contrôles CI stricts. Je maintiens [oh-my-agent](https://github.com/first-fluke/oh-my-agent), un projet MIT qui propose déjà une configuration commune de spécialistes et de workflows à plusieurs agents pour les environnements pris en charge. On peut conserver un agent de code pris en charge et y rattacher les vérifications du projet ; les workflows concernés ajoutent une revue indépendante et des contrôles des fichiers de résultat. La prise en charge des hooks varie selon l’environnement. Voici une reproduction limitée au contrôle Stop.

L’expérience porte sur une fonction d’expiration et trois tests : avant l’échéance, à l’échéance et après. Avec `now > expiresAt`, le test de l’égalité échoue ; les deux autres passent. J’ai ensuite appelé le véritable hook Stop d’OMA, avec le contrôle `test` attaché au workflow. Le CLI a réexécuté le script du projet et produit un JSON contenant `"decision":"block"`.

Après le changement en `now >= expiresAt`, les trois tests passent. Un nouvel appel Stop produit une sortie vide et supprime l’état du workflow de cette fixture. Le journal d’événements conserve le passage du contrôle et la fin de session.

Un détail compte pour lire correctement le résultat : le processus du hook termine avec le code 0 avant comme après la correction. Le refus est porté par le JSON, pas par son code de retour. Regarder seulement le statut du processus masquerait donc la différence entre ces deux appels.

Il s’agit d’une fixture locale isolée, exécutée sur macOS. J’ai envoyé manuellement une entrée Stop au format Claude ; ce n’est pas l’enregistrement d’une session autonome en production. La correction est explicite, et les trois tests définissent exactement ce que cette expérience vérifie. Elle ne mesure pas la qualité générale du code produit par un modèle.

Le [Gist de reproduction](https://gist.github.com/gracefullight/06ed76480cd105882067e814bb2cbaf6) contient le script, le diff, les commandes, les sorties et les codes de retour. Il utilise le CLI source OMA 15.0.13 et indique les dépendances nécessaires. Le script de reproduction ne compile pas le logiciel et n’installe pas de dépendances.

OMA conserve aussi la configuration des spécialistes dans `.agents/`, puis l’adapte aux environnements pris en charge. Cela permet de partager cette configuration quand on travaille avec plusieurs outils. Les workflows qui les prévoient ajoutent une revue indépendante et des contrôles des fichiers de résultat ; cette petite expérience ne teste que le mécanisme Stop.

Pour essayer le harness complet, après préparation de Bun, uv et Serena :

```sh
bunx oh-my-agent@latest
oma doctor
```

`npx skills add first-fluke/oh-my-agent` distribue les compétences seules. Les hooks et contrôles décrits ici nécessitent le harness complet.

Je serais intéressé par vos retours sur cette frontière de vérification : quels résultats faudrait-il conserver pour qu’une décision de fin reste compréhensible après la session ?

Ce texte en français a été préparé avec une aide d’IA.