CLAUDE.md: Historische Branches, producer→consumer-Kettendesign und Effizienz-Prinzip...

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

diff --git a/CLAUDE.md b/CLAUDE.md
index d1303e1d417a771bb66484dc8d01b68f5e2ed09d..54f90acbecc4e096dde0aa13373056c72ac9acd5 100644 (file)
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -27,6 +27,7 @@ Die Rebase-Elternbeziehungen (ROOTs) sind **ausschließlich** in der ROOT-Tabell
 
 > **Diese `CLAUDE.md` ist die einzige maßgebliche Quelle für die Branch-Struktur.**
 > Vor dem Start einer Aufgabe keine Git-Erkundungsbefehle ausführen (`git branch -a`, `git tag`, `git log --all` o.ä.) — alle benötigten Informationen zur Branch-Hierarchie und den ROOTs sind hier vollständig dokumentiert.
+> Nur die in der ROOT-Tabelle aufgeführten Branches werden aktiv gepflegt. Das Repository enthält weitere historische Branches, die nicht mehr gewartet werden und ignoriert werden sollen.
 
 ### Branch-Hierarchie (vollständige ROOT-Tabelle)
 
@@ -150,6 +151,7 @@ Zweck dieser Live-Codings:
   - Sauberes Herunterfahren
   - Paketierung als Docker-Image
 - Der benötigte Zusatz-Code und das Setup sollen so einfach wie möglich, aber vollständig funktionsfähig sein
+- `grundlagen/simple-consumer` baut absichtlich auf `grundlagen/simple-producer` auf: Beide Übungen verwenden dasselbe Setup und ähnlichen Boilerplate-Code (Konfigurierbarkeit, sauberes Herunterfahren). Der Diff zwischen den beiden Branches zeigt genau, was sich beim Übergang von der Producer- zur Consumer-API ändert — und macht damit den Unterschied für Teilnehmer besonders klar.
 
 ### `producer/*` und `consumer/*`
 
@@ -244,10 +246,11 @@ Diese beiden Stellen müssen immer gemeinsam aktualisiert werden — sie halten
 
 Beim Einführen von Änderungen in einem Branch wird bewusst darauf geachtet, den Diff gegen den Eltern-Branch so klein wie möglich zu halten. Ziel ist, dass ein Diff zwischen einem späteren Branch und einem seiner Vorfahren **nur zeigt, was der spätere Branch tatsächlich hinzufügt** — kein Rauschen durch unzusammenhängendes Reformatieren oder Umstrukturieren.
 
-Dies ist aus zwei Gründen wesentlich:
+Dies ist aus drei Gründen wesentlich:
 
 1. **Überblick**: Der Autor kann immer klar sehen, was ein Branch relativ zu seinem Ursprung ändert.
 2. **Lehre**: Der Diff wird direkt in Übungen verwendet — z.B. um Teilnehmern genau zu zeigen, welches Boilerplate verschwindet, wenn Spring Boot oder Spring Kafka Features schrittweise aktiviert werden.
+3. **Effizienz**: Verbesserungen müssen nur im frühesten betroffenen Branch eingeführt werden und fließen per Rebase automatisch in alle Downstream-Branches. Dieses Prinzip gilt auch gruppenübergreifend: da `grundlagen/simple-consumer` auf `grundlagen/simple-producer` aufbaut, genügt es, eine Verbesserung einmal im Producer-Branch einzuführen — sie propagiert per Rebase über den Consumer-Branch in alle weiteren Downstream-Branches.
 
 **Implikation für Rebases**: Wird eine Verbesserung in einem frühen Branch eingeführt (z.B. Entfernen des `Dockerfile` und überflüssiger Maven-Plugins), müssen alle Downstream-Branches diese Verbesserung konsistent übernehmen. Ein `-- ALIGN`-Commit darf **keine** entfernten Elemente wieder einführen. Er soll nur die branch-spezifischen Änderungen enthalten (z.B. `mainClass` von `ExampleProducer` auf `ExampleConsumer` aktualisieren in der Jib-Konfiguration).