ET-OVR-TOOL-LANDSCAPE-001

Engineering Tool Landscape#

Zweck#

Die Tool Landscape ordnet die dauerhaft versionierten Werkzeuge von engineering-tools in fachliche Werkzeugdomänen ein. Sie beschreibt Verantwortungen und Übergaben, ohne Enterprise-, Solution-, Workspace- oder Runtime-Semantik erneut zu definieren.

Führende Grenze#

engineering-tools besitzt ausführbare und dokumentierte Mechanik für Bootstrap, Umgebungsverwaltung, Roundtrip, Repository-Verwaltung, Validierung, Reporting, Packaging, Deployment, Migration, CLI, Vorlagen, Hilfsskripte und Werkzeugtests.

Fachliche Architekturentscheidungen, Repositoryverträge und Zielzustände werden nicht aus Werkzeugimplementierungen abgeleitet. Werkzeuge setzen die jeweils führenden Contracts um und erzeugen prüfbare .

Werkzeugdomänen#

Reihenfolge	Domäne	Verantwortung	Typische Ergebnisse
10	Bootstrap	Reproduzierbare Initialisierung einer Engineering-Landschaft	Installationsplan, materialisierte Grundstruktur, Bootstrap-Evidence
15	Environment Management	Laden, Katalogisieren und Prüfen umgebungsabhängiger Konfiguration	Vorlagen, Variablenkatalog, Konfigurationsbefunde
17	Workbench & Editors	Kontrolliertes Anzeigen, Bearbeiten, Vergleichen und Übergeben versionierter Artefakte	Delta, Findings und Review-Übergabe
20	Roundtrip	Orchestrierte Verarbeitung von Import bis Recovery	Run-Status, Delta, Fehlerpaket, Promotion-Evidence
30	Repository Management	, Initialisierung, Status und kontrollierte Synchronisation	Repository-Inventar, Status- und Synchronisationsbefunde
40	Validation	Ausführbare Struktur-, Manifest-, Link-, Modell- und Konsistenzprüfungen	Validierungsergebnis und maschinenlesbare Findings
50	Reporting	Reproduzierbare Ableitung menschenlesbarer Berichte	HTML-, Markdown-, Delta-, Status- und Qualitätsberichte
55	Generatoren	Deterministische Ableitung aus validierten Eingaben und Vorlagen	Materialisierungsplan, erzeugte Artefakte und
60	Packaging	Deterministische Erstellung und Integritätsbeschreibung von Paketen	ZIP, Dateiliste, Prüfsummen und Paketmetadaten
70	Deployment	Kontrollierte Installation in ausdrücklich freigegebene Zielbereiche	Deployment-Plan, Installationsstatus und Verifikation
80	Migration	Kontrollierte semantische Übernahme bestehender Artefakte	Migrationsplan, Zuordnungen und Findings
90	CLI	Stabile gemeinsame Befehlsoberfläche über Werkzeugdomänen	Befehle, Exit-Codes und maschinenlesbare Ausgabe
95	Templates	Wiederverwendbare, nicht produktive Ausgangsartefakte	Repository-, Dokument-, Manifest- und Konfigurationsvorlagen
96	Scripts	Kleine domänenübergreifende Hilfsmechanik ohne eigene Werkzeugdomäne	Eng begrenzte Hilfsskripte
97	Documentation	Nutzer-, Betriebs- und Entwicklerdokumentation der Werkzeuge	Bedienungs-, Betriebs- und Erweiterungsanleitungen
98	Tests	Automatisierte Verifikation der Werkzeuge und ihrer Sicherheitsgrenzen	Testresultate, Dry-Run- und Recovery-Nachweise
99	Examples	Nicht produktive, minimale Nutzungsbeispiele	Beispielkonfigurationen und Beispielaufrufe

Gemeinsamer Werkzeugfluss#

Bootstrap / Repository Discovery
                        ↓
                Import und Materialisierung
                        ↓
                Validation
                        ↓
                Reporting und Evidence
                        ↓
                Packaging
                        ↓
                Deployment oder Recovery

Die Reihenfolge beschreibt eine fachliche Übergabe. Einzelne Werkzeuge dürfen unabhängig nutzbar sein, solange sie ihre Eingaben, Ausgaben, Seiteneffekte und Fehlerzustände eindeutig dokumentieren.

Querschnittsregeln#

Dry-Run oder reine Planung ist der sichere Standard, sofern ein Werkzeug Änderungen an Zielzuständen auslösen kann.
Seiteneffekte benötigen eine ausdrückliche über einen dokumentierten Modus.
Pfade, Hosts, Ports, Benutzer, Secrets und Runtime-Namen werden nicht hart codiert.
Werkzeuge liefern eindeutige Exit-Codes und nachvollziehbare Evidence.
Generierte Zustände, Logs und Reports verbleiben außerhalb des versionierten Repositorys, sofern sie keine ausdrücklich versionierte Spezifikation sind.
Ein Changed-only-Paket ist ein Overlay; fehlende Dateien sind keine Löschaufträge.

Abhängigkeiten#

Die Tool Landscape wird durch den Architecture Contract, die geltenden Baselines, den beauftragten Scope und die lokalen Tool Contracts begrenzt. Die zentrale Zuordnung ist in TRACEABILITY.md dokumentiert.

CLI Services#

Die vorhandenen einzeln ausführbaren Oberflächen werden durch 90-cli/README.md als gemeinsame CLI-Service-Landschaft eingeordnet. Eine zentrale ns-Implementierung wird nicht vorausgesetzt.

Generatoren#

Die gemeinsame Architektur und Sicherheitsgrenze ist in 55-generators/README.md definiert. Vorlagen bleiben unter 95-templates/; ihre Materialisierung folgt dem Generatorvertrag.

Validatoren#

Die Domäne 40-validation besitzt lesende Validatoren und auswertende Reporter. Führende Verträge: VALIDATOR_ARCHITECTURE.md, FINDING_AND_SEVERITY_CONTRACT.md, VALIDATION_EXECUTION_CONTRACT.md und VERIFICATION.md.

Documentation Tooling#

Die Domänen 50-reporting und 97-documentation bleiben getrennte Eigentümer: Reporting erzeugt Evidence, Documentation Tooling verantwortet Publishing, Navigation und Dokumentationsqualität. Der gemeinsame Einstieg liegt unter 97-documentation/README.md.