OrbitWake Code
Génération de code
Dans OrbitWake Code, un build transforme une consigne utilisateur et l’état courant du projet en un changement structuré. La private beta privilégie une portée contrôlée, des modèles explicitement disponibles et une revue visible après chaque exécution.
Qu’est-ce qu’un build ?
Un build AI est une opération qui prend le projet courant, la consigne saisie dans le composer et le modèle sélectionné, puis demande à OrbitWake de produire une nouvelle version des fichiers concernés.
Avant de lancer le build, l’éditeur enregistre le fichier actif afin que le contexte envoyé corresponde à l’état visible dans Code.
Le build ne publie rien automatiquement. Il met à jour le projet privé et rafraîchit la preview afin que le résultat puisse être revu.
Le composer de build
Le composer demande de décrire le résultat voulu plutôt qu’une suite de micro-instructions techniques. Une consigne claire doit expliquer l’objectif, les éléments à modifier et les contraintes importantes.
La consigne est limitée à 8 000 caractères dans l’implémentation beta actuelle. Les demandes trop vagues produisent généralement un résultat moins ciblé que les demandes qui décrivent précisément le comportement attendu.
Pendant l’exécution, l’interface affiche le temps écoulé et bloque les modifications concurrentes dans l’éditeur pour éviter que l’utilisateur et le build écrivent simultanément sur le même état.
Choix du modèle
OrbitWake Auto est toujours proposé comme choix de base. Les options GPT, Claude et Grok apparaissent uniquement lorsque le fournisseur correspondant est configuré et disponible dans l’environnement OrbitWake.
Avec OrbitWake Auto, le produit choisit un fournisseur configuré selon sa logique de routage interne. Avec un choix explicite, le build demande le fournisseur correspondant et échoue proprement si celui-ci n’est pas configuré.
La liste visible dans Code reflète donc l’état réel de l’environnement plutôt qu’une liste statique de modèles garantie pour tous les comptes.
Contexte envoyé au modèle
Le build prépare un prompt à partir du nom du projet, de la demande utilisateur et des fichiers du projet utilisés par la private beta.
Les fichiers existants sont traités comme du code source non fiable et non comme des instructions système. OrbitWake conserve ses propres règles de génération même si un fichier contient du texte ressemblant à une instruction.
Si la taille combinée du contexte dépasse la limite autorisée par la politique beta, le build est refusé plutôt que tronqué silencieusement.
Patch structuré
La génération actuelle n’accepte pas une réponse libre du fournisseur. OrbitWake demande un patch structuré avec un résumé et une liste contrôlée de fichiers.
Dans la private beta actuelle, le patch peut modifier uniquement index.html, styles.css et script.js. Entre un et trois fichiers peuvent être renvoyés par une exécution.
Chaque chemin est validé et les doublons sont refusés. Le contenu retourné reste lui aussi soumis aux limites de taille du projet.
Preview après génération
Après un build réussi, Code recharge le projet retourné par le backend puis ouvre la vue Preview. La preview privée est reconstruite à partir des fichiers sauvegardés.
L’interface conserve également la liste des chemins modifiés afin que la vue Changes puisse montrer exactement quels fichiers ont été mis à jour.
Une preview correcte visuellement ne remplace pas la revue du code. Les vues Code et Changes restent nécessaires pour comprendre le résultat réel du build.
Historique des exécutions AI
Les exécutions récentes d’un projet peuvent apparaître dans l’historique AI avec leur statut, le modèle sélectionné, le modèle fournisseur réellement utilisé, le résumé du changement et la date.
Une exécution peut être en attente, réussie, échouée ou bloquée. Les erreurs fournisseur et les erreurs de validation sont renvoyées au produit plutôt que masquées derrière un résultat partiel.
Cette trace aide à comprendre ce qui a été demandé et quel moteur a produit le résultat observé.
Crédits, quotas et limites beta
Les builds sont soumis aux règles de la private beta : accès actif, nombre maximal de builds par heure, limites quotidiennes de requêtes, limites de tokens et crédit disponible.
Avant une exécution, OrbitWake estime la consommation afin de réserver le crédit nécessaire. Si le solde ou une limite beta est dépassé, le build est bloqué avant l’appel fournisseur.
Après un build réussi, l’interface peut afficher le coût facturé au crédit beta ainsi que le solde restant.
Les valeurs exactes des quotas sont liées à la configuration du workspace et ne doivent pas être documentées comme constantes universelles.
Fiabilité et idempotence
Chaque demande de build utilise un identifiant de requête unique. Si une requête déjà traitée est rejouée, OrbitWake évite de la traiter comme une nouvelle opération identique.
Une requête déjà en cours ou déjà consommée peut donc être refusée afin d’éviter les doubles builds et les doubles coûts.
Cette logique est importante lorsque le réseau est lent ou lorsqu’un utilisateur clique plusieurs fois sur Build.
Contrôle et sécurité
La génération Code actuelle est conçue pour un site statique privé. Le prompt système demande de ne pas ajouter de backend, de secrets, de credentials, de variables d’environnement ni de dépendances réseau nécessaires au fonctionnement principal.
La preview bloque les connexions réseau, ce qui évite qu’un résultat généré dépende silencieusement d’un service externe non configuré.
Les changements restent dans le projet OrbitWake tant qu’une étape séparée de publication ou de déploiement n’est pas explicitement réalisée.
Workflow recommandé
| Étape | Objectif |
|---|---|
| 1. Vérifier le projet | S’assurer que le bon espace de travail est ouvert |
| 2. Attendre la sauvegarde | Utiliser l’état le plus récent comme contexte |
| 3. Créer un checkpoint | Conserver un point de retour avant un grand changement |
| 4. Décrire précisément le résultat | Limiter l’ambiguïté du build |
| 5. Choisir Auto ou un modèle disponible | Contrôler le mode de génération |
| 6. Lancer Build | Produire le patch et mettre à jour le projet |
| 7. Revoir Preview, Code et Changes | Valider le rendu et les fichiers modifiés |
Limites actuelles
La génération Code de la private beta est centrée sur trois fichiers de site statique. Elle ne doit pas encore être présentée comme un agent général capable de modifier n’importe quel dépôt, lancer des builds npm ou gérer automatiquement une infrastructure.
Les capacités multi-framework, monorepo, dépendances, backend, terminal et Git seront documentées séparément lorsqu’elles seront disponibles comme interfaces stables.
Étapes suivantes
Continuez avec Revue de code pour comprendre comment inspecter les changements après un build, distinguer les fichiers modifiés et décider si le résultat doit être conservé, restauré ou retravaillé.