johnson7543/design

Produkt-Demo aufnehmen

Verwandeln Sie die Produkt- und Aktionsbeschreibung des Benutzers in ein eingechecktes Aufnahmeszenario, führen Sie es gegen die echte Anwendung aus und wenden Sie die generierten Assets auf die angeforderte Vorschau an.

Workflow auswählen

• Für die erste Demo eines Produkts lesen Sie references/new-product-workflow.md und references/scenario-schema.md.
• Für ein bestehendes Szenario lesen Sie references/scenario-schema.md, aktualisieren Sie nur das angeforderte Verhalten und zeichnen Sie es erneut auf die gleichen angewendeten Pfade auf, es sei denn, der Benutzer wünscht etwas anderes.

Workflow

1. Finden Sie die Produktroute, stabile Interaktionsselektoren und die Komponente, die die Vorschau verwendet. Bewahren Sie den angeforderten Inhalt, die Reihenfolge, den Bildausschnitt, die Dauer und den Ausgabeort.

2. Erstellen oder aktualisieren Sie scripts/demo-video-scenarios/<produkt-slug>.json. Initialisieren Sie es für eine erste Demo mit npm run init:demo -- --product "<name>" --route <route> --consumer <datei> und ersetzen Sie dann die Startaktion durch die angeforderte Sequenz. Behalten Sie produktspezifisches Verhalten im Szenario bei, anstatt es im Rekorder hart zu codieren.

3. Verwenden Sie echte Browseraktionen. Fügen Sie bewusste Wartezeiten ein, wenn der Betrachter eine entprellte Aktualisierung, eine abgeschlossene Animation oder einen Zwischenzustand sehen muss. Halten Sie die gesamte Aktionszeit unter der Aufnahmedauer; ungenutzte Zeit wird zum endgültigen Stillstand. Budgetieren Sie für kontinuierliche Animationen deren vollständigen Ablauf plus lesbare Haltepunkte und fügen Sie ein quality.motionChecks-Fenster hinzu.

4. Legen Sie generierte Medien unter public/previews/ ab, es sei denn, das bestehende Produkt verwendet einen anderen öffentlichen Asset-Speicherort. Setzen Sie application.consumerFiles und öffentliche Pfade so, dass der Ausführer überprüft, ob die Assets angewendet wurden. Patchen Sie zuerst den Consumer beim Hinzufügen einer neuen Vorschau; das Überschreiben einer bereits referenzierten Ausgabe gilt als Anwenden eines Updates.

5. Führen Sie aus:

   npm run record:demo -- --scenario scripts/demo-video-scenarios/<produkt-slug>.json
   

6. Überprüfen Sie das Ergebnis, nicht nur den Befehlsabschluss:

   • Der Rekorder führt verify:demo aus und muss die genaue Dauer, Abmessungen, quadratische Pixel, durchschnittliche Bildrate, Bildanzahl, H.264-Kodierung und konfigurierte Bewegungsprüfungen bestehen.
   • Öffnen Sie jedes gedruckte Übersichts- und Bewegungskontaktblatt mit view_image. Bestätigen Sie eingegebene Werte, zwischenzeitliche Produktänderungen, gleichmäßig verteilte Bewegung, beide Enden von Übergängen und den Endzustand.
   • Führen Sie npm run lint aus; führen Sie die von AGENTS.md geforderten Prüfungen für alle UI-Änderungen an der Anwendung durch, die während des Anwendens der Vorschau vorgenommen wurden.

Vertrag für flüssige Bewegungen

• Bevorzugen Sie echte 60 fps für Animations-Demos. Respektieren Sie die gemeldete Bildratenobergrenze der Quellaufnahme; werben Sie niemals für flüssigere Ausgabe durch Duplizieren von Frames oder Interpolieren von WebGL-Bewegungen.
• Geben Sie einem großen Übergang genügend Szenariozeit, um klar lesbar zu sein. Verwenden Sie die beabsichtigte Dauer des Produkts; wenn keine vorhanden ist und Flüssigkeit im Mittelpunkt steht, beginnen Sie mit etwa 2–3 Sekunden pro Richtung und verlängern Sie das gesamte Video, anstatt spätere Aktionen zu überstürzen.
• Markieren Sie jedes Intervall, das sich kontinuierlich bewegen soll, in quality.motionChecks. Der Standard-Gate erlaubt keine aufeinanderfolgenden identischen Doppelbilder. Lockern Sie es nur, wenn das Produkt innerhalb dieses Intervalls absichtlich einen Stillstand einlegt, und dokumentieren Sie dies in der Szenariobeschreibung.
• Beurteilen Sie das Tempo visuell anhand des dichten Bewegungskontaktblatts. Eine gültige Bildanzahl kann eine vorderlastige oder abrupte Easing-Kurve nicht erkennen.
• Wenn die echte Produktanimation selbst ruckelig ist und der Benutzer um eine Verbesserung der Flüssigkeit gebeten hat, korrigieren Sie das Bildraten-Timing oder Easing und führen Sie die relevanten UI-Prüfungen durch, bevor Sie erneut aufnehmen. Andernfalls bewahren Sie das Produktverhalten und erklären Sie die Einschränkung, anstatt sie in der Nachbearbeitung zu überdecken.

Aufnahme-Invarianten

• Nehmen Sie die echte Vite-Anwendung über den nativen Tab-Compositor-Stream von Chrome auf. Puppeteer kann Tastatur, Zeiger und Timing bereitstellen, aber das Produkt muss seine eigenen Zustandsaktualisierungen und sein eigenes Rendering durchführen.
• Ersetzen Sie die native Tab-Aufnahme nicht durch DevTools-Screenshot-Sampling für WebGL-Bewegungen; dies kann Zwischenbilder auslassen und einen falschen Übergang erzeugen.
• Kodieren Sie nicht mit einer Rate über der echten Aufnahmerate und verwenden Sie keine Bewegungsinterpolation, um eine Flüssigkeitsanfrage zu erfüllen.
• Nehmen Sie niemals den gesamten Desktop des Benutzers oder ein vorhandenes Display auf. Die lokale Erweiterung darf nur den ausgewählten lokalen Host-Produkt-Tab aufnehmen.
• Verwenden Sie recordingCss nur, um die Demo einzurahmen. Ändern Sie nicht die echte Produkt-UI, nur um die Aufnahme zu erleichtern, es sei denn, der Benutzer hat diese UI-Änderung ebenfalls angefordert.
• Fügen Sie Szenarien keine willkürlichen JavaScript-Evaluierungsaktionen hinzu. Fügen Sie dem Ausführer eine eng benannte, echte Eingabeaktion hinzu, wenn eine Interaktion wirklich nicht unterstützt wird.
• Wenn die native Tab-Aufnahme nicht ausgeführt werden kann, melden Sie die konkrete Voraussetzung, anstatt stillschweigend ein simuliertes Video zu generieren.

Interpretation von Anfragen

Leiten Sie Routen, Selektoren und vorhandene Asset-Consumer aus dem Repository ab. Fragen Sie nur nach, wenn nach der Inspektion mehrere Produkte oder materiell unterschiedliche Ausgabeplatzierungen plausibel bleiben.

Wenn der Benutzer ohne technische Details „Demo für <produkt> erstellen/initialisieren und anwenden“ sagt, leiten Sie die implementierte Route, den Katalog-Consumer, Selektoren und vorhandene Vorschaukonventionen ab. Standardmäßig 8 Sekunden, 60 fps und Hochformat-Rahmen nur dann, wenn das Repository und die Anfrage keine bessere Konvention bieten. Eine Demo-Anfrage autorisiert nicht die Implementierung eines fehlenden Produkts.

Eine geeignete Anfrage kann so einfach sein wie:

Verwenden Sie $record-product-demo für Design QR: Geben Sie die URL in zwei Teilen ein, pausieren Sie für die Baumaktualisierung, transformieren Sie 3D zu 2D und zurück, und wenden Sie es dann auf die Katalogkarte an.

Benutzerseitige Initialisierungs- und Eingabeaufforderungsbeispiele sind in dem Demo-Video-Workflow dokumentiert.