astrale-os/astrale-domain

Domaine Astrale

Charger des connaissances détaillées du domaine à partir des références qui correspondent à l'objectif.

Limite du noyau

• Utiliser le schéma, les preuves exécutables et le linter de domaine du SDK comme garde-fous.
• Le code source du domaine importe les valeurs Core et de création DSL uniquement via les sous-chemins sémantiques correspondants @astrale-os/sdk/*. Ne pas importer @astrale-os/kernel-core ou @astrale-os/kernel-dsl directement, et ne pas les remplacer par un baril plat racine du SDK.
• Conserver l'autorisation dans la Politique (Policy) appartenant au schéma et le mode auth appelable ; les gestionnaires n'exécutent que les appels admis et ne définissent pas un second modèle d'autorisation.
• Choisir délibérément la portée de chaque nœud de politique existentielle : node() pour la correspondance appartenant à la topologie, node(Class) pour une famille polymorphe de classes, ou node.exact(Class) pour une identité exacte.
• Considérer les exportations publiques du SDK installé et le code source actuel du domaine comme faisant autorité pour la syntaxe de l'API.

Routeur d'intention

Utiliser ce routeur pour charger uniquement les références appartenant à la tâche en cours. Pour les nouveaux domaines, utiliser également le workflow par phases ci-dessous ; un échafaudage public existant satisfait déjà sa phase de fondation.

• Échafauder, déployer, installer, tester ou configurer TypeScript pour un domaine : lire references/development.md.
• Rédiger un schéma, un vocabulaire, des propriétés, des choix de classes/arêtes, ou réviser un schéma : lire d'abord references/schema.md. Toujours le lire pour un travail sur le schéma.
• Implémenter des gestionnaires, des liaisons appelables, des appels au noyau, des lectures/écritures de graphe, ou des appels entre domaines : lire references/runtime.md.
• Encapsuler une API externe, définir une intégration/un fournisseur, recevoir des webhooks, ou concevoir un comportement d'effet secondaire/de nouvelle tentative : lire references/integrations.md.
• Décider s'il faut réutiliser/importer un domaine Astrale natif plutôt que de modéliser une capacité soi-même : lire references/domains.md.
• Modéliser les utilisateurs connectés, inviter/enregistrer des personnes existantes, ou attribuer des groupes Shell : lire references/users.md.
• Sécuriser un domaine, une fonction, une vue, un appel client, un point de terminaison public, une identité, une délégation, un mode d'authentification, ou une politique : lire references/policies.md.
• Construire ou réviser des vues navigateur, une interface utilisateur montée, l'accès aux vues, la résolution des vues, ou la conception frontend : lire references/views.md et appliquer astrale-frontend-design pour la disposition, l'interaction et le texte de l'interface produit.
• Planifier ou qualifier une révision de schéma installée, une transition de données, ou un rattrapage : lire references/migration.md.
• Optimiser l'accès au graphe, réduire les allers-retours, choisir les index/requêtes, ou examiner les modèles d'appels pour la latence : lire references/performance.md.
• Rédiger ou mettre à jour des données de démonstration — les jeux de données sous tests/ que le Studio utilise et sur lesquels il prouve les politiques : lire references/datasets.md.
• Écrire des tests, des fixtures, des flux de démonstration, ou des scénarios de test rapide : lire references/testing.md.
• Diagnostiquer un domaine en direct défaillant, une confusion émetteur/découverte, un routage d'invocation, ou une dérive d'exécution : lire references/debugging.md.

Workflow de création d'un nouveau domaine

Pour une demande de création, construction, prototype ou POC d'un domaine, suivre les phases applicables dans l'ordre et charger une référence uniquement lorsque sa phase commence.

1. Fondation : Inspecter d'abord l'espace de travail. Lorsqu'aucun échafaudage public n'existe, lire references/development.md ; lire references/domains.md uniquement lorsqu'on décide de réutiliser un domaine natif. Lorsque l'espace de travail déclare déjà le SDK, l'adaptateur de déploiement, l'application et l'exécution, conserver cette plomberie et passer directement au schéma.
2. Schéma : Avant de rédiger le schéma, lire references/schema.md ; pour les utilisateurs connectés et les groupes, lire également references/users.md avant d'inventer un vocabulaire d'identité ou d'intégration.
3. Appelables : Avant d'implémenter des appelables, lire references/runtime.md et references/policies.md. Si un système externe est impliqué, lire également references/integrations.md.
4. Vues : Lorsque le domaine possède une surface navigateur, lire references/views.md avant de la concevoir ou de l'implémenter. Les vues sont des déclarations de schéma, pas des champs de la définition de domaine du SDK.
5. Données de démonstration : Pour un domaine avec un graphe d'exemple significatif, rédiger un petit jeu de données sous tests/, référencé depuis astrale.config.ts. Lire d'abord references/datasets.md ; ne pas inventer des données de graphe pour un domaine uniquement API ou étendre une modification ciblée en un travail de démonstration sans rapport.
6. Finalisation : Lire references/testing.md ; exercer les appelables publics livrés avec des entrées de succès représentatives et des entrées de refus applicables, puis exécuter les tests pertinents, la vérification de type, le lint et la construction. Vérifier l'empaquetage lors de la livraison d'un paquet consommable et le comportement en direct lors de la revendication d'un déploiement ou d'une intégration réussie.

Lire references/migration.md, references/performance.md et references/debugging.md uniquement lorsque le cycle de vie du domaine ou le problème actuel le nécessite.

Workflow permanent

1. Inspecter le dépôt ou l'échafaudage actuel avant de faire confiance à la syntaxe de l'API de mémoire.
2. Pour le comportement en direct, utiliser references/debugging.md et prouver le chemin déployé/installé/exécuté avant de considérer les modifications source comme effectives.
3. Lorsqu'une modification du schéma affecte des jeux de données existants, les maintenir valides et représentatifs dans la même modification. Lire references/datasets.md ; les exemples complètent les tests plutôt que d'épuiser tous les cas.