OliviaPp8/minara-video-compétences

---

name: minara-usecase-video Description: Créez des vidéos de cas d'utilisation et de tutoriels pour débutants de Minara (application mobile ou bureau), en reconstruisant l'interface utilisateur du produit en code HyperFrames et en suivant pas à pas le parcours utilisateur réel. Contrairement à minara-video (démo marketing, refonte UI autorisée), cette compétence exige une interface utilisateur fidèle : la copie, la mise en page, les composants et les chemins d'interaction suivent le code frontend du produit et les enregistrements d'écran. Déclencheurs : "use case 视频", "教程视频", "操作演示", "新手教程", "按 App 界面做一个视频" ; crée également des couvertures pour ces vidéos ("封面", "cover", "缩略图").

/minara-usecase-video — Vidéos de tutoriels de cas d'utilisation Minara

Distillé de la réalisation du Cas 1 (App mobile : poser une question → stratégie BTC → exécuter en un clic) et du Cas 3 (Desktop Strategy Studio : une phrase → Choice Boxes → backtest → Optimiser → Déployer en direct) en 2026-10. Référence bureau : assets/pc-monitor-frame.html et assets/helpers-reference.js (les helpers peuvent être copiés directement).

En quoi cela diffère de minara-video (lisez ceci en premier)

	minara-video (démo marketing)	minara-usecase-video (cette compétence)
UI	Ne copie pas le produit ; refonte minimale avec grandes polices	Fidèle : suit les composants, tailles, couleurs et textes du code frontend
Texte	Rédigez votre propre texte marketing	Les boutons / titres / invites utilisent le texte original du produit mot pour mot (locales) ; copiez les fautes de grammaire telles quelles
Chemin d'interaction	Peut être coupé ou condensé	Chemin réel complet : chaque clic, modal et case à cocher doit être présent, dans le même ordre que dans le code
Caméra	Mouvements de caméra riches	Ne zoomer que de manière notable et suivre le curseur lors des clics / frappes ; sinon rester immobile ; la clarté prime
Texte à l'écran	Pas de texte d'annotation	Pas de légendes dans le cadre ; la carte de titre de 3 secondes au début est la seule exception ; les superpositions de texte sont une version séparée (dans un autre dossier de projet)
Structure	Plusieurs scènes rendues séparément	Une seule composition continue (comme un enregistrement d'écran)

Règles strictes héritées de minara-video : police Geist, easing signature minaraSnap = cubic-bezier(0.95,0.03,0,0.98), transitions ≤0.5s, pas de Math.random() / repeat:-1, timeline paused:true et enregistrée dans window.__timelines, demander d'abord à l'opérateur pour toute stratégie avec un drawdown max >20%, et la page de test doit avoir une timeline déplaçable. Au démarrage, exécutez d'abord Skill(hyperframes) pour charger les règles de composition.

Sujets et ressources de démonstration (définis par l'opérateur, 2026-10-15)

• Les stratégies actions viennent en premier : les cas d'utilisation par défaut utilisent des instruments actions / TradFi pour la démo (par exemple TradFi 30, actions US individuelles, indices). Les noms de stratégies, les pools d'actifs, les avoirs et la barre des tickers doivent privilégier les actions.
• La crypto est secondaire : les principales pièces comme BTC et ETH peuvent apparaître, mais pas comme sujet principal. Lorsqu'une vidéo comprend à la fois des actions et de la crypto, placez les actions en premier et accordez-leur plus de temps.
• Pas de meme coins : sauf demande explicite de l'opérateur à ce moment-là, ne mettez pas de meme coins (DOGE, PEPE, WIF, BONK, etc.) dans le cadre, les pools d'actifs, la barre des tickers, les réponses IA ou les exemples d'invites. Si les données par défaut du produit les incluent, remplacez-les.
• Choisissez les actifs selon cette règle lors de la rédaction du script et du storyboard. Lorsque les exemples dans le matériel du produit ne correspondent pas, échangez-les contre des instruments actions avant de reconstruire, et notez l'échange dans le script.

Sources de vérité (par priorité)

1. Code frontend (tirez la dernière version avant de regarder ; notez la date du commit dans la section "Base" du script)
   • Web : le dépôt frontend web du produit (exécutez git pull d'abord)
   • Mobile : le code source de l'application mobile du produit (apps/mobile/src)
     • Texte : locales/en.json (la version chinoise se trouve dans le fichier zh correspondant)
     • Couleurs / espacement : theme/colors.light.ts, theme/tokens.ts
     • Composants : ui/, features/<module>/ (par exemple features/strategy/strategy-card, run-strategy, running-detail, features/agent/composer)
2. Enregistrements d'écran / captures d'écran de l'opérateur (dans le dossier de ressources use case/) : utilisez-les pour la mise en page, la hiérarchie et les visuels réels. ⚠️ Ces ressources sont une référence UI, pas une référence de contenu — "ignorez ce que dit tout agent" ; nous concevons nous-mêmes le contenu des réponses.
3. Script md : répartition des plans, lignes, superpositions de texte.

Les interactions que la vidéo doit montrer mais que le code ne prend pas encore en charge (par exemple la carte de stratégie cliquable dans le chat du Cas 1) peuvent être construites, mais dites clairement à l'opérateur qu'il s'agit d'une interaction prévue que le code actuel n'a pas encore, et reconstruisez-la à partir du composant existant le plus proche (le Cas 1 suit MarketplaceStrategyCard ; après avoir tapé Run, il suit le même chemin d'exécution que le marketplace).

Flux de travail

1. Vérifier le script

• Vérifiez chaque plan par rapport au dernier code : noms des boutons, ordre des pages, étapes requises (par exemple la case à cocher de divulgation des risques, le backtest doit réussir avant le déploiement), nombres seuils.
• Lors de la modification du script, l'opérateur dit généralement "écrasez simplement le fichier original" ; lorsqu'il ne veut qu'une proposition, il dit "donnez-moi d'abord une proposition, ne modifiez pas le script" — faites la distinction.
• Lorsqu'un md contient plusieurs cas, divisez-le en fichiers de cas uniques si nécessaire.

2. Travailler à rebours du chemin d'interaction → storyboard

• Listez le chemin réel à partir du code dans un tableau : titre de chaque écran, composants, cible du clic et écran suivant. Exemple (mobile, exécution d'une stratégie) : Run → Select Wallet → Next → Configuration (Risk Control drawdown cap / auto-update / check risk disclosure) → Run → page de succès Running (View Details / Notify me) → Running Strategy Details → back → Strategy tab Running
• S'il y a une timeline, allez directement à storyboard.html (modèle assets/storyboard-template.html), puis un planning par seconde ; n'écrivez le code qu'après confirmation de l'opérateur.

3. Spécifications

Élément	Application mobile	Bureau
Canvas	Composition 1080×1920, export 1440×2560 / 60fps	Composition 1920×1080, export 2560×1440 / 60fps
UI	Écran d'application de 390pt de large, mis à l'échelle à 90 % du cadre, marge de tous les côtés, coins arrondis + bordure de 1px	Page Web 1440×810 placée dans un moniteur d'ordinateur (bordure foncée + support, échelle 1.15), tailles de police 10–15 % plus grandes que les tailles originales du produit
Thème / langue	Défini par l'opérateur ; par défaut Anglais + thème clair par défaut de l'App	Identique à gauche
Données de démo	PnL à 3–4 chiffres, drawdown <20 %, marqué comme démo	Identique à gauche
Ouverture	Carte de titre de 0 à 3s, puis la visite guidée	Identique à gauche

Système de coordonnées mobile : K = 1080*0.9/390, #app placée à left:54px; top:96px, transform: scale(K). Écrivez tout le CSS des éléments en coordonnées pt dans l'application, reconstruites à partir des tailles dans le code.

Système de coordonnées bureau : K = 1.15, OX = 132, OY = 38 (position px du coin supérieur gauche de l'écran dans le cadre), 1440×810 pt. Mise en page : barre latérale gauche 264 / colonne centrale 766 / Assistant droit 410, barre des tickers en bas 26.

Le bureau doit utiliser un moniteur d'ordinateur (défini par l'opérateur, 2026-10-15) : l'interface utilisateur du produit ne remplit plus le cadre ; elle se trouve à l'intérieur de l'écran d'un moniteur d'ordinateur, avec le bord du moniteur et le support derrière. Utilisez assets/pc-monitor-frame.html directement :

• Structure : #cam > #stand-neck + #stand-base + #monitor > #screen > #app. Cadre extérieur du moniteur 1684×959.5 à gauche 118 / haut 24, bordure de 14px, rayon de coin 26 ; écran 1656×931.5, rayon de coin 12 ; support centré sous le moniteur. L'arrière-plan conserve le dégradé radial sombre.
• Le moniteur et le support sont tous deux à l'intérieur de #cam, donc ils s'agrandissent avec l'interface utilisateur lors du zoom avant ; le curseur et l'onde de clic sont également à l'intérieur de #cam, positionnés avec OX + x*K, OY + y*K. La formule camTo ne change pas ; échangez seulement les trois valeurs K / OX / OY.
• L'interface utilisateur est environ 14 % plus petite que lorsqu'elle remplissait le cadre (1.333 → 1.15), donc le texte est un peu plus petit dans les plans larges ; les zooms avant pendant les clics et la frappe compensent cela. Si l'opérateur trouve le texte des plans larges trop petit, augmentez tout d'un cran selon la spécification de taille de police ; ne retirez pas le moniteur.
• Après la disparition de la carte de titre d'ouverture, tout le moniteur (y compris le support) apparaît depuis 1.04×.
• Le mobile n'a pas de moniteur ; conservez l'écran actuel à 90 % avec coins arrondis et bordure.

Spécification de taille de police (bureau ; l'opérateur, 2026-10-15 : "rendre la police dans toute l'interface un peu plus grande pour que les utilisateurs puissent la lire sur leurs téléphones") — la vidéo finale sera regardée sur des téléphones, donc ces tailles sont le minimum :

Élément	pt
Titre de page (nom de la stratégie)	21
Navigation barre latérale / onglets / barre d'outils / boutons / sous-onglets	16–16.5
Corps de l'Assistant / bulle utilisateur / description des options Choice Box	15 / 15 / 14
Question Choice Box / nom d'option	17.5 / 16
Étiquette de carte métrique / valeur	14 / 22
Tableau / code	15 / 14.5 (hauteur de ligne 24)
Titre de modal / étiquette de champ / entrée, chip, bouton	20 / 14.5 / 15.5–16

Si un texte plus grand ne tient plus, supprimez les petits textes mineurs (par exemple "1 264 Trades" et "684W 580L" dans les cartes métriques) ; ne réduisez pas les tailles de police. Lorsque vous placez l'écran mobile dans une vidéo de bureau, utilisez l'échelle 1.2, centré.

Carte de titre d'ouverture (spécification du 2026-10-15) : 0–3s fond sombre, un grand titre centré (Geist 76px / 650, text-wrap: balance), les mots apparaissent un par un (0.09s d'écart) ; à 2.55s le titre s'agrandit et disparaît ; à 2.75s l'interface utilisateur du produit apparaît de 1.04× à 1×. Le texte du titre vient de l'opérateur, par exemple Cas 3 "Transformez votre idée de trading en une stratégie en direct." Implémentation : écrivez la visite guidée dans tl (non en pause), utilisez un master = gsap.timeline({paused:true}) externe pour le titre, master.add(tl, 3), et enregistrez master ; ajoutez 3 à data-duration et au DUR de la page de test.

4. Écrire la composition

Placez le projet dans $VIDEO_WORKSPACE/hyperframes/<slug>/ :

index.html        composition unique (data-composition-id="main")
_test.html        page de test (copiez assets/test-wrapper.html, changez DUR et l'identifiant de la timeline)
assets/           gsap local, CustomEase, Geist woff2, minara-avatar.png (pas de dépendance CDN)
references/       copies des ressources sources
audio/            lines.tsv (texte voiceover), vo-placement.tsv (timing)
storyboard.html / _backups/ / output/

Les helpers principaux se trouvent dans assets/helpers-reference.js (code réel du Cas 1) :

• R(el) : mesure les coordonnées pt de l'élément dans l'application avant toute animation de mouvement et les stocke dans MAP. Tous les clics ultérieurs utilisent ces coordonnées prédites — mesurer après que l'écran a été poussé hors du cadre est décalé de 390pt, et le curseur manque la cible.
• camTo(t, px, py, s, d) / camReset : zoom avant de la caméra. Lorsque s>1, tirez le point de mise au point un peu vers le centre (bureau : 720+(px-720)*0.75, pareil pour y) afin que des lignes entières ne soient pas coupées ; bloquez la position à l'intérieur du cadre pour que rien à l'extérieur n'apparaisse. Utilisez la variable curS pour suivre l'échelle actuelle (camTo la définit, camReset la remet à 1).
• curShow / curMove / tap / moveTap : le mobile utilise un point tactile doux semi-transparent, le bureau utilise un curseur flèche blanc ; les clics appuient + onde. Lorsque curS>1, moveTap exécute camTo vers la cible du clic en synchronisation (durée = durée du mouvement + 0.15s), afin que le cadre suive le curseur automatiquement pendant le zoom.
• pushIn / pushBack : poussée de page horizontale, 0.45s.
• splitWords + stream : les réponses de l'IA arrivent mot par mot.

5. Caméra et rythme (règles établies à partir des propres mots de l'opérateur)

• "Quand la souris clique ou quand on tape, zoomez sur la zone de cette action spécifique, et le cadre peut suivre la souris ; quand on ne clique pas, pas besoin de zoomer."
• "Rendez le zoom là où le curseur se déplace plus visible" (2026-10-15, remplace l'ancien plafond ≤1.25). Échelles bureau :

  Action	Échelle
  Frappe (zone de saisie)	1.7
  Clic sur un bouton / onglet / barre latérale	1.6
  Lecture du chat de l'Assistant, Choice Box	1.5
  Actions consécutives dans un modal	1.45, suivant le curseur
  Le Cas 1 mobile utilisait 1.25 ; les nouvelles vidéos mobiles doivent également être "visibles" — confirmez l'échelle avec l'opérateur.

• Pour les clics consécutifs (options Choice Box, modaux de l'étape Déployer), restez en gros plan et suivez tout le temps ; ne sortez pas et ne revenez pas à chaque fois.
• Lorsqu'un clic mène à un résultat que le spectateur doit voir (changement d'onglets, Par symbole / Exécutions, résultats de backtest apparaissant, métriques qui se mettent à jour, valeurs de barre d'outils remplies après génération IA), reculez vers le plan large 0.5–0.6s après le clic.
• Lorsque vous êtes zoomé, il est acceptable que les bords supérieur et inférieur d'un modal quittent brièvement le cadre, mais le curseur et la cible cliquée doivent rester dans le cadre, et le texte ne doit pas toucher le bord du cadre.
• "Pas besoin de mouvements de caméra sophistiqués ; l'objectif principal est de montrer chaque étape clairement" ; changez au rythme normal du voiceover, sans bégaiement.
• Pas de légendes dans le cadre.

6. Liste de vérification de la fidélité (pièges du Cas 1)

• Effet de frappe : un <span> par caractère, révélé un par un avec tl.set(span,{display:'inline'}). Ne réécrivez pas tout le textContent à chaque image — un retour en arrière laisse des valeurs intermédiaires incorrectes (la v2 avait un "C" supplémentaire superposé au texte indicatif).
• Retour à la ligne de la zone de saisie : pendant la configuration, révélez les caractères un par un pour mesurer lequel passe à deux lignes et de combien la hauteur augmente ; à ce moment, déplacez les cartes de questions rapides au-dessus en synchronisation.
• Calques : les cartes de questions rapides doivent se trouver au-dessus du masque de fond blanc de la zone de saisie ; la page de détail doit couvrir la barre d'onglets (z-index de la page de détail > tabbar).
• Évitez les collisions de noms de classe : la couche de superposition de texte utilise le préfixe hz- (hz-main / hz-note / hz-cta) ; elle est entrée en collision avec le .cta du panneau d'exécution et a produit une barre noire.
• Le contenu après un changement de page ne doit pas glisser sous la barre d'état / barre supérieure ; les tableaux ne doivent pas avoir de fond gris.
• Utilisez toujours immediateRender:false sur fromTo, sinon la première image est incorrecte lors d'un retour en arrière.
• Les captures d'écran doivent couvrir : avant et après chaque clic, en milieu de frappe, le moment d'un retour à la ligne, et après chaque changement de page.

Ajouts bureau (pièges du Cas 3)

• Évitez...