hermes verify : la commande qui répond à « est-ce que ce projet tourne vraiment ? »

Quand vous reprenez un dépôt — ou venez de cloner quelque chose de frais — la première chose que vous faites est de taper l’incantation familière : installer les dépendances, builder, lancer les tests, démarrer le serveur, vérifier le port. Chaque projet a besoin de sa propre variante : npm pour certains, pip pour d’autres, cargo build ici, docker compose up là.
hermes verify, arrivé sur main de Hermes Agent début août 2026, est conçu pour exactement ce moment : une commande qui répond à « est-ce que ce projet tourne vraiment ? » Il détecte automatiquement la recette d’exécution du projet et effectue un passage smoke complet dans l’ordre bootstrap → build → test → start → readiness, puis renvoie un verdict structuré.
$ hermes verify
detected: node (npm, vite)
bootstrap ✓ build ✓ test ✓
start on :5173 → ready in 2.1s
VERIFY PASS · evidence recorded
1. Ce qu’il fait
Le flux de travail principal de hermes verify :
- Detect — analyser le répertoire courant (ou un chemin donné) à la recherche de fichiers signatures, déterminer le framework utilisé par le projet et construire une recette ;
- bootstrap — installer/préparer les dépendances (p. ex.
make installou la cible d’installation détectée) ; - build — compiler le projet (
npm run build,go build ./...,cargo build,mvn package, …) ; - test — exécuter la suite de tests (
npm test,pytest,go test ./...,mvn test, …) ; - start — démarrer l’application en arrière-plan et sonder sa readiness (timeout de readiness de 60 s par défaut, port surchargeable) ;
- teardown — nettoyer, afficher un résumé des preuves (evidence) et un verdict structuré de réussite/échec.
S’il ne reconnaît pas le projet, il le dit explicitement et vous explique comment définir une recette manuellement.
Sa place dans ce que Hermes possède déjà
Hermes disposait déjà de trois niveaux de vérification (auto-vérification, contrats de complétion, commandes de test canoniques). hermes verify comble le vide qu’ils laissent : la vérification smoke au runtime — le projet se compile-t-il vraiment, démarre-t-il vraiment, le port répond-il vraiment ? Les exécutions réussies sont enregistrées dans le registre de preuves de vérification (agent/verification_evidence), qui partage le même magasin de preuves que la garde verify-on-stop — un hermes verify réussi a le même poids qu’une commande de test canonique réussie.
Point de conception clé : c’est une commande CLI pure, avec zéro empreinte sur les outils du modèle — aucun nouvel outil visible par le modèle, aucun changement de la surface d’outils de l’agent.
2. Types de projets pris en charge
Les vrais détecteurs dans agent/verify/recipes.py (chacun avec ses chaînes de preuves) :
| Project | Signature | Default build / test / start |
|---|---|---|
| Node.js | package.json + package manager (npm/pnpm/yarn) | npm run build / npm test / npm run dev (vite & friends) |
| Python (Django) | manage.py or django dep | — / python manage.py test / python manage.py runserver 0.0.0.0:8000 |
| Python (FastAPI etc.) | pyproject/requirements | — / pytest (or unittest) / per detection |
| Go | go.mod | go build ./... / go test ./... / go run . |
| Rust | Cargo.toml | cargo build / cargo test / cargo run |
| Java (Maven) | pom.xml | mvn package / mvn test |
| Java (Gradle) | build.gradle(.kts) | ./gradlew build / ./gradlew test |
| Makefile project | Makefile | auto-picks install/build/test/run targets |
| docker-compose | compose.yml etc. | docker compose build / docker compose up |
3. Flags complets
hermes verify [path] [options]
path project root to verify (default: current directory)
--detect-only detect and print the recipe as JSON only; run nothing
--save save the recipe as .hermes/environment.json in the project
--skip-start run command phases but skip booting the app / readiness poll
--phase <name> run only the given phase(s) (bootstrap|build|test|start; repeatable)
--port <n> override the port used for the readiness poll
--timeout <sec> per-phase timeout (default 600s)
--ready-timeout <sec> readiness poll timeout (default 60s)
--json emit a machine-readable JSON result
4. Utilisation typique
Contrôle smoke quotidien
cd ~/projects/acme-web
hermes verify
Détection seule — voir si votre projet est reconnu
hermes verify --detect-only
# {"source": "detected", "recipe": {"kind": "node", ...}}
Figer la recette
La détection peut dériver quand le contenu du répertoire change. --save fige la recette dans .hermes/environment.json ; ensuite, hermes verify charge ce manifeste en premier et les résultats deviennent reproductibles :
hermes verify --save
# Saved manifest: /Users/me/projects/acme-web/.hermes/environment.json
Sortie JSON comme porte de CI
hermes verify --json
# {"ok": true, "recipe": {...}, "phases": {...}}
Phase de test seule
hermes verify --phase test
5. Définir une recette manuellement
Quand --detect-only échoue, le message vous oriente vers la création de .hermes/environment.json dans le projet pour définir la recette à la main. Le manifeste est limité au projet, et le choix de mettre .hermes/ dans .gitignore vous appartient — mais notez qu’il a priorité sur l’auto-détection, donc une fois sauvegardé, toutes les vérifications ultérieures suivent votre définition.
6. Compromis de conception à noter
- Zéro empreinte modèle : verify est une commande CLI, pas un outil d’agent — il sert « un humain dans le terminal qui confirme rapidement la santé du projet » et ne coûte aucun budget d’outils d’agent ;
- Les preuves sont comptabilisées : les exécutions réussies atterrissent dans le registre de preuves de vérification, partagé avec la garde verify-on-stop, ce qui boucle la boucle ;
- Échec rapide : timeout de 600 s par phase et de 60 s pour la readiness par défaut — un projet bloqué ne pend jamais indéfiniment.
Résumé
hermes verify automatise le rituel quotidien du « clone-le et fais-le tourner » : détecter le framework, installer, builder, tester, démarrer, sonder — une commande, un verdict structuré. C’est particulièrement utile si vous évaluez fréquemment des dépôts inconnus ou voulez une porte smoke bon marché dans votre CI.
Plus sur notre site : associez-le à notre guide complet de l’automatisation cron avec Hermes Agent pour exécuter verify selon un planning, lisez comment Hermes gère les erreurs et se rétablit, ou installez Hermes en cinq minutes.