marketing_claude/teilgebiete/01-lebenslauf.md

Teilgebiet 01: Lebenslauf-Optimierung

Ziel

Universeller CV (eine Version) für Consulting-Agenturen, der Thomas als freiberuflichen Ingenieurdienstleister und AI Consultant positioniert. Ziellänge: 4–5 Seiten (aktuell 7). KI klar priorisiert, Elektronik-Kompetenz als wertvolles Differenzierungsmerkmal erhalten.

Zielgruppe des CVs

Primär: Recruiting-Mitarbeiterinnen von Consulting-Agenturen (sekundäre Zielgruppe laut marketing.md). Diese scannen CVs in 30–60 Sekunden auf Keyword-Passung und entscheiden dann, ob sie weiterlesen.

Analyse des Ist-Zustands

Stärken

• Portraitfoto vorhanden und professionell
• Berufserfahrung chronologisch klar gegliedert
• Bei einigen Stationen bereits gute Mehrwert-Formulierungen (z.B. Infineon: "Verhinderte eine Verzögerung der IC-Evaluierung")
• KI-Projekte stehen bereits im oberen Bereich

Schwächen

1. Zusammenfassung nicht auf KI ausgerichtet: Kein KI-Keyword in den Branchenaufzählungen, TÜV-Zertifikat fehlt komplett, "Hardware Design" gleichberechtigt mit KI genannt.
2. Seitenbudget falsch verteilt: KI-Inhalte ca. 1,5 Seiten vs. HF/Hardware ca. 4,5 Seiten. Über 60% des CVs beschreiben Tätigkeiten außerhalb des strategischen Fokus.
3. DesTEngS-Block mischt Leistungskatalog mit Projekten: Unterpunkte unter "Generative KI" und "Elektronik Entwicklung" lesen sich wie ein Dienstleistungskatalog, während die Projekte danach nochmals separat erscheinen → Redundanz (z.B. KI-Workshops doppelt).
4. ASMPT Ethernet-Block (Nov 2020–Mai 2024) zu detailliert: Ca. 2 Seiten für ein einzelnes Projekt, dessen Kerninhalt (Ethernet-Feldbus) kein strategischer Fokus ist.
5. Stil "Angestellter" bei älteren Stationen: "Entwicklungsingenieur bei Siemens" statt Consultant-Perspektive.
6. Kenntnisse-Abschnitt verwässert: Veraltete Technologien (AEL, Pascal, Ada, Assembler) stehen neben aktuellen KI-Tools. KI-Strategiebegriffe fehlen (Prompt Engineering, LLM Evaluation, KI-Strategie).
7. Trainings-Abschnitt zu lang: Viele veraltete Einträge (GSM-Kurse 1998, Aplac 2001).
8. Fehlende Mehrwert-Perspektive bei ASMPT: Längste und aktuellste Station beschreibt fast ausschließlich Tätigkeiten, kaum Kundenmehrwert.

Optimierungsstrategie

S1 — Zusammenfassung komplett neu schreiben

• KI und TÜV-Zertifikat in den ersten Satz
• Branchenliste ersetzen durch Kompetenz-Cluster: Generative KI, Software Design, System Integration, Test & Automatisierung
• "30+ Jahre Ingenieurerfahrung" beibehalten als Differenzierer
• "Freiberuflicher Consultant seit 2011" statt "seit 2011 ausschließlich freiberuflich tätig"
• Mehrwert-Aussage ergänzen (was der Kunde davon hat)

S2 — DesTEngS-Block umstrukturieren

• Den generischen Leistungskatalog entfernen (diese Information gehört in den One-Pager, nicht in den CV)
• Stattdessen: KI-Projekte als eigenständige, prominente Einträge mit Kundenname, Zeitraum und Mehrwert
• KI-Workshops mit konkreten Ergebnissen/Outcomes versehen

S3 — ASMPT-Block straffen

• ASMPT Aug 2024–Feb 2026 (KI-Workshop + ArxmlGenerator): Behalten und KI-Anteil hervorheben
• ASMPT Nov 2020–Mai 2024 (Ethernet-Feldbus): Radikal kürzen auf ca. 8–10 Zeilen. Fokus auf übertragbare Kompetenzen: Konzepterstellung, Protokoll-Evaluierung, Tool-Entwicklung, Test-Automatisierung. Tiefe HF/Ethernet-Details entfernen.

S4 — Magna, Infineon, Kathrein: Moderat kürzen

• Magna (2018–2020): LIDAR und xDiagnostics sind aktuell relevant (Automotive, Embedded, Requirements). EMV/Signalintegrität kürzen. Ca. 6–8 Zeilen.
• Infineon (2014–2018): Signal-Integrity-Kern behalten, aber Details zu 77-GHz-Radar und EM-Feldsimulationen kürzen. Mehrwert-Beispiele behalten. Ca. 6–8 Zeilen.
• Kathrein (2015): Stark kürzen auf 2 Zeilen (HF-Tests, Automatisierung mit Matlab/Ruby).

S5 — Alcatel-Lucent, Ubidyne, Toshiba, Siemens, Multilink, FBH, HMI: Kompakt halten

• Alcatel-Lucent (2011–2014): Kürzen auf ca. 6–8 Zeilen. LTE/WiFi-Kontext behalten, Mehrwert-Beispiele behalten, HF-Messdetails stark reduzieren.
• Ubidyne (2006–2011): Führungserfahrung und Teamaufbau hervorheben (10 MA, Prozesserstellung, Projektmanagement). HF-Details radikal kürzen. Ca. 6–8 Zeilen.
• Toshiba (2003–2006): Kürzen auf 4–5 Zeilen. OIF/MIPI-Normungsarbeit und Senior-Rolle betonen.
• Siemens (1998–2000): Kürzen auf 3–4 Zeilen. HF-Modul-Verantwortung behalten.
• Multilink (2000–2002): Kürzen auf 3–4 Zeilen. System-Level-Arbeit betonen.
• FBH Promotion (1994–1998): Kürzen auf 2–3 Zeilen. Promotion erwähnen, Details in Ausbildungs-Abschnitt.
• HMI (1990–1992): 1–2 Zeilen oder in Ausbildung integrieren.

S6 — Kenntnisse-Abschnitt reorganisieren

• KI ganz oben, erweitert um: KI-Strategie & Potenzialanalyse, Prompt Engineering, LLM Evaluation & Benchmarking
• Software Design: Python prominent, C++/Matlab behalten, veraltete Sprachen (Ada, Pascal, AEL, Assembler, Basic) entfernen
• IT: Kürzen, nur aktuelle Tools
• Engineering Software: Kürzen, nur noch die wichtigsten
• Messtechnik: Stark kürzen oder in eine Zeile zusammenfassen
• Veraltete Einzeltechnologien entfernen

S7 — Trainings kürzen

• Behalten: AI Consultant TÜV-Zertifikat (2025), Management (2008), Führung und Organisation (2007), Ansys SIwave (2016), Keysight ADS (2016)
• Entfernen: Erste-Hilfe, Marketing 2011, Pulsonix, HFSS, MS Project, Gedächtnistraining, Aplac, Persönlichkeitsentwicklung, ADS RF Class 1999, BWL-Seminar, Mobilfunk-Kurse

S8 — Durchgängig Consultant-Perspektive

• Bei allen Stationen seit 2011: "Consultant bei X" beibehalten (ist bereits so)
• Bei Stationen vor 2011: Titel beibehalten (waren ja tatsächlich Anstellungen), aber in der Beschreibung wo möglich Mehrwert und Verantwortung betonen statt reine Tätigkeitsbeschreibung

Getroffene Entscheidungen

• Seitenumfang: 4–5 Seiten Ziel, HF/Hardware komprimiert, KI und Software/SI in voller Detailtiefe (wegen Keyword-Matching durch Agentursoftware)
• Stationen: Alle Stationen beibehalten; HF-lastige Stationen (Kathrein, Siemens, FBH, HMI) nur gekürzt wo anderer Inhalt vorhanden; bei reinen HF-Stationen bleibt der Inhalt (sonst leere Station)
• DesTEngS-Block: Umstrukturiert zu KI-Workshops (mit Kundennamen), KI-Beratungen, KI-Anwendung, KI-gestützte Dokumentationen
• ASMPT Ethernet (2020–2024): Detailliert belassen, da SI/Software-Inhalte für Agentursoftware-Matching relevant; Success Stories erhalten
• Kenntnisse KI: Erweitert um KI-Strategieentwicklung, Prompt Engineering, Context Engineering, LLM-Evaluierung, Multimodale KI, DSGVO, NLP, Edge AI, On-Premise KI-Infrastruktur, Agentic AI, Generative AI (GenAI), RAG mit Embedding Models und Vektor-Datenbanken
• Kenntnisse Software Design: Prozessautomatisierung (UI.Vision, PyAutoGUI, n8n, Langflow), REST API Integration, Python KI-Module (transformers, openai, anthropic, tiktoken), IronPython aus Kenntnissen entfernt (bleibt in Infineon-Station)
• Kenntnisse Methodik: Neuer Abschnitt mit 7 Einträgen (Konzepterstellung, Spezifikationserstellung, Systematische Fehleranalyse, Technologie-Evaluierung und -Auswahl, Machbarkeitsstudien, Technische Dokumentation, Projektmanagement)
• Trainings: Gekürzt auf 6 Einträge (AI Consultant TÜV 2025, Ansys SIwave 2016, Keysight ADS 2016, Management 2008, Führung 2007, Gedächtnistraining 2006, Persönlichkeitsentwicklung 2000)
• Suchbegriff-Optimierung: Begriffe so formuliert, dass Agentursoftware bei gängigen Suchstrings Treffer findet (z.B. „KI-Strategie", „Prompt Engineering", „Agentic AI", „Edge AI", „GenAI", „NLP")
• Evaluation vs. Evaluierung: Deutsch konsequent „Evaluierung", englisch „Evaluation Board" beibehalten
• Berufstätigkeit aufgeteilt: „Projekte als freiberuflicher Consultant" (ab 2011) und „Berufliche Stationen vor der Selbständigkeit" (vor 2011)
• LLM-Evaluierung: Kein eigener Punkt mehr, sondern in den LLM-Hauptpunkt integriert
• LinkedIn/Freelance.de: Korrekte Profil-URLs eingebaut, als klickbare Links
• Portraitfoto: foto-wrba_2026_6782_1.jpg ausgewählt und eingebettet
• Seitenumfang (final): 7 Seiten — von Thomas akzeptiert, da Inhalt sehr gut passend

Wendepunkt S05 — Tool-Wechsel zu Pandoc + LuaLaTeX

Die in S04 mit docx-js erstellte Version hatte strukturelle typographische Mängel (Widows/Orphans, Spalten-Layout bei Ausbildung, fehlende Kontaktlabels, Schriftsatz bei Einheiten wie „6 GHz", etc.). Eine Analyse hat ergeben, dass docx-js für den gewünschten typographischen Anspruch das falsche Werkzeug ist — die Grenzen liegen zum Teil am Tool, zum Teil strukturell am .docx-Format selbst.

Neue Strategie 1: Eine Quelle (Markdown), zwei Zielformate mit unterschiedlichem Anspruch:

• PDF via Pandoc + LuaLaTeX mit eigenem LaTeX-Template → tadellose Typographie, IBM Plex Sans (DesTEngS-neue-Hausschrift, siehe Teilgebiet 25), für Direktkanäle (Website, persönliche Bewerbungen).
• DOCX via Pandoc mit reference-doc.docx → semantisch sauber, Calibri, bewusst schlicht, für Consulting-Agenturen (die das Layout beim Umbau in ihr Template ohnehin überschreiben).

Getroffene Entscheidungen (ergänzt in S05)

• Quellformat: Markdown (aufbauend auf V10-Inhalt, um Änderungen in Git lesbar zu halten und Pandoc-native Pipelines zu nutzen).
• PDF-Toolchain: Pandoc → LuaLaTeX (wegen fontspec/OpenType und voller microtype-Unterstützung).
• DOCX-Toolchain: Pandoc mit Reference-Doc (Starter-Version von Pandoc generiert; Styles iterativ in Word anzupassen).
• Schriften: PDF nutzt IBM Plex Sans (Plex Sans/Mono), DOCX nutzt Calibri (weil Agenturen eh umbauen und Calibri universell verfügbar ist — keine Font-Substitutions-Risiken).
• TeX-Distribution: MiKTeX (Windows, on-the-fly package installation).
• Ordnerstruktur: artefakte/01-lebenslauf/ wurde in Unterordner gegliedert: source/, templates/, build/, output/, entwuerfe/ (für die MD-Entwürfe v1–v10) und archiv/ (für die alten docx-js-Ausgaben).
• Foto-Umbenennung: Die Foto-Datei wurde von ©foto-wrba_2026_6782_1.jpg auf foto-wrba_2026_6782_1.jpg umbenannt, um Encoding-Probleme in Build-Pfaden zu vermeiden.
• Draft-Marker in cv.md entfernt: Der H1-Suffix „— Entwurf V10", die Review-Blockquote und der Platzhalter-Bullet „- Portraitfoto" wurden aus source/cv.md entfernt (reine Meta-Elemente, kein CV-Inhalt).
• Status Teilgebiet 01 auf „in Bearbeitung" gesetzt im zentral-index.md.

Iteration A (S06) — Ausbildung als 2-Spalten-Layout

Erster Versuch (verworfen) — Definition-List: Quellseitig als Pandoc-Definition-List umgesetzt, im PDF mit enumitem-Konfiguration der description-Liste sauber 2-spaltig. Im DOCX rendert Pandoc Definition-Lists aber als zwei separate Absatzstile (DefinitionTerm und Definition) — Word kann zwei Absätze nicht ohne weiteres optisch in eine Zeile zwingen, ein echtes 2-Spalten-Layout im DOCX ist mit Definition-Lists nicht erreichbar. Das war beim ersten Build-Test sichtbar (Datum fett auf eigener Zeile, Inhalt darunter).

Revision — Tabellen-Variante (aktiv): Die Markdown-Quelle nutzt eine Pandoc-Multiline-Tabelle ohne Header (zwei Strich-Zeilen als äußere Begrenzung, vier Datenzeilen, blank-lines zwischen Einträgen). Pandoc rendert daraus eine longtable mit Minipage-Auto-Wrap im PDF und eine native Word-Tabelle im DOCX — beides ergibt echtes 2-Spalten-Verhalten und ist bei Agenturen mindestens so robust wie eine Definition-List (eine 4-zeilige 2-Spalten-Tabelle ist Word-Standardrepertoire).

Quellseitig (source/cv.md): Multiline-Tabelle mit Strich-Verhältnis 10:70. Pandoc berechnet daraus Spaltenbreiten von ca. 14 % (Datum) und 80 % (Inhalt) der Textbreite.

PDF-Pfad (templates/template.tex): Neuer Abschnitt „Tabellen": booktabs und longtable werden geladen, die Linienbreiten (\heavyrulewidth, \lightrulewidth, \cmidrulewidth) auf 0 pt gesetzt, ebenso \aboverulesep und \belowrulesep. \LTpre/\LTpost auf 0.4 em reduziert (Default ist \bigskipamount). Damit rendert die Tabelle rahmenlos und mit kompaktem Vertikalabstand.

DOCX-Pfad: Pandoc rendert die Tabelle als native Word-Tabelle (<w:tbl> mit vier <w:tr> und acht <w:tc>), Default-Tabellenstil ohne expliziten Pandoc-Stil. Das Feinstyling (Spaltenbreite, Rahmen aus, vertikale Abstände) erfolgt in der reference.docx (Iteration B), entweder über den Default-Tabellenstil oder einen benannten Tabellenstil.

Sandbox-Verifikation der Revision: Pandoc-LaTeX-Output zeigt \begin{longtable}[]{@{}ll@{}} mit vier Datenzeilen, Minipage-Spalten (0.14 + 0.80), korrekte URL-Escapung. Pandoc-DOCX-Output enthält genau eine Tabelle mit vier Zeilen und acht Zellen im Ausbildungs-Bereich, keine Reste der zwischenzeitlich genutzten Definition-List-Stile.

Visuelle Bestätigung im PDF: Layout im Tabellen-Format wie gewünscht (linke Spalte Datum normal, rechte Spalte Titel fett, Beschreibung normal). Visuelle Bestätigung im DOCX steht nach erstem Build der Revision aus.

Hotfix Build-Fehler (S06, Teil 1): Beim ersten Build der Tabellen-Revision schlug LuaLaTeX mit ! LaTeX Error: No counter 'none' defined. in der Spaltenangabe p{(\columnwidth - 2\tabcolsep) * \real{0.8554}} fehl. Erste Vermutung: Thomas' Pandoc-Version (3.x) emittiert für Tabellen-Spaltenbreiten einen calc-basierten Multiplikator, der das Pandoc-Hilfsmakro \real und das calc-Paket voraussetzt. Ergänzung von \usepackage{array}, \usepackage{calc} und \providecommand{\real}[1]{#1} im Tabellen-Block des Templates. Sandbox-Verifikation mit synthetischem Pandoc-3.x-Spalten-Format kompilierte zu PDF ohne Fehler — die echte Ursache war damit aber noch nicht behoben.

Hotfix Build-Fehler (S07, eigentliche Ursache): Der Folgebuild auf Thomas' System lieferte unverändert ! LaTeX Error: No counter 'none' defined. Recherche (Pandoc-Issue #11201) zeigte den eigentlichen Auslöser: Pandoc 3.x emittiert für unnummerierte Tabellen direkt vor dem \begin{longtable} die Zeile \def\LTcaptype{none} — ohne den Counter none zu definieren. Pandocs eigene Default-Vorlage definiert ihn (commit d835461 in 3.8.2.1 nachgezogen), aber Custom-Templates müssen das selbst tun. Sobald longtable intern \refstepcounter{\LTcaptype} aufruft, bricht LaTeX ab. Behoben durch eine Zeile \newcounter{none} direkt nach dem \providecommand{\real} im Tabellen-Block. Sandbox-Reproduktion lieferte exakt den gleichen Fehlertext und wurde durch den Fix behoben. Anschließender Build auf Thomas' System: PDF erfolgreich erzeugt, Ausbildungs-Layout im PDF visuell bestätigt.

Lehre für die Sandbox-Verifikation: Pandocs \def\LTcaptype{none}-Bug tritt nur auf, wenn longtable den Counter intern referenziert. Sandbox-Pandoc 2.9 emittiert weder die calc-basierten Spaltenbreiten noch \def\LTcaptype{none} — die Sandbox kann diesen Bug also nicht reproduzieren, indem sie einfach pandoc auf cv.md laufen lässt. Synthetische Mini-Tex-Beispiele bleiben für Pandoc-3.x-spezifische Bugs die einzige verlässliche Verifikationsquelle.

Visuelle Bestätigung im DOCX: Tabelle sieht gut aus, nur die Default-Word-Tabellenrahmenlinien sind noch sichtbar; der Rahmen-Aus geht in Iteration B über die reference.docx.

Visuelle Bestätigung im PDF (S07): Ausbildungs-Layout entspricht der Vorgabe — linke Spalte Datum normal, rechte Spalte Titel fett mit Beschreibung. Iteration A damit inhaltlich abgeschlossen.

Build-UX-Fix (S07): build/build.ps1 ergänzt um Start-Sleep -Seconds 3 nach jedem fehlschlagenden Build-Schritt (Pflichtdatei-Check, PDF, DOCX). Bei Doppelklick auf checkpoint.cmd-artigen Aufruf schließt sich das PowerShell-Fenster sonst sofort und Fehlermeldungen sind nicht lesbar. Bei mehreren Fehlern in einem Lauf akkumulieren sich die Pausen — gewollt.

Iteration B (S07) — reference.docx programmatisch bauen

Ansatz: Anstatt die reference.docx manuell in Word zu pflegen (nicht versionierbar, nicht reproduzierbar), wird sie durch ein Python-Skript build/build-reference-docx.py aus Pandocs Default-Reference erzeugt und gezielt angepasst. Nur Python-Stdlib (zipfile, xml.etree.ElementTree, subprocess, re) — keine pip-Abhängigkeit. Das Skript läuft unter Sandbox-Pandoc 2.9 und Thomas' Pandoc 3.x gleichermaßen, weil es die Pandoc-Default-Reference per pandoc --print-default-data-file reference.docx zur Laufzeit zieht. Manueller Aufruf vor jedem build.ps1, wenn Stile geändert wurden.

B1 — Schriften und Tabellen:

• Theme-Schriften majorFont und minorFont beide auf Calibri umgestellt (Pandoc 3.x setzt sie als Default auf Aptos Display und Aptos, Sandbox-Pandoc 2.9 auf Calibri und Cambria).
• Defensive Maßnahme: alle direkten Schriftnamen-Referenzen in styles.xml (z.B. <w:rFonts w:ascii="..." />) auf Calibri umgestellt, ausgenommen Code-Schriften (Consolas, Courier, ...). In der Pandoc-3.x-Variante kommt das mit 0 Treffern aus, in zukünftigen Pandoc-Versionen mit direkten Heading-Schriftreferenzen würde es greifen.
• Tabellen-Default-Stil Table bekommt explizite <w:tblBorders> mit val="none" auf allen Sides (top, left, bottom, right, insideH, insideV). Word-Editor zeigt die Default-„Tabellenbegrenzungen" weiterhin als Anzeige-Hilfe an (kein Druck-Rendering), Druckansicht und PDF-Export sind sauber rahmenlos.

B1.5 — Schriftgrößen analog PDF:

• DocDefault <w:sz> auf 22 (= 11 pt Body, analog template.tex).
• Heading 1/2/3 explizit auf 30/26/24 (= 15/13/12 pt). Damit ist die Heading-Hierarchie visuell ähnlich zum PDF, ohne den Word-Default-Sprung von 20 pt nach 12 pt.
• Effekt: DOCX schrumpft von 10 auf 9 Seiten (im PDF sind es 7).

B2 — Header, Footer, Page-Setup:

• word/header1.xml (Default ab Seite 2): links „Dr.-Ing. Thomas Langer", rechts „Lebenslauf" (Tab-Stop am rechten Textrand).
• word/header2.xml (erste Seite): leerer <w:p/> über <w:titlePg/> aktiviert.
• word/footer1.xml: rechtsbündig „Seite n / m" mit Word-Feldern PAGE und NUMPAGES. Wird über zwei footerReference-Einträge (type="default" und type="first") auf alle Seiten inkl. Seite 1 angewendet — ohne den type="first"-Eintrag würde titlePg Seite 1 ohne Footer lassen.
• Page-Setup explizit in <w:sectPr>: A4 (pgSz w:w="11906" w:h="16838"), Ränder 2.2 cm oben/unten, 2.5 cm links/rechts (analog PDF). Damit ist der Tab-Stop an 9072 dxa (= 16 cm Textbreite) deterministisch unabhängig von Word-Locale-Defaults; ohne explizites Page-Setup waren die Tab-Stops vorher etwa 5 mm zu weit links.
• Beziehungen werden in word/_rels/document.xml.rels mit dynamisch ermittelter nächster freier rId registriert; Content-Types-Overrides in [Content_Types].xml ergänzt; <w:sectPr> in word/document.xml regex-basiert ersetzt (idempotent gegenüber Pandoc-Defaults <w:sectPr/> und längeren Varianten). Pandoc übernimmt die letzte sectPr aus der reference.docx ins generierte DOCX — End-to-End-Test in der Sandbox bestätigt: alle Header/Footer-Refs, pgMar und titlePg sind im finalen DOCX vorhanden.

Visuelle Bestätigung im Word (S07):

• Body: Calibri 11 pt; Headings 1/2/3: Calibri 15/13/12 pt.
• Ausbildungs-Tabelle in Druckansicht und PDF-Export rahmenlos.
• Seite 1 ohne Header, mit Footer.
• Seite 2 ff. mit Header (Name links, „Lebenslauf" rechts) und Footer (Seite n / m).
• Tab-Stops „Lebenslauf" und Seitenzahl bündig am rechten Textrand.

B3 — Schusterjungen- und Witwen-Schutz für DOCX:

• DocDefault <w:widowControl/> aktiviert (klassische Witwen/Waisen-Logik in mehrzeiligen Absätzen).
• Heading 1/2/3 und FirstParagraph (Pandoc-Stil für ersten Absatz nach einem Heading — deckt unsere Kenntnisse-Subsection-Labels ab) bekommen <w:keepNext/> und <w:keepLines/>. Damit bleibt jede Überschrift mit dem nachfolgenden Inhalt zusammen.

B3.5 — 3-3-Regel für Listen-Bullets:

• Erster Versuch (Compact-Stil mit keepNext+keepLines) hat Listen komplett unteilbar gemacht — Folge: Job-Stationen begannen jedes Mal auf einer neuen Seite, Seitenenden ungenutzt. Auf Wunsch von Thomas auf eine 3-3-Regel umgestellt: bei Listen mit ≥ 6 Bullets darf getrennt werden, aber mindestens 3 Bullets bleiben jeweils zusammen vor und nach dem Umbruch. Bei Listen mit < 6 Bullets bleibt alles zusammen (sonst nicht erfüllbar).
• Da das stilbasiert nicht abbildbar ist (alle Bullets haben pStyle="Compact"), läuft die Logik in einem Post-Processing-Skript build/post-process-docx.py, das nach dem Pandoc-DOCX-Build die document.xml modifiziert: Sequenzen aufeinanderfolgender Listen-Bullets (Absätze mit <w:numPr>) werden gefunden, pro Sequenz bekommen die ersten 2 und die N-3-/N-2-Bullets <w:keepNext/>. Bullets in Tabellen-Zellen werden defensiv ausgenommen (faktisch bei uns leer, weil unsere Tabellen-Zellen Compact-Absätze ohne numPr enthalten).
• 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 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

Aktive Pipeline-Dateien

• artefakte/01-lebenslauf/source/cv.md — Aktive Quelldatei (aufbauend auf V10, Draft-Marker entfernt).
• 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, 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.

Historische Entwürfe (unter artefakte/01-lebenslauf/entwuerfe/)

• cv-entwurf-v1.md bis cv-entwurf-v10.md — zehn iterative Entwürfe von Agent und Thomas, freigegeben mit V10.

Archiv (unter artefakte/01-lebenslauf/archiv/)

• Lebenslauf_Dr-Ing_Thomas_Langer.docx, Lebenslauf_Dr-Ing_Thomas_Langer.pdf — alte docx-js-Ausgaben (dokumentieren die typographischen Mängel, dienen als Vergleichsreferenz für die neue Pipeline).
• Lock- und Temp-Dateien von LibreOffice/docx-js als verwaiste Reste.