kimsanguine/signal-to-growth

OSMU Fanout

Un brief, plusieurs surfaces, une seule piste de preuves. Diffusez le contenu déjà validé plutôt que d'inventer une deuxième version de l'histoire pour chaque canal.

Entrées

Requis :

• un content-brief.json qui se valide selon contracts/content-brief.schema.json ;
• le brouillon (draft.md) et le registre des allégations (claim-ledger.jsonl) rédigés à partir de ce brief ;
• les surfaces demandées dans les planned_outputs du brief ;
• les contraintes de langue, de marque et juridiques pour le texte à l'écran ;
• la personne qui possède le sujet et la décision de rendu.

Le brief est le contrat d'entrée, pas quelque chose que cette compétence écrit. S'il n'existe pas ou ne se valide pas, arrêtez et dites-le plutôt que de reconstruire le sujet à partir du brouillon.

Flux de travail

1. Validez le brief et confirmez que le brouillon a été rédigé à partir du même brief_id.
2. Sélectionnez les allégations éligibles à la réutilisation : public: true avec un approbateur nommé.
3. Donnez à chaque instruction visuelle exactement un ID d'allégation comme sujet, et décrivez seulement ce que cette allégation affirme déjà.
4. Conservez l'état de l'allégation dans l'instruction. Une allégation inferred ou recommended ne peut pas être dessinée comme une scène observée, une capture d'écran, un graphique ou une photo de client.
5. Rédigez le script vidéo en séquences, chaque séquence nommant les ID d'allégations qu'elle prononce et le texte à l'écran dont elle a besoin.
6. Reportez les limitations du brief dans les deux surfaces. Un échantillon de trois ne devient pas une tendance parce que le format a changé.
7. Enregistrez quelles allégations ont été réutilisées, lesquelles ont été délibérément ignorées et pourquoi, afin qu'un lecteur puisse distinguer la couverture de l'omission.
8. Listez ce qu'une personne doit approuver avant tout rendu, et arrêtez-vous au texte.

Limites

• Laissez le modèle proposer la composition, le cadrage, le rythme, la formulation de la narration et l'ordre des séquences.
• Utilisez des vérifications déterministes pour la validité du brief, l'existence de l'ID d'allégation, l'état de l'allégation et l'éligibilité publique.
• Exigez qu'une personne approuve les allégations visuelles, le texte de marque et juridique, et la décision de rendre quoi que ce soit.
• Cette compétence ne crée pas de fichiers image ou vidéo. Elle produit des instructions et un plan de script ; le rendu a lieu plus tard, en dehors de cette compétence, avec un outil que la personne choisit.
• N'inventez pas une scène, une mesure sur un graphique, une capture d'écran, un logo, un visage ou un témoignage qu'aucune allégation ne soutient.
• N'améliorez pas l'état d'une allégation pour faire une image plus forte, et ne supprimez pas une limitation parce qu'elle est difficile à faire tenir à l'écran.
• Ne publiez, ne planifiez et n'envoyez rien.

Sorties

Créez :

• visual-prompts.md
• video-script.md
• fanout-coverage.md

Lisez references/output-contract.md avant de les écrire.

Conditions d'arrêt

Arrêtez lorsque le brief est manquant ou invalide, que le brouillon et le brief ne s'accordent pas sur le sujet, qu'aucune allégation n'est publiquement éligible, qu'une visuelle demandée nécessite une allégation que le registre ne contient pas, ou qu'un rendu ou une publication est demandé sans l'approbation d'une personne dans un tour utilisateur ultérieur.

Vérification

Exécutez :

python3 scripts/stg.py validate-artifacts <artifact-directory>
python3 scripts/stg.py scan-privacy <artifact-directory>/visual-prompts.md
python3 scripts/stg.py scan-privacy <artifact-directory>/video-script.md

Exigez que chaque instruction et chaque séquence nomme au moins un ID d'allégation qui existe dans claim-ledger.jsonl, et exigez qu'aucun fichier rendu n'ait été créé.