411 lines
52 KiB
Markdown
411 lines
52 KiB
Markdown
# 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](https://github.com/jgm/pandoc/issues/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="3C68AE"/>` 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.
|
||
|
||
## Iteration B5 (S08) — Trainings als Tabelle
|
||
|
||
**Anforderung:** Die Trainings-Sektion war als Bullet-Liste im Format `- Datum — Beschreibung` formatiert. Auf Wunsch von Thomas analog zur Ausbildungs-Sektion als Multiline-Tabelle umgestaltet, damit beide Sektionen visuell konsistent sind.
|
||
|
||
**Umsetzung:** Trainings-Bullet-Liste in `source/cv.md` durch eine Pandoc-Multiline-Tabelle mit Strich-Verhältnis 10:70 ersetzt (gleiches Format wie Ausbildung). Datum in Spalte 1, Inhalt in Spalte 2. Inhalte normal (nicht fett), nach kurzem Feedback-Zyklus mit Thomas. Mai-2000-Eintrag braucht 4 Padding-Leerzeichen statt 3, weil „Mai 2000" 8 Zeichen lang ist (alle anderen 9). Sandbox-Verifikation: 1 → 2 Tabellen im DOCX, 1 → 2 longtables im LaTeX. Visuell durch Thomas bestätigt.
|
||
|
||
## Iteration B6 (S08) — Bullet-Einzüge verkleinern
|
||
|
||
**Anforderung:** Pandoc-Default-Bullet-Einzüge waren großzügig — Thomas wollte das kompakter, um Platzverschwendung zu reduzieren. Konkrete Wunschwerte: E1 Einzug 0,25 cm + Sondereinzug 0,35 cm; E2 Einzug 0,80 cm + Sondereinzug 0,40 cm.
|
||
|
||
**Umsetzung-Pfad:** Pandoc generiert die `numbering.xml` selbst und IGNORIERT die Werte aus der `reference.docx`. Daher kann das nicht über `build-reference-docx.py` geregelt werden, sondern muss im Post-Processing nach dem Pandoc-Build stattfinden. `build/post-process-docx.py` um eine dritte Modifikation erweitert: Funktion `process_numbering_xml` parst die `numbering.xml` aus dem DOCX, iteriert alle `<w:abstractNum>` und ersetzt für jedes `<w:lvl>` (ilvl 0–8) die `<w:ind>`-Werte aus einer Konstanten-Tabelle `BULLET_INDENTS`.
|
||
|
||
**Word-Konvention (wichtig — kostete eine Iteration):** Word zeigt im Absatz-Dialog „Einzug links" als `(left - hanging)` (= Bullet-Position) und „Sondereinzug Hängend" als `hanging`. Daher rechnen wir: `left = (gewünschter Einzug + gewünschter Hanging-Indent)` in dxa. Bei E1 mit 0,25 + 0,35 cm ergibt sich also `left = 340 dxa`, `hanging = 198 dxa`. Erster Versuch hatte `left = 142 dxa` gesetzt — Word zeigte dadurch Einzug `-0,1 cm`, weil das Mental-Modell die Word-Logik vertauscht hatte. Korrigiert in zweiter Iteration.
|
||
|
||
**Sandbox-Verifikation:** 2 abstractNum-Einträge in `numbering.xml` (Pandoc nutzt 990 für „plain" und 991 für „bullet" Listen), 18 lvls insgesamt modifiziert. Auf Thomas' System visuell bestätigt: Word zeigt jetzt für E1 Einzug 0,25 cm + Sondereinzug 0,35 cm, für E2 Einzug 0,80 cm + Sondereinzug 0,40 cm. Kein Bullet klebt am Text.
|
||
|
||
**Hinweis (S08):** Pandoc verwendet im DOCX-Output `o` als E2-Bullet-Marker (nicht `–` wie im PDF-LaTeX-Pfad). Das ist kein Problem — beide Marker passen mit dem Sondereinzug 0,4 cm.
|
||
|
||
## Iteration Links (S09) — Klickbare Hyperlinks im DOCX und PDF
|
||
|
||
**Anforderung:** In `cv.md` standen Adressen und URLs als Plain-Text. Im PDF (LuaLaTeX/`hyperref`) wurden sie automatisch klickbar, im DOCX in Word jedoch unsichtbar als Hyperlink — kein blaues Underline, kein Hover, kein Klick. Beim Word-zu-PDF-Export griff Words eigene URL-Erkennung und machte sie im exportierten PDF doch klickbar; diese Inkonsistenz hatte Thomas richtig wahrgenommen. Außerdem fehlte ein Link auf das TÜV-Zertifikat.
|
||
|
||
**Diagnose Hyperlink-Sichtbarkeit im DOCX:** Pandoc übernimmt nackte URLs ohne die Extension `autolink_bare_uris` 1:1 als Text in die DOCX, ohne `<w:hyperlink>`-Markup. Lösung: explizite Markdown-Link-Syntax in der Quelle, dann emittiert Pandoc echte Hyperlink-Elemente.
|
||
|
||
**Diagnose TÜV-Zertifikat-Link in Word:** Direkt-URL `perscert-tuv.certif-id.com/...` funktioniert im Browser, schlägt aber bei Word-Ctrl+Klick mit „Die angeforderten Informationen können nicht heruntergeladen werden" fehl. Ursache: Word führt vor dem eigentlichen Klick eine Pre-Flight-Anfrage über `urlmon.dll`/WinINet aus. Die certif-id.com-Domain liegt hinter Cloudflare-Bot-Schutz, der diese Anfrage als Bot klassifiziert und mit 403 abweist. Würde sich auch beim Empfänger (Recruiter) reproduzieren.
|
||
|
||
**Strategie für TÜV-Link (Optionen diskutiert):**
|
||
|
||
- A — Self-hosted 301-Redirect auf `destengs.de`: würde Word-seitig funktionieren, kann aber unseriös wirken; zur Verifikation soll möglichst die Aussteller-Website verlinkt sein.
|
||
- B — LinkedIn-Safety-Redirect mit gestrippten Session-Parametern: schnell, aber Abhängigkeit von einem nicht stabilen LinkedIn-Endpoint.
|
||
- C — Link weglassen: verschenkt das Verifikationsangebot.
|
||
- D (gewählt) — Direkt-Link auf certif-id.com beibehalten mit erklärendem Display-Text, der den Empfänger über die Word-Einschränkung informiert: „Link zum Zertifikat (funktioniert nur im Browser)". Manueller Copy-and-Paste der URL in den Browser funktioniert. Thomas hat zusätzlich eine kürzere Direkt-URL vom TÜV besorgt: `https://perscert-tuv.certif-id.com/expert/public/share/7MR0WDzG106JDCqV_RW7` (statt der ursprünglichen 130-Zeichen-Hash-URL).
|
||
|
||
**Display-Text-Stil:**
|
||
|
||
- Web-Links: kurze sprechende Labels mit sichtbaren äußeren eckigen Klammern als einheitlicher Stil über alle Web-Link-Anzeigetexte. Markdown-Syntax `[[text]](url)` rendert mit Pandoc als Link mit Display-Text `[text]` inkl. der äußeren Klammern (balanced brackets im Link-Text sind in CommonMark erlaubt).
|
||
- E-Mail: Pandoc-Autolink-Form `<email@domain>` (Sonderfall — keine Klammern, da die Adresse selbst die Information ist).
|
||
- Telefon: `[+49 ...](tel:+49...)` für mobile Clients (Display-Text mit Leerzeichen, URL ohne — RFC 3966).
|
||
|
||
**Konkrete Änderungen in `cv.md`:**
|
||
|
||
- E-Mail: `Thomas.Langer@destengs.com` → `<Thomas.Langer@destengs.com>`.
|
||
- Telefon: `+49 89 413 27 59 20` → `[+49 89 413 27 59 20](tel:+4989413275920)`.
|
||
- Freelance.de: nackte URL → `[[Link zum Profil]](URL)`.
|
||
- Website: `https://destengs.com` → `[[destengs.de]](https://destengs.de)` — bewusster Wechsel auf die deutsche Domain (stimmiger zur deutschen Primärsprache).
|
||
- LinkedIn: nackte URL → `[[Link zum Profil]](URL)`.
|
||
- Ausbildung TÜV-Zeile: trailing `TÜV-Zertifikat` → `[[Link zum Zertifikat (funktioniert nur im Browser)]](https://perscert-tuv.certif-id.com/expert/public/share/7MR0WDzG106JDCqV_RW7)`.
|
||
- Ausbildung Promotion-Zeile: nackte URL `depositonce.tu-berlin.de/.../Dokument_9.pdf` → `[[Dissertation]](URL)`.
|
||
|
||
**DOCX-Hyperlink-Stil:** Pandoc-Default belassen (klassisch blau-unterstrichen). Keine Anpassung in `build-reference-docx.py` nötig.
|
||
|
||
**Zwischenfall — zweite Edit-Tool-Truncation in S09:** Beim zweiten Edit-Tool-Aufruf in dieser Session auf `cv.md` (TÜV-Zeile + Promotion-Zeile) hat das Tool die Datei still am Ende gekürzt; die Schluss-Zeile „Dissertation, fünf Veröffentlichungen, ein Patent, eine Erfindungsmeldung" wurde mitten im Wort abgeschnitten. Symptom identisch zum S08-Vorfall mit derselben Datei. Reparatur identisch zum S08-Pattern: git HEAD-Version als Input, alle 7 Link-Änderungen in einem Python-Script atomar via `os.replace` zurückgeschrieben, mit `count(old) == 1`-Eindeutigkeits-Check pro Replacement. **Lehre: Für `cv.md` das Edit-Tool nicht mehr verwenden, stattdessen Python-aus-git-Pattern.** Wandert beim Session-Abschluss in `agent-prompt.md`.
|
||
|
||
**Build und visuelle Bestätigung durch Thomas (S09):** `build.ps1` ausgeführt; alle Links in DOCX und PDF wie gewünscht klickbar. TÜV-Klick zeigt erwartungsgemäß die Word-Fehlermeldung — der Display-Text warnt den Empfänger vorab, manuelles Copy-Paste in den Browser funktioniert.
|
||
|
||
## Iteration C (S09) — Foto-Einbindung via Grid Table
|
||
|
||
**Ziel:** Foto rechts oben auf Höhe Name + Kontaktdaten, 4,06 × 4,06 cm, eckig, nur Seite 1, einheitlich in DOCX und PDF.
|
||
|
||
**Layout-Pfad:** Grid Table im `cv.md` als 2-Spalten-Header. Linke Zelle: H1 (Name) + H2 (Kontaktdaten) + Bullet-Liste der Kontaktdaten. Rechte Zelle: Foto-Image. Spalten-Verhältnis 65,1% / 34,9% (Strich-Anzahl 112:60), entspricht ca. 10,15 cm linke / 5,43 cm rechte Spalte.
|
||
|
||
**C1 — Pipe-Alignment-Strenge in Pandoc 3.x:** Erste Grid-Table-Variante hatte inkonsistente Pipe-Positionen, weil ich die Cell-Inhalte nicht genau auf die Strich-Breiten gepaddet habe. Pandoc 2.9 (Sandbox) parst das tolerant als Tabelle, Pandoc 3.x (Thomas) erkennt das nicht als Grid Table und fällt auf Plain-Text-Rendering der Pipes zurück (DOCX-Output war reiner Text). Fix: Tabelle programmatisch in Python aufbauen mit `ljust(LEFT_W)`/`ljust(RIGHT_W)` und Eindeutigkeits-Check der Pipe-Positionen pro Zeile. Lehre: Pandoc 3.x Grid Tables verlangen exakt konsistente Pipe-Positionen in allen Zeilen.
|
||
|
||
**C2 — DOCX-Spacing für H1 und Foto via Post-Processing:** Pandoc emittiert für H1 Default-Spacing-before = 18 pt, das Foto landet ohne Spacing auf Cell-Top. Resultat: H1-Top liegt 0,7 cm unter Foto-Top. Thomas hat in Word experimentiert und gewünscht: H1-spacing-before = 0 pt, Foto-spacing-before = 5 pt, dazu Foto-Paragraph horizontal rechtsbündig (`<w:jc w:val="right"/>`). Da Pandoc das Image als „Mit Text in Zeile" einbettet (nicht als Floating Image), kann es nur über die umgebende Paragraph-Eigenschaft ausgerichtet werden. Umgesetzt als vierte Modifikation in `build/post-process-docx.py` (Funktion `process_header_table`): findet die erste Tabelle, modifiziert die `<w:pPr>` der Heading1- und der Drawing-tragenden Paragraphen.
|
||
|
||
**C3 — Foto-Größe 4,5 → 4,06 cm und Pandoc-Default-Image-Bug:** Bei der Größenänderung mit `{width=4.06cm}` allein emittierte Pandoc 3.x `\includegraphics[width=4.06cm,height=\textheight,keepaspectratio]`. Das `height=\textheight` ist Pandocs Default für Single-Width-Specs. Mit `keepaspectratio` rendert das Bild zwar visuell auf 4,06 cm × 4,06 cm, aber die Image-Box hat layoutmäßig `\textheight` (~24 cm) Höhe — und LaTeX zieht die Tabellen-Zeile auf 24 cm Höhe auf, was den ganzen Header-Layout zerschießt (Foto oben, Text unten — beobachtet von Thomas). Fix: beide Dimensionen explizit in der Markdown-Image-Syntax: `{width=4.06cm height=4.06cm}`. Pandoc emittiert dann `\includegraphics[width=4.06cm,height=4.06cm]` ohne textheight-Anteil — saubere Box-Höhe.
|
||
|
||
**C4 — PDF-Layout via Lua-Filter:** Selbst nach C3 saß das Foto im PDF in der falschen vertikalen Position (oben aus der Cell herausragend). Ursache: Pandoc 3.x emittiert für die rechte Cell mit nur einem Image-Element KEINEN `\begin{minipage}`-Wrapper (im Gegensatz zu Pandoc 2.9), das Image landet direkt in der `p{calc...}`-Spalte. In dieser p-Spalte wirkt eine implizite `\parbox[t]`-Logik: die Baseline des Images (= unterer Bildrand) wird auf die Cell-Top-Linie gesetzt, das Bild ragt also nach OBEN aus der Cell heraus. **Fix:** Pandoc-Lua-Filter `build/header-image-wrap.lua`, der das Header-Foto im LaTeX-Output mit `\hfill\raisebox{-\height}[0pt][0pt]{...}` umschließt: `\hfill` schiebt das Bild rechtsbündig in der `\raggedright`-p-Spalte, `\raisebox{-\height}[0pt][0pt]` setzt die Bild-Top auf die Baseline (= Cell-Top) und reportet null Höhe an die Tabellen-Zeile, damit die Zeilenhöhe von der linken Zelle bestimmt wird. Filter-Trigger: nur bei `FORMAT="latex"` und nur für `img.src` mit „foto" im Namen. DOCX bleibt unberührt; das DOCX-Post-Processing macht das Pendant per `<w:jc>` und `<w:spacing>`.
|
||
|
||
**C4a — Lua-Filter-Erste-Version (Image durch RawInline ersetzt) → Image-not-found:** Die erste Filter-Version hat das gesamte Image-Element durch ein einzelnes `RawInline` ersetzt, mit dem Image-Pfad gebacken in den raw-LaTeX-String. Folge: Pandoc sah kein Image-Element mehr im AST und triggerte seine Resource-Path-Resolution nicht. LuaLaTeX scheiterte mit `! Package luatex.def Error: File 'foto-wrba_2026_6782_1.jpg' not found: using draft setting.` Korrektur in der zweiten Version: Filter gibt eine Lua-**Liste** zurück, in der das Original-`img`-Element zwischen den beiden RawInline-Wrappern erhalten bleibt. So läuft Pandocs Image-Resource-Resolution weiterhin.
|
||
|
||
**C4b — `\nolinkurl{}` in `longtable`-Minipage → `\@xverbatim`-Fehler:** Pandoc emittiert für href-Links, deren Display-Text einer URL ähnelt (z.B. eine E-Mail-Adresse als Display und mailto:Adresse als Ziel), `\nolinkurl{...}` für Verbatim-Mode-Rendering. In einer `longtable`-Minipage bricht das mit `! Paragraph ended before \@xverbatim was complete.` ab. Fix: `\renewcommand{\nolinkurl}[1]{#1}` direkt nach `\hypersetup{}` im Template — URL-Display-Text wird normaler Text statt Verbatim-Mode. Im CV mit Sans-Schrift sowieso erwünscht (kein Monospace-Display für E-Mail).
|
||
|
||
**C4c — `\titlespacing*{\section}` für H1-Top-Alignment:** Default-`\titlespacing*{\section}{0pt}{1.4em}{0.5em}` (zweite Zahl = before-space) lässt H1 um 1,4 em unter der Cell-Top beginnen. Cv.md hat nur ein einziges H1 (Header-Name), daher unschädlich, das vor-Spacing global auf 0 zu setzen: `\titlespacing*{\section}{0pt}{0pt}{0.5em}`. H1 startet jetzt direkt am Cell-Top, parallel zum Foto-Top.
|
||
|
||
**C5 — Spaltenbreiten 112:60:** Strich-Verhältnis ergibt 65,12% / 34,88% ≈ 10,15 / 5,43 cm bei 16 cm Textbreite. Thomas-Wunsch war exakt 10,66 / 5,73 cm (= 65,04% / 34,96%); meine kompakteste Variante mit Image-Markdown-Mindestbreite 60 Zeichen liegt 0,5 cm linke Spalte zu schmal vs. Wunsch, ist aber funktional korrekt: H1 in einer Zeile, E-Mail in einer Zeile, Foto-Rechtsrand bündig mit Textbereich-Rand. Thomas hat das so akzeptiert.
|
||
|
||
**Build-System-Verbesserungen (S09):**
|
||
|
||
- `build/build.ps1` um `--lua-filter=$luaFilter` in PDF- und DOCX-Pandoc-Calls erweitert.
|
||
- `Read-Host`-Wait-on-Error aus `build.ps1` entfernt — das blockierte AI-Agents/CI-Aufrufe. Stattdessen `Start-Sleep -Seconds 3` am Ende bei Fehler, was menschliche Lesezeit ermöglicht und nicht blockt.
|
||
- `header-image-wrap.lua` als Pflichtdatei in den `Test-Path`-Check aufgenommen.
|
||
|
||
**Edit-Tool-Truncation-Vorfälle in S09 (vier weitere):** beim Initial-Edit der Grid Table in cv.md, bei der `\renewcommand{\nolinkurl}`-Insertion in template.tex, beim Einbau des Read-Host-Blocks in build.ps1, und nochmals bei der Dezimalpunkt-Korrektur. **Lehre verschärft: Edit-Tool für JEDE nicht-triviale Modifikation auf NTFS-Mount-Dateien meiden, generell Python-aus-git-HEAD- oder Python-aus-Disk-Pattern bevorzugen.**
|
||
|
||
**Sandbox-NTFS-Stale-Read auf DOCX-Output:** Beim Versuch, das von Thomas erzeugte DOCX im Sandbox zu inspizieren, lieferte der Sandbox-Read das DOCX als „File is not a zip file" zurück (End-of-central-directory fehlte). Workaround: DOCX in der Sandbox aus cv.md neu generieren statt das Live-File zu lesen.
|
||
|
||
**Build und visuelle Bestätigung durch Thomas (S09):** DOCX und PDF zeigen Foto rechts oben, korrekt ausgerichtet, korrekt bemessen. Layout aus Thomas' Sicht akzeptiert.
|
||
|
||
## S10 — Heading-Farbe-Fix, Sinn-Korrekturen, Buzzword-Erweiterung, PDF-Layout (teilweise)
|
||
|
||
**S10-A — DOCX-Heading-Farbe und H1+H2-Bold:**
|
||
|
||
- Farb-Audit: DesTEngS-Primärfarbe ist `#3C68AE`, nicht `#0B5394`. In `agent-prompt.md`, `teilgebiete/01-lebenslauf.md`, `build/build-reference-docx.py` (Konstante `HEADING_COLOR` und Doc-Kommentar) und `templates/template.tex` (`destengsblue`-Definition) korrigiert.
|
||
- Diagnose der nicht-greifenden Heading-Farbe im DOCX: Pandoc-3.x-Default-Reference enthält Linked Character Styles `Heading1Char`/`2Char`/`3Char` mit eigener `<w:color val="0F4761" themeColor="accent1" themeShade="BF"/>` (Aptos-Petrol). Char-Styles haben in Word Vorrang vor Para-Styles bei Run-Eigenschaften (Schrift, Farbe). Pandoc 2.9 (Sandbox) hat diese Char-Styles nicht — daher war das Problem in der Sandbox nicht reproduzierbar.
|
||
- Fix: `HEADING_COLOR_STYLES` in `build-reference-docx.py` um `Heading1Char`/`2Char`/`3Char` erweitert.
|
||
- Zusatzanforderung Thomas: H1+H2 fett. Neue Funktion `set_heading_bold` mit Konstante `HEADING_BOLD_STYLES` (Heading1+2 Para- und Char-Stil). H3 bleibt unverändert.
|
||
- Visuell verifiziert: alle Headings im DOCX in `#3C68AE`, H1+H2 fett, H3 normal.
|
||
|
||
**S10-B — cv.md Sinn-Korrekturen (Aufgabe 2):**
|
||
|
||
- Diff-Vorbereitung: `output/cv-old-plain.txt` (alte DOCX 2025-03-21 normalisiert), `output/cv-new-plain.txt` (cv.md normalisiert), `output/cv-diff-unified.txt` (kompletter Unified-Diff), `output/cv-diff-report.md` (sektionsweise mit Mapping „Berufstätigkeit" ≡ „Projekte als freiberuflicher Consultant").
|
||
- 18 Korrekturen umgesetzt (atomar via Python-aus-Disk-Pattern):
|
||
- Thomas: „Digitales"→„digitales Dämpfungsglied"; „Leiterplattenherstellern"→„Leiterplattenhersteller"; Toshiba-Spezifikation Komma; „Detaillierte Analysen elektrischer IC-Gehäuse"→„Detaillierte elektrische Analysen von IC-Gehäusen"; „Dotierungsprofile und dessen Implementierung"→„… und Implementierung".
|
||
- Agent: „inclusive"→„inklusive"; „Faseroptische"→„faseroptische"; „10 KHz"→„10 kHz"; PyAutoGui→PyAutoGUI; Halbgeviertstrich + Komposita-Fix Transimpedanzverstärker-GaAs-MMICs; „2.5 GHz"→„2,5 GHz"; „Evaluierungsboard Redesigns"→„-Redesigns"; Komma vor „abgeschlossen 2001"; Mixed-Mode-S-Parameter Bindestrich; Realtime-Oszilloskopen; Objektorientierte/ereignisorientierte ohne Bindestrich.
|
||
- Methodik-Liste umsortiert nach Projekt-Lifecycle: Konzepterstellung → Machbarkeitsstudien → Technologie-Evaluierung und -Auswahl → Spezifikationserstellung → Technische Dokumentation → Systematische Fehleranalyse → Projektmanagement.
|
||
|
||
**S10-C — Buzzword-Erweiterung KI-Block (Aufgabe 3):**
|
||
|
||
- KI-Sektion in `cv.md` umstrukturiert nach Thomas-Layout:
|
||
- Service-Begriffe (Potenzialanalyse, Schulung, Implementierung, Prompt Engineering, Multimodale KI, DSGVO).
|
||
- „KI Software" als kompakte Office/Marketing-Tool-Liste (Miro, Notion, Fireflies.ai, Gamma, Canva).
|
||
- „GenAI / LLMs" mit neuem Sub-Bullet „Mixture of Experts (MoE), Reasoning Models, Function Calling / Tool Use".
|
||
- „Agentic AI" mit neuem Sub-Bullet „Model Context Protocol (MCP)".
|
||
- NLP als eigener Top-Level-Punkt.
|
||
- „RAG" mit neuem Sub-Bullet „Chunk-Strategien".
|
||
- „Edge AI / On-Premise KI-Infrastruktur" am Ende als gebündeltes Stack-Kapitel: Hardware (Consumer-GPU NVIDIA Blackwell + RTX 50-Serie + CUDA Toolkit) → Quantisierung (8-bit Inference FP8, MXFP4) → Modell-Formate (GGUF, Safetensors) → Software-Stack (Ollama, Hugging Face Transformers, PyTorch, llama.cpp, Open WebUI).
|
||
- Modellname „Qwen3.5-9B" (S5-Vorschlag des Agents zur Korrektur) wurde von Thomas als korrekt bestätigt — bleibt unverändert.
|
||
|
||
**S10-D — PDF-Layout (Aufgabe 4) — TEILWEISE GELÖST mit Trade-off:**
|
||
|
||
- H1: keine Trennlinie mehr (analog DOCX, wo nur H2 Trennlinien hat).
|
||
- H2: schwarze Trennlinie 8,6 cm × 1,25 pt (1:1 wie DOCX-H2-Trennlinie aus B4.4 in S08). `\nobreak` vor der Linie hält Heading + Linie auf gleicher Seite.
|
||
- H3: in DesTEngS-Blau, nicht fett (analog DOCX).
|
||
- Erste Seite: graue Header-Trennlinie weg (`\renewcommand{\headrule}{}` in `firstpage`-Stil); `\vspace*{-1.16cm}` direkt nach `\thispagestyle{firstpage}` rückt H1+Foto an die Top-Margin.
|
||
- **Body-Spacings (H2↔Linie und Linie↔Bullets) bleiben etwas größer als im Header.** Versuch der Angleichung an Header-Spacings via parskip-Glue-Eliminierung + parskip-Kompensation im H2-after-code wurde nach Sandbox-Diagnose **rückgebaut**, weil das 2–3 zusätzliche PDF-Seiten produzierte. Der parskip-Glue ist essentiell für LaTeX-Pagebreak-Flexibilität. Final-Lösung der Body-Header-Konsistenz kommt mit S12 (CV-LaTeX-Klasse).
|
||
- **Pagebreaks bei Trainings/Kenntnisse/„Berufliche Stationen vor der Selbständigkeit"**: longtable-Pagebreak-Logik macht im aktuellen Setup gelegentlich unschöne Trennungen. Wird mit der CV-LaTeX-Klasse in S12 strukturell gelöst.
|
||
|
||
**Lessons-learned aus S10:**
|
||
|
||
- **Sandbox-Build als Pflicht für Layout-Iterationen.** Setup mit `pdflatex` + `lmodern` (statt `lualatex` + IBM Plex Sans) etabliert. Page-Counts und Pagebreak-Verhalten lassen sich dort gut beurteilen, exakte Schriftbild-Abweichungen zu IBM Plex bleiben aber. Iterations-Loop über Thomas ist nur sinnvoll, wenn jede Variante vorher selbst getestet wurde.
|
||
- **Layout-Eingriffe einzeln testen.** Mehrere Mechanismen gleichzeitig (parskip-Manipulation + needspace + penalty + bodyonlyvspace) haben Diagnose blockiert. Saubere Sandbox-Isolierung jedes Mechanismus hat den Schuldigen schnell gefunden (parskip-Glue-Eliminierung).
|
||
- **parskip-Glue ist essentiell.** `\setlength{\parskip}{0.5em plus 0.2em minus 0.1em}` (Glue) gibt LaTeX Layout-Flexibilität für Pagebreaks. Eliminierung des Glues kostet 2+ Seiten.
|
||
- **Pandoc 3.x emittiert `minipage[t]` für Tabellen-Cells**, in denen `\@parboxrestore` `parskip` auf 0pt setzt. Das erklärt unterschiedliche Spacings Body vs. Header.
|
||
- **`titlesec` verträgt kein `\par` im after-code** (`! Paragraph ended before \ttl@format@iii was complete.`). Direktes `\penalty` ist sicherer.
|
||
- **`\nopagebreak` in longtable-Kontext** ist auf `\noalign{...}`-Form überschrieben — bricht im after-code mit `! Misplaced \noalign.`. `\penalty 7500` ist longtable-sicher.
|
||
|
||
**Strategische Entscheidung am Ende von S10 (mit Thomas):** PDF-Pipeline wird in S12 mit professioneller CV-LaTeX-Klasse neu aufgesetzt (`moderncv` / `awesome-cv` / typst — Tool-Recherche dort). `cv.md` bleibt single source of truth; Daten-Extraktion via Custom-Pandoc-Filter oder Build-Skript-Erweiterung.
|
||
|
||
## S11 — Methodik-Sektion ergänzt
|
||
|
||
**Ausgangslage:** Methodik-Liste hatte 7 Einträge (Konzepterstellung, Machbarkeitsstudien, Technologie-Evaluierung und -Auswahl, Spezifikationserstellung, Technische Dokumentation, Systematische Fehleranalyse, Projektmanagement). Thomas: lückenhaft, außerdem sollte „Spezifikationserstellung" vor „Technologie-Evaluierung und -Auswahl" stehen, und wichtige Lifecycle-Phasen (System Design, Software Design, Test, System Integration) fehlen.
|
||
|
||
**Diskussion mit Thomas:**
|
||
|
||
- Reordering bestätigt: Spec vor Technologie-Auswahl folgt der „Was-vor-Wie"-Logik und stimmt mit `marketing.md` Abschnitt 2 überein („Konzeptfindung, Requirements Engineering und Erstellung von Spezifikationen").
|
||
- „Software Design"-Konflikt mit der bestehenden Kenntnisse-Subsection `**Software Design:**` (Sprachen/Paradigmen) gelöst über **Variante 1**: Methodik-Eintrag heißt „SW-Architektur und -Design" — Subsection-Titel bleibt unverändert.
|
||
- „Test" wird als „Verifikation und Validierung" formuliert (im regulierten Engineering präziser, deckt Reviews/Analysen mit ab).
|
||
- „Anforderungsanalyse / Requirements Engineering" und „Spezifikationserstellung" beide drin — verschiedene Schritte (Bedarf erheben → in Spec überführen).
|
||
- Querschnittsthemen (Risikomanagement, QS, Konfigurationsmanagement, Reviews, V-Modell/Agile) bewusst weggelassen.
|
||
- „Inbetriebnahme und Übergabe" weggelassen — kein Schwerpunkt im aktuellen Positionierungs-Kern (Consultant, Entwicklungsingenieur), KI-Pendant „KI-Implementierung" steht bereits im KI-Block.
|
||
- „Systematische Fehleranalyse" beibehalten nach Diskussion: V&V deckt SFA nicht ab. V&V ist entwicklungsbegleitend, beweist Konformität. SFA ist reaktiv, findet Root Cause bei unerwartetem Fehlverhalten. Unterschiedliche Werkzeuge, unterschiedlicher Zeitpunkt. SFA ist ein Differenzierer in Thomas' Profil (Toshiba, Multilink, Freelance-Stationen) und Recruiter-Filter-Begriff (Root Cause Analysis, Troubleshooting, Debugging).
|
||
|
||
**Finale Liste in `cv.md` (12 Einträge, in Lifecycle-Reihenfolge):**
|
||
|
||
1. Konzepterstellung
|
||
2. Machbarkeitsstudien
|
||
3. Anforderungsanalyse / Requirements Engineering
|
||
4. Spezifikationserstellung
|
||
5. Technologie-Evaluierung und -Auswahl
|
||
6. System-Architektur und -Design
|
||
7. SW-Architektur und -Design
|
||
8. Verifikation und Validierung
|
||
9. System Integration
|
||
10. Technische Dokumentation
|
||
11. Systematische Fehleranalyse
|
||
12. Projektmanagement
|
||
|
||
**Umsetzung:** Atomar via Python-aus-Disk (`os.replace`), kein Edit-Tool — gemäß S08/S09-Lehre. Ein-Treffer-Check vor dem Replace bestand. Sandbox-Read der geänderten Datei verifiziert: 12 Einträge in korrekter Reihenfolge, Vor-/Nachkontext (Software-Design-Subsection, IT-Subsection) unverändert.
|
||
|
||
**Offen für S11 (zweiter Teil):** Inhaltliche Kleinigkeiten in `cv.md`, die Thomas im Sinn hat — wird in einer der nächsten Aktionen abgearbeitet.
|
||
|
||
## Nächste Schritte
|
||
|
||
**S11 — Rest des Lebenslauf-Inhalts:**
|
||
|
||
1. ~~Methodik-Sektion ergänzen~~ — abgeschlossen (siehe S11-Block oben).
|
||
2. **Inhaltliche Kleinigkeiten verbessern.** Thomas hat konkrete Detail-Verbesserungen in `cv.md` im Sinn — werden in einer Folgesitzung oder im Anschluss an S11 abgearbeitet.
|
||
|
||
**S12 — PDF-Pipeline-Refactoring mit professioneller CV-LaTeX-Klasse:**
|
||
|
||
1. Tool-Recherche: `moderncv` vs. `awesome-cv` vs. typst (oder andere). Vergleich nach Optik, Aufwand, MikTeX-Integration, DesTEngS-CI-Anpassbarkeit (`#3C68AE`, IBM Plex Sans).
|
||
2. `cv.md` bleibt single source of truth.
|
||
3. Daten-Extraktion aus `cv.md` für CV-Klasse-Features (`\cventry` / `\cvevent` etc.):
|
||
- Custom Pandoc-Filter (Lua oder Python) ODER
|
||
- Erweiterung von `build.ps1` mit Python-Pre-Processor, der `cv.md` → `cv.tex` transformiert.
|
||
4. Implementierung, Sandbox-Test, visuelle Verifikation durch Thomas.
|
||
5. 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, B4.4 H2-Trennlinien, B6 Bullet-Einzüge). 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.
|