/service/single öffnen. Die obere Toolbar hat drei Zonen.

• Links — Verlauf · Guide · App-Titel · Speichern (💾)
• Mitte — Template-Dropdown (11 Optionen)
• Rechts — Shared-Liste · Teilen · Kopieren · Run ▶ · Deploy 📦

Der Body hat vier Editor-Tabs (prompt · html · scss · vuejs) und eine Live-Vorschau rechts.

Zwei Einstiegsmöglichkeiten:

1. Vorgefertigte Vorlagen — 11 Optionen im Dropdown: E-Commerce · Echtzeit-Aktienchart · Favoriten-Dashboard · SaaS-Preise · Kiosk-Menü · Restaurant-Buchung · YouTube-Creator-Hub · Produktdetail · Chat-App · Event-Countdown · Admin-Dashboard. Die Auswahl füllt alle vier Tabs sofort.
2. AI-Prompt von Grund auf — im prompt-Tab beschreiben, was Sie wollen (z. B. „Café-Menü-Seite mit 3 Kategorie-Tabs“), dann über den AI-Button HTML-/SCSS-/Vue-Tabs automatisch generieren.

Tabs umschalten, um die jeweilige Schicht zu bearbeiten.

• prompt — die für die AI-Regeneration genutzte Beschreibung. Bearbeiten + Regenerieren aktualisiert den Code.
• html — Struktur und Text. Zeilennummern + Strg+F-Suche.
• scss — Farben, Schriften, Abstände. Die meisten Vorlagen definieren Theme-Variablen am Anfang der Datei.
• vuejs — Daten und Interaktivität. Nutzt data() { return { ... } }, methods: { ... }, mounted().

Klick auf Run ▶ rechts in der Toolbar rendert die Seite live im Vorschaupanel. Nach Änderungen erneut klicken, um zu aktualisieren.

Der History-Button oben links öffnet Ihre zuletzt gespeicherten Versionen. Das → Load-Icon in einer Zeile stellt diesen Zustand wieder her — das Sicherheitsnetz, wenn eine Änderung etwas kaputt macht.

Zwei Wege, Ihre Arbeit nach draussen zu bringen:

• Deploy 📦 — äusserst rechter Button der Toolbar. Nach Verbinden eines Railway-Kontos läuft ein Deploy-Fortschritt-Modal; in 1–3 Minuten ist Ihre Seite unter einer kostenlosen Domain live.
• Share — das Share-Icon in der Toolbar. Titel/Beschreibung/Tags hinzufügen und in der Community veröffentlichen; andere können Ihre Arbeit forken (ein Template-Share, kein Live-Deploy).

Aus dem Menü Service > Projekt öffnen. Layout:

• Linke Sidebar — blaue Buttons [+ Neues Projekt] / [+ Neues Team] plus die Bereiche Kürzlich, Öffentliche Solutions, Meine Projekte, Teams.
• Obere Breadcrumb — wechselt zwischen Liste ↔ Detail ↔ Programme ↔ Deploy.
• Body — Karten mit Domain-Badge, DB-Typ und Programm-/Router-Zahlen pro Projekt.

Klick auf [+ Neues Projekt] → Assistenten-Modal.

1. Schritt 1 — Funktionskarten und ein Flussdiagramm.
2. Schritt 2 — Konfiguration
   • Domain (Pflicht) — eine Ihrer vorhandenen Domains
   • Dataset (Pflicht) — die DB, mit der das Projekt arbeitet
   • Projektname / Beschreibung
   • Team-Zuweisung (Checkboxen)
3. [Speichern] unten — erst aktiv, wenn Domain und Dataset gesetzt sind.

Ein Programm ist eine Seite oder ein Funktionsbaustein innerhalb des Projekts. Füllen Sie im Anlegen-Formular die Basisangaben und springen Sie direkt in den Code-Editor — Blade + SCSS + Vue auf einem Bildschirm.

1) Neues Programm anlegen

Die Detail-Toolbar des Projekts zeigt [+ Neues Programm] und [+ Neuer Router]. Klick auf Neues Programm öffnet ein Formularmodal.

• Programmname (z. B. home, admin_dashboard)
• Beschreibung — ein Satz, was der Screen/die Funktion ist
• Typ — frontend (HTML/CSS/JS) / backend (PHP)
• Router — vorhandenen wählen oder direkt per Alias + URL-Pfad + HTTP-Methode neu anlegen

2) Code-Editor öffnen & Screen-Layout

Klick auf das -Icon einer Programmzeile wechselt in den Editor. Drei Zonen.

• Obere Breadcrumb + Tool-Leiste — aktueller Programmname, Speicherstand-Indikator und Tool-Buttons in einer Reihe.
• Linke Sidebar — Liste der anderen Programme des Projekts. Jedes hat Schnell-Icons (Code) und (Builder) zum Springen.
• Drei-Spalten-Editor in der Mitte — drei CodeMirror 6-Panels (HTML / CSS / JavaScript) nebeneinander. Klick auf ein Panel hebt es als focused hervor, das Editor-Theme folgt automatisch Ihrer Dark/Light-Einstellung.

3) Was jeder Tab wirklich enthält

• HTML — reines HTML plus Blade-Direktiven (@if, @foreach) und @{{ ... }}-Ausgabe. Server-Variablen, Bedingungen, Schleifen direkt im Template.
• CSS — SCSS-Syntax (Verschachtelung, &-Referenzen, Variablen, Mixins) durchgängig. Beim Deploy automatisch kompiliert.
• JavaScript — Vue 3 Options API-Form (data / computed / methods / mounted). Die Runtime greift das automatisch ab und bindet es an das Template in der HTML-Spalte.

Standard-Shortcuts von CodeMirror funktionieren wie erwartet: Strg+F Editor-Suche, Strg+Z Undo, Strg+/ Kommentar, automatisches Klammer-/Tag-Schliessen, Soft-Wrap.

4) Bearbeitungs-Zustand & Speicherzyklus

Ab dem ersten geänderten Zeichen erscheint oben Ungesichert. Klick auf [ Speichern] verschickt alle drei Tabs auf einmal; bei Erfolg blitzt kurz Gespeichert auf.

Jedes Speichern schreibt die drei Spalten ins Programm und notiert den Moment zugleich als Revision. Speichern = automatischer Versions-Snapshot — Sie können später zu jedem zurückrollen.

5) Deploy on Save — jedes Speichern direkt live

Den [Deploy on Save]-Toggle neben Speichern auf ON stellen und jedes Speichern deployt zugleich zum Ziel des Projekts (z. B. Hauptserver). Nach dem Push erscheint kurz ein Badge „N deployed“, sodass Sie keinen separaten Deploy-Button mehr klicken — die Schleife „Edit → live“ schliesst sich selbst. Der Toggle wird pro Projekt gemerkt.

6) Das obere Tool-Cluster im Überblick

• Datenbank — öffnet das Popup Dataset-Binding. Variablennamen vergeben, Tabelle wählen, WHERE/LIMIT/ORDER setzen — das Query-Ergebnis wird im Programm unter diesem Variablennamen automatisch eingespielt.
• Builder — wechselt in die blockbasierte Ansicht desselben Programms. Code-View und Builder-View teilen sich die Ausgabe.
• Code Search — projektweite Such-&-Ersetz-Leiste (siehe 7 unten).
• Revisions — Revisionshistorie mit Diff-Panel (siehe 8 unten).
• Extension Guide — Popup, der erklärt, wie man dasselbe Projekt lokal per VSCode-Extension bearbeitet und deployt.

7) Projektweite Suche & Ersetzung

Oben Stichwort tippen und Enter oder den -Button drücken. Bereich-Tabs bieten zwei Optionen — Project (alle Programme des aktuellen Projekts) oder Revisions (inkl. früherer Snapshots).

• Die Ergebnisse zeigen Typ-Badge (HTML / CSS / JS), Programm-ID, Programmnamen und Trefferanzahl.
• Typ-Filter-Tabs All / HTML / CSS / JS verengen auf eine Spalte, mit Trefferzahl pro Tab.
• Klick auf den Pfeil neben einem Programmnamen springt direkt in dessen Editor.
• Klick auf [Show More] in einer Zeile öffnet rechts das Kontextpanel mit dem Code um jeden Treffer herum.

Replace ist in der zweiten Zeile. Bereich (All / HTML / CSS / JS) wählen, Such- und Ersatzbegriffe eintragen, den -Button drücken — eine Bestätigung „In N Dateien wird geändert“ erscheint, und nach Ja läuft die projektweite Ersetzung in einem Rutsch.

8) Revisions · Historie und Rollback

Jedes Speichern legt hier einen Snapshot ab. Sobald das Panel aufgeht, läuft rechts automatisch ein Diff neueste Revision ↔ aktuelle Bearbeitung.

• Links: die Revisionsliste (paginiert). Jede Zeile hat drei Aktions-Icons:
  • Revert — diese Revision überschreibt den Editor (ungespeicherte Änderungen gehen verloren).
  • Diff mit aktuell — diese Revision ↔ was gerade im Editor steht.
  • Diff mit vorheriger — diese Revision ↔ die unmittelbar davor.
• Rechts: Side-by-Side-Diff mit HTML-/CSS-/JS-Tabs. Der tatsächlich geänderte Tab wird automatisch ausgewählt.

9) Der reale Ablauf eines Autors

1. Editor über das -Icon einer Programmzeile öffnen.
2. In HTML(Blade) → CSS(SCSS) → JS(Vue) schreiben, wo es die Änderung verlangt.
3. Für Daten Datenbank, für programmübergreifende Suchen Code Search, für Vergleich mit Historie Revisions nutzen.
4. [Speichern] drücken → auf „Gespeichert“ warten. Wenn Deploy on Save ON ist, geht der Deploy mit.
5. Geht etwas kaputt, per Revisions-Panel zum richtigen Snapshot zurück.
6. Für Umbenennungen, die viele Programme betreffen, Code Search → Replace in einer bestätigten Aktion.

Router in der einklappbaren Router-Sektion der Detailansicht registrieren, oder via [+ Neuer Router].

• Alias — interner Identifier (z. B. home, api_orders)
• URL-Pfad — öffentlicher Pfad (z. B. /home, /api/orders)
• HTTP-Methode — GET / POST / PUT / DELETE / ANY

Im Router-Selector des Programm-Formulars einen Router an ein Programm koppeln — Besucher, die diese URL treffen, lösen das Programm aus.

Klick auf das 🚀-Icon (Rakete) einer Projektlisten-Karte öffnet das Deploy-Modal.

1. Deploy-Modus wählen: integrate (bestehenden Docker wiederverwenden) · rebuild · new
2. Klick [Deploy starten] → die 9-Schritte-Pipeline läuft (jeder Schritt wird beim Abschluss grün):
   ① Pack erstellen → ② DB vorbereiten → ③ Daten vorbereiten → ④ Server-Transfer → ⑤ Docker Build → ⑥ Docker Deploy → ⑦ Domain verbinden → ⑧ Installation abgeschlossen → ⑨ Service-Stabilisierung
3. Am Ende ist die Domain-URL live und sofort erreichbar.

Über das Icon in einer Programmzeile den Code Builder öffnen. Oben liegen acht Schritt-Tabs (DB · List · Detail · Search · Hook · Style · Code · Menu); die meisten Programme sind fertig, wenn man sie einmal von links nach rechts durchgeht.

Der Fluss im Überblick

• [1] DB
  Tabellen wählen
  Felder wählen
  WHERE · ORDER
• [2] List
  Felder platzieren
  Gruppen · Sortierung
  fünf Layouts
• [3] Detail · Search
  Formular formen
  Komponenten wählen
  insert / update trennen
• [4] Hook · Code
  Hooks injizieren
  [Builder] liefert Code
  Snippets wiederverwenden
• [5] Menu
  4-Ebenen-Baum
  [menu:code]
  gemeinsames Include

DB-Tab im Detail — ist die Verbindung tot, sehen Sie zuerst ein „DB not connected“-Banner mit einem Reconnect-Guide. Läuft sie, öffnet sich das Panel so:

• #list (editierbar) — eine Haupttabelle. Aus dem Dropdown wählen und [Select] drücken. Das ist die Tabelle, deren Zeilen Sie editieren / löschen / einfügen werden.
• #list2 (nur lesen) — eine Sekundärtabelle für Joins (z. B. Labels oder Namen ziehen).
• #list3, #list4 … — Klick auf das in der Sidebar fügt weitere Tabellen hinzu.
• Drei Feldpicker — aus derselben Spaltenliste wählen Sie separat mehrfach „Felder für List“, „Felder für Detail“ und „Felder für Search“. Eine Checkbox daneben schaltet alles an/aus.
• DB Search Option — drei Zeilen WHERE · ORDER BY · LIMIT, plus optional Raw Query. Das wird der Default-Query-Filter der Liste.
• Unten [Update] speichert den Schritt; [Reset] setzt neu an.

Die im DB-Tab gewählten „Felder für List“ erscheinen links als Kandidaten. Dieser Tab definiert wie der Listenbildschirm aussieht und wie sich jede Spalte verhält.

Zuerst eines von fünf Layouts wählen — die Optionen darunter passen sich automatisch an.

• datatable — Tabelle mit eingebauter Sortierung und Paginierung.
• table — einfache Tabelle mit per-Spalten-Sort-Toggle.
• grid — Kartenraster.
• modal — Liste, die Zeilen direkt als Modals aufklappt.
• slots — eingebettet in Slots eines Layout-Frames.

Items (Feldspalten) hinzufügen — Klick auf [+ Add Item] links öffnet das Kandidaten-Dropdown. Bestehendes Feld wählen oder per + new ein virtuelles hinzufügen (für berechnete oder zusammengesetzte Werte).

• Pro Zeile: header_value (Anzeige-Label) · header_text (Beschreibung) · width · mutator (feldspezifischer Code) · sortable · linkable · use_opt (Optionswert) · (ein-/ausblenden).
• ↑↓ zum Umsortieren, zum Entfernen, der -Zauberstab für AI-gestützten Code.

Gruppierung — [Create Group] oben rechts bündelt gewählte Felder in 1–5 Gruppen. … tippen, um Items in eine Gruppe zu legen.

• Im Gruppenmodus wechselt [Toggle Panel] in ein Gruppen-Bearbeitungs-Panel. Dort füllen Sie pro Gruppe einen group name (interner Identifier), einen group header (Titel auf dem Screen) und ein layout (wie die Spalten innerhalb der Gruppe angeordnet sind) aus. Oben im Panel entscheidet die group display method, wie mehrere Gruppen dargestellt werden — Tabs, Boxen nebeneinander oder eine einzelne Input-Group-Reihe.

[Update] unten speichert den Schritt.

Der Detail-Tab definiert das Detail- / Bearbeiten-Popup (Modal), das sich bei Klick auf eine Zeile in der Liste öffnet. Die Form sieht fast wie im List-Tab aus; der entscheidende Zusatz ist die Wahl einer Input-Komponente pro Feld.

• Component-Dropdown — Input-Typ pro Feld: text · textarea · select · checkbox · radio · date · datetime · file · editor · hidden …
• opt_name / opt_value — komponentenspezifische Zusatzoptionen (Optionsliste für select, erlaubte Endungen für file, Format für date …).
• insert / update Dreiecks-Icon — schaltet, ob das Feld im Add-Formular, im Edit-Formular oder beiden auftaucht. Z. B. id / created_at sind normalerweise nur im Edit.
• required (+/-)-Toggle — Pflichtfeld-Flag.
• layout — Platzierung / Breite der Zelle (1/2, 1/3, volle Breite …).
• In der oberen Toolbar wählen Sie die Primary-Key-Spalte (die Spalte, die eine Zeile eindeutig identifiziert) und den Detail-Page-Key (die Spalte, die beim Öffnen einer Detailseite in der URL steht).

Der Search-Tab teilt denselben Editor. Unterschiede:

• Match mode — wie der eingegebene Wert gegen die DB geprüft wird: contains (Teiltreffer) · equals (exakt) · one-of (gegen eine Kommaliste) · full-text (Wortsuche in langem Text) usw.
• Komponenten spiegeln die Such-UX wider — freier Textinput, Dropdown-Filter …

Such-Inputs werden automatisch über die Liste gesetzt; das Absenden wird per AND mit dem WHERE aus dem DB-Tab kombiniert.

Bis hierhin haben die Schritte 1–3 die „Zutaten“ des Screens gefüllt. Jetzt kommen feinere Verhaltensregeln, Rechte und eigene Logik — und anschliessend der Code.

Hook-Tab — zeigt eine kleine Skizze des generierten HTML- und JavaScript-Scaffolds samt einer Reihe von Hook-Punkten (Badges), an denen Sie eigenen Code injizieren können.

• Mini-HTML/JavaScript-Gerüst oben — <?php ... ?>, <style>, <body>, Modal, data / computed / mounted / methods-Positionen sind markiert, sodass Sie genau sehen, wo Ihr Hook landet.
• Jede Hook-Zeile per aufklappen, um den Editor zu öffnen. Doppelklick für den Wide-Modus.
• Rechtsklick im Editor → Save Snippet / Load Snippet. Wiederkehrende Logik (Login-Check, Rechtegate, Upload-Vorverarbeitung …) unter einem Ident speichern und in jedem anderen Programm wiederverwenden.

Style-Tab — CSS/SCSS-Editor für dieses Programm. css_integrate anwerfen, um mit dem globalen CSS-Bundle des Projekts zu fusionieren; Backend Code anwerfen, um zusätzlich einen PHP-Snippet anzuhängen.

Code-Tab · die echte Generierung — hier drücken Sie [Builder].

• Zwei CodeMirror-Editoren — links Blade-Template, rechts Vue-Script. Sie zeigen live den aus den Schritten 1–3 und Ihren Hooks montierten Code.
• Session Condition, vier Zellen — Add / Delete / Read / Detail. Jede nimmt ein Session-Prädikat (z. B. user_level>=3) und bewacht diese CRUD-Operation.
• Feature-Toggle-Raster — wiederverwendbare Features (CSV-/Excel-Export, Multi-Delete, Sort-Persistenz …) anschalten und benötigte Parameter setzen.
• Der [Builder]-Button unten montiert alles zu Blade + Vue Script und schreibt es direkt in den tatsächlichen Code des Programms. Ab da übernimmt der normale Code-Editor — bearbeiten, speichern, deployen wie gewohnt.

Sind mehrere Programme vorhanden, will man eine gemeinsame Navigation. Der Menu-Tab ist ein Assistent, der einen Menübaum mit bis zu 4 Ebenen baut und per Einzeiler-Shortcode überallhin gesetzt werden kann.

Menu group — ein Namespace, der eine Menüdefinition im Projekt hält.

• Im Dropdown eine bestehende Gruppe wählen oder einen neuen Group-Code (alphanumerisch + Unterstrich, 2–9 Zeichen) eintippen und [Create Menu Group] drücken.

4-Ebenen-Baum-Editor — mit Auswahl der Gruppe erscheint links eine Depth 0-Tabelle. Ein Reinklicken öffnet die nächste Ebene rechts; bis zu vier Spalten reihen sich beim Tiefertauchen auf (Depth 0 → Depth 3).

  Depth 0 ┐
          ├─ Depth 1 ┐
          │          ├─ Depth 2 ┐
          │          │          └─ Depth 3   ← max 4 Ebenen
          └─ Depth 1'
           ...

• Jede Tiefen-Tabelle hat ihren eigenen [+ Add Menu]-Button — ein Popup lässt Name, URL-Alias und optionale Session-Bedingung eintragen.
• Pro Zeile: Bearbeiten, Löschen, Pfeile zum Umsortieren.
• Der Check-Button am Zeilenende taucht in die Kinder dieses Items in der rechten Spalte.

Per Shortcode einspritzen — steht der Baum, packen Sie ihn auf die realen Seiten. In einem gemeinsamen Include-Bereich (Layout-Frame, Header-/Sidebar-Partial) reicht eine Zeile:

<?php echo get_menus_by_code($project_id, 'group_code', 'nav nav-menu', 'role="navigation"'); ?>

Beim Rendern liest der Helper get_menus_by_code() die project_menu-Tabelle und baut <ul>/<li> bis zu vier Ebenen tief. Menüzeilen mit session_condition werden nur angezeigt, wenn die Session des Nutzers die Bedingung erfüllt. Dem Item, dessen URL zur aktuellen Seite passt, wird automatisch die Klasse active vergeben.

Zu /layout/page gehen.

• Linke Sidebar — [+ Neue Seite]-Button + Bereiche Kürzlich / Geteilt / Meine Seiten.
• Obere Toolbar — Suche (Feld + Stichwort), Umschalter-Tabs Block/Frame/Page, Grid/List-Toggle, Zeilen pro Seite (20/50/100).
• Body — Seitenkarten mit Titel, Beschreibung, Frame und „deployed-or-not“-Anzeige.

Klick auf eine Seitenkarte oder das Rasterzeichen öffnet den Vollbild-Builder. Er hat drei Bereiche.

• Linkes Panel — oben: Frame-Filmstrip (responsive Vorlage wählen); Mitte: Frame-Canvas (iframe + Slot-Overlays); unten: Block-Filmstrip (ziehbare Blöcke).
• Mittleres Panel — Data Sampler (Tabs Architecture / Data) für API-Binding.
• Rechtes Panel — Deploy + AI-Hilfe.

Nach Auswahl eines Frames erscheinen transparente Drop-Slots über dem iframe. Beginnen Sie, einen Block aus dem Block-Filmstrip zu ziehen — die Slots leuchten blau — loslassen, um den Block in diesem Slot zu installieren.

Installierte Slots werden „filled“; erneuter Klick tauscht sie. Derselbe Block darf mehrere Slots füllen, und eine Seite kann verschiedene Blöcke frei mischen.

Im Architecture-Tab des mittleren Panels koppeln Sie die Sample-Daten-Keys jedes Blocks mit echten API-Response-Keys.

1. Die linke Spalte jeder Blockkarte zeigt den Sample-Key-Baum, den der Block erwartet.
2. Der ⚡-Toggle (Blitz) in der Mitte schaltet den API-Binding-Modus an.
3. Rechts einen im Database-Service gebauten Endpoint wählen → der Response-Key-Baum dieser API klappt auf.
4. Per Klick paaren — Sample-Key mit API-Key: eine Mapping-Linie verbindet sie und erscheint unten in der „Pair Map“ als sample_key → api_key.

Der Data-Tab zeigt zum Debuggen rohe JSON-Responses.

Fürs Deployen das rechte Panel verwenden.

• Expose parameters — Liste der Query/Path-Parameter, die in der URL verfügbar sein sollen. Pro Zeile Aktivierungs-Checkbox, Name, Quelle (query/path), Standardwert. [Add] erweitert die Liste.
• Deploy URL — Slug wie /my-page eintippen aktualisiert die Vorschau live.
• [Deploy] — zeigt Fortschrittsbalken und Stufen-Label; fertig = live auf der Domain.
• Darunter sammelt Deploy history frühere URLs, die Sie erneut besuchen können.

Im Menü Display > Slideshow öffnen. Linke Sidebar hat einen [+ Slideshow registrieren]-Button und einen Filter „Community slideshows“; der Body ist eine Grid/List-Ansicht.

Jede Karte zeigt Titel, Szenenzahl, Gesamtlaufzeit und Deploy-Status.

Klick auf [+ Slideshow registrieren].

1. Schritt 1 — Einführung: Karten + Flussdiagramm (Remote → Upload → Slideshow → Browser), erklärt URI-Mapping, Kanäle, 67 Übergänge und Timeline-Steuerung.
2. Schritt 2 — Registrieren: Titel + Beschreibung eingeben → [Speichern] → im Detail-Editor landen.

Das zentrale Timeline-Panel definiert die Wiedergabe.

• Gesamtdauer — Slider, 10–3600 s.
• Anzahl Szenen — Bereichsslider; Dauer pro Szene wird automatisch berechnet.
• Übergänge — aus einem Katalog mit 67 wählen (fade, slide, cube, page flip etc.).
• Mit dem [Speichern]-Button bestätigen.

Parametrischer Cursor (Page Sequencer) erzeugt automatisch N Szenen aus einer einzelnen Layout-Seite durch Variation eines Parameters.

• Parametername (z. B. month), Algorithmus (by_range / by_comma / by_json), Werte (z. B. 1-12 Schritt 1).
• Ergebnis: 12 automatisch erzeugte Szenen, eine pro Monat.

Display-Kanäle (nur MAX) — dasselbe Slideshow mit unterschiedlichen Zusammenstellungen an unterschiedliche Displays senden.

• Kanalname (z. B. „Kategorie A“, „Kategorie B“) + Mehrfachauswahl der Slides.
• Toggle „Query-Parameter verwenden“ mappt Kanäle über ?keyword=value auf URLs.

Das rechte Deploy-Panel (se-deploy) veröffentlicht die Show.

1. Einen URL-Pfad tippen (z. B. /menu-signage) + aus dem Dropdown eine Domain wählen.
2. Klick [Slideshow deployen] — Fortschrittsbalken, „Deploying...“ und „Deploy abgeschlossen“-Meldungen.
3. Eine Deploy-Historienkarte notiert Domain / Pfad / Zeitstempel.

Jedes Display im Vollbild auf die URL richten — fertig.

Aus dem Menü Data > Parser öffnen. Linke Sidebar hat [+ Neue Parser-Regel] plus die Bereiche Kürzlich / Öffentlich / Meine Regeln; der Body ist Grid/List-Ansicht.

Jede Karte hat Icons (Run) · (Item-Test) · (Zeitplan — MAX) · (Bearbeiten) · (Duplizieren) · (Löschen).

[+ Neue Parser-Regel] öffnet einen 3-Schritte-Assistenten. Der Assistent registriert nur die Basis-Infos der Regel (Name, Beschreibung, Ziel-Dataset) — die eigentliche Crawl-URL, Selektoren und Feld-Mapping werden danach auf dem Parser-Einstellungs-Screen gefüllt, der sich nach Abschluss des Assistenten automatisch öffnet.

1. Schritt 1 — Überblick: Eine „Was ist eine Parser-Regel?“-Einführung plus vier Funktionskarten nebeneinander (Datenextraktion, Erweitertes Web-Crawling, Feld-Mapping, Wiederverwendbarkeit) und ein „Parser Pipeline“-Diagramm mit vier unterstützten Flows auf einen Blick (Parser-Regel → DB / → Makro → DB / → Scheduler → DB / → API-Endpoint → Service-Start). Mit [Weiter] fortfahren.
2. Schritt 2 — Datenbank-Verbindung: Klick auf eine Dataset-Karte (zeigt db_type-Badge, Tabellenname, Domain), um zu wählen, wohin extrahierte Zeilen fallen. Ohne registrierte Datasets wird nur ein „Go to Dataset“-Link gezeigt. Drücken von [Weiter] startet einen 3-Stufen-Deploy-Progress („Agent connect → Parser engine deploy → Deploy complete“), der die Parser-Engine auf dem gewählten docker-Agent provisioniert.
3. Schritt 3 — Regel erstellen: Regelname und optionale Beschreibung eintragen, dann [Create Rule]. Die Basis-Infos (Name, Beschreibung, Dataset, Share-Flag) werden gespeichert, der Assistent schliesst, und der Einstellungs-Screen der neu erstellten Regel öffnet sich automatisch.

Da endet der Assistent. Auf dem Parser-Einstellungs-Screen füllen Sie dann Ziel-URL, HTTP-Optionen, Loop Splitter, XPath-/JSON-Selektoren und Feld-Mapping (siehe ▶︎ Schritt 3 · Ziel-URL & Extraktions-Selektoren), verifizieren im „Test“-Tab und speichern — erst dann ist der Parser bereit, wirklich zu laufen.

Die Schrittleiste oben zeigt den Fortschritt; [Zurück] geht zum vorherigen Schritt (während Deploy deaktiviert). Das Assistenten-Modal schliesst nur über [x] oben rechts.

(Beschreibung des Parser-Regel-Editors: Ziel-URL, Loop Splitter, XPath/JSON-Selektoren, Postprocessing-Funktionen und Auto-Registrierung der Regel per AI Prompt. Die detaillierte Prosa unten ist noch nicht vollständig ins Deutsche übersetzt.)

Enter the Target URL at the top of the editor and combine three techniques to extract rows.

• Loop Splitter (3 inputs — primary + 2 secondary) — string patterns that chop HTML into repeated units.
• XPath selectors — up to 3 levels, extracting fields inside each unit. The selector should point at a node set (array), not a leaf value — if the actual data sits at //h3/a/text(), enter just //h3/a so the result comes out as an array.
• JSON selectors — for JSON APIs, dot/bracket paths. Same idea: point at the array path. If the data has a shape like data.items[0].title, enter data.items as the selector so the item array is produced.
• Post-processing functions — chain trim(@p), replace(...), regex(...), strtoupper(@p), slice(), remove() per column.

The fastest path is to feed a slice of the source (via the Loop Splitter) into the AI Prompt and let the AI response auto-register the rule. Hand-tuning selectors one by one is much slower — especially when the page structure is non-trivial.

Auto-register with an AI prompt (recommended)

Instead of hand-filling selectors, hand the sample to an AI and apply the completed rule it returns.

1. Prerequisite — enter the Target URL and run the extract test once from the "Test" tab so a response body exists. That body is injected into the prompt automatically.
2. Click the highlighted "AI Prompt" button (wand icon) at the top of the test result panel. A prompt is auto-built in the editor area just below it, picking the right language for the document out of 8 supported (Korean · English · Japanese · Chinese · Russian · German · French · Spanish) and the right document type (HTML / JSON / XML).
3. Click inside the editor panel → Ctrl+A → Ctrl+C to copy everything.
4. Paste into an AI such as ChatGPT / Claude / Gemini and run → the AI returns a rule JSON.
5. Copy the response, then click the "Import Pattern" button (import icon) in the same panel — a paste-in textarea opens. Paste and click [Apply Pattern].
6. Loop splitter, selectors, unique key, and every column are mapped into the right slots of the rule automatically; the editor switches to the "fields" tab so you can check the result immediately. A summary toast like "Pattern applied: N fields" appears at the bottom.

If the AI response isn't valid, you'll see an "Invalid JSON" toast and your existing values stay untouched — safe to retry.

Das Icon (Reagenzglas) auf der Karte oder die „Test“-Tab im Editor öffnen das Test-Modal.

• Top-Bar: „N items / M columns“
• Export: CSV · XLSX · JSON · HTML
• Raster: Row# + automatisch erkannte Spalten
• Zellen-Hover → „Copy“-Button

Selektoren anpassen, testen, justieren, testen — Schleife, bis die Ausgabe passt.

(Wie das „Run“-Modal genutzt wird, das per ▶-Icon (Play) einer Regelkarte öffnet — Drei-Panel-Interface (URL-Liste / Plan & Execute / Result-Feedback), die Schritte URI · Fuzzer · Preview · Run mode · Live-Feedback und die erwartbaren Effekte. Die Details unten sind noch nicht vollständig übersetzt.)

Clicking the (Play) icon on a rule card opens the Run modal — the single screen where you decide where to hit, with what parameter combinations, how to run, and where to store results, then launch and monitor in place.

• [1] URI
  Target address
  {param} tokens
  path · query
• [2] Fuzzer
  Parameter mix
  1-N · A,B · DB
  combine / pair
• [3] Preview
  Expand URLs
  Fill left panel
  Verify count
• [4] Run · Save
  Runtime / Schedule
  DB / CSV / JSON
  Items per run
• [5] Start
  Flow checks
  [Start] enables
  Pause anytime
• [6] Feedback
  Progress · stats
  Per-URL log
  Macro chain

Interface at a glance — 3-panel layout

• Left panel · URL list — shows the preview URLs generated from the center panel, numbered. While a run is in progress the current row is highlighted and finished rows show a check, so you can see progress at a glance. Each row has a button to test-parse that single URL in isolation, and a at the top-right loads past run configurations for reuse.
• Center panel · Plan & Execute — the main body: define URI, fuzzer parameters, run/save mode, then launch from the flow diagram's [Start] button.
• Right panel · Result feedback — two tabs. "Results" shows live statistics and log during a run; "Parse Test" shows the cell-level preview when you click on the left.

Step-by-step

1. URI input — first card in the center panel. Two example styles — path-token (/category/{param}/list) and query-string (?param={param}) — are pinned to the header as clickable hint badges. Names inside the curly braces {...} must match the parameter names defined in the next card so substitution works.
2. Fuzzer parameters — the card that builds the list of values injected into each {...}. A top toggle picks one of two modes:
   • Combination — cartesian product of every parameter's values. E.g. {page}=1..10 × {cat}=A,B → 20 URLs.
   • Paired — zip-style: the n-th value of every parameter together. All lists must have the same length.
   For each parameter pick a name and a generator — 1-N (range with step), A,B (comma list), DB (pull from a dataset column with optional WHERE/ORDER/LIMIT), [,] (JSON array), or \n (newline list). adds another parameter.
3. URL preview — the [URL preview] button at the bottom of the card expands the URI + parameter combinations into real URLs listed in the left panel. The count shows in the header badge, so you can immediately verify the expected size (e.g. range 10 × categories 2 = 20).
4. Run mode & Save mode — the third card.
   • Run: Runtime (one-off) / Schedule (periodic, MAX plan). Schedule reveals start-time and interval (minutes) inputs inline.
   • Items per run: Page / PK.
   • Save: DB (dataset, or a custom external DB via host/user/password/database), CSV, JSON, or SQL. DB mode also surfaces table (collection) name and a DBMS badge so you can confirm the destination visually.
5. Visual flow guide & Start — below the cards, a small flow diagram chains URI → Parameter → Preview → Save → [Start] → Macro. Each node lights up with a green check as its input is filled. Once required nodes are valid the [Start] button at the top-right activates. (If you pin a macro on the trailing node, it runs automatically right after the scrape.)
6. Live feedback while running — the moment you press Start, the top progress bar fills up (parsed / total) and the right-panel "Results" tab updates in real time.
   • Stat cards: Total · Passed · Failed · Remaining — the red "Failed" card only appears when a failure actually happens.
   • Log view: one line per URL as it's processed, latest highlighted, each showing time · URL · +rows added; failed URLs carry an badge.
   • Pause / Resume: the Start button switches to [Pause] during a run — stop at any time safely.
   • File-save modes (CSV/JSON/SQL): the Output textarea below fills with the generated file body; a button grabs it immediately.

What this run screen buys you

• Plan, run and observe in one screen — no tab hopping. Tweak the URI, parameter list, or save target and immediately re-run. The configure → run → verify loop is as tight as it gets.
• A fuzzer that scales — generate tens of thousands of URLs without writing one by hand. Ranges, comma lists, DB columns, JSON arrays, newline lists — category × page × date combinations are ready in seconds.
• DB-backed parameters (by_db_field) read a key table column and iterate detail pages on top of it — the classic "list → detail" two-stage crawl works end-to-end without spreadsheets or glue scripts.
• Transparent live feedback — per-URL checkmarks, streaming log, and success/fail counters make it easy to spot exactly where things stalled. Rerun a failed row on its own via to isolate the cause.
• Resource-friendly architecture — the actual HTTP and parsing runs on your docker agent, not the QuickStart server. Large crawls don't affect the service's bandwidth.
• Macro chaining — attach a macro to run right after the scrape for notifications, aggregation, or post-processing, turning collect → clean → notify into a single action.

(Aufbau der Zeitplan-Karte (nur MAX), 5-Schritte-Ablaufdiagramm, Ergebnisverifikation im Datenbank-Editor, Tipp zur Verkettung mit einem Makro usw. Details unten sind noch nicht vollständig übersetzt.)

Scheduled runs are a hands-off mode: the docker agent executes the rule on a fixed interval on its own, even while the screen is closed. Rows flow straight into the dataset (DB), so to actually see the results you open the target table in the Database editor.

• [1] Schedule setup
  Start time
  Interval (min)
  Active toggle
• [2] Agent sync
  [Save] pushes
  config to the
  docker agent
• [3] Auto periodic run
  Agent runs alone
  QuickStart idle
  Background task
• [4] DB accumulation
  Rows INSERT into
  dataset table
  Dup keys skipped
• [5] Check in Database editor
  Data > Database
  Open the table
  Query with WHERE/ORDER

The (clock) icon on a card opens the schedule modal (FREE/PRO plans show a "Max" ribbon).

• Start time (hour 0–23, minute 0–59)
• Interval (minutes)
• Active toggle
• Run mode: Single URL / URL list (batch)

[Save] persists to QuickStart and auto-syncs to the selected docker agent. The agent is what actually runs the schedule — QuickStart never sits in the traffic path.

Verify results in the "Database editor"

Because scheduled runs are headless, the way to check the output is to open the target dataset directly and inspect the rows that piled up.

1. Open Data > Database from the left menu.
2. Click the dataset card that the parser rule is linked to — this opens the Database editor.
3. Pick the target table from the left table list (e.g. items, products, etc.).
4. Use WHERE / ORDER BY at the top to bring recent rows to the top (ORDER BY created_at DESC, ORDER BY id DESC) and inspect what the last scheduled run added.
5. A quick row count (COUNT) or a date-range filter is enough to sanity-check trend — if the count grows each interval, the schedule is healthy.

The run log itself is shown as a table in the Run modal's right-panel "Results" tab when schedule mode is active, but for content verification of the actual harvested data, the Database editor is always the source of truth.

Aus dem Menü Data > Makro öffnen. Linke Sidebar mit den Abschnitten „Kürzlich“ / „Community“ / „Meine Makros“; der Body ist eine Grid/List-Ansicht. Die obere Toolbar unterstützt Suche nach Name oder Beschreibung.

Klick auf [+ Neues Makro] in der Sidebar öffnet sofort den Erstellen-Assistenten.

[+ Neues Makro] öffnet einen 4-Schritte-Assistenten. Dieser eine Assistent deckt sowohl die Registrierung der Makro-Basisinfos als auch die Vorbereitung seines Runtime-Servers ab.

1. Schritt 1 — Makro-Intro: Ein „Was ist ein Makro?“-Intro mit vier Funktionskarten (Pipeline-Chaining, Adapter-Pattern, Input → Output, Code Gen) und einem Flussdiagramm mit den vier unterstützten Topologien (DB Query · Chaining · Parser · Scheduler). Keine Eingabe — [Weiter] drücken.
2. Schritt 2 — Verbindungsart: Bereiten Sie den Ort vor, an dem das Makro tatsächlich läuft. Zwei Optionen:
   • Neuen Makro-Server deployen — Ihren Railway-Account verbinden (Token einfügen), dann Sprache · Framework · Core-Stack · optionale Add-ons (MongoDB / FFmpeg / Puppeteer / WebSocket usw.) · DB-Zugangsdaten wählen. Klick auf [Server deployen] fährt eine 6-Schritte-Pipeline (Receive → Decrypt → Docker build → Deploying → Network → Verify), und Ihr Konto bekommt eine eigene Makro-Runtime.
   • Bestehenden Makro-Server verbinden — wenn schon ein Server läuft, auf dem Ihr Makro-Code lebt, tragen Sie die Verbindungsdaten ein, um ihn anzuschliessen.
   Ist der Server fertig, rutscht der Assistent automatisch weiter.
3. Schritt 3 — Typ auswählen: Einen der 24 Makro-Typen wählen (ETL-Pipeline · Batch-API · Datenmigration · CSV/Excel-Import · u. a.). Startcode passend zum Typ — mit Eingabeparametern, Schleifenskelett und Ausgabestruktur — wird automatisch generiert als Ausgangspunkt für den nächsten Schritt.
4. Schritt 4 — Registrieren: Einen Makronamen (z. B. „Nächtliche DB-Sync“, „Bulk-Übersetzung“) und eine kurze Beschreibung eintragen, dann [Erstellen]. Das Makro wird gespeichert, der Assistent schliesst, und die Detailansicht (Code-Editor) öffnet sich automatisch.

Eine Schrittleiste oben zeigt den Fortschritt; [Zurück] springt zum vorherigen Schritt (während des Deploys deaktiviert). Der Assistent schliesst nur über den [x]-Button oben rechts.

Wenn der Assistent schliesst, öffnet sich ein 3-Pane-Editor: links die Input-Field-Definition; in der Mitte der Code-Editor mit PHP-/Node.js-/Python-Tabs; rechts das AI-Prompt-Pane. Der Editor ist mit einem Scaffold für den in Schritt 3 gewählten Makro-Typ vorgefüllt, sodass Sie meist nur die wichtigen Teile anpassen.

Hinweis: Die vollständige Lokalisierung dieses langen Abschnitts (6-Karten-Grid, run_data-Tabelle, Code-Beispiel, AI-Prompt-Sektion) folgt in einem späteren Pass. Kernbotschaften: run_data.input_data ist anfangs ein Array von { item_name, item_value, item_type } und muss zu einem Schlüssel/Wert-Objekt flipgedreht werden; run_data.conn_string/table_name/file_name sind vorbelegt; Rückgabefelder data / json / download_links / message stimmen mit dem im Assistenten gewählten Output-Typ überein; das rechte AI-Prompt-Pane baut aus einem Szenario-Badge + Ihrer Textarea einen Prompt, den Sie nach ChatGPT/Claude/Gemini kopieren und dessen Code zurück in den zentralen Editor einfügen.

Oben im linken Pane auf den Quick-Test-Tab (🧪 Kolbenicon) wechseln. Quick Test jagt den Code durch den in Schritt 2 vorbereiteten Makro-Server.

1. Füllen Sie die Input-Parameter Zeile für Zeile aus.
2. Klick auf [Run] → „Running…“-Spinner.
3. Die Ergebnisanzeige richtet sich nach der Form der Rückgabe:
   • data → Tabelle
   • json → JSON-Viewer
   • download_links → Liste von Download-Buttons
   • message/error → <pre>-Textblock

Stdout und stderr streamen in Echtzeit ins darunterliegende Terminal-Pane — ideal zum Debuggen.

Sieht Quick Test gut aus, übergeben Sie das Makro einem Zeitplan für unbeaufsichtigte Ausführung. Im Schedule-Abschnitt der Detailansicht genügen zwei Werte.

• Startzeit (Offset) — Format HH:MM (z. B. 00:00 = Mitternacht, 03:30 = 3:30 Uhr morgens). Das ist der Anker des wiederkehrenden Zeitplans.
• Intervall N (Minuten) — das Makro läuft ab der Startzeit alle N Minuten. 5 für alle 5 Minuten, 60 für stündlich, 1440 für einmal täglich.
• Active-Toggle — pausieren oder fortsetzen, ohne die Konfiguration zu verlieren.

Beispiele: Startzeit 00:00 + Intervall 5 → ab Mitternacht alle 5 Minuten (00:00, 00:05, 00:10 …). Startzeit 09:00 + Intervall 1440 → einmal täglich um 9 Uhr.

Nach dem Speichern läuft der Makro-Server dieses Makro in diesem Takt selbstständig. QuickStart signalisiert nur — die tatsächliche Ausführung und der Traffic liegen auf dem Makro-Server. (Keine Cron-Ausdrücke — Scheduler nutzt nur Startzeit + Intervall.)

Aus dem Menü Data > Datenbank öffnen. Linke Sidebar hat einen blauen Button [+ Neues Dataset] und Bereiche Kürzlich / Öffentlich / Mein / Team; der Body ist eine Grid/List-Ansicht mit Karten.

Vier Icons auf jeder Karte: ▶ (DB-Editor) · Tabelle (Cell Editor) · (API-Einstellungen) · Kopieren/Löschen.

[+ Neues Dataset] → Assistent-Modal.

1. Schritt 1 — drei Verbindungsoptionen: Neue DB deployen (Railway) · Bestehende DB verbinden · Lokale Datei (JSON/CSV/Excel). DB-Typ-Dropdown (MySQL 3306 · MariaDB 3306 · PostgreSQL 5432 · MongoDB 27017) · Host · Port · DB · Benutzer · Passwort → [Verbindungstest] prüft, ob die Credentials die Datenbank erreichen.
2. Schritt 2 — bei Erfolg eine Tabelle wählen, ihre Felder klappen auf.
3. Schritt 3 — Dataset registrieren: Name · Beschreibung · Tabelle · PK · Spalten (* oder kommagetrennt) · WHERE · LIMIT · ORDER BY · shared. Rechts zeigt [Query testen] eine Vorschau; dann [Speichern].

Klick auf das ▶ (Play)-Icon einer Dataset-Karte öffnet den Vollbild-Editor mit drei Panels.

• Links — Tabs (Tables/Views/Procedures/Functions), Inspektor der Tabellenstruktur, Kommando-Icons (CREATE kopieren · Drop · Update · Insert · Delete · Join · Reverse · Refresh).
• Mitte — SQL-Editor mit mehreren Tabs. ▶ Run oder F5/F9. Export nach TSV/CSV/JSON/SQL oder per „An Makro senden“ direkt an ein Makro.
• Rechts — Ergebnisraster mit zellgenauer Editierung.

Klick auf den API-Einstellungen-Button (Stecker-Icon) auf der Karte öffnet das API-Einstellungs-Modal.

1. Basics: Namespace (Pflicht, URL-Ende) · Tabelle · JOIN-Tabelle · Page var (Default page) · Per Page (50) · Cache (0–1440 Min.).
2. [Auto-generieren] → baut die JSON-Form (main_container → main_fields → item_container → item_fields → detail). Jedes Feld ist ein Paar „JSON-Schlüssel → SQL-Variable“.
3. [Speichern] → [Deploy] aktiviert den Endpoint.

Endpoints gehen unter GET https://happycat.apidealder.net/endpoint/{namespace} live. Die ACL-Sektion des Modals sichert sie ab.

• API-Key (Auto-generieren-Button · Transport header/param · Header-Name X-API-KEY)
• IP-Whitelist — Wildcards / CIDR
• Referer-Einschränkung — erlaubte Domains
• Rate limit — max. Anfragen pro Minute

Beispiel: curl -H "X-API-KEY: ..." https://happycat.apidealder.net/endpoint/menu_list

Remote Management gliedert sich in vier Zonen. Wissen Sie, wo Sie schauen müssen, bevor Sie klicken.

• Linke Serverliste — alle Domains, die Sie verwalten, jede mit einem kleinen Statuspunkt. Für mehr Platz können Sie das Panel zu Icons einklappen.
• Dateibereich in der Mitte — der Dateibrowser des ausgewählten Servers. Die Toolbar oben enthält Pfadleiste, Sortier-Buttons und Terminal-Umschalter; der Ordnerinhalt darunter wächst beim Hineinklicken in Spalten.
• Untere Aktionsleiste — Hochladen · Neuer Ordner · Neue Datei · Herunterladen · Löschen. Buttons leuchten erst auf, nachdem Sie Datei oder Ordner ausgewählt haben.
• Terminal-Panel — eine Konsole, die bei Bedarf von unten hochfährt. Mit dem Terminal-Icon in der oberen Toolbar ein- und ausblenden.

Eine Domain links anklicken. Der Punkt neben dem Namen zeigt den aktuellen Zustand:

• Grüner Punkt — online. Die Dateiliste öffnet sich sofort.
• Grauer Punkt — offline. Der Container schläft eventuell oder das Netzwerk ist blockiert.
• Weisser Punkt — Prüfung läuft noch oder Status unbekannt.

Ist die Liste leer, sehen Sie den Hinweis „Server zuerst deployen“ mit Shortcut-Buttons zu den Deploy-Screens für Single-File, Projekt und Datenbank.

Der Mittelbereich ist ein spaltenbasierter Browser — jeder Ordnerklick öffnet rechts eine neue Spalte. Gleichzeitig sind bis zu vier Spalten sichtbar; tiefere Pfade klappen die linkeste automatisch weg.

• Pfadleiste — das Haus-Symbol springt zurück zur Wurzel (/), jedes slash-getrennte Segment darüber ist anklickbar und führt direkt dorthin.
• Pfad-Eingabe — einen kompletten Pfad wie /var/www/html/storage/logs tippen und Enter drücken, um ohne Klicks dorthin zu springen.
• Sortier-Buttons — Name · Grösse · Änderungszeit. Denselben Button erneut drücken kehrt die Reihenfolge um.
• Auswählen — ein Klick wählt ein Element, Shift+Klick wählt einen Bereich, Ctrl/⌘+Klick fügt einzeln hinzu oder entfernt. Sobald mehr als ein Element ausgewählt ist, erscheint oben rechts in der Aktionsleiste ein „N ausgewählt“-Badge.

Einmal auf eine Datei klicken, um sie auszuwählen. Ein zweiter Klick öffnet sie — die passende rechte Ansicht ploppt je nach Dateityp automatisch auf.

• Text-/Codedateien → mittig öffnet sich ein Editor mit Syntax-Highlighting. HTML, PHP, Vue, CSS/SCSS, JavaScript/TypeScript, JSON und mehr werden automatisch erkannt.
• Bilder (PNG · JPG · GIF · SVG · WebP · BMP · ICO) → öffnen in einem Vorschau-Viewer zum visuellen Check.
• Binär-/ausführbare Dateien lösen die Meldung „Binärdatei kann nicht editiert werden“ aus und öffnen nicht.
• Der [Speichern]-Button oben rechts im Editor schickt die Änderung sofort zum Server — kein Redeploy nötig. Esc oder [Abbrechen] schliesst ohne Speichern.
• Im Editor lassen sich nur Dateien bis 10 MB öffnen; grössere zeigen stattdessen den Hinweis „zu gross“.

Untere Aktionsleiste und Terminal-Panel kombinieren — so geht echte Arbeit.

• Archiv hochladen — .zip · .tar · .tar.gz · .tgz per Drag oder Klick auswählen. Eine Vorschau des Archivinhalts erscheint; nach Start Upload wird die Datei in 1-MB-Blöcken mit Prozentbalken gesendet, und beim Ende aktualisiert sich der aktuelle Ordner automatisch.
• Dateien hochladen — eine oder mehrere Dateien gleichzeitig wählen, sie werden as-is in den aktuellen Ordner geladen (keine Entpackung).
• Neuer Ordner / Neue Datei — fragt nach einem Namen. Erlaubt sind nur Buchstaben, Ziffern, Punkt, Bindestrich und Unterstrich.
• Download — Dateien laden as-is herunter; Ordner werden automatisch als ein ZIP zusammengepackt.
• Löschen — bestätigt einmal; bei Mehrfachauswahl gehen alle in einer Operation.
• Verschieben / Kopieren — Datei auf einen Ordner ziehen öffnet einen Bestätigungsdialog. Oder Ctrl+X/Ctrl+C legt die Auswahl ab, Ctrl+V in einem anderen Ordner fügt mit demselben Dialog ein.
• Terminal — das Terminal-Icon in der oberen Toolbar fährt das untere Panel hoch und verbindet Sie mit der Shell des ausgewählten Servers. Befehl eintippen und Enter — stdout erscheint weiss, stderr rot. ↑/↓ holt frühere Befehle zurück, das aktuelle Arbeitsverzeichnis wird mitgeführt, sodass nach cd some/path der nächste Befehl von dort ausgeführt wird.

Nach dem Anmelden öffnen Sie über die obere Navigation oder das Dashboard Services → Single File. Der Bildschirm teilt sich in eine obere Toolbar und den Hauptbereich:

• Obere Toolbar — links: Verlauf · Guide · Titeleingabe · Speichern (💾). Mitte: Template-Dropdown. Rechts: Teilen · Run ▶ · Deploy 📦.
• Editor in der Mitte — oben vier Tabs: prompt · html · scss · vuejs. Klick schaltet um.
• Vorschaupanel rechts — rendert, sobald Sie Run drücken.

Öffnen Sie das Template-Dropdown in der Mitte der Toolbar und wählen Sie «Restaurant Booking System». Der Ablauf ist:

1. Sobald sich der Wert des Dropdowns ändert, wird die gewählte Vorlage automatisch angewendet.
2. Alle vier Tabs (prompt · html · scss · vuejs) füllen sich automatisch mit vorgefertigtem Code und dem AI-Prompt für eine Regeneration.
3. Der aktive Tab wechselt standardmässig zu prompt — dieser Text ist das, was die AI beim Regenerieren verwendet.
4. Klicken Sie Run ▶ in der Toolbar, und die Vorschau rechts rendert einen dreispaltigen Reservierungsbildschirm (Kalender / Zeitslots / Reservierungsformular).

Hinweis: Diese Vorlage ist ein Betreiberbildschirm, mit dem der Inhaber Termine, Zeitfenster und Tischverfügbarkeit verwaltet — keine reine Besucher-Menü-Landingpage.

Diese Vorlage wird auf zwei Ebenen angepasst: ein Einstellungs-Modal (kein Code nötig) und direkte Code-Änderungen. Einstiegspunkt ist das ⚙ Einstellungen-Icon rechts oben auf der gerenderten Seite, neben dem Theme-Umschalter (☀/🌙).

A. Einstellungs-Modal — nur Daten, kein Code

1. ⚙ anklicken → eine bildschirmfüllende Overlay öffnet ein zentriertes Modal (4 Tabs).
2. Time Ranges — Start- und Endzeit für Morgen / Mittag / Abend mit Zahleneingaben anpassen. Eine Visualisierungsleiste oben zeigt die Farbsegmente live. Wenn Start == Ende, wird das Segment als «(inaktiv)» markiert.
3. Time Slots — Schrittweite wählen (10 / 30 / 60 / 120 Min.), dann einzelne Slots im Raster aktiv/inaktiv schalten. Oben sind aktive/inaktive Zähler zu sehen.
4. Tables — Liste mit Inline-Umbenennen + Löschen sowie ein Eingabefeld unten zum Hinzufügen von Tischen. Diese Liste treibt die Auswahl «Tisch» im Reservierungsformular.
5. Holidays — wiederkehrende Ruhetage (So–Sa, 7 Schaltflächen) + konkrete Feiertage (Datumsfeld + Grundtext, Liste mit Hinzufügen/Löschen). Gründe erscheinen nur in den Einstellungen, nie im öffentlichen Bildschirm.

B. Code-Änderungen — Shopname, Theme usw.

• html-Tab — ersetzen Sie den Header-Titel "레스토랑 예약" durch Ihren Shopnamen. Mit Ctrl+F schnell finden.
• vuejs-Tab — mounted() enthält Mock-Datengenerierung (D+1 ~10 %, D+2 ~5 %, D+3 ~2 % zufällige Reservierungen + ein Array koreanischer Namen). Für echte Nutzung den Block leeren oder durch einen Server-API-Call ersetzen. Feiertage werden von https://date.nager.at/api/v3/PublicHolidays/{year}/KR geladen — bei Bedarf KR durch einen anderen Ländercode ersetzen.
• scss-Tab — das Theme nutzt CSS Custom Properties, keine SCSS-Variablen. Definiert unter .reservation (hell) / .reservation.dark (dunkel): --primary (Markenakzent), --bg (Seitenhintergrund), --card-bg, --text / --text-sub, --border, --holiday (Feiertagsrot), --closed-bg (Shop-Ruhe in Bernstein), --occ-bg / --occ-border (Slot mit freien Plätzen). Wer nur diese anpasst, verschiebt den gesamten Look konsistent.

Nach dem Bearbeiten: Speichern (💾) → Run ▶ zum Neuladen. Ungespeicherte Tabs zeigen einen kleinen Punkt (●).

Jetzt reservieren Sie selbst einmal — so als wären Sie Gast. Das ist genau das, was Ihr Team und Ihre Besucher nach dem Livegang tun. Gehen Sie in der Vorschau in dieser Reihenfolge vor:

1. Datum im Kalender wählen (linke Seite) — beliebiges Datum ab heute anklicken. Rote Tage sind Feiertage, bernsteinfarbene sind von Ihnen gesetzte Schliesstage, ausgegraute sind reguläre Ruhetage — die sind nicht klickbar. Tage mit bestehenden Reservierungen zeigen in der Ecke eine kleine Zahl wie «+2», damit der Buchungsstand auf einen Blick erkennbar ist.
2. Zeit wählen (Mitte) — nach Auswahl eines Datums erscheinen die verfügbaren Zeiten als runde Buttons. Die Zahl wie «2/5» darauf bedeutet «2 bereits gebucht / 5 Tische insgesamt». Heller Ton = noch viele Plätze, dunkel = fast voll, durchgestrichen = voll und nicht klickbar.
3. Bereits vorhandene Reservierungen sehen — Klick auf einen Zeit-Button öffnet darunter die Liste bestehender Reservierungen zu dieser Zeit (Gastname, Tisch, Gruppengrösse). Das verhindert Doppelbuchungen.
4. Formular ausfüllen (rechte Seite) — gewähltes Datum und gewählte Zeit erscheinen oben als Zusammenfassung. Füllen Sie von oben nach unten:
   • Gastname
   • Telefon: einfach Ziffern tippen, wird automatisch als «010-1234-5678» formatiert
   • Tisch: Tische, die zu dieser Zeit bereits belegt sind, werden automatisch ausgeblendet — doppelte Buchung passiert gar nicht
   • Gruppengrösse: 1 bis 20 Personen
   • Memo: besondere Wünsche (Geburtstag, Rollstuhlzugang usw.)
5. [Reservieren] drücken — bei leerem Namen erscheint eine Warnung. Sonst ploppt eine «Reservierung abgeschlossen»-Bestätigung auf, und das «+N» im Kalender sowie das «N/M» am Zeit-Button springen sofort um 1 hoch. Das Formular leert sich selbst und ist für die nächste Buchung bereit.
6. Beides probieren: helles und dunkles Theme — das Icon ☀/🌙 rechts oben klicken. Ihr Shop wird vielleicht tagsüber bei Sonne und abends bei gedämpftem Licht benutzt — prüfen Sie, dass alles in beiden Varianten gut lesbar ist.

Handy- und Tablet-Ansichten testen Sie, indem Sie das Browserfenster einfach mit der Maus schmaler ziehen. Je schmaler der Bildschirm wird, desto stärker rearrangieren sich die 3 Spalten zu 2 und schliesslich stapeln sich als eine. Da Personal oft Tablets und Gäste oft Handys benutzen, prüfen Sie, dass Text und Buttons auch auf schmalen Screens gross genug zum Antippen bleiben.

Das Deployment nutzt den Hosting-Anbieter Railway. Beim ersten Klick auf Deploy erscheint das Modal «Railway-Konto verbinden». Der Ablauf ist:

1. Log in with Railway anklicken → Railways Login öffnet sich in einem neuen Tab.
2. Noch kein Railway-Konto? Dort kostenfrei registrieren (E-Mail oder GitHub).
3. Im Screen «QuickStart beantragt Deploy-Berechtigung» auf Authorize klicken.
4. Sie werden zu QuickStart zurückgeleitet, und ein «Verbunden»-Toast erscheint.

Das macht man nur einmal — spätere Deploys überspringen diesen Schritt.

Ist das Konto verbunden, erneut auf Deploy klicken. Ein Fortschritts-Modal öffnet sich und durchläuft 8 Stufen — jede wird beim Abschluss grün.

1. Pack — Code in ein Paket bündeln.
2. Upload — Paket zu Railway senden.
3. Install — benötigte Bibliotheken installieren.
4. Build — SCSS kompilieren und Vue bündeln.
5. Migrate — statische Dateien am richtigen Ort im Webserver ablegen.
6. Start — den Container hochfahren.
7. Health — prüfen, dass die Site tatsächlich antwortet.
8. Complete — finalisieren und die URL zuweisen.

Insgesamt dauert es meist 1–3 Minuten. Unten im Modal Logs anzeigen ausklappen, um live zuzusehen.

Nach Abschluss des Deploys erscheint unten im Modal ein Domain öffnen-Button. Klick darauf, und die automatisch zugewiesene Gratisdomain (z. B. happycat.apidealder.net) öffnet sich in einem neuen Tab. Diese URL kann an beliebige Personen geteilt werden.

Später zum Anbinden einer eigenen Domain (z. B. myname.com) im Dashboard unter Einstellungen → Domain-Verwaltung die Custom-Domain eintragen und die dort gezeigten DNS-Einträge beim eigenen DNS-Anbieter hinterlegen.

Über die obere Navigation oder das Dashboard auf Services → Datenbank klicken, um die Datenbank-Seite zu öffnen. Der Bildschirm teilt sich in eine linke Sidebar und den Hauptbereich.

• Linke Sidebar — oben ein blauer Button [+ Neues Dataset], darunter die Abschnitte „Kürzlich“, „Öffentliche Datasets“, „Meine Datasets“, „Team“.
• Hauptbereich — in der oberen Toolbar: Suchfeld (Name / Tabelle / URI), Umschalter Rasteransicht⇄Liste, Auswahl Zeilen pro Seite (20/50/100). Darunter erscheinen vorhandene Datasets als Karten.
• Vier Icons auf jeder Karte — ▶ (Play) öffnet den Datenbank-Editor · Tabellen-Icon öffnet den Zellen-Editor · API-Einstellungen-Button (Stecker-Icon) öffnet die API-Einstellungen · plus Kopieren/Löschen. Doppelklick auf den Kartennamen für Inline-Umbenennen.

Klick auf [+ Neues Dataset] in der linken Sidebar öffnet mittig ein 3-Schritte-Assistent-Modal. Der Ablauf:

1. Schritt 0 — Überblick: Erklärkarten zu Datasets und Funktionen. Weiter mit Next.
2. Schritt 1 — Verbindungsart: eine von drei grossen Optionen wählen.
   • Neue DB deployen — richtet einen frischen DB-Container auf Railway ein.
   • Bestehende DB verbinden (häufigster Fall) — Verbindung zu einer bereits vorhandenen DB.
   • Lokale Datei — JSON / CSV / Excel als Dataset hochladen.
3. Bei „Bestehende DB verbinden“:
   • DB-Typ-Dropdown — MySQL (Standardport 3306) · MariaDB (3306) · PostgreSQL (5432) · MongoDB (27017). Die Auswahl füllt den Standardport automatisch aus.
   • Host · Port · Datenbankname · Benutzer · Passwort
4. Unten [Verbindungstest] klicken — bei Erfolg springt der Assistent automatisch zu Schritt 2, bei Fehler erscheint unten eine rote Meldung.

Nach der Verbindung führt der Assistent automatisch durch zwei weitere Schritte.

Schritt 2 — Tabellenauswahl

• Die Tabellen der DB erscheinen als Zeilen (Name · Icon · Zeilenzahl · Kommentar).
• Klick auf eine Tabelle — die rechte Seite klappt auf und zeigt ihre Feldliste.

Schritt 3 — Dataset registrieren (hier werden die „Dataset“-Metadaten finalisiert)

• Links — Registrierungsformular:
  • Dataset-Name (Pflicht) — z. B. „Menüliste“
  • Dataset-Beschreibung
  • Ziel-Tabelle-Dropdown (Pflicht)
  • Primary-Key-Feld — wird automatisch auf id gesetzt, falls vorhanden.
  • Eingeschlossene Spalten — * (alle) oder kommasepariert wie id,name,price
  • WHERE-Klausel — z. B. stock_flag = 1
  • LIMIT — z. B. 0,100 (Offset 0, 100 Zeilen)
  • ORDER BY — z. B. created_at DESC
  • Checkbox „Shared“ — für andere Nutzer im Nur-Lese-Modus freigeben.
• Rechts — Query-Tester: Klick auf [Query testen] führt das tatsächliche SQL mit den aktuellen Einstellungen aus und zeigt Anzahl Zeilen, Spalten und eine Live-Vorschau. Bedingungen links so lange anpassen, bis das Ergebnis stimmt.
• [Speichern] klicken → der Assistent schliesst → auf dem Hauptbildschirm erscheint eine neue Dataset-Karte.

Ein Klick auf das ▶ (Play)-Icon einer Dataset-Karte öffnet den Datenbank-Editor als Vollbild-Overlay. Er hat drei Panels.

• Links — Objekt-Browser: oben Tabs (Tables / Views / Procedures / Functions). Klick auf eine beliebige Tabelle zeigt im Inspector darunter Spalten · Typen · Kommentare. Die Befehlsleiste über der Liste enthält CREATE-Skript kopieren, Drop, Update, Insert, Delete, Join, Reverse, Refresh.
• Mitte — SQL-Editor: mehrere Queries als Tabs. Doppelklick auf einen Tab zum Umbenennen. In der Toolbar ▶ Run-Button plus Shortcuts F5 / F9. Ergebnisse lassen sich als TSV / CSV / JSON / SQL exportieren oder per „An Makro senden“ direkt an ein Makro übergeben.
• Rechts — Ergebnisraster: Zeilen der letzten Query, Editierung auf Zellenebene.

Nutzen Sie diesen Schritt, um zu bestätigen, dass die Daten, die Sie gleich veröffentlichen, wirklich so aussehen, wie Sie wollen. Passt es nicht, hier zuerst korrigieren.

Jetzt stellen Sie dieses Dataset als REST-API bereit. Klicken Sie in der Dataset-Karte auf den API-Einstellungen-Button (Stecker-Icon), um das API-Einstellungs-Modal zu öffnen.

1. Basics
   • Namespace (Pflicht) — wird das Ende der URL. menu_list erzeugt /endpoint/menu_list.
   • Tabelle — Ziel-Tabelle (aus dem Dataset automatisch befüllt)
   • JOIN-Tabelle — optionale zweite Tabelle für Joins
   • Page var — Name des Query-Parameters für Paginierung (Default page)
   • Per page — Default 50
   • Cache-Zeit — 0–1440 Minuten
2. Response-Autogenerierung: Klick auf [Auto-generieren] baut die JSON-Form als main_container → main_fields → item_container → item_fields → (optional) detail auf. Jedes Feld ist ein Paar „JSON-Schlüssel → SQL-Variable“ (z. B. name → $customer_name). Felder können manuell ergänzt oder entfernt werden.
3. Zugriffssteuerung (ACL) — siehe unten.
4. Mit [Speichern] die API-Definition sichern.
5. Mit [Deploy] die Deploy-Pipeline laufen lassen — ein Fortschrittsbalken erscheint, nach Abschluss ist der Endpoint live.

Nach dem Deploy ist der Endpoint (bei Custom-Domain) öffentlich unter:

• GET https://happycat.apidealder.net/endpoint/menu_list
• GET https://happycat.apidealder.net/endpoint/menu_list?page=2
• GET https://happycat.apidealder.net/endpoint/menu_list/csv — CSV-Download

API-Key-Authentifizierung (ACL-Bereich im API-Modal):

• API-Key — Klick auf [Auto-generieren] liefert einen zufälligen Key im UUID-Stil.
• Übertragung — header oder param.
• Header-Name z. B. X-API-KEY / Param-Name z. B. api_key.

Aufrufbeispiele

Per Header:

curl -H "X-API-KEY: your-secret-key" https://happycat.apidealder.net/endpoint/menu_list

Per Query-Parameter:

curl "https://happycat.apidealder.net/endpoint/menu_list?api_key=your-secret-key"

Browser fetch:

const res = await fetch('https://happycat.apidealder.net/endpoint/menu_list', { headers: { 'X-API-KEY': 'your-secret-key' } });
const data = await res.json();

Zusätzliche Schutzmassnahmen (alle im ACL-Bereich):

• IP-Whitelist — Wildcards (192.168.1.*) und CIDR (10.0.0.0/24).
• Referer-Einschränkung — Liste erlaubter Domains.
• Rate limit — maximale Anfragen pro Minute.

Aus der oberen Navigation oder dem Dashboard Services → Datensammlung klicken, um die Parser-Regeln-Liste zu öffnen. Das Layout entspricht der Datenbank-Seite.

• Linke Sidebar — oben ein blauer Button [+ Neue Parser-Regel], darunter „Kürzlich“, „Öffentliche Regeln“, „Meine Regeln“ (mit Benutzerfilter).
• Hauptbereich — Toolbar mit Suche, Grid/List-Umschalter, Paginierung. Darunter vorhandene Regeln als Karten (oder Tabellenzeilen).
• Icons auf jeder Karte — ⚗️ (Reagenzglas) Item-Test · ⏱ (Uhr) Zeitplan (zeigt ein „Max“-Band, falls nicht im Tarif) · Bearbeiten · Duplizieren · Löschen. Karten zeigen Regelname, Testseite, Beschreibung und Erstelldatum.

Klick auf [+ Neue Parser-Regel] in der Sidebar → ein 3-Schritte-Assistent öffnet sich.

1. Schritt 1 — Überblick: vier Info-Karten (Extrahieren / Crawlen / Feld-Mapping / Wiederverwendung) und ein Pipeline-Diagramm (Parser-Regel → Datenbank / Makro / Scheduler / API). Keine Eingabe, nur Kontext.
2. Schritt 2 — Datenbankverbindung: ein Dataset aus einer Kartenliste auswählen, in das die gescrapten Daten landen. Jede Karte zeigt Dataset-Name, DB-Typ, Tabelle und Domain. Nach der Auswahl [Weiter] drücken — ein 3-Phasen-Auto-Flow läuft („Agent verbinden → Parser-Engine deployen → Deploy abgeschlossen“), der die Parser-Engine auf den gewählten docker-Agent installiert.
3. Schritt 3 — Regel registrieren:
   • Regelname (Pflicht) — z. B. „Naver News IT-Sektion“
   • Beschreibung — ein Satz zum Inhalt der Sammlung
   • Klick auf [Regel erstellen] schliesst den Assistenten und Sie landen direkt im Parser-Einstellungsbildschirm.

Der Regel-Editor öffnet sich mit dem Feld Ziel-URL oben. Geben Sie die zu scrapende Seite an (z. B. https://news.example.com/it) und konfigurieren Sie die Extraktion. Der Parser kombiniert drei Ansätze.

• Loop Splitter (3 Eingaben — Haupt + 2 sekundäre) — ein Zeichenkettenmuster, das das HTML in wiederholte Einheiten zerschneidet. Beispiel: Teil von <li class="article"> als Splitter — jeder Artikel wird zu einem Item.
• XPath-Selektoren (bis zu 3 Ebenen) — Titel / URL / Bild innerhalb jeder Wiederholungseinheit per XPath. Der Selektor sollte auf eine Knotenmenge (Array) zeigen; liegt der Wert bei //h3/a/text(), geben Sie nur //h3/a ein.
• JSON-Selektoren (3 Ebenen) — liefert die Seite JSON, nutzen Sie Punkt-/Klammer-Syntax, um auf den Array-Pfad zu zeigen. Bei data.items[0].title geben Sie data.items ein, damit das Item-Array erzeugt wird.
• Funktions-Postprocessing — die Spalte „function“ wird auf jeden extrahierten Wert angewendet:
  • trim(@p) — Whitespace trimmen (@p ist der aktuelle Wert)
  • replace(old,new) / regex(pattern,replacement)
  • Direkte PHP-Aufrufe wie strtoupper(@p)
  • Eingebaute Helper: get_data() · slice() · remove() · map()

Der schnellste Weg ist nicht, Selektoren von Hand zu tippen — sondern einen Ausschnitt des Quelltextes (via Loop Splitter) in den AI Prompt zu füttern und die AI-Antwort die Regel selbst registrieren zu lassen. Genau das behandelt Schritt 4 unten.

Statt Dutzende Selektoren von Hand einzutippen, können Sie das Sample einer AI geben und die zurückgegebene fertige Regel anwenden. Für Einsteiger der empfohlene Pfad.

Voraussetzung — in Schritt 3 muss eine Ziel-URL eingegeben sein und der Extract-Test über den Tab „Test“ des Editors mindestens einmal gelaufen sein, damit ein Response-Body existiert. Dieser Body wird automatisch in den Prompt eingefügt.

A. Prompt zusammenbauen & kopieren

1. Im Test-Ergebnis-Panel oben auf den hervorgehobenen 🪄-Button „AI Prompt“ (Zauberstab) klicken.
2. Der Dokumenttyp (HTML / JSON / XML) wird automatisch erkannt, der Body extrahiert und in einen Prompt gegossen.
3. Direkt darunter füllt sich das Code-Editor-Panel mit einem Markdown-Prompt. Inhalt:
   • Einleitungsabsatz zur Aufgabe
   • HTML/JSON-Sample
   • Ziel-Definitionen — Wiederhol-Trenner, detail-URL-Feld, Unique Key, pro Spalte: Label, Variablenname, Typ, Split-Regeln, Postprocessing-Funktion
   • Ein Beispiel-JSON und die explizite Anweisung „Gib ausser JSON keinen Text aus“
4. Der Prompt ist mehrsprachig-bewusst (8 Sprachen: Koreanisch · Englisch · Japanisch · Chinesisch · Russisch · Deutsch · Französisch · Spanisch) — ein koreanisches Dokument erzeugt koreanische Labels, ein chinesisches chinesische usw.
5. Ins Panel klicken → Strg+A → Strg+C, um alles zu kopieren.

B. In die AI Ihrer Wahl einfügen und laufen lassen

1. In ChatGPT / Claude / Gemini einfügen und abschicken.
2. Die AI antwortet mit einer Regel-JSON.
3. Antwort (oder nur den JSON-Teil) kopieren.

C. Antwort einfügen, um Regelfelder automatisch zu füllen

1. Zurück im selben Panel auf den 📥-Button „Import Pattern“ (Importsymbol) klicken — ein Einfüge-Textbereich öffnet sich (Format-Hinweis inklusive).
2. Ihr JSON einfügen, dann [Pattern anwenden] klicken.
3. Wiederhol-Trenner, Selektoren, Unique Key und detail-URL-Feld landen automatisch oben in der Regel, und jede Spalte (Label, Variablenname, Typ, Split-Regeln, Postprocessing-Funktion) wird in einem Rutsch in die Feldliste eingetragen. Doppelte Variablennamen werden automatisch umbenannt, um Kollisionen zu vermeiden.
4. Der Editor wechselt automatisch zum „fields“-Tab, damit Sie sofort verifizieren können, und unten erscheint eine Zusammenfassungs-Toast wie „Pattern applied: N fields“.

Mit grob gesetzten Selektoren prüfen, ob sie wirklich das Gewünschte extrahieren. Zwei Einstiegspunkte:

• Das ⚗️-Icon auf der Regelkarte
• Oder der „Test“-Tab oben im Regel-Editor

Das Item-Test-Modal öffnet sich mit:

1. Obere Statusleiste — Zusammenfassung „N Items / M Spalten“. Ist N = 0, stimmt der Loop Splitter nicht — das zuerst beheben.
2. Export-Buttons — CSV · XLSX · JSON · HTML, praktisch, um dem Team ein Sample zu schicken.
3. Ergebnisraster — Row# + Spaltenüberschriften, automatisch aus dem ersten Item abgeleitet, eine Zeile pro extrahiertem Item.
4. Zellen-Hover — beim Überfahren erscheint ein „Copy“-Button, der den Wert in die Zwischenablage holt.

Sehen die Ergebnisse falsch aus: Modal schliessen, Selektoren/Funktionen justieren, erneut testen — diese Schleife ist ~70 % der Parser-Arbeit.

Sobald der Test sauber aussieht, bestätigen Sie die Speichereinstellungen im Bereich „Save“ des Editors.

• Save type-Dropdown — auf „Database“ (bereits voreingestellt, wenn Sie im Assistenten ein Dataset gewählt haben).
• Ziel-Tabelle / Collection-Name — dort landen die Zeilen. Existiert sie nicht, erstellt der Agent sie beim ersten Lauf — mit den in Ihrem Test erkannten Spalten.
• DB mode — Dataset (verknüpft) / Custom. Custom erlaubt direktes Eintragen von Host · Benutzer · Passwort · Datenbank (nützlich, wenn Sie in eine andere DB schreiben als die aus dem Assistenten).

Was beim Lauf passiert

1. Sie starten die Regel (Button „Persist“ im Test oder der Zeitplan aus dem nächsten Schritt) und der docker-Agent ruft die Ziel-URL ab.
2. Items werden extrahiert: Loop Splitter → XPath/JSON-Selektoren → Funktionsverarbeitung.
3. Extrahierte Items werden in die Ziel-Tabelle eingefügt. Duplikate (nach URL-Hash oder dem gewählten Schlüssel) werden automatisch übersprungen oder aktualisiert.
4. Weil diese Tabelle in derselben DB lebt wie die Dataset-Karte aus Schritt 5, liefert der zuvor gebaute API-Endpoint /endpoint/... ab sofort die frischesten Daten.

Der letzte Schritt bringt das Ding zum selbstständigen Laufen. Klick auf das ⏱-Icon (Uhr) einer Regelkarte öffnet das Zeitplan-Modal. Die Funktion ist nur in MAX verfügbar — in anderen Tarifen zeigt das Icon eine „Max“-Banderole.

1. Zeitplan-Felder:
   • Startzeit — Stunde (0–23) + Minute (0–59). z. B. 03:30 Uhr.
   • Intervall (Minuten) — 60 = stündlich, 1440 = einmal pro Tag.
   • Active — Schalter. Off behält die Konfiguration, pausiert aber Läufe.
   • Run mode — Single URL (eine Ziel-URL) oder Batch (durch eine URL-Liste, eine pro Zeile).
2. Klick [Speichern] — der Zeitplan wird in QuickStart gespeichert und automatisch mit dem ausgewählten docker-Agenten synchronisiert, der ihn tatsächlich fährt.
3. Ab da zündet der Agent die Regel in Ihrem Intervall und leitet Zeilen ins Dataset. QuickStart signalisiert nur — es liegt nicht im Traffic-Pfad, keine Bandbreiten-Overhead.

Verkettung mit einem Makro (optional) — im Fluss-Diagramm des Editors per Dropdown „Select macro“ ein Makro wählen. Direkt nach Abschluss eines Scrapes läuft es. Beispiel: gerade gescrapte Produktpreise mit gestern vergleichen; bei Rückgang von N % einen Slack-Alert senden.

Von der Produktions-DB (B) direkt in die Analyse-DB (C) schieben wirkt am einfachsten, aber in der Praxis heißen Spalten anders, personenbezogene Daten sind drin und Zeitzonen unterscheiden sich — es braucht einen Ort dazwischen zum Aufräumen. Genau dafür ist der QuickStart-Datensatz (A) da.

• B (externe Quelle) — der laufende Shop oder das ERP. Anfassen heißt Betriebsausfall, deshalb nur lesen.
• A (eigener Datensatz · Docker) — die eigene Werkbank. Spalten umbenennen, URLs ersetzen, überflüssige Felder rauswerfen, Aggregate ergänzen — alles hier.
• C (externes Ziel) — die BI-Datenbank, die Partner-DB, jedes Ziel. Nur die bereits saubere Version aus A fließt hinein.

Was das bringt:

1. B und C können unterschiedliche Engines haben (MySQL ↔ PostgreSQL …) — A vermittelt.
2. Daten bleiben in A; wird C gelöscht, neu nachschieben genügt. Rollback ist billig.
3. In A lässt sich beliebig iterieren und testen, erst wenn es passt, geht es in C.

Zuerst legen wir den Datensatz (A) an, in dem die Daten aus B landen.

1. Obere Navi → Daten → Datenbank. Die Liste öffnet sich.
2. Oben rechts [+ Neuer Datensatz]. Eintragen:
   • Name — z. B. replication_staging
   • DB-Typ — MySQL oder PostgreSQL. Gleicher Typ wie B spart Konvertierung.
   • Host — standardmäßig die DB im Docker-Agent (wird automatisch gesetzt).
   • DB-Name — z. B. my_staging
3. [Speichern] — eine neue Zeile erscheint, daneben die Icons 🔌 Verbindungstest · Bearbeiten · Migration · Export.
4. Erst 🔌 drücken und "Verbindung erfolgreich" bestätigen; sonst nicht weitermachen.

Dieser Datensatz A ist der Zwischenpuffer, in dem die Daten von B und die Daten für C kurz liegen.

In der Liste bei der Zeile A auf das Icon Migration klicken. Ein großes, dreispaltiges Modal öffnet sich.

• Links Deck A — der neu angelegte Datensatz (replication_staging) ist schon verbunden, Tabellen und Felder sind sofort sichtbar.
• Mitte Werkzeugleiste — Richtungsanzeige (A → B / B → A), [Umschalten]-Button, darunter die Aktionen (⚡ hard_sync, 🔄 soft_sync, ➕ append …).
• Rechts Deck B — Formular für die entfernte DB.

Standardrichtung ist A → B (rausschieben), wir wollen aber aus B lesen, also in der Mitte [Umschalten] klicken, Richtung wird B → A. Deck B zeigt "source", Deck A "target".

Jetzt die Verbindung der externen Produktions-DB (B) in Deck B eintragen:

1. Host — z. B. origin.acme.com oder 10.0.1.23
2. DB-Typ — MYSQL · POSTGRESQL · MONGODB · ELASTICSEARCH
3. DB-Name — z. B. sales_db
4. Account / Passwort — dringend einen Read-only-Account verwenden. Nur SELECT, dann kann B nichts passieren.
5. [Verbindungstest] → "Verbindung erfolgreich" und die Tabellenliste wird automatisch geladen.

Nach erfolgreicher Verbindung zeigt Deck B die Tabellenliste, oben rechts erscheint [Weiter]. Drauf klicken schaltet Deck B von "Verbindung" auf "Tabellenauswahl" um.

1. Tabellen wählen — gewünschte anhaken. [Alle Tabellen] markiert alles. Beim ersten Lauf lieber klein anfangen, nur orders · customers · products.
2. Filter (optional) — im WHERE-Feld unten in Deck B Bedingungen wie created_at > '2026-01-01'. LIMIT 0, 1000 holt nur 1000 Zeilen als Stichprobe. Beim ersten Lauf immer LIMIT setzen.
3. Felder prüfen (optional) — Icon neben der Tabelle öffnet die Spaltenliste; Spalten, die man nicht mitnehmen will (password_hash, national_id …), abwählen.
4. ⚡ hard_sync starten — in der Mitte [hard_sync] (Blitz-Icon) klicken. Dialog "hard_sync für {count} Tabellen ausführen?" — bestätigen. In A werden die Tabellen pro Stück DROP → CREATE → INSERT neu aufgebaut. Der Fortschrittsbalken zeigt aktuelle Tabelle / Gesamt und den Zeilen-Fortschritt.
5. Am Ende steht im Log unten "Success"; die Tabellenliste in Deck A aktualisiert sich und zeigt die neuen Tabellen.

Andere Aktionen als hard_sync:

• 🔄 soft_sync — nur UPDATE/INSERT/DELETE nach Primärschlüssel gegen A; bereits vorhandene A-Daten bleiben. Für regelmäßige Synchronisation.
• ➕ append — fügt nur IDs ein, die es in A noch nicht gibt. Für inkrementelles Einlesen.
• 🔀 merge — fügt nur Zeilen ein, deren ID sich nicht mit A überschneidet.

Die Rohdaten aus B liegen jetzt in A, aber so direkt nach C geschickt gibt es meistens Probleme. Zum Aufräumen zwei Wege.

① Ersetzung im Migrations-Modal — in der Werkzeugleiste ist unten ein Block "Ersetzung einrichten" für Massen-Stringersetzung. Beispiel: in B lautet die Bild-URL https://cdn-old.acme.com/, C erwartet https://cdn.acme.com/:

1. Modus [Text] (oder [Regex]) wählen.
2. Links https://cdn-old.acme.com/
3. Rechts https://cdn.acme.com/
4. Beim nächsten hard_sync / soft_sync wird der Wert während des Transfers ersetzt und so in A (oder in Schritt 6 in C) geschrieben. Die Quelle bleibt unverändert.

② Direkt im SQL-Editor — zurück in die Datensatzliste, bei A auf Editor klicken und SQL absetzen.

• ALTER TABLE orders DROP COLUMN password_hash; — sensible Spalten entfernen
• UPDATE orders SET created_kst = CONVERT_TZ(created_at, 'UTC', 'Asia/Seoul'); — Zeitzone umrechnen
• CREATE TABLE orders_summary AS SELECT product_id, COUNT(*) cnt, SUM(amount) total FROM orders GROUP BY product_id; — Aggregat-Tabelle

Vor Schritt 6 mit SELECT * FROM orders_summary LIMIT 20; kurz das Ergebnis ansehen.

Jetzt die aufgeräumten Daten aus A ins externe Ziel (C) schieben. Aus der Datensatzliste erneut die Migration von A öffnen.

1. Richtung prüfen — in der Mitte muss A → B stehen, wobei B im UI jetzt unser C ist. Steht noch B → A aus Schritt 3, auf [Umschalten] drücken. Deck A wird Quelle, Deck B Ziel.
2. Ziel-Verbindung in Deck B (= C) eintragen — Host warehouse.acme.com, Typ POSTGRESQL, Name reporting, Account mit INSERT/UPDATE-Rechten. [Verbindungstest] → erfolgreich.
3. Tabellen in Deck A wählen — orders_summary · products · customers_clean etc., also die in A bereits aufbereiteten.
4. Aktion wählen:
   • C ist brandneu: ⚡ hard_sync, Struktur wird mitgenommen, fehlende Tabellen werden auf C automatisch angelegt.
   • C enthält schon Daten und das ist ein Abgleich: 🔄 soft_sync, UPDATE/INSERT/DELETE gegen C auf Basis von A.
   • C sammelt nur an: ➕ append, nur neu in A erschienene IDs landen in C.
5. Ausführen — bestätigen, Fortschrittsbalken verfolgen. Bei Netzaussetzern werden Zeilen in Chunks geschickt; ein erneuter Lauf setzt dort fort, wo abgebrochen wurde.

Ist die Pipeline einmal von Hand durch, in ein Makro packen für den Zeitplan. Service → Makro, neues Makro, im Code die Migrations-Aktion aufrufen.

• Rumpf ungefähr so: fetch('/dataset/api/mig_run', { method: 'POST', body: JSON.stringify({ dataset_id: 123, action: 'soft_sync', deck_b: {host, db_name, user, password}, sel_tables: ['orders'] }) }). Die exakten Parameter bekommt man am sichersten, indem man den Button einmal manuell klickt und den Request aus dem Network-Panel kopiert.
• Im Reiter Zeitplan des Makros einen Cron setzen. Z. B. täglich 3 Uhr — 0 3 * * *.
• B → A und A → C als zwei getrennte Makros halten, damit ein Ausfall auf einer Seite nicht die andere blockiert. Die Reihenfolge über das success-Feld des ersten Makro-Ergebnisses in den zweiten verketten.

Prüf-Liste:

1. In C SELECT COUNT(*) FROM orders und mit A und B vergleichen.
2. Eine zufällige, aktuelle ID nehmen und die Spaltenwerte in B · A · C vergleichen.
3. Absichtlich eine Zeile in B einfügen und verfolgen, ob sie binnen 5–10 Min. in A und dann in C landet. Nicht angekommen → Makro-Ausführungs-Log und Migrations-Ergebnislog ansehen.

In diesen Fällen schlägt Paste-to-Insert jedes handgeschriebene SQL klar:

• Marketing liefert eine Excel mit 500 Gutscheincodes, die in die Service-DB sollen.
• Design schickt ein Google Sheet mit Produktname · Preis · Kategorie, alles auf einmal hochladen.
• Ein Partner schickt eine CSV mit Mitgliederliste, die 1:1 importiert werden soll.
• Sie wollen dem KI-Assistenten eine Tabelle mit 100 vorbereiteten Beispielen hinterlegen.

Der Zelleditor verhält sich wie Excel: Zeilen × Spalten-Grid. Strg+C in Excel und Strg+V in einer Editor-Zelle — Tab oder Komma als Trenner werden automatisch erkannt und Zeilen landen direkt. Kein Feldmapping-Dialog: ab der Startzelle fließen die Spalten nach rechts.

Obere Navigation → Daten → Datenbank. Die Liste eigener Datensätze erscheint als Karten oder Zeilen.

1. Zeile eines eigenen Datensatzes (user_id = Sie) finden. Öffentliche Datensätze sind read-only.
2. Icon Zelleditor in den Zeilen-Aktionen klicken. Ein bildschirmfüllendes Modal öffnet sich.
3. Aufbau: links Optionspanel (Tabelle · Seitenschritt · Sortierung · Suche · Ersetzen); in der Mitte Grid; rechts Toolbar (Speichern · Zeile +/– · Undo/Redo · Kopieren · CSV/SQL-Export · ✨ KI-Assistent).
4. Im linken Dropdown die Zieltabelle wählen. Ihre bestehenden Zeilen laden ins Grid. Leere Tabelle → leeres Grid.

Vor dem Einfügen unbedingt Spaltenreihenfolge in Excel = Spaltenreihenfolge der Tabelle sicherstellen. Sonst landen Werte in falschen Feldern.

• Spaltenköpfe — die erste Zeile im Grid zeigt Namen und Typen. Excel muss von Spalte 1 links nach rechts zu dieser Reihenfolge passen.
• Primärschlüssel (PK) — mit 🔑 markiert. Bei auto_increment id die id-Spalte in Excel weglassen; die DB vergibt sie beim INSERT.
• NOT NULL — rot markierte Köpfe dürfen nicht leer sein. In jeder Zeile füllen.
• Zu viele / zu wenige Spalten — Überschuss rechts wird ignoriert, Fehlstellen rechts bleiben leer.

Passt die Struktur nicht, entweder das Grid über Grid erzeugen (X × Y) im linken Panel neu aufsetzen oder in Excel die Spalten umsortieren.

Kern des Ablaufs. In Excel/Sheets den Bereich ohne id-Spalte markieren und Strg+C. Zurück im Editor:

1. Startzelle klicken. Meist ganz links, eine Zeile unter der letzten bestehenden Zeile — neue Zeilen laufen hinten an.
2. Strg+V. Der Editor erkennt Tab (Excel-Standard) oder Komma (CSV) und verteilt die Zellen automatisch.
3. Das Grid wächst; neue Zeilen bekommen einen leicht getönten Hintergrund — "neu, noch nicht gespeichert".
4. Weitere Bereiche über neue Startzelle und erneutes Einfügen anhängen.

Trennzeichen manuell — das Trennzeichen-Dropdown im linken Panel bietet Tab · Komma · sicheres Komma (Anführungszeichen geschützt). CSV mit Kommas innerhalb von Anführungszeichen: sicheres Komma nehmen.

Vor dem Speichern einmal mit dem Auge durchgehen. Drei Zustände werden farbig markiert.

• Getönte Zeile — frisch eingefügte "neue" Zeile. Beim Speichern INSERT.
• Gelber Punkt in der Ecke der Zelle — geänderte Zelle einer bestehenden Zeile. Beim Speichern UPDATE.
• Graue Zeile — zum Löschen markiert. Statusbar zeigt "🗑 X Zeilen werden gelöscht" und Button [Wiederherstellen].

Häufige Editieraktionen:

• Doppelklick auf Zelle zum Eintippen.
• Rechte Toolbar / — leere Zeile am Cursor / aktuelle Zeile löschen.
• Strg+Z · Strg+Y — Rückgängig/Wiederholen (bis zu 50 Snapshots).
• Suchen & Ersetzen — im linken Panel; Text oder Regex, wirkt auf das gesamte Grid.

Die Statusbar zeigt ✏ X Zeilen, Y Zellen bearbeitet. Weicht die Zahl ab, vor dem Speichern korrigieren.

Alles ok? Über den Button Speichern rechts oder Strg+S. Der Editor baut und führt aus:

• Neue Zeilen → INSERT INTO Tabelle (col1, col2, ...) VALUES (...). Auto_increment-PKs werden von der DB vergeben.
• Zeilen mit geänderten Zellen → UPDATE Tabelle SET col=val WHERE id=..., nur betroffene Spalten.
• Zum Löschen markierte Zeilen → DELETE FROM Tabelle WHERE id=....

Erfolg: Toast "X Zeilen gespeichert". Die Tönung neuer Zeilen verschwindet; leere id-Zellen bekommen die DB-Nummern. Die Zeilen sind nun ganz normale Daten.

Bei Fehlschlag zeigt das Memo-Panel die Ursache — meist NOT NULL verletzt, Typ passt nicht, Unique-Konflikt. Zeile korrigieren und erneut speichern.

as if to be ist eine mustererkennende Anweisungsform: "Wenn das fertige Ergebnis (Sollwert) so aussieht, verwandle das Rohmaterial (Istwert) analog." Statt das Regel-Wie auszuformulieren, zeigt man der KI ein paar Regel-Ergebnisse; sie verallgemeinert auf den Rest.

Der Zelleditor bringt dafür zwei Marker (Farbe 1 · Farbe 2).

• Marker 1 (Sollwert · standardmäßig türkis) — korrekte Beispiele des gewünschten Ergebnisses.
• Marker 2 (Istwert · standardmäßig orange) — rohe Zellen, die die KI ausfüllen soll.

Warum das stark ist:

1. Keine verbale Regelbeschreibung nötig — Beispiele sprechen für sich.
2. Funktioniert auch bei Regeln, die zu subtil für Worte sind (Tonfall, Nuance, Stil).
3. Ein Prompt deckt hunderte Zellen ab. Das "Zeile-für-Zeile-Kopieren zur KI" entfällt.
4. Beispiele anpassen hebt die Qualität sofort. Tuning-Zyklus: Sekunden.

Datensatz im Zelleditor geöffnet; Struktur vorab anlegen:

1. Quellspalte — was die KI liest. z. B. de_text, product_desc, address_raw.
2. Zielspalte — was die KI befüllt. z. B. en_text, summary, city. Fehlt sie, per SQL anlegen: ALTER TABLE ... ADD COLUMN en_text TEXT;.
3. 2–5 Saat-Zeilen — Zielspalte per Hand ausfüllen. Drei gute Beispiele entscheiden die Qualität für 500 Zeilen.

Gute Beispiele auswählen:

• Vielfalt — kurz, lang, Spezialfall. Zu ähnliche Beispiele lassen die KI an Randfällen scheitern.
• Schwierigkeitsmix — leicht, mittel, knifflig.
• Stil explizit — Zeilenumbrüche, Groß/Klein, Förmlichkeit muss an den Beispielen sichtbar sein.

In der rechten Marker-Palette die erste Farbe (türkis · Sollwert) klicken, so wird sie aktiv (hervorgehobener Rand).

1. Jede per Hand gefüllte Beispielzelle im Grid einmal klicken — sie wird türkis, also als "Sollwert" markiert.
2. Marker toggeln: erneuter Klick entfernt den Marker.
3. Bereich per Ziehen markieren, dann Farbe klicken — der gesamte Bereich wird auf einmal markiert.

Label auf Aufgabe umstellen — Stift neben dem Label ("Sollwert" Standard) klicken. Bei Übersetzung "Englische Übersetzung", bei Summary "Einzeiler", bei Klassifikation "Kategorie". Das Label landet in Schritt 5 im Prompt und präzisiert die Aufgabe für die KI.

Jetzt den zweiten Marker (orange · Istwert) aktivieren.

1. Leere oder rohe Zellen der Zielspalte per Ziehen markieren — z. B. en_text Zeilen 4 bis Ende.
2. Einmal auf die orange Farbe klicken — alle werden orange, das sind die KI-Targets.
3. Quellspalte (de_text) muss nicht markiert werden; die KI liest sie automatisch pro Zeile.
4. Auch dieses Label umbenennen: "Ins Englische", "Kürzen", "Kategorie zuweisen" — eine Einwort-Anweisung für die KI.

Am Ende zeigt das Grid türkise Zellen (Musterlösungen) + orange Zellen (zu befüllen) nebeneinander — das ist "as if to be" in Reinform.

Rechte Toolbar → ✨ KI-Assistent. Der Editor liest die Marker, baut einen strukturierten Prompt und legt ihn automatisch in die Zwischenablage. Unten erscheint "KI-Prompt in die Zwischenablage kopiert".

Struktur (konkreter Text je nach Labels/Beispielen):

1. Systemnachricht — "You are a data transformation assistant"
2. Aufgabenbeschreibung — aus den Labels. z. B. "Transform each 'Current Value' cell according to the pattern shown in 'Desired Value' examples."
3. Beispielzellen-Liste — (Zeile, Spalte, Wert) aller türkisen Zellen. Muster-Lernen.
4. Zielzellen-Liste — (Zeile, Spalte, Rohwert) aller orangen Zellen.
5. Ausgabeformat — fordert ein JSON-Array [{"pos":"Zeile,Spalte","return_txt":"Wert"}, ...].

Abbruchbedingung — ohne Marker kommt nur eine Warnung. Zurück zu Schritt 3 und 4 und markieren.

Prompt in Claude · ChatGPT · Gemini einfügen und absenden. Die KI antwortet mit einem JSON-Array.

1. Nur den JSON-Teil markieren und Strg+C. Erklärtext davor/danach ist egal — nur das Array kopieren.
2. Im Zelleditor: Strg+V in die Memo-Textbox unten rechts. Memo ist die Landebahn für KI-Output.
3. Kurz mit dem Auge: [{"pos":"3,5","return_txt":"Translated"},{"pos":"4,5","return_txt":"Another"}, ...].

KI-Geplapper entfernen — "Here is the JSON you asked for:" kommt oft davor. Nur das Array ([ … ]) verwenden; der Anwenden-Button in Schritt 7 parst strenges JSON.

JSON im Memo — Button 📥 KI-Ergebnis anwenden in der rechten Toolbar. Der Editor parst das JSON und schreibt return_txt in die Zelle an pos. Toast "X Zelle(n) angewendet".

• Befüllte Zellen bekommen den Geändert-Punkt (gelb) — noch nicht in der DB.
• Einzelne Zellen nicht zufrieden? Strg+Z setzt zurück, verwirft aber die ganze KI-Runde. Meist schneller: nur die schlechten Zellen von Hand korrigieren.
• Passt alles → Strg+S. Gleicher UPDATE-Weg wie Abschnitt 1 Schritt 6.

Schleifen- und Batch-Strategie:

1. Erste Runde: nur 10 Stichproben prüfen, bevor Sie alles anwenden. Abweichung → Beispiele/Labels in 3–4 anpassen und Prompt neu erzeugen.
2. Passt es: nächste Seite, nächste Markierung, Schritte 5–7 wiederholen.
3. Zum Schluss eine Meta-Spalte (batch_note) mitlaufen lassen, die Beispiele pro Abschnitt dokumentiert — später trivial re-runbar bei Stiländerung.

Konkret bleibt es greifbar. Café "Sodam" braucht eine digitale Speisekarte auf einem Tablet am Eingang. Von Grund auf bauen ist langsam; die Marktplatz-Lösung menupan nehmen und auf Café-Branding ummöbeln ist drastisch schneller.

Was wir in 30–45 Min. fertig bekommen:

• Logo — das Standard-menupan-Logo durch das "Sodam"-Logo ersetzen.
• Speisekarte — Demo-Einträge (Americano 4500 KRW etc.) gegen das echte Sortiment austauschen.
• Farben & Schrift — Standardblau auf warmes Beige + Dunkelbraun umstellen, Schrift auf eine gut lesbare koreanische Type wechseln.
• Live — auf der eigenen Domain veröffentlichen, etwa menu.sodam.kr.

Warum forken?

1. Layout, DB-Schema und Admin-Oberfläche sind fertig — spart 90% Aufbauzeit.
2. Der Fork läuft unter Ihrem Konto, Ihrer Domain, Ihrer DB; das Original bleibt unangetastet, nur die Kopie wird editiert.
3. Spätere menupan-Updates betreffen Ihren Fork nicht — Ihre Anpassungen bleiben.

Obere Navigation → Community → Lösungsmarkt (oder /solution). Eine Galerie aus Karten erscheint.

1. Filter oben (Alle / Project / Macro / Community / Direct) — Project wählen — oder im Suchfeld menupan / digitale Speisekarte.
2. Karte klicken: Detailseite mit Vorschauen, Funktionsbeschreibung und benötigten Ressourcen (Domain / DB).
3. Auf der Detailseite Als neues Projekt forken klicken — das Fork-Modal öffnet sich.
4. Eingaben:
   • Domain — aus den eigenen aktiven Domains, etwa menu.sodam.kr. Keine Domain? In einem zweiten Tab Einstellungen → Domains öffnen und eine kostenlose Subdomain (~.apidealder.net) holen, dann zurück.
   • Datensatz — die DB für die Menüdaten. Neu oder ein vorhandener eigener.
   • Projektname & Beschreibung — z. B. Name sodam_menu, Beschreibung "Café Sodam, In-Store-Menüboard".
   • "Auto-Deploy"-Schalter — einschalten, damit der erste Build sofort nach Fork-Ende läuft. Beim ersten Mal empfohlen.
5. [Fork ausführen] klicken. Nach 30 Sek. – 2 Min. erscheint ein Erfolgs-Toast. Im Sidebar Meine Projekte erscheint die neue Zeile oben, der Workspace öffnet sich automatisch.

Zwei Hälften: (a) neues Logo per Remote-Verwaltung hochladen, (b) Logo-URL im Programm-Editor ersetzen.

(a) Logo via Remote hochladen

1. Obere Nav → Service → Remote-Verwaltung. Links die Domain Ihres geforkten Projekts (menu.sodam.kr) auswählen. Grüner Punkt = ok.
2. Pfadleiste in der Mitte: /public/assets direkt eintippen + Enter.
3. Unten [Datei hochladen]: das Café-Logo (sodam_logo.png) auswählen. Für eine Einzeldatei kein Archiv nötig.
4. Browser-Direktaufruf: https://menu.sodam.kr/assets/sodam_logo.png sollte 200 OK + Bild liefern.

(b) Logo-URL im Programm-Editor ersetzen

1. Zurück im Workspace → Projekt → Programme. Liste der zugehörigen Programme (main, menu_list, …) erscheint.
2. Doppelklick auf das Programm mit dem Logo (meist main) — Editor öffnet sich.
3. Suchen/Ersetzen (Strg+H) oben rechts: bisherige Logo-URL suchen, häufig /assets/menupan_logo.png.
4. Suchen: menupan_logo.png, Ersetzen: sodam_logo.png, Alle ersetzen. HTML und CSS gleichzeitig.
5. Strg+S speichern. Im rechten Vorschaubereich sollte das eigene Logo erscheinen.

menupan bringt eine Admin-Seite mit, damit das Personal Einträge selbst pflegen kann. Zwei Wege; klare Empfehlung: Admin-Seite.

(Empfohlen) Admin-Seite

1. https://menu.sodam.kr/admin (oder den von menupan definierten Pfad) öffnen und einloggen. Standardzugang steht im README der Lösungsdetailseite.
2. Im Sidebar Menüverwaltung. Kategorien (Kaffee · Dessert · Koffeinfrei) und Positionen (Americano · Latte · …) als Tabelle/Karten.
3. Demo-Einträge alle löschen, dann echte Position für Position hinzufügen:
   • Name (Americano) · Preis (4500) · Beschreibung (...) · Kategorie (Kaffee) · Foto (URL des in Remote hochgeladenen Bildes).
4. Tagesgeschäft — Bearbeiten, Sortieren, Sichtbarkeits-Schalter — alles hier. Auch Personal kann diese Seite bedienen.

(Alternative) Direkt in der DB

• Für Bulk-Operationen, die die Admin nicht abdeckt (z. B. alle Kaffees um 500 erhöhen): Daten → Datenbank → der Datensatz vom Fork → Zelleditor.
• Tabelle menu_item direkt bearbeiten oder im SQL-Editor: UPDATE menu_item SET price = price + 500 WHERE category='Kaffee';. (Siehe Best Practices → Zelleditor · Einfügen in DB.)
• Achtung: Spalten, die die Admin nicht kennt, oder PK/FK-Verstöße können die Admin lahmlegen. Deshalb gehört der Alltag in die Admin.

Vor dem Code: im Browser den Wunschfarbton finden. Änderungen sind temporär — Reload setzt zurück, also gefahrlos experimentieren.

1. Veröffentlichtes Menü (https://menu.sodam.kr) in Chrome öffnen, F12 für DevTools (oder Rechtsklick → Untersuchen).
2. Pfeil-Symbol oben links in DevTools (Element-Picker) anklicken, dann den umzufärbenden Bereich (Header, Karten-Hintergrund) auswählen. Im rechten Panel Styles stehen die anzuwendenden Regeln.
3. Über einem Farbwert (background-color: #2563eb;) zeigt sich ein kleines Farbquadrat. Klick öffnet einen Farbpicker — ziehen oder hex eintippen.
4. Auch font-family: ...; wird so geändert: anderer Familienname ('Pretendard', 'Noto Sans KR', sans-serif).
5. Wenn die Kombi sitzt, hex-Codes und Schriftnamen notieren — für Schritt 6 (KI) oder Schritt 7 (Code-Übernahme).

Nützliche Kniffe:

• Mehrere Elemente vergleichen — wenn der Header passt, der Body aber nicht, beide live durchstimmen.
• Computed — zeigt den endgültigen Wert (mit Vererbung). Hilft bei Fragen "wo kommt das her?".
• :hover erzwingen — die :hov-Schaltfläche oben in Styles fixiert :hover·:focus, sodass auch Hover-Farben prüfbar sind.

Wirkt die Auswahl aus Schritt 5 noch nicht? Bitten Sie Claude / ChatGPT um Tonvorschläge — fünf bis zehn Kandidaten in einem Schwung. Prompt-Vorlage:

Ich baue eine digitale Speisekarte für Café "Sodam".
Stimmung: warm und ruhig, koreanische Cafékultur.
Raum: Holztöne, warmes gelbes Licht.

Aktuelle Palette:
- Header-Bg: #2563eb (Blau)
- Body-Bg:   #ffffff
- Text:      #1f2937
- Akzent:    #2563eb

Bitte 5 Paletten-Sets, die zu dieser Stimmung passen.
Pro Set 4 hex-Werte (Header / Body-Bg / Text / Akzent)
plus eine Kurzzeile, die das Gefühl beschreibt.

Außerdem 3 Google-Fonts (oder freie koreanische Schriften),
die für Koreanisch gut lesbar sind und zur Stimmung passen.

Die KI antwortet meist so:

• Set 1 (warmes Beige · dunkles Braun) — Header #6b4423, Body-Bg #f5ecd9, Text #3c2415, Akzent #c97a4a · fügt sich natürlich in Holztöne und gelbes Licht ein
• Set 2 (modern minimal) — …
• …

Kandidaten verifizieren:

1. Zurück in F12 (Schritt 5): jeden hex-Wert nacheinander einsetzen und das beste Set auswählen.
2. Mischformen ("Header aus Set 1, Akzent aus Set 3") sind oft die Gewinner. Auch notieren.
3. Für Schriften https://fonts.google.com nach den Namen durchsuchen und die echten Glyphen am Menü testen.

F12- und KI-Auswahl jetzt in echten Code. Damit überleben die Änderungen den Reload und sind für alle sichtbar.

1. Workspace → Projekt → Programme — Doppelklick auf das Design-Programm (meist main oder theme).
2. Reiter SCSS (oder CSS). Farbvariablen sind meist oben gesammelt ($primary-color, $bg-color etc.).
3. Hex-Werte einsetzen:
   $header-bg: #6b4423;
$body-bg: #f5ecd9;
$text-main: #3c2415;
$accent: #c97a4a;
4. Korean. Schrift: ganz oben im SCSS @import url('https://fonts.googleapis.com/css2?family=Pretendard&display=swap'); ergänzen, body font-family: 'Pretendard', sans-serif; setzen.
5. Strg+S. Die Vorschau unten sollte die Änderung sofort übernehmen.

Zwei Wege zum Deploy

• Variante A — manuelles Deploy (Standard): Button 🚀 Deploy in der Workspace-Toolbar. 1–2 Min. Build + Auslieferung; danach zeigt menu.sodam.kr das neue Design. Beim ersten Mal sicher.
• Variante B — Bei Speichern deployen (toll für schnelle Iteration): Schalter "Bei Speichern deployen" in der Toolbar. Ab dann löst jedes Strg+S automatisch ein Deploy aus. Perfekt für schnelle Farb-/Schrift-/Menüruns mit Live-Sicht. Im laufenden Betrieb besser ausschalten (Flackern beim Editieren vermeiden).

Nach dem Deploy https://menu.sodam.kr auf Smartphone und Tablet öffnen und finalisieren. Genau diese URL läuft am Tablet im Eingang — das ist die Speisekarte, die Gäste sehen.

Statt eigenes fetch() und eigenes v-for gibt es ein Muster: vorgefertigtes Designteil (Block) in einen Frame-Slot stecken, Datensatz dranhängen — Seite fertig. Diese Anleitung läuft den Kreis komplett ab.

Analogie noch mal: ein leerer Bilderrahmen (Frame) nimmt vorgestaltete Fotos (Blocks) auf; ein Album (Datensatz) liefert den Aufdruck; Rahmen an die Wand hängen ist der Deploy.

Heutige Seite — «Produktliste unseres Ladens»: oben ein Header, in der Mitte zehn Produktkarten (echte Zeilen aus dem Datensatz), unten ein Footer. Schlichter Einseiter.

• Einen Schritt weiter: Fortgeschrittene Aufbauten verdrahten 8–10 Datensatztabellen — Kurse, News, Rankings — auf einmal mit mehreren Variablen (list / list3 ... list10) und rendern eine ganze Seite aus einer einzigen JSON-Spezifikation. Diese Anleitung bleibt beim ersten Stich: eine Variable (list) + ein Datensatz (products).
• Warum dieser Ansatz — Designer kümmert sich nur ums Aussehen des Blocks, Datenverantwortlicher nur um den Datensatz, Seitenverantwortlicher nur um Slot-Zuordnung im Programm-Builder. Saubere Rollentrennung. Daten ändern stört Design nicht und umgekehrt.

Erst echte Daten bereitstellen. Eine Seite über einer leeren Tabelle bauen — niemand kann irgendwas verifizieren. Daten zuerst, Bildschirm danach.

1. Obere Nav → Daten → Datenbank. Kein eigener Datensatz? [+ Neuer Datensatz]. z. B. Name shop, MySQL/PostgreSQL.
2. Im SQL-Editor des Datensatzes () Tabelle anlegen:
   CREATE TABLE products (id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(100), price INT, image_url TEXT);
3. Im Zelleditor für products 5–10 Zeilen einfügen. Aus Excel Strg+V ist der schnellste Weg (siehe Best Practices → Zelleditor · Einfügen in DB).
4. Schnellprüfung: SELECT * FROM products LIMIT 3;. Diesen Datensatz hängen wir in Schritt 6 an die Variable list.

Welche Spalten — nur das, was der Block braucht. name · price · image_url reicht. Mehr schadet nichts, schlanker macht Debug schneller.

Jetzt der Block, der in den Slot soll. Obere Nav → Design → Block (oder /layout/block) öffnet die Bibliothek. [+ Neuer Block].

1. Name — etwas Erkennbares wie product_card_list.
2. HTML-Bereich — Karten-Grid einfügen. Wichtig: Variable heißt list:
   <div class="card-grid">
  <div class="card" v-for="item in list" :key="item.id">
    <img :src="item.image_url">
    <div class="name">@{{ item.name }}</div>
    <div class="price">@{{ item.price }}</div>
  </div>
</div>
3. CSS/SCSS-Bereich — Basisgrid:
   .card-grid { display:grid; grid-template-columns:repeat(3,1fr); gap:16px; }
.card { padding:14px; border:1px solid #eee; border-radius:8px; }
4. sample_data — Dummy-Daten als JSON, Schlüssel list:
   { "list": [
  {"id":1,"name":"Beispiel A","price":1000,"image_url":"/assets/sample.jpg"},
  {"id":2,"name":"Beispiel B","price":2000,"image_url":"/assets/sample.jpg"}
] }
5. Speichern. Im Block-Builder-Vorschauplatz erscheinen automatisch zwei Karten aus sample_data. Diese Vorschau ist die kritische Probe. Wenn nicht: prüfen, ob der Variablenname im HTML (list) zum Schlüssel in sample_data (list) passt.

Jetzt die Seite (Programm). Service → Projekt → [mein Projekt] → + Neues Programm, oder vorhandenes Programm im Programm-Builder (Coder Builder) öffnen. Gleiches Tool, zwei Namen. Acht Step-Reiter.

1. Acht Reiter — db · list · detail · search · hook · style · code · menu. Zweiter Reiter list.
2. Layout-Modus umschalten — am Kopf des list-Reiters zwei Modi: «Felder / Slots». Standard «Felder» (table-like). Wir setzen Designblöcke ein → auf Slots umstellen. UI wird zur 3-stufigen Slot-Konfiguration:
   • 1) Frame-Auswahl — welcher Rahmen mit welchen Slots, welcher Anordnung.
   • 2) Slot-Konfiguration — welcher Block in welchen Slot, wie Variablen mappen.
   • 3) Code-Vorschau — synthetisiertes Ergebnis prüfen.
3. Klingt «Frame / Slot» abstrakt? Stellen Sie sich «ein 3-zeiliger Bilderrahmen für drei Fotos» vor. Frame wählen wir in Schritt 5.

In 1) Frame-Auswahl im Slot-Modus eine Dropdown öffnen, etwas Einfaches wählen — «3-row (oben/Mitte/unten)» reicht. Frame gewählt, [Anwenden] drücken; in 2) Slot-Konfiguration erscheinen automatisch Slot 1, Slot 2, Slot 3 …

1. Bei Slot 2 (Mitte) die Block-Auswahl-Dropdown öffnen und product_card_list aus Schritt 3 wählen. Optionen meist im Format id - Name - Autor.
2. Sofort nach Auswahl bekommt der Slot-Bereich die sample_data-Vorschau des Blocks: zwei Karten. Sieht man sie, sitzt der Block.
3. Slot 1 (oben) und Slot 3 (unten) lassen sich genauso mit Header-/Footer-Blöcken befüllen — oder leer lassen. Erstrunde reicht Slot 2.
4. In jeder Slot-Zeile gibt es data_placer (Quell-Selektor) und data_selector (Ziel-Selektor). Vorerst beide auf list. Bedeutung folgt in Schritt 6.
5. Block sitzt im Slot, läuft aber noch auf Sample-Daten. Echtes Anschließen folgt.

Der wichtigste Schritt. Die Variable list im Block wird mit echten Zeilen der products-Tabelle verdrahtet.

Was die zwei Felder bedeuten:

• data_placer (Quell-Selektor) — Variablenname wie im Block geschrieben. Bei v-for="item in list" ist das list.
• data_selector (Ziel-Selektor) — Variablenname auf Seitenebene. Zwei Kartenlisten auf einer Seite: list kollidiert; mappen zu product_list und review_list. Eine einzige Liste? list bleibt list.

Zur Vereinfachung lassen wir beide auf list.

Datensatz tatsächlich anschließen — Sektion «Datenvariablen / data_vars» oben im Programm-Builder (oder Sidebar). Leer? + Hinzufügen.

1. Variablenname: list (muss zu data_selector aus Schritt 5 passen).
2. Datensatz: shop aus Schritt 2 wählen.
3. Tabelle: products.
4. WHERE (optional): leer = alles. z. B. price > 0.
5. LIMIT (optional): 0, 20 für die ersten 20 Zeilen.
6. ORDER BY (optional): id desc für neueste zuerst.
7. Speichern.

Intern entsteht eine JSON-Aufzeichnung (nicht direkt sichtbar, konzeptuell):

{"var_name":"list","dataset":{"id":42,"table_name":"products","str_limit":"0, 20","str_order":"id desc"}}

Diese JSON ist die Spezifikation des Renderers: zur Laufzeit läuft SELECT * FROM products ORDER BY id desc LIMIT 20, das Ergebnis landet in list, das Block-v-for nimmt es auf.

Alles verkabelt? Auf 3) Code-Vorschau im Slot-Modus (oder den code-Reiter) wechseln und das System synthetisieren lassen.

1. Code generieren (Sync) drücken. Es entsteht:
   • HTML-Skelett des Frames + die HTML-Stücke der Slot-Blöcke an <[slot-1]>·<[slot-2]>·…
   • Innen list → data_selector aus Schritt 5 (hier weiterhin list).
   • data_vars-Definitionen werden in den Init-Code aufgenommen.
2. Code prüfen. Wenn v-for="item in list" intakt ist und oben list = await fetch('/api/...') oder Server-Side-Injection auftaucht — passt.
3. Strg+S oder Speichern. Vorschau zeigt nun echte products-Karten — 5–10 statt zwei aus sample_data.
4. Final 🚀 Deploy in der Workspace (oder «Bei Speichern deployen»), Live-Domain prüfen.

Warum die JSON-Spezifikation das Frontend ist — alles Verhalten reduziert sich auf drei JSONs:

• slot_info — welcher Frame, welche Slots, welche Blöcke.
• data_vars — welche Variable an welchen Datensatz/Tabelle/Filter.
• ui_info — zusätzliche UI-Optionen (hier fast leer).

Kein Handcode mehr nötig: drei JSONs anpassen, Seite zeichnet sich neu. Magisch wird es ab da: 10 Bildschirme zu bauen nähert sich dem Aufwand von einem, weil jeder neue Bildschirm vor allem eine neue Kombination bestehender Blöcke und Bindungen ist.

Bei einer einfachen Seite reicht eine GET-URL wie https://site.com/search?q=hello. Aber mehr als die Hälfte der echten Seiten ist nicht so einfach.

• Ergebnisse nur nach Login — ohne Session-Cookie kommt nur eine leere Seite oder der Login-Screen.
• POST + JSON-Body — der Suchbegriff steht nicht in der URL, sondern im Body: {"q":"hello","page":1,"size":20}.
• CSRF- / Bearer-Token — jeder Request braucht einen zusätzlichen Header, sonst kommt nichts zurück.
• X-Requested-With · Referer · User-Agent — fehlen diese AJAX-Marker, antwortet der Server gerne absichtlich leer.

Jeden Header per Hand abzuschreiben ist unrealistisch. Der schnellste Weg: den echten Browser-Request als einzeiligen cURL-Befehl kopieren, alles so lassen, wie es erfasst wurde, und nur die pro Zeile wechselnden Stellen durch Variablen ersetzen.

Was wir bauen — ein Dataset mit N Stichworten (z.B. keyword_list), dann N-mal die Such-API der Seite aufrufen und die Antworten in einem zweiten Dataset (z.B. search_results) sammeln.

Ziel-Seite in Chrome (oder Edge) öffnen und einmal ganz normal suchen.

1. F12 öffnet die DevTools, dann auf den Tab Network.
2. Beim Suchen füllt sich die Liste. Der gesuchte Eintrag enthält im Namen meist search, list, query oder api und liefert JSON.
3. Eintrag anklicken, im rechten Panel auf Response bestätigen, dass der Body wirklich die gewünschten Daten enthält.
4. Rechtsklick auf die Zeile → Copy → Copy as cURL (bash). Auch unter Windows: bash-Variante hat das sauberste Quoting.

In der Zwischenablage liegt jetzt ein Einzeiler à la curl 'https://...' -H 'Cookie: ...' -H 'Authorization: ...' --data-raw '{...}'. Sieht lang aus, enthält aber URL · Cookies · alle Header · Body in einem Stück.

Den cURL nicht direkt in den Parser kleben. Erst in Postman (oder Insomnia / Bruno) bestätigen, dass ein einziger Aufruf exakt funktioniert. Scheitert es hier, scheitert auch die Parser-Regel.

1. Postman öffnen → links oben Import → Tab Raw text.
2. Den cURL-Einzeiler mit Strg+V einfügen, dann Continue → Import.
3. Es öffnet sich ein neuer Request-Tab mit allen Headern und Body. Rechts oben auf Send.
4. Status 200 und Body wie im Browser → fertig. Leerer Body, 401, 403 oder 302 → Punkte unten prüfen.

• Cookie abgelaufen — bei weitem die häufigste Ursache. Im Browser bestätigen, dass Sie noch eingeloggt sind, dann F12 → Copy as cURL erneut.
• Header beim Import verloren — Postman lässt gelegentlich 1–2 Header fallen. Browser-Headers und Postman-Headers nebeneinander Zeile für Zeile vergleichen.
• Referer / Origin — manche Seiten antworten ohne diese beiden leer. Wenn der Browser sie sendet, hier ergänzen.

Im funktionierenden Postman-Request markieren, was sich beim nächsten Aufruf ändern wird. Typische Kandidaten:

• Suchbegriff im POST-Body — "q":"hello" → "q":"${query}"
• Seite / Offset — "page":1 → "page":${page} (Zahlen ohne Anführungszeichen)
• Kategorie / Filter — "cat":"food" → "cat":"${category}"
• Datumsbereich — "from":"2026-04-01" → "from":"${date_from}"
• Pfadvariable in der URL — /api/user/12345 → /api/user/${user_id}

Der Trick: Variablen identisch zur späteren Dataset-Spalte benennen. Wenn die Spalten query · page · category heißen sollen, schreiben Sie im cURL ${query} · ${page} · ${category}. Identische Namen → automatisches Mapping ohne manuelle Verkabelung.

Format — der Parser erkennt das Muster ${name}. Nur ASCII-Buchstaben, Ziffern und Unterstrich (keine Leerzeichen, keine Umlaute, keine Sonderzeichen).

Der Parser liest das Dataset zeilenweise und füllt damit die cURL-Variablen-Slots. In diesem Schritt also die N Eingabe-Kombinationen als Dataset vorbereiten.

1. Seitenmenü Daten > Datasets → rechts oben + Neues Dataset.
2. Name z.B. keyword_list. Spalten anlegen, deren Namen exakt mit den Variablen aus Schritt 4 übereinstimmen — z.B. query (varchar) · page (int) · category (varchar).
3. Zeilen entweder (a) per UI einzeln tippen oder (b) in Excel/Sheets vorbereiten und im Cell Editor per Einfügen → in DB schreiben übertragen (siehe Cell-Paste-Leitfaden).
4. Nicht groß starten. Erst 3–5 Zeilen, dann weiter. Mit 100 Zeilen wird ein Fehler zu 100 falschen Aufrufen.

Das Ausgabe-Dataset gleich mit anlegen. Z.B. search_results mit query, rank, title, url, snippet. Daran zeigt der Parser in Schritt 6.

Jetzt im Parser eine neue Regel erstellen und cURL mit Dataset verbinden.

1. Seitenmenü Daten > Parser → rechts oben + Neue Regel.
2. Test-Page (Basis-URL) Feld — den Endpunkt vom Anfang des cURL hier eintragen, z.B. https://example.com/api/search. Enthält die URL selbst eine Variable, gleich schreiben: ${user_id}.
3. cURL-Feld — den variablen-markierten Einzeiler aus Schritt 4 mit Strg+V einfügen. Der Parser teilt Methode, Header, Cookies und Body automatisch auf und registriert ${...}-Muster als Variablenkandidaten.
4. Eingabe-Dataset wählen — keyword_list aus Schritt 5. Übereinstimmende Namen mappen automatisch, ungleiche zeigen ein Mapping-Dropdown.
5. Antwort-Speicher-Dataset wählen — search_results. Im JSON-Path-Feld den Pfad angeben (z.B. data.items[*]), der zu einer Zeile entfaltet wird.
6. Speichern. Die Regel ist registriert — noch ohne Aufrufe.

Zwei Run-Modi stehen zur Verfügung.

• ① Einmaliger Direkt-Override — auf der Regelseite neben dem ▶ Ausführen-Button im Panel Variableneingabe direkt query="café berlin", page=1 eintippen und einen einzelnen Call abschicken. Antwort-Vorschau und extrahierte Zeilen erscheinen Seite an Seite. So lange in diesem Modus bleiben, bis die Antwortform vollständig verstanden ist.
• ② Schleife über Dataset — Variablen-Panel auf „Aus Dataset" umstellen → keyword_list aus Schritt 5 wählen → Ausführen. Fortschrittsbalken läuft von 0/N auf N/N, Antworten werden zeilenweise an search_results angehängt.

Während des Laufs beobachten — Fehlerzahl (leer/401/5xx), Response-Beispiel, Anzahl gespeicherter Zeilen. Ein, zwei Fehler sind normal; wenn mehr als 50 % scheitern, sofort stoppen und cURL prüfen.

Zeitplan — im Tab Schedule der Regel kann täglich/stündlich/zu beliebiger Zeit automatisch gelaufen werden. Stichwortliste hinterlegen — und jeden Tag fließen frische Ergebnisse ins Ausgabe-Dataset.

Packe vor dem Upload alles, was der Designer geliefert hat, in ein ZIP-Archiv. Die Art der Verpackung bestimmt die Pfade auf dem Server — befolge diese Regeln.

• Lege immer einen obersten Ordner um alles — z. B. Bilder und css in design_assets/, und zippe diesen Ordner selbst. Nach dem Entpacken siehst du /Upload-Pfad/design_assets/logo.png, der Ordnername bleibt als eine Ebene erhalten.
• In Namen nur Buchstaben, Ziffern, Bindestrich (-) und Unterstrich (_) — Leerzeichen oder Nicht-ASCII-Zeichen brechen URL-Verweise leicht. Beispiel: haupt banner.png ❌ → main-banner.png ✅
• Unterstützte Formate — .zip · .tar · .tar.gz · .tgz. In der Regel reicht .zip. Unter Windows Rechtsklick → „In ZIP-Datei komprimieren", unter macOS im Finder Rechtsklick → „komprimieren".
• Beispielstruktur —
  design_assets/
 ├─ images/logo.png
 ├─ images/hero.jpg
 ├─ fonts/pretendard.woff2
 └─ css/theme.css

Gehe über die obere Navigation oder das Dashboard zu Services → Remote-Verwaltung. Links siehst du die Server-Seitenleiste, in der Mitte einen vierspaltigen Datei-Explorer und unten die Aktionsleiste.

1. Klicke in der Liste links die Domain an, zu der du hochlädst (z. B. myshop.apidealder.net). Der kleine Punkt daneben zeigt den Status.
   • Grüner Punkt — bereit; die Dateiliste öffnet sofort.
   • Grauer Punkt — offline. Container ist gestoppt oder noch nicht ausgerollt.
   • Weißer Punkt — Status wird geprüft.
2. Ist die Liste leer, erscheint der Hinweis „Erst einen Server ausrollen". Dann einmal einen Single-File- oder Projekt-Deploy machen und zurückkehren.
3. Nach der Auswahl klappt in der Mitte der Root (/) auf und du siehst den echten Dateibaum.

Assets werden vom Browser per URL geladen, sie müssen also in einem öffentlich erreichbaren Ordner liegen. Bei Single-File-basierten Servern ist public/assets üblich.

• Pfadleiste — das Haus-Icon oben springt zum Root; jeder Slash-Abschnitt ist klickbar und bringt dich direkt an diese Stelle.
• Direktes Pfadeingabefeld — tippe /public/assets und drücke Enter, um in einem Rutsch dorthin zu springen statt Ordner für Ordner zu durchklicken.
• Wenn es keinen assets-Ordner gibt — nutze [Neuer Ordner] in der unteren Aktionsleiste, um assets anzulegen, und öffne ihn. Erlaubt sind nur Buchstaben, Ziffern, Punkt (.), Bindestrich (-), Unterstrich (_).
• Prüfe anschließend, dass die Pfadleiste /public/assets zeigt. Dorthin wird das Archiv entpackt — ein falscher Ort heißt löschen und neu hochladen.

Mit Pfad /public/assets (oder einem anderen öffentlichen Ordner) klicke in der unteren Aktionsleiste [Archiv hochladen] (Cloud-Pfeil-nach-oben). Das Upload-Modal läuft in drei Phasen.

1. Dropzone — ZIP in den gestrichelten Bereich ziehen oder klicken, um den Dateidialog zu öffnen. Unterstützt werden .zip · .tar · .tar.gz · .tgz.
2. Vorschau — das Modal zeichnet den Ordner-/Dateibaum im Archiv und zeigt oben Name, Größe und Entpack-Ziel (/public/assets). Hier prüfst du, ob der äußere Ordner passt und keine versteckten Dateien (z. B. macOS .DS_Store) eingeschlichen sind. Mit [x] oben rechts tauschst du die Datei.
3. Senden — Klick auf [Senden]. Die Datei wird in 1-MB-Chunks gesendet, mit Live-Fortschrittsbalken — auch wacklige Netze und Hunderte MB große Dateien laufen stabil durch.
4. Nach erfolgreichem Upload entpackt der Server automatisch, der aktuelle Ordner wird aktualisiert, und der neue design_assets-Ordner (oder images/fonts/css) erscheint. Ein Abschluss-Toast bestätigt den Vorgang.

Du willst statt eines Archivs ein paar Einzeldateien laden? Daneben gibt es [Dateien hochladen] — Mehrfachauswahl kopiert die Dateien 1:1 in den aktuellen Ordner, ohne zu entpacken.

Hochgeladene Dateien werden direkt über die Domain ausgeliefert. Liegt z. B. /public/assets/design_assets/images/logo.png auf myshop.apidealder.net, dann ist die Browser-URL https://myshop.apidealder.net/assets/design_assets/images/logo.png. (public ist das Web-Root und fällt aus der URL raus.)

Öffne nun den Single-File-Editor (Services → Single File) und referenziere die eben hochgeladenen Assets.

• Bilder im HTML-Tab einfügen —
  <img src="/assets/design_assets/images/logo.png" alt="logo">
<img src="/assets/design_assets/images/hero.jpg">
• Backgrounds und Schriftarten im SCSS-Tab referenzieren —
  .hero { background: url("/assets/design_assets/images/hero.jpg") center/cover; }
@font-face { font-family: 'Pretendard'; src: url("/assets/design_assets/fonts/pretendard.woff2") format('woff2'); }
• Kernregel — verwende immer einen absoluten Pfad, der mit / beginnt. Relative Pfade (../assets/...) verhalten sich in Vorschau und Produktion möglicherweise unterschiedlich und sind zu vermeiden.
• Externes CSS komplett einbinden — ganz oben im SCSS-Tab @import url("/assets/design_assets/css/theme.css"); hinzufügen.

Nach dem Verdrahten klickst du oben rechts im Single-File-Editor [Run ▶] und schaust die Vorschau an. Passt alles, schiebst du es mit [Deploy 📦] live.

1. Run-Vorschau — der rechte Bereich rendert in Echtzeit. Prüfe: Bilder da, Schriftarten geladen, CSS nicht kaputt.
2. Deploy — der Deploy-Button läuft schrittweise und braucht meistens 1–2 Minuten. Am Ende erscheint ein Domain-Link im Ergebnisbereich.
3. Auf der Live-Domain prüfen — öffne den Link in einem neuen Tab oder rufe https://deine-domain/ direkt auf. Mit einem harten Reload (Strg+F5 oder Cmd+Shift+R) umgehst du den Cache.
4. Fehlt ein Bild, zurück zur Remote-Verwaltung und Pfad nochmal gegenchecken. Passt die entpackte Struktur nicht, ist es meist schneller, den Ordner zu löschen und ab Schritt 4 neu hochzuladen.

An der Oberfläche sehen viele Symptome ähnlich aus, die Ursachen dahinter sind sehr unterschiedlich. Trifft einer dieser Fälle zu, sind die serverseitigen Logs der kürzeste Weg.

• 500 / 502 / 504 Server-Fehler — im Browser nur „Ein Fehler ist aufgetreten"; die echte Ursache steht im Server-Log.
• Leere weiße Seite — meist ein fataler PHP-Fehler, der die Ausgabe stillgelegt hat. Im Log fast sicher eine Fatal-Error- oder Parse-Error-Zeile.
• API liefert 400/422, Ursache unklar — welche Validierungsregel genau ausgelöst hat, steht im Controller-Log.
• Hintergrund-Jobs (Queue, Scheduler, Makro) „scheinen zu laufen, aber ohne Ergebnis" — stumme Fehler hinterlassen nur im Log Spuren.

Wichtige Log-Dateien:

• storage/logs/laravel.log — das Haupt-Log für PHP/Laravel. Die meistgeöffnete Datei.
• storage/logs/laravel-YYYY-MM-DD.log — bei täglicher Rotation.
• storage/logs/worker.log und feature-spezifische Logs (Makros, Parser), wenn Subsysteme eigene Dateien schreiben.

Im Browser zu Services → Remote-Verwaltung.

1. In der Serverliste links die betroffene Domain klicken. Grüner Punkt = Container erreichbar. Grauer/weißer Punkt = Container schläft — eine Minute warten und nochmal klicken.
2. Klicke das Terminal-Icon (▷_) in der Toolbar oben in der Mitte. Von unten fährt ein Terminal-Panel hoch. Gleiches Icon erneut klicken klappt es wieder zu.
3. Oben im Panel steht das aktuelle Arbeitsverzeichnis (z. B. /var/www/html), im Eingabefeld blinkt der Cursor. Er ist direkt mit der Shell des gewählten Servers verbunden, Befehle laufen dort.
4. Prüfe zuerst, wo du stehst:
   pwd
ls
   Normalerweise landest du im Projekt-Root (/var/www/html).

In einem Laravel-Projekt liegen die Logs unter storage/logs. Im Terminal dorthin wechseln.

• cd storage/logs — relativ zum aktuellen Ordner; reicht, wenn du schon in /var/www/html bist.
• cd /var/www/html/storage/logs — absoluter Pfad; funktioniert aus jedem Ort.
• pwd — bestätigen, dass du in /var/www/html/storage/logs bist.

Das Terminal merkt sich das Arbeitsverzeichnis, deshalb laufen nachfolgende Befehle relativ zu diesem Ordner — Pfad nicht jedes Mal neu tippen.

Alternative: im Datei-Explorer zuerst nach /storage/logs navigieren, dann Terminal öffnen — der Pfad folgt automatisch. Praktisch, wenn du Pfade ungern tippst.

Im Ordner zuerst schauen, welche Dateien existieren und welche zuletzt angepackt wurden, danach in den Inhalt reinlesen.

• ls -lhrt — Liste nach Änderungszeit aufsteigend; die neueste Datei steht unten. -h zeigt menschenlesbare Größen (KB/MB).
• cat laravel.log — ganze Datei ausgeben. Nur für kleine Dateien sinnvoll; mehrere MB fluten das Terminal.
• tail -n 100 laravel.log — die letzten 100 Zeilen. Schnellster Weg zur aktuellsten Fehlerzeile. Zahl nach Bedarf anpassen.
• tail -f laravel.log — Live-Follow. Neue Zeilen tauchen sofort auf; im Browser den Bug reproduzieren und das Log dabei beobachten. Stopp mit Strg+C.
• head -n 50 laravel.log — erste 50 Zeilen; für Startmeldungen am Dateianfang.
• wc -l laravel.log — Zeilenanzahl. Bei Hunderttausenden Zeilen direkt zu grep springen.

Ist die Datei lang, reicht tail nicht. grep gibt nur Zeilen aus, die ein Muster enthalten — das Arbeitstier der Log-Analyse.

• grep -i error laravel.log — alle Zeilen, die „error" enthalten; -i ignoriert Groß-/Kleinschreibung, also treffen „Error", „ERROR" und „error".
• grep -in "fatal\|exception" laravel.log — Zeilen mit „fatal" oder „exception", mit Zeilennummern (-n). Mehrere Muster werden mit \| zu ODER verknüpft.
• grep -A 5 -B 2 "SQLSTATE" laravel.log — sucht Zeilen mit SQLSTATE und zeigt 2 Zeilen davor (-B 2) und 5 danach (-A 5). Ideal, um den Stack-Trace gleich mit zu sehen.
• grep "2026-04-25 15:4" laravel.log — auf ein Zeitfenster einschränken (Bereich 15:40). Mit dem in Schritt 1 notierten Fenster kombiniert, wird die Suche sehr eng.
• grep -c "production.ERROR" laravel.log — gibt nur die Anzahl der Treffer aus. Gut für „wie oft passiert das".
• tail -f laravel.log | grep -i error — Live-Follow mit Filter. Auf dem Bildschirm landen nur Zeilen mit „error".

Typischer Ablauf — grep -i error für einen Überblick → eine auffällige Nachricht rausgreifen und mit grep -A 10 "diese Nachricht" den Kontext dazunehmen → Dateipfade und Zeilennummern notieren.

In den von grep gefundenen Fehlerzeilen steht üblicherweise ein Dateipfad und eine Zeilennummer (z. B. /var/www/html/app/Services/Order.php:127). Damit kann man direkt an den Fix.

1. Terminal einklappen, im Pfadfeld des Datei-Explorers /var/www/html/app/Services einfügen und Enter.
2. Doppelklick auf die Datei öffnet den Code-Editor mit Syntax-Highlighting. Zeile korrigieren, [Speichern] drücken — Änderungen wirken sofort, kein Redeploy nötig.
3. Terminal wieder öffnen, per tail -f /var/www/html/storage/logs/laravel.log einen Live-Follow starten und den Bug im Browser noch einmal reproduzieren.
4. Taucht derselbe Fehler nicht mehr auf, Strg+C, fertig. Kommt ein anderer Fehler, zurück zu Schritt 5 und weiter eingrenzen.

Wenn vorübergehend mehr Log gebraucht wird — in den verdächtigen Code eine Zeile \Log::info('[debug] ' . json_encode($variable)); einsetzen, speichern, reproduzieren, Werte mit grep "[debug]" laravel.log auslesen. Nach Klärung die Log::info()-Zeile wieder entfernen — so ist es am sichersten.

Fast jedes echte Entwicklungsteam folgt diesem Ablauf. Kleine Änderungen, Verifikation auf jeder Stufe. Direkt-auf-Prod heißt direkt-kaputt-auf-Prod.

• Lokal ist schnell. Speichern → Refresh in einer Sekunde. Erste Stelle, an der Sie die Änderung gegen die Absicht prüfen.
• Stage spiegelt Domain/DB/Traffic-Form von Prod. Letztes Netz für "auf meinem Rechner ging\'s".
• Prod ist, was echte Nutzer sehen. Ein Problem, das hier zuerst auftaucht, kommt als Beschwerde zurück.

Heute laufen wir alle drei Stufen einmal durch. Die eigentliche Arbeit erledigen Aufträge an Claude/Codex in VS Code in natürlicher Sprache. Ihre Aufgabe ist nicht mehr, Zeile für Zeile zu tippen, sondern klar zu formulieren, das Ergebnis zu prüfen und zu entscheiden, ob es weiter darf.

Fünf Minuten einmalig — der Rest des Tags läuft schneller.

1. Im QuickStart-Web Paket herunterladen, ZIP entpacken, in VS Code File > Open Folder.
2. Das untere Panel QUICKSTART erscheint automatisch. Auth ist still — der Fingerprint aus .env verbindet ohne Login-Formular.
3. UTIL-Tab → unten [🚀 SMART SETUP]. Läuft composer dump-autoload → npm install → vite build. Wenn fertig, sind vite dev und PHP-Built-in-Server beide live.

Öffnen Sie http://localhost:<port> — Ihr Projekt läuft. Hier ist die Startlinie.

Zwei Wege, üblicherweise zusammen genutzt.

• ① VS Code-Chatpanel + MCP — Claude (oder Cursor / Copilot Chat / Codex CLI) auf einen MCP-Server für das Projekt zeigen lassen. Im Chat: "Spalte phone zur users-Tabelle hinzufügen und eine Zeile im Registrierformular". AI schreibt SQL, ändert blade/vue/scss und führt den Build aus — alles auf einmal.
• ② AI-Buttons im UTIL-Tab — Code markieren, dann UTIL → AI-Gruppe → [CODE REVIEW] · [REFACTOR] · [EXPLAIN] · [i18n TS]. Jeder erzeugt einen Prompt mit reichem Projekt-Kontext, den Sie in Claude/Codex einfügen — die Antwort wird deutlich schärfer.

Eine gute Anfrage — konkret zu "was, wo, in welcher Form". Beispiel: "Auf /admin/users die Spalte phone direkt nach email zeigen; bei leerem Wert \"-\" anzeigen." Damit verirrt sich die AI nicht.

Sobald die AI eine Datei speichert, lädt vite dev den Browser per Hot-Reload neu. Fast alle .blade.php·.scss·.vue·.js aktualisieren sich beim Speichern; PHP-Backend-Änderungen nimmt php artisan serve direkt auf.

1. Auf den tatsächlichen Bildschirm schauen — richtige Stelle, richtiges Verhalten, richtige Form?
2. Kurz auf F12-Konsole — keine roten Fehler, dann weiter.
3. UTIL → SYSTEM → [CLEAN CACHE] leert Laravels view/route-Cache, damit Template-/Konfig-Änderungen sauber landen.

Nicht passend → kurze AI-Folgeanfrage: "die phone-Spalte über die PLZ schieben" — und Refresh. In Form ist eine Runde unter einer Minute Standardtempo.

Lokal bestanden → auf Stage pushen.

1. Tab QS DEPLOY unten öffnen.
2. Linke Seitenleiste: Source = L (Local) wählen, Destination = stage ankreuzen.
3. Pro Knoten einmal [CONNECT] und [TEST CONFIG] drücken — echte Verbindung bestätigen. Roter Punkt → .env des Knotens (Host/Port/DB-Konto) prüfen.
4. Mittig [SRC → DST] klicken. Rechts [Save on Deploy] auf ON prüfen — wenn ON, werden vor dem Deploy alle offenen Dateien gespeichert.
5. Der Log-Viewer streamt live, wie Code + Assets (Bilder/Build-Output) + DB-Schema & Daten in einem Rutsch nach Stage fließen.

Fertig — Stage-Domain im Browser öffnen und prüfen, dass nicht nur der Code, sondern auch die neue phone-Spalte in der Stage-DB angekommen ist.

Stage ist der Spiegel von Prod. Nur die Domain unterscheidet sich; Code und DB sind genau das, was gleich ausgeliefert wird.

• Echte Stage-Domain aufrufen und die Änderung selbst nutzen. Caching-, CDN- und Session-Probleme, die auf localhost verborgen bleiben, kommen hier hoch.
• Link teilen, jemand anderes drauf schauen lassen. Was Sie aus Nähe nicht sehen, sieht ein anderer sofort.
• QS DEPLOY → [DIFF] vergleicht Stage ↔ Local. Differenzen → jemand hat Stage manuell angefasst; vor Prod-Deploy aufräumen.
• [BROWSER] öffnet den realen Dateibaum auf dem Stage-Server, um Verdächtiges direkt zu prüfen.

Regression gefunden → zurück nach lokal, AI erneut beauftragen → Schritt 4 → bei Erfolg wieder Schritt 5. Eine Extra-Runde hier ist drastisch billiger als ein Prod-Vorfall.

Stage durch → letzter Schritt. Bedienung wie in Schritt 5, der Unterschied: echte Nutzer sehen es sofort.

1. QS DEPLOY → Source = stage (oder L mit gleichem Code), Destination = main (Prod-Knoten).
2. [Save on Deploy] nochmal auf ON bestätigen. Dauer-ON ist die sichere Standard-Einstellung.
3. [SRC → DST] klicken. Auf dem Log-Viewer bleiben, bis er fertig ist — jeder 5xx oder rote Zeile = abbrechen.
4. Prod-Domain öffnen. Neue Funktion einmal durchgehen, plus die nicht angefassten Kernflüsse (Login, Checkout etc.) — sicher, dass sie noch laufen.
5. Etwas falsch → [SWITCH] tauscht Source/Destination, der vorherige Stage-Stand geht zurück auf Prod — der schnelle Rollback-Pfad.

Eine ganze Runde abgeschlossen — VS Code → Claude/Codex(MCP) → Local → Stage → Prod. Jede künftige Änderung fährt dieselbe Schiene, nur schneller.