OrbitWake Code

Projets

Un projet OrbitWake Code est l’espace de travail privé qui regroupe les fichiers, les versions, les builds AI et la preview nécessaires pour construire et revoir une expérience sans quitter OrbitWake.

Ce qu’un projet représente

Dans la version actuelle de Code, un projet possède un identifiant, un nom, un slug, un ensemble de fichiers et un historique de versions. L’interface affiche également le nombre de fichiers, l’espace utilisé, le nombre de checkpoints et la date de dernière mise à jour.

Le projet sert à garder le travail isolé. Les fichiers et versions d’un projet ne doivent pas être mélangés avec ceux d’un autre projet simplement parce qu’ils sont visibles dans la même liste Code.

OrbitWake Code utilise cet objet projet comme base pour l’éditeur, les builds AI, les sauvegardes, les checkpoints et la preview privée.

Accès et private beta

La surface /app/code nécessite une session utilisateur. Un utilisateur non authentifié est redirigé vers la connexion avant d’accéder au workspace Code.

Le workspace est actuellement protégé par l’état de private beta. L’accès peut être invité, actif, en pause ou révoqué. Les builds et la création de projets restent dépendants de l’état d’accès fourni par OrbitWake.

Quand la beta est active, OrbitWake peut également appliquer des limites de compte, notamment un nombre maximal de projets, une capacité de stockage et un nombre de builds par heure. Les valeurs exactes peuvent varier selon la configuration du compte et ne sont donc pas figées dans cette documentation.

Accès beta ≠ publication publiqueLe fait d’avoir accès à Code permet de travailler dans le workspace privé. Cela ne signifie pas qu’un projet est automatiquement publié sur Internet.

Liste et recherche de projets

Le rail de gauche de Code charge les projets disponibles pour l’utilisateur courant. Chaque entrée affiche le nom du projet ainsi que des informations synthétiques comme le nombre de fichiers et de checkpoints.

La recherche intégrée filtre actuellement la liste à partir du nom ou du slug du projet. Cette recherche agit sur les projets déjà chargés dans le workspace.

Si aucun projet n’existe encore et que l’accès beta est actif, l’interface propose de créer le premier projet. Si l’accès n’est pas actif, le rail affiche plutôt l’état correspondant du workspace.

Créer un projet

La création actuelle demande un nom de projet. Le formulaire limite ce nom à 120 caractères et envoie la création vers l’API projets authentifiée d’OrbitWake.

Après création, le workspace recharge la liste puis ouvre le nouveau projet. L’identifiant du projet devient alors la référence utilisée pour charger l’éditeur et ses ressources.

La création est désactivée si l’accès beta n’est pas actif. Les autres règles de nommage, quotas et validations sont appliquées par le backend et peuvent évoluer.

Ne documentez pas de quota fixeLes limites de projets et de stockage sont retournées par le statut beta. Elles ne doivent pas être présentées comme identiques pour tous les comptes.

Sélectionner et ouvrir un projet

Quand un projet est ouvert dans Code, son identifiant est placé dans le paramètre project de l’URL de /app/code. Cela permet au workspace de restaurer la sélection au chargement.

Si l’identifiant demandé n’existe plus dans la liste accessible, Code annule la sélection et revient au workspace principal plutôt que de conserver un projet invalide.

Le projet sélectionné est ensuite chargé dans l’éditeur privé. L’éditeur récupère ses fichiers, ses versions et, lorsqu’elles sont disponibles, les exécutions AI associées.

Fichiers du projet

Dans l’expérience actuelle, un fichier de projet contient notamment son chemin, son contenu, son type, sa taille et sa date de mise à jour. Le mode Code permet de sélectionner un fichier et de modifier son contenu depuis l’interface.

Les sauvegardes sont effectuées par l’éditeur. Lorsqu’un fichier actif change, l’interface peut enregistrer automatiquement son contenu après un court délai et affiche l’état de sauvegarde : enregistrement, enregistré ou erreur.

La preview privée utilise actuellement le contenu de index.html, styles.css et script.js lorsqu’ils existent. Cela décrit le comportement de la private beta actuelle et ne constitue pas une limitation permanente du produit.

Versions et checkpoints

Chaque projet peut posséder plusieurs versions. Les sources de version actuellement prévues incluent les checkpoints manuels, l’autosave, les builds AI et les restaurations.

Le bouton Checkpoint crée une version manuelle après sauvegarde du fichier actif. Cette version peut ensuite servir de point de retour.

Lorsqu’une restauration est demandée, OrbitWake affiche une confirmation avant de poursuivre. Le flux actuel prévoit également une sauvegarde automatique de l’état courant avant de restaurer le checkpoint choisi.

Utilisez les checkpoints avant un changement importantIls permettent de revenir à un état connu sans confondre restauration de projet et historique Git.

Preview privée et sandbox

Le mode Preview affiche le résultat du projet dans une iframe sandboxée. L’interface la présente comme une preview privée, accessible dans le contexte du compte, sans étape de publication publique automatique.

La preview applique une politique de sécurité restrictive : pas de connexion réseau depuis le document rendu, pas de formulaires externes, pas d’objets embarqués et scripts limités au sandbox de l’iframe.

Cette preview sert à inspecter rapidement le résultat du projet. Elle ne doit pas être confondue avec un environnement de production ou un déploiement public.

Nothing is published automaticallyUn build AI met à jour le projet et sa preview. Il ne publie pas automatiquement le résultat sur un domaine public.

Build avec AI

Le composer Code permet de décrire le résultat souhaité. Lorsqu’une exécution AI est activée, OrbitWake enregistre d’abord le fichier actif, lance le build puis recharge le projet retourné par le backend.

OrbitWake Auto est toujours proposé. GPT, Claude ou Grok apparaissent seulement lorsque le fournisseur correspondant est configuré dans l’environnement.

Après un build réussi, l’interface peut afficher un résumé, le modèle fournisseur réellement utilisé, les chemins modifiés et le coût facturé au crédit beta. Le compteur de builds par heure et le solde de crédit peuvent aussi être visibles lorsque ces informations sont disponibles.

Pendant un build, l’éditeur empêche certaines modifications concurrentes afin d’éviter que l’utilisateur et l’exécution AI écrivent simultanément sur le même état de projet.

Limites et états d’erreur

Les projets peuvent être limités par le nombre maximal de projets, le stockage ou la fréquence de build définis pour le compte beta. Le workspace affiche les erreurs renvoyées lorsqu’un projet ne peut pas être chargé, créé, sauvegardé, restauré ou construit.

Un projet indisponible ne doit pas être réparé en supprimant manuellement ses données. Utilisez d’abord l’état affiché dans Code et réessayez l’opération non destructive appropriée.

Les règles exactes de suppression, renommage, duplication, export, publication et liaison à un dépôt externe ne sont pas encore toutes documentées comme interfaces stables.

Bonnes pratiques

Gardez un projet par objectif ou base de code cohérente. Utilisez un nom clair, vérifiez le projet sélectionné avant un build et créez un checkpoint avant les changements importants.

Après un build AI, consultez la preview mais aussi le mode Code et le mode Changes. Une preview correcte visuellement ne garantit pas que tous les fichiers ont été modifiés de la manière attendue.

Ne considérez pas la preview privée comme une publication. Les étapes de déploiement, de domaine ou de production doivent rester séparées et explicites.

Étapes suivantes

Continuez avec Contexte du dépôt pour comprendre comment OrbitWake Code doit sélectionner les fichiers et informations nécessaires à une tâche sans traiter tout le projet comme un contexte unique.

Cette page vous a-t-elle aidé ?