Fichiers

Le rôle des fichiers dans le CLI

Quand vous utilisez OrbitWake depuis un projet local, les fichiers permettent de fournir le contexte nécessaire à une tâche : code source, configuration, documentation, tests, schémas ou autres ressources utiles.

Le simple fait qu’un fichier existe dans le répertoire courant ne signifie pas qu’il doit être utilisé. OrbitWake doit privilégier les fichiers pertinents pour la demande afin d’éviter un contexte inutilement large.

Cette approche réduit le bruit, améliore la précision et limite l’exposition accidentelle de données sans rapport avec la tâche.

Lecture et contexte

Lire un fichier signifie utiliser son contenu comme contexte pour comprendre ou répondre à une demande. Cette lecture peut concerner un fichier précis, plusieurs fichiers liés ou une portion de projet suffisante pour résoudre la tâche.

Une analyse de bug peut nécessiter le fichier concerné et ses dépendances proches. Une question d’architecture peut nécessiter plusieurs points d’entrée, fichiers de configuration et modules centraux. La portée de lecture doit donc dépendre du problème à résoudre.

Lecture et écriture sont deux permissions différentes

OrbitWake peut avoir besoin de lire un fichier pour proposer une correction sans que cela implique automatiquement une autorisation de modifier ce fichier.

L’écriture, le renommage, le déplacement ou la suppression d’un fichier sont des opérations distinctes et potentiellement plus sensibles. Elles doivent respecter les permissions prévues par le produit et le niveau de contrôle demandé par l’utilisateur.

Pour les changements importants, une approche sûre consiste à examiner d’abord les fichiers concernés, comprendre la portée du changement, puis appliquer les modifications avec une validation appropriée.

Sélectionner les bons fichiers

Une bonne sélection commence par la tâche. Si vous demandez une correction précise, commencez avec le fichier directement concerné et les dépendances immédiates. Si le problème est transversal, élargissez progressivement le contexte.

Évitez d’inclure tout un dépôt volumineux par défaut. Cela peut augmenter la latence, rendre la tâche plus difficile à raisonner et introduire des éléments sans rapport avec le problème.

Formats, taille et compatibilité

Les formats réellement exploitables dépendent des capacités disponibles dans le CLI et des traitements que le produit sait appliquer. Les fichiers texte et de code sont des cas naturels, mais tous les formats présents dans un projet ne doivent pas être supposés lisibles ou interprétables.

Les limites de taille, le nombre maximal de fichiers et le comportement face aux fichiers volumineux ne sont pas encore publiés comme contrat stable. Un fichier trop grand peut être partiellement lu, résumé, refusé ou nécessiter une approche plus ciblée.

La documentation ne publie volontairement aucun seuil numérique tant que ces limites ne sont pas confirmées dans le produit.

Secrets et fichiers sensibles

Un projet local peut contenir des fichiers d’environnement, des clés privées, des secrets API, des certificats, des exports de données ou d’autres informations sensibles.

Ces fichiers ne doivent pas être ajoutés au contexte simplement parce qu’ils sont présents dans le dossier. Avant une analyse large, vérifiez la portée du répertoire et excluez les données qui ne sont pas nécessaires à la tâche.

Les mécanismes précis d’exclusion automatique, de fichiers ignorés ou de règles personnalisées seront documentés lorsqu’ils seront stabilisés.

Tâches multi-fichiers

Certaines tâches nécessitent plusieurs modifications coordonnées : refactor d’une API, changement de type partagé, migration de configuration ou mise à jour d’un flux complet.

Dans ces cas, il est important d’identifier les fichiers impactés avant d’écrire. Une modification cohérente doit prendre en compte les dépendances, les tests et les usages indirects afin d’éviter des changements partiels.

Pour une opération importante, demandez d’abord la portée ou le plan si vous avez besoin de valider ce qui sera modifié. Cela permet de garder le contrôle avant toute écriture sur plusieurs fichiers.

Workflow recommandé

Commencez par ouvrir le bon projet, puis lancez OrbitWake depuis ce répertoire.

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

Ensuite, formulez une tâche précise et indiquez les fichiers concernés si vous les connaissez. Si OrbitWake a besoin d’un contexte supplémentaire, élargissez la portée progressivement plutôt que d’inclure tout le projet dès le départ.

Avant une écriture importante, vérifiez les fichiers impactés et assurez-vous que les opérations proposées correspondent bien à votre intention.

Bonnes pratiques

Gardez vos tâches spécifiques, utilisez des projets bien structurés et évitez de travailler depuis un dossier qui mélange plusieurs projets indépendants.

Lorsque vous cherchez un bug, partez du fichier où le symptôme apparaît puis élargissez vers les dépendances. Pour une migration ou un refactor, identifiez la surface de changement avant de modifier.

Ne mélangez pas lecture et écriture dans votre propre raisonnement : comprendre le projet est une étape, modifier le projet en est une autre. Cette distinction est particulièrement importante pour les fichiers de configuration, scripts de déploiement et secrets.

Ce qui reste à documenter

Les extensions officiellement prises en charge, les tailles maximales, les règles d’exclusion, le traitement des fichiers binaires, les fichiers ignorés par Git, les liens symboliques, les fichiers générés et les mécanismes précis de sélection automatique ne sont pas encore publiés comme interface stable.

Lorsque ces comportements seront validés, ils seront ajoutés ici avec des exemples concrets plutôt qu’avec des hypothèses.

Étapes suivantes

Continuez avec Git pour comprendre la différence entre lire l’état d’un dépôt, préparer des changements et effectuer des opérations Git qui peuvent modifier l’historique ou le remote.