RUNTIME-RESPONSIBILITY

Runtime Responsibility#

Eigene Verantwortung#

Dieses Repository materialisiert Runtime- und Execution-Capability-Verträge. Der technische Repositoryname runtime bleibt unverändert; die kanonische Begriffsklärung liegt in enterprise-architecture:98-glossary/[[GLOSSARY-EXECUTION-CAPABILITY|execution-capability]].md.

Dieses Repository besitzt:

materialisierte Test- und Produktionsinstallationen,
deklarierte Konfigurationsorte und Environment-Grenzen,
mutable Runtime-Zustände und erzeugte ,
die Trennung von Test und Produktion.

Nicht #

Dokumente oder Artefakte innerhalb von test/installations/, production/installations/ oder Reports können vollständige materialisierte Kopien aus anderen Repositorys sein. Sie bleiben nicht-kanonische Snapshots der installierten Revision. Änderungen an ihrer erfolgen ausschließlich in ihrem Quellrepository und werden anschließend neu materialisiert.

Führende Quellen#

enterprise-architecture:00-overview/cross-repository-responsibility-model.md
                solution-architecture:00-overview/solution-scope-and-boundaries.md
                engineering-platform:00-overview/RESPONSIBILITY_BOUNDARIES.md
                engineering-tools:00-overview/REPOSITORY_BOUNDARIES.md

Änderungsregel#

Runtime-Dateien dürfen lokale Zustände oder materialisierte Revisionen verändern. Sie dürfen keine Architekturentscheidung, keinen Solution Contract und keinen Engineering Tool Contract neu definieren.

Workspace-Konsolidierung#

Für die Workspace-Konsolidierung materialisiert Runtime lokale Ausführung, Konfiguration, veröffentlichte Reports und Execution . Wiederverwendbare Renderer-, Resolver-, Validator- und Packaging-Mechanik bleibt in engineering-tools; der historische Workspace bleibt Quelle oder enger Kompatibilitätsadapter. Eine mögliche SQLite-Universe-Registry wird erst nach einer expliziten Persistenzentscheidung in Runtime aufgenommen.

Deklarierte Realisierungskette#

RC-0001 – Verifizierter Engineering-Roundtrip verwendet test/installations/engineering-platform/deployment.json als Materialisierung und test/reports/startup/engineering-platform-startup.json als Evidence. Beide Dateien dokumentieren eine konkrete Ausführung; sie definieren weder den Erfolgsbegriff noch den Deployment-Vertrag neu. Das kanonische Register liegt unter enterprise-architecture:85-reference-artifacts/reference-model/realization-chain-register.md.