Super-Video-Cut

Que fait Super-Video-Cut ?

Positionnement

Traitez chaque travail de montage comme une livraison d'ingénierie avec une chaîne de preuves, et non comme un empilement de plans assemblés au feeling. Cette compétence fournit une mesure objective reproductible, une évaluation détaillée et justifiée, des modèles de chronologie réutilisables, un contrôle qualité avant livraison et des limites de droits d'auteur qui traversent tout le processus.

references/ contient la matière approfondie, répartie par domaine de compétence (environ 50 documents, la plupart étant des tableaux de paramètres et des spécifications de 100 à 250 lignes). Ne lisez pas tout à l'avance — suivez le routage ci-dessous et ne lisez que les 1 à 3 documents dont l'étape actuelle a besoin.

Abréviation de volume utilisée dans tout ce fichier : 09/02 signifie references/09-material-memory/02-*.md.

Trois lignes rouges

En violer une seule interdit la livraison.

1. Style de référence : évaluer d'abord, couper ensuite. Lorsque l'utilisateur fournit une vidéo de référence, vous devez réaliser l'évaluation tridimensionnelle (art du montage / son / scène) avec une justification détaillée pour chaque entrée, et obtenir la confirmation de l'utilisateur avant de toucher à la chronologie. Produire un montage sans cette confirmation est considéré comme une reprise.

2. Rushes : vérifier le cache avant de solliciter un modèle. Avant d'analyser un rush vidéo, exécutez material_cache.py lookup. En cas de succès, lisez directement la fiche de description du rush — il est interdit de faire appel à un modèle vidéo pour une nouvelle analyse ; seulement en cas d'échec, effectuez une analyse complète et enregistrez-la.

3. Conformité et contrôle qualité d'abord. Ne montez pas un plan dont le risque de droits d'auteur n'est pas déterminé, et ne remettez pas un fichier final que qc_scan.sh n'a pas validé. Le volume juridique est une documentation de référence, pas un conseil juridique ; pour les projets commerciaux ou à haut risque, dites à l'utilisateur de le faire examiner par un avocat.

Workflow principal M0–M6

Étape	Objectif	Lecture obligatoire	Résultat
M0 Brief	Verrouiller les paramètres exécutables	Ce fichier	Brief
M1 Réception des rushes	Ne jamais payer deux fois les mêmes tokens	09/02 + scripts/material_cache.py	Fiche rush ou succès du cache
M2 Évaluation du style	Transformer "une impression" en paramètres	08/02 + 08/03 + scripts/reference_probe.sh	Grille d'évaluation + empreinte + conclusion en une page
M3 Plan de montage	Empreinte → chronologie	08/04 + le volume du genre correspondant	Plan au niveau seconde
M4 Production	Montage / voix / sous-titres / étalonnage	01 / 02 / 03 selon les besoins	Montage brut et projet
M5 Contrôle qualité livraison	Validation technique + conformité	06/01 + 06/02 + 06/03	Rapport QC + journaux de détection
M6 Retour d'expérience	Produire uniquement des candidats, ne jamais modifier les règles automatiquement	08/05	Enregistrement d'auto-amélioration

M0 Brief : demander les paramètres manquants, au maximum 3 questions

Vous devez obtenir : plateforme et rapport hauteur/largeur (détermine la zone de sécurité et la durée), durée totale, présence ou non d'une voix-off/doublage, caractère commercial ou non, spécification de livraison (résolution / débit binaire / conteneur).

Déduisez et énoncez tout ce qui peut l'être à partir de ce que vous possédez déjà ; n'interrogez pas l'utilisateur point par point. Le caractère commercial du travail détermine directement la musique et les rushes que vous pouvez utiliser — si ce point n'est pas clair, vous devez le demander.

M1 Réception des rushes : l'action pour chacun des cinq états est codée en dur

SK="$HOME/.workbuddy/skills/super-video-cut"
export MDC_HOME="$PWD/material-cache"     # garder le cache dans le projet, jamais dans le répertoire de la compétence
python "$SK/scripts/material_cache.py" lookup "<chemin du rush>"

État	Action
HIT	N'appelez pas de modèle vidéo. Lisez $MDC_HOME/cards/<MID>.yaml et effectuez uniquement une adaptation thématique
MISS	Sonde locale E1 → une seule demande d'analyse complète en utilisant references/09-material-memory/templates/model-analysis-prompt.md → remplir la fiche → validate → register
STALE	Le rush a changé ; marquez l'ancienne fiche superseded et refaites comme un MISS
HIT_BLOCKED	Le statut des droits n'est pas clarifié ; ne l'utilisez pas — résolvez d'abord les droits
Kill switch	Quand _config.json a cache_enabled=false, traitez tout comme MISS ; il est interdit de contourner cette règle

La fiche de description comporte trois couches : L0 identité (hachage / spécifications), L1 description du rush (ce qu'il montre / où il a été tourné / quel est son style / s'il est utilisable), L2 adaptation thématique (quelles secondes ce thème prend, et quel rôle narratif elles jouent). "Fonctionne bien comme ouverture pour le thème X" n'appartient qu'à L2 — le placer dans L1 contamine tous les autres thèmes.

Le champ de localisation est une règle stricte : sans texte à l'écran, un point de repère ou un enregistrement de tournage, définissez place_name: null. Ne déduisez jamais une ville à partir de "il y a la mer et un palmier".

M2 Évaluation du style : six étapes chaque fois que l'utilisateur fournit une vidéo de référence

S1 pré-vérification de conformité → S2 sonde objective → S3 deux visionnages complets → S4 évaluation dimension par dimension
→ S5 conclusion en une page → S6 ★porte de confirmation utilisateur★

• S1 Analyser uniquement, ne jamais réutiliser son expression. Les génériques de début et de fin, dialogues, musique, texte cinétique et mise en scène des plans sont tous marqués protected: expression.
• S2 Exécutez le script de sonde pour obtenir des nombres reproductibles (points de coupe, longueurs de plan, sonie, silence, statistiques de couleur, planches contact).
• S3 Regardez l'ensemble deux fois : une fois pour l'image uniquement, une fois pour le son uniquement. Passer en vitesse perd le rythme et les temps d'arrêt — c'est l'erreur méthodologique la plus courante.
• S4 Évaluez élément par élément dans les trois groupes principaux — A art du montage / B son / C scène (10 sous-éléments chacun) — plus D sous-titres, E narration, F contexte de la plateforme et G limite de conformité (obligatoire).
• S5 Produisez une conclusion en une page : 3 caractéristiques clés, 3 éléments non transférables, confiance globale.
• S6 Soumettez-la à l'utilisateur pour confirmation. Sans cette confirmation, vous ne pouvez pas entrer en M3.

Chaque entrée d'évaluation doit remplir les cinq parties ; une partie manquante invalide l'entrée entière :

① Observation (timecode + phénomène concret) ② Base (ID de preuve) ③ Inférence (pourquoi cela a été conçu ainsi) ④ Action (comment ce montage l'utilise) ⑤ Confiance (élevée/moyenne/faible + raison)

Contre-exemple (ne doit jamais être produit) : "Le montage est fluide et très cinématographique." — pas de timecode, pas de base, pas d'action, rien d'exécutable.

Chaque action doit porter une étiquette de transfert : transferable: parameter (rythme, durée, sonie, séquence de tailles de plan — apprenable) ou protected: expression (plans spécifiques, dialogues, musique, texte cinétique — non reproductible). Le style et la formule relèvent du domaine des idées et peuvent être empruntés ; l'expression ne peut pas être copiée. C'est le seuil de droits d'auteur de cette compétence, pas une suggestion.

M3 Plan de montage : traduire l'empreinte en une chronologie de second niveau

Lisez les règles de correspondance dans 08/04 et produisez une chronologie directement exécutable : point d'entrée/sortie pour chaque plan, taille de plan, type de transition et durée en trames, points de repère pour les effets sonores, points d'entrée/sortie des sous-titres et objectif de sonie.

Ordre de résolution des conflits : demande explicite de l'utilisateur > limites dures de la plateforme > caractéristiques de la vidéo de référence > esthétique par défaut. Lorsque le rush ne peut pas supporter quelque chose, dites-le clairement — "la référence utilise la technique X ; ce projet n'a pas de rush correspondant, donc Y la remplace" — plutôt que de forcer.

M4 Production : lire exactement un volume par action en cours

Action en cours	Lire
Rythme, transitions, axe	01/01, 01/02
Organisation du projet, proxies, conform, livraison	01/03
Étalonnage, Log/LUT, HDR	01/04
Enregistrement vocal, livraison, ADR	02/01
Mixage, sonie, égaliseur/compression	02/02
Musique, effets sonores, sound design	02/03
Voix IA, TTS, SSML	02/04
Disposition et durée des sous-titres	03/01
Formats SRT/VTT/ASS/TTML	03/02
Transcription, alignement, incrustation	03/03
Multilingue, CC/SDH, accessibilité	03/04
Comment montrer un genre spécifique	04/01–04/06

Ancres de sonie (tableau complet des objectifs dans 02/02) : streaming autour de −14 LUFS, podcast/Apple autour de −16 LUFS, diffusion EBU R128 à −23 LUFS, avec un True Peak généralement requis à ≤ −1 dBTP. Référez-vous à la documentation officielle de la plateforme cible ; en cas de doute, mesurez d'abord, puis décidez.

M5 Contrôle qualité livraison : exécutez d'abord le script, puis jugez en tant qu'humain

bash "$SK/scripts/qc_scan.sh" "<fichier_final>" "<répertoire de sortie>"

Un passage produit un JSON de spécifications, l'intégrité du décodage, la détection d'images noires/gel, le silence, la sonie et une planche contact. Le script ne peut trouver que des anomalies techniques — le contenu et la conformité doivent passer par les tableaux manuellement :

• 06/01 liste de contrôle des spécifications techniques (résolution / fréquence d'images / couleur / débit binaire / pistes audio / durée / nommage)
• 06/02 revue du contenu et de la conformité (faits, contenu sensible, allégations publicitaires interdites, documentation des droits)
• 06/03 Modèles de remplissage des tableaux A–G (pour les archives)

Sévérité QC : les éléments bloquants (images noires, piste audio manquante, sonie hors tolérance, risque de contrefaçon) doivent être corrigés ; les éléments d'amélioration peuvent être livrés une fois journalisés ; les éléments de suggestion attendent la version suivante.

M6 Boucle de retour d'expérience : une seule vidéo à succès ne change jamais une règle

Lorsque des retours réels arrivent (taux de complétion, conversion, notes clients), effectuez une attribution d'erreur selon 08/05 et écrivez-la dans 08/case-library/<CASE-ID>/self-improvement-record.md.

Règle stricte : un seul cas produit uniquement des candidats ; un changement prend effet seulement après ≥5 échantillons dans la même direction, un ensemble de régression figé, une validation humaine, un versionnage et un déploiement progressif. Le moteur d'auto-amélioration ne doit pas réécrire automatiquement les champs objectifs E1/E2 d'une fiche de description de rush — le cache propagerait une seule erreur à tous les thèmes ultérieurs, tandis que les enregistrements de succès auraient toujours l'air parfaitement normaux.

Chemin le plus court une fois déclenché

L'utilisateur dit	Faites ceci
"Monte quelque chose dans le style de cette vidéo virale"	Workflow complet M2 → porte de confirmation S6 ; ne commencez pas à monter
"Monte cette vidéo pour moi"	M0 demander plateforme/durée/commercial → M1 rushes → M3 plan
"Ce rush est-il utilisable, que montre-t-il ?"	M1 lookup ; répondez directement en cas de HIT, analysez uniquement en cas de MISS
"Ajoute des sous-titres"	03/01 disposition + 03/03 transcription et alignement ; vérifiez la vitesse de lecture et la durée minimale
"La voix-off sonne mal"	02/01 enregistrement → 02/02 chaîne de traitement → mesurez la sonie
"Exporte pour Douyin / WeChat Channels / Bilibili"	04/01 spécifications de la plateforme + 06/01 vérification de livraison
"Ce montage porterait-il atteinte à des droits ?"	05/02 arbre de décision + dimension G dans 08/02 ; donnez un niveau de risque, pas un avis juridique concluant
"Le montage fini est-il OK ?"	qc_scan.sh + 06/01 / 06/02 point par point

Scripts

Script	Objectif	Dépendances
scripts/material_cache.py	Empreinte des rushes, recherche dans le cache, enregistrement, réutilisation, validation, statistiques (8 sous-commandes)	Python 3, aucun package tiers
scripts/reference_probe.sh	Sonde objective d'un fichier de référence ou de rush : points de coupe, longueurs de plan, sonie, silence, couleur, planches contact	bash + ffmpeg/ffprobe
scripts/qc_scan.sh	Contrôle qualité technique d'un fichier final : spécifications, décodage, images noires, gels, silence, sonie, planche contact	bash + ffmpeg/ffprobe

Vérifiez d'abord l'environnement : ffmpeg -version && ffprobe -version && python --version. Sans ffmpeg, toute mesure objective est indisponible — dans ce cas, dites clairement à l'utilisateur que seule une évaluation manuelle est possible et qu'aucune mesure reproductible ne peut être fournie. N'inventez jamais de chiffres.

Auto-vérification avant livraison

• La référence est passée par S1–S6 et l'utilisateur a confirmé (si une référence a été utilisée)
• Chaque rush peut être retracé dans le cache jusqu'à sa source et son statut de droits
• Aucune expression non étayée comme "fluide", "premium" ou "texturé" n'apparaît dans l'évaluation ou le plan
• La sonie a été mesurée et se situe dans la tolérance cible ; le True Peak est sous la limite
• Les sous-titres ne débordent pas de la zone de sécurité, ne contiennent pas de fautes de frappe et respectent la limite de vitesse de lecture
• qc_scan.sh ne signale aucun élément bloquant, et les tableaux A–G sont remplis
• La documentation des droits pour la musique / les polices / les droits à l'image / les plans libres de droits est complète, ou le niveau de risque est indiqué
• Le nommage du fichier de livraison, le conteneur et le débit binaire correspondent aux exigences de la plateforme

Périmètre de la documentation (doit être indiqué à l'utilisateur)

• Le volume juridique n'est pas un conseil juridique. Les articles et les positions jurisprudentielles changent ; pour les projets commerciaux ou à haut risque, faites-les examiner par un avocat et fiez-vous au texte officiel le plus récent.
• Les paramètres de plateforme changent. La durée, le débit binaire, la zone de sécurité et les objectifs de sonie sont contradictoires selon les sources, ils sont donc toujours marqués "soumis à la documentation officielle la plus récente de la plateforme" — téléchargez et prévisualisez pour vérifier avant la livraison.
• Les paramètres d'auto-amélioration n'ont pas de norme industrielle. η, δ, N_min et le reste dans le volume 08 sont les valeurs de départ de cette bibliothèque ; ils existent pour rendre le processus exécutable, non parce qu'ils sont des optima validés.
• Environ 190 éléments "À VÉRIFIER" sont détaillés dans le corps ou à la fin de chaque document, concentrés dans references/00-overview/sources-and-reliability.md (avec des niveaux de preuve A/B/C/D et des priorités P0/P1/P2). Vérifiez le niveau de preuve de ce fichier avant de citer quoi que ce soit.

Routage et index

• references/INDEX.md — chemin le plus court et lecture minimale requise par étape ou tâche
• references/00-overview/knowledge-map.md — cartographie complète des domaines de compétence et recherche rapide de dépannage
• references/00-overview/sources-and-reliability.md — niveaux de preuve, liste des sources, éléments À VÉRIFIER
• references/00-overview/manifest.csv — index de fichiers lisibles par machine

Lors de la recherche dans un fichier volumineux, localisez par mot-clé au lieu de le lire en entier, par exemple grep -n "LUFS" references/02-audio-and-voice/02-audio-post-and-mixing.md.