# Konzept: Bewertungsskala 1–10 (AssignmentMonitorV2)

Stand: 2026-08-06 · nur DEV (`AssigmentMonitorV2`), Produktiv unberührt.

## Festgezogene Entscheidungen

| # | Entscheidung |
|---|---|
| Skala | **1–10**, ganzzahlig; `null` = nicht gesetzt (kein N/A-String mehr) |
| Primäre Ebene | **Kategorie** — Meeting-Bewertung und Assignment-Feedback setzen den Score hier |
| Kriterien | Primär **Beobachtungen** (Tags, Notizen, Gewichtung); nicht die Pflicht-Bewertungsebene |
| Warum Kategorie direkt? | Nicht alle Kriterien sind in jedem Meeting beobachtbar → Score darf **nicht** nur aus Kriterien-Ø abgeleitet werden müssen |
| Notation | Führende Zahl `1`–`10` am Zeilenanfang; **keine** `+` / `!` / `(+)` / `(!)` mehr; `>` Zitat und `[…]` Abschnitte bleiben |
| Farben | 4 Bänder, **konfigurierbar** unter Config (Defaults unten) |
| Labels | Nur Zahlen, keine Ankertexte |
| Altdaten | Keine Migration; frische Dev-DB (`npm run db:reset` bei Bedarf) |
| Struktur | Noch nicht angelegt — parallel in Config pflegbar, kein Blocker für Skalen-Umbau |
| Typ-Strukturen | Prio 2 (später) |
| Schnelle Zuordnung | `lineTags` / Tag-Picker / Vorschläge bleiben |

### Default-Farbbänder

Überlappung an der 5 in der Erstidee bereinigt:

| Score | Farbe |
|---|---|
| 1–2 | rot |
| 3–5 | orange |
| 6–8 | hellgrün |
| 9–10 | dunkelgrün |

Speicherung in `appSettings.ratingColorBands` (JSON), editierbar in einem neuen Config-Bereich „Skala / Farben“.

---

## Zielmodell (Daten)

```text
Beobachtung (Kriterium)
  lineTags / generalNoteTags / Assessment.note
  optionale Notations-Zahl auf der Zeile → Vorschlag / Detail

Meeting-Bewertung (Pflicht-Skala)
  NEU bzw. klar: Score 1–10 pro Kategorie × Institutee × Meeting
  direkt setzbar, unabhängig davon ob alle Kriterien getaggt sind

Assignment-Feedback
  FeedbackCategoryRating.rating → 1–10
  Vorschlag aus zeitgewichteten Meeting-Kategorie-Scores

Checkliste
  ChecklistResponse.rating → 1–10 (gleiche Skala/Farben)
```

### Speicherung Meeting-Kategorie-Score

Neue Tabelle `meetingCategoryRatings`:

- `meetingInstanceId`, `instituteeId`, `categoryId`, `score` (INTEGER nullable 1–10), optional `note`

Bestehende `ConversationSkillScore` (Schnellscore am Protokoll-Eintrag) ebenfalls auf 1–10 umstellen — bleibt optionaler Feinschliff während des Tippens, ersetzt aber nicht die Meeting-Gesamtbewertung pro Kategorie.

`Assessment.score` (pro Kriterium): optional `number | null` für Detail/KI; UI der Gesamtbewertung fokussiert auf **Kategorien**. Kriterien darunter zeigen Beobachtungen + optionalen Detail-Score.

---

## Umsetzungsphasen

### Phase 1 — Skalen-Kern ✅ (2026-08-06)
- Types: `RatingScore` 1–10, `null` = unset; `meetingCategoryRatings`; `ratingColorBands`
- `constants.ts`: Bänder, `resolveScoreStyle`, `ScorePicker`
- Config-Tab „Skala“
- `ratingTrend` / Notation (führende Zahl) / Meeting-/Feedback-/Export-UI umgestellt
- Hard-Delete räumt `meetingCategoryRatings` + `checklistResponses` auf

### Phase 2 — Meeting-UI Feinschliff
- Notation-Schnellbuttons weiter verfeinern; Farbbänder live aus Config laden (nicht nur Defaults)
- Detail/History-Chips primär aus `meetingCategoryRatings`

### Phase 3 — Feedback & Auswertung
- Trend/Vorschlag konsequent aus Meeting-Kategorie-Scores
- **Neukonzeption Benefits/Concerns + KI-Kaskade:** siehe `docs/FEEDBACK_CASCADE_PLAN.md`

### Phase 4 — Export & KI
- Persistierte Dimension-Prompts auf neue Skalen-Sprache zurücksetzen/syncen
- Kategorie-Benefits/Concerns im PDF (Teil von `FEEDBACK_CASCADE_PLAN.md` Paket 5)

### Phase 5 — UX-Feinschliff
- Slider/Stepper, mobile Hit-Areas; Schreibfluss schützen

### Phase 6 (Prio 2) — Struktur je Assignment-Typ
- Sichtbarkeit Dimension/Kategorie pro Typ — **umgesetzt als Paket 1b** (`resolveVisibleStructure`, Config → Ass.-Typen → Struktur)

---

## Nicht-Ziele (jetzt)

- Produktiv-Migration / Mapping alter Enum-Werte
- Ankertexte auf der Skala
- Getrennte Taxonomien pro Assignment-Typ (erst Prio 2)