astrale-os/astrale-domain

Astrale Domain

Lade detailliertes Domänenwissen aus den Referenzen, das zum Ziel passt.

Kernel-Grenzen

• Verwende Schema, ausführbare Evidenz und den Domain Linter des SDK als Leitplanken.
• Der Domain-Quellcode importiert Core- und DSL-Authoring-Werte nur über den passenden semantischen @astrale-os/sdk/* Subpath. Importiere nicht @astrale-os/kernel-core oder @astrale-os/kernel-dsl direkt und ersetze sie nicht durch ein flaches SDK-Root-Barrel.
• Halte die Autorisierung in der Policy des Schemas und im aufrufbaren auth-Modus; Handler führen nur zugelassene Aufrufe aus und definieren kein zweites Autorisierungsmodell.
• Wähle den Umfang jedes existentiellen Policy-Knotens bewusst: node() für topologie-eigenes Matching, node(Class) für eine polymorphe Class-Familie oder node.exact(Class) für exakte Identität.
• Behandle die öffentlichen Exporte des installierten SDKs und den aktuellen Domain-Quellcode als maßgeblich für die API-Syntax.

Intent-Router

Verwende diesen Router, um nur die Referenzen zu laden, die zur aktuellen Aufgabe gehören. Für neue Domänen verwende auch den unten stehenden schrittweisen Workflow; ein vorhandenes öffentliches Grundgerüst erfüllt bereits dessen Grundlagenphase.

• Scaffold, deploye, installiere, teste oder konfiguriere TypeScript für eine Domäne: lies references/development.md.
• Erstelle Schema, Vokabular, Eigenschaften, Class/Edge-Entscheidungen oder überprüfe ein Schema: lies zuerst references/schema.md. Lese sie immer bei Schema-Arbeiten.
• Implementiere Handler, aufrufbare Bindungen, Kernel-Aufrufe, Graph-Lese-/Schreibzugriffe oder domänenübergreifende Aufrufe: lies references/runtime.md.
• Kapsle eine externe API, definiere eine Integration/einen Provider, empfange Webhooks oder entwerfe Seiteneffekt-/Retry-Verhalten: lies references/integrations.md.
• Entscheide, ob eine native Astrale-Domäne wiederverwendet/importiert werden soll, anstatt eine Fähigkeit selbst zu modellieren: lies references/domains.md.
• Modelliere angemeldete Benutzer, lade bestehende Personen ein/registriere sie oder weise Shell-Gruppen zu: lies references/users.md.
• Sichere eine Domäne, Funktion, View, Client-Aufruf, öffentlichen Endpunkt, Identität, Delegation, Authentifizierungsmodus oder Policy: lies references/policies.md.
• Erstelle oder überprüfe Browser-Views, eingebundene UI, View-Zugriff, View-Auflösung oder Frontend-Design: lies references/views.md und wende astrale-frontend-design für Produkt-Interface-Layout, Interaktion und Copy an.
• Plane oder qualifiziere eine installierte Schema-Revision, Datenmigration oder Backfill: lies references/migration.md.
• Optimiere Graph-Zugriff, reduziere Roundtrips, wähle Indizes/Queries oder überprüfe Aufrufmuster auf Latenz: lies references/performance.md.
• Erstelle oder aktualisiere Demo-Daten – die Datasets unter tests/, die das Studio zeichnet und auf Policies prüft: lies references/datasets.md.
• Schreibe Tests, Fixtures, Demo-Abläufe oder Smoke-Test-Szenarien: lies references/testing.md.
• Diagnostiziere eine fehlerhafte Live-Domäne, Issuer/Discovery-Verwirrung, Invocation-Routing oder Runtime-Drift: lies references/debugging.md.

Workflow zur Erstellung neuer Domänen

Für eine Anfrage zur Erstellung, zum Bauen, Prototyping oder Erstellen eines POC einer Domäne folge den anwendbaren Phasen der Reihe nach und lade eine Referenz erst, wenn ihre Phase beginnt.

1. Grundlagen: Durchsuche zuerst das Workspace. Wenn kein öffentliches Grundgerüst existiert, lies references/development.md; lies references/domains.md nur, wenn du entscheiden musst, ob eine native Domäne wiederverwendet werden soll. Wenn das Workspace bereits das SDK, den Deployment-Adapter, die Application und die Runtime deklariert, behalte diese Infrastruktur und gehe direkt zum Schema über.
2. Schema: Bevor du das Schema erstellst, lies references/schema.md; für angemeldete Benutzer und Gruppen lies außerdem references/users.md, bevor du Identitäts- oder Onboarding-Vokabular erfindest.
3. Callables: Bevor du Callables implementierst, lies references/runtime.md und references/policies.md. Wenn ein externes System beteiligt ist, lies auch references/integrations.md.
4. Views: Wenn die Domäne eine Browser-Oberfläche besitzt, lies references/views.md, bevor du sie entwirfst oder implementierst. Views sind Schema-Deklarationen, keine Felder in der SDK-Domänendefinition.
5. Demo-Daten: Für eine Domäne mit einem aussagekräftigen Beispielgraphen erstelle ein kleines Dataset unter tests/, das in astrale.config.ts referenziert wird. Lies zuerst references/datasets.md; erfinde keine Graphdaten für eine reine API-Domäne oder erweitere eine fokussierte Bearbeitung nicht zu unnötigen Demo-Arbeiten.
6. Abschluss: Lies references/testing.md; führe die ausgelieferten öffentlichen Callables mit repräsentativen Erfolgs- und zutreffenden Ablehnungseingaben aus, führe dann die relevanten Tests, Typecheck, Lint und Build durch. Überprüfe die Paketierung, wenn ein konsumierbares Paket ausgeliefert wird, und das Live-Verhalten, wenn Deployment- oder Integrationserfolg beansprucht wird.

Lies references/migration.md, references/performance.md und references/debugging.md nur, wenn der Lebenszyklus der Domäne oder das aktuelle Problem sie erfordert.

Immer aktiver Workflow

1. Durchsuche das aktuelle Repository oder Grundgerüst, bevor du dich auf die API-Syntax aus dem Gedächtnis verlässt.
2. Verwende für Live-Verhalten references/debugging.md und überprüfe den deployed/installierten/Runtime-Pfad, bevor du Quellcode-Änderungen als wirksam betrachtest.
3. Wenn eine Schema-Änderung bestehende Datasets betrifft, halte sie in derselben Änderung gültig und repräsentativ. Lese references/datasets.md; Beispiele ergänzen Tests, anstatt jeden Fall auszuschöpfen.