Configuration

Qu’est-ce que la configuration CLI ?

La configuration regroupe les paramètres qui influencent le comportement du CLI sans faire partie directement de votre demande. Elle peut concerner l’environnement de travail, le projet courant, les préférences utilisateur ou les intégrations activées.

Une bonne configuration doit rester prévisible, explicite et facile à diagnostiquer. L’utilisateur doit pouvoir comprendre pourquoi un comportement change d’un projet ou d’un environnement à un autre.

Cette page ne suppose aucun format précis comme YAML, JSON ou TOML tant qu’OrbitWake n’a pas publié officiellement le mécanisme correspondant.

Niveaux de configuration

Un CLI moderne peut avoir plusieurs niveaux de configuration. OrbitWake doit distinguer clairement leur portée afin d’éviter qu’un réglage local ne modifie involontairement tous les projets de l’utilisateur.

Les mécanismes exacts utilisés par OrbitWake pour représenter ces niveaux seront documentés lorsqu’ils seront stabilisés.

Configuration liée à l’environnement

Le CLI s’exécute dans un environnement shell qui possède déjà son propre contexte : système d’exploitation, variables d’environnement, PATH, outils installés, accès réseau et permissions du compte local.

Ces éléments peuvent influencer le comportement d’une tâche. Par exemple, une commande disponible sur une machine peut être absente sur une autre, ou une variable d’environnement peut changer l’accès à un service.

OrbitWake doit éviter d’exposer ou de consommer des informations sensibles sans nécessité. Les variables contenant des secrets doivent être traitées avec prudence et ne pas être affichées intégralement dans les logs ou les réponses.

Configuration spécifique au projet

Certains comportements ont du sens uniquement pour un projet donné : structure du dépôt, conventions internes, scripts de test, chemins importants ou politiques de déploiement.

Un réglage de projet doit rester isolé à ce projet et ne pas changer le comportement d’OrbitWake dans un dépôt sans rapport.

La documentation ne publie pas encore de nom de fichier comme .orbitwake, orbitwake.json ou équivalent, car aucun de ces formats n’est confirmé ici comme contrat stable.

Préférences utilisateur

Les préférences personnelles peuvent concerner des choix de comportement généraux qui doivent suivre l’utilisateur d’un projet à l’autre. Elles doivent rester distinctes des politiques d’équipe ou des réglages spécifiques à un dépôt.

Un bon système de préférences doit également permettre de revenir aux valeurs par défaut et d’identifier l’origine d’un réglage actif lorsqu’un comportement paraît inattendu.

La portée exacte des préférences utilisateur dans OrbitWake CLI sera documentée lorsque l’interface correspondante sera stabilisée.

Priorité entre plusieurs sources de configuration

Lorsqu’un produit supporte plusieurs niveaux de configuration, il doit définir une règle de priorité claire. Par exemple, un réglage de projet peut parfois remplacer un réglage utilisateur, tandis qu’une politique d’organisation peut rester prioritaire.

OrbitWake ne publie pas ici d’ordre de priorité précis tant que cette logique n’est pas confirmée. Le principe important est qu’un conflit de configuration doit être déterministe et explicable.

Pour le dépannage, il doit être possible d’identifier quelle source a produit la valeur finale plutôt que de deviner pourquoi un réglage semble ignoré.

Secrets et configuration

Les secrets ne doivent pas être traités comme de simples préférences. Clés API, tokens, mots de passe, certificats et autres informations sensibles nécessitent un stockage et une exposition adaptés à leur niveau de risque.

Évitez de placer un secret directement dans un fichier versionné ou dans une commande qui sera conservée dans l’historique shell. Préférez les mécanismes sécurisés proposés par le système, l’environnement ou OrbitWake lorsqu’ils seront documentés.

Valider une configuration

Une configuration incorrecte doit produire une erreur compréhensible plutôt qu’un comportement silencieusement imprévisible. Les valeurs inconnues, chemins invalides ou options incompatibles doivent être signalés aussi tôt que possible.

Pour les environnements partagés, la validation est également importante afin d’éviter qu’une configuration locale différente ne produise des résultats inattendus entre plusieurs développeurs.

Les commandes éventuelles de validation, d’inspection ou d’affichage de configuration OrbitWake ne sont pas documentées tant qu’elles ne sont pas confirmées.

Workflow recommandé

Avant d’attribuer un comportement étrange à OrbitWake, vérifiez d’abord le contexte de votre environnement et de votre projet.

$ pwd
$ git status
$ git branch --show-current
$ orbitwake

Les trois premières commandes sont des commandes standard du shell ou de Git. Elles permettent de confirmer où vous travaillez avant d’ouvrir une session OrbitWake.

Si un réglage spécifique est introduit à l’avenir, documentez son objectif et sa portée dans le projet afin que les autres développeurs puissent comprendre pourquoi il existe.

Bonnes pratiques

Gardez les réglages aussi simples que possible. Chaque option supplémentaire augmente le nombre de comportements possibles et rend le dépannage plus difficile.

Séparez les préférences personnelles des règles nécessaires au projet. Une convention essentielle à toute l’équipe ne doit pas dépendre d’un réglage privé connu d’une seule personne.

Évitez les secrets en clair, les chemins absolus propres à une seule machine et les configurations qui dépendent d’un état non documenté.

Lorsque vous modifiez une configuration importante, vérifiez son impact sur les commandes, les permissions, Git et les workflows de déploiement avant de la considérer comme prête pour un environnement partagé.

Ce qui reste à documenter

Le nom et l’emplacement des fichiers de configuration, les clés disponibles, les variables d’environnement OrbitWake, l’ordre de priorité exact, les commandes d’inspection, les valeurs par défaut, la validation automatique et les politiques d’organisation ne sont pas encore publiés comme contrat stable.

Cette page documente donc la structure conceptuelle attendue sans inventer de syntaxe ou de fichier qui pourrait changer avant stabilisation.

Étapes suivantes

Continuez avec Dépannage pour apprendre à isoler un problème CLI, vérifier l’installation, la connexion, le projet, Git, les permissions et la configuration avant de conclure qu’un comportement vient du produit.