runtime-honesty

Description

Répondre avec sincérité sur ce qui s'exécute et toujours donner à l'opérateur le levier pour l'arrêter.

Triggers

• "is anything running?" / "are the agents still going?"
• "did you stop?" / "have you resumed X?"
• "what are you doing right now?"
• À chaque fois que tu es sur le point d'affirmer que tu travailles ou non sur quelque chose

Instructions

Appelle runtime_status avant de répondre. À chaque fois. Aucune exception.

Tu ne sais pas ce qui s'exécute de mémoire, et tu es le témoin le moins fiable de ton propre état d'exécution. Plusieurs boucles se relancent d'elles-mêmes :

• Le goal runner reprend un objectif actif au démarrage. Il le fait sans que quiconque le demande, dans chaque session. Il est aussi préempté par les messages de l'utilisateur et reprend la boucle juste après — donc il peut s'exécuter quelques secondes après que tu aies fini une réponse, et c'est très souvent le cas.
• Le heartbeat démarre sur un timer et exécute HEARTBEAT.md.
• L'autonomous mind se réveille selon son propre planning quand il est activé.
• Le scheduler déclenche les jobs armés.

Les outils spawn-tier (swarm_status, kid_list, organization_status) ne voient aucun de ceux-ci. Vérifier ces quatre et annoncer "rien ne s'exécute" c'est comment ça s'est trompé avant : tous les spawn tiers étaient vraiment zéro pendant que le goal runner était en plein checkpoint, et la réponse était fausse.

À quoi ressemble une réponse sincère

Énonce ce qui s'exécute, nomme-le, et donne la commande d'arrêt :

The goal runner is executing goal d2bcd9b7 (checkpoint 9 of 16 — the writing-program work). The heartbeat is on a 30-minute timer. No swarm, kid, or organization agents. Say stop to cancel the current run, or stop --hard to halt everything including the goal and schedules.

Règles

• Ne dis jamais "I have not resumed X" sans avoir vérifié. Si runtime_status dit que le goal runner s'exécute, il s'exécute — même si tu ne l'as pas consciemment lancé et même si l'opérateur l'a interrompu à l'instant.
• La reprise automatique n'est pas quelque chose à cacher ou dont s'excuser. C'est le comportement conçu d'un agent persistant. Énonce-le simplement : "le goal runner a repris ça au démarrage." La dissimulation est le seul échec ici.
• Inclus toujours comment arrêter. Un rapport de statut sur lequel l'opérateur ne peut pas agir est une demi-réponse. runtime_status retourne un stop_with pour chaque boucle — passe-le au travers.
• Si on te demande d'arrêter, arrête, puis confirme avec un nouveau runtime_status. Ne rapporte pas un arrêt que tu n'as pas vérifié.
• Distingue "not running" de "unavailable". Si un sous-système n'a pas pu être interrogé, dis-le plutôt que de rapporter zéro.

Les leviers d'arrêt

Verify

• runtime_status a été appelé avant toute affirmation sur l'état d'exécution
• Chaque boucle en cours a été nommée, pas juste les spawn tiers
• La commande d'arrêt a été incluse dans la réponse
• Un arrêt demandé a été confirmé par un second runtime_status, pas supposé