Jardis über MCP

Alles, was der Designer im Browser kann, steuerst du auch headless: über den MCP-Server. Ein AI-Agent treibt denselben Workspace ohne Browser: dieselbe Sequenz, nur über MCP-Calls statt UI-Klicks.

jardis mcp

Der Prozess bindet sich beim Start an einen Projekt-Root (den Workspace). Er ist zustandslos: jeder Call arbeitet gegen den aktuellen Disk-Zustand.

Tools vs. Resources

Die zwei Grundbausteine:

• Tools = Aktionen (create, save, validate, build). Schreibend; sie liefern ein Ergebnis oder einen strukturierten Fehler.
• Resources = read-only Projektionen des aktuellen Disk-Zustands (z. B. jardis://tree, jardis://schema/{domain}/{bc}). Kein Push, kein Subscribe: nach einem Write rufst du die Resource erneut ab, um den Effekt zu sehen.

Der Workflow

Dieselbe Kette wie im Designer, Schritt für Schritt über Tools; jeder Schritt lässt sich vorher gegen die eigene Resource gegenprüfen:

1. Workspace — der Prozess zeigt auf den Projekt-Root. Fehlt die Domänen-Struktur, erst strukturell aufbauen (Domäne / BC / Aggregat), dann Schema.
2. Schema importieren (import_schema) — DB-Verbindung oder handgeschriebenes Schema.yaml in den Bounded Context.
3. Aggregat speichern (save_aggregate) — der Designer-Graph: Entitäten, Relationen, Schlüssel.
4. Naming bestätigen (save_naming) — die Feld-Mapping-Konventionen des BC, vor dem Build.
5. Prozess modellieren (create_process / save_process / validate_process) — den BC-Prozessgraphen bauen, iterieren, strukturell validieren.
6. Build (build) — long-running, erzeugt den Code-Baum auf der Platte und sendet Fortschritts-Notifications.
7. Code lesen — über die Resource-Templates code-tree und code-file (chunked, mit Offset/Limit-Fenster), der Ersatz für „im Editor öffnen".

Auch die strategische Ebene ist voll erreichbar: save_glossary, save_steckbrief, die geplanten BCs (create_planned_bc … promote_bc) und die Context-Map-Kanten (create_context_map_edge …). Der Drift-Check liegt read-only unter jardis://context-map/{domain}/drift: inklusive Call-Evidenz je realer Kante.

Muster-Katalog abrufen, nicht hart verdrahten

Die acht kanonischen DDD-Muster liest ein Agent als Resource (context-map-patterns), statt die Namen fest zu kodieren.

Der GUI-Ersatz

Browser-Affordanzen ohne eigenen MCP-Button werden zu Datenoperationen:

• Ausgabeverzeichnis wählen (statt Dateidialog) → update_domain_manifest, Feld outputDir.
• Im Editor öffnen (statt IDE) → code-file-Resource, chunked lesen.
• Projekt wechseln (statt Workspace-Switcher) → kein In-Process-Wechsel. Ein Workspace = ein Prozess: für einen anderen Root startest du einen zweiten jardis mcp.

Workspace-Registry

Die host-weite Registry bekannter Projekte (für den UI-Startbildschirm) hat bewusst kein MCP-Tool. Für einen anderen Workspace einfach einen neuen Prozess starten: Registry-Mitgliedschaft ist für MCP irrelevant.

Fehler-Envelopes

Jeder Fehler kommt als strukturiertes Envelope, nie als nackter String: code, optional ruleId + location (bei Validator-Befunden), message (menschenlesbar) und hint (umsetzbar).

Code	Bedeutung
CONFLICT	Ressource wurde parallel geändert (mtime) — reload + retry, oder als Bestätigung werten.
CONFIRM_REQUIRED	Destruktiver Call (delete/rename mit realem Impact) — braucht ein explizites Confirm-Flag; vorher die Preview-Resource prüfen.
BUILD_RUNNING	Parallelbuild auf demselben Scope.
DRAFT_EXISTS	Ungesicherter Entwurf blockiert den Build.
VALIDATION	Struktureller Befund — Details im details-Feld, nicht unverändert erneut senden.
NOT_FOUND	Ziel existiert nicht.

Bei VALIDATION und CONFIRM_REQUIRED gilt: erst die Ursache beheben bzw. die Bestätigung liefern, nie unverändert erneut senden.

Die Tiefe zu Designdenken und Sorte-A-Nutzung steht im Skill jardis-mcp-consumer (siehe Skills).