Centerplan mit Claude Design

Du kopierst einen Kasten, schreibst in einer kurzen Nachricht dazu, um welches Center es geht, und hängst an, was du hast (Grundriss, alter Plan, Fotos, Skizze). Ausfüllen musst du nichts. Claude schlägt Center, Slug, Etagen und Shops selbst im Cockpit nach und stellt danach höchstens sechs einfache Fragen.

Claude Design baut daraus den klickbaren Lageplan. Danach dieselbe SVG ins Dashboard legen und den Code in die bestehende v0-Website, nicht als zweite Website.

Die langen Zeilen in den Kästen (Adressen, Dateinamen, IDs) nicht umschreiben. Die braucht Claude. Du musst sie nicht verstehen.

Lange Kästen werden oft zum Anhang. Deshalb den Kasten ungeändert einfügen und den Centernamen in einer kurzen Chat-Nachricht dazu.

Claude-Team und cockpitOS: Wir arbeiten in der Claude-Team-Organisation, nicht im privaten Account. cockpitOS-MCP ist für alle in der Organisation an. Deshalb reicht der Centername. Fehlen die Tools bei dir: im Team angemeldet? Sonst siehe Claude und Cockpit (MCP).

Nur ein schönes Plan-Bild für den Upload im Dashboard? Siehe KI-Masterprompt (Hybrid).

Wozu der Plan da ist

Lies das einmal, bevor du den ersten Kasten abschickst. Es entscheidet mehr über das Ergebnis als jede Design-Frage.

Ein Centerplan ist kein Bild vom Center. Er beantwortet drei Fragen, und zwar in dieser Reihenfolge:

Gibt es das hier? Der häufigste Einstieg ist ein Name oder eine Kategorie, nicht die Karte. Deshalb führt die Suche, und der Plan zeigt die Antwort.
Auf welcher Etage? Danach fragt fast jeder, bevor er wissen will, wo genau.
Wie komme ich hin? Sinnvoll vor allem vor Ort, wo der Startpunkt feststeht. Am Handy zu Hause ist das die seltenste Frage.

Dazu kommen die Ziele, nach denen im Center am häufigsten gesucht wird und die kein Shop sind: Toilette, Aufzug, Ausgang zum Parkhaus, Foodcourt, Information.

Die Optik dient diesen Fragen, sie ist kein Selbstzweck. Tiefe und Volumen leisten drei Dinge: sie machen den Plan mit dem abgleichbar, was jemand vor Ort sieht (Atrium, Rolltreppe, gläserner Aufzug als Ankerpunkte), sie trennen Fläche von Gang ohne Legende, und sie führen den Blick auf Ziel und Weg. Was das nicht leistet, ist Schmuck. Im Zweifel gewinnt Lesbarkeit: kein Effekt darf Kontrast, Klickfläche oder Schriftgröße kosten. Am Handy in der Sonne und an der Stele aus zwei Metern Entfernung ist das der einzige Maßstab, der zählt.

Abgenommen wird deshalb so: jemand, der das Center nicht kennt, findet ein genanntes Ziel in unter zwanzig Sekunden, ohne Erklärung. Nicht: sieht hochwertig aus.

Zur Optik gehört eine Erwartung, die es zu kennen lohnt: Der Plan wird als SVG gezeichnet, nicht gerendert. Global Illumination, wie man sie aus Cinema 4D oder V-Ray kennt, gibt es dort nicht. Was der Kasten stattdessen verlangt, ist gebackenes Licht: Kontaktschatten, Verschattung in den Gängen, Bounce Light an den Fassaden, ein einziger Lichteinfall für alles. Das wirkt räumlich und bleibt lesbar. Wer eine wirklich gerenderte Optik braucht, geht den Hybrid-Weg: gerendertes Bild als Hintergrund, unsichtbare Polygone darüber. Der Preis ist, dass das Bild bei jedem Umbau neu gerendert werden muss.

Für das Center selbst ist der Plan zusätzlich ein Messinstrument. Wonach gesucht wird, was nicht gefunden wurde und welche Ziele angesteuert werden, ist die Zahl, die im Kundengespräch zählt. Deshalb meldet der Plan diese Ereignisse über das vorhandene Website-Tracking (Umami).

Was / Warum / Wer / Wo


Was	Drei kopierbare Kästen: neu, ändern, in v0 einhängen. Ohne Ausfüllen.
Warum	Nicht bei null prompten. Shop-Namen und Zeiten bleiben im Cockpit.
Wer	Redaktion und Center-Betrieb. Claude-Team-Organisation, cockpitOS-MCP für alle an.
Wo	Kasten hier, dann Claude Design (Team-Chat), dann Dateien ins bestehende v0-Projekt. Parallel: Dashboard, Centerpläne, hochladen und Shops zuordnen.

Dein Ablauf

Design-Vorlage in der Oberfläche auf neutral stellen, falls eine vorausgewählt ist (zum Beispiel „Industrial“). Eine Einstellung wirkt stärker als ein Satz im Prompt.
Kasten in der Tabelle wählen und kopieren. Nichts ausfüllen, nichts kürzen.
In Claude Design einfügen. Dazu eine kurze Nachricht: um welches Center es geht und wo der Plan laufen soll. Beispiel: „Forum Gummersbach, Grundriss hängt an, Website und Stele. Bitte kein Style-Preset anwenden.“
Vorlage anhängen. Siehe Vorlage vorbereiten.
Auf die Rückfragen antworten. Claude stellt sie gesammelt in einer Nachricht. „1b 2a 3 weiß nicht“ genügt.
Steckbrief bestätigen (sieben Zeilen, ein „ja“).
Erkennung prüfen. Claude zeigt die erkannten Flächen über deiner Vorlage. Sitzt etwas falsch, sagst du es in einem Satz. Erst danach wird gebaut.
Checkliste unten durchgehen, auch auf dem Handy und, falls vorhanden, an der Stele.
Code in v0 legen (Kasten 3). Dieselbe SVG: Dashboard, Centerpläne, hochladen, Shops zuordnen. Weg-Linie gewünscht: Routen aus der SVG erzeugen.

Mehr Stopps als Schritt 5 bis 7 gibt es nicht. Alles, was Claude beim Bauen unklar bleibt, landet im Inventar und wird bei Schritt 7 gesammelt gezeigt.

Welcher Kasten?

Situation	Kasten
Neues Center, Plan soll sofort in v0 klickbar sein	1 (Neu), neues Claude-Design-Projekt
Umbau, geteilte Fläche, neue Etage am bestehenden Plan	2 (Ändern), in den Chat dieses Centerplans, nicht in ein neues Projekt
Plan soll aussehen wie die Website (Farben, Schrift)	3 (Nach v0), v0-Chat der Website, nicht Claude Design
Nur ein Bild für die Segmentierung im Dashboard	Hybrid KI-Masterprompt
Vektor vom Grafikbüro	Illustrator

Der Plan soll auch auf der Stele laufen? Das ist keine eigene Vorlage, sondern eine Antwort auf Frage 1 in Kasten 1 (Website und Stele). Dieselbe Komponente, andere Bedienung — nicht die alte Signage-App.

Vorlage vorbereiten

Je besser die Vorlage, desto genauer die Flächen. Fünf Minuten hier sparen eine Stunde Korrektur später.

Am besten: Vektor. Hast du ein PDF vom Architekten oder eine Illustrator-Datei, schick genau die. Dann muss nichts erkannt werden, die Flächen sind schon drin.

Raster (Foto, Scan, Screenshot der alten Website):

Eine Datei pro Etage. Keine Collage mit drei Etagen auf einem Blatt. Dateiname mit Etage: eg.png, og1.png.
Zuschneiden auf das Center. Legende, Titelblock, Maßketten, Wasserzeichen, Nachbargebäude weg. Was drin bleibt, hält Claude für Center.
Gerade drehen, quer, und alle Etagen gleich ausgerichtet. Sonst liegen die Aufzüge hinterher nicht übereinander.
Beschriftung zu klein? Zusätzlich vier bis sechs Ausschnitte in hoher Auflösung anhängen, mit etwas Überlappung.
Scan: lieber hart schwarz-weiß als grau. Farbpläne in Farbe lassen, Farbe steht oft für die Kategorie.

Kein Bild-KI-Werkzeug vorschalten. Bildmodelle zeichnen neu statt zu putzen: Flächen verschwinden, Gänge werden erfunden, Nummern werden zu ähnlich aussehendem Unsinn. Ein hässlicher, aber echter Scan ist besser als ein schöner, falscher Plan. Entzerren, drehen, zuschneiden und Kontrast sind in Ordnung, das ändert keine Inhalte.

Gar nichts vorhanden? Auch gut. Claude legt eine plausible Anordnung an, markiert alles als unsicher und sagt es in der Lieferung deutlich. Vor dem Zuordnen der Shops im Center gegenprüfen.

Kasten 1: Neuen Centerplan anlegen

Kasten kopieren und in ein neues Claude-Design-Projekt einfügen. Centername als kurze Nachricht dazu, Vorlage anhängen. Ausfüllen musst du nichts, Claude fragt.

Ab hier für Claude

Den Kasten nicht kürzen und nicht umschreiben.

ZWECK (geht jeder Gestaltungsfrage vor)
Der Plan ist kein Bild vom Center. Er beantwortet drei Fragen,
in dieser Reihenfolge:
1) Gibt es das hier? Einstieg ist meist ein Name oder eine
   Kategorie, nicht die Karte. Die Suche führt, der Plan
   antwortet.
2) Auf welcher Etage?
3) Wie komme ich hin? Vor allem vor Ort, wo der Start feststeht.
Dazu die häufigsten Ziele, die kein Shop sind: Toilette, Aufzug,
Ausgang zum Parkhaus, Foodcourt, Information.

Die Optik dient diesen Fragen. Tiefe und Volumen leisten drei
Dinge: Wiedererkennung vor Ort (Atrium, Rolltreppe, gläserner
Aufzug als Anker), Trennung von Fläche und Gang ohne Legende,
Blickführung auf Ziel und Weg. Alles darüber hinaus ist Schmuck.
IM ZWEIFEL GEWINNT LESBARKEIT: kein Effekt darf Kontrast,
Klickfläche oder Schriftgröße kosten. Maßstab ist ein Handy in
der Sonne und, falls Stele, zwei Meter Betrachtungsabstand.
Abnahme: jemand, der das Center nicht kennt, findet ein genanntes
Ziel in unter 20 Sekunden ohne Erklärung. Nicht: sieht
hochwertig aus.

ZUERST FRAGEN, DANN BAUEN. NICHT SOFORT ZEICHNEN.
Es sind keine Felder ausgefüllt. Das ist Absicht.
Ohne bestätigten Steckbrief (Schritt 3) wird nichts gezeichnet
und kein Code geschrieben.

SCHRITT 1: SELBST NACHSCHLAGEN
Steht im Chat ein Centername: Center, Slug, Etagen, Shopzahl,
Eingänge und Farben per cockpitOS-MCP nachschlagen.
Steht kein Name da: Center auflisten, auf die du Zugriff hast,
und auswählen lassen.
Frag NIE nach etwas, das im Cockpit steht oder im Anhang zu
sehen ist. Eine Frage nach dem Slug ist ein Fehler.

SCHRITT 2: GENAU EINE NACHRICHT MIT RÜCKFRAGEN
Höchstens sechs Fragen, nummeriert, je zwei bis drei Antworten,
Standard markiert. Alltagssprache, keine Fachbegriffe, keine
SVG- oder API-Wörter. "weiß nicht" ist immer erlaubt und heißt:
Standard gilt. Eine Antwort wie "1b 2a 3 weiß nicht" muss reichen.
Keine Fragen nacheinander über mehrere Nachrichten.
Sinnvoll sind:
1) Wo läuft der Plan? Website / Website und Stele vor Ort
   (Standard: Website)
2) Sollen Besucher sich einen Weg zum Shop anzeigen lassen?
   ja / nein (Standard: nein bei Website, ja bei Stele)
3) Soll es einen Weg ohne Treppen geben?
   ja / nein / weiß nicht
   (Standard: anbieten, sobald im Plan ein Aufzug zu sehen ist)
4) Was auf dem Bild gehört NICHT zum Center?
   nichts / Nachbargebäude / Parkdeck / anderes (Standard: nichts)
5) Welche Etage zeigt der Anhang, und wie ist die Reihenfolge
   von unten nach oben? (nur wenn nicht ableitbar)
6) Stehen im Plan Flächennummern, die übernommen werden sollen?
   ja / nein / weiß nicht (Standard: übernehmen, wenn lesbar)

SCHRITT 3: STECKBRIEF BESTÄTIGEN LASSEN
Sieben Zeilen: Center, Etagen, Shopzahl, Vorlage, Ort (Website
oder Stele), Weg zeigen, stufenfrei. Dazu eine Zeile
"Stil: neutral, Vorlage {Name} nicht angewendet".
Frag "passt das?". Ein "ja" genügt, danach baust du ohne weitere
Zwischenfragen.
Weicht die Shopzahl im Cockpit von dem ab, was du im Anhang
zählst: in den Steckbrief schreiben, nicht als Frage stellen.
Sagt jemand "mach einfach" oder antwortet nicht: alle Standards
nehmen, bauen, und die Annahmen in der Lieferung auflisten.

SCHRITT 4: ERKENNUNG ZEIGEN, BEVOR DU DIE SVG BAUST
Siehe VORLAGE LESEN. Das ist der zweite und letzte Stopp.
Unklarheiten beim Bauen NICHT einzeln nachfragen, sondern als
UNKLAR ins Inventar schreiben und hier gesammelt vorlegen.

STIL: KEIN PRESET, KEINE EIGENE HANDSCHRIFT
Ist in der Oberfläche eine Design-Vorlage vorausgewählt
(zum Beispiel "Industrial"), ignoriere sie vollständig: keine
Preset-Farben, keine Preset-Schrift, keine Texturen, kein dunkles
Grundthema, keine Metall- oder Beton-Anmutung. Melde in einem
Satz, welche Vorlage aktiv war und dass du sie nicht angewendet
hast.
Drei Ebenen, klar getrennt:
1) Chrome (Tabs, Panel, Buttons, Suche, Liste, Menüs): wird NICHT
   gestaltet. Neutrale Fallbacks aus dem Token-Block, sonst
   nichts. Die Website-Farben kommen später über v0.
2) Karte (Volumen, Schatten, Licht, Material): folgt allein dem
   Abschnitt OPTIK. Ein Preset ändert daran nichts, insbesondere
   nicht Richtung dunkel, technisch oder Blueprint.
3) Vorlagen im Anhang: Grundriss, Skizze und Foto liefern
   ausschließlich Anordnung und Nachbarschaft, nie Gestaltung.
   Eine graue, technische Vorlage macht den Plan nicht grau.
Screenshot der bestehenden Website im Anhang: Du darfst Schrift,
Radius, Abstände und die Fallback-Farben in
lib/centerplan/tokens.ts daran ausrichten, als Startwerte mit
Kommentar "Fallback, wird von v0 ersetzt". Kein Farbwert wandert
dabei in eine Komponente, die Seitenstruktur wird nicht
nachgebaut. Branding aus public-visitor-surface hat Vorrang vor
dem Screenshot.

---

AUFGABE
Baue einen interaktiven Shopping-Center-Lageplan als wartbares,
modulares React/TypeScript für ein bestehendes v0/Next.js-Projekt
(App Router). Kein Ein-Datei-Monolith, kein .js.
Eine Datei = eine Aufgabe, Schnitt genau wie unter DATEIEN.
Der Plan ist EINE SEITE der bestehenden Website (Route
/centerplan), keine eigene Mini-Site: kein eigener Header,
Footer, Logo, keine zweite Navigation.
Shop-Fakten kommen aus dem Cockpit, nicht aus Dummy-Text im Code.
Die Website-Farben kommen später, deshalb keine Markenfarben
hardcoden.

AUSGABEFORM
Ein Codeblock pro Datei, Pfad als erste Zeile im Block, exakt die
Pfade unter DATEIEN. Eine Vorschau in Claude Design ist erlaubt,
die Vorschau ist aber nicht die Lieferung.

EINSTIEG: SUCHE FÜHRT, KARTE ANTWORTET
- Suchfeld ohne Klick sichtbar, am Handy über der Karte, am
  Desktop in der Liste daneben. Nicht hinter einem Lupensymbol
  versteckt.
- Sucht über Shopname, Kategorie und Servicetyp (WC, Aufzug,
  Parkhaus). Tippfehler-tolerant, ab dem zweiten Zeichen.
- Treffer zeigt in einer Zeile: Name, Etage, geöffnet oder
  geschlossen. Auswahl markiert die Fläche und wechselt die
  Etage mit.
- Kein Treffer: nicht "keine Ergebnisse". Stattdessen die
  nächstbeste Kategorie anbieten ("Parfümerie: 2 Shops") und das
  Ereignis melden (siehe MESSEN).
- Schnellziele als Schaltflächen über oder neben der Suche:
  Toilette, Aufzug, Parkhaus, Foodcourt, Information. Nur
  anzeigen, was in der SVG und im Cockpit existiert.
- Kategorien zum Stöbern, wenn Kategorien im Cockpit gepflegt
  sind. Nicht erfinden.

DATEN: BAUZEIT UND LAUFZEIT TRENNEN
Beim Bauen: cockpitOS-MCP zum Nachschlagen und Gegenprüfen.
Ergebnisse davon NIE als Konstanten in den Code schreiben.
Im Code: nur diese Aufrufe, zur Laufzeit, Basis
https://dashboard.cockpit-os.de (wenn die Website eine ENV-Basis
hat, die nutzen, sonst diese URL):
1) GET /api/centers/by-slug/{SLUG}
   id = centerId (niemals eine floorId aus einer Edit-URL)
2) GET /api/centers/{centerId}/public-visitor-surface
   data.center (baseColor, accentColor, secondaryColor)
   data.centerplan (hoverColorSvg, initialViewMode, showLogosOnPlan)
   data.v0Integration.centerplan
   data.kiosk.touchscreens[] und data.v0Integration.kiosk
   wenn Stele
   data.tracking (umamiWebsiteId) für MESSEN
3) GET /api/wayfinding/floors?centerId={centerId}
   erst mit omitMapSvg=true die Etagenliste, danach die aktive
   Etage mit mapSvg nachladen
   floors[]: mapSvg (String), mapImage, mapLocations[], enable3D,
   floorNumber
4) GET /api/centers/{centerId}/shops?publicWebsite=true
   &status=Aktiv&limit=5000
Shop-Namen, Zeiten, Logos, Kategorien NUR daraus.
mapSvg wird inline eingesetzt und muss vorher gesäubert werden:
kein <script>, keine on*-Attribute, keine fremden href/src-Hosts,
IDs außerhalb der Konvention ignorieren.
Reihenfolge: erst API, nur bei leerem oder fehlerhaftem mapSvg die
mitgelieferte Fallback-SVG. Eine Funktion, nicht zwei Wege.
VERBOTEN: website-config, AgencyOS, Secrets, erfundene Shop-Listen.

DÜNNE DATEN (ehrlich bleiben)
Ein Plan mit vielen nicht zugeordneten Flächen ist schlechter als
eine Liste, weil er Vollständigkeit behauptet.
- Sind weniger als 60 Prozent der Flächen einem Shop zugeordnet:
  Liste und Suche stehen vorn, die Karte ergänzt. Am Desktop
  Sidebar offen, am Handy Liste zuerst.
- Nicht zugeordnete Flächen bleiben neutral, ohne Label und ohne
  Klick-Versprechen (kein Cursor-Pointer, kein Hover-Ring).
- Wird eine solche Fläche doch angetippt: "Diese Fläche ist im
  Cockpit noch keinem Shop zugeordnet" plus svgId. Kein
  Fragezeichen, kein erfundener Name.
- Den Anteil in der Lieferung nennen, damit die Redaktion weiß,
  was noch fehlt.

VORLAGE LESEN (Erkennung, vor dem Zeichnen)
Erkenne selbst, was für eine Vorlage vorliegt, und sag es:
- Vektor (PDF, AI, SVG): NICHT neu zeichnen. Vorhandene Pfade
  übernehmen, aufräumen, gruppieren, IDs nach Konvention setzen.
- Raster (Foto, Scan, Screenshot): erkennen wie unten.
- Nichts: plausible Anordnung anlegen, ALLES als UNKLAR ins
  Inventar, in der Lieferung oben deutlich schreiben, dass die
  Geometrie im Center gegenzuprüfen ist, bevor Shops zugeordnet
  werden.
Stimmt die Angabe der Redaktion nicht mit dem überein, was du
siehst: widersprechen, nicht still übernehmen.
Priorität bei schlechter Vorlage: Anzahl und Nachbarschaft der
Flächen sind verbindlich, exakte Proportionen nicht. Eine Fläche
zu wenig ist ein Fehler, eine Fläche 20 Prozent zu breit nicht.
Nummerierung:
- Sind Mietflächennummern lesbar, übernimm sie (Fläche 1.07 wird
  shop-EG-107). Stabilste Kennung, hält bei Umbauten.
- Sonst deterministisch: vom Haupteingang aus im Uhrzeigersinn,
  dreistellig mit führender Null.
- Shop-Namen musst du nicht lesen, die kommen aus dem Cockpit.
  Anzahl über MCP gegenprüfen, Abweichung melden, nicht glätten.

STOPP: ERKENNUNG ZEIGEN
Bevor du die Produktions-SVG baust, liefere nur:
a) Inventar pro Etage als Tabelle: id, Typ, Lage in Worten,
   Nachbarn links und rechts, Quelle (Vorlage, Cockpit, geraten),
   Sicherheit (sicher / unklar). Dazu die gefundene Anzahl gegen
   die Cockpit-Shopzahl und was sichtbar, aber nicht zuzuordnen
   war.
b) Erkennungs-Vorschau: deine Flächen halbtransparent über der
   Vorlage, mit IDs beschriftet, als
   public/centerplan/_preview-{etage}.html
   Dort zusätzlich mall-floor eingefärbt und #routes als dünne
   Linie einblenden. Das ist der einzige Ort, an dem beides
   sichtbar ist, und der einzige Moment, in dem jemand merkt,
   dass ein Servicegang im Netz hängt. Im Produktivplan bleibt
   beides unsichtbar.
c) Übergangs-Matrix über alle Etagen (siehe unten).
Dann fragen, ob eine Fläche falsch sitzt. Erst nach Antwort oder
einem "passt" die SVG und den Code bauen.

ERKENNEN, WAS FÜR DIE WEGE ZÄHLT (Pflicht, auch ohne Weg-UI)
Beim Inventar mitsuchen und mit den IDs unten eintragen:
- Hindernisse: Brunnen, Atrium, Loch, Säule, Pflanzkübel, festes
  Mobiliar, Absperrung, Rolltreppen-Schacht, Galerieöffnung.
- Übergänge: Aufzug, Treppe, Rolltreppe, Rampe, Brücke, Passage.
- Eingänge und Ausgänge inklusive Parkhaus, mit data-name.
- WC, Info, Geldautomat, Info-Stele ("Sie sind hier").
- Shop-Türen (nicht die Dachmitte), Besucherwege gegen
  Servicegänge.
Fehlt ein Aufzug im Material: das sagen, keinen erfinden.
Unklar: als UNKLAR markieren, nicht raten und nicht weglassen.

BEGEHBAREN RAUM ZUERST BESTIMMEN
Gänge sind in Plänen nicht gezeichnet, sie sind das, was übrig
bleibt. Arbeite in dieser Reihenfolge, nicht umgekehrt:
1) Außenkontur des Centers festlegen.
2) Abziehen, was nicht begehbar ist: Shopflächen, Hindernisse,
   Atriumlöcher, Technik- und Servicebereiche. Das Ergebnis ist
   mall-floor-{ETAGE}, ein zusammenhängender Bereich mit Löchern.
3) Die Mittellinie von mall-floor ist #routes. Kreuzungen werden
   Knoten, Sackgassen enden an einer Tür oder einem Portal.
   Mindestabstand zur Wand halten, das Netz klebt nicht an
   Kanten.
Daraus folgt automatisch: keine Linie durch ein Shop-Dach, keine
Linie außerhalb des begehbaren Raums, kein Gang ohne Netz.

GANG ODER NICHT GANG
Ein Besuchergang ist durchgehend, verbindet mindestens zwei
Eingänge oder Portale, und die Shops liegen mit ihrer offenen
Seite daran.
NICHT ins Netz gehören: Servicegänge hinter den Läden (schmaler,
ohne Anschluss an einen öffentlichen Eingang, führen zu
Anlieferung oder Technik), Parkhausrampen, Außenflächen und
Durchgänge zu Nachbargebäuden, die nicht zum Center zählen.
Unklar, ob öffentlich: als UNKLAR ins Inventar, nicht still
aufnehmen und nicht still weglassen.

ÜBERGÄNGE FINDEN UND BELEGEN
Vertikal: Aufzug, Treppe, Rolltreppe, Rampe.
Horizontal: Tür, Windfang, Passage, Brücke, Durchgang zum
Parkhaus. Beide Arten brauchen ein Portal und eine Anweisung,
weil der Besucher etwas tun muss.
Deckungstest, verbindlich: ein Portal gilt erst, wenn an
derselben Koordinate auf der Nachbaretage etwas liegt. Fehlt es
dort, hast du zwei Möglichkeiten: projizieren und als UNKLAR
melden, oder sagen, dass dieser Etagenwechsel nicht belegt ist.
Erfinden ist keine Möglichkeit.
Pro Portal angeben, welche Etagen es verbindet, ob stufenfrei,
und bei Rolltreppen die Richtung. Nicht jeder Aufzug hält
überall, Rolltreppen fahren in eine Richtung und stehen meist als
Paar. Ohne diese Angabe rechnet das Cockpit Wege, die es nicht
gibt.

TÜREN AUS DER GEOMETRIE ABLEITEN
Der p-shop-Anschluss liegt an der Kante, an der die Shopfläche an
mall-floor grenzt, mittig auf dieser Kante. Grenzen mehrere
Kanten an (Eckladen), setze zwei Anschlüsse. Nie die Dachmitte.
Ist die Tür in der Vorlage eingezeichnet, hat sie Vorrang vor der
Ableitung.

ÜBERGANGS-MATRIX MITLIEFERN (Teil des Inventars)
Eine Tabelle über alle Etagen:
  Portal-ID | Typ | verbindet Etagen | stufenfrei | Richtung |
  Quelle (Vorlage, projiziert, unklar)
Daraus sieht die Redaktion sofort, ob eine Etage nur über Treppen
erreichbar ist.

ERREICHBARKEIT PRÜFEN, BEVOR DU ABGIBST
- Jeder Shop ist von jedem Eingang aus über das Netz erreichbar.
- Jede Etage hängt über mindestens ein Portal am Rest.
- Dieselbe Prüfung noch einmal nur mit stufenfreien Segmenten und
  elevator- oder ramp-Portalen.
Isolierte Flächen oder Etagen benennen, nicht durch eine
zusätzliche Linie kaschieren. Kommt eine Etage stufenfrei nicht
in Frage, gehört das in die Lieferung, nicht in eine erfundene
Verbindung.

ETAGEN UND IDS (verbindlich, ein System)
Etagen-Token, groß, ohne Punkt und Leerzeichen:
  UG2, UG1, EG, OG1, OG2, OG3
Dateinamen dazu klein: ug1.svg, eg.svg, og1.svg
Zahlen im Token mit führender Null (01), Shop-Nummern dreistellig.

  <g id="shops">
    shop-{ETAGE}-{nnn}
  <g id="services">
    service-{ETAGE}-{wc|info|atm|parking}-{nn}
    service-{ETAGE}-{aufzug|treppe|rolltreppe|rampe}-{nn}
  <g id="entrances">
    entrance-{ETAGE}-{nn}   plus data-name="Haupteingang"
  mall-floor-{ETAGE}        begehbarer Boden, ein path/polygon
  obstacle-{ETAGE}-{name}   Route darf nicht hindurch

Anschlüsse ans Wegenetz (kurze line in #routes).
IDs EXAKT so — der Routen-Import im Cockpit erwartet dieses Muster,
nicht Etage in der Mitte:
    p-shop-{ETAGE}-{nnn}       an der Tür, nicht in der Dachmitte
    p-service-{ETAGE}-{typ}-{nn}
    p-stele-{n}
Portale, Nummer identisch über alle Etagen:
    pf-stairs{n}-{ETAGE}       data-type="stairs"
    pf-escalator{n}-{ETAGE}    data-type="escalator"
    pfb-elevator{n}-{ETAGE}    data-type="elevator"   stufenfrei
    pfb-ramp{n}-{ETAGE}        data-type="ramp"       stufenfrei

Regeln dazu:
- Alle Etagen benutzen dieselbe viewBox, denselben Nullpunkt und
  denselben Maßstab. Ohne das liegen Portale nicht übereinander.
- Portale physisch übereinander, gleiche Nummer, nicht spiegeln.
  Beispiel Aufzug 1: pfb-elevator1-UG1, pfb-elevator1-EG,
  pfb-elevator1-OG1.
- Nie eine UUID als SVG-id. Nie zwei Flächen mit derselben id.
- Jede klickbare Fläche ist ein eigenes path/polygon/g mit id
  (Dach oder Grundfläche, nicht der Schatten-Layer).
- Dekor, Logos, Schatten und #routes: pointer-events: none.
- Keine Shop-Namen und keine Logos in die SVG zeichnen.
- In jede SVG ein <metadata>-Block: Plan-Version, Datum, Etage,
  höchste vergebene Shop-Nummer. Das braucht der Änderungslauf.
- Konvention und Sonderfälle:
  https://docs.cockpit-os.de/centerplan/svg-struktur
  Im Zweifel gilt diese Seite, nicht dieser Kasten.

OPTIK (dient dem Zweck, siehe oben)
- Shops als Volumen (Dach plus sichtbare Fassade). Kein flacher
  Bauplan, kein Blueprint, kein Cartoon, kein dunkles Thema.
- Grafik isometrisch von oben, 25 bis 35 Grad, fast
  orthografisch.
- Gänge klar tiefer und anders als Dächer. Aufzüge und
  Rolltreppen als erkennbares Highlight, weil sie vor Ort die
  Ankerpunkte sind.
- Dächer groß genug zum Klicken, eine erkennbare Dachfläche pro
  Shop.
- Kontrast: Text auf Fläche mindestens 4,5:1, Auswahl und Route
  heben sich auch für Menschen mit Farbsehschwäche ab, also nicht
  nur über Farbe, sondern zusätzlich über Helligkeit oder Kontur.
- Lesbarkeit darf Gänge begradigen und Proportionen glätten, die
  Nachbarschaft bleibt.
- Effekte, die Kontrast, Klickfläche oder Schriftgröße kosten,
  entfallen. Kein Glassmorphism, keine Dauer-Animation, keine
  Verschattung über Labels.

LICHT UND SCHATTEN (gebacken, nicht gerechnet)
Ziel ist glaubwürdige Räumlichkeit, nicht Fotorealismus. Alles
wird als Geometrie und Verlauf gezeichnet, nicht als Filterkette
gerechnet. Höchstens ein globaler weicher Schatten-Layer, keine
Filter pro Fläche. Filter kosten auf einfachen Handys und auf
Signage-Playern spürbar Leistung und sind beim Säubern des
mapSvg eine zusätzliche Fehlerquelle.

Ein Lichteinfall für alles: eine Richtung, gleicher Winkel auf
allen Etagen, alle Schatten parallel, warmes indirektes Licht.
Konsistenz erzeugt mehr Realismus als Weichheit. Der häufigste
Fehler ist, dass jeder Block sein eigenes Licht hat.

Vier Effekte, in dieser Wichtigkeit:
1) Kontaktschatten: schmaler dunkler Saum am Fuß jedes Volumens,
   kurz und weich. Der stärkste Tiefenreiz, wichtiger als ein
   langer Schlagschatten.
2) Ambient Occlusion: Verlauf entlang der Gangkanten und in
   Innenecken, zur Gangmitte hin heller. Lässt Gänge tiefer
   wirken, ohne sie einzufärben.
3) Bounce Light: schmale, warme Aufhellung an der Unterkante der
   Fassaden, getönt wie der Boden. Ohne das wirken Volumen
   ausgeschnitten.
4) Kantenlicht: leichte Aufhellung der oberen Dachkante gegen die
   Fassade.
Glas an Aufzügen und Rolltreppen: leichter Verlauf mit heller
Kante, keine graue Fläche. Boden mit feiner Struktur, sehr
zurückhaltend.

Grenzen, die der Lesbarkeit dienen:
- Alle Dachflächen liegen in einem engen Helligkeitsband, damit
  Logos und Namen überall lesbar bleiben. Schatten leben in den
  Gängen, nicht auf den Beschriftungsflächen.
- Schatten bleiben kurz und fallen nicht auf Nachbardächer. Zwei
  Läden dürfen optisch nie zu einem verschmelzen.
- Keine Spiegelungen, keine Tiefenunschärfe, keine
  Umgebungsverschattung über Labels.
- Am Handy und an der Stele darf der Schatten-Layer weicher und
  schwächer sein. Verboten bleibt der Wechsel auf einen flachen
  Strichplan.

Echtes Rendering (Global Illumination, V-Ray, Blender) ist in der
SVG nicht möglich und auch nicht das Ziel. Wer eine gerenderte
Optik braucht, nimmt den Hybrid-Weg: gerendertes Bild als
Hintergrund, unsichtbare Polygone darüber. Das ist ein eigener
Ablauf (Hybrid-Seite), und wird hier nicht halb nachgebaut.

LOGIK
- Etagen-Tabs aus floors[] oder aus den erzeugten Etagen.
- Karte inline, nicht als totes <img> ohne Klick-Layer.
- Klick und Tap: Delegation auf path/g/polygon/rect, dann id,
  dann mapLocations, dann shop.id oder service.id. Nie über den
  Anzeigenamen auflösen. Schatten-Layer nie als Treffer.
- Hover am Desktop: ein mousemove auf dem SVG-Root plus
  elementFromPoint, eine hoveredSvgId, auf rAF gedrosselt.
  Nicht mouseover auf jedes Kind-Element.
- Am Handy ersetzt Tap den Hover. Kein Zustand, der nur per Hover
  erreichbar ist.
- Klick öffnet ein Panel auf DIESER Seite. Link-Ziel:
  /shops/{slug|id} oder /services/{slug|id}, nie das Dashboard.
- Panel zeigt zuerst, was gefragt war: Name, Etage, geöffnet oder
  geschlossen mit heutigen Zeiten, Kategorie. Danach der Rest.
- Deep-Links: ?floor=, ?shop={uuid}, ?from= und ?to= für einen
  Weg. Beim Laden markieren und Panel öffnen, Auswahl schreibt
  die URL per replaceState mit.
- Kleine Bewegung ist kein Klick (Schwelle 8 px).
- Zustände ausbauen: Laden, Fehler, Center nicht gefunden, keine
  Etage, mapSvg leer.
- Tastatur und Screenreader: Flächen fokussierbar mit aria-label
  aus dem Cockpit-Namen, Panel per Esc schließen, Fokus fangen,
  die Liste ist die textliche Alternative zur Karte.

LABELS AUF DER FLÄCHE
- Overlay über der Dachfläche, nicht in die SVG gezeichnet.
  Quelle: shops[] (logo/logoUrl, name) über das Mapping svgId zu
  Shop. Nie erfundene Namen, nie Fake-Logos.
- Genug Platz und Bild vorhanden: Logo zentriert, nicht verzerrt.
- Kein Logo oder Fläche zu schmal: kurzer Name, eine Zeile.
- Zu klein oder weit rausgezoomt: Label ausblenden, höchstens 40
  gleichzeitig. Reinzoomen zeigt mehr.
- Ausgewähltes Ziel und Schnellziele (WC, Aufzug, Parkhaus)
  behalten ihr Label auch in der Übersicht. Sie sind der Grund,
  warum jemand hinschaut.
- showLogosOnPlan aus data.centerplan beachten.
- Overlay pointer-events: none. Ohne Zuordnung kein Label.

SUCHE UND LISTE (ein- und ausblendbar)
Desktop: Liste mit Suche neben der Karte, Breite 280 bis 360 px,
über eine sichtbare Schaltfläche auf- und zuklappbar, Zustand in
localStorage. Zugeklappt nutzt die Karte die volle Breite, ein
sichtbarer Button holt die Liste zurück, nicht nur Esc.
Handy: dieselbe Liste als Sheet. Standard zugeklappt, außer die
Zuordnung liegt unter 60 Prozent, dann Liste zuerst.
Auswahl in der Liste setzt das Ziel. Sidebar schließen schließt
nicht das Detail-Panel und umgekehrt.
Kein zweites Shop-Menü erfinden.
Datei: components/centerplan/shop-list-sidebar.tsx
Datei: components/centerplan/search-bar.tsx
Datei: components/centerplan/quick-targets.tsx

KAMERA (eine Regel, gilt überall)
Die SVG-Grafik wird NIE gedreht, gespiegelt oder in Wegrichtung
neu gezeichnet. Schatten und Volumen bleiben, wie gebaut.
- Mausrad und Trackpad: weich zoomen, mit Dämpfung, keine Stufen.
- Linke Taste ziehen: leicht orbitieren um den Blickpunkt.
  Isometrie 25 bis 35 Grad halten.
- Rechte oder mittlere Taste oder Space plus Ziehen: verschieben.
- Handy: ein Finger verschiebt, zwei Finger zoomen weich. Kleine
  Bewegung bleibt Tap.
- Grenzen: höchstens Faktor 3,5 gegenüber der Gesamtansicht,
  mindestens 0,8.
- Ohne Ziel: ganzes Center sichtbar, nicht an eine Fläche fahren.
- Mit Ziel und ohne Start: weich auf das Ziel zentrieren, Zoom
  innerhalb der Grenzen, Umgebung sichtbar lassen.
- Mit Start UND Ziel: Rahmen ist die Bounding-Box beider Punkte
  plus Rand, beide bleiben im Bild, auch bei Nachbarflächen mit
  Mindest-Padding.
- Weg über mehrere Etagen: auf der sichtbaren Etage den Abschnitt
  rahmen (Start zu Portal oder Portal zu Ziel).
- Leichter Navi-Dreh NUR an der Kamera, wenn Start und Ziel fest
  stehen: höchstens plus/minus 20 Grad, EIN weicher Move, dann
  halten. Nicht der Linie hinterherdrehen. Nutzer-Orbit bricht
  den Auto-Dreh ab.
- prefers-reduced-motion: kein Flug, kein Dreh, harter Schnitt.
Logik in lib/centerplan/orbit-camera.ts (maxYaw), nicht in die
View. VERBOTEN: Heading-up wie im Autonavi, Dauerrotation,
Sprünge um 90 oder 180 Grad, Kirmes, Rotation in die Grafik.

MOBILE
- Touch-Ziele mindestens 44 x 44 CSS-px. Etagen-Tabs scrollen
  horizontal und verdecken den Plan nicht.
- Shop-Detail als Sheet von unten, am Desktop seitlich.
- Plan füllt die Breite, sichtbare Kartenhöhe 55 bis 70 vh,
  safe-area beachten.
- Startansicht: ganzes Center. Doppeltipp setzt das Ziel.
- Ein Schatten-Pass, keine Partikel, keine Dauer-Animation.
- Kein Hover-only, kein horizontaler Scroll der ganzen Seite.

STELE / SIGNAGE (nur wenn Frage 1 mit Stele beantwortet wurde)
Dieselbe Geometrie, andere Anwendung. Als Variante derselben
Komponente über eine Property kiosk={true}, kein zweites Projekt
und nicht die veraltete Signage-App.
- Hochformat. Bedienung im unteren Drittel, das obere Drittel ist
  nicht erreichbar und zeigt nur an.
- Touch-Ziele mindestens 64 px, Grundschrift ab 24 px, Kontraste
  für zwei Meter Abstand.
- "Sie wären hier" ist fest und kommt aus
  data.kiosk.touchscreens[] (floorNumber, Standort) bzw. p-stele-*,
  keine Startauswahl. Damit hat jede Route sofort einen Sinn.
- Schnellziele als große Kacheln über allem: Toilette, Aufzug,
  Parkhaus, Foodcourt, Information.
- Kein Hover, keine Sidebar-Logik aus dem Desktop.
- Rücksetzen nach 60 Sekunden ohne Eingabe: zurück in die
  Übersicht, Suche leeren, Panel schließen.
- Idle-Zustand ist nicht schwarz: Übersicht, Öffnungszeiten,
  Schnellziele.
- Weg mitnehmen: QR auf die Website-Deep-Link derselben Seite
  mit ?from= und ?to= (gleicher Host). Wenn die Website bereits
  Handoff-QR (Companion) hat, die nutzen — keine fremden
  Shortener, keine erfundenen QR-APIs.
- Bildschirm-Einbrennen vermeiden: keine dauerhaft statische
  Fläche mit hohem Kontrast an derselben Stelle.
Datei: components/centerplan/kiosk-shell.tsx

WEGENETZ (Pflicht in jeder Etage, sichtbare UI nur auf Wunsch)
Auch ohne Weg-UI werden Netz, Portale und erkannte Elemente
angelegt. Sonst kann später niemand einen Weg rechnen.
1) <g id="routes"> ist die Mittellinie von mall-floor, siehe
   BEGEHBAREN RAUM ZUERST BESTIMMEN (line, path, polyline).
   Endpunkte stoßen an Kreuzungen an (5 px Toleranz).
   visibility: hidden plus pointer-events: none.
   NICHT display:none, sonst ist die Geometrie nicht messbar.
   Nie als Linien über dem Plan zeigen. Nie durch Shop-Flächen,
   Löcher im mall-floor, obstacle-* oder Servicegänge.
2) Optional <g id="routes-accessible">: nur stufenfreie Gänge.
   Fehlt es, gilt: #routes ohne Segmente mit
   data-type="stairs|escalator".
3) Anschlüsse und Portale wie oben unter IDS. Jeder Shop braucht
   einen p-shop-Anschluss, sonst endet die Linie in der
   Dachmitte.
4) Etagenwechsel: Netz endet AM Portal. Route bis zum Portal,
   dann die Anweisung, dann Etage wechseln, dann weiter vom
   selben Portal. Immer sagen, was der Mensch tun soll, in
   Alltagssprache:
   Aufzug:      "Nimm den Aufzug {Name} ins {Ziel-Etage}"
   Treppe:      "Nimm die Treppe {Name} ins {Ziel-Etage}"
   Rolltreppe:  "Nimm die Rolltreppe ins {Ziel-Etage}"
   Rampe:       "Nimm die Rampe ins {Ziel-Etage}"
   Tür/Passage: "Geh durch die Tür {Name}"
   An drei Stellen: als Marker mit Text am Portal, als eigener
   Satz im Weg-Panel, und der Hinweis bleibt stehen, bis die
   Zieletage aktiv ist. Mehrere Wechsel: Schritte nacheinander.
   Nie die Etage still umschalten.
5) Stufenfrei: Schalter "Stufenfreier Weg", Standard an, wenn so
   beantwortet. Dann POST mit avoidStairs: true,
   preferElevator: true,
   accessibilityRequirements: { wheelchairAccess: true }.
   Treppen und Rolltreppen meiden, nur elevator- und
   ramp-Portale. Gibt es keinen: "Kein stufenfreier Weg zu diesem
   Ziel" sagen, keine Linie über Treppen erfinden. Den Schalter
   auch dann anbieten, wenn mindestens ein Aufzug in der SVG
   liegt.
6) Weg-UI: Panel "Weg hierhin", Start ist ein Eingang (Standard
   aktuelle Etage), an der Stele der feste Standort, oder ein
   Shop. Eine Overlay-Linie in --cp-accent, nie das ganze Netz.
   Dazu die Schritte als Text, damit man sie ohne die Karte
   lesen kann. floorChanges der API: Teilstücke pro Etage,
   Etagen-Tab folgt, am Wechsel immer die Anweisung.
   429: kurz warten und erneut. Leere Antwort: "Weg gerade nicht
   verfügbar".
7) Routing-Daten:
   GET /api/centers/{centerId}/entrances, id = startWaypointId
   POST /api/wayfinding/routing
     { startWaypointId, endLocationId }   Eingang zu Shop
     { startLocationId, endLocationId }   Shop zu Shop
   endLocationId ist mapLocations[].id (UUID), nie eine svgId.
   Antwort: waypoints, connections, floorChanges, totalDistance,
   dazu wheelchairAccessible und hasStairs auswerten.
   Erst POST routing (setzt "Routen aus SVG erzeugen" im Cockpit
   voraus). Fallback auf Dijkstra über #routes bei 404, 5xx oder
   leeren connections, mit Timeout und einem Wiederholungsversuch.

MESSEN (Rückkanal)
Genau vier Ereignisse, anonym, ohne personenbezogene Daten:
  centerplan_search_no_result   { query, floor }
  centerplan_location_opened    { svgId, shopId|null, floor }
  centerplan_route_requested    { fromId, toId, stufenfrei }
  centerplan_floor_changed      { from, to }
Über das vorhandene Umami der Website (trackEvent / vorhandenes
Analytics-Snippet). Kein zweites Werkzeug, keine eigene
Datenbank, kein MCP-Schreibaufruf aus dem öffentlichen Plan.
Fehlt das Snippet: Ereignisse vorbereiten, aber nicht erfinden.
Wozu: oft angetippte, nicht zugeordnete Flächen und Suchen ohne
Treffer zeigen der Redaktion die Lücke.

DESIGN-TOKENS
Chrome (Tabs, Buttons, Panel, Suche, Liste, Dropdowns, Rahmen,
Hover) nur über CSS-Variablen, einmal am Root gesetzt, Werte
zuerst aus public-visitor-surface, sonst neutraler Fallback.
Außerhalb von lib/centerplan/tokens.ts steht KEIN Farbwert und
keine feste Farbklasse. Die Komponente muss auch funktionieren,
wenn die Tokens von außen schon gesetzt sind.
  --cp-accent     accentColor            Fallback #111111
  --cp-accent-fg  Schrift auf Akzent     Fallback #ffffff
  --cp-bg         Fläche hinter Controls Fallback #ffffff
  --cp-fg         Text                   Fallback #111111
  --cp-border     Rahmen                 Fallback rgba(0,0,0,.12)
  --cp-muted      Nebentext              Fallback #6b6b6b
  --cp-radius     Radius                 Fallback 8px
  --cp-font       data.design.fontFamily sonst erben
  --cp-hover      hoverColorSvg          sonst --cp-accent
Dachfarben, Volumen und Schatten der Grafik sind Optik, nicht
Chrome. Tokens färben Tabs, Panel, Hover-Ring und Menüs, sie
bleichen den 3D-Look nicht aus und dunkeln ihn nicht ab.
VERBOTEN: fremde Marken-Hex-Werte, ein zweites Farbsystem,
Glassmorphism als Standard, native Browser-Dropdowns.

AUSWAHLLISTEN
Nie ein natives <select> und kein appearance:none auf einem
echten Select. Stattdessen ein eigenes Menü (Button plus Popover)
mit den Tokens oben, gleiche Schrift und Radien wie Tabs und
Panel, Tastatur mit Pfeilen, Enter und Esc, Rolle
listbox/option, am Handy als Sheet mit Einträgen ab 44 px, an der
Stele ab 64 px.
Eine Komponente für alles: components/centerplan/select-menu.tsx

DATEIEN (Pflicht-Schnitt, TypeScript, zum Mergen)
lib/centerplan/types.ts
lib/centerplan/load-data.ts
lib/centerplan/tokens.ts
lib/centerplan/svg-id.ts            Parsen und Bauen der IDs
lib/centerplan/build-svg-id-map.ts
lib/centerplan/orbit-camera.ts
lib/centerplan/routing.ts
lib/centerplan/search.ts            Suche, Kategorien, Synonyme
lib/centerplan/analytics.ts         die vier Ereignisse
lib/centerplan/state.ts             Reducer und Selektoren
lib/centerplan/strings.ts           alle sichtbaren Texte
components/centerplan/centerplan-view.tsx
components/centerplan/plan-view-2d.tsx
components/centerplan/floor-tabs.tsx
components/centerplan/label-overlay.tsx
components/centerplan/search-bar.tsx
components/centerplan/quick-targets.tsx
components/centerplan/shop-detail-sheet.tsx
components/centerplan/shop-list-sidebar.tsx
components/centerplan/route-overlay.tsx
components/centerplan/floor-change-cue.tsx
components/centerplan/select-menu.tsx
components/centerplan/kiosk-shell.tsx   nur bei Stele
app/centerplan/page.tsx     nur den Plan, Root-Layout erben
app/centerplan/loading.tsx
app/centerplan/error.tsx
public/centerplan/{eg,og1}.svg          Fallback und Upload
public/centerplan/ids.{etage}.json      Flächenliste maschinenlesbar
public/centerplan/_preview-{etage}.html Prüfmittel, nicht produktiv
Hinweise: useSearchParams in Suspense, Logo-Hosts in
next.config remotePatterns eintragen.

LIEFERUNG
1) Funktionierender Plan: Suche, Schnellziele, Etagen, Klick und
   Tap, Liste auf und zu, Panel, Labels, weiche Kamera, Desktop
   und Handy, bei Bedarf Stele.
2) SVG pro Etage zum Hochladen ins Dashboard.
3) ids.{etage}.json plus lesbare Liste: id, Typ, was gemeint ist.
4) Inventar pro Etage: gefunden, fehlt, unklar. Dazu Netz,
   Türanschlüsse, Portale, mall-floor, Hindernisse.
5) Übergangs-Matrix über alle Etagen plus das Ergebnis der
   Erreichbarkeitsprüfung, einmal normal und einmal stufenfrei.
   Isolierte Flächen oder Etagen ausdrücklich benennen.
6) Anteil zugeordneter Flächen, damit die Redaktion die Lücke
   sieht.
7) README in acht Zeilen: welche Dateien nach v0, welche SVG ins
   Dashboard, dass die Tokens von der Website kommen, ob Weg-UI
   und Stele an sind.
8) Liste der getroffenen Annahmen, falls ohne Antwort gebaut
   wurde, plus der Satz, welche Design-Vorlage ignoriert wurde.

SELBSTPRÜFUNG VOR DER ABGABE (alles ja, sonst nachbessern)
[ ] Ein Ortsfremder findet ein genanntes Ziel in unter 20
    Sekunden: Suche sichtbar, Treffer nennt die Etage, Fläche
    wird markiert.
[ ] Toilette, Aufzug, Parkhaus und Foodcourt sind ohne Tippen
    erreichbar, sofern vorhanden.
[ ] Keine Design-Vorlage der Oberfläche übernommen, kein dunkles
    Grundthema, keine Preset-Schrift, keine Textur am Chrome.
[ ] Kein Effekt verdeckt Labels oder senkt den Kontrast unter
    4,5:1.
[ ] Keine zwei Flächen mit derselben id, keine UUID als id.
[ ] Alle Etagen: gleiche viewBox, Portale mit gleicher Nummer
    liegen übereinander.
[ ] Jeder shop-* hat einen p-shop-*-Anschluss am Netz, an der
    Kante zu mall-floor und nicht in der Dachmitte.
[ ] mall-floor deckt jeden Besuchergang ab und enthält keine
    Shopfläche, kein Hindernis und keinen Servicegang.
[ ] Jedes Portal ist auf beiden Etagen belegt oder als UNKLAR
    gemeldet, mit Angabe der bedienten Etagen.
[ ] Erreichbarkeit geprüft, einmal normal und einmal stufenfrei.
    Isolierte Flächen oder Etagen sind benannt.
[ ] Ein Lichteinfall für alle Flächen und Etagen, Schatten kurz,
    keine zwei Dächer verschmolzen, Labels liegen auf gleichmäßig
    hellen Flächen.
[ ] #routes ist unsichtbar und führt nicht durch Flächen, Löcher
    oder Hindernisse.
[ ] Kein Shop-Name und kein Logo in der SVG.
[ ] Kein Farbwert außerhalb von tokens.ts, kein natives <select>.
[ ] Dateischnitt exakt wie oben, kein Header, kein Footer.
[ ] Kamera dreht die Grafik nicht, Zoomgrenzen greifen,
    Navi-Dreh höchstens plus/minus 20 Grad, einmal, dann ruhig.
[ ] Bedienbar am Handy: Tap statt Hover, Ziele ab 44 px.
[ ] Bei Stele: Hochformat, Bedienung unten, Ziele ab 64 px,
    Rücksetzen nach Inaktivität, QR zum Mitnehmen.
[ ] Inventar und Erkennungs-Vorschau liegen bei.
[ ] Keine erfundenen Shop-Namen, unzugeordnete Flächen sagen das.

Kasten 2: Bestehenden Centerplan ändern

Wohin: in denselben Claude-Design-Chat, in dem der Plan gebaut wurde. Nicht „New project“, nicht in v0.

Kasten kopieren, in einem Satz dazuschreiben, was sich ändert. Beispiel: „Die Fläche neben dem Bäcker wird geteilt, sonst bleibt alles.“ Du musst keine ID heraussuchen, Claude sucht die Fläche und nennt sie dir zur Bestätigung. Liegt der alte Plan nicht mehr im Chat, häng ihn an.

Ab hier für Claude

Den Kasten nicht kürzen.

ZUERST KLÄREN, DANN ÄNDERN.
Es ist nichts ausgefüllt. Das ist Absicht.

SCHRITT 1: ALTEN STAND HOLEN
Liegt der bisherige Plan im Chat, benutze ihn. Sonst frag einmal
nach der aktuellen SVG oder einem Screenshot und zeichne nichts
neu, solange du ihn nicht hast.
Center, Slug, Etagen und Shops per cockpitOS-MCP nachschlagen,
nicht erfragen.

SCHRITT 2: ÄNDERUNG VERSTEHEN
Die Beschreibung kommt in Alltagssprache ("die Fläche neben dem
Bäcker wird geteilt"). Finde die gemeinte Fläche selbst, nenne
die gefundene id zurück und lass bestätigen.
Höchstens drei Rückfragen, in einer Nachricht, mit Standard:
betroffene Etage, ob sonst alles bleibt, ob Weg zeigen und
stufenfrei unverändert gelten.

SCHRITT 3: ÄNDERN
Du änderst NUR die Geometrie der genannten Stellen. Zweck,
Logik, Dateischnitt, Token-Namen und ID-Konvention bleiben.

REGELN
- Stil nicht anfassen: keine Design-Vorlage der Oberfläche
  anwenden, keine neue Schrift, keine neuen Farben, kein dunkles
  Thema. Optik und Tokens bleiben, wie sie im Anhang und im
  Projekt stehen.
- Jede Fläche, die nicht betroffen ist, behält ihre id.
- Neue Flächen bekommen die nächste freie Nummer derselben
  Konvention. Die höchste vergebene Nummer steht im
  <metadata>-Block der alten SVG und in ids.{etage}.json.
- Entfallene ids nicht wiederverwenden, im Diff als entfernt
  markieren.
- Topologie sonst 1:1: nicht spiegeln, Portale etagenübergreifend
  gleich, Nachbarschaft außerhalb der Änderung unangetastet.
- Portal-IDs bleiben pf-stairs{n}-{ETAGE} / pfb-elevator{n}-{ETAGE}
  (nicht umschreiben, der Import erwartet das).
- Gleiche viewBox wie bisher, sonst passen die Etagen nicht mehr.
- Suche, Schnellziele, Liste, Kamera, Labels, Mobile und, falls
  vorhanden, die Stele-Variante bleiben vollständig erhalten.
  Keine dieser Dateien streichen.
- mall-floor der betroffenen Etage neu bestimmen: geänderte
  Shopflächen abziehen oder freigeben, danach #routes als
  Mittellinie nachziehen. Netz bleibt unsichtbar, Portalnummern
  mitziehen, nicht neu zählen.
- Türanschlüsse der geänderten Flächen neu an die Kante zu
  mall-floor setzen. Eckläden behalten zwei Anschlüsse.
- Übergangs-Matrix aktualisieren, wenn ein Portal dazukommt oder
  entfällt, inklusive der bedienten Etagen. Erreichbarkeit erneut
  prüfen, normal und stufenfrei.
- Licht nicht neu erfinden: gleiche Richtung, gleicher Winkel,
  gleiche Schattenlänge wie im Anhang. Neue Flächen fügen sich
  in dieselbe Beleuchtung ein.
- Kamera: weiches Zoomen, Grafik dreht sich nicht, leichter
  Navi-Dreh nur Kamera (max. plus/minus 20 Grad, einmal).
- Geänderte Stellen erneut prüfen: neue oder entfallene
  Hindernisse, Übergänge, Eingänge. Nichts still weglassen,
  nichts erfinden.
- Daten weiter aus by-slug, public-visitor-surface,
  wayfinding/floors, shops. Keine Dummy-Shops.
- Version im <metadata>-Block hochzählen, Datum setzen.

LIEFERUNG
1) Aktualisierte SVG pro betroffener Etage.
2) Aktualisierte ids.{etage}.json plus Diff: neu, entfernt,
   unverändert.
3) Ein Satz: welche Flächen die Redaktion im Cockpit neu
   zuordnen muss.
4) Inventar-Diff: Hindernisse, Übergänge, Eingänge, neu,
   entfernt, unklar.
5) Erkennungs-Vorschau nur für die geänderten Etagen.

Kasten 3: In v0 einhängen und an die Website anpassen

Claude Design ersetzt nicht die ganze Website. Nur den Centerplan-Ordner ins bestehende v0-Projekt legen. Diesen Text einmal in den v0-Chat, nicht als neue Instruction, die Slots A bis J bleiben.

Vorher in v0: Instruction Cockpit F (Centerplan) sollte aktiv sein. Teil F kopieren.

Ab hier für v0

Eins zu eins einfügen. Nichts streichen.

Centerplan aus Claude Design einhängen und an die Website-Tokens
anpassen.

KONTEXT
Im Projekt liegen Dateien unter lib/centerplan/ und
components/centerplan/ plus app/centerplan/page.tsx.
Instruction Teil C (Design-Tokens aus public-visitor-surface) und
Teil F (Centerplan-Daten) sind aktiv.

KEINE RÜCKFRAGEN. Fehlen erwartete Dateien, melde welche und
stoppe. Sonst arbeite durch.

ZWECK
Der Plan beantwortet: gibt es das hier, auf welcher Etage, wie
komme ich hin. Suche und Schnellziele sind der Einstieg, die
Karte ist die Antwort. Nichts davon beim Einhängen entfernen
oder hinter ein Symbol legen.

AUFGABE
1) Dateien mergen, nichts am Rest der Website überschreiben.
   Schnitt lib/centerplan/, components/centerplan/ und die Seite
   behalten. TypeScript, modular, keine Mega-Datei.
2) /centerplan in die bestehende Navigation einhängen. Gleicher
   Header und Footer wie die anderen Seiten, keinen zweiten
   bauen.
3) Chrome des Plans (Tabs, Panel, Suche, Liste, Dropdowns,
   Hover, Rahmen) ausschließlich auf die Website-Tokens legen:
   accentColor, baseColor, secondaryColor, Schrift, Radius aus
   public-visitor-surface. Die Variablen --cp-accent,
   --cp-accent-fg, --cp-bg, --cp-fg, --cp-border, --cp-muted,
   --cp-radius, --cp-font und --cp-hover sind Aliase: zuweisen,
   nicht durch neue Farben ersetzen. Kein Farbwert außerhalb von
   tokens.ts.
4) Keine zweiten Markenfarben, kein eigenes Plan-Theme. Die
   Tokens dürfen den Kontrast nicht unter 4,5:1 drücken und den
   Plan nicht abdunkeln.
5) Shop-Daten weiter aus dem Cockpit (floors und shops). Die
   mitgelieferte Fallback-SVG nur, wenn mapSvg leer ist. mapSvg
   vor dem Einsetzen säubern (kein script, keine on*-Attribute,
   keine fremden Hosts).
6) Klick bleibt auf /shops/{slug|id} und /services/{slug|id}
   dieser Site.
7) Optik behalten: Volumen, Schatten, isometrische Grafik.
8) Mobile behalten: Touch statt Hover-only, Sheet von unten,
   Pinch-Zoom, Ziele ab 44 px.
9) Suche, Schnellziele und Labels behalten, live aus dem
   Cockpit, nicht in die SVG brennen.
10) Kamera behalten: weiches Zoomen, Grenzen, Rahmen aus Start
    und Ziel sobald beides feststeht, Grafik nie mitdrehen.
    Leichter Navi-Dreh nur Kamera (max. plus/minus 20 Grad).
11) Liste auf- und zuklappbar behalten, mit sichtbarem Button.
12) Dropdowns custom behalten, kein natives Browser-Select.
13) Wegenetz und Weg-UI behalten, falls mitgeliefert: Linie nur
    als Overlay in --cp-accent, GET entrances plus POST
    wayfinding/routing (endLocationId = mapLocations[].id),
    #routes nicht einblenden, Schalter "stufenfreier Weg" mit
    avoidStairs und preferElevator, Etagenwechsel immer mit
    Anweisung, nicht nur Tab umschalten.
14) Die vier Analytics-Ereignisse an das vorhandene Umami der
    Website hängen (trackEvent), kein zweites Werkzeug.
15) Deep-Links ?floor=, ?shop=, ?from=, ?to= müssen
    funktionieren, useSearchParams in Suspense.
16) Logo-Hosts in next.config remotePatterns eintragen.
17) Stele-Variante behalten, falls mitgeliefert. kiosk-shell nicht
    streichen.

NICHT
- Die ganze App neu generieren.
- Eigener Header, Footer, Logo-Leiste oder zweite Navigation.
- Suche oder Schnellziele entfernen, weil die Karte "schöner
  allein" wirkt.
- Den Plan als iframe auf eine fremde Domain legen, solange die
  Komponente da ist.
- website-config ohne Login aufrufen.
- Schatten und Volumen entfernen oder am Handy durch einen
  Strichplan ersetzen.

ZIP und späteres Update

Schritt	Was du tust
Export	In Claude Design Code oder ZIP laden. Nur die Centerplan-Ordner behalten, nicht eine zweite komplette Site.
In v0	Dateien ins bestehende Projekt legen. Kasten 3 in den Chat.
Ins Cockpit	Dieselbe SVG: Dashboard, Centerpläne, hochladen oder ersetzen, Shops zuordnen. Dann Routen, aus der SVG erzeugen.
Plan-Umbau	Kasten 2 in den bestehenden Claude-Design-Chat dieses Plans, neue SVG ins Dashboard.
Neue Website-Farbe	Nur im Cockpit-Branding oder in den v0-Tokens. Claude nicht erneut starten.
Neuer Shop-Name	Nur im Cockpit. Der Plan liest live.

Ein ZIP als ganze neue v0-Website ist der falsche Weg, dann entstehen zwei Designs und zwei Datenquellen.

Checkliste vor dem Weitergeben

Der Test, der zählt. Gib jemandem, der das Center nicht kennt, ein Ziel („finde die Apotheke“) und ein Handy. Unter zwanzig Sekunden, ohne Erklärung, ist bestanden. Alles Weitere danach.

Querverweise

Nutzungsstatistik: Seitenaufrufe werden anonymisiert erfasst. Im Umami-Dashboard nach diesem Pfad filtern: /centerplan/claude-design

Wozu der Plan da ist​

Was / Warum / Wer / Wo​

Dein Ablauf​

Welcher Kasten?​

Vorlage vorbereiten​

Kasten 1: Neuen Centerplan anlegen​

Kasten 2: Bestehenden Centerplan ändern​

Kasten 3: In v0 einhängen und an die Website anpassen​

ZIP und späteres Update​

Checkliste vor dem Weitergeben​

Querverweise​