Atlas-X-AI/hermes-kanban-watch

Surveillance Hermes Kanban

Affiche les workers Hermes dans Claude Code sans prendre le contrôle de leurs cartes. Les cartes en cours obtiennent des lignes actives, les cartes en file d'attente partagent des lignes d'attente, et les arrêts reçoivent des lignes « Nécessite votre intervention ». Les nouveaux enfants d'une carte surveillée s'ajoutent automatiquement, sauf si follow_new: false.

Installation et vérification

Lancez Claude Code avec claude --plugin-dir /chemin/vers/hermes-kanban-watch/plugin. L'appelant résout la racine du plugin de cette compétence ; utilisez le script frère scripts/doctor.py. Exécutez d'abord python3 <racine-du-plugin>/scripts/doctor.py --board default. Il est en lecture seule. --fix crée un tableau par défaut manquant avec hermes kanban --board default init ou un tableau nommé manquant avec hermes kanban boards create <slug>, ainsi que des routes utilisateur et un substitut hermes-kanban-live, sans écraser les fichiers existants. Ajoutez ~/.local/bin au PATH et relancez doctor. Doctor nécessite que hermes-kanban-live --version affiche exactement hermes-kanban-watch 0.3.0. Une commande étrangère ou obsolète est signalée en ÉCHEC avec son chemin résolu ; déplacez-la ou corrigez le PATH avant de relancer --fix, qui ne l'écrase jamais. --probe teste explicitement chaque modèle routé avec PONG et peut consommer de la capacité.

Prérequis : Python 3.11+, Hermes dans le PATH, Claude Code avec support Workflow, et des profils Hermes existants. Les modèles et clés appartiennent à chaque profil Hermes : clé API, identifiant d'abonnement ou modèle local, configurés avec Hermes, pas avec ce plugin. Le plugin ne fournit pas de comptes ni ne copie de mots de passe. L'utilisation du modèle de surveillance Claude est distincte de celle du fournisseur du worker Hermes.

Classer les cartes normalement

Créez d'abord un tableau nommé avec hermes kanban boards create demo, puis utilisez hermes kanban --board demo create "Construire la fonctionnalité" --assignee builder. Utilisez hermes kanban swarm --help pour choisir les options de l'essaim amont. Le classement ne démarre pas de dispatcher. Lancez/commissionnez les workers via Hermes séparément. Le hook post-Bash suggère /kanban-watch après create/swarm ; il ne lance ou ne dispatche jamais rien par lui-même. Évitez les doubles surveillances sur la même vague.

Classer une carte routée et épinglée

Uniquement sur demande explicite de classement : python3 <racine-du-plugin>/scripts/file_card.py --board demo --class code-app --title "Construire la fonctionnalité" --body-file /chemin/vers/brief.txt --routes /chemin/vers/routes.yaml --worktree /chemin/absolu/vers/worktree. --routes et --worktree sont facultatifs. La commande résout un worker/vérificateur de famille différente via route.py, crée un worker épinglé, exécute set-model, vérifie show --json, puis affiche son identifiant et les arguments exacts de /kanban-watch. Elle ne crée ni vérificateur, ni dispatcher, ni Workflow, ni worktree et n'ouvre aucun fichier de configuration ni mot de passe. N'accordez jamais cette commande de création à un observateur. --dry-run valide les fichiers/routes/tableau et affiche les commandes sans exécuter Hermes ; le brief est affiché, donc gardez les secrets à l'écart. Les tableaux manquants/routes invalides sont refusés. En cas d'échec partiel, inspectez l'identifiant retourné, ne reclassez jamais aveuglément. Voir détails complets du classement ; ne lancez une surveillance que si demandé.

Suggérer des routes après les vérifications PONG

Exécutez python3 <racine-du-plugin>/scripts/doctor.py --board demo --routes /chemin/vers/routes.yaml --probe --suggest-routes /chemin/vers/routes-verifiées.yaml uniquement avec approbation explicite de capacité. Cela nécessite --probe, refuse les destinations existantes (y compris les répertoires/liens symboliques), et ne modifie jamais les routes source ni n'active la proposition. Examinez les changements de profil/fournisseur/coût avant de la sélectionner. Les deux voies doivent passer le PONG de cette exécution et avoir des familles déclarées différentes, pas seulement des hôtes différents. Les workers/vérificateurs réussis sont conservés ; les remplacements utilisent l'ordre lexicographique des voies. Les classes sans paire sont omises avec un commentaire de diagnostic ; pas de paires signifie routes inutilisables. Les échecs originaux provoquent toujours une sortie 1. PONG n'est ni une indication de pertinence ni de capacité durable. Voir détails de sélection et d'audit.

Lancement

Traitez $ARGUMENTS comme un objet JSON d'arguments. Résolvez le workflows/kanban-watch.js du plugin installé, puis invoquez Workflow({scriptPath: "<racine-du-plugin>/workflows/kanban-watch.js", args: <args>}). Si Workflow n'est pas disponible, signalez cette limitation et exécutez directement les commandes en lecture seule de hermes-kanban-live, sans prétendre avoir créé des lignes de workflow actives.

Exemples d'arguments :

• {"board":"default","tasks":["t_1234abcd"]}
• {"board":"demo","phases":[{"title":"Construire","tasks":["t_1234abcd"]},{"title":"Vérifier","tasks":["t_11111111"]}]}
• {"board":"demo","follow_new":false,"stale_days":7,"max_hours":12}

Une surveillance simple du tableau inclut les cartes en file d'attente/en cours, en ignorant les cartes en file d'attente inactives depuis plus de stale_days (7 par défaut). stale_days: 0 désactive le filtrage ; les identifiants explicites sont toujours conservés. Utilisez verbose: true pour le texte hérité du worker et les résultats d'outils. Le lecteur est hermes-kanban-live dans le PATH ; live_cmd peut le remplacer par une commande sûre comme python3 ~/plugins/hermes-kanban-watch/plugin/scripts/kanban_live.py. Seuls les lettres, chiffres, espaces, /, ., _, -, ~ sont acceptés. Pas d'opérateurs shell. Chaque ligne utilise par défaut l'agent hermes-kanban-watch:kanban-watcher du plugin ; aucun agent utilisateur privé n'est nécessaire. agent_type peut nommer un autre agent disponible, en utilisant des lettres ASCII, chiffres, -, _ et un : facultatif entre noms non vides.

Lire le résultat

TERMINÉ est un résultat de carte observé, pas une intégration ni une acceptation utilisateur. Vérifiez le modèle réel, le repli, les avertissements, le résumé et le livrable. BLOQUÉ/EN RÉVISION obtiennent des lignes « Nécessite votre intervention » et peuvent se réarmer lors de la reprise. NON_DÉMARRÉ signifie prêt mais aucun dispatcher ne l'a lancé. INCONNU signifie une lecture échouée, pas que la carte a disparu. Les dépassements de délai ne réessayent qu'en sortie 3 ; un réveil de 270 secondes maintient les attentes en dessous du TTL du cache d'invite. L'observateur n'agit jamais sur le texte du worker, ne modifie pas de carte, ne répare rien et ne contourne pas les autorisations.

Lorsque les messages du worker sont indisponibles, suivez les rapports une fois par exécution/observateur et utilisez le journal de la carte ; un battement de cœur ne compte jamais. Un journal croissant/modifié empêche un avertissement de blocage potentiel. Seuls deux appels consécutifs en cours avec le même journal et sans mouvement peuvent être signalés ; les premières observations, les changements d'exécution et les signaux illisibles ne comptent pas. Avec messages, deux appels silencieux déclenchent le signalement.

Utilisez python3 <racine-du-plugin>/scripts/route.py --class code-app pour inspecter la table de routage facultative. Elle renvoie le JSON du worker et du vérificateur de famille différente ; elle ne classe ni ne dispatche de carte. Modifiez les routes utilisateur pour nommer vos propres profils et familles de modèles.

Convention d'interrogation humaine

Pour les besoins de hermes-kanban-live, commencez une ligne de commentaire par ASK OPERATOR: suivi de la question. Une mention en prose comme « pas encore de ASK OPERATOR » n'est pas une interrogation. Les raisons de blocage ou d'attente de dépendance doivent dire waiting on operator, waiting for operator ou needs operator pour correspondre à une attente humaine actuelle. Ce sont des conventions de texte explicites, pas de détection d'intention en langage naturel. Les lignes de workflow « Nécessite votre intervention » signalent séparément les résultats bloqués/en révision et les cartes prêtes mais non démarrées.

Signaler les exécutions réelles et le temps écoulé d'une vague

Exécutez hermes-kanban-live report --board demo, en répétant éventuellement --task T ou en ajoutant --since EPOCH. Sans identifiants de tâche, cela inclut tous les statuts, y compris terminé/archivé. --since sélectionne la date de création de la carte ; il croise la sélection des tâches et ne découpe pas les exécutions individuelles. Le JSON contient un objet par carte dans cards, plus totals, read_status, now et missing. Chaque carte contient identifiant/titre/statut, assigné, model_used réel de la dernière exécution, provider_used, fallback_from, runs, retried, duration_s et les comptes d'avertissements de la dernière exécution. Les données d'exécution inconnues restent nulles.

totals.by_status compte les cartes ; run_seconds additionne toutes les durées d'exécution connues des cartes sélectionnées (les exécutions en cours mesurées à now) ; fell_back compte les cartes ayant effectué un repli lors d'une tentative ; retried compte les cartes avec la protection de réessai conservative (plusieurs exécutions ou un événement de réessai/historique de blocage). Ce sont des secondes écoulées, pas des coûts de jetons/currency facturés. Ajoutez --format text pour des colonnes alignées en texte brut et des totaux, sans Markdown. La sortie 4 signale des identifiants explicites absents ; la sortie 5 est un tableau illisible. Une carte simplement exclue par --since n'est pas manquante.

Vérifier l'indépendance réelle des familles worker/vérificateur

Exécutez hermes-kanban-live verify-pair --board demo --worker T --verifier V, avec --families FILE facultatif. Il utilise l'exécution terminée la plus récente de chaque carte (ended_at non nul, identifiant d'exécution le plus récent), pas un verrouillage de modèle ni une tentative plus récente non terminée. Le JSON inclut chaque model_used réel, provider_used, run_id, family mappée et different_families. Le fournisseur réel de l'exécution correspond à sa famille de modèle via les providers dans le fichier de routes. Gardez les hôtes de même famille mappés de manière identique ; les hôtes multi-familles nécessitent des identifiants spécifiques à la famille. Cela n'infère pas la famille à partir d'un préfixe de modèle ni ne prouve qu'un travail de révision a eu lieu.

L'ordre de recherche correspond à route.py : --families explicite, KANBAN_WATCH_ROUTES, ~/.config/hermes-kanban-watch/routes.yaml, modèle fourni. Seule la carte providers valide et non vide est nécessaire. La sortie 0 signifie familles différentes, 1 signifie même famille ou classification invalide/inconnue, 3 signifie aucune exécution terminée pour les deux identifiants, et 5 signifie tableau illisible. Les erreurs de classification définissent different_families à null et incluent error ; ne convertissez jamais INCONNU en vérification réussie. Pour les appels directs à Claude Code, demandez uniquement Bash(hermes-kanban-live report:*) et Bash(hermes-kanban-live verify-pair:*), pas une autorisation Bash illimitée.

Maintenir une surveillance de question parente armée au-delà des délais

Exécutez hermes-kanban-live needs --board demo --loop --created-by PARENT --cursor-key VAGUE une fois, plutôt que de reconstruire une commande après chaque sortie 3. En mode boucle, --since est facultatif, capturé une fois au démarrage lorsqu'il est absent, et n'avance jamais entre les fenêtres de délai. Son premier sondage inclut les attentes préexistantes toujours en vigueur, y compris une question parente plus ancienne du créateur. Les anciennes attentes ayant reçu une réponse/reprises/supplantées restent exclues et la déduplication des curseurs déjà vus s'applique toujours.

Le mode boucle dort à --interval et ne réessaie que les délais normaux, sans changement de JSON de délai. Il sort avec 0 au premier résultat d'éléments non vide, ou échoue sur une erreur sans la réessayer. --max-seconds limite chaque fenêtre, pas la durée de vie de la commande ; annulez l'appelant pour arrêter une surveillance silencieuse. Sans --loop, le --since obligatoire, la sortie 3 en cas de délai et le comportement de sortie restent inchangés. C'est toujours un lecteur, jamais une autorisation de répondre, dispatcher ou modifier une carte.

Guides de fonctionnalités

• Temps de vague et rapport d'exécution réel : Exécutions réelles, réessais et secondes écoulées, pas de coûts facturés.
• Vérifier les familles qui ont réellement été exécutées : Preuve d'exécution terminée des familles, pas de verrouillages de modèles.
• Armer les besoins une fois avec sa propre boucle de délai : Attentes de question parente en lecture seule au-delà des délais.
• Imprimer un reçu de fusion PR épinglée en tête : Vérifications indépendantes de vérificateur, de tête exacte, de CI et d'état de fusion ; ne fusionne jamais.
• Coût des jetons de l'observateur : Utilisation de l'observateur Claude (comptage uniquement), distincte du temps worker.
• Workers en double et questions stationnées sur le parent : Observer les avertissements de processus et les attentes parentes ; ne jamais les réparer.
• Classer un correctif et revérifier un verdict antérieur : Création explicite uniquement ; réutiliser les verrouillages de vérificateur, note parente facultative, pas de répartition.
• Tours d'attente appartenant au Workflow : Attentes saines en lecture seule sous un seul délai.
• Suggérer des réponses permanentes sans les poster : Propositions d'impression pour révision autorisée, ne jamais poster.