CLAUDE.md

@@ -99,7 +99,7 @@ mitai-jinkendo/
 ### Was in v9c kommt: Subscription & Coupon Management System
 **Phase 1 (DB-Schema): ✅ DONE**
 **Phase 2 (Backend API): ✅ DONE**
-**Phase 3 (Frontend UI): 🔲 TODO**
+**Phase 3 (Frontend UI): ⚡ MOSTLY DONE** (Kern-Features komplett, Self-Registration offen)
 
 **Core Features (Backend):**
 - ✅ DB-Schema (11 neue Tabellen, Feature-Registry Pattern)
@@ -113,15 +113,17 @@ mitai-jinkendo/
 - ✅ Individuelle User-Restrictions (Admin kann Limits pro User setzen)
 - ✅ 7 neue Router, 30+ neue Endpoints (subscription, coupons, features, tiers, tier-limits, user-restrictions, access-grants)
 
-**Frontend TODO (Phase 3):**
+**Frontend (Phase 3) - Status:**
+- ✅ **AdminFeaturesPage** - Feature-Konfiguration (sortierung, reset_period, limits, visibility)
+- ✅ **AdminTiersPage** - Tier-Verwaltung (CRUD, pricing monthly/yearly)
+- ✅ **AdminTierLimitsPage** - Matrix-Editor (Tier x Feature, responsive mobile/desktop views)
+- ✅ **AdminCouponsPage** - Coupon-Manager (CRUD, 3 Typen, auto-generate codes, redemption history)
+- ✅ **AdminUserRestrictionsPage** - User-Override-System (effektive Werte, auto-remove redundant overrides)
+- ✅ **SubscriptionPage** - User Subscription-Info + Coupon-Einlösung (tier badge, limits, usage progress bars)
+- ✅ Alle Routes in App.jsx registriert
 - 🔲 Selbst-Registrierung mit E-Mail-Verifizierung (Pflicht)
-- 🔲 Trial-System UI (Dauer konfigurierbar, auto-start nach E-Mail-Verifikation)
-- 🔲 Admin Matrix-Editor (Tier x Feature Limits)
-- 🔲 Admin Coupon-Manager (CRUD, Redemption-Historie)
-- 🔲 Admin User-Restrictions UI
-- 🔲 User Subscription-Info Page
-- 🔲 User Coupon-Einlösung UI
-- 🔲 App-Settings Admin-Panel (globale Konfiguration)
+- 🔲 Trial-System UI (Countdown-Banner, auto-start nach E-Mail-Verifikation)
+- 🔲 App-Settings Admin-Panel (globale Konfiguration: trial_days, allow_registration, etc.)
 
 **E-Mail Templates (v9c):**
 - 🔲 Registrierung + E-Mail-Verifizierung
@@ -909,6 +911,39 @@ Dev:  dev-mitai-api, dev-mitai-ui
 **Workaround:** Email manuell via `/api/admin/profiles/{pid}/email` setzen.
 **Fix-TODO:** POST `/api/profiles` sollte Email als optionales Feld akzeptieren.
 
+### AdminUserRestrictionsPage – Effektive Werte anzeigen (v9c GELÖST)
+**Problem:** Ursprüngliches Design zeigte leere Felder wenn kein Override existierte.
+**Issues:**
+- User konnte nicht sehen welcher Wert aktuell gilt (Override vs Tier-Standard)
+- "unlimited" konnte nicht eingegeben/gespeichert werden (nur Platzhalter)
+- Redundante Overrides (Wert = Tier-Standard) wurden nicht verhindert
+- Tier-Limits verwendeten falschen Fallback (default_limit statt null)
+
+**Lösung (März 2026):**
+```javascript
+// getDisplayValue() zeigt effektiven Wert (Override ODER Tier-Limit)
+const restriction = restrictions.find(r => r.feature_id === featureId)
+if (restriction) return formatValue(restriction.limit_value)
+return formatValue(tierLimits[featureId]) // Tier-Standard als Fallback
+
+// formatValue() konvertiert NULL zu "unlimited" (statt leer)
+if (val === null) return 'unlimited'
+
+// handleChange() entfernt Override wenn Wert = Tier-Standard
+if (parsedValue === tierLimit) {
+  newChanges[featureId] = { action: 'remove' } // Redundanter Override
+}
+
+// Tier-Limits-Fallback wie TierLimitsPage
+limits[feature.id] = limitsMatrix.limits[key] ?? null // nicht default_limit!
+```
+
+**Ergebnis:**
+- ✅ User sieht immer den aktuellen effektiven Wert
+- ✅ "unlimited" kann getippt und gespeichert werden (grün gefärbt)
+- ✅ Redundante Overrides werden automatisch entfernt
+- ✅ Selfhosted-Tier zeigt korrekt "unlimited" statt "0"
+
 ### dayjs.week() – NIEMALS verwenden
 ```javascript
 // ❌ Falsch: