S08: Teilgebiet 01 Iteration B4 fuer DOCX umgesetzt. Heading 1/2/3 in destengsblue (build/build-reference-docx.py Funktion set_heading_colors mit explizitem color val=0B5394, themeColor accent1 entfernt). Heading-Bottom-Borders direkt am Stil verworfen, weil Word die Border bei hanging-Indent linksbuendig statt zentriert rendert und der right-Indent sowohl Text als auch Border begrenzt. 21 Markdown-HRs aus cv.md entfernt - Quelle der wahrgenommenen Doppellinien war Pandocs DOCX-Konvertierung von --- Zeilen zu VML-rect mit o:hr=t (Embossed-Look). Tabellen-Strich-Zeilen blieben unangetastet. Zwischenfall: NTFS-Mount-Stale-Read der cv.md (20043 statt 20201 Bytes) haette fast die Live-Datei truncated, sofortige Wiederherstellung aus git show HEAD und HR-Removal erneut mit git-Version als Input. H2-Trennlinien via Post-Processing eingefuehrt (build/post-process-docx.py um Logik erweitert): nach jedem H2 wird ein leerer Trenn-Absatz mit linksbuendiger Bottom-Border eingefuegt, schwarz (000000), 8,6 cm Linienlaenge (right-Indent 4196 dxa), 1,25 pt Dicke (sz=10). Sandbox-Verifikation 7 H2 zu 7 Trenner. Visuelle Bestaetigung durch Thomas. teilgebiete/01-lebenslauf.md um Iteration-B4-Block ergaenzt (B4.1 Farben, B4.2 Heading-Border-Sackgasse, B4.3 HR-Removal inkl. Zwischenfall, B4.4 H2-Trennlinien) und Naechste-Schritte-Liste auf C/D verkuerzt.

teilgebiete/01-lebenslauf.md

@@ -184,12 +184,25 @@ Die in S04 mit docx-js erstellte Version hatte strukturelle typographische Mäng
 - `build.ps1` ruft das Skript automatisch nach erfolgreichem DOCX-Build auf (Schritt [3/3]), Console-Output und Log enthalten Statistiken (Anzahl Listen, Bullets, gesetzte keepNext-Markierungen).
 - Sandbox-Verifikation: 26 Listen, 184 Bullets, 93 keepNext-Markierungen, Pattern für Listen mit n ≥ 6 z.B. `KK......KK.` (Liste mit 11 Bullets: erste 2 + Bullets 9 und 10 keepNext). Auf Thomas' System visuell bestätigt: Stationen-Listen werden jetzt sauber an guter Stelle getrennt, keine ungenutzten Seitenenden mehr, kein einzelner Bullet alleine am Seitenrand.
 
+## Iteration B4 (S08) — Heading-Farben und H2-Trennlinien
+
+**B4.1 — Heading-Farben in destengsblue:** Heading 1, 2 und 3 werden in `build/build-reference-docx.py` per Funktion `set_heading_colors` auf `<w:color w:val="0B5394"/>` gesetzt; das `themeColor`-Attribut (Pandoc-Default: `accent1`) wird entfernt, damit die Farbe nicht aus dem Word-Theme kommt. Visuelle Bestätigung im DOCX: alle drei Heading-Levels erscheinen in destengsblue.
+
+**B4.2 — Heading-Trennlinien (Sackgasse):** Erster Versuch war eine Bottom-Border direkt auf den Heading 1/2-Stilen, mit symmetrischem Indent (`left=2268`, `right=2268`, `hanging=2268`) für eine zentrierte Halblinie ca. 50 % der Textbreite. Word hat den `hanging`-Indent jedoch so interpretiert, dass die Border bei der visuellen Position der ersten Zeile (= 0 dxa) beginnt — die Linien erschienen linksbündig statt zentriert. **Verworfen.** Lehre: Words `right`-Indent begrenzt sowohl Text als auch Border, deshalb ist eine Border *schmaler als der Heading-Text* über den Heading-Stil selbst nicht erreichbar. Die Heading-Border-Logik wurde aus dem Skript wieder entfernt; nur die Heading-Farben (B4.1) sind geblieben.
+
+**B4.3 — Markdown-HRs aus cv.md entfernt:** Beim Build der ersten B4-Variante fielen Thomas „Doppellinien über die gesamte Zeilenbreite" auf, die als anklickbare Word-Horizontal-Lines erschienen. Quelle: 21 alleinstehende `---`-Zeilen in `cv.md`. Pandoc rendert Markdown-HRs im PDF als `\begin{center}\rule{0.5\linewidth}{0.5pt}\end{center}` (saubere zentrierte Halblinie 0.5 pt) und im DOCX als VML-`<v:rect ... o:hr="t"/>` (Embossed-Doppellinien-Look). Auf Thomas' Wunsch wurden alle 21 HR-Zeilen aus `cv.md` entfernt — PDF verliert die Trennlinien zwischen Stationen, DOCX verliert die Doppellinien. Die Tabellen-Strich-Zeilen der Multiline-Tabelle für Ausbildung blieben unangetastet (anderes Pattern: `^----------  -----...$`). Sandbox-Verifikation: 21 → 0 `o:hr="t"` Vorkommen im DOCX.
+
+**B4.3-Vorfall — Datei-Verlust und Wiederherstellung:** Beim ersten HR-Removal hat die Sandbox die `cv.md` durch einen NTFS-Mount-Stale-Read truncated gelesen (20043 statt 20201 Bytes — die letzten 5 Zeilen mit „Englisch", „Veröffentlichungen", „Dissertation, fünf Veröffentlichungen, ein Patent, eine Erfindungsmeldung" fehlten). Das Python-Skript hat die HRs aus dieser truncated Version entfernt und die Datei zurückgeschrieben — die echte `cv.md` auf Thomas' System wäre damit ohne den Schluss-Block gewesen. Sofortige Wiederherstellung aus `git show HEAD:artefakte/01-lebenslauf/source/cv.md` (= S06-Commit be4f695, der letzte mit cv.md-Änderung); HR-Removal anschließend erneut auf der git-Version als Input (kein zweiter Sandbox-Read), Output direkt zurückgeschrieben. Live-Datei nach erfolgreichem zweiten Versuch: 20096 Bytes / 288 Zeilen, korrektes Ende. **Lehre für die Pipeline:** Bei jedem Sandbox-write auf NTFS-Mount-Datei mit grösserem Volumen erst die git-Version verifizieren, nicht blind dem Sandbox-Read trauen.
+
+**B4.4 — H2-Trennlinien via Post-Processing:** Thomas wünschte stattdessen Trennlinien unter H2 (für visuelle Trennung der Hauptabschnitte und um H3 wieder klarer abzuheben). Nach einem Demo-Vergleich (linksbündiger Trennstrich vs. Underline-auf-Heading-Text in Text-Breite) Entscheidung für Trennstrich. Finale Parameter: schwarz (`000000`), 8,6 cm Linienlänge (= 4876 dxa, `right`-Indent 4196 dxa bei 9072 dxa Textbreite), 1,25 pt dick (`<w:sz w:val="10"/>` — sz ist in 1/8 pt). Umgesetzt in `build/post-process-docx.py`: Funktion `process_document_xml` ergänzt um eine zweite Logik, die nach jedem H2-Absatz einen leeren Trenn-Absatz mit Bottom-Border einfügt. Trenn-Absatz: `<w:spacing before=0 after=80>`, `<w:ind right=4196>`, `<w:pBdr><w:bottom single sz=10 space=2 color=000000>`, `<w:rPr><w:sz val=2>` (1 pt) für minimale Absatzhöhe. Sandbox-Verifikation: 7 H2 → 7 Trenner. Visuelle Bestätigung durch Thomas: Trennlinien sehen gut aus, Hierarchie zwischen H2 und H3 wieder klar.
+
+**Warum kein Heading-Stil-Border:** Words `right`-Indent gilt sowohl für Text als auch für Border. Eine Border *schmaler als der Heading-Text* ist über den Stil selbst nicht abbildbar, weil Indent den Text mitkürzt. Lösung: separater Trenn-Absatz nach dem Heading. Die Underline-Alternative (Linie genau in Heading-Text-Breite) wurde verworfen, weil sie wie ein unterstrichener Text wirkt und nicht wie ein Trenner.
+
 ## Nächste Schritte
 
-1. **Iteration B4 — Heading-Farben auf DesTEngS-Blau und/oder Trennlinien analog PDF.** Eher Kosmetik bei Vorlage für Consulting-Agenturen, aber für eigene Direktverwendung des DOCX (Website-Download, persönliche Bewerbungen) sinnvoll.
-2. **Iteration C — Foto-Einbindung:** Portraitfoto in `source/cv.md` einbetten (Pandoc-Image-Syntax), Position und Größe im Template absichern (z.B. oben rechts neben Name, ca. 3 cm).
-3. **Iteration D — Hyphenation-Feintuning für PDF:** Kurze Wortteile am Zeilenanfang mit höherer Penalty oder gezielten `\hyphenation`-Ausnahmen reduzieren. Iterativ.
-4. Teilgebiet nach erfolgreichem Output und Freigabe durch Thomas abschließen (R2-OK von Thomas: Status auf „abgeschlossen" im zentral-index.md).
+1. **Iteration C — Foto-Einbindung:** Portraitfoto in `source/cv.md` einbetten (Pandoc-Image-Syntax), Position und Größe im Template absichern (z.B. oben rechts neben Name, ca. 3 cm).
+2. **Iteration D — Hyphenation-Feintuning für PDF:** Kurze Wortteile am Zeilenanfang mit höherer Penalty oder gezielten `\hyphenation`-Ausnahmen reduzieren. Iterativ.
+3. Teilgebiet nach erfolgreichem Output und Freigabe durch Thomas abschließen (R2-OK von Thomas: Status auf „abgeschlossen" im zentral-index.md).
 
 ## Artefakte
 
@@ -199,8 +212,8 @@ Die in S04 mit docx-js erstellte Version hatte strukturelle typographische Mäng
 - `artefakte/01-lebenslauf/source/foto-wrba_2026_6782_1.jpg` — Portraitfoto (umbenannt, noch nicht in cv.md eingebunden).
 - `artefakte/01-lebenslauf/templates/template.tex` — Pandoc-LaTeX-Template für LuaLaTeX (Iteration A inkl. Pandoc-3.x-Hotfix `\newcounter{none}`).
 - `artefakte/01-lebenslauf/templates/reference.docx` — Pandoc-Reference-Doc, **automatisch erzeugt** durch `build/build-reference-docx.py`. Nicht von Hand editieren — Änderungen würden beim nächsten Skript-Lauf überschrieben.
-- `artefakte/01-lebenslauf/build/build-reference-docx.py` — Python-Skript zum Bauen der `reference.docx` (Iterationen B1, B1.5, B2, B3). Manuell aufrufen, wenn Stile geändert werden sollen, danach normalen `build.ps1` laufen.
-- `artefakte/01-lebenslauf/build/post-process-docx.py` — Python-Skript für DOCX-Post-Processing (B3.5 Listen-Bullet-Schutz). Wird automatisch von `build.ps1` als Schritt [3/3] aufgerufen.
+- `artefakte/01-lebenslauf/build/build-reference-docx.py` — Python-Skript zum Bauen der `reference.docx` (Iterationen B1, B1.5, B2, B3, B4.1 Heading-Farben). Manuell aufrufen, wenn Stile geändert werden sollen, danach normalen `build.ps1` laufen.
+- `artefakte/01-lebenslauf/build/post-process-docx.py` — Python-Skript für DOCX-Post-Processing (B3.5 Listen-Bullet-Schutz und B4.4 H2-Trennlinien). Wird automatisch von `build.ps1` als Schritt [3/3] aufgerufen.
 - `artefakte/01-lebenslauf/build/build.ps1` — PowerShell-Build-Skript (PDF + DOCX + Post-Process) mit 3-Sekunden-Pause bei Fehler.
 - `artefakte/01-lebenslauf/output/` — erzeugte Ausgaben plus `build.log`.