# QAF → Wertstrom: Gap-Analyse

Stand: 2026-07-17 · Programm QVS · Basis: `qaf-value-stream-current-state.md` + Spec `Autonomous_QAF_to_Value_Stream_Integration_and_Manufacturing_Flow` (17.07.2026, extern übermittelt; Text-Konvertat beigelegt als `reports/qaf-value-stream-spec-source.txt` — alle „Spec N"-Verweise meinen dessen nummerierte Abschnitte).

Bewertungs-Logik je Gap: **Klasse A** = muss das Programm bauen (Kern-Scope) · **Klasse B** = bauen, wenn der Korpus die Datenbasis real hergibt (evidenzbasiert, kein Blindausbau) · **Klasse C** = ehrliche Limitation, dokumentieren statt bauen (Spec erlaubt das explizit: „Record why it was not mapped directly" / „Remaining Limitations").

## G1 — Keine QAF↔VSM-Verbindung (Klasse A, Kern)

Es existiert kein Service, keine API, kein UI-Element, das aus QAF-Daten einen Wertstrom erzeugt. Gleichzeitig sind beide Enden fertig: `qaf_manufacturing_step` liefert Prozesszeilen mit Lineage, `VsmNode` hat die Timing-Zielfelder. **Die Integration ist primär Mapping + Workflow, kein Parser-Neubau.**

## G2 — VsmNode-Modell unvollständig für Import (Klasse A)

Fehlend: sämtliche Kosten-Felder (Prozesskosten, MSS, Lohnsatz, Rüstkosten), Scrap (Rate/Kosten), Varianten-Zugehörigkeit, Prozesskategorie, **Source-Lineage**, **Import-/Änderungs-Status je Feld**, VA-Klassifikation nur binär (`isValueAdded` statt VA/NNVA/NVA/UNKNOWN).
Richtung: additive, optionale Felder im Node-JSONB (rückwärtskompatibel — bestehende Nodes bleiben gültig); `isValueAdded` wird abgeleitet/deprecated, nicht gebrochen.

## G3 — Kein Import-/Audit-Modell (Klasse A)

Kein `value_stream_imports`-Äquivalent: Wer hat wann aus welchem QAF (Hash, Parser-Version, Mapping-Version, Variante) welchen Wertstrom erzeugt, wie viele Schritte importiert/ausgeschlossen, mit welchen Warnungen. Spec 17/26 verlangt das. Auch Voraussetzung für Duplikat-Schutz (G7) und Sync (G8).

## G4 — Extraktions-Lücken auf Schritt-Ebene (Klasse B — Korpus entscheidet)

Vom Spec-Feldkatalog (Sektion 6) heute nicht extrahiert:
| Feld | Registry-Status | Einschätzung |
|---|---|---|
| Rüstzeit (Zeit) | kein Canonical-Field | B — Korpus-Scan nötig: steht Rüst-ZEIT überhaupt in QAFs? |
| Wartezeit | kein Canonical-Field | B — vermutlich C (QAF ist Kosten-Dokument, keine Fluss-Doku) |
| Transportzeit je Schritt | nur Transport-KOSTEN je Lieferort (LOGISTICS) | B/C |
| Zykluszeit-Split manuell/maschinell | kein Canonical-Field | B — Korpus-Scan |
| Kapazität | `sum_planned_capacity` existiert, „not parsed today" | B — Datei-Ebene, für Takt nutzbar |
| Losgröße | `sum_lot_size` existiert, „not parsed today" | B — Datei-Ebene |
| Schichtmodell je Schritt | nur `sum_shifts_per_week` je Datei | C wahrscheinlich |
Vorgehen: EIN Korpus-Evidenz-Scan (Header-Ebene, dev-Split) beziffert je Feld die reale Verfügbarkeit; nur Felder mit substanzieller Präsenz bekommen Canonical-Fields + Parser-Erweiterung. Kein Blindausbau — deckt sich mit Spec („Do not assume that all fields are available in every QAF").

## G5 — Multi-QAF-Varianten ohne Schritt-Ebene (Klasse C, strukturell)

`bridge.ts:86-100`: Fertigungskosten sind im Multi-QAF-Modell ein GETEILTES Profil-Aggregat; eine variantenspezifische Prozessschritt-Liste existiert in den Quelldateien nicht. Konsequenz für Spec-Sektion 24: Varianten-Wertströme können (a) den geteilten Fluss aus dem Fertigungs-Sheet + Varianten-Applicability-Tags zeigen und (b) Varianten-Aggregate (totalPerUnit, Volumen) als Metadaten tragen — aber KEINE variantenspezifischen Zykluszeiten je Schritt. KEIN Versuch, Schritt-Ebene je Variante zu fabrizieren (Spec: „No values are fabricated").

**Review-Fix 1 (KAR-973 adversarial review, MAJOR, ergänzt 2026-07-18):** "der geteilte Fluss gilt für N Varianten" ist selbst eine Annahme, die nicht unconditioniert getroffen werden darf — ein Container kann Varianten auf UNTERSCHIEDLICHEN Fertigungsprofilen/Standorten führen (`multi-qaf/types.ts` `variantProfileBindings`, `SharedCostProfileKind` inkl. `'location'`), und der `multi_qaf_variant_vs_standard`-Vergleich selbst prüft Fertigungs-/Prozess-Kompatibilität nicht (`variant-vs-standard.ts` `DEGRADED_MODULES.manufacturing_steps`). 00-master-prompt-multi-qaf.md §12: „Do not assume that all variants use the same manufacturing total."; §15: „Do not compare an entire Multi-QAF container with one standard QAF as if they represented the same scope." `multi-qaf-context.ts` surfaces deshalb NUR (a) die tatsächlich verglichene Variante (`engine_version.selectedVariantId`) plus (b) jede weitere aktive Variante, deren `variantProfileBindings`-Eintrag nachweislich auf dasselbe `profileId` zeigt — bei fehlender Bindungs-Evidenz NUR die verglichene Variante. Preview kommuniziert das ehrlich („N Varianten mit nachweislich gleichem Fertigungsprofil" bzw. „nur die verglichene Variante — Profil-Bindung unbekannt"), nie mehr pauschal „geteilter Fertigungsfluss, N Varianten" für den ganzen Container.

## G6 — Sequenz-Evidenz dünn, aber vorhanden (Klasse A, klein)

`row_index` + `position_number` tragen die Quell-Reihenfolge (Spec-konform: „Preserve the source order"). Keine Verzweigungs-Evidenz im Standard-QAF → linearer Fluss ist die ehrliche Default-Darstellung; `connections`-Modell kann Graph, `vsm-metrics` aber nicht (flache Summe). Richtung: linear importieren, Sequenz-Confidence markieren, Reordering im Editor (existiert via Drag) — Metrik-Graph-Umbau NICHT in diesem Programm (eigenes Follow-up), solange Importe linear sind entsteht kein Fehler.

## G7 — Duplikat-Schutz fehlt, Fundament liegt brach (Klasse A)

`qaf_file.file_hash` wird geschrieben+indiziert, nie gelesen. Mit G3 (Import-Records) wird der Check trivial: gleicher Hash+Projekt+Variante → Dialog „Öffnen / Neu erstellen / (später) Sync".

## G8 — Reimport/Synchronisation (Klasse A, späte Phase)

Kein Mechanismus. Baut vollständig auf G2 (Feld-Status) + G3 (Import-Records) auf. Statuses laut Spec 21 (`UNCHANGED|SOURCE_CHANGED|LOCAL_CHANGED|BOTH_CHANGED|NEW_IN_SOURCE|REMOVED_FROM_SOURCE`) — bewusst letzte Kern-Phase, weil G2/G3 die Datengrundlage liefern.

## G9 — VSM-Versionierung fehlt (Klasse B, minimal)

Spec 26: „analyze the minimum safe implementation". Jeder Save überschreibt das Dokument. Minimal-sicher für QVS: Import-Snapshot im Import-Record (Zustand bei Erzeugung, für Sync-Vergleich) statt genereller Dokument-Versionierung. Volle Versionierung = Follow-up außerhalb QVS-Kern.

## G10 — Kennzahlen-Lücken (Klasse A, begrenzt)

`vsm-metrics` kann Bottleneck + VA-Quote (binär). Für QVS nötig: NNVA-fähige VA-Quote, Setup-/Warte-/Transport-Summen, Kosten-/Scrap-Rollup (sobald Felder existieren), Takt-Vergleich (Takt-Quelle: `projects.customer_takt_time_sec` existiert; QAF-seitig `sum_shifts_per_week`, künftig ggf. Kapazität/Losgröße aus G4). Jede Kennzahl mit Formel + Datenbasis + Ausschluss-Liste (Spec 15) — Anzeige-Konzept folgt dem Explain-Panel-Muster.

## G11 — UI-Entry-Points fehlen (Klasse A)

Kein „Wertstrom erstellen" nirgends; /wertstrom ist von Projektseiten unverlinkt. Kandidaten priorisiert: (1) `qaf-differences/[id]` summary/g60-Detail (dort stehen die Fertigungszeilen, neben Export-Buttons), (2) `project/[id]/qaf`, (3) /wertstrom-Create mit Quelle. Genau EIN konsistentes Aktions-Muster, kein Formular-Zoo (Spec 28).

## G12 — Berechtigungen für neue Flächen (Klasse A, klein)

Neue Tabellen (G3) brauchen das etablierte `_own`+`_admin`-RLS-Paar ab Tag 1 (das historische `qaf_process_mappings`-Loch — laxe Policy, seit KAR-890 am 09.07.2026 geschlossen — dient als Warnbeispiel, nicht als offener Fall). Wertstrom-Erzeugung aus QAF erbt Projekt-Scope der Quelle (`project_id NOT NULL` auf QAF-Seite vs. NULLABLE auf VSM-Seite: beim Import wird `project_id` aus der Quelle gesetzt — kein projektloser Import-Wertstrom, sonst verlöre RLS den Scope und Kosten-Daten könnten aus dem Projekt-Kontext entkommen).

## G13 — Deliverable-Struktur fehlt (Klasse A, erledigt mit P0)

Kein `reports/ schemas/ mappings/` im Repo — mit diesem PR angelegt.

## Nicht-Gaps (bewusst außerhalb QVS)

- Editor-Qualität allgemein (kein Undo, Desktop-only, tote layout-Spalte, Titel-Edit, Offline-Fähigkeit): vorbestehend, unabhängig von QAF — als Follow-up-Kandidaten notiert, NICHT in QVS-PRs mitgefixt (Scope-Disziplin).
- Graph-/Parallelpfad-Metriken: erst relevant, wenn nicht-lineare Importe existieren (siehe G6).
- Legacy-Pipeline B konsolidieren: außerhalb Scope; QVS liest aus der Haupt-Engine (`qaf_manufacturing_step`), nicht aus `qaf_uploads.parsed_data`.

## Konsequenz → Architektur

Reihenfolge der Phasen ergibt sich aus den Abhängigkeiten: G2+G3 (Datenmodell) → G1 (Mapper+Creation) → G11 (Entry-Points+Preview) → G7 (Duplikate) → G10 (Kennzahlen) → G5-Handling (Varianten) → G8 (Sync) → G4 (evidenzbasierte Extraktions-Erweiterung, parallel ab früh via Korpus-Scan). Detail: `qaf-value-stream-architecture.md`.