Repositories & delivery
Frontière entre la documentation Orbit et l’application de production.
Deux repositories, deux responsabilités
| Repository | Domaine | Responsabilité |
|---|---|---|
BoostEcom/orbit.boostecom.dev | orbit.boostecom.dev | documentation, source de vérité, ADR, contrats, prototype canonique |
BoostEcom/orbit.boostecom.app | orbit.boostecom.app | webapp, runtime, base de données, APIs, workers et code livré |
Aucun troisième repository webapp n’est nécessaire.
Pourquoi ne pas tout fusionner ?
Documentation.AI peut être connecté à un repository et déployer sa documentation depuis Git, mais cela ne fait pas de Documentation.AI un hébergeur de webapp Next.js.
Séparer docs et runtime permet :
- des ACL documentaires différentes des ACL de code ;
- des déploiements indépendants ;
- un historique produit plus lisible ;
- une source de vérité stable pendant les migrations applicatives ;
- moins de risque qu’un changement de build app casse la documentation.
Contrat entre les deux repositories
Avant parité production :
orbit.boostecom.dev
↓
spécification canonique
↓
orbit.boostecom.app
↓
implémentation
Une modification d’invariant produit commence dans la source de vérité puis est portée dans l’application.
Après parité, le code de production devient l’autorité sur le comportement réellement livré, tandis que la documentation reste l’autorité sur les contrats, décisions et concepts publics.
État du repo application existant
Le repository orbit.boostecom.app possède déjà un socle technique conséquent : monorepo pnpm, Next.js, base de données, moteur, connecteurs, tests et CI.
Il contient cependant encore des conventions et une narration héritées de l’ancien Studio / growth system.
Avant d’implémenter le nouveau Context OS, il faut donc réaliser un réalignement contrôlé, pas créer un nouveau repository :
- inventorier ce qui est réutilisable ;
- isoler ce qui appartient encore à l’ancien produit ;
- renommer packages et concepts au fur et à mesure ;
- porter les invariants Brain / Spaces / Memory / CU depuis la source de vérité ;
- conserver les protections techniques déjà utiles (tests, auth, DB, CI, guards).
Ne pas effectuer une réécriture massive « big bang ». Réutiliser le socle existant par tranches verticales et garder l’application buildable pendant toute la migration.