EP-CONTRACT-001
Engineering Platform Contract#
Zweck#
Dieser Contract ist die repositoryweite Ordnungs- und Ausführungsschicht der Engineering Platform. Er konkretisiert die übergeordneten Architektur- und Governance-Quellen für dieses Produkt, ohne sie zu duplizieren.
Geltungsreihenfolge#
Architecture Contract
→ geltende Solution- und Enterprise-Quellen
→ beauftragter Engineering-Scope
→ Engineering Platform Contract
→ Plateau- oder Feature-Vertrag
→ Repositoryzustand
→ Implementierung
Die bestehende Implementierung ist Evidenz. Sie ersetzt keine Architekturentscheidung.
Verbindliche Engineering-Folge#
Exploration
→ Contract und Scope
→ Requirements und Traceability
→ Materialisierung
→ Validation
→ Verification
→ Packaging
→ Promotion
→ Deployment oder Delivery
→ Evidence und Review
Ein Schritt darf übersprungen werden, wenn der konkrete Vertrag ihn ausdrücklich als nicht anwendbar kennzeichnet. Ein stillschweigendes Überspringen ist unzulässig.
Änderungsvertrag#
Jede fachlich sichtbare Änderung benennt mindestens:
- Ziel und Nicht-Ziele,
- verantwortlichen Bereich,
- führende Quellen,
- betroffene Artefakte,
- erwartete Validierung und Verifikation,
- Packaging- und Migrationsauswirkung,
- nachvollziehbare Ergebnisse oder Findings.
Qualitätsvertrag#
Eine Änderung gilt nicht allein deshalb als abgeschlossen, weil Dateien erzeugt oder Tests ausgeführt wurden. Erforderlich sind:
- konsistente Verantwortungsgrenzen,
- gültige Navigation und Referenzen,
- vollständiges Frontmatter für Dokumentartefakte,
- vorhandene und nachvollziehbare Verifikationsnachweise,
- keine impliziten Löschungen,
- environment-neutrale Konfiguration,
- dokumentierte Abweichungen und offene Risiken.
Konfliktregel#
Widersprüche zwischen Contract, GlossarbegriffEin Plateau ist ein zeitlich eingeordneter, freigegebener Reife- oder Materialisierungsstand.Glossareintrag vollständig lesen, Repository und Implementierung werden dokumentiert. Die Engineering Platform ändert keine übergeordnete Quelle implizit. Dauerhafte Abweichungen benötigen eine ausdrückliche Architecture Decision.
Verhältnis zu spezialisierten Verträgen#
Spezialisierte Verträge dürfen diesen Contract konkretisieren, etwa für Backend, Frontend, Persistenz, Runtime, Installer oder Tests. Sie dürfen seine Geltungsreihenfolge, Ownership-Grenzen und Nachweispflichten nicht abschwächen.