Registry System

Registries sind die kanonischen Verzeichnisse für Domains, Nodes, Repos, Solutions und Universes. Sie sind das Discovery-Rückgrat für skalierbare Agentic Cooperation Spaces.

1. Zweck der Registry-Schicht

Registries sorgen dafür, dass neue Knoten und Beziehungen nicht implizit „gefunden“ werden, sondern explizit, versionierbar und auditierbar registriert sind.

Discovery mit nachvollziehbarer Quelle State-change als Transaction Fraktal skalierbar Keine stille Auto-Aufnahme

2. Die 5 Registry-Typen

Registry	Datei	Fokus
Domain Registry	`registries/domain-registry/domain-registry.yaml`	Welche Domänen im Space geführt werden
Node Registry	`registries/node-registry/node-registry.yaml`	Welche Nodes im Universe aktiv sind
Repo Registry	`registries/repo-registry/repo-registry.yaml`	Quell- und Ziel-Repositories als Integrationspunkte
Solution Registry	`registries/solution-registry/solution-registry.yaml`	Lösungsbausteine, Patterns und bundelbare Services
Universe Registry	`registries/universe-registry/universe-registry.yaml`	Übergeordnete Universe-Struktur und Föderationsbezüge

3. Aktueller Seed-Status

Im Basistemplate sind die Registry-Dateien absichtlich leer und dienen als kanonische Container, die node-lokal befüllt werden:

# domain-registry.yaml
 domains: []

# node-registry.yaml
 nodes: []

# repo-registry.yaml
 repos: []

# solution-registry.yaml
 solutions: []

# universe-registry.yaml
 universes: []

Leere Listen sind in dieser Phase korrekt: sie signalisieren „Schema steht, Instanzen folgen kontrolliert“.

4. Befüllregeln (operativ)

Schritt	Regel
Eintrag vorschlagen	Story, Owner, Purpose und Scope müssen benannt sein
Boundary prüfen	Neue externe Kanten prüfen (insb. repo/universe-Einträge)
TX loggen	Registry-Änderung ist State-Änderung und wird als Transaction erfasst
Review Gate	Bei riskanten Domains oder Cross-Org-Bezügen ist HITL-Gate verpflichtend
Append-only Historie	Keine stillen Löschungen; Stilllegung als neuer Status/Eintrag

5. Relation zu Flows und Federation

Die Flow-Registry führt die Prozessmodelle (z.B. federation-flow), während die Registries die strukturellen Objekte führen. Beides zusammen ergibt den kontrollierten Discovery- und Kopplungsraum.

flow-registry.yaml
  - story-to-reality
  - import-flow
  - publishing-flow
  - service-flow
  - contract-flow
  - agent-workflow
  - federation-flow
  - coding-flow

Praktisch heißt das: Flows definieren, wie gearbeitet wird; Registries definieren, worauf gearbeitet wird.

6. typische Anti-Pattern

Node genutzt, aber nicht registriert Repo-Kopplung ohne Registry-Eintrag Registry geändert ohne TX Cross-Org Beziehung ohne Federation-Gate

Diese Muster führen zu Drift, schlechter Auditierbarkeit und nicht reproduzierbarer Orchestrierung.

P-PROJ-003 P-PROJ-006 P-TXN-005 P-TXN-006 P-BOUND-001 P-FED-001