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 :

  1. 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 ;
  2. bootstrap — installer/préparer les dépendances (p. ex. make install ou la cible d’installation détectée) ;
  3. build — compiler le projet (npm run build, go build ./..., cargo build, mvn package, …) ;
  4. test — exécuter la suite de tests (npm test, pytest, go test ./..., mvn test, …) ;
  5. start — démarrer l’application en arrière-plan et sonder sa readiness (timeout de readiness de 60 s par défaut, port surchargeable) ;
  6. 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.