remotion-assembly

Chaîne de montage pour présentateur vocal (Hub v3, issu de l'assemblage 0715-01 + itérations v3/v4)

Ce fichier est le hub du processus d'assemblage : il ne contient que le squelette du processus et le routage. Les détails des modules se trouvent dans les fichiers de references/ (point de consolidation de l'écart de 77 lignes, finalisé après un examen comparatif approfondi le 2026-07-16).

§0 Vérification de la préparation de l'environnement (À exécuter à chaque fois que le skill est invoqué, puis passer au reste une fois réussi)

Pour mettre en œuvre les règles de ce skill, vous avez besoin d'un projet Remotion avec une base. N'imprimez pas d'instructions pour que l'utilisateur le fasse lui-même – exécutez directement les vérifications ci-dessous et comblez les lacunes.

Ordre de vérification (à exécuter une par une, ne commencer que si tout est vert)

# 1) Environnement d'exécution de base
node -v && ffmpeg -version | head -1
# 2) Vérifier si le répertoire actuel est un projet Remotion
[ -f package.json ] && grep -q '"remotion"' package.json && echo "OK : projet remotion"
# 3) Vérifier si la base est complète (incomplète si l'un manque)
ls src/design/tokens.ts src/design/motion.ts src/koubo/scenes/shared.tsx \
 scripts/render-service.cjs scripts/qc-master.mjs 2>/dev/null

Gestion des trois résultats

Résultat	Action
Tout vert	Passer silencieusement, ne pas rapporter l'état de l'environnement à l'utilisateur, entrer directement dans le processus d'assemblage
Projet existant, base manquante	Installer automatiquement, sans demander (lorsque setup détecte qu'il s'agit déjà d'un projet Remotion, il ne fait qu'ajouter le skill/les scripts/la base, sans écraser votre code) :macOS/Linux : bash <(curl -fsSL https://raw.githubusercontent.com/jincheng2026/jc-remotion-skills/master/setup.sh) .Windows (PowerShell) : `irm https://raw.githubusercontent.com/jincheng2026/jc-remotion-skills/master/setup.ps1
Pas de projet	Demander avant d'installer (npm install prend 3-5 minutes et est volumineux, c'est une opération lourde qui nécessite la confirmation de l'utilisateur sur le répertoire) :« Il faut d'abord créer un projet Remotion (l'installation des dépendances prend environ 3-5 minutes). Où le créer ? Par défaut ./remotion-koubo-studio »Après avoir obtenu la réponse : macOS/Linux utiliser le setup.sh ci-dessus avec le paramètre <répertoire> ; Windows utiliser node <dépôt>/setup.mjs <répertoire>
node / ffmpeg manquant	Installer automatiquement si possible, ne pas donner la commande à l'utilisateur (la plupart des environnements peuvent installer ces deux éléments sans privilèges administrateur via le gestionnaire de paquets système) :① macOS a brew (command -v brew) → informer « X manque, je l'installe avec brew, cela prend quelques minutes » puis exécuter directement brew install <seulement ce qui manque>, puis relancer cette section après l'installation② Windows a winget → winget install OpenJS.NodeJS Gyan.FFmpeg③ Linux essayer d'abord sudo -n true : si sans mot de passe, alors sudo apt install -y nodejs ffmpeg ; si un mot de passe est nécessaire, donner la commande à l'utilisateur pour qu'il l'exécute④ Si rien ne fonctionne (ex. Mac sans Homebrew) → donner une commande officielle pour installer Homebrew que l'utilisateur peut coller dans le terminal (nécessite de saisir un mot de passe), une fois l'installation terminée, demander à l'utilisateur de le dire, puis relancer cette section

Règles

• Exécuter uniquement à la première invocation ; ne pas répéter la vérification si déjà réussie dans la même session.
• Rester silencieux quand tout est vert – l'utilisateur veut monter la vidéo, pas un rapport d'environnement. Ne parler que si quelque chose doit être installé.
• Après l'installation/la création, relancer la vérification pour confirmer que tout est vert, puis entrer dans le processus.
• Si l'utilisateur dit explicitement « sauter la vérification » ou « je sais que l'environnement est bon », respecter sa décision et commencer directement.

§0.1 Contrôle préalable obligatoire avant de commencer (À exécuter avant de proposer un plan, au même niveau que la vérification de l'environnement §0 : ne pas continuer si non réussi)

Ce fichier est un hub de routage, pas le contenu. Le tableau ci-dessous est la liste des sources réelles – elles doivent toutes être lues avant de produire le tableau du plan d'assemblage, pas « consulter au besoin ».

Obligatoire	Gère quoi
design-system references/motion.md	Vocabulaire des effets (défilement numérique / chute du verdict / croissance des lignes / sortie / écran vide), Cinq Règles de Fluidité
design-system references/typography.md	Échelle typographique T, zones de respiration, ratio du personnage principal
design-system references/layout.md	Coordonnées des trois zones, mécanisme de reprise, cadre de sécurité
design-system references/specs.md	Tableau des spécifications des composants, tableau des valeurs des effets
assembly references/subtitle.md	Césure des sous-titres, normes bilingues, barrière de validation
assembly references/rhythm.md	Densité des beats, règle de sortie, courbe de densité
assembly references/narrative.md	Système de marqueurs latéraux, cinq nœuds d'énergie, élévation du verdict
assembly references/selection.md	Table de correspondance type de phrase → type de segment → composant
design-system references/infographic.md	Métaphores graphiques, sélection de graphiques (à lire absolument pour les segments avec données/processus/comparaison)

Pourquoi cette barrière a été instaurée (2026-07-27, cause racine de l'incident 0727-01, niveau 1) : Cette version a commencé en ne lisant que ce hub + tokens.ts + un fichier Scene existant, sans lire les 9 sources réelles ci-dessus. La conséquence a été que tout le vocabulaire des effets s'est réduit à un seul « fondu » – les chiffres ne défilaient pas, les verdicts ne tombaient pas, la plupart des segments n'avaient pas de sortie, il n'y avait pas d'écran vide entre les chapitres, bien que tout cela soit écrit noir sur blanc dans motion.md.

Deux règles supplémentaires :

• Il est interdit de déduire les normes d'un fichier Scene existant. Une scène ne reflète que les règles qu'elle utilise ; ce qui manque, ce sont précisément les règles qu'elle n'utilise pas – 0727-01 a utilisé Scene02 de 0724-01 comme modèle, et comme cette scène n'avait pas de défilement numérique ni de Stamp, la vidéo entière n'en a pas eu.
• Chaque segment du plan doit indiquer le numéro de règle (voir §2 étape 2). Si on ne peut pas écrire « selon motion §7 / narrative §3 », c'est qu'on n'a pas lu, et il faut retourner lire les sources.

§0.2 Aperçu en direct Studio activé par défaut (« Chemin A », décision de l'utilisateur du 2026-07-28)

Le moyen par défaut itératif est la mise à jour à chaud de Remotion Studio, pas le visionnage d'images rendues – le cycle « modifier une chose → rendre une image → lire l'image » est réservé à la validation des barrières.

• Lancer l'aperçu au démarrage : Après la vérification de l'environnement, démarrer Studio par défaut et ouvrir la composition de la vidéo en cours pour que l'utilisateur la voie (Claude Code : lancer remotion-studio du fichier .claude/launch.json à la racine du dépôt ; hôte générique : npm run dev puis demander à l'utilisateur d'ouvrir http://localhost:3000/Koubo-<nom-de-la-vidéo>). Le composant principal a un pré-montage de base (OffthreadVideo), et Studio affiche la composition complète (présentateur vocal + MG + sous-titres + SFX en même temps), l'utilisateur peut lire et déplacer la timeline à tout moment.
• Itérer via la mise à jour à chaud : Après avoir modifié le code, la mise à jour est quasi instantanée. Les ajustements de taille de police/position/couleur/texte sont à voir directement dans l'aperçu par l'utilisateur, qui décide. Le rendu d'images (render-service stills/segment) est utilisé uniquement pour les preuves des trois barrières, les entrées de mg-judge et la validation de livraison – les règles pour les barrières et la soumission restent inchangées (la soumission inclut toujours le segment avec l'audio ; l'auto-vérification des effets doit toujours être faite en regardant des images en continu, §2.5 étape 5).
• Panneau de paramètres (Props) : Le composant principal de la nouvelle vidéo est généré automatiquement par scaffold-koubo.mjs avec un schéma zod (qc / subZhSize / subBottom / sfxGain ; le snippet d'enregistrement Root imprimé à la fin contient déjà le schéma+defaultProps). Lors de l'ajout d'InfoScrim, connecter scrimStrength au schéma comme dans src/koubo/Koubo072701.tsx ; les autres paramètres sont ajoutés/supprimés selon la vidéo. Règle absolue : les valeurs par défaut du schéma sont toujours égales aux tokens/valeurs décidées, et la sortie se fait avec les valeurs par défaut – le panneau est une couche d'exploration, pas la source de vérité. Les valeurs finalisées sont réécrites dans les sources correspondantes (taille de police/marge inférieure → tokens.ts ; niveau de volume → processus sfx §4.4). Il est interdit de laisser des valeurs non par défaut dans defaultProps. Les defaultProps de Root référencent les variables de token. Le message « Can't save default props » de Studio est une conception délibérée (pour bloquer le contournement des tokens), ne pas le corriger. La version de zod est verrouillée avec celle requise par Remotion (4.0.489 ↔ zod 4.3.6). L'avertissement de mismatch de version au démarrage de Studio est la vérification.
• Les pertes d'images lors de la lecture en temps réel sont normales pour la composition en direct du navigateur : juger le rendu des effets en ralentissant à 0.5x ou en rendant des segments. Lors du rendu avec Studio ouvert, la règle de sérialisation reste inchangée (#23 deadlock de concurrence + zone d'alerte « Studio+still concurrent crash »). Pour les processus « gelés silencieusement à 0% CPU », vérifier d'abord l'éviction iCloud (erreur #25 et sa variante node_modules).

Principes d'itération du système (Décision de l'utilisateur du 2026-07-16 : les compétences doivent constamment itérer, améliorer les normes et la qualité)

• Le cliquet ne recule jamais : Les normes décidées par l'utilisateur (valeurs de spécifications, éléments rejetés, grammaire de la bande-son) sont un plancher, pas un plafond – les sections suivantes ne peuvent qu'ajouter des contraintes, il est interdit de maintenir le statu quo avec des arguments comme « c'était comme ça la dernière fois ».
• Chaque segment doit être capitalisé : Un segment approuvé = au moins une raison why transférable dans le fichier de module ; un échec = ouverture d'un dossier d'erreur (symptôme → emplacement de la correction). Un « pas terrible/acceptable » de l'utilisateur = noter la direction d'amélioration (ex. : un effet sonore « passable » → prévoir une mise à niveau vers un pack commercial).
• Chaque vidéo doit être rétrospectée : Avant de commencer l'assemblage d'une nouvelle vidéo, parcourir d'abord le recueil d'erreurs et les « contre-exemples » de chaque module, pour confirmer que le point de départ de la nouvelle vidéo = le niveau d'arrivée de la vidéo précédente.
• La qualité ne connaît pas de plafond : La vidéo de référence actuelle n'est qu'une base, pas une fin ; dès qu'on trouve une référence de niveau supérieur, l'absorber dans la table de spécifications via la méthode de comparaison mot à mot.

Ordre d'arbitrage des conflits de règles (Lorsque deux règles s'affrontent, s'arbitrer selon cet ordre, enregistrer et attendre la confirmation de l'utilisateur)

Décision de l'utilisateur > Contraintes dures (trois zones/table d'occupation/contrôle d'accès/surface claire sans texte nu) > Alignement sémantique (montrer ce qui est dit) > Référence de densité/rythme > Préférence esthétique. Exemples d'arbitrages connus : l'alignement prime sur l'écran vide (rhythm 1), l'exemption de la règle de sortie pour l'explication des graphiques (rhythm 4, en attente de validation par un grand test), la liste rapide ne déclenche pas l'obligation de fournir un contenu de case (broll 6). Pour les nouveaux conflits, s'arbitrer selon l'ordre et enregistrer explicitement dans le plan, il est interdit d'en choisir un silencieusement.

Règles de la session principale (Barrières de la rétrospective complète du processus 0722-01, établies le 2026-07-24 ; voir my-video/docs/0722-01-全流程踩坑复盘-20260723.md)

Trois retouches en une nuit, deux blocages de la machine, la cause racine n'est pas l'exécution, mais le jugement et l'alignement. Quatre règles absolues :

1. Avant d'adopter une solution existante / de coder en dur une valeur, écrire d'abord les « conditions d'application ». La sortie par défaut du skill (ex. l'animation de révélation lente de gbro) n'est valable que dans son propre contexte, elle ne s'adapte pas automatiquement à votre contenu hôte – dans un discours dense, une révélation lente = l'image est toujours en retard (A1, 8 vidéos mises au rebut). Une valeur unique pour un lot = suppose que tous les éléments sont identiques, alors qu'ils ne le sont généralement pas (A2 « hauteur du personnage 45-60% » appliqué de manière uniforme a échoué pour les plans d'ensemble lointains). Les spécifications doivent indiquer « quel niveau utiliser dans quelle situation » (ex. métaphore basée sur l'objet 45-60% / métaphore basée sur le personnage gros plan 65-80%), pas seulement un niveau.
2. Les phrases conditionnelles de l'utilisateur ne sont pas des impératifs. « Seulement si X alors Y » donne une contrainte, pas une demande de X (A3 : l'utilisateur a dit « seulement avec un B-roll plein écran on cache le personnage » = le personnage ne disparaît pas par défaut. J'ai lu « faire le B-roll en plein écran », j'ai perdu 1.5h de retouche nocturne). Pour les termes ambigus (« faire bouger l'image » = mouvement de caméra vs mouvement d'élément), demander d'abord une clarification avant d'implémenter, c'est moins cher que de deviner.
3. La validation doit pouvoir distinguer « testé et OK » de « pas testé du tout ». QC « zéro violation » doit d'abord vérifier la couverture des sondes (erreur #35). Pour surveiller les longues tâches, surveiller le signal spécifique à la tâche (sa propre session/produit/PID de processus), pas le global – les trois fausses alertes de surveillance du 0722-01 viennent toutes d'avoir surveillé le mauvais signal (la tâche de couverture de l'utilisateur exécutée en parallèle, juger la viabilité par « depuis combien de temps le fichier n'a pas changé » alors que Codex écrit par lots). Pour les lignes rouges strictes (pas de faux texte/logo/filigrane), la session principale doit effectuer une double vérification indépendante et agrandie, sans se fier aux auto-vérifications des sous-agents (C5 : l'auto-vérification du n°07 « pas de faux texte sur les quatre côtés » alors qu'il y avait des lettres en haut).
4. Chaque modification / livraison = commit git. Le projet est un dépôt git mais jamais commité → le code des scènes v5 a été écrasé par une version plein écran, et n'a pu être reconstruit qu'en se basant sur les images rendues, avec une fidélité réduite (D3). Après chaque version ou avant livraison : git add -A && git commit. La perte de code est la seule perte irréversible de tout le processus.

Les défauts de base sont à corriger dans la base ou à enregistrer comme erreur, il est interdit de les patcher localement dans un seul segment (erreur #36 InfoScrim : patch local dans 0715-02, la lacune a persisté jusqu'à 0722-01 où elle a explosé).

Table de routage des modules (Quel fichier lire pour chaque étape de l'assemblage)

Module	Fichier	Gère quoi
Sélection du type de phrase (premier point de consultation)	references/selection.md	Table de correspondance type de phrase orale → type de segment → pointeur de grammaire → composant ; critères de la séquence de prises de vue principale ; sortie sans correspondance
R&D sans référence	references/rd-noref.md	Conception de nouvelles séquences en cas de lacune de grammaire + absence de vidéo de référence : génération de multiples solutions → judge panel → décision utilisateur
Réplication de vidéo de référence (mode R&D - couche méthode A)	Skill indépendant remotion-reference-fidelity	Méthodologie de fidélité lors de la réplication d'une vidéo de référence : six types de grammaire de scène, tableau de beats mot à mot, barrière de fidélité ; gère uniquement « comment lire fidèlement la vidéo de référence », les valeurs numériques sont toujours basées sur les sources réelles de chaque module ; la ligne de livraison alpha transparente est également définie ici (voir §6)
Narration du chapitre	references/narrative.md	Système de marqueurs latéraux, camps rouge/vert, timing des coups forts, hook/CTA, élévation du verdict
Densité et rythme	references/rhythm.md	Tableau de beats, rythme toutes les 3 à 5 secondes, règle de sortie, accentuation du récapitulatif, méthode d'audit
Sous-titres	references/subtitle.md	Césure sémantique, phrases courtes en anglais, boîte de fond, script de validation
Contenu brut	references/broll.md (source de vérité des règles) + skill d'exécution indépendant remotion-broll (détection → collecte → vérification → sélection → intégration → étalonnage → rendu de segment, un pipeline complet ; l'invoquer quand un segment de contenu brut est décidé)	Quatre niveaux de priorité (enregistrement d'écran > vidéo officielle > capture d'écran > carte simulée), pipeline de collecte et de montage vidéo, punch-in, étalonnage unifié
Audio	references/audio.md (source de vérité des règles) + skill d'exécution indépendant remotion-sfx (sélection de source → tableau d'écoute → traitement et importation → montage cue → validation quantitative, l'invoquer quand on ajoute du son à un segment)	Pipeline SFX, normes de volume, loudnorm master, validation quantitative
Mise en page/Typographie/Texture/Animation/Graphiques	design-system references/	layout / typography / texture / motion / infographic
Recueil d'erreurs (symptôme → index de correction)	Skill indépendant remotion-gotchas-index	Pour toutes les « Erreur #NN » (#18/#19/#23/#24/#25, etc.) dans le texte, l'emplacement de la correction est ici

Base technique (substrate) : Ce processus suppose que src/design/ (tokens/composants/motion/sondes QC/FontGuard) + src/koubo/scenes/shared.tsx (kit de contrôle + Place + qcAllow) sont déjà en place – ce sont des bases partagées par l'ensemble du dépôt, réutilisées sans reconstruction pour les nouvelles vidéos. En cas de démarrage à froid sans src/, installer d'abord la base selon le SKILL du design-system « Liste de la base technique du projet », puis suivre ce processus.

Processus de bout en bout pour une nouvelle vidéo (Sans vidéo de référence : checklist générale du pré-montage + SRT au produit fini)

Clarification du positionnement (2026-07-20) : La situation sans vidéo de référence est la norme, la situation avec vidéo de référence est une exception. La norme = monter un discours original, sans vidéo de référence correspondante, suivre la route de la grammaire des types de phrases de references/selection.md, utiliser des spécifications de style déjà calibrées pour produire un plan (cette checklist a été écrite pour cela). La situation avec vidéo de référence (ex. reproduire 1:1 une vidéo de référence pour un calibrage de style) est une exception, son utilité est de calibrer, vérifier si le style est bien appris ; ne pas faire de « l'alignement image par image sur une vidéo de référence » le processus par défaut. Les différentes sections actuelles utilisent principalement la vidéo de référence 0715-01 comme exemple (c'était un scénario de calibrage avec une vidéo de référence pour un alignement image par image). Les vidéos auto-produites sans vidéo de référence suivent cette checklist – le processus général est ici, les détails de l'instance de la vidéo relèvent des modules correspondants. Lorsqu'il y a une vidéo de référence, insérer uniquement avant l'étape 4 « alignement mot à mot de la contact sheet de la vidéo originale » (voir §2 étape 3 / §2.5 mode R&D), le reste est identique.

1. Validation des entrées et intégration du contenu (§0 + §0.5) : Recevoir le pré-montage + SRT, suivre les sept étapes du §0.5 pour transformer « les deux fichiers donnés par l'utilisateur » en un état prêt à travailler (vérification de la même vidéo/placement/brouillon de sous-titres/squelette du projet/adaptation de l'encodage). Utiliser ffprobe pour déterminer fps/résolution, les paramètres de la composition doivent correspondre au contenu, ne pas utiliser 60fps par défaut (erreur design-system #19) ; coder calculateMetadata.
2. Demander la composition à l'utilisateur (§1 / layout.md §1) : Ne pas décider seul si la zone d'information est à gauche ou à droite. Extraire 3-4 images pour voir la position du personnage, la décision de l'utilisateur fait foi ; par défaut, l'auteur place les MG d'information à gauche.
3. Lire le SRT en entier pour délimiter les chapitres (§2 étape 1) : Découper en 15-20 segments selon les transitions sémantiques, choisir un point d'habillage principal par segment ; marquer simultanément les cinq nœuds d'énergie sur la timeline (hook/verdict coup fort/VS décision/verdict au niveau de la vidéo entière/CTA, voir narrative.md §1).
4. Produire un plan basé sur la grammaire (Différence clé sans vidéo de référence) : Sans vidéo originale pour copier les beats, consulter d'abord la table de correspondance des types de phrases de references/selection.md phrase par phrase pour déterminer le type de segment et la grammaire principale (y compris les critères de la séquence de prises de vue principale), puis se référer aux sources réelles des modules pointés par le pointeur pour obtenir les spécifications – narrative pour le squelette narratif et les cinq nœuds, rhythm pour le changement de rythme et le pic, infographic pour les métaphores graphiques, layout pour les trois zones et la reprise. Pour les phrases sans correspondance dans la table, utiliser references/rd-noref.md. Interdiction de faire du design nu. Produire un tableau du plan d'assemblage (assembly/<nom-de-la-vidéo>/装配方案.md : plage horaire | points clés du discours | marqueur latéral | MG principal | lacune de contenu | mode de support), le soumettre à l'utilisateur pour approbation avant d'écrire du code.
5. Déterminer le mode R&D/Production (§2.5) : Tous les segments principaux ont une correspondance dans la grammaire existante = mode Production pour l'ensemble du processus (§2.5.1 cinq phases) ; les segments contenant un nouveau modèle d'agencement passent en mode R&D, en boucle segment par segment.
6. Implémentation + Trois barrières (§2.5) : Les segments de contenu utilisent remotion-broll, les segments HUD sont codés selon les mesures de layout, l'ajout de son utilise remotion-sfx ; chaque segment passe les sondes QC → mg-judge → approbation finale de l'utilisateur.
7. Validation artistique globale (§2.6) : Budget de couleurs/continuité des marqueurs latéraux/courbe de densité du rythme/répartition des SFX/éléments répétés – vérification transversale de ces cinq éléments.
8. Chaîne de mastering + Livraison (§5/§6) : Après la chaîne de mastering (compression + gain quantitatif + limiteur, règle 2 de audio.md), utiliser ffprobe pour vérifier la durée/pistes audio/débit binaire ; livrer avec les preuves (rapport QC + comparaison des images rendues). Après la livraison ou la fin d'une retouche, mettre à jour la ligne d'état de la vidéo dans le fichier STATUS.md à la racine du projet (le créer s'il n'existe pas ; c'est le fichier d'état inter-session/inter-agent, la nouvelle session qui prend le relais en dépend entièrement).

0. Spécifications d'entrée (Convention de livraison de l'utilisateur)

• L'utilisateur fournit : un pré-montage (respirations déjà coupées) + un fichier SRT associé. Ne pas exécuter whisper.
• Contrat d'interaction (Décision de l'utilisateur du 2026-07-21, niveau règle absolue) : L'utilisateur ne fournit que trois choses – ① pré-montage+SRT ; ② le contenu demandé (enregistrement d'écran/capture d'écran du B-roll – l'IA doit d'abord, selon la règle 2 de broll, établir une liste et la demander, ou l'utilisateur le fournit volontairement) ; ③ retours en langage naturel et validation finale (direction de la composition, points temporels pour l'audio/la sensation). En dehors de cela, il est interdit de demander à l'utilisateur de fournir un fichier quelconque : les plans d'assemblage, documents d'atelier, bons de retouche, tableaux de cue sont tous des produits internes, que l'IA crée, lit et continue elle-même – pour les retouches/suivis, charger automatiquement les éléments non soldés via la « ré-entrée pour la même vidéo » de l'étape 1 du §0.5, il est interdit de demander à l'utilisateur de transporter, coller ou reformuler un document interne.
• Les timestamps du SRT sont la seule référence pour l'assemblage : frame enterAt = début du SRT en secondes × fps de la composition.
• En l'absence de SRT (texte du discours uniquement), ne produire qu'un tableau de beats au niveau du plan : marquer la colonne temps comme « estimation », recalibrer impérativement avec le vrai SRT avant de coder ; si le pré-montage permet d'extraire des images, marquer la décision de composition comme « à décider ».
• Les fps/résolution de la composition correspondent au contenu (vérifier d'abord avec ffprobe, ne pas utiliser 60fps par défaut). Si ce n'est pas du 1080p@30 : les tableaux de spécifications/les frames d'effets/les assertions de métadonnées de qc-master.mjs doivent être modifiés en conséquence. La liste complète de ce qui doit être modifié est dans design-system references/motion.md §0 (l'ensemble des valeurs calibrées actuelles est verrouillé sur 30fps).
• Génération et règles de césure des sous-titres → references/subtitle.md.

0.5 Liste des actions d'intégration du contenu (Étape 0 au démarrage d'une nouvelle vidéo : du mp4+SRT fourni par l'utilisateur à l'état prêt à travailler)

0. Auto-vérification de l'environnement (si échec, s'arrêter, pas de contournement, générique pour les hôtes) : Écrire un fichier de test en Bash (ex. echo ok > assembly/env-check.txt) → Le relire pour vérifier la visibilité (Claude=outil Read) → Le supprimer. Si l'écriture n'est pas persistante ou si la relecture ne voit rien = la session s'exécute en mode bac à sable, tous les produits suivants seront volatilisés (erreur #30 : les tests du 0719-01 ont donc été perdus) – s'arrêter immédiatement et laisser l'utilisateur autoriser les droits d'écriture (Claude=autoriser Bash/édition ; Codex=workspace-write, etc.), puis commencer. Interdiction des trois contournements suivants : lien symbolique /tmp pour contourner les chemins chinois (il suffit de mettre le chemin entre guillemets doubles), désactiver soi-même le bac à sable (dangerouslyDisableSandbox ou tout autre drapeau de l'hôte), copier le projet ailleurs pour travailler. Tous les fichiers produits doivent être enregistrés sur le disque via des moyens d'écriture de fichiers standard et relus pour vérification (Claude=outil Write en priorité).
1. Vérification de la même vidéo : Comparer la durée ffprobe avec chaque vidéo existante dans public/footage/. Si l'écart est inférieur à ±1s, considérer comme la même vidéo → demander à l'utilisateur « Réutiliser l'implémentation existante ou la remonter comme une nouvelle vidéo ? » ; s'il choisit de remonter, ne pas lire du tout le code des scènes de l'ancienne vidéo ni les documents d'atelier assembly/<ancien-nom>/ (pour éviter de copier les anciennes réponses et d'écraser par erreur l'ancienne vidéo), suivre un tout nouveau processus pour le nouveau nom. Ré-entrée pour la même vidéo (suite/retouche/changement de contenu, décidé le 2026-07-21) : Lorsque l'utilisateur dit « continuez » ou ne donne que du nouveau contenu, scanner automatiquement les éléments non soldés de assembly/<nom>/segments.md + les entrées non clôturées de docs/<nom>-返工单*.md, et les définir directement comme la liste des tâches de la session – interdiction d'attendre que l'utilisateur fournisse un bon de retouche, reformule l'historique ou explique quoi modifier (§0 contrat d'interaction).
2. Définir le nom de la vidéo : MMDD-NN (date de tournage-numéro, ex. 0715-01) ; suivre le nom spécifié par l'utilisateur s'il y en a un.
3. Placement du contenu : Copier le pré-montage dans public/footage/<nom>.mp4 ; si la source est 4K, la convertir d'abord en 1080p H264 avant de la placer dans footage (la composition étant déjà en 1080p, le décodage 4K par OffthreadVideo peut provoquer des répétitions d'images = gel du personnage dans le produit fini, confirmé par l'incident 0721-01, voir erreur #33 – effectuer la conversion à l'étape d'intégration, ne pas attendre qu'un gel apparaisse au rendu pour faire une retouche) ; archiver le SRT original dans assembly/<nom>/input/ (le SRT est la seule référence d'assemblage, il doit être archivé – leçon du 0715-01 : le SRT original n'a pas été archivé, il ne restait que des artefacts et aucune base de vérification). Ne pas modifier les fichiers originaux de l'utilisateur.
4. Validation : Les éléments ffprobe du §0 + les trois éléments SRT (UTF-8 lisible, timestamps monotones, heure de fin de la dernière entrée ≈ durée de la vidéo) + Vérification des sous-titres incrustés (obligatoire après ffprobe) : extraire 1 à 3 images aléatoires avec ffmpeg, les lire avec Read, vérifier visuellement que le pré-montage n'a pas de sous-titres incrustés/de filigrane en bas (leçon du 0715-02 : la livraison originale contenait des sous-titres incrustés dans toute la vidéo, gravés dans les pixels sans flux de sous-titres indépendant, en conflit avec les nouveaux sous-titres raffinés, découverts seulement lors du rendu = un cycle QC à vide ; s'arrêter immédiatement, demander à l'utilisateur de fournir une version sans sous-titres ou de décider de l'écrasement).
5. Brouillon des sous-titres : Exécuter node scripts/srt-to-cues.mjs <archive.srt> <nom> pour une conversion mécanique vers src/koubo/subtitles-<nom>.ts (zh=texte original SRT, en=vide), puis, selon les règles 2/3 de subtitle.md, effectuer la réorganisation sémantique, la correction des fautes (basée sur le discours), la traduction en anglais, et ne commencer l'assemblage qu'après zéro erreur de check-subs.mjs. Les trois étapes sont indissociables, la traduction en anglais n'est pas une option – check-subs bloque désormais les cas où « en est entièrement vide / couverture <90% » (enquête du 2026-07-27 : 0727-01 n'a fait que la réorganisation, les 77 entrées en étaient toutes vides, le produit fini a régressé à un texte chinois monolingue ; l'ancienne version de check-subs ne validait le format que si en n'était pas vide, laissant passer silencieusement un en vide). Si une vidéo vraiment monolingue, passer explicitement --mono pour séparer « c'est une décision » et « c'est un oubli ».
6. Squelette du projet : Exécuter node scripts/scaffold-koubo.mjs <nom> <durée_en_secondes> pour générer en une commande (piste de sous-titres/piste d'effets sonores+tableau de cues vide/composant principal/répertoire scenes-<nom>/ + placeholders/tableau de segments d'atelier, volume basé sur la ligne de base actuelle ; le script imprime à la fin le snippet d'enregistrement de Root.tsx à coller tel quel). Le répertoire des fichiers de segments est isolé de scenes/ de l'ancienne vidéo – les verrous de fichiers sont indépendants par vidéo pour éviter les conflits de noms ; la base partagée est toujours importée depuis src/koubo/scenes/shared.tsx.
7. Deux endroits à modifier lors d'un changement de vidéo : COMP_ID/ENTRY de render-service et les assertions de métadonnées de qc-master, les détails sont dans §6 « Modifications obligatoires lors d'un changement de vidéo ».

1. Composition et mise en page des trois zones → design-system references/layout.md

Demander d'abord la composition à l'utilisateur (leçon du 0715-01 : la direction de la zone d'information ne peut pas être décidée unilatéralement, l'utilisateur a décidé qu'elle serait à gauche). Les coordonnées des trois zones, le mécanisme de reprise de contenu (prise-over) (niveau A : personnage disparaît pour tout le segment, sans PiP ; l'élévation des moments forts se fait en augmentant la police + effaçant + miroir rouge/vert, l'assombrissement de niveau B a été rejeté par l'utilisateur), le moment du personnage principal, les modèles de groupement – tout est dans layout.md, qui est la seule source de vérité pour la mise en page.

2. Méthode de segmentation : d'abord le plan, ensuite le code (en deux étapes)

1. Lire le SRT en entier pour délimiter les chapitres : Découper en 15-20 segments selon les transitions sémantiques (hook d'ouverture / argument / cas pratique / métaphore de transition / progression des types / résumé / prédiction / fin), choisir un « point d'habillage principal » par segment.
2. Produire le tableau du plan d'assemblage (assembly/<nom>/装配方案.md) : plage horaire | points clés du discours | marqueur latéral | MG principal | **Référence de règle** | lacune de contenu | mode de support, le soumettre à l'utilisateur pour approbation avant d'écrire du code. La colonne « Référence de règle » est la preuve de validation du contrôle préalable obligatoire du §0.1 (ajoutée le 2026-07-27) : Pour chaque segment, indiquer le numéro de règle sur lequel se base l'agencement principal du segment (ex. motion §7 défilement numérique / narrative §5 élévation du verdict / selection phrase de comparaison horizontale). Si on ne peut pas remplir un numéro de règle = ce segment a été conçu au feeling, retourner lire la source réelle et le réagencer – cette colonne n'est pas un travail administratif, c'est la seule preuve vérifiable de « lu ou pas lu » (le tableau du plan du 0727-01 avait 27 segments sans aucune référence de règle, donc toute la vidéo n'a eu qu'un seul type d'effet, le fondu).

Le mode de support B-roll doit d'abord être demandé (décision de l'utilisateur du 2026-07-24, obligatoire pour les vidéos paysage) : Lors de la segmentation, marquer les segments qui nécessitent du B-roll/incrustation. Pour chacun de ces segments, si l'utilisateur n'a pas fourni le contenu, prendre l'initiative de suggérer avec sa compréhension et demander : pour ce segment, on veut un « B-roll plein écran » (personnage disparaît, contenu occupe tout l'écran) ou un support par « carte incrustée » (personnage présent, contenu dans une petite carte à droite, comme 0722-01) ? Le mode de support détermine trois choses en une fois : ① Mise en page : coupe du personnage en plein écran vs carte + personnage permanent (layout §2 règle absolue) ; ② Résolution/outil : pour l'incrustation, du 720p suffit (utilisable avec Grok/gbro pour le collage), le plein écran nécessite du vrai 1080p – grok CLI n'a que 480p/720p, ce qui ne suffit pas, il faut passer par l'API xAI (grok-imagine-video-1.5 supporte le 1080p), du vrai contenu ou Sora/Veo/Kling/Seedance (voir broll SKILL ④) ; ③ Direction du contenu : en fonction, je génère via IA ou demande à l'utilisateur/monteur de trouver. Ne pas définir le mode de support par défaut – l'incident 0722-01, parce que par défaut il a fait du plein écran, avec un ratio uniforme, deux retouches ont été nécessaires.

Rendu parallèle des segments dont le contenu n'est pas encore disponible (règle absolue d'accélération, décision de l'utilisateur du 2026-07-24) : Après avoir confirmé le mode de support et la direction du contenu, ne pas bloquer en attendant le contenu – rendre d'abord tous les segments purement MG qui ne dépendent d'aucun contenu externe, en ne gardant que des placeholders pour les segments en attente de B-roll/incrustation ; une fois le contenu disponible, ne rerendre que ces segments, puis les splice (fusionner) dans la vidéo complète (le raccord après rendu de segment est de niveau 22s, voir §6). C'est-à-dire : découpler les segments dépendants du contenu et les segments indépendants, la session principale rend tout ce qu'elle peut pendant que l'utilisateur cherche le contenu, pour maximiser le parallélisme. 3. Si le texte du discours provient d'une vidéo de référence (enregistrement/réécriture), extraire d'abord la contact sheet de la vidéo originale pour aligner segment par segment (une image toutes les 10-15s avec ffmpeg, disposée en grille), se baser sur le traitement réel de la vidéo originale, ne pas improviser – les 8 écarts de la première version de montage provenaient tous du fait de ne pas avoir d'abord regardé la vidéo originale.

2.5 Atelier d'alignement par segment (Décision de l'utilisateur du 2026-07-16 ; Ajout du critère de double mode le 2026-07-17)

Mode R&D vs Mode Production (décidé après que l'utilisateur a demandé d'accélérer, premier principe : si la grammaire est déjà établie, il ne faut plus faire d'archéologie) :

• Mode R&D (processus complet de cette section : lecture dense d'images → plan → validation multi-voies → approbation finale segment par segment) s'applique uniquement aux segments qui introduisent un nouveau modèle d'agencement – critère : l'agencement principal du segment ne trouve pas de grammaire correspondante dans les règles existantes de narrative/rhythm/infographic/specs. Le mode R&D se divise en deux routes méthodologiques A/B : s'il y a une vidéo de référence pour extraire des images = R&D-A (étape 2 de cette section : lire les images de référence) ; lacune de grammaire ET pas de vidéo de référence = R&D-B, la méthode elle-même est dans references/rd-noref.md (génération de multiples solutions → judge panel pour choisir → décision utilisateur → consolidation par réécriture), l'étape 2 de cette section ne s'applique pas à R&D-B.
• Mode Production (segments réutilisant un modèle) : Ne pas passer par la boucle segment par segment, mais suivre une topologie de « fan-out parallèle de tous les segments + intégration centralisée » en cinq phases (détaillée dans §2.5.1) – critère inverse : l'agencement principal de tous les segments peut trouver une grammaire correspondante dans les règles existantes. Si le taux de rejet de judge pour un segment remonte = ce segment contient en fait un nouveau modèle, le repasser individuellement en mode R&D, sans impacter les autres segments (seuil de passage quantifié : remploi du même segment rejeté ≥ 2 fois ou retour en approbation finale utilisateur, voir §2.5.1 phase 4).

Boucle segment par segment en mode R&D :

1. Découpage : Aligner sur la vidéo de référence par contenu, découper en dizaines de segments (au niveau chapitre, puis affiner au niveau beat pour les segments problématiques). Règle de parallélisme multi-session (Instruction de l'utilisateur du 2026-07-17) : Avant de commencer, lire le tableau des segments assembly/<nom>/segments.md (pour cette vidéo : assembly/0715-01/segments.md) – ne pas toucher aux segments qui ont un placeholder ; avant de commencer le travail, écrire une ligne de placeholder (identifiant de session + liste de portée : quels blocs de fichiers seront modifiés) ; le rendu/npm est en série pour tout le projet (erreur #23/#24), avant de lancer un rendu, vérifier le champ avec pgrep. La première fois qu'une nouvelle vidéo entre dans l'atelier, le fichier n'existe pas : il est initialisé par la session principale – après mkdir -p assembly/<nom>/, créer segments.md, en utilisant le format du tableau de segments de 0715-01 (une ligne par segment : numéro de segment | plage horaire | point d'habillage principal | fichier de portée | état placeholder/attribution), créer d'abord avant d'assigner, les sous-agents ne font que s'attribuer un segment, pas en créer un nouveau.
2. Regarder la référence (alignement mot à mot, décision de l'utilisateur du 2026-07-16) : Extraire les images denses de ce segment de la vidéo de référence (1 image/0.5s). Lorsque le texte mot à mot est le même que celui de la vidéo de référence, utiliser les sous-titres incrustés de la vidéo de référence comme axe d'alignement – chaque image porte « ce qu'il est en train de dire », ce qui permet de reconstituer un tableau de beats mot à mot de type « à quel mot → quel MG apparaît », puis de trouver le point temporel correspondant dans notre SRT pour la même phrase ; la comparaison doit se faire en lisant et comprenant les images image par image (spécifications des éléments/relation de coordination/action de cession), il est interdit de se baser uniquement sur les noms de fichiers ou les vignettes. Juger d'abord s'il s'agit d'un « segment de contenu réel » ou d'un « segment HUD dessiné à la main » (voir broll.md introduction), puis mesurer avant de coder – à partir des images de référence, mesurer les proportions/tailles de police/positions des éléments, interdiction d'estimer visuellement (leçon du seg01 : l'estimation visuelle = réduction systématique de 0.4 à 0.7 fois). Produire un « Plan » pour ce segment (tableau de beats + diagnostic des différences + méthode de correction + captures d'écran de comparaison), le soumettre à l'utilisateur pour approbation avant de modifier le code.
3. Faire : Les segments de contenu passent par le pipeline de collecte, les segments HUD sont codés selon les valeurs mesurées.
4. Rendre ce segment : --frames=a-b donne le segment en quelques secondes ; supprimer les anciens produits avant le rendu pour éviter le cache ○.
5. Validation (trois barrières, à partir du 2026-07-16 ; ajout d'une barrière statique préalable le 2026-07-27) : ⓪Barrière de réutilisation de la base (node scripts/check-scenes.mjs src/koubo/scenes-<nom>) – scanner statiquement le répertoire des scènes : zéro référence à design/motion, zéro élément de sortie (useExit/Exit/ClearOut, motion §1 sev5) sont chacun un FAIL ; les catégories de composants sont inférieures au niveau du nombre de segments (court métrage <10 segments 3 catégories / long métrage 5 catégories), la couverture de sortie <50%, un kit auto-construit >150 lignes mais zéro motion chacun rapport WARN ; à la fin, imprimer une liste de vérification (défilement numérique / chute du verdict / écran vide entre les chapitres / vocabulaire d'effets unique), ces quatre éléments ne pouvant pas être vérifiés par le scan statique, il faut regarder les images en continu soi-même. (Seuils révisés après l'examen contradictoire du 2026-07-27 : la condition « zéro référence à Breathe rapporte WARN » de la première version a été supprimée – en conflit direct avec motion §9 « les nouvelles vidéos ne portent jamais de Breathe » ; la condition « catégories de composants <4 de manière uniforme »)

…

[Le contenu est tronqué pour la traduction]