Zum Hauptinhalt springen

IronClaw Architektur und Laufzeit

1. Die Gestalt des Workspace​

Die README macht deutlich, dass IronClaws aktuelle Geschichte eine eigene Reborn-Laufzeit mit eigenem Binary und eigenem State-Root umfasst.

Das verrät dir schon etwas Wichtiges:

Das Projekt behandelt Laufzeitgrenzen und State-Layout als erstklassige Designaspekte

2. Das mentale Laufzeitmodell​

Zur Laufzeit funktioniert IronClaw im Allgemeinen so:

  1. die CLI löst das aktive Home und Profil auf,
  2. die Konfiguration wählt eine Modellroute,
  3. Umgebungsvariablen stellen Secrets bereit,
  4. die Laufzeit führt im gewählten Richtlinien- und Speichermodus aus,
  5. Ausgaben kommen über CLI-Flächen wie run, repl oder serve zurück.

3. Warum das Konfigurations-Home wichtig ist​

Weil IronClaw bei seinem Konfigurations-Root, seinen Dateien und seinem Seed-Verhalten explizit ist, ist das Home-Verzeichnis kein Randdetail. Es ist die Betriebsgrenze fĂĽr:

  • config.toml,
  • providers.json,
  • Profile,
  • und Laufzeitzustand.

Das macht die Architektur leichter durchschaubar als Systeme, die den Zustand ĂĽber viele Orte verteilen.

4. Richtlinien- und Deployment-Modi sind Teil der Architektur​

Die README zeigt, dass Richtlinie und Speicher nicht nur optionale Features sind. Sie prägen echte Deployment-Modi, einschließlich produktionsnaher Konfigurationen mit PostgreSQL und expliziten Richtlinienabschnitten.

Deshalb wirkt IronClaw eher wie eine betreiberfreundliche Laufzeit als wie eine Hobby-CLI.

5. Was man im Code zuerst lesen sollte​

Beginne mit:

  1. dem Reborn-Quick-Start in der README,
  2. den Konfigurations- und Anbieter-Docs,
  3. dem Laufzeit- und Speichercode,
  4. den Richtlinienflächen,
  5. den Skills oder Automatisierungserweiterungen, sobald der Kernablauf klar ist.