Kunden-Demo MATEV 2026 — Walkthrough

Dauer: 30 Min Demo + 15 Min Q&A.

Vorbereitung 15 Min vor Termin

cd matev_2026
git submodule update --init --recursive

cd admin && ddev start
ddev exec "php artisan migrate --force"
ddev exec "php artisan db:seed"
ddev exec "php artisan opensearch:setup"

# Optional für echte Pimcore-Daten (sonst Demo-Seeder):
ddev load-pimcore-dump ../migration/exports/pimcore-2026-04-27.sql.gz
ddev exec "php artisan import:pimcore --phase=1"
ddev exec "php artisan import:pimcore --phase=2"
ddev exec "php artisan import:pimcore --phase=3 --limit=200"
ddev exec "php artisan blueprints:generate"

# Zweites Terminal — Storybook
cd ../storybook && bun install && bun run storybook

Tabs vorbereiten:

1. https://admin.matev.ddev.site/admin — admin@matev.eu / admin
2. http://localhost:6006 — Storybook
3. ddev adminer — Backup für DB-Sichtungen

Akt 1 — Wo wir herkommen (3 Min)

"Pimcore 11 läuft stabil — aber: 5.255 Hauptartikel, 41 Bricks, 524 Produkte, 362 Traktoren, 3.190 Bestellungen, 939 Angebote. Editor-Komfort, Multi-Tenant, semantische Suche, KI-Workflows — da holt Pimcore nicht mehr ein. Der neue Stack: Filament-PIM für Stammdaten, Kirby-CMS für Marketing-Content, Storybook als Komponenten-Showroom. Alles als Container hinter Caddy + FrankenPHP."

Akt 2 — Filament-PIM (8 Min)

Tab 1, in dieser Reihenfolge:

1. Login admin@matev.eu / admin
2. Dashboard — der Anker für die KI-Widgets, die in Sprint 4 kommen
3. Stammdaten → Hersteller: Multi-Sprache (DE/EN/FR), Asset-Felder, Slug-Generation
4. Produkte → MainArticle: Tabelle, Filter, dann eine Detail-View — die Bricks als Classification Store, der SpecBrickRenderer macht das gleiche im Frontend
5. Kataloge → Catalog: PDF-Templates, Spatie-Tags, Spatie-Settings für Defaults

Talking Points:

• Daten kommen aus dem Pimcore-Dump per import:pimcore (22 Importer, 5 Phasen, idempotent — beliebig oft wiederholbar)
• Multi-Sprache ist Pflicht (Spatie Translatable)
• Brick-Werte landen in attribute_values UND parallel als YAML in shared/schemas/spec-bricks/ — Single Source of Truth für Backend-Validierung und Frontend-Rendering
• Permissions: Filament-Shield + Spatie-Permission, 14 Rollen (8 Mitarbeiter, 6 Tenant) bereits geseedet

Akt 3 — Storybook (10 Min)

Tab 2 — schema-driven, kein hardcoded HTML.

3a Spec-Bricks (3 Min) — SpecBrickRenderer

• Hydraulic Drive: Min/Max-Range, Einheit l/min
• Lighting: Booleans, Sprache umschaltbar
• Main Article MOW: kombiniert
• Eine Komponente für alle 41 Bricks. Rendering wird vom YAML-Schema gesteuert.

3b Area-Bricks (3 Min) — 10 Komponenten

Text mit Background-Optionen, CTA in 4 Varianten, ImageText (Layout-Switch), Gallery (Grid / Masonry / Carousel), DealerFinder, ProductGrid.

3c Snippets (2 Min) — 5 Bausteine

Cta, Faq, Gallery, Generic, Teaser — wiederverwendbar in jedem Page-Layout.

3d Page-Layouts (2 Min) — 6 Templates

• Default (verschiedene Hero-Designs)
• Product (Galerie + Spec-Bricks)
• Dealer (Geo-Karte + DealerFinder)
• Home, Search, Secure

"Sechs Templates für ~900 Pimcore-Pages. Was Pimcore in 41 Bricks kann, decken wir mit dem Generic-Renderer + 6 Layouts ab."

Akt 4 — Architektur (5 Min)

Filament 5 Admin (PIM)  →  REST + Sanctum
                       ↘
                         GraphQL (Kirby/KQL)
                                              ↘
Marketing-Frontend (Nuxt 4, Bun)               ──→  Browser
B2B-Händlerportal (Livewire/Blade, FrankenPHP) ──→  Browser
Storybook (Komponenten-Showroom)                ──→  Browser

Search:  Meilisearch  +  OpenSearch  (Geo, RAG, Konfigurator, Embeddings)
KI:      Ollama lokal  +  Sonnet 4.6 Cloud-Fallback

• 3 Such-Schichten: Filament Global Search · Meilisearch (Frontend) · OpenSearch (Geo/Konfigurator/RAG)
• KI standardmäßig lokal über Ollama (bge-m3 Embeddings, qwen2.5:14b für Generierung), Sonnet als Cloud-Fallback per ConnectivitySettings
• Multi-Tenant von Tag 1 (Spatie-Permission Tenant-Roles)

Auf dem Server: alle Services als Container, hinter einem Caddy mit Auto-SSL. Stack-Definitionen in Git, Portainer als Cockpit.

Akt 5 — Status & Roadmap (4 Min)

Heute fertig:

• Pimcore-Importer (22 Klassen, 5 Phasen, idempotent)
• Filament 5 PIM (6 Resources funktional, weitere Resources im Sprint 1)
• 60+ Vue-Komponenten in shared/ + Storybook-Coverage
• Search-Stack (Meilisearch + OpenSearch + Ollama als DDEV/Compose-Services)
• Spatie Tags + Settings + Permission + Filament-Shield
• 41 Spec-Brick-YAML-Schemas (via blueprints:generate)
• 4 Stacks auf dem Server (proxy/mgmt/git/apps)

Sprints:

Sprint	Dauer	Ergebnis
1	2 Wochen	Filament-Resources voll v5 (alle Pivot-Manager, Actions)
2	2 Wochen	Marketing-Frontend (Nuxt) + OpenSearch-Geo
3	3 Wochen	Händlerportal (Livewire) + Konfigurator
4	2 Wochen	KI + Blueprints + Agentic-Workflows
5	1 Woche	Production-Cutover

Akt 6 — Q&A (vorbereitet)

„41 Bricks, jeder anders — wie skaliert das?" Eine Komponente, ein YAML pro Brick. blueprints:generate extrahiert das Schema aus information_schema. Neuer Brick = neues YAML, kein Code-Change.

„Bilder/Assets?" Spatie Media Library Pro. AssetImporter zieht synchron während des Pimcore-Imports.

„Customer-Logins beibehalten?" Pimcore-Hashes bleiben falls bcrypt-kompatibel, sonst Reset-Token-Mail beim ersten Login.

„Wie schalten Sie um?" Nach Sprint 2-3 läuft alles parallel. DNS-Switch im Wartungsfenster, Rollback durch DNS-Revert in Minuten.

„Was wenn Ollama nicht ausreicht?" Sonnet-Cloud-Fallback per ConnectivitySettings — ein Schalter, kein Code-Change.

„Hosting-Anforderung?" Ein Server reicht (16+ GB RAM, GPU optional für Ollama). Sonnet-Fallback < 50 EUR/Monat. Penpot/Taiga können später auf separaten Host wenn die Last steigt.

Notfall-Plan

Symptom	Lösung
ddev hängt	ddev poweroff && ddev start
Login fehlt	ddev exec "php artisan db:seed"
Storybook crasht	rm -rf storybook/node_modules && bun install
OpenSearch OOM	Akt 4 überspringen, Meilisearch reicht für die Story
Kein Pimcore-Dump	Storybook + Skeleton zeigen die Architektur
Filament 500	ddev exec "php artisan optimize:clear"

Nicht zeigen

• Code-Editor länger als nötig (max. 5 Sek für eine Schema-YAML)
• Composer-Install-Logs
• Migrations-Output (im Hintergrund laufen lassen)
• migration/-Ordner (ist die alte Spec-Sammlung)

Nach der Demo

git -C admin status -s
git -C shared status -s
git -C matev_2026 status -s

Feedback in CLIENT_FEEDBACK.md festhalten — speziell:

• Welche Akte zu lang/zu kurz waren
• Welche Q&A-Fragen tatsächlich gestellt wurden (für nächstes Mal vorbereiten)
• Welche Demo-Daten gefehlt haben (für Sprint-1-Backlog)