CLAUDE.md: Remote-Angabe korrigieren, Wiki-Push-Regel ergaenzen, Versionszeilen im Wiki entfernen #47

New Issue

2026-09-26T23:37:44+02:00

jlab-bot commented

2026-09-26 23:37:44 +02:00

Zwei Stellen in CLAUDE.md beschreiben etwas anderes als das, was vorliegt. Beide haben bereits Zeit gekostet.

1. Die Remote-Angabe ist falsch

CLAUDE.md sagt:

Remotes are named github and JLab-Git — there is no origin.

Tatsächlich hat der Checkout genau einen Remote, und der heißt origin:

origin  ssh://git@git.jk-dev.de:30022/jlab-cluster/helm-charts.git

Dasselbe gilt für frisch erzeugte Worktrees. Zwei Umsetzungs-Agenten sind unabhängig voneinander darüber gestolpert und haben es im Abschlussbericht gemeldet; ein Push, der sich nach dieser Zeile richtet, scheitert schlicht.

Zu tun: Die Zeile beschreibt, was da ist — ein Remote origin auf die Gitea-Instanz. Der Punkt dahinter bleibt gültig und gehört erhalten: github.com ist ein Spiegel, main auf Gitea ist die führende Kopie. Wenn auf der Maschine des Betreuers zusätzlich ein zweiter Remote existiert, gehört das als Zusatz formuliert, nicht als Regel für alle.

2. Paralleles Arbeiten am Wiki ist ungeregelt

Das Wiki ist ein eigenes Repository ohne PR-Verfahren. Bei der Umsetzung von #16 und #18 haben zwei Agenten fast gleichzeitig dieselben zwei Seiten bearbeitet (Chart-Style-Guide.md, Lessons-Learned.md). Der Rebase lief konfliktfrei durch — das war Glück, und Glück ist kein Verfahren. Ein Push mit Force hätte an dieser Stelle fremde Arbeit gelöscht, ohne dass irgendetwas gemeldet hätte.

Zu tun: Im Wiki-Abschnitt von CLAUDE.md einen Satz ergänzen: vor jedem Push fetchen und rebasen, niemals mit Force pushen.

3. Versionszeilen im Wiki entfernen (gehört fachlich dazu)

Die Chart-Seiten im Wiki nennen je eine Chart- und eine App-Version. Bei urlaubsverwaltung war die App-Version bereits eine Renovate-Runde veraltet, ohne dass es jemandem aufgefallen wäre.

Das ist die unmittelbare Folge einer bewussten Regel in CLAUDE.md: Ein reiner App-Versions-Bump verpflichtet zu keiner Wiki-Änderung — sonst bräuchte jeder automatisch gemergte Renovate-PR einen Wiki-Commit, und die Regel wäre binnen einer Woche tot. Die Regel bleibt; was weg kann, ist die Zahl, die dadurch veraltet.

Zu tun: Auf allen Chart-Seiten die Versionszeilen aus der Übersichtstabelle entfernen und stattdessen auf Chart.yaml verweisen — so, wie es der Chart-Index von Anfang an hält, mit genau dieser Begründung. Reine Wiki-Änderung: kein Chart-Bump, kein PR, keine Veröffentlichung.

Umfang

CLAUDE.md (Punkte 1 und 2) in einem PR; Punkt 3 direkt im Wiki, da dort kein PR-Verfahren existiert. Charts werden nicht angefasst, also keine Versionsänderung und kein Install-Test.

Zwei Stellen in `CLAUDE.md` beschreiben etwas anderes als das, was vorliegt. Beide haben bereits Zeit gekostet. ## 1. Die Remote-Angabe ist falsch `CLAUDE.md` sagt: > **Remotes are named `github` and `JLab-Git`** — there is no `origin`. Tatsächlich hat der Checkout genau einen Remote, und der heißt `origin`: ``` origin ssh://git@git.jk-dev.de:30022/jlab-cluster/helm-charts.git ``` Dasselbe gilt für frisch erzeugte Worktrees. Zwei Umsetzungs-Agenten sind unabhängig voneinander darüber gestolpert und haben es im Abschlussbericht gemeldet; ein Push, der sich nach dieser Zeile richtet, scheitert schlicht. **Zu tun:** Die Zeile beschreibt, was da ist — ein Remote `origin` auf die Gitea-Instanz. Der Punkt dahinter bleibt gültig und gehört erhalten: github.com ist ein Spiegel, `main` auf Gitea ist die führende Kopie. Wenn auf der Maschine des Betreuers zusätzlich ein zweiter Remote existiert, gehört das als Zusatz formuliert, nicht als Regel für alle. ## 2. Paralleles Arbeiten am Wiki ist ungeregelt Das Wiki ist ein eigenes Repository **ohne PR-Verfahren**. Bei der Umsetzung von #16 und #18 haben zwei Agenten fast gleichzeitig dieselben zwei Seiten bearbeitet (`Chart-Style-Guide.md`, `Lessons-Learned.md`). Der Rebase lief konfliktfrei durch — das war Glück, und Glück ist kein Verfahren. Ein Push mit Force hätte an dieser Stelle fremde Arbeit gelöscht, ohne dass irgendetwas gemeldet hätte. **Zu tun:** Im Wiki-Abschnitt von `CLAUDE.md` einen Satz ergänzen: vor jedem Push fetchen und rebasen, niemals mit Force pushen. ## 3. Versionszeilen im Wiki entfernen (gehört fachlich dazu) Die Chart-Seiten im Wiki nennen je eine Chart- und eine App-Version. Bei `urlaubsverwaltung` war die App-Version bereits eine Renovate-Runde veraltet, ohne dass es jemandem aufgefallen wäre. Das ist die unmittelbare Folge einer bewussten Regel in `CLAUDE.md`: Ein reiner App-Versions-Bump verpflichtet zu **keiner** Wiki-Änderung — sonst bräuchte jeder automatisch gemergte Renovate-PR einen Wiki-Commit, und die Regel wäre binnen einer Woche tot. Die Regel bleibt; was weg kann, ist die Zahl, die dadurch veraltet. **Zu tun:** Auf allen Chart-Seiten die Versionszeilen aus der Übersichtstabelle entfernen und stattdessen auf `Chart.yaml` verweisen — so, wie es der Chart-Index von Anfang an hält, mit genau dieser Begründung. Reine Wiki-Änderung: kein Chart-Bump, kein PR, keine Veröffentlichung. ## Umfang `CLAUDE.md` (Punkte 1 und 2) in einem PR; Punkt 3 direkt im Wiki, da dort kein PR-Verfahren existiert. Charts werden nicht angefasst, also keine Versionsänderung und kein Install-Test.

jlab-bot referenced a pull request that will close this issue

2026-09-26 23:43:36 +02:00

docs: name the remote that exists, and a push rule for the wiki #49

jklein closed this issue

2026-09-27 00:00:21 +02:00

jklein referenced this issue from a commit

2026-09-28 01:05:09 +02:00

docs: the instructions block is a snapshot from session start

jlab-bot referenced this issue

2026-09-28 01:06:12 +02:00

docs: cut every worktree from a freshly fetched origin/main #58

Sign in to join this conversation.