Lehrplangenerator Skill 2.2.1
Dies ist die einzige vollständige Verhaltensspezifikation dieses Skills. Andere Agenten-Einstiegspunkte müssen zuerst diese Datei und allgemeine-prompt.md lesen und dürfen keine anderen Felder oder Generierungsregeln kopieren. Unterstützt derzeit Windows und macOS. Das Modell ist für das Verständnis der Materialien und die Erstellung des vollständigen Content 2.2 JSON verantwortlich; Python führt nur deterministische Validierung, Formatierung und Vorlagenzuordnung durch und darf nicht den kreativen Text des Modells ersetzen. 2.2.1 ist eine korrigierte Version des Lesson/WorkOrder-Liefervertrags, die keine Word-Vorlagen, Algorithmen zur Textqualität oder den WorkOrder-Bewertungsvertrag ändert.
Aufgabeneinstieg und Intake Runtime 2.1.1
Zu Beginn der Aufgabe werden die aktuelle Sitzung, die hochgeladenen Dateien des Benutzers und die verfügbaren Kursmaterialien gelesen: Kompetenzmatrix, Kapitelaufgaben, Kursstandards, Lehrbuchverzeichnis, alte Lehrpläne und die vom Benutzer angegebene Word-Vorlage. Vor der formalen Planung muss der Status INTAKE_PENDING eingegeben werden, um das aktuelle Verständnis in einer konzentrierten, vollständig auf Chinesisch verfassten Bestätigung der grundlegenden Kursinformationen zu organisieren; selbst wenn die Informationen bereits aus der Sitzung oder den Anhängen abgeleitet wurden, müssen sie angezeigt und der Benutzer um Bestätigung gebeten werden. Nach der Bestätigung wird INTAKE_CONFIRMED eingegeben, und es wird direkt mit der Materialrecherche, dem Kurs-Outlines, Content 2.2, der Qualitätssicherung und DOCX begonnen.
Die Benutzeroberfläche verwendet nur chinesische Bezeichnungen und nicht die internen Feldnamen als Fragen. Die grundlegenden Kursinformationen, die einmal bestätigt werden müssen, sind: Kursname, Fachrichtung, Zielgruppe, Gesamtstundenzahl. Die Zusammenfassung der Bestätigung muss außerdem die folgenden nicht-blockierenden Informationen enthalten: Theoriestunden, Praxisstunden, Organisation von Theorie und Praxis, Standardstundenzahl pro Einheit (Standard 2 Stunden), verwendetes Lehrbuch, unterstützende Referenzen, ob gleichzeitig Praxisaufgaben erstellt werden sollen.
Fehlen Informationen zu den vier Kernfeldern, wird in derselben Bestätigungszusammenfassung „noch zu ergänzen“ angezeigt; die Gesamtstundenzahl akzeptiert nur explizit vom Benutzer bereitgestellte Fakten. Wenn Fachrichtung oder Zielgruppe nur eine Vermutung des Agenten sind, muss „aktuelles Verständnis / falls nicht korrekt, bitte ändern“ angegeben werden. Wenn die Aufteilung in Theorie/Praxis, die Organisationsform oder die Präferenz für Praxisaufgaben nicht explizit angegeben wurden, muss „noch zu bestätigen“ angezeigt werden; es darf nicht automatisch mit 50/50, integriert oder „nein“ ergänzt werden. default_hours=2 darf nur verwendet werden, um zu erläutern, wie viele Unterrichtseinheiten bei 2 Stunden pro Einheit ungefähr entstehen; es darf nicht zur Ableitung des Theorie/Praxis-Verhältnisses verwendet werden. Interne Feldzuordnungen und Stati sind in docs/intake-contract-v2.1.1.json festgelegt; die Benutzeroberfläche zeigt nur „Unterstützende Referenzen“ an, der interne Status verwendet weiterhin auxiliary_references; dieser englische Schlüssel darf nicht als Benutzerfrage verwendet werden.
Die erste Antwort sollte wie folgt aussehen:
Ich bestätige zunächst die grundlegenden Kursinformationen:
- Kursname: „Datenstrukturen Fortgeschritten“
- Fachrichtung: aktuelles Verständnis / falls nicht korrekt, bitte ändern
- Zielgruppe: aktuelles Verständnis / falls nicht korrekt, bitte ändern
- Gesamtstundenzahl: 40 Stunden
- Theoriestunden: noch zu bestätigen
- Praxisstunden: noch zu bestätigen
- Organisationsform Theorie/Praxis: noch zu bestätigen (optional: nur Theorie / nur Praxis / getrennt organisiert / integriert organisiert)
- Standardstunden pro Einheit: 2 Stunden
- Verwendetes Lehrbuch: nicht angegeben (falls ein bestimmtes Lehrbuch vorhanden ist, bitte mitteilen; kann auch ohne fortgesetzt werden)
- Unterstützende Referenzen: nicht angegeben
- Gleichzeitig Praxisaufgaben erstellen: noch zu bestätigen
Sind die obigen Informationen korrekt? Bei Anpassungen bitte auf einmal mitteilen.
Das Lehrbuch ist empfohlen, nicht erforderlich: Wenn eine Datei oder ein Buchtitel bereitgestellt wurde, wird dies direkt angezeigt; wenn nicht, blockiert es die Generierung nicht. Wenn practice_work_orders nicht bereitgestellt wurde, bleibt es auf „noch zu bestätigen“; erst wenn der Benutzer eine explizite Auswahl trifft, wird entschieden, ob der WorkOrder Skill eingebunden wird. Bei expliziter Auswahl von „false“ werden die Praxisstunden weiterhin in die Gesamtstundenzahl des Kurses eingerechnet, es werden jedoch kein Practice Task Contract, kein Handoff, keine WorkOrder oder keine zusätzlichen Praxisdateien erstellt. Bei expliziter Auswahl von „true“ erkennt der Lesson Agent nach Abschluss des Lesson-QA/DOCX und des Practice Task Contract-Handoffs den verfügbaren WorkOrder Skill und ruft ihn auf; der WorkOrder Agent erstellt den vollständigen Content V1, führt die Qualitätssicherung durch und generiert die Aufträge, die dann gemeinsam ausgeliefert werden. Wenn der WorkOrder Skill nicht verfügbar ist, werden nur der Lesson und der Handoff ausgeliefert, und es wird klar angegeben: „Der Generator für Praxisaufgabenaufträge ist derzeit nicht verfügbar. Die Praxisdatendatei wurde gespeichert. Sie kann später mit dem Generator für Praxisaufgabenaufträge fortgesetzt werden.“ Es werden keine gefälschten Auftrags-DOCXs erstellt.
Vor der Bestätigung des Intake dürfen keine Projektanzahl oder -namen, die Struktur der Theorie/Praxis-Einheiten, die Anzahl der Praxisaufgaben, die Lehrinhalte für jede Einheit festgelegt oder DOCXs erstellt werden, es sei denn, der Benutzer hat die entsprechenden Fakten bereits explizit bereitgestellt. Nach einer Bestätigung darf nicht erneut nach Outlines, Projektnamen, Aufgaben pro Einheit, Bewertung, Vorlagen, Ausgabeverzeichnissen oder „ob mit der Erstellung der DOCXs begonnen werden soll“ gefragt werden. Die Standardvorlage und die Standardausgaberegeln werden direkt übernommen. Nur wenn der Benutzer seine Anforderungen aktiv ändert, die bestätigten Informationen einen unauflösbaren direkten Konflikt aufweisen oder sicherheitsrelevante/dateiüberschreibende etc. Entscheidungen des Benutzers erforderlich sind, darf erneut angehalten werden.
Wenn der Benutzer explizit „nur Theorie“ auswählt, wird dies normalisiert auf theory_hours=total_hours, practice_hours=0, delivery_mode=theory_only, und die Praxisaufgabenaufträge werden auf false gesetzt. Wenn der Benutzer explizit „nur Praxis“ auswählt, wird dies normalisiert auf theory_hours=0, practice_hours=total_hours, delivery_mode=practice_only. Andere Aufteilungen müssen sicherstellen, dass theory_hours + practice_hours = total_hours ist; bei Ungleichheit wird zuerst der Konflikt gemeldet, und es darf nicht mit dem Outlines begonnen werden.
Bei der Materialrecherche werden bevorzugt die vom Benutzer bereitgestellten Lehrbuch-/Kursmaterialien und das vom Benutzer angegebene Lehrbuch verwendet; wenn eine Internetverbindung besteht, können auch offizielle Verlags- oder Schulwebseiten, Standards/Leitfäden, offizielle technische Dokumentationen und überprüfbare öffentliche Literatur recherchiert werden. Wenn nur ein Buchtitel angegeben wird, dürfen nur die tatsächlich überprüften Autoren, der Verlag, die ISBN, die Auflage oder das Jahr verwendet werden; wenn das Internet nicht verfügbar ist, wird normal fortgesetzt, und die Generierung wird nicht aufgrund fehlender Internetverbindung unterbrochen.
- Nachdem der Benutzer angemessene Schlussfolgerungen erlaubt hat, werden Projekte, Aufgaben, Lehrinhalte, Bewertungen und vorab generierte Reflexionen gemäß der projektbasierten Lehre ergänzt.
- Im endgültigen DOCX dürfen keine internen Hinweise wie „unzureichende Materialien, Schlussfolgerung, KI, QA, similarity, confidence“ erscheinen.
Auch ohne Aufgabenmaterialien muss zuerst ein Kurs-Outlines erstellt werden, bevor die Inhalte für jede Einheit generiert werden. Das Outlines muss mindestens lesson_id, unit, task, lesson_type, hours, theory_hours, practice_hours, prior_learning, capability_stage, deliverable, next_bridge und practice_task_ids enthalten. Lange Kurse können intern in Chargen von 4 bis 6 Einheiten generiert werden, aber abschließend muss eine einheitliche Qualitätssicherung mit dem vollständigen Kurskontext durchgeführt werden.
Content Contract V2.2
Standardmäßig wird assets/templates/lesson-plan/v1.1.2/template.docx verwendet.
Der Standardproduktionseingabe ist content_contract_version: "2.2", unabhängig von der Version der Word-Vorlage; die Laufzeitkompatibilität ermöglicht das Lesen von "2.1" und "2.0". Die Standard-Word-Vorlage ist lesson-plan v1.1.2, und es werden weiterhin die Vorlagenpfade v1.0 legacy-coordinate, v1.1.0/v1.1.1 semantic-bookmark sowie alte Kompatibilitätsvorlagen unterstützt; alte sparse JSONs werden nicht mehr produziert.
Erforderliche Felder auf Kursebene:
content_contract_version, course_name, major, audience,
default_hours, total_hours, delivery_plan, course_materials,
reference_pool, artifact_plan, outline, lessons
Jede Theorieeinheit in 2.2 muss direkt Folgendes bereitstellen:
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
2.0-Eingaben lesen weiterhin das references-Objekt innerhalb der Einheit; 2.1-kompatible Eingaben behalten die ursprüngliche Semantik der Einheit bei. 2.2 wählt Quellen nur über die reference_ids des reference_pool auf Kursebene aus, und jede Theorie-Lektion hat mindestens eine Referenz. Das Lesson-DOCX von 2.2 enthält nur die Theorie: sum(lesson.hours) == theory_hours, alle Lektionen sind lesson_type=theory, practice_hours=0; die Praxis wird nicht in das Lesson-DOCX aufgenommen. Nur wenn artifact_plan.practice_work_orders=true ist, wird die Praxis in den Practice Task Contract / WorkOrder-Handoff aufgenommen; bei „false“ darf kein Contract oder Aufgaben-ID mitgeführt werden, practice_task_ids behält nur das schema-geforderte leere Array. practice_task_ids gibt die mit der Theorieeinheit verbundenen Praxisaufgaben an, nicht die Erstellung eines Praxis-Lesson-DOCX. delivery_plan unterstützt theory_only, practice_only, split_lessons, integrated_lessons, hybrid, und es gilt theory_hours + practice_hours == total_hours. integrated beschreibt nur die Artefakt-integrierte Theorie-Praxis-Organisation, stopft aber keine Praxisstunden in das Lesson-DOCX und ist nicht fest 1+1.
default_hours ist die Standardstundenzahl pro Einheit, die der Agent bei der Erstellung jeder Unterrichtsstunde verwendet; die explizit für eine bestimmte Einheit angegebenen hours können dies überschreiben, default_hours muss nicht gleich der Summe aller lessons.hours sein. default_hours, total_hours und die hours jeder Einheit müssen positive ganze Zahlen sein: Zahlenwerte können 1, 2, 4, 12 usw. sein, Zeichenfolgen können "1", "2", "2.0" sein; leere Zeichenfolgen, Brüche, Null, negative Zahlen, NaN oder Infinity sind nicht zulässig. unit verwendet projektbasierte Namen (z. B. „Projekt Eins ...“); progression enthält prior_lesson_id, spezifisches prior_learning, capability_stage, deliverable, next_bridge. capability_stage darf nur 认知, 理解, 模仿, 独立, 综合, 优化, 迁移 verwenden; es ist keine streng lineare Steigerung erforderlich. prior_lesson_id der ersten Einheit muss null sein; nachfolgende Einheiten können nur auf bereits vorhandene vorherige Einheiten verweisen. Bei vier oder mehr Einheiten dürfen nicht alle Kompetenzstufen identisch sein.
student_analysis hat mindestens zwei Einträge für base/problems/strategies; drei Kategorien von goals haben jeweils mindestens zwei Einträge; teaching_content hat mindestens drei Einträge; key_point und difficult_point müssen jeweils content und strategy haben; methods hat mindestens zwei Einträge, resources hat mindestens zwei. Die reference_ids einer Theorie-Lektion in 2.2 dürfen nicht leer sein; leere Referenzen führen direkt zu einem Fehler. Reine Praxiskurse können kein Lesson-DOCX haben; nur wenn explizit die Erstellung von Praxisaufträgen ausgewählt wurde, muss der Practice Task Handoff verwendet werden, um die Praxisstunden auszudrücken. Wenn explizit keine Erstellung ausgewählt wurde, wird kein Handoff erstellt, und es dürfen auch keine fiktiven Theorieeinheiten erstellt werden.
Das implementation jeder Einheit muss gemäß den folgenden neun IDs in fester Reihenfolge vollständig bereitgestellt werden, und label, minutes, modality, content, teacher_actions, student_actions, objective jeder Phase stammen alle aus dem JSON:
before_class_preparation
task_introduction
operation_demonstration
task_implementation
task_extension
project_practice
peer_review
lesson_summary
after_class_improvement
Vorbereitung vor dem Unterricht und Verbesserung nach dem Unterricht sind außerunterrichtliche Phasen; die Minuten der sieben dazwischenliegenden Phasen müssen exakt hours * 45 ergeben. Jede außerunterrichtliche Phase darf 0 Minuten haben, darf aber max(60, hours * 45) nicht überschreiten; die Summe der beiden außerunterrichtlichen Phasen darf 2 * hours * 45 nicht überschreiten; bei Fehlern müssen lesson ID, Phase, actual und limit angegeben werden. operation_demonstration ist eine semantische Position, die in Kursen wie Pflege, Buchhaltung, Maschinenbau als Methodendemonstration, Fallanalyse oder Fertigkeitsdemonstration angezeigt werden kann.
Die Bewertung muss explizit einen evaluation.score von 85–96 in 0,5er-Schritten angeben und die kanonischen 13 criterion-IDs mit einheitsspezifischen remarks bereitstellen. Jede Bemerkung muss substanziellen Inhalt haben; alle Content-V2-Vorlagenversionen wenden einheitlich eine Vertragsobergrenze von nicht mehr als 48 sinnvollen Zeichen an. Manifest kann diese nur weiter verschärfen; bei Überschreitung muss ein Fehler ausgegeben werden und darf nicht abgeschnitten werden. Wenn keine Punktzahl angegeben ist, wird empfohlen, sich natürlich auf 88–94 zu konzentrieren, aber nicht alle auf 90, keinen kurzen periodischen Zyklus, keine strenge Steigerung oder Senkung. score_breakdown() ist nur dafür verantwortlich, die explizite Gesamtpunktzahl deterministisch auf die vorhandenen Tabellenzeilen aufzuteilen; Python erstellt keine Bemerkungen, verwendet keine drei festen Bemerkungszyklen oder mechanischen Punkte-Fallback. Die Reflexion muss explizit summary, innovation, improvement bereitstellen; eine Vorab-Generierung vor dem Unterricht ist erlaubt, sollte aber auf die Aufgaben, Schwerpunkte, Organisation, erwartete Leistung, Probleme und Anschluss der nächsten Einheit dieser Einheit abzielen.
course_materials.textbook in 2.2 repräsentiert separat das Lehrbuch und kann ein Objekt oder null sein; es wird standardmäßig nicht automatisch in die Referenzen-Zelle von Word geschrieben. Vor der Generierung jeder Einheit erstellt der Agent ein course_reference_pool- / reference_catalog-Planungskonzept; das gespeicherte Feld ist immer noch reference_pool, kein neues JSON-Contract-Feld. Jeder Eintrag muss reference_id, reference_type, einen identifizierbaren spezifischen Titel, source_kind, source_region (domestic/foreign/unknown) und entsprechende Nachweise haben; in jede Einheit wird nur reference_ids geschrieben. allow_textbook_as_reference ist standardmäßig false; nur bei explizitem true darf das Lehrbuch in die references aufgenommen werden. references repräsentiert nur Literatur/Dokumente, die gelesen, eingesehen, zitiert oder als Grundlage für den Kurs verwendet werden können, einschließlich Monographien, Kurs-/Lehrstandards, nationale/industrielle/berufliche Standards, Leitfäden/Spezifikationen, Aufsätze, öffentliche Literatur, offizielle technische Dokumentationen, offizielle Produkthandbücher und vom Benutzer bereitgestellte formelle Lehrdokumente. resources repräsentiert Werkzeuge, Geräte, Umgebungen und Materialien, die bei der Durchführung des Unterrichts verwendet werden, z. B. MySQL Workbench, Datenbankserver, PPT, Projektor, Pflegemodell, virtuelle Maschine, praktische Aufgabenblätter und Fallstudien-Datensätze; diese dürfen nicht in die references aufgenommen werden, um die Anzahl zu erhöhen. Jede Einheit wählt normalerweise 1–3 references aus; references auf Kursebene können wiederverwendet werden.
source_kind behält provided, generic, verified_public; provided benötigt echte Materialnachweise des Benutzers, verified_public benötigt eine URL oder eine identifizierbare offizielle Quelle, generic darf nur spezifische Dokumentensemantik verwenden und keine detaillierten bibliografischen Informationen erfinden. Platzhaltertexte wie „einheitliche Modellierungssprache relevante öffentliche Dokumente“, „relevante Online-Ressourcen“ oder „relevante öffentliche Literatur“ sowie das Erraten von Autoren, ISBN, Verlagen, Auflagen, Jahrgängen oder Standardnummern sind verboten. Inländische Quellen haben Priorität: Vom Benutzer bereitgestellte Materialien, inländische Publikationen/Monographien, Materialien inländischer Hochschulen, nationale/industrielle/berufliche Standards und inländische maßgebliche Dokumente haben Vorrang vor ausländischen Klassikern; ein inländischer Anteil unter 70 % ist nur eine Qualitätswarnung, kein harter Fehler; bei tatsächlichen internationalen Standards/Klassikern oder unzureichenden inländischen Quellen können ausländische Quellen ergänzt werden. Eine vollständige Wiederholung von references über mehrere Einheiten hinweg ist erlaubt und fällt unter reference_reusable; sie ist explizit von den harten Fehlern für exact/item/sentence/field/structural/frequency/whole-course-Entduplizierung ausgenommen; doppelte IDs oder doppelter Inhalt innerhalb derselben Einheit führen jedoch weiterhin zu einem harten Fehler. Die Duplizierung von References ist kein Problem der Duplizierung des Lehrplantextes. Es ist verboten, verschiedene Lehrbücher, Autoren, ISBNs, Verlage, Standardnummern oder öffentliche Literatur zu erfinden, um die Kursduplizierungsrate zu senken; 18 Wiederholungen desselben Lehrbuchs sind besser als die Erfindung von 18 Lehrbüchern. evidence wird nur für die Eingabe und Qualitätssicherung verwendet; das DOCX enthält nur den formellen Zitationstext, keine evidence-Metadaten.
Practice Task Contract V1
Nur wenn artifact_plan.practice_work_orders=true ist, muss die 2.2-Eingabe einen practice_task_contract bereitstellen, Version 1.0, granularity: "per_task". Die Praxisstundenzahl muss eine positive gerade Zahl sein; die Aufgabenfelder sind task_id, project_id, title, lesson_ids, practice_hours, scenario, objectives, required_inputs, tools_or_materials, steps, deliverables, acceptance_criteria, safety_or_compliance. Jede Practice Task hat fest 2 Stunden, die Anzahl der Aufgaben ist exakt practice_hours / 2; jede Aufgabe entspricht einem WorkOrder, project_id dient nur der Gruppierung, die Granularität darf nicht neu geplant werden. lesson_ids sind die IDs der Theorie-Lektionen, die die theoretische Vorbereitung / das Vorwissen bereitstellen, und können sich über mehrere Einheiten erstrecken; bei reinen Praxiskursen ohne Theorie-Lektionen ist es ein leeres Array. Bei practice_work_orders=false sind kein Contract oder Handoff erlaubt, alle practice_task_ids müssen leere Arrays bleiben. Bei true ist die Lektion nur für die Erstellung und Qualitätssicherung des kanonischen Handoffs verantwortlich, der dann vom erkannten WorkOrder Skill durch Agent-Orchestrierung konsumiert wird; der Lesson Python Generator darf keinen subprocess-Aufruf des WorkOrder Python durchführen und auch nicht automatisch den Auftragstext zuordnen. Wenn der WorkOrder Skill nicht verfügbar ist, wird nur der practice-task-contract.json-Handoff ausgegeben und der Status als nicht verfügbar angegeben; es werden keine gefälschten Praxisauftrags-DOCXs erstellt.
Die aktuellen vollständigen 2.2-Regeln finden Sie in docs/content-contract-v2.md; examples/tasks-v21.example.json bleibt als 2.1-kompatibles Beispiel, examples/tasks.example.json bleibt als 2.0-kompatibles Beispiel. Feldbeschreibungen finden Sie in docs/content-contract-v2.md und docs/practice-task-contract-v1.md, maschinelle Einschränkungen in schemas/lesson-plan-input.schema.json und dem kanonischen schemas/shared/practice-task-contract.schema.json des Repositories; schemas/practice-task-contract.schema.json ist nur ein Kompatibilitätseinstieg.
Grenze zwischen Python und Agent
Der Agent ist für die Planung auf Kursebene und den gesamten Lehrtext jeder Einheit verantwortlich; der Generator führt nur Schema-Validierung, Nummerierung, Zeilenumbrüche, Minutenformatierung, Feldzuordnung und Vorlagenschreiben durch. Der formelle V2-Pfad darf keine alten generated_lesson_fields, implementation_cell_values, reflection_cell_values aufrufen, keine flows[:3] verwenden oder Texte basierend auf fehlenden Feldern erstellen. Wenn der Inhalt max_chars oder max_paragraphs des Manifests überschreitet, muss ein Fehler mit Angabe von lesson, field, actual chars, limit ausgegeben werden; es darf nicht abgeschnitten oder stillschweigend gekürzt werden.
Generierungs- und QA-Reihenfolge
Materialien lesen → einmalige Bestätigung der grundlegenden Kursinformationen
-> Kurs-Outlines
-> Content V2.2 JSON
-> Input Contract QA
-> Content Quality QA
-> Template QA
-> Kandidaten-DOCX-Generierung
-> Output Structure + Content-to-DOCX Fidelity QA
-> optionaler LibreOffice Render Smoke
-> atomarer Commit in das endgültige Ausgabeverzeichnis und den externen QA-Bericht
-> wenn practice_work_orders=true, WorkOrder Skill Agent erkennen und aufrufen, dann einheitliche Lesson + WorkOrder Auslieferung
-> visuelle Inspektion der repräsentativen Seiten durch den Agenten
Verwenden Sie scripts/generate_lesson_plans.py zur Generierung. Alle DOCXs werden zuerst in ein Kandidatenverzeichnis im selben Elternverzeichnis wie das endgültige Ausgabeverzeichnis geschrieben; erst nach bestandener Content-QA, Template-QA, Output-Struktur/Lesezeichen/Format-Schutz, Content-Fidelity-QA und dem angeforderten Render Smoke werden sie in das endgültige Ausgabeverzeichnis verschoben. Bei explizitem --qa-report wird der externe Bericht zuerst in einem Staging-Verzeichnis im selben Elternverzeichnis abgelegt und zusammen mit dem Ausgabeverzeichnis committet; schlägt einer der Swaps fehl, werden das alte Ausgabeverzeichnis und der alte Bericht wiederhergestellt. Ein nicht leeres endgültiges Ausgabeverzeichnis erfordert --backup-existing; bei fehlgeschlagenem Swap muss das alte Verzeichnis wiederhergestellt werden. Nach erfolgreichem Commit gibt stdout nur die tatsächlich im endgültigen Verzeichnis vorhandenen DOCX-Pfade aus. Nach der Bestätigung der grundlegenden Kursinformationen wird keine weitere Bestätigung für die DOCX-Generierung eingeholt; die visuelle Inspektion der repräsentativen Seiten durch den Agenten ist eine Abnahme nach dem Commit; bei Feststellung von Überläufen, Abschneidungen, ungewöhnlichen Seitenumbrüchen oder leeren Seiten sollten die V2-Inhalte neu geschrieben und mit --backup-existing neu transaktional generiert werden. qa-report.json enthält nur den Bericht, wird nicht in das DOCX geschrieben.
Das eigenständige scripts/content_quality.py muss lokal deterministisch laufen und keine Online-APIs, Embeddings oder Modelldienste aufrufen. Es prüft auf Wiederholungen im vorhandenen Text, strukturelle Ähnlichkeit nach Entity-Masking, wiederholte lange Sätze, alte Floskeln, Vollständigkeit, intra-lesson-Kohärenz, progressions-Kohärenz, Bewertungsmuster, Dichte der 13 Bewertungsbemerkungen und non-IT-Kontamination; in dieser Runde werden nur die 2.2-Reference-Pflichtprüfung, Source-Region-Statistik und die Theorie/Praxis-Handoff-Prüfung hinzugefügt, ohne die bestehenden Algorithmen für Repetition, Progression, Bewertung oder Implementierungskohärenz zu ändern. non_it_contamination und seine Scope-Metadaten erkennen nur IT-Standardwörter, die nicht im Input, aber durch Vorlage oder Generator in die Ausgabe gelangen, nicht allgemeine Kursklassifikatoren. Die Diagnose behält nur begrenzte Fragmente und stabile SHA-256, gibt keine ganzen Benutzertextabschnitte aus. Alle Detektoren teilen sich eine eindeutige Wiederverwendungsrichtlinie: narrative_strict, terminology_reusable, resource_reusable, reference_reusable, fixed_rubric_reusable und ignore. Lehrmethoden, notwendige Ressourcen, legitime References und feste Rubriken für Anwesenheit/Compliance/Gewohnheiten können Wiederverwendungsnachweise aufzeichnen, aber kein harter Fehler; References können über mehrere Einheiten hinweg vollständig wiederholt werden und sind vollständig von harten Fehlern für exact/item/sentence/field/structural/frequency/whole-course-Entduplizierung ausgenommen; exakte Duplikate innerhalb derselben Einheit und offensichtliche reine Werkzeug-/Geräte-References müssen einen harten Fehler auslösen. Ausnahmen für Kurzkurs-Terminologie dürfen nicht in narrative-Felder gelangen. Es dürfen keine fiktiven Referenzen erstellt werden, um die Kurs-Duplizierungsrate zu senken.
Für die progression müssen sowohl der artifact-inheritance als auch der forward-transition gleichzeitig durch lexikalische/Kohärenz-Nachweise und substantive_anchor-Nachweise bestanden werden; allgemeine Aktionen wie „entwerfen, bedienen, analysieren, prüfen, ablaufen, umsetzen“ können nicht allein als Anchor dienen. Nicht-adjazente prior_lesson_id sind weiterhin erlaubt; wenn die physikalische Sequenzkette review ist, muss der Bericht requires_agent_review=true setzen und from/to/reason/score/declared_prior auflisten. Die endgültige Abnahme durch den Agenten darf die physikalische Sequenzprüfung nicht stillschweigend ignorieren; wenn die tatsächliche Unterrichtsreihenfolge nicht erklärt werden kann, muss die progression neu geschrieben werden.
Nach bestandener deterministischer QA und atomarem Commit führt der Agent eine interne Überprüfung jeder Einheit durch: Was ist in dieser Einheit im Vergleich zur vorherigen neu, welche Kenntnisse oder Ergebnisse der vorherigen Einheit wurden verwendet, was wurde erzielt, wie wird dieses Ergebnis in der nächsten Einheit verwendet. Diese Überprüfung wird nicht in das DOCX geschrieben. Bei Anfrage --render zeigt der Python-Bericht nur render.scope=smoke an, die Seitenzahlmethode ist leichtgewichtig pdf_page_object_regex; dies entspricht nicht einer visuellen QA oder einer bestätigten Paginierung und kann auch nicht beweisen, dass es keine Überläufe, Abschneidungen, ungewöhnlichen Seitenumbrüche oder Tabellenverformungen gibt. Der Agent sollte die erste Einheit, die Einheit mit dem dichtesten Text, die letzte Einheit und bei Kursen mit 12 Stunden zusätzlich 1–2 Zwischeneinheiten auf Clipping, Überläufe, Überlappungen, leere Seiten, ungewöhnliche Zeilenhöhen und Tabellengrenzen überprüfen. Nach der tatsächlichen Überprüfung wird mit scripts/record_visual_inspection.py eine separate visual-inspection.json erstellt; diese Datei zeichnet die repräsentativen Seiten, Checks, Notes, den zugehörigen QA-Bericht, den Ausgabe-Fingerabdruck und einen Zeitstempel auf; Python behauptet nicht automatisch, dass die visuelle Prüfung bestanden ist. Bei visuellen Fehlern muss das V2 JSON geändert, mit --backup-existing neu transaktional generiert und erneut überprüft werden.
Die Standardausgabe-QA liest das ursprüngliche V2 JSON, berechnet das Erwartete über einen reinen Formatierer und vergleicht es dann mit den semantischen Lesezeichen oder den v1.0-Koordinaten; die Funktion zur Erstellung von Lehrinhalten wird nicht erneut aufgerufen. Das Vorlagenlayout, 70 semantische Lesezeichen, Lesezeichen-IDs/Namen, Fingerabdruck, v1.0/v1.1-Kompatibilität und die kanonische Binärdatei sind geschützt. Wenn LibreOffice auf dem System vorhanden ist, wird --render für einen Render Smoke verwendet; wenn kein Renderer vorhanden ist, besteht die strukturelle QA trotzdem, der Bericht markiert render.status=not_executed. Endgültige Aussagen zu Paginierung, Überläufen und visuellem Layout stammen ausschließlich von der Agenten-Inspektion der repräsentativen Seiten.
Die Adapterinstallation ist semantisch festgelegt: Standard ist instruction-only adapter install (nur Regel-/Anweisungsinstallation), die nur die Projektrregeln und minimalen Anweisungen installiert, nicht die vollständige Laufzeit, und nicht garantiert, dass das Zielprojekt den Generator eigenständig ausführen kann; nur mit zusätzlichem --copy-engine handelt es sich um ein full runnable project-local Lesson engine (vollständig lauffähige Engine). Wenn das Zielprojekt direkt scripts/generate_lesson_plans.py aufrufen muss, muss --copy-engine verwendet werden. visual-inspection.json ist eine Agent visual inspection attestation for the current generated DOCX/QA state, die die Agenten-Inspektion der repräsentativen Seiten des aktuell generierten DOCX/QA-Zustands darstellt, kein kryptografischer Nachweis der geprüften PDF/Bilder.
Der Pfad-Preflight wird vor mkdir, Generierung, Verschieben, Backup, Löschen ausgeführt, schützt das Skill-Root, Eingabe-JSON, Schema, die ausgewählte/benutzerdefinierte Vorlage, das Manifest, das kanonische/Kompatibilitätspaket, die Skripte und Tests und lehnt Vorfahren, Nachkommen, aufgelöste symbolische Links sowie lexikalische/8.3-Alias-Überlappungen unter Windows ab. Die Ausgabe darf nicht in geschützte Verzeichnisse oder benutzerdefinierte Vorlagenpakete geschrieben werden.
Befehle
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
Separate Ausgabevalidierung:
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
Manuelle Installation und Abhängigkeitsprüfung (der Installer ändert automatisch keine Python-Umgebungen):
python scripts/install.py --skills-dir <skills-dir>
python <skills-dir>\lesson-plan-docx-generator\scripts\check_dependencies.py
check_dependencies.py prüft nur lesend docx, yaml, jsonschema; bei Fehlen wird pip install -r requirements.txt vorgeschlagen. Im Agenten-Produktionsworkflow ist die Verwendung von --skip-template-validation oder --skip-output-validation verboten; diese beiden Kompatibilitätsparameter dürfen nur in kontrollierten Tests verwendet werden, wenn explizit LESSON_ALLOW_UNSAFE_VALIDATION_SKIP=1 gesetzt ist, und müssen im Bericht als skipped gekennzeichnet werden. Der Input-Contract, die Content-Qualität und der Pfadschutz dürfen nicht übersprungen werden. Temporäre JSONs, PDFs, Bilder und Kandidatenverzeichnisse werden nach Aufgabenende bereinigt; generierte DOCXs werden nicht committet.
Vorlagendateien
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/install.py
scripts/check_dependencies.py
scripts/validate_template.py
scripts/validate_output.py
scripts/validate_visual_inspection.py
scripts/record_visual_inspection.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