Cron et planification

Les tâches Cron exécutent des tâches d'agent selon un horaire. Chaque tâche est une requête en langage naturel plus un horaire; au déclenchement, elle s'exécute dans sa propre session et le résultat est livré à votre message direct Slack et/ou au panneau de notifications du tableau de bord.

Ouvrez le panneau Schedule dans le tableau de bord et cliquez sur Add. Remplissez un nom, la requête et l'horaire (intervalle ou expression cron). Vous pouvez aussi simplement demander dans le clavardage : « Chaque jour de semaine à 9 h, résume mon travail en cours » — l'agent crée la tâche pour vous.

kirocrew cron add "briefing" "give me a morning status report" --cron "0 9 * * 1-5"
kirocrew cron add "poll-status" "check the pipeline endpoint" --every 300

L'agent lui-même appelle l'outil MCP équivalent (cron_add) chaque fois que vous dites quelque chose comme « rappelle-moi chaque matin de vérifier… ». Aucune syntaxe à mémoriser.

Le panneau Schedule affiche toutes les tâches avec leur statut, leur prochaine heure d'exécution et des contrôles : mettre en pause, reprendre, déclencher maintenant, modifier, supprimer.

kirocrew cron list
kirocrew cron pause <job_id>
kirocrew cron resume <job_id>
kirocrew cron trigger <job_id>       # run once manually
kirocrew cron remove <job_id>
kirocrew cron remove-all

Toutes ces commandes sont aussi exposées comme outils MCP (cron_list, cron_pause, cron_resume, cron_trigger, cron_remove, cron_remove_all).

Les expressions cron acceptent le format habituel à cinq champs : minute, heure, jour du mois, mois, jour de la semaine.

Chaque tâche peut être ajustée :

Par défaut, les tâches cron obtiennent un petit délai aléatoire avant de se déclencher. Cela répartit la charge lorsque plusieurs tâches partagent un horaire et évite que tout le monde frappe le même point d'accès exactement à HH:00:00. Désactivez cette option avec --strict-schedule.

• Nouvelle (par défaut) — chaque exécution démarre une nouvelle session. Le contexte des exécutions précédentes ne s'y infiltre pas.
• Persistante — la même session est réutilisée. Utile lorsque la tâche accumule du contexte au fil du temps (p. ex. « interroge un point d'accès de statut toutes les 5 minutes et retiens ce que tu as observé »).

Les nouvelles exécutions sont plus sûres pour du travail parallèle ou sans lien. Les exécutions persistantes sont plus efficaces pour un observateur de longue durée.

La sortie de chaque tâche est livrée à votre message direct Slack (si configuré) et au panneau de notifications du tableau de bord.

Vous pouvez remplacer la livraison par exécution avec des marqueurs deliver: dans la requête ou dans HEARTBEAT.md :

- [ ] Monitor pipeline for failures  <!-- deliver:C0123CHANNEL -->

Cela achemine le résultat vers un canal Slack précis au lieu de votre message direct.

Les tâches cron persistent dans ~/.kiro/crew/crons.json et se chargent au démarrage de la passerelle. Le planificateur s'exécute en continu — tant que la passerelle est en marche, les tâches se déclenchent selon l'horaire.

Si la passerelle est arrêtée au moment où une tâche aurait dû se déclencher, l'exécution est manquée. Il n'y a pas de rattrapage au redémarrage — c'est un planificateur, pas une file d'attente.

Certaines configurations multi-instances ne veulent pas que le planificateur cron soit actif. Démarrez la passerelle avec --no-crons pour l'éviter :

kirocrew gateway --no-crons

Les tâches restent lisibles via kirocrew cron list, mais elles ne se déclencheront pas sur cette instance.

Les tâches cron qui déclenchent le Task Runner n'apparaissent pas dans la page Tasks du tableau de bord — elles sont filtrées pour garder la vue centrée sur le travail initié par l'utilisateur. Les tâches s'exécutent toujours; l'état est simplement caché de la liste visible.

Les exécutions cron sont sans surveillance par définition, donc elles ne portent jamais de confiance par exécution. Tout appel d'outil à l'intérieur d'une tâche cron :

• N'obtient jamais la confiance « approuver automatiquement cette session » propre au tableau de bord
• Respecte toujours les listes de refus des hooks, les blocages de chemins sensibles et les politiques de gouvernance
• Respecte toujours le remplacement global YOLO si celui-ci est actif

Étendre la confiance par exécution aux exécutions récurrentes n'est délibérément pas prise en charge — l'approbation automatique récurrente est un risque plus grand qu'une seule session interactive.

Les Heartbeats permettent à Crew de surveiller quelque chose au fil du temps sans que vous ayez à surveiller une session. Demandez dans le clavardage — « surveille cette pull request et dis-moi quand des commentaires arrivent » ou « surveille le pipeline et alerte-moi s'il passe au rouge » — et Crew crée une tâche heartbeat qui vérifie toutes les 60 secondes.

Contrairement aux tâches cron (qui exécutent une requête selon un horaire fixe), les Heartbeats sont réactifs — ils ne font apparaître des résultats que lorsque quelque chose change.

Les tâches Heartbeat vivent dans ~/.kiro/crew/workspace/HEARTBEAT.md. Le service heartbeat lit le fichier toutes les 60 secondes, exécute toutes les tâches en parallèle et :

• En cas de succès — efface la tâche (la condition a été remplie)
• En cas d'échec — la réécrit pour une nouvelle tentative au prochain cycle
• Lors de la livraison — achemine les résultats vers votre surface configurée

Par défaut, les résultats vont vers votre message direct Slack ou les notifications du tableau de bord. Remplacez cela par tâche avec un marqueur de livraison dans le fichier heartbeat : <!-- deliver:C0123CHANNEL --> achemine vers un canal Slack précis.

Des systèmes externes peuvent déclencher des sessions d'agent Crew via HTTP. Un pipeline d'intégration continue peut aviser Crew lorsqu'une build échoue, ou un outil de surveillance peut escalader une alerte — tout cela sans que personne soit au terminal.

Le point d'accès :

POST /api/hooks/agent
Authorization: Bearer <token>
Content-Type: application/json

{
  "message": "Build failed for pipeline X. Check logs and report the root cause."
}

Les requêtes nécessitent un jeton Bearer valide (générez-en un avec kirocrew token). Jusqu'à 6 sessions webhook simultanées; chacune a un délai d'expiration par défaut de 10 minutes.

Exemple — alerte d'échec d'intégration continue :

curl -X POST http://localhost:5476/api/hooks/agent \
  -H "Authorization: Bearer $KIROCREW_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"message": "Build failed. Summarize what went wrong."}'

Crew analyse l'échec et répond. Le résultat est acheminé vers votre surface de notification configurée.

Pour les flux de travail persistants qui transportent le contexte à travers plusieurs appels webhook (p. ex. un pipeline à plusieurs étapes), l'agent peut utiliser register_hook pour enregistrer l'état du flux de travail que le prochain appel webhook récupère.

Pour une surveillance qui reste au sein d'une session active (plutôt qu'un heartbeat en arrière-plan), Crew dispose de l'autonudge — une boucle d'autovérification qui réinjecte vos instructions selon une minuterie d'inactivité.

Utilisez-le lorsque vous voulez que Crew continue de vérifier quelque chose dans votre conversation actuelle :

• « Continue de vérifier ceci toutes les 5 minutes et dis-moi si ça change »
• « Surveille ce déploiement et alerte-moi quand c'est terminé »

Autonudge fonctionne depuis le clavardage du tableau de bord, les fils Slack et les messages directs Discord. Arrêtez-le en envoyant un nouveau message qui prend le relais de la session, ou avec l'outil autonudge_stop.