AURA

Zusammenfassung

AURA ist ein repo-sourced Architecture Knowledge System.

← Zurück zur Übersicht

Zusammenfassung

Kernzusammenfassung

AURA ist ein repo-sourced Architecture Knowledge System.

Jedes Repository enthält eine normalisierte, versionierte technische Dokumentation mit C4-Diagrammen, ADRs, Metadaten und Schnittstellenbeschreibungen.

Bei Pull Requests prüft AURA, ob architekturrelevante Änderungen korrekt dokumentiert wurden.

Nach dem Merge erzeugt AURA aus den validierten Repository-Artefakten einen nachvollziehbaren Architecture Snapshot und aktualisiert daraus:

zentrale MkDocs-Webseite
Service-Katalog
Dependency Graph
Suchindex
Embedding Index
AI Context Layer
MCP Server

Über den MCP Server stellt AURA geprüften Kontext und ausgewählte Tools für KI-Assistenten bereit.

Dadurch können Feature-Analyse, Architekturverständnis, Ticket-Erstellung, Pull-Request-Review und Code-Exploration auf geprüften, versionierten Architekturinformationen basieren.

Der wichtigste Satz

AURA ist die Architektur-Kontextschicht zwischen Code, Menschen und KI.

Oder ausführlicher:

AURA macht aus repo-naher, versionierter und menschlich geprüfter Architektur-Dokumentation eine zentrale, durchsuchbare und KI-nutzbare Architekturübersicht.

Die zehn Kernaussagen

  1. Repo als Source of Truth — Die Wahrheit lebt im Repository, nicht im Portal.
  2. Doku ist Teil des Codes — Versioniert, reviewbar, CI-validiert.
  3. AURA prüft im PR — Architekturrelevante Änderungen brauchen Doku.
  4. Snapshots statt loser Texte — Jede zentrale Aussage ist auf Commit, PR und Owner zurückführbar.
  5. C4 als Diagrammstandard — Mindestens C1 und C2, Quellen versioniert.
  6. ADRs erklären das Warum — Strukturiert und auffindbar.
  7. KI bekommt geprüften Kontext — Mit Quellen, nicht nur Embeddings.
  8. MCP als Schnittstelle — Resources, Tools und Prompts für KI-Assistenten.
  9. Menschen entscheiden, KI unterstützt — Human-in-the-loop bleibt nicht-verhandelbar.
  10. Stufenweise einführen — Erst Hinweise, dann Warnungen, dann harte Gates.

Nächster sinnvoller Schritt

Der nächste Schritt wäre nicht sofort die technische Implementierung, sondern die Definition des Standards.

Konkret sollten als Nächstes definiert werden:

  1. Welche Repository-Typen gibt es?
  2. Welche Doku-Dateien sind pro Repo-Typ Pflicht?
  3. Wie sieht architecture.yaml exakt aus?
  4. Welche C4-Diagramme sind Pflicht?
  5. Wie sieht ein ADR-Template aus?
  6. Welche PR-Regeln gelten initial?
  7. Welche Informationen braucht der erste MkDocs-Prototyp?
  8. Welche MCP Resources und Tools wären für den ersten AI-Use-Case nötig?

Erst danach sollte ein MVP gebaut werden.

Weiterlesen

← Zurück zur Übersicht

Vorlagen und CLI