Prototyp-Wartung

Was macht Prototyp-Wartung?

Verwende diese Fähigkeit, um einen bestehenden Prototyp über viele Produktiterationen hinweg leichter anpassbar zu machen.

Das Ziel ist nicht das Produkt neu zu gestalten. Bewahre das aktuelle Verhalten und die visuelle Ausrichtung, während du die Wartbarkeit, Dateizuständigkeit und Validierungsgeschwindigkeit verbesserst.

Umfang und Übergabe

• Verwende diese Fähigkeit für fortlaufende strukturelle Iterationen und die Kartierung von Zuständigkeiten in einem bestehenden Prototyp. Für die erstmalige statische Aufteilung oder Paketierung verwende, falls verfügbar, static-prototype-splitter; es ist keine zwingende Abhängigkeit.
• Eine kleine Anfrage zu Text, Layout oder Verhalten erfordert keine Verzeichnisüberholung. Teile nur die für die Anfrage relevanten Zuständigkeiten auf.
• Behalte den vorhandenen Einstiegsdateinamen, das Framework, das Skriptmodell und den Vorschau-Workflow bei. Das untenstehende app.html-Layout ist ein Beispiel und keine Umbenennungsanforderung.
• Befolge die Autorisierungsregeln des Benutzers für Dateiersetzung, Konfiguration, Abhängigkeiten, Netzwerkzugriff, lokale Server und gespeicherte Daten. Diese Fähigkeit erteilt diese Berechtigungen nicht.

Wann diese Fähigkeit auslösen

Löse diese Fähigkeit aus, wenn der Benutzer darum bittet:

• Die spätere Änderungsgeschwindigkeit des Prototyps zu verbessern.
• JS nach Seite, Komponente, Feld, Modal, Store oder Datenebene aufzuteilen.
• CSS nach Basis, Layout, Seite, Komponente, Modal und Feldbereich aufzuteilen.
• Mock-Daten, Seed-Daten, Schemas und State/Store-Logik zu trennen.
• Eine README zur Prototyp-Wartung zu erstellen oder zu aktualisieren.
• Eine CHANGE-MAP (Änderungskarte) zu erstellen oder zu aktualisieren, die zukünftige Anfragen Dateien zuordnet.
• Die Optimierung eines bestehenden interaktiven Prototyps fortzusetzen.
• Eine kombinierte Vorschau und aufgeteilte Dateien gemeinsam wartbar zu halten.
• Zu erklären, wo eine zukünftige Änderung am Prototyp vorgenommen werden sollte.

Standardprinzipien

• Befolge die Sprache des Benutzers und die bestehende Terminologie des Prototyps.
• Lese den aktuellen Einstieg und die aktiven Skriptverweise, bevor du Änderungen vornimmst.
• Behalte das ursprüngliche visuelle Design und die Interaktionsabsicht bei, es sei denn, der Benutzer bittet um ein Redesign.
• Schreibe nicht alles in ein Framework um, es sei denn, es wird ausdrücklich darum gebeten.
• Vermeide eine zweite, abweichende Implementierung. Die kombinierte Vorschau sollte gemeinsame/aufgeteilte Module laden oder aus diesen generiert werden.
• Halte Änderungen auf die Wartbarkeit und das angeforderte Produktverhalten fokussiert.
• Die Aufteilung ist nicht abgeschlossen, wenn nur neue Dateien hinzugefügt werden. Jede Aufteilung muss auch die Verantwortung der alten Datei reduzieren, sodass zukünftige Änderungen einen eindeutigen Eigentümer haben.
• Lasse nicht zusammenhängende Änderungen intakt und bewahre die ursprüngliche Eingabe und die ersetzten Dateien auf. Fokussiere autorisierte Änderungen auf die aktive Implementierung; lösche keine Legacy-Dateien und ersetze keine geschützten Dokumente ohne Genehmigung.
• Überprüfe nach Änderungen die Syntax und die Hauptvorschau-Interaktion, wenn praktikabel.

Empfohlene Struktur

Passe die Namen an das Projekt an, bevorzuge aber diese Form für statische interaktive Prototypen:

prototype/
├── app.html
├── README-prototype.md
├── CHANGE-MAP.md
├── assets/
│   ├── css/
│   │   ├── base.css
│   │   ├── layout.css
│   │   ├── components.css
│   │   ├── modals.css
│   │   ├── fields.css
│   │   └── pages/
│   │       ├── home.css
│   │       ├── editor.css
│   │       └── fill.css
│   └── js/
│       └── app/
│           ├── core.js
│           ├── runtime.js
│           ├── pages/
│           ├── components/
│           ├── fields/
│           ├── modals/
│           ├── data/
│           ├── store/
│           └── utils/
└── pages/
    └── ...

Verwende äquivalente Namen, wenn sich die Prototyp-Domäne unterscheidet. Wichtig ist die Aufteilung der Verantwortlichkeiten.

Für kleine Prototypen ist eine flachere Struktur in Ordnung. Für Prototypen, die sich häufig ändern, bevorzuge die obige Verzeichnisstruktur, damit jede zukünftige Anfrage einer kleinen Datei zugeordnet werden kann.

Verantwortlichkeiten der Schichten

Einstiegsschicht

Behalte den aktuellen kombinierten Vorschau-Einstieg bei; app.html ist der unten verwendete Beispielname.

Er sollte enthalten:

• Geräterahmen oder Vorschau-Shell, falls vorhanden.
• Root-Container.
• CSS-Links.
• Geordnete Skriptverweise.

Er sollte nicht die meiste Geschäftslogik enthalten.

Seitenschicht

Verwende Seitendateien für das Seiten-Rendering und das seiten-spezifische Layout:

• Startseite/Liste/Suche/Tabs.
• Editor/Erstellen/Bearbeiten-Seite.
• Ausfüllen/Vorschau/Übermitteln/Detailseite.
• Anmelde-/Registrierungs-/Onboarding-Seiten.
• Einstellungen/Konto-Seiten.

Wenn der Benutzer darum bittet, ein Seitenlayout oder einen Seitentext zu ändern, beginne hier.

Wenn eine Seitendatei mehrere häufig bearbeitete Unteransichten enthält, teile sie erneut auf. Beispiel:

pages/home/
├── index.js
├── search.js
├── my-forms.js
└── submitted.js

Feld- oder Komponentenschicht

Verwende Feld-/Komponentendateien für wiederholte UI-Blöcke:

• Feldtyplabels.
• Feldstandards.
• Feldvorschau im Editor.
• Ausfüllseiten-Steuerelemente.
• Upload/Bild/Datei/Radio/Checkbox/OCR/Datum-Renderer.

Wenn der Benutzer darum bittet, einen Elementtyp zu ändern, vermeide, zuerst die gesamte App zu durchsuchen. Beginne mit den Feldkonfigurations- und Renderer-Dateien.

Wenn ein Prototyp viele Formularsteuerelemente oder wiederholte Karten hat, bevorzuge Registries:

fields/
├── registry.js
├── text.js
├── image.js
├── file.js
├── options.js
└── ocr.js

Modalschicht

Verwende Modal-Dateien für:

• Feldeinstellungs-Blatt.
• Typauswahl-Blatt.
• Sortier-Drawer.
• Bestätigungsdialoge.
• Element-hinzufügen-Bibliotheks-Blatt.

Halte den Modal-Zustand nach Möglichkeit lokal und übergebe Daten erst nach Bestätigungsaktionen.

Datenschicht

Trenne Daten vom Store-Verhalten.

Verwende data/ für:

• Mock-Vorlagen.
• Branchen-/Kategorielisten.
• Feldtypdefinitionen.
• Demo-Benutzer und Beispiele.
• Seed-Datensätze und Fixtures.

Verwende store/ für:

• Lokale Speicherschlüssel.
• Formular speichern/löschen/aktualisieren.
• Übermittlungsdatensatz speichern/löschen/aktualisieren.
• Datennormalisierung und Migrationen.

Mische keine Speicherregeln in Seiten-Renderer, es sei denn, der Prototyp ist sehr klein.

Wenn bereits lokale Daten vorhanden sein könnten, bewahre deren Schlüssel und Benutzeränderungen. Füge nur fehlende Seed-Datensätze mit stabilen IDs hinzu und mache das Seeding idempotent; überschreibe keine bearbeiteten Datensätze, dupliziere keine Elemente und setze den lokalen Speicher beim Neuladen nicht zurück. Behandle Schema-Migrationen als separate, autorisierte Operation mit einem dokumentierten Wiederherstellungspfad.

CSS-Schicht

Teile CSS nach Zuständigkeit auf, nicht nur nach Größe:

• base.css: Variablen, Reset, Typografie.
• layout.css: Shell, Geräterahmen, Seitencontainer, Grid-Primitive.
• components.css: Buttons, Eingaben, Karten, Tabs, Chips.
• modals.css: Blätter, Drawer, Bestätigungsdialoge, Toast.
• fields.css: Feldsteuerelemente und Formularelementvorschauen.
• pages/*.css: Seiten-spezifisches Layout und Ausnahmen.

Wenn ein Selektor seitenübergreifend wiederverwendet wird, behalte ihn in components oder fields. Wenn er für eine Seite spezifisch ist, verschiebe ihn in das entsprechende Seiten-CSS.

Änderungskarten-Schicht

Füge CHANGE-MAP.md für Prototypen hinzu, von denen viele Bearbeitungsrunden erwartet werden.

Sie sollte häufige Benutzeranfragen direkt Dateien zuordnen:

# Änderungskarte

## Seiten
- Startseite: assets/js/app/pages/home/index.js
- Vorlagenseite: assets/js/app/pages/templates/index.js
- Formulareditor: assets/js/app/pages/editor/index.js

## Felder
- Bild-Upload-Feld: assets/js/app/fields/image.js
- Datei-Upload-Feld: assets/js/app/fields/file.js
- Radio/Checkbox-Felder: assets/js/app/fields/options.js

## Modals
- Feldeinstellungs-Modal: assets/js/app/modals/field-settings.js
- Sortier-Drawer: assets/js/app/modals/sort.js

## Daten
- Vorlagendaten: assets/js/app/data/templates.js
- Branchenkategorien: assets/js/app/data/industries.js

## Styles
- Vorlagenseiten-Styles: assets/css/pages/templates.css
- Feld-Styles: assets/css/fields.css

Halte CHANGE-MAP kurz. Sie ist ein Bearbeitungsindex, keine Produktdokumentation.

Laufzeitschicht

Verwende Laufzeitdateien für:

• Router/Render-Dispatch.
• Ereignisdelegation.
• Gestenverarbeitung.
• Aktions-Dispatch.
• Bootstrapping.

Wenn die Laufzeit groß wird, teile sie nach Interaktionstyp auf, behalte aber einen klaren Einstiegspunkt.

Wartungs-README

Wenn angefordert, füge README-prototype.md im Prototyp-Stammverzeichnis hinzu oder aktualisiere es.

Enthalten:

• Total-Vorschau-Einstieg.
• Lokale Vorschau-URL und reservierte Ports, falls vorhanden.
• Seiten-zu-Datei-Zuordnung.
• Feld-/Komponenten-zu-Datei-Zuordnung.
• Modal-zu-Datei-Zuordnung.
• Datenebenen-Speicherort.
• CSS-Ebenen-Speicherort.
• CHANGE-MAP-Speicherort.
• Wie nach Änderungen aktualisiert und validiert wird.
• Häufige zukünftige Änderungsbeispiele, wie "Ändere das Bild-Upload-Feld" oder "Ändere die Formular-Übermittlungsseite".

Halte es kurz und nützlich. Es ist für Menschen, die den Prototyp warten, kein langes Entwicklungstagebuch.

Arbeitsablauf

1. Untersuche aktive Einstiegsdateien.

   • Verwende rg --files, grep und gezielte Lesevorgänge.
   • Bestätige, welche Skripte tatsächlich von der kombinierten Vorschau geladen werden.
   • Gehe nicht davon aus, dass vorhandene aufgeteilte Dateien aktiv sind.

2. Identifiziere die aktuellen Zuständigkeiten.

   • Seiten-Renderer.
   • Feld-Renderer/Konfiguration.
   • Modals/Drawer.
   • Store/Daten-Helfer.
   • Laufzeit-/Ereignisbehandler.

3. Teile sorgfältig auf.

   • Bevorzuge zuerst mechanische Extraktion, wenn das Bewahren des Verhaltens wichtig ist.
   • Halte die Skript-Ladereihenfolge in app.html explizit.
   • Vermeide Verhaltensänderungen während der Aufteilung, es sei denn, der Benutzer hat auch Verhaltensänderungen verlangt.
   • Entferne oder verkleinere nach dem Extrahieren eines Moduls die entsprechende Verantwortung aus der alten Datei. Lasse nicht zwei aktive Eigentümer für dieselbe Seite, Komponente, Modal, denselben Datensatz oder CSS-Selektor zurück.
   • Lasse Legacy-kombinierte Dateien ungenutzt, anstatt sie zu löschen, es sei denn, der Benutzer bestätigt die Löschung.
   • Behalte das vorhandene klassische Skript- oder ES-Modell bei. Überprüfe nach dem Verschieben von Funktionen die Ladereihenfolge, Exporte und Inline-Ereignisbehandler.
   • Mache View-Mount/Unmount-Verantwortlichkeiten explizit. Entferne veraltete Listener und Timer beim Verlassen einer View, damit wiederholte Navigation keine Aktionen dupliziert.

4. Teile Daten auf, wenn die Daten wachsen.

   • Verschiebe große Mock-Daten aus Seiten-Renderern und Store-Dateien.
   • Halte Seed-Fixtures deterministisch und leicht überblickbar.
   • Führe nach Möglichkeit neue Seed-Daten in vorhandene lokale Daten ein.
   • Wenn Daten nach data/ verschoben werden, sorge dafür, dass Store/State-Dateien diese Daten konsumieren, anstatt eine doppelte aktive Kopie zu behalten.

5. Teile CSS auf, wenn visuelle Änderungen langsam werden.

   • Beginne mit base/layout/components/pages.
   • Verschiebe seiten-spezifische Selektoren in das entsprechende Seiten-CSS.
   • Verschiebe wiederverwendbare Steuerelemente in Komponenten- oder Felder-CSS.
   • Entferne nach dem Verschieben von Selektoren doppelte aktive Selektoren aus dem vorherigen globalen Stylesheet, es sei denn, sie werden absichtlich als gemeinsame Komponenten-Styles beibehalten.
   • Bewahre die Kaskadenordnung und responsiven Breakpoints; bastele CSS url(...), Font- und Importpfade relativ zum neuen Dateispeicherort um.

6. Aktualisiere oder erstelle README und CHANGE-MAP.

   • Dokumentiere die endgültige aktive Struktur.
   • Mache klar, welche Datei für häufige zukünftige Anfragen bearbeitet werden muss.
   • Füge bei Bedarf lokale Vorschau-URL, reservierte Ports und Cache-Busting-Anweisungen hinzu.

7. Verifiziere.

   • Überprüfe rekursiv die JavaScript-Dateien, die tatsächlich vom Prototyp gehören, einschließlich verschachtelter Seiten-/Komponentendateien. Wenn Python und Node bereits verfügbar sind, überprüft dieses Beispiel .js, .mjs und .cjs unterhalb von assets/js; passe den Stamm an das Projekt an. Installiere keine Laufzeiten, nur um es auszuführen.

     python3 - <<'PY_CHECK'
     from pathlib import Path
     import subprocess
     import sys
     
     root = Path("assets/js")
     files = sorted(p for p in root.rglob("*")
                    if p.is_file() and p.suffix in {".js", ".mjs", ".cjs"}
                    and not {"node_modules", "vendor", ".git"}.intersection(p.parts))
     if not files:
         sys.exit("Keine JavaScript-Dateien gefunden; überprüfe das Stammverzeichnis der Prüfung.")
     failed = False
     for path in files:
         failed |= subprocess.run(["node", "--check", str(path)]).returncode != 0
     sys.exit(1 if failed else 0)
     PY_CHECK
     

   • Verwende für Framework-Projekte oder ein anderes Modul-Modell die vorhandenen Projektprüfungen. Ein Syntax-Check beweist kein Browser-Verhalten.
   • Öffne die kombinierte Vorschau.
   • Vergleiche das betroffene Verhalten mit der Baseline, einschließlich Vorwärts-/Rückwärts-Navigation, erneutem Besuch der bearbeiteten Ansicht, Modal-Bestätigen/Abbrechen und gespeichertem Zustand nach dem Neuladen, wo zutreffend.
   • Überprüfe die Browser-Konsole auf Fehler, wenn praktikabel.

Regeln für den Aufteilungsgrad

Verwende diese Regeln, um sowohl Unter- als auch Über-Aufteilung zu vermeiden:

• Wenn eine Datei wiederholt für nicht zusammenhängende Anfragen bearbeitet wird, teile sie auf.
• Wenn eine Seite mehrere unabhängig voneinander ändernde Unteransichten enthält, teile die Unteransichten auf.
• Wenn Mock-Daten mehr Platz einnehmen als die Logik darum herum, verschiebe sie nach data/.
• Ziehe fields/ in Betracht, wenn sich mehrere Feld-/Steuerelementtypen unabhängig ändern; teile nicht nur auf, um eine Anzahl zu erreichen.
• Ziehe modals/ in Betracht, wenn Dialoge oder Drawer separate Zustände oder Wartungsanforderungen haben.
• Wenn CSS-Änderungen das Durchsuchen eines großen globalen Stylesheets erfordern, teile nach Seite und Komponente auf.
• Wenn eine Datei stabil ist und selten bearbeitet wird, teile sie nicht nur aus ästhetischen Gründen auf.

Validierungshilfen

Bevorzuge einfache, abhängigkeitsfreie Validierung für statische Prototypen:

• Verwende node --check für JS-Syntax.
• Verwende für Cache-Busting einen tatsächlichen Wert, z. B. app.html?t=20261109-153000; Date.now(), wörtlich in eine URL eingegeben, ist ein fester String. Eine HTML-Abfrage allein aktualisiert nicht separat gecachtes JS/CSS. Verwende daher bei Bedarf Browser-Cache-Steuerung oder die vorhandene Asset-Versionierungsstrategie.
• Halte den lokalen Vorschau-Port stabil, wenn der Benutzer einen ausgewählt hat.
• Überprüfe die geänderte Interaktion im Browser nach strukturellen Refactorings.
• Direktes Öffnen der Datei ist für kompatible statische Seiten akzeptabel. Abgerufene Fragmente und Browser-ES-Module erfordern im Allgemeinen HTTP; dokumentiere den Öffnungsmodus und verwende den vorhandenen Vorschau-Server, wenn verfügbar. Das Starten eines neuen Servers folgt den Autorisierungsregeln des Benutzers.

Antwortstil

Teile dem Benutzer beim Abschluss mit:

• Was aufgeteilt oder dokumentiert wurde.
• Die aktive Einstiegsdatei.
• Die wichtigsten neuen Dateipfade.
• Ob README-prototype.md oder CHANGE-MAP.md erstellt oder aktualisiert wurde.
• Welche Überprüfung abgeschlossen wurde.
• Alle Legacy-Dateien, die absichtlich belassen wurden.

Halte die abschließende Antwort kurz und praktisch.