# SupplierPulse QAF-Vergleich

## Akribischer Audit des aktuellen Code- und Architekturstands

**Stand der analysierten Unterlagen:** 03.08.2026  
**Auditstatus:** Dokumentenbasierter Code-Audit, keine Laufzeitausführung des Repositories  
**Eingangsquellen:** `QAF-Vergleich-Architektur.md`, `QAF-Vergleich-Quellcode.md`, `QAF-Vergleich-Stand-und-Plan.md`  
**Zweck:** Den tatsächlich vorhandenen Stand gegen das vollständige QAF-Zielbild prüfen und eine belastbare Entscheidung zwischen Weiterentwicklung, Strangler-V2 und vollständigem Neuaufbau treffen.

## 1. Aussagegrenze dieses Audits

Die bereitgestellten Unterlagen enthalten:

- die vollständigen Produktionsmodule als zusammengeführte Quellcodedokumentation
- eine kompakte Architekturfassung mit Kopfkommentaren und öffentlichen Signaturen
- eine explizite Aufstellung dessen, was gebaut ist, was fehlt und welche Kompromisse bewusst eingegangen wurden

Die Tests selbst sind nicht Bestandteil der bereitgestellten Quellcodedatei. Laut Begleitdokument existiert eine Gesamttestsuite mit ungefähr 6.900 Tests. Diese Zahl und der behauptete Testumfang können in diesem Audit dokumentiert, aber nicht durch Ausführung bestätigt werden.

Ebenso liegen keine Repository-Metadaten, Migrationen, Laufzeitkonfigurationen, Supabase-Schemas, CI-Protokolle oder echte Testreports als ausführbare Projektstruktur vor. Deshalb ist jede Aussage zur Laufzeitstabilität als dokumentenbasiert zu verstehen.

## 2. Executive Verdict

### 2.1 Klare Empfehlung

**Kein vollständiger Rewrite des deterministischen Kerns.**

Der aktuelle Stand enthält bereits eine außergewöhnlich umfangreiche, fachlich begründete und weitgehend UI-unabhängige Vergleichsengine. Ein kompletter Neuaufbau würde genau die schwersten und teuersten Lernkurven erneut öffnen:

- Excel- und QAF-Sonderfälle
- deterministisches Matching
- Reconciliation
- Formel- und Zellprovenienz
- Multi-QAF-Strukturen
- Sicherheitsprüfungen
- bewusste Degradation statt stiller Fehlinterpretation
- Test- und Mutationslogik

Empfohlen wird eine **Strangler-V2 auf dem bestehenden Kern**, kombiniert mit einer gezielten Konsolidierung des Kerns. Das bedeutet:

1. Der vorhandene deterministische Domain-Kern bleibt die Ausgangsbasis.
2. Offene Kernlücken werden zuerst geschlossen.
3. Der kanonische Ergebnis-JSON wird zur verbindlichen Systemgrenze.
4. Die neue V2-Oberfläche liest ausschließlich diesen Vertrag.
5. Die bisherige Vergleichsseite bleibt bis zur fachlichen Parität als Referenz verfügbar.
6. Große Legacy-Komponenten und Server-Actions werden schrittweise zerlegt.
7. Die V1-Oberfläche wird erst nach nachgewiesener Parität abgeschaltet.

### 2.2 Warum kein simples Weiterbauen der heutigen Seite genügt

Ein reines Weiterbauen der bestehenden Detailseite würde folgende strukturelle Probleme konservieren:

- eine sehr lange, überfüllte Einzelansicht
- 14 Hauptsektionen plus technische Anhänge
- gleichartige Platzhalter in fest nummerierten Bereichen
- sehr große React-Komponenten
- ein Server-Action-Modul mit 4.772 Zeilen
- ein JSON-Export, der noch immer aus dem UI-View-Model erzeugt wird
- keine vollständige Vergleichsmenge aus bis zu sechs eigenständigen QAF-Dateien
- kein globales Mapping über sechs Dokumentstände
- kein durchgängiger Originaldatei-Zugriff nach dem Ingest
- unvollständiger V2-Envelope

### 2.3 Warum ein vollständiger Neuaufbau unverhältnismäßig wäre

Der vorhandene Stand erfüllt bereits wesentliche Zielprinzipien:

- deterministische Berechnung
- stabile Differenzkennungen
- Provenienz
- explizite Zustände für `empty_verified` und `not_computed`
- keine Preisbrücke mit verstecktem Restposten
- capability-basierte Architekturbausteine
- Multi-QAF-Container und Variantenlogik
- Sicherheitskontrollen vor dem Parsing
- Legacy-XLS-Unterstützung
- manual Overrides
- vergleichstypabhängige Regeln
- AI-ready-Ausgabe ohne Berechnungen im Modell
- kanonisches Hashing
- UI-unabhängige Kernmodule

Diese Substanz sollte nicht verworfen werden.

## 3. Umfang des vorhandenen Produktionscodes

Aus `QAF-Vergleich-Architektur.md` wurden 190 Produktionsmodule mit insgesamt 76.881 deklarierten Codezeilen inventarisiert.

| Bereich | Module | Deklarierte Zeilen |
|---|---:|---:|
| Kern, Parser, Domain, Vergleich, Export | 126 | 57.729 |
| UI-Komponenten | 54 | 12.478 |
| Routen und Server-Actions | 10 | 6.674 |
| Gesamt | 190 | 76.881 |

Die größten Einzelmodule sind:

| Modul | Zeilen | Auditbewertung |
|---|---:|---|
| `app/qaf-differences/actions.ts` | 4.772 | Kritischer Wartbarkeits-Hotspot |
| `lib/qaf-differences/internal/canonical-fields.ts` | 4.400 | Umfangreiches Fachregister, Governance erforderlich |
| `components/qaf-differences/qaf-multi-qaf-detail.tsx` | 1.810 | UI-Monolith, modularisieren |
| `components/qaf-differences/qaf-comparison-detail.tsx` | 1.744 | UI-Monolith, modularisieren |
| `lib/qaf-differences/index.ts` | 1.437 | Sehr große öffentliche API-Fläche |
| `multi-qaf/variant-reconciliation.ts` | 1.390 | Fachlich komplex, gezielt erhalten |
| `multi-qaf/profile-parser.ts` | 1.362 | Fachlich komplex, gezielt erhalten |
| `multi-qaf/variant-matcher.ts` | 1.328 | Fachlich komplex, gezielt erhalten |
| `rmr-parser.ts` | 1.238 | Fachlich komplex, gezielt erhalten |
| `multi-qaf/material-matrix-parser.ts` | 1.231 | Fachlich komplex, gezielt erhalten |

## 4. Leitgedanke und Architekturqualität

Der Code folgt einer klaren Ehrlichkeits-Doktrin:

- Eine nicht schließende Preisbrücke wird nicht gezeichnet.
- Ein geprüfter Bereich ohne Befund wird von einem nicht berechneten Bereich unterschieden.
- Werte tragen Datei, Blatt, Zelle, Formel und Wertzustand.
- Gleiche Eingaben sollen über kanonische Serialisierung denselben Determinismus-Hash erzeugen.
- Fehlende oder nicht prüfbare Daten werden benannt, nicht durch Nullwerte oder leere Zellen ersetzt.
- Eine Sprachschicht darf fertige Fakten umformulieren, aber keine Zahlen erzeugen.

Diese Grundhaltung entspricht dem fachlichen Zielbild sehr gut und ist einer der stärksten Gründe gegen einen Rewrite.

## 5. Vorhandene Kernschichten

### 5.1 Öffentliche Kern-API

`lib/qaf-differences/index.ts` bildet einen expliziten öffentlichen Einstiegspunkt. Interne Module sollen nicht über Deep Imports angesprochen werden. Das ist architektonisch richtig.

Risiko:

- Die Exportfläche ist inzwischen sehr groß.
- Die Datei reexportiert Standard-QAF, G60, Multi-QAF, Benchmark, Export, Security, Capability, Parser und UI-Verträge.
- Ohne Domänen-Unterpakete wird die öffentliche API schwerer versionierbar.

Empfehlung:

- Weiterhin genau einen offiziellen Einstieg anbieten.
- Zusätzlich domänenspezifische Entry Points bereitstellen, beispielsweise:
  - `qaf-differences/standard`
  - `qaf-differences/g60`
  - `qaf-differences/multi-qaf`
  - `qaf-differences/export`
  - `qaf-differences/security`
- Den bisherigen Root Entry Point als kompatiblen Aggregator erhalten.

### 5.2 Kanonisches Feldmodell

`canonical-model.ts`, `canonical-fields.ts` und zugehörige Registries bilden bereits ein sprachunabhängiges Feldmodell.

Stärke:

- stabile kanonische IDs
- DE/EN-Aliase
- Modulzuordnung
- Grundlage für weitere QAF-Formate

Offene Schuld:

- Bestehende Dictionaries wie `HEADER_TO_KEY` und Summary-Synonyme bestehen teilweise parallel.
- Die Registry ist laut Modulkommentar zunächst additiv eingeführt worden.
- Es muss geprüft werden, welche Parser heute tatsächlich vollständig aus der kanonischen Registry lesen und wo noch Parallelwahrheiten bestehen.

Ziel:

- eine Registry
- eine Aliasnormalisierung
- eine kontrollierte Adapterebene
- keine konkurrierenden Feldkataloge

### 5.3 Capability Detection

Vorhanden sind:

- semantische Sheet-Auflösung
- Capability Detector
- Capability Matrix
- Module Capability Resolver
- Degradation und EmptyFieldReason

Das ist exakt die richtige Grundlage für eine flexible UI.

Offene Lücke:

- Die Capability-API existiert.
- Laut Modulkommentar sind die früher katalogisierten festen Gates noch nicht vollständig auf Capability-basierte Entscheidungen migriert.
- Die UI und Serverlogik müssen deshalb auf verbleibende hart codierte `comparison_mode`- oder Template-Gates geprüft werden.

### 5.4 Workbook Reader und Sicherheit

Vorhandene Schutzmechanismen umfassen:

- ZIP-Strukturprüfung
- echte dekomprimierte Größenprüfung
- ZIP-Bomb-Risiko
- Makroerkennung
- externe Workbook-Links
- Sheet-Dimensionslimits
- BIFF-Legacy-Prüfung
- `.xls`-Lesen über Legacy Shim
- semantische Active-Range-Grenzen
- read-only Workbook-Adapter

Bewertung:

- sehr stark
- nicht neu aufbauen
- Runtime- und adversariale Tests im echten Repository verifizieren

### 5.5 Formel-Engine und Business Rules

Vorhanden sind:

- Formel-Extraktion
- Formel-Normalisierung
- Formelvergleich
- Zellzustände
- unabhängige Zeilen-Nachrechnungen
- Summary-Reconciliation
- Business-Rule-Engine

Bewusste Grenzen:

- kein vollständiger Excel-Formelinterpreter
- keine spekulative Nachrechnung ohne dokumentierte Formel
- keine externe FX-Quelle
- Energiefelder der Fertigung sind teilweise nicht geparst
- `FK [AW]` wird ohne eindeutige Leitfadenformel nicht analog hergeleitet

Diese konservative Haltung ist richtig.

### 5.6 Reconciliation

Die Engine unterscheidet:

- echt unabhängig bestanden
- aus derselben Quelle gespeist
- nicht prüfbar
- abweichend

Im Referenzfall werden nicht 896 Prüfungen pauschal als bestanden bezeichnet. Dokumentiert sind 13 unabhängige Treffer, 97 nicht unabhängige Gleichquellen, 784 nicht prüfbare Fälle und keine Abweichung.

Das ist fachlich sehr stark.

Verbesserungsbedarf:

- Reconciliation-Coverage als übersichtliche Matrix im UI
- klare Trennung von unabhängiger Prüfung und Quellgleichheit
- Coverage je QAF-Dokument
- Coverage je fachlichem Reiter
- Coverage im JSON

## 6. Vorhandene Vergleichsmodi

Der aktuelle Code kennt fünf Modi:

1. `summary`
2. `g60`
3. `multi_qaf`
4. `multi_qaf_variant_vs_standard`
5. `supplier_benchmark`

Die zentrale `comparison-mode.ts` Registry ist eine gute Reaktion auf frühere Fallthrough-Fehler.

### 6.1 Summary

Klassischer Vergleich zweier Standard-QAF-Stände.

Vorhanden:

- Summary
- Material
- Fertigung
- SBM
- Sondermodule
- Mapping
- Datenqualität
- Reconciliation
- Verhandlung
- Hochrechnung
- Szenario, soweit verfügbar

### 6.2 G60

Eigene Detail-QAF-Engine mit:

- Kostenreitern
- INPUT-Raten
- Szenario
- Kalkulator
- Produktionssicht
- eigener Exportlogik
- Structure Guard

### 6.3 Multi-QAF

Der Begriff bezeichnet im aktuellen Code primär eine spezielle Workbook-Familie mit mehreren Varianten innerhalb eines Containers.

Vorhanden:

- Container-Domainmodell
- Variant Identity
- Header Parser
- Column Classification
- Material Matrix
- Shared Profiles
- Formula Lineage
- Container Assembly
- Variantenmatching
- Container-Diff
- Material-Diff
- Profile-Diff
- Varianten-Reconciliation
- Aggregate Impact
- eigener Export
- eigene Detailansicht

### 6.4 Variante gegen Standard

Eine einzelne virtuelle Variante aus einem Multi-QAF-Container kann gegen eine Standard-QAF gestellt werden.

### 6.5 Supplier Benchmark

Formatagnostischer Benchmark von Angeboten verschiedener Lieferanten. Der Ansatz vermeidet absichtlich Variant-Matching und verwendet strukturbezogene Verhältnisse.

## 7. Zentrale Abgrenzung: Vorhandenes Multi-QAF ist nicht gleich Mehrfachvergleich bis sechs QAFs

Die Nutzeranforderung lautet:

- ein bis sechs eigenständige QAF-Dateien gleichzeitig
- Baseline, Zeitreihe, Matrix und Paar-Detail
- globales Mapping über alle Dokumente

Der vorhandene Code erfüllt diese Anforderung noch nicht vollständig.

### 7.1 Was vorhanden ist

- Batch-Upload bis zu 12 Dateien
- Gruppierung nach Sachnummer
- Fallback-Paarung über Anfragenummer oder Teil plus Lieferant
- Baseline-Auswahl
- Multi-QAF-Container mit internen Varianten
- zwei Container im Multi-QAF-Vergleich
- Variante gegen Standard
- Supplier Benchmark

### 7.2 Was nicht vorhanden ist

- ein persistiertes `comparison_set` mit ein bis sechs QAF-Dokumenten
- globales Mapping einer Position über sechs eigenständige Dateien
- chronologische Zeitreihe aus mehr als zwei Standard-QAFs
- Baseline-Umschaltung über sechs Dokumente ohne neue Extraktion
- N-Spalten-Vergleichstabelle für sechs Stände
- paarweise Detailauswahl innerhalb desselben Vergleichssets
- 6 x 6 Matrix eines Standard-QAF-Vergleichssets
- konsistente Transitivität von Split, Merge, Rename und Reaktivierung über sechs Stände

### 7.3 Warum der bestehende Batch nicht genügt

`buildBatchComparisons` gruppiert zwar mehrere Dateien. Pro Gruppe wird jedoch eine Baseline-Auswahl getroffen und genau ein ALT/NEU-Paar verglichen. Das ist kein globaler Mehrfachvergleich.

Fallback-Paarungen werden nur bei genau zwei Kandidaten vorgenommen. Bei drei oder mehr Dateien wird bewusst nicht geraten. Diese Sicherheitsregel ist richtig, löst aber die neue Mehrfachanforderung nicht.

## 8. Positionsmapping

### 8.1 Material

Vorhandene Kaskade:

1. eindeutige Namensgleichheit
2. Gleichteile
3. Split und Merge
4. Rename über Anker und Wortstamm
5. Baugruppenregel
6. Restklassen

Der HICE-Referenzfall trifft die dokumentierten Effekt-Summen.

Offene Lücke:

- Materialresultate werden noch nicht vollständig in den globalen Differenzkatalog übersetzt.
- Das fehlende Modul `differences-from-material.ts` ist ein hoher Hebel.

### 8.2 Fertigung

Vorhanden:

- Parameteridentität statt nur Namensgleichheit
- Rename bei gleichen Parametern
- keine falsche Aussage "unverändert", wenn kein Paar existiert

Offene Lücke:

- `differences-from-manufacturing.ts` fehlt.
- Der Differenzkatalog ist dadurch für Fertigung nicht vollständig.

### 8.3 Werkzeuge

Vorhanden:

- Name zuerst
- Zählsuffixe erst danach
- Vermeidung der Vertauschung von Basis- und Zweitwerkzeug

### 8.4 Multi-QAF-Varianten

Vorhanden:

- kanonische Variant Identity
- Dimensionen
- Fuzzy und Override
- Container-übergreifendes Matching
- Review-Workflow

### 8.5 Globale Mappinggruppen

Für die neue Anforderung bis sechs eigenständige QAFs fehlt noch ein übergeordnetes Modell.

Empfehlung:

- bestehende Pair-Matcher nicht ersetzen
- einen `GlobalMappingAssembler` darüber setzen
- Pair-Evidenzen zu transitiven Gruppen vereinigen
- Konflikte explizit blockieren
- keine automatische Transitivität erzwingen, wenn Split und Merge widersprüchlich sind

## 9. Datenqualität und Regelwerk

Vorhanden:

- D01 bis D14
- Rule Engine R1 bis R6
- bilingual persistierte Messages ohne Schemaänderung
- Plausibility Issues
- Workbook Safety Findings
- candidate sheet visibility
- template fingerprints
- not-a-QAF detection
- foreign-form detection

Offene Punkte laut Begleitdokument:

- D15 Dateiname-Gate
- D16 Stammdatenabgleich
- D17 Make-or-Buy
- Vergleichstyp-Regel R-03
- `scope_removed`
- Konflikt bei Nullkosten-Zugängen

Technische Schuld:

- Bilingualität wird in einer Textspalte kodiert. Das ist als migrationsfreier Übergang nachvollziehbar, sollte in V2 aber durch ein strukturiertes Feld ersetzt werden.

## 10. Differenzkatalog und Traceability

Vorhanden:

- stabile IDs
- sortierte Vergabe
- Zellen
- Formeln
- Traceability Index
- Evidence Panels
- View Specs mit Difference-Referenzen

Kritische Lücke:

- Material und Fertigung speisen den Katalog noch nicht vollständig.
- Solange diese Übersetzung fehlt, kann ein JSON- oder Präsentationsexport nicht jede Aussage vollständig auf die kanonische Differenzebene zurückführen.

Priorität:

- P0 für den V2-Export
- vor Management-Zusammenfassung
- vor finaler KI-Freigabe

## 11. Aktueller JSON-Export

### 11.1 Was heute vorhanden ist

Die bestehende UI erzeugt clientseitig einen versionierten View-Model-Export:

- Engine-Version
- Metadaten
- Vergleichstyp
- Konventionen
- Sections
- Section States
- Validation
- Determinismus-Hash

Der Hash schließt volatile Pfade wie Vergleichs-ID, Generierungszeit und den Hash selbst aus.

### 11.2 Was daran noch nicht das Ziel ist

Der Export dokumentiert selbst, dass seine Sections "genau wie gerendert" sind.

Damit bleibt er ein UI-View-Model und kein vollständiger kanonischer Fachdatenvertrag.

Probleme:

- UI-Struktur bestimmt die JSON-Struktur.
- Fachliche Entitäten und Fakten sind nicht der primäre Vertrag.
- Material- und Fertigungsdifferenzen fehlen im vollständigen Katalog.
- Originalformeln und Blattnamen fehlen nach Rehydration.
- Mehrfachvergleich bis sechs Dokumente ist nicht modelliert.
- Unmapped Regions sind nicht systematisch enthalten.
- User Inputs und Overrides sind nicht als vollständige Auditspur im kanonischen Vertrag ausgeprägt.
- der V2-Envelope ist noch nicht der aktive Exportpfad

### 11.3 V2-Envelope

`v2-export.ts` erklärt, das Golden File habe 24 Bereiche. Die tatsächliche Konstante `V2_AREAS` enthält im gelieferten Quellcode 19 Bereiche.

Diese Inkonsistenz muss aufgelöst werden. Sie ist kein kosmetischer Dokumentationsfehler, weil:

- Vollständigkeitsprüfungen davon abhängen
- `missingAreas` davon abhängt
- Downstream-KI und Präsentation eine feste Bereichsliste benötigen
- der Auditstatus `complete` davon abhängt

### 11.4 Ziel

Der neue Export muss:

- kanonische Entitäten, Fakten und Beziehungen enthalten
- ein bis sechs Dokumente unterstützen
- globale Mappinggruppen enthalten
- fachliche Bereiche unabhängig von UI-Reitern führen
- vollständige Provenienz enthalten
- Section States enthalten
- Validierung und Reconciliation enthalten
- AI-ready als abgeleitete Fläche enthalten
- UI-State nur optional und getrennt enthalten
- schema-validiert werden
- serverseitig und reproduzierbar erzeugt werden

## 12. Originaldateien und Provenienz

Die aktuelle V2-Seite rekonstruiert Werte aus persistierten Datenbankzeilen.

Dokumentierte Folge:

- Werte und Zelladressen sind vorhanden
- Formeln fehlen
- Blattnamen fehlen teilweise
- Originaldateien sind nach dem Ingest nicht direkt über einen gespeicherten Storage-Pfad adressierbar

Das ist ein zentraler V2-Blocker.

Empfehlung:

- `qaf_file` um einen unveränderlichen Source Artifact Reference erweitern
- Storage-Pfad oder Object Key speichern
- SHA-256 speichern
- Dateiart und Bytegröße speichern
- Parserversion speichern
- Workbook-Safety-Manifest speichern
- Originaldatei niemals überschreiben
- Reparse deterministisch über die referenzierte Originaldatei ermöglichen
- rehydrierte Ergebnisse und Originale auf Hashkonsistenz prüfen

## 13. UI- und UX-Audit

### 13.1 Positive Entwicklungen

Bereits vorhanden sind:

- Aussage im Abschnittstitel
- methodische Grenzen
- explizite Platzhalter
- Evidence Panel
- V2 Header
- KPI Tiles mit Quellen
- Waterfall ohne Restbalken
- Section Registry
- Sprachumschaltung
- manuelle Overrides
- Vergleichsstatus
- Review Toggle
- Exporte
- Supplier Benchmark
- Multi-QAF-Detailansichten

### 13.2 Hauptprobleme

#### Feste Langseite

Die Standardseite besitzt 14 nummerierte Hauptsektionen sowie technische Anhänge. Das ist fachlich vollständig, aber nicht die beste primäre Navigation.

#### Gleiche Sektionen für jeden QAF-Typ

`qaf-section-registry.ts` kodiert den Grundsatz, dass jede Analyse dieselben nummerierten Sektionen in derselben Reihenfolge zeigt und fehlende Bereiche als Platzhalter erscheinen.

Dieser Ansatz schafft Wiedererkennung, widerspricht aber teilweise dem neuen Ziel:

- Reiter sollen möglichst QAF-Bezeichnungen tragen.
- Nicht verfügbare Module sollen nicht die Hauptnavigation überladen.
- Ein HICE-Zeitvergleich braucht andere Schwerpunkte als ein Supplier Benchmark.
- G60, Standard-QAF, Multi-QAF und Variantenvergleich haben unterschiedliche fachliche Strukturen.

Empfehlung:

- gleiche semantische IDs im Hintergrund
- gleiche technische Coverage-Matrix
- dynamische, QAF-nahe Primärreiter
- keine dauerhaften leeren Hauptreiter
- nicht verfügbare Bereiche in "Abdeckung und Grenzen" anzeigen

#### Überladener Header

Dateiersatz, Swap, Kalkulator, Wertstrom, Status, Exporte, Tags und Titel stehen zu dicht nebeneinander.

#### Große UI-Komponenten

- Standarddetail: 1.744 Zeilen
- Multi-QAF-Detail: 1.810 Zeilen
- Hauptseite: 889 Zeilen
- Client-Upload und Liste: 539 Zeilen

#### Responsive Design

Die bisher analysierte HTML-Ausgabe zeigt horizontale Überläufe auf Mobil und Tablet. Die aktuelle Max-Width- und Tabellenstrategie muss im echten Repository per Screenshot-Tests geprüft werden.

#### Farblogik

Der Code verwendet an mehreren Stellen `text-destructive` für Kostenanstieg und `text-success` für Kostensenkung.

Das BMW Design System erlaubt RAG-Farben für echte Status- und Risikocodierung. Eine Kostenrichtung ist nicht automatisch ein Qualitätsstatus.

Ziel:

- Richtung über Vorzeichen, Pfeil, Label und neutrale A-F-Farben
- Rot nur für kritischen Befund oder klar definierte wirtschaftliche Eskalation
- Grün nur für bestätigten guten Status, nicht pauschal für jede Kostensenkung

## 14. BMW Design System

Das neue BMW Group Design System ist eindeutig:

- BMW Teal `#035970` als Anker
- weißer Hintergrund
- kühle Teal- und Gray-Blue-Skala
- BMWGroupTN
- Sentence Case für Titel
- All Caps nur für kleine Eyebrows
- quadratische Ecken
- Hairline Rules
- praktisch keine Schatten
- kein dekorativer Headerbalken
- Wordmark oben rechts, monochrom
- fakten- und zahlenorientierte Sprache
- keine Marketingformulierungen
- keine Emojis
- keine Ausrufezeichen

Der aktuelle Produktcode muss gegen diese Regeln geprüft werden. Das Designsystem ist nicht nur eine Farbpalette. Es umfasst auch Informationsdichte, Beschriftung, Tabellen, Buttons, Status, Wortwahl und visuelle Hierarchie.

## 15. Server-Actions und Persistenz

`actions.ts` mit 4.772 Zeilen ist der größte technische Wartbarkeitsblocker.

Darin liegen unter anderem:

- Upload
- Ingest
- Batchanalyse
- Export
- Recompare
- Replacement
- Manual Pins
- Field Overrides
- Variant Overrides
- Benchmark
- Kalkulator
- Tags
- Review
- Cycle-Time-Integration

Empfehlung:

- keine Big-Bang-Zerlegung
- erst charakterisierende Tests
- dann nach Use Cases aufteilen:
  - `upload-actions`
  - `ingest-actions`
  - `comparison-actions`
  - `replacement-actions`
  - `review-actions`
  - `export-actions`
  - `multi-qaf-actions`
  - `benchmark-actions`
  - `calculator-actions`
- Domainlogik weiterhin aus Server-Actions heraushalten
- gemeinsame Authorization und Audit Wrapper verwenden

## 16. Tests und Qualitätssicherung

Dokumentierte Stärken:

- ungefähr 6.900 Tests
- Mutationsproben nach Regeln
- Gegenproben
- Gruppenprüfung statt nur Summenzählung
- reale operator-lokale Golden Cases
- einzelne anonymisierte Material-Fixture in CI
- real-file UI Tests teilweise env-gated

Offene Risiken:

- Tests wurden nicht mitgeliefert und nicht ausgeführt.
- Golden Cases mit echten Dateien laufen nicht regulär in CI.
- Für viele Ebenen fehlen anonymisierte reale Fixtures.
- Zwei flaky Wertstromtests erzeugen CI-Rauschen.
- Eine hohe Testanzahl ersetzt keine Corpus-Coverage.

Ziel:

- anonymisierter Golden Corpus je QAF-Familie
- deterministische Snapshot- und Hash-Tests
- Parser-Mutationsfälle
- UI-Visual-Regression
- sechs-QAF-Tests
- Export-Schema-Tests
- Performance-Budgets
- Security-Corpus
- keine env-gated Kernabnahme

## 17. Bekannte offene Fachentscheidungen

### 17.1 Nullkosten-Zugänge

Konflikt:

- Spezifikation: `unchanged` plus `zero_cost`
- Referenzlauf: `scope_added`

Entscheidungsvorschlag:

- zwei getrennte Achsen:
  - Strukturstatus: `scope_added`
  - Kostenstatus: `zero_cost`
- keine gegenseitige Verdrängung

### 17.2 Maßnahmen-IDs

Aktuell folgen M-01 und weitere IDs der Sortierung und sind nur innerhalb eines Laufs stabil.

Ziel:

- persistente Action-ID
- semantischer Fingerprint
- Anzeigeordinal getrennt von Identität

### 17.3 Rot und Grün

Zielentscheidung:

- Rot und Grün als Statusfarben
- Kostenrichtung nicht ausschließlich als Statusfarbe
- A-F-Standfarben aus Teal-Skala
- Vorzeichen immer sichtbar

### 17.4 Vergleichsklassifikation

`comparison_type` bleibt teilweise `undetermined`, weil R-03 fehlt.

Ziel:

- deterministische Klassifikation
- manuelle Deklaration als Fallback
- Evidenzliste
- kein Raten

## 18. Bewertungsmatrix

Dokumentenbasierte Bewertung, vor Ausführung der Tests:

| Kriterium | Gewicht | Bewertung | Begründung |
|---|---:|---:|---|
| Deterministische Kernlogik | 20 | 18 | Hashing, stabile IDs, konservative Regeln, ehrliche Brücke |
| Parser- und Adapterarchitektur | 15 | 13 | breite Parserabdeckung, Capability-Kern, noch parallele Registries und Gates |
| Kanonisches Modell und Multi-QAF | 15 | 11 | starkes Container-Modell, aber kein 1-bis-6-Standard-QAF-Set |
| Tests und Golden Fixtures | 15 | 11 | hohe dokumentierte Testtiefe, reale Golden Cases nicht regulär in CI |
| UI und progressive Offenlegung | 10 | 5 | gute V2-Bausteine, noch überladene Langseite und Monolithen |
| Performance und Skalierbarkeit | 10 | 7 | Limits und serverseitige Verarbeitung, 6-QAF-Ziel nicht nachgewiesen |
| Sicherheit und Datenschutz | 5 | 5 | sehr starke Workbook- und Upload-Schutzschicht |
| Wartbarkeit und Dokumentation | 5 | 3 | außergewöhnlich gute Kommentare, aber große Hotspots |
| Migration und V2-Fähigkeit | 5 | 4 | V2-Bausteine vorhanden, reale V2-Datenanbindung unvollständig |
| Gesamt | 100 | 77 | Strangler-V2 auf vorhandenem Kern |

### 18.1 Kritische Blocker trotz guter Punktzahl

Die folgenden Punkte müssen vor einer produktiven V2 geschlossen werden:

1. vollständiger kanonischer JSON-Export
2. Originaldatei-Referenz und vollständige Provenienz
3. Material- und Fertigungsübersetzung in den Differenzkatalog
4. Mehrfachvergleich ein bis sechs eigenständiger QAFs
5. klare V2-Informationsarchitektur
6. feste Entscheidung zu 19 gegen 24 Exportbereichen
7. R-03, D15 bis D17 und `scope_removed`
8. CI-fähiger anonymisierter Golden Corpus

## 19. Zielentscheidung

### 19.1 Bestehenden Kern behalten

Behalten und härten:

- Workbook Safety
- Reader und Adapter
- Normalizer
- Canonical Fields
- Formula Engine
- Business Rules
- Reconciliation
- Difference IDs
- Traceability
- Standard Matching
- G60
- Multi-QAF Container
- Supplier Benchmark
- Export Canonicalization
- AI-ready

### 19.2 V2 neu strukturieren

Neu beziehungsweise grundlegend konsolidieren:

- persistiertes Comparison Set für ein bis sechs QAFs
- globales Mapping
- vollständiger kanonischer Export
- Source Artifact Management
- UI Application Shell
- QAF-nahe Navigation
- große Detailkomponenten
- Export und Präsentationspipeline
- strukturierte bilingual Messages
- Server-Action-Orchestrierung

### 19.3 V1 als Referenz erhalten

Bis zur Abnahme:

- bestehende Vergleichsseite bleibt verfügbar
- HICE Golden Output bleibt Referenz
- V5-Paritätskarte bleibt Referenz für Benchmarking
- V2 wird pro Fachbereich gegen V1 abgeglichen
- keine Entfernung ohne Paritätsnachweis

## 20. Unmittelbare Prioritäten

### P0

1. Repository reproduzierbar starten und Tests ausführen.
2. Source Artifact Reference ergänzen.
3. `differences-from-material.ts` bauen.
4. `differences-from-manufacturing.ts` bauen.
5. V2-Area-Konflikt 19 gegen 24 entscheiden.
6. Kanonischen JSON-Builder serverseitig vollständig verdrahten.
7. Export-Route auf den kanonischen Builder umstellen.
8. Golden Corpus in CI bringen.

### P1

1. Comparison Set für bis zu sechs Dokumente.
2. Global Mapping Assembler.
3. Zeitreihe, Baseline, Matrix und Paar-Detail.
4. neue V2-Navigation.
5. UI-Monolithen zerlegen.
6. Capability Gates vollständig migrieren.
7. R-03, D15, D16, D17, `scope_removed`.

### P2

1. WAF, LAF und LEK fachlich integrieren.
2. zusätzliche CO2e- und LC-Layouts.
3. vollständige Multi-Currency-Darstellung.
4. Wertstromübergabe auf kanonischen Prozessentitäten.
5. Präsentationspaket aus demselben JSON.
6. BMW LLM API nur auf AI-ready-Fläche.

## 21. Schlussfolgerung

Der aktuelle Stand ist kein Prototyp, der verworfen werden sollte. Er ist ein umfangreicher deterministischer Fachkern mit mehreren bereits aufgebauten V2-Bausteinen.

Die richtige Herausforderung lautet deshalb nicht:

> Weiterbauen oder alles neu schreiben?

Sie lautet:

> Welche vorhandenen Kernmodule sind fachlich belastbar, welche Systemgrenzen fehlen, und wie wird daraus ohne Funktionsverlust eine klarere V2?

Die Antwort dieses Audits ist:

- Kern behalten
- offene Kernlücken schließen
- JSON zur verbindlichen Grenze machen
- Mehrfachvergleich neu oberhalb des Kerns modellieren
- UI als V2 neu ordnen
- V1 kontrolliert ablösen