Source de vérité
Ce qui fait foi dans Orbit et comment éviter la dérive entre produit, UX et code.
Hiérarchie canonique
Jusqu’à ce que l’application de production atteigne la parité complète :
- orbit-brain-demo.html fait foi pour le comportement UX et les interactions.
- Les commentaires de spécification dans ce HTML font foi pour les invariants produit et le hand-off.
- README.md fait foi pour le contrat du repository et l’architecture globale.
- Les pages MDX organisent et rendent navigable cette même connaissance.
- Le futur code de production devra reproduire ces invariants avant de les faire évoluer.
Pourquoi conserver le HTML
Le HTML n’est pas un mock statique. Il encode notamment :
- tailles canoniques des nœuds ;
- séquence d’encodage ;
- lazy loading ;
- anti-collision ;
- focus et hover ;
- popovers ;
- ressort et drag ;
- Context Quality ;
- CU ;
- ingestion par pilier ;
- paywall contextuel ;
- Spaces ;
- hub admin de développement.
Une réécriture Next.js ne doit jamais modifier silencieusement un invariant simplement parce qu’une autre implémentation paraît plus simple.
Contrat de mise à jour
Toute décision qui change un invariant doit modifier la source exécutable, sa documentation interne, le README et les pages MDX concernées dans le même cycle de travail.
Sources canoniques par domaine
Orbit possède plusieurs sources canoniques spécialisées, sans les confondre.
| Domaine | Source canonique | Dérivés |
|---|---|---|
| Produit / UX Orbit | orbit-brain-demo.html | README, pages MDX, futur code production |
| Doctrine Founder OS | sources/indie-founder-os-agent-instruction.md | Skill Founder OS, Agent Founder, évaluations |
Une source canonique spécialisée ne remplace pas la source de vérité d’un autre domaine.
Le fichier Founder OS définit la doctrine opérationnelle du founder. Il ne modifie pas les invariants du Brain Orbit, de la mémoire, des Spaces ou des ACL.