`CLAUDE.md` überflüssige Hinweise auf bereits umgesetzte Verbesserungen von Claude...

diff --git a/CLAUDE.md b/CLAUDE.md
index 791170104aabf9ac83d551d356f1f9de6b294e86..8d0474c1e3f8a6fac4d6d45a3646ed721115bcdf 100644 (file)
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -215,13 +215,13 @@ Bei diesen beiden Live-Codings ist der Zielbranch **derselbe** wie der Ausgangsb
 Diese Branches repräsentieren schrittweise Übergänge für Live-Coding-Sessions. Ihre Struktur ist pädagogisch wichtig:
 
 - **Leere Commits nicht überspringen** — jeder Commit ist ein Lehrschritt. Auch wenn der Inhalt eines Schritts nach einem Rebase leer geworden ist, muss der Schritt erhalten bleiben. Innehalten und mit dem Benutzer besprechen, anstatt stillschweigend zu überspringen.
-- **Wird der Inhalt eines Schritts durch eine vorgelagerte Verbesserung entfernt**, ist er durch die funktional äquivalente Änderung im neuen Setup zu ersetzen. Beispiel: Der "Docker-Image"-Schritt zeigte ursprünglich ein `Dockerfile` — nach der Jib-Migration zeigt er stattdessen die `mainClass`-Aktualisierung in `pom.xml`/`build.gradle`, weil Jib einen expliziten Einstiegspunkt benötigt, während `bootBuildImage` ihn automatisch erkennt.
+- **Wird der Inhalt eines Schritts durch eine vorgelagerte Verbesserung entfernt**, ist er durch die funktional äquivalente Änderung im neuen Setup zu ersetzen — also durch diejenige Änderung, die bei dem hier schrittweise vollzogenen Umbau an dieser Stelle tatsächlich nötig ist.
 - Den Commit-Namen entsprechend umbenennen, sodass er beschreibt, was der Schritt nun demonstriert.
 - Das Endergebnis aller Schritte soll dem Zielbranch annähernd (aber nicht zwingend zu 100%) entsprechen.
 
 ## Rebase-Technische-Referenz
 
-Dieser Abschnitt dokumentiert wiederkehrende Muster und Entscheidungen, die durch die Claude-unterstützten Rebase-Sessions erarbeitet wurden.
+Dieser Abschnitt dokumentiert die technischen Standards und wiederkehrenden Muster für die manuelle Rebase-Arbeit.
 
 ### Docker-Image-Build-Tools nach Branch-Gruppe
 
@@ -230,9 +230,7 @@ Dieser Abschnitt dokumentiert wiederkehrende Muster und Entscheidungen, die durc
 | `grundlagen/*` | **Jib** (`jib-maven-plugin` 3.4.5) | `<container><mainClass>` explizit | `jib { container { mainClass = '...' } }` |
 | `producer/*`, `consumer/*`, `springkafka/*` | **bootBuildImage** (Cloud Native Buildpacks) | `spring-boot-maven-plugin` + `build-info`-Goal, `<image><name>juplo/...` | `bootBuildImage { imageName = "juplo/${project.name}:${project.version}" }` |
 
-Das `Dockerfile` ist auf **allen** Branches gelöscht — Jib und bootBuildImage machen es überflüssig.
-
-Die Dateien `.dockerignore` und `.maven-dockerinclude` sind ebenfalls **obsolet** und sollen aus allen Branches entfernt werden: `.dockerignore` gehörte zum Docker-Daemon-Build-Kontext, `.maven-dockerinclude` zum alten fabric8/bmuschko-Plugin. Beide wurden beim Entfernen des `Dockerfile` übersehen.
+Branches enthalten kein `Dockerfile`, keine `.dockerignore` und keine `.maven-dockerinclude` — Jib und bootBuildImage übernehmen das Image-Building vollständig und benötigen diese Dateien nicht.
 
 Image-Name muss immer `juplo/<artifactId>:<version>` (Maven) oder `juplo/${project.name}:${project.version}` (Gradle) entsprechen.
 
@@ -280,13 +278,6 @@ for fname in ['pom.xml', 'build.gradle']:
 "
 ```
 
-**bootBuildImage-Migrations-Commit** (z.B. Commit `4213dbdf`):
-- `pom.xml`: Jib-Plugin vollständig entfernen; `spring-boot-maven-plugin` mit `<image><name>juplo/...</name></image>` und `build-info`-Execution behalten
-- `build.gradle`: `jib { ... }`-Block durch `bootBuildImage { imageName = "juplo/${project.name}:${project.version}" }` ersetzen
-
-**`Dockerfile`-Delete/Modify-Konflikt:**
-Immer `git rm Dockerfile` — es ist in allen Branch-Gruppen obsolet.
-
 **Testdateien in HEAD gelöscht, durch eingehenden Commit modifiziert:**
 Aus dem eingehenden Commit wiederherstellen: `git checkout <eingehender-commit-hash> -- <pfad/zur/datei>`
 
@@ -301,13 +292,7 @@ Wandelt ein Branch die Anwendung in eine **reine Java-Bibliothek** um (keine Spr
 
 ### Session-Tagging-Schema
 
-Jede Rebase-Session taggt jeden abgeschlossenen Branch als `<branch>--claude-N`. Die Tag-Nummer erhöht sich pro Session:
-- `--claude-0`: erster automatisierter Durchlauf
-- `--claude-1`: erste manuelle Korrektursession
-- `--claude-2`: letzte abgeschlossene Session
-- `--claude-3`: nächste Session (aktuell geplant: `.dockerignore`/`.maven-dockerinclude` entfernen, Schritt-Nummerierung in `consumer/spring-consumer--livecoding--schritte` korrigieren)
-
-Tags dienen als Wiederherstellungspunkte. `./RESET.sh claude-2` setzt alle Branches auf die `--claude-2`-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.
 
 ## Wesentliche Einschränkungen