As-Is
Was der Code tatsächlich enthält.
ARCHITEKTURVERTRAG · EXPLORER · DETERMINISTISCHE CHECKS
Ein Architekturvertrag.
Für dich und deinen Agenten.
Definiere Komponenten, Verantwortlichkeiten und erlaubte Abhängigkeiten. Prüfe Implementierung, deklariertes Target und ihre Unterschiede im ArchQ Explorer. Dein Coding-Agent fragt denselben Vertrag und dieselben Befunde ab.
Architekturchecks für Coding-Agenten
Lokal · Ohne LLM im Checker · MIT · Python, Dart, TypeScript mit unterschiedlichem Prüfumfang
ArchKeel 2.0.0: unsere eigene Architektur123 Dateien · 36 Komponenten
Target
Was der Vertrag deklariert.
Diff
Wo Implementierung und Target voneinander abweichen.
Suche · Health check · Perspektiven · Vollbild · SVG- und Mermaid-Export
Öffne eine Komponente und erkunde ihre Verantwortlichkeiten, Schnittstellen und Abhängigkeiten. As-Is, Target und Diff zeigen unseren eigenen Code und den dafür deklarierten Vertrag.
Aufgezeichneter Snapshot · aa159e5 · abgerufen am 2026-10-12. Analysegrenzen und UNKNOWN stehen im Report.
Vollständigen Report öffnen ↗Neueste veröffentlichte Fassung ↗✓Quellbelege zum Befund✓Deklarierte Änderungen prüfen✓UNKNOWN bleibt sichtbar
GRÜNE TESTS REICHEN NICHT
Aus einer entschiedenen Grenze
wird ein prüfbarer Befund.
Ein Coding-Agent kann eine Grenze verletzen, ohne einen Verhaltenstest zu brechen. Diese Regel beschreibt die Grenze. Der Befund zeigt die konkrete Quellstelle.
DEIN VERTRAGJSON · Regel-Ausschnitt
{
"id": "DEP-RENDER-NO-STORE",
"kind": "forbidden_dependency",
"source": "shop.render",
"target": "shop.store",
"include_type_checking": true,
"rationale": "Text projection consumes typed values without touching persistence.",
"provenance": ["docs/architecture/shop.md"],
"decided_by": "architect"
}10 Zeilen aus der Shop-Regel. Der vollständige Vertrag enthält auch Komponenten und weitere Regeln.
ARCHKEEL / DOKUMENTIERTER BEFUNDFAIL
render → store
Die Darstellung greift direkt auf die Persistenz zu. Diese Abhängigkeit ist im Vertrag verboten.
shop/render/text.py:9
from shop.store import OrderRepository- rule
- DEP-RENDER-NO-STORE
- finding
- rule.violated
- evidence
- closed_world.observed_forbidden
Quelle: Shop-Fixture im README.
BELEG / PYTHON-REPLAY
Acht Tests bleiben grün.
Ein Aufruf ist nicht mehr auflösbar.
Ein Wechsel zu Dictionary-Dispatch lässt die acht Verhaltenstests grün. Die statische Analyse kann den neuen Aufruf nicht mehr auflösen. Der Kandidat wird wegen dieser Regression abgelehnt.
before → candidate
# before · sample/work.py
from sample.helpers import credit, debit
def run(key: str, amount: int) -> int:
if key == 'credit':
return credit(amount)
if key == 'debit':
return debit(amount)
raise KeyError(key)
# candidate · sample/work.py
from sample.helpers import credit, debit
def run(key: str, amount: int) -> int:
handlers = {'credit': credit, 'debit': debit}
return handlers[key](amount)Verhaltenstests8/8 → 8/8
Unaufgelöste Aufrufe0 → 1
Architekturverstöße0 → 0
archkeel checkFAIL · exit 1
Dieser Replay misst statische Sichtbarkeit. Er weist keinen Laufzeitfehler nach. Die vollständigen Bedingungen und Call-Zahlen stehen im Quellnachweis.
Bedingungen & Quelle ↗Result JSON ↗Reproduzieren ↗WARUM ARCHKEEL?
Wann lohnt sich ArchKeel zusätzlich
zu deinem Architekturchecker?
Import Linter und Tach prüfen Python-Grenzen; ArchUnit prüft JVM-Architektur, einschließlich Aufrufen und Zugriffen. dependency-cruiser und Nx prüfen Abhängigkeiten in JavaScript-/TypeScript-Projekten.
ArchKeel verbindet deklarierte Änderungsprüfungen, Regressionen in vergleichbaren Analysebelegen und fokussierte Snapshot-Abfragen mit sichtbarem UNKNOWN. Auch ANMA und code-governance unterstützen Agenten. Wähle ArchKeel, wenn du diesen Prüfablauf brauchst.
Deklarierte Änderung
Den Kandidaten mit einer vorher veröffentlichten Erwartung vergleichen.
Analyseverlust erkennen
Weniger Befunde reichen nicht, wenn die Analyse weniger erkennen kann.
Gezielte Belege
Vertrag und Befunde gezielt abfragen. Globale Ergebnisse und UNKNOWN erhalten.
Vergleiche die Werkzeuge anhand deines Prüfablaufs.
Werkzeuge und Grenzen vergleichenERSTER EIGENER CHECK
Installieren.
Grenzen prüfen lassen.
Python 3.11+ und ein Git-Repository mit mindestens einem Commit. Die Python-Version muss zu deinem Projekt passen.
Bitte deinen Agenten: Lies die Architekturdokumente, schlage Grenzen vor und lass mich die erlaubten Abhängigkeiten entscheiden.
Onboarding lesen ↗local setup
uv tool install archkeel
archkeel skill install codex
# or: archkeel skill install claudeFür einen geprüften Vertrag
archkeel validateFür den deklarierten Change-Check: archkeel check mit dem eingerichteten Protokoll. report erzeugt Belege und kann trotz FAIL oder UNKNOWN mit Exit 0 enden.
ArchKeel 2.0.0 ist veröffentlicht. Historische Beispiele nutzen ihre dokumentierten Versionen. Release notes ↗
ARCHKEEL PRÜFT ARCHKEEL
Unsere Architektur. Unsere Befunde.
Wir prüfen unseren eigenen Code mit demselben Werkzeug. Der Snapshot im Explorer enthält diese Regelbewertungen:
49 Regeln
Vollständig geprüfte Regeln ohne Verstöße.
0 Regeln
Regeln mit belegten Verstößen.
4 Regeln
Regeln, für die vollständige Belege fehlen.
Gesamtergebnis: UNKNOWN. Bestandene Regeln lösen die verbleibenden Analysefragen nicht auf.
Befunde und Belege öffnen ↗FAQ
Was prüft ArchKeel?
Was ist ArchKeel?
Architekturchecks für Coding-Agenten. ArchKeel prüft deklarierte Architekturgrenzen und Änderungen in Code, der mit KI-Unterstützung entsteht. Die CLI prüft lokal und deterministisch, ohne LLM im Checker.
Wann reicht ein anderer Checker?
Wenn du nur Import- oder Modulgrenzen in deinem vorhandenen Stack brauchst, kann dein bestehender Checker ausreichen. ArchUnit bietet darüber hinaus JVM-Strukturtests.
Was kann ArchKeel nicht beweisen?
Keine vollständige Laufzeitkorrektheit oder gute Architektur. Die Analyse ist statisch und vom Sprachprofil abhängig.
Ist Studio schon verfügbar?
Die kollaborative Studio-Oberfläche ist geplant. Die CLI und ihre Reports sind verfügbar. Den Studio-Entwurf findest du auf Vision & Roadmap.