CLAUDE.md: Skripte überarbeitet, alte Referenzen entfernt

- Skript-Tabelle um detaillierte Beschreibungen ergänzt
- Abschnitt für Skripte im technik-check--vorlage-Branch hinzugefügt
- Alle Verweise auf alte Großbuchstaben-Skripte (BRANCHES.sh, REBASE.sh,
  PUSH.sh, RESET.sh, DIFF.sh, TAG.sh) auf neue Namen aktualisiert
- Einleitung "Manueller Rebase-Workflow" ohne REBASE.sh-Referenz neu formuliert
- config/flawed-setup--zookeeper vollständig entfernt

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

diff --git a/CLAUDE.md b/CLAUDE.md
index 75afaaaeca895ece8eee233e125c4076e024eb74..86d41edc835acaf8db1eb3e04be1461017b3e9e3 100644 (file)
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -199,19 +199,30 @@ Alle Skripte laden zuerst `branches.sh`, das die vollständige Branch-Liste defi
 
 | Skript | Zweck |
 |--------|-------|
-| `branches.sh` | Definiert alle Branch-Namen und die Iterationsliste `$BRANCHES` |
-| `push.sh` | Force-pusht alle Branches zu origin (erstellt vorher zeitgestempelte Backup-Tags) |
-| `reset.sh` | Setzt alle Branches auf `origin/<branch>` oder auf ein Tag-Präfix zurück (`./reset.sh <prefix>`) |
-| `diff.sh` | Diff jedes Branches: gegen Remote (kein Arg), gegen Tag-Suffix (1 Arg) oder zwischen zwei Tags (2 Args) |
-| `build.sh` | Baut alle Branches (Maven + Gradle); mit `--publish` auch Docker-Images veröffentlichen |
-| `copy.sh` | Kopiert Branches in `../vorlagen`-, `../livecoding`-, `../spickzettel`-Verzeichnisse; mit `--nexus-url=<url>` Gradle-Setups für Nexus patchen |
-| `patch-nexus.sh` | Patcht `build.gradle`, `settings.gradle` und optional `gradle-wrapper.properties` für internen Nexus-Mirror |
+| `branches.sh` | Definiert alle Branch-Namen als Variablen und die Iterationsliste `$BRANCHES` |
+| `push.sh` | Force-pusht alle Branches zu origin; erstellt vorher zeitgestempelte Backup-Tags der Remote-Stände |
+| `reset.sh` | Ohne Argument: setzt alle Branches auf `origin/<branch>` zurück. Mit Argument: auf Tag `<branch>--<prefix>` |
+| `diff.sh` | Ohne Arg: lokaler Branch gegen `origin/<branch>`. Ein Arg: gegen `<branch>--<suffix>`. Zwei Args: `<branch>--<suffix1>` gegen `<branch>--<suffix2>` |
+| `build.sh` | Baut alle Branches (erkennt Maven/Gradle automatisch); `--vorlage`-Branches werden übersprungen. Mit `--publish`: Docker-Images veröffentlichen |
+| `copy.sh` | Kopiert Branches in `../vorlagen`-, `../livecoding`-, `../spickzettel`-Verzeichnisse. Optionaler Tag-Suffix als erstes Argument kopiert den jeweiligen Tag-Stand. Mit `--nexus-url=<url>` werden Gradle-Setups anschließend für einen internen Nexus gepatcht |
+| `patch-nexus.sh` | Patcht `build.gradle` (Nexus als Repository), `settings.gradle` (pluginManagement) und optional mit `--gradle-dist-url=<url>` auch `gradle-wrapper.properties`. Wird aus dem Zielverzeichnis (`../vorlagen/`) aufgerufen |
 
 Nach Massenoperationen immer zu `scripting` zurückkehren — Skripte führen am Ende `git checkout scripting` aus.
 
+### Skripte im `springkafka/technik-check--vorlage`-Branch
+
+Dieser Branch enthält zwei zusätzliche Skripte für das Gradle-Setup:
+
+| Skript | Zweck |
+|--------|-------|
+| `bootstrap-gradle.sh` | Erzeugt den fehlenden `gradle-wrapper.jar` (per lokaler Gradle-Installation oder Download von GitHub). Mit `--distribute`: kopiert JAR und `gradlew` in alle Geschwister-Übungsverzeichnisse |
+| `README-gradle.sh` | Wie `README.sh`, aber für den Gradle-Build: ruft zuerst `bootstrap-gradle.sh` auf, baut dann mit `./gradlew bootBuildImage` |
+
+`gradle-wrapper.jar` ist absichtlich nicht im Repository (wird von Unternehmens-Mail-Filtern blockiert). `gradlew` und `gradle/wrapper/gradle-wrapper.properties` sind versioniert.
+
 ### TGZ-Verzeichnisstruktur
 
-Branch-Namen bilden auch die Verzeichnisstruktur im verteilten TGZ ab: Der Branch `springkafka/technik-check--vorlage` wird als `springkafka/technik-check/` extrahiert. Von dort ist `../..` das Trainings-Wurzelverzeichnis. Das nutzt `bootstrap-gradle.sh` mit `--distribute`, um Gradle-Wrapper-Dateien in alle Geschwister-Übungsverzeichnisse zu kopieren.
+Branch-Namen bilden auch die Verzeichnisstruktur im verteilten TGZ ab: Der Branch `springkafka/technik-check--vorlage` wird als `springkafka/technik-check/` extrahiert. Von dort ist `../..` das Trainings-Wurzelverzeichnis — so funktioniert `bootstrap-gradle.sh --distribute` korrekt.
 
 **Sonderfall `copy.sh`**: `springkafka/technik-check--vorlage` wird nach `vorlagen/grundlagen/technik-check/` kopiert (nicht `vorlagen/springkafka/`), da der Technik-Check thematisch zu den Grundlagen-Vorlagen gehört.
 
@@ -219,7 +230,7 @@ Branch-Namen bilden auch die Verzeichnisstruktur im verteilten TGZ ab: Der Branc
 
 Diese beiden Stellen müssen immer gemeinsam aktualisiert werden — sie halten unterschiedliche Informationen:
 
-**In `BRANCHES.sh`** (Branch-Name und Iterationsliste):
+**In `branches.sh`** (Branch-Name und Iterationsliste):
 1. Variablenname und -wert (Branch-Name) als neue Zeile eintragen.
 2. Variablenname in die `$BRANCHES`-Iterationsliste aufnehmen.
 
@@ -252,7 +263,7 @@ Wird eine Klasse oder Datei in einen neuen Branch verschoben (oder ein neuer Spi
 
 ## Manueller Rebase-Workflow
 
-Das `REBASE.sh`-Skript automatisiert das Rebasen prinzipiell, aber in der Praxis entstehen häufig Konflikte, weil Branches sich absichtlich unterscheiden — sie demonstrieren verschiedene Aspekte von Kafka. Claude Code übernimmt die Rolle des Menschen, der bisher manuell eingreifen musste.
+Rebases werden immer manuell durchgeführt, weil Branches sich absichtlich unterscheiden — sie demonstrieren verschiedene Aspekte von Kafka. Konflikte erfordern fachliches Urteil darüber, was absichtliche und was unbeabsichtigte Divergenz ist.
 
 ### Ansatz zur Konfliktlösung
 
@@ -267,7 +278,7 @@ In diesen Fällen: Problem zeigen, erklären warum es wichtig ist, und einen kon
 
 ### Allgemeine Prinzipien
 
-- Branch für Branch in der Reihenfolge arbeiten, wie in `BRANCHES.sh` definiert
+- Branch für Branch in der Reihenfolge arbeiten, wie in `branches.sh` definiert
 - Zwischen **absichtlichen** Unterschieden (verschiedene Lernziele) und **unbeabsichtigten** Unterschieden (Zeitdruck, vergessene Backports) unterscheiden
 - Verbesserungen von späteren auf frühere Branches zurückportieren, wo sinnvoll
 - Nach dem Rebasen immer zum `scripting`-Branch zurückkehren
@@ -278,7 +289,7 @@ Live-Codings verbinden die technischen Lücken zwischen den Übungsgruppen. Jede
 
 ### Struktur eines Live-Codings
 
-**Schritt 0** (`--livecoding`-Branch): Die Anwendung aus dem Ausgangsbranch wird auf die Benennung der Anwendung im Zielbranch umbenannt (mit dem Zusatz `--livecoding`) und das Setup entsprechend vorbereitet. Der Ausgangsbranch ist der ROOT des `--livecoding`-Branches in `BRANCHES.sh`.
+**Schritt 0** (`--livecoding`-Branch): Die Anwendung aus dem Ausgangsbranch wird auf die Benennung der Anwendung im Zielbranch umbenannt (mit dem Zusatz `--livecoding`) und das Setup entsprechend vorbereitet. Der Ausgangsbranch ist der ROOT des `--livecoding`-Branches (nachzuschlagen in der ROOT-Tabelle dieser `CLAUDE.md`).
 
 **Schritte 1–N** (`--livecoding--schritte`-Branch): Die Anwendung und das Setup werden Schritt für Schritt so umgebaut, dass sie dem Zustand im Zielbranch annähernd entsprechen. Der Zielbranch enthält ggf. noch weitere "off-topic"-Features als "Best Practices", sodass 100% Übereinstimmung weder erwartet noch nötig ist.
 
@@ -328,7 +339,7 @@ Image-Name muss immer `juplo/<artifactId>:<version>` (Maven) oder `juplo/${proje
 
 ### ROOT eines Branches ermitteln
 
-Der ROOT jedes Branches steht in der **ROOT-Tabelle in dieser `CLAUDE.md`** (Abschnitt „Branch-Hierarchie"). **Vor jedem Rebase dort nachschlagen** — nicht in `BRANCHES.sh` greifen, da die Tabelle hier bereits vollständig und geprüft ist.
+Der ROOT jedes Branches steht in der **ROOT-Tabelle in dieser `CLAUDE.md`** (Abschnitt „Branch-Hierarchie"). **Vor jedem Rebase dort nachschlagen** — nicht in `branches.sh` greifen, da die Tabelle hier bereits vollständig und geprüft ist.
 
 Als Gegencheck lässt sich der ROOT auch aus dem Branch-HEAD ableiten:
 ```bash
@@ -411,7 +422,7 @@ Um die wirklich neuen Inhalte einer Session zu identifizieren, nicht die Anzahl
 
 ### Session-Tagging-Schema
 
-Jede Rebase-Session taggt jeden abgeschlossenen Branch als `<branch>--claude-N`. Die Tag-Nummer erhöht sich pro Session. Tags dienen als Wiederherstellungspunkte — `./RESET.sh claude-N` setzt alle Branches auf die entsprechenden Tags zurück. Immer direkt nach Abschluss eines Branches taggen, bevor mit dem nächsten begonnen wird.
+Jede Rebase-Session taggt jeden abgeschlossenen Branch als `<branch>--claude-N`. Die Tag-Nummer erhöht sich pro Session. Tags dienen als Wiederherstellungspunkte — `./reset.sh claude-N` setzt alle Branches auf die entsprechenden Tags zurück. Immer direkt nach Abschluss eines Branches taggen, bevor mit dem nächsten begonnen wird.
 
 **Am Ende jeder Session: alle Branches taggen** — auch solche, die sich in dieser Session nicht geändert haben. Branches ohne neue Änderungen erhalten ein `--claude-N`-Tag auf demselben Commit wie ihr `--claude-(N-1)`-Tag:
 ```bash
@@ -426,6 +437,6 @@ done
 
 ## Wesentliche Einschränkungen
 
-- `PUSH.sh` force-pusht — das ist für diesen Schulungsworkflow absichtlich und erwartet.
+- `push.sh` force-pusht — das ist für diesen Schulungsworkflow absichtlich und erwartet.
 - `--vorlage`-Branches werden von Build-Skripten übersprungen (sie sind absichtlich unvollständig).
-- Der `grundlagen/docker`-Branch ist nicht in `$BRANCHES`, wird aber in mehreren Skripten explizit behandelt (PUSH, DIFF, RESET, TAG).
+- Der `grundlagen/docker`-Branch ist nicht in `$BRANCHES`, wird aber in mehreren Skripten explizit behandelt (`push.sh`, `diff.sh`, `reset.sh`).