OrbitWake Code
Code — Vue d’ensemble
OrbitWake Code est l’espace de travail dédié aux tâches de développement : comprendre un dépôt, travailler avec le contexte d’un projet, générer ou modifier du code, revoir les changements et préparer des workflows Git avec un contrôle explicite.
Présentation
OrbitWake Code est conçu comme une surface de travail technique, pas comme une page de chat générique. L’objectif est de rapprocher la demande, le contexte du dépôt, les résultats produits et la revue dans une même expérience.
La vue Code est disponible dans l’application OrbitWake à l’adresse /app/code. Elle est actuellement traitée comme une surface produit en évolution, avec une approche orientée résultat : le travail utile doit rester au centre de l’interface plutôt qu’une accumulation de panneaux décoratifs.
Code complète les autres surfaces d’OrbitWake. Le CLI sert au travail depuis le terminal, l’extension VS Code rapproche OrbitWake de l’éditeur, et Code offre une surface web dédiée aux projets et aux résultats de développement.
Une interface orientée résultat
Le principe de Code est de faire apparaître en priorité ce qui aide réellement à terminer la tâche : projet courant, contexte utile, résultat généré, fichiers concernés et état de la revue.
Une bonne session Code doit permettre de comprendre rapidement trois choses : sur quel projet vous travaillez, quelle tâche est en cours et quels changements sont proposés ou déjà produits.
Les détails d’implémentation de l’interface peuvent évoluer, mais le produit doit éviter de masquer le résultat derrière des couches de navigation inutiles. Les informations de contexte doivent soutenir le travail, pas devenir le travail.
Projets
Un projet représente l’unité de travail dans OrbitWake Code. Il sert à regrouper le contexte nécessaire pour travailler sur une base de code sans mélanger des dépôts ou objectifs qui n’ont pas de rapport.
Le produit peut associer un projet à un contexte de dépôt, des fichiers, des sessions de travail et d’autres informations nécessaires à la tâche. Les règles exactes de création, connexion et persistance seront détaillées dans la page Projets.
Lorsque plusieurs projets existent, vérifiez toujours que le projet sélectionné correspond à la tâche avant de demander une modification importante. Une erreur de projet peut conduire à analyser les mauvais fichiers ou à préparer des changements dans le mauvais contexte.
Contexte du dépôt
OrbitWake Code doit comprendre suffisamment de contexte pour effectuer une tâche utile sans traiter tout le dépôt comme une seule masse de données. Le contexte peut inclure des fichiers pertinents, leur relation, la structure du projet et l’état Git nécessaire à la tâche.
Le contexte doit être sélectionné en fonction du problème. Une correction ciblée peut nécessiter un composant, sa dépendance et son test. Un refactor transversal peut nécessiter plusieurs fichiers et interfaces partagées.
Lire le contexte du dépôt n’est pas une autorisation automatique de modifier chaque fichier. OrbitWake doit conserver la distinction entre compréhension, proposition, écriture et opérations externes.
Génération et modification de code
Code peut servir à produire de nouveaux fichiers, proposer des modifications, corriger un bug ou refactoriser une portion du projet lorsque les capacités correspondantes sont disponibles.
La qualité du résultat dépend autant du contexte que du modèle. Une demande précise avec les bons fichiers est généralement plus utile qu’une consigne large appliquée à l’ensemble d’un dépôt.
Pour une modification importante, la portée doit rester visible : fichiers concernés, objectif de chaque changement et relation avec les tests ou dépendances impactées.
Revue avant application
La revue est une étape centrale du workflow Code. Avant d’accepter une modification importante, vérifiez ce qui change, pourquoi et dans quels fichiers.
Une revue utile doit rendre visibles les différences, les effets secondaires possibles et les parties du projet touchées. Les changements déjà présents avant la tâche doivent être préservés et distingués de ceux produits par OrbitWake.
Pour les opérations multi-fichiers, la revue doit être suffisamment claire pour détecter une modification incomplète, une dépendance oubliée ou une configuration changée sans raison.
Workflows Git
Git fournit un cadre naturel pour comprendre et contrôler les modifications. L’état du dépôt, la branche courante et le diff permettent de vérifier ce qui existait avant la tâche et ce qui a changé ensuite.
Les opérations Git ne doivent pas toutes être traitées de la même manière. Lire un diff est différent de créer un commit, pousser une branche ou réécrire l’historique.
Les futurs workflows Git documentés dans Code préciseront quelles actions peuvent être proposées, lesquelles nécessitent une confirmation explicite et comment les changements sont présentés avant publication.
Contrôle, permissions et sécurité
OrbitWake Code peut intervenir sur des actifs importants : code source, configuration, scripts, dépendances et parfois workflows de déploiement. Les actions qui augmentent le niveau d’impact doivent augmenter également le niveau de contrôle.
Une opération de lecture, une modification locale, une commande shell et un déploiement en production ne représentent pas le même risque. Le produit doit conserver cette séparation et demander une validation adaptée lorsque l’action devient sensible ou irréversible.
Les secrets, variables d’environnement et données sensibles ne doivent pas être inclus inutilement dans le contexte. Le principe de moindre exposition reste applicable à Code comme au CLI.
Code, CLI et VS Code
Les trois surfaces sont complémentaires. Code fournit l’espace web orienté projet et résultat. Le CLI permet de travailler depuis le terminal. L’extension VS Code rapproche les conversations, le contexte du workspace et les changements de code de l’éditeur local.
| Surface | Usage principal |
|---|---|
| OrbitWake Code | Projet, contexte, résultat, revue et workflows web |
| OrbitWake CLI | Travail depuis le terminal et contexte du répertoire courant |
| VS Code | Travail directement dans l’éditeur avec contexte du workspace |
La documentation de chaque surface précise ses propres permissions et comportements. Ne supposez pas qu’une capacité disponible dans l’une est automatiquement disponible dans les deux autres.
Workflow recommandé
Pour une tâche de développement importante, commencez par confirmer le projet et le contexte. Décrivez ensuite le résultat attendu, inspectez les fichiers concernés, produisez le changement, puis passez par une revue avant toute opération Git ou déploiement.
| Étape | Objectif |
|---|---|
| 1. Sélectionner le projet | Éviter de travailler dans le mauvais contexte |
| 2. Définir la tâche | Limiter la portée et clarifier le résultat attendu |
| 3. Construire le contexte | Inclure uniquement les fichiers et informations utiles |
| 4. Générer ou modifier | Produire un résultat cohérent avec le projet |
| 5. Revoir | Vérifier fichiers, diff et effets secondaires |
| 6. Valider l’action suivante | Séparer clairement revue, Git et déploiement |
Ce qui reste à documenter
Les règles exactes de création de projets Code, l’association à un dépôt, les limites de contexte, les mécanismes de patch, les états de revue, les commandes disponibles, les workflows Git intégrés et les politiques de confirmation ne sont pas encore tous publiés comme contrat stable.
Les pages suivantes détailleront ces éléments progressivement. La documentation évite de présenter comme garanti un comportement qui peut encore évoluer pendant la phase actuelle du produit.
Étapes suivantes
Continuez avec Projets pour comprendre comment OrbitWake Code organise les espaces de travail, le contexte associé et la séparation entre plusieurs bases de code.