ET-OVR-TOOL-CONTRACT-MODEL-001

Engineering Tool Contract Model#

Zweck#

Ein Tool Contract beschreibt die stabile, prüfbare Außensicht eines Engineering-Werkzeugs. Er trennt verbindliches Verhalten von austauschbaren Implementierungsdetails und verhindert, dass aus vorhandenem ⌘CodeCode ist eine ausführbare oder interpretierbare technische Realisierung, die durch Tests und Runtime-Evidence überprüfbar bleibt. stillschweigend neue Architektur abgeleitet wird.

Pflichtbestandteile#

Jeder lokale Tool Contract dokumentiert mindestens:

1. Verantwortung und Scope-Grenze,
2. Eingaben und deren Validierung,
3. Ausgaben und erzeugte ⌘EvidenceTechnical documentation artifact.,
4. Betriebsmodi einschließlich Dry-Run oder rein lesendem Modus,
5. zulässige Seiteneffekte und deren ausdrückliche ⌘FreigabeEin Release ist ein bewusst freigegebener und nachvollziehbarer Stand von Artefakten und ihrer Realisierung.,
6. Fehlerklassen und Exit-Code-Semantik,
7. Idempotenz-, Wiederholungs- und Recovery-Verhalten,
8. Sicherheits- und Secret-Regeln,
9. Traceability zu führenden Vorgaben,
10. Verifikationsnachweise.

Vertragsgrenze#

Ein Tool Contract darf eine führende Architekturvorgabe technisch spezialisieren, aber nicht ersetzen. Fachliche Modelle, Zielzustände und Repositoryverträge anderer Eigentümer werden referenziert. Implementierungsdetails sind nur dann Vertragsbestandteil, wenn externe Nutzer oder automatisierte Abläufe darauf angewiesen sind.

Gemeinsame Verhaltensregeln#

• Lesender, planender oder prüfender Betrieb ist der sichere Standard.
• Schreibende oder systemverändernde Modi benötigen eine ausdrückliche Option.
• Eingaben werden vor dem ersten Seiteneffekt vollständig geprüft, soweit dies technisch möglich ist.
• Fehlende Dateien in einem Overlay sind kein Löschauftrag.
• Secrets werden weder versioniert noch in Reports ausgegeben.
• Ausgaben sind für Menschen nachvollziehbar und, soweit automatisiert weiterverarbeitet, maschinenlesbar.
• Ein erfolgreicher Lauf liefert ◆EvidenceTechnical documentation artifact. über die tatsächlich ausgeführten Prüfungen oder Änderungen.
• Wiederholte Ausführung mit gleicher Eingabe darf keinen unkontrollierten zusätzlichen Zustand erzeugen.

Exit-Code-Baseline#

Soweit ein Werkzeug keine engere dokumentierte Semantik besitzt, gilt:

Feinere Codes dürfen lokal ergänzt werden, müssen dann jedoch im jeweiligen Vertrag stabil dokumentiert und getestet sein.

Vertragsstatus#

Ein Vertrag beschreibt nur vorhandene oder ausdrücklich freigegebene Werkzeugoberflächen. Geplante Funktionen werden als Requirement oder ⌘FindingTechnical documentation artifact. geführt, nicht als bereits gültiger Vertrag.