xxjrq/github-project-intro

Orchestration vidéo pour un dépôt GitHub unique

Ce Skill est le point d'entrée unique pour orchestrer la production vidéo d'un seul dépôt GitHub. Chaque dépôt possède de manière indépendante ses faits, son planification, son script, ses captures d'écran, sa timeline, son audio, ses données de couverture et son pack de publication ; seuls les composants publics sont réutilisés. Les anciens travaux et exemples ne doivent servir que de référence, et non de faits, de schémas ou de normes visuelles strictes.

1. Ordre de lecture et responsabilités

Lire d'abord les documents spécifiés par le fichier AGENTS.md du dépôt, puis lire et exécuter intégralement par étape :

1. work-library-api-registration : Enregistrement en bibliothèque de travail ou copie des champs de tâche.
2. ~/.codex/skills/selfmedia-github-research/SKILL.md : Sources officielles et déclarations à haut risque.
3. ~/.codex/skills/douyin-tech-content-planner/SKILL.md : Audience, bénéfice unique, accroche et ordre des preuves.
4. ~/.codex/skills/record-web-demo/SKILL.md : Liste de preuves, plan d'action et captures d'écran réelles.
5. ~/.codex/skills/selfmedia-script-storyboard/SKILL.md : Déterminer d'abord le script vocal final et le storyboard lisible, sans estimer la durée audio finale.
6. Règles audio de ce Skill : Générer et mesurer l'audio en série, obtenir d'abord la durée réelle et le timing des sous-titres.
7. ~/.codex/skills/selfmedia-script-storyboard/SKILL.md : Utiliser les temps des actions de capture et l'audio mesuré pour compléter la Timeline v1.2.
8. ~/.codex/skills/selfmedia-cover-design/SKILL.md : Couvertures aux formats 3:4 et 4:3.
9. ~/.codex/skills/selfmedia-remotion-render/SKILL.md : Rendu avec les templates publics.
10. Porte de validation du flux de ce Skill : Vérifier l'ordre des étapes, les produits requis et l'état de la bibliothèque de travail ; après validation du contrat machine des cinq fichiers, générer atomiquement le pack de publication final.

L'agent de contenu ne peut modifier que ses propres unités de contenu. apps/studio/src/root.tsx, les templates publics, les couvertures publiques, les schémas, la pré-vérification et le validateur de publication ne peuvent être modifiés que par l'agent d'intégration principal. Plusieurs agents ne doivent pas modifier les fichiers partagés simultanément.

2. Enregistrement et unités de contenu formelles

1. Après qu'un utilisateur a soumis un sujet formel, l'enregistrement en bibliothèque de travail doit d'abord être effectué : pour un nouveau contenu, appeler POST /api/production-requests ; pour un répertoire existant, appeler POST /api/works puis POST /api/production-requests/adopt. Les deux méthodes doivent retourner un work_id et un ID de requête de production valides ; sans ces deux ID, aucune recherche, capture d'écran ou rendu n'est autorisé.
2. Après un enregistrement réussi, établir ou prendre le contrôle de l'unité de contenu indépendante dans projects/github/videos/<content-id>/, et synchroniser projects/index.yaml et projects/task-index.yaml. content.yaml, task.yaml et 制作单.md doivent enregistrer le même work_id ; la première étape de l'interface du flux de la bibliothèque de travail affiche toujours "Enregistrement en bibliothèque de travail".
3. La bibliothèque de travail ne stocke que les exigences de la tâche ; lors de la copie d'un template, vider l'ancienne URL du dépôt, les étoiles, la version, la licence, le script, la timeline, les captures d'écran, les sources, les données de couverture et le pack de publication.
4. renderer.composition_id est fixé à GitHubProjectDemoTemplate. L'ID du template est retourné par la bibliothèque de travail/API ; ne pas coder en dur l'ID d'un template d'un travail historique.
5. Lorsqu'un utilisateur soumet une tâche formelle, la bibliothèque de travail est autorisée à exécuter les huit étapes en continu jusqu'à release_ready. Ce n'est que lorsque l'utilisateur demande explicitement un test et spécifie un point d'arrêt que stopAfterStageId est défini ; planning ne remet que le bon de production, render ne conserve que le rendu temporaire, sans générer de répertoire formel. Lors de l'exécution continue de la bibliothèque de travail, la même session Codex est réutilisée, les portes de validation des étapes sont conservées mais le contexte n'est pas reconstruit pour chaque étape.
6. L'unité de contenu formelle doit contenir :
   • project.json
   • content.yaml
   • task.yaml
   • research/facts.json
   • 制作单.md
7. Lorsque la sortie de recherche du Pipeline se trouve dans un espace de travail temporaire, les sources officielles, les champs dynamiques actuellement utilisés et les conclusions des déclarations à haut risque doivent être réécrits dans l'unité de contenu formelle ; ne pas utiliser de répertoire temporaire à la place du projet formel.

La vidéo d'un seul projet GitHub ne maintient qu'un seul document principal rédigé manuellement, 制作单.md, en utilisant cinq blocs de balises fixes : decision, voiceover, storyboard, assets, release. Les nouvelles tâches ne créent pas research/decision.md, research/content-plan.md, script/voiceover.md, script/script.json, 创作提示词.md ou qa/ ; les faits, la timeline, le plan d'action, la liste des captures d'écran, l'audio, les SRT et les propriétés de rendu continuent d'utiliser des fichiers machine indépendants.

3. Portes de validation des sources, des risques et de la planification

1. Utiliser la page du dépôt GitHub pour confirmer l'identité du projet et enregistrer l'URL officielle. N'accéder au README, à la documentation officielle ou à la page de publication que pour les déclarations à haut risque apparaissant réellement dans cette vidéo ; ne pas effectuer de vérification encyclopédique complète des fonctionnalités.
2. Les déclarations à haut risque incluent : les chiffres et classements dynamiques ; les prix, coûts, pourcentages d'économies et comparaisons de performances ; les conclusions en matière de sécurité, de confidentialité et juridiques ; les licences, versions, état de maintenance et identité officielle ; les promesses absolues ; ainsi que les résultats spécifiques sans preuve visuelle réelle ni source officielle.
3. Les champs comme les étoiles, la version et la licence ne sont vérifiés que lorsqu'ils sont utilisés dans l'image ou le texte ; les rafraîchir avant le rendu formel. facts.json stocke les valeurs précises, les sources et les conclusions de risque ; en l'absence de déclarations à haut risque supplémentaires, enregistrer simplement une liste vide.
4. Les résumés en langage courant des points douloureux courants, des questions rhétoriques, des émotions, des analogies, de l'humour léger et des démonstrations réelles ne sont pas vérifiés phrase par phrase. Les accroches fournies ou approuvées par l'utilisateur sont verrouillées par défaut ; elles ne peuvent être rejetées que pour des erreurs factuelles évidentes, des risques de conformité légale ou une désinformation grave ; pour les autres risques, seules des modifications minimes au niveau du mot sont autorisées.
5. Une seule vidéo ne promet qu'un seul bénéfice principal. Déterminer d'abord l'audience, l'accroche en langage courant, la preuve de valeur dans les 12 premières secondes et un seul appel à l'action, puis écrire le script. Le fichier de faits ne doit pas injecter le vocabulaire technique du README dans le script vocal ; seule une barrière matérielle affectant réellement l'utilisabilité doit être expliquée naturellement avec la fonction correspondante. Il est interdit de créer une page d'avertissement de risque, une page à vérifier, un mur de clauses de non-responsabilité ou une page de limites d'application séparée.
6. Les produits finis publics ne doivent pas afficher d'URL complète, de code QR, de bouton de téléchargement, d'instruction d'action vers un site externe ou de montant monétaire spécifique pour des outils courants.
7. Arrêter si l'identité du projet ne peut être confirmée, ou si le texte public contient encore des déclarations à haut risque non résolues ; ne pas bloquer les captures d'écran et le rendu en l'absence de déclaration à haut risque.

4. Preuves réelles et temps des actifs

record-web-demo doit être exécuté en premier :

1. Utiliser une fenêtre d'affichage logique de 800×600 pour capturer le README, les images/GIF, les captures d'écran candidates et les sélecteurs.
2. Définir d'abord la prise de vue d'identité du dépôt GitHub : utiliser un cadre arrondi fin pour le nom réel du dépôt, un ovale elliptique fin pour les étoiles ou la version ; cette prise de vue doit précéder tout README ou démo externe.
3. Ensuite, sélectionner 1 à 3 preuves du README ou de la démo officielle pouvant démontrer le bénéfice principal ; les listes de fichiers, les journaux d'installation, les logos et les licences ne peuvent pas servir par défaut de preuves de résultat.
4. Utiliser des plans d'action et des fichiers de capture d'écran séparés pour l'identité GitHub et la démo externe ; capturer après validation réussie de chaque partie. Lorsqu'un encodage source 1600×1200 est nécessaire, utiliser le post-traitement --pixel-scale 2, sans agrandir la mise en page web.
5. La liste des captures d'écran doit enregistrer pour chaque action réelle : startMs, endMs, page, opération, objet de preuve et résultat de l'exécution.
6. Le script de capture doit se terminer avec succès ; les actions de la liste doivent avoir des startMs, endMs réels et un état d'achèvement ; les actions échouées ne doivent pas entrer dans la Timeline.
7. Les trimStartMs et trimEndMs de la Timeline ne peuvent provenir que de la liste des captures d'écran ; il est interdit d'utiliser les horodatages de la scène finale comme points d'entrée des actifs.

5. Script et Timeline

La durée est déterminée par l'information, le temps de parole mesuré et le temps de lecture visuelle, sans être fixée à 25 secondes. Référence narrative par défaut :

0 ~ 3 s    Page du dépôt GitHub, nom du projet, étoiles et valeur principale
3 ~ 6 s    Résultat README ou première preuve réelle de la démo officielle
12 s       Apparition de la preuve réelle la plus solide
Milieu     Continuer à démontrer 1 à 2 preuves
Fin        Scénarios d'utilisation, seuils ou limites
Conclusion Une phrase de résumé et un appel à l'action naturel

Écrire d'abord le script vocal final et le storyboard lisible dans les blocs voiceover et storyboard du fichier 制作单.md. Une fois l'étape audio terminée, utiliser la durée audio mesurée, le timing des sous-titres et la liste des captures d'écran pour générer le seul fichier directeur machine timeline.json. Timeline :

• Utiliser packages/timeline-schema/timeline.schema.json, version 1.2 ;
• Le role de la scène n'autorise que hook, proof, process, result, identity, cta ;
• direction.proofByMs <= 12000 ;
• direction.demoLayoutPreset est fixé à fixed-demo-v1 ; le cadre de la démo est fixé à x=86, y=420, width=908, height=681 ;
• Au maximum un visualPeak: true ;
• focus utilise des coordonnées normalisées dérivées de trames sources vérifiées ;
• Les scènes de démonstration ne doivent pas définir identityTop, evidenceTop, captionTop ; les surlignements ne sont autorisés qu'à l'intérieur du cadre de la démo ;
• Si la capture d'écran a déjà une annotation, ne pas la répéter dans Remotion ;
• Les scènes, les sous-titres et l'audio couvrent toute la durée, sans chevauchement, débordement ou espace vide invalide.

Le titre, la couverture, le premier plan, le script vocal, les sous-titres et le texte de publication doivent contenir GitHub et le nom du projet, et maintenir la cohérence de l'identité du projet, des chiffres et des autres faits à haut risque. Les titres des trois plateformes ne doivent pas dépasser 30 caractères Unicode chacun. Les lignes Sujets/Hashtags des trois plateformes doivent chacune contenir #github优质项目 #github开源, avec un total de 5 à 7 tags non répétés, et compléter avec le tag du projet et au moins deux tags de valeur/scénario correspondant au contenu actuel ; ajouter au maximum 2 tags tendance réels, et uniquement s'il existe une preuve de plateforme contemporaine.

6. Architecture Remotion publique

Les nouveaux dépôts utilisent uniquement les Compositions publiques :

• GitHubProjectDemoTemplate
• GitHubProjectCoverPortrait
• GitHubProjectCoverLandscape

GitHubProjectCoverFeed est uniquement pour la compatibilité historique, et n'entre pas dans la liste des Compositions, les tâches de rendu ou le pack de publication des nouveaux projets.

Le projet transmet la Timeline, le nom du projet, les étoiles, l'accroche, les résultats, les préréglages et les actifs via une entrée structurée. Interdictions :

• Créer un nouveau système visuel TSX dédié au dépôt ;
• Enregistrer une Composition vidéo ou de couverture dédiée au dépôt dans Root ;
• Coder en dur OpenMontage ou tout projet historique comme fait par défaut du template public ;
• Modifier les faits, deviner les horodatages des actifs ou réorganiser les scènes pendant la phase de rendu.

GitHubProjectDemoTemplate est l'ID du template, pas l'ID du projet. Le Studio utilise fixement http://localhost:3000/, et sélectionne les données du projet via les propriétés d'entrée. Les modifications courantes des TSX, CSS, JSON et actifs reposent sur le hot-reload ; seuls les changements de dépendances, de configuration, les modifications du point d'entrée, l'absence de réponse du service ou les erreurs de compilation irrécupérables autorisent un redémarrage avec enregistrement de la raison. Le rendu CLI formel ne dépend pas du port Studio.

Avant le rendu formel, exécuter une pré-vérification unifiée : intégrité des fichiers formels, validité des champs dynamiques et des déclarations à haut risque utilisés dans le contenu public, validation du plan d'action et des captures d'écran, validité des horodatages des actifs, validation du schéma de la Timeline, validation de la longueur du titre, cohérence du mode audio, et exhaustivité des données de couverture. Arrêter immédiatement en cas d'échec.

7. Mode audio

N'obéir qu'au voice.mode cohérent de la bibliothèque de travail, de content.yaml et de task.yaml :

• generate-and-mix : Générer Edge-TTS en série et le mixer dans la vidéo de publication ; le résultat final doit être AAC 48 kHz stéréo, avec un volume moyen d'environ -20 ~ -28 dB.
• generate-reference : Générer un fichier audio de référence sans le mixer ; la vidéo de publication doit être véritablement sans piste audio.
• self-recorded : Ne pas générer de TTS ; la vidéo de publication doit être véritablement sans piste audio ; les SRT sont conservés pour un affinage après le doublage par l'utilisateur.

La pré-vérification échoue en cas d'absence de mode ou d'incohérence entre les trois sources. L'étape audio doit précéder l'étape de la Timeline ; après tout changement du texte, regénérer et mesurer l'audio, sans réutiliser l'ancienne durée. La Timeline et les SRT doivent utiliser la durée mesurée de cette itération ; ne pas entrer en rendu si l'audio ou les SRT dépassent la durée de la Timeline.

8. Couverture et rendu formel

La couverture doit être exécutée par selfmedia-cover-design, et ne doit pas être improvisée après la fin de la vidéo. La vidéo génère fixement deux pochettes indépendantes : 3:4, 4:3 ; ne pas recadrer durement les trames vidéo, ne pas générer de couverture de flux vidéo 9:16.

Ordre d'information fixe pour la série GitHub : identité de la colonne GitHub, nom du projet, étoiles dorées sous le nom du projet, un résultat spécifique de 6 à 12 caractères. Les données de couverture doivent provenir de ce projet, et générer deux fichiers, 3:4 et 4:3.

Après que tous les projets ont passé la pré-vérification, ne Bundler qu'une seule fois, puis effectuer le rendu des vidéos et des couvertures en lot selon la planification approuvée. Ne pas prévisualiser à plusieurs reprises, extraire et re-rendre trame par trame pour une même version, et ne pas créer de répertoire d'images QA.

9. Actifs médiatiques, couverture et publication multi-plateforme

9.1 Commencer par distinguer quatre types de produits d'image

Un projet ne peut pas enregistrer un seul champ "image". Les éléments suivants doivent être gérés séparément :

Produit	Usage	Méthode de génération privilégiée	Utilisation de l'IA générative d'images
Illustration d'article	Expliquer l'architecture, le flux, les étapes d'installation, les fonctionnalités réelles	Capture d'écran officielle, trame extraite de la capture vidéo, image fixe Remotion ou SVG ; utiliser l'IA uniquement en cas de nécessité pour un arrière-plan ne portant pas de faits	Par défaut, non ; les images factuelles ne peuvent pas être fabriquées par IA
Couverture d'article	Vignette de liste d'articles pour CSDN, Zhihu, WeChat, etc.	Mise en page superposée via Remotion/HTML/CSS	L'IA peut générer un arrière-plan sans texte, mais le titre, le nom du projet, les étoiles et les chiffres doivent être superposés ultérieurement
Couverture vidéo	Couverture d'entrée pour vidéo/image-texte sur Douyin/Bilibili	selfmedia-cover-design + Composition Remotion publique, génère indépendamment 3:4 et 4:3	L'IA peut générer le sujet visuel, mais ne pas recadrer durement la trame vidéo pour remplacer la couverture
Icône de Skill	Page d'exploration SkillHub, métadonnées du pack de skill	Réutiliser l'icône du projet ou utiliser selfmedia-imagegen pour générer une icône sans texte, puis recadrer/exporter en 512 px	Possible ; ne pas inclure de petits caractères ou d'anglais illisible dans l'icône

Conclusion : La couverture d'article et la couverture vidéo ne consistent pas à extraire la première trame de la vidéo ; les illustrations d'article ne nécessitent pas non plus d'appeler la génération d'image pour chacune. Les captures d'écran réelles sont responsables des preuves, Remotion est responsable de la mise en page stable, et l'IA générative d'images n'est responsable que des arrière-plans visuels ou des icônes sans risque factuel.

9.2 Ordre de génération des actifs d'image

Pour chaque projet, préparer les actifs dans l'ordre suivant. Interdiction de commencer par la couverture puis de compléter les faits :

Vérification des sources officielles et des faits
  → Captures d'écran réelles / preuves par capture vidéo / README
  → Structure de l'article et storyboard vidéo
  → Déterminer les illustrations nécessaires
  → Générer ou organiser les actifs d'image
  → Remotion superpose uniformément le nom du projet, le titre, les chiffres et la mise en page de la marque
  → Générer la couverture de l'article, la couverture vidéo 3:4, la couverture vidéo 4:3
  → Vérification de la conformité des dimensions/de la zone de sécurité/des faits

Choix de la source d'image :

1. Image réelle du produit : GitHub, démo officielle, documentation officielle, page d'exécution réelle, capture d'écran directe ou trame extraite de la capture vidéo.
2. Diagramme explicatif : privilégier Remotion, SVG, HTML/CSS pour les diagrammes d'architecture, les organigrammes, les tableaux de comparaison et les étapes d'installation.
3. Arrière-plan d'ambiance : utiliser selfmedia-imagegen, sans y placer de logo, d'étoiles, de numéro de version, de prix ou d'engagement de fonctionnalité non vérifiés.
4. Titre de la couverture de l'article : doit être superposé dans Remotion/HTML/CSS, ne pas dépendre de l'IA pour générer du texte chinois dans les pixels.

9.3 Règles pour les champs de couverture et la mise en page

Les données de couverture de chaque projet doivent être sauvegardées séparément, incluant au minimum :

cover:
  eyebrow: "Projet Open Source GitHub"
  project_name: "<Nom du projet>"
  hook: "<Résultat spécifique de 6 à 12 caractères>"
  star_text: "<Étoiles réelles, avec date de vérification>"
  focal_asset: "<Chemin de la capture d'écran réelle ou de l'image d'arrière-plan sans risque factuel>"
  palette: "<Palette de couleurs choisie pour ce projet>"
  source_checked_at: "<AAAA-MM-JJ>"
  outputs:
    portrait: "02-CouverturePortrait-3x4.png"
    landscape: "03-CouverturePaysage-4x3.png"

Ordre d'information fixe pour la série GitHub : identité de la colonne → nom du projet → étoiles dorées → un résultat spécifique. Le titre principal de la couverture n'exprime qu'un seul bénéfice, sans insérer "100 projets", une liste complète de fonctionnalités ou des commandes d'installation dans la couverture.

• 3:4 : 1080×1440, bord supérieur à environ 115px, bord inférieur à environ 216px, bords gauche et droit à 86px.
• 4:3 : remise en page indépendante, sans étirement ni recadrage dur de la couverture 3:4.
• Image vidéo 9:16 : 1080×1920, le contenu principal respecte une zone de sécurité de 170px en haut, 288px en bas, 86px à gauche et 86px à droite ; ce n'est pas une taille de couverture vidéo.
• Le titre, le nom du projet, les étoiles, la version et autres chiffres précis utilisent une mise en page déterministe ; aucun texte précis n'est généré dans les images IA.

9.4 Répartition des tâches entre les images d'article et Remotion

Avant la publication de l'article, choisir en fonction du type d'article :

Contenu de l'article	Actifs recommandés	Description
Présentation de projet	1 couverture de projet + 1 capture d'écran GitHub réelle + 1 image de capacité principale	L'image de capacité principale utilise SVG/Remotion, pas d'IA simulant une capture d'écran de produit
Tutoriel d'installation	Capture d'écran de commande, capture d'écran de terminal, organigramme	Les commandes et chemins doivent provenir du projet réel
Analyse d'architecture	Schéma d'architecture SVG/Remotion + capture d'écran du README officiel	Visualisation de la structure, la source des faits reste le dépôt officiel
Comparaison et évaluation	Tableau Remotion/HTML + liens officiels de chaque projet	Ne comparer que les champs vérifiés
Article d'opinion pure	Couverture + quelques images d'ambiance	Les images d'ambiance peuvent être générées par IA, mais ne peuvent pas prouver la fonctionnalité du produit

9.5 Stratification des plateformes de publication

La publication n'envoie pas le même texte original sur toutes les plateformes ; elle est stratifiée en "source de code, distribution de skill, recherche d'article, distribution vidéo" :

Niveau	Plateforme	Tâche principale	Contenu publié
Source de code principale	GitHub	Faits faisant autorité, version, Issues, Étoiles	Code source, README, CHANGELOG, Licence, Release
Miroir de code national	Gitee	Accès national, point d'entrée miroir, téléchargement de secours	Code source et README synchronisés avec GitHub, clarifiant que GitHub est la source principale
Distribution de Skill	SkillHub	Recherche, installation, gestion des versions de Skill	Pack de Skill valide, manifest, description en chinois, icône, changelog de version
Recherche d'article	CSDN, Zhihu, Juejin, Toutiao, WeChat	Recherche d'articles longs, explication et génération de trafic	Article adapté à la plateforme, couverture, captures d'écran réelles, liens officiels
Distribution vidéo/image-texte	Bilibili, Douyin	Découverte, démonstration, suivi et génération de trafic	Vidéo, article/texte-image, image d'entrée 3:4 ou selon les exigences de la plateforme
Diffusion optionnelle	Shaoshupai, SegmentFault, OSChina, Blog Park	Lecteurs techniques et communauté de développeurs	Publier uniquement si le contenu est réellement adapté, ne pas publier en double pour atteindre un nombre

La combinaison de publication minimale recommandée pour 100 projets est :

Source principale GitHub + Miroir Gitee
  → Les projets avec Skill sont ensuite mis en ligne sur SkillHub
  → CSDN / Zhihu / WeChat : choisir la version d'article adaptée à la plateforme
  → Bilibili / Douyin : publier la vidéo de démonstration ou le contenu texte-image

Tous les projets GitHub ne peuvent pas être publiés sur SkillHub. Seuls les projets possédant une structure de pack de skill exécutable, un fichier SKILL.md/manifest.yaml, des mots de déclenchement et des instructions d'auto-test sont mis en ligne ; les dépôts d'outils ordinaires publient uniquement du contenu GitHub, Gitee et article/vidéo.

9.6 Adaptation à la plateforme avant publication

Chaque plateforme génère un champ release indépendant. Il est interdit de copier un article Markdown à l'identique sur toutes les plateformes :

release:
  github:
    repo_url: ""
    release_url: ""
    status: "pending"
  gitee:
    mirror_url: ""
    sync_checked_at: ""
    status: "pending"
  skillhub:
    skill_slug: ""
    package_path: ""
    icon_path: ""
    status: "not_applicable"
  articles:
    csdn: { title: "", url: "", status: "pending" }
    zhihu: { title: "", url: "", status: "not_applicable" }
    wechat: { title: "", url: "", status: "not_applicable" }
  media:
    bilibili: { url: "", status: "pending" }
    douyin: { url: "", status: "pending" }

Après l'achèvement de chaque plateforme, il faut relire le titre, les sections clés du corps/README, le lien du projet, les images et l'état de publication ; le journal de publication enregistre l'URL réelle, l'horodatage, la version, l'environnement du navigateur et la conclusion de la validation. L'envoi, la publication, la suppression et le remplacement d'anciens articles restent des actions de confirmation humaine.

10. Vérification de la publication (Release Check)

Une fois que l'Agent a terminé le processus de validation machine suivant, écrire les cinq fichiers dans renders/release-package/. Après validation par la bibliothèque de travail, renommer atomiquement en 发布成品/ et passer directement à release_ready :

• La requête de production de la bibliothèque de travail est associée à un work_id valide, et le répertoire d'enregistrement correspond exactement à source_dir ; sinon, arrêter, sans entrer dans la phase de vérification des sources et des risques, de capture d'écran ou de rendu ;
• Le Pipeline validate --require-assets réussit ;
• La validation du schéma de la Timeline, des horodatages des actifs et de la preuve des 12 premières secondes réussit ;
• La commande de rendu réussit, la sortie vidéo est en 1080×1920, 30 fps, H.264 ;
• La piste audio est conforme au voice.mode ; la fin du TTS et des SRT ne dépasse pas la durée de la vidéo ; le volume moyen final du mode generate-and-mix doit être compris entre -28 et -20 dB ;
• Les deux couvertures ont les bonnes dimensions et le bon nommage ;
• Les trois plateformes ont chacune un titre et une description sensiblement différents ; les titres ne dépassent pas 30 caractères Unicode ; la description conserve les paragraphes réels ;
• Les tags des trois plateformes contiennent tous #github优质项目 #github开源 ; chaque ligne comporte 5 à 7 tags non répétés ; les tags du projet et les tags de valeur/scénario correspondent au contenu actuel ;
• Les états de projects/index.yaml, projects/task-index.yaml, task.yaml, content.yaml sont cohérents.

Ne pas effectuer de lecture incomplète, ne pas extraire de trames, ne pas examiner image par image, ne pas faire d'OCR, ne pas créer de planche contact ou de graphique de stress 20:9, ne pas générer d'images QA ou de rapports subjectifs. L'image finale est examinée par l'utilisateur.

Ne plus définir d'étape de confirmation humaine rendered → visual_reviewed, et ne pas dupliquer de packs candidats redondants. En cas d'échec d'un contrat machine, ne pas générer 发布成品/ ni signaler release_ready. Le pack de publication formel doit contenir et uniquement cinq fichiers : texte de publication, vidéo, couverture 3:4, couverture 4:3, SRT. Le SRT est nommé fixement 04-Sous-titres.srt ; l'image finale est visualisée par l'utilisateur dans le répertoire formel.

Ne pas télécharger automatiquement, ne pas manipuler les comptes de plateforme, ne pas collecter de données post-publication.