WARTUNG.md

# Regelzuständigkeit und Pflege

Ziel: passende Arbeitsblätter zügig entwickeln, bewährte Gestaltung erkennbar
halten und neue Formate zulassen. Es bleiben zwei Skills: Entwicklung und
technische Umsetzung. Keine weitere Steuerungsebene oder didaktische Regelpipeline.

## Ein Standardablauf, klare Zuständigkeiten

Auftrag verstehen → Aufgaben/Platz planen → gestalten/bauen → lösen und prüfen
→ gezielt korrigieren → schlank liefern. Die Entwicklung routet den Auftrag,
der HTML-Skill die Umsetzung. Details nur passend zuschalten.

| Regel | Führende Quelle |
| --- | --- |
| Entscheidende Fragen, Delegation, Abschlussdialog | Entwicklung: `references/entwurfsdialog.md` |
| Zielbezug, freie/unbekannte Formate, Selbstlösen, Redundanz/Muster, Prüfrunden und Nachweis | Entwicklung: `references/lernfoerderliche-aufgaben.md` |
| Spezifische Auswahlqualität | Entwicklung: `references/aufgabenformate/multiple-choice.md`, nur bei Auswahlaufgaben |
| Gemeinsame Handschrift, Referenzauswahl, Nutzerlayout, Name/Datum/Zeit | HTML: `references/layoutorientierung.md` |
| Bildfunktion, Quellen, ImageGen und Bildprüfung | HTML: `references/abbildungen.md`, wenn Bilder geplant/verwendet werden |
| HTML/CSS, Felder, A4-Vertrag, Zustandsvertrag, Lieferumfang | HTML: `references/paketvertrag.md` |
| Umgebung/Übergabe und Wahl eines verfügbaren Prüfwegs | HTML: `references/work-cloud.md` |
| Technischer Abschluss und reale Bildsichtung | HTML: `references/technischer-abschluss.md` und `visuelle-pruefung.md` |
| Eigene Fachinteraktion / Hostabnahme | `gemeinsame-auswertung.md`, Paketvertrag und `druckabnahme.md`, nur für betroffene Wege |
| Konkreter Unterrichtsfall / historische Herkunft | Beispielindex und passende Fallnotiz, nicht allgemeiner Pflichtablauf |

Einstiege dürfen kurze Invarianten nennen und verlinken. Vollständige Erklärungen
nur an der führenden Stelle pflegen; historische Test-/Verlaufsnotizen nicht als
aktuelle Erstellungsregeln laden. Kein neues Formular pro Prüfpunkt.

## Verbindlichkeit und Freiheit

Verbindlich sind fachlich richtige/lösbare Aufgaben, passende Umsetzung des
geklärten Ziels, nutzbarer Schreibraum, geltender Paket-/Druckvertrag und ehrlicher
Prüfstand. Nutzerauftrag und begründete Anpassungen steuern Inhalt und Gestaltung.
Unmögliche Vorgaben offen klären; keine falsche Lösung als freie Variante zulassen.
Didaktische Leitlinien kontextbezogen anwenden. Beispiele liefern Komponenten und
Orientierung, keine Pflichtfolge, Wortzahl, Formatquote oder universelle AFB-Regel.

Die Bildübersicht unter `assets/designreferenzen/` im HTML-Skill ist eine Ableitung
aktueller Referenzansichten; Herkunft und Quellhashes stehen in `herkunft.json`.
Bei Änderungen dieser Vorlagen die betroffenen Ansichten/Übersicht aktualisieren.
Sie ist keine zweite Materialquelle und kein Pflichtlayout.

`references/referenzpakete/` wird mit `scripts/build-reference-packages.py` aus
`assets/vorlagen/` erzeugt. Vollständige Dateien und lokale Abhängigkeiten werden
geprüft; große Fotos nur in dieser Sichtreferenz proportional verkleinert.
Originalvorlagen bleiben führend. Nach deren Änderung Pakete neu erzeugen und
`tests/check-reference-packages.py` ausführen; keine manuelle Pflege der Payloads.
Pillow wird nur beim Erzeugen benötigt, nicht beim Entpacken in Work.

Technische Tests prüfen Teile des Vertrags; sie beweisen keine didaktische Qualität
oder zuverlässige Befolgung in jedem neuen Chat. Modellproben, tatsächliche
Bildsichtung und Rückmeldung der Lehrkraft getrennt von technischen Checks ausweisen.

## Technische Quellen erhalten

Der Parser ist der gebündelte Snapshot des Hostvertrags, keine zweite eigene
Validierung. `create-browser-start.mjs`/Python-Adapter verwenden dieselbe
`browser-shell.json`. `finish-worksheet.py` bündelt vorhandene Einzelprüfer und kurze Berichte; sein
Cache bewahrt ausschließlich unveränderte technische Nachweise. Die tatsächliche
Sichtprüfung bleibt beim Modell. `finalize-material.mjs` besitzt den vollständigen Browserweg,
`render-pdf-evidence.py` den begrenzten Cloud-PDF-Weg. Keine zweite Druck- oder
Sichtprüfschleife; weder `technical_pass` als Sichtfreigabe noch Cloud-PDF als
Browsernachweis ausgeben. Nach Änderung nur Betroffenes nachprüfen.

`assets/beispiele/` bewahrt Originale samt historischen Feldern/Quellen.
`assets/vorlagen/` und `assets/browserstarts/` werden mit
`scripts/build-example-browser-starts.mjs` daraus abgeleitet. Bekannte technische
Anpassungen gehören in diesen Generator, nicht in ungepflegte zweite Kopien.
Die aktuelle Leseverständnisvorlage projiziert ihre vorhandenen Rahmenlinien
auch in die digitale Ansicht; historische Verläufe bleiben nur im Original.
Nach Generatoränderung neu erzeugen und betroffene Ableitungen prüfen;
ungeänderte Materialien behalten ihren belegten Stand. Keine historischen
Originale oder stabilen Feld-IDs unaufgefordert austauschen.
Der Generator projiziert den einheitlichen unteren Seitenabschluss mit
`project-page-footers.mjs`; `page-footer.css` in den aktuellen Vorlagen ist erzeugt.
Quellen-/Seitenhinweise bleiben im gemeinsamen Fußbereich, fachliche Abschlussaufträge
bleiben Inhalt. Der Seitenrahmen trennt Inhalt und Abschluss; ein dehnbarer Puffer
statt allein auto-Margin hält den Abschluss auch im Cloud-Renderer unten. Historische Zählungen bleiben in den Originalen; aktuelle Ableitungen
zählen die tatsächlichen Seiten ihres Materialpakets.

Der portable Block `references/werkzeuge-ohne-dateizugriff.md` entsteht aus zehn
Laufzeitdateien mit `scripts/build-portable-tools.py`. Nur nach Änderung dieser
Dateien neu erzeugen; exakte Extraktion mit `tests/check-portable-tools.py` prüfen.
Die Werkzeugbereitstellung ist kein zusätzlicher Prüfweg.
`resource_bootstrap.py` ist die gemeinsame Erzeugungsvorlage für portable
Werkzeug-/Referenzblöcke: vorhandene Dateien vollständig prüfen, wiederverwenden
oder beschädigte Cachekopien getrennt erhalten und sauber neu bereitstellen.
Beide Builder nach Änderungen daran neu ausführen; keine zweite Cachelogik.

Die Root-`plugin.json` ist kanonisch; eine vorhandene native Kompatibilitätsdatei
bewahrt dieselben Werte in ihrer vorgesehenen Form. Bei Versionierung Manifest-
und Referenzprüfstände synchron halten, Interface/Default-Prompts erhalten.
Account-Veröffentlichung und öffentliche GitHub-Pilotreleases getrennt behandeln.

## Änderungen klein halten

Vor Ergänzung vorhandene Regel suchen. Geltung bestimmen: allgemein, Format,
Gruppe oder Einzelfall. Nutzerfeedback nicht ungefragt globalisieren. Zuständige
Quelle bearbeiten, widersprechende Stellen bereinigen, Links und passende
Szenarien prüfen. Keine datierten Nachtragsregeln an aktive Anweisungen anhängen.
Changelog dokumentiert Änderungen, PRUEFSTAND tatsächliche Tests und offene Grenzen.
Laufzeitdateien nur bei technischem Bedarf ändern; keine neuen Abhängigkeiten
oder generischen Analysewerkzeuge für einfache lokale Korrekturen einführen.