Monitors persistants

Les monitors persistants et les surveillances de carte permettent à un agent de continuer à attendre après la fin de son propre processus. Le démon Stib les stocke sur la carte et reprend un agent inactif quand quelque chose se produit : un monitor exécute une commande à l'intervalle demandé et rapporte sa sortie stdout ; une surveillance de carte attend que l'agent d'une autre carte s'arrête, ou qu'il soit au repos.

Surveillances de carte

stib monitor watch-card 905 --description 'Verifone type 14'
stib monitor list
stib monitor unwatch 3

Une surveillance de carte ne demande ni commande ni identifiant : le serveur lit lui-même l'état de la carte cible. La cible doit être une autre carte du même projet dont l'agent tourne. Sinon, la création est refusée avec CARD_WATCH_TARGET_NOT_RUNNING et l'état actuel de la cible : l'agent peut le rapporter aussitôt au lieu de promettre une notification. La cible accepte les mêmes références que les autres commandes de carte (905, "#905", id:905, STIB-12).

La surveillance se déclenche une seule fois, puis disparaît. Elle se déclenche quand le tour de la cible se termine (idle, succès ou erreur), quand son agent attend une réponse de l'utilisateur ou l'approbation d'un plan, et quand la cible est archivée, mise à la corbeille, supprimée ou déplacée dans une colonne passive. Les attentes qui relèvent de Stib et non de l'agent — un contexte saturé en attente d'une nouvelle session, un démarrage différé, une reprise après quota — la laissent armée, tout comme un passage de colonne automatique qui relance l'agent en quelques secondes. Une surveillance déclenchée pendant que Stib était arrêté est livrée après le redémarrage.

Jusqu'à ce que la carte soit au repos

Une carte dont le tour est fini n'a pas toujours terminé : son agent peut encore faire tourner des tâches de fond ou des sous-agents, ou avoir programmé un réveil, et Claude Code reprend seul quand ils se terminent. Pour être prévenu de la vraie fin, armez la surveillance avec --until settled :

stib monitor watch-card 905 --until settled --description 'Revue de #905'

Une surveillance settled se déclenche quand la cible est arrêtée sans tâche de fond, sous-agent, réveil programmé ni reprise attendue. Elle se déclenche aussi tout de suite quand la cible attend une réponse de l'utilisateur ou l'approbation d'un plan, et quand elle est archivée, mise à la corbeille ou supprimée. Une cible déplacée dans une colonne passive la déclenche une fois son travail en fond terminé. Elle accepte une cible déjà arrêtée qui a encore du travail en fond ; une surveillance simple refuse cette cible, et son refus suggère --until settled. Une carte n'a qu'une surveillance par cible : pour changer de mode, retirez-la avec unwatch puis armez-en une nouvelle.

Une tâche de fond sans fin, comme un serveur de dev, retient une surveillance settled jusqu'au plafond « tâche de fond » (6 heures par défaut, réglable), qui abandonne la tâche : la carte passe alors au repos et la surveillance se déclenche. Si ce plafond est levé, rien ne borne l'attente et unwatch reste la sortie. Les agents Codex et ACP ne signalent pas de tâches de fond : pour eux, au repos veut dire arrêté.

Dans les deux modes, la ligne d'événement d'une cible arrêtée avec du travail en fond dit ce qui reste à venir, par exemple card #stib:905 "Title" stopped: success — 2 background tasks still running, the card will resume.

Les agents lisent le même état sur les cartes : stib cards get et chaque élément de stib cards list portent settled et background (tasks, subagents, wakeupAt, resumeExpected), et stib cards tasks 905 liste les tâches de fond qui tournent encore sur une carte du même projet.

Les autres erreurs stables sont CARD_WATCH_SELF, CARD_WATCH_TARGET_NOT_FOUND, CARD_WATCH_ALREADY_ARMED, CARD_WATCH_LIMIT_REACHED et, pour une carte qui a quitté sa colonne active, CARD_WATCH_CARD_INACTIVE. Une conversation de project agent peut surveiller des cartes, bien que sa carte vive dans une colonne passive. Face à un serveur sans surveillances de carte, watch-card refuse en demandant une mise à jour, et list ne montre que les monitors.

Monitors de commande

Droits du serveur

Les commandes des monitors tournent hors de la sandbox agent, avec les droits système du serveur Stib. N'utilisez que des commandes de confiance. --allow-unsandboxed est un acquittement obligatoire et persistant de cette frontière de sécurité.

stib monitor add --cmd 'git fetch --quiet && ./check-ci' --interval 45s --description 'État CI' --allow-unsandboxed
stib monitor list
stib monitor remove 42

add accepte des intervalles de 10s à 24h. Sa description optionnelle prend par défaut un extrait lisible de la commande. La CLI s'authentifie avec le nonce de la carte courante et le scope self : un agent ne peut donc gérer que les monitors et les surveillances de sa propre carte.

Une commande de monitor tourne dans l'environnement du serveur, sans identifiants Stib : la CLI stib ne peut pas s'y authentifier. Pour attendre une autre carte, utilisez une surveillance de carte.

add attend le premier run du monitor et en rend compte : first run: success, ou l'échec avec son erreur et le code de sortie 4, ou un avertissement si le run ne s'est pas terminé dans son délai plus une marge de planification. Le monitor reste armé dans tous les cas. L'échec est aussi mis en file comme événement : retirer le monitor pendant le même tour le supprime avant qu'il n'atteigne l'agent, tandis qu'un monitor laissé armé le livre dès que la carte est inactive.

Exécution et événements

Le démon lance un monitor immédiatement au démarrage ou après sa création. Un monitor ne se chevauche jamais avec lui-même : le délai suivant commence après la fin du run précédent. Le serveur exécute au plus quatre commandes monitor à la fois, et chaque run expire après le minimum entre son intervalle et 60 secondes.

Chaque ligne stdout est un événement. Stderr est drainé et conservé comme diagnostic. Les événements de tous les monitors et surveillances d'une carte sont ordonnés, regroupés pendant 10 secondes, puis livrés par follow-ups de 100 événements ou 32 Kio maximum. Le reliquat part dans les lots suivants. Les lignes et la sortie totale sont bornées ; des marqueurs explicites signalent les troncatures.

Les événements attendent tant que l'agent travaille, attend l'utilisateur ou une approbation de plan. La livraison reprend par le mécanisme normal de follow-up dès que la carte est inactive.

Notifications

Un follow-up déclenché par un monitor ou une surveillance appartient à la personne qui a lancé le run d'agent qui l'a armé. La réponse de l'agent aux événements produit donc les mêmes notifications desktop et mobile qu'une réponse à un message de cette personne. Une personne qui a perdu entre-temps l'accès au projet n'est pas notifiée, et les monitors armés par une automatisation ne notifient personne.

Répertoire et cycle de vie

La CLI capture son répertoire courant. Le serveur n'accepte que le dépôt, le worktree géré ou un worktree attaché appartenant à la carte. Si ce répertoire disparaît, les runs suivants retombent sur le chemin actuel du dépôt du projet sans recréer de worktree.

Les monitors et surveillances sont supprimés définitivement lorsque leur carte quitte une colonne active, est archivée, mise à la corbeille ou supprimée, ainsi que lorsque sa colonne devient passive. Une conversation de project agent les garde dans sa colonne passive ; la réinitialiser ou la supprimer les retire. Retirer un monitor ou arrêter Stib termine puis récolte sa commande et ses descendants.

Les limites sont de huit monitors et 32 surveillances par carte, 16 Kio par ligne et 1 Mio de sortie collectée par run. Les erreurs de création stables incluent MONITOR_UNSANDBOXED_ACK_REQUIRED, MONITOR_INTERVAL_INVALID, MONITOR_CWD_OUTSIDE_CARD et MONITOR_LIMIT_REACHED.