# SupplierDev — Product Specification > **Product**: SupplierDev > **Purpose**: BMW Supplier Development platform for cycle time analysis, shift output tracking, and continuous improvement management during supplier plant visits. > **Platforms**: Web (Next.js), iOS (SwiftUI) > **Backend**: Supabase (PostgreSQL + Auth + Storage) --- ## 1. Domain Overview BMW Supplier Development engineers visit supplier manufacturing plants to: 1. **Measure** cycle times at each production station (time study) 2. **Identify** bottlenecks vs. customer takt time 3. **Track** shift production (target vs. actual output) 4. **Drive** continuous improvement via workshop actions 5. **Compare** QAF (Quality Assessment File) versions over time 6. **Report** findings as structured Excel exports --- ## 2. Core Entities ### 2.1 Visit Represents a single supplier plant visit/audit session. | Field | Type | Required | Description | |-------|------|----------|-------------| | `id` | UUID | auto | Primary key | | `user_id` | UUID | auto | Owner (FK → auth.users) | | `supplier_name` | string | ✓ | Supplier company name | | `plant_location` | string | — | Plant city/address | | `product_name` | string | — | Product being manufactured | | `visit_date` | date | ✓ | Date of visit (default: today) | | `customer_takt_time_sec` | decimal | — | Customer demand rate (seconds) | | `planned_oee` | decimal | — | Target OEE % (0–100, default: 85) | | `target_cycle_time_sec` | decimal | — | Manufacturing target CT (seconds) | | `notes` | text | — | Free-form notes | | `created_at` | timestamp | auto | Creation timestamp | | `updated_at` | timestamp | auto | Last update timestamp | **Business rules:** - A user can only access their own visits (RLS) - `target_cycle_time_sec` is typically calculated as `customer_takt_time_sec × planned_oee / 100` - Visits are the root entity; all other entities cascade-delete with it - A visit must have at least one station before cycle time measurement can start **Relationships:** - Has many → Stations (1:N) - Has many → ShiftRecords (1:N) - Has many → Actions (1:N) - Has many → QAFDocuments (1:N) --- ### 2.2 Station A manufacturing workstation or process step within a visit. | Field | Type | Required | Description | |-------|------|----------|-------------| | `id` | UUID | auto | Primary key | | `visit_id` | UUID | ✓ | Parent visit (FK) | | `step_number` | integer | ✓ | Sequential identifier | | `station_name` | string | ✓ | Station name (e.g. "M0500", "Endmontage") | | `description` | text | — | Optional description | | `planned_cycle_time_sec` | decimal | — | Expected cycle time | | `is_manual` | boolean | ✓ | Manual vs. automated station | | `operator_count` | integer | ✓ | Number of operators (default: 1) | | `sort_order` | integer | ✓ | Display order (default: 0) | | `created_at` | timestamp | auto | | **Business rules:** - `sort_order` controls the station sequence in the Yamazumi chart - Stations can be reordered by the user - A station is the **bottleneck** if its average measured CT ≥ all other stations' average CT - A station is **over-takt** if its average CT > `customer_takt_time_sec` **Relationships:** - Belongs to → Visit - Has many → Measurements (1:N) --- ### 2.3 Measurement An individual cycle time recording for a station. | Field | Type | Required | Description | |-------|------|----------|-------------| | `id` | UUID | auto | Primary key | | `station_id` | UUID | ✓ | Parent station (FK) | | `cycle_number` | integer | ✓ | Sequential measurement number (1-based) | | `cycle_time_sec` | decimal | ✓ | Measured cycle duration (seconds) | | `is_outlier` | boolean | ✓ | Excluded from averages (default: false) | | `notes` | text | — | Observation notes for this cycle | | `measured_at` | timestamp | auto | Recording timestamp | **Business rules:** - Outliers are excluded from avg/min/max calculations - Target is typically 10 cycles per station for statistical validity - `cycle_number` is assigned in sequence; renumber if a measurement is deleted - Average is calculated over non-outlier measurements only **Relationships:** - Belongs to → Station --- ### 2.4 ShiftRecord Hourly production output for a specific shift. | Field | Type | Required | Description | |-------|------|----------|-------------| | `id` | UUID | auto | Primary key | | `visit_id` | UUID | ✓ | Parent visit (FK) | | `shift_date` | date | ✓ | Date of shift | | `shift_type` | enum | ✓ | `Frühschicht` \| `Spätschicht` \| `Nachtschicht` | | `hour_start` | integer | ✓ | Hour (0–23) | | `target_output` | integer | ✓ | Planned units for this hour | | `actual_output` | integer | ✓ | Actual units produced | | `remarks` | text | — | Notes/anomaly description | | `created_at` | timestamp | auto | | **Business rules:** - One record per shift-date + shift_type + hour_start combination (upsert) - `delta = actual_output - target_output` (negative = shortfall) - A shift where all hours meet target but total is low = "hidden loss" warning - Target output typically derived from takt time: `3600 / customer_takt_time_sec` **Relationships:** - Belongs to → Visit --- ### 2.5 Action A continuous improvement action item identified during the visit. | Field | Type | Required | Description | |-------|------|----------|-------------| | `id` | UUID | auto | Primary key | | `visit_id` | UUID | ✓ | Parent visit (FK) | | `action_number` | integer | ✓ | Display number (1-based, auto-assigned) | | `area` | string | ✓ | Process area / station reference | | `description` | string | ✓ | What needs to be done | | `effort` | enum | ✓ | `low` \| `medium` \| `high` (default: `medium`) | | `benefit` | enum | ✓ | `low` \| `medium` \| `high` (default: `medium`) | | `status` | enum | ✓ | `open` \| `in_progress` \| `done` \| `rejected` | | `responsible` | string | — | Assignee name | | `target_date` | date | — | Expected completion date | | `time_saving_sec` | decimal | — | Estimated cycle time reduction (seconds) | | `cost_saving_eur` | decimal | — | Estimated cost savings (EUR) | | `created_at` | timestamp | auto | | **Business rules:** - Status lifecycle: `open` → `in_progress` → `done` or `rejected` - Actions are ranked by effort/benefit matrix (low effort + high benefit = quick win) - `action_number` is sequential per visit; renumber if deleted **Relationships:** - Belongs to → Visit --- ### 2.6 QAFDocument A versioned Quality Assessment File upload. | Field | Type | Required | Description | |-------|------|----------|-------------| | `id` | UUID | auto | Primary key | | `visit_id` | UUID | ✓ | Parent visit (FK) | | `version_type` | enum | ✓ | `zur_vergabe` \| `nach_vergabe` \| `aktuell` | | `file_name` | string | ✓ | Original filename | | `file_path` | string | ✓ | Supabase Storage path | | `parsed_data` | jsonb | — | Extracted fields (CT, OEE, costs, reject rate) | | `uploaded_at` | timestamp | auto | | **Enum meanings:** - `zur_vergabe` — At time of supplier award (baseline) - `nach_vergabe` — After award / during ramp-up - `aktuell` — Current state **Business rules:** - Only one document per version_type per visit (upsert on re-upload) - `parsed_data` stores: `cycle_time_sec`, `oee_percent`, `cost_per_unit`, `reject_rate_percent` - Delta comparison is shown when ≥2 versions are present **Relationships:** - Belongs to → Visit --- ## 3. User (Auth) Managed by Supabase Auth. Extended profile stored in `auth.users.user_metadata`: | Field | Type | Description | |-------|------|-------------| | `name` | string | Display name | | `department` | string | BMW department (e.g. "Supplier Development", "Einkauf") | | `language` | enum | `en` \| `de` | | `avatar_url` | string | Supabase Storage URL | --- ## 4. Business Rules Summary ### Bottleneck Detection - Bottleneck = station with highest non-outlier average CT - Highlighted red if avg CT > `customer_takt_time_sec` - Highlighted yellow if avg CT > `target_cycle_time_sec` but ≤ `customer_takt_time_sec` - Highlighted green if avg CT ≤ `target_cycle_time_sec` ### Takt Time Logic - `customer_takt_time_sec` = demand rate (seconds per unit) - `target_cycle_time_sec` = `customer_takt_time_sec × planned_oee/100` - Yamazumi chart shows all stations stacked against these reference lines ### Cycle Time Validity - Minimum 3 measurements for meaningful average - 10 measurements is the standard for reliable time study - Outlier threshold: typically ±2σ from mean (manual flag in current version) --- ## 5. Feature Set ### Authentication - Email/password sign up + confirmation - Login / logout - Password reset via email - Profile management (name, department, language, avatar) ### Visit Management - Create, read, update, delete visits - Dashboard list with status overview - Bottleneck + KPI strip per visit ### Project Overview — Modul-Kennzahlen (KAR-983) - On `/project/[id]`, a "Kennzahlen" section shows the state of every module of the project at a glance — generic for any project type, not gated to a specific type or to demo projects: - **Fabrikanalyse**: fulfillment score (average `selected_rating` 1–4 of answered, relevant `assessment_responses`, aggregated across all `assessments` of the project), share fulfilled (rating 3–4) / partial (2) / not fulfilled (1), count of answered questions. - **QAF**: the newest `qaf_comparison`, core cost impact (total production cost / quotation price / material, each as Δ%) read straight from the persisted `qaf_summary_diff` rows via the existing summary-KPI builder — never recomputed. A comparison mode that never persists summary-diff rows (e.g. Multi-QAF) shows an explicit "no core metrics available" note instead of a wrong or empty number. - **Wertstrom**: the newest `value_stream_maps` row of the project — lead time (Durchlaufzeit), value-added ratio, bottleneck station — derived via the existing vaClass-aware VSM metric helpers (QVS-P4), not a bespoke recomputation. - **Maßnahmen**: a combined counter across `lsc_measures` and `workshop_actions` (each table keeps its own status vocabulary) with three visible buckets — open / in progress / done; the total equals the sum of these buckets (rejected workshop actions are not counted as measure stock). - Demo state: no badge of its own — the sticky project header already renders the demo badge for every `/project/[id]` route. - Each tile links into its own module (Fabrikanalyse, QAF, Wertstrom, Maßnahmen) and degrades independently to a clean "no data" tile — never a crash or an empty gap — when the project has nothing yet for that module. - The project's `order_reason` ("Ausgangslage") and `order_objective` ("Ziele") fields are rendered as their own labeled sub-section in the Projektdetails card when set; hidden entirely when both are empty. - **iOS scope**: web-only for this PR; the underlying tables are already PostgREST-readable, no new API surface. ### Cycle Time Study - Stopwatch with requestAnimationFrame precision - Multi-station measurement (station picker) - Inline edit/delete measurements - Outlier flagging - Notes per cycle - Progress indicator (target: 10 cycles) - Excel template import/export ### Takt Diagram - Yamazumi chart (all stations) - Cycle detail chart (per station, drill-down) - Reference lines: customer takt, target CT - Bottleneck highlighting ### Shift Output Tracking - Hourly Soll/Ist recording per shift - 3 shift types (German system) - Delta calculation per hour - Hidden-loss detection ### Workshop Actions - Create/edit/delete actions - Effort/benefit matrix (3×3) - Status lifecycle management - Time + cost saving estimates - Responsible + target date ### QAF Comparison - Upload 3 document versions - Auto-parse cycle time, OEE, cost, reject rate - Side-by-side delta comparison ### QAF-Differences (SupplierPulse) — auditable diff engine - **Distinct from the per-visit QAF Comparison above:** a standalone top-level page (`/qaf-differences`) that batch-compares full QAF cost documents of the **same part number** across quotation rounds, not a single visit's 3 versions. - Multi-file `.xlsx` upload, grouped strictly by part number; per-file parse errors are isolated and reported rather than failing the batch. - 5-stage process-step matching cascade, field-level cost diffs, structure-change detection (new/removed/renamed steps), plausibility checks, and root-cause drivers. - Every comparison persists an **auditable trail** (engine + parser version, baseline selection, step matches, diffs, plausibility issues, audit log) in the `qaf_*` tables. - Reference-quality 8-sheet Excel export, downloadable from the comparison detail page (KAR-840 PR1). - **Summary-metric engine (KAR-840):** 19 canonical money metrics extracted from the Zusammenfassung/SUMMARY sheet with A1-cell provenance, diffed ALT→NEU and persisted to `qaf_summary_metric`/`qaf_summary_diff`. - **Comparison detail view — V11-parity analysis sections (KAR-840):** - KPI tiles (quotation price / material / total production costs, Δ % + amounts) - QAF form view (the six Zusammenfassung positions, Δ % per line) - Cost-structure bucket chart (Material/Manufacturing/Scrap/SG&A, ALT vs. NEU, toggleable legend, Δ markers) - Cost bridge waterfall (per-metric floating steps, residual, NEU composition) - Metrics comparison table with per-value source cells and engine status - Tornado "biggest price movers" (top-N filter; per-step fk deltas, or a comparison-object fallback for summary-only QAFs; uncertain-match caveat) - Negotiation quick wins & big bringers (top-3 cost decreases/increases) - Negotiation levers with fixed asks (process-KPI deltas ≥5 %, uncertain-match caveat) - Interactive projection ("Hochrechnung & Potenzial in €"): editable year/volume table, Δ-per-unit override, defend-quota slider, per-year + cumulative chart; inputs debounced-autosave per comparison (KAR-985 — see Autosave note below) - One-time payments table (development / special tooling / total) - **Preis-Kalkulator (KAR-847/848):** a standalone route per comparison (`/qaf-differences/[id]/kalkulator`, fixed 1:1 to its comparison) turns manual or ALT/NEU-adopted process values (cycle time, parts/cycle, headcount, labour/machine rate, inefficiency, material, scrap, SG&A + profit on manufacturing and material) into a live per-part price with the same formula as the G60 QAF. Values can be filled per click from the ALT or NEU side of the bound comparison (whole set or per-field) or from the stopwatch average cycle time. Manual field inputs debounced-autosave per comparison (KAR-985 — see Autosave note below). - **Autosave (KAR-985):** the projection and calculator inputs above persist into an additive `qaf_comparison.user_inputs` JSONB namespace bag (`{projection, calculator}`, same pattern as `qaf_file.g60_meta`) via a ~800 ms debounced save — no explicit Save button, a small "Gespeichert"/"…speichert" indicator is the only UI signal. Failsoft by design: any DB error (e.g. the migration not yet applied) degrades to a quiet "Speichern derzeit nicht verfügbar" hint (save) or "nothing saved yet" (load) — the page stays fully usable either way. This does **not** apply to `qaf-g60-detail.tsx`'s own projection instance (the G60 detail comparison view), which stays session-only as before. - **QAF upload transport:** the browser uploads workbooks (≤20 MB each, ≤12 per batch) directly to the private `qaf-uploads` storage bucket via signed URLs; analysis reads from storage server-side. Originals stay stored for re-ingest. iOS must use the same two-step flow (request upload targets → PUT to storage → trigger analysis) — multipart uploads to the API will hit platform body limits. - **G60 detail-QAF comparison (KAR-840 G60 track):** `.xlsm` detail workbooks are auto-detected, persisted structurally (cost tabs, INPUT rate card, volumes — migration #105) and compared as whole files (`comparison_mode='g60'`, upload order = ALT/NEU with baseline review, cross-batch pairing). The G60 detail view shows: headline KPIs (total quotation delta, global machine-rate lever, tab count with PART-SPECIFIC outliers), six-bucket cost structure + bridge, per-tab metric table (11 metrics, PART-SPECIFIC flags), tornado per cost tab, production index (ALT=100, log/linear), anomalies & drivers from the INPUT card (CMEAN clear names), the three G60 negotiation levers, and the projection pre-filled with the QAF's real yearly volumes. - **G60 scenario editor (KAR-840 G4):** live what-if on the NEU quotation — global lever factors (machine rate, labour, cycle time, staffing, material, inefficiency removal) plus a per-tab, per-row process editor (cycle/emp/ labour rate/inefficiency/MSS/scrap/material). All figures recompute client-side through the delta-anchored pure engine (no overrides = persisted analysis exactly); outcome shows Potential vs. Bestandsaufnahme per bucket, Δ per piece and total savings over the QAF volumes. Session-only state (V1). - **Multi-QAF container comparison (KAR-947, `comparison_mode='multi_qaf'`):** a Multi-QAF workbook packs several product variants (each with its own dimensions, annual/peak/lifetime volumes, and an active/inactive/reserved state) into one file. Auto-detected at upload time (`multiQafDetection`, default **ON** since KAR-925 — Kais' go, TG 8475; a comparison persisted before that flip keeps its own pre-flip detection config on file-replace, so its behavior never silently changes). Comparing two such containers produces: a composite-identity-based variant match (with a manual per-variant override — confirm/reject a match, with a note; set or cleared, each immediately recomputes the persisted result), a container-structure diff, a material-matrix diff, a per-variant summary-metrics profile diff, and an aggregate volume-weighted cost impact. Every section is Result-version-tolerant: a comparison computed before a given sub-feature shipped shows an explicit "not available for this comparison" notice, never a silently-empty section that could be misread as "no differences". - **Variante↔Standard-QAF-Vergleich (KAR-948, `comparison_mode= 'multi_qaf_variant_vs_standard'`):** covers the case where a project has only ONE Multi-QAF container on file (no second container to diff against). The user picks ONE active variant out of an already-uploaded Multi-QAF container and compares it against a confirmed Standard-QAF file of the same project — summary-identity checks, a summary-metrics diff, and an explicit list of the standard-engine's detail modules that are structurally not applicable to a single-variant compare (never presented as empty/zero-diff sections). - **iOS scope:** web-only for the BMW pilot. iOS may later read the `qaf_*` rows via PostgREST; no separate data model needed. ### QAF → Wertstrom-Übernahme (QVS, flag-gated: `qafValueStream`, `true` in `bmw`/`default` since QVS-P7, `false` in `_template`) - **"Als Wertstrom übernehmen"** — a one-click path from a QAF comparison with real manufacturing data (`qaf_manufacturing_step`, the main engine — never the legacy `qaf_uploads.parsed_data` path the per-visit QAF Comparison above still uses) into a new Wertstromanalyse (VSM), with full field-level source lineage. Replaces manually retyping QAF numbers into the VSM editor. - **Entry points (both open the same preview dialog):** (1) the QAF-Vergleich detail page (§10a/§10b — `summary`/`g60` comparison modes only; an ALT/NEU comparison offers a side selector, default NEU), (2) a project's QAF tab, listing that project's main-engine QAF comparisons with at least one eligible side (separate from — and additive to — the existing per-visit QAF Comparison Board on that same page, which keeps reading the legacy path unchanged). The button is never shown for a file with no detectable manufacturing steps (no dead button) or when the flag is off. - **Preview dialog:** source file name, an editable suggested title (`[Lieferant] · [Projekt] · [Variante] · QAF-Wertstrom`), a per-step checklist (deselect individual steps before creating), a coverage line ("18 Schritte · 15 mit Zykluszeit · 12 mit Kosten"), non-blocking warnings, a collapsible list of fields that could not be extracted (with the reason), and a duplicate-import banner ("Öffnen" the existing Wertstrom / "Trotzdem neu erstellen") when this exact QAF file was already imported before. If the duplicate check itself fails, the dialog says so explicitly ("Duplikat-Prüfung nicht verfügbar") — it never silently reports "0 duplicates". - **Creation is transactional and idempotent** (one Wertstrom + one audit/import record per confirmed preview, re-submitting the same confirmation is a no-op); on success the browser is redirected straight into the new Wertstrom's editor with a success toast reporting the partial-import balance ("18 Schritte importiert, 3 ohne Zykluszeit"). - **Editor extensions (additive — existing manually-built Wertströme are unaffected):** - A subtle, colourless marker on a node that came from a QAF import, plus a per-field "importiert"/"geändert" tag once a value is edited after import (never on a manually created node). - **"Quelle anzeigen"** on an imported node opens all of its captured QAF source fields — spreadsheet cell, original value, unit, parser confidence. - **Value-added classification** is a 4-way choice (Wertschöpfend / Notwendig, nicht wertschöpfend / Nicht wertschöpfend / Ungeklärt) instead of the old binary "Wertschöpfend" checkbox; imported steps default conservatively (never auto-"Wertschöpfend" — the classification the legacy Excel import used to hardcode). The old checkbox's underlying value is kept as read-only, unmodified compatibility data and shown as a hint until a step is explicitly classified. - **QAF-Soll/Stoppuhr-Ist comparison:** a step with both a QAF cycle time and a matching measured cycle time (by process name, same join key the existing QAF↔Prozess-Step mapping already uses) shows both plus the delta — display-only, never auto-overwrites the editor's cycle-time field. - The Wertstromanalyse list shows "aus QAF · " on an entry that came from this flow. - **Never fabricates data:** a field the QAF genuinely does not contain stays visibly empty ("—"), never a placeholder number; a step whose position is ambiguous is imported with the source row order and a non-blocking warning, never silently reordered or dropped. - **iOS scope:** web-only, behind the flag. No iOS work until the flag is evaluated for general availability. - **Multi-QAF variants (QVS-P4, additive):** when the source QAF is one side of a Multi-QAF-Varianten-vs-Standard comparison, the preview gains a Varianten-Sektion listing an EVIDENCE-SCOPED variant set (label, volume; Review-Fix 1, PR #338) — always the ONE variant the comparison was actually run against, plus any OTHER active variant provably bound to the SAME manufacturing profile (`variantProfileBindings`), never "every active variant in the container" unconditionally (a container may legitimately run variants on different manufacturing profiles/plants, and the comparison itself never checks manufacturing compatibility) — with a strategy choice: "Geteilter Fertigungsfluss" (default, one Wertstrom, every node tagged with that evidence-scoped key set) or "Je Variante ein Wertstrom" (N Wertströme with identical steps, one variant tag AND its own distinguishing title suffix each — Review-Fix 3). A degraded variant-context check surfaces its own visible "nicht verfügbar" notice, never silently identical to "no Multi-QAF context" (Review-Fix 8) nor a silently untagged create (Review-Fix 7). Multi-QAF has no per-variant step-level data (a shared cost-profile aggregate, not a process-step list) — cycle times are never fabricated per variant, and the section is never shown for a plain Multi-QAF-vs-Multi-QAF comparison (neither side has manufacturing steps to import from). "Je Variante" is N independent creates, not one transaction — a mid-sequence failure is reported per variant (toast type reflects the actual outcome — success/info/error, never a hardcoded green — Review-Fix 2/10), never hidden. - **`sum_planned_capacity`/`sum_lot_size` (QVS-P4):** the QAF Summary sheet's "Plankapazität [Teile/Jahr]" and "Fertigungslosgröße [Teile]" premises (previously unparsed) now feed the import record's engine context and a Kapazitäts-Kontext metric (exact `lotsPerYear = plannedCapacity ÷ lotSize`, no fabricated Kundentakt derivation — that would need an unparsed working-hours-per-year constant). - **Kennzahlen-Erweiterung (QVS-P4, `vsm-metrics.ts`, additive — existing Bottleneck/VA-Quote untouched):** a vaClass-aware VA-Quote (va/nnva/nva/ungeklärt separately, legacy binary-only nodes marked "abgeleitet"), Setup-/Warte-/ Transportzeit-Summen (node-level; `null` when no node carries the field, never a 0-lie), and a Kosten-/Scrap-Rollup per Währung (mixed currencies always kept in separate buckets, never silently summed — scrap is AW-denominated, its own bucket). Every metric ships a Formel/Datenbasis/Ausschlüsse explain object. Computed and unit-tested; not yet wired into an editor panel (follow-up). - **Reimport & Synchronisation (QVS-P5, additive, Spec 21):** an imported Wertstrom (any node still carrying `qafSource`) can be re-synced against a QAF source — either the file it was originally created from (re-checks whether the source itself changed; a `qaf_file` row never mutates in place, so this is a legitimate "nothing changed" confirmation) or a DIFFERENT/newer `qaf_file` upload in the same project (the "A newer QAF revision is uploaded" scenario). The delta engine classifies every matched step AND every one of its fields into exactly one of the 6 statuses Spec 21 names: **Unverändert**, **Quelle geändert**, **Lokal geändert**, **Konflikt** (changed on both axes since the last sync), **Neu in Quelle**, **In Quelle entfernt**. Matching a step across two different QAF uploads (row indexes are not comparable across files — every upload gets fresh, unrelated `qaf_manufacturing_step` rows) uses the process name as the identity; a name whose count differs between the two sides (e.g. one "Prüfen" became two) is never force-matched — it surfaces as its own, honestly unresolved "nicht eindeutig zuordenbar" state instead of guessing which one corresponds to which. - **Selective adoption, never silent:** a Übernahme-Plan can apply all source changes, a hand-picked subset, or none. "Lokal geändert" fields are NEVER touched by a bulk "alle übernehmen" — the only way to move a Konflikt-Feld (changed both source-side and locally) is an explicit per-field decision ("Quelle übernehmen" / "Lokal behalten"). A step removed from the source defaults to staying in the Wertstrom (explicit "entfernen" required to actually delete it). Adopting a field also refreshes that field's own source-lineage entry (cell/original value/confidence) so "Quelle anzeigen" never shows stale provenance after a sync. - **Separate comparison copy:** instead of updating the existing Wertstrom, "Als separaten Vergleichs-Wertstrom anlegen" creates an entirely independent Wertstrom from the chosen source (reuses the normal one-click creation path unchanged), titled ` · Reimport ` — the original Wertstrom and its import history are untouched by this option. - **Persistence:** no new migration. The existing `value_stream_imports` audit record is updated in place on every reimport (its `import_snapshot` becomes the new sync baseline; a `reimportHistory` entry inside `engine_context` keeps the full time series of what was adopted/kept/removed and when) rather than inserting a new row per sync — a deliberate, schema-compatible choice (`engine_context` has no closed shape) over the "N import rows over time" pattern the schema also supports (used instead by the separate-comparison-copy option above, which genuinely is a new, independent import). - **Entry point:** a "Synchronisieren" action in the Wertstrom editor toolbar, shown only when the Wertstrom has at least one QAF-imported node (an old, manually built, or Excel/LSC-imported Wertstrom never sees it) and the flag is on. ### Wertstromanalyse — Szenarien, Kantentypen, Lager-Untertypen, Provenance (Wertstrom P2, KAR-878/KAR-986) Datenmodell-Erweiterung des VSM-Editors (`value_stream_maps`) — the data model itself (A7/A8/A12 fields, the `scenario_kind`/`parent_value_stream_id` columns) is additive and not gated behind a feature flag. The A9 **create-action** (below) IS gated — review-fix F2 (adversarial review, PR #353) corrected the original "kein Feature-Flag" claim here: CAPABILITY-MATRIX.md explicitly scopes the Soll-Zustand-Erstellung UI to P5, and P5 is on the matrix's own flag-mandatory list. No UI redesign ("das UX-Herz" — Quick-Start-Wizard, Auto-Layout, Panel-Redesign — is P3/P4); this phase only makes the new data shapes creatable/visible. - **Informationsfluss-Kantentyp (A7):** a connection can be `materialFlow` (default, every pre-existing connection) or `information`. Chosen via a small Material/ Information toggle shown while drawing a connection, plus an optional free-text frequency ("täglich", …) for information flow. Renders dashed on the canvas (material flow stays solid) — no new symbol matrix, matching the Simplicity-Ansatz. - **Lager-Untertypen (A8):** the existing generic inventory element gains an optional "Lager-Art" choice — FIFO-Bahn, Supermarkt, or Push (one select on the same element, not three separate palette entries) — plus an optional max-capacity field shown only for FIFO ("FIFO mit Kapazität"). Absent = today's generic/undifferentiated inventory, unchanged. Validated by the A11 engine (review-fix F4): a negative capacity is critical, a FIFO quantity above its capacity is a warning (a real lane can genuinely overflow — a modelling hint, not an impossibility). Switching away from FIFO clears the capacity value, not just its input (review-fix F10) — the canvas card no longer keeps showing a stale "/ " for a since-changed Lager-Art. - **Szenarien — Ist/Soll (A9):** "Soll-Zustand erstellen" in the editor toolbar — gated behind the `wertstromScenarios` flag (`config/profiles/`, off in every profile until P5, review-fix F2) — duplicates the current Wertstrom (nodes/connections/layout, node/connection ids preserved) into a new, independent map with a traceable link back to the source (`parent_value_stream_id`) and `scenario_kind: 'future'`; the source map is never modified. `is_demo` is always `false` on the new map regardless of the source's (review-fix F1 — a user-created Soll-Zustand is never seed content). Only an Ist-Wertstrom (`scenario_kind: 'current'`) can be duplicated — chaining off an already-derived scenario is rejected (button hidden client-side, 400 server-side, review-fix F3), so a scenario's `parent_value_stream_id` always points at the Ist-Wurzel, never at an intermediate scenario. If the editor has unsaved changes when "Soll-Zustand erstellen" is clicked, it saves them first — a failed save aborts the duplicate entirely rather than silently deriving the new Soll from a stale server copy (review-fix F5). The Wertstromanalyse list shows a small "Soll"/"Alternative" badge for a derived scenario (nothing shown for an ordinary Ist-Wertstrom); both the button and the badge are hidden when the flag is off. Side-by-side KPI comparison and reopening a scenario's delta view are explicitly **P5** — this phase covers creation + listing + labelling only, per execution-prompt §9.1/§9.4. - **Provenance ("Herkunft", A12):** a node can carry one data-quality tag — geplant / gemessen / berechnet / importiert / angenommen — shown as a small read-only badge next to the Zykluszeit field (review-fix F11 — moved off the node header, which read as a node-wide claim it never was; all 3 write paths only ever tag `cycleTimeSec`). Set automatically by the two stopwatch/LSC paths that already existed (Capability-Matrix "RETAIN EXISTING"): a live inline stopwatch measurement and the LSC-Workshop bulk import tag "gemessen" when a real `cycle_measurements` average exists, "geplant" when they fall back to a step's planned cycle time. Never silently overwrites: hand-editing the Zykluszeit field resets provenance to unknown rather than leaving a stale claim (review-fix F6), and replacing an already-set value with a lower-confidence one (confidence order measured > calculated = imported > planned > assumed) asks for confirmation first (review-fix F7 — e.g. the Stoppuhr-Picker's "geplant" pick over an existing "gemessen" value). Absent = unknown, no badge shown (never a noisy "unbekannt" badge on every node). - **iOS scope:** web-only (the VSM editor itself is web-only per the existing QVS section above); no separate iOS data model needed for these additive JSONB fields. ### Wertstromanalyse — Quick-Start-Wizard, Auto-Layout, Timeline-Leiter v2 (Wertstrom P3, KAR-878/KAR-986) "Das UX-Herz" (Capability-Matrix A1/A2/A4) — complete behind the new `wertstromUxV2` feature flag (`config/profiles/`, `false` in every profile; Phasenplan-Pflicht for P3). Existing editor behaviour is byte-identical while the flag is off. - **A1 Quick-Start-Wizard (`components/wertstrom/vsm-quick-start-wizard.tsx` + `vsm-wizard-logic.ts`):** a 5-step guided flow, opened via a "Neu mit Assistent"/"Mit Assistent erstellen" button on the Wertstrom list page (gated, next to the existing "Neue Wertstromanalyse"): 1. **Produkt & Bedarf** — Titel (required to finish, not to advance), Projekt (optional), Produkt (optional, free text), Bedarfsmenge (optional). 2. **Arbeitszeit** — Std./Schicht, Schichten/Tag, Pausen (Min./Schicht), Arbeitstage; all optional (§8.2 simple work-time model). 3. **Prozessschritte** — repeatable Name + optional Zykluszeit (s) rows, "+ Prozessschritt hinzufügen"; at least one named step is required to advance past this step (the one non-skippable step — a Wertstrom needs at least one process). 4. **Bestände zwischen Prozessen** (optional) — one toggle + optional Menge (Stk) per gap between two named process steps; skipped entirely when fewer than two steps are named. 5. **Ergebnis** — summary (title, step/inventory counts, Taktzeit via the P1 engine's `computeTakt`) and "Fertigstellen". "Fertigstellen" is the ONLY point that touches the network — every earlier step is local React state, so closing/cancelling the wizard at any point creates zero rows (no data litter). It calls the EXISTING `POST /api/wertstrom` (title/description/ project_id) followed by the EXISTING `PUT /api/wertstrom/[id]` (nodes/connections, with the `If-Match` optimistic-locking header from the POST response) — no new route, no server-contract change. The built graph is Lieferant + one node per named process step + optional Lager-Nodes + Kunde, connected in a single linear materialFlow chain (`buildLinearConnectionPairs`, the existing P0 helper) and positioned by the new Auto-Layout function (below). A process step's cycle time is tagged `provenance: 'planned'` (a plan value, never a measurement) — only on a step that actually has a cycle time. The Kunde node's `demand` field is set from Bedarfsmenge when given. "Produkt" has no dedicated column (Nicht-Scope: no migration) — folded into `description` as `"Produkt: "` when entered, a real, readable home for the value rather than dropping it silently. Every step stays skippable (§10.3 Smart Defaults) EXCEPT Prozessschritte; missing working-time/demand data makes the Ergebnis step's Taktzeit honestly "nicht berechenbar" (with the engine's own exclusion reasons shown) rather than a guessed number. - **A2 Auto-Layout (`components/wertstrom/vsm-auto-layout.ts`, `computeAutoLayout`):** a pure, deterministic function — additive/unflagged, inert without a caller. Orders Lieferant→Prozesse→Kunde via a topological sort over materialFlow connections (Kahn's algorithm, deterministic array-order tie-break; anything the graph can't resolve — a disconnected node, a cycle — is appended rather than dropped). Splices Bestands-Nodes onto a row below the main line, at the x-midpoint between their resolved materialFlow predecessor/successor (staggered when two collide onto the same slot); a node whose ONLY connections are `kind: 'information'` is placed on a row above instead (production-control-style nodes), matching §11.1's "supplier left, customer right, production control/information above, inventories between processes". Used by the Quick-Start-Wizard for its initial layout AND by a new, flag-gated "Automatisch anordnen" button in the editor's toolbar — the button always confirms first (`window.confirm`) since it overwrites every node's manual position; manual dragging remains fully available afterwards (this is a one-shot repositioning action, not a persistent constraint). - **A4 Timeline-Leiter v2 (`components/wertstrom/vsm-timeline-ladder.tsx`):** renders the P1 engine's `computeTimelineLadder` (`lib/vsm-engine`) below the canvas — a proportional segmented bar (Wertschöpfend/NVA-Prozesszeit/Wartezeit/Bestandszeit/ Transportzeit), Durchlaufzeit (DLZ), and Process Cycle Efficiency (PCE), all derived live from the editor's `nodes` state (the UI never recomputes — P1 doctrine). PCE shows "nicht berechenbar" rather than a fabricated 0% when no VA time was measured; DLZ is flagged "(ohne Bestandszeit)" when inventory nodes exist but coverage isn't computable (no demand/shift-model input available in the plain editor — an honest, visible gap, not a silent underestimate). The engine's `formula`/`dataBasis`/ `exclusions` (MetricExplain) are reachable via a native `
` disclosure — always in the DOM, keyboard-operable, not a hover-only tooltip. Replaces the pre-existing 1-Prozentbalken ONLY while the flag is on; the old bar is untouched and byte-identical when it is off. - **Scope decisions:** no migration, no new DB columns, no engine-formula changes (P3 only consumes `computeTakt`/`computeTimelineLadder`, both already shipped in P1). No new API route — the Wizard's "Fertigstellen" deliberately reuses the two existing Wertstrom endpoints verbatim rather than widening `CreateValueStreamMapBody`; the `wertstromUxV2Gate` predicate therefore has no dedicated route call site this phase (unlike `wertstromScenariosGate`) and is instead the single source of truth both `page.tsx` files use to resolve the `wertstromUxV2Enabled` prop. A11y-Basis: every wizard input has a real `