Vers l'article
Transformez un content/TOPIC.md approuvé en content/ARTICLE.md : le maître du contenu lisible pour à la fois le futur billet de blog et le plan vidéo.
Préconditions
Lisez content/TOPIC.md, content/RESEARCH.md, chaque rapport d'expérience cité et le matériel source nécessaire pour vérifier les preuves sélectionnées. Continuez uniquement lorsque TOPIC.md a le statut status: approved.
Revenez à /develop-topic lorsque la rédaction révèle une affirmation matérielle manquante, des preuves contradictoires, une conclusion non étayée ou un changement nécessaire dans les limites approuvées du public, de la thèse, de la portée, de l'argumentation, des preuves ou des conclusions. Remettez immédiatement TOPIC.md au statut status: draft, résolvez l'écart là-bas et renouvelez l'approbation du sujet avant de rédiger à partir de celui-ci. L'ajout de preuves qui modifient la confiance, la limite ou l'interprétation est matériel ; l'ajout d'une source équivalente sans modifier le contrat ne l'est pas.
Voix
Déterminez la voix de l'article à partir du sujet approuvé. Avant de rédiger, inspectez les compétences disponibles pour une compétence de style d'écriture correspondant à la langue de sortie et au type de contenu, puis chargez toutes les sources de style utilisateur, projet ou marque applicables nommées dans voice.skills ou voice.documents.
Si aucune source fiable n'existe pour un article de qualité publication, posez une question concise pour la voix souhaitée ou un échantillon. Lorsque l'utilisateur délègue ce choix, ou que l'article est explicitement un brouillon interne, utilisez une valeur par défaut explicative claire et enregistrez voice.status: assumed. Enregistrez les sources nommées indisponibles sous voice.unavailable ; elles ne constituent pas une preuve que leurs règles ont été appliquées. Une source indisponible ne bloque pas la rédaction lorsqu'une autre source disponible résout la voix.
Rédaction
Rédigez un article complet et indépendant de la plateforme. Il doit se suffire à lui-même pour un lecteur, préserver l'argumentation et les limites approuvées, distinguer les faits de l'interprétation et citer les sources originales derrière les affirmations matérielles. Utilisez des titres, des liens, des tableaux ou des notes lorsqu'ils aident la lecture ; les champs SEO spécifiques au site, les composants de publication et les chemins de plateforme appartiennent à une adaptation de publication ultérieure.
Écrivez content/ARTICLE.md avec ce front-matter :
---
source: content/TOPIC.md
source_digest: sha256:<TOPIC approved_digest>
status: draft
voice:
language: ...
skills: []
documents: []
unavailable: []
status: resolved | assumed
---
L'article peut améliorer le titre de travail, la prose, les exemples et l'ordre des sections. Il peut compresser ou expliquer les affirmations approuvées, mais chaque fait, point de vue et conclusion matériels doit remonter au sujet approuvé et à ses preuves. Tout nouveau contenu va d'abord en amont.
Porte d'approbation
Présentez l'article complet pour révision. Seule l'approbation explicite de l'utilisateur modifie son front-matter en :
status: approved
approved_at: YYYY-MM-DD
approved_digest: sha256:<digest>
Calculez approved_digest comme le SHA-256 du fichier complet après avoir supprimé uniquement la ligne approved_digest:. Avant de rédiger ou d'approuver, recalculez le digest du sujet et exigez qu'il corresponde à la fois à approved_digest de TOPIC.md et à source_digest de cet article. Une discordance rend l'approbation concernée ou le brouillon dépendant obsolète. Une modification non matérielle vérifiée peut actualiser et propager les digest sans renouvellement de l'approbation.
Jusqu'à ce moment, ne créez pas BEATS.md. Une demande de poursuivre la production ne remplace pas l'approbation de l'article lui-même.
Une révision matérielle de TOPIC.md ramène l'article à l'état draft. Une révision matérielle d'un article approuvé le ramène également à l'état draft ; les corrections de copie, les changements de titre et les exemples qui préservent le sens approuvé ne le font pas.
Avant de présenter content/ARTICLE.md ou toute révision ultérieure, suivez ../boring-video/references/markdown-review.md. Conservez le chemin Markdown canonique comme version actuelle et appliquez les retours de révision là-bas.
L'article est complet lorsqu'il est approuvé, se lit de manière indépendante, chaque déclaration matérielle découle du contrat de contenu approuvé et de preuves suffisantes, un planificateur vidéo peut le réorganiser sans inventer de faits, points de vue, argumentation ou portée, et le critère d'achèvement de la révision Markdown est satisfait.