Contexte de projet

Qu’est-ce que le contexte de projet ?

Quand vous lancez OrbitWake depuis un terminal, le CLI doit savoir sur quel projet vous travaillez et quelles informations sont réellement nécessaires pour répondre. Le contexte de projet sert à construire cette vue de travail.

Le contexte n’est pas synonyme de « tout le disque » ni de « tout le dépôt ». OrbitWake doit préparer un ensemble ciblé d’informations utiles à la tâche en cours plutôt que d’envoyer systématiquement chaque fichier disponible.

Cette séparation est importante pour la qualité des réponses, la performance, la confidentialité et le contrôle des opérations qui peuvent toucher votre code.

Le répertoire courant comme point de départ

Le moyen le plus simple d’indiquer le projet sur lequel vous voulez travailler est de lancer OrbitWake depuis le bon répertoire local.

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

Dans ce workflow, cd est une commande standard du shell. La commande orbitwake démarre ensuite la session depuis ce répertoire.

Comment le contexte doit être sélectionné

Une bonne sélection de contexte doit répondre à une question simple : « de quelles informations OrbitWake a-t-il besoin pour accomplir cette tâche correctement ? »

Pour corriger un composant, il peut être suffisant d’utiliser le fichier concerné, ses dépendances proches et éventuellement les tests associés. Pour comprendre une architecture, un ensemble plus large de fichiers peut être nécessaire. Le contexte doit donc dépendre de la tâche et non d’une règle unique appliquée à tous les projets.

La logique exacte de sélection automatique du contexte dans le CLI sera documentée uniquement lorsqu’elle sera stabilisée. Cette page décrit le principe produit sans promettre un algorithme interne précis.

Fichiers et contenu local

Les fichiers constituent une grande partie du contexte d’un projet. OrbitWake peut avoir besoin de lire du code source, de la configuration, de la documentation ou d’autres ressources pertinentes afin de comprendre une demande.

Lire un fichier et modifier un fichier sont deux actions différentes. L’accès au contexte ne doit pas être interprété comme une autorisation automatique d’écrire, renommer ou supprimer un fichier.

Les règles exactes de sélection, d’exclusion, de taille maximale et de formats pris en charge seront détaillées dans la prochaine page CLI Fichiers.

Contexte du dépôt

Dans un projet versionné, l’état du dépôt peut aider à comprendre la structure du travail : fichiers modifiés, fichiers suivis, organisation des dossiers et différences locales. La documentation Git dédiée précisera quelles informations OrbitWake peut lire et quelles actions peuvent être proposées.

Le contexte Git doit rester distinct des permissions Git. Comprendre l’état d’un dépôt ne signifie pas qu’OrbitWake peut automatiquement créer un commit, changer de branche, pousser vers un remote ou modifier l’historique.

Taille du contexte et précision

Un contexte plus grand n’est pas automatiquement meilleur. Envoyer trop d’informations peut introduire du bruit, augmenter la latence et rendre plus difficile l’identification des éléments importants.

À l’inverse, un contexte trop petit peut empêcher OrbitWake de voir une dépendance, une configuration ou un test nécessaire. L’objectif est donc d’obtenir un contexte suffisamment complet pour la tâche, mais suffisamment ciblé pour rester utile.

Sécurité, secrets et données sensibles

Le contexte local peut contenir des informations qui ne doivent pas être envoyées inutilement : secrets, identifiants, clés privées, fichiers d’environnement, données clients ou configurations internes.

Avant de demander une analyse large d’un projet, vérifiez ce qui se trouve dans le répertoire courant et limitez la tâche aux éléments nécessaires. Les mécanismes précis d’exclusion et de permission seront documentés dans les pages Fichiers, Permissions shell et Configuration.

Workflow recommandé

Un workflow simple consiste à ouvrir le bon projet, lancer OrbitWake, formuler une tâche précise et élargir le contexte uniquement si nécessaire.

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

Une fois la session ouverte, décrivez la tâche avec suffisamment de précision pour qu’OrbitWake puisse déterminer quelles informations sont utiles. Si un élément manque, ajoutez-le explicitement plutôt que de supposer que tout le dépôt est déjà inclus.

Bonnes pratiques

Travaillez depuis un répertoire dédié au projet, évitez les dossiers qui regroupent plusieurs dépôts sans rapport et gardez vos tâches suffisamment spécifiques pour limiter le contexte nécessaire.

Avant une modification importante, vérifiez les fichiers concernés et l’état du projet. Pour les opérations multi-fichiers, demandez d’abord une explication ou un plan si vous avez besoin de confirmer la portée avant l’écriture.

Ne supposez pas qu’un fichier non mentionné est automatiquement ignoré ou automatiquement inclus. Tant que les règles de sélection ne sont pas documentées comme interface stable, considérez le contexte comme une capacité contrôlée par OrbitWake et par les permissions du produit.

Ce qui reste à documenter

Les règles exactes de découverte de projet, la prise en compte des fichiers ignorés, les limites de taille, les formats binaires, les monorepos, les liens symboliques, les exclusions personnalisées et la manière dont le contexte est résumé ou tronqué ne sont pas encore publiés comme contrat stable.

Ces éléments seront ajoutés lorsqu’ils seront confirmés dans le CLI. La documentation évite volontairement de présenter comme garanti un comportement qui pourrait encore évoluer.

Étapes suivantes

Continuez avec Fichiers pour voir comment les ressources locales s’intègrent au contexte, quelles opérations doivent rester séparées de la lecture et comment préparer des tâches qui impliquent plusieurs fichiers.