MVP-001-REQUIREMENT-VERIFICATION-TRACEABILITY-MATRIX

MVP-001 – Anforderungs-, Verifikations- und Traceability-Matrix#

Zweck#

Diese Matrix ist der navigierbare Einstieg in die repositoryweiten Nachweisketten. Sie ersetzt keine fachliche Detailmatrix und behauptet keine Testausführung. Sie zeigt, wo normative Zusagen, Requirements, Realisierung und Verification für jeden konsolidierten Solution-Cluster geführt werden.

Coverage-Matrix#

Cluster	Normativer Einstieg	Primäre Realisierung	Verification-Einstieg	Coverage-Grenze
Product Contract		Capabilities, Domain Model, Application Services und Runtime Contracts		End-to-End-Acceptance benötigt konkrete Ausführungsevidence
Unified Model	Daten- und Materialisierungsverträge sowie `SADR-002`	UAM-, Identifier-, Provenance- und Manifest-Verträge		Detailmatrix definiert Invarianten; Implementierungsevidence bleibt nachgelagert
Realization	Capability Scope und Realization Contract	Capability Traceability Matrix und Building-Block-Beiträge		fehlende Beiträge werden als sichtbar
Knowledge, Terminology and Explainability	Context-, Daten-, Komponenten- und Servicevertrag sowie `SADR-011`	Knowledge-/Explainability-Mapping und `BB-EP-012`		Coverage und Provider-Konflikte bleiben explizit
Components, Services and Contributions	Komponenten-, Contribution-, Port- und Adapterverträge sowie `SADR-012`	Komponenten-/Service-/BB-Mapping		serverseitige Autorisierung und technische Adapter benötigen konkrete
Runtime and Deployment	Runtime-, Storage-, Deployment- und Promotion-Verträge sowie `SADR-007` und `SADR-013`	Runtime Targets, Assemblies, Storage Areas und Deployment Transaction		Restore, Failure Injection und benötigen ausgeführte Runtime-Evidence
Governance	Building-Block Map, Ownership Matrix und Modularity Rules	Reference Mapping, Ownership und Dependency Matrix		statische und repositoryübergreifende Prüfungen bleiben ausführungsabhängig
Solution Decisions	Decision Governance und Accepted SADR Catalog	SADRs, Katalog und historische Disposition		Kandidaten besitzen keine normative Coverage
Workbench Knowledge	EP-000 Workbench Interaction und Knowledge Domain Extension	`BB-EP-012` und Workbench Knowledge Contracts	Clusterbezogene Tests und KTE-Matrix	vorhandene EP-000-Nachweise sind teilweise indirekt
Workbench Foundation	EP-002.1 Component und UI Manifest Model	Workbench Foundation und UI Manifest		konkrete Testpfade sind Evidence-Kandidaten, kein Ausführungsnachweis
Contribution Framework	EP-002.2 Component und Context Model	Contribution Loader, Policies und Context Binding		Demonstrator besitzt eine eigene ergänzende Matrix
Workbench Observability	EP-002.2C Component und `SADR-010`	strukturierte Trace- und Reason-Code-Verträge		Log- und Trace-Evidence darf keine Secrets enthalten
Bootstrap Installation	Bootstrap Contract und `BB-EP-013`	Bootstrap- und Installation-Management		Negativtests und idempotente Wiederholung sind verpflichtend

Repositoryweite Konsistenzprüfungen#

ID	Prüfung	Erwartung
`TRV-001`	Requirement-IDs innerhalb jedes Sets auf Eindeutigkeit prüfen	keine doppelte ID im selben Set
`TRV-002`	jede Verification-Zeile auf Requirement-Bezug prüfen	keine ungebundene Verification
`TRV-003`	jedes Requirement Set auf einen Verification-Einstieg prüfen	keine unsichtbare Coverage-Lücke
`TRV-004`	alle zentralen Cluster gegen README und `AI_STARTS_HERE.md` prüfen	navigierbare Lesefäden ohne Orphans
`TRV-005`	Statusaussagen gegen vorhandene Evidence prüfen	keine behauptete Ausführung ohne Nachweis
`TRV-006`	historische Quellen und Kandidaten prüfen	keine parallele normative Requirement- oder Testschicht
`TRV-007`	lokale Markdown-Links der Traceability-Artefakte prüfen	alle Verweise auflösbar

Interpretation#

Eine vorhandene Matrixzeile bedeutet, dass ein Verification Contract existiert. Sie bedeutet nicht automatisch directly-verified. Der konkrete Coverage-Status wird erst durch ausgeführte Evidence gesetzt oder bleibt als verification-gap sichtbar.