Cockpit steuert Frontends
Zielgruppe: Entwickler, IT, Cursor/Claude/MCP — und alle, die in einem neuen Chat oder Projekt das Architekturmodell schnell verstehen wollen, ohne es jedes Mal neu erklären zu müssen.
Kurz: Das Dashboard (cockpitOS) ist die Source of Truth — Daten und Optionen/Konfig. Das Frontend ist künftig ein v0-Projekt im GitHub-Repo (Website, später Kiosk/Companion). Es liest über öffentliche APIs; schreiben tun nur Redaktion (Dashboard) oder Agenten (MCP/AgencyOS).
WordPress, die Center-Website-App (apps/center-website) und die Signage-App (apps/digital-signage) sind veraltet. Bestehende Center laufen weiter, bis IT sie nach v0 zieht. Keine neuen Go-Lives auf diesen drei Frontends.
Im Repo: .cursor/context.md (Typ SMG + Verweis hierher). Ergänzende Regel: .cursor/rules/cockpit-steuert-frontends.mdc. Code-Wahrheit: apps/dashboard/src/lib/integration/v0-integration-contract.ts.
Was / Warum
| Was | Layout und UX = v0 / GitHub-Repo. Inhalte, Sichtbarkeit, Optionen = Cockpit (Webseiten-Reiter und Module). |
| Warum | Keine zweite Wahrheit pro Kanal. Ein Frontend-Stack statt WordPress + SPA + Signage-App. Migration tauscht nur die Oberfläche, nicht die Daten. |
| Wer betroffen | Redaktion (pflegt Reiter), Besucher (sehen Kanäle), Dev/IT (API + MCP), Agenten (MCP/AgencyOS). |
Konzeptionell breiter: Plattform-Überblick · Migration konkret: Cockpit → v0 Migration.
Das Modell in drei Schichten
- Steuer-UI — Webseiten-Reiter (
website-config-tabs.ts) und passende Dashboard-Module (Shops, News, Social, …). - Speicher — feste Pfade in PostgreSQL (JSON-Felder, Entitäten-Tabellen).
- Ausgänge — Frontends rufen Leserouten auf; Schreibzugriffe gehen nie über anonyme Public-APIs.
Goldene Regel (Lesen vs. Schreiben)
cockpitOS = Source of Truth. Öffentliche Websites und v0-Apps lesen nur öffentliche GET-Routen. Schreiben nur über Dashboard oder MCP/AgencyOS mit Integrations-API-Key.
| Aktion | Wo | Typische Routen / Tools |
|---|---|---|
| Lesen | v0 (serverseitig); Bestand: SPA / Signage / WP | GET …/by-slug/{slug} → GET …/public-visitor-surface, page-content, homepage-tiles, Pfade aus data.apiHints |
| Schreiben | Redaktion, MCP, AgencyOS | cockpit_website_config_schema → cockpit_get_center_website_config → cockpit_update_center_website_config / cockpit_page_content / cockpit_content_push |
| Verboten | Öffentliches Frontend, Browser ohne Auth | GET …/website-config, AgencyOS-URLs ohne Bearer |
Vollständiger Vertrag: Public Center-Website API · MCP: AgencyOS Integration · Redaktion: v0 + Cockpit (So geht's).
Die gleiche Regel steht maschinenlesbar in jeder public-visitor-surface-Antwort unter data.v0Integration (gebaut aus v0-integration-contract.ts).
Vier Speicher-Körbe
| Korb | Inhalt | Cockpit-UI | Frontend liest |
|---|---|---|---|
| 1. Template / Website-Config | templateContent, Hero, Footer, Optionen, pagesConfig, Farben | Webseiten-Reiter (template-spezifisch) | public-visitor-surface → templatePublicContent, design, hero, … |
| 2. Page Content | Unterseiten-Texte, SEO, customContent pro pageType | Reiter „Seite: …“ / Page-Content-Editor | GET …/page-content — nach pageType filtern |
| 3. Homepage-Tiles | Startseiten-Kacheln (MEC u. a.) | Reiter Startseite / Kacheln | GET …/homepage-tiles |
| 4. Content-Entitäten | Shops, News, Events, Angebote, Services, Kontakte, … | Eigene Dashboard-Module | data.apiHints + dokumentierte Public-Routen (Shops, News, Centerplan, DOOH, …) |
Reiter → Speicher → API ist pro Template in MCP-Schema und Migration-Doku tabelliert — Beispiel ILG: Cockpit → v0 Migration → ILG-Referenz.
Code-Register:
| Was | Datei |
|---|---|
| Reiter-IDs & Renderer | apps/dashboard/src/lib/website-config-tabs.ts |
MCP-Feldpfade & writeSafety | apps/dashboard/src/lib/integration/website-config-mcp-schema.ts, mcp-tab-hints-*.ts |
| Public-Payload bauen | apps/dashboard/src/lib/build-public-visitor-surface.ts |
| v0-Anleitung (goldenRule) | apps/dashboard/src/lib/integration/v0-integration-contract.ts |
Kanäle: Ziel vs. Bestand
| Kanal | Status | Rolle |
|---|---|---|
| v0 + GitHub-Repo (Vercel) | Ziel | Einziges neues Frontend — Website, später Kiosk/Companion. Gleiche Public API. Migration |
apps/center-website | Veraltet | Multi-Tenant-SPA im Monorepo. Läuft weiter, bis DNS auf v0 zeigt. |
apps/digital-signage | Veraltet | Touch/Kiosk-App im Monorepo. Neue Stelen: v0, gleiche Cockpit-Daten. Signage → v0 |
| WordPress-Plugin | Veraltet | Bestehende WP-Sites bis Umzug. Keine neuen Anbindungen als Zielarchitektur. |
| Social, Center-Manager | Aktiv | Weitere Ausgänge — kein zweiter Shop-Stamm. Social bleibt Outstand über das Cockpit. |
Layout (Komponenten, Routing, Animation) = v0/GitHub. Was sichtbar ist, welcher Text, welche Option = Cockpit.
Neues Feature richtig anlegen
Wenn Redaktion oder Agenten etwas steuern sollen (z. B. Videothek, zeitgesteuerter Hero, Signage-Playlist):
- Dashboard — Reiter oder Modul mit verständlicher UI (optionale Template-Felder als Reiter-Einstellung pflegen, nicht nur als Code-Default — Repo-Regel
website-template-configuration.mdc). - Speicher — Additive Felder (nullable/Default), kein Datenverlust.
- Public Read —
GET-Route oder Erweiterung vonpublic-visitor-surface/apiHints— Public API Vertrag. - MCP-Parität — Hints, Schema, ggf. Tool-Export in derselben Lieferung (Repo-Regel
mcp-parity-with-changes.mdc, Doku: AgencyOS Integration). - Kanal — v0/GitHub als Konsument anbinden. Bestand (SPA, Signage-App, WordPress) nur mitziehen, wenn das Center dort noch live ist — nicht als Ziel bauen.
Anti-Pattern: Feature nur in apps/center-website, apps/digital-signage oder WordPress bauen, ohne Cockpit-Reiter und ohne öffentliche Leseroute.
MCP: Landkarte für Agenten
Typischer Ablauf für Website-Inhalte:
cockpit_website_config_schema(centerId | websiteTemplate)— Reiter, Feldpfade,v0PublicRead,writeSafety.cockpit_get_center_website_config(centerId)— Ist-Stand vor jedem Update.- Partial Update —
cockpit_update_center_website_config,cockpit_page_content,cockpit_content_push.
Tool-Liste: MCP-Tool-Referenz · Export: exports/cockpitos-tools.json.
So testen
- Im Cockpit einen Webseiten-Reiter ändern (z. B. Hero-Titel) → speichern.
GET /api/centers/{centerId}/public-visitor-surface— Feld intemplatePublicContent/herosichtbar.- v0-Preview (oder Bestand-SPA, falls das Center dort noch läuft) — gleicher Text ohne Frontend-Deploy der Inhalts-Logik (nur Cache/Revalidate beachten).
- MCP: Schema-Feldpfad mit tatsächlichem JSON in DB abgleichen.
- Seite deaktivieren (
pagesConfig) → Route 404 in v0/Template, Nav-Eintrag weg.
Betrieb
| Thema | Hinweis |
|---|---|
| Revalidate | Nach Publish On-Demand-Revalidate (REVALIDATION_SECRET) — v0/Vercel und Render |
| Env Frontends | NEXT_PUBLIC_DASHBOARD_URL / DASHBOARD_API_URL — öffentliche Dashboard-URL |
| Multi-Center v0 | by-slug / by-domain — kein Hardcoding im Frontend |
| Nur Lesen öffentlich | Schreib-APIs und website-config GET bleiben auth-pflichtig |
Verwandte Seiten
| Thema | Link |
|---|---|
| Plattform-Gesamtbild | Plattform-Überblick |
| Dev-Einstieg | Start hier (Entwicklung) |
| Public API (Detail) | Public Center-Website API |
| v0 migrieren | Cockpit → v0 Migration |
| KI-Builder-Konzept | KI Website Builder ↔ Cockpit |
| Signage | AI Premium v0-Parität |
| Redaktion MCP | Claude & MCP |
Nutzungsstatistik: Seitenaufrufe werden anonymisiert erfasst. Im Umami-Dashboard nach diesem Pfad filtern: /en/developer-guide/cockpit-steuert-frontends