EP-002-1-ENGINEERING-WORKBENCH-FOUNDATION

EP-002.1 – Engineering-Workbench-Grundlage#

Ziel#

EP-002.1 materialisiert die erste eigene, manifestgesteuerte Engineering Workbench. Sie stellt einen generischen Composition Root bereit und komponiert Ribbon, Perspectives, Navigation, Command Registry und Knowledge Panel ohne fachliche UI-Artefakte im Shell-Kern zu hardcodieren.

Komponenten#

Workbench Manifest
                → Composition Root
                → Command Registry
                → Perspective Model
                → Navigation Model
                → Ribbon Model
                → Knowledge Panel Model
                → Browser Workbench

Verbindliche Regeln#

• Der Composition Root kennt nur Manifesttypen, Registries und generische ⌘RendererEin Renderer erzeugt eine konkrete technische Ausgabeform aus einer vorbereiteten Dokumentationsprojektion. Beispiele sind HTML, PDF, Markdown, JSON oder ein Suchindex..
• Perspectives bestimmen sichtbare Navigation, Ribbon-Kontext und Arbeitsbereich.
• Navigationseinträge referenzieren stabile Artefakt- oder View-IDs.
• Ribbon-Einträge referenzieren ausschließlich Command-IDs.
• Jeder sichtbare Command und Navigationseintrag besitzt einen Help Context.
• Jedes UI-Artefakt führt Artifact-ID, Hilfetext, Glossar-, Learning-Nugget-, Finding-, ADR-, Capability- und Dokumentationsreferenzen.
• Fehlende Referenzen sind ein Validierungsfehler und werden nicht stillschweigend ergänzt.

Initiale Materialisierung#

Die erste Perspective engineering zeigt eine dokumentationsbezogene Navigation, das globale Ribbon und ein kontextbezogenes Knowledge Panel. Der bestehende Command [[ART-DEF-0001|artifact]].create bleibt der erste fachliche Demonstrator.

Außerhalb des Scopes#

• vollständiger Editor,
• persistierte Benutzerpräferenzen,
• produktiver AI-Transport,
• dynamisches Nachladen externer Building-Block-Bundles.

Einordnung in den solutionweiten Vertrag#

Dieser EP-Slice materialisiert einen Teil des ◆Workbench Composition ContractSolutionweiter Vertrag für Composition Root, registrierte UI-Beiträge und gemeinsamen Workbench-Kontext.. Der solutionweite Vertrag hat Vorrang vor demonstratorspezifischen Details.