astrale-os/astrale-domain

Astrale Domain

Carregue conhecimento detalhado do domínio a partir das referências que correspondem ao objetivo.

Limite do Kernel

• Use Esquema, evidências executáveis e o linter de Domínio do SDK como guardrails.
• O código-fonte do Domínio importa valores de criação do Core e DSL apenas por meio do subcaminho semântico correspondente @astrale-os/sdk/*. Não importe @astrale-os/kernel-core ou @astrale-os/kernel-dsl diretamente, e não os substitua por um barrel raiz do SDK.
• Mantenha a autorização na Política de propriedade do Esquema e no modo auth chamável; os handlers executam apenas chamadas admitidas e não definem um segundo modelo de autorização.
• Escolha a extensão de cada Nó de Política existencial deliberadamente: node() para correspondência de propriedade da topologia, node(Class) para uma família polimórfica de Classes ou node.exact(Class) para identidade exata.
• Trate as exportações públicas do SDK instalado e o código-fonte atual do Domínio como autoritativos para a sintaxe da API.

Roteador de Intenções

Use este roteador para carregar apenas as referências de propriedade da tarefa atual. Para novos Domínios, use também o fluxo de trabalho em fases abaixo; um scaffold público existente já satisfaz sua fase de fundação.

• Scaffold, implantar, instalar, testar ou configurar TypeScript para um domínio: leia references/development.md.
• Criar esquema, vocabulário, propriedades, escolhas de Classe/Aresta ou revisar um esquema: leia references/schema.md primeiro. Sempre leia para trabalho em esquema.
• Implementar handlers, bindings chamáveis, chamadas ao kernel, leituras/escritas de grafo ou chamadas entre domínios: leia references/runtime.md.
• Encapsular uma API externa, definir uma Integração/Provider, receber webhooks ou projetar comportamento de efeito colateral/retry: leia references/integrations.md.
• Decidir se deve reutilizar/importar um domínio Astrale nativo em vez de modelar uma capacidade você mesmo: leia references/domains.md.
• Modelar usuários que fazem login, convidar/registrar pessoas existentes ou atribuir grupos Shell: leia references/users.md.
• Proteger um Domínio, Função, Visualização, chamada de cliente, endpoint público, identidade, delegação, modo de autenticação ou Política: leia references/policies.md.
• Construir ou revisar visualizações em navegador, UI montada, acesso a Visualizações, resolução de Visualizações ou design de frontend: leia references/views.md e aplique astrale-frontend-design para layout, interação e texto da interface do produto.
• Planejar ou qualificar uma revisão de Esquema instalado, transição de dados ou backfill: leia references/migration.md.
• Otimizar acesso a grafo, reduzir viagens de ida e volta, escolher índices/consultas ou revisar padrões de chamada para latência: leia references/performance.md.
• Criar ou atualizar dados de demonstração — os Conjuntos de Dados sob tests/ que o Studio desenha e prova políticas: leia references/datasets.md.
• Escrever testes, fixtures, fluxos de demonstração ou cenários de smoke-test: leia references/testing.md.
• Diagnosticar um domínio ativo com falha, confusão de emissor/descoberta, roteamento de invocação ou deriva de runtime: leia references/debugging.md.

Fluxo de Trabalho de Criação de Novo Domínio

Para uma solicitação de criar, construir, prototipar ou fazer um POC de um Domínio, siga as fases aplicáveis em ordem e carregue uma referência apenas quando sua fase começar.

1. Fundação: Inspecione o workspace primeiro. Quando não existir um scaffold público, leia references/development.md; leia references/domains.md apenas ao decidir se deve reutilizar um Domínio nativo. Quando o workspace já declarar o SDK, adaptador de implantação, Aplicação e Runtime, mantenha essa parte de infraestrutura e vá diretamente para o Esquema.
2. Esquema: Antes de criar o esquema, leia references/schema.md; para usuários que fazem login e grupos, leia também references/users.md antes de inventar identidade ou vocabulário de integração.
3. Chamáveis: Antes de implementar chamáveis, leia references/runtime.md e references/policies.md. Se um sistema externo estiver envolvido, leia também references/integrations.md.
4. Visualizações: Quando o Domínio possui uma superfície de navegador, leia references/views.md antes de projetá-la ou implementá-la. Visualizações são declarações de Esquema, não campos na definição de Domínio do SDK.
5. Dados de demonstração: Para um Domínio com um grafo de amostra significativo, crie um pequeno Conjunto de Dados sob tests/, referenciado a partir de astrale.config.ts. Leia references/datasets.md primeiro; não invente dados de grafo para um Domínio apenas de API nem expanda uma edição focada em trabalho de demonstração não relacionado.
6. Conclusão: Leia references/testing.md; exercite os chamáveis públicos entregues com entradas de sucesso representativas e entradas de recusa aplicáveis, então execute os testes relevantes, verificação de tipos, lint e build. Verifique o empacotamento ao entregar um pacote consumível e o comportamento em produção ao reivindicar sucesso de implantação ou integração.

Leia references/migration.md, references/performance.md e references/debugging.md apenas quando o ciclo de vida do domínio ou o problema atual exigir.

Fluxo de Trabalho Sempre Ativo

1. Inspecione o repositório ou scaffold atual antes de confiar na sintaxe da API a partir da memória.
2. Para comportamento em produção, use references/debugging.md e comprove o caminho implantado/instalado/runtime antes de tratar edições de código-fonte como eficazes.
3. Quando uma alteração no Esquema afetar Conjuntos de Dados existentes, mantenha-os válidos e representativos na mesma alteração. Leia references/datasets.md; exemplos complementam testes, em vez de exaurir todos os casos.