tasteforge-video

TasteForge Video

Pour le pipeline créatif complet autonome, utilisez taste-distillation puis taste-application. Ces skills ECC embarquent leurs scripts Python directement : mesure des références, génération ou passage des plans existants, étalonnage, montage, composition, vérification, et remise à Blender et Resolve. Aucun référentiel vidéo séparé n'est requis pour ce flux. Ce skill documente le moteur hors ligne emballé d'ECC et son contrat de preuve strict.

TasteForge transforme « rends-le comme cette référence » en un workflow reproductible et inspectable : entretien du goût, distillation en un pack de style structuré, validation du pack, application de sa cadence et de son aspect mesurés à des médias locaux, et export d'une timeline éditable. L'implémentation canonique est le paquet tasteforge embarqué dans ECC à skills/taste-application/scripts/tasteforge/. Ito-Markets/ito-video est un exemple de projet qui consomme le moteur ECC emballé.

Quand l'utiliser

• L'utilisateur demande à interviewer pour le goût vidéo avant qu'aucune séquence ne soit faite (« demande-moi à propos du look », « interviewe-moi sur la direction esthétique »).
• L'utilisateur veut distiller une esthétique en contraintes structurées — un pack de style réutilisable plutôt que des vibes (« transforme ces références en pack »).
• L'utilisateur veut valider un pack de style (les métadonnées sont-elles complètes, conformes au schéma, la cadence mesurée, la spécification distillée ?).
• L'utilisateur veut appliquer un pack de style à des séquences locales — planifier un montage à partir de la cadence mesurée du pack sur des clips locaux, de manière déterministe.
• L'utilisateur veut exporter EDL/FCPXML — une remise éditable, image par image, vers DaVinci Resolve / Premiere / Final Cut.
• L'utilisateur demande un audit de provenance des médias générés — d'où vient ce pack, cette spécification, ou ce montage ; qu'est-ce qui a été mesuré localement versus généré par un fournisseur ; qu'est-ce qui a été simulé (dry-run).
• L'utilisateur demande de découvrir ou planifier des sorties fichier-driven multimodales (images, vidéos, actifs 3D) à partir de fichiers de référence locaux, y compris des manifests séparés, des effets CV ancrés sur un sujet, ou des recettes d'effets Resolve.
• L'utilisateur mentionne TasteForge, les packs de style, flashethereal, la distillation de goût, la planification de cadence/rythme, la découverte multimodale, les workflows de distillation/application, ou un entretien de goût pour la vidéo.

Opérations déterministes locales vs génération par fournisseur

Cette frontière est le cœur de ce skill de compatibilité. Ses opérations sont locales, déterministes et hors ligne :

Opération	Déterministe ?	ECC peut l'exécuter ?
Entretien de goût → profil	oui (hors ligne)	oui
Inspection/validation de pack contre les schémas	oui	oui
Distillation du profil (+ ancrage mesuré) → spécification	oui (sémantique dry-run)	oui
Application de la cadence du pack aux médias locaux → rapport + timeline	oui	oui
Export EDL (CMX3600) / FCPXML 1.9	oui	oui
Rapport de provenance / lignée	oui	oui
Distillation vision-modèle de photos	génération par fournisseur	non
Référence-vers-vidéo, image-vers-3D, composition hébergée	génération par fournisseur	non

La génération par fournisseur doit échouer en mode fermé dans ECC. Tout appel en direct à Fal (ou autre fournisseur) — génération de plans, crédit de maillages de props, distillation VLM hébergée — nécessite une exécution explicitement séparée et autorisée via un canal distinct avec sa propre revue. Dans ce canal de compatibilité, ECC n'appelle jamais Fal, ne lit aucune clé API ou autre information d'identification (FAL_KEY inclus), ne télécharge aucun média et ne mute aucun état de compte fournisseur. Lorsqu'une requête nécessite une génération par fournisseur, énoncez exactement cette frontière, exécutez la moitié locale (entretien, validation de pack, planification, export) et arrêtez-vous.

Ne prétendez jamais qu'un workflow Fal est sauvegardé. Une référence locale à un endpoint Fal, un identifiant de modèle ou une URL de simulation (ils apparaissent dans les métadonnées du pack) est uniquement une référence : cela ne signifie jamais qu'un workflow côté fournisseur a été sauvegardé, persisté ou autorisé à s'exécuter. Tout ce qui est produit hors ligne porte une sémantique dry-run — dites « spécification dry-run » ou « plan déterministe », jamais « généré par le modèle ».

Implémentation canonique

• Référentiel : affaan-m/ECC ; distribution Python ecc-tasteforge, répertoire du paquet skills/taste-application/scripts/tasteforge/. Installez depuis le paquet ECC extrait avec python3 -m pip install ./skills/taste-application/scripts. Le projet exemple Ito-Markets/ito-video épingle un commit ECC spécifique.
• CLI : python3 -m tasteforge <commande> — provenance, inspect, validate, interview, distill, apply, export, multimodal. Les drapeaux --live se terminent avec le code 2 et refusent.
• Les schémas sont le contrat : profil de goût, manifeste de pack, étalonnage, cadence, spécification, évènements de timeline, rapports d'application (provider est verrouillé par énumération à "none" ; dry_run à true).
• La lignée des sources récupérées et les exclusions délibérées se trouvent dans le fichier skills/taste-application/SOURCE.md du dépôt. Exécutez python3 -m tasteforge provenance pour la version lisible par machine.

Utilisez le moteur ECC installé pour les commandes déterministes locales et interprétez son JSON. Installez le moteur emballé s'il est absent ; ne reconstruisez pas sa logique en ligne. taste.resolve est une importation de compatibilité de tasteforge.resolve, de sorte que les scripts créatifs et le projet exemple partagent un adaptateur Resolve vérifié.

La CLI python3 -m tasteforge utilise la distribution ecc-tasteforge installée. Les scripts autonomes taste-distillation et taste-application sont livrés dans le module de génération média optionnel d'ECC avec leurs propres prérequis Python. Aucun des deux chemins ne nécessite la publication du dépôt ou des médias de l'utilisateur.

Avant de reprendre un checkout sauvegardé, enregistrez son commit et inspectez les branches locales et les espaces de travail pour de futures corrections d'implémentation. Exécutez les tests du paquet canonique et python3 -m tasteforge apply --help ; les tests textuels et de fixtures d'ECC ne prouvent pas que le checkout Python sélectionné implémente ce contrat.

Enchaînement des skills créatifs

Étape	Propriétaire	Résultat vérifiable
Direction créative	taste	Genres nommés, observations des références, liste de looks choisis et à éviter
Distillation et planification	tasteforge-video	Preuves mesurées, spécifications de genres séparées, manifests et plan de cadence dry-run
Montage et effets	video-editing, avec le moteur de rendu choisi comme Remotion, Manim ou Fusion	Séquences appliquées, pistes réelles, effets et timeline modifiables
Actifs ou voix optionnels générés	fal-ai-media ou le workflow audio sélectionné, sous sa propre autorisation	Reçu du fournisseur et sortie inspectée
Livraison	Workflow de montage, puis content-engine si demandé	Export exact vérifié et copie de distribution

Utilisez uniquement les étapes dont le projet a besoin. La palette historique angelcore/cloud-trance et la grammaire de beat du skill taste sont des exemples créatifs optionnels ; elles ne doivent pas remplacer le brief actuel ni fusionner des genres numérotés distincts. Utilisez les références réelles de chaque genre pour sa direction, y compris 3D Cyber Glitch et Fluid Sketch. TasteForge ne remplace pas ces skills et ne nécessite pas tous les moteurs de rendu. Gardez les matériaux 3D, la géométrie, le comportement du wireframe, le mouvement et la composition explicites dans la signature du genre. Un manifeste de demande 3D est un plan pour un actif ; ce n'est pas un maillage. Un descripteur d'ancrage sujet nomme une exigence de suivi ; ce n'est pas une preuve qu'un sujet a été détecté ou suivi. Inspectez les pistes réelles, le comportement en cas de perte de piste, et les images de sujet rendues avant d'affirmer que les effets CV ont été appliqués de manière fiable.

Workflow

1. Entretien (interview) : collectez les réponses pour les axes du look — palette, grain, éclairage, focale, mouvement de caméra, cadrage du sujet, étalonnage, adjectifs d'ambiance, liste à éviter — et séparément le brief de contenu. Gardez le look et le contenu séparés ; les fusionner est l'échec classique.
2. Distillation (distill) : mappez le profil sur le schéma de spécification hors ligne, en intégrant l'ancrage mesuré du pack (point noir/blanc, contraste, chroma par zone, palette, rythme de coupe) lorsqu'un pack est fourni. Le résultat est une spécification dry-run : déterministe, fournisseur "none".
3. Validation (validate / inspect) : vérifiez le pack par rapport à ses schémas ; signalez les erreurs vs avertissements (les photos manquantes dans un pack uniquement métadonnées sont un avertissement, pas une erreur).
4. Application (apply) : planifiez les durées des plans à partir de la cadence mesurée du pack (initialisée de manière déterministe) sur les clips locaux de l'utilisateur ; produisez le rapport d'application et les évènements de timeline image par image.
5. Export (export) : écrivez EDL CMX3600 + FCPXML 1.9 avec des temps rationnels et compatibles NTSC pour importation dans un NLE réel.
6. Audit (provenance) : rapportez la lignée — empreintes des sources récupérées, historique de génération, provenance des fixtures, références fournisseur en tant qu'enregistrements de type pointeur uniquement.

Application de séquences réelles sans sources répétées

Lorsque le brief n'autorise pas de clips répétés, utilisez un checkout canonique prenant en charge apply --no-repeat --fps, et définissez explicitement le taux d'images de sortie. Si ces drapeaux sont absents, signalez l'écart d'implémentation plutôt que d'utiliser silencieusement la sélection round-robin héritée. Le mode strict utilise chaque chemin de source normalisé au plus une fois dans l'ordre du manifeste et rejette les sources insuffisantes ou trop courtes. Préparez suffisamment de sélections révisées pour remplir le plan de cadence. Il s'agit d'unicité au niveau de la source, pas du support pour des plages d'entrée/sortie distinctes du même enregistrement.

Le rapport d'application est un plan de coupe. Il n'effectue pas de classement visuel des plans, d'étalonnage des séquences, d'application d'une LUT, de rendu de superpositions, ni d'import d'un projet Resolve. Gardez la cadence de référence mesurée du pack séparée du taux d'images de sortie.

La CLI d'export s'attend à {"clips": [...]}. Enveloppez les timeline_events de l'application sous clips avant d'exporter, et passez le même --fps que celui utilisé pour l'application ; le taux d'images par défaut de l'export ne doit pas reconformer le plan. Vérifiez le nombre d'évènements émis, le nombre total d'images, les sources uniques et le lien médiatique avant de remettre la timeline au workflow de montage. Lorsque ce workflow applique des effets qui se chevauchent dans un NLE, allouez des pistes compatibles et lisez chaque début, fin et durée demandés. Un élément retourné ou un appel append réussi ne prouve pas à lui seul que chaque effet programmé a été placé ; rejetez les placements manquants, décalés ou tronqués avant le rendu.

Contrat multimodal fichier-driven

Utilisez ce chemin lorsque les références locales doivent piloter des plans de génération dry-run pour des sorties d'images, vidéos et actifs 3D tout en préservant la séparation des genres :

python3 -m tasteforge multimodal --config workflow.json --out-dir out/multimodal

La configuration nomme les genres numérotés et les fichiers de preuve locaux. Gardez ces genres candidats distincts plutôt que de les fusionner en une seule esthétique générique :

1. Flash Ethereal
2. 3D Cyber Glitch
3. Fluid Sketch

La commande mesure les références locales avec ffprobe/ffmpeg et émet une spécification de style par genre, des manifests séparés pour images, vidéos et actifs 3D, une provenance, et une recette d'effets Resolve. Le calendrier des effets doit être initialisé de manière apériodique. Les effets CV nécessitent un ancrage sujet réel dont la politique exacte en cas de perte de piste est disable_effect_until_track_recovers ; continue_without_anchor et toute autre politique échouent en mode fermé. Chaque effet porte des contraintes de placement qui préservent les visages et le texte lisible et empêchent les maillages d'angle décoratifs de remplacer le travail 3D plein écran.

Le reçu retourné est la limite du bundle. Il lie chaque artefact de preuve émis par chemin relatif, taille en octets, SHA-256, genre, modalité, provider_execution:false, et provenance exacte de référence/temps. Le reçu nécessite provider_calls:0 comme un entier exact (le booléen JSON false est invalide), provider_execution:false, et dry_run:true. Chaque spécification de genre nécessite également dry_run:true explicite. La recette d'effets Resolve nécessite ce même entier exact provider_calls:0, provider_execution:false, et dry_run:true. Chaque manifeste de modalité et chaque requête imbriquée doit contenir les quatre champs exacts de fermeture en cas d'échec : entier provider_calls:0, provider_execution:false, dry_run:true, et submit:false ; chaque requête nécessite également provider_call_mode:"disabled". Un champ manquant est un rejet, pas une valeur par défaut, et dry_run:false doit être rejeté avant que la sortie ne soit écrite.

Traitez les booléens comme des nombres invalides partout dans les données de timeline, de preuve, de sonde et de durée de source. Chaque valeur numérique de ce type doit être un réel fini : rejetez true, false, NaN, les infinis, les débuts d'évènements négatifs, les durées non positives, les temps de preuve hors plage et les évènements se terminant au-delà de la timeline finie positive déclarée. La preuve de fichier entier utilise une base de temps de fichier entier explicite et n'invente jamais d'horodatages.

Les références du reçu sont l'autorité en matière de durée. Clé chaque durée de référence validée par son SHA-256 cité ; les occurrences en double d'une même empreinte doivent s'accorder sur la durée ou le bundle est invalide. Chaque source_duration de preuve d'effet et chaque source_duration d'ancrage sujet doit être égale à la durée de reçu validée de cette empreinte, pas simplement contenir son temps cité. La durée de la sonde et toutes les mesures de la sonde doivent décrire les mêmes octets stables utilisés pour le nombre d'octets et le SHA-256. Si la source mute pendant la sonde ou est re-hachée différemment lorsqu'elle est encore disponible, échouez en mode fermé plutôt que d'émettre ou d'accepter un reçu.

Exécutez toujours la validation du bundle après la création. Un manifeste manquant (image, vidéo ou actif 3D) doit échouer en mode fermé. Les genres génériques ou dupliqués, les calendriers périodiques, les effets CV non ancrés, les contraintes de placement manquantes, les indicateurs d'exécution fournisseur, les fichiers de sortie non liés, la dérive de taille d'octet ou la falsification SHA-256 doivent échouer en mode fermé. Rejetez les racines de sortie, les intermédiaires ou les artefacts qui sont des liens symboliques, et rejetez les fichiers spéciaux (y compris les FIFO et les périphériques) ; les sorties doivent rester des fichiers réguliers dans une arborescence de répertoires réelle. Si ffmpeg ou ffprobe local est indisponible, la CLI doit retourner son erreur de traitement média local non nulle et bornée sans une trace Python. Ne réparez pas un reçu ayant échoué en supprimant des preuves ou en affaiblissant la validation.

Exemple de session

# après avoir installé le moteur ECC ; les chemins ci-dessous sont vos entrées de projet
python3 -m tasteforge validate stylepacks/flashethereal
python3 -m tasteforge interview --answers answers.json --genre flashetherea

…

[truncated for translation]