OrbitWake Code
Revue de code
La revue de code est l’étape qui suit un build ou une modification manuelle. Dans la private beta actuelle, OrbitWake Code combine Preview, Code, Changes, checkpoints et historique AI pour aider à vérifier ce qui a changé avant de poursuivre.
Objectif de la revue
Une revue ne consiste pas seulement à vérifier que la page « a l’air correcte ». Elle doit confirmer que le projet visuel, le contenu des fichiers et la portée du changement correspondent à la demande initiale.
OrbitWake Code sépare volontairement plusieurs vues afin que l’utilisateur puisse examiner le résultat sous différents angles : rendu, contenu du code, chemins modifiés et historique de l’exécution.
Cette étape reste importante même lorsqu’un build AI se termine sans erreur. Une exécution réussie signifie que le patch a été accepté et appliqué, pas que le résultat est automatiquement correct pour votre produit.
Commencer par Preview
Après un build réussi, Code ouvre la vue Preview. Elle permet de vérifier rapidement le résultat visuel dans la sandbox privée du projet.
Utilisez cette vue pour repérer les problèmes évidents : mise en page cassée, contenu manquant, navigation incohérente, comportement JavaScript inattendu ou régression mobile visible.
La preview reste cependant un environnement statique et sandboxé. Elle ne prouve pas qu’une future intégration réseau, backend ou déploiement fonctionnera en production.
Inspecter la vue Code
La vue Code affiche les fichiers du projet et permet d’ouvrir le contenu de chacun. Dans la private beta actuelle, l’éditeur principal travaille notamment avec index.html, styles.css et script.js.
Après un build, vérifiez que le changement est placé dans le bon fichier et qu’il n’a pas remplacé une partie du projet qui devait rester intacte.
La sauvegarde automatique continue de s’appliquer dans cette vue. Si vous corrigez manuellement un détail après la génération, attendez que l’état de sauvegarde confirme l’enregistrement avant de lancer un nouveau build.
Utiliser la vue Changes
La vue Changes de l’implémentation actuelle affiche les chemins modifiés par le dernier build. Chaque fichier concerné apparaît comme mis à jour.
Cette vue est utile pour vérifier la portée du build : une demande sur le style ne devrait pas modifier inutilement un fichier sans rapport, et un changement de comportement peut nécessiter un fichier JavaScript en plus du HTML ou du CSS.
La version actuelle ne doit pas être présentée comme un diff Git ligne par ligne complet. Elle indique surtout quels fichiers ont changé et complète la lecture directe dans la vue Code.
git diff et ne montre pas encore toutes les additions et suppressions ligne par ligne.Comparer avec un checkpoint
Les checkpoints servent de points de retour. Avant un changement important, créez un checkpoint afin de conserver l’état précédent du projet.
Si le résultat d’un build n’est pas acceptable, l’interface permet de restaurer un checkpoint. Avant la restauration, OrbitWake demande une confirmation et crée une sauvegarde automatique de l’état courant.
Ce mécanisme offre une manière simple de revenir en arrière sans confondre l’historique interne de Code avec Git.
Vérifier l’historique AI
La section AI history permet d’identifier les exécutions récentes du projet. Elle peut afficher le résumé du build, le modèle choisi, le modèle fournisseur utilisé, le statut et l’heure.
Utilisez cette information pour relier un résultat à l’exécution qui l’a produit. C’est particulièrement utile lorsque plusieurs builds sont effectués successivement sur le même projet.
Un statut réussi indique que le build a été appliqué. Un statut échoué ou bloqué indique qu’aucun résultat complet ne doit être considéré comme validé.
Ordre de revue recommandé
| Étape | À vérifier |
|---|---|
| 1. Preview | Le résultat visuel correspond-il à la demande ? |
| 2. Changes | Quels fichiers ont été touchés ? |
| 3. Code | Le contenu des fichiers est-il cohérent et lisible ? |
| 4. AI history | Quelle exécution et quel modèle ont produit ce résultat ? |
| 5. Checkpoint | Faut-il conserver, corriger ou restaurer l’état précédent ? |
Revue après une correction manuelle
Vous pouvez corriger directement un fichier dans la vue Code après un build. Dans ce cas, la modification manuelle devient elle aussi partie de l’état du projet.
Vérifiez la sauvegarde avant de relancer l’AI, sinon la prochaine exécution pourrait partir d’un état qui ne correspond pas encore à la version affichée dans l’éditeur.
Si la correction manuelle est importante, créez un nouveau checkpoint après validation afin de conserver cet état comme point de retour.
Décider si le résultat est acceptable
Dans la private beta actuelle, Code ne possède pas encore un workflow formel de type « Approve / Reject » comparable à une pull request Git. L’état appliqué du projet est directement visible après le build.
La décision pratique consiste donc à conserver le résultat, le corriger manuellement, lancer un nouveau build avec une consigne plus précise ou restaurer un checkpoint.
Ne documentez pas de bouton d’approbation ou de rejet global tant qu’une telle interface n’existe pas réellement dans Code.
Revue avant Git ou déploiement
Un build réussi dans Code ne doit jamais être considéré comme une autorisation automatique de commit, push, merge ou déploiement.
Avant toute opération externe, assurez-vous que le résultat a été revu, que les fichiers modifiés sont attendus et que les changements importants peuvent être expliqués.
La page Workflows Git documentera séparément les opérations Git disponibles lorsqu’elles seront stabilisées dans la surface Code.
Limites actuelles de la revue
La vue Changes actuelle montre les chemins modifiés mais ne fournit pas encore un diff complet avec hunks, additions, suppressions, commentaires ligne par ligne ou approbation formelle.
La preview est statique et sandboxée. Elle ne remplace pas des tests automatisés, une validation de backend ou une vérification en environnement de production.
Les fonctionnalités de revue plus avancées seront documentées lorsqu’elles seront présentes dans le produit plutôt qu’anticipées dans la documentation.
Étapes suivantes
Continuez avec Workflows Git pour comprendre la frontière entre l’état privé du projet Code et les opérations Git comme branche, commit, push ou pull request.