Volet de configuration

zerocode, le volet Config configure un ZeroClaw en cours d’exécution. Chaque paramètre dispose d’un contrôle typé, d’une validation et d’une explication intégrée. Une sauvegarde réussie persiste la modification, tandis que son application aux composants en cours d’exécution dépend du paramètre et de la cible. Ouvrez Config depuis n’importe quelle session zerocode pour modifier les paramètres.

Les paramètres sont toujours persistés dans votre configuration, et la documentation décrit les champs concernés afin que vous puissiez voir exactement ce qu’écrit un contrôle donné. Lisez ces descriptions comme le résultat persisté, et non comme une instruction d’ouvrir le fichier dans un éditeur. La modification manuelle est une solution de repli pour les hôtes sans interface graphique et le provisionnement par scripts, lorsque la documentation le mentionne explicitement.

Modificateurs de raccourcis clavier

Les raccourcis clavier utilisent des noms canoniques de modificateurs : control désigne littéralement Control, primary désigne Command sur macOS et Control ailleurs, et super désigne littéralement Super/Command. Par exemple, control+c, primary+r et alt+shift+up sont des valeurs portables persistées. Les anciennes valeurs ctrl+... sont migrées une fois lors du chargement de la configuration et réécrites avec l’orthographe canonique correspondante.

Pourquoi le volet au-dessus du fichier

• Validation. Les contrôles rejettent les valeurs mal formées avant qu’elles n’atteignent le démon, de sorte qu’une faute de frappe ne peut pas laisser la configuration dans un état qui échoue au chargement.
• Découvrabilité. Chaque paramètre comporte une description en ligne, vous n’avez donc pas besoin de consulter la référence de configuration pour savoir à quoi sert un champ.
• Retour de l’application. Les modifications enregistrées affichent les résultats d’application confirmés pour les cibles en cours d’exécution concernées lorsque le démon les prend en charge. Les autres paramètres nécessitent un rechargement explicite.
• Listes basées sur le registre. Les choix de fournisseur, de canal, de modèle et de thème proviennent du registre du backend, donc les options affichées sont exactement celles prises en charge par cette version.

Modifications enregistrées et appliquées

Après la réussite d’une modification de la configuration du démon, le résumé de l’application conserve la propriété enregistrée et sa révision séparées des résultats des cibles en cours d’exécution. Appuyez sur s en dehors d’un éditeur ou d’un champ de recherche pour ouvrir l’état de l’application. Utilisez Haut/Bas ou Page précédente/Page suivante pour faire défiler, et Échap pour revenir. L’action configurée application_status peut remplacer le raccourci par défaut.

Chaque résultat affiche les composants de chemin canoniques, sa révision et l’instance du démon ou de la session qu’il décrit. Une session peut afficher Appliqué à chaud alors que le démon affiche toujours Rechargement requis pour la même modification. En attente signifie que la cible n’a pas accusé réception de la mise à jour ; Rejeté signifie que la cible tentée n’a pas accepté celle-ci. La prise en charge du schéma et une sauvegarde réussie ne suffisent pas, à elles seules, à établir que la modification a été appliquée.

Un reçu manquant, une API de statut non prise en charge, une lecture échouée, une époque de daemon de remplacement ou un résultat manquant affiche Statut de l’application indisponible. Le daemon conserve un ensemble borné de modifications observées, et non un inventaire complet ni un historique persistant. La troncature et les enregistrements absents n’impliquent jamais un succès. Les résultats d’une modification plus ancienne et sans rapport conservent leur révision réelle ; les résultats d’une modification ultérieure effectuée par un autre rédacteur ne peuvent pas confirmer votre enregistrement. Les opérations d’alias acheminées par des méthodes de cycle de vie distinctes peuvent ne pas avoir de reçu d’enregistrement et restent indisponibles pour le retour d’information d’enregistrement exact.

Le statut de l’application est actualisé pendant que Config est affiché. Quitter Config ou perdre la connexion invalide sa vue en cache de l’application. Le rechargement passe toujours par l’action de rechargement explicite existante et sa confirmation ; la simple lecture du statut ne le déclenche pas. Les paramètres locaux de ZeroCode, les fichiers de personnalité et les fichiers de compétences conservent leur propre retour d’enregistrement, car ils ne partagent pas le registre d’application de la configuration du démon.

Paramètres locaux de l’interface utilisateur (zerocode-config.toml)

Certains paramètres décrivent comment zerocode lui-même affiche ses volets, plutôt que le comportement du démon. Ils figurent dans le fichier propre à zerocode, <config-dir>/zerocode-config.toml, et se modifient depuis le volet Config de zerocode.

Le suivi TodoWrite en fait partie. Il s’agit uniquement d’un élément d’affichage : le démon se contente d’émettre les mises à jour du plan et, via ACP, le client contrôle entièrement le formatage ; il relève donc de zerocode :

[todotracker]
enabled = true           # interrupteur principal ; lorsque false, le suivi n'est jamais affiché
enabled_at_start = false # visible au lancement, avant l'arrivée du premier plan
location = "right"       # "bottom", "left" ou "right"
width = 32               # largeur de colonne cible du panneau latéral (gauche/droite)
max_height = 5           # hauteur maximale de la barre inférieure en lignes

The shell-level agent sidebar is stored in the same file. The default section is serialized explicitly so environment overrides have a schema node to target:

Wait, that’s not right. Let me give the actual translation.

La barre latérale d’agent au niveau du shell est stockée dans le même fichier. La section par défaut est sérialisée explicitement afin que les surcharges d’environnement disposent d’un nœud de schéma à cibler :

[sidebar]
visible = true # show the agent/session sidebar at launch
width = 24     # target width in terminal columns

Appuyez sur Ctrl+B pour afficher ou masquer la barre latérale. Quickstart reste accessible depuis la barre de mode clavier et apparaît aussi comme lanceur dans la barre latérale, y compris sur les terminaux étroits. Sélectionner un agent existant dans la barre latérale démarre une nouvelle session Chat ou Code sans remplacer les autres sessions déjà suivies par ce volet.

TodoWrite values are re-read at every session boundary, so an edit made in the Config pane applies to the next session you start, restart, or switch to, with no zerocode restart needed.

Wait, I need to correct that: the translation should be in French. Here it is:

Les valeurs de TodoWrite sont relues à chaque limite de session, de sorte qu’une modification effectuée dans le volet Config s’applique à la prochaine session que vous démarrez, redémarrez ou vers laquelle vous basculez, sans qu’il soit nécessaire de redémarrer zerocode.

Surcharges de l’environnement

Chaque champ peut être remplacé pour une seule exécution au moyen d’une variable ZEROCODE_. La syntaxe est le préfixe suivi du chemin de configuration en minuscules, où . est noté __ :

ZEROCODE_todotracker__enabled=false zerocode
ZEROCODE_todotracker__location=bas zerocode
ZEROCODE_sidebar__visible=false zerocode

Ces remplacements sont transitoires au niveau du processus : ils n’affectent que l’instance en cours d’exécution et ne sont jamais réécrits dans zerocode-config.toml. Enregistrer un champ non apparenté dans le volet Config n’enregistrera pas dans le fichier une valeur injectée par une variable d’environnement.

Mise à niveau depuis un [todotracker] géré par un démon

Avant le déplacement de ce paramètre, [todotracker] était une section du config.toml du daemon. Si vous l’y avez défini, recopiez les valeurs :

1. Ouvrez le fichier config.toml de votre démon et notez les valeurs de [todotracker].
2. Placez le même bloc dans <config-dir>/zerocode-config.toml (indiqué ci-dessus), ou définissez-les depuis Configuration → Suivi des tâches.
3. Supprimez la section [todotracker] du fichier config.toml du démon.

Les variables d’environnement ZEROCLAW_todotracker__* existantes n’ont pas besoin d’être supprimées avant la mise à niveau : les cinq champs reconnus (enabled, enabled_at_start, location, width, max_height) sont acceptés et ignorés par le démon, de sorte qu’un déploiement qui fonctionnait auparavant démarre toujours. Ils n’ont plus aucun effet ; remplacez-les donc par la syntaxe ZEROCODE_ indiquée ci-dessus.