bright-y/static-prototype-splitter

Static Prototype Splitter

Verwenden Sie diese Fähigkeit, um einen fertigen oder halbfertigen statischen Prototyp in eine sauberere Lieferform für Demo, Iteration, Migration oder Übergabe umzuwandeln.

Das Ziel ist nicht, das Produkt neu zu gestalten. Bewahren Sie die bestehende visuelle Richtung und Interaktionsabsicht, während der Prototyp leichter zu öffnen, zu inspizieren, zu modifizieren und zu migrieren ist.

Umfang und Übergabe

• Verwenden Sie diese Fähigkeit für eine neue Aufteilung, Komponentisierung oder Übergabelieferung aus einem bestehenden statischen Prototyp. Für fortlaufende Bearbeitungen an einem bereits organisierten Prototyp verwenden Sie prototype-maintenance, sofern verfügbar; es ist keine erforderliche Abhängigkeit.
• Führen Sie bei einer kleinen Text- oder Stiländerung die gewünschte Änderung durch, ohne den Prototyp umzustrukturieren.
• Behalten Sie bestehende Framework-Projekte in ihrem etablierten Stack; flachen Sie ein React/Vue- oder ähnliches Projekt nicht in statisches HTML ab, es sei denn, es wird ausdrücklich gewünscht.
• Befolgen Sie die Autorisierungsregeln des Benutzers für Dateiersetzung, Konfiguration, Abhängigkeiten, Netzwerkzugriff, lokale Server und gespeicherte Daten. Diese Fähigkeit gewährt diese Berechtigungen nicht.

Standardprinzipien

• Bewahren Sie Quelldateien. Überschreiben Sie den ursprünglichen Prototyp nicht, es sei denn, der Benutzer bittet ausdrücklich darum.
• Erstellen Sie Zeitstempel-Ausgabeordner für generierte Lieferobjekte.
• Halten Sie Bearbeitungen auf Struktur, Pfade, wiederverwendbare Assets und grundlegende Interaktionsverdrahtung fokussiert.
• Behalten Sie die ursprüngliche Sprache, Produktterminologie, visuellen Stil und Seitenhierarchie bei.
• Bevorzugen Sie einfaches statisches HTML/CSS/JS, es sei denn, der Benutzer wünscht ein Framework.
• Vermeiden Sie unzusammenhängendes Redesign, Installieren von Abhängigkeiten, Build-Tooling oder Framework-Migration.
• Wenn ein Prototyp sowohl aufgeteilte Seiten als auch eine vollständige Vorschau benötigt, behandeln Sie die aufgeteilten Seitendateien als die alleinige Quelle der Wahrheit. Vermeiden Sie das Führen einer zweiten, abweichenden Kopie des Seiteninhalts oder der Interaktionslogik im kombinierten Einstieg.
• Der kombinierte Einstieg sollte aus der aufgeteilten Seitenquelle durch Routing, Templates, gemeinsame Module oder ein kleines Build/Sync-Skript komponieren, laden oder generieren. Wenn eine temporäre kombinierte Implementierung aus Zuverlässigkeitsgründen notwendig ist, weisen Sie auf die Duplizierung hin und empfehlen Sie, sie vor weiteren Seiteniterationen zu bereinigen.
• Für spätere Seitenbearbeitungen ändern Sie zuerst die spezifische aufgeteilte Seite und ihr Seiten-Level-Skript, aktualisieren Sie dann die kombinierte Vorschau oder generieren Sie sie neu, damit der Benutzer dieselbe Änderung nicht zweimal vornehmen muss.

Wann auslösen

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

• Einen großen HTML-Prototyp in separate Seiten aufzuteilen.
• Einen statischen Prototyp in einen Lieferordner zu organisieren.
• Einen statischen HTML-Prototyp zu komponentisieren.
• Einen Prototyp für die Übergabe oder Demo zu verpacken.
• Eine sauberere Version eines Produktdesign-Prototyps zu erstellen.
• Eine statische Einzeldatei-App in eine mehrseitige oder statische Komponentenstruktur umzuwandeln.
• Einen Prototyp für die spätere Migration zu Vue, React, Taro, uni-app, WeChat Mini-Programm oder einem anderen Frontend-Stack vorzubereiten.

Empfohlene Ausgabeformen

Wählen Sie je nach Anfrage eine oder mehrere Formen aus.

Aufgeteilte Dateiversion

Verwenden Sie diese, wenn der Benutzer einfache statische Demoseiten oder seitenweise Designiteration benötigt.

Empfohlene Struktur:

Ausgabeordner_YYYYMMDD-HHMMSS/
├── aufgeteilte_dateien/
│   ├── index.html
│   ├── seite-a.html
│   ├── seite-b.html
│   └── assets/
│       ├── styles.css
│       └── app.js
└── README.md

Richtlinien:

• Jede Hauptansicht wird zu einer HTML-Datei.
• Bewahren Sie die Seitennavigation wo praktikabel über normale Links.
• Extrahieren Sie gemeinsames CSS und leichtgewichtiges JS in assets/.
• Stellen Sie sicher, dass jede Seite unabhängig im Browser geöffnet werden kann.
• Halten Sie Seitennamen aussagekräftig und stabil.

Komponentisierte statische Version

Verwenden Sie diese, wenn der Prototyp später leichter in ein Frontend-Framework migrierbar sein soll.

Empfohlene Struktur:

Ausgabeordner_YYYYMMDD-HHMMSS/
├── komponentisierte_version/
│   ├── index.html
│   └── assets/
│       ├── styles.css
│       ├── components.js
│       ├── data.js
│       └── app.js
└── README.md

Richtlinien:

• index.html: Shell, Root-Container, Skript-/Style-Referenzen.
• assets/styles.css: gemeinsame Styles.
• assets/data.js: Mock-Daten und Geschäftsdaten, wenn sinnvoll.
• assets/components.js: wiederverwendbare HTML-Renderfunktionen oder Komponentenvorlagen.
• assets/app.js: Routenwechsel, Zustand, Event-Bindung und einfache Interaktionen.
• Halten Sie diese Version frameworkfrei, es sei denn, der Benutzer wünscht ein bestimmtes Framework.
• Wenn auch aufgeteilte HTML-Seiten existieren, duplizieren Sie deren Inhalt nicht manuell in app.js. Bevorzugen Sie das Importieren gemeinsamer Vorlagen, das Laden von Seitenfragmenten oder einen deterministischen Synchronisationsschritt, sodass die aufgeteilten Seiten die Wartungsquelle bleiben.

Kombinierte Vorschau aus aufgeteilten Seiten

Verwenden Sie diese, wenn der Benutzer jede Seite unabhängig bearbeitbar haben möchte, aber auch eine vollständige interaktive Vorschau benötigt.

Empfohlene Struktur:

prototype/
├── app.html                  # Vollständige Vorschau-Shell
├── pages/
│   ├── welcome.html
│   ├── templates.html
│   └── ...
├── assets/
│   ├── css/styles.css
│   ├── js/common.js
│   ├── js/router.js          # Nur Vorschau-Routing / -Komposition
│   └── js/pages/
│       ├── templates.js
│       └── ...
└── README.md

Richtlinien:

• Behalten Sie Seiten-Markup und seiten-spezifisches Verhalten in pages/ und assets/js/pages/.
• Halten Sie app.html als Shell: Geräterahmen, Navigation, Routencontainer und gemeinsame Skript-/Style-Referenzen.
• Halten Sie router.js fokussiert auf das Laden von Seiten, Binden gemeinsamer Navigation, Zustandserhaltung und Vorschau-spezifische Belange.
• Vermeiden Sie eine lange app-combined.js, die jede Seite von Hand neu schreibt. Wenn eine als kurzfristige Problemumgehung existiert, kennzeichnen Sie sie als generiert oder temporär und gleichen Sie sie mit den aufgeteilten Seiten ab, bevor Sie viele Seiten bearbeiten.
• Wenn der Benutzer bittet, eine Seite zu ändern, bearbeiten Sie nur diese Seite und ihr Seitenskript, es sei denn, die Vorschau-Shell oder gemeinsame Styles benötigen tatsächlich Anpassungen.

Verpackter Übergabeordner

Verwenden Sie diesen, wenn der Benutzer ein vollständiges Paket oder Lieferbündel wünscht.

Empfohlene Struktur:

Produktprototyp_Vollpaket_YYYYMMDD-HHMMSS/
├── nutzungshinweise.md
├── originaldateien/
├── aufgeteilte_dateien/
└── komponentisierte_version/

Richtlinien:

• Fügen Sie nur Dateien ein, die für Demo und Übergabe benötigt werden.
• Halten Sie Quelldateinamen wiedererkennbar.
• Wenn Sie ein Archiv erstellen, verwenden Sie einen Zeitstempelnamen.
• Löschen Sie keine zwischengenerierten Ordner, es sei denn, der Benutzer bestätigt.

Arbeitsablauf

1. Inspizieren Sie die Prototypdateien.

   • Identifizieren Sie Einstiegsdateien, Hauptansichten, gemeinsames CSS, gemeinsames JS, Inline-Event-Handler, Assets, externe CDN-Abhängigkeiten, Dialoge, Drawer, Tabs und Seitennavigation.
   • Verwenden Sie rg --files und gezielte Lesevorgänge vor der Bearbeitung.

2. Entscheiden Sie die Ausgabeform.

   • Wenn der Benutzer nur um Aufteilung bittet: Erstellen Sie aufgeteilte_dateien.
   • Wenn der Benutzer um Migrationsbereitschaft oder Komponentisierung bittet: Erstellen Sie komponentisierte_version.
   • Wenn der Benutzer um Auslieferung bittet: Erstellen Sie ein vollständiges Paket mit einem Nutzungshinweis.
   • Falls unklar, wählen Sie die kleinste Ausgabe, die der Anfrage genügt. Erstellen Sie mehrere Versionen nur, wenn sie einem genannten Zweck dienen; behalten Sie eine autoritative Quelle für gemeinsame Inhalte und Verhalten.

3. Erstellen Sie einen Zeitstempel-Ausgabeordner.

   • Empfohlenes Zeitstempelformat: YYYYMMDD-HHMMSS.
   • Lassen Sie Originaldateien unverändert.

4. Extrahieren und organisieren Sie.

   • Verschieben Sie gemeinsames CSS in ein gemeinsames Stylesheet.
   • Verschieben Sie gemeinsames JS in ein gemeinsames Skript.
   • Normalisieren Sie Asset-Pfade.
   • Wandeln Sie Hauptansichten in separate HTML-Dateien oder Komponentenvorlagen um.
   • Behalten Sie für die Demo relevante Interaktionen bei: Navigation, Tabs, Drawer, Modals, Toggles, Listendetail-Übergänge, einfache Formulare und Dateieingaben.

5. Lösen Sie Laufzeit- und Extraktionsdetails.

   • Wählen Sie den Öffnungsmodus vor der Implementierung: direkte file:// Seiten oder HTTP-Vorschau bei Verwendung abgerufener Fragmente oder ES-Module. Versprechen Sie keinen Doppelklick-Betrieb für ein Design, das HTTP erfordert. Verwenden Sie nach Möglichkeit einen vorhandenen Vorschauserver; das Starten eines solchen folgt den Autorisierungsregeln des Benutzers.
   • Halten Sie vollständige HTML-Dokumente und ladbare Fragmente getrennt. Beim Laden eines Fragments in eine Shell normalisieren Sie seine relativen Asset- und Navigations-URLs zur Basis der Shell; rohe Fragment-Einfügung bewahrt die Basis-URL des Quelldokuments nicht und führt dessen Skripte nicht zuverlässig aus.
   • Beim Verschieben von Inline-CSS in ein Stylesheet: Basisieren Sie url(...), Schriftarten und Importpfade relativ zum neuen Stylesheet neu. Bewahren Sie Kaskadenreihenfolge, Spezifität und reaktives Verhalten.
   • Behalten Sie ein kohärentes Skriptmodell bei. Bewahren Sie Ladeordnung und gemeinsamen Zustand für klassische Skripte; bewahren Sie Import/Export-Grenzen für Module. Inline-Handler können ohne explizite Brücke nicht auf modullokale Funktionen zugreifen.
   • Hängen Sie Seitenverhalten explizit an und räumen Sie Listener oder Timer beim Verlassen einer Ansicht auf. Stellen Sie sicher, dass ein erneuter Besuch einer Seite keine Aktionen doppelt registriert.
   • Erfassen Sie vorhandene Speicherschlüssel und Zustandsübergänge vor der Aufteilung. Löschen Sie keinen Speicher und überschreiben Sie nicht stillschweigend benutzererstellte Daten, um die Demo funktionsfähig zu machen.

6. Schreiben Sie die Übergabedokumentation.

   • Fügen Sie Quelldatei, Generierungszeit, Einstiegsseiten, Ordnerzweck und empfohlene nächste Schritte ein.
   • Halten Sie die Dokumentation kurz und nützlich.

7. Verifizieren Sie.

   • Prüfen Sie, ob Einstiegs-HTML-Dateien existieren.
   • Prüfen Sie verlinkte CSS/JS-Pfade, CSS-Asset-URLs, Fragment-Assets und Navigationsziele von jedem Einstieg oder zusammengesetzten View.
   • Öffnen oder zeigen Sie lokal eine Vorschau, wenn praktikabel.
   • Überprüfen Sie bei visuellen Prototypen das Desktop-/Mobil-Layout, falls ein Browser-Tool verfügbar ist.
   • Vergleichen Sie Schlüsselrouten und Interaktionen mit dem Original: initiales Rendern, Vorwärts-/Rückwärtsnavigation, erneuter Besuch eines Views, Modal-Bestätigen/Abbrechen und gespeicherter Zustand nach Aktualisierung, wo zutreffend.
   • Erwähnen Sie nicht verifiziertes Verhalten oder Risiken externer CDN-Abhängigkeiten. Behaupten Sie keine Offline-Unterstützung, ohne externe Ressourcen zu prüfen.

README / Nutzungshinweis-Vorlage

Verwenden Sie ein kurzes README in der Sprache des Benutzers oder Projekts. Das folgende chinesische Beispiel kann angepasst werden; listen Sie nur die tatsächlich generierten Einträge auf und geben Sie an, ob HTTP erforderlich ist:

# Projektprototyp-Aufbereitung

Generierungszeit: YYYY-MM-DD HH:mm:ss

Quelldatei: Originaldateiname.html

## Empfohlene Öffnungen

- `aufgeteilte_dateien/index.html`
- `komponentisierte_version/index.html`

## Aufgeteilte Dateien

Geeignet für statische Prototyp-Demo und seitenweise Designanpassung. Jede Seite ist ein unabhängiges HTML, die Seiten navigieren über Dateilinks.

## Komponentisierte Version

Geeignet für die weitere Entwicklung zu Vue, React, Taro, uni-app, WeChat Mini-Programm oder anderen Frontend-Strukturen.

## Hinweise

- Originaldateien wurden nicht geändert.
- Gemeinsame Styles und Skripte wurden in `assets/` organisiert.
- Für weitere Engineering-Schritte können zuerst `components.js`, `data.js` und `app.js` migriert werden.

Qualitätscheckliste

Vor der endgültigen Antwort prüfen:

• Originalquelldateien sind erhalten.
• Ausgabeordner hat einen Zeitstempel.
• Einstiegsdateien sind klar benannt.
• Asset-Pfade funktionieren relativ zu jeder HTML-Datei.
• Navigation zwischen Seiten oder Ansichten funktioniert noch.
• Wichtige Interaktionen sind nicht verloren gegangen.
• README oder Nutzungshinweis erklärt, was zu öffnen ist.
• Endgültige Antwort enthält den gespeicherten Pfad und das Verifikationsergebnis.