20-02-2026

2026-02-20 17:57:50 +01:00 · 2026-02-20 17:57:50 +01:00 · 4d6b4930b2
commit 4d6b4930b2
parent 854ce02bf6
128 changed files with 18247 additions and 2093 deletions
--- a/dev/12-01-2026/entwicklungsplan.md
+++ b/dev/12-01-2026/entwicklungsplan.md
@ -0,0 +1,983 @@
+# Entwicklungsplan: B2In / Local for Local Marktplatz-Ökosystem
+
+**Erstellt:** 12.02.2026
+**Letzte Aktualisierung:** 12.02.2026
+**Basis:** konzeption.md (Version 1.1)
+**Status:** Phase 1 ✅, Phase 2 ✅, Phase 2.5 Produkt-Bearbeitung ✅, Phase 2.6 Refactoring & UX ✅, Phase 2.7 Admin-Produktverwaltung & Freigabe ✅, Phase 3 Kern ✅
+**Docker** Projekt läuft in Docker, root /var/www/html nutze php artisan ... nicht vendor/bin/sail artisan ...
+---
+
+## 0. Umsetzungsprotokoll
+
+### Phase 2.7: Admin-Produktverwaltung, Freigabe-Workflow & Statusaktionen – ABGESCHLOSSEN (13.02.2026)
+
+Vollstaendige Admin-Produktverwaltung mit tabellarischer Uebersicht, Filtern, Freigabe-Workflow mit Ablehnungsgrund, sowie Archivieren/Verkauft-Aktionen fuer Haendler und Admin.
+
+**Produkt archivieren / als Verkauft markieren**
+- Neue `archiveProduct()` und `markAsSold()` Methoden in `form-standard.blade.php`, `form-teaser.blade.php` und `products/index.blade.php`
+- Edit-Formulare: Buttons "Als verkauft markieren" und "Archivieren" links neben Speichern-Button (nur im Edit-Modus)
+- Produktliste: Dropdown-Menue (3-Punkte-Menue) je Produkt mit "Als verkauft" und "Archivieren" Optionen
+- `wire:confirm` Dialoge fuer Sicherheitsabfrage
+- Activity-Log-Eintraege (action: `archived` / `sold`) werden automatisch erstellt
+- Produkte im Status Archived/Sold zeigen kein Dropdown mehr
+
+**Erstellungsdatum in Produktliste**
+- Neue Spalte "Erstellt" in `products/index.blade.php` (Format: dd.mm.YYYY)
+- Sowohl fuer Haendler als auch Admin sichtbar
+
+**Admin-Produktuebersicht (komplett neu)**
+- `admin/products/index.blade.php` komplett umgebaut: von Card-/Tab-Layout zu tabellarischer Uebersicht
+- Statistik-Karten: Gesamt, Zur Freigabe, In Korrektur, Freigegeben (klickbar als Schnellfilter)
+- Filter: Suche (Name, Artikelnummer), Status (alle ProductStatus-Werte), Produkttyp, Haendler, Kategorie
+- Tabelle: Produkt (mit Bild), Haendler, Kategorie, Status, Kuration (Freigabe-Buttons), Erstellt, Aktionen
+- Admin kann alle Produkte bearbeiten – Edit-Link fuehrt zum gleichen Formular wie fuer Haendler
+- Suche durchsucht auch `b2in_article_number` und `partner_product_number`
+
+**Freigabe-Workflow mit Ablehnungsgrund**
+- **Freigeben:** Direkt-Button in Kuration-Spalte (Pending → Active + is_curated)
+- **Korrektur:** Inline-Formular (orange) mit Pflicht-Textfeld → Status `Correction`, `curation_notes` gespeichert
+- **Ablehnung (NEU):** Inline-Formular (rot) mit Pflicht-Textfeld → Status `Archived`, Ablehnungsgrund in `curation_notes` gespeichert
+- Activity-Log-Eintrag bei allen drei Aktionen (mit `note` bei Korrektur/Ablehnung)
+- `Flux::toast()` Benachrichtigungen statt Flash-Messages
+
+**Kuration-Hinweis beim Haendler**
+- Standard- und Teaser-Edit-Formulare zeigen prominenten Callout wenn `curation_notes` vorhanden:
+  - Korrektur (Status `correction`): Gelbes Warning-Callout "Korrektur erforderlich"
+  - Ablehnung (Status `archived`): Rotes Danger-Callout "Produkt abgelehnt"
+- Angezeigt oberhalb des Formulars, immer sichtbar
+
+**Admin Archiv/Verkauft in Admin-Uebersicht**
+- Dropdown-Menue analog zur Haendler-Produktliste
+- Admin kann alle Produkte archivieren oder als verkauft markieren
+
+**Erstellte/geaenderte Dateien (5):**
+
+| Kategorie | Dateien | Details |
+|-----------|---------|---------|
+| **Volt** (3) | `form-standard.blade.php`, `form-teaser.blade.php`, `products/index.blade.php` | Archive/Sold-Methoden, Kuration-Callout, Erstellungsdatum, Dropdown-Aktionen |
+| **Admin-Volt** (1) | `admin/products/index.blade.php` | Komplett umgebaut: Tabelle, Filter, Statistiken, Rejection mit Textfeld |
+| **Tests** (1) | `ProductCurationTest.php`, `ProductEditTest.php` | Aktualisiert + erweitert |
+
+**Neue/aktualisierte Tests (25):**
+- ProductCurationTest: 23 Tests (komplett ueberarbeitet fuer neues Tabellen-Layout, Rejection mit Pflicht-Textfeld, Archive/Sold, Filter, Kuration-Notes-Anzeige)
+- ProductEditTest: +2 Tests (archiveProduct, markAsSold aus Edit)
+
+**Tests gesamt: 194 Produkt-Tests, alle bestanden ✅ (533 Assertions)**
+
+---
+
+### Phase 2.6: Refactoring, UX-Verbesserungen & Teaser-Erweiterung – ABGESCHLOSSEN (13.02.2026)
+
+Umfassende Qualitaetsverbesserung der Produkt-Formulare: Code-Redundanzen eliminiert, UX-Workflow optimiert, Bildsortierung implementiert, Teaser-Produkte mit Produktnummern und korrektem Freigabe-Workflow ausgestattet.
+
+**Refactoring: Create + Edit zu einem Formular zusammengefuehrt**
+- `create.blade.php` + `edit.blade.php` → `form-standard.blade.php` (Standard-Produkte)
+- `create-teaser.blade.php` + `edit-teaser.blade.php` → `form-teaser.blade.php` (Teaser-Produkte)
+- Steuerung ueber `$isEditing`-Flag in `mount()`: `?Product $product = null`
+- Separate `saveNew()` und `saveExisting()` Methoden
+- Alte Einzeldateien geloescht
+
+**UX: Save-Verhalten bei Bearbeitung**
+- Bei Edit: Seite bleibt offen statt Redirect zur Produktliste
+- Flux Toast-Notification ("Produkt wurde gespeichert" / "zur Freigabe eingereicht")
+- Bei Standard-Produkten: aktiver Tab bleibt erhalten (kein Page-Reload)
+- `<flux:toast />` global im Sidebar-Layout ergaenzt
+- Bei Create: weiterhin Redirect zur Produktliste mit Flash-Message
+
+**Bildsortierung per Drag & Drop**
+- Vorhandene Bilder per HTML5 Drag & Drop umsortierbar (Alpine.js, keine externe Dependency)
+- Erstes Bild = Standardbild, visuell markiert (blaues "Standard"-Badge + blauer Ring)
+- `updateMediaOrder(array $orderedIds)` Methode speichert Reihenfolge in `order_column`
+- `existingMedia` wird immer nach `order_column` sortiert geladen
+- Drag-Feedback: halbtransparent, blauer Ring am Ziel, Grab-Cursor, Sortier-Icon bei Hover
+
+**Vorschaubild in Produktliste**
+- `products/index.blade.php`: Erstes Bild (nach `order_column`) als 40x40px Thumbnail vor dem Produktnamen
+- Platzhalter-Icon (Foto-Symbol) wenn kein Bild vorhanden
+
+**Teaser-Produkte: Produktnummern & Status-Fix**
+- `partnerProductNumber` hinzugefuegt: wird bei Create automatisch generiert (z.B. P003-0001), bei Edit pre-filled
+- `b2inArticleNumber` wird beim Speichern automatisch erzeugt (z.B. B2IN-000001)
+- Eigene "Produktnummern"-Karte im Formular (B2in-Badge + Partner-Nummer-Feld)
+- **Bug-Fix:** Status "aktiv" im UI setzte Status direkt auf Active statt Pending. Jetzt korrekt: UI "aktiv" → DB `pending` (zur Freigabe)
+- UI-Text vereinheitlicht: immer "Zur Freigabe einreichen" (nicht mehr "Aktiv – direkt veröffentlichen")
+- Freigabe-Workflow-Hinweis erscheint bei Create und Edit
+
+**Routing-Aenderung:**
+```
+products/create/standard  → products.form-standard (products.create.standard)
+products/create/teaser    → products.form-teaser   (products.create.teaser)
+products/{product}/edit-standard → products.form-standard (products.edit.standard)
+products/{product}/edit-teaser   → products.form-teaser   (products.edit.teaser)
+```
+
+**Erstellte/geaenderte Dateien (8):**
+
+| Kategorie | Dateien | Details |
+|-----------|---------|---------|
+| **Volt** (2) | `form-standard.blade.php`, `form-teaser.blade.php` | Merged Create+Edit, Toast, Bildsortierung, Produktnummern |
+| **Views** (2) | `index.blade.php`, `sidebar.blade.php` | Vorschaubild, `<flux:toast />` |
+| **Routes** (1) | `routes/admin.php` | Neue Routennamen (.standard/.teaser) |
+| **Tests** (4) | `StandardProductCreateTest`, `ProductEditTest`, `TeaserProductCreateTest`, `TeaserProductEditTest` | Komponentennamen aktualisiert, 13 neue Tests |
+
+**Geloeschte Dateien:** `create.blade.php`, `edit.blade.php`, `create-teaser.blade.php`, `edit-teaser.blade.php`
+
+**Neue Tests (13):** Bildsortierung (5), Teaser-Status pending/draft (2), Teaser B2in-Artikelnummer (1), Teaser Partnernummer create+edit (3), Teaser Partnernummer pre-fill (2)
+
+**Tests gesamt: 109 Produkt-Tests, alle bestanden ✅**
+
+---
+
+### Phase 2.5: Produkt-Bearbeitung (Standard + Teaser) – ABGESCHLOSSEN (13.02.2026)
+
+Beide Produkttypen koennen jetzt vollstaendig bearbeitet werden. Standard-Produkte (SmartOrder) nutzen das 8-Tab-Formular, Teaser-Produkte (LocalStock) ein vereinfachtes Einseiten-Formular. Die Produkt-Liste leitet automatisch zur richtigen Edit-Seite weiter.
+
+Erstellte/geaenderte Dateien (4):
+- Volt: resources/views/livewire/products/edit-teaser.blade.php (neu) - Teaser-Edit mit Pre-Fill, Status-Handling, Media-Verwaltung, Activity-Log
+- Routes: routes/admin.php - products.edit.teaser Route hinzugefuegt
+- Views: resources/views/livewire/products/index.blade.php - Edit-Link basierend auf product_type
+- Tests: tests/Feature/TeaserProductEditTest.php (neu) - 24 Tests
+
+Infrastruktur-Fix: Route-Cache und Test-DB-Migration bereinigt.
+
+Tests gesamt: 24 Tests (TeaserProductEditTest) + 22 Tests (ProductEditTest), alle bestanden.
+Produkt-bezogene Tests gesamt: 133 Tests, alle bestanden.
+
+---
+
+### Phase 2.3b: CSV-Felder Erweiterung (Moebeldatenliste) – ✅ ABGESCHLOSSEN (13.02.2026)
+
+**Änderung:** Alle fehlenden Felder aus `Moebeldatenliste Stand 4.11.2025.csv` (70 Felder, 13 Sektionen) wurden als DB-Spalten und Formularfelder ergänzt. Von ~30 existierenden Feldern auf ~70 erweitert. Neue Tabelle `product_wood_origins` für EUDR-Compliance. Formular von 5 auf 8 Tabs umgebaut.
+
+**Erstellte/geänderte Dateien (13):**
+
+| Kategorie | Dateien | Details |
+|-----------|---------|---------|
+| **Migrationen** (4) | `add_csv_fields_to_products_table`, `add_csv_fields_to_product_logistics_table`, `add_currency_to_product_variants_table`, `create_product_wood_origins_table` | +21 Spalten products, +4 Spalten product_logistics, +1 Spalte product_variants, neue Tabelle product_wood_origins |
+| **Models** (4) | `Product.php`, `ProductLogistics.php`, `ProductVariant.php`, `ProductWoodOrigin.php` (neu) | Fillable, Casts, woodOrigins() Relationship |
+| **Factories** (1) | `ProductWoodOriginFactory.php` (neu) | Factory mit Holzarten, Ländern, EUDR-Daten |
+| **Volt-Komponenten** (1) | `products/create.blade.php` | 8-Tab-Layout, ~25 neue Properties, Wood-Origins-Repeater, erweiterte Validierung + Save-Logik |
+| **Tests** (2) | `StandardProductCreateTest.php` (+12 Tests), `Models/ProductWoodOriginTest.php` (4 Tests, neu) | Material, Logistik, Services, Nachhaltigkeit, EUDR, Scoring, Währung, Validierung |
+
+**Neue DB-Spalten (26):** products: country_of_origin, main_material, surface_material, cover_material, color_finish, certificates(JSON), assembly_time_min, load_capacity_kg, delivery_type, assembly_service, service_radius_km, warranty_months, production_time_days, visible_from, visible_until, co2_footprint_kg, recycling_percentage, is_regional_production, storage_volume_liters, assembly_effort_score, design_score. product_logistics: packaging_type, packaging_recyclable_percent, is_palletizable, hs_code. product_variants: currency.
+
+**Neue Tabelle:** `product_wood_origins` (1:n von products) – EUDR-Compliance mit Holzart, Herkunftsland, Region, Erntejahr, Forstbetrieb, Zertifikat, EUDR-ID
+
+**Pint-Formatierung:** ✅ (keine Korrekturen nötig)
+
+**Tests gesamt: 33 Tests (StandardProductCreateTest) + 4 Tests (ProductWoodOriginTest), alle bestanden ✅**
+
+---
+
+### Phase 2.3: Standard-Produkt Erstellung (Maske 2) – ✅ ABGESCHLOSSEN (13.02.2026)
+
+**Änderung:** Das Standard-Produkt-Formular (`create.blade.php`) wurde komplett neu geschrieben – von einer nicht-funktionalen Dummy-Vorlage zu einem voll funktionsfähigen class-based Volt Component mit 5 Tabs.
+
+**Erstellte/geänderte Dateien (3):**
+
+| Kategorie | Dateien | Details |
+|-----------|---------|---------|
+| **Volt-Komponenten** (1) | `resources/views/livewire/products/create.blade.php` | Komplett neugeschrieben: 5-Tab-Layout (Basis, Bilder, Physisch, Kommerziell, Zuordnung), erstellt Product + ProductVariant + ProductLogistics + Media, inline Validierung, Preise EUR→Cents |
+| **Migrationen** (1) | `database/migrations/2026_02_13_..._make_tax_rate_id_nullable_on_product_variants_table.php` | `tax_rate_id` nullable gemacht (war NOT NULL ohne Default, tax_rates Tabelle leer) |
+| **Tests** (1) | `tests/Feature/StandardProductCreateTest.php` | 17 neue Tests: Zugriff (3), Happy Path (2), Physisch+Logistik (1), Kommerziell (1), SEO (1), Validierung (8), Preistypen (1) |
+
+**Pint-Formatierung:** ✅ (1 Fix: unused import in StandardProductCreateTest)
+
+**Tests gesamt: 17 Tests (StandardProductCreateTest), alle bestanden ✅**
+
+---
+
+### Phase 2 Ergänzung: Beide Rollen → Beide Produkttypen (13.02.2026)
+
+**Änderung:** Sowohl Händler (Retailer) als auch Hersteller (Manufacturer) können nun BEIDE Produkttypen anlegen (Teaser + Standard). Vorher war die Erstellmaske rollenbasiert auf einen Typ beschränkt.
+
+**Erstellte/geänderte Dateien (3):**
+
+| Kategorie | Dateien | Details |
+|-----------|---------|---------|
+| **Volt-Komponenten** (1) | `resources/views/livewire/products/index.blade.php` | Zwei Buttons ("Neues Teaser-Produkt" + "Neues Standard-Produkt"), neuer `productTypeFilter` State + Query-Filter, Produkttyp-Dropdown im Filterbereich |
+| **Tests** (2) | `tests/Feature/LocalFeedTest.php`, `tests/Feature/TeaserProductCreateTest.php` | +6 neue Tests: Produkttyp-Filter (3), Zwei-Button-Anzeige (3), Manufacturer Teaser-Zugriff (1), Manufacturer Teaser-Erstellung (1). Fix: `mainImage` → `mainImages` in bestehenden Tests |
+
+**Pint-Formatierung:** ✅ (keine Korrekturen nötig)
+
+**Tests gesamt: 21 Tests (LocalFeedTest + TeaserProductCreateTest), alle bestanden ✅**
+
+---
+
+### Phase 3: Kunden-Frontend & Local Feed – ✅ KERN ABGESCHLOSSEN (12.02.2026)
+
+**Erstellte/geänderte Dateien (8):**
+
+| Kategorie | Dateien | Details |
+|-----------|---------|---------|
+| **Actions** (1) | `app/Actions/Fortify/CreateNewUser.php` | `origin` aus `config('app.theme')` via `UserOrigin::tryFrom()`, `hub_id` aus Input |
+| **Models** (1) | `app/Models/Partner.php` | `PartnerType` Cast hinzugefügt (`type` Feld) |
+| **Volt-Komponenten** (2) | `resources/views/livewire/products/index.blade.php`, `resources/views/livewire/partner/profile.blade.php` | products/index: echte DB-Queries, Rollen-basierte Filterung (Admin/Customer/Partner). partner/profile: neue öffentliche Profilseite |
+| **Routes** (1) | `routes/admin.php` | `partner.profile` Route hinzugefügt |
+| **Tests** (3) | `CreateNewUserOriginTest`, `LocalFeedTest`, `PartnerProfilePageTest` | **17 Tests – alle bestanden** |
+
+**Wichtige Korrekturen (12.02.2026):**
+- `products` Tabelle hat keine `sku` Spalte – aus Suche und Tabellenansicht entfernt
+- Partner `type` war nicht auf `PartnerType` Enum gecastet – `PartnerType::class` Cast zu `Partner.php` hinzugefügt
+- `Volt::test()` wirft `ModelNotFoundException` direkt (kein HTTP 404) – 404-Tests nutzen `toThrow()`
+
+**Pint-Formatierung:** ✅ (5 Dateien: Partner.php, CreateNewUser.php, 3 Test-Dateien)
+
+**Tests Phase 3 gesamt: 17 Tests, alle bestanden ✅**
+
+---
+
+### Phase 2: Händler-Profil & Produkt-Management – ✅ KERN ABGESCHLOSSEN (12.02.2026)
+
+**Erstellte/geänderte Dateien (11):**
+
+| Kategorie | Dateien | Details |
+|-----------|---------|---------|
+| **Policies** (2) | `app/Policies/PartnerPolicy.php`, `ProductPolicy.php` | PartnerPolicy: viewAny/view/create/update/delete/curateProducts. ProductPolicy: viewAny/view/create/update/delete/curate |
+| **Volt-Komponenten** (4) | `admin/partners/index.blade.php`, `admin/partners/edit.blade.php`, `products/create-teaser.blade.php`, `admin/products/index.blade.php` | Partner-Übersicht, Profil-Edit (Story+Öffnungszeiten), Teaser-Erstellen (Typ A, Preislogik via Enum), Kuration-Queue |
+| **Routes** (1) | `routes/admin.php` | 4 neue Routen: `admin.partners.index`, `admin.partners.edit`, `products.create.teaser`, `admin.products.index` |
+| **Seeders** (1) | `database/seeders/RoleSeeder.php` | `curate products` Permission hinzugefügt |
+| **Tests** (5) | `PartnerPolicyTest`, `ProductPolicyTest`, `PartnerProfileUpdateTest`, `TeaserProductCreateTest`, `ProductCurationTest` | **48 Tests – alle bestanden** |
+
+**Enums erweitert (12.02.2026):**
+- `app/Enums/ProductType.php`: `requiresTicket(): bool`, `allowedPriceTypes(): array`
+- `tests/Unit/Enums/ProductTypeTest.php`: 4 neue Tests für Typ A/B Geschäftsregeln
+
+**Pint-Formatierung:** ✅ (keine Style-Korrekturen nötig)
+
+**Wichtige Erkenntnisse:**
+- Volt `actingAs()` ist `void` – für Tests immer `$this->actingAs($user)` VOR `Volt::test()` aufrufen
+- Für HTTP-Tests mit `partner.setup` Middleware: `Partner::factory()->setupCompleted()->create()` verwenden
+- `Storage::fake('public')` + `UploadedFile::fake()->image()` für File-Upload-Tests
+
+---
+
+### Phase 1: DB & Core-Vervollständigung – ✅ ABGESCHLOSSEN (12.02.2026)
+
+**Erstellte Dateien (29 Dateien):**
+
+| Kategorie | Dateien | Details |
+|-----------|---------|---------|
+| **Enums** (6) | `app/Enums/ProductType.php`, `ProductStatus.php`, `PriceType.php`, `PartnerType.php`, `UserOrigin.php`, `CurationStatus.php` | Alle mit `label()`, Status-Enums zusätzlich mit `color()`, UserOrigin mit `tonality()` |
+| **Neue Models** (4) | `app/Models/Product.php`, `Media.php`, `Setting.php`, `ProductLogistics.php` | Product: 6 Relationships, 6 Scopes. Media: Polymorphe Beziehung. Setting: Key-Value mit getValue/setValue Helpers |
+| **Aktualisierte Models** (11) | `Attribute`, `AttributeValue`, `Category`, `Collection`, `Tag`, `ProductVariant`, `ShippingClass`, `TaxRate`, `Hub`, `Partner`, `User` | Alle Sparse Models mit Fillable, Casts, Relationships ergänzt. Partner: +products(), +media(). User: +hub(), +origin Cast |
+| **Migrationen** (4) | `2026_02_12_000001` bis `000004` | Users (+origin, +hub_id), Products (+product_type, +is_curated, +hub_id, +price_type, +is_available, +curated_at, +curated_by), Partners (+story_text, +opening_hours, +specialties, +founded_year), Settings-Tabelle |
+| **Factories** (5) | `ProductFactory`, `MediaFactory`, `PartnerFactory`, `HubFactory`, `BrandFactory` | Alle mit sinnvollen States (localStock, smartOrder, active, retailer, manufacturer, etc.) |
+| **Seeders** (1) | `SettingsSeeder` | 6 Default-Settings: Ticket-Gültigkeit, Beleg-Deadline, Ticket-Limits, Provisions-Defaults |
+| **Config** (1) | `config/domains.php` | +local4local Domain (local4local.test / local4local.online) |
+| **Tests** (7 Dateien) | 3× Unit (Enums), 4× Feature (Product, Setting, User, Partner) | **47 Tests, 84 Assertions – alle bestanden** |
+
+**Migrationen auf Produktions-DB ausgeführt:** ✅
+**Settings-Seeder ausgeführt:** ✅ (6 Settings angelegt)
+**Pint-Formatierung:** ✅ (7 Style-Issues automatisch korrigiert)
+
+**Vorbestehende Test-Failures – BEHOBEN (12.02.2026):**
+Alle 16 vorbestehenden Fehler plus 15 weitere Fehler (31 insgesamt) wurden systematisch behoben. Die gesamte Test-Suite besteht jetzt mit **139 Tests, 269 Assertions – alle bestanden** ✅
+
+Behobene Probleme:
+- `phpunit.xml`: `BASIC_AUTH_ENABLED=false` hinzugefügt (BasicAuth-Middleware blockierte alle HTTP-Tests)
+- `admin/partners/index.blade.php`: Flux UI v2 Shorthand `<flux:columns>` → `<flux:table.columns>` korrigiert
+- `config/livewire.php`: `component_layout` Key hinzugefügt (Livewire 4 Layout-Resolution)
+- Auth-Tests: Portal-Domain (`portal.b2in.test`) für alle HTTP-Requests
+- `RegistrationTest`: Komplett neu geschrieben für code-basierte Registrierung über `/reg/{role}`
+- `PasswordResetTest`: `CustomResetPasswordNotification` statt Standard-`ResetPassword`
+- `EmailVerificationTest`: Redirect zu `partner.setup.wizard` statt `dashboard`
+- `ProfileUpdateTest`: SoftDeletes-Assertion (`->trashed()`) und Layout-Redirect
+- `DashboardTest`: `RefreshDatabase` Trait hinzugefügt
+- `ProductCurationTest`, `PartnerProfileUpdateTest`, `TeaserProductCreateTest`: `actingAs()` Chaining korrigiert (Volt `actingAs()` ist `void`)
+- `TeaserProductCreateTest`: `mainImage` Upload, `setupCompleted()` Factory-State, `CategoryFactory` erstellt
+- `ProductCurationTest`: Authorization-Test angepasst (Component authorize in `with()`)
+- `Category` Model: `HasFactory` Trait hinzugefügt
+
+---
+
+## 1. Validierung: IST-Zustand vs. Konzeption
+
+### ✅ Bereits implementiert und konzeptkonform
+
+| Bereich | Status | Details |
+|---------|--------|---------|
+| **Hub-System** | ✅ Fertig | `hubs` + `hub_locations` Tabellen, Hub Model mit Relationships |
+| **Partner-System** | ✅ Basis fertig | `partners` Tabelle mit `hub_id`, `type`, Provisionsfelder, Parent/Child-Beziehungen |
+| **User-System** | ✅ Basis fertig | Users mit `partner_id`, SoftDeletes, Spatie Roles |
+| **Rollen & Permissions** | ✅ Fertig | Customer, Estate-Agent, Retailer, Manufacturer, Admin, Super-Admin (via Spatie) |
+| **Registrierungs-Codes** | ✅ Fertig | `registration_codes` mit `broker_partner_id` für Makler→Kunden Attribution |
+| **Partner-Invitations** | ✅ Fertig | `partner_invitations` mit Token, Expiry, Status |
+| **Multi-Domain-Routing** | ✅ Fertig | ThemeMiddleware, ThemeServiceProvider, `config/domains.php` (5 Domains) |
+| **Auth-System** | ✅ Fertig | Fortify + Sanctum, Login, Register, Passwort-Reset, Email-Verifizierung, 2FA |
+| **Admin-Portal** | ✅ Basis fertig | Dashboard, User-Management, Partner-Management, Hub-Management, CMS |
+| **Partner-Setup-Wizard** | ✅ Fertig | Setup-Workflow für neue Partner nach Registrierung |
+| **Produkt-DB-Struktur** | ✅ Tabellen vorhanden | `products`, `product_variants`, `categories`, `tags`, `brands`, `collections`, `attributes`, `media` |
+
+### ⚠️ Teilweise implementiert – Erweiterung nötig
+
+| Bereich | Was fehlt | Konzept-Referenz |
+|---------|-----------|-----------------|
+| **Product Model** | Migration existiert, aber **kein `App\Models\Product`** – Model muss erstellt werden | Abschnitt 2: Produkt-Modul |
+| **Media Model** | Migration existiert, aber **kein `App\Models\Media`** – Model muss erstellt werden | Für Produkt-Bilder, Partner-Galerie |
+| **Partner-Profil** | Basis-Felder vorhanden, aber es fehlen: Team-Fotos, Showroom-Galerie, Story-Text, Öffnungszeiten | Abschnitt 3: "Faces" Profile |
+| **Produkt-Upload UI** | `livewire/products/create` existiert als Blade, aber unvollständig | Abschnitt 2: Händler-Upload |
+| **Produkt-Feed** | `livewire/products/index` existiert, aber keine Hub-basierte Filterung | Abschnitt 5: Local Feed |
+| **Sparse Models** | `Attribute`, `AttributeValue`, `Category`, `Collection`, `Tag`, `ProductVariant`, `ShippingClass`, `TaxRate` haben keine Relationships definiert | Allgemein |
+
+### ❌ Nicht implementiert – Muss gebaut werden
+
+| Bereich | Beschreibung | Konzept-Referenz |
+|---------|-------------|-----------------|
+| **User `origin` Feld** | Herkunft des Kunden (`style2own` / `stileigentum`) für Theme-Steuerung | Abschnitt 1: Core-Modul |
+| **User `hub_id` Feld** | Direkte Hub-Zuordnung für Kunden (nicht nur indirekt über Partner) | Abschnitt 1: Hub-Logik |
+| **`product_type` Feld** | Unterscheidung `local_stock` (Säule A) vs. `smart_order` (Säule B) | Abschnitt 2: Produkt-Modul |
+| **`is_curated` Feld** | Admin-Freigabe-Flag für Produkt-Sichtbarkeit | Abschnitt 2: Produkt-Modul |
+| **Ticket-System** | Komplett fehlend: Tickets, QR-Codes, Voucher-Generierung | Abschnitt 3A: Ticket-System |
+| **Transaction/Receipt** | Beleg-Upload, State Machine (pending→confirmed→paid→distributed) | Abschnitt 3B: Clearing-System |
+| **Wallet/Ledger** | Cashback-Wallets, Provisions-Split, Kassenbuch | Abschnitt 3C: Wallet-Logik |
+| **Kunden-Dashboard** | "Mein Zuhause" – emotionaler Feed mit Produkten aus dem eigenen Hub | Abschnitt 4: User Journey |
+| **Setup-Buchung** | Service-Store für Händler (z.B. Setup-Paket 399€) | Abschnitt 4: Partner-Modul |
+| **Enums** | Keine PHP Enums vorhanden (ProductType, TransactionStatus, TicketStatus, etc.) | Best Practice |
+| **Form Requests** | Keine Form Request Klassen vorhanden | Best Practice |
+| **Policies** | Keine Authorization Policies vorhanden | Best Practice |
+
+---
+
+## 2. Entwicklungsphasen
+
+### Phase 1: Datenbank & Core-Vervollständigung ✅ ABGESCHLOSSEN
+**Geschätzter Aufwand:** 2-3 Tage | **Tatsächlich:** 1 Tag (12.02.2026)
+**Priorität:** HÖCHSTE – Basis für alle weiteren Phasen
+
+#### 1.1 Fehlende Models erstellen
+- [ ] `App\Models\Product` erstellen mit allen Relationships:
+  - `belongsTo(Partner)`, `belongsTo(Brand)`, `belongsTo(Collection)`
+  - `belongsToMany(Category)`, `belongsToMany(Tag)`
+  - `hasMany(ProductVariant)`, `morphMany(Media)`
+  - `hasMany(RelatedProduct)`
+  - Scopes: `active()`, `curated()`, `localStock()`, `smartOrder()`, `inHub($hubId)`
+- [ ] `App\Models\Media` erstellen (polymorphe Beziehung)
+- [ ] Fehlende Relationships in Sparse Models ergänzen:
+  - `Attribute` → `hasMany(AttributeValue)`
+  - `AttributeValue` → `belongsTo(Attribute)`
+  - `Category` → self-referencing parent/children, `belongsToMany(Product)`
+  - `Tag` → `belongsToMany(Product)`
+  - `ProductVariant` → `belongsTo(Product)`, `belongsToMany(AttributeValue)`
+  - etc.
+- [ ] `Partner::products()` Relationship aktivieren (aktuell auskommentiert)
+
+#### 1.2 Migrationen: User-Erweiterung
+```
+Migration: add_origin_and_hub_id_to_users_table
+```
+- [ ] `origin` (nullable string) – `style2own` | `stileigentum` | null
+- [ ] `hub_id` (nullable FK → hubs) – direkte Hub-Zuordnung für Kunden
+- [ ] `broker_partner_id` (nullable FK → partners) – direkte Makler-Attribution (Alternative zu indirekter Verknüpfung über Partner-Hierarchie; **Entscheidung nötig**: reicht `partner.parent_partner_id` oder braucht User direkt ein Feld?)
+
+> **Offene Frage 1:** Soll der Kunde einen eigenen Partner-Eintrag bekommen (so wie jetzt über `partner_id` → Partner mit `parent_partner_id`) oder reicht eine direkte `hub_id` + `broker_partner_id` auf dem User? Die aktuelle Architektur erstellt für jeden Kunden einen Partner-Eintrag. Das könnte für das Wallet/Ledger System nützlich sein (jeder Partner hat eigene Provision-Settings). **Empfehlung:** Beibehalten, aber `hub_id` und `origin` direkt auf User setzen für schnelle Queries.
+
+#### 1.3 Migrationen: Produkt-Erweiterung
+```
+Migration: add_marketplace_fields_to_products_table
+```
+- [ ] `product_type` (string, default: `local_stock`) – `local_stock` | `smart_order`
+- [ ] `is_curated` (boolean, default: false) – Admin-Freigabe
+- [ ] `curated_at` (nullable datetime) – Zeitpunkt der Freigabe
+- [ ] `curated_by` (nullable FK → users) – Wer hat freigegeben
+- [ ] `hub_id` (nullable FK → hubs) – Direkte Hub-Zuordnung (ergänzend zu Partner→Hub)
+- [ ] `price_type` (string) – `fixed` | `from_price` | `on_request` (Preisanzeige-Logik)
+- [ ] `price_display_text` (nullable string) – z.B. "Ab 2.500 €" Freitext
+- [ ] `is_available` (boolean, default: true) – Verfügbar/Verkauft Toggle für Händler
+
+#### 1.4 Migrationen: Partner-Profil Erweiterung
+```
+Migration: add_profile_fields_to_partners_table
+```
+- [ ] `story_text` (nullable text) – "Seit 1950 in Herford..."
+- [ ] `opening_hours` (nullable JSON) – Öffnungszeiten strukturiert
+- [ ] `specialties` (nullable JSON) – Fachgebiete/Spezialisierungen
+- [ ] `founded_year` (nullable integer) – Gründungsjahr
+
+> **Hinweis:** Team-Fotos und Showroom-Galerie werden über die polymorphe `media` Tabelle abgebildet (type: `team_photo`, `showroom`, `gallery`).
+
+#### 1.5 Migration: Settings-Tabelle
+```
+Migration: create_settings_table
+```
+- [ ] `id`
+- [ ] `group` (string) – z.B. `tickets`, `marketplace`, `commissions`
+- [ ] `key` (string, unique innerhalb group)
+- [ ] `value` (text, nullable)
+- [ ] `type` (string) – `string` | `integer` | `boolean` | `json`
+- [ ] `description` (nullable text) – Beschreibung für Admin-UI
+- [ ] `timestamps`
+
+Default-Werte per Seeder:
+- `tickets.validity_days` = 30
+- `tickets.receipt_upload_deadline_days` = 30
+- `tickets.max_per_merchant_per_customer` = 3
+- `tickets.max_merchants_per_customer` = 4
+- `commissions.default_broker_rate` = 0 (individuell)
+- `commissions.default_cashback_rate` = 0 (individuell)
+
+#### 1.6 Domain-Ergänzung: local4local
+- [ ] `config/domains.php` um `local4local` Domain erweitern:
+  - Produktion: `local4local.online`
+  - Entwicklung: `local4local.test`
+  - Theme, Farben, Fonts definieren
+- [ ] `.env` Variablen: `DOMAIN_LOCAL4LOCAL=local4local.test`
+- [ ] Routing in `routes/domains.php` einbinden
+
+#### 1.7 Enums erstellen
+- [ ] `App\Enums\ProductType` – `LocalStock`, `SmartOrder`
+- [ ] `App\Enums\ProductStatus` – `Draft`, `Active`, `Archived`, `Sold`
+- [ ] `App\Enums\PriceType` – `Fixed`, `FromPrice`, `OnRequest`
+- [ ] `App\Enums\PartnerType` – `Retailer`, `Manufacturer`, `EstateAgent`
+- [ ] `App\Enums\UserOrigin` – `Style2Own`, `StilEigentum`
+- [ ] `App\Enums\CurationStatus` – `Pending`, `Approved`, `Rejected`
+
+#### 1.8 Factories & Seeders
+- [ ] `ProductFactory` erstellen
+- [ ] `MediaFactory` erstellen
+- [ ] `SettingFactory` erstellen
+- [ ] `PartnerFactory` erweitern (fehlende Felder)
+- [ ] `ProductSeeder` für Testdaten
+- [ ] `SettingsSeeder` für Default-Werte
+- [ ] `HubSeeder` erweitern (wenn nötig)
+
+#### 1.9 Tests Phase 1
+- [ ] Unit-Tests für alle neuen Models und Relationships
+- [ ] Unit-Tests für Enums
+- [ ] Feature-Tests für Migrations (Datenintegrität)
+
+---
+
+### Phase 2: Händler-Profil & Produkt-Management – ✅ KERN ABGESCHLOSSEN (12.02.2026)
+**Geschätzter Aufwand:** 5-6 Tage | **Tatsächlich:** 1 Tag (12.02.2026)
+**Priorität:** HOCH – Content-Erstellung ermöglichen
+
+#### 2.0 Architektur-Entscheidung: EINE Tabelle, ZWEI Masken
+
+> **Entscheidung:** Beide Produkttypen nutzen dieselbe `products` Tabelle. Das Feld `product_type` (`local_stock` | `smart_order`) bestimmt, welche Eingabemaske und Validierung angewendet wird.
+
+**Begründung:**
+- Beides sind Produkte mit identischem Kern (Name, Beschreibung, Preis, Bilder, Partner, Hub, Kategorie)
+- Der Local Feed zeigt beide Typen gemischt an – eine Tabelle ermöglicht einfache Queries ohne UNION
+- Das Teaser-Produkt ist ein "leichtes" Produkt: die Felder, die es nicht braucht, bleiben `null`
+- Ein Model, ein Satz Relationships, ein Satz Scopes – kein doppelter Code
+- Filterung per Scope: `Product::localStock()`, `Product::smartOrder()`
+
+---
+
+#### Kundenfeedback: Typ A vs. Typ B (12.02.2026)
+
+> **Implementiert in `app/Enums/ProductType.php`:**
+> - `requiresTicket(): bool` → `LocalStock = true`, `SmartOrder = false`
+> - `allowedPriceTypes(): array` → `LocalStock = [FromPrice, OnRequest]`, `SmartOrder = [Fixed, FromPrice, OnRequest]`
+
+**Typ A – Teaser-Produkte** (`product_type = 'local_stock'`)
+
+Komplex → Beratung → Laden → **Ticket zwingend erforderlich**
+
+- Aufwendige Konfiguration (Maße, Module, Materialien) – Abschluss nur im Laden
+- Online nur Beispiele, Referenzen, grobe Preisindikationen
+- Typisch: Küchenstudios, maßgefertigte Möbel (Cabinet), Einbausysteme
+- **Preistyp:** Nur `from_price` oder `on_request` – Festpreis online nicht erlaubt
+- **Ticket:** zwingend (`ProductType::LocalStock->requiresTicket() === true`)
+
+**Typ B – Standard-Produkte** (`product_type = 'smart_order'`)
+
+Einfach → verständlich → skalierbar → **Ticket optional / Direktkauf möglich**
+
+- Klare Varianten, vollständig online konfigurierbar, ca. 99 % des Sortiments
+- **Preistyp:** Alle erlaubt (`fixed`, `from_price`, `on_request`)
+- **Ticket:** optional – Direktkauf online möglich oder Ticket + Ladenbesuch
+
+---
+
+**Maske 1: Typ A – Teaser-Produkt / Local Stock (Händler)**
+Ziel: Extrem vereinfacht, handy-optimiert. Kein komplexes Warenwirtschafts-Monster.
+
+| Feld | DB-Spalte | Pflicht | Beschreibung |
+|------|-----------|---------|-------------|
+| Fotos | → `media` (morph) | Ja (min. 1) | 1 Hauptbild + optional 2 Galerie-Bilder |
+| Titel | `name` | Ja | Produktname |
+| Kurzbeschreibung | `description_short` | Ja | Max. 180 Zeichen |
+| Preistyp | `price_type` | Ja | Nur `from_price` oder `on_request` (via `allowedPriceTypes()`) |
+| Preisangabe | `price_display_text` | Cond. | Pflicht wenn `from_price` (z.B. "Ab 2.500 €") |
+| Kategorie | → `category_product` (Pivot) | Ja | Dropdown-Auswahl |
+| Status | `status` | Ja | Verfügbar / Verkauft |
+
+Automatisch gesetzt: `product_type = 'local_stock'`, `hub_id` = Hub des Händlers, `partner_id` = Partner des Users.
+`PriceType::Fixed` für Maske 1 **nicht erlaubt** – Validierung via `ProductType::LocalStock->allowedPriceTypes()`.
+
+**Maske 2: Typ B – Konfigurations-Produkt / Smart Order (Hersteller)**
+Das bestehende 6-Tab-Formular (`livewire/products/create.blade.php`) mit 13 Sektionen:
+Basis → Bilder → Physisch → Material & Herkunft → Kommerziell → Zuordnung & Verwaltung
+
+Automatisch gesetzt: `product_type = 'smart_order'`, `partner_id` = Partner des Users.
+Hub-Zuordnung: Manuell wählbar (Hersteller können in mehreren Hubs aktiv sein).
+Alle Preistypen erlaubt; Standard-Varianten mit Festpreis möglich.
+
+**Routing-Logik:** ✅ AKTUALISIERT (13.02.2026)
+```
+// Beide Rollen können BEIDE Produkttypen anlegen.
+// Die Produktliste zeigt zwei Buttons:
+//   "Neues Teaser-Produkt"    → Maske 1 (Typ A: Teaser, vereinfacht, Ticket zwingend)
+//   "Neues Standard-Produkt"  → Maske 2 (Typ B: Konfiguration, komplex, Ticket optional)
+// Sichtbar für: Retailer, Manufacturer, Admin, Super-Admin
+// Zusätzlich: Produkttyp-Filter in der Produktliste (Teaser / Standard / Alle)
+```
+
+#### 2.1 Partner-Profil Erweiterung (Admin-Portal) – ✅ Kern implementiert
+- [x] Partner-Profil Formular erweitern:
+  - [x] Story-Text Editor (`<flux:textarea>`)
+  - [x] Öffnungszeiten-Eingabe (strukturiertes JSON-Formular, 7 Wochentage)
+  - [ ] Team-Fotos Upload (mehrere Bilder via `<flux:file-upload>`) – ausstehend
+  - [ ] Showroom-Galerie Upload – ausstehend
+- [ ] Form Request: `UpdatePartnerProfileRequest` – inline Validierung verwendet
+- [x] Policy: `PartnerPolicy` (viewAny, view, update, delete, curateProducts)
+- [x] Admin Partner-Übersicht: `admin/partners/index.blade.php` (Suche, Filter, Tabelle)
+
+#### 2.2 Produkt-CRUD: Maske 1 – Teaser / Local Stock (Händler) – ✅ Implementiert
+- [x] Volt-Komponente: `livewire/products/form-teaser.blade.php` (merged Create + Edit)
+  - [x] Einzelseiten-Formular (KEIN Tab-Layout)
+  - [x] Bild-Upload via `WithFileUploads` + Drag & Drop Bildsortierung
+  - [x] Felder: Foto, Titel, Kurzbeschreibung, Preistyp (nur FromPrice/OnRequest), Preistext, Kategorie, Status, Produktnummer
+  - [x] Produktnummern: Partner-Produktnummer (auto-generiert) + B2in-Artikelnummer (auto bei Save)
+  - [x] Automatisch: `product_type = 'local_stock'`, `hub_id` vom Händler-Hub, `partner_id`
+  - [x] Preistyp-Validierung via `ProductType::LocalStock->allowedPriceTypes()` (kein Festpreis)
+  - [x] Freigabe-Workflow: UI "aktiv" → DB `pending` (korrekt zur Freigabe, nicht direkt Active)
+- [x] Produkt-Liste: Zwei Buttons ("Neues Teaser-Produkt" + "Neues Standard-Produkt") für alle Partner-Rollen
+- [x] Produkt-Liste: Produkttyp-Filter (Teaser / Standard / Alle)
+- [x] Produkt-Liste: Vorschaubild (erstes Bild nach order_column) vor Produktname
+- [x] Produkt bearbeiten: Pre-Fill, Status-Handling, Media-Verwaltung, Activity-Log, Toast-Notification
+- [x] Bildsortierung: Drag & Drop, erstes Bild = Standardbild, order_column in DB
+- [x] Produkt archivieren / als "Verkauft" markieren – in Edit-Formular und Produktliste (Dropdown-Menue)
+- [ ] Form Request: `StoreTeaserProductRequest` – inline Validierung verwendet
+- [x] Policy: `ProductPolicy` (viewAny, view, create, update, delete, curate)
+
+#### 2.3 Produkt-CRUD: Maske 2 – Standard / Smart Order – ✅ Implementiert (13.02.2026)
+- [x] Volt-Komponente: `livewire/products/form-standard.blade.php` (merged Create + Edit)
+  - [x] 8-Tab-Layout: Basis, Bilder, Maße & Material, Verpackung & Versand, Kommerziell, Service & Garantie, Nachhaltigkeit, Zuordnung
+  - [x] Erstellt Product + Master-Variante (ProductVariant) + ProductLogistics + Media
+  - [x] Preis-Typ Logik: Festpreis / Ab-Preis / Preis auf Anfrage (alle 3 für SmartOrder erlaubt)
+  - [x] Automatisch: `product_type = 'smart_order'`, Hub-Fallback auf Partner-Hub
+  - [x] File-Uploads: Mehrere Bilder (max 10, JPG/PNG, max 10 MB) + Drag & Drop Bildsortierung
+  - [x] Preise in EUR eingeben → automatische Umrechnung in Cents bei Speicherung
+  - [x] Alle optionalen Felder: MPN, EAN/GTIN, UVP, EK, Lagerstatus, Lieferzeit, SEO-Metadaten, Maße, Verpackung
+  - [x] Validierung inline (kein separater Form Request – konsistent mit Teaser-Formular)
+  - [x] Authorization: ProductPolicy + Rollenprüfung (Retailer, Manufacturer, Admin, Super-Admin)
+  - [x] Bei Edit: Toast-Notification, aktiver Tab bleibt erhalten, kein Redirect
+- [x] Migration: `tax_rate_id` auf `product_variants` nullable gemacht (war NOT NULL ohne Default)
+
+#### 2.4 Admin: Produkt-Kuration (Approval Queue) – ✅ Vollstaendig implementiert
+- [x] Admin-View: `admin/products/index.blade.php` – Tabelle mit Filtern (Status, Typ, Haendler, Kategorie, Suche)
+- [x] Statistik-Karten: Gesamt, Zur Freigabe, In Korrektur, Freigegeben (klickbar als Schnellfilter)
+- [x] Approve Action: `is_curated=true`, `curated_at`, `curated_by` + Flux::toast()
+- [x] Correction Action: Inline-Formular mit Pflicht-Textfeld → `curation_notes`
+- [x] Reject Action: Inline-Formular mit Pflicht-Ablehnungsgrund → `curation_notes` + `status=Archived`
+- [x] Autorisierung via `ProductPolicy::curate` (`curate products` Permission)
+- [x] Admin kann alle Produkte bearbeiten (gleiche Edit-Formulare wie Haendler)
+- [x] Admin kann Produkte archivieren / als verkauft markieren (Dropdown-Menue)
+- [x] Erstellungsdatum in Tabelle sichtbar
+- [x] Kuration-Hinweis beim Haendler: Callout im Edit-Formular (Korrektur gelb, Ablehnung rot)
+- [ ] Notification an Händler/Hersteller bei Freigabe/Ablehnung – ausstehend
+- [ ] Admin kann `product_type` bei Bedarf nachträglich ändern – ausstehend
+
+#### 2.5 Tests Phase 2 – ✅ Kern abgeschlossen
+- [x] Feature-Tests: `PartnerPolicyTest` (10 Tests) – viewAny, view, update, curateProducts
+- [x] Feature-Tests: `ProductPolicyTest` (14 Tests) – alle Policy-Methoden
+- [x] Feature-Tests: `PartnerProfileUpdateTest` (8 Tests) – Profil-Update, Öffnungszeiten, Validierung
+- [x] Feature-Tests: `TeaserProductCreateTest` (18 Tests) – Happy Path, Preistyp-Validierung, Autorisierung, Status-Logik, Produktnummern
+- [x] Feature-Tests: `ProductCurationTest` (23 Tests) – Approve, Reject mit Pflicht-Textfeld, Correction, Archive/Sold, Filter, Kuration-Notes-Anzeige im Edit
+- [x] Feature-Tests: `StandardProductCreateTest` (39 Tests) – Zugriff, Happy Path, alle Tabs, Validierung, Preistypen, Produktnummern, Marken
+- [x] Feature-Tests: `ProductEditTest` (27 Tests) – Pre-Fill, Save, Status, Validierung, Media-Sortierung, Wood Origins, Activity, Archive/Sold
+- [x] Feature-Tests: `TeaserProductEditTest` (30 Tests) – Pre-Fill, Save, Status, Media-Sortierung, Produktnummern
+- [x] Tests: Beide Rollen (Händler + Hersteller) können BEIDE Produkttypen anlegen (Teaser + Standard)
+
+**Tests Phase 2 gesamt: 109 Produkt-Tests + 48 Policy/Profil/Kuration-Tests, alle bestanden ✅**
+
+---
+
+### Phase 3: Kunden-Frontend & Local Feed – ✅ KERN ABGESCHLOSSEN (12.02.2026)
+**Geschätzter Aufwand:** 4-5 Tage | **Tatsächlich:** 1 Tag (12.02.2026)
+**Priorität:** HOCH – Kunden-Facing Funktionalität
+
+#### 3.1 User-Origin Tracking – ✅ Implementiert
+- [x] Bei Registrierung: `origin` automatisch aus Domain setzen
+  - Request von `style2own.test` → `origin = 'style2own'`
+  - Request von `stileigentum.test` → `origin = 'stileigentum'`
+- [x] `CreateNewUser` Action (Fortify) erweitern um `origin` + `hub_id`
+- [ ] Hub-Auswahl bei Registrierung (oder automatisch via Invite-Code des Maklers) – ausstehend
+
+#### 3.2 Kunden-Dashboard ("Mein Zuhause") – ✅ Kern implementiert
+- [x] `topOffers` im Dashboard: echte Produkte aus dem Hub des Kunden laden
+  - `Product::query()->where('status', Active)->where('is_curated', true)->...->take(3)`
+  - Fallback auf Dummy-Daten wenn noch keine Produkte vorhanden
+- [ ] Eigene Dashboard-Seite für Customer-Rolle – ausstehend
+- [ ] Theme-Steuerung basierend auf `origin` (`style2own` / `stileigentum`) – ausstehend
+
+#### 3.3 Local Feed (Marktplatz-View) – ✅ Implementiert
+- [x] `products/index` mit echter DB-Abfrage und Rollen-Filterung:
+  - **Admin**: sieht alle Produkte
+  - **Customer**: nur `active + is_curated + is_available` aus eigenem Hub
+  - **Retailer/Partner**: nur eigene Produkte
+- [x] Suchfilter nach Name, Kategorie-Filter, Paginierung (20 Einträge)
+- [ ] Produkt-Detailseite – ausstehend
+- [ ] Filteroptionen: Preisbereich, Verfügbarkeit – ausstehend
+
+#### 3.4 Partner-Profilseite (öffentlich) – ✅ Implementiert
+- [x] `partner/profile.blade.php`: Story, Öffnungszeiten, Produkte (max. 6), Spezialisierungen, Adresse
+- [x] Route: `partner/{partnerId}/profile` → `partner.profile`
+- [ ] Team-Fotos / Showroom-Galerie – ausstehend (abhängig von Media-Upload)
+
+#### 3.5 Tests Phase 3 – ✅ Abgeschlossen
+- [x] `CreateNewUserOriginTest` (6 Tests) – Origin-Tracking, hub_id
+- [x] `LocalFeedTest` (5 Tests) – Hub-Filterung, Kuration, Rollen, Suche, Kategorie
+- [x] `PartnerProfilePageTest` (6 Tests) – Profilseite, Story, Produkte, Auth
+
+**Tests Phase 3 gesamt: 17 Tests, alle bestanden ✅**
+
+---
+
+### Phase 4: Ticket-System & QR-Generierung
+**Geschätzter Aufwand:** 3-4 Tage
+**Priorität:** HOCH – Kern der Monetarisierung
+
+#### 4.1 Datenbank: Tickets
+```
+Migration: create_tickets_table
+```
+- [ ] `id`, `uuid` (public identifier)
+- [ ] `user_id` (FK → users, Kunde)
+- [ ] `merchant_partner_id` (FK → partners, Händler)
+- [ ] `product_id` (nullable FK → products)
+- [ ] `hub_id` (FK → hubs)
+- [ ] `code` (unique string, z.B. "TK-2026-XXXXX")
+- [ ] `qr_code_path` (nullable string, Pfad zur generierten QR-Datei)
+- [ ] `status` (string: `active` | `redeemed` | `expired`)
+- [ ] `discount_type` (string: `percentage` | `fixed`)
+- [ ] `discount_value` (decimal)
+- [ ] `valid_until` (datetime)
+- [ ] `redeemed_at` (nullable datetime)
+- [ ] `timestamps`
+
+#### 4.2 Ticket Model & Enum
+- [ ] `App\Models\Ticket` mit Relationships
+- [ ] `App\Enums\TicketStatus` – `Active`, `Redeemed`, `Expired`
+- [ ] `TicketFactory` erstellen
+- [ ] `TicketPolicy` erstellen
+
+#### 4.3 Ticket-Generierung
+- [ ] Composer-Paket für QR-Code Generierung (`simplesoftwareio/simple-qrcode` oder ähnlich) – **Genehmigung einholen**
+- [ ] Service: `App\Services\TicketService`
+  - `generateTicket(User $user, Partner $merchant, ?Product $product): Ticket`
+  - `generateQrCode(Ticket $ticket): string` (gibt Pfad zurück)
+  - `validateTicket(string $code): ?Ticket`
+  - `redeemTicket(Ticket $ticket): void`
+- [ ] Livewire-Komponente: "Ticket ziehen" Button auf Produktdetailseite
+- [ ] Mail/PDF-Generierung mit QR-Code + Händler-Info
+
+#### 4.4 Händler: Ticket-Einlösung
+- [ ] Händler-Dashboard: "Eingelöste Tickets" Übersicht
+- [ ] QR-Code Scanner (Optional, Phase 5)
+- [ ] Manuelle Code-Eingabe zum Einlösen
+
+#### 4.5 Tests Phase 4
+- [ ] Unit-Tests für TicketService
+- [ ] Feature-Tests für Ticket-Generierung
+- [ ] Feature-Tests für Ticket-Einlösung
+- [ ] Tests für QR-Code Generierung
+
+---
+
+### Phase 5: Transaction-Engine & Clearing
+**Geschätzter Aufwand:** 5-6 Tage
+**Priorität:** MITTEL – Aufbauend auf Ticket-System
+
+#### 5.1 Datenbank: Transaktionen
+```
+Migration: create_transactions_table
+```
+- [ ] `id`, `uuid`
+- [ ] `ticket_id` (FK → tickets)
+- [ ] `user_id` (FK → users, Kunde)
+- [ ] `merchant_partner_id` (FK → partners, Händler)
+- [ ] `broker_partner_id` (nullable FK → partners, Makler)
+- [ ] `amount` (integer, in Cents)
+- [ ] `receipt_image_path` (nullable string, hochgeladener Beleg)
+- [ ] `receipt_amount` (nullable integer, vom Kunden angegebener Betrag in Cents)
+- [ ] `status` (string: State Machine)
+- [ ] `merchant_confirmed_at` (nullable datetime)
+- [ ] `merchant_confirmed_amount` (nullable integer, in Cents)
+- [ ] `invoice_generated_at` (nullable datetime)
+- [ ] `paid_at` (nullable datetime)
+- [ ] `distributed_at` (nullable datetime)
+- [ ] `notes` (nullable text)
+- [ ] `timestamps`
+
+#### 5.2 Transaction State Machine
+```
+Enum: App\Enums\TransactionStatus
+```
+- [ ] `PendingReceipt` – Ticket eingelöst, Kunde muss Beleg hochladen
+- [ ] `PendingMerchant` – Beleg hochgeladen, Händler muss bestätigen
+- [ ] `Confirmed` – Händler hat bestätigt → Rechnung an Händler generieren
+- [ ] `Invoiced` – Rechnung erstellt → Zahlung ausstehend
+- [ ] `Paid` – Händler hat Provision an B2In überwiesen
+- [ ] `Distributed` – Provisionen an Makler/Kunde ausgeschüttet
+- [ ] `Rejected` – Händler hat abgelehnt
+- [ ] `Disputed` – Streitfall
+
+#### 5.3 Beleg-Upload (Kunden-View)
+- [ ] Livewire-Komponente: Beleg-Upload Formular
+  - Foto-Upload des Kaufbelegs
+  - Betrag-Eingabe
+  - Verknüpfung mit Ticket
+- [ ] Validierung: Ticket muss `redeemed` sein
+- [ ] Mail-Notification an Händler: "Neuer Beleg zur Bestätigung"
+
+#### 5.4 Händler-Bestätigung
+- [ ] Händler-Dashboard: "Offene Umsatz-Bestätigungen"
+- [ ] Beleg anzeigen mit Bestätigungs-/Ablehnungs-Buttons
+- [ ] Händler kann Betrag korrigieren (falls Kunde falschen Betrag eingegeben hat)
+- [ ] Bei Bestätigung: Event `TransactionConfirmed` feuern
+
+#### 5.5 Tests Phase 5
+- [ ] Unit-Tests für State Machine Übergänge
+- [ ] Feature-Tests für Beleg-Upload
+- [ ] Feature-Tests für Händler-Bestätigung
+- [ ] Tests für Events und Notifications
+
+---
+
+### Phase 6: Wallet, Cashback & Provisions-System
+**Geschätzter Aufwand:** 4-5 Tage
+**Priorität:** MITTEL – Monetarisierung
+
+#### 6.1 Datenbank: Wallets & Ledger
+```
+Migration: create_wallets_table
+```
+- [ ] `id`
+- [ ] `partner_id` (nullable FK → partners)
+- [ ] `user_id` (nullable FK → users)
+- [ ] `balance` (integer, in Cents)
+- [ ] `type` (string: `cashback` | `commission` | `platform`)
+- [ ] `timestamps`
+
+```
+Migration: create_ledger_entries_table
+```
+- [ ] `id`, `uuid`
+- [ ] `wallet_id` (FK → wallets)
+- [ ] `transaction_id` (nullable FK → transactions)
+- [ ] `type` (string: `credit` | `debit`)
+- [ ] `amount` (integer, in Cents, immer positiv)
+- [ ] `balance_after` (integer, in Cents)
+- [ ] `description` (string)
+- [ ] `timestamps`
+
+#### 6.2 Provisions-Berechnung
+- [ ] Service: `App\Services\CommissionService`
+  - `calculateSplit(Transaction $transaction): CommissionSplit`
+  - Berechnet: Makler-Anteil, Kunden-Cashback, B2In-Marge
+  - Nutzt `partner.provision_rate_percentage` und `partner.provision_fixed_amount`
+- [ ] Event Listener für `TransactionPaid`:
+  - Erstellt Ledger-Einträge
+  - Aktualisiert Wallet-Balances
+  - Setzt Transaction-Status auf `distributed`
+
+#### 6.3 Wallet-Views
+- [ ] Kunden-Dashboard: "Mein Cashback" (Guthaben, Historie)
+- [ ] Makler-Dashboard: "Meine Provisionen" (Guthaben, Historie)
+- [ ] Admin: Wallet-Übersicht aller Partner und Kunden
+
+#### 6.4 Tests Phase 6
+- [ ] Unit-Tests für CommissionService (Splits korrekt berechnet)
+- [ ] Feature-Tests für Wallet-Operationen
+- [ ] Feature-Tests für Event-basierte Distribution
+- [ ] Edge Cases: Rundung, Null-Beträge, fehlende Provisionsregeln
+
+---
+
+### Phase 7: Frontend-Polish & Domains
+**Geschätzter Aufwand:** 3-4 Tage
+**Priorität:** MITTEL
+
+#### 7.1 Style2Own vs. StilEigentum Feinschliff
+- [ ] CSS-Variablen-Sets für beide Brands finalisieren
+- [ ] Wording-Datenbank: "Du" vs. "Sie" Ansprache in allen Texten
+- [ ] Landingpage-Anpassungen je Brand
+
+#### 7.2 "Local for Local" Branding
+- [ ] Hub-spezifisches Branding (z.B. "Local for Local OWL")
+- [ ] Hub-Landingpages mit regionalen Inhalten
+- [ ] Domain-Routing für `localforlocal.de` (wenn verfügbar)
+
+#### 7.3 Responsive & Mobile
+- [ ] Händler-Upload Formular mobil-optimiert ("Handy-optimiert" laut Konzept)
+- [ ] Ticket-Anzeige mobil-optimiert (QR-Code gut scanbar)
+- [ ] Kunden-Dashboard responsive
+
+#### 7.4 Tests Phase 7
+- [ ] Browser-Tests (Laravel Dusk) für Multi-Domain
+- [ ] Responsive Tests
+
+---
+
+## 3. Beantwortete Fragen & Entscheidungen
+
+### Architektur-Entscheidungen
+
+**Frage 1: Kunden-Partner-Beziehung** ✅
+> **Entscheidung:** Beibehalten. Jeder Kunde behält seinen Partner-Eintrag. Zusätzlich `hub_id` und `origin` direkt auf User für schnelle Queries.
+
+**Frage 2: Hub-Zuordnung bei Produkten** ✅
+> **Entscheidung:** Direktes `hub_id` Feld auf Products. Hersteller können Produkte in mehreren Hubs anbieten.
+
+**Frage 3: QR-Code Paket** ✅
+> **Entscheidung:** `chillerlan/php-qrcode`
+
+**Frage 4: PDF-Generierung für Tickets** ✅
+> **Entscheidung:** `spatie/laravel-pdf`
+
+**Frage 5: Makler-Invite und Hub-Zuweisung** ✅
+> **Entscheidung:** Automatisch vom Makler übernehmen. Admin kann manuell ändern.
+
+**Frage 6: Domain Local for Local** ✅
+> **Entscheidung:** `local4local.online` (Produktion) / `local4local.test` (Entwicklung). Muss in `config/domains.php` ergänzt werden.
+
+**Frage 11: Produkttypen – Eine oder zwei Tabellen?** ✅
+> **Entscheidung:** EINE `products` Tabelle, ZWEI Eingabemasken. Das Feld `product_type` (`local_stock` | `smart_order`) steuert welche Maske und Validierung greift. Siehe Phase 2.0 für Details.
+> - Maske 1 (Teaser/Local Stock): Vereinfacht, handy-optimiert, für Händler
+> - Maske 2 (Konfiguration/Smart Order): Komplex mit 6 Tabs, für Hersteller
+
+### Business-Logic Entscheidungen
+
+**Frage 7: Provisions-Split** ✅
+> **Entscheidung:** Individuell pro Partner. Admin-Settings-Seite mit Feldern für:
+> - Makler-Provision (%)
+> - Kunden-Cashback (%)
+> - B2In-Marge (Rest)
+> Felder werden pro Partner im Admin-Backend konfiguriert.
+
+**Frage 8: Ticket-Gültigkeit** ✅
+> **Entscheidung:** Default 30 Tage. Konfigurierbar über Admin-Settings-Seite.
+
+**Frage 9: Beleg-Upload Deadline** ✅
+> **Entscheidung:** Default 30 Tage. Konfigurierbar über Admin-Settings-Seite.
+
+**Frage 10: Ticket-Begrenzung pro Kunde** ✅
+> **Entscheidung:** Produkte sind immer an einen Händler gebunden. Ein Kunde kann Tickets bei verschiedenen Händlern für ähnliche Produkte ziehen. Begrenzung über Admin-Settings:
+> - Max. Tickets pro Händler (z.B. 3)
+> - Max. Händler pro Zeitraum (z.B. 4)
+> - Konfigurierbar durch Admin
+
+### Benötigte Admin-Settings-Seite (Neue Anforderung)
+Aus den Antworten ergibt sich die Notwendigkeit einer zentralen **Admin-Settings-Seite** für:
+- Ticket-Gültigkeit (Tage)
+- Beleg-Upload Deadline (Tage)
+- Max. Tickets pro Händler pro Kunde
+- Max. Händler pro Kunde pro Zeitraum
+- Standard-Provisions-Split (Default-Werte für neue Partner)
+
+> **Umsetzung:** `settings` Tabelle (key-value) + Admin-Settings-View in Phase 4/5. Alternativ: `config/marketplace.php` mit `.env`-Variablen für nicht-dynamische Werte.
+---
+
+## 4. Technische Richtlinien für die Entwicklung
+
+### Architektur-Prinzipien
+- **Eloquent-First:** Keine `DB::` Facades, immer `Model::query()`
+- **Form Requests:** Jede Validierung in eigene Request-Klassen
+- **Policies:** Jede Autorisierung über Laravel Policies
+- **Events/Listeners:** Für alle Seiteneffekte (Mail, Wallet-Buchung, Notifications)
+- **Services:** Business-Logik in Service-Klassen (`TicketService`, `CommissionService`)
+- **Enums:** Alle Status-Werte als PHP 8.1+ Enums
+
+### Namenskonventionen
+- Models: Singular, PascalCase (`Ticket`, `LedgerEntry`)
+- Tabellen: Plural, snake_case (`tickets`, `ledger_entries`)
+- Enums: PascalCase Keys (`LocalStock`, `SmartOrder`)
+- Services: `{Domain}Service` (`TicketService`, `CommissionService`)
+- Policies: `{Model}Policy` (`TicketPolicy`, `TransactionPolicy`)
+- Form Requests: `{Action}{Model}Request` (`StoreProductRequest`, `UpdatePartnerProfileRequest`)
+- Events: Past Tense (`TransactionConfirmed`, `TicketRedeemed`)
+
+### Testing-Strategie
+- Jede Phase muss vollständig getestet sein bevor die nächste beginnt
+- Feature-Tests für alle Endpoints und Livewire-Komponenten
+- Unit-Tests für Services und komplexe Business-Logik
+- Pest als Test-Framework, Factories für Testdaten
+- Mindestens: Happy Path + Validation + Authorization pro Feature
+
+### Reihenfolge der Entwicklung (innerhalb jeder Phase)
+1. Migration(s) erstellen und ausführen
+2. Model(s) mit Relationships, Casts, Scopes
+3. Enum(s) falls nötig
+4. Factory und Seeder
+5. Form Request(s)
+6. Policy
+7. Service-Klasse (falls komplexe Logik)
+8. Livewire/Volt Komponente
+9. Tests schreiben und ausführen
+10. `pint --dirty` für Code-Formatierung
+
+---
+
+## 5. Abhängigkeiten zwischen Phasen
+
+```
+Phase 1 (Core) ──────────┬──────────> Phase 2 (Produkte)
+                         │                    │
+                         │                    ▼
+                         └──────────> Phase 3 (Frontend) ──> Phase 7 (Polish)
+                                              │
+                                              ▼
+                                     Phase 4 (Tickets)
+                                              │
+                                              ▼
+                                     Phase 5 (Transactions)
+                                              │
+                                              ▼
+                                     Phase 6 (Wallet/Cashback)
+```
+
+- **Phase 1** ist Voraussetzung für alles
+- **Phase 2 und 3** können teilweise parallel laufen
+- **Phase 4** setzt Phase 3 voraus (Produktdetailseite muss existieren)
+- **Phase 5** setzt Phase 4 voraus (Tickets müssen existieren)
+- **Phase 6** setzt Phase 5 voraus (Transaktionen müssen existieren)
+- **Phase 7** kann teilweise parallel zu Phase 4-6 laufen
+
+---
+
+## 6. Neue Permissions (zu ergänzen)
+
+Folgende Permissions müssen im RoleSeeder ergänzt werden:
+
+| Permission | Beschreibung | Rollen |
+|-----------|-------------|--------|
+| `curate products` | Produkte freigeben/ablehnen | Admin, Super-Admin |
+| `view tickets` | Eigene Tickets sehen | Customer |
+| `create tickets` | Ticket generieren | Customer |
+| `redeem tickets` | Ticket einlösen | Retailer |
+| `view transactions` | Transaktionen sehen | Customer, Retailer, Estate-Agent, Admin |
+| `confirm transactions` | Umsatz bestätigen | Retailer |
+| `upload receipts` | Beleg hochladen | Customer |
+| `view wallet` | Wallet-Guthaben sehen | Customer, Estate-Agent, Retailer |
+| `manage wallets` | Wallets verwalten | Admin |
+| `view commissions` | Provisionen einsehen | Estate-Agent, Admin |
+| `manage setup packages` | Setup-Pakete verwalten | Admin |
+| `book setup package` | Setup-Paket buchen | Retailer |
+
+---
+
+*Dieses Dokument dient als lebende Referenz für die Entwicklung. Bei Änderungen am Konzept muss dieser Plan entsprechend aktualisiert werden.*
+ochladen | Customer |
+| `view wallet` | Wallet-Guthaben sehen | Customer, Estate-Agent, Retailer |
+| `manage wallets` | Wallets verwalten | Admin |
+| `view commissions` | Provisionen einsehen | Estate-Agent, Admin |
+| `manage setup packages` | Setup-Pakete verwalten | Admin |
+| `book setup package` | Setup-Paket buchen | Retailer |
+
+---
+
+*Dieses Dokument dient als lebende Referenz für die Entwicklung. Bei Änderungen am Konzept muss dieser Plan entsprechend aktualisiert werden.*