docs: neue Flags, Quick-Judge und parallele Server-Checks dokumentiert

- --no-tests und --approve-concerns in Syntax, Beschreibungen und Beispielen
- Quick-Check für Runde 1 im Ablaufbeispiel erklärt
- --continue: Hinweis auf parallele Server-Bereitschaftsprüfung
- Abschnitt 11 (Anwendungsfälle): neue Beispiele für --no-tests / --approve-concerns
- CLAUDE.md: currentModelKey-Cache, normalizeForComparison, quickJudgePrompt dokumentiert

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

BEDIENUNGSANLEITUNG.md

@@ -279,6 +279,7 @@ Empfohlene Sofortmaßnahmen: keine
 
 ```
 /optimize <auftrag> [--rounds N] [--with-doku] [--continue] [--interactive]
+          [--no-tests] [--approve-concerns] [--test-cmd "cmd"] [--test-timeout N]
 ```
 
 - `--rounds N` — maximale Anzahl Runden (Standard: 2)
@@ -286,8 +287,16 @@ Empfohlene Sofortmaßnahmen: keine
 - `--continue` — überspringt die Implementierungsphase und startet direkt mit dem
   Judge→Fix-Zyklus ab dem aktuellen Code-Stand. Nützlich wenn man bereits manuell
   `/coder`, `/judge` und `/fix` durchgeführt hat und den Rest automatisieren möchte.
+  Im `--continue`-Modus werden Coder- und Judge-Server gleichzeitig geprüft.
 - `--interactive` — pausiert nach erstem PASS für einen menschlichen Checkpoint.
   Details: siehe [Interactive-Modus](#interactive-modus) weiter unten.
+- `--no-tests` — überspringt die automatische Test-Erkennung. Sinnvoll wenn keine
+  Test-Suite vorhanden ist oder Tests über externe Infrastruktur laufen.
+- `--approve-concerns` — behandelt „PASS WITH CONCERNS" wie „PASS": kein ShipIt-Call,
+  direktes SHIP. Für Projekte, bei denen du dem Judge-Urteil vertraust.
+- `--test-cmd "befehl"` — überschreibt die automatische Test-Erkennung mit einem
+  eigenen Befehl (z.B. `--test-cmd "pytest tests/ -x"`).
+- `--test-timeout N` — maximale Laufzeit pro Test-Befehl in Sekunden (Standard: 120).
 
 ### Beispiel: einfacher Auftrag
 
@@ -298,21 +307,25 @@ Empfohlene Sofortmaßnahmen: keine
 Was im Hintergrund passiert:
 ```
 Phase 1: Coder implementiert...
-Phase 2: Runde 1/2: Judge prüft...
+Phase 2: Runde 1/2: Quick-Check (kompakter Erstcheck)...
   → Urteil: FAIL (2 Blocker)
 Phase 3: Runde 1/2: Coder fixt...
-Phase 4: Runde 2/2: Judge prüft...
+Phase 4: Runde 2/2: Judge — TASK.md + letzter Commit + Tests...
   → Urteil: PASS WITH CONCERNS
 ✓ PASS WITH CONCERNS nach Runde 2
-Finale ShipIt-Prüfung... (nur bei PASS WITH CONCERNS)
+Finale ShipIt-Prüfung... (nur bei PASS WITH CONCERNS, nicht bei klarem PASS)
   → SHIP
 [Dialog: Version → v0.1.0 (empfohlen)]
 ```
 
+**Runde 1 = Quick-Check:** Kompakter Prompt ohne TASK.md-Analyse — erkennt offensichtliche
+Fehler schnell. Erst ab Runde 2 (oder bei `--continue`) kommt der vollständige Judge-Prompt.
+
 Bei klarem `PASS` entfällt die ShipIt-Runde — es wird direkt SHIP ausgelöst.
+Mit `--approve-concerns` gilt das auch für `PASS WITH CONCERNS`.
 
 Während des Ablaufs zeigt die Statuszeile immer die aktuelle Aktivität:
-`Coder implementiert…` → `Editiere src/main.rs…` → `Git-Commit…` → `Judge reviewt (Runde 1/2)…`
+`Coder implementiert…` → `Quick-Check…` → `Coder fixt Blocker…` → `Judge reviewt (Runde 2/2)…`
 
 ### Beispiel: mehr Runden
 
@@ -694,6 +707,26 @@ Die Checkboxen werden automatisch abgehakt:
 /quick_check
 ```
 
+### Repo ohne Test-Suite oder mit externer CI
+
+```bash
+# Test-Erkennung überspringen — Judge bewertet nur den Code
+/optimize "Implementiere Feature X" --no-tests
+
+# Externe Test-Suite explizit angeben
+/optimize "Implementiere Feature X" --test-cmd "make integration-test"
+```
+
+### Schneller Loop ohne ShipIt-Runde
+
+```bash
+# Für Projekte wo "PASS WITH CONCERNS" ausreicht:
+/optimize "Kleines Refactoring" --approve-concerns
+
+# Kombination: kein Test, kein ShipIt bei Concerns, 1 Runde
+/optimize "Typo-Fix in Fehlermeldungen" --rounds 1 --no-tests --approve-concerns
+```
+
 ### Versionsnummer nach der Entwicklung setzen
 
 ```bash