Point d'entrée HyperFrames
HyperFrames effectue le rendu vidéo à partir de HTML — une composition est un fichier HTML dont le DOM déclare le timing avec des attributs data-*, dont le runtime d'animation est accessible par recherche, et dont la lecture multimédia est contrôlée par le framework. Le contrat d'auteur complet se trouve dans /hyperframes-core ; lisez-le avant d'écrire le HTML de la composition.
1. Démarrer à partir de l'état du projet
Appliquez la première ligne correspondante ; n'évaluez pas les lignes d'état inférieures :
| État | Action |
|---|---|
| Port explicite d'une source Remotion existante vers HyperFrames | Lisez la section /remotion-to-hyperframes de references/workflow-catalog.md, puis acheminez directement vers ce workflow. Ignorez la couche d'intention. |
| Opération spécifique sur un projet HyperFrames existant : inspecter, diagnostiquer, valider, prévisualiser, rendre, publier ou effectuer un rendu par lot | Effectuez uniquement cette opération. Ignorez l'intention et le routage du workflow ; chargez /hyperframes-cli et les compétences de domaine nécessaires. |
| Modification spécifique d'un projet existant | Effectuez la modification. N'exécutez pas la couche d'intention. |
BRIEF.md existe | Lisez workflow et flow. Exécutez ce workflow ; flow: companion s'exécute toujours dans /general-video. Ne posez aucune question sur le brief. |
Pas de brief, mais hyperframes.json ou STORYBOARD.md existe | Reprenez à partir des fichiers du projet et des préférences enregistrées. Déduisez le workflow propriétaire des artefacts existants. S'il ne peut pas être déterminé de manière unique, posez une seule question de routage ; n'exécutez pas l'entretien d'intention. |
| Nouvelle création | Exécutez la couche d'intention (§ 4), puis acheminez une fois en utilisant les règles ci-dessous. |
Continuez avec les adaptateurs de source dans § 2. Un routage de workflow direct ou repris ignore les §§ 3–4 et passe à l'installation du workflow dans § 5. Une opération ou modification spécifique ignore les §§ 3–5 et charge uniquement les compétences de domaine dont elle a besoin dans § 6.
Si une nouvelle demande n'identifie pas le sujet ou l'entrée, demandez de quoi parle la vidéo avant de router. Vérifiez les préférences et les recettes avant de demander quoi que ce soit (§ 4, étape 1).
Maintenir l'interface CLI du projet à jour
Un projet généré épingle hyperframes@<version> dans ses scripts package.json pour que les rendus restent reproductibles ; l'épingle n'avance jamais d'elle-même, et une exécution épinglée d'une ancienne CLI n'affiche aucun avertissement à ce sujet. Lors de la reprise d'un projet dont les scripts portent une épingle, sondez une fois avant la première commande affectant le rendu :
npx hyperframes@latest upgrade --project . --check
La sonde est en lecture seule et signale l'épingle par rapport à la dernière version ; conservez le . explicite — sur les anciennes versions de la CLI, un --project nu suivi d'un autre indicateur consomme cet indicateur comme valeur de répertoire. Lorsqu'il signale que le projet est en retard — ou que toute sortie CLI l'indique déjà (le message stderr This project pins hyperframes@… (latest …), ou _meta.updateAvailable: true dans un résultat --json d'un script épinglé) — appliquez avec npx hyperframes@latest upgrade --project ., puis vérifiez avec npx hyperframes check. Une vérification réussie confirme que les compositions du projet sont toujours valides sur la nouvelle version — et non que le rendu est identique image par image à l'ancienne épingle — donc une mise à niveau réussie n'est jamais silencieuse : nommez l'ancienne et la nouvelle version dans le résumé de l'exécution. Un projet sans composition n'a pas besoin de vérification. Si la vérification échoue, revenez sur la modification du package.json, continuez sur la version épinglée, et signalez sur quelle version le projet reste et pourquoi. Agissez sur le signal plutôt que de le relayer à l'utilisateur ; ne laissez jamais une épingle mise à niveau non vérifiée.
2. Adapter les entrées orthogonales avant le routage
Une source Figma modifie comment les ressources et le design entrent dans le projet, et non quel workflow possède le livrable.
Si une entrée est une URL figma.com :
- Pour une nouvelle création, commencez la couche d'intention (§ 4) et terminez ses lectures de mémoire et de recettes.
- Pendant le triage des entrées, exécutez
/figmapour extraire les ressources, les jetons de marque, les composants et les images de storyboard lorsqu'ils sont présents. Pour une modification de projet existant, exécutez/figmasans rouvrir l'intention. - Acheminez le livrable demandé en utilisant la sortie de
/figma, puis continuez uniquement les questions d'intention sans réponse de la route sélectionnée. - Ne pilotez pas Figma via des outils MCP bruts. Cela contourne la désinfection SVG, la provenance
.media/manifest.jsonlet la liaisonvar()des jetons de marque.
Une URL de PR GitHub n'est pas une source de site web. Une recette nommée ou adoptée porte déjà son workflow ; confirmez l'adoption via la couche d'intention, puis acheminez vers ce workflow.
3. Router une nouvelle création
Utilisez la première ligne correspondante. Faites correspondre le livrable demandé, et non un mot ou un type de fichier mentionné au passage.
| Priorité | Demande | Workflow |
|---|---|---|
| 1 | Porter explicitement une source Remotion existante | /remotion-to-hyperframes |
| 2 | Créer une présentation, un pitch deck ou un deck interactif navigable | /slideshow |
| 3 | Ajouter des sous-titres ou légendes simples à des images de tête parlante existantes sans les modifier | /embedded-captions |
| 4 | Ajouter des superpositions graphiques conçues à des images de tête parlante, interview ou podcast existantes sans modifier les images | /talking-head-recut |
| 5 | Construire une vidéo synchronisée sur le rythme à partir d'une piste musicale, sans narration ni capture de site web | /music-to-video |
| 6 | Créer une unité explicitement courte, sans narration, centrée sur le mouvement, typiquement de moins de 10s | /motion-graphics |
| 7 | Expliquer une pull request GitHub ou un changement de code à partir d'une référence PR | /pr-to-video |
| 8 | Commercialiser ou présenter un site web, un site produit, une application ou une entreprise à partir d'une URL ou d'un brief spécifique au site | /product-launch-video |
| 9 | Expliquer un sujet, un article ou des notes avec des visuels inventés et aucune capture de produit ou de site | /faceless-explainer |
| 10 | Toute autre vidéo ou composition personnalisée | /general-video |
Avant de finaliser le routage, lisez la section correspondante de references/workflow-catalog.md. C'est le contrat d'entrée/sortie/déclencheur canonique disponible avant que les compétences de workflow installées paresseusement ne soient présentes. Si le candidat ne satisfait pas à cette entrée, continuez le routage au lieu de forcer la correspondance.
Résoudre les ambiguïtés courantes
- Un titre animé court, un sting de logo, un hit de statistique, un hit de graphique, un hit de carte, ou un tiers inférieur autonome est
/motion-graphicslorsqu'il est sans narration et que le mouvement est le message. Un carton titre statique, une séquence narrée, un montage plus long ou une boucle personnalisée est/general-video. - Un graphique animé explicitement court peut utiliser une URL, un tweet, un article ou une capture d'écran comme matériel source. Une demande générique de « faire une vidéo à partir de ce site » est
/product-launch-video. - Des images existantes avec des sous-titres sont acheminées vers
/embedded-captions; des images avec des cartes d'information conçues sont acheminées vers/talking-head-recut. Remettre à l'heure, réorganiser, recolorer, recadrer ou remixer des images est une modification personnalisée et tombe dans/general-video. - Un fichier musical sélectionne
/music-to-videouniquement lorsque sa grille de rythme pilote la pièce. La musique utilisée comme fond sonore ne remplace pas la route correspondant au sujet. - « Je veux un storyboard » modifie le processus de révision, pas le workflow. Sans autre signal de routage, utilisez
/general-video. Un storyboard esquissé confirmé peut lui-même être le livrable demandé ; la boucle de révision définit ce point d'arrêt. - Les workflows narratifs spécialisés prennent en charge jusqu'à environ 3 minutes et sont les plus efficaces autour de 30 à 90 secondes. Acheminez une pièce nettement plus longue vers
/general-video. La longueur ne remplace jamais un port explicite, un deck, un sous-titre, une superposition ou un livrable piloté par la musique.
4. La couche d'intention — une conversation, avant l'exécution de tout workflow
Nouvelle création uniquement — le tableau d'état du § 1 décide déjà si cette section s'exécute ou non (les modifications, les opérations de projet, les projets avec brief et reprenables, et les ports Remotion explicites n'y entrent jamais). Une conversation à la porte d'entrée transforme « fais-moi une vidéo » en un brief confirmé — la route, les réponses essentielles, la forme de l'exécution et tout ce qui est dans la tête de l'utilisateur — remis au workflow qui exécute et rendu durable sous forme de BRIEF.md (forme : ../hyperframes-core/references/brief-format.md). Les workflows possèdent l'exécution ; cette couche possède la compréhension. La règle d'ouverture de chaque workflow renvoie ici, donc les questions sont posées une fois, quelle que soit la porte par laquelle l'utilisateur est entré.
Ces lectures sont obligatoires lorsque leur condition correspond ; ne les remplacez pas par des souvenirs, et lisez uniquement la section correspondante lorsqu'une référence est organisée par workflow :
| Condition | Lecture avant action |
|---|---|
| Une route est candidate, avant de la confirmer | Sa section dans references/workflow-catalog.md |
| La route est connue, avant de poser des questions spécifiques à la route | Sa section dans references/route-briefs.md |
| Le triage a jugé la demande informe, avant tout travail conceptuel | references/pitch-round.md |
| Proposer des capacités optionnelles ou collecter des médias fournis | Les lignes filtrées par route dans references/capability-menu.md |
Dériver flow, storyboard, le mode ou les champs canoniques | ../hyperframes-core/references/brief-contract.md |
1 — La mémoire avant les questions. Deux lectures, toutes deux obligatoires, avant de poser quoi que ce soit :
- Valeurs par défaut mémorisées. Soit
<MEDIA_DIR>le répertoire de compétence/media-useinstallé. Pour un projet existant,<MEMORY_ROOT>est sa racine. Avant la génération, utilisez un chemin de sonde inexistant délibérément sans.media, comme/tmp/hyperframes-intent-memory-<run-id>; n'utilisez jamais l'espace de travail actuel. Exécuteznode <MEDIA_DIR>/scripts/prefs.mjs get --hyperframes <MEMORY_ROOT> --json. Faites de chaque valeur mémorisée l'option recommandée et nommez sa source. La sonde avant projet ne voit que le niveau personnel ; ne revendiquez pas la provenance du projet. - Recettes. Exécutez
node <MEDIA_DIR>/scripts/recipe.mjs list --hyperframes <MEMORY_ROOT> --json. Si l'utilisateur nomme une recette, dit « comme la dernière fois », ou qu'une recette correspond à la route probable, demandez s'il faut l'adopter avant les autres questions du brief — et faites en sorte que l'offre mérite le oui : dites pourquoi elle correspond et ce que l'adoption permet d'économiser (« cette recette correspond à votre recette de promo de lancement — l'adopter remplit la destination, le format, la langue et le cahier des charges du design ; vous confirmerez le message et les deux questions sur la forme de l'exécution »). Lorsque plusieurs correspondent, listez-les et incluez « aucune ». Une recette adoptée verrouille les champs qu'elle contient ; posez uniquement les questions sur ses champs manquants et les questions sur la forme de l'exécution. Elle ne supprime pas les étapes de révision ou d'approbation du rendu.
2 — Trier l'entrée. De quoi parle la vidéo — un site web (vendu ou présenté), une PR, un sujet, une piste musicale, des images existantes ? Et la demande est-elle formée — le message, le matériel et l'occasion lisibles à partir de ce que l'utilisateur a donné — ou informe, un sujet sans point de vue ? Le matériel source ne règle pas cela tout seul : un site, un document ou une PR porte sa propre thèse, mais cinq narrations de cette thèse sont cinq vidéos différentes — une demande dont la seule forme vient de sa source (« fais une vidéo à propos de cette URL ») est formée sur les faits et informe sur la narration, et entre dans le tour pour pitcher la narration. Une demande formée exécute la couche exactement comme toujours ; rien ci-dessous n'est ajouté pour elle. Une demande informe passe par le tour de pitch après le routage (étape 4) et gagne une question ici, avant que quoi que ce soit ne soit généré : à quoi l'utilisateur pense-t-il déjà ? Leur réponse sème le tour (references/pitch-round.md). Un utilisateur qui dit qu'il ne connaît rien à la vidéo reçoit la carte de décision de cette référence au lieu d'une séquence de questions. Pour une demande véritablement exploratoire (« nous avons besoin d'une vidéo mais je ne suis pas sûr du genre »), n'interrogez pas — établissez le sujet et ce qui existe à montrer, une question à la fois, puis concluez par
...
[tronqué pour la traduction]