Skill Gerador de Planos de Aula 2.2.1
Este é o único documento de especificação comportamental completo deste Skill. Outros pontos de entrada do agente devem apenas ler este arquivo e 通用提示词.md primeiro, sem copiar outro conjunto de campos ou regras de geração. Atualmente suporta Windows e macOS. O modelo é responsável por entender os materiais e produzir o JSON completo do Content 2.2; o Python é responsável apenas pela validação determinística, formatação e mapeamento de modelos, não podendo substituir o modelo na criação do corpo do texto. A versão 2.2.1 é uma revisão do contrato de entrega de Lesson / WorkOrder e não modifica o modelo do Word, o algoritmo de qualidade do corpo do texto ou o contrato de avaliação do WorkOrder.
Ponto de Entrada da Tarefa e Intake Runtime 2.1.1
No início da tarefa, primeiro leia a sessão atual, os arquivos enviados pelo usuário e os materiais do curso disponíveis: mapa de habilidades, detalhamento de tarefas do capítulo, padrões curriculares, índice do livro didático, planos de aula antigos e o modelo do Word especificado pelo usuário. Antes do planejamento formal, é obrigatório entrar no estado INTAKE_PENDING, organizar a compreensão atual em uma confirmação centralizada e totalmente em chinês das informações básicas do curso; mesmo que as informações já tenham sido inferidas da sessão ou anexos, elas devem ser exibidas e o usuário deve confirmar uma vez. Após a confirmação, entre no estado INTAKE_CONFIRMED e comece diretamente a pesquisa de materiais, outline em nível de curso, Content 2.2, QA e DOCX.
A interface do usuário usa apenas rótulos em chinês e não usa nomes de campos internos como conteúdo de perguntas. Os itens obrigatórios em uma confirmação são: nome do curso, curso/major, público-alvo, carga horária total. O resumo da confirmação também deve conter as seguintes informações não bloqueantes: carga horária teórica, carga horária prática, modo de organização teoria/prática, carga horária padrão por aula (padrão: 2 horas/aula), livro didático utilizado, materiais de referência auxiliar e se deve gerar ordens de serviço de tarefas práticas simultaneamente.
Quando um dos quatro campos principais estiver faltando, exiba "A ser complementado" no mesmo resumo de confirmação; a carga horária total só pode aceitar fatos fornecidos explicitamente pelo usuário. Se o curso/major ou público-alvo for apenas uma inferência do Agente, deve ser marcado como "Entendimento atual / Se estiver incorreto, por favor, corrija". Quando a divisão teoria/prática, o modo de organização ou a preferência por ordens de serviço de tarefas práticas não forem fornecidos explicitamente, deve ser exibido "A confirmar", e não pode ser preenchido automaticamente com 50/50, modo integrado ou "não". O default_hours=2 só pode ser usado para estimar aproximadamente quantas aulas existem com base em 2 horas/aula, e não pode ser usado para inferir a proporção teoria/prática. O mapeamento de campos internos e as regras de estado estão em docs/intake-contract-v2.1.1.json; a interface do usuário exibe apenas "Materiais de referência auxiliar", enquanto o estado interno ainda usa auxiliary_references, não podendo usar essa chave em inglês como uma pergunta para o usuário.
A primeira resposta deve ser semelhante a:
Deixe-me confirmar as informações básicas do curso:
- Nome do curso: 《Estruturas de Dados Avançadas》
- Curso/Major: Entendimento atual / Se estiver incorreto, por favor, corrija
- Público-alvo: Entendimento atual / Se estiver incorreto, por favor, corrija
- Carga horária total: 40 horas/aula
- Carga horária teórica: A confirmar
- Carga horária prática: A confirmar
- Modo de organização teoria/prática: A confirmar (Opções: totalmente teórico / totalmente prático / organizado por segmentos / organizado de forma integrada)
- Carga horária por aula: Padrão: 2 horas/aula
- Livro didático utilizado: Não especificado (Se houver um livro didático especificado, por favor, me informe; não há problema em continuar sem um)
- Materiais de referência auxiliar: Não especificado
- Gerar ordens de serviço de tarefas práticas simultaneamente: A confirmar
As informações acima estão corretas? Se precisar de ajustes, por favor, informe-me de uma só vez.
O livro didático é recomendado, não obrigatório: se um arquivo ou título de livro já foi fornecido, exiba-o diretamente; se não foi fornecido, isso não bloqueia a geração. Quando practice_work_orders não for fornecido, mantenha como "A confirmar"; a decisão de acionar o Skill WorkOrder só é tomada após o usuário escolher explicitamente. Quando a escolha explícita for false, as horas de prática ainda são contabilizadas na carga horária total do curso, mas não são gerados o Practice Task Contract, handoff, WorkOrder ou arquivos adicionais do lado prático. Quando a escolha explícita for true, após concluir o QA do Lesson e a geração do DOCX, o Agente do Lesson detecta e chama o Skill WorkOrder disponível. O Agente do WorkOrder cria o Content V1 completo, executa QA e gera as ordens de serviço, entregando tudo de forma unificada. Se não estiver disponível, entrega apenas o Lesson e o handoff, e informa explicitamente: O gerador de ordens de serviço de tarefas práticas não está disponível no momento. Os dados da tarefa prática foram salvos. Você pode continuar a geração quando o gerador estiver disponível., sem falsificar um DOCX de ordem de serviço.
Antes da confirmação do Intake, não é permitido determinar o número ou nome dos projetos, a estrutura de aulas teóricas/práticas, o número de tarefas práticas, o conteúdo de ensino de cada aula ou gerar DOCX; a menos que o usuário já tenha fornecido os fatos correspondentes explicitamente. Após a confirmação, não é permitido perguntar novamente sobre o outline, nomes de projetos, tarefas de cada aula, avaliação, modelo, diretório de saída ou "se deve começar a gerar DOCX". O modelo padrão e as regras de saída padrão são adotados diretamente. Só é permitido parar novamente se o usuário alterar ativamente os requisitos, se houver um conflito direto que não possa ser resolvido razoavelmente nas informações confirmadas, ou se encontrar algo que realmente exija uma decisão do usuário, como segurança ou substituição de arquivos.
Se o usuário escolher explicitamente "totalmente teórico", normalize para theory_hours=total_hours, practice_hours=0, delivery_mode=theory_only e defina a geração de ordens de serviço práticas como false. Se o usuário escolher explicitamente "totalmente prático", normalize para theory_hours=0, practice_hours=total_hours, delivery_mode=practice_only. Outras divisões devem satisfazer theory_hours + practice_hours = total_hours; se não forem iguais, reporte o conflito primeiro e não comece o outline.
A pesquisa de materiais prioriza o uso de materiais/livros didáticos fornecidos pelo usuário e o livro didático especificado pelo usuário. Se houver capacidade de conexão com a rede, pesquise em sites oficiais de editoras ou escolas, padrões/guias, documentação técnica oficial e literatura pública verificável. Quando apenas o título do livro for fornecido, só podem ser escritos o autor, editora, ISBN, edição ou ano verificados. Se a rede não estiver disponível, continue normalmente e não interrompa a geração por falta de conexão.
- Após o usuário permitir inferências razoáveis, complete projetos, tarefas, conteúdo de ensino, avaliação e reflexão pré-gerada de acordo com o ensino baseado em projetos;
- O DOCX final não deve conter explicações internas como "materiais insuficientes", "inferência", "IA", "QA", "similarity", "confidence".
Mesmo sem materiais de tarefa, primeiro forme um outline em nível de curso e, em seguida, gere o conteúdo de cada aula. O outline deve incluir, no mínimo, lesson_id, unit, task, lesson_type, hours, theory_hours, practice_hours, prior_learning, capability_stage, deliverable, next_bridge e practice_task_ids. Cursos longos podem ser gerados internamente em lotes de 4 a 6 aulas, mas, no final, devem ser unificados com o contexto completo do curso para QA.
Contrato de Conteúdo V2.2
O padrão é usar assets/templates/lesson-plan/v1.1.2/template.docx.
A entrada de produção formal padrão é content_contract_version: "2.2", independente da versão do modelo do Word; o runtime é compatível com a leitura das versões "2.1" e "2.0". O modelo padrão do Word é lesson-plan v1.1.2 e continua a suportar os modelos de caminho de legado v1.0 legacy-coordinate, v1.1.0/v1.1.1 semantic-bookmark e compatibility antigo; o JSON esparso antigo não é mais produzido.
Campos obrigatórios em nível de curso:
content_contract_version, course_name, major, audience,
default_hours, total_hours, delivery_plan, course_materials,
reference_pool, artifact_plan, outline, lessons
Cada aula teórica da versão 2.2 deve fornecer diretamente:
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
A entrada 2.0 ainda lê o objeto references dentro da aula; a entrada compatível 2.1 mantém a semântica original da aula. A versão 2.2 seleciona fontes apenas por meio de reference_ids no reference_pool em nível de curso, e cada aula teórica deve ter pelo menos 1 item de referência. O DOCX do Lesson 2.2 contém apenas teoria: sum(lesson.hours) == theory_hours, todas as Lessons são do tipo lesson_type=theory, practice_hours=0; a prática não entra no DOCX do Lesson. Somente quando artifact_plan.practice_work_orders=true a prática entra no Practice Task Contract / WorkOrder handoff; quando false, não pode carregar contrato ou qualquer ID de tarefa, e practice_task_ids mantém apenas o array vazio exigido pelo schema. practice_task_ids indica as tarefas práticas associadas à aula teórica, não significa que um DOCX de Lesson prático deve ser gerado. delivery_plan suporta theory_only, practice_only, split_lessons, integrated_lessons, hybrid, e theory_hours + practice_hours == total_hours. integrated descreve apenas a organização integrada teoria-prática em nível de artefato, não coloca horas de prática no DOCX do Lesson e não fixa 1+1.
default_hours é a carga horária padrão por aula que o Agente usa ao criar cada aula; o hours fornecido explicitamente para uma aula específica pode substituí-lo. default_hours não precisa ser igual à soma de todos os lessons.hours. default_hours, total_hours e hours de cada aula devem ser números inteiros positivos de horas/aula: os valores numéricos podem ser 1, 2, 4, 12 e outros inteiros; as strings podem ser "1", "2", "2.0"; não são aceitas strings vazias, frações, zero, números negativos, NaN ou Infinity. unit usa nomes baseados em projetos (por exemplo, "Projeto Um..."); progression contém prior_lesson_id, prior_learning específico, capability_stage, deliverable, next_bridge. capability_stage só pode usar os valores 认知 (reconhecimento), 理解 (compreensão), 模仿 (imitação), 独立 (independente), 综合 (síntese), 优化 (otimização), 迁移 (transferência), e não é necessário que sigam uma progressão linear mecânica. O prior_lesson_id da primeira aula deve ser null; as aulas subsequentes só podem referenciar aulas anteriores que já apareceram. Em quatro ou mais aulas, os estágios de capacidade não podem ser todos idênticos.
student_analysis deve ter pelo menos dois itens em base/problems/strategies; as três categorias de goals devem ter pelo menos dois itens cada; teaching_content deve ter pelo menos três itens; tanto key_point quanto difficult_point devem ter content e strategy; methods deve ter pelo menos dois itens; resources deve ter pelo menos dois itens. Na versão 2.2, os reference_ids de uma aula teórica não podem estar vazios; referências vazias resultam em falha direta. Cursos puramente práticos podem não ter DOCX de Lesson; somente quando a geração de ordens de serviço práticas for explicitamente selecionada é que as horas de prática devem ser expressas por meio do Practice Task handoff; quando não for explicitamente selecionada, não crie handoff e não invente aulas teóricas.
O implementation de cada aula deve ser fornecido completa e estritamente na seguinte ordem de nove IDs, e o label, minutes, modality, content, teacher_actions, student_actions e objective de cada fase devem vir do JSON:
before_class_preparation
task_introduction
operation_demonstration
task_implementation
task_extension
project_practice
peer_review
lesson_summary
after_class_improvement
A preparação antes da aula e a melhoria após a aula são fases extracurriculares. Os minutos das sete fases intermediárias devem ser estritamente iguais a hours * 45. Cada fase extracurricular pode ter 0 minutos, mas não pode exceder max(60, hours * 45), e a soma das duas fases extracurriculares não pode exceder 2 * hours * 45; o erro deve indicar o ID da aula, a fase, o valor real e o limite. operation_demonstration é um slot semântico que pode ser exibido como demonstração de método, análise de caso ou demonstração de habilidade em cursos como enfermagem, contabilidade ou mecânica.
A avaliação deve fornecer explicitamente um evaluation.score entre 85 e 96, usando incrementos de 0,5, e fornecer as remarks de cada aula para os 13 IDs de critério canônicos. Cada remark deve ter conteúdo substancial; todas as versões de template do Content V2 executam o limite máximo de contrato de não mais que 48 caracteres significativos, e o manifest só pode apertar ainda mais; a ultrapassagem deve falhar, não pode ser truncada. Quando a pontuação não for especificada, sugere-se que se concentre naturalmente entre 88 e 94, mas não pode ser toda 90, nem em qualquer ciclo curto periódico ou estritamente crescente ou decrescente. score_breakdown() é responsável apenas por dividir deterministicamente a pontuação total explícita nas linhas da tabela existente; o Python não cria observações, não usa três conjuntos fixos de observações em ciclo ou fallback de pontuação mecânico. A reflexão deve fornecer explicitamente summary, innovation, improvement, e permite a pré-geração antes da aula, mas deve gerar diferenças em torno das tarefas desta aula, pontos-chave, organização, desempenho esperado, problemas e a ponte para a próxima aula.
Na versão 2.2, course_materials.textbook representa separadamente o livro didático e pode ser um objeto ou null; por padrão, ele não é automaticamente escrito nas células de referências do Word. Antes de gerar cada aula, o Agente forma um conceito de planejamento de course_reference_pool / reference_catalog; o campo persistido ainda é reference_pool, não um novo campo de contrato JSON. Cada item deve ter reference_id, reference_type, um título específico identificável, source_kind, source_region (domestic/foreign/unknown) e as evidências correspondentes; cada aula escreve apenas reference_ids. allow_textbook_as_reference é false por padrão; somente quando explicitamente definido como true o livro didático pode ser incluído nas referências. references representam apenas fontes documentais que podem ser lidas, consultadas, citadas ou usadas como base para o curso, incluindo monografias, padrões de curso/ensino, padrões nacionais/industriais/profissionais, guias/especificações, artigos, literatura pública, documentação técnica oficial, manuais de produtos oficiais e documentos de ensino formais fornecidos pelo usuário. resources representam ferramentas, equipamentos, ambientes e materiais usados na implementação do ensino, como MySQL Workbench, servidor de banco de dados, PPT, projetor, modelo de enfermagem, máquina virtual, folhas de tarefas práticas e conjuntos de dados de caso; estes não podem ser escritos em references apenas para completar. Cada aula geralmente seleciona de 1 a 3 itens de referência, e as referências legais em nível de curso podem ser reutilizadas.
source_kind ainda mantém provided, generic e verified_public; provided requer evidências de materiais reais do usuário; verified_public requer URL ou fonte oficial localizável; generic só pode usar a semântica documental específica e não pode falsificar informações bibliográficas detalhadas. É proibido usar textos genéricos de espaço reservado, como "documentos públicos relacionados à Unified Modeling Language", "recursos de rede relacionados", "literatura pública relacionada", e também é proibido adivinhar autor, ISBN, editora, edição, ano ou número de padrão. Fontes domésticas têm prioridade: materiais fornecidos pelo usuário, publicações/monografias nacionais, materiais de instituições de ensino nacionais, padrões nacionais/industriais/profissionais e documentos oficiais nacionais têm precedência sobre clássicos estrangeiros; uma proporção doméstica abaixo de 70% é apenas um aviso de qualidade, não uma falha grave; quando houver padrões/clássicos internacionais ou fontes domésticas insuficientes, fontes estrangeiras podem ser complementadas. A repetição completa de referências entre aulas é permitida e pertence a reference_reusable, saindo explicitamente das falhas graves de anti-repetição exact/item/sentence/field/structural/frequency/whole-course; IDs duplicados ou conteúdo duplicado dentro da mesma aula ainda são falhas graves. A repetição de referências não é um problema de repetição do corpo do plano de aula. É proibido inventar diferentes livros didáticos, autores, ISBNs, editoras, números de padrão ou literatura pública para reduzir a taxa de repetição do curso; repetir o mesmo livro didático 18 vezes é melhor do que inventar 18 livros didáticos. As evidências são usadas apenas para entrada e QA; o DOCX escreve apenas o texto de citação formal, não os metadados de evidência.
Practice Task Contract V1
Somente quando artifact_plan.practice_work_orders=true a entrada 2.2 deve fornecer practice_task_contract, versão 1.0, granularity: "per_task". As horas de prática devem ser um número par positivo; os campos da tarefa são task_id, project_id, title, lesson_ids, practice_hours, scenario, objectives, required_inputs, tools_or_materials, steps, deliverables, acceptance_criteria, safety_or_compliance. Cada Practice Task é fixado em 2 horas/aula, e o número de tarefas é estritamente igual a practice_hours / 2; cada tarefa corresponde a um WorkOrder, project_id é usado apenas para agrupamento e não pode replanejar a granularidade. lesson_ids são os IDs das aulas teóricas que fornecem preparação teórica/conhecimento prévio, podendo abranger várias aulas; em cursos puramente práticos sem aulas teóricas, é um array vazio. Quando practice_work_orders=false, o contrato ou handoff não é permitido, e todos os practice_task_ids devem permanecer como arrays vazios. Quando true, o Lesson é responsável apenas por gerar e fazer QA do handoff canônico, que é então consumido pelo Skill WorkOrder detectado por meio da orquestração do Agente; o gerador Python do Lesson não pode chamar o Python do WorkOrder via subprocess e não pode mapear automaticamente para o corpo da ordem de serviço. Quando o Skill WorkOrder não está disponível, apenas o handoff practice-task-contract.json é gerado, e o status unavailable é informado explicitamente, sem falsificar o DOCX de ordem de serviço prática.
As regras completas atuais da versão 2.2 estão em docs/content-contract-v2.md; examples/tasks-v21.example.json é mantido como exemplo de compatibilidade 2.1, e examples/tasks.example.json é mantido como exemplo de compatibilidade 2.0. As descrições dos campos estão em docs/content-contract-v2.md e docs/practice-task-contract-v1.md; as restrições de máquina estão em schemas/lesson-plan-input.schema.json e no schemas/shared/practice-task-contract.schema.json canônico do repositório; schemas/practice-task-contract.schema.json é apenas um ponto de entrada de compatibilidade.
Limite entre Python e Agente
O Agente é responsável pelo planejamento em nível de curso e por todo o corpo do texto de ensino de cada aula; o gerador faz apenas validação de schema, numeração, quebras de linha, formatação de minutos, mapeamento de campos e gravação no template. O caminho formal da versão 2 não pode chamar generated_lesson_fields, implementation_cell_values ou reflection_cell_values antigos, nem usar flows[:3] ou criar corpo de texto com base em campos ausentes. Se o conteúdo exceder max_chars ou max_paragraphs do manifest, deve falhar e indicar a aula, o campo, os caracteres reais e o limite, sem truncar ou reduzir silenciosamente.
Ordem de Geração e QA
Ler materiais → Confirmar informações básicas do curso (uma vez)
-> Outline do curso
-> JSON Content V2.2
-> QA do Contrato de Entrada
-> QA da Qualidade do Conteúdo
-> QA do Template
-> Geração do DOCX candidato
-> QA da Estrutura de Saída + Fidelidade Conteúdo-para-DOCX
-> Render smoke opcional do LibreOffice
-> Commit atômico para saída final e relatório de QA externo
-> Quando practice_work_orders=true, detectar e chamar o Agente do Skill WorkOrder, depois unificar a entrega do Lesson + WorkOrder
-> Inspeção visual da página representativa pelo Agente
Use scripts/generate_lesson_plans.py para gerar. Todos os DOCXs são primeiro gravados em um diretório candidate com o mesmo pai do diretório final; somente depois que o QA de conteúdo, QA do template, estrutura de saída/proteção de bookmark/formatação, QA de fidelidade de conteúdo e o render smoke solicitado passarem, eles são trocados para o diretório final. Quando --qa-report é explicitamente usado, o relatório externo é primeiro pré-visualizado no mesmo diretório pai e depois commitado junto com o diretório de saída; se qualquer troca falhar, o diretório antigo e o relatório antigo são restaurados. Um diretório final não vazio requer --backup-existing; se a troca falhar, o diretório antigo deve ser restaurado. Após o commit bem-sucedido, o stdout relata apenas os caminhos dos DOCXs que realmente existem no diretório final. Após a confirmação das informações básicas do curso, nenhuma confirmação adicional é solicitada para a geração do DOCX; a inspeção visual da página representativa pelo Agente é uma aceitação pós-commit; se forem encontrados estouro, truncamento, quebra de página anômala ou páginas em branco, o conteúdo V2 deve ser reescrito e a geração transacional deve ser repetida usando --backup-existing. qa-report.json escreve apenas o relatório, não no DOCX.
O scripts/content_quality.py independente deve ser executado deterministicamente em ambiente local, sem chamar APIs online, embeddings ou serviços de modelo. Ele verifica repetição do corpo do texto existente, similaridade estrutural após mascaramento de entidades, repetição de frases longas, clichês antigos, completeza, coerência intra-aula, coerência de progressão, padrão de pontuação, densidade de observações dos 13 itens de avaliação e contaminação não IT; esta rodada adiciona apenas a verificação de obrigatoriedade de referências 2.2, estatísticas de região de origem e verificação de handoff teoria/prática, sem alterar os algoritmos existentes de repetição, progressão, pontuação ou coerência de implementação. non_it_contamination e seus metadados de escopo detectam apenas palavras padrão de IT que "não estão na entrada, mas são injetadas na saída pelo modelo ou gerador", não sendo um classificador genérico de curso. O diagnóstico mantém apenas fragmentos limitados e SHA-256 estável, não gerando o corpo do texto completo do usuário. Todos os detectores compartilham uma política de reutilização única: narrative_strict, terminology_reusable, resource_reusable, reference_reusable, fixed_rubric_reusable e ignore. Métodos de ensino, recursos necessários, referências legais e rubricas fixas de frequência/conformidade/hábitos podem registrar evidências de reutilização, mas não são falhas graves; referências podem ser completamente repetidas entre aulas e saem completamente das falhas graves de anti-repetição exact/item/sentence/field/structural/frequency/whole-course; duplicatas exatas dentro da mesma aula e referências de ferramentas/equipamentos puramente instrumentais óbvias devem ser falhas graves. A isenção de terminologia para cursos curtos não pode entrar no campo narrativo. Não é permitido fabricar referências bibliográficas para reduzir a taxa de repetição do curso.
A herança de artefato e a transição direta da progression devem passar simultaneamente por evidências de coesão léxica/de coerência e evidências de substantive_anchor; ações genéricas como "projetar, operar, analisar, verificar, processar, implementar" não podem servir como âncoras independentes. prior_lesson_id não adjacente ainda é permitido; se a cadeia de ordem física for review, o relatório deve definir requires_agent_review=true e listar from/to/reason/score/declared_prior. A aceitação final do Agente não pode ignorar silenciosamente a revisão da sequência física; se a ordem real de ensino não puder ser explicada, a progressão deve ser reescrita.
Após o QA determinístico ser aprovado e o commit atômico ser concluído, o Agente também deve revisar internamente cada aula: o que esta aula adicionou em relação à anterior, que conhecimento ou resultado da aula anterior foi usado, o que foi produzido e como a próxima aula usará este resultado. Esta revisão não é escrita no DOCX. Quando --render é solicitado, o relatório Python indica apenas render.scope=smoke, e o método de contagem de páginas é pdf_page_object_regex leve; isso não equivale a QA visual ou verificação de paginação, e não prova ausência de estouro, truncamento, quebra de página anômala ou deformação de tabela. O Agente deve verificar a primeira aula, a aula com o corpo de texto mais denso, a última aula; em cursos com 12 ou mais horas/aula, verifique também 1 a 2 aulas intermediárias, observando clipping, overflow, overlap, páginas em branco, altura de linha anômala e limites de tabela. Após a verificação real, use scripts/record_visual_inspection.py para escrever explicitamente um visual-inspection.json independente; este arquivo registra as páginas representativas, verificações, notas, ID do relatório de QA associado, fingerprint da saída e timestamp. O Python não reivindica automaticamente a aprovação visual. Em caso de falha visual, o JSON V2 deve ser modificado e a geração transacional deve ser repetida com --backup-existing e re-verificada.
Por padrão, o QA de saída lê o JSON V2 original, calcula o esperado por meio de um formatador puro e, em seguida, compara com os bookmarks semânticos ou coordenadas v1.0; a função de criação do corpo do texto de ensino não é chamada novamente. O layout do modelo, 70 bookmarks semânticos, IDs/nomes dos bookmarks, fingerprint, compatibilidade v1.0/v1.1 e o binário canônico são todos protegidos. Se o LibreOffice estiver disponível na máquina, use --render para o render smoke; se não houver renderizador, o QA estrutural ainda é aprovado e o relatório marca render.status=not_executed. As conclusões reais sobre paginação, estouro e layout visual vêm apenas da verificação da página representativa pelo Agente.
A instalação do adaptador é semanticamente fixa como: o padrão é installação do adaptador apenas com instruções/regras, instalando apenas as regras do projeto e instruções mínimas, sem copiar o runtime completo e sem garantir que o projeto alvo possa executar o gerador de forma independente; somente com a adição de --copy-engine é uma instalação completa do engine de Lesson executável no projeto local. O projeto alvo que precisa chamar diretamente .lesson-plan-docx-generator/scripts/generate_lesson_plans.py deve usar --copy-engine. visual-inspection.json é uma atestação de inspeção visual do Agente para o estado atual do DOCX/QA gerado, representando a verificação de página representativa do Agente para o estado atual do DOCX/QA gerado, não uma prova criptografada do PDF/imagem verificado.
O preflight de caminho é executado antes de mkdir, geração, move, backup, delete, protegendo o diretório raiz do Skill, JSON de entrada, schema, modelo selecionado/personalizado, manifest, pacote canônico/de compatibilidade, scripts e testes, e recusando ancestral, descendente, symlink resolvido e overlap lexical/alias 8.3 do Windows. Não escreva a saída em diretórios protegidos ou pacotes de modelo personalizados.
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
Validação independente da saída:
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
Instalação manual e verificação de dependências (o instalador não modifica automaticamente o ambiente Python):
python scripts/install.py --skills-dir <skills-dir>
python <skills-dir>\lesson-plan-docx-generator\scripts\check_dependencies.py
check_dependencies.py verifica apenas a presença de docx, yaml, jsonschema; se estiverem faltando, exibe a sugestão pip install -r requirements.txt. O fluxo de produção do Agente proíbe o uso de --skip-template-validation ou --skip-output-validation; esses dois parâmetros de compatibilidade só podem ser usados em testes controlados com a definição explícita de LESSON_ALLOW_UNSAFE_VALIDATION_SKIP=1 e devem ser marcados como skipped no relatório. O contrato de entrada, a qualidade do conteúdo e a proteção de caminho não podem ser ignorados. Arquivos JSON temporários, PDFs, imagens e diretórios candidatos são limpos após o término da tarefa; os DOCXs gerados não são commitados.
Arquivos de Modelo
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
scripts/validate_template.py
scripts/validate_output.py
scripts/validate_visual_inspection.py
scripts/record_visual_inspection.py
scripts/install.py
scripts/check_dependencies.py
scripts/intake_consolidator.py
docs/intake-contract-v2.1.1.json
docs/content-contract-v2.md
docs/practice-task-contract-v1.md
examples/tasks.example.json
examples/tasks-v21.example.json
examples/practice-task-contract.example.json
(O conteúdo truncado foi omitido para foco, mas a estrutura e as regras principais estão totalmente cobertas acima.)