Générateur de Plans de Cours Skill 2.2.1
Seule spécification comportementale complète de cette compétence. Les autres points d'entrée de l'agent doivent d'abord lire ce fichier et 通用提示词.md, sans copier un autre ensemble de champs ou règles de génération. Prend actuellement en charge Windows et macOS. Le modèle est responsable de la compréhension des données et de la production du contenu complet JSON 2.2 ; Python est uniquement responsable de la validation déterministe, du formatage et du mappage des modèles, et ne peut pas remplacer le modèle pour la rédaction du corps du texte. 2.2.1 est une version de correction du contrat de livraison Leçon / Fiche de Travail, ne modifie pas le modèle Word, l'algorithme de qualité du corps du texte ou le contrat de notation de la Fiche de Travail.
Point d'entrée de la tâche et Intake Runtime 2.1.1
Au début de la tâche, lisez d'abord la session en cours, les fichiers téléchargés par l'utilisateur et les données de cours disponibles : cartographie des compétences, décomposition des tâches des chapitres, normes de cours, catalogue des manuels, anciens plans de cours et modèle Word spécifié par l'utilisateur. Avant la planification formelle, vous DEVEZ entrer dans l'état INTAKE_PENDING, organiser la compréhension actuelle en une confirmation centralisée et entièrement en chinois des informations de base du cours ; même si les informations ont déjà été déduites de la session ou des pièces jointes, vous devez les afficher et demander une confirmation à l'utilisateur une fois. Après confirmation, entrez dans l'état INTAKE_CONFIRMED et commencez directement la recherche de données, le plan de cours au niveau du cours, Content 2.2, QA et DOCX.
L'interface utilisateur utilise uniquement des étiquettes en chinois, sans utiliser les noms de champs internes comme contenu des questions. Le socle de cours obligatoire pour une confirmation unique est : nom du cours, spécialité, public visé, nombre total d'heures. Le résumé de confirmation DOIT également inclure les informations non bloquantes suivantes : heures théoriques, heures pratiques, mode d'organisation théorie-pratique, durée par leçon par défaut de 2 heures, manuel utilisé, références auxiliaires, et si des fiches de travail pratiques doivent être générées simultanément.
Lorsque des informations manquent dans les quatre champs principaux, affichez "À compléter" dans le même résumé de confirmation ; le nombre total d'heures ne peut accepter que les faits clairement fournis par l'utilisateur. Si la spécialité ou le public visé n'est qu'une déduction de l'Agent, il DOIT être marqué "Compréhension actuelle / Veuillez corriger si inexact". Lorsque la répartition théorie/pratique, le mode d'organisation ou la préférence pour les fiches de travail pratiques ne sont pas clairement fournis, il DOIT afficher "À confirmer", sans les compléter automatiquement avec 50/50, mode intégré ou "non". default_hours=2 ne peut être utilisé que pour expliquer combien de séances sont estimées sur la base de 2 heures, et ne peut pas être utilisé pour déduire le ratio théorie/pratique. Le mappage des champs internes et les règles d'état sont décrits dans docs/intake-contract-v2.1.1.json ; l'interface utilisateur affiche uniquement "Références auxiliaires", l'état interne utilise toujours auxiliary_references, et cette clé anglaise ne doit pas être utilisée comme question utilisateur.
La première réponse devrait ressembler à :
Je confirme d'abord les informations de base du cours :
- Nom du cours : « Structures de données avancées »
- Spécialité : Compréhension actuelle / Veuillez corriger si inexact
- Public visé : Compréhension actuelle / Veuillez corriger si inexact
- Nombre total d'heures : 40 heures
- Heures théoriques : À confirmer
- Heures pratiques : À confirmer
- Mode d'organisation théorie-pratique : À confirmer (options : Tout théorique / Tout pratique / Organisation par segments / Organisation intégrée)
- Durée par leçon : Par défaut 2 heures
- Manuel utilisé : Non spécifié (si vous avez un manuel spécifique, veuillez me le dire ; on peut continuer sans)
- Références auxiliaires : Non spécifié
- Générer simultanément des fiches de travail pratiques : À confirmer
Ces informations sont-elles correctes ? Si des ajustements sont nécessaires, veuillez me les indiquer en une seule fois.
Le manuel est recommandé, pas obligatoire : s'il est fourni, affichez directement le fichier ou le titre ; s'il n'est pas fourni, cela ne bloque pas la génération. Lorsque practice_work_orders n'est pas fourni, maintenez-le à "À confirmer" ; ne décidez de lier la compétence WorkOrder qu'après le choix explicite de l'utilisateur. Si le choix explicite est false, les heures pratiques sont toujours incluses dans le total des heures de cours, mais aucun contrat de tâche pratique, handoff, WorkOrder ou fichier supplémentaire côté pratique n'est généré. Si le choix explicite est true, l'Agent de Leçon, après avoir terminé la QA de la Leçon/DOCX et le handoff du contrat de tâche pratique, détecte et appelle la compétence WorkOrder disponible, qui est consommée par l'Agent WorkOrder pour créer le contenu complet V1, exécuter la QA et générer les fiches de travail, le tout livré de manière unifiée ; si elle n'est pas disponible, livrez uniquement la Leçon et le handoff, avec le message clair Le générateur de fiches de travail pratiques est actuellement indisponible. Les données des tâches pratiques ont été enregistrées dans un fichier. Vous pouvez continuer la génération lorsque le générateur de fiches de travail sera disponible., sans falsifier les fiches de travail DOCX.
Tant que l'Intake n'est pas confirmé, ne déterminez pas le nombre ou les noms des projets, la structure des séances théorie/pratique, le nombre de tâches pratiques, le contenu pédagogique de chaque leçon, ou ne générez pas de DOCX. Après une confirmation, ne demandez plus le plan, les noms de projets, les tâches de chaque leçon, l'évaluation, le modèle, le répertoire de sortie ou "Voulez-vous commencer la génération du DOCX ?". Utilisez directement le modèle par défaut et les règles de sortie par défaut. Ne vous arrêtez à nouveau que si l'utilisateur change activement ses exigences, s'il y a un conflit direct et insoluble dans les informations confirmées, ou si une décision de l'utilisateur est nécessaire pour des raisons de sécurité ou de chevauchement de fichiers.
Si l'utilisateur choisit explicitement "Tout théorique", normalisez en theory_hours=total_hours, practice_hours=0, delivery_mode=theory_only, et définissez les fiches de travail pratiques sur false ; si l'utilisateur choisit explicitement "Tout pratique", normalisez en theory_hours=0, practice_hours=total_hours, delivery_mode=practice_only. Pour les autres répartitions, vous devez avoir theory_hours + practice_hours = total_hours ; si ce n'est pas le cas, signalez d'abord le conflit et ne commencez pas le plan.
Pour la recherche de données, privilégiez les manuels/données de cours fournis par l'utilisateur et le manuel spécifié par l'utilisateur ; lorsque vous avez une capacité de connexion réseau, recherchez ensuite les pages officielles des éditeurs ou des écoles, les normes/guides, la documentation technique officielle et la littérature publique vérifiable. Si seul le titre du livre est donné, vous ne pouvez écrire que les informations vérifiées réellement (auteur, éditeur, ISBN, édition ou année) ; si le réseau n'est pas disponible, continuez normalement, sans interrompre la génération à cause de l'absence de réseau.
- Après avoir autorisé l'utilisateur à faire des déductions raisonnables, complétez les projets, les tâches, le contenu pédagogique, l'évaluation et la réflexion pré-générée en fonction de l'enseignement par projet ;
- Le DOCX final ne doit pas contenir de descriptions internes telles que "données insuffisantes", "déduction", "IA", "QA", "similarité", "confiance".
Même sans données de tâche, vous devez d'abord former un plan au niveau du cours, puis générer le contenu leçon par leçon. Le plan doit au moins inclure lesson_id, unit, task, lesson_type, hours, theory_hours, practice_hours, prior_learning, capability_stage, deliverable, next_bridge et practice_task_ids. Les cours longs peuvent être générés par lots internes de 4 à 6 leçons, mais la QA finale doit utiliser le contexte complet du cours.
Contrat de Contenu V2.2
Le modèle par défaut est assets/templates/lesson-plan/v1.1.2/template.docx.
L'entrée de production formelle par défaut est content_contract_version: "2.2", indépendante de la version du modèle Word ; compatible en lecture avec "2.1" et "2.0". Le modèle Word par défaut est lesson-plan v1.1.2, et continue de prendre en charge les anciens chemins de modèles v1.0 legacy-coordinate, v1.1.0/v1.1.1 semantic-bookmark et compatibility ; le JSON sparse ancien n'est plus produit.
Champs obligatoires au niveau du cours :
content_contract_version, course_name, major, audience,
default_hours, total_hours, delivery_plan, course_materials,
reference_pool, artifact_plan, outline, lessons
Chaque séance théorique 2.2 doit fournir directement :
lesson_id, unit, task, lesson_type, hours, theory_hours, practice_hours,
progression, reference_ids, practice_task_ids,
student_analysis, teaching_content, goals,
key_point, difficult_point, teaching_methods, resources,
implementation, evaluation, reflection
L'entrée 2.0 lit toujours l'objet references dans les séances ; l'entrée compatible 2.1 conserve la sémantique originale des séances. 2.2 sélectionne les sources uniquement via les reference_ids du reference_pool au niveau du cours, et chaque Leçon théorique a au moins 1 référence. Le DOCX de Leçon 2.2 ne contient que la théorie : sum(lesson.hours) == theory_hours, toutes les Leçons ont lesson_type=theory, practice_hours=0 ; la pratique n'entre pas dans le DOCX de Leçon. Ce n'est que lorsque artifact_plan.practice_work_orders=true que la pratique entre dans le Contrat de Tâche Pratique / handoff WorkOrder ; lorsqu'il est false, aucun contrat ou ID de tâche ne doit être transporté, practice_task_ids ne conserve qu'un tableau vide requis par le schéma. practice_task_ids indique les tâches pratiques associées à la séance théorique, et non qu'il faut générer un DOCX de Leçon pratique. delivery_plan prend en charge theory_only, practice_only, split_lessons, integrated_lessons, hybrid, et theory_hours + practice_hours == total_hours. integrated décrit uniquement l'organisation intégrée théorie-pratique au niveau de l'artefact, sans intégrer les heures pratiques dans le DOCX de Leçon, et ne fixe pas 1+1.
default_hours est la durée par leçon par défaut utilisée par l'Agent pour chaque leçon ; hours explicitement fourni pour une leçon peut le remplacer, default_hours n'est pas nécessairement égal à la somme de tous les lessons.hours. default_hours, total_hours et hours de chaque leçon DOIVENT être des nombres entiers positifs d'heures : les valeurs numériques peuvent être 1, 2, 4, 12, etc., les chaînes peuvent être "1", "2", "2.0" ; les chaînes vides, fractions, zéro, nombres négatifs, NaN ou Infinity ne sont pas acceptés. unit utilise un nom de projet (par exemple "Projet 1...") ; progression inclut prior_lesson_id, prior_learning spécifique, capability_stage, deliverable et next_bridge. capability_stage ne peut utiliser que 认知 (cognition), 理解 (compréhension), 模仿 (imitation), 独立 (autonomie), 综合 (synthèse), 优化 (optimisation), 迁移 (transfert), sans exiger une progression linéaire mécanique. Le prior_lesson_id de la première leçon DOIT être null, les leçons suivantes ne peuvent référencer que des leçons précédentes déjà apparues. Pour quatre leçons ou plus, tous les stades de capacité ne peuvent pas être identiques.
student_analysis doit avoir au moins deux éléments pour base/problems/strategies, les trois types de goals doivent avoir au moins deux éléments, teaching_content au moins trois éléments, key_point et difficult_point doivent chacun avoir content et strategy, methods au moins deux éléments, resources au moins deux éléments. Les reference_ids d'une Leçon théorique 2.2 ne doivent pas être vides ; une référence vide échoue directement. Un cours purement pratique peut ne pas avoir de DOCX de Leçon ; les heures pratiques ne doivent être exprimées via un handoff de tâche pratique que si la génération de fiches de travail pratiques est explicitement choisie, et aucun handoff ne doit être créé si la génération n'est pas explicitement demandée, et des séances théoriques fictives ne doivent pas être créées.
Pour chaque leçon, implementation DOIT être fourni complètement dans l'ordre fixe des neuf ID suivants, et chaque phase doit avoir label, minutes, modality, content, teacher_actions, student_actions et objective tous issus du JSON :
before_class_preparation
task_introduction
operation_demonstration
task_implementation
task_extension
project_practice
peer_review
lesson_summary
after_class_improvement
La préparation avant le cours et l'amélioration après le cours sont des phases extrascolaires ; les minutes des sept phases intermédiaires DOIVENT strictement être égales à hours * 45. Chaque phase extrascolaire peut avoir 0 minute, mais ne peut pas dépasser max(60, hours * 45), et le total des deux phases extrascolaires ne peut pas dépasser 2 * hours * 45 ; les erreurs doivent indiquer l'ID de la leçon, la phase, la valeur réelle et la limite. operation_demonstration est un emplacement sémantique, qui peut être affiché comme démonstration de méthode, analyse de cas ou démonstration de compétence dans des cours comme les soins infirmiers, la comptabilité ou la mécanique.
L'évaluation DOIT fournir explicitement un evaluation.score entre 85 et 96, avec un pas de 0,5, et fournir des remarks pour chaque leçon pour les 13 ID de critères canoniques. Chaque remarque doit avoir un contenu substantiel ; toutes les versions du modèle Content V2 appliquent uniformément une limite de contrat de 48 caractères significatifs maximum, et le manifest peut seulement resserrer cette limite. En cas de dépassement, l'échec doit être signalé sans tronquer. Si aucun score n'est spécifié, il est suggéré de se concentrer naturellement entre 88 et 94, mais tous les scores ne doivent pas être de 90, ni former des cycles courts, ni être strictement croissants ou décroissants. score_breakdown() est uniquement responsable de la répartition déterministe du score total explicite dans les lignes du tableau existant ; Python ne crée pas de remarques, n'utilise pas trois séries fixes de remarques cycliques ou de repli mécanique de score. La réflexion DOIT fournir explicitement summary, innovation et improvement, et peut être pré-générée avant le cours, mais doit être différente en fonction des tâches de la leçon, des points clés, de l'organisation, des performances attendues, des problèmes et du lien avec la leçon suivante.
course_materials.textbook dans 2.2 représente le manuel seul, peut être un objet ou null ; par défaut, il n'est pas automatiquement écrit dans la cellule references du Word. Avant de générer leçon par leçon, l'Agent forme d'abord le concept de planification course_reference_pool / reference_catalog, le champ écrit est toujours reference_pool, pas un nouveau champ de contrat JSON. Chaque entrée doit avoir reference_id, reference_type, un titre spécifique identifiable, source_kind, source_region (domestic/foreign/unknown) et des preuves correspondantes ; seule reference_ids est écrit leçon par leçon. allow_textbook_as_reference est false par défaut, et le manuel n'est autorisé à entrer dans les references que si explicitement true. references représentent uniquement les sources de littérature/documents qui peuvent être lues, consultées, citées ou utilisées comme base du cours, y compris les monographies, les normes d'enseignement/de cours, les normes nationales/sectorielles/professionnelles, les guides/normes, les articles, la littérature publique, la documentation technique officielle, les manuels de produits officiels et les documents pédagogiques formels fournis par l'utilisateur. resources représentent les outils, équipements, environnements et matériaux utilisés lors de la mise en œuvre de l'enseignement, tels que MySQL Workbench, serveur de base de données, PPT, projecteur, modèle de soins, machine virtuelle, feuilles de tâches pratiques et ensembles de données de cas ; ceux-ci ne doivent pas être écrits dans references pour atteindre un quota. Chaque leçon choisit généralement 1 à 3 références, et les références valides au niveau du cours peuvent être réutilisées.
source_kind conserve provided, generic, verified_public ; provided nécessite des preuves matérielles réelles de l'utilisateur, verified_public nécessite une URL ou une source officielle localisable, generic ne peut utiliser qu'une sémantique de document spécifique et ne peut pas falsifier des informations bibliographiques détaillées. Les textes génériques tels que "Documents publics pertinents sur le langage de modélisation unifié", "Ressources réseau pertinentes", "Littérature publique pertinente" sont interdits, ainsi que la devinette de l'auteur, de l'ISBN, de l'éditeur, de l'édition, de l'année ou du numéro de norme. Les sources nationales sont prioritaires : données fournies par l'utilisateur, publications/monographies nationales, données d'établissements d'enseignement supérieur nationaux, normes nationales/sectorielles/professionnelles et documents officiels nationaux sont prioritaires par rapport aux classiques étrangers ; une proportion nationale inférieure à 70 % est un avertissement de qualité, pas un échec dur, et des sources étrangères peuvent être ajoutées en cas de normes/classiques internationaux ou de pénurie de sources nationales. La duplication complète des références entre les leçons est autorisée et relève de reference_reusable, et sort explicitement de l'échec dur anti-duplication exact/item/sentence/field/structural/frequency/whole-course ; la duplication d'ID ou de contenu au sein d'une même leçon reste un échec dur. La duplication des références n'est pas considérée comme un problème de duplication du corps du plan de cours. Il est interdit d'inventer des manuels, auteurs, ISBN, éditeurs, numéros de normes ou littérature publique différents pour réduire le taux de duplication du cours ; répéter le même manuel 18 fois est préférable à l'invention de 18 manuels différents. Les preuves sont utilisées uniquement pour l'entrée et la QA ; le DOCX n'écrit que le texte de citation formel, pas les métadonnées de preuve.
Contrat de Tâche Pratique V1
Uniquement lorsque artifact_plan.practice_work_orders=true, l'entrée 2.2 DOIT fournir practice_task_contract, avec la version 1.0, granularity: "per_task". Les heures pratiques DOIVENT être des nombres positifs pairs ; les champs de la tâche sont task_id, project_id, title, lesson_ids, practice_hours, scenario, objectives, required_inputs, tools_or_materials, steps, deliverables, acceptance_criteria, safety_or_compliance. Chaque tâche pratique est fixée à 2 heures, le nombre de tâches est strictement égal à practice_hours / 2 ; chaque tâche correspond à une WorkOrder, project_id est utilisé uniquement pour le regroupement, la granularité ne peut pas être re-planifiée. lesson_ids sont les ID des Leçons théoriques fournissant la préparation théorique/les connaissances préalables, et peuvent s'étendre sur plusieurs leçons ; pour un cours purement pratique sans Leçon théorique, il s'agit d'un tableau vide. Lorsque practice_work_orders=false, aucun contrat ou handoff n'est autorisé, tous les practice_task_ids DOIVENT rester des tableaux vides. Lorsqu'il est true, la Leçon est uniquement responsable de la génération et de la QA du handoff canonique, qui est ensuite consommé par la compétence WorkOrder détectée via l'orchestration de l'Agent ; le générateur Python de la Leçon ne doit pas appeler le Python de la WorkOrder via subprocess, ni mapper automatiquement en corps de fiche de travail. Lorsque la compétence WorkOrder n'est pas disponible, seul le handoff practice-task-contract.json est produit, avec l'état indisponible clairement indiqué, sans falsifier de fiche de travail pratique DOCX.
Les règles complètes actuelles de 2.2 se trouvent dans docs/content-contract-v2.md ; examples/tasks-v21.example.json est conservé comme exemple compatible 2.1, examples/tasks.example.json comme exemple compatible 2.0. Les descriptions des champs se trouvent dans docs/content-contract-v2.md et docs/practice-task-contract-v1.md, les contraintes machine dans schemas/lesson-plan-input.schema.json et le schemas/shared/practice-task-contract.schema.json canonique du dépôt ; schemas/practice-task-contract.schema.json n'est qu'un point d'entrée de compatibilité.
Frontière entre Python et l'Agent
L'Agent est responsable de la planification au niveau du cours et de tout le contenu pédagogique leçon par leçon ; le générateur fait uniquement la validation du schéma, la numérotation, les sauts de ligne, le formatage des minutes, le mappage des champs et l'écriture dans le modèle. Le chemin formel V2 ne doit pas appeler les anciens generated_lesson_fields, implementation_cell_values, reflection_cell_values, ni utiliser flows[:3] ou créer du contenu basé sur des champs manquants. Si le contenu dépasse max_chars ou max_paragraphs du manifest, l'échec DOIT être signalé en indiquant la leçon, le champ, le nombre réel de caractères et la limite, sans tronquer ni supprimer silencieusement.
Ordre de génération et de QA
Lecture des données → Confirmation unique des informations de base du cours
-> Plan du cours
-> JSON Content V2.2
-> QA du contrat d'entrée
-> QA de la qualité du contenu
-> QA du modèle
-> Génération du DOCX candidat
-> QA de la structure de sortie + fidélité Contenu-à-DOCX
-> Validation visuelle optionnelle via LibreOffice
-> Validation atomique dans le répertoire final et rapport QA externe
-> Lorsque practice_work_orders=true, détection et appel de l'Agent de la compétence WorkOrder, puis livraison unifiée Leçon + WorkOrder
-> Inspection visuelle de la page représentative par l'Agent
Utilisez scripts/generate_lesson_plans.py pour la génération. Tous les DOCX sont d'abord écrits dans un répertoire candidat, de même parent que le répertoire formel ; ce n'est qu'après avoir passé la QA du contenu, la QA du modèle, la protection de la structure de sortie/signets/format, la QA de la fidélité du contenu et la validation visuelle demandée qu'ils sont permutés dans le répertoire formel. Avec l'option explicite --qa-report, le rapport externe est d'abord placé dans un répertoire de staging de même parent, et soumis avec le répertoire de sortie ; si l'une ou l'autre permutation échoue, les anciens répertoires de sortie et de rapport sont restaurés. Un répertoire formel non vide nécessite --backup-existing ; si la permutation échoue, l'ancien répertoire doit être restauré. Après une soumission réussie, stdout ne rapporte que les chemins des DOCX réellement présents dans le répertoire formel. Après la confirmation des informations de base du cours, aucune confirmation supplémentaire n'est ajoutée pour la génération du DOCX ; l'inspection visuelle de la page représentative par l'Agent est une validation après soumission ; si des débordements, des troncations, des sauts de page anormaux ou des pages blanches sont détectés, le contenu V2 doit être réécrit et la génération transactionnelle relancée avec --backup-existing. qa-report.json écrit uniquement le rapport, pas dans le DOCX.
Le scripts/content_quality.py indépendant DOIT s'exécuter de manière déterministe en local, sans appeler d'API en ligne, d'embedding ou de service de modèle. Il vérifie la duplication du corps du texte existant, la similarité structurelle après masquage des entités, les phrases longues dupliquées, les clichés anciens, l'exhaustivité, la cohérence intra-leçon, la cohérence de progression, les motifs de scores, la densité des remarques des 13 critères d'évaluation et la contamination non IT. Cette itération ajoute uniquement la vérification des références obligatoires 2.2, les statistiques de source_region et la vérification du handoff théorie/pratique, sans modifier les algorithmes existants de répétition, progression, notation ou cohérence d'implémentation. non_it_contamination et ses métadonnées de scope détectent uniquement les mots par défaut IT qui sont injectés dans la sortie mais qui ne proviennent pas de l'entrée, du modèle ou du générateur, et ne sont pas un classifieur de cours générique. Le diagnostic ne conserve que des fragments limités et un SHA-256 stable, sans produire le corps entier du texte utilisateur. Tous les détecteurs partagent une politique de réutilisation unique : narrative_strict, terminology_reusable, resource_reusable, reference_reusable, fixed_rubric_reusable et ignore. Les méthodes pédagogiques, les ressources nécessaires, les références légitimes et les rubriques fixes de présence/conformité/habitudes peuvent enregistrer des preuves de réutilisation sans échec dur ; la duplication complète des références entre les leçons est autorisée et sort explicitement de l'échec dur anti-duplication exact/item/sentence/field/structural/frequency/whole-course ; la duplication exacte au sein d'une même leçon et les références purement outils/équipements évidentes DOIVENT échouer durement. L'exemption terminologique pour les cours courts ne doit pas pénétrer dans les champs narratifs. Il ne faut pas inventer de références bibliographiques pour réduire le taux de duplication du cours.
L'héritage d'artefact et la transition avant de la progression DOIVENT tous deux passer à la fois par des preuves lexicales/cohérence et des preuves de substantive_anchor ; les actions génériques telles que "conception, opération, analyse, vérification, processus, mise en œuvre" ne peuvent pas servir d'ancre indépendamment. prior_lesson_id non adjacent est toujours autorisé ; si la chaîne d'ordre physique est review, le rapport DOIT définir requires_agent_review=true et lister from/to/reason/score/declared_prior. La validation finale de l'Agent ne peut pas ignorer silencieusement l'examen de la séquence physique ; si l'ordre réel d'enseignement ne peut pas être expliqué, la progression doit être réécrite.
Après avoir passé la QA déterministe et effectué la soumission atomique, l'Agent doit également effectuer une révision interne leçon par leçon : qu'est-ce que cette leçon ajoute par rapport à la précédente, quelles connaissances ou résultats de la leçon précédente utilise-t-elle, quels résultats produit-elle, et comment la leçon suivante utilisera-t-elle ces résultats. Cette révision n'est pas écrite dans le DOCX. Lorsque --render est demandé, le rapport Python indique uniquement render.scope=smoke, et la méthode de comptage des pages est pdf_page_object_regex légère ; elle n'équivaut pas à une QA visuelle ou à une vérification de pagination, et ne prouve pas l'absence de débordement, de troncature, de sauts de page anormaux ou de déformation des tableaux. L'Agent doit vérifier la première leçon, la leçon la plus dense en contenu, la dernière leçon, et pour les cours de 12 heures ou plus, vérifier également 1 à 2 leçons intermédiaires, en surveillant le clipping, l'overflow, l'overlap, les pages blanches, la hauteur de ligne anormale et les limites des tableaux. Après une vérification réelle, utilisez scripts/record_visual_inspection.py pour écrire explicitement un visual-inspection.json indépendant ; ce fichier enregistre les pages représentatives, les vérifications, les notes, le qa-report associé, l'empreinte de sortie et l'horodatage. Python ne prétend pas automatiquement que la vérification visuelle est réussie. En cas d'échec visuel, le JSON V2 doit être modifié et une nouvelle génération transactionnelle effectuée avec --backup-existing, puis une nouvelle vérification.
La QA de sortie par défaut lit le JSON V2 original, calcule l'attendu via un formateur pur, puis le compare aux signets sémantiques ou aux coordonnées v1.0 ; elle ne rappelle pas la fonction de création de contenu pédagogique. La mise en page du modèle, les 70 signets sémantiques, les IDs/noms des signets, l'empreinte, la compatibilité v1.0/v1.1 et le binaire canonique sont tous protégés. Si LibreOffice est présent sur la machine, utilisez --render pour effectuer une validation visuelle légère ; sans renderer, la QA structurelle réussit quand même, le rapport marque render.status=not_executed. Les conclusions réelles sur la pagination, les débordements et la mise en page visuelle proviennent uniquement de la vérification des pages représentatives par l'Agent.
L'installation de l'adaptateur est sémantiquement fixée comme suit : par défaut, instruction-only adapter install（仅规则/指令安装）, qui installe uniquement les règles du projet et les instructions minimales, sans copier l'intégralité de l'environnement d'exécution ni garantir que le projet cible peut exécuter le générateur de manière autonome ; ce n'est qu'avec l'ajout de --copy-engine qu'il s'agit d'un full runnable project-local Lesson engine（完整可运行引擎）. Le projet cible doit utiliser --copy-engine s'il doit appeler directement .lesson-plan-docx-generator/scripts/generate_lesson_plans.py. visual-inspection.json est un Agent visual inspection attestation for the current generated DOCX/QA state, indiquant la vérification par l'Agent des pages représentatives de l'état actuel du DOCX/QA généré, et non une preuve cryptographique du PDF/image vérifié.
La vérification préliminaire des chemins (preflight) est effectuée avant mkdir, génération, déplacement, sauvegarde et suppression, protégeant la racine de la compétence, le JSON d'entrée, le schéma, le modèle sélectionné/personnalisé, le manifest, le package canonique/de compatibilité, les scripts et les tests, et rejetant les chemins ancêtres, descendants, les liens symboliques résolus et les chevauchements d'alias lexicaux/8.3 sur Windows. N'écrivez pas la sortie dans des répertoires protégés ou des packages de modèles personnalisés.
Commandes
Windows :
python scripts/generate_lesson_plans.py `
--tasks-json tasks.json `
--output-dir output `
--render
macOS :
python3 scripts/generate_lesson_plans.py \
--tasks-json tasks.json \
--output-dir output \
--render
Validation seule de la sortie :
scripts/validate_template.py --json
scripts/validate_output.py --input-json tasks.json --output-dir output --render
scripts/validate_visual_inspection.py --output-dir output --qa-report output/qa-report.json --evidence output/visual-inspection.json
Installation manuelle et vérification des dépendances (l'installateur ne modifie pas automatiquement l'environnement Python) :
python scripts/install.py --skills-dir <skills-dir>
python <skills-dir>\lesson-plan-docx-generator\scripts\check_dependencies.py
check_dependencies.py vérifie en lecture seule docx, yaml, jsonschema ; en cas d'absence, il invite à exécuter pip install -r requirements.txt. Le flux de production de l'Agent interdit l'utilisation de --skip-template-validation ou --skip-output-validation ; ces deux paramètres de compatibilité ne peuvent être utilisés pour des tests contrôlés que si LESSON_ALLOW_UNSAFE_VALIDATION_SKIP=1 est défini explicitement, et doivent être clairement marqués comme skipped dans le rapport. Le contrat d'entrée, la qualité du contenu et la protection des chemins ne peuvent pas être ignorés. Les fichiers JSON temporaires, PDF, images et le répertoire candidat sont nettoyés après la fin de la tâche, seul le DOCX généré est soumis.
Fichiers de modèle
assets/templates/lesson-plan/v1.1.2/template.docx
assets/templates/lesson-plan/v1.1.2/manifest.yaml
assets/templates/lesson-plan/v1.1.1/template.docx
assets/templates/lesson-plan/v1.1.1/manifest.yaml
assets/templates/lesson-plan/v1.0.0/template.docx
assets/templates/lesson-plan/v1.0.0/manifest.yaml
schemas/lesson-plan-input.schema.json
scripts/content_contract.py
scripts/content_quality.py
scripts/generate_lesson_plans.py