Configurer une tâche Hermes récurrente avec un skill et vérifier sa première exécution

Les opérateurs Hermes peuvent associer un skill vérifié à une tâche récurrente pour que chaque exécution commence par la même procédure. Le contrôle utile consiste à vérifier qu’une exécution planifiée lit l’entrée autorisée, produit un rapport local acceptable et indique le modèle et l’hôte réellement utilisés. Ce guide s’adresse à un opérateur qui maîtrise le profil Hermes, le compte fournisseur et l’hôte de la passerelle. BIG CHANGE a consulté le manuel cron officiel et la documentation associée le 19 octobre 2026 ; nous n’avons ni installé Hermes ni exécuté de tâche.

Le grand changement

• Ce qui change : Hermes peut charger un skill vérifié avant une instruction planifiée, l’exécuter dans un espace de travail choisi et enregistrer le résultat localement. L’opérateur peut créer la tâche en pause, l’inspecter et la reprendre sous le même ID.
• Pourquoi cela compte : Une tâche d’information répétable peut suivre une procédure vérifiée. L’opérateur doit toutefois comparer une exécution arrivée à échéance avec son entrée autorisée ; un calendrier enregistré ne prouve ni la révision du skill ou le modèle utilisés, ni l’exactitude du rapport.
• À surveiller : La poursuite de l’utilisation dépend de la disponibilité de l’hôte de la passerelle et du respect des critères par le premier rapport. Vérifiez la tentative, le résultat et les éléments disponibles sur le fournisseur et le modèle avant de laisser la tâche active ; réexaminez son état exact après toute interruption.

Avant de planifier quoi que ce soit

Choisissez un petit fichier d’entrée autorisé et un espace de travail existant et isolé. Définissez le contenu d’un court rapport correct, les références à l’entrée et les données manquantes qui doivent provoquer l’arrêt. Limitez cette première tâche à l’information : aucune publication externe, modification de registre ou donnée secrète dans le résultat. Obtenez une autorisation distincte pour la rendre récurrente. Il vous faut aussi une installation Hermes configurée, un chemin utilisable vers un modèle et son fournisseur avec les identifiants nécessaires, et un hôte de passerelle disponible pour les exécutions planifiées. Vérifiez votre version installée et hermes cron create --help car le manuel public ne précise pas la version de chaque option. Le guide de démarrage explique l’installation ; le guide des fournisseurs explique le chemin d’inférence. Une conversation ponctuelle sans risque peut vérifier ce chemin avant la récurrence, mais ne prouve pas la réussite d’une exécution planifiée.

Un skill est une procédure SKILL.md vérifiée, pas une limite d’autorisation. Placez skills/local-input-report/SKILL.md sous le HERMES_HOME du profil propriétaire réel ; ~/.hermes/skills/local-input-report/SKILL.md est l’exemple pour le profil par défaut. Adaptez cette procédure minimale à l’entrée autorisée et aux critères du rapport avant de l’utiliser :

---
name: local-input-report
description: Report checked facts from one approved local input.
---

Read only <absolute-permitted-input-path> in the job workspace. In a short report, name that file, state only facts supported by it, and cite the relevant part. Flag missing data and stop. Do not send messages or change files or external records.

Inspectez le fichier réel et confirmez que Hermes le découvre avec hermes skills list dans ce même profil. Si vous utilisez plutôt un skill propre au projet, le manuel des skills indique qu’une décision interactive de confiance et d’analyse doit précéder une exécution cron non interactive ; cron n’accorde pas lui-même cette confiance. Examinez séparément les outils activés et l’accès réel aux fichiers. Conservez le contenu ou la révision du skill : son nom ne remplace pas une vérification.

Créer une tâche, puis l’inspecter

1. Exécutez chaque commande avec le même profil propriétaire : les exemples ci-dessous utilisent le profil par défaut, tandis qu’un profil nommé exige son sélecteur, tel que hermes -p NAME, dans chaque commande. Vérifiez le modèle actuel de ce profil avec hermes model et l’état de la passerelle et du mécanisme de déclenchement avec hermes cron status. Décidez de fixer explicitement le fournisseur et le modèle, ou de fixer le modèle principal actuel. Une sélection fixée pour la tâche est prioritaire sur cron.model et cron.model_provider ; ces paramètres communs sont prioritaires sur le modèle principal actuel. Une tâche sans sélection fixée peut donc changer de modèle si la valeur par défaut applicable change. La configuration enregistrée ne prouve toujours pas le modèle utilisé lors d’une exécution réelle.
2. Une fois la récurrence autorisée, adaptez cet exemple de CLI pour un shell POSIX à votre skill vérifié et au chemin absolu d’un espace de travail existant. Confirmez d’abord chaque option dans l’aide installée. Les continuations de ligne par barre oblique inverse suivent la syntaxe POSIX ; sur une autre plateforme, utilisez la syntaxe de votre shell. L’instruction est volontairement limitée et la livraison locale conserve le premier résultat dans le profil propriétaire :

   hermes cron create "every 1h" \
     "Use the attached reviewed skill to read only the permitted input. Return a short local report with its source and missing-data note. Do not send or change external records." \
     --skill local-input-report \
     --name "Local input report" \
     --workdir "/absolute/existing/workspace" \
     --pin \
     --paused --paused-reason "Awaiting owner review"

Remplacez le chemin de l’espace de travail, choisissez un nom de tâche unique et remplacez l’emplacement réservé à l’entrée dans le fichier du skill avant d’exécuter cette commande. La CLI utilise par défaut la livraison locale. Le manuel cron décrit aussi --model et --provider pour fixer explicitement la sélection. Utilisez les vrais identifiants de fournisseur et de modèle de votre installation si vous choisissez cette voie. Ne placez pas d’identifiants secrets dans l’instruction ou l’historique du shell. --workdir permet à Hermes de découvrir les instructions de l’espace de travail ; sans cette option, cron s’exécute hors du dépôt. Une nouvelle tâche en pause n’a pas de next_run_at avant sa reprise.

La livraison locale détermine où le rapport final est enregistré. L’instruction et tout contenu d’entrée utilisé pour l’inférence suivent toujours le chemin du modèle et du fournisseur sélectionnés ; approuvez ce flux de données avant la reprise.

3. Conservez l’ID de tâche renvoyé. Utilisez hermes cron list pour relire son skill, son espace de travail, sa livraison et son état de pause ; utilisez hermes cron status pour vérifier le planificateur. Le code officiel actuel de la CLI n’affiche pas les champs de modèle et de fournisseur enregistrés dans les lignes de la liste. Inspectez l’ID exact dans le fichier du profil propriétaire cron/jobs.json en lecture seule pour connaître la sélection fixée, le modèle, le fournisseur et les paramètres d’inférence prioritaires, ou utilisez une vue de détail réellement prise en charge par votre version installée. N’affichez pas les identifiants secrets. Comparez les paramètres enregistrés avec le fichier, les critères du rapport et le périmètre approuvé. Corrigez cette tâche avec hermes cron edit <job_id> ... si nécessaire ; il n’est pas utile de créer un doublon.
4. Lorsque vous êtes prêt à observer une exécution arrivée à échéance, utilisez hermes cron resume <job_id>. Relisez l’heure réelle de la prochaine exécution et le dernier déclenchement réussi de la passerelle. Celle-ci se réveille environ une fois par minute ; au premier plan, elle exige que son hôte reste allumé. hermes cron tick ne démarre pas de passerelle pour une tâche d’agent. Un service ou un processus résistant aux redémarrages a des exigences propres à l’hôte : vérifiez l’hôte choisi sans supposer de garantie quand un ordinateur portable est éteint ou redémarre.
5. Après une échéance planifiée, inspectez hermes cron runs <job_id> --limit 20 et le fichier correspondant sous le chemin du profil propriétaire cron/output/<job_id>/. Comparez le rapport avec l’entrée réelle et vos critères d’acceptation. Vérifiez les heures de planification et de prise en charge de la tentative, son état final et toute transcription ou télémétrie disponible concernant le fournisseur et le modèle réellement utilisés. Si les enregistrements installés ne révèlent pas cette identité, notez-la comme inconnue. Un déclenchement du planificateur, une exécution admise ou l’état completed ne valide pas à lui seul le rapport.
6. Suspendez la tâche exacte avec hermes cron pause <job_id> et relisez son état dans hermes cron list. Cela empêche les futures planifications automatiques, sans arrêter une tentative en cours. Une exécution manuelle explicite constitue une dérogation de l’opérateur, même pendant une pause. Gardez l’historique et le résultat local pour décider si la tâche a satisfait les critères d’acceptation.

En cas d’échec, rétablir la même tâche

Lisez d’abord la tentative exacte et son résultat, puis les champs de la tâche last_error, last_fire_error et last_delivery_error lorsqu’ils sont disponibles. hermes cron status distingue un mécanisme de déclenchement arrêté ou un stockage cron non inscriptible d’une tâche exécutée mais échouée. Vérifiez le profil propriétaire et l’hôte de la passerelle avant de modifier les paramètres du fournisseur : un shell interactif et un service peuvent lire des identifiants différents. Corrigez uniquement le paramètre concerné, vérifiez de nouveau l’état et reprenez le même ID seulement si son périmètre reste approuvé. Si la livraison est incertaine, inspectez la destination prévue avant de réessayer ; un délai d’attente peut expirer après qu’un adaptateur a accepté l’envoi.

La section du manuel cron sur la reprise des admissions indique qu’une exécution interrompue ou un déclenchement préparé introuvable reste en pause pour examen ; sa section sur l’historique indique que les tentatives inconnues ne sont jamais relancées automatiquement. Après un redémarrage, vérifiez l’état de pause de la tâche installée et l’identité exacte de la tentative avant de décider de la reprise. Ne déclenchez jamais deux fois une tentative active pour tester les chevauchements. Hermes dispose d’un verrou du planificateur, d’une protection contre une nouvelle admission de la même tâche en cours et d’une limite configurable de concurrence globale. Ces contrôles ne garantissent pas des effets exactement une fois dans un système externe.

L’utilisation du fournisseur et d’un hôte toujours disponible peut être payante. Commencez par une entrée limitée et examinez l’usage du fournisseur après l’exécution attendue avant de choisir une cadence continue. Le délai documenté du script préalable ne limite ni un tour de modèle piloté par un skill ni sa facture ; les limites de nettoyage et d’inactivité sont distinctes. Une échéance dans l’instruction est une consigne, pas une limite de dépenses contraignante. Si vous ne pouvez pas tolérer un tour de modèle sans borne ou un effet secondaire incertain, gardez la tâche en pause jusqu’à disposer de contrôles adaptés. Ce guide décrit le comportement documenté, pas une exécution mesurée, un prix, une fiabilité constatée ou une économie promise.