Phase 8.1: Synthese-Seiten je Teil - und die gebrochene Lesekette

Setzt Paket 5 aus Verbesserungen_02.md um (den Teil, der nicht
zurueckgestellt wurde). Fuenf neue Dateien 19_/29_/39_/49_/52_Synthese_*.md,
je eine am Ende eines Teils, mit eigener Website-Seite ueber SONDERSEITEN -
sie tragen bewusst keine "# Kapitel:"-Ueberschrift, weil sie keine Kapitel
sind, sondern der Rueckblick auf einen Teil.

Der Entwurf musste sich abgrenzen: Die Teil-Einleitungen haben bereits
Entscheidungsdiagramme. Eine zweite Matrix am Teil-Ende waere eine Dopplung
gewesen. Die Synthesen leisten deshalb, was eine Einleitung nicht kann - den
Vergleich ueber die Kapitel hinweg (Verfahren nebeneinander, mit der Spalte
"wo es aufhoert"), eine Tabelle "was dieser Teil gemessen hat" (Behauptung
gegen Messung gegen Fundstelle) und drei Fehler, die der Teil verhindert.
Zitiert wird ausschliesslich, was im Buch tatsaechlich gerechnet wird.

Drei Funde beim Einbau:

* Teil III sagte "die drei Kapitel dieses Teils", hat aber fuenf. Phase 3
  hatte Mehrziel und Predict-then-Optimize hinzugefuegt, die Einleitung
  blieb stehen.
* 50_Praxis.md verwies auf die Projektwerkstatt mit "acht eigene
  Anwendungen" - sie hat elf.
* Und der eigentliche Fund: Die Lesekette der Quelldateien fuehrte an ACHT
  Kapiteln vorbei. 12_Python_Oekosystem zeigte direkt auf
  20_Lineare_Programmierung, 23_Graphen direkt auf 30_QP, 32_Dynamische
  direkt auf 40_Finanzdaten, 50_Praxis direkt auf die Projektwerkstatt. Wer
  der Kette folgte, uebersprang acht von 23 Kapiteln - darunter
  Metaheuristiken, Spaltengenerierung, Strukturbruecke, Supply-Chain und das
  ganze Testing-Kapitel. Zehn weitere Dateien hatten gar keine
  Navigationszeile.

Zur Reichweite, damit sie nicht ueberschaetzt wird: Diese Zeilen stehen nur
in den Quelldateien. entferne_navigation() streicht sie aus dem
Gesamtdokument, und die Website baut ihre Vor/Zurueck-Knoepfe selbst aus
DATEIEN. PDF und Website waren nie betroffen - wohl aber jeder, der die
Markdown-Dateien im Repository liest, und das wird nach der
Veroeffentlichung der Normalfall sein.

Die Kette ist jetzt ueber alle 35 Uebergaenge 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: 36 Dateien, 296 Abschnitte, 815 Querverweise, 328 Indexmarken, 76
Programme (unveraendert), 33 pytest-Tests, PDF 758 Seiten.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Operations_Research_mit_Python_Version_04/12_Python_Oekosystem.md

@@ -1264,4 +1264,4 @@ Schattenpreise kommen — und was sie wirtschaftlich bedeuten.
 
 ---
 
-*Weiter mit:* [{ref:kap:lp} — Lineare Programmierung](20_Lineare_Programmierung.md)
+*Weiter mit:* [{ref:kap:modellierung} — Vom Management-Wunsch zum Modell](13_Vom_Wunsch_zum_Modell.md)

Operations_Research_mit_Python_Version_04/13_Vom_Wunsch_zum_Modell.md

@@ -809,3 +809,7 @@ Kennzahlen. Zwei Seiten genügen — sie sind mehr wert als zwei Wochen Programm
 * Die vier Fragen — worüber wird entschieden, woran gemessen, was ist unverhandelbar, was
   bei Unlösbarkeit — gehören in die erste Besprechung. Der Leitfaden in
   {ref:sec:modellierung-leitfaden} macht zwölf daraus.
+
+---
+
+*Weiter mit:* [Synthese Teil I](19_Synthese_Grundlagen.md)

Operations_Research_mit_Python_Version_04/19_Synthese_Grundlagen.md

@@ -0,0 +1,44 @@
+# Synthese Teil I — Grundlagen auf einen Blick
+
+Vier Kapitel, eine Frage: **Was muss vorliegen, bevor ein Solver überhaupt sinnvoll
+gestartet werden kann?** Die Antwort ist unbequem, weil das meiste davon nichts mit
+Programmieren zu tun hat.
+
+## Was welches Kapitel klärt
+
+| Frage | Kapitel | Was Sie danach können |
+| --- | --- | --- |
+| Was ist überhaupt ein Optimierungsmodell? | {ref:kap:einfuehrung} | Die vier Bausteine benennen — Variablen, Zielfunktion, Nebenbedingungen, Daten — und sie in einem fremden Problem wiedererkennen |
+| Warum rechnet der Solver falsch, obwohl das Modell stimmt? | {ref:kap:fundament} | Konvexität beurteilen, den zulässigen Bereich als Polyeder sehen, schlechte Konditionierung erkennen und beheben |
+| Welche Bibliothek, und warum vertragen sie sich nicht? | {ref:kap:oekosystem} | Solver, Bindings und Modellierungsschichten unterscheiden — und den HiGHS-Symbolkonflikt zwischen `ortools` und `highspy` umgehen |
+| Wie wird aus einem Satz ein Modell? | {ref:kap:modellierung} | Die vier Fragen stellen, harte von weichen Regeln trennen, einen Besprechungssatz übersetzen ({ref:sec:modellierung-glossar}) |
+
+## Die Reihenfolge ist die Aussage
+
+Dieser Teil steht bewusst **vor** den Verfahren. Die drei häufigsten Gründe, aus denen ein
+OR-Projekt scheitert, liegen alle hier — und keiner davon ist ein Solverproblem:
+
+1. **Die falsche Zielgröße.** Sie ist die folgenreichste Entscheidung des ganzen Projekts,
+   und sie wird meist in den ersten zehn Minuten nebenbei getroffen. Auslastung ist ein
+   Ergebnis, kein Ziel; „Umsatz" wird gesagt, wenn „Deckungsbeitrag" gemeint ist.
+2. **Zu viele harte Regeln.** Jede unnötig harte Bedingung ist eine Zeitbombe: Irgendwann
+   ist sie nicht erfüllbar, und das System antwortet gar nicht mehr. Hart ist nur, was
+   rechtlich oder physikalisch unmöglich ist.
+3. **Ein Satz, der mehrere Lesarten hat.** „Stammkunden dürfen wir nicht verlieren" lässt
+   sich auf mindestens drei Arten modellieren, und keine ist aus dem Satz ableitbar. Die
+   Wahl trifft man — im Zweifel unbewusst.
+
+## Wenn Sie nur eines mitnehmen
+
+> **🎯** Ein Modell rechnet aus, was **aufgeschrieben** wurde, nicht was gemeint war. Die
+> Arbeit, die darüber entscheidet, ob am Ende etwas Brauchbares herauskommt, findet vor der
+> ersten Zeile Code statt — und sie besteht aus Fragen an andere Menschen, nicht aus
+> Mathematik.
+
+**Vor {ref:teil:kernverfahren}** sollten Sie an einem eigenen Beispiel die vier Fragen aus
+{ref:sec:modellierung-vier-fragen} durchgespielt haben. Ohne das bleiben die Verfahren
+Technik ohne Anwendung.
+
+---
+
+*Weiter mit:* [{ref:kap:lp} — Lineare Programmierung](20_Lineare_Programmierung.md)

Operations_Research_mit_Python_Version_04/22_CP_SAT.md

@@ -1854,4 +1854,4 @@ Zeitfenstern.
 
 ---
 
-*Weiter mit:* [{ref:kap:graphen} — Graphen, Flüsse, Touren](23_Graphen_Fluesse_Touren.md)
+*Weiter mit:* [{ref:kap:graphen} — Graphen, Flüsse und Touren](23_Graphen_Fluesse_Touren.md)

Operations_Research_mit_Python_Version_04/23_Graphen_Fluesse_Touren.md

@@ -1084,4 +1084,4 @@ und die KKT-Bedingungen ein — das mathematische Fundament der Portfoliooptimie
 
 ---
 
-*Weiter mit:* [{ref:kap:qp-nlp} — Quadratische und nichtlineare Optimierung](30_QP_und_NLP.md)
+*Weiter mit:* [{ref:kap:metaheuristiken} — Metaheuristiken](24_Metaheuristiken.md)

Operations_Research_mit_Python_Version_04/24_Metaheuristiken.md

@@ -1526,3 +1526,7 @@ liegt es an der Strategie oder an der Zahl der Runden, die sie schafft?
   könnte.
 * **LNS** kombiniert beide: zerstören, exakt reparieren, übernehmen. Die Fenstergröße hat
   ein Optimum in der Mitte und gehört gemessen.
+
+---
+
+*Weiter mit:* [{ref:kap:dekomposition} — Spaltengenerierung](25_Spaltengenerierung.md)

Operations_Research_mit_Python_Version_04/25_Spaltengenerierung.md

@@ -750,3 +750,7 @@ Spalten verzweigen kann.
   Verfahren 11 %, bei sechs nichts. Diese Kennzahl lässt sich vor dem Projekt ausrechnen.
 * Auch wo es nichts spart, liefert es die **Schranke** — und damit die Erlaubnis,
   aufzuhören.
+
+---
+
+*Weiter mit:* [Synthese Teil II](29_Synthese_Kernverfahren.md)

Operations_Research_mit_Python_Version_04/29_Synthese_Kernverfahren.md

@@ -0,0 +1,50 @@
+# Synthese Teil II — Die Kernverfahren nebeneinander
+
+Sechs Kapitel, sechs Werkzeuge. Jedes einzelne wurde im Zusammenhang gezeigt; hier stehen
+sie zum ersten Mal **nebeneinander**, mit der Frage, die vor jedem Projekt zu beantworten
+ist: Welches nehme ich, und was bekomme ich dafür?
+
+## Die Entscheidungsmatrix
+
+| Verfahren | Wofür es gebaut ist | Was Sie bekommen | Wo es aufhört | Kapitel |
+| --- | --- | --- | --- | --- |
+| **LP** | teilbare Mengen, lineare Zusammenhänge | beweisbares Optimum **plus Schattenpreise** | sobald etwas ganzzahlig sein muss | {ref:kap:lp} |
+| **MILP** | Ja/Nein-Entscheidungen, Fixkosten, Logik | beweisbares Optimum, Gap als Fortschrittsmaß | Laufzeit wächst mit der Zahl der Binärvariablen | {ref:kap:milp} |
+| **CP-SAT** | Zuweisung, Reihenfolge, Kalender, harte Logik | beweisbares Optimum, sehr ausdrucksstarke Bedingungen | keine Schattenpreise, keine stetigen Größen | {ref:kap:cpsat} |
+| **Graphenalgorithmen** | Flüsse, Zuordnung, Touren | oft **polynomiell** statt exponentiell | nur, wenn die Struktur wirklich passt | {ref:kap:graphen} |
+| **Metaheuristiken** | wenn der exakte Solver aussteigt | eine gute Lösung in **fester Zeit** | keine Garantie, kein Beweis, keine Schranke | {ref:kap:metaheuristiken} |
+| **Spaltengenerierung** | Modelle mit astronomisch vielen Variablen | beweisbares Optimum über nie erzeugte Spalten | lohnt nur bei bestimmter Instanzstruktur | {ref:kap:dekomposition} |
+
+**Die Spalte, die am meisten wert ist, ist die vierte.** Ein Verfahren zu kennen heißt zu
+wissen, wo es aufhört — nicht, wofür es gedacht ist.
+
+## Was dieser Teil gemessen hat
+
+| Behauptung | Gemessen | Wo |
+| --- | --- | --- |
+| „Der exakte Solver ist immer besser." | Bei 500 Aufträgen liefert CP-SAT eine Lösung, die **5,2 % schlechter** ist als die Faustregel eines Meisters | {ref:kap:metaheuristiken} |
+| „Metaheuristiken sind ungenau." | Faustregel 2 497 → Annealing 2 343 → Annealing plus LNS **2 289** Minuten Rüstzeit; untere Schranke 1 768 | {ref:kap:metaheuristiken} |
+| „Man muss alle Variablen aufschreiben." | 28 erzeugte Muster von **46 408** möglichen — und die Lösung ist beweisbar optimal | {ref:kap:dekomposition} |
+| „Dekomposition lohnt sich immer." | Bei drei Stücken je Rolle **11 %** Ersparnis, bei sechs **nichts** | {ref:kap:dekomposition} |
+| „Mit Seed ist der Lauf reproduzierbar." | Schon **zwei** Arbeiter liefern bei identischem Seed drei verschiedene Pläne zum selben Zielwert | {ref:sec:cpsat-parallele-suche} |
+
+## Drei Fehler, die dieser Teil verhindert
+
+1. **Runden.** Die LP-Lösung ist keine Näherung der ganzzahligen Lösung — sie kann beliebig
+   weit danebenliegen, und gerundet sogar unzulässig werden.
+2. **Ein zu großes Big-M.** Es macht das Modell nicht falsch, sondern die Suche langsam und
+   die Schranken wertlos. So klein wie zulässig, nie „sicherheitshalber groß".
+3. **Zu früh heuristisch werden.** Der Umschlagpunkt, ab dem eine Metaheuristik den exakten
+   Solver schlägt, ist eine Eigenschaft **des Problems** und lässt sich messen. Wer ihn
+   nicht misst, verzichtet auf Optimalitätsgarantien, die er hätte haben können.
+
+## Wenn Sie nur eines mitnehmen
+
+> **🎯** Die Frage lautet nie „welcher Solver ist der beste", sondern „welche Garantie
+> brauche ich, und was bin ich bereit, dafür an Laufzeit zu zahlen". Ein Verfahren ohne
+> Schranke liefert eine Lösung; ein Verfahren mit Schranke liefert die Erlaubnis,
+> aufzuhören.
+
+---
+
+*Weiter mit:* [{ref:kap:qp-nlp} — Quadratische und nichtlineare Optimierung](30_QP_und_NLP.md)

Operations_Research_mit_Python_Version_04/30_QP_und_NLP.md

@@ -5,7 +5,7 @@ in der Praxis oft nicht: Risiko wächst **quadratisch** mit dem Einsatz, Nachfra
 morgen bekannt, und eine Entscheidung heute verändert, welche Möglichkeiten übermorgen noch
 offenstehen.
 
-Die drei Kapitel dieses Teils behandeln genau diese drei Abweichungen. Welches Werkzeug Sie
+Drei Kapitel dieses Teils behandeln genau diese drei Abweichungen. Welches Werkzeug Sie
 brauchen, hängt davon ab, **welche** davon bei Ihnen vorliegt:
 
 ![Entscheidungsdiagramm: Welches Werkzeug passt zu meinem Problem? (Teil III)](bilder_04/teil3_solverwahl.svg)
@@ -21,6 +21,11 @@ brauchen, hängt davon ab, **welche** davon bei Ihnen vorliegt:
 > und dann deterministisch zu rechnen. Warum das systematisch danebengeht, zeigt
 > {ref:kap:unsicherheit} unter dem Namen *Fluch des Durchschnitts*.
 
+Zwei weitere Kapitel schließen sich an, weil sie dieselbe Voraussetzung aufgeben, nur an
+einer anderen Stelle: {ref:kap:mehrziel} gibt das **eine Ziel** auf, {ref:kap:prognose} die
+Annahme, die **Eingabedaten** seien gegeben statt selbst geschätzt. Was dieser Teil
+insgesamt leistet, fasst die Synthese an seinem Ende zusammen.
+
 ---
 
 # Kapitel: Quadratische und nichtlineare Optimierung — KKT, Lagrange, Konvexität {#kap:qp-nlp}

Operations_Research_mit_Python_Version_04/32_Dynamische_Programmierung.md

@@ -862,4 +862,4 @@ Marktdaten — und lernen zuerst, warum diese Daten trügerisch sind.
 
 ---
 
-*Weiter mit:* [{ref:kap:finanzdaten} — Finanzdaten und Kovarianz-Shrinkage](40_Finanzdaten.md)
+*Weiter mit:* [{ref:kap:mehrziel} — Mehrere Ziele](33_Mehrziel_und_Pareto.md)

Operations_Research_mit_Python_Version_04/33_Mehrziel_und_Pareto.md

@@ -757,3 +757,7 @@ einer Fläche. Wie ändert sich das ε-Verfahren, und warum wächst der Aufwand
   dafür so sauber wie möglich" ist eine Frage, die ein Kaufmann beantworten kann.
 * Die Front wird erst entscheidbar durch die Spalte **€ je kg**: Sie ist mit dem internen
   CO₂-Preis vergleichbar und verwandelt eine Wertefrage in eine Rechnung.
+
+---
+
+*Weiter mit:* [{ref:kap:prognose} — Predict-then-Optimize](34_Predict_then_Optimize.md)

Operations_Research_mit_Python_Version_04/34_Predict_then_Optimize.md

@@ -700,3 +700,7 @@ und zwar **in unterschiedlichem Ausmaß**? Was sagt das über den Wert eines Mer
 * Ein Kennzahlenvergleich braucht eine **Streuungsangabe**. Bei 180 Testtagen sah das
   schlechtere Modell in gut jedem zehnten Fall besser aus — und wer einmal misst, hat genau
   eine Ziehung.
+
+---
+
+*Weiter mit:* [Synthese Teil III](39_Synthese_Nichtlinear.md)

Operations_Research_mit_Python_Version_04/35_Strukturbruecke.md

@@ -735,3 +735,7 @@ trägt — und schreiben Sie auf, welche der drei Zeilen im Weg steht.
   gegen reagierende Marktteilnehmer) und ob Teilbarkeit erlaubt ist (MILP gegen LP).
 * Die erste dieser Grenzen ist die gefährlichste: Dieselbe Optimierung ist in der Werkstatt
   Planung und im Depot Fehlerverstärkung.
+
+---
+
+*Weiter mit:* [{ref:kap:supplychain} — Supply-Chain und Energieeinsatz unter Unsicherheit](36_Supply_Chain_Energie.md)

Operations_Research_mit_Python_Version_04/36_Supply_Chain_Energie.md

@@ -785,3 +785,7 @@ und welches Verfahren aus {ref:kap:metaheuristiken} würden Sie einsetzen?
   der erwarteten Kosten die Absicherung von selbst.
 * Wo sie greift, liefert sie den **Preis der Vorgabe**: 46 € je vermiedener MWh — eine Zahl,
   über die man verhandeln kann.
+
+---
+
+*Weiter mit:* [{ref:kap:finanzdaten} — Finanzdaten-Modellierung](40_Finanzdaten.md)

Operations_Research_mit_Python_Version_04/39_Synthese_Nichtlinear.md

@@ -0,0 +1,52 @@
+# Synthese Teil III — Wenn die Idealwelt nicht gilt
+
+{ref:teil:kernverfahren} setzte voraus: feste Daten, lineare Zusammenhänge, ein Ziel, eine
+Periode. Dieser Teil nimmt jede dieser vier Voraussetzungen einzeln weg. Die Tabelle ordnet
+die Kapitel danach, **welche** Voraussetzung bei Ihnen verletzt ist.
+
+## Welche Annahme fällt weg?
+
+| Was nicht gilt | Woran Sie es merken | Werkzeug | Kapitel |
+| --- | --- | --- | --- |
+| **Linearität** | Risiko wächst quadratisch, Kosten degressiv, Sättigung | QP, konvexe Optimierung, KKT | {ref:kap:qp-nlp} |
+| **Feste Daten** | Nachfrage, Wind, Rendite stehen erst morgen fest | Monte-Carlo, Zweistufigkeit, Robustheit, Chance Constraints | {ref:kap:unsicherheit} |
+| **Eine Periode** | die Entscheidung heute verändert, was übermorgen möglich ist | Bellman-Gleichung, Rückwärtsinduktion | {ref:kap:dynamische-programmierung} |
+| **Ein Ziel** | zwei Kennzahlen sollen gleichzeitig stimmen | Pareto-Front, ε-Constraint | {ref:kap:mehrziel} |
+| **Daten sind gegeben** | die Eingabe ist selbst eine Prognose | Predict-then-Optimize, entscheidungsorientiertes Lernen | {ref:kap:prognose} |
+
+Die letzte Zeile ist die unbequemste: Dort ist nicht das Modell unsicher, sondern seine
+**Eingabe** — und die kommt aus einem zweiten Modell, das nach anderen Kriterien gebaut
+wurde.
+
+## Was dieser Teil gemessen hat
+
+| Behauptung | Gemessen | Wo |
+| --- | --- | --- |
+| „Mit dem Mittelwert zu rechnen ist eine brauchbare Näherung." | Der Mittelwertplan hält seine Zusage in **50,08 %** der Fälle — per Definition | {ref:sec:unsicherheit-chance-constraints} |
+| „Versorgungssicherheit kostet linear." | 56 289 € je Prozentpunkt auf dem Weg zu 80 %, **253 848 €** zwischen 95 und 99 % — das 4,5-fache | {ref:sec:unsicherheit-chance-constraints} |
+| „Eine Zusage aus dem Modell hält." | Der 95-%-Plan hält **87,44 %**, sobald die Testverteilung einen Fall enthält, in dem alles zugleich ausfällt | {ref:sec:unsicherheit-chance-constraints} |
+| „Die bessere Prognose führt zur besseren Entscheidung." | Das Modell mit dem **schlechteren** MSE trifft die günstigere Entscheidung | {ref:kap:prognose} |
+
+## Drei Fehler, die dieser Teil verhindert
+
+1. **Unsicherheit durch Mittelwerte ersetzen.** Der Durchschnittskunde kauft nie. Bei
+   asymmetrischen Kosten liegt das Optimum systematisch neben dem Mittelwert, und eine
+   Terminzusage ist ein **Quantil**, kein Erwartungswert.
+2. **Konvexität voraussetzen, ohne sie zu prüfen.** Ohne sie gibt es keine
+   Optimalitätsgarantie, sondern nur ein lokales Ergebnis — und der Solver sagt das nicht
+   von selbst.
+3. **Zwei Ziele mit einem Gewicht verrechnen, bevor die Front bekannt ist.** Ein Gewicht
+   ist eine Antwort auf eine Frage, die noch niemand gestellt hat. Die Pareto-Front stellt
+   sie zuerst.
+
+## Wenn Sie nur eines mitnehmen
+
+> **🎯** Jede der vier Annahmen lässt sich einzeln aufgeben — aber jede kostet etwas
+> Bestimmtes: Linearität kostet die Optimalitätsgarantie, feste Daten kosten Rechenzeit
+> oder Vorsicht, eine Periode kostet Zustandsraum, ein Ziel kostet eine Entscheidung, die
+> nicht der Modellierer treffen darf. Wer weiß, **welche** Annahme bei ihm fällt, weiß
+> auch, welchen Preis er zahlt.
+
+---
+
+*Weiter mit:* [{ref:kap:bruecke} — Die Strukturbrücke](35_Strukturbruecke.md)

Operations_Research_mit_Python_Version_04/40_Finanzdaten.md

@@ -951,4 +951,4 @@ Markowitz-Effizienzgrenze mit realistischen institutionellen Restriktionen.
 
 ---
 
-*Weiter mit:* [{ref:kap:markowitz} — Markowitz-Portfoliotheorie](41_Markowitz.md)
+*Weiter mit:* [{ref:kap:markowitz} — Die moderne Portfoliotheorie nach Markowitz](41_Markowitz.md)

Operations_Research_mit_Python_Version_04/42_CVaR.md

@@ -846,4 +846,4 @@ Rebalancing und ein Walk-Forward-Backtest ohne Lookahead-Bias.
 
 ---
 
-*Weiter mit:* [{ref:kap:handelsmaschine} — Die vollständige Handelsmaschine](43_Handelsmaschine.md)
+*Weiter mit:* [{ref:kap:handelsmaschine} — Die vollständige quantitative Handelsmaschine](43_Handelsmaschine.md)

Operations_Research_mit_Python_Version_04/43_Handelsmaschine.md

@@ -1047,4 +1047,4 @@ der Weg vom Skript zum produktiven System.
 
 ---
 
-*Weiter mit:* [{ref:kap:praxisfallen} — Praxisfallen und produktiver Einsatz](50_Praxis.md)
+*Weiter mit:* [Synthese Teil IV](49_Synthese_Anwendungen.md)

Operations_Research_mit_Python_Version_04/49_Synthese_Anwendungen.md

@@ -0,0 +1,50 @@
+# Synthese Teil IV — Zwei Domänen, dieselbe Mathematik
+
+Sechs Kapitel, zwei Branchen, die sich für unvergleichbar halten. Die Werkstatt plant
+Maschinen, das Depot plant Titel — und beide lösen dasselbe Problem: **knappe Mittel auf
+konkurrierende Verwendungen verteilen, unter Unsicherheit.**
+
+## Dieselbe Struktur, andere Namen
+
+| Werkstatt und Kraftwerk | Depot und Handel | Was mathematisch dahintersteht |
+| --- | --- | --- |
+| Produkt, Maschinenstunde | Titel, Kapital | Entscheidungsvariable |
+| Deckungsbeitrag | erwartete Rendite | linearer Zielterm |
+| Kapazität, Liefervertrag | Positionsgrenze, Sektorlimit | Nebenbedingung |
+| Rüstkosten, Anfahrkosten | Transaktionskosten | Fixkosten mit Binärvariable (B1) |
+| Lastabwurf, Konventionalstrafe | Tail-Verlust | Straf- bzw. Risikoterm |
+| Wind- und Nachfrageszenarien | Renditeszenarien | Szenariomenge |
+
+**Und wo die Analogie endet**, benennt {ref:kap:bruecke} an drei Stellen ausdrücklich — das
+ist der wertvollere Teil. Eine Analogie, die man nicht begrenzen kann, ist keine Erkenntnis,
+sondern eine Redewendung.
+
+## Was dieser Teil gemessen hat
+
+| Behauptung | Gemessen | Wo |
+| --- | --- | --- |
+| „Planen mit der Prognose ist gut genug." | Der Erwartungswert-Plan kostet **149 % mehr** (874 870 € statt 351 356 €) und wirft in **28 von 40** Szenarien Last ab | {ref:kap:supplychain} |
+| „Dann sparen wir eben beim Brennstoff." | Genau das tut er: 12 725 € gespart, **536 239 €** Lastabwurf bezahlt — das 42-fache. Die Anfahrkosten sind in beiden Plänen gleich | {ref:kap:supplychain} |
+| „Der VaR sagt, wie riskant es ist." | VaR **1,86 %**, CVaR **2,99 %** — und der schlechteste Tag der Stichprobe (**−23,0 %**) ändert am VaR **nichts** | {ref:kap:cvar} |
+| „Die Kovarianzmatrix ist eine Eingabe wie jede andere." | Aus kurzen Reihen geschätzt ist sie schlecht konditioniert; die Optimierung setzt dann auf Schätzrauschen | {ref:kap:finanzdaten} |
+
+## Drei Fehler, die dieser Teil verhindert
+
+1. **Bei Markowitz einsteigen.** Wer {ref:kap:finanzdaten} überspringt, optimiert seine
+   eigenen Schätzfehler und wundert sich über Gewichte, die niemand halten würde.
+2. **Den VaR für ein Risikomaß halten.** Er sagt, **ob** die Schwelle gerissen wird, nicht
+   **wie schlimm** es dahinter aussieht — und er ist nicht kohärent. Optimiert wird der
+   CVaR.
+3. **Trägheit unterschätzen.** Im Kraftwerkspark ist nicht die Prognosegüte das Problem,
+   sondern dass sich ein Block mit acht Stunden Mindestlaufzeit um 18 Uhr nicht mehr
+   herbeirufen lässt. Dieselbe Trägheit heißt im Depot Transaktionskosten.
+
+## Wenn Sie nur eines mitnehmen
+
+> **🎯** Wer die Struktur erkennt, kann sein Werkzeug mitnehmen, wenn er die Branche
+> wechselt. Wer nur die Bibliothek kennt, fängt jedes Mal von vorn an — und wer die Grenzen
+> der Analogie nicht kennt, überträgt irgendwann auch das, was nicht überträgt.
+
+---
+
+*Weiter mit:* [{ref:kap:praxisfallen} — Praxisfallen und der Weg zum produktiven Einsatz](50_Praxis.md)

Operations_Research_mit_Python_Version_04/50_Praxis.md

@@ -2515,4 +2515,4 @@ sichtbar wird, und gibt Zeit zum Handeln.
 
 ---
 
-*Weiter mit:* [Projektwerkstatt — acht eigene Anwendungen](59_Projektwerkstatt.md)
+*Weiter mit:* [{ref:kap:testing} — Testen, Messen, Ausliefern](51_Testing_und_Deployment.md)

Operations_Research_mit_Python_Version_04/51_Testing_und_Deployment.md

@@ -1636,3 +1636,7 @@ Test, der eine Instanz einreicht, die das Limit überschreitet.
 * Ein **Optimierungsdienst** ist zweistufig: annehmen und prüfen sofort, rechnen im
   Hintergrund, Ergebnis mit Status und Gap abholen. Die Frage Threads oder Prozesse gehört
   gemessen — bei C++-Solvern genügen Threads, bei Python-Heuristiken nicht.
+
+---
+
+*Weiter mit:* [Synthese Teil V](52_Synthese_Praxis.md)

Operations_Research_mit_Python_Version_04/52_Synthese_Praxis.md

@@ -0,0 +1,48 @@
+# Synthese Teil V — Vom rechnenden Modell zum benutzten System
+
+Zwei Kapitel, ein Übergang: Das Modell rechnet — und muss jetzt jemand anderem übergeben
+werden. Was dabei schiefgeht, hat selten mit Mathematik zu tun.
+
+## Was schiefgeht, und was dagegen hilft
+
+| Was in Produktion passiert | Gegenmittel | Wo |
+| --- | --- | --- |
+| `INFEASIBLE` um 3 Uhr nachts, niemand weiß warum | Relaxation mit gestaffelten Strafkosten (B18); Deletion Filter für die Diagnose | {ref:kap:praxisfallen}, {ref:anhang:fehlerdiagnose} |
+| Der Disponent lehnt den Plan ab, weil er ihn nicht versteht | Constraint-Trace für die einzelne Zuweisung; Kostenzurechnung für den ganzen Plan | {ref:kap:praxisfallen}, {ref:sec:praxisfallen-attribution} |
+| Der Solver läuft ins Zeitlimit und keiner merkt es | Status, Gap und Zeitausschöpfung protokollieren — konstante Laufzeit ist ein Warnsignal | {ref:kap:praxisfallen} |
+| Ein Test wird grundlos mal rot, mal grün | auf Zielwert und Regeln prüfen, nicht auf die Gestalt der Lösung; `num_workers = 1` **und** Seed | {ref:sec:cpsat-parallele-suche}, {ref:kap:testing} |
+| Ein Ergebnis lässt sich später nicht mehr nachvollziehen | Snapshot-Prinzip: unveränderlicher Datenstand mit ID je Lauf | {ref:kap:praxisfallen} |
+| Das Modell prüft sich selbst | Abnahmeprüfung als eigener Baustein, ohne Solver und ohne Modellvariable | {ref:sec:praxisfallen-or-kern} |
+
+## Was dieser Teil gemessen hat
+
+| Behauptung | Gemessen | Wo |
+| --- | --- | --- |
+| „Der Solver nennt schon den Grund für `INFEASIBLE`." | Er nennt gar nichts. Der Deletion Filter findet einen kleinsten Konflikt — dieses Modell enthält **neun** verschiedene, und welchen man sieht, steuert die Prüfreihenfolge | {ref:anhang:fehlerdiagnose} |
+| „Bindende Bedingungen sind die teuren." | Von fünf bindenden Bedingungen kostet eine **0,00 €** | {ref:sec:praxisfallen-attribution} |
+| „Der Schattenpreis sagt, was der Hebel bringt." | Hochgerechnet 120 €, gemessen **60 €** — er gilt nur bis +15 Stunden. Die Ranglisten nach Preis und nach Wirkung drehen sich um | {ref:sec:praxisfallen-attribution} |
+| „Mehr Arbeiter sind proportional schneller." | **12,3-fach** bei acht Arbeitern — überlinear, weil verschiedene Strategien statt derselben Suche laufen | {ref:sec:cpsat-parallele-suche} |
+
+## Drei Fehler, die dieser Teil verhindert
+
+1. **Alles hart formulieren.** Wer keine Regel brechen lässt, bekommt irgendwann eine
+   Fehlermeldung statt eines Plans — und zwar nachts, im Batchlauf.
+2. **Genauer optimieren als die Daten sind.** Ein Gap von 2 % ist bei ±10 %
+   Datenunsicherheit bedeutungslos. Die Rechenzeit dafür ist verschenkt.
+3. **Einen Bericht für einen Beweis halten.** Ein generierter Text erklärt das **Modell**,
+   nicht die **Wirklichkeit**. Ist eine Eingabe falsch geschätzt, ist er überzeugend **und**
+   falsch — die gefährlichste Kombination.
+
+## Wenn Sie nur eines mitnehmen
+
+> **🎯** Ein Modell, das nur auf Ihrem Rechner und nur mit Ihren Daten läuft, ist ein
+> Prototyp — kein System. Der Unterschied besteht aus drei Dingen, die alle nichts mit dem
+> Solver zu tun haben: einer Abnahmeprüfung, einer Erklärung und einem Protokoll.
+
+**Danach:** die Projektwerkstatt. Elf Aufträge, jeder mit Datenquellen, Modellskizze,
+Abnahmekriterien und Stolperfallen — zugeschnitten auf 10 bis 25 Stunden bis zu einem
+vorzeigbaren Ergebnis.
+
+---
+
+*Weiter mit:* [Projektwerkstatt](59_Projektwerkstatt.md)

Operations_Research_mit_Python_Version_04/59_Projektwerkstatt.md

@@ -367,4 +367,4 @@ Viel Erfolg.
 
 ---
 
-*Weiter mit:* [{ref:anhang:loesungen} — Lösungen](90_Anhang_Loesungen.md)
+*Weiter mit:* [{ref:anhang:loesungen} — Lösungen zu allen Übungsaufgaben](90_Anhang_Loesungen.md)

Operations_Research_mit_Python_Version_04/90_Anhang_Loesungen.md

@@ -3201,3 +3201,7 @@ der Solver, sondern die Bindung davor.
    Eine in reinem Python geschriebene Heuristik hält den GIL; für sie braucht es Prozesse.
 
 ---
+
+---
+
+*Weiter mit:* [{ref:anhang:modellierungsmuster} — Katalog der Modellierungsmuster](91_Anhang_Modellierungsmuster.md)

Operations_Research_mit_Python_Version_04/91_Anhang_Modellierungsmuster.md

@@ -438,4 +438,4 @@ Wenn mehrere Muster passen, entscheiden Sie nach dieser Reihenfolge:
 
 ---
 
-*Weiter mit:* [{ref:anhang:fehlerdiagnose} — Fehlerdiagnose](92_Anhang_Fehlerdiagnose.md)
+*Weiter mit:* [{ref:anhang:fehlerdiagnose} — Fehlerdiagnose-Handbuch](92_Anhang_Fehlerdiagnose.md)

Operations_Research_mit_Python_Version_04/build_version_04.py

@@ -95,25 +95,30 @@ DATEIEN = [
     "11_Mathematisches_Fundament.md",
     "12_Python_Oekosystem.md",
     "13_Vom_Wunsch_zum_Modell.md",
+    "19_Synthese_Grundlagen.md",
     "20_Lineare_Programmierung.md",
     "21_MILP.md",
     "22_CP_SAT.md",
     "23_Graphen_Fluesse_Touren.md",
     "24_Metaheuristiken.md",
     "25_Spaltengenerierung.md",
+    "29_Synthese_Kernverfahren.md",
     "30_QP_und_NLP.md",
     "31_Unsicherheit.md",
     "32_Dynamische_Programmierung.md",
     "33_Mehrziel_und_Pareto.md",
     "34_Predict_then_Optimize.md",
+    "39_Synthese_Nichtlinear.md",
     "35_Strukturbruecke.md",
     "36_Supply_Chain_Energie.md",
     "40_Finanzdaten.md",
     "41_Markowitz.md",
     "42_CVaR.md",
     "43_Handelsmaschine.md",
+    "49_Synthese_Anwendungen.md",
     "50_Praxis.md",
     "51_Testing_und_Deployment.md",
+    "52_Synthese_Praxis.md",
     "59_Projektwerkstatt.md",
     "90_Anhang_Loesungen.md",
     "91_Anhang_Modellierungsmuster.md",
@@ -308,6 +313,35 @@ def pruefe_dateien() -> list[str]:
                       f"{marken} Loesungen, das Kapitel aber {erwartet} Aufgaben.")
                 fehlend.append(anhang)
 
+    # Die Lesekette. Jede Datei ausser der letzten schliesst mit
+    # '*Weiter mit:* [...](naechste_datei.md)' - und zwar auf die Datei, die in
+    # DATEIEN als naechste steht.
+    #
+    # Das ist keine Formalie: Nach den acht in Phase 3 eingefuegten Kapiteln
+    # zeigte die Kette an ihnen VORBEI. Wer ihr folgte, uebersprang
+    # stillschweigend acht von 23 Kapiteln - darunter Metaheuristiken,
+    # Spaltengenerierung und das ganze Testing-Kapitel. Gefunden wurde das
+    # erst, als die Synthese-Seiten dazwischenkamen.
+    #
+    # Vorwort und Notation sind ausgenommen: Sie verweisen in eigener Form.
+    OHNE_KETTE = {"00_Vorwort_und_Lesehilfe.md", "01_Notation_und_Abkuerzungen.md"}
+    weiter_re = re.compile(r"^\*Weiter mit:\*.*?\]\((\S+?\.md)\)", re.MULTILINE)
+    for i, name in enumerate(DATEIEN[:-1]):
+        if name in OHNE_KETTE:
+            continue
+        with open(os.path.join(HIER, name), encoding="utf-8") as f:
+            inhalt = f.read()
+        treffer = weiter_re.search(inhalt)
+        soll = DATEIEN[i + 1]
+        if treffer is None:
+            print(f"FEHLER: {name} hat keine '*Weiter mit:*'-Zeile - die Lesekette "
+                  f"bricht dort ab (naechste Datei waere {soll}).")
+            fehlend.append(name)
+        elif treffer.group(1) != soll:
+            print(f"FEHLER: {name} verweist auf '{treffer.group(1)}', in DATEIEN "
+                  f"folgt aber '{soll}' - die Lesekette ueberspringt eine Datei.")
+            fehlend.append(name)
+
     return fehlend
 
 
@@ -983,6 +1017,14 @@ def baue_pdf() -> None:
 SONDERSEITEN = {
     "00_Vorwort_und_Lesehilfe.md": ("vorwort.html", "Vorwort & Lesehilfe"),
     "01_Notation_und_Abkuerzungen.md": ("notation.html", "Notation & Abkürzungen"),
+    # Die fuenf Teil-Synthesen. Sie tragen bewusst keine
+    # '# Kapitel:'-Ueberschrift - sie sind keine Kapitel, sondern der Rueckblick
+    # auf einen ganzen Teil - und brauchen deshalb hier ihren Seitennamen.
+    "19_Synthese_Grundlagen.md": ("synthese-grundlagen.html", "Synthese Teil I"),
+    "29_Synthese_Kernverfahren.md": ("synthese-kernverfahren.html", "Synthese Teil II"),
+    "39_Synthese_Nichtlinear.md": ("synthese-nichtlinear.html", "Synthese Teil III"),
+    "49_Synthese_Anwendungen.md": ("synthese-anwendungen.html", "Synthese Teil IV"),
+    "52_Synthese_Praxis.md": ("synthese-praxis.html", "Synthese Teil V"),
     "59_Projektwerkstatt.md": ("projektwerkstatt.html", "Projektwerkstatt"),
 }