# TODO

## Offen

- [ ] (Demo-067 C, KAR-982) QAF-Vergleich-Copilot-Export unterstützt nur den Standard/Summary-
  Vergleichsmodus (`comparisonModeRule(...).exportSupported`, gleiche Beschränkung wie der
  bestehende XLSX-Export) — G60-, Multi-QAF- und Variante↔Standard-Vergleiche haben keinen
  Copilot-Export. Eigener Folge-Task, falls gewünscht.
- [ ] (Demo-067 C, KAR-982) Copilot-Exporte sind DE-only — anders als der bestehende Fabrik-
  analyse-Export (`lib/assessment-export.ts`, DE/EN/ZH über `AssessmentLang`) gibt es keine
  Sprachauswahl. Bewusste Scope-Entscheidung für diesen PR (Auftrag: "Sprache der Inhalte:
  Deutsch"); EN/ZH wäre ein eigener Folge-Task.
- [ ] (Demo-067 C, KAR-982) Kein Audit-Trail für Copilot-Exporte (anders als QAF's `qaf_export`-
  Tabelle für den bestehenden XLSX-Export) — bewusst, da eine neue Tabelle/Spalte eine Schema-
  Änderung wäre (außerhalb dieses Tasks). Falls Audit-Logging gewünscht wird, braucht es eine
  eigene Migration + Review.

- [ ] (KAR-889 Follow-up, Fachfreigabe nötig) R3 ("Nicht-Pflichtfeld inkorrekt") ist hart auf `warn` verdrahtet, nie blockierend — offene BMW-Fachfrage lt. Fehlerreport-Analyse §6.1, ob das dauerhaft korrekt ist. Nicht ändern ohne Rückfrage.
- [ ] (KAR-889 Follow-up, P1.1) Regel-Engine-Pflichtfeldliste ist bewusst minimal (`partNumber` + 4 Fertigungskosten-Felder) um Bestandsfixtures nicht zu fluten — migriert später auf das kanonische Feldmodell (P1.1), dann auch `supplier`/`supplierNo` etc. neu bewerten.
- [ ] (KAR-778/R22 Follow-up, migrations-gated) Partieller UNIQUE-Index `email_queue (to_email, template) WHERE status='pending'` als echter Race-Schutz — aktuell nur Application-Level check-then-insert in `queueEmail`.
- [ ] `app/project/[id]/analyse/page.tsx` erstellen — Tab für Fabrikanalyse-Projekte (verlinkt auf Assessment-Workflow)
- [ ] `onlyOwn`-Filteroption in `ViewConfig` serverseitig/RLS-seitig durchsetzen (aktuell nur clientseitig, kein echter Schutz)
- [ ] Passwort-Änderungsseite `/auth/change-password` testen — `must_change_password`-Flag wird vom Proxy erzwungen
- [ ] Projektliste mit echten DB-Daten testen (Lookup-Tabellen befüllt?)
- [ ] DB-Migration für Projektformular ausführen: `MO-24/` SQL-Dateien (project_types, project_statuses, project_responsibilities, project_id_sequence, ALTER TABLE projects, project_consultants, role_view_configs)
- [ ] `check_email_in_profiles` RPC in Supabase anlegen (benötigt von create-user-modal.tsx)
- [ ] E-Mail-Versand für Kontoanlagen testen (`notifyAccountCreated` in `/api/admin/users`)
- [ ] (gefunden bei QVS-P3, KAR-972) Das bestehende Wertstrom/VSM-Modul (`components/wertstrom/`, `/wertstrom`) selbst hat nie einen PRODUCT_SPEC.md/UI_FLOWS.md-Eintrag bekommen (vorbestehende Lücke, nicht durch QVS verursacht) — nur die QVS-Erweiterung wurde dokumentiert. Backfill wäre ein eigener, ungefragter Task.
- [ ] (gefunden bei QVS-P4, KAR-973) Die neuen additiven `vsm-metrics.ts`-Kennzahlen (`computeVaClassBreakdown`, Setup-/Warte-/Transport-Summen, Kosten-/Scrap-Rollup, `computeCapacityContext`) sind berechnet + unit-getestet, aber noch NICHT in ein Editor-Panel verdrahtet — `vsm-editor.tsx` zeigt sie nirgends an. `computeCapacityContext` braucht außerdem noch einen Loader für `value_stream_imports.engine_context` (der Editor lädt diesen Import-Record heute nicht nach). Eigener, ungefragter Folge-Task.
- [ ] (gefunden bei QVS-P4, KAR-973; korrigiert bei PR #338 Review-Fix 5) `sum_planned_capacity`/`sum_lot_size`-Real-Korpus-Abdeckung liegt bei tatsächlich 54,6 %/85,9 % (gemessen NACH dem labelScan-Plausibilitäts-Guard), nicht bei den im P1-Korpus-Scan zitierten 97 % — und auch niedriger als die zuerst gemessenen 61 %/88 %, weil diese Erstmessung 13-14 Dateien mit einer benachbarten SUMMARY_METRIC-Label-Kollision fälschlich mitzählte (Root-Cause: siehe `qaf-value-stream-corpus-evidence.md`-Nachtrag). Kein Bug, aber falls die 97 % später fachlich vorausgesetzt werden, hier nachschlagen statt neu zu wundern.
- [ ] (gefunden bei PR #338 Review-Fix 5, Follow-up-KAR folgt) Derselbe labelScan-Kollisions-Mechanismus (jetzt für `plannedCapacity`/`lotSize` per `FieldDef.strictValueCheck` gefixt) betrifft nachweislich auch 2 bereits ausgelieferte KAR-910-Felder — `peakVolumeYear` (6/17 Schnittmengen-Dateien) und `deliverySite` (5 Dateien). Bewusst NICHT in diesem Fix mit-behoben (kein stilles Verhaltens-Update ausgelieferter Felder) — eigenes Follow-up-KAR nötig, um `strictValueCheck` kontrolliert auch dort zu prüfen/aktivieren.
- [ ] (gefunden bei QVS-P5, KAR-974) `computeSyncDelta`s Namens-basiertes Matching erkennt eine im QAF umbenannte Station nicht als Rename (QAF trägt keine Prozess-UUID) — sie erscheint als REMOVED_FROM_SOURCE (alter Name) + NEW_IN_SOURCE (neuer Name) statt als ein SOURCE_CHANGED-Feld `name`. Bewusst keine Positions-Fallback-Heuristik gebaut (wäre Raten statt Ableiten). Kein Bug, dokumentierte Grenze — falls das in der Praxis stört, bräuchte es eine stabile Prozess-Identität im QAF selbst (Datenmodell-Frage, kein QVS-P5-Scope).
- [ ] (gefunden bei QVS-P5, KAR-974) Kein separater adversarialer Review-Pass (wie ihn P2/P3/P4 in eigenen Folge-Commits bekamen) — die Bestandsaufnahme mündete v. a. in der Migrations-Status-Klärung (Ergebnis: applied 18.07., gegen die Live-DB verifiziert — siehe MIGRATIONS.md §7o + CHANGELOG), ansonsten keine formale Mehrdimensions-Review. Wäre ein sinnvoller Folge-Schritt vor dem Merge.
- [ ] (gefunden bei KAR-980, Demo-067 A) `reconciliation.ts`s `angebotspreis_cascade`-Check kann auf `QAF_LEGACY_DE_SUMMARY`-Dateien NIE `bestanden` erreichen — `rawMaterialPriceShareEnergy` hat dort strukturell keinen `TEMPLATE_CONFIG.rows`-Eintrag, `evaluateCascadeCheck`s `missing`-Gate greift daher immer (Ergebnis `nicht_pruefbar`, Severity `hinweis`, nie `kritisch` — kein Bug, aber dokumentiert hier, damit es niemand später als neuen Fund verwechselt). Betrifft nicht nur die Demo-Dateien, sondern jede echte Legacy-Summary-QAF.
- [ ] (Wertstrom P3, KAR-878/KAR-986) `computeAutoLayout` (`components/wertstrom/vsm-auto-layout.ts`) ordnet die Prozesskette per topologischer Sortierung in EINE einzige Reihe — dieselbe Gap-G6-artige Grenze wie `computeTimeline`/`computeTimelineLadder` (lib/vsm-engine): ein echt verzweigter Wertstrom (zwei parallele Prozesspfade, die vor dem Kunden zusammenlaufen) bekommt keine Mehrspuren-Anordnung, sondern eine einzelne plausible, aber nicht spur-differenzierte Reihenfolge. Für den Simplicity-Doktrin-Hauptfall (normaler linearer Wertstrom, §10.5) ausreichend und bewusst nicht behoben — ein echtes Mehrspur-DAG-Layout wäre ein eigener, ungefragter Folge-Task.
- [x] ~~(Wertstrom P3, KAR-878/KAR-986) Die Timeline-Leiter v2 (`vsm-timeline-ladder.tsx`) im normalen Editor ruft `computeTimelineLadder` OHNE `demandUnitsPerDay`/`shiftModel` auf — der Editor hat (außerhalb des Quick-Start-Wizards) keinen persistenten Ort für Bedarf/Arbeitszeitmodell ohne neue DB-Spalte (Nicht-Scope). Bestandszeit ist dadurch im normalen Editor grundsätzlich "nicht berechenbar" (ehrlich, kein Bug) — falls das stört, bräuchte es eine eigene Persistenzentscheidung (z. B. `layout`-JSONB, wie schon `layout.viewport`), kein P3-Scope.~~ — gelöst in Wertstrom P4 (B2, KAR-878/KAR-986): `layout.shiftModel` (additiv, `layout.viewport`-Muster), editierbares Formular in `vsm-timeline-ladder.tsx`, `demandUnitsPerDay` aus Kunden-Node-`demand` summiert.
- [ ] (Wertstrom P4, KAR-878/KAR-986) Die neue Tabellen-View (`vsm-table-view.tsx`) zeigt NUR Prozess-Nodes (`type === 'process'`) — Bestand/Transport/Kunde/Lieferant/Maschine/Zeitwert bleiben Canvas-only. Bewusste Scope-Entscheidung (einheitliches Spaltenschema passt nur zu einheitlicher Zeilen-Semantik), aber falls Bulk-Edit auch für andere Node-Typen gewünscht wird, bräuchte es ein eigenes Spalten-/Zeilenkonzept (kein P4-Scope).
- [ ] (Wertstrom P4, KAR-878/KAR-986) Excel-Paste in der Tabellen-View (`vsm-table-paste.ts`) deckt nur die Essential-Felder ab (Name/Zykluszeit/Anzahl Mitarbeiter) — anders als der bestehende Datei-basierte Excel-Import (5 Zeitfelder) gibt es keinen Paste-Weg für die Advanced-Zeitaufschlüsselung oder die 9 P4-Kostenfelder. Bewusste Scope-Entscheidung (Paste-Spalten = Tabellen-Spalten, 1:1); Advanced-Feld-Paste wäre ein eigener Folge-Task.
- [ ] (Wertstrom P4, B3, KAR-878/KAR-986) `mtbfMin`/`mttrMin` sind reine Referenz-/Eingabefelder ohne Verknüpfung zu echten Stillstands-/Ausfallzeit-Datenquellen (z. B. Shift-Output/OEE-Erfassung) — die "→ berechnete Verfügbarkeit"-Ableitung ist eine reine Formel-Anwendung, kein Datenimport. Eine echte Verknüpfung zu gemessenen MTBF/MTTR-Werten wäre ein eigener, ungefragter Folge-Task.
- [ ] (Wertstrom P5, KAR-878/KAR-986) Der KPI-Delta-Vergleich (`vsm-scenario-compare.ts`) zeigt bewusst nur die P5-Brief-"Kern-KPIs" (Takt-Auslastung Engpass, DLZ, VA-Zeit, PCE, Bestandsreichweite gesamt, Engpass-Node) — die restlichen execution-prompt-§9.3-KPIs (Output, Kapazität, Operatoren, Schichten, OEE, Scrap, Nacharbeit, Risiken, Maßnahmen) sind nicht gebaut. Für Output/Kapazität/OEE/Scrap existieren bereits Engine-Bausteine (`lib/vsm-engine`, `lib/oee`) und könnten ergänzt werden; Risiken/Maßnahmen haben aktuell keine eigene Datenquelle am Wertstrom (nur `workshop_actions` am Projekt, nicht am Node/Wertstrom verknüpft) — wäre ein eigener, ungefragter Folge-Task.
- [ ] (Wertstrom P5, KAR-878/KAR-986) Die Parameter-Abweichungs-Ansicht (§9.4) kann "Nacharbeit" (Rework) nicht vergleichen — `VsmNode` hat kein `reworkRatePct`/`reworkTimeSec`-Feld (bereits in P1 bewusst nicht hinzugefügt, `lib/vsm-engine/internal/quality.ts`). Ebenso fehlen Grund/Autor/Änderungsdatum je Feldänderung komplett im Datenmodell (`VsmNode.fieldStatus` kennt nur 'imported'/'modified', kein Wer/Wann/Warum). Beide Lücken sind in der neuen Ansicht als Hinweistext ausgewiesen (kein stilles Verschweigen), aber ungelöst — ein Nacharbeits-Feld und ein Änderungs-Audit-Trail wären eigene, ungefragte Datenmodell-Erweiterungen (Migration nötig).
- [ ] (Wertstrom P8.2c, KAR-878/KAR-986/KAR-987) `es.json`/`zh.json`s neuer `wertstrom.*`-Namespace ist eine 1:1-Kopie der EN-Werte (deklarierte Übersetzungsschuld — kein Auto-Translate von ~700 Fachbegriffen ohne menschliches Review). Eine echte ES/ZH-Fachübersetzung wäre ein eigener, ungefragter Folge-Task (idealerweise mit einem Lean/VSM-Fachreview, nicht nur Maschinenübersetzung). Ebenfalls offen: `lib/copilot-export/internal/wertstrom-docx.ts`/`wertstrom-md.ts` (Copilot-Export DOCX/Markdown) rendern weiterhin hartkodiertes Deutsch — außerhalb des P8.2c-Datei-Scopes (`components/wertstrom/**`/`app/wertstrom/**`), aber derselbe `computeManagementAnalysis`-Fließtext, den P8.2c bereits als Engine-Grenze deklariert hat, landet über diesen Pfad auch im Word/Markdown-Export, nicht nur im PDF.
- [ ] (Wertstrom P6, KAR-878/KAR-986) `app/api/wertstrom/import/preview` akzeptiert `.json`-Dateien bis 4 MB (Route-eigenes Limit, Headroum unter Vercels 4,5-MB-Node-Serverless-Body-Cap) — die größte real vermessene SimVSM-Datei (siehe Testkorpus) ist ~13,4 MiB und kann über diesen Weg NICHT importiert werden (dokumentierte, bewusste P6-Scope-Grenze, kein stiller Fehlschlag: die Route meldet die Datei als "zu groß" statt zu crashen). Ein größerer Weg (Chunked-Upload, oder ein Storage-Bucket-Umweg: Client lädt zuerst zu Supabase Storage hoch, Route liest von dort) wäre ein eigener, ungefragter Folge-Task.
- [ ] (Wertstrom P6, KAR-878/KAR-986) Idempotenz beim Re-Confirm (`lib/simvsm-import/internal/persist.ts`) ist Application-Level (find-then-insert), nicht DB-atomar — anders als QVS' `value_stream_imports_preview_token_idx` (partial UNIQUE index) gibt es ohne Migration keinen echten Race-Schutz. Zwei gleichzeitige Confirms derselben (Datei, Auswahl, Projekt) könnten in einem sehr seltenen Fenster beide schreiben. Dokumentiertes, akzeptiertes Risiko (siehe `lib/simvsm-import/README.md` "Bekannte Grenze: Idempotenz ohne DDL") — ein echter Schutz bräuchte eine Migration (kein P6-Scope).
- [ ] (Wertstrom P6, KAR-878/KAR-986; Signal-Kaskade ergänzt per Review-Fix, adversarial review PR #360) SimVSMs `isMain`-Flag ist im gesamten realen Korpus (73 Alternativen, 25 Dateien) nie `true` — `resolveCurrentStreamIndex` nutzt seither eine 4-stufige Signal-Kaskade (isMain → unsuffixierter Name gegen `_N`-suffixierten Geschwister → frühestes modificationTime → Array-Index 0), gegen mindestens eine reale Korpus-Datei mit invertierter Array-Reihenfolge verifiziert. Auch die neue Kaskade ist eine Heuristik, kein Beweis — der Preview-Dialog zeigt jetzt zwar hasResultData/modificationTime als Kontext pro Stream-Zeile, bietet aber weiterhin KEINE manuelle "das ist eigentlich der Ist-Zustand"-Korrektur (bewusst außerhalb des einfachen §14.1-Flows gehalten) — falls die Kaskade in der Praxis noch öfter falschliegt, bräuchte es eine kleine manuelle Override-UI, kein P6-Scope (P7-Kandidat).
- [ ] (Wertstrom P6, KAR-878/KAR-986) `noteVSM`/`noteAnnotation` (Kaizen-Hinweise/Anmerkungen) werden erkannt und im Import-Report gezählt, aber NICHT als Datenobjekt übernommen — dem Datenmodell fehlt ein Notiz-/Kaizen-`NodeType` (`lib/vsm-types.ts` hat 7 feste Typen). Das ist zugleich Capability-Matrix A18 ("Maßnahmen aus Engpass/Kaizen"), explizit P8-Scope — ein neuer NodeType bräuchte Editor-Rendering (`vsm-config.ts`/`vsm-editor.tsx`), kein reiner Parser-Task.
- [ ] (Wertstrom P6, KAR-878/KAR-986; teilweise entschärft in P8.2a) `productionControl` (PPS) wird auf `type: 'process'` mit `isValueAdded:false` angenähert (kein eigener PPS-Typ im Datenmodell) — Alternative wäre Verwerfen, das aber die daran hängenden `informationFlow`-Kanten verwaisen ließe (Korpus-Report nennt Informationsfluss "Pflicht"). Bewusste, im Import-Report als "vereinfacht übernommen" ausgewiesene Näherung. P8.2a (Baustein 2, KAR-878/KAR-986) ergänzt `isPps: true` auf dem gemappten Node (`mapping-registry.ts` `targetIsPps`) — ein echtes, positives Identitäts-Signal statt nur einer Typ-Annäherung, aber weiterhin KEIN eigener `NodeType`: ein eigener PPS-NodeType bliebe ein Datenmodell-/Editor-Folge-Task, falls je gewünscht.
- [ ] (Wertstrom P6, KAR-878/KAR-986, C11 — deklarierte Abweichung, adversarial review PR #360; Scope-Korrektur per P7 fix-round) Ein importierter `productionControl`-Knoten hat strukturell nie Zykluszeit-/Kapazitätsdaten (siehe Eintrag oben) und zählt daher in `lib/vsm-engine/internal/bottleneck.ts`s Engpass-Konfidenz permanent als "ungemessene Station" — Konfidenz kann für Wertströme mit PPS-Knoten strukturell nie "hoch" werden, und die Ausschluss-Meldung nennt den Knoten nicht als PPS-Box. Betraf ursprünglich nur den P5-Vergleich (`vsm-scenario-compare.ts`); seit der P7-Fix-Runde (Grundsatz-Entscheidung "v2 überall, wo 'Engpass' draufsteht") nutzt AUCH der normale Editor-Canvas-Badge (`vsm-editor.tsx`) sowie die Copilot-/XLSX-Exporte `computeBottleneckV2` statt der alten `findBottleneckId`-Heuristik — dieser Punkt betrifft damit jetzt den gesamten Wertstrom-UI-/Export-Bereich, nicht mehr nur den P5-Vergleich. Der Parent-Entscheid sah vor, importierte PPS-Knoten mit einem erkennbaren Merkmal zu markieren und in der Konfidenz-Auswertung auszuschließen — NICHT umgesetzt: `VsmNode` hat kein Feld für "SimVSM-Herkunftsklasse" (Zero-Schema-Change-Doktrin), und der einzige verfügbare Träger (`notes`) ist ein echtes, nutzersichtbares Freitextfeld — ein interner Marker darin wäre selbst ein neuer §14.1-Verstoß ("keine Technik-Begriffe in der einfachen Ansicht"). Eine engine-seitige Lösung bräuchte entweder ein neues VsmNode-Feld (Schema-Änderung) oder eine generische (nicht SimVSM-spezifische) Heuristik in `bottleneck.ts`, die aber das Confidence-Verhalten für ALLE Wertström-Nutzer ändern würde (nicht nur SimVSM-Importe) — beides über P6-Scope hinaus. Stattdessen: Assumption im Import-Report (`report.ts` assumptionsDe) deklariert die Konfidenz-Auswirkung explizit. Ein sauberer Fix (z. B. additiver `structurallyUnmeasurableNodeIds`-Parameter an `computeBottleneckV2`, vom Aufrufer aus einem erkennbaren Merkmal befüllt) wäre ein eigener, ungefragter Folge-Task.
- [ ] (Wertstrom P7, KAR-878/KAR-986, P8-E2E-Liste — C25/C26, adversarial review Fix-Runde) Zwei Browser-only-Pfade in der neuen P7-Fläche sind strukturell nicht in jsdom testbar und daher nur durch manuelle Real-Browser-Verifikation vor jedem Ship abgedeckt, nicht durch die grüne vitest-Suite — bewusst NICHT mit Fake-Tests/Polyfills überbrückt (ein Node-Canvas-Polyfill oder ein manuelles jsdom-Fullscreen-Stub würde nur Vertrauen in eine Suite vortäuschen, die den echten Browser-Pfad weiterhin nie ausführt): (1) `vsm-presentation-mode.tsx`s Fullscreen-API-Guard (`document.fullscreenEnabled`/`requestFullscreen`/`exitFullscreen`) — jsdom implementiert die Fullscreen-API überhaupt nicht (kein Treffer im ganzen `node_modules/jsdom`-Package), der Guard ist in JEDEM Testlauf strukturell unerreichbar, nicht nur "gemockt und grün"; die reale Interaktion mit der Browser-Fullscreen-API (inkl. externem Exit über Browser-Chrome-UI) ist ungetestet. (2) `vsm-export-svg.ts`s `svgToPngBlob` (Blob→ObjectURL→Image.onload→Canvas 2D drawImage→canvas.toBlob, PNG-Export-Pfad) trägt bereits `tdd-guard:skip` und wird im einzigen Aufrufort (`vsm-export-dialog.test.tsx`) komplett weggemockt — reale Bilddekodierung/Canvas-Zeichenkette (inkl. Canvas-Tainting-Risiko bei Blob-URLs, Systemfont-Abhängigkeit von `font-family="Arial, sans-serif"`, Canvas-Größenlimits bei sehr großen 2×-Karten) hat im gesamten Repo keine automatisierte Abdeckung. P8-Kandidat: ein Real-Browser-E2E-Sweep (z. B. Playwright/gstack) für Präsentationsmodus (Fullscreen an/aus, inkl. externer Exit) UND Visuelle-Karte-Export (PNG-Datei tatsächlich öffnen/visuell prüfen, kleine UND große Karte) — bis dahin: fester manueller QA-Schritt vor jedem Wertstrom-Export-Release.
- [ ] (Wertstrom P8, KAR-878/KAR-986, Excel-Roundtrip Fix-Runde PR #362 — REFUTED-Finding, bewusst NICHT gefixt) Ein adversarieller Reviewer behauptete, die neue "Wertstrom"-Meta-Blatt-Einfügung (VOR dem "Stationen"-Blatt) breche den ALTEN, vorbestehenden P0-Editor-Excel-Import (`vsm-editor.tsx handleExcelFile`, `ejWb.worksheets[0]` — positionsbasiert, nicht namensbasiert). Ein Verifier widerlegte das: der alte Import konnte bereits VOR diesem PR keine P7-Excel-Exportdatei lesen (jede von `exportToXlsx` erzeugte Sheet beginnt mit einer Section-Banner-Zeile 1 + Leerzeile 2, nicht direkt mit der Kopfzeile, die `handleExcelFile` an Position 0 erwartet) — die Sheet-Reihenfolgen-Änderung dieses PRs bricht also keine vorher funktionierende Fähigkeit. Der bestehende Roundtrip-Pflichttest kann das strukturell nicht selbst erkennen (siehe C14-Fix im selben PR, `vsm-import-xlsx.test.ts`), weil er nur den NEUEN Export↔NEUEN Import-Pfad prüft, nie `vsm-editor.tsx`s eigenen alten, positionsbasierten Lesepfad. Kein Bug in diesem PR, aber eine vorbestehende, bislang undokumentierte Alt-Feature-Schwäche: der alte Editor-Excel-Import ist gegen JEDE `exportToXlsx`-erzeugte Datei (nicht nur Wertstrom-Exporte) strukturell blind. Ein Fix (`ejWb.worksheets[0]` durch eine namens-/inhaltsbasierte Suche ersetzen, analog zu `findWorksheetCaseInsensitive` im selben Fix-Runde-PR) wäre ein eigener, ungefragter Folge-Task.
- [ ] (Wertstrom, Excel-Roundtrip Fix-Runde PR #362, C7 — bewusst scope-begrenzt) `text-warning` (`--warning: #D48830` auf `--card: #FFFFFF`, ~2,85:1) unterschreitet WCAG AA (4,5:1) für Normaltext im Light-Theme — in DIESEM PR nur an den 2 Fundstellen in `vsm-import-xlsx-dialog.tsx` behoben (ersetzt durch das bereits AA-sichere, repo-weit etablierte `text-amber-700 dark:text-amber-400`-Muster, keine neue Farbe erfunden). Mindestens 14 weitere `.tsx`-Dateien im Repo verwenden `text-warning` für Fließtext noch unverändert (u. a. `components/wertstrom/simvsm-import-report-view.tsx`, `simvsm-import-dialog.tsx`, `components/intake/*`, `components/project/kpi-section.tsx`) — derselbe Kontrast-Fehler besteht dort vermutlich fort, wurde aber nicht systematisch neu geprüft. Ein sauberer Fix bräuchte entweder ein neues `--warning-text` (analog `--success-text`) mit repo-weiter Migration, oder eine Einzelprüfung jeder Fundstelle — beides ein eigener, ungefragter Folge-Task (nicht Teil des ursprünglich gemeldeten C7-Findings, das nur auf die 2 neuen Stellen dieses PRs zeigte).
- [ ] (Wertstrom P8.1, KAR-878/KAR-986, execution-prompt §15.5 "Measure Management" — P8-DoD-Lücke, bewusst nicht gefixt) §15.5 listet für eine Maßnahme auch root cause, target state, expected effect, actual effect und linked KPI — `workshop_actions` (`supabase/bootstrap/supabase-schema.sql`) hat dafür keine Spalten und bekommt in P8.1 bewusst KEINE (Architektur-Entscheidung "KEIN DDL"). Der neue "Maßnahme erstellen"-Dialog (`vsm-measure-dialog.tsx`) deckt nur die Felder ab, die workshop_actions bereits hat (Titel/Beschreibung/Owner/Fälligkeit/Aufwand+Nutzen/Status). Ein vollständiges §15.5-Datenmodell bräuchte eine Migration (5 neue Spalten, ggf. `linked KPI` als FK auf ein noch nicht existierendes KPI-Konzept) — eigener, ungefragter Folge-Task mit Migration+Review.
- [x] ~~(Wertstrom P8.1, KAR-878/KAR-986) `measureRefs` wird nach erfolgreicher Maßnahmen-Anlage über den normalen `updateNode`/isDirty-Pfad gesetzt, nicht sofort persistiert … (gleiche Risiko-Klasse wie jede andere unsaved Panel-Änderung in diesem Editor, kein neues Verhalten).~~ **Korrigiert (PR #363 Fix-Runde, K1):** die Einordnung war falsch — anders als jede reine Feld-Änderung hinterlässt eine verlorene Verknüpfung ein bereits committetes Fremdobjekt (`workshop_actions`-Zeile) plus ein echtes Duplikat-Risiko beim Retry, siehe verworfener Finding-Cluster im adversariellen Review. Gefixt: `onCreated` (vsm-editor.tsx `linkMeasureToNode`) löst sofort einen gezielten PUT nur für `nodes` aus, statt auf Speichern/Autosave zu warten; Dialog bleibt bei Fehler (409/Fehler/Node gelöscht) offen mit spezifischer Meldung (Maßnahme + Nr.) statt zu schließen; `beforeunload`-Guard bei `isDirty` ergänzt (Browser-Standard-Warnung, vorher 0 Treffer im Editor). Siehe CHANGELOG.md Fix-Runde-Eintrag.
- [x] ~~(Wertstrom P8.2-Kandidat, aus PR #363 Fix-Runde K1) "Bestehende Maßnahme verknüpfen"-UI — falls der Sofort-PUT (K1-Fix) trotzdem einmal fehlschlägt (409/Fehler/Node zwischenzeitlich gelöscht), bleibt die bereits angelegte `workshop_actions`-Zeile ein Orphan; der einzige Reparatur-Weg ist aktuell "Seite neu laden, im Workshop-Modul nachschauen" (die Fehlermeldung nennt Titel + Nr.), NICHT ein Dialog, der eine bestehende Maßnahme nachträglich mit einem Node verknüpfen kann. Bewusst NICHT gebaut in dieser Fix-Runde (K1-Entscheidung: Fix-Scope ist "Fenster verengen", nicht "jeden Restfall reparierbar machen") — eigener, ungefragter Folge-Task falls gewünscht.~~ **Gelöst in Wertstrom P8.2a (Baustein 4, KAR-878/KAR-986):** `vsm-link-measure-dialog.tsx` (`VsmLinkMeasureDialog`) — pickt eine bestehende `workshop_actions`-Zeile des Projekts und verknüpft sie über dieselbe `linkMeasureToNode` (K1 Sofort-PUT). Repariert damit auch RÜCKWIRKEND einen Orphan aus einem früheren fehlgeschlagenen Sofort-PUT (einfach die bereits angelegte Maßnahme nachträglich verknüpfen, statt "Seite neu laden + im Workshop-Modul nachschauen"). Die 5 §15.5-Felder (root cause/target state/expected effect/actual effect/linked KPI) bleiben weiterhin offen — Stufe-4-Migration mit Kais, siehe PRODUCT_SPEC.md.
- [ ] (Wertstrom P8.1, KAR-878/KAR-986) PDF-/SVG-/XLSX-/JSON-/Copilot-Export (`vsm-export-*.ts`, `lib/copilot-export`) surfacen `kaizenNote`/`measureRefs` nirgends — nur das Technische-JSON gibt sie über den vollständigen Node-Dump implizit mit aus, kein anderer Export zeigt Kaizen-Marker oder verlinkte Maßnahmen. Nicht angefragt für P8.1 (Brief-Scope war Editor-Panel + Management-Analyse); ein eigener, ungefragter Folge-Task falls gewünscht.

## KAR-628 Agenda-Feature Follow-Ups

- [x] ~~Host-Org-Abstraktion~~ — Option A umgesetzt (Env-Config `NEXT_PUBLIC_HOST_ORG_*`, `participant_type 'host'`), `check:portability` strict grün.
- [x] ~~Basis-Migration `supabase/migrations/supabase-migration-agenda-schema.sql` anwenden~~ — appliziert + verifiziert (5 Tabellen, RLS, Bucket, logo-Spalte).
- [ ] **Delta-Migration anwenden:** `supabase/migrations/supabase-migration-agenda-deltas.sql` — additive Spalten `agenda_item.color` + `agenda_participant.comment` (Round-2-Features #4/#9 brauchen sie). Erst dann persistieren Farben/Kommentare in Prod.
- [x] ~~#10 Entscheidung~~ — Kais: eigene Agenda je Sprache (Varianten). Umgesetzt: `loadProjectAgendas` + Variant-Switcher + `createLanguageVariantAction`.
- [ ] E2E/RLS-Tests nach Delta-Migration (Tenant-/Projekt-Isolation, Rechteprüfung).
- [ ] ZH-PDF: CJK-Font in jspdf einbetten oder ZH nur Excel/Preview (jspdf-Standardfont kann kein CJK).
- [ ] Supplier-Logo-Upload-UI (Spalte `supplier_master_data.logo_storage_key` + Bucket `supplier-logos` vorbereitet) — Stammdaten- vs. Per-Agenda-Upload.
- [ ] Voll-Audit-Trigger (`audit_log`) für Agenda-CRUD (aktuell created_by/updated_by + `agenda_export`-Trail).
- [ ] Component-/E2E-Tests für Wizard + DnD-Editor (jsdom/Playwright), tdd-guard:skip aufheben.

## KAR-522 Follow-Up (Architecture Audit)

- [ ] `react-hooks/exhaustive-deps` von `warn` auf `error` bumpen — 23 standing warnings vorher fixen (gesonderter Fix-Pass)
- [ ] Restliche P1-Items aus `architecture-audit/00-synthese.md` als KAR-Issues anlegen (10 Stueck)
- [ ] OWASP ASVS L2 Self-Assessment — Spreadsheet `docs/security/asvs-l2.md` (vor BMW-Pilot Pflicht)

## Entscheidungen offen

- Sollen Projekt-Tabs auf Mobile in der Bottom-Bar erscheinen oder als eigene Navigation?
- Berechtigungsmodell für Reporting-Seite — nur Admin+, oder auch Berater mit eingeschränkter Sicht?