234f87d408
Bündelt die Neuentwicklung in AssigmentMonitorV2 (eigene Ports/DB), die Umstellung auf numerische Bewertungen, Meeting-Checklisten, KI-Tagging und die geplante Feedback-Kaskade — als Basis für Versionsverwaltung in Gitea. Co-authored-by: Cursor <cursoragent@cursor.com>
14 KiB
Plan: Feedback-Neukonzeption, KI-Kaskadierung & UX
Stand: 2026-08-06 · nur DEV (AssigmentMonitorV2)
Voraussetzung: Bewertungsskala 1–10 weitgehend umgesetzt (docs/SCALE_1_TO_10.md).
Dieses Dokument ist die Arbeitsliste. Pakete nacheinander abarbeiten; innerhalb eines Pakets Unterpunkte möglichst in der angegebenen Reihenfolge. Abhaken in diesem File oder in der Session-Todo-Liste.
Zielbild (festgezogen)
Assignment-Feedback (Gesamtauswertung pro Person)
| Ebene | Inhalt |
|---|---|
| Kategorie | Score 1–10 · Benefits · Concerns (Gesprächsbasis) |
| Dimension | Benefits · Concerns — 3 bis max. 5 Hauptpunkte (verdichtet) |
- PDF enthält beides (Kategorie + Dimension) — intern/Manager-Gespräch, spätere Anbindung Erfassungssystem.
- Keine Pflicht-Rubrik „Reifegrad pro Scorelevel 1–10“; Score-Vorschlag primär aus zeitgewichteten Meeting-Kategorie-Scores, KI darf ±1 mit Begründung feinjustieren.
- Achievements/Development Needs → fachlich Benefits/Concerns (UI-Sprache umstellen).
KI-Kaskade Feedback
Stufe A — 1 Call pro Kategorie (schmaler Kontext)
→ suggested Score, Benefits, Concerns (Kategorie)
Stufe B — 1 Call pro Dimension
Input: NUR Ergebnisse aus A (kein Rohprotokoll)
→ 3–5 Benefits + 3–5 Concerns (Dimension)
KI-Kaskade Tagging („Vorschläge analysieren“)
Nur ungetaggte Zeilen (bereits zugeordnete nie an KI)
→ Batches nach Zeilenanzahl UND Zeichenbudget
→ optional Hybrid: bei Monster-Batches Kriterien auf lokale Top-Kandidaten beschränken
→ Dimensions-Schnitt kein Standardweg
→ lokale Jaccard-Vorschläge + learnedPatternHints bleiben
Entscheidungen (Nachtrag 2026-08-06)
- Score: KI darf vorschlagen. Primärquelle = Meeting-Trend (wie bisherige Gewichtung). Keine 10-stufige Erwartungs-Rubrik als Voraussetzung; optional später globale Anker (z.B. 2/5/8/10), nicht jetzt.
- PDF: Kategorie-Benefits/Concerns mit ausgeben.
- Tagging-Batches: A (zeilen- + zeichenbasiert). B (Dimension) verworfen als Standard; Hybrid nur bei extrem großen Einträgen (Top-K Kriterien). C: getaggte Zeilen weiter ausschließen.
Paket 0 — Aufräumen Skala 1–10 (Rest aus SCALE Phase 2–4)
Bereits weitgehend erledigt; nur nachziehen, was noch hinkt.
| # | Aufgabe | Done |
|---|---|---|
| 0.1 | Farbbänder speichern/laden (getOrSeed/saveRatingColorBands Server) — Hell-/Dunkelgrün unterscheidbar |
☐ prüfen |
| 0.2 | Chips Detail/History/PDF/MD aus meetingCategoryRatings (+ Fallback) |
☐ prüfen |
| 0.3 | Dimension-Prompts per „Auf Standard (1–10) setzen“ nachziehen / manuell testen | ☐ |
| 0.4 | Kurz-Smoke: Speichern Skala → Meeting-Einschätzung → Farben greifen nach Reload | ☐ |
Exit: Skala und Farben verhalten sich in Config, Meeting und Feedback konsistent.
Paket 1 — Datenmodell Feedback (Benefits/Concerns)
| # | Aufgabe | Dateien (Orientierung) | Done |
|---|---|---|---|
| 1.1 | FeedbackCategoryText: benefits, concerns, suggestedBenefits, suggestedConcerns (+ Migration ALTER). Altes text/suggestedText entfernt (Dev: ggf. npm run db:reset oder Spalten bleiben ungenutzt in alter SQLite) |
types.ts, tableRegistry, UI/PDF |
☑ |
| 1.2 | Dimension: DB achievements/developmentNeeds behalten; UI/PDF-Labels Benefits/Concerns |
☑ | |
| 1.3 | CRUD unverändert (generisch); Parser + Feedback-Seite + PDF angepasst | ☑ | |
| 1.4 | npx tsc -b grün |
☑ |
Exit: Persistenz für Kategorie- und Dimension-Benefits/Concerns inkl. suggested*.
Paket 2 — Prompt-Engine Stufe A (pro Kategorie)
| # | Aufgabe | Done |
|---|---|---|
| 2.1 | Neues Template (AppSettings oder pro Dimension): Kategorie-Call — Platzhalter nur für eine Kategorie (Struktur, Kriterien-Scores/Notizen dieser Cat, Meeting-Cat-Scores/Trend, getaggte Zeilen dieser Cat) | ☑ |
| 2.2 | Antwortformat Marker z.B. SCORE:, BENEFITS:, CONCERNS: — Parser analog parseDimensionAiResponse |
☑ |
| 2.3 | Score-Vorschlag: berechneten Trend im Prompt vorgeben; KI nur bestätigen oder ±1 mit Begründung (nicht frei aus Protokoll erfinden) | ☑ |
| 2.4 | Sequenz: alle Kategorien eines Institutee (Fortschritt, Teilfehler, Retry pro Kategorie) | ☑ |
| 2.5 | Config-UI: Kategorie-Prompt editierbar (+ Reset), Platzhalter-Legende | ☑ |
Exit: „KI generieren“ füllt suggested* auf Kategorie-Ebene; Score-Badge aus Trend bleibt führend.
Paket 3 — Prompt-Engine Stufe B (Dimension verdichten)
| # | Aufgabe | Done |
|---|---|---|
| 3.1 | Dimension-Template umbauen: Input = Kategorie-Benefits/Concerns + Scores der Dimension; kein Rohprotokoll | ☑ |
| 3.2 | Output: genau 3–5 Benefits, 3–5 Concerns; Parser/Validierung (zu viele kürzen-Hinweis oder Prompt-Zwang) | ☑ |
| 3.3 | Orchestrierung: erst alle Cats der Dim (A), dann ein Call B; fehlende Cats = Retry A vor B | ☑ |
| 3.4 | Bestehende Dimension-Prompts in DB: Reset-Button / Sync auf neues Default-Template | ☑ |
Exit: Dimension-Texte sind Verdichtung, nicht Parallel-Erfindung aus dem Protokoll.
Paket 4 — Feedback-UI
| # | Aufgabe | Done |
|---|---|---|
| 4.1 | Pro Kategorie: ScorePicker + Trend/KI-Score-Vorschlag („Übernehmen“) + Benefits/Concerns (editierbar + suggested-Boxen) | ☐ |
| 4.2 | Pro Dimension: nur Benefits/Concerns (3–5), suggested übernehmen/verwerfen | ☐ |
| 4.3 | Alten Ein-Text-pro-Kategorie und Achievements/DevNeeds-Labels entfernen bzw. umbenennen | ☐ |
| 4.4 | „Trend in Text“ → sinnvoll auf Concerns oder Benefits mappen (Regel festlegen, z.B. Verschlechterung→Concern) | ☑ |
| 4.5 | Fortschrittsanzeige Generierung: Kategorie X/Y, dann Dimension Z | ☑ |
Exit: Direktgespräch möglich: Kategorie-Details + Dimensions-Hauptpunkte auf einer Seite.
Paket 5 — PDF & sonstige Exporte
| # | Aufgabe | Done |
|---|---|---|
| 5.1 | InstituteeFeedbackDocument / Assignment-Report: pro Kategorie Score + Benefits + Concerns; pro Dimension Benefits + Concerns |
☐ |
| 5.2 | Nur finale Felder, nie suggested* |
☐ |
| 5.3 | Markdown/JSON Assignment-Feedback falls vorhanden nachziehen | ☐ |
Exit: Internes PDF für Manager-Gespräch brauchbar.
Paket 6 — Tagging-Kaskade (Zeichen-Batches)
| # | Aufgabe | Done |
|---|---|---|
| 6.1 | Hilfsfunktion: offene Zeilen sammeln (unverändert: ohne bereits Getaggte, ohne Kundenzitate wie bisher) | ☐ |
| 6.2 | Batch-Builder: max. Zeilen und max. Zeichensumme (Konstanten in constants oder AI_CONFIG, konfigurierbar später) |
☐ |
| 6.3 | analyzeSuggestions: Schleife über Batches; Ergebnisse mergen; Fortschritt „Batch i/n“; Teilfehler retrybar |
☐ |
| 6.4 | Hybrid-Notnagel: wenn ein Batch trotz 1 Zeile zu groß (Struktur+Text), {{KRITERIEN_STRUKTUR}} auf Jaccard-Top-K der Batch-Zeilen beschränken |
☐ |
| 6.5 | MUSTER:-Block: nach allen Batches einmal zusammenführen/schreiben oder nur aus Batches mit Treffern — Regel dokumentieren |
☐ |
| 6.6 | Info-Zeile + Rohantwort weiter nutzbar (pro Batch oder letzte) | ☐ |
Exit: Lange Protokolle brechen nicht mehr am Einzelcall; getaggte Zeilen bleiben draußen.
Paket 7 — Robustheit KI-Client (gemeinsam)
Betrifft Feedback- und Tagging-Calls.
| # | Aufgabe | Done |
|---|---|---|
| 7.1 | Timeouts / Abbruch klar melden (nicht still) | ☐ |
| 7.2 | Retry mit Backoff für transient failures (einmalig) | ☐ |
| 7.3 | Grobe Prompt-Größen-Schätzung vor Call → Warnung oder Auto-Split | ☐ |
| 7.4 | Gleiche aiClient-Hilfen für Feedback und Tagging |
☐ |
Exit: Abbrüche sind erklärbar und oft automatisch reparierbar.
Paket UX — Professionelle Oberfläche (Capgemini-Tool, kein Marketing-Landing)
Bisher wirkt die App funktional, aber wie ein schneller Prototyp (graue Fläche, Emoji-Navigation, uneinheitliche Karten/Abstände). Ziel: ruhig, markenklar, gut lesbar im Direktgespräch und im Live-Meeting — nicht „bunte Dashboard-Show“.
Leitplanken
- Capgemini-Brand
#0070AD/ Tailwindbrandals Primärsignal; keine lila/Indie-Themes. - Bestehende Interaktionsmuster behalten (Tabs, ScorePicker, Tag-Picker) — visuell vereinheitlichen, nicht neu erfinden.
- Schreibfluss im Meeting schützen (keine zusätzlichen Overlays beim Tippen).
- Emojis in Nav/Buttons schrittweise durch klare Labels oder einfache Icons ersetzen (oder stark reduzieren).
- Typografie und Abstände einmal zentral (
index.css/ kleine UI-Primitives), nicht Seite für Seite wildwuchs.
| # | Aufgabe | Done |
|---|---|---|
| UX.1 | Design-Tokens: Schrift, Abstände, Radius, Schatten, Flächen (bg-app, surface, border-subtle) in index.css / @theme — App-Shell (App.tsx) darauf umstellen |
☐ |
| UX.2 | App-Chrome: Header (Titel/Kontext), Bottom-Nav ohne Emoji-Overload, aktiver Zustand klar, sichere Touch-Targets | ☐ |
| UX.3 | Dashboard / Assignment-Listen: einheitliche Zeilen/Kacheln, Status, Typografie-Hierarchie (Nummer, Kunde, Institutees) | ☐ |
| UX.4 | Meeting-Live-UX: Einschätzung + Protokoll dichter und ruhiger; ScorePicker/Chips konsistent; Fokus auf Tippen + schnelle Scores | ☐ |
| UX.5 | Feedback-Seite: nach Paket 4 — klare Hierarchie Dimension → Kategorie; Benefits/Concerns optisch getrennt; KI-Vorschläge als „Entwurf“, nicht als Lärm | ☐ |
| UX.6 | Config: Tabs und Formulare angleichen (Skala, KI-Prompts, Struktur) — gleiche Button-/Hinweis-Muster | ☐ |
| UX.7 | Leere Zustände & Fehler: kurze, professionelle Leer-/Fehlertexte statt stiller Lücken | ☐ |
| UX.8 | PDF-Feinschliff: Typo/Abstände an Capgemini-Report-Anmutung (ohne Corporate-Template-Zwang) | ☐ |
Timing: UX.1–UX.2 früh (nach Paket 0) als Fundament. UX.4 mit Meeting-Arbeit; UX.5 bewusst nach Paket 4 (sonst doppelte UI-Arbeit). UX.3/6/7 parallel zu funktionalen Paketen möglich. UX.8 nach Paket 5.
Exit: App wirkt wie ein internes Capgemini-Fachtool: einheitlich, ruhig, brandklar — ohne Feature-Regression.
Paket 8 — SCALE / Struktur Prio-2 und bekannte Offenheiten
Nicht blockierend für Pakete 1–7 / UX; einplanen wenn Kapazität.
| # | Aufgabe | Quelle | Done |
|---|---|---|---|
| 8.1 | Sichtbarkeit Dim/Cat pro Typ — vorgezogen nach Paket 1b | SCALE Phase 6 | → 1b |
| 8.2 | Notation-Schnellbuttons / mobile Hit-Areas (kann in UX.4 aufgehen) | SCALE Phase 5 | ☐ |
| 8.3 | Dexie/IndexedDB-Legacy entfernen | CLAUDE Offene Punkte L | ☐ |
| 8.4 | Server Seed-if-empty Assignment-Typen/Struktur | CLAUDE L | ☐ |
| 8.5 | Evaluation.tsx / FeedbackDraftPage auf neue Benefits/Concerns + Bänder prüfen oder Legacy deprecaten | ☐ | |
| 8.6 | Datenschutz: Hinweis Tagging+Feedback (externe API) vor Prod | CLAUDE | ☐ |
Empfohlene Abarbeitungsreihenfolge
0 (Smoke Skala)
→ 1 (Schema Benefits/Concerns) ← erledigt
→ 1b (Typ → sichtbare Struktur) ← VOR Feedback-KI: gleiche Teilmenge in Meeting + Feedback + Kaskade
→ 6 + 7 parallel möglich ← Tagging-Abbrüche lindern
→ 2 → 3 → 4 → 5 ← Feedback-Neukonzeption Ende-zu-Ende
→ 8 Rest nach Bedarf
→ UX später
Hinweis: Paket UX ist spezifiziert, aber zurückgestellt — erst Features fertig, dann Optik.
Warum 1b vor 2: Stufe A (ein Call pro Kategorie) und Feedback-UI müssen nur Kategorien/Dimensionen des Assignment-Typs sehen. Ohne kanonische Sichtbarkeit generiert die KI später Inhalte für ausgeblendete Strukturteile.
Paket 1b — Feedback-Struktur je Assignment-Typ (vorziehen aus 8.1)
Ziel: Ein Assignment-Typ blendet Dimensionen und/oder Kategorien aus → Meeting-Einschätzung, Tagging-Struktur und Assignment-Feedback arbeiten auf derselben Teilmenge.
| # | Aufgabe | Done |
|---|---|---|
| 1b.1 | Kanonischer Helper z.B. resolveVisibleStructure(allDims, allCats, allItems, criteriaIds) → { dimensions, categories, items } (Cats ohne Items und Dims ohne Cats entfallen) — baut auf filterVisibleFeedbackStructure auf |
☑ |
| 1b.2 | Überall verdrahten: MeetingView, Assessment, Feedback-Seite, Tagging-Prompt, PDF-Feedback-Teil, History/Detail wo nötig | ☑ |
| 1b.3 | Config Ass.-Typen: Auswahl auf Dimension- / Kategorie-Ebene (Checkboxen), persistiert weiter als criteriaIds (alle Items der gewählten Cats) — kein zweites Parallel-Feld nötig |
☑ |
| 1b.4 | Leere criteriaIds = alles sichtbar (unverändert); Smoke mit Typ der z.B. nur 1–2 Dimensionen hat |
☐ manuell |
Nicht nötig jetzt: separates dimensionIds[]/categoryIds[] in der DB, solange die UI Dim/Cat pflegt und auf criteriaIds mappt.
Exit: Feedback und Einschätzung zeigen für denselben Assignment-Typ dieselbe Struktur; KI-Kaskade kann darauf aufsetzen.
Empfohlene Abarbeitungsreihenfolge (Detail)
0 → 1 → 1b → (6+7 optional) → 2 → 3 → 4 → 5 → 8 → UX
Alternative, wenn Feedback-Calls zuerst stören: nach 1b sofort 2→3→4→5, Tagging 6→7 dazwischen wenn Abbrüche blockieren.
Nicht-Ziele (jetzt)
- Produktiv-Migration / Mapping alter Enum-Skala
- 10-stufige Score-Rubrik pro Kategorie
- Dimensions-Score als eigene Pflicht-Ebene
- Tagging-Batches standardmäßig nach Dimension schneiden
- Automatischer KI-Call beim Meeting-Öffnen
- Anbindung externes Erfassungssystem (PDF/Struktur vorbereiten reicht)
- Komplett-Redesign als Marketing-Landing / Dark Mode / Illustration-Heavy UI
Abnahmekriterien (Gesamt)
- Feedback-Seite zeigt Kategorie-Score + Benefits/Concerns und Dimensions-Hauptpunkte (3–5).
- Generierung läuft kaskadiert (Cat → Dim), Teilfehler retrybar, Prompt ohne wiederholtes Vollprotokoll in Stufe B.
- PDF enthält Kategorie- und Dimension-Benefits/Concerns (final).
- „Vorschläge analysieren“ arbeitet in zeichenbewussten Batches; bereits getaggte Zeilen gehen nicht an die KI.
- Score-Vorschlag bleibt an Meeting-Trend gekoppelt; KI erfindet keinen Score aus dem Nichts.
- Oberfläche wirkt professionell und einheitlich (Shell, Typo, Abstände, Meeting + Feedback).
npx tsc -bfehlerfrei; manuelle Smoke-Tests Meeting + Feedback + PDF.
Nächster Schritt
Beim Start der Umsetzung: Paket 0 kurz verifizieren, optional UX.1–UX.2 für den ersten visuellen Sprung, dann entscheiden ob zuerst Paket 6 (Tagging) oder Paket 1+2 (Feedback-Schema/KI).