OrbitWake CLI

Sessions

Une session CLI représente une période de travail continue dans le terminal. Elle regroupe votre interaction courante, le contexte de projet nécessaire, le modèle utilisé et les permissions applicables pendant cette interaction.

Qu’est-ce qu’une session CLI ?

Une session commence lorsque vous lancez OrbitWake depuis votre terminal et que le produit entre dans son mode interactif. À partir de là, les demandes successives peuvent s’appuyer sur le contexte déjà établi pendant la même interaction.

La session ne doit pas être confondue avec le projet lui-même. Un projet correspond à votre code et à vos fichiers ; une session correspond à la période de travail active pendant laquelle OrbitWake traite vos demandes dans ce contexte.

Cette distinction permet de comprendre pourquoi deux lancements séparés d’OrbitWake peuvent partager le même projet tout en ayant des états de conversation différents.

Démarrer une session

Le flux de base reste simple : ouvrez le bon répertoire puis lancez OrbitWake.

Terminal
$ cd /chemin/vers/votre-projet
$ orbitwake

Le répertoire courant sert de point de départ au contexte de projet. La commande orbitwake ouvre ensuite la session interactive.

Une session démarre dans un contexte précisVérifiez le répertoire, la branche et les changements locaux avant de lancer une tâche importante.

Contexte conservé pendant la session

Pendant une même session, OrbitWake peut réutiliser les éléments nécessaires au fil du travail : demandes précédentes, réponses, informations de projet et autres données de contexte pertinentes.

Le fait qu’un élément ait été utilisé une fois ne signifie pas qu’il est toujours envoyé intégralement à chaque nouvelle requête. Le produit peut sélectionner, résumer ou réutiliser uniquement la partie du contexte utile à la demande suivante.

Le contexte visible dans le terminal et le contexte technique réellement transmis au modèle ne doivent pas être considérés comme strictement identiques. OrbitWake peut organiser le contexte pour rester dans les limites disponibles et maintenir la qualité de la réponse.

Continuité entre les messages

Une session interactive est utile parce qu’elle évite de repartir de zéro à chaque message. Vous pouvez continuer une tâche, préciser une demande ou demander une correction supplémentaire en vous appuyant sur ce qui vient d’être discuté.

Cependant, la continuité ne doit pas être interprétée comme une mémoire infinie. Plus une session devient longue, plus le produit peut avoir besoin de compacter ou de sélectionner le contexte pertinent.

Pour les tâches très longues ou qui changent complètement de sujet, commencer une nouvelle session peut être plus clair que de conserver un historique devenu sans rapport avec la nouvelle tâche.

Modèle et état de session

Une session utilise OrbitWake Auto ou un modèle explicitement disponible lorsque le produit expose ce choix. Le modèle fait partie du comportement fonctionnel de la session, mais les règles précises de persistance du choix entre deux lancements ne sont pas encore publiées comme contrat stable.

Ne supposez donc pas qu’une préférence de modèle sélectionnée dans une session sera automatiquement restaurée dans une nouvelle session tant que ce comportement n’est pas documenté.

De la même manière, un changement interne de routage avec OrbitWake Auto ne doit pas être interprété comme une nouvelle session : il s’agit d’un détail de traitement à l’intérieur de la même interaction utilisateur.

Permissions et session

Une session ne doit jamais transformer une autorisation ponctuelle en permission permanente. Si une opération sensible nécessite une confirmation, l’acceptation de cette action ne signifie pas automatiquement que toutes les opérations futures du même type sont autorisées.

Les permissions peuvent concerner la lecture de fichiers, l’écriture locale, les commandes shell, Git ou des opérations externes. Elles doivent rester proportionnées à l’action réelle.

Session ≠ autorisation globaleLe simple fait qu’une session reste ouverte ne doit pas élargir automatiquement les droits accordés à OrbitWake.

Travailler avec plusieurs projets

Si vous passez d’un projet à un autre, évitez d’utiliser la même session comme si le contexte local n’avait pas changé. Le répertoire courant, la branche Git, les fichiers et les dépendances peuvent être complètement différents.

Une nouvelle session est généralement plus claire lorsqu’un changement de projet modifie fortement le contexte de travail. Cela réduit le risque de réutiliser une hypothèse ou une information issue du projet précédent.

Pour les monorepos ou projets composés de plusieurs applications liées, le bon choix dépend de la tâche : vous pouvez travailler depuis la racine si les dépendances croisées sont nécessaires, ou depuis un sous-répertoire si la tâche est plus locale.

Fin de session

La manière exacte de quitter, reprendre, restaurer ou lister des sessions CLI n’est pas encore publiée comme interface stable. Cette documentation n’invente donc pas de commande comme orbitwake session, orbitwake resume ou orbitwake history.

Lorsque ces capacités seront confirmées, elles seront documentées ici avec des commandes copiables et un comportement précis.

En attendant, considérez chaque lancement du CLI comme une nouvelle entrée de travail à moins que le produit n’indique explicitement qu’une session existante a été reprise.

Workflow recommandé

Avant de commencer une session importante, vérifiez rapidement l’état du projet, puis lancez OrbitWake.

Terminal
$ cd /chemin/vers/votre-projet
$ git status
$ git branch --show-current
$ orbitwake

Une fois la session ouverte, gardez les demandes liées au même objectif lorsque c’est possible. Si vous changez complètement de projet ou de tâche, une nouvelle session peut fournir un contexte plus propre.

Bonnes pratiques

Gardez une session centrée sur un objectif principal. Cela facilite la continuité du contexte et réduit le risque que des informations anciennes deviennent ambiguës.

Avant une action importante, reformulez la cible si nécessaire : fichiers concernés, branche, environnement, portée attendue. Une session longue ne remplace pas une confirmation claire.

Si une tâche évolue fortement, vérifiez que les hypothèses du début restent valides. Les fichiers, la branche ou l’état du dépôt peuvent avoir changé pendant la session.

Pour les opérations sensibles, conservez une séparation nette entre conversation, proposition de plan, écriture locale et actions externes.

Ce qui reste à documenter

La liste des sessions, leur persistance, la restauration, la reprise après fermeture du terminal, les identifiants de session, le stockage local ou serveur, la durée de vie, la synchronisation entre appareils et les commandes de gestion de session ne sont pas encore publiés comme contrat stable.

La documentation reste donc volontairement centrée sur le comportement confirmé : lancer OrbitWake ouvre une interaction CLI dans le contexte du projet courant.

Étapes suivantes

Continuez avec Configuration pour comprendre quels comportements du CLI pourront être réglés au niveau de l’environnement, du projet ou de l’utilisateur lorsqu’ils seront documentés comme options stables.

PrécédentPermissions shellSuivantConfiguration
Cette page vous a-t-elle aidé ?
Sessions CLICLIPermissions shellCLIGit CLICLI
↑↓ NaviguerEntrée OuvrirÉchap Fermer