OrbitWake Cloud
Vue d’ensemble
OrbitWake Cloud est actuellement une surface Preview. Le workspace authentifié indique explicitement que le provisioning Cloud n’est pas activé dans cette build et refuse d’afficher de fausses instances, un faux historique de déploiement ou des coûts synthétiques.
Statut actuel : Preview
La page /app/cloud est présente dans le workspace, mais elle n’expose pas encore un runtime d’infrastructure réel.
L’état produit est volontairement explicite : Cloud reste une surface de prévisualisation tant que le provisioning et les données d’exécution réelles ne sont pas connectés au workspace authentifié.
/cloud ne signifient pas qu’OrbitWake peut aujourd’hui créer, modifier ou supprimer des ressources Cloud depuis le workspace.Ce que le workspace authentifié expose aujourd’hui
| Surface | État réel |
|---|---|
| Page Cloud | Disponible avec le statut Preview. |
| Provisioning d’infrastructure | Non activé dans cette build. |
| Instances | Aucune instance réelle n’est inventée pour remplir l’interface. |
| Historique de déploiement | Aucun historique synthétique n’est présenté comme réel. |
| Dépenses Cloud | Aucun coût synthétique n’est affiché. |
| Runtime Cloud | Pas encore connecté au workspace authentifié. |
Surface publique Cloud
La page publique OrbitWake Cloud présente la direction produit autour de quatre notions : Environments, Deployments, Runtime et Logs.
Elle montre aussi un flux conceptuel allant de la source au build, puis à la release et au runtime.
Ces représentations servent à expliquer l’expérience visée. Elles ne constituent pas une preuve que les environnements, releases et logs affichés sur cette page sont issus d’un backend Cloud actuellement actif.
Quelle surface fait foi ?
Pour les capacités réellement disponibles, la source de vérité reste le workspace authentifié et ses données runtime.
Lorsqu’une page marketing contient une console, un statut, une release ou un exemple de log, la documentation Developers ne doit pas transformer ces éléments en fonctionnalités livrées tant qu’une implémentation vérifiable n’existe pas dans le produit authentifié.
Cette règle est particulièrement importante pour les surfaces opérationnelles, où une représentation visuelle réaliste pourrait autrement être confondue avec un environnement réellement provisionné.
Modèle conceptuel Cloud
La page publique décrit un modèle opérationnel cohérent pour la future surface Cloud.
| Concept | Direction produit | Statut actuel |
|---|---|---|
| Projects | Relier l’infrastructure au contexte source du projet. | La relation Cloud runtime n’est pas encore exposée. |
| Environments | Distinguer production, preview et développement. | Concept public ; données réelles non exposées. |
| Deployments | Suivre source, build et release. | Pas d’historique Cloud authentifié disponible. |
| Runtime | Afficher l’état du service associé à la release. | Runtime Cloud non connecté dans cette build. |
| Logs | Prolonger le flux opérationnel après le déploiement. | Pas de logs Cloud réels exposés dans la surface authentifiée. |
Cloud et projets
La direction produit prévoit que les opérations Cloud restent liées au projet qui les a produites. L’objectif est d’éviter une séparation artificielle entre code, release et runtime.
Cette relation reste aujourd’hui conceptuelle dans Cloud. La documentation ne doit pas encore promettre qu’un projet OrbitWake peut provisionner automatiquement son infrastructure ou posséder une liste d’environnements Cloud synchronisés.
Déploiements
La page publique illustre des releases courantes, précédentes et preview. Dans la build authentifiée actuelle, il n’existe cependant pas encore de source de données Cloud réelle alimentant un historique de déploiement.
La documentation détaillée des déploiements sera publiée lorsque les éléments suivants pourront être vérifiés dans le produit : origine de la release, statut de build, destination, historique, état courant et comportement de rollback.
Environnements
Production, Preview et Development sont utilisés publiquement pour illustrer l’organisation future des environnements.
Le workspace ne fournit pas encore une API ou une interface authentifiée permettant de créer, modifier, sélectionner ou supprimer ces environnements comme des ressources Cloud réelles.
Les noms d’environnements vus sur la page marketing doivent donc rester des exemples de direction produit.
Runtime
Le runtime Cloud visé doit représenter l’état réel d’un service, d’une release et de son environnement.
Aujourd’hui, aucun backend Cloud authentifié n’est présent dans le repo pour fournir cet état. La surface Cloud du workspace indique précisément que le provisioning et le runtime réel ne sont pas connectés.
La documentation ne doit donc pas annoncer un état active, ready ou similaire comme une donnée utilisateur lorsqu’il provient uniquement d’une illustration publique.
Logs
La page publique utilise des lignes de logs pour illustrer une séquence de déploiement : sélection de source, build, bundle, runtime et vérification.
Ces lignes sont illustratives. Elles ne proviennent pas encore d’un pipeline Cloud OrbitWake rattaché au workspace authentifié.
Une documentation Logs détaillée ne sera publiée que lorsqu’une source de logs réelle, un modèle de rétention, des filtres et une portée d’accès pourront être vérifiés.
Hosting, Domains et Cloud
La page publique relie Cloud à des surfaces spécialisées comme Hosting, Domains et Projects. Cette navigation décrit l’écosystème produit, mais elle ne transforme pas automatiquement ces surfaces en ressources Cloud provisionnées par le runtime Cloud.
Chaque surface doit être documentée à partir de sa propre implémentation réelle. Une capacité disponible ailleurs dans OrbitWake ne doit pas être présentée comme une capacité du runtime Cloud tant que l’intégration n’est pas effectivement connectée.
Pourquoi OrbitWake n’affiche pas de fausses ressources
Pour une surface d’infrastructure, des données factices peuvent être particulièrement trompeuses. Une instance fictive, un statut fictif ou un faux coût peuvent être interprétés comme un état réel du compte.
La build actuelle choisit donc de montrer un état Preview explicite plutôt qu’un tableau de bord simulé dans l’espace authentifié.
Cette frontière sera conservée dans la documentation : les exemples publics peuvent expliquer une direction UX, mais ne seront pas convertis en procédures opérationnelles avant que le backend correspondant existe.
Ce qui n’est pas encore disponible comme capacité Cloud stable
| Capacité | État actuel |
|---|---|
| Créer une instance | Non disponible. |
| Provisionner un environnement | Non disponible. |
| Déployer depuis Cloud | Pas de runtime Cloud authentifié exposé. |
| Consulter un historique de releases réel | Non disponible dans la surface Cloud authentifiée. |
| Lire des logs Cloud réels | Non disponible dans cette build. |
| Voir la consommation ou les coûts Cloud | Aucune donnée réelle ou synthétique affichée. |
| Rollback d’une release Cloud | Non documenté comme capacité stable. |
| Gérer secrets et variables depuis Cloud | Pas encore exposé comme workflow Cloud stable. |
Conditions pour publier les prochaines pages Cloud
Les pages Projets, Déploiements, Environnements et Logs documentent maintenant explicitement leur état Preview. Elles ne deviennent des procédures opérationnelles que lorsque le backend et l’interface réels sont vérifiables.
Une page Cloud détaillée sera publiée lorsqu’il sera possible de vérifier au minimum l’état de la ressource, les opérations disponibles, leurs effets, les permissions, les erreurs et les limites.
Cette approche évite de documenter une roadmap comme si elle était déjà disponible.
Limites actuelles
OrbitWake Cloud est Preview. Le provisioning, les déploiements, les environnements, le runtime et les logs ne sont pas encore alimentés par un backend Cloud authentifié dans cette build.
La page publique contient des démonstrations visuelles qui illustrent le produit visé ; elles ne doivent pas être utilisées comme référence opérationnelle.
Aucune procédure Developers ne doit actuellement demander à un utilisateur de créer, modifier ou supprimer une ressource Cloud depuis OrbitWake.
Étapes suivantes
Les sous-pages Cloud sont disponibles comme documentation de statut Preview. Elles seront enrichies avec des procédures opérationnelles au fur et à mesure que le runtime réel apparaîtra dans le workspace.