Goals

Un Goal maintient Qwen Code en activité à travers les tours jusqu’à ce qu’une condition déclarée soit remplie. Définissez-en un avec /goal <objective>, et la session continue d’elle-même. Chaque tour est enregistré comme preuve ; lorsque le modèle propose que l’objectif est terminé ou bloqué, un vérificateur indépendant juge cette proposition à partir des preuves uniquement. La session s’arrête lorsque le vérificateur accepte, ou lorsque le Goal est mis en pause, effacé ou arrêté par une limite.

Commandes

Créer, modifier ou reprendre un Goal nécessite un workspace de confiance (/trust). L’utilisation headless est couverte dans Mode Headless.

Une fois qu’un Goal a facturé un tour, la pilule de pied de page et chaque carte de statut affichent ce qu’il a dépensé par rapport à la fenêtre autorisée, sous la forme 1.2k/30.0m. Le chiffre compte les appels de modèle que le Goal fait dans ses propres tours ; les sous-agents et les vérifications du vérificateur ne sont pas inclus. La fenêtre est définie par model.goalTokenBudget ; reprendre un Goal qui a épuisé sa fenêtre en accorde une nouvelle en plus de ce qu’il a déjà dépensé, donc le chiffre affiche 30.0m/60.0m au lieu de recommencer à zéro. Un Goal sans budget affiche uniquement ce qu’il a dépensé. Un Goal qui n’a pas encore facturé de tour n’affiche aucun chiffre.

Deux fenêtres supplémentaires sont disponibles et désactivées par défaut : model.goalMaxTurns limite le nombre de tours qu’un Goal peut terminer, y compris les tours de Goal pilotés par l’utilisateur, et model.goalMaxActiveMinutes limite le temps réel pendant qu’il reste actif dans un processus en cours d’exécution, y compris les attentes et les temps d’inactivité entre les tours. Le temps pendant lequel le Goal est en pause, bloqué ou arrêté ne compte pas dans la seconde fenêtre, pas plus que les temps d’arrêt entre les redémarrages ; un processus simplement suspendu est toujours comptabilisé. Quelle que soit la fenêtre qui s’épuise en premier, le Goal reçoit le même et unique tour de clôture pour transmettre le relais puis s’arrête jusqu’à ce que vous le repreniez, et la reprise autorise une nouvelle fenêtre en plus de ce qui a déjà été utilisé. Seule la fenêtre qui s’est épuisée avance ; les autres restent où elles étaient, et le -1 opt-out retire également uniquement un plafond qu’un Goal a déjà atteint. La fenêtre temporelle est lue entre les tours plutôt qu’imposée par un minuteur, donc un Goal peut largement dépasser sa limite avant de s’arrêter : un tour déjà en cours n’est jamais interrompu, et une fenêtre qui s’épuise alors qu’aucun tour n’est en cours n’est détectée qu’à la fin du tour suivant. Le temps actif est compté entre les transitions enregistrées, donc le temps d’un tour interrompu par un redémarrage n’est pas comptabilisé. Les modifications de l’un ou l’autre paramètre prennent effet après le redémarrage. Les deux fenêtres ne s’arment que pour un Goal créé après le changement, donc borner un Goal déjà enregistré signifie le remplacer par /goal set — un nouveau Goal à la révision 1, avec ses compteurs de tours, de tokens et de temps actif remis à zéro et sa fenêtre de preuves démarrant au remplacement, de sorte que les preuves enregistrées par l’ancien Goal ne sont plus citables — ou l’effacer et recommencer. Une reprise ou une modification n’ajoute jamais un plafond qui n’était pas armé à la création.

Chaque tour que la session entreprend d’elle-même signale ce que le Goal a dépensé jusqu’à présent, combien de tours le soutiennent, et — sauf si le Goal s’exécute sans limite — la fenêtre qui lui est autorisée. Chacun de ces tours, sauf la transmission finale de clôture, porte également des instructions permanentes pour revérifier le workspace plutôt que faire confiance aux rapports des tours précédents, pour travailler vers l’état final demandé par l’objectif, pour faire autrement lorsque le tour précédent n’a rien changé (à partir du deuxième tour, dès qu’il y a un tour précédent à juger), et pour vérifier chaque exigence par rapport à des preuves citables avant de proposer que le Goal est terminé.

Un Goal long comprime périodiquement les preuves qu’il a enregistrées en revendications de checkpoint avec un appel à un modèle secondaire, afin que les tours ultérieurs et le vérificateur puissent encore les citer. Le contrôle est borné par model.goalCheckpointTimeoutSeconds, 180 secondes par défaut. Une réponse entourée d’une fence markdown est lue sans la fence. Si ses revendications dépassent le budget d’octets agrégé, incluent une revendication au-delà de la limite de caractères par revendication, un nombre supérieur à ce qu’un seul checkpoint peut contenir, citent un identifiant qui n’était pas dans la requête, ou changent le type de preuve d’une source qu’elles citent, il effectue un appel de modèle correctif qui nomme ce qui était erroné, et les deux appels partagent ce plafond. Une réponse qui n’est pas un objet JSON contenant un tableau claims non vide ne reçoit pas d’appel correctif, pas plus qu’une réponse contenant une revendication malformée, même à côté de revendications utilisables : une clé supplémentaire à l’un ou l’autre niveau, un proofKind non reconnu, une revendication vide, ou une liste sourceRefs vide, contenant un identifiant non-string ou vide, répétant un identifiant, ou contenant plus de 32 identifiants. Un contrôle qui ne se termine pas à temps est abandonné comme non concluant ; il compte dans la limite de blocages de checkpoint uniquement lorsque la fenêtre de preuves a débordé, tandis qu’un contrôle sans débordement préserve la série et réessaie à un tour ultérieur. Les appels sont diffusés en flux, donc le timeout de transport par requête ne borne que la connexion et la première réponse, et le plafond lui-même s’arrête à la limite de durée de vie de 15 minutes des gardes du flux parce qu’au-delà, c’est le garde, et non le paramètre, qui termine l’appel. Cette limite de 15 minutes sur le paramètre est fixe, et augmenter le propre plafond du garde du flux ne la lève pas.

Un checkpoint défaillant apparaît avant qu’il n’arrête le Goal. Pendant que la série de blocages d’un Goal actif s’allonge, la pilule de pied de page passe d’elle-même à checkpoint N/3 stalled ; une fois le Goal en pause ou arrêté, la pilule affiche ce statut à la place. La barre de statut Goal du Web Shell affiche le compte quel que soit le statut. Chaque fois qu’une carte de statut terminal de Goal est affichée, par exemple par /goal ou par une carte de pause, reprise ou vérification, elle indique combien de vérifications consécutives ont bloqué sur les trois autorisées par le Goal, ainsi que le dernier échec lorsqu’il y en a un ; la boîte de dialogue Goals du Web Shell et la sortie texte /goal headless affichent la même ligne, tandis que les cartes transcript du Web Shell pour les événements de Goal affichent uniquement la raison de l’arrêt, et le modèle voit les deux champs lorsqu’il lit le Goal. Une vérification qui échoue alors que la fenêtre a encore de la place est également affichée, sans dépenser un blocage, mais uniquement pendant que le Goal est actif, ou lorsque cet échec est lui-même ce qui a arrêté le Goal, comme avec une requête de checkpoint trop volumineuse pour être envoyée. Un arrêt de checkpoint pour toute autre raison efface l’échec et conserve la série, et un Goal terminé n’affiche aucune ligne de checkpoint. L’échec est conservé sur une seule ligne avec les caractères de contrôle supprimés. Un Goal arrêté par trois checkpoints bloqués nomme ce sur quoi le dernier a buté. Une vérification qui n’a pas pu faire tenir la fenêtre dans les limites des revendications de checkpoint, qu’il s’agisse d’une liste complète de revendications qui a tout de même laissé des preuves de côté ou de revendications dépassant le budget de nombre ou de taille de revendications, signifie que l’objectif produit plus de preuves qu’une seule fenêtre ne peut en contenir, donc réduisez-le. Une réponse qui n’a pas pu être intégrée dans des revendications signifie que le modèle de checkpoint ne renvoie pas la sortie structurée demandée, et réduire l’objectif ne corrige pas cela. Une vérification qui n’a jamais répondu peut indiquer un fournisseur inaccessible ou limité par un throttle, une vérification qui ne s’est pas terminée dans les model.goalCheckpointTimeoutSeconds, ou une erreur dans la vérification elle-même ; l’échec enregistré indique lequel. Reprendre après l’un des trois types démarre une nouvelle fenêtre de preuves.

Interrompre un Goal

Annuler un tour de Goal met le Goal en pause. Appuyez sur Échap pendant que le modèle répond ou pendant que ses outils sont encore en cours d’exécution, et le tour s’arrête, le Goal passe à paused, et la carte et /goal indiquent tous deux pourquoi il s’est arrêté. Rien ne continue tant que vous n’avez pas exécuté /goal resume.

Taper un message pendant qu’un Goal est actif ne le met pas en pause. Votre message s’exécute comme le prochain tour du Goal, utilisez-le donc pour orienter le travail ; utilisez /goal pause ou /goal clear pour l’arrêter.

Chaque pause indique sa raison : vous l’avez interrompu, vous avez exécuté /goal pause, la limite de tokens de la session a bloqué la prochaine requête modèle, que le tour a échoué, ou que trois tours d’affilée n’ont rien enregistré que le vérificateur puisse juger et aucune proposition — les opérations de comptabilité du Goal (get_goal, update_goal) ne comptent pas comme de la progression. Un Goal arrêté par une limite conserve la raison de cette limite à la place.

Comment un Goal est évalué

Le vérificateur n’exécute jamais de commandes ni ne lit de fichiers de lui-même. Il ne voit que ce qui est déjà dans la transcription :

• Les sorties visibles de l’assistant et les résultats d’outils comptent comme des preuves. Le texte de l’objectif, vos prompts et le raisonnement caché du modèle ne comptent pas.
• Du texte affiché prouve seulement que du texte a été affiché. Une affirmation selon laquelle des tests passent, qu’un fichier a été modifié ou qu’une remote est mise à jour nécessite le résultat d’outil correspondant dans la transcription.
• Une affirmation selon laquelle vous avez confirmé, choisi ou approuvé quelque chose nécessite un vrai message de votre part ; le vérificateur rejette les propositions qui le supposent.
• Lorsque la preuve est absente, le verdict est « pas encore », pas « terminé ». Une condition que personne ne peut étayer maintient la boucle en activité jusqu’à ce qu’une limite l’arrête.

L’objectif doit donc amener l’agent à produire des preuves : exécuter la vérification nommée et montrer la sortie décisive.

Rédiger un bon objectif

Incorpérez ces éléments dans l’objectif, dans cet ordre :

Limitez-vous à un seul objectif. /goal set et /goal edit acceptent n’importe quelle longueur, mais restez environ en dessous de 1 200 caractères : l’objectif est renvoyé à chaque tour du Goal. Un objectif que le modèle propose via propose_goal est limité à 1 500 caractères. Les deux commandes fusionnent les sauts de ligne en espaces, numérotez donc les éléments plutôt que de compter sur les retours à la ligne.

Budget est une instruction au modèle sur le moment d’arrêter et de signaler un bloqueur ; le modèle peut ou non la respecter. Pour que le runtime lui-même s’arrête à un nombre de tours ou une durée, définissez model.goalMaxTurns ou model.goalMaxActiveMinutes. Écrire l’un ou l’autre dans l’objectif ne les configure pas, et ne modifie pas le budget de tokens du Goal.

Laissez /goal-draft le rédiger

/goal-draft <ce que vous voulez faire> est un skill intégré qui fait ce qui précède pour vous. Il ne lit que ce qu’il faut du workspace pour établir le périmètre et les vraies commandes de vérification, sans exécuter de tests, sans construire, sans installer de dépendances ni démarrer de services. Il pose au maximum un tour de questions lorsque des choix essentiels ne sont pas clairs, puis rédige un objectif compact, généralement avec 3 à 5 vérifications de complétion (moins lorsque c’est suffisant). Les exigences explicites sont préservées ; il n’ajoute pas de vérifications juste pour atteindre un compte.

Pour un audit, la complétion signifie couvrir les scénarios convenus et rapporter les preuves, y compris les étapes de reproduction pour les défauts confirmés. Ne trouver aucun défaut est un résultat valide. Le draft ne doit pas inventer un nombre minimum de scénarios, de fichiers de preuve, de tours d’exploration ou de défauts.

Si un critère de succès, une commande, un chemin d’entrée ou une décision essentielle ne peut pas être établi, le skill retourne un draft marqué « Needs clarification » avec des éléments <TODO: …>. Il ne propose pas ce draft pour approbation ni n’affiche de commande /goal set ou /goal edit exécutable. Les valeurs par défaut non essentielles sont marquées [ASSUMPTION] ; elles ne se substituent pas à des critères de succès manquants.

Une fois l’objectif prêt, une session terminal interactive ou Web Shell peut afficher la boîte de dialogue d’approbation propose_goal décrite ci-dessous. Les clients sans prise en charge des propositions de Goal, les exécutions headless, les sessions avec l’outil désactivé et les sessions avec un Goal actif reçoivent plutôt une commande à exécuter manuellement. La transmission indique que le draft n’a pas été appliqué. Le skill ne démarre jamais le travail lui-même, et rien n’est défini sans votre approbation.

Passez un objectif existant pour le renforcer : /goal-draft all tests pass and the lint is clean. Pour un Goal actif, une demande explicite de le renforcer produit /goal edit ; un remplacement utilise /goal set. Si l’opération souhaitée n’est pas claire, le skill inclut ce choix dans son unique tour de questions.

Approuver un Goal proposé par le modèle

Dans une session terminal interactive ou un tour Web Shell avec un client rattaché, le modèle dispose d’un outil propose_goal. Lorsque /goal-draft se termine, ou lorsque vous demandez un résultat qui s’étend sur plusieurs tours, il peut proposer l’objectif au lieu d’afficher une ligne /goal set … à copier. La proposition apparaît sous forme d’une boîte de dialogue d’approbation affichant l’objectif complet. L’approuver définit le Goal exactement comme le ferait /goal set, au moment où le tour en cours se termine (le modèle acquiesce et s’arrête ; le premier tour du Goal démarre alors de lui-même), et la refuser ne définit rien — le modèle voit uniquement que l’appel d’outil n’a pas été autorisé, et ses instructions lui disent de ne pas demander pourquoi et de ne pas proposer le même objectif à nouveau. L’approbation est liée au tour qui l’a demandée : si ce tour est annulé ou n’atteint jamais sa fin, l’approbation est abandonnée plutôt qu’appliquée sous un message ultérieur ou un tour automatisé. Aucune règle de permission ni mode d’approbation (y compris YOLO) ne contourne cette boîte de dialogue, et l’outil refuse lorsqu’un autre Goal est actif, en mode plan et dans les dossiers non fiables ; les sous-agents ne se le voient jamais proposer. Web Shell utilise son panneau de permission Allow/Reject existant. Un Goal arrêté ne peut être remplacé que s’il correspond encore à la version affichée pour approbation ; le modifier invalide la proposition. Les exécutions headless, les livraisons de canal Web Shell et les tours automatiques, ainsi que les clients ACP sans la prise en charge requise de l’approbation et du cycle de vie des tours conservent la transmission par commande /goal set affichée.

Désactivez-le avec goals.modelProposed: "disabled" dans vos paramètres utilisateur. Parce que ce paramètre décide si le modèle peut vous demander de démarrer une boucle autonome, il est honoré uniquement depuis les portées utilisateur et système ; une valeur dans un .qwen/settings.json de workspace est ignorée avec un avertissement.

Le skill est configuré pour être en lecture seule, et seuls ses outils non mutatifs sont auto-approuvés (get_goal, read_file, glob, grep_search). ask_user_question n’est volontairement pas auto-approuvé, donc sa boîte de dialogue de questions est affichée avant que le skill ne rédige à partir de vos réponses. Comme les autres skills intégrés, un skill de projet ou personnel nommé goal-draft le remplace, et skills.disabled peut le désactiver. Consultez Skills pour savoir comment les skills intégrés sont découverts.