`, Kopfleiste, Landing-Page, Notebook-Kopf und der `pagetitle` des Gesamtdokuments — und `TITEL` in `erzeuge_titelseite.py`, weil er dort umbrochen und vermessen werden muss. **Nicht** geändert: die Verzeichnis- und Dateinamen (`Operations_Research_mit_Python_…`) und die historischen Dokumente unter `Kritik_und_Verbesserungsvorschlaege/`. **Die Anwendungsfelder auf dem Titelblatt sind gegen den Inhalt geprüft.** Zu jedem Begriff gibt es ein gerechnetes Beispiel: | Anspruch | belegt durch | | --- | --- | | Personaleinsatz-, Schicht- und Vertretungspläne | `CP_SAT_Vertretungssystem.py`, Schichtplan-Beispiel in {ref:kap:cpsat} (6 Personen, 14 Tage), Projekte P1/P2 | | Fahrtrouten | `VRP_Flotten_Routing.py` (CVRPTW, 16 Kunden, 619 km), `VRP_Kapazitaetsfalle.py` | | Logistik | Min-Cost-Flow-Transportnetz, VRP, {ref:kap:supplychain} | | Maschinenauslastung | `JobShop_Intervalle.py`, Rüstzeitmuster B26 | | Netzwerkauslastung | `Min_Cost_Flow.py` mit Kantenkapazitäten | | Energieverteilung | `Kraftwerkseinsatz.py` (Unit Commitment mit Windunsicherheit) | | Ressourcenplanung | `Bot_Allokation.py`, `Rucksack.py` | | Portfoliooptimierung, Finanzmärkte | {ref:kap:markowitz}, {ref:kap:cvar}, {ref:kap:handelsmaschine} | **Ein Begriff wurde dabei ausgetauscht.** Die erste Fassung warb mit „Stundenplänen" — das Wort kommt im ganzen Buch nur zweimal vor, als Stichwort in einer CP-SAT-Tabelle und als *Datenquelle* im Projektauftrag P1. Ein Stundenplan im engeren Sinne (Klassen, Fächer, Räume, Lehrerverfügbarkeit gegeneinander optimieren) wird **nicht** gerechnet; gerechnet werden Vertretungsplan und Schichtplan. Die Formulierung lautet jetzt „Personaleinsatz-, Schicht- und Vertretungsplänen" und deckt sich damit mit dem, was das Buch einlöst. **Verifiziert:** `--check` ohne Warnung, PDF 715 Seiten, Titelblatt in PDF und Website sichtgeprüft, kein Rest eines früheren Titels in Quellen oder generierten Seiten, 33 pytest-Tests grün, Version 03 unberührt. --- ## 7. Was als Nächstes ansteht ### Der Stand **Alle Phasen sind abgeschlossen** — die sechs des Umbaus, dazu Phase 6 bis 8 aus `Verbesserungen_02.md`/`_03.md`. `Version_04/` ist seit dem 08.09.2026 ein eigenes Git-Repository. 23 Kapitel, 5 Anhänge, 5 Teil-Synthesen, **76** lauffähige Programme, 141 Aufgaben mit 141 Lösungen, 33 Diagramme, PDF mit 760 Seiten, Website mit vier interaktiven Figuren. **Zum eigenen Repository — eine Korrektur der früheren Angabe hier:** `git subtree split -P Version_04` hätte die Historie **nicht** mitgenommen. Der Pfad `Version_04/` existiert erst seit der Verzeichnistrennung; der Split hätte 7 statt 41 einschlägiger Commits gebracht — eine Teilhistorie, die vollständig aussieht und es nicht ist. Volle Historie ginge nur über `git-filter-repo` (nicht installiert). Deshalb: frischer `git init -b main`, das übergeordnete Repository bleibt das Archiv der 71 Commits und trägt `Version_04/` in seiner `.gitignore`. ### Was von außen kommen muss 1. ✅ **Remote-Repository angelegt und gepusht** — <https://kitux.de/forgejo/dschlueter/operations_research>, öffentlich, Branch `main`. 2. ✅ **`COLAB_BASIS_URL` geklärt — und zwar anders als geplant.** Der Platzhalter zeigte auf GitHub, das Repository liegt auf einer eigenen Forgejo-Instanz. Colab öffnet Notebooks **nur** aus GitHub, Google Drive oder einem Upload; die URL-Form `colab.research.google.com/github/…` ist fest auf GitHub verdrahtet. Eine selbstgehostete Adresse dort einzusetzen ergäbe keinen Link zum eigenen Server, sondern einen toten GitHub-Link — der Kommentar im Quelltext („zu ändern sind nur Kontoname und Repository-Name") ging von GitHub aus und war damit selbst irreführend. Die Konstante steht jetzt auf `""`: Die Colab-Zeile entfällt, der **Download-Link auf das Notebook bleibt**, ergänzt um den Hinweis, was man damit tut. Ein späterer GitHub-Spiegel braucht weiterhin nur diesen einen Wert. 3. ✅ **Veröffentlicht** unter <https://jamulix.de/OR/> — Landing-Page, Kapitelseiten, Diagramme, Notebooks, Suchindex, KaTeX und PDF sind erreichbar (alles HTTP 200 geprüft). ⚠️ **Aber: Die dort liegende Fassung ist einen Bau alt.** Sie stammt aus der Zeit nach Phase 8.1 (die fünf Synthese-Seiten sind da), aber vor der Colab-Umstellung: `lp.html` enthält noch einen toten Colab-Link, die neue Notebook-Formulierung fehlt, und das PDF ist 3 820 135 statt 3 816 207 Bytes groß. **`OR_HTML_04/` muss neu kopiert werden** — und künftig nach jedem `--pdf --html`. ### Bewusst zurückgestellt (aus `Verbesserungen_02/_03`) * **Streamlit-Apps** (V03/1, 2, 5) — Entscheidung des Autors. Sie wären eine neue Artefaktklasse: nicht über die Programmsuite prüfbar, ohne abgedruckte Ausgabe (Regel 4). Der „Was-wäre-wenn"-Gedanke daraus ist in {ref:sec:praxisfallen-attribution} ohne UI eingelöst. * **Zielgruppen-Callouts in allen Kapiteln** (V02/5) — die Lernpfade und die One-Pager aus 7.1 leisten dasselbe gezielter, ohne Eingriff in jeden Abschnitt. * **`joblib`/`ray`** (V02/2) — `num_workers` und `ProcessPoolExecutor` decken den Bedarf; ein Cluster-Framework wäre eine Abhängigkeit ohne Beispiel, das sie braucht. * **Folium-Karten** (V03/3) — **blockiert durch eine offene Entscheidung**: Die VRP-Instanz ist ein synthetisches 100 × 100-km-Raster ohne Geokoordinaten. Eine echte Karte verlangt entweder eine neue Instanz (und damit neue abgedruckte Zahlen) oder eine willkürliche Verankerung an einem realen Ort. * **Executive-PDF-Report** (V03/6) — ohne Streamlit-Apps fehlt der Ort, an dem er entstünde. ### Offen, rein redaktionell **53 der 141 Lösungstitel weichen vom Aufgabentitel ab** — durchweg Kürzungen („Zweistufiges Modell rechnen" → „Zweistufig rechnen"), alle in den 15 Abschnitten aus Version 03; die acht in Phase 3 ergänzten stimmen vollständig. Seit 6.1a trägt jede Lösung wieder die richtige Nummer, die Navigation ist also intakt. Ein Angleichen wäre Kosmetik, kein Fehler — aber es würde den Anhang lesbarer machen. ### Was einer späteren Sitzung auffällt und **kein** Fehler ist * **14 der 33 Diagramme haben keinen Generator.** Dokumentierte Entscheidung — Kästen, Pfeile, beschriftete Formeln, generische Funktionsverläufe. Kriterium in Abschnitt 6c. * **`Mutationstest.py` benutzt weiterhin `subprocess`.** Richtig so: Dort läuft pytest auf einer mutierten Kopie, das ist ein externes Werkzeug auf veränderten Dateien und keine Import-Isolation (Abschnitt 8.2). * **Die abgedruckte Ausgabe von `Parallele_Suche.py` ist absichtlich nicht byteidentisch reproduzierbar.** Die Zahl der verschiedenen Pläne schwankt — und genau das ist die Aussage des Abschnitts. * **Version 03 ist eingefroren** und liegt in `../Version_03/`. Ihre READMEs nennen als Arbeitsverzeichnis noch `OR_mit_Python`, und ihr generiertes Gesamtdokument liegt minimal hinter den Quellen zurück. Beides bleibt bewusst stehen. ### Kleinere offene Punkte aus abgeschlossenen Phasen - ✅ **Formel-Übersetzer in {ref:kap:markowitz} und {ref:kap:cvar}** — erledigt, siehe Abschnitt 6c. Damit hat jedes formelreiche Kapitel seinen 🔤-Übersetzer; die Kapitel Finanzdaten, Handelsmaschine und Praxisfallen sind formelarm, dort besteht kein Bedarf. - ✅ **`CLAUDE.md` um den V04-Strang ergänzt** — aus Phase 5 vorgezogen, weil `CLAUDE.md` die einzige Datei ist, die eine neue Sitzung automatisch liest. Ohne diesen Abschnitt hätte eine frische Sitzung am eingefrorenen V03 weitergearbeitet und `PLAN.md`/`PROGRESS.md` nie gesehen. Damit war die Wiederaufnahme der eigentliche Schwachpunkt — nicht die Frage, in welchem Verzeichnis die Planungsdateien liegen. --- ## 6d. Phase 6 — Umsetzung von `Verbesserungen_02` / `_03` 🔄 Grundlage: `Kritik_und_Verbesserungsvorschlaege/Verbesserungen_02.md` und `_03.md`, zwölf Arbeitspakete. Nach Ertrag geordnet umgesetzt; **Streamlit-Apps sind auf Wunsch des Autors zurückgestellt**, ebenso Folium-Karten (die VRP-Instanz ist ein synthetisches Raster ohne Geokoordinaten) und Zielgruppen-Callouts in allen Kapiteln. ### ✅ Repository und `pyproject.toml` `git init -b main` in `Version_04`, `Version_04` im übergeordneten Repository ausgetragen. Neu: `pyproject.toml` mit den Gruppen `finance`, `large-scale`, `api`, `figures`, `dev`, `empfehlungen` — die abgedruckte `requirements.txt` bleibt unverändert daneben bestehen. **`ortools` steht in der Grundausstattung, `highspy` erst in `[large-scale]`.** Damit kann der HiGHS-Symbolkonflikt bei der schlanken Installation gar nicht erst auftreten; `cvxpy` zieht `highspy` nicht nach. Zwei Funde beim Abgleich der Importe gegen `requirements.txt`: * **`graphviz` fehlte** — `bilder_04/erzeuge_architektur_diagramme.py` importiert es, die Leserliste kennt es nicht. Es gehört nicht in die abgedruckte Datei (kein Beispielprogramm braucht es), steht jetzt aber in `[figures]`. * **`pymoo` steht in `requirements.txt`, wird aber von keinem der 74 Programme importiert** — es ist nur eine Empfehlung im Kapitel Metaheuristiken. Jetzt in `[empfehlungen]`. Später korrigiert: **`cvxpy` lag zuerst in `[finance]`** — falsch, es wird von 13 Programmen gebraucht, darunter dreien im Kapitel Unsicherheit, lange vor dem Finanzteil. Jetzt in der Grundausstattung. ### ✅ 6.1 Chance Constraints ({ref:kap:unsicherheit}) Neuer Abschnitt {ref:sec:unsicherheit-chance-constraints} plus `Chance_Constraints.py` (74. Programm). Das Kapitel hatte Monte-Carlo, Zweistufigkeit und Worst-Case-Robustheit; die Wahrscheinlichkeitszusage war die fehlende vierte Antwort — und die, nach der das Management tatsächlich fragt. Beide Wege an **derselben** Instanz: analytisch als Second-Order-Cone-Bedingung (CLARABEL) und szenariobasiert als Big-M-MILP (SciPy/HiGHS), beide in einem Prozess ohne `ortools`- oder `highspy`-Import. Der Fall ist ein Kraftwerkspark mit 500 MW Zusage. **Drei Befunde, alle gemessen:** 1. **Der Mittelwertplan hält 50,08 %.** Kein Fehler, sondern die Definition des Erwartungswerts — dieselbe Falle wie im Kapitelanfang, nur teurer. 2. **Sicherheit ist konvex bepreist.** 56 289 € je Prozentpunkt auf dem Weg zu 80 %, 253 848 € zwischen 95 % und 99 % — das **4,5-fache**. Das Programm rechnet die Tabelle selbst aus, statt sie zu behaupten. 3. **Die Zusage gilt nur für die unterstellte Verteilung.** Der 95-%-Plan hält gemessen **87,44 %**, sobald die Testverteilung eine Kältewelle mit Dunkelflaute enthält, in der *alles zugleich* einbricht — auch das Gaskraftwerk. In einer reinen Normalwelt liefert derselbe Plan 94,97 %. Nicht das Verfahren ist falsch, sondern die Annahme. **Zwei eigene Fehlgriffe unterwegs, beide durch Messen aufgefallen:** * Die erste Kostentarierung ergab eine **entartete Lösung** (alles ins Gaskraftwerk), womit die Kovarianzmatrix wirkungslos war — und gerade sie ist der Grund für die Kegelform. Erst Kosten, die je *erwarteter* MW vergleichbar sind, machen den Konflikt echt. * Der erste Kälteeinbruch traf nur Wind und Sonne. Der SOC-Plan hatte die aber ohnehin fast herausgehalten und war zufällig robust (94,40 %) — das Argument trug nicht. Physikalisch richtig ist, dass bei Frost auch der Gasdruck fällt; damit trifft der Einbruch alles zugleich, und genau das kann eine Kovarianzmatrix mit Korrelationen um null nicht ausdrücken. **Ehrlich berichtet statt geglättet:** Die Szenariomethode **überanpasst**. Über zwölf Läufe (je vier Ziehungen bei S = 200, 400, 800, geprüft an 200 000 unabhängigen Szenarien) lag die tatsächliche Quote zwischen **93,14 % und 96,71 %**, und die Spanne wurde von S = 400 auf S = 800 wieder **breiter**. Beide Solver (SciPy und HiGHS) bestätigten `optimal` bei identischen Kosten — es ist echte Überanpassung, kein Solverartefakt. Steht als ⚠️-Kasten im Abschnitt. **Aus der Ausgabe entfernt: die Laufzeitmessung.** Eine Wanduhrzeit ist nie byteidentisch reproduzierbar (2,2 s / 2,3 s zwischen zwei Läufen) und hätte Regel 4 dauerhaft gebrochen. Die Beobachtung steht jetzt im Fließtext, wo eine Spanne ehrlich ist. Danach: drei Läufe zeichengleich, und die abgedruckte Ausgabe stimmt mit dem Lauf des **extrahierten** Programms überein. Eine Aufgabenprämisse musste ich verwerfen: „Ab welcher Zusage wird das Modell unlösbar?“ — das analytische Modell bleibt bis praktisch 100 % lösbar. Die Aufgabe fragt jetzt nach dem Fall mit gedrosselter Biomasse, in dem das **szenariobasierte** Modell `infeasible` meldet (7,50 % der Szenarien deckt selbst der Vollausbau nicht), das analytische aber `optimal` liefert — und dann 87,39 % hält. ### ✅ 6.1a Die letzten handgeschriebenen Nummern — **sechster und siebter** Fund **Der sechste Fund: 98 Lösungsmarken in Anhang A.** Marken der Bauart `**9.2 — Ansatz wählen.**`, sämtlich aus Version 03, wo Unsicherheit Kapitel 9 war. Heute ist es Kapitel 12, und die Aufgabe wird korrekt als „Aufgabe 12.2" gesetzt. Das war keine Schönheitsfrage: **„Aufgabe 9.2" existiert wirklich** — sie gehört zum Kapitel Metaheuristiken („Zuggröße und Temperatur"). Wer die Lösung zu 9.2 nachschlug, landete beim falschen Thema. Beide bisherigen Prüfungen liefen vorbei: Vor der Zahl steht kein Schlüsselwort, und es ist keine Tabellenzelle. **Zwei Messungen machten die Reparatur billig.** Erstens: In allen 15 nummerierten Abschnitten gab es exakt so viele Lösungen wie Aufgaben, lückenlos 1…n — nur der Kapitelteil war falsch, die Umstellung also reine Mechanik. Zweitens: Die **acht in Phase 3 ergänzten Kapitel machten es längst richtig** (`**Titel.**` ohne Nummer). Der Anhang wurde damit nicht auf etwas Neues umgestellt, sondern auf das, was seine neueren Teile schon taten. Der Build vergibt die Marken jetzt selbst. Der Präfix kommt **nicht** aus `# Anhang A:` — der Anhang ist *eine* Überschrift, seine Abschnitte gehören aber zu 23 verschiedenen Kapiteln. Er kommt aus `{#sec:loesungen-<X>}` → `{#kap:<X>}`; diese Zuordnung gilt geprüft für alle 23. Im Quelltext steht `**{loesung} — Titel.**`. **Der siebte Fund, unterwegs: neun Verweise auf Denkfehler-Nummern.** Sätze wie „siehe Denkfehler 8.1" standen in alter Zählung — „8" war in Version 03 das QP/NLP-Kapitel, heute ist es Graphen. Eine bloße Umnummerierung hätte sie **stillschweigend woanders hin zeigen lassen**; das Ziel wurde deshalb für jeden einzelnen aus dem Zusammenhang bestimmt (die Kovarianzmatrix-Stelle in Finanzdaten meint QP/NLP, die „vergessene Dimension" meint Graphen) und auf `{ref:sec:<kapitel>-denkfehler}` umgestellt — ein Label, das alle 23 Kapitel haben. Einer davon steckte in einem **Programm-Docstring** und bekam nach Regel 12 den Kapitelnamen statt eines Verweises. **Eine Abweichung vom Plan, bewusst:** Der Denkfehler bekommt **gar keine** Nummer. Es gibt je Kapitel genau einen, die zweite Stelle wäre immer `.1`, und er steht ohnehin unter einer nummerierten Überschrift. Eine Nummer, die nie variiert, holte nur die Fragilität zurück, die hier gerade beseitigt wurde. Auch das folgt den acht neuen Kapiteln, die den Denkfehler schon vorher nur mit dem Titel des Rätsels ankündigen. **`--check` bewacht jetzt alle Familien** — `Denkfehler N.M`, `Micro-Quiz N`, `**N.M — ` im Anhang — **und zählt zusätzlich ab**, dass jeder Lösungsabschnitt so viele `{loesung}`-Marken hat wie sein Kapitel Aufgaben. Das ist die eigentliche Absicherung: Sie fängt eine vergessene oder doppelte Lösung, was keine Textsuche leisten kann. Gegengetestet mit vier künstlichen Fehlern auf einmal — alle vier gemeldet, nach dem Rückbau null. **Die Gegenprobe der Umstellung:** Das gebaute Gesamtdokument vorher gesichert, nachher verglichen. 168 geänderte Zeilen, restlos einer Familie zuzuordnen — **118** Lösungsmarken, 15 Anhang-Überschriften, 15 Kapitel-Callouts, 12 Micro-Quiz, 7 Zeilen mit Denkfehler-Verweisen (darauf 8 `{ref:}`), 1 Docstring-Zeile. Keine verschobene, verlorene oder inhaltlich veränderte Zeile. Die 118 sind die Probe aufs Exempel: 138 Marken gesamt, davon **20 unverändert** — genau die Kapitel 1 bis 3, deren alte Nummern zufällig noch stimmten, weil vor ihnen nichts eingefügt worden war. Ergebnis: **138 Aufgaben, 138 Lösungen, keine ohne Gegenstück.** Micro-Quiz tragen jetzt die echten Kapitelnummern (1, 2, 3, 5, 6, 7, 8, 11, 12, 13, 18–22 — die Lücken sind die Kapitel ohne Quiz). PDF unverändert 725 Seiten. **Nicht Teil dieser Runde:** In den 15 alten Abschnitten weichen 69 der 138 Lösungstitel von den Aufgabentiteln ab (gekürzt: „Zweistufiges Modell rechnen" → „Zweistufig rechnen"). Da die Nummer wieder stimmt, ist sie der Schlüssel; das Angleichen wäre eine rein redaktionelle Runde. ### ✅ 6.2 Constraint Attribution und Managementbericht ({ref:kap:praxisfallen}) Neuer Abschnitt {ref:sec:praxisfallen-attribution} plus `Constraint_Attribution.py` (75. Programm). Setzt Paket 3 aus `Verbesserungen_02.md` um — den Teil, der noch fehlte. **Die Lücke, die es schließt.** Zwei Fälle waren abgedeckt: `Erklaerbarkeit.py` beantwortet „warum **diese** Zuweisung?", `Konfliktsuche.py` „warum geht es **gar nicht**?". Der häufigste Fall der Praxis lag dazwischen und hatte kein Werkzeug: *Das Modell rechnet, der Plan ist zulässig — und trotzdem enttäuschend, nur weiß niemand woran es liegt.* **Dieselbe Fabrik wie die Konfliktsuche, nach der Reparatur.** Dort war die Lackierkapazität von 150 Stunden der Kern des Widerspruchs ($2 \cdot 40 + 3 \cdot 30 = 170 > 150$); eine zweite Schicht bringt sie auf 210, der Mindestumsatz sinkt auf 10 000 €. Damit kann ein Leser dieselben 14 benannten Bedingungen über zwei Kapitel hinweg verfolgen — erst „warum nicht?", dann „was kostet was?". **Drei gemessene Befunde:** 1. **Bindend heißt nicht teuer.** Fünf Bedingungen binden, „Lackierbudget Schicht 2" mit einem Schattenpreis von **0,00 €**. Dieselbe Unterscheidung, die `Erklaerbarkeit.py` an einer einzelnen Zuweisung zeigt — hier im Dualwert eines LP. 2. **Der Schattenpreis ist eine Momentaufnahme.** Für die Lackiererei verspricht die Hochrechnung $4{,}00 \cdot 30 = 120$ €, gemessen kommen **60 €**; der Preis gilt exakt bis **+15 Stunden**. Die zweite Hälfte der Sonderschicht wäre bezahlt und wirkungslos. Und die Ranglisten drehen sich: nach Schattenpreis führt der Trägervertrag (18 €/Stück), nach tatsächlicher Wirkung die Montage-Sonderschicht (450 €). 3. **Ein Wunsch kann unmöglich statt teuer sein.** „Mindestens 55 Rahmen" ist `INFEASIBLE`, blockiert von **drei** Bedingungen gemeinsam (jede einzeln entfernt macht ihn möglich) — die Deletion-Filter-Struktur, angewandt auf einen Wunsch statt auf einen Widerspruch. Mit +15 Stunden Lackierkapazität wird er erfüllbar und kostet dann **nichts**: Der Plan wählt diese Menge von sich aus. Der Konflikt bestand nie zwischen Vertrieb und Produktion. **Der Managementbericht** entsteht in Teil (4) aus genau diesen Zahlen — kein Satz enthält eine Zahl, die nicht vorher gerechnet wurde, auch nicht die Rangfolge und nicht die Namen der blockierenden Bedingungen. Voraussetzung dafür ist der sprechende Name jeder Bedingung; aus `A_ub[7]` wird kein Satz. **Und die Grenze, die dazugehört** — als ⚠️-Kasten und als Übungsaufgabe: Ein solcher Bericht erklärt das **Modell**, nicht die Wirklichkeit. Die Aufgabe lässt den Deckungsbeitrag von *Deckel* von 9 € auf 20 € steigen. Gemessen: Der Plan kippt (Rahmen auf das Vertragsminimum 40, Deckel auf die Marktgrenze 120), „Kapazität Lackieren" hört auf zu binden, „Liefervertrag Rahmen" fängt damit an — **und der Satz „Teuerste Bindung ist Liefervertrag Träger" steht wörtlich unverändert im Bericht**, während die Zahl dahinter von 18 € auf 58 € springt. Ein Bericht, der sich nicht ändert, ist kein Beweis dafür, dass sich nichts geändert hat. **Die neue Zählprobe aus 6.1a hat sich sofort bewährt:** Nach dem Einbau der Übungsaufgabe meldete `--check` „6 Loesungen, das Kapitel aber 7 Aufgaben", bevor die Lösung geschrieben war. Genau der Fall, für den sie gebaut wurde. Stand danach: 294 Abschnitte, 725 Querverweise, 328 Indexmarken, **75** Programme, 139 Aufgaben mit 139 Lösungen, PDF **737** Seiten. ### ✅ 6.3 Parallelität und Determinismus ({ref:kap:cpsat}) Neuer Abschnitt {ref:sec:cpsat-parallele-suche} plus `Parallele_Suche.py` (76. Programm). Setzt Paket 2 aus `Verbesserungen_02.md` um. **Was fehlte, war nicht die Regel, sondern die Messung.** Das Buch setzt an acht Stellen `num_workers = 1` mit dem Kommentar „für eine reproduzierbare Ausgabe", und der Spickzettel nennt den Grund. Nachgeprüft hatte es nie jemand. Gerechnet wird auf demselben Job-Shop wie {ref:sec:cpsat-intervallvariablen-job-shop-scheduling}, nur groß genug, dass die Suche arbeitet: 12 Aufträge, 10 Maschinen, 120 Arbeitsgänge. **Zwei Befunde, beide stärker als die Behauptung:** 1. **Die Beschleunigung ist überlinear.** Acht Arbeiter waren im abgedruckten Lauf nicht achtmal, sondern **12,3-mal** schneller als einer. Kein Messfehler: CP-SAT vervielfacht nicht dieselbe Suche, sondern lässt **verschiedene Strategien** nebeneinander laufen, die einander ihre Schranken mitteilen. Der zweite Arbeiter ist nicht „der zweite Kern", sondern ein anderes Verfahren. 2. **Der Seed genügt nicht — und zwar schon ab zwei Arbeitern.** Ein Arbeiter: 1 Plan aus 4 Läufen. **Zwei** Arbeiter: 3 verschiedene Pläne aus 4 Läufen, bei identischem `random_seed` und identischem Zielwert 183. Es braucht also keine acht Arbeiter, um die Reproduzierbarkeit zu verlieren. **Die vollständige Antwort kam erst über die Übungsaufgabe**, und sie ist besser als der Abschnitt allein: Mit `num_workers = 1`, aber **fünf verschiedenen Seeds**, ergeben sich ebenfalls **fünf verschiedene Pläne**. Keiner der beiden Parameter sichert die Reproduzierbarkeit allein: | | Seed fest | Seed variabel | | --- | --- | --- | | **1 Arbeiter** | reproduzierbar | 5 Pläne aus 5 Läufen | | **mehrere Arbeiter** | 3 Pläne aus 4 Läufen | erst recht nicht | Weiter gemessen für die Aufgabe: Der Gewinn kehrt sich um — auf 24 Kernen Faktor **10,2** (8 Arbeiter), **12,3** (16), **9,0** (24). „So viele Arbeiter wie Kerne" ist damit widerlegt. Und bei 15 Aufträgen läuft ein Arbeiter ins 60-s-Limit (`FEASIBLE`, Makespan 200), während acht `OPTIMAL` mit **demselben** Makespan 200 nach 26,4 s melden — der Unterschied liegt nicht in der Lösung, sondern im **Beweis**, dass es keine bessere gibt. **Zur abgedruckten Ausgabe:** Sie trägt die Kennzeichnung „Laufzeiten *und* die Zahl der verschiedenen Pläne sind hardwareabhängig" — nach dem Muster, das {ref:kap:testing} für `Benchmark_Skalierung.py` schon verwendet. Der Vergleich des extrahierten Programms mit dem Abdruck weicht denn auch in genau einer Zelle ab (4 statt 3 verschiedene Pläne bei 4 Arbeitern); Zielwert und Struktur sind identisch. Hier ist die Nichtreproduzierbarkeit der abgedruckten Zahl **die Aussage selbst** — der einzige Fall im Buch, in dem das so ist. Im MILP-Kapitel bekam die entsprechende Stelle in `Warmstart_Effekt.py` einen Verweis; dort steht nach Regel 12 der Kapitel**name**, keine Nummer. Stand danach: 295 Abschnitte, 730 Querverweise, **76** Programme, 140 Aufgaben mit 140 Lösungen, PDF **744** Seiten. ### ✅ 7.1 Vier Zielgruppen-One-Pager (Vorwort) Setzt Paket 4 aus `Verbesserungen_03.md` um. Das Titelblatt wirbt seit dem Umbau mit Entscheidern, Ingenieuren und Investoren — die Lernpfade im Vorwort waren aber nach **Themen** geschnitten, nicht nach **Rollen**. Der neue Abschnitt „Für wen dieses Buch geschrieben ist" steht zwischen „Wie dieses Buch aufgebaut ist" und den Lernpfaden und schließt genau diese Lücke: vier Einstiege, jeder mit Schmerzpunkt, drei Belegen, dem passenden Pfad und der Frage, an der es in dieser Rolle scheitert. **Die Entscheidung, die den Abschnitt trägt: nur gemessene Zahlen.** Jeder Beleg ist ein Ergebnis, das im Buch gerechnet wird — kein Werbeversprechen: * Entscheider: der Erwartungswert-Plan aus {ref:kap:supplychain} kostet **149 % mehr** (874 870 € statt 351 356 €) und führt in 28 von 40 Szenarien zum Lastabwurf; der Preis eines Prozentpunkts Versorgungssicherheit steigt um das 4,5-fache ({ref:sec:unsicherheit-chance-constraints}). * Ingenieure: der Schattenpreis der Lackiererei gilt bis +15 Stunden, eine 30-Stunden-Schicht bringt deshalb 60 € statt 120 € ({ref:sec:praxisfallen-attribution}); das Gesamtbild der Metaheuristiken 2 497 → 2 289 Minuten bei einer Schranke von 1 768. * Investoren: VaR 1,86 % gegen CVaR 2,99 %, schlechtester Tag −23,0 % — der am VaR nichts ändert ({ref:kap:cvar}). * Studierende: das Modell mit dem **schlechteren** MSE trifft die günstigere Entscheidung ({ref:kap:prognose}). **Und eine Erwartung wird ausdrücklich enttäuscht.** `Verbesserungen_03` verlangt für die Managementseite „typischer ROI und Amortisationszeit". Das Buch hat diese Zahlen nicht, und jede hier genannte wäre erfunden. Der One-Pager sagt das offen und nennt stattdessen die beiden Werkzeuge, mit denen der Leser **seine eigene** Zahl ausrechnet: den EVPI aus {ref:kap:unsicherheit} als Obergrenze für jedes Prognoseprojekt und die Kostenzurechnung aus {ref:sec:praxisfallen-attribution}. Kein neues Programm, keine neue Aufgabe — der Abschnitt bündelt Vorhandenes. Querverweise 730 → 755, PDF 744 → **746** Seiten. ### ✅ 7.2 Wasserfalldiagramm „was es bringt" ({ref:kap:supplychain}) Setzt den umsetzbaren Teil von Paket 3 aus `Verbesserungen_03.md` um (Vorher-Nachher- Wasserfall, Business Impact). Neuer Generator `bilder_04/erzeuge_wirkung.py`; das Supply-Chain-Kapitel bekommt damit **sein erstes Diagramm** überhaupt. **Der Anlass:** Die Tabelle im Kapitel nannte nur die Summen — 874 870 € gegen 351 356 €, 149 % mehr. Wofür genau, stand nirgends. **Der Generator rechnet die Instanz erneut**, wie es die Konvention verlangt („so können Diagramm und Buchtext nicht auseinanderlaufen"). Die Probe fiel gut aus: Der unabhängige Nachbau reproduziert beide abgedruckten Summen **exakt**, dazu 178,7 MWh Fehlmenge und 28/40 Szenarien mit Abwurf. Kein Auseinanderlaufen — der erste Generator dieser Reihe, der nichts findet, und das ist ein Ergebnis für sich. **Was die Zerlegung zeigt und die Tabelle nicht:** | | Anfahrt | Brennstoff | Lastabwurf | Gesamt | | --- | ---: | ---: | ---: | ---: | | zweistufig | 58 000 € | 293 356 € | 0 € | **351 356 €** | | Erwartungswert | 58 000 € | 280 631 € | 536 239 € | **874 870 €** | Die **Anfahrkosten sind identisch** — der Erwartungswert-Plan spart also nicht dort, wo man es vermuten würde. Er spart 12 725 € Brennstoff und bezahlt dafür 536 239 € Lastabwurf: das **42-fache**. „149 % mehr" ist eine Zahl, über die man streiten kann; „wir sparen 12 725 € und riskieren 536 239 €" ist eine, über die man entscheidet. Die Trennung von Brennstoff- und Abwurfkosten ist der einzige Zusatz gegenüber `bewerte()` im Buchprogramm; dort wird sie nicht gebraucht. **Ein eigener Fehler unterwegs:** Ein `.replace(",", ".")` für deutsche Tausenderpunkte lag auf dem **ganzen Titelsatz** und machte aus „Brennstoff, Preis" ein „Brennstoff. Preis". Jetzt gibt es `euro()`, das nur auf Zahlen angewandt wird — mit einem Kommentar, der genau davor warnt. SVG byteidentisch über zwei Läufe. Diagramme jetzt **33**, davon **19** mit Generator (16 Skripte). ### ✅ 7.3 Glossar „Deutsch — OR" ({ref:kap:modellierung}) Setzt Paket 7 aus `Verbesserungen_03.md` um. Neuer Abschnitt {ref:sec:modellierung-glossar}, unmittelbar hinter dem Gesprächsleitfaden: Die zwölf Fragen liefern Sätze — hier werden sie übersetzt. **Die Abgrenzung zu Anhang B war die eigentliche Entwurfsfrage.** Der Musterkatalog hat längst eine Spalte „Umgangssprachlich", aber er läuft in die andere Richtung: **Muster → Formulierung**. Wer aus einer Besprechung kommt, hat den Satz und sucht den Baustein. Das Lexikon ist genau so herum gebaut (21 Einträge, jeweils mit B-Nummer), und Anhang B bekam einen Rückverweis. Kein Duplikat, sondern die fehlende Gegenrichtung. **Der Teil, der den Abschnitt trägt, ist aber nicht die Tabelle**, sondern was danach kommt: **fünf Wendungen, bei denen die Übersetzung eine Entscheidung erzwingt** — „möglichst", „nicht mehr als drei pro Woche", „im Durchschnitt", „so schnell wie möglich", „fair". Bei jeder gibt es zwei bis drei vertretbare Modelle, und die Wahl gehört dem Betrieb, nicht dem Modellierer. Das ist die These des Kapitels („Ein Satz ist noch kein Modell"), hier auf die Alltagssprache angewandt. Dazu die **Gegenrichtung OR → Deutsch**: acht Sätze, die sich bewährt haben, wenn ein Ergebnis jemandem erklärt werden muss, der das Modell nicht kennt — einschließlich der Formulierung für `INFEASIBLE` („Ihre Regeln widersprechen sich", **nicht** „der Computer schafft es nicht"). Die neue Übungsaufgabe lässt drei Zielfunktionen für „gleichmäßig ausgelastet" aufstellen; die Lösung nennt je einen Fall, in dem die Wahl den Plan sichtbar ändert — und weist darauf hin, dass zwei der drei einen Halbtagsmonteur bestrafen. Mitgezogen: Lernziel, Zusammenfassung, Rückverweis aus Anhang B, Pfad E im Vorwort (er führte bisher direkt zum Musterkatalog, jetzt über das Lexikon). **Damit ist Phase 7 abgeschlossen.** 296 Abschnitte, 766 Querverweise, 141 Aufgaben mit 141 Lösungen, PDF **749** Seiten. ### ✅ 8.1 Synthese-Seiten je Teil — und ein Fund in der Lesekette Setzt Paket 5 aus `Verbesserungen_02.md` um (den Teil, der nicht zurückgestellt wurde). Fünf neue Dateien `19_/29_/39_/49_/52_Synthese_*.md`, je eine am Ende eines Teils, mit eigener Website-Seite (`SONDERSEITEN`, weil sie bewusst **keine** `# Kapitel:`-Überschrift tragen — sie sind keine Kapitel, sondern der Rückblick auf einen Teil). **Der Entwurf musste sich abgrenzen:** Die Teil-**Einleitungen** haben bereits Entscheidungsdiagramme („welches Werkzeug passt zu meinem Problem"). Eine zweite Entscheidungsmatrix am Teil-Ende wäre eine Dopplung gewesen. Die Synthesen leisten deshalb das, was eine Einleitung nicht kann: den **Vergleich über die Kapitel hinweg** (Verfahren nebeneinander, mit der Spalte „wo es aufhört"), eine Tabelle **„was dieser Teil gemessen hat"** — Behauptung gegen Messung gegen Fundstelle — und drei Fehler, die der Teil verhindert. Zitiert wird ausschließlich, was im Buch tatsächlich gerechnet wird. ### Drei Funde beim Einbau **Erstens: Teil III sagte „die drei Kapitel dieses Teils", hat aber fünf.** Phase 3 hatte {ref:kap:mehrziel} und {ref:kap:prognose} hinzugefügt, die Einleitung blieb stehen. Sie nennt die drei Abweichungen jetzt weiterhin, schließt die beiden späteren Kapitel aber ausdrücklich an. **Zweitens: `50_Praxis.md` verwies auf die Projektwerkstatt mit „acht eigene Anwendungen"** — sie hat elf. **Drittens, und das ist der eigentliche Fund: Die Lesekette der Quelldateien führte an acht Kapiteln vorbei.** Nach Phase 3 zeigte `12_Python_Oekosystem.md` direkt auf `20_Lineare_Programmierung.md`, `23_Graphen…` direkt auf `30_QP…`, `32_Dynamische…` direkt auf `40_Finanzdaten.md`, `50_Praxis.md` direkt auf die Projektwerkstatt. Wer der Kette folgte, übersprang **acht von 23 Kapiteln** — darunter Metaheuristiken, Spaltengenerierung, Mehrziel, Predict-then-Optimize, Strukturbrücke, Supply-Chain und das ganze Testing-Kapitel. Zehn weitere Dateien hatten gar keine Navigationszeile. **Zur Reichweite, damit sie nicht überschätzt wird:** Diese Zeilen stehen **nur in den Quelldateien**. `entferne_navigation()` streicht sie aus dem Gesamtdokument, und die Website baut ihre Vor/Zurück-Knöpfe selbst aus `DATEIEN`. PDF und Website waren also nie betroffen — wohl aber jeder, der die Markdown-Dateien im Repository liest, und das wird nach der Veröffentlichung der Normalfall sein. Die Kette ist jetzt über **alle 35 Übergänge** geschlossen, und `--check` bewacht sie: Fehlt eine Zeile oder zeigt sie an der in `DATEIEN` folgenden Datei vorbei, ist der Lauf rot. Gegengetestet mit beiden Bruchformen. Stand danach: **36 Dateien** (31 + 5 Synthesen), 296 Abschnitte, **815** Querverweise, 303 Hauptüberschriften, PDF **758** Seiten. ### ✅ 8.2 Solver-Isolation ohne `subprocess`-Codestrings Setzt den Isolationsteil von Paket 1 aus `Verbesserungen_02.md` um. Der Plan nannte zwei Programme; beim Suchen kam ein **drittes** dazu, das dasselbe Muster verwendete. **Was ersetzt wurde.** `Ein_System_Vier_Ansaetze.py` und `Benchmark_Skalierung.py` hielten ihre vier Solvervarianten als **Zeichenketten** in einem Dictionary und gaben sie an `python -c` weiter — bei `Benchmark_Skalierung.py` sogar mit `.format()`-Platzhaltern für die Instanzgröße. Aus jeder Variante ist jetzt eine gewöhnliche Funktion mit **lokalem Import** geworden. `Solverwechsel_CPSAT_HiGHS.py` rief sich selbst über `sys.argv` erneut auf; auch das entfällt. Ausgeführt wird über einen `ProcessPoolExecutor` mit zwei Einstellungen, die zusammen die Garantie ergeben — und beide sind nötig: * `mp_context="spawn"` — frischer Interpreter statt geerbtem Speicher. Unter Linux ist `fork` der Standard, und damit wäre alles bereits Importierte auch im Kind importiert. * `max_tasks_per_child=1` — ein **neuer** Prozess je Aufgabe. Ohne das verwendet der Pool seinen Arbeiter wieder, und beim zweiten Solver ist der Konflikt zurück. Nachgemessen: vier Aufgaben, vier verschiedene PIDs. Der zweite Punkt hat einen eigenen ⚠️-Kasten bekommen, weil der Fehler leicht zu machen und schwer zu finden ist: Der Absturz käme nicht beim ersten Solver, sondern beim zweiten — und sähe aus wie ein Problem des zweiten. **Regel 4, dreifach geprüft.** Alle drei Programme drucken Ausgaben, die im Buch stehen: * `Ein_System_Vier_Ansaetze.py`: identisch bis auf die Zeitspalte, **einschließlich der Spannweite 2,41 · 10⁻⁸**, auf die sich der Merksatz des Kapitels beruft. * `Benchmark_Skalierung.py`: **alle zwölf Zielwerte und alle drei Spannweiten bitgleich**; Zeiten und Speicher haben sich verschoben, beide sind im Abdruck seit jeher als hardwareabhängig gekennzeichnet. * `Solverwechsel_CPSAT_HiGHS.py`: Ausgabe ohne Zeiten unverändert. **Was bewusst `subprocess` bleibt:** `Mutationstest.py`. Dort wird pytest auf einer **mutierten Kopie** in einem temporären Verzeichnis gestartet — ein externes Werkzeug auf veränderten Dateien, nicht die Isolation eines Imports. Für diesen Fall ist `subprocess` richtig. **Neu im Kapitel Ökosystem:** ein Abschnitt „Wie die Isolation aussieht, wenn sie tragen soll" — warum ein Codestring die schlechteste Umsetzung von „eigener Prozess" ist (unsichtbar für Editor, Linter und Testwerkzeug; Tippfehler fallen erst zur Laufzeit auf; übergeben lassen sich nur Zeichenketten). Anhang C nennt jetzt ebenfalls `ProcessPoolExecutor` statt `subprocess`. **Ein eigener Fehler, gefunden und abgesichert:** Ich hatte dem neuen `###` ein `{#sec:...}`-Label gegeben. `ABSCHNITT_RE` erkennt nur `## ` — das Label wäre nie registriert worden, und jeder Verweis darauf ins Leere gelaufen, ohne Warnung. Label entfernt, und `--check` meldet diesen Fall jetzt. Gegengetestet. Stand danach: 818 Querverweise, PDF **760** Seiten, 69 netzfreie Programme fehlerfrei. ### ✅ Achter Fund: die „Übung N.N"-Verweise Sieben Sätze der Bauart „Übung 8.5 lässt Sie diese Balance untersuchen" — und **sechs davon standen in alter Zählung**. „8" war in Version 03 das QP/NLP-Kapitel, heute ist es Kapitel 11. Dieselbe Familie wie die Denkfehler-Verweise aus 6.1a, nur mit einem Wort, das keine der bestehenden Prüfungen kannte. Aufgaben haben kein eigenes Label, ein `{ref:}` auf eine einzelne Aufgabe ist also nicht möglich. Verwiesen wird stattdessen auf **Abschnitt plus Aufgabentitel** — und der ist stabil: „die Aufgabe *Gültigkeitsbereich des Schattenpreises* ({ref:sec:lp-uebungsaufgaben})". Jedes Ziel wurde einzeln über die alte Zählung bestimmt und am Zusammenhang geprüft. **Ein Fall war knifflig:** „Übung 6.7 (Wochendienstplan)" meinte die siebte CP-SAT-Aufgabe der alten Zählung, also *Eigener Dienstplan* — die heute an achter Stelle steht, weil ich in Phase 6.3 selbst eine Aufgabe davor eingefügt habe. Wer nur die Kapitelnummer angepasst hätte, wäre bei der falschen Aufgabe gelandet. `--check` kennt jetzt auch „Übung"/„Uebung". Gegengetestet. Querverweise 818 → 825. ### ✅ 8.3 Dockerfile — gebaut und durchgemessen Setzt den letzten Teil von Paket 1 aus `Verbesserungen_02.md` um. Zweistufig: Die erste Stufe übersetzt die Abhängigkeiten in eine virtuelle Umgebung und braucht dafür einen Compiler, die zweite kopiert nur `/opt/venv` — die Bauumgebung landet nicht im Image. Installiert werden die Gruppen `finance`, `large-scale`, `api` und `dev` aus `pyproject.toml`; `figures` fehlt bewusst, weil es zusätzlich Graphviz verlangt. **Es wurde nicht behauptet, sondern gebaut.** Ergebnis: **1,31 GB**, und darin * der `Installationstest.py` mit allen drei Solver-Funktionstests bestanden, * die 33 pytest-Tests bestanden, * **alle 69 netzfreien Programme fehlerfrei** — einschließlich der drei aus 8.2, deren `spawn`-Isolation im Container ebenso trägt wie außerhalb. **Zwei Dinge, die der Bau gelehrt hat.** Erstens: `libgomp1` fehlt im `python:3.12-slim`-Image und wird von OR-Tools und HiGHS zur Laufzeit gebraucht — ohne es scheitert der erste Solveraufruf mit `libgomp.so.1: cannot open shared object file`. Zweitens, ein eigener Fehler: Ich hatte `USER kurs` **vor** das `mkdir /buch/output` gesetzt; `/buch` gehört root, und der Bau brach in der letzten Zeile ab. Beides steht jetzt als Kommentar im Dockerfile. Das Image führt die Programme aus und **baut das Buch nicht** — pandoc, xelatex und inkscape wären zusammen über ein Gigabyte ohne Nutzen für jemanden, der die Beispiele durchrechnen will. Ein `.dockerignore` hält Website, PDF und Notebooks aus dem Build-Kontext. Und der Punkt, der erklärungsbedürftig ist: Das Image enthält `ortools` **und** `highspy`, obwohl sie sich nicht gemeinsam importieren lassen. Der Konflikt wird nicht durch Weglassen gelöst, sondern zur Laufzeit durch getrennte Prozesse — ein Image mit nur einem von beiden könnte die Hälfte der Beispiele nicht ausführen. **Damit ist Phase 8 abgeschlossen und der Plan abgearbeitet.** ### ✅ Aufgeräumt — und dabei zwei Funde **Die 33 PNG-Zweitfassungen sind weg.** Jedes Diagramm lag doppelt vor, als SVG und als PNG, und **kein einziges `src=`/`href=` in der Website zeigte je auf ein PNG**. Der Build kopierte sie trotzdem mit: 3,3 MB im Repository plus 3,3 MB, die bei jeder Veröffentlichung auf den Webserver gingen, ohne dass sie jemand abrief. Die 15 Generatoren schreiben jetzt nur noch SVG; die Docstrings sind mitgezogen. Vor dem Löschen geprüft: Jedes PNG hatte sein gleichnamiges SVG, und alle 33 waren versioniert — rückholbar. **Fund 1 dabei: `erzeuge_kap06_gantt.py` folgte als einziger Generator nicht der Konvention.** Weder `svg.hashsalt` noch `metadata={"Date": None}` waren gesetzt. Sein SVG trug deshalb einen echten Zeitstempel und bei jedem Lauf andere `clip-path`-IDs — es war **nie** byteidentisch reproduzierbar, obwohl `CLAUDE.md` genau das für alle Generatoren festhält. Aufgefallen ist es nur, weil nach der PNG-Umstellung 32 von 33 SVGs bitgleich blieben und eines nicht. Jetzt byteidentisch über zwei Läufe. **Fund 2: `spiegle_bilder()` legte leere Verzeichnisse auf dem Webserver an.** Der Dateifilter arbeitete korrekt, aber `os.walk` durchlief auch `__pycache__/`, und `os.makedirs()` erzeugte es am Ziel — ein leerer Ordner in `OR_HTML_04/bilder_04/`. Die Verzeichnisliste wird jetzt vorher gefiltert. Gegengetestet. **`Excel_Bruecke.py` schreibt neben das Skript statt ins Arbeitsverzeichnis.** Es benutzte blanke relative Namen; wer es aus der Repository-Wurzel startete, verstreute dort `produktionsmix.xlsx` und `produktionsmix_ergebnis.xlsx`. Jetzt wie die vier anderen schreibenden Programme über `os.path.dirname(os.path.abspath(__file__))`. Nachgemessen: Lauf aus der Wurzel legt dort **null** Dateien ab. **Und `git gc`:** 653 lose Objekte gepackt, `.git` von 71 MB auf **28 MB** — reines Repacken, kein Inhalt berührt. --- ## 8. Commit-Historie des V04-Strangs > **Zu den Kapitelnummern in dieser Tabelle:** Sie stammen aus den Commit-Betreffs und geben > die Nummerierung **zum Zeitpunkt des Commits** wieder. Nach den acht in Phase 3 > eingefügten Kapiteln stimmen sie nicht mehr mit dem heutigen Buch überein — sie hier > nachzuziehen würde die Tabelle von den tatsächlichen Commits entkoppeln. Überall sonst in > dieser Datei stehen Kapitel**namen**. | Commit | Datum | Inhalt | | --- | --- | --- | | `604c532` | 06.09. | Version 04 anlegen: Infrastruktur und Kapitel 1–3 | | `72fa8a8` | 06.09. | Arbeitsplan als versionierte Datei | | `a661a99` | 06.09. | Kapitel 4: Schattenpreise, und wann sie eine Entscheidung nicht tragen | | `1d0170a` | 06.09. | Kapitel 5: MIP-Gap, Warm-Starts und die stille Big-M-Falle | | `138be3f` | 07.09. | Kapitel 6: Die fünf Antworten von CP-SAT und die Strafgewichts-Falle | | `360ffb2` | 07.09. | Kapitel 7 und die Entscheidungs-Flussdiagramme für Teil II und III | | `b052653` | 07.09. | Kapitel 8: Jenseits der Konvexität — lokale Optima, Multistart, MINLP | | `4ab2ad3` | 07.09. | Kapitel 9: Newsvendor als Einstieg, und der zweite Fluch des Durchschnitts | | `fe7c0b9` | 07.09. | Kapitel 10: Rückwärtsinduktion und der Zustand, der zu wenig weiß | | `f519e2d` | 07.09. | Kapitel 11 und der Auftakt zu Teil IV | | `2583bbc` | 07.09. | Kapitel 12: Die Effizienzlinie als Speisekarte | | `a7049e5` | 07.09. | Kapitel 13: Der VaR sagt wie oft, der CVaR wie schlimm | | `5213258` | 07.09. | Kapitel 14: Die Reihenfolge zählt, und die Zahl der Versuche auch | | `b154fe8` | 07.09. | Kapitel 15 — Phase 1 abgeschlossen | | `33e9a36` | 07.09. | Phase 2 beginnt: `or_kern.py` als gemeinsamer Unterbau | | `eeea9e8` | 07.09. | Excel-Schicht nach `or_kern.py`, `Excel_Bruecke.py` umgestellt | | `ed3640d` | 07.09. | Phase 2 abgeschlossen: Statusauswertung, Abnahmeprüfung, Solverwechsel | | `5c6cc2d` | 07.09. | Plan und Fortschritt als eigene Dateien im Repo-Wurzelverzeichnis | | `1c856f1` | 07.09. | Kapitel 1 der Version 03: Umformatierung durch den Editor übernehmen | | *(dieser)* | 07.09. | Planungsdateien konsolidiert, `CLAUDE.md` kennt jetzt Version 04 |

` beginnt und danach ein paar Dutzend Leerzeichen enthält. Pandoc schließt den Roh-HTML-Block am ersten Blocktag und liest den eingerückten Rest als **indented code block**. `resolve_plotly()` gibt das Fragment jetzt als Rohblock (` ```{=html} `) aus, den Pandoc unverändert durchreicht — unabhängig von Einrückung und Zeilenlänge. Nachgeprüft: vier eingebettete Figuren, kein `

` mehr.

Das ist genau der Fall, für den die Schlussabnahme da ist: Der Build meldete nie einen
Fehler, `--check` war grün, und im PDF war alles in Ordnung, weil dort ohnehin die statische
Fassung steht.

**Zwei kleinere Korrekturen nebenbei.** Der Platzhaltertext im PDF lautete *„steht auf der
Website des Buches bereit"* — er erscheint aber auch in `gesamtdokument.html`, und wer das
liest, ist bereits auf der Website. Jetzt: *„auf den Kapitelseiten der Website"*.

Und ein eigener Fehlgriff: Für die V03-Gegenprobe hatte ich `--html` statt `--check` laufen
lassen. Das regenerierte V03-Artefakte (Datumsstempel, Tabellenausrichtung) — an einem
Strang, der eingefroren ist. Zurückgenommen; der Arbeitsbaum enthält keine V03-Änderung.
**Dabei ist allerdings aufgefallen:** V03s generiertes Gesamtdokument ist gegenüber seinen
Quelldateien leicht veraltet (Tabellenausrichtung, Stand-Datum). Das stammt aus einer
Quelländerung vor dieser Sitzung, nicht aus dem Umbau — wer V03 einmal neu baut, zieht es
nach.

**Sichtprüfung der Website** (strukturell nachgezählt statt behauptet): Landing-Page mit 35
Seitenverweisen, Sidebar mit Navigation und Suchfeld auf den Kapitelseiten, Suchindex mit
592 Einträgen, Stichwortverzeichnis mit 24 Buchstabengruppen und 323 Verweisen, didaktische
Karten (`card-blick`, `card-schnellstart`, `card-denkfehler`, `card-quiz`) auf den
Kapitelseiten, 73 Programme und 25 Notebooks zum Herunterladen, KaTeX lokal eingebunden,
**kein einziger toter Bildverweis**, und seitenübergreifende Querverweise lösen als
`andere-seite.html#anker` auf.

### Trennung von Version 03 und Version 04 ✅

Beide Ausbaustufen lagen bis dahin nebeneinander im selben Wurzelverzeichnis. Jetzt liegt
jede in einem eigenen Baum: **`Version_04/` ist die Wurzel dieses Strangs** und taugt
unmittelbar als Wurzel eines eigenen Repositorys; `Version_03/` steht daneben, eingefroren.

**Der Umbau kostete keine einzige Pfadänderung an den Skripten.** Alle leiten ihre Pfade aus
der eigenen Position ab — `BASIS = dirname(HIER)` in den Build-Skripten,
`BASIS = dirname(dirname(__file__))` in den 15 Bildgeneratoren — und jeder `subprocess.run`
läuft mit `cwd=BASIS`. Mit dem Verschieben wurde `BASIS` automatisch zu `Version_04`. Der
`--check` lieferte am neuen Ort auf Anhieb dieselben Zahlen wie vorher.

Verschoben wurde mit `git mv`, die Historie bleibt darum vollständig. Die Trennung in zwei
Repositories ist **noch nicht vollzogen**; sie erfolgt später mit
`git subtree split -P Version_04 -b v04-only`, was die Historie mitnimmt.

**Was dabei zu tun war, ging fast alles über Pfadangaben in Prosa hinaus:**

1. **Der PDF-Bau hing an zwei Dateien außerhalb des Repositorys.**
`~/.config/pandoc/defaults.yaml` (Schriften, Geometrie) lädt darin per **absolutem** Pfad
`~/.pandoc/templates/header-includes.tex`. Ein frischer Klon hätte **kein PDF bauen
können** — die Meldung wäre nur „pandoc-Defaults nicht gefunden" gewesen.
Beide liegen jetzt als `pandoc-defaults-basis.yaml` und `pandoc/header-includes.tex` im
Repository, mit relativiertem Pfad; `build_version_04.py` bevorzugt die Kopie und fällt
auf die Benutzerdatei zurück.
**Nachgewiesen**, nicht behauptet: Mit temporär entfernten Benutzerdateien baut das PDF
unverändert 715 Seiten.
2. **`pandoc-defaults-buch.yaml` brauchen beide Versionen** unter ihrem jeweiligen `BASIS` —
sie wurde kopiert, nicht verschoben.
3. **`.gitignore` dreigeteilt.** Die versionsspezifischen Regeln stehen jetzt **in**
`Version_03/` und `Version_04/`, relativ zum jeweiligen Verzeichnis. Damit gilt
`Version_04/.gitignore` unverändert weiter, sobald der Baum herausgelöst ist. In der
Wurzel bleibt nur, was überall gilt.
4. **Ein Altfehler im Buchtext**, bei der Gelegenheit gefunden:
`00_Vorwort_und_Lesehilfe.md` schickte Leser zu
`Operations_Research_mit_Python_Programme/requirements.txt` — ein Verzeichnis, das es nie
gegeben hat. Korrigiert auf `…_Version_04_Programme/`.
5. **Die Wiederaufnahme-Checkliste oben** hätte sonst mit einem falschen Verzeichnis begonnen
und in Schritt 4 auf ein Version-03-Skript gezeigt, das von hier aus nicht mehr auflöst.

**Neu ausgestattet, damit `Version_04/` als Repo-Wurzel taugt:** `README.md` (Bau- und
Laufanleitung, Werkzeugliste, die beim Veröffentlichen zu setzenden Werte), `CLAUDE.md`
(V04-Konventionen ohne V03-Bezüge) und der Kommentar an `COLAB_BASIS_URL`, der ihn als den
einen beim Veröffentlichen zu ändernden Wert ausweist — der Pfadteil `Notebooks_04/…` stimmt
bereits, weil er relativ zur Repository-Wurzel aufgelöst wird.

**Verifiziert am neuen Ort:** `--check` ohne Warnung (703 Querverweise, 325 Indexmarken),
**73 Programme mit 0 Fehlern**, 33 pytest-Tests grün, PDF 715 Seiten, ein Bildgenerator,
`OR_HTML_04/` selbstgenügsam (kein Verweisziel außerhalb), Version 03 unverändert baubar.

### Titel, Untertitel und Titelblatt geändert ✅

Das Buch heißt jetzt **„Optimierte Entscheidungsfindung mit Python"**, Untertitel
**„Von der mathematischen Modellierung zu praktischen intelligenten Lösungen für Betrieb,
Technik und Finanzmärkte"**. Bis Version 03 lautete der Titel „Operations Research mit
Python".

Auf dem Titelblatt stehen **vier** Textblöcke: Titel, Untertitel und in der Solver-Karte die
beiden Absätze aus `Kritik_und_Verbesserungsvorschlaege/NEUER_TITEL.md` — die
Kompendium-Beschreibung und die Anwendungsfelder. **Maßgeblich sind die Zeichenketten in
`erzeuge_titelseite.py`**; `NEUER_TITEL.md` ist die Vorlage, aus der sie stammen.

**Das Titelblatt musste dafür neu gesetzt werden, nicht nur umbenannt.** Die Textzeilen
standen mit von Hand vermessenen Koordinaten in `erzeuge_titelseite.py`, übernommen aus der
ursprünglichen, gezeichneten SVG — das trägt genau so lange, wie sich der Text nicht ändert.
Jetzt **misst** das Skript: `_textbreite()` fragt den echten Renderer, `_umbrechen()` bricht
auf den Satzspiegel um, `_setze_block()` stapelt mit definiertem Durchschuss. Der Titel wurde
seither dreimal geändert; ab dem zweiten Mal kostete das nur noch das Austauschen von
Zeichenketten.

Gemessene Werte: Titel **34 pt** in drei Zeilen, Untertitel **14 pt** in zwei Zeilen,
Kartentext **11,5 pt** in 3 + 1 + 5 Zeilen (Spanne 117 pt bei 141 pt Kartenhöhe).

Zwei dieser Größen sind gegenüber der ersten Fassung gefallen, und zwar aus messbaren
Gründen: Der Untertitel bräuchte bei 15 pt **drei** Zeilen, deren letzte nur noch das Wort
„Finanzmärkte" trüge — ein Hurenkind mitten auf dem Titelblatt; bei 14 pt sind es zwei
ausgeglichene Zeilen. Und der Kartentext ist auf neun Zeilen gewachsen: Bei 12 pt blieben nur
9 pt Luft über und unter dem Block, und der Text geriete in die abgerundeten Kartenecken
(Radius 11,9 pt); 11,5 pt lassen 12 pt.

**Warum der Titel dreizeilig ist:** „Entscheidungsfindung" ist bei 34 pt bereits 429 pt breit
und damit fast so breit wie der ganze Satzspiegel (453 pt). Jede zweizeilige Aufteilung
bräuchte mindestens 649 pt — das passt bei keiner lesbaren Schriftgröße. Der Umbruch wird
über ein `\n` im `TITEL` erzwungen, damit „mit Python" zusammenbleibt.

**Der Platz für den zweiten Kartenabsatz kam aus dem kürzeren Untertitel.** Er braucht nur
noch zwei statt vier Zeilen; Trennlinie und Kartenoberkante sind deshalb von y = 336,7 / 368,7
auf 308 / 340 gerückt, und die Karte wuchs von 113 auf 141 pt. Beide Werte stehen als
gemeinsame Konstanten am Dateikopf, aus denen `_design()` und `_texte()` lesen — Kasten und
Text können nicht auseinanderlaufen.

**Zwei Sicherungen sind eingebaut** und gegengetestet: Passt eine Titelzeile nicht in den
Satzspiegel oder läuft der Kartentext über den Kartenrand, bricht das Skript mit einer
Meldung ab, statt ein Titelblatt zu erzeugen, auf dem Text übereinanderliegt.

**Der Titel steht an genau zwei Stellen** statt verstreut: `SITE_TITEL` im Versionsblock von
`build_version_04.py` — von dort lesen ``, Kopfleiste, Landing-Page, Notebook-Kopf und
der `pagetitle` des Gesamtdokuments — und `TITEL` in `erzeuge_titelseite.py`, weil er dort
umbrochen und vermessen werden muss.

**Nicht** geändert: die Verzeichnis- und Dateinamen (`Operations_Research_mit_Python_…`) und
die historischen Dokumente unter `Kritik_und_Verbesserungsvorschlaege/`.

**Die Anwendungsfelder auf dem Titelblatt sind gegen den Inhalt geprüft.** Zu jedem Begriff
gibt es ein gerechnetes Beispiel:

| Anspruch | belegt durch |
| --- | --- |
| Personaleinsatz-, Schicht- und Vertretungspläne | `CP_SAT_Vertretungssystem.py`, Schichtplan-Beispiel in {ref:kap:cpsat} (6 Personen, 14 Tage), Projekte P1/P2 |
| Fahrtrouten | `VRP_Flotten_Routing.py` (CVRPTW, 16 Kunden, 619 km), `VRP_Kapazitaetsfalle.py` |
| Logistik | Min-Cost-Flow-Transportnetz, VRP, {ref:kap:supplychain} |
| Maschinenauslastung | `JobShop_Intervalle.py`, Rüstzeitmuster B26 |
| Netzwerkauslastung | `Min_Cost_Flow.py` mit Kantenkapazitäten |
| Energieverteilung | `Kraftwerkseinsatz.py` (Unit Commitment mit Windunsicherheit) |
| Ressourcenplanung | `Bot_Allokation.py`, `Rucksack.py` |
| Portfoliooptimierung, Finanzmärkte | {ref:kap:markowitz}, {ref:kap:cvar}, {ref:kap:handelsmaschine} |

**Ein Begriff wurde dabei ausgetauscht.** Die erste Fassung warb mit „Stundenplänen" — das
Wort kommt im ganzen Buch nur zweimal vor, als Stichwort in einer CP-SAT-Tabelle und als
*Datenquelle* im Projektauftrag P1. Ein Stundenplan im engeren Sinne (Klassen, Fächer, Räume,
Lehrerverfügbarkeit gegeneinander optimieren) wird **nicht** gerechnet; gerechnet werden
Vertretungsplan und Schichtplan. Die Formulierung lautet jetzt „Personaleinsatz-, Schicht-
und Vertretungsplänen" und deckt sich damit mit dem, was das Buch einlöst.

**Verifiziert:** `--check` ohne Warnung, PDF 715 Seiten, Titelblatt in PDF und Website
sichtgeprüft, kein Rest eines früheren Titels in Quellen oder generierten Seiten, 33
pytest-Tests grün, Version 03 unberührt.

---

## 7. Was als Nächstes ansteht

### Der Stand

**Alle Phasen sind abgeschlossen** — die sechs des Umbaus, dazu Phase 6 bis 8 aus
`Verbesserungen_02.md`/`_03.md`. `Version_04/` ist seit dem 08.09.2026 ein eigenes
Git-Repository. 23 Kapitel, 5 Anhänge, 5 Teil-Synthesen, **76** lauffähige Programme,
141 Aufgaben mit 141 Lösungen, 33 Diagramme, PDF mit 760 Seiten, Website mit vier
interaktiven Figuren.

**Zum eigenen Repository — eine Korrektur der früheren Angabe hier:** `git subtree split -P
Version_04` hätte die Historie **nicht** mitgenommen. Der Pfad `Version_04/` existiert erst
seit der Verzeichnistrennung; der Split hätte 7 statt 41 einschlägiger Commits gebracht — eine
Teilhistorie, die vollständig aussieht und es nicht ist. Volle Historie ginge nur über
`git-filter-repo` (nicht installiert). Deshalb: frischer `git init -b main`, das
übergeordnete Repository bleibt das Archiv der 71 Commits und trägt `Version_04/` in seiner
`.gitignore`.

### Was von außen kommen muss

1. ✅ **Remote-Repository angelegt und gepusht** — <https://kitux.de/forgejo/dschlueter/operations_research>,
öffentlich, Branch `main`.
2. ✅ **`COLAB_BASIS_URL` geklärt — und zwar anders als geplant.** Der Platzhalter zeigte auf
GitHub, das Repository liegt auf einer eigenen Forgejo-Instanz. Colab öffnet Notebooks
**nur** aus GitHub, Google Drive oder einem Upload; die URL-Form
`colab.research.google.com/github/…` ist fest auf GitHub verdrahtet. Eine
selbstgehostete Adresse dort einzusetzen ergäbe keinen Link zum eigenen Server, sondern
einen toten GitHub-Link — der Kommentar im Quelltext („zu ändern sind nur Kontoname und
Repository-Name") ging von GitHub aus und war damit selbst irreführend.
Die Konstante steht jetzt auf `""`: Die Colab-Zeile entfällt, der **Download-Link auf das
Notebook bleibt**, ergänzt um den Hinweis, was man damit tut. Ein späterer GitHub-Spiegel
braucht weiterhin nur diesen einen Wert.
3. ✅ **Veröffentlicht** unter <https://jamulix.de/OR/> — Landing-Page, Kapitelseiten, Diagramme,
Notebooks, Suchindex, KaTeX und PDF sind erreichbar (alles HTTP 200 geprüft).

⚠️ **Aber: Die dort liegende Fassung ist einen Bau alt.** Sie stammt aus der Zeit nach
Phase 8.1 (die fünf Synthese-Seiten sind da), aber vor der Colab-Umstellung: `lp.html`
enthält noch einen toten Colab-Link, die neue Notebook-Formulierung fehlt, und das PDF
ist 3 820 135 statt 3 816 207 Bytes groß. **`OR_HTML_04/` muss neu kopiert werden** — und
künftig nach jedem `--pdf --html`.

### Bewusst zurückgestellt (aus `Verbesserungen_02/_03`)

* **Streamlit-Apps** (V03/1, 2, 5) — Entscheidung des Autors. Sie wären eine neue
Artefaktklasse: nicht über die Programmsuite prüfbar, ohne abgedruckte Ausgabe (Regel 4).
Der „Was-wäre-wenn"-Gedanke daraus ist in {ref:sec:praxisfallen-attribution} ohne UI
eingelöst.
* **Zielgruppen-Callouts in allen Kapiteln** (V02/5) — die Lernpfade und die One-Pager aus
7.1 leisten dasselbe gezielter, ohne Eingriff in jeden Abschnitt.
* **`joblib`/`ray`** (V02/2) — `num_workers` und `ProcessPoolExecutor` decken den Bedarf;
ein Cluster-Framework wäre eine Abhängigkeit ohne Beispiel, das sie braucht.
* **Folium-Karten** (V03/3) — **blockiert durch eine offene Entscheidung**: Die VRP-Instanz
ist ein synthetisches 100 × 100-km-Raster ohne Geokoordinaten. Eine echte Karte verlangt
entweder eine neue Instanz (und damit neue abgedruckte Zahlen) oder eine willkürliche
Verankerung an einem realen Ort.
* **Executive-PDF-Report** (V03/6) — ohne Streamlit-Apps fehlt der Ort, an dem er entstünde.

### Offen, rein redaktionell

**53 der 141 Lösungstitel weichen vom Aufgabentitel ab** — durchweg Kürzungen
(„Zweistufiges Modell rechnen" → „Zweistufig rechnen"), alle in den 15 Abschnitten aus
Version 03; die acht in Phase 3 ergänzten stimmen vollständig. Seit 6.1a trägt jede Lösung
wieder die richtige Nummer, die Navigation ist also intakt. Ein Angleichen wäre Kosmetik,
kein Fehler — aber es würde den Anhang lesbarer machen.

### Was einer späteren Sitzung auffällt und **kein** Fehler ist

* **14 der 33 Diagramme haben keinen Generator.** Dokumentierte Entscheidung — Kästen,
Pfeile, beschriftete Formeln, generische Funktionsverläufe. Kriterium in Abschnitt 6c.
* **`Mutationstest.py` benutzt weiterhin `subprocess`.** Richtig so: Dort läuft pytest auf
einer mutierten Kopie, das ist ein externes Werkzeug auf veränderten Dateien und keine
Import-Isolation (Abschnitt 8.2).
* **Die abgedruckte Ausgabe von `Parallele_Suche.py` ist absichtlich nicht byteidentisch
reproduzierbar.** Die Zahl der verschiedenen Pläne schwankt — und genau das ist die
Aussage des Abschnitts.
* **Version 03 ist eingefroren** und liegt in `../Version_03/`. Ihre READMEs nennen als
Arbeitsverzeichnis noch `OR_mit_Python`, und ihr generiertes Gesamtdokument liegt minimal
hinter den Quellen zurück. Beides bleibt bewusst stehen.

### Kleinere offene Punkte aus abgeschlossenen Phasen

- ✅ **Formel-Übersetzer in {ref:kap:markowitz} und {ref:kap:cvar}** — erledigt, siehe
Abschnitt 6c. Damit hat jedes formelreiche Kapitel seinen 🔤-Übersetzer; die Kapitel
Finanzdaten, Handelsmaschine und Praxisfallen sind formelarm, dort besteht kein Bedarf.
- ✅ **`CLAUDE.md` um den V04-Strang ergänzt** — aus Phase 5 vorgezogen, weil `CLAUDE.md`
die einzige Datei ist, die eine neue Sitzung automatisch liest. Ohne diesen Abschnitt
hätte eine frische Sitzung am eingefrorenen V03 weitergearbeitet und `PLAN.md`/`PROGRESS.md`
nie gesehen. Damit war die Wiederaufnahme der eigentliche Schwachpunkt — nicht die Frage,
in welchem Verzeichnis die Planungsdateien liegen.

---

## 6d. Phase 6 — Umsetzung von `Verbesserungen_02` / `_03` 🔄

Grundlage: `Kritik_und_Verbesserungsvorschlaege/Verbesserungen_02.md` und `_03.md`, zwölf
Arbeitspakete. Nach Ertrag geordnet umgesetzt; **Streamlit-Apps sind auf Wunsch des Autors
zurückgestellt**, ebenso Folium-Karten (die VRP-Instanz ist ein synthetisches Raster ohne
Geokoordinaten) und Zielgruppen-Callouts in allen Kapiteln.

### ✅ Repository und `pyproject.toml`

`git init -b main` in `Version_04`, `Version_04` im übergeordneten Repository ausgetragen.
Neu: `pyproject.toml` mit den Gruppen `finance`, `large-scale`, `api`, `figures`, `dev`,
`empfehlungen` — die abgedruckte `requirements.txt` bleibt unverändert daneben bestehen.

**`ortools` steht in der Grundausstattung, `highspy` erst in `[large-scale]`.** Damit kann
der HiGHS-Symbolkonflikt bei der schlanken Installation gar nicht erst auftreten; `cvxpy`
zieht `highspy` nicht nach.

Zwei Funde beim Abgleich der Importe gegen `requirements.txt`:

* **`graphviz` fehlte** — `bilder_04/erzeuge_architektur_diagramme.py` importiert es, die
Leserliste kennt es nicht. Es gehört nicht in die abgedruckte Datei (kein
Beispielprogramm braucht es), steht jetzt aber in `[figures]`.
* **`pymoo` steht in `requirements.txt`, wird aber von keinem der 74 Programme importiert** —
es ist nur eine Empfehlung im Kapitel Metaheuristiken. Jetzt in `[empfehlungen]`.

Später korrigiert: **`cvxpy` lag zuerst in `[finance]`** — falsch, es wird von 13 Programmen
gebraucht, darunter dreien im Kapitel Unsicherheit, lange vor dem Finanzteil. Jetzt in der
Grundausstattung.

### ✅ 6.1 Chance Constraints ({ref:kap:unsicherheit})

Neuer Abschnitt {ref:sec:unsicherheit-chance-constraints} plus `Chance_Constraints.py`
(74. Programm). Das Kapitel hatte Monte-Carlo, Zweistufigkeit und Worst-Case-Robustheit; die
Wahrscheinlichkeitszusage war die fehlende vierte Antwort — und die, nach der das Management
tatsächlich fragt. Beide Wege an **derselben** Instanz: analytisch als
Second-Order-Cone-Bedingung (CLARABEL) und szenariobasiert als Big-M-MILP (SciPy/HiGHS),
beide in einem Prozess ohne `ortools`- oder `highspy`-Import.

Der Fall ist ein Kraftwerkspark mit 500 MW Zusage. **Drei Befunde, alle gemessen:**

1. **Der Mittelwertplan hält 50,08 %.** Kein Fehler, sondern die Definition des
Erwartungswerts — dieselbe Falle wie im Kapitelanfang, nur teurer.
2. **Sicherheit ist konvex bepreist.** 56 289 € je Prozentpunkt auf dem Weg zu 80 %,
253 848 € zwischen 95 % und 99 % — das **4,5-fache**. Das Programm rechnet die Tabelle
selbst aus, statt sie zu behaupten.
3. **Die Zusage gilt nur für die unterstellte Verteilung.** Der 95-%-Plan hält gemessen
**87,44 %**, sobald die Testverteilung eine Kältewelle mit Dunkelflaute enthält, in der
*alles zugleich* einbricht — auch das Gaskraftwerk. In einer reinen Normalwelt liefert
derselbe Plan 94,97 %. Nicht das Verfahren ist falsch, sondern die Annahme.

**Zwei eigene Fehlgriffe unterwegs, beide durch Messen aufgefallen:**

* Die erste Kostentarierung ergab eine **entartete Lösung** (alles ins Gaskraftwerk), womit
die Kovarianzmatrix wirkungslos war — und gerade sie ist der Grund für die Kegelform. Erst
Kosten, die je *erwarteter* MW vergleichbar sind, machen den Konflikt echt.
* Der erste Kälteeinbruch traf nur Wind und Sonne. Der SOC-Plan hatte die aber ohnehin fast
herausgehalten und war zufällig robust (94,40 %) — das Argument trug nicht. Physikalisch
richtig ist, dass bei Frost auch der Gasdruck fällt; damit trifft der Einbruch alles
zugleich, und genau das kann eine Kovarianzmatrix mit Korrelationen um null nicht
ausdrücken.

**Ehrlich berichtet statt geglättet:** Die Szenariomethode **überanpasst**. Über zwölf Läufe
(je vier Ziehungen bei S = 200, 400, 800, geprüft an 200 000 unabhängigen Szenarien) lag die
tatsächliche Quote zwischen **93,14 % und 96,71 %**, und die Spanne wurde von S = 400 auf
S = 800 wieder **breiter**. Beide Solver (SciPy und HiGHS) bestätigten `optimal` bei
identischen Kosten — es ist echte Überanpassung, kein Solverartefakt. Steht als
⚠️-Kasten im Abschnitt.

**Aus der Ausgabe entfernt: die Laufzeitmessung.** Eine Wanduhrzeit ist nie byteidentisch
reproduzierbar (2,2 s / 2,3 s zwischen zwei Läufen) und hätte Regel 4 dauerhaft gebrochen.
Die Beobachtung steht jetzt im Fließtext, wo eine Spanne ehrlich ist. Danach: drei Läufe
zeichengleich, und die abgedruckte Ausgabe stimmt mit dem Lauf des **extrahierten**
Programms überein.

Eine Aufgabenprämisse musste ich verwerfen: „Ab welcher Zusage wird das Modell unlösbar?“ —
das analytische Modell bleibt bis praktisch 100 % lösbar. Die Aufgabe fragt jetzt nach dem
Fall mit gedrosselter Biomasse, in dem das **szenariobasierte** Modell `infeasible` meldet
(7,50 % der Szenarien deckt selbst der Vollausbau nicht), das analytische aber `optimal`
liefert — und dann 87,39 % hält.

### ✅ 6.1a Die letzten handgeschriebenen Nummern — **sechster und siebter** Fund

**Der sechste Fund: 98 Lösungsmarken in Anhang A.** Marken der Bauart
`**9.2 — Ansatz wählen.**`, sämtlich aus Version 03, wo Unsicherheit Kapitel 9 war. Heute ist
es Kapitel 12, und die Aufgabe wird korrekt als „Aufgabe 12.2" gesetzt.

Das war keine Schönheitsfrage: **„Aufgabe 9.2" existiert wirklich** — sie gehört zum Kapitel
Metaheuristiken („Zuggröße und Temperatur"). Wer die Lösung zu 9.2 nachschlug, landete beim
falschen Thema. Beide bisherigen Prüfungen liefen vorbei: Vor der Zahl steht kein
Schlüsselwort, und es ist keine Tabellenzelle.

**Zwei Messungen machten die Reparatur billig.** Erstens: In allen 15 nummerierten
Abschnitten gab es exakt so viele Lösungen wie Aufgaben, lückenlos 1…n — nur der Kapitelteil
war falsch, die Umstellung also reine Mechanik. Zweitens: Die **acht in Phase 3 ergänzten
Kapitel machten es längst richtig** (`**Titel.**` ohne Nummer). Der Anhang wurde damit nicht
auf etwas Neues umgestellt, sondern auf das, was seine neueren Teile schon taten.

Der Build vergibt die Marken jetzt selbst. Der Präfix kommt **nicht** aus `# Anhang A:` —
der Anhang ist *eine* Überschrift, seine Abschnitte gehören aber zu 23 verschiedenen
Kapiteln. Er kommt aus `{#sec:loesungen-<X>}` → `{#kap:<X>}`; diese Zuordnung gilt geprüft
für alle 23. Im Quelltext steht `**{loesung} — Titel.**`.

**Der siebte Fund, unterwegs: neun Verweise auf Denkfehler-Nummern.** Sätze wie „siehe
Denkfehler 8.1" standen in alter Zählung — „8" war in Version 03 das QP/NLP-Kapitel, heute
ist es Graphen. Eine bloße Umnummerierung hätte sie **stillschweigend woanders hin zeigen
lassen**; das Ziel wurde deshalb für jeden einzelnen aus dem Zusammenhang bestimmt (die
Kovarianzmatrix-Stelle in Finanzdaten meint QP/NLP, die „vergessene Dimension" meint Graphen)
und auf `{ref:sec:<kapitel>-denkfehler}` umgestellt — ein Label, das alle 23 Kapitel haben.
Einer davon steckte in einem **Programm-Docstring** und bekam nach Regel 12 den Kapitelnamen
statt eines Verweises.

**Eine Abweichung vom Plan, bewusst:** Der Denkfehler bekommt **gar keine** Nummer. Es gibt
je Kapitel genau einen, die zweite Stelle wäre immer `.1`, und er steht ohnehin unter einer
nummerierten Überschrift. Eine Nummer, die nie variiert, holte nur die Fragilität zurück, die
hier gerade beseitigt wurde. Auch das folgt den acht neuen Kapiteln, die den Denkfehler schon
vorher nur mit dem Titel des Rätsels ankündigen.

**`--check` bewacht jetzt alle Familien** — `Denkfehler N.M`, `Micro-Quiz N`,
`**N.M — ` im Anhang — **und zählt zusätzlich ab**, dass jeder Lösungsabschnitt so viele
`{loesung}`-Marken hat wie sein Kapitel Aufgaben. Das ist die eigentliche Absicherung: Sie
fängt eine vergessene oder doppelte Lösung, was keine Textsuche leisten kann. Gegengetestet
mit vier künstlichen Fehlern auf einmal — alle vier gemeldet, nach dem Rückbau null.

**Die Gegenprobe der Umstellung:** Das gebaute Gesamtdokument vorher gesichert, nachher
verglichen. 168 geänderte Zeilen, restlos einer Familie zuzuordnen — **118** Lösungsmarken,
15 Anhang-Überschriften, 15 Kapitel-Callouts, 12 Micro-Quiz, 7 Zeilen mit Denkfehler-Verweisen
(darauf 8 `{ref:}`), 1 Docstring-Zeile. Keine verschobene, verlorene oder inhaltlich
veränderte Zeile.

Die 118 sind die Probe aufs Exempel: 138 Marken gesamt, davon **20 unverändert** — genau die
Kapitel 1 bis 3, deren alte Nummern zufällig noch stimmten, weil vor ihnen nichts eingefügt
worden war.

Ergebnis: **138 Aufgaben, 138 Lösungen, keine ohne Gegenstück.** Micro-Quiz tragen jetzt die
echten Kapitelnummern (1, 2, 3, 5, 6, 7, 8, 11, 12, 13, 18–22 — die Lücken sind die Kapitel
ohne Quiz). PDF unverändert 725 Seiten.

**Nicht Teil dieser Runde:** In den 15 alten Abschnitten weichen 69 der 138 Lösungstitel von
den Aufgabentiteln ab (gekürzt: „Zweistufiges Modell rechnen" → „Zweistufig rechnen"). Da die
Nummer wieder stimmt, ist sie der Schlüssel; das Angleichen wäre eine rein redaktionelle
Runde.

### ✅ 6.2 Constraint Attribution und Managementbericht ({ref:kap:praxisfallen})

Neuer Abschnitt {ref:sec:praxisfallen-attribution} plus `Constraint_Attribution.py`
(75. Programm). Setzt Paket 3 aus `Verbesserungen_02.md` um — den Teil, der noch fehlte.

**Die Lücke, die es schließt.** Zwei Fälle waren abgedeckt: `Erklaerbarkeit.py` beantwortet
„warum **diese** Zuweisung?", `Konfliktsuche.py` „warum geht es **gar nicht**?". Der
häufigste Fall der Praxis lag dazwischen und hatte kein Werkzeug: *Das Modell rechnet, der
Plan ist zulässig — und trotzdem enttäuschend, nur weiß niemand woran es liegt.*

**Dieselbe Fabrik wie die Konfliktsuche, nach der Reparatur.** Dort war die Lackierkapazität
von 150 Stunden der Kern des Widerspruchs ($2 \cdot 40 + 3 \cdot 30 = 170 > 150$); eine
zweite Schicht bringt sie auf 210, der Mindestumsatz sinkt auf 10 000 €. Damit kann ein
Leser dieselben 14 benannten Bedingungen über zwei Kapitel hinweg verfolgen — erst
„warum nicht?", dann „was kostet was?".

**Drei gemessene Befunde:**

1. **Bindend heißt nicht teuer.** Fünf Bedingungen binden, „Lackierbudget Schicht 2" mit
einem Schattenpreis von **0,00 €**. Dieselbe Unterscheidung, die `Erklaerbarkeit.py` an
einer einzelnen Zuweisung zeigt — hier im Dualwert eines LP.
2. **Der Schattenpreis ist eine Momentaufnahme.** Für die Lackiererei verspricht die
Hochrechnung $4{,}00 \cdot 30 = 120$ €, gemessen kommen **60 €**; der Preis gilt exakt
bis **+15 Stunden**. Die zweite Hälfte der Sonderschicht wäre bezahlt und wirkungslos.
Und die Ranglisten drehen sich: nach Schattenpreis führt der Trägervertrag (18 €/Stück),
nach tatsächlicher Wirkung die Montage-Sonderschicht (450 €).
3. **Ein Wunsch kann unmöglich statt teuer sein.** „Mindestens 55 Rahmen" ist `INFEASIBLE`,
blockiert von **drei** Bedingungen gemeinsam (jede einzeln entfernt macht ihn möglich) —
die Deletion-Filter-Struktur, angewandt auf einen Wunsch statt auf einen Widerspruch. Mit
+15 Stunden Lackierkapazität wird er erfüllbar und kostet dann **nichts**: Der Plan wählt
diese Menge von sich aus. Der Konflikt bestand nie zwischen Vertrieb und Produktion.

**Der Managementbericht** entsteht in Teil (4) aus genau diesen Zahlen — kein Satz enthält
eine Zahl, die nicht vorher gerechnet wurde, auch nicht die Rangfolge und nicht die Namen
der blockierenden Bedingungen. Voraussetzung dafür ist der sprechende Name jeder Bedingung;
aus `A_ub[7]` wird kein Satz.

**Und die Grenze, die dazugehört** — als ⚠️-Kasten und als Übungsaufgabe: Ein solcher
Bericht erklärt das **Modell**, nicht die Wirklichkeit. Die Aufgabe lässt den
Deckungsbeitrag von *Deckel* von 9 € auf 20 € steigen. Gemessen: Der Plan kippt (Rahmen auf
das Vertragsminimum 40, Deckel auf die Marktgrenze 120), „Kapazität Lackieren" hört auf zu
binden, „Liefervertrag Rahmen" fängt damit an — **und der Satz „Teuerste Bindung ist
Liefervertrag Träger" steht wörtlich unverändert im Bericht**, während die Zahl dahinter von
18 € auf 58 € springt. Ein Bericht, der sich nicht ändert, ist kein Beweis dafür, dass sich
nichts geändert hat.

**Die neue Zählprobe aus 6.1a hat sich sofort bewährt:** Nach dem Einbau der Übungsaufgabe
meldete `--check` „6 Loesungen, das Kapitel aber 7 Aufgaben", bevor die Lösung geschrieben
war. Genau der Fall, für den sie gebaut wurde.

Stand danach: 294 Abschnitte, 725 Querverweise, 328 Indexmarken, **75** Programme,
139 Aufgaben mit 139 Lösungen, PDF **737** Seiten.

### ✅ 6.3 Parallelität und Determinismus ({ref:kap:cpsat})

Neuer Abschnitt {ref:sec:cpsat-parallele-suche} plus `Parallele_Suche.py` (76. Programm).
Setzt Paket 2 aus `Verbesserungen_02.md` um.

**Was fehlte, war nicht die Regel, sondern die Messung.** Das Buch setzt an acht Stellen
`num_workers = 1` mit dem Kommentar „für eine reproduzierbare Ausgabe", und der Spickzettel
nennt den Grund. Nachgeprüft hatte es nie jemand. Gerechnet wird auf demselben Job-Shop wie
{ref:sec:cpsat-intervallvariablen-job-shop-scheduling}, nur groß genug, dass die Suche
arbeitet: 12 Aufträge, 10 Maschinen, 120 Arbeitsgänge.

**Zwei Befunde, beide stärker als die Behauptung:**

1. **Die Beschleunigung ist überlinear.** Acht Arbeiter waren im abgedruckten Lauf nicht
achtmal, sondern **12,3-mal** schneller als einer. Kein Messfehler: CP-SAT vervielfacht
nicht dieselbe Suche, sondern lässt **verschiedene Strategien** nebeneinander laufen, die
einander ihre Schranken mitteilen. Der zweite Arbeiter ist nicht „der zweite Kern",
sondern ein anderes Verfahren.
2. **Der Seed genügt nicht — und zwar schon ab zwei Arbeitern.** Ein Arbeiter: 1 Plan aus
4 Läufen. **Zwei** Arbeiter: 3 verschiedene Pläne aus 4 Läufen, bei identischem
`random_seed` und identischem Zielwert 183. Es braucht also keine acht Arbeiter, um die
Reproduzierbarkeit zu verlieren.

**Die vollständige Antwort kam erst über die Übungsaufgabe**, und sie ist besser als der
Abschnitt allein: Mit `num_workers = 1`, aber **fünf verschiedenen Seeds**, ergeben sich
ebenfalls **fünf verschiedene Pläne**. Keiner der beiden Parameter sichert die
Reproduzierbarkeit allein:

| | Seed fest | Seed variabel |
| --- | --- | --- |
| **1 Arbeiter** | reproduzierbar | 5 Pläne aus 5 Läufen |
| **mehrere Arbeiter** | 3 Pläne aus 4 Läufen | erst recht nicht |

Weiter gemessen für die Aufgabe: Der Gewinn kehrt sich um — auf 24 Kernen Faktor **10,2**
(8 Arbeiter), **12,3** (16), **9,0** (24). „So viele Arbeiter wie Kerne" ist damit
widerlegt. Und bei 15 Aufträgen läuft ein Arbeiter ins 60-s-Limit (`FEASIBLE`, Makespan
200), während acht `OPTIMAL` mit **demselben** Makespan 200 nach 26,4 s melden — der
Unterschied liegt nicht in der Lösung, sondern im **Beweis**, dass es keine bessere gibt.

**Zur abgedruckten Ausgabe:** Sie trägt die Kennzeichnung „Laufzeiten *und* die Zahl der
verschiedenen Pläne sind hardwareabhängig" — nach dem Muster, das
{ref:kap:testing} für `Benchmark_Skalierung.py` schon verwendet. Der Vergleich des
extrahierten Programms mit dem Abdruck weicht denn auch in genau einer Zelle ab (4 statt 3
verschiedene Pläne bei 4 Arbeitern); Zielwert und Struktur sind identisch. Hier ist die
Nichtreproduzierbarkeit der abgedruckten Zahl **die Aussage selbst** — der einzige Fall im
Buch, in dem das so ist.

Im MILP-Kapitel bekam die entsprechende Stelle in `Warmstart_Effekt.py` einen Verweis;
dort steht nach Regel 12 der Kapitel**name**, keine Nummer.

Stand danach: 295 Abschnitte, 730 Querverweise, **76** Programme, 140 Aufgaben mit
140 Lösungen, PDF **744** Seiten.

### ✅ 7.1 Vier Zielgruppen-One-Pager (Vorwort)

Setzt Paket 4 aus `Verbesserungen_03.md` um. Das Titelblatt wirbt seit dem Umbau mit
Entscheidern, Ingenieuren und Investoren — die Lernpfade im Vorwort waren aber nach
**Themen** geschnitten, nicht nach **Rollen**. Der neue Abschnitt „Für wen dieses Buch
geschrieben ist" steht zwischen „Wie dieses Buch aufgebaut ist" und den Lernpfaden und
schließt genau diese Lücke: vier Einstiege, jeder mit Schmerzpunkt, drei Belegen, dem
passenden Pfad und der Frage, an der es in dieser Rolle scheitert.

**Die Entscheidung, die den Abschnitt trägt: nur gemessene Zahlen.** Jeder Beleg ist ein
Ergebnis, das im Buch gerechnet wird — kein Werbeversprechen:

* Entscheider: der Erwartungswert-Plan aus {ref:kap:supplychain} kostet **149 % mehr**
(874 870 € statt 351 356 €) und führt in 28 von 40 Szenarien zum Lastabwurf; der Preis
eines Prozentpunkts Versorgungssicherheit steigt um das 4,5-fache
({ref:sec:unsicherheit-chance-constraints}).
* Ingenieure: der Schattenpreis der Lackiererei gilt bis +15 Stunden, eine 30-Stunden-Schicht
bringt deshalb 60 € statt 120 € ({ref:sec:praxisfallen-attribution}); das Gesamtbild der
Metaheuristiken 2 497 → 2 289 Minuten bei einer Schranke von 1 768.
* Investoren: VaR 1,86 % gegen CVaR 2,99 %, schlechtester Tag −23,0 % — der am VaR nichts
ändert ({ref:kap:cvar}).
* Studierende: das Modell mit dem **schlechteren** MSE trifft die günstigere Entscheidung
({ref:kap:prognose}).

**Und eine Erwartung wird ausdrücklich enttäuscht.** `Verbesserungen_03` verlangt für die
Managementseite „typischer ROI und Amortisationszeit". Das Buch hat diese Zahlen nicht, und
jede hier genannte wäre erfunden. Der One-Pager sagt das offen und nennt stattdessen die
beiden Werkzeuge, mit denen der Leser **seine eigene** Zahl ausrechnet: den EVPI aus
{ref:kap:unsicherheit} als Obergrenze für jedes Prognoseprojekt und die Kostenzurechnung
aus {ref:sec:praxisfallen-attribution}.

Kein neues Programm, keine neue Aufgabe — der Abschnitt bündelt Vorhandenes. Querverweise
730 → 755, PDF 744 → **746** Seiten.

### ✅ 7.2 Wasserfalldiagramm „was es bringt" ({ref:kap:supplychain})

Setzt den umsetzbaren Teil von Paket 3 aus `Verbesserungen_03.md` um (Vorher-Nachher-
Wasserfall, Business Impact). Neuer Generator `bilder_04/erzeuge_wirkung.py`; das
Supply-Chain-Kapitel bekommt damit **sein erstes Diagramm** überhaupt.

**Der Anlass:** Die Tabelle im Kapitel nannte nur die Summen — 874 870 € gegen 351 356 €,
149 % mehr. Wofür genau, stand nirgends.

**Der Generator rechnet die Instanz erneut**, wie es die Konvention verlangt („so können
Diagramm und Buchtext nicht auseinanderlaufen"). Die Probe fiel gut aus: Der unabhängige
Nachbau reproduziert beide abgedruckten Summen **exakt**, dazu 178,7 MWh Fehlmenge und
28/40 Szenarien mit Abwurf. Kein Auseinanderlaufen — der erste Generator dieser Reihe, der
nichts findet, und das ist ein Ergebnis für sich.

**Was die Zerlegung zeigt und die Tabelle nicht:**

| | Anfahrt | Brennstoff | Lastabwurf | Gesamt |
| --- | ---: | ---: | ---: | ---: |
| zweistufig | 58 000 € | 293 356 € | 0 € | **351 356 €** |
| Erwartungswert | 58 000 € | 280 631 € | 536 239 € | **874 870 €** |

Die **Anfahrkosten sind identisch** — der Erwartungswert-Plan spart also nicht dort, wo man
es vermuten würde. Er spart 12 725 € Brennstoff und bezahlt dafür 536 239 € Lastabwurf: das
**42-fache**. „149 % mehr" ist eine Zahl, über die man streiten kann; „wir sparen 12 725 €
und riskieren 536 239 €" ist eine, über die man entscheidet.

Die Trennung von Brennstoff- und Abwurfkosten ist der einzige Zusatz gegenüber `bewerte()`
im Buchprogramm; dort wird sie nicht gebraucht.

**Ein eigener Fehler unterwegs:** Ein `.replace(",", ".")` für deutsche Tausenderpunkte lag
auf dem **ganzen Titelsatz** und machte aus „Brennstoff, Preis" ein „Brennstoff. Preis".
Jetzt gibt es `euro()`, das nur auf Zahlen angewandt wird — mit einem Kommentar, der genau
davor warnt.

SVG byteidentisch über zwei Läufe. Diagramme jetzt **33**, davon **19** mit Generator
(16 Skripte).

### ✅ 7.3 Glossar „Deutsch — OR" ({ref:kap:modellierung})

Setzt Paket 7 aus `Verbesserungen_03.md` um. Neuer Abschnitt
{ref:sec:modellierung-glossar}, unmittelbar hinter dem Gesprächsleitfaden: Die zwölf Fragen
liefern Sätze — hier werden sie übersetzt.

**Die Abgrenzung zu Anhang B war die eigentliche Entwurfsfrage.** Der Musterkatalog hat
längst eine Spalte „Umgangssprachlich", aber er läuft in die andere Richtung: **Muster →
Formulierung**. Wer aus einer Besprechung kommt, hat den Satz und sucht den Baustein. Das
Lexikon ist genau so herum gebaut (21 Einträge, jeweils mit B-Nummer), und Anhang B bekam
einen Rückverweis. Kein Duplikat, sondern die fehlende Gegenrichtung.

**Der Teil, der den Abschnitt trägt, ist aber nicht die Tabelle**, sondern was danach kommt:
**fünf Wendungen, bei denen die Übersetzung eine Entscheidung erzwingt** — „möglichst",
„nicht mehr als drei pro Woche", „im Durchschnitt", „so schnell wie möglich", „fair". Bei
jeder gibt es zwei bis drei vertretbare Modelle, und die Wahl gehört dem Betrieb, nicht dem
Modellierer. Das ist die These des Kapitels („Ein Satz ist noch kein Modell"), hier auf die
Alltagssprache angewandt.

Dazu die **Gegenrichtung OR → Deutsch**: acht Sätze, die sich bewährt haben, wenn ein
Ergebnis jemandem erklärt werden muss, der das Modell nicht kennt — einschließlich der
Formulierung für `INFEASIBLE` („Ihre Regeln widersprechen sich", **nicht** „der Computer
schafft es nicht").

Die neue Übungsaufgabe lässt drei Zielfunktionen für „gleichmäßig ausgelastet" aufstellen;
die Lösung nennt je einen Fall, in dem die Wahl den Plan sichtbar ändert — und weist darauf
hin, dass zwei der drei einen Halbtagsmonteur bestrafen.

Mitgezogen: Lernziel, Zusammenfassung, Rückverweis aus Anhang B, Pfad E im Vorwort
(er führte bisher direkt zum Musterkatalog, jetzt über das Lexikon).

**Damit ist Phase 7 abgeschlossen.** 296 Abschnitte, 766 Querverweise, 141 Aufgaben mit
141 Lösungen, PDF **749** Seiten.

### ✅ 8.1 Synthese-Seiten je Teil — und ein Fund in der Lesekette

Setzt Paket 5 aus `Verbesserungen_02.md` um (den Teil, der nicht zurückgestellt wurde). Fünf
neue Dateien `19_/29_/39_/49_/52_Synthese_*.md`, je eine am Ende eines Teils, mit eigener
Website-Seite (`SONDERSEITEN`, weil sie bewusst **keine** `# Kapitel:`-Überschrift tragen —
sie sind keine Kapitel, sondern der Rückblick auf einen Teil).

**Der Entwurf musste sich abgrenzen:** Die Teil-**Einleitungen** haben bereits
Entscheidungsdiagramme („welches Werkzeug passt zu meinem Problem"). Eine zweite
Entscheidungsmatrix am Teil-Ende wäre eine Dopplung gewesen. Die Synthesen leisten deshalb
das, was eine Einleitung nicht kann: den **Vergleich über die Kapitel hinweg** (Verfahren
nebeneinander, mit der Spalte „wo es aufhört"), eine Tabelle **„was dieser Teil gemessen
hat"** — Behauptung gegen Messung gegen Fundstelle — und drei Fehler, die der Teil
verhindert. Zitiert wird ausschließlich, was im Buch tatsächlich gerechnet wird.

### Drei Funde beim Einbau

**Erstens: Teil III sagte „die drei Kapitel dieses Teils", hat aber fünf.** Phase 3 hatte
{ref:kap:mehrziel} und {ref:kap:prognose} hinzugefügt, die Einleitung blieb stehen. Sie
nennt die drei Abweichungen jetzt weiterhin, schließt die beiden späteren Kapitel aber
ausdrücklich an.

**Zweitens: `50_Praxis.md` verwies auf die Projektwerkstatt mit „acht eigene Anwendungen"** —
sie hat elf.

**Drittens, und das ist der eigentliche Fund: Die Lesekette der Quelldateien führte an acht
Kapiteln vorbei.** Nach Phase 3 zeigte `12_Python_Oekosystem.md` direkt auf
`20_Lineare_Programmierung.md`, `23_Graphen…` direkt auf `30_QP…`, `32_Dynamische…` direkt
auf `40_Finanzdaten.md`, `50_Praxis.md` direkt auf die Projektwerkstatt. Wer der Kette
folgte, übersprang **acht von 23 Kapiteln** — darunter Metaheuristiken, Spaltengenerierung,
Mehrziel, Predict-then-Optimize, Strukturbrücke, Supply-Chain und das ganze
Testing-Kapitel. Zehn weitere Dateien hatten gar keine Navigationszeile.

**Zur Reichweite, damit sie nicht überschätzt wird:** Diese Zeilen stehen **nur in den
Quelldateien**. `entferne_navigation()` streicht sie aus dem Gesamtdokument, und die Website
baut ihre Vor/Zurück-Knöpfe selbst aus `DATEIEN`. PDF und Website waren also nie betroffen —
wohl aber jeder, der die Markdown-Dateien im Repository liest, und das wird nach der
Veröffentlichung der Normalfall sein.

Die Kette ist jetzt über **alle 35 Übergänge** geschlossen, und `--check` bewacht sie: Fehlt
eine Zeile oder zeigt sie an der in `DATEIEN` folgenden Datei vorbei, ist der Lauf rot.
Gegengetestet mit beiden Bruchformen.

Stand danach: **36 Dateien** (31 + 5 Synthesen), 296 Abschnitte, **815** Querverweise,
303 Hauptüberschriften, PDF **758** Seiten.

### ✅ 8.2 Solver-Isolation ohne `subprocess`-Codestrings

Setzt den Isolationsteil von Paket 1 aus `Verbesserungen_02.md` um. Der Plan nannte zwei
Programme; beim Suchen kam ein **drittes** dazu, das dasselbe Muster verwendete.

**Was ersetzt wurde.** `Ein_System_Vier_Ansaetze.py` und `Benchmark_Skalierung.py` hielten
ihre vier Solvervarianten als **Zeichenketten** in einem Dictionary und gaben sie an
`python -c` weiter — bei `Benchmark_Skalierung.py` sogar mit `.format()`-Platzhaltern für
die Instanzgröße. Aus jeder Variante ist jetzt eine gewöhnliche Funktion mit **lokalem
Import** geworden. `Solverwechsel_CPSAT_HiGHS.py` rief sich selbst über `sys.argv` erneut
auf; auch das entfällt.

Ausgeführt wird über einen `ProcessPoolExecutor` mit zwei Einstellungen, die zusammen die
Garantie ergeben — und beide sind nötig:

* `mp_context="spawn"` — frischer Interpreter statt geerbtem Speicher. Unter Linux ist
`fork` der Standard, und damit wäre alles bereits Importierte auch im Kind importiert.
* `max_tasks_per_child=1` — ein **neuer** Prozess je Aufgabe. Ohne das verwendet der Pool
seinen Arbeiter wieder, und beim zweiten Solver ist der Konflikt zurück. Nachgemessen:
vier Aufgaben, vier verschiedene PIDs.

Der zweite Punkt hat einen eigenen ⚠️-Kasten bekommen, weil der Fehler leicht zu machen und
schwer zu finden ist: Der Absturz käme nicht beim ersten Solver, sondern beim zweiten — und
sähe aus wie ein Problem des zweiten.

**Regel 4, dreifach geprüft.** Alle drei Programme drucken Ausgaben, die im Buch stehen:

* `Ein_System_Vier_Ansaetze.py`: identisch bis auf die Zeitspalte, **einschließlich der
Spannweite 2,41 · 10⁻⁸**, auf die sich der Merksatz des Kapitels beruft.
* `Benchmark_Skalierung.py`: **alle zwölf Zielwerte und alle drei Spannweiten
bitgleich**; Zeiten und Speicher haben sich verschoben, beide sind im Abdruck seit jeher
als hardwareabhängig gekennzeichnet.
* `Solverwechsel_CPSAT_HiGHS.py`: Ausgabe ohne Zeiten unverändert.

**Was bewusst `subprocess` bleibt:** `Mutationstest.py`. Dort wird pytest auf einer
**mutierten Kopie** in einem temporären Verzeichnis gestartet — ein externes Werkzeug auf
veränderten Dateien, nicht die Isolation eines Imports. Für diesen Fall ist `subprocess`
richtig.

**Neu im Kapitel Ökosystem:** ein Abschnitt „Wie die Isolation aussieht, wenn sie tragen
soll" — warum ein Codestring die schlechteste Umsetzung von „eigener Prozess" ist (unsichtbar
für Editor, Linter und Testwerkzeug; Tippfehler fallen erst zur Laufzeit auf; übergeben
lassen sich nur Zeichenketten). Anhang C nennt jetzt ebenfalls `ProcessPoolExecutor` statt
`subprocess`.

**Ein eigener Fehler, gefunden und abgesichert:** Ich hatte dem neuen `###` ein
`{#sec:...}`-Label gegeben. `ABSCHNITT_RE` erkennt nur `## ` — das Label wäre nie
registriert worden, und jeder Verweis darauf ins Leere gelaufen, ohne Warnung. Label
entfernt, und `--check` meldet diesen Fall jetzt. Gegengetestet.

Stand danach: 818 Querverweise, PDF **760** Seiten, 69 netzfreie Programme fehlerfrei.

### ✅ Achter Fund: die „Übung N.N"-Verweise

Sieben Sätze der Bauart „Übung 8.5 lässt Sie diese Balance untersuchen" — und **sechs davon
standen in alter Zählung**. „8" war in Version 03 das QP/NLP-Kapitel, heute ist es
Kapitel 11. Dieselbe Familie wie die Denkfehler-Verweise aus 6.1a, nur mit einem Wort, das
keine der bestehenden Prüfungen kannte.

Aufgaben haben kein eigenes Label, ein `{ref:}` auf eine einzelne Aufgabe ist also nicht
möglich. Verwiesen wird stattdessen auf **Abschnitt plus Aufgabentitel** — und der ist
stabil: „die Aufgabe *Gültigkeitsbereich des Schattenpreises*
({ref:sec:lp-uebungsaufgaben})". Jedes Ziel wurde einzeln über die alte Zählung bestimmt
und am Zusammenhang geprüft.

**Ein Fall war knifflig:** „Übung 6.7 (Wochendienstplan)" meinte die siebte CP-SAT-Aufgabe
der alten Zählung, also *Eigener Dienstplan* — die heute an achter Stelle steht, weil ich in
Phase 6.3 selbst eine Aufgabe davor eingefügt habe. Wer nur die Kapitelnummer angepasst
hätte, wäre bei der falschen Aufgabe gelandet.

`--check` kennt jetzt auch „Übung"/„Uebung". Gegengetestet. Querverweise 818 → 825.

### ✅ 8.3 Dockerfile — gebaut und durchgemessen

Setzt den letzten Teil von Paket 1 aus `Verbesserungen_02.md` um. Zweistufig: Die erste
Stufe übersetzt die Abhängigkeiten in eine virtuelle Umgebung und braucht dafür einen
Compiler, die zweite kopiert nur `/opt/venv` — die Bauumgebung landet nicht im Image.
Installiert werden die Gruppen `finance`, `large-scale`, `api` und `dev` aus
`pyproject.toml`; `figures` fehlt bewusst, weil es zusätzlich Graphviz verlangt.

**Es wurde nicht behauptet, sondern gebaut.** Ergebnis: **1,31 GB**, und darin

* der `Installationstest.py` mit allen drei Solver-Funktionstests bestanden,
* die 33 pytest-Tests bestanden,
* **alle 69 netzfreien Programme fehlerfrei** — einschließlich der drei aus 8.2, deren
`spawn`-Isolation im Container ebenso trägt wie außerhalb.

**Zwei Dinge, die der Bau gelehrt hat.** Erstens: `libgomp1` fehlt im
`python:3.12-slim`-Image und wird von OR-Tools und HiGHS zur Laufzeit gebraucht — ohne es
scheitert der erste Solveraufruf mit `libgomp.so.1: cannot open shared object file`.
Zweitens, ein eigener Fehler: Ich hatte `USER kurs` **vor** das `mkdir /buch/output` gesetzt;
`/buch` gehört root, und der Bau brach in der letzten Zeile ab. Beides steht jetzt als
Kommentar im Dockerfile.

Das Image führt die Programme aus und **baut das Buch nicht** — pandoc, xelatex und inkscape
wären zusammen über ein Gigabyte ohne Nutzen für jemanden, der die Beispiele durchrechnen
will. Ein `.dockerignore` hält Website, PDF und Notebooks aus dem Build-Kontext.

Und der Punkt, der erklärungsbedürftig ist: Das Image enthält `ortools` **und** `highspy`,
obwohl sie sich nicht gemeinsam importieren lassen. Der Konflikt wird nicht durch Weglassen
gelöst, sondern zur Laufzeit durch getrennte Prozesse — ein Image mit nur einem von beiden
könnte die Hälfte der Beispiele nicht ausführen.

**Damit ist Phase 8 abgeschlossen und der Plan abgearbeitet.**

### ✅ Aufgeräumt — und dabei zwei Funde

**Die 33 PNG-Zweitfassungen sind weg.** Jedes Diagramm lag doppelt vor, als SVG und als PNG,
und **kein einziges `src=`/`href=` in der Website zeigte je auf ein PNG**. Der Build kopierte
sie trotzdem mit: 3,3 MB im Repository plus 3,3 MB, die bei jeder Veröffentlichung auf den
Webserver gingen, ohne dass sie jemand abrief. Die 15 Generatoren schreiben jetzt nur noch
SVG; die Docstrings sind mitgezogen. Vor dem Löschen geprüft: Jedes PNG hatte sein
gleichnamiges SVG, und alle 33 waren versioniert — rückholbar.

**Fund 1 dabei: `erzeuge_kap06_gantt.py` folgte als einziger Generator nicht der Konvention.**
Weder `svg.hashsalt` noch `metadata={"Date": None}` waren gesetzt. Sein SVG trug deshalb
einen echten Zeitstempel und bei jedem Lauf andere `clip-path`-IDs — es war **nie**
byteidentisch reproduzierbar, obwohl `CLAUDE.md` genau das für alle Generatoren festhält.
Aufgefallen ist es nur, weil nach der PNG-Umstellung 32 von 33 SVGs bitgleich blieben und
eines nicht. Jetzt byteidentisch über zwei Läufe.

**Fund 2: `spiegle_bilder()` legte leere Verzeichnisse auf dem Webserver an.** Der
Dateifilter arbeitete korrekt, aber `os.walk` durchlief auch `__pycache__/`, und
`os.makedirs()` erzeugte es am Ziel — ein leerer Ordner in `OR_HTML_04/bilder_04/`. Die
Verzeichnisliste wird jetzt vorher gefiltert. Gegengetestet.

**`Excel_Bruecke.py` schreibt neben das Skript statt ins Arbeitsverzeichnis.** Es benutzte
blanke relative Namen; wer es aus der Repository-Wurzel startete, verstreute dort
`produktionsmix.xlsx` und `produktionsmix_ergebnis.xlsx`. Jetzt wie die vier anderen
schreibenden Programme über `os.path.dirname(os.path.abspath(__file__))`. Nachgemessen: Lauf
aus der Wurzel legt dort **null** Dateien ab.

**Und `git gc`:** 653 lose Objekte gepackt, `.git` von 71 MB auf **28 MB** — reines
Repacken, kein Inhalt berührt.

---

## 8. Commit-Historie des V04-Strangs

> **Zu den Kapitelnummern in dieser Tabelle:** Sie stammen aus den Commit-Betreffs und geben
> die Nummerierung **zum Zeitpunkt des Commits** wieder. Nach den acht in Phase 3
> eingefügten Kapiteln stimmen sie nicht mehr mit dem heutigen Buch überein — sie hier
> nachzuziehen würde die Tabelle von den tatsächlichen Commits entkoppeln. Überall sonst in
> dieser Datei stehen Kapitel**namen**.

| Commit | Datum | Inhalt |
| --- | --- | --- |
| `604c532` | 06.09. | Version 04 anlegen: Infrastruktur und Kapitel 1–3 |
| `72fa8a8` | 06.09. | Arbeitsplan als versionierte Datei |
| `a661a99` | 06.09. | Kapitel 4: Schattenpreise, und wann sie eine Entscheidung nicht tragen |
| `1d0170a` | 06.09. | Kapitel 5: MIP-Gap, Warm-Starts und die stille Big-M-Falle |
| `138be3f` | 07.09. | Kapitel 6: Die fünf Antworten von CP-SAT und die Strafgewichts-Falle |
| `360ffb2` | 07.09. | Kapitel 7 und die Entscheidungs-Flussdiagramme für Teil II und III |
| `b052653` | 07.09. | Kapitel 8: Jenseits der Konvexität — lokale Optima, Multistart, MINLP |
| `4ab2ad3` | 07.09. | Kapitel 9: Newsvendor als Einstieg, und der zweite Fluch des Durchschnitts |
| `fe7c0b9` | 07.09. | Kapitel 10: Rückwärtsinduktion und der Zustand, der zu wenig weiß |
| `f519e2d` | 07.09. | Kapitel 11 und der Auftakt zu Teil IV |
| `2583bbc` | 07.09. | Kapitel 12: Die Effizienzlinie als Speisekarte |
| `a7049e5` | 07.09. | Kapitel 13: Der VaR sagt wie oft, der CVaR wie schlimm |
| `5213258` | 07.09. | Kapitel 14: Die Reihenfolge zählt, und die Zahl der Versuche auch |
| `b154fe8` | 07.09. | Kapitel 15 — Phase 1 abgeschlossen |
| `33e9a36` | 07.09. | Phase 2 beginnt: `or_kern.py` als gemeinsamer Unterbau |
| `eeea9e8` | 07.09. | Excel-Schicht nach `or_kern.py`, `Excel_Bruecke.py` umgestellt |
| `ed3640d` | 07.09. | Phase 2 abgeschlossen: Statusauswertung, Abnahmeprüfung, Solverwechsel |
| `5c6cc2d` | 07.09. | Plan und Fortschritt als eigene Dateien im Repo-Wurzelverzeichnis |
| `1c856f1` | 07.09. | Kapitel 1 der Version 03: Umformatierung durch den Editor übernehmen |
| *(dieser)* | 07.09. | Planungsdateien konsolidiert, `CLAUDE.md` kennt jetzt Version 04 |