johnson7543/design

Enregistrer une Démonstration Produit

Transformez la description du produit et des actions de l'utilisateur en un scénario d'enregistrement validé, exécutez-le sur l'application réelle, puis appliquez les ressources générées à l'aperçu demandé.

Choisir le flux de travail

• Pour une première démonstration d'un produit, lisez references/new-product-workflow.md et references/scenario-schema.md.
• Pour un scénario existant, lisez references/scenario-schema.md, mettez à jour uniquement le comportement demandé, et ré-enregistrez en utilisant les mêmes chemins d'application, sauf indication contraire de l'utilisateur.

Flux de travail

1. Localisez la route du produit, les sélecteurs d'interaction stables et le composant qui consomme son aperçu. Préservez le contenu, l'ordre, le cadrage, la durée et l'emplacement de sortie demandés.

2. Créez ou mettez à jour scripts/demo-video-scenarios/<slug-du-produit>.json. Pour une première démonstration, initialisez-le avec npm run init:demo -- --product "<nom>" --route <route> --consumer <fichier>, puis remplacez l'action de démarrage par la séquence demandée. Gardez le comportement spécifique au produit dans le scénario plutôt que de le coder en dur dans l'enregistreur.

3. Utilisez de véritables actions de navigateur. Ajoutez des temps d'attente délibérés lorsque le spectateur doit voir une mise à jour différée, une animation terminée ou un état intermédiaire. Gardez la durée totale des actions en dessous de la durée d'enregistrement ; le temps non utilisé devient la pose finale. Pour une animation continue, prévoyez sa durée totale plus des poses lisibles et ajoutez une fenêtre quality.motionChecks.

4. Placez les médias générés sous public/previews/ sauf si le produit existant utilise un autre emplacement d'actif public. Définissez application.consumerFiles et les chemins publics pour que l'exécuteur vérifie que les ressources sont bien appliquées. Patchez d'abord le consommateur lors de l'ajout d'un nouvel aperçu ; écraser une sortie déjà référencée compte comme une mise à jour appliquée.

5. Lancez :

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

6. Vérifiez le résultat, pas seulement la sortie de la commande :

   • L'enregistreur exécute verify:demo et doit valider la durée exacte, les dimensions, les pixels carrés, la fréquence d'images moyenne, le nombre d'images, l'encodage H.264 et les vérifications de mouvement continu configurées.
   • Ouvrez chaque planche contact imprimée (globale et de mouvement) avec view_image. Confirmez les valeurs tapées, les modifications intermédiaires du produit, la répartition uniforme du mouvement, les deux extrémités des transitions, et l'état final.
   • Exécutez npm run lint ; exécutez les vérifications requises par AGENTS.md pour toute modification de l'interface utilisateur de l'application effectuée lors de l'application de l'aperçu.

Contrat de fluidité du mouvement

• Privilégiez un véritable 60 ips pour les démonstrations d'animations. Respectez le plafond de fréquence d'images rapporté par la source de capture ; ne promettez jamais une sortie plus fluide en dupliquant des images ou en interpolant du mouvement WebGL.
• Accordez à une transition majeure suffisamment de temps de scénario pour être lisible. Utilisez la durée prévue par le produit ; en l'absence de celle-ci et si la fluidité est centrale, commencez autour de 2 à 3 secondes par direction et allongez la vidéo globale plutôt que de précipiter les actions suivantes.
• Marquez chaque intervalle qui doit se déplacer en continu dans quality.motionChecks. La porte par défaut n'autorise aucune image dupliquée consécutive exacte. Desserrez-la uniquement lorsque le produit marque intentionnellement une pause dans cet intervalle, et documentez pourquoi dans la description du scénario.
• Jugez le rythme visuellement à partir de la planche contact dense du mouvement. Un nombre d'images valide ne peut pas détecter une courbe d'assouplissement abrupte ou trop concentrée au début.
• Si l'animation réelle du produit est saccadée et que l'utilisateur a demandé d'améliorer la fluidité, corrigez le rythme des images ou l'assouplissement et exécutez les vérifications d'interface utilisateur pertinentes avant de ré-enregistrer. Sinon, préservez le comportement du produit et expliquez la limitation plutôt que de la masquer en post-production.

Invariants de capture

• Enregistrez l'application Vite réelle via le flux de composition d'onglet natif de Chrome. Puppeteer peut fournir le clavier, la souris et le timing, mais le produit doit effectuer ses propres mises à jour d'état et son rendu.
• Ne remplacez pas la capture d'onglet native par un échantillonnage de capture d'écran DevTools pour le mouvement WebGL ; cela peut omettre des images intermédiaires et produire une transition artificielle.
• N'encodez pas au-dessus du taux de capture réel et n'utilisez pas d'interpolation de mouvement pour satisfaire une demande de fluidité.
• Ne capturez jamais le bureau complet de l'utilisateur ou un écran existant. L'extension locale ne peut capturer que l'onglet de produit localhost sélectionné.
• Utilisez recordingCss uniquement pour cadrer la démonstration. Ne modifiez pas l'interface utilisateur réelle du produit simplement pour faciliter l'enregistrement, sauf si l'utilisateur a également demandé ce changement d'interface.
• N'ajoutez pas d'actions d'évaluation JavaScript arbitraires aux scénarios. Ajoutez une action d'entrée réelle et étroitement nommée à l'exécuteur lorsqu'une interaction n'est vraiment pas prise en charge.
• Si la capture d'onglet native ne peut pas s'exécuter, signalez la condition préalable concrète plutôt que de générer silencieusement une vidéo simulée.

Interprétation des demandes

Inférez les routes, les sélecteurs et les consommateurs d'actifs existants à partir du dépôt. Ne demandez que lorsque plusieurs produits ou des placements de sortie matériellement différents restent plausibles après inspection.

Lorsque l'utilisateur dit « créer/initialiser et appliquer une démo pour <produit> » sans détails techniques, inférez la route implémentée, le consommateur de catalogue, les sélecteurs et les conventions d'aperçu existantes. Par défaut, utilisez 8 secondes, 60 ips, et un cadrage portrait uniquement lorsque le dépôt et la demande ne fournissent pas de meilleure convention. Une demande de démonstration n'autorise pas à implémenter un produit manquant.

Une demande appropriée peut être aussi simple que :

Utilisez $record-product-demo pour Design QR : tapez l'URL en deux parties, faites une pause pour la mise à jour de l'arbre, transformez 3D en 2D et inversement, puis appliquez-la à la carte du catalogue.

Les exemples d'initialisation et d'invite destinés à l'utilisateur sont documentés dans le flux de travail vidéo de démonstration.