Generador de Planes de Clase Skill 2.2.1
Única especificación de comportamiento completa de este Skill. Otros puntos de entrada del agente solo deben leer este archivo y 通用提示词.md (Prompt Genérico.md), sin copiar otro conjunto de campos o reglas de generación. Actualmente compatible con Windows y macOS. El modelo es responsable de comprender los materiales y producir el JSON completo de Content 2.2; Python solo se encarga de la validación determinista, el formateo y el mapeo de plantillas, y no puede reemplazar al modelo en la creación del cuerpo del texto. La versión 2.2.1 es una revisión del contrato de entrega de Lección / Orden de Trabajo (WorkOrder), y no modifica la plantilla de Word, el algoritmo de calidad del cuerpo del texto ni el contrato de evaluación de la Orden de Trabajo.
Punto de Entrada de la Tarea y Entorno de Ejecución (Intake Runtime 2.1.1)
Al inicio de la tarea, primero se leen la sesión actual, los archivos subidos por el usuario y los materiales del curso disponibles: mapa de capacidades, desglose de tareas por capítulo, estándares del curso, índice del libro de texto, planes de clase antiguos y la plantilla de Word especificada por el usuario. Antes de la planificación formal, se debe entrar en el estado INTAKE_PENDING, organizando la comprensión actual en una confirmación centralizada y completamente en chino de la información básica del curso; incluso si la información ya se ha inferido de la sesión o los archivos adjuntos, se debe mostrar y solicitar confirmación al usuario una vez. Una vez confirmado, se entra en INTAKE_CONFIRMED, y se comienza directamente con la búsqueda de materiales, el esquema a nivel de curso, la generación de Content 2.2, QA y DOCX.
La interfaz de usuario solo utiliza etiquetas en chino, y no se deben usar los nombres de campos internos como contenido de las preguntas. Los elementos básicos obligatorios del curso para una confirmación única son: Nombre del Curso, Especialidad, Público Objetivo y Horas Totales. El resumen de confirmación también debe incluir la siguiente información no bloqueante: Horas Teóricas, Horas Prácticas, Método de Organización Teórico-Práctico, Horas por Clase (por defecto 2 horas académicas), Libro de Texto Utilizado, Materiales de Referencia Auxiliares y si se generan simultáneamente Órdenes de Trabajo de Tareas Prácticas.
Cuando falte información en los cuatro campos principales, se mostrará "Pendiente de completar" en el mismo resumen de confirmación; el total de horas solo puede aceptar el hecho proporcionado explícitamente por el usuario. Si la especialidad o el público objetivo son solo inferencias del Agente, se debe marcar con "Entendimiento actual / Si es incorrecto, modifíquelo". Cuando la división teoría/práctica, el método de organización o la preferencia por órdenes de trabajo de tareas prácticas no se hayan proporcionado explícitamente, se debe mostrar "Pendiente de confirmar", sin completar automáticamente como 50/50, modo integrado o "No". default_hours=2 solo se utiliza para explicar cuántas sesiones de clase se estiman aproximadamente basándose en 2 horas académicas, y no se puede usar para inferir la proporción teoría/práctica. El mapeo de campos internos y las reglas de estado se encuentran en docs/intake-contract-v2.1.1.json; la interfaz de usuario solo muestra "Materiales de Referencia Auxiliares", mientras que el estado interno sigue usando auxiliary_references, y no se debe usar esta clave en inglés como pregunta para el usuario.
La primera respuesta debería ser similar a:
Permíteme confirmar primero la información básica del curso:
- Nombre del Curso: «Estructuras de Datos Avanzadas»
- Especialidad: Entendimiento actual / Si es incorrecto, modifíquelo
- Público Objetivo: Entendimiento actual / Si es incorrecto, modifíquelo
- Horas Totales: 40 horas académicas
- Horas Teóricas: Pendiente de confirmar
- Horas Prácticas: Pendiente de confirmar
- Método de Organización Teórico-Práctico: Pendiente de confirmar (Opciones: Todo teoría / Todo práctica / Organización por segmentos / Organización integrada)
- Horas por Clase: 2 horas académicas por defecto
- Libro de Texto Utilizado: No especificado (Si tiene un libro de texto designado, por favor indíquemelo; si no, podemos continuar igualmente)
- Materiales de Referencia Auxiliares: No especificados
- ¿Generar simultáneamente Órdenes de Trabajo de Tareas Prácticas?: Pendiente de confirmar
¿Es correcta la información anterior? Si necesita ajustes, por favor indíquemelo de una sola vez.
El libro de texto es recomendado, no obligatorio: si se ha proporcionado un archivo o el nombre del libro, se muestra directamente; si no se ha proporcionado, no bloquea la generación. Cuando practice_work_orders no se ha proporcionado, se mantiene como pendiente de confirmar; solo después de que el usuario lo seleccione explícitamente se decide si se vincula el Skill de Orden de Trabajo. Cuando se selecciona explícitamente como false, las horas prácticas aún se contabilizan en las horas totales del curso, pero no se generan Contrato de Tarea Práctica, handoff, Orden de Trabajo ni archivos adicionales del lado práctico. Cuando se selecciona explícitamente como true, el Agente de Lección, después de completar el QA de la Lección/DOCX y el handoff del Contrato de Tarea Práctica, detecta e invoca el Skill de Orden de Trabajo disponible. El Agente de Orden de Trabajo crea el Contenido V1 completo, ejecuta QA y genera la Orden de Trabajo, y finalmente entrega todo de forma unificada. Si no está disponible, solo se entregan la Lección y el handoff, indicando claramente: El generador de órdenes de trabajo de tareas prácticas no está disponible actualmente. Se han guardado los archivos de datos de tareas prácticas. Se puede continuar la generación cuando el generador de órdenes de trabajo esté disponible., sin falsificar el DOCX de la Orden de Trabajo.
Hasta que no se confirme el Intake, no se debe determinar la cantidad o el nombre de los proyectos, la estructura de sesiones teóricas/prácticas, la cantidad de tareas prácticas, el contenido de enseñanza de cada lección ni generar DOCX; a menos que el usuario ya haya proporcionado los hechos correspondientes de forma explícita. Después de una confirmación, no se debe preguntar nuevamente sobre el esquema, nombres de proyectos, tareas de cada lección, evaluación, plantilla, directorio de salida o "si se debe comenzar a generar DOCX". La plantilla predeterminada y las reglas de salida predeterminadas se adoptan directamente. Solo se permite detenerse nuevamente si el usuario cambia activamente sus requisitos, si hay un conflicto directo que no se pueda resolver razonablemente en la información confirmada, o si se encuentra con asuntos que realmente requieren la decisión del usuario, como problemas de seguridad o sobrescritura de archivos.
Si el usuario selecciona explícitamente "Todo teoría", se normaliza a theory_hours=total_hours, practice_hours=0, delivery_mode=theory_only, y la opción de órdenes de trabajo de tareas prácticas se establece en falso. Si selecciona explícitamente "Todo práctica", se normaliza a theory_hours=0, practice_hours=total_hours, delivery_mode=practice_only. Otras divisiones deben cumplir theory_hours + practice_hours = total_hours; si no son iguales, primero se informa el conflicto y no se comienza con el esquema.
La búsqueda de materiales da prioridad a los materiales/libros de texto proporcionados por el usuario y los libros de texto designados por el usuario. Cuando haya capacidad de conexión a la red, también se pueden buscar páginas oficiales de editoriales o escuelas, estándares/guias, documentación técnica oficial y literatura pública verificable. Cuando solo se proporcione el nombre del libro, solo se pueden incluir el autor, la editorial, el ISBN, la edición o el año verificados de forma real. Cuando la red no esté disponible, se continúa normalmente sin interrumpir la generación por falta de conexión.
- Después de que el usuario permita una inferencia razonable, se completan proyectos, tareas, contenido de enseñanza, evaluación y reflexión pregenerada según la enseñanza basada en proyectos.
- En el DOCX final no deben aparecer explicaciones internas como "materiales insuficientes", "inferencia", "IA", "QA", "similaridad", "confianza", etc.
Incluso si no hay materiales de tarea, primero se debe formar un esquema a nivel de curso y luego generar el contenido de cada lección. El esquema debe contener al menos lesson_id, unit, task, lesson_type, hours, theory_hours, practice_hours, prior_learning, capability_stage, deliverable, next_bridge y practice_task_ids. Para cursos largos, se pueden generar internamente en lotes de 4 a 6 lecciones, pero finalmente se debe realizar un QA unificado con el contexto completo del curso.
Contrato de Contenido V2.2
Por defecto, se usa assets/templates/lesson-plan/v1.1.2/template.docx.
La entrada de producción formal por defecto es content_contract_version: "2.2", independiente de la versión de la plantilla de Word; en tiempo de ejecución es compatible con la lectura de versiones "2.1" y "2.0". La plantilla de Word por defecto es lesson-plan v1.1.2, y se sigue dando soporte a las rutas de plantillas heredadas v1.0 legacy-coordinate, v1.1.0/v1.1.1 semantic-bookmark y las antiguas de compatibilidad; ya no se produce JSON antiguo disperso.
Campos obligatorios a nivel de curso:
content_contract_version, course_name, major, audience,
default_hours, total_hours, delivery_plan, course_materials,
reference_pool, artifact_plan, outline, lessons
Cada sesión teórica de la versión 2.2 debe proporcionar directamente:
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
La entrada de la versión 2.0 sigue leyendo el objeto references dentro de la sesión; la entrada compatible con 2.1 conserva la semántica de la sesión original. La versión 2.2 solo selecciona la fuente a través de reference_ids del reference_pool a nivel de curso, y cada Lección teórica tiene al menos 1 referencia. El DOCX de Lección de la versión 2.2 solo contiene la teoría: sum(lesson.hours) == theory_hours, todas las Lecciones son de lesson_type=theory, practice_hours=0; la práctica no entra en el DOCX de Lección. Solo cuando artifact_plan.practice_work_orders=true, la práctica entra en el Contrato de Tarea Práctica / handoff de Orden de Trabajo; cuando es false, no se debe llevar ningún contrato o ID de tarea, y practice_task_ids solo mantiene el array vacío requerido por el esquema. practice_task_ids indica las tareas prácticas asociadas con la sesión teórica, no que se deba generar un DOCX de Lección práctica. delivery_plan soporta theory_only, practice_only, split_lessons, integrated_lessons, hybrid, y debe cumplir theory_hours + practice_hours == total_hours. integrated solo describe la organización integrada de teoría y práctica a nivel de artefacto, no mete horas prácticas en el DOCX de Lección ni fija 1+1.
default_hours son las horas académicas predeterminadas por sesión que usa el Agente al crear cada lección; si una lección proporciona explícitamente hours, puede anularlo. default_hours no requiere ser igual a la suma de todos los lessons.hours. default_hours, total_hours y hours de cada lección deben ser números enteros positivos de horas académicas: el valor numérico puede ser 1, 2, 4, 12, etc., y la cadena puede ser "1", "2", "2.0"; no se aceptan cadenas vacías, fracciones, cero, números negativos, NaN o Infinity. unit usa nombres basados en proyectos (por ejemplo, "Proyecto 1..."); progression contiene prior_lesson_id, prior_learning específico, capability_stage, deliverable, next_bridge. capability_stage solo puede usar 认知 (Cognitivo), 理解 (Comprensión), 模仿 (Imitación), 独立 (Independiente), 综合 (Integral), 优化 (Optimización), 迁移 (Transferencia), y no se requiere un incremento lineal mecánico. El prior_lesson_id de la primera lección debe ser null, y las lecciones posteriores solo pueden referenciar lecciones anteriores que ya hayan aparecido. En cuatro o más lecciones, no todas las etapas de capacidad pueden ser idénticas.
student_analysis debe tener al menos dos elementos en base/problems/strategies; los tres tipos de goals deben tener al menos dos elementos cada uno; teaching_content debe tener al menos tres elementos; key_point y difficult_point deben tener content y strategy; methods debe tener al menos dos elementos, y resources al menos dos. En la versión 2.2, los reference_ids de las Lecciones teóricas no pueden estar vacíos; una referencia vacía provoca un fallo directo. Un curso puramente práctico puede no tener Lecciones DOCX; solo cuando se selecciona explícitamente generar órdenes de trabajo prácticas se debe usar el handoff de la Tarea Práctica para expresar las horas prácticas; cuando se selecciona explícitamente no generar, no se crea el handoff y no se pueden inventar Lecciones teóricas.
La implementation de cada lección debe proporcionarse completamente en el siguiente orden fijo de nueve IDs, y cada etapa debe tener label, minutes, modality, content, teacher_actions, student_actions y objective provenientes del JSON:
before_class_preparation
task_introduction
operation_demonstration
task_implementation
task_extension
project_practice
peer_review
lesson_summary
after_class_improvement
before_class_preparation (preparación antes de clase) y after_class_improvement (mejora después de clase) son etapas extracurriculares. Los minutos de las siete etapas intermedias deben ser estrictamente iguales a hours * 45. Cada etapa extracurricular puede tener 0 minutos, pero no debe exceder max(60, hours * 45), y la suma de las dos etapas extracurriculares no debe exceder 2 * hours * 45; el error debe señalar el ID de la lección, la etapa, el valor real y el límite. operation_demonstration es un marcador de posición semántico; en cursos de enfermería, contabilidad, mecánica, etc., puede mostrarse como demostración de métodos, análisis de casos o demostración de habilidades.
La evaluación debe proporcionar explícitamente un evaluation.score entre 85 y 96, con pasos de 0.5, y proporcionar remarks (observaciones) para cada lección con los 13 IDs de criterio canónicos. Cada observación debe tener contenido sustancial. Todas las versiones de la plantilla de Content V2 ejecutan un límite de contrato de no más de 48 caracteres significativos; el manifiesto solo puede reducir aún más este límite; si se supera, debe fallar sin truncar. Cuando no se especifica una puntuación, se sugiere que se concentre naturalmente entre 88 y 94, pero no todas pueden ser 90, ni formar ciclos cortos arbitrarios, ni ser estrictamente crecientes o decrecientes. score_breakdown() solo se encarga de desglosar deterministamente la puntuación total explícita en las filas de la tabla existentes; Python no crea observaciones, no usa tres conjuntos fijos de observaciones en ciclo ni utiliza un fallback mecánico de puntuación. La reflexión debe proporcionar explícitamente summary, innovation e improvement; se permite la pregeneración antes de la clase, pero debe ser diferenciada en torno a la tarea de esta lección, los puntos clave y difíciles, la organización, el rendimiento esperado, los problemas y la conexión con la siguiente lección.
En la versión 2.2, course_materials.textbook representa el libro de texto de forma independiente, y puede ser un objeto o null; por defecto, no se escribe automáticamente en la celda de referencias del Word. Antes de generar cada lección, el Agente primero forma un concepto de planificación course_reference_pool / reference_catalog. El campo de almacenamiento sigue siendo reference_pool, no un nuevo campo de contrato JSON. Cada elemento debe tener reference_id, reference_type, un título específico identificable, source_kind, source_region (domestic/foreign/unknown) y la evidencia correspondiente; en cada lección solo se escriben reference_ids. allow_textbook_as_reference es false por defecto; solo cuando se establece explícitamente como true, el libro de texto puede entrar en las referencias. references solo representan fuentes de literatura/documentos que se pueden leer, consultar, citar o usar como base para el curso, incluyendo monografías, estándares de curso/enseñanza, estándares nacionales/institucionales/profesionales, guías/normas, artículos, literatura pública, documentación técnica oficial, manuales de productos oficiales y documentos de enseñanza formales proporcionados por el usuario. resources representan las herramientas, equipos, entornos y materiales utilizados en la implementación de la enseñanza, como MySQL Workbench, servidores de bases de datos, PPT, proyectores, modelos de enfermería, máquinas virtuales, hojas de tareas de formación y conjuntos de datos de casos; estos no se pueden escribir en references para inflar el número. Cada lección normalmente selecciona de 1 a 3 referencias, y las referencias legales a nivel de curso se pueden reutilizar.
source_kind sigue conservando provided, generic, verified_public; provided requiere evidencia de material real del usuario, verified_public requiere URL o fuente oficial localizable, generic solo puede usar una semántica de documento específica y no puede falsificar información bibliográfica detallada. Están prohibidos los textos de marcador de posición genéricos como "documentos públicos relacionados con el lenguaje de modelado unificado", "recursos de red relacionados", "literatura pública relacionada", y también está prohibido adivinar el autor, ISBN, editorial, edición, año o número de estándar. Se da prioridad a las fuentes nacionales: los materiales proporcionados por el usuario, las publicaciones/monografías nacionales, los materiales de instituciones de educación superior nacionales, los estándares nacionales/institucionales/profesionales y los documentos autorizados nacionales tienen prioridad sobre los clásicos extranjeros; una proporción nacional inferior al 70% solo es una advertencia de calidad, no un fallo duro. Si realmente hay estándares/clásicos internacionales o fuentes nacionales insuficientes, se pueden complementar con fuentes extranjeras. La repetición completa de referencias entre lecciones está permitida, pertenece a reference_reusable, y está explícitamente excluida de los fallos duros de anti-repetición a nivel exacto/elemento/oración/campo/estructural/frecuencia/curso completo; la repetición de ID o contenido dentro de la misma lección sigue siendo un fallo duro. La repetición de referencias no pertenece al problema de repetición del texto principal del plan de clase. Está prohibido inventar diferentes libros de texto, autores, ISBN, editoriales, números de estándar o literatura pública para reducir la tasa de repetición del curso; es mejor repetir el mismo libro de texto 18 veces que inventar 18 libros de texto. evidence solo se usa para la entrada y el QA; en el DOCX solo se escribe el texto de cita formal, no los metadatos de evidencia.
Contrato de Tarea Práctica V1
Solo cuando artifact_plan.practice_work_orders=true, la entrada de la versión 2.2 debe proporcionar practice_task_contract, con versión 1.0, granularity: "per_task". Las horas prácticas deben ser un número par positivo; los campos de la tarea son task_id, project_id, title, lesson_ids, practice_hours, scenario, objectives, required_inputs, tools_or_materials, steps, deliverables, acceptance_criteria, safety_or_compliance. Cada Tarea Práctica tiene fijamente 2 horas académicas, y el número de tareas es estrictamente igual a practice_hours / 2; cada tarea corresponde a una Orden de Trabajo, project_id solo se usa para agrupar, y no se puede replanificar la granularidad. lesson_ids son los IDs de las Lecciones teóricas que proporcionan preparación teórica/conocimientos previos, y pueden abarcar múltiples sesiones; cuando no hay Lecciones teóricas en un curso puramente práctico, es un array vacío. Cuando practice_work_orders=false, no se permite el contrato ni el handoff, y todos los practice_task_ids deben mantenerse como un array vacío. Cuando es true, la Lección solo es responsable de generar y realizar el QA del handoff canónico, y luego el Skill de Orden de Trabajo detectado consume el handoff a través de la orquestación del Agente; el generador Python de la Lección no debe invocar mediante subprocess el Python de la Orden de Trabajo, ni mapear automáticamente la orden de trabajo en el cuerpo del texto. Cuando el Skill de Orden de Trabajo no esté disponible, solo se genera el handoff practice-task-contract.json, y se indica claramente el estado de no disponible, sin falsificar el DOCX de la orden de trabajo práctica.
Las reglas completas actuales de la versión 2.2 se encuentran en docs/content-contract-v2.md; examples/tasks-v21.example.json se conserva como ejemplo compatible con la versión 2.1, y examples/tasks.example.json se conserva como ejemplo compatible con la versión 2.0. La descripción de los campos se encuentra en docs/content-contract-v2.md y docs/practice-task-contract-v1.md; las restricciones de la máquina se encuentran en schemas/lesson-plan-input.schema.json y en el canónico schemas/shared/practice-task-contract.schema.json del repositorio; schemas/practice-task-contract.schema.json es solo un punto de entrada de compatibilidad.
Límite entre Python y el Agente
El Agente es responsable de la planificación a nivel de curso y de todo el texto de enseñanza de cada lección; el generador solo realiza validación de esquema, numeración, saltos de línea, formato de minutos, mapeo de campos y escritura en la plantilla. La ruta formal de V2 no debe invocar los antiguos generated_lesson_fields, implementation_cell_values, reflection_cell_values, ni usar flows[:3] o crear texto basado en campos faltantes. Si el contenido supera max_chars o max_paragraphs del manifiesto, debe fallar e indicar la lección, el campo, los caracteres reales y el límite, sin truncar o eliminar silenciosamente.
Orden de Generación y QA
Leer materiales → Confirmación única de información básica del curso
-> Esquema del curso
-> Content V2.2 JSON
-> QA del Contrato de Entrada
-> QA de Calidad del Contenido
-> QA de la Plantilla
-> Generación del DOCX candidato
-> QA de la Estructura de Salida + Fidelidad Contenido-a-DOCX
-> Prueba de renderizado smoke opcional con LibreOffice
-> Commit atómico a la salida final y al informe QA externo
-> Cuando practice_work_orders=true, detectar e invocar al Agente del Skill de Orden de Trabajo, luego unificar la entrega de Lección + Orden de Trabajo
-> Inspección visual de la página representativa por parte del Agente
Usar scripts/generate_lesson_plans.py para generar. Todos los DOCX se escriben primero en un directorio candidato en el mismo directorio padre que el directorio formal; solo después de pasar el QA de contenido, QA de plantilla, protección de estructura de salida/marcadores/formato, QA de fidelidad de contenido y la prueba de renderizado smoke solicitada, se intercambian al directorio formal. Con --qa-report explícito, el informe externo primero se prepara en el mismo directorio padre y se confirma junto con el directorio de salida; si falla algún intercambio, se restauran la salida anterior y el informe anterior. Si el directorio formal no está vacío, se necesita --backup-existing; si falla el intercambio, se debe restaurar el directorio anterior. Después de una confirmación exitosa, stdout solo informa las rutas de los DOCX que realmente existen en el directorio formal. Después de la confirmación de la información básica del curso, no se agregan más confirmaciones para generar DOCX; la inspección visual de la página representativa por parte del Agente pertenece a la aceptación posterior a la confirmación; si se encuentran desbordamientos, truncamientos, paginación anormal o páginas en blanco, se debe reescribir el contenido V2 y usar --backup-existing para regenerar transaccionalmente. qa-report.json solo escribe el informe, no en el DOCX.
El script independiente scripts/content_quality.py debe ejecutarse de forma determinista localmente, sin invocar API en línea, embedding o servicios de modelo. Verifica la repetición del texto principal, la similaridad estructural después del enmascaramiento de entidades, la repetición de oraciones largas, las frases hechas antiguas, la integridad, la coherencia intra-lección, la coherencia de progresión, el patrón de puntuaciones, la densidad de las 13 observaciones de evaluación y la contaminación no informática (no IT). En esta ronda, solo se agregan la verificación de referencias obligatorias de la versión 2.2, la estadística de la región de origen y la verificación del handoff teoría/práctica; no se modifican los algoritmos existentes de repetición, progresión, puntuación o coherencia de implementación. non_it_contamination y sus metadatos de alcance solo detectan las palabras predeterminadas de IT que "la entrada no tiene pero la plantilla o el generador inyectan en la salida", no es un clasificador de cursos general. El diagnóstico solo conserva fragmentos limitados y un SHA-256 estable, no produce segmentos completos del texto del usuario. Todos los detectores comparten una política de reutilización única: narrative_strict, terminology_reusable, resource_reusable, reference_reusable, fixed_rubric_reusable e ignore. Los métodos de enseñanza, los recursos necesarios, las referencias legales y la rúbrica fija de asistencia/cumplimiento/hábitos pueden registrar evidencia de reutilización sin fallo duro; las referencias permiten la repetición completa entre lecciones, y están completamente excluidas de los fallos duros de anti-repetición a nivel exacto/elemento/oración/campo/estructural/frecuencia/curso completo; la duplicación exacta dentro de la misma lección y las referencias claramente solo de herramientas/equipos deben ser un fallo duro. La exención de terminología para cursos cortos no debe entrar en el campo narrativo. No se deben inventar referencias falsas para reducir la tasa de repetición del curso.
Tanto la herencia de artefactos como la transición hacia adelante en progression deben pasar tanto la evidencia léxica/de coherencia como la evidencia de substantive_anchor (anclaje sustantivo); acciones genéricas como "diseñar, operar, analizar, verificar, procesar, implementar" no pueden actuar como anclaje de forma independiente. Los prior_lesson_id no adyacentes siguen estando permitidos; si la cadena de orden físico es review, el informe debe establecer requires_agent_review=true y enumerar from/to/reason/score/declared_prior. La aceptación final del Agente no puede ignorar silenciosamente la revisión de secuencia física; si no se puede explicar el orden real de la enseñanza, se debe reescribir la progresión.
Después de que el QA determinista se complete correctamente y se realice el commit atómico, el Agente también debe realizar una revisión interna de cada lección: ¿qué agrega esta lección con respecto a la anterior?, ¿qué conocimientos o resultados de la lección anterior utiliza?, ¿qué produce?, ¿cómo utilizará este resultado la siguiente lección? Esta revisión no se escribe en el DOCX. Cuando se solicita --render, el informe de Python solo indica render.scope=smoke, y el método de conteo de páginas es un pdf_page_object_regex ligero; no equivale a un QA visual o verificación de paginación, y no puede probar que no haya desbordamiento, truncamiento, paginación anormal o deformación de tablas. El Agente debe verificar la primera lección, la lección con el texto más denso, la última lección, y si el curso alcanza las 12 horas, verificar también 1-2 lecciones intermedias, prestando atención a clipping, overflow, overlap, páginas en blanco, altura de fila anormal y límites de tabla. Después de la verificación real, use scripts/record_visual_inspection.py para escribir explícitamente un visual-inspection.json independiente; este archivo registra las páginas representativas, las comprobaciones, las notas, el qa-report asociado, la huella digital de la salida y la marca de tiempo; Python no afirmará automáticamente que la inspección visual ha pasado. Si la inspección visual falla, se debe modificar el JSON V2 y usar --backup-existing para regenerar transaccionalmente y volver a comprobar.
El QA de salida predeterminado lee el JSON V2 original, calcula lo esperado a través de un formateador puro, y luego compara con los marcadores semánticos o las coordenadas v1.0; no vuelve a invocar la función de creación de contenido de enseñanza. El diseño de la plantilla, los 70 marcadores semánticos, los IDs/nombres de marcadores, la huella digital, la compatibilidad con v1.0/v1.1 y el binario canónico están protegidos. Si existe LibreOffice en el equipo local, use --render para realizar una prueba de renderizado smoke; si no hay renderizador, el QA estructural aún pasa, y el informe marca render.status=not_executed. Las conclusiones reales sobre paginación, desbordamiento y diseño visual provienen solo de la inspección de la página representativa por parte del Agente.
La instalación del adaptador es semánticamente fija: por defecto es instruction-only adapter install (solo instalación de reglas/instrucciones), que solo instala las reglas del proyecto y las instrucciones mínimas, sin copiar el tiempo de ejecución completo, y no garantiza que el proyecto de destino pueda ejecutar el generador de forma independiente; solo añadiendo --copy-engine se obtiene full runnable project-local Lesson engine (motor de Lección completo y ejecutable en el proyecto local). Cuando el proyecto de destino necesita invocar directamente .lesson-plan-docx-generator/scripts/generate_lesson_plans.py, debe usar --copy-engine. visual-inspection.json es la atestación de inspección visual del Agente para el estado actual del DOCX/QA generado, que indica la inspección de la página representativa del Agente sobre el estado actual del DOCX/QA generado, no es una prueba criptográfica del PDF/imagen verificado.
La verificación previa de rutas (path preflight) se ejecuta antes de mkdir, generar, mover, respaldar y eliminar, protegiendo el directorio raíz del Skill, el JSON de entrada, el esquema, la plantilla seleccionada/personalizada, el manifiesto, el paquete canónico/de compatibilidad, los scripts y las pruebas, y rechaza antepasados, descendientes, enlaces simbólicos resueltos y la superposición de alias léxicos/8.3 de Windows. No se debe escribir la salida en un directorio protegido o en un paquete de plantilla personalizada.
Comandos
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
Verificación independiente de la salida:
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
Instalación manual y verificación de dependencias (el instalador no modifica automáticamente el entorno Python):
python scripts/install.py --skills-dir <skills-dir>
python <skills-dir>\lesson-plan-docx-generator\scripts\check_dependencies.py
check_dependencies.py solo verifica docx, yaml, jsonschema; si faltan, sugiere pip install -r requirements.txt. En el flujo de producción del Agente, está prohibido usar --skip-template-validation o --skip-output-validation; estos dos parámetros de compatibilidad solo se pueden usar en pruebas controladas si se establece explícitamente LESSON_ALLOW_UNSAFE_VALIDATION_SKIP=1, y se debe indicar claramente en el informe como skipped. El contrato de entrada, la calidad del contenido y la protección de rutas no se pueden omitir. Los directorios de JSON temporal, PDF, imágenes y candidatos se limpian al finalizar la tarea, y no se confirman los DOCX generados.
Archivos de Plantilla
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
...