Drama2557/4RealDigital-Video-Studio

Vidéo générale

Avant de vous fier à ce workflow, exécutez :

npx hyperframes skills update general-video

Un succès sans opération signifie que le skill est à jour. Signalez un échec de mise à jour au lieu de continuer de mémoire.

1. Appliquer les adaptateurs de sources transversaux

• Média : Pour tout besoin audio, image, icône, logo, voix, étalonnage, LUT, traitement/effet, sous-titre ou opération média, chargez /media-use et suivez ../media-use/references/resolve.md (résoudre, adopter, réutiliser) et ../media-use/references/setup-providers.md (fournisseurs, authentification). Les retours vagues sur les séquences et les styles nommés utilisent ../media-use/references/media-treatments.md avant l'édition ; n'improvisez pas les effets média pris en charge avec CSS/SVG/opacité. Avant la première action authentifiée d'un fournisseur, exécutez npx hyperframes auth status et retransmettez sa sortie textuellement. Si vous êtes déconnecté, appliquez la barrière décrite dans ../hyperframes-core/references/brief-contract.md : le mode collaboratif attend la connexion ou un choix explicite hors ligne ; le mode autonome indique l'état et continue via un fournisseur hors ligne disponible. Signalez un blocage lorsqu'aucun fournisseur hors ligne ne peut satisfaire une capacité requise. L'adoption locale seule ne nécessite pas de barrière d'authentification.
• Figma : Si une entrée est une URL figma.com, exécutez d'abord /figma. Construisez à partir de ses actifs exportés, tokens, composants ou storyboards. N'utilisez pas d'appels bruts au connecteur Figma car ils contournent l'assainissement SVG, la provenance des médias et la liaison des tokens de marque.

Ces adaptateurs ne changent pas le workflow sélectionné par /hyperframes.

2. 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
Modification spécifique	Effectuez la modification, préservez les décisions existantes du projet, puis relancez les vérifications affectées. Ne rouvrez pas la découverte.
BRIEF.md existe	Lisez-le. Si workflow nomme un autre workflow et flow n'est pas companion, transférez. Ne posez pas de questions sur le brief.
Pas de brief, mais hyperframes.json ou STORYBOARD.md existe	Reprenez à partir des fichiers et des préférences enregistrées. Ne renseignez BRIEF.md qu'à partir de faits connus.
Nouvelle création	Exécutez /hyperframes et sa couche d'intention. Revenez ici uniquement pour workflow: general-video ou flow: companion.

Pour un nouveau projet, choisissez un nom de répertoire en kebab-case à partir du brief et créez la structure avant d'écrire le brief :

npx hyperframes init "videos/<projet>" --non-interactive --example=blank --skill=general-video

Ensuite, écrivez BRIEF.md à la racine du projet en utilisant ../hyperframes-core/references/brief-format.md. Dans un projet existant, la racine est le répertoire contenant hyperframes.json. Enregistrez uniquement les champs confirmés et basés sur les préférences nommés par le format du brief, en utilisant node <MEDIA_DIR>/scripts/prefs.mjs record --hyperframes <PROJECT_ROOT> ; n'enregistrez jamais de valeurs par défaut inférées. Ici, <MEDIA_DIR> est le répertoire d'installation du skill /media-use et <PROJECT_ROOT> est le répertoire contenant hyperframes.json. Si la couche d'intention a adopté une recette, appliquez-la maintenant avec node <MEDIA_DIR>/scripts/recipe.mjs use --hyperframes <PROJECT_ROOT> --name <nom> et ne demandez pas à nouveau.

3. Interpréter la forme de l'exécution

Utilisez uniquement les termes canoniques de ../hyperframes-core/references/brief-contract.md :

Champ	Signification	Effet
flow	Qui pilote	automation : choisissez et exécutez la route. companion : co-créez en conversation.
storyboard	Si le storyboard est une surface de révision	yes : lancez la révision du plan et de l'esquisse. no : construisez sans le storyboard.
mode dérivé	Comment les points de contrôle se comportent	Suivez le contrat du brief. Ne demandez jamais à l'utilisateur de nommer un mode.

N'inventez pas de synonymes pour ces états. Un signal continu de « construisez-le simplement » est géré par la couche d'intention et arrive sous la forme flow: automation, storyboard: no.

• Pour flow: automation, choisissez la route et indiquez-la en une ligne dans la première mise à jour de progression.
• Pour une modification spécifique, effectuez la modification sans inventer une nouvelle route.

Flux Companion

Lorsque flow: companion :

• Lisez BRIEF.md et réconciliez les sections ## Assets et ## Customizations acceptées avec les artefacts du projet. Terminez le travail accepté qui est encore en attente ; laissez le travail terminé tranquille ; ne proposez pas à nouveau une capacité acceptée comme si elle était nouvelle.
• Arrivez en tant que directeur, pas en tant qu'entrepreneur. Un utilisateur qui a choisi le mode compagnon a choisi l'implication et la qualité ; la réponse honnête est la meilleure version que vous puissiez concevoir, pas la plus petite que vous puissiez défendre. Le premier plan est le traitement plafond : l'arc narratif (empruntez la lentille de genre la plus proche — menu § Lentilles de genre), le cahier des charges, le traitement de mouvement de chaque scène cité par son nom (§ 5, discipline du plan), les transitions, l'identité audio — musique et marques sonores, ou silence délibéré — le matériau de l'utilisateur placé, et une ouverture et une fermeture conçues. Dites ce que chaque couche ajoute en une ligne ; signalez les plus coûteuses (temps de rendu, connexion, facturation) au moment de les nommer. L'utilisateur réduit un traitement ; il ne devrait jamais avoir à en assembler un approbation par approbation.
• Le plafond appartient au concept, pas à la boîte à outils. Chaque couche doit servir le message du brief — un traitement qui habillerait n'importe quelle vidéo de la même manière est de la décoration. L'artisanat s'élève jusqu'au plafond ; le contenu ne grandit jamais au-delà de ce qui a été demandé (§ 6).
• Entre les points de contrôle, ../hyperframes/references/capability-menu.md fonctionne dans les deux sens. En tant que liste de déclencheurs : proposez une capacité pertinente lorsque l'utilisateur mentionne son entrée ou que la construction atteint son besoin. En tant que canal de mise à niveau de chaque passage : un point de contrôle de plan, d'esquisse ou de construction peut porter une ou deux offres tracées pointant vers le matériau que l'utilisateur regarde (« le stat de la scène 3 nécessite le traitement de comptage »). Lisez-le avant de proposer ; ne déversez jamais le catalogue complet.
• Après que l'utilisateur a accepté une capacité, produisez son artefact et enregistrez la décision dans la section correspondante du corps de BRIEF.md immédiatement. Ne réécrivez un champ d'en-tête et n'enregistrez la préférence confirmée que lorsque l'utilisateur la modifie explicitement.
• Gardez les mêmes points de contrôle de storyboard, de validation, d'aperçu final et d'approbation du rendu. Le mode compagnon change qui dirige, pas ce que la qualité exige.

4. Charger les connaissances requises avant chaque étape

Ces lectures sont obligatoires lorsque leur condition correspond :

Condition	Lire avant d'agir
Tout code HTML de composition ou mise en page de scène	/hyperframes-core ; utilisez references/determinism-rules.md pour son contrat de mise en page
Toute création non triviale ou traitement visuel	/hyperframes-creative → references/house-style.md et references/video-composition.md
Tout mouvement, animation ou transition de scène	/hyperframes-animation ; suivez son routage vers les règles, adaptateurs, blueprints ou références de transition correspondants
storyboard: yes	../hyperframes-core/references/storyboard-format.md et ../hyperframes-core/references/review-loop.md
Tout actif ou opération média, y compris narration, BGM, effets sonores, sous-titres, étalonnage ou transformations	/media-use ; pour la lecture et le placement dans le framework, lisez également /hyperframes-core → references/variables-and-media.md
Assemblage multi-scène	../hyperframes-core/references/production-loop.md
flow: companion, avant le premier plan	/hyperframes-creative → references/story-spine.md et references/house-style.md ; la lentille de genre la plus proche et l'intégralité de ../hyperframes/references/capability-menu.md — le traitement plafond est conçu à partir de ceux-ci, pas rappelé de mémoire
Une offre de capacité compagnon, capture, grille de rythme, vidéo générative, carte, publication ou capacité inter-workflow	../hyperframes/references/capability-menu.md
Un cahier des charges existe, avant l'approbation finale	/hyperframes-creative → references/design-adherence.md

Ne remplacez pas ces lectures par des souvenirs. La divulgation progressive ne sauvegarde le contexte que lorsque la référence correspondante est réellement chargée.

5. Exécuter la composition

Utilisez cet ordre de dépendances. Ne sautez une étape que lorsque son entrée est absente.

1. Plan. Énoncez l'arc du spectateur, la structure, le rythme et le pilote de la durée. Utilisez un fichier pour une courte scène unique ; utilisez des sous-compositions pour trois coupes de scène dures ou plus, ou toute scène réutilisée. Lisez /hyperframes-creative → references/story-spine.md pour les arcs narrés, references/beat-direction.md pour le rythme, et /hyperframes-core → references/composition-patterns.md pour la structure. Pour un brief multi-scène ouvert, développez l'invite via /hyperframes-creative → references/prompt-expansion.md. Un plan multi-scène cite la forme de chaque scène : un identifiant de blueprint provenant de /hyperframes-animation → blueprints-index.md lorsqu'il correspond, ou les règles nommées qu'il compose à partir de rules-index.md lorsqu'aucun ne correspond — les noms de mouvement proviennent de ces index, jamais inventés. La vérité de l'histoire décide quelles scènes existent ; la citation les habille. Un plan multi-scène est également enregistré en tant qu'artefact de dispatch : un bloc ## Trame N par scène dans STORYBOARD.md — status: outline, une src: déclarée, la citation du blueprint/règles et le texte de la trame rythmique — même lorsque storyboard: no. Le bloc est l'unité de dispatch ; le storyboard n'est que la surface de révision.

2. Réviser le plan lorsqu'il est demandé. Pour storyboard: yes, exécutez la boucle de révision partagée sur ces blocs. Pour storyboard: no, continuez sans ouvrir le storyboard. Lorsqu'une pause de plan se produit quand même, intégrez l'autorisation de délégation du sous-agent (nécessaire pour le dispatch de l'étape 4 par codex) dans cette pause plutôt que de vous arrêter à nouveau plus tard.

3. Résoudre les dépendances. Installez les blocs de registre avant le travail parallèle. Préparez les actifs utilisateur, adoptez les médias existants et ne résolvez que ce que le brief exige. Démarrez l'audio tôt lorsque ses temporisations pilotent la durée.

4. Construire les scènes. Pour une courte pièce à scène unique, implémentez la scène à son moment le plus visible avant d'ajouter du mouvement (le wireframe confirmé, lorsqu'il est présent, est cet état final et ne doit pas être redessiné), puis animez à partir de son blueprint ou de ses règles cités — lisez le corps complet de la recette (/hyperframes-animation → blueprints/<id>.md, rules/<id>.md) avant d'écrire le mouvement.

   Le dispatch ne paie qu'à l'échelle. La création de paquets et le préchauffage de nouveaux contextes de travail coûtent des minutes et des tokens réels : un film d'environ 6 courtes scènes se construit PLUS VITE en ligne, dans ce contexte, une scène après l'autre (mesuré : 5 courtes scènes ≈ 9 min en ligne contre ≈ 21 min en paquets). Ne répartissez que lorsque le plan dépasse cette limite — plus de scènes, ou des scènes individuellement lourdes — et donnez alors à chaque travailleur 2–3 scènes, pas une, et lancez tous les travailleurs en une seule vague (une deuxième vague double presque la fenêtre). Lors du dispatch :

   node <SKILL_DIR>/scripts/frame-packets.mjs --project "$PROJECT_DIR" --storyboard "$PROJECT_DIR/STORYBOARD.md"

   Le constructeur écrit un paquet délimité par scène sous .hyperframes/frame-packets/ (le bloc de storyboard exact de la scène + le corps du blueprint + chaque règle citée, en ligne) et _role.md (../hyperframes-core/references/frame-worker.md).

   Chaque travailleur reçoit des sous-tâches à une scène via node <SKILL_DIR>/scripts/frame-assemble.mjs. Les variables médiatiques liées via /hyperframes-core → references/variables-and-media.md sont échangées pour les actifs montés ; le code du paquet est validé pour la déterministe décrite dans ../hyperframes-core/references/determinism-rules.md avant frame-assemble.mjs.

   Le résultat d'un travailleur est une composition HTML unique paginée dans build/scenes/<n>-<slug>.html et sa vignette dans build/thumbnails/<n>-<slug>.png.

   Surveillez les limites du contexte. Un plan de 12 scènes réparties en 4 lots de 3 scènes surpasse 12 lots d'une scène.

5. Étapes de post-construction.

   • Validation : Exécutez le vérificateur de composition (node <SKILL_DIR>/scripts/check-composition.mjs --project "$PROJECT_DIR"). Tous les scènes de construction actuelle doivent être valides dans la composition ; les précédentes sont supprimées. Le binaire de validation analyse les problèmes de mise en page, les ressources manquantes et les échecs de sélecteur CSS. Corrigez les problèmes avant de continuer.
   • Montage : Assemblez les scènes validées via node <SKILL_DIR>/scripts/compose.mjs --project "$PROJECT_DIR". Cela crée le montage brut : une chronologie avec tous les scènes dans l'ordre, les transitions (lire /hyperframes-animation → references/transition-catalog.md pour les options), les crossfades audio et le positionnement des sous-titres. Le montage produit build/composition-raw.html.
   • Finitions : node <SKILL_DIR>/scripts/finish.mjs --project "$PROJECT_DIR". Cela applique les dégradés vidéo (lire /media-use/references/grade-spec.md), les effets finaux (lire /media-use/references/media-treatments.md pour le post-traitement), les superpositions de générique (lire /hyperframes-creative/references/title-card-spec.md), et valide la chronologie finale.
   • Rendu : node <SKILL_DIR>/scripts/render.mjs --project "$PROJECT_DIR". Le rendu utilise la configuration du fournisseur pour produire le fichier final. Pour le rendu local, les exigences sont : FFmpeg (v4.4+), Chrome (v100+). Le rendu échoue avec un message clair si les dépendances sont manquantes.

6. Limites de qualité et de portée

• Durée vidéo maximale : 30 minutes (1800 secondes). Au-delà, divisez le projet en segments de 30 minutes.
• Limite de scènes : 50 scènes par composition.
• Actifs : Résolution d'actif maximale de 8K (7680x4320). Les actifs audio doivent être en WAV, MP3 ou FLAC.
• Polices : Utilisez les polices web sûres et les polices système. Évitez les polices personnalisées non packagées.
• Performance : Les compositions doivent viser une fluidité de mouvement de 60 ips sur un matériel de référence. Signalez les goulets d'étranglement de performance dans la sortie de validation.
• Ce skill n'est pas un séquenceur musical, un générateur de jeux, un lecteur de diapositives ou un outil de streaming en direct. Les cas d'utilisation en dehors de sa portée doivent diriger l'utilisateur vers le workflow approprié.

7. Journalisation de la progression et rapports

À chaque étape, enregistrez un résumé au format JSON structuré dans .hyperframes/progress.json :