feat: Clean-Code-Kommentarregel in Implementierungsphasen verankern

Explizite No-Comment-Regel in /story Phase 4, /implement Phase 4
und /script V1+V2, damit Sonnet bei der Implementierung keine
überflüssigen Kommentare generiert.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
2026-06-08 07:30:16 +02:00
co-authored by Claude Opus 4.6
parent 449bf76518
commit cff9549617
3 changed files with 4 additions and 1 deletions
+1
View File
@@ -61,6 +61,7 @@ Implementiere die im Plan beschriebene Phase Schritt für Schritt:
- Nach jedem logischen Abschnitt committen (mindestens alle 30 Minuten) - Nach jedem logischen Abschnitt committen (mindestens alle 30 Minuten)
- CLAUDE.md-Konventionen einhalten: Ruff, Type Hints, async, Pydantic-Schemas, Logging statt print - CLAUDE.md-Konventionen einhalten: Ruff, Type Hints, async, Pydantic-Schemas, Logging statt print
- Keine generischen `try/except`, kein toter Code - Keine generischen `try/except`, kein toter Code
- Keine Kommentare — Code muss selbsterklärend sein. Nur kommentieren wenn das WARUM nicht aus dem Code hervorgeht
- Alembic-Migration: `alembic revision --autogenerate -m "<beschreibung>"` falls nötig - Alembic-Migration: `alembic revision --autogenerate -m "<beschreibung>"` falls nötig
Bei unerwarteten Problemen: User informieren, konkreten Lösungsvorschlag präsentieren, nicht stumm abweichen. Bei unerwarteten Problemen: User informieren, konkreten Lösungsvorschlag präsentieren, nicht stumm abweichen.
+2 -1
View File
@@ -116,7 +116,7 @@ Plan-Inhalt:
- **Error-Handling:** Cleanup-Strategie (`trap`), definierte Exit-Codes (0 Erfolg, 1 Fehler, 2 Usage, weitere dokumentiert) - **Error-Handling:** Cleanup-Strategie (`trap`), definierte Exit-Codes (0 Erfolg, 1 Fehler, 2 Usage, weitere dokumentiert)
- **Konsolenausgabe:** Eine Zeile pro Hauptschritt (` Schritt ... ok (Details)`). Keine Farben außer Gelb (Warnungen) und Rot (Fehler). Keine Querlinien, Tabellen oder Raw-Ausgabe. Ergebnis in die Hauptzeile, nicht als separater Block. "Erfolgreich" nur wenn tatsächlich etwas passiert ist — keine irreführenden Meldungen - **Konsolenausgabe:** Eine Zeile pro Hauptschritt (` Schritt ... ok (Details)`). Keine Farben außer Gelb (Warnungen) und Rot (Fehler). Keine Querlinien, Tabellen oder Raw-Ausgabe. Ergebnis in die Hauptzeile, nicht als separater Block. "Erfolgreich" nur wenn tatsächlich etwas passiert ist — keine irreführenden Meldungen
- **Output-Beispiel:** Exakte Zeile-für-Zeile-Ausgabe für den typischen Ablauf, so wie der User sie sehen soll - **Output-Beispiel:** Exakte Zeile-für-Zeile-Ausgabe für den typischen Ablauf, so wie der User sie sehen soll
- **Code-Skelett:** Hauptfunktion als Ablauf von Funktionsaufrufen, Hilfsfunktionen als Signatur mit Kommentar. Sonnet füllt die Funktionskörper - **Code-Skelett:** Hauptfunktion als Ablauf von Funktionsaufrufen, Hilfsfunktionen als Signatur mit kurzem Einzeiler nur wenn das WARUM nicht offensichtlich ist. Sonnet füllt die Funktionskörper
- **Dry-Run:** Welche Aktionen werden durch Log-Ausgabe ersetzt - **Dry-Run:** Welche Aktionen werden durch Log-Ausgabe ersetzt
- **User-Einbindung:** Rückfragen bei irreversiblen Operationen (`read -p`), `--yes` für nicht-interaktive Ausführung - **User-Einbindung:** Rückfragen bei irreversiblen Operationen (`read -p`), `--yes` für nicht-interaktive Ausführung
- **Explizite Verbote:** Bekannte Pitfalls, Redundanzen und Stilfehler benennen, die Sonnet vermeiden muss - **Explizite Verbote:** Bekannte Pitfalls, Redundanzen und Stilfehler benennen, die Sonnet vermeiden muss
@@ -143,6 +143,7 @@ Bash-spezifische Leitplanken:
- Quoting konsequent: `"$var"`, Arrays als `"${array[@]}"` - Quoting konsequent: `"$var"`, Arrays als `"${array[@]}"`
- `main()`-Funktion am Dateiende, aufgerufen mit `main "$@"` - `main()`-Funktion am Dateiende, aufgerufen mit `main "$@"`
- Script ausführbar machen: `chmod +x <pfad>` - Script ausführbar machen: `chmod +x <pfad>`
- Keine Kommentare — Code muss selbsterklärend sein. Nur kommentieren wenn das WARUM nicht aus dem Code hervorgeht
### V3: shellcheck (Pflicht) ### V3: shellcheck (Pflicht)
@@ -10,6 +10,7 @@ Implementierung nach Plan durchführen:
- Nach jedem logischen Abschnitt committen (mind. nach jeder abgeschlossenen Komponente) - Nach jedem logischen Abschnitt committen (mind. nach jeder abgeschlossenen Komponente)
- CLAUDE.md-Konventionen einhalten: Ruff, Type Hints, async, Pydantic-Schemas - CLAUDE.md-Konventionen einhalten: Ruff, Type Hints, async, Pydantic-Schemas
- Keine generischen `try/except`, kein toter Code, Logging statt print - Keine generischen `try/except`, kein toter Code, Logging statt print
- Keine Kommentare — Code muss selbsterklärend sein. Nur kommentieren wenn das WARUM nicht aus dem Code hervorgeht
- Alembic-Migration erstellen falls nötig: `alembic revision --autogenerate -m "..."` - Alembic-Migration erstellen falls nötig: `alembic revision --autogenerate -m "..."`
Bei unerwarteten Problemen: User informieren und Lösungsvorschlag präsentieren, nicht stumm abweichen. Bei unerwarteten Problemen: User informieren und Lösungsvorschlag präsentieren, nicht stumm abweichen.