Que fait framechord ?
Utilisez le binaire framechord depuis n'importe quel agent capable d'exécuter un processus. S'il est manquant, lisez installation pour les installateurs publics, l'installation locale utilisateur et les mises à jour explicites, ou expliquez cargo install --path /path/to/framechord pour une construction depuis les sources. N'utilisez pas d'outils médias alternatifs et n'effectuez pas d'appels API fournisseur à l'intérieur de la compétence.
Les projets mediaagent/ existants sont supportés en place. Lisez renommage et projets hérités avant de mettre à niveau une installation plus ancienne ; utilisez les chemins data_directory retournés plutôt que de supposer le nom du dossier.
Lisez commandes pour chaque commande et drapeau de cette version du binaire ; workflow pour les sorties, limites, reprises et revues ; création pour les modèles de personnages et d'infographies. Les schémas lisibles par machine se trouvent dans references/schemas/. Les modèles exportés sont dans templates/.
Lisez continuité des personnages lorsque vous réutilisez les mêmes personnages à travers les scènes. Utilisez des références d'identité sélectionnées, les contrôles de fidélité supportés et la comparaison avec les images originales réelles ; le succès de l'API n'établit pas la ressemblance.
Lisez vérifications de connexion lors de la vérification de la configuration ou des échecs de fournisseur/de clé : doctor vérifie la présence hors ligne ; doctor --live authentifie explicitement avec des requêtes en lecture seule. Il supporte le filtrage par fournisseur, les timeouts et le format JSON. Lisez le statut/actions par fournisseur ; une authentification réussie n'établit pas la disponibilité de génération/modèle/facturation.
Lisez voix lors de la découverte de voix, de la conception d'aperçus, de l'acceptation d'enregistrements autorisés, ou de la création/clonage/liaison explicite d'une voix de fournisseur sélectionnée. La génération d'aperçus, la création côté fournisseur, la liaison canonique et l'acceptation d'enregistrements sont des opérations distinctes.
Lisez configuration et modèles courants pour l'assistant terminal en boucle, les valeurs par défaut Google-first et une alternative OpenAI explicite, la préservation de la configuration .env du projet, les identifiants masqués et l'installation de la compétence dans le projet, la disponibilité de la configuration non interactive, les filtres de modèles et l'actualisation explicite du catalogue. Pour un asset unique, utilisez les drapeaux explicites fournisseur/modèle/entrée/sortie sans initialisation. Pour un travail répété, les agents utilisent init PATH --preset recommended --json --non-interactive, inspectent config status --json et fournissent une configuration exacte avec config setup --file si nécessaire. Les utilisateurs humains en terminal exécutent init pour reprendre la configuration. Aucun appel fournisseur n'a lieu pendant l'initialisation. Les verrous de modèle de personnage existants sont préservés ; les identités de modèles retirés nécessitent une nouvelle version du personnage et des références acceptées par l'humain avant de pouvoir générer à nouveau.
Préservez exactement le dialogue, les paroles, les nombres et les étiquettes demandés. Utilisez une opération de planification explicite distincte lorsque vous adaptez un article en podcast. Fournissez le texte de l'article dans un fichier local. Les personnages sont optionnels ; lorsqu'ils sont sélectionnés, réutilisez leurs références acceptées et leur voix/fournisseur/modèle épinglés. Les assets d'identité dérivés doivent utiliser le fournisseur/modèle enregistré de l'asset original ; les remplacements conflictuels échouent. Préservez les métadonnées d'origine au lieu de copier la valeur par défaut du projet dans le YAML du job dérivé. Décrivez l'identité stable séparément de la pose, de la scène, de la livraison ou des vêtements temporaires. Les références candidates nécessitent la sélection de l'utilisateur avant acceptation.
Créez les fichiers à l'aide des modèles, puis validate. Inspectez generate --job ... --dry-run --json avant l'exécution lorsque les entrées sont nouvelles. Appelez la génération uniquement si elle fait partie de la demande de l'utilisateur. Utilisez --json --non-interactive pour l'automatisation. Rapportez honnêtement les chemins des artefacts retournés par le binaire et les jobs incomplets.
Utilisez runs status, runs wait, runs reconcile et runs resume pour les exécutions enregistrées. Récupérez les résultats des fournisseurs supportés avant d'envisager une nouvelle tentative payante. Ne réessayez jamais silencieusement une requête payante inconnue ; --retry-unknown nécessite une autorisation explicite de l'utilisateur. Les revues enregistrent la qualité séparément du succès de la génération. La revue ne révise pas automatiquement, et les révisions ne remplacent pas les références canoniques des personnages.
Lisez workflows de correction pour les casts v2, les entrées de planificateur sélectionnées, la vérification bornée, le stockage des références, le rattachement des résultats récupérés, l'utilisation et les migrations. Les jobs/config/runs acceptent v1 et v2 ; les nouveaux casts et l'assemblage de podcasts nécessitent v2. Les autres versions de manifeste restent inchangées.
Utilisez plan --character MANIFEST --asset FILE pour sélectionner explicitement les dépendances ; le binaire les copie dans _inputs/. Pour une scène avec plusieurs personnages enregistrés, utilisez des entrées cast et des fichiers de direction spécifiques au job. Exigez des références acceptées et des lignées de modèles originales compatibles ; ne réécrivez jamais les profils pour faire disparaître un conflit.
Pour les tests d'acceptation, prévisualisez verify --suite SUITE --json et obtenez l'approbation pour le lot payant borné avant --execute --preview-hash HASH. Les identifiants manquants sont ignorés, pas transmis. La création/clonage de voix utilisent leurs propres commandes et approbations de personnage explicites. review report compare les artefacts générés et les références enregistrées ; seules les sélections réelles de l'utilisateur autorisent l'acceptation canonique.
models --live lit les catalogues des fournisseurs ; la visibilité n'est pas un droit de génération. usage rapporte honnêtement les unités retournées et les coûts inconnus. storage plan --output cleanup.yaml prépare un aperçu de nettoyage conservateur en dehors de framechord/ ; storage clean --plan cleanup.yaml ne supprime que les blobs non référencés après revalidation. migrate --kind job|config|run --file FILE prévisualise ; --apply préserve une sauvegarde v1. Pour les jobs incertains, runs recover nécessite l'empreinte enregistrée et la preuve de réconciliation, puis runs resume publie la réponse fournie sans régénération.