EA-MVP-TRACEABILITY-001
MVP Traceability – vom Ziel zur produktiven Materialisierung#
Zweck#
Diese Traceability verbindet den im GlossarbegriffEin MVP ist eine kleinste überprüfbare Materialisierung mit bewusst begrenztem Umfang.Glossareintrag vollständig lesen beschriebenen realen Bedarf mit bestehenden Architekturquellen und den späteren Materialisierungsorten. Sie ist der rote Faden für Solution Architecture, Engineering Platform, Engineering Tools und Runtime.
Leitende Vision-Aussagen#
Die bisherige Plattformvision beschreibt insbesondere folgende für den MVP verbindliche Wirkungen:
- eine gemeinsame Wissensbasis aus identifizierbaren Wissenselementen, Kontexten, Fähigkeiten und Beziehungen,
- dieselbe fachliche Wahrheit in unterschiedlichen Werkzeugen, Sprachen, Rollen und Sichten,
- Dokumentation direkt an Artefakten,
- sichtbare, auswertbare und historisierbare Beziehungen,
- mehrsprachiges und dimensionsfähiges Wissen,
- kontrollierte Einbindung von AI-Diensten,
- Nachvollziehbarkeit von GlossarbegriffEine Vision beschreibt eine langfristig gewünschte Wirkung und gibt der Weiterentwicklung eine gemeinsame Richtung.Glossareintrag vollständig lesen über Architektur, Entscheidung, Implementierung, Test und GlossarbegriffEin Release ist ein bewusst freigegebener und nachvollziehbarer Stand von Artefakten und ihrer Realisierung.Glossareintrag vollständig lesen,
- Selbstanwendung der Plattform auf ihre eigene Architektur und Entwicklung.
Die Aussagen werden in diesem Schritt nicht neu formuliert oder promoviert. Sie werden am ersten produktiven Vertikalschnitt überprüft.
Durchgängige Ableitung#
| Vision / Bedarf | GlossarbegriffEine Capability beschreibt ein dauerhaft benötigtes fachliches Leistungsvermögen, nicht dessen technische Umsetzung.Glossareintrag vollständig lesen | Requirement-Gruppe | Materialisierung |
|---|---|---|---|
| Gemeinsame Wissensbasis | CAP-002, CAP-003, CAP-015, CAP-019 | Artefakte, stabile Identität, Dimensionen, Revisionen | Engineering Platform + MariaDB |
| Beziehungen sichtbar und bearbeitbar | CAP-004, CAP-018, CAP-019, CAP-020 | GlossarbegriffEine Beziehung beschreibt eine nachvollziehbare Verbindung zwischen Bedeutungen, Artefakten und ihrem Kontext.Glossareintrag vollständig lesen Management | Backend, UI, Datenmodell |
| Bedienung in mehreren Sprachen | CAP-006, CAP-007, CAP-014, CAP-020, CAP-021 | UI Internationalization de/en/uk |
Frontend + User Preferences |
| Mehrsprachige Inhalte | CAP-003, CAP-006, CAP-015, CAP-019, CAP-023 | GlossarbegriffEin Artefakt ist jede eindeutig identifizierbare fachliche, technische, organisatorische oder reale Einheit, die in der Engineering-Landschaft modelliert wird. Alles Modellierbare wird als Artefakt geführt. Dazu gehören unter anderem Systeme, Beziehungen, Features, Dokumente, ADRs, Tests, UI-Buttons, Menüs, Farben, Icons, Konfigurationen, Diagramme, Runtime-Ressourcen, fachliche Objekte und reale Objekte wie ein Blumentopf, sofern sie modelliert werden. Knowledge ist keine Sonderklasse. UI- und Applikationsartefakte werden fachlich nach demselben Grundmodell behandelt.Glossareintrag vollständig lesen Localization | Datenmodell, API, Vergleichs-UI |
| Automatische Übersetzung kontrolliert nutzen | CAP-011, CAP-022, CAP-023, CAP-026 | manuell startbarer Translation Job | Translation Connector + Worker + UI |
| Übersetzungen vergleichen und korrigieren | CAP-005, CAP-010, CAP-020, CAP-024 | Source/Target Compare and Edit | Merge-/Comparison-UI + Revisioning |
| Änderungen nachvollziehen | CAP-005, CAP-010, CAP-015, CAP-024 | Audit und Historie | Audit Events + Revisionen + Reports |
| Mensch und AI arbeiten kontrolliert zusammen | CAP-011, CAP-012, CAP-013, CAP-022, CAP-023 | Human–AI Roundtrip | Engineering Platform steuert Engineering Tools |
| Produktiver Betrieb | CAP-016, CAP-025, CAP-027 | Security, Test/Production, Recovery | getrennte Runtimes + Konfiguration + Observability |
Verantwortliche Repositories#
Enterprise Architecture#
Begründet Vision-Ausschnitt, Capability-Auswahl, allgemeingültige Prinzipien und fachliche Traceability.
Solution Architecture#
Spezifiziert den konkreten produktiven Vertikalschnitt: Requirements, Komponenten, Services, Datenmodell, Security, Runtime und Acceptance Tests.
Engineering Platform#
Enthält die produktive Anwendung aus Go-Backend und JavaScript-Frontend. Sie verwaltet Benutzer, Artefakte, Beziehungen, Sprachfassungen, Revisionen, Translation Jobs, Audit und Roundtrip Jobs.
Engineering Tools#
Führt technische Roundtrip-, Packaging-, Import-, Export-, Validierungs-, Reporting-, Repository- und Deployment-Operationen aus. Die Tools werden durch die Engineering Platform orchestriert und bleiben auch unabhängig testbar.
Runtime#
Enthält getrennte Test- und Produktionsinstallationen mit Konfiguration, Secrets, Datenbank, Services, Inbox, Outbox, Reports, Logs und Arbeitszuständen.
Erste produktive Inhalte#
Die vorhandenen Markdown-Dokumente aus Enterprise Architecture, Solution Architecture, Engineering Platform und Engineering Tools sind die ersten realen Artefakte des Systems. Ihr Import und ihre verlustarme Wiederausgabe testen:
- stabile Identität,
- Struktur und Beziehungen,
- mehrsprachige Varianten,
- Revisionierung,
- Source Ownership,
- Markdown als Austauschmaterialisierung,
- Roundtrip zwischen Mensch, AI und Repository.
Transportgrenze#
Wie ein Roundtrip-Auftrag technisch zu einem konkreten AI-Chat und zurück gelangt, ist noch nicht festgelegt. Der Kern modelliert bereits:
- Roundtrip Job,
- Roundtrip Package,
- Roundtrip Item,
- Source Revision,
- Returned Revision,
- Validation Result,
- Review Decision,
- GlossarbegriffTechnical documentation artifact.Glossareintrag vollständig lesen Result.
Der Transport bleibt austauschbar und darf das fachliche Daten- und Prozessmodell nicht bestimmen.