Guten Tag. Neue Produktionssitzung am Kit.
Vor jeder Erzeugung gilt der folgende Rahmen.
 
ABSOLUTE REGEL — NULL FORMATIERUNG AUS DEM GEDÄCHTNIS
==============================
 
PFLICHTLEKTÜRE VOR JEDER GENERIERUNG :
------------------------------
 
1. Kit - Projet - Prompt vollständig LESEN.
2. Das aktive Stylesheet .js vollständig LESEN
   (General / Glossary / YAML / HTML je nach Dokument).
 
3. Die zugehörige Reference .docx LESEN (gleicher Zeitstempel).
   §9.1 = Zeilenformat von makeTable.
   §9.3 = Einrückungskonstanten und Spaltenbreiten.
   §13 = Rückgabeverträge, Spread, Vorgänger, Nachfolger.
 
4. Den aktuellen Projekt-Prompt LESEN.
5. Kit - Documentation - Quality Control §3.13 und §3.14 LESEN
   — absolute Aufrufkette und Umgebungsvoraussetzungen.
 
− Reference .docx — NIEMALS allein aus der .js neu erstellt.
  Die .js enthält den Code. Die .docx enthält das
  Anwendungsrezept: Verträge, Vorgänger, Nachfolger,
  Anti-Patterns. Ohne das Quellbinärformat: kompletter Stopp.
 
Kein Zahlenwert, keine Funktionssignatur, keine Farbe und keine
Einrückungskonstante darf verwendet werden, ohne in der in
dieser Sitzung gelesenen .js geprüft worden zu sein.
 
VALIDIERUNGSKETTE — ABSOLUTE REIHENFOLGE :
------------------------------
 
0. VORAUSSETZUNGEN :
   node -e "console.log(Object.keys(require('docx')).length)"
   -> muss mehr als 200 ergeben.
   node -e "require('adm-zip')" — nur vor einer
   Veröffentlichung der Website ; seit General 1.83
   außerhalb der Dokumentenkette.
 
1. VOR jeder Erzeugung :
   python kit_check_registry.py
   -> exit 0 erforderlich.
 
2. VOR jedem node gen-*.js :
   python kit_check_setters.py gen-document.js
   -> exit 0 erforderlich.
 
3. NACH der .docx-Generierung :
   node kit_validate_docx.js document.docx --version {version}
 
4. NACH der .xlsx-Generierung :
   python kit_validate_xlsx.py document.xlsx
 
5. NACH der Neuerzeugung eines bestehenden Dokuments :
   python kit_check_markup.py quelle.docx erzeugt.docx
   -> ein Text-Diff sieht keinen Auszeichnungsverlust.
 
6. NACH der Neuerzeugung einer Sprachvariante :
   python kit_check_ossature.py referenz.docx variante.docx
 
7. NACH einer Änderung der Extraktion :
   python kit_check_fidelite.py über den Bestand, --version {version}
 
8. VOR jeder Lieferung, die ein Glied eines Paares berührt :
   python kit_check_couplets.py
 
Keine Auslieferung, solange die Kette nicht vollständig
durchlaufen wurde.
 
PRÜFUNGEN VOR DER SKRIPTAUSFÜHRUNG :
------------------------------
 
− Die Ebene eines Body-Elements kommt von der aktuellen
  Überschrift. h1, h2 und h3 setzen sie, die übrigen
  Helfer lesen sie. Seit General 1.70 kein Suffix mehr.
 
− Dokumentabschnitt :
  properties: { ...style.pageProps, titlePage: true }
  Ohne dieses Flag ignoriert Word Kopf- und Fußzeile der ersten
  Seite, und das Deckblatt verliert seine Schlichtheit.
 
− makeTable erhält Zellen im richtigen Format: einfache
  Zeichenkette oder Paar aus Text und Kursiv-Flag. Niemals eine
  numerische Breite innerhalb einer Zelle.
 
− Bedingtes Laden der Datenmodule gemäß
  [Präfix] - Registry.requires.
 
− style.getLuxTimestamp() für den Zeitstempel. Niemals einen
  bestehenden Zeitstempel wiederverwenden.
 
− Vor jedem Funktionsaufruf den Vertragsabschnitt der Reference
  prüfen (General §13 / YAML §8 / HTML §13).
 
− makeImageRun(buffer, breite, höhe, format) für jedes Bild —
  Format aus png, jpg, gif, bmp, svg, verpflichtend.
 
− Dateinamen ohne Unterstriche, außer bei kit_*-Werkzeugen.
− Paarintegrität: die Änderung einer Datei eines Paars
  erfordert die gleichzeitige Aktualisierung des Partners.
 
− Vorabprüfung: ausdrücklich fragen, was sich ändert oder
  hinzukommt. Den genauen Dateinamen bestätigen.
 
ABBRUCHBEDINGUNGEN :
------------------------------
 
Bei Anomalie, Widerspruch oder Mehrdeutigkeit in irgendeinem
Schritt :
 
-> Kompletter Stopp.
-> Klar melden und auf ausdrückliche Bestätigung warten.
-> Ausbleibende Antwort ist ein Stoppsignal.
-> Niemals melden und im selben Satz fortfahren.
 
Wenn ein Formatierungsfall nicht vom Stylesheet abgedeckt ist :
 
-> Als Weiterentwicklungsbedarf des Kits melden. Nicht
   improvisieren.
 
Wenn das zu ändernde Dokument bereits existiert :
 
-> Das .docx-Binärformat im Chat anfordern.
-> Die Arbeitsbaumdatei ist reiner Text, kein Binärformat.
-> Nur das ändern, was ausdrücklich verlangt wurde.

Die Sitzung ist abgedriftet. Wir setzen wieder bei den
Quellen an und rekonstruieren nichts aus dem Gedächtnis.
 
RADIKALE KURSKORREKTUR — RÜCKKEHR ZU DEN QUELLEN
==============================
 
KONTEXT :
------------------------------
 
Ein neuer Chat ist zwingend, wenn die Sitzung zu umfangreich
geworden ist. Vorherige Chats vor dem Neustart löschen.
 
TECHNISCHER HINWEIS :
------------------------------
 
− Dateinamen mit Unterstrichen im Arbeitsbaum sind eine
  Umwandlung der Plattform. Der kanonische Name verwendet
  Leerzeichen.
 
− Die .docx im Arbeitsbaum sind keine Word-Quelldateien,
  sondern Textauszüge der Plattform. Für jede Änderung immer
  das Binärformat im Chat anfordern.
 
SITZUNGSSTART — VERBINDLICHE REIHENFOLGE :
------------------------------
 
1. Kit - Projet - Prompt vollständig lesen.
2. Die Stylesheets .js und ihre Reference .docx lesen.
3. Den aktuellen Projekt-Prompt lesen.
4. Alle noch nicht im Detail gelesenen Dokumente lesen.
5. Alles löschen, was diesen Dokumenten widerspricht.
6. Alles löschen, was zu unaufgeforderter Initiative oder zu
   irgendeiner Abkürzung führen könnte.
 
7. Melden, was entfernt wurde, und was im Gedächtnis bleibt.
 
PRODUKTIONSREGELN :
------------------------------
 
− Formatierung ausschließlich über das aktive Stylesheet.
  Niemals Stylesheets in einem Dokument mischen. Niemals aus
  dem Gedächtnis formatieren.
 
− Generatorskript in jeder Sitzung von Grund auf neu erstellt.
− Bedingtes Laden der Datenmodule gemäß Registry.requires.
− Das .docx-Binärformat wird vor jeder Änderung im Chat
  angefordert. Nur ändern, was ausdrücklich verlangt wurde.
  Kein unerlaubter Informationsverlust.
 
− Nur mit dem aktuellsten in der Sitzung bereitgestellten
  Export arbeiten. Niemals aus einem bereits erzeugten Dokument
  oder aus einer früheren Sitzung rekonstruieren.
 
− Paarintegrität: die Änderung einer Datei erfordert die
  gleichzeitige Aktualisierung des Partners.
 
− Jede Unstimmigkeit vor dem Start der Generierung melden und
  auf das ausdrückliche Go warten.
 
− Prüfen, dass der Validator auf die richtige Dateiversion
  zeigt.
 
− Strikte Namensgebung: nur Leerzeichen und Bindestriche,
  niemals Unterstriche. Frischer Zeitstempel bei jeder
  Auslieferung, ohne Ausnahme.
 
− Die Ebene niemals anders setzen als durch das Ausgeben
  einer Überschrift: h1, h2 und h3 sind die einzigen
  Funktionen, die sie schreiben.
 
VERBINDLICHE PAARE :
------------------------------
 
− Stylesheet .js und zugehörige Reference .docx, gleicher
  Zeitstempel.
 
− Kit Cover Sheet .docx und .png, gleicher Zeitstempel.
− Projekt Cover Sheet .docx und .png, gleicher Zeitstempel,
  unabhängig vom Kit.
 
− Begriffsmodul und Glossar .docx, gleicher Zeitstempel. Ein
  mehrsprachiges Projekt erzeugt ein Glossar je Sprache, alle
  mit demselben Zeitstempel.
 
− Cover Sheet: alle Anweisungen zum Aufbau des Bildes stehen in
  der zugehörigen .docx. Ausgabe ausschließlich über benannte
  Konstanten, niemals freie Komposition.

NACHJUSTIEREN
==============================
 
Lies Kit Prompt §1 (Checkliste) und §2 (Ton) erneut. Wende
sie ab jetzt an.
 
VOR JEDER ANTWORT :
------------------------------
 
− Antworte auf das, worum gebeten wurde. Auf nichts sonst.
− Keine unaufgeforderte Analyse, keine Zusammenfassung
  dessen, was ich gerade gesagt habe, keine Belehrung über
  die Regeln.
− Ein Formatierungswert wird in der .js und der Reference
  dieser Sitzung gelesen, nie aus dem Gedächtnis.
− Weißt du etwas nicht, sage es in einem Satz.
 
Bestätige in einer Zeile und fahre dann fort.

Genaue Anfrage: eine bestehende .docx durch einen gezielten
Patch ändern, ohne sie neu zu erzeugen. Die Bedingungen:
 
REGEL — DIREKTE XML-BEARBEITUNG AN BESTEHENDEM .docx
==============================
 
ERFORDERLICHE BEDINGUNGEN (alle gleichzeitig) :
------------------------------
 
− Die Ziel-.docx wurde von einem Skript mit dem aktiven
  Stylesheet erzeugt. Niemals bei unbekannter Herkunft.
 
− Das Generatorskript ist in der Sitzung nicht mehr verfügbar.
  Ist es verfügbar, ist XML-Bearbeitung verboten: neu
  generieren.
 
− Jeder geänderte Wert stammt aus dem in dieser Sitzung
  gelesenen Stylesheet. Kein Zahlenwert aus dem Gedächtnis.
 
− Die Änderung ist chirurgisch: nur das ausdrücklich Verlangte
  wird berührt. Kein Umschreiben, keine Umformulierung, keine
  unaufgeforderte Ergänzung.
 
− Kein Inhaltsverlust an einem bestehenden Dokument. Alles im
  Quellbinärformat Vorhandene bleibt vollständig erhalten.
 
− Vor jeder Änderung: genau angeben, welche Knoten berührt
  werden, und auf ausdrückliche Bestätigung warten.
 
− Regex ist beim Schreiben in strukturierte Dateien verboten.
  Jede Änderung läuft über den nativen Parser des Formats.
  Regex zum reinen Lesen bleibt erlaubt.
 
− Zum Einfügen eines Hinweises oder Kastens die Helfer aus
  kit_patch_helpers.py verwenden — niemals ein Fragment des
  Zieldokuments klonen.
 
− Nach der Änderung: mit kit_validate_docx.js validieren und
  jede Warnung vor der Auslieferung melden.
 
ABBRUCHBEDINGUNGEN :
------------------------------
 
Ist eine dieser Bedingungen nicht erfüllt :
 
-> Kompletter Stopp.
-> Die Anomalie klar melden.
-> Auf ausdrückliche Bestätigung warten.
-> Niemals melden und im selben Satz fortfahren.

Vor dem Erstellen oder Ändern eines Dokuments ist die
folgende Prüfung Punkt für Punkt zu durchlaufen.
 
VORKONTROLLE — DOKUMENTERSTELLUNG / -ÄNDERUNG
==============================
 
PFLICHTLEKTÜRE VOR JEDER AKTION :
------------------------------
 
1. Kit - Projet - Prompt vollständig LESEN.
2. Das aktive Stylesheet .js vollständig LESEN.
3. Die zugehörige Reference .docx LESEN (gleicher Zeitstempel).
   Diese .docx ist das Anwendungsrezept und hat Vorrang vor
   jeder Ableitung aus dem Code.
   §9.1 = Zeilenformat von makeTable.
   §9.3 = Konstanten und Spaltenbreiten.
   §13 = Rückgabeverträge, Spread, Vorgänger, Nachfolger.
 
4. Den aktuellen Projekt-Prompt LESEN.
5. Kit - Documentation - Quality Control §3.13 und §3.14 LESEN.
 
− Reference .docx — NIEMALS allein aus der .js neu erstellt.
  Ohne das Quellbinärformat: kompletter Stopp.
 
LESEBERICHT — JEDEN PUNKT BEANTWORTEN :
------------------------------
 
− Kit Projet Prompt vollständig gelesen: ja / nein.
− Stylesheet .js vollständig gelesen: ja / nein, und Version.
− Reference .docx vollständig gelesen: ja / nein, und
  Zeitstempel.
 
− Projekt-Prompt gelesen: ja / nein.
− Quality Control §3.13 und §3.14 gelesen: ja / nein.
 
-> Ist ein Punkt "nein": kompletter Stopp. Vorher lesen.
 
BEI ÄNDERUNG EINES BESTEHENDEN DOKUMENTS :
------------------------------
 
− Das .docx-Binärformat im Chat anfordern, falls noch nicht
  vorhanden. Die Arbeitsbaumdatei ist reiner Text und
  niemals eine gültige Quelle.
 
− Paarintegrität: gehört die geänderte Datei zu einem Paar,
  muss der Partner in derselben Sitzung bewertet UND
  aktualisiert werden. Fehlt das Partnerbinärformat:
  kompletter Stopp.
 
− Das Quellbinärformat inventarisieren: Absätze, Tabellen,
  Bilder. Die genauen Zahlen vor dem Skript festhalten.
 
− Die Bilder vor jedem Skript aus dem Binärformat extrahieren.
  Kein Bild ohne ausdrückliche Anweisung auslassen.
 
− Das Skript wird aus dem Inhalt des Binärformats von Grund auf
  neu erstellt. Niemals aus dem Gedächtnis.
 
− Jede geplante inhaltliche Änderung gegenüber der Quellversion
  auflisten und auf die ausdrückliche Freigabe warten.
 
VALIDIERUNGSKETTE :
------------------------------
 
0. VORAUSSETZUNGEN: docx muss auflösen ; adm-zip nur vor
   einer Veröffentlichung der Website.
1. VOR jeder Erzeugung : python kit_check_registry.py.
2. VOR node gen-*.js :
   python kit_check_setters.py gen-document.js
   -> exit 0 erforderlich.
 
3. NACH der .docx-Generierung :
   node kit_validate_docx.js document.docx --version {version}
 
4. NACH der .xlsx-Generierung :
   python kit_validate_xlsx.py document.xlsx
 
5. NACH der Neuerzeugung eines bestehenden Dokuments :
   python kit_check_markup.py quelle.docx erzeugt.docx
   -> ein Text-Diff sieht keinen Auszeichnungsverlust.
 
6. NACH der Neuerzeugung einer Sprachvariante :
   python kit_check_ossature.py referenz.docx variante.docx
 
7. NACH einer Änderung der Extraktion :
   python kit_check_fidelite.py über den Bestand, --version {version}
 
8. VOR jeder Lieferung, die ein Glied eines Paares berührt :
   python kit_check_couplets.py
 
PRÜFUNG VOR DER ENDGÜLTIGEN AUSLIEFERUNG :
------------------------------
 
Das erzeugte Dokument mit dem Inventar der Quelle vergleichen :
 
− Anzahl Abschnitte und Überschriften: identisch ?
− Anzahl Tabellen: identisch ?
− Anzahl Bilder: identisch ?
− Inhalt jedes Abschnitts: kein Verlust ?
− Bildunterschriften: vorhanden und korrekt ?
 
-> Bei Abweichung: melden, korrigieren, erneut prüfen.
-> Auslieferung erst nach ausdrücklicher Bestätigung.
 
FORMATIERUNGSREGELN :
------------------------------
 
− Null Formatierung aus dem Gedächtnis. Jeder Wert in der in
  dieser Sitzung gelesenen .js oder Reference geprüft.
 
− makeTable: rows sind einfache Zeichenketten oder Paare aus
  Text und Kursiv-Flag. Niemals Zellobjekte in rows.
 
− Spaltenbreiten: Summe entspricht exakt der Ebenenbreite.
  Anzahl der Breiten entspricht der Anzahl der Spalten.
 
− Ebene jedes Elements passend zur übergeordneten Überschrift.
− Abschnitt: properties mit titlePage auf true.
 
REGELN FÜR HINWEIS UND KASTEN :
------------------------------
 
− Hinweis: nur wenn die Information wichtig, nicht
  offensichtlich und im Fließtext nicht enthalten ist. Niemals
  direkt unter einer Überschrift, niemals ohne vorangehenden
  Absatz. Im Zweifel -> normaler Absatz.
 
− Kasten: nur wenn der Rat etwas bringt, das im Fließtext nicht
  steht. Bringt er nichts Neues -> entfernen.
 
ABBRUCHBEDINGUNGEN :
------------------------------
 
Bei Anomalie, Widerspruch oder Mehrdeutigkeit :
 
-> Kompletter Stopp.
-> Klar melden und auf ausdrückliche Bestätigung warten.
-> Niemals melden und im selben Satz fortfahren.
 
Wenn ein Formatierungsfall nicht vom Stylesheet abgedeckt ist :
 
-> Als Weiterentwicklungsbedarf des Kits melden. Nicht
   improvisieren.