docs: LICENCE.md-Feature, .gitignore, Single-GPU-Doku

- pi-coder-judge-extension.ts: licenceMd() + writeLicenceMd() — erzeugt proprietäre LICENCE.md in der Doku-Phase (nur wenn noch nicht vorhanden) - tests: Guards und pure-logic-Tests für LICENCE.md ergänzt (38 Tests, alle grün) - .gitignore: Node, TypeScript-Artefakte, Backups, Editor-Dateien, OS-Metadaten - README.md + BEDIENUNGSANLEITUNG.md: vollständig auf Single-GPU-Architektur aktualisiert (ein Server, System-Prompt-Rollen, kein Quick-Judge, PASS WITH CONCERNS-Verhalten, LICENCE.md in /update_doku, start-single.sh) - SINGLE_SERVER_PLAN.md: entfernt (umgesetzt, kein Mehrwert mehr) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-06-15 05:03:50 +02:00 · 2026-06-15 05:03:50 +02:00 · 485ab30265
commit 485ab30265
parent ba733fe684
7 changed files with 297 additions and 357 deletions
--- a/README.md
+++ b/README.md
@ -1,8 +1,9 @@
-# pi_coder — Automatisierter Coder/Judge-Workflow für pi agent
+# pi_coder_2 — Automatisierter Coder/Judge-Workflow für pi agent

 Dieses Repository enthält die Konfiguration und Skripte für einen automatisierten
-Coding-Workflow mit zwei lokalen LLaMA-Modellen: ein Coder-Modell und ein Judge-Modell,
-gesteuert über [pi agent](https://github.com/earendil-works/pi).
+Coding-Workflow mit einem lokalen LLaMA-Modell, das abwechselnd als Coder und Judge
+agiert — gesteuert über Pi Agent. Er dreht solange Optimierungsschleifen, bis das
+Programm Produktionsreife hat.

 ---

@ -12,37 +13,40 @@ gesteuert über [pi agent](https://github.com/earendil-works/pi).
 Nutzer gibt Auftrag
        │
        ▼
-  /coder  →  qwen3.5-coder (:8001)  →  Implementierung + git commit
+  /coder  →  qwen3.5-single (:8001, Coder-Persona)  →  Implementierung + git commit
        │
        ▼
-  /judge  →  qwen3.5-judge (:8002)  →  Review: PASS / FAIL + Blocker
+  /judge  →  qwen3.5-single (:8001, Judge-Persona)  →  Review: PASS / FAIL + Blocker
        │
   FAIL? ▼
-  /fix    →  qwen3.5-coder (:8001)  →  Fixes + git commit
+  /fix    →  qwen3.5-single (:8001, Coder-Persona)  →  Fixes + git commit
+        │
+   PASS WITH CONCERNS? ▼
+        │  (ohne --approve-concerns: wie FAIL → weiterer Fix-Zyklus)
        │
   PASS? ▼
-  /shipit →  qwen3.5-judge (:8002)  →  Finale Freigabe: SHIP / NO-SHIP
-               (nur bei "PASS WITH CONCERNS" — klares PASS → direkt SHIP)
+  /shipit →  qwen3.5-single (:8001, Judge-Persona)  →  Finale Freigabe: SHIP / NO-SHIP
+               (nur bei "PASS WITH CONCERNS" --approve-concerns; klares PASS → direkt SHIP)

  /optimize = Coder→Judge→Fix-Schleife automatisch (bis PASS oder max. N Runden)
  --interactive: pausiert nach PASS für menschlichen Checkpoint + optionale Zusatzaufträge
 ```

-Beide Modelle laufen als **separate llama.cpp-Docker-Container** und sprechen eine
-OpenAI-kompatible API (`/v1/chat/completions`). pi agent wechselt automatisch zwischen
-den Endpunkten wenn du ein `/judge`-, `/fix`- oder `/coder`-Kommando aufrufst.
+Ein **einzelner** llama.cpp-Docker-Container bedient beide Rollen. Die Rollenumschaltung
+(Coder ↔ Judge) erfolgt über unterschiedliche System-Prompts, die der `before_agent_start`-Hook
+der Extension vor jeder Inference injiziert. pi agent wechselt keine Server mehr —
+nur die Persona im System-Prompt ändert sich.

 ---

 ## Modelle

-| Rolle  | Modell                                            | Port | Container        | Alias          | GPU      |
-|--------|---------------------------------------------------|------|------------------|----------------|----------|
-| Coder  | Qwen3.6-27B-Uncensored-HauhauCS-Aggressive-IQ4_XS | 8001 | qwen36-27b-coder | qwen3.5-coder  | device=1 |
-| Judge  | Qwen3.6-27B-Uncensored-HauhauCS-Aggressive-IQ4_XS | 8002 | qwen36-27b-judge | qwen3.5-judge  | device=2 |
+| Rolle          | Modell                                            | Port | Container          | Alias          | GPU      |
+|----------------|---------------------------------------------------|------|--------------------|----------------|----------|
+| Coder + Judge  | Qwen3.6-27B-Uncensored-HauhauCS-Aggressive-IQ4_XS | 8001 | qwen36-27b-single  | qwen3.5-single | device=1 |

-Beide Container verwenden dasselbe GGUF-Datei, aber mit unterschiedlichen
-Serverparametern (Kontext, Temperatur, Parallelität).
+Coder- und Judge-Rollen werden durch verschiedene System-Prompts realisiert —
+dasselbe Modell, derselbe Container, unterschiedliche Persona.

 ---

@ -58,12 +62,12 @@ Serverparametern (Kontext, Temperatur, Parallelität).
  sudo apt-get update && sudo apt-get install -y nvidia-container-toolkit
  sudo systemctl restart docker
  ```
- NVIDIA-GPUs: empfohlen 2 × RTX 3090 (je 24 GB VRAM) für Coder und Judge parallel.
-  Bei 3 GPUs: GPU 0 für Display reservieren, GPU 1 → Coder, GPU 2 → Judge.
+- NVIDIA-GPU: empfohlen RTX 3090 (24 GB VRAM). Standard: GPU 1. Überschreibbar mit
+  `GPU_DEVICE=0 ./start-single.sh`. Bei 3 GPUs: GPU 0 für Display reservieren.
 - GGUF-Modell vorhanden unter:
  `$HF_HOME/models/qwen3/Qwen3.6-27B-Uncensored-HauhauCS-Aggressive-IQ4_XS.gguf`
  - Standard-Pfad: `HF_HOME=/home/dschlueter/nvme2n1p7_home/huggingface`
-  - Überschreibbar: `HF_HOME=/anderer/pfad ./start-servers.sh`
+  - Überschreibbar: `HF_HOME=/anderer/pfad ./start-single.sh`
 - [pi agent](https://github.com/earendil-works/pi) installiert (`~/.pi/`)

 ---
@ -75,16 +79,20 @@ Serverparametern (Kontext, Temperatur, Parallelität).
 git clone https://kitux.de/forgejo/dschlueter/pi_coder.git ~/pi_coder
 cd ~/pi_coder

-# 2. Extension und Modell-Config nach ~/.pi/agent/ deployen
+# 2. Extension, Modell-Config und settings.json nach ~/.pi/agent/ deployen
 ./install_servers_and_pi_coder_extension.sh

 # 3. pi agent neu laden (in der pi-Oberfläche)
 # /reload

 # 4. Server starten
-./start-servers.sh
+./start-single.sh
 ```

+Das Install-Skript sichert eine vorhandene `~/.pi/agent/settings.json` als `.bak` und
+kopiert dann `settings.json` aus dem Repo. Damit ist der korrekte Default-Provider
+(`llama-cpp-single/qwen3.5-single`) automatisch konfiguriert.
+
 Nach späteren Änderungen an `pi-coder-judge-extension.ts` oder `models.json`:
 ```bash
 ./install_servers_and_pi_coder_extension.sh   # kopiert nach ~/.pi/agent/
@ -96,95 +104,71 @@ Nach späteren Änderungen an `pi-coder-judge-extension.ts` oder `models.json`:
 ## Server starten / stoppen / status

 ```bash
-# Beide Server parallel starten (empfohlen — dauert 1–3 Minuten)
-./start-servers.sh
+# Server starten (empfohlen — dauert 1–3 Minuten)
+./start-single.sh

-# Einzeln starten (z.B. nur einen neu starten)
-./start-coder.sh   # Port 8001
-./start-judge.sh   # Port 8002
+# Server auf anderer GPU starten
+GPU_DEVICE=0 ./start-single.sh

-# Beide stoppen
+# Stoppen
 ./stop-servers.sh

-# Status beider Server prüfen
+# Status prüfen
 ./status.sh
 ```

-`start-servers.sh` startet beide Container gleichzeitig und wartet bis beide
-HTTP-ready sind (max. 5 Minuten — die neue llama.cpp-Version prüft beim Start, ob
-Modell + KV-Cache in den VRAM passen, was zusätzliche Zeit kostet). Logs werden
-getrennt gesammelt und nur bei Fehler ausgegeben.
+`start-single.sh` startet den Container und wartet bis HTTP-ready (max. 5 Minuten — die
+neue llama.cpp-Version prüft beim Start, ob Modell + KV-Cache in den VRAM passen, was
+zusätzliche Zeit kostet).

-Wenn Server bereits laufen und du `start-servers.sh` (oder ein Einzelskript)
-aufrufst, werden die laufenden Container zuerst per `docker rm -f` gestoppt
-und dann neu gestartet — ein laufender Inference-Request wird dabei abgebrochen.
+Wenn der Server bereits läuft und du `start-single.sh` aufrufst, wird der laufende
+Container zuerst per `docker rm -f` gestoppt und dann neu gestartet — ein laufender
+Inference-Request wird dabei abgebrochen.

 ---

 ## llama.cpp-Serverparameter im Detail

-### Gemeinsame Parameter
+### Parameter des Single-Servers (Port 8001)

 | Parameter | Wert | Bedeutung |
 |---|---|---|
 | `--jinja` | — | Verwendet das im GGUF eingebettete Jinja-Chat-Template (Qwen-Format). Notwendig für korrekte `<\|im_start\|>`-Tokens. |
-| `--reasoning on` | — | Aktiviert das interne Thinking-Budget des Modells (Qwen3-spezifisch). Ersetzt das frühere `--chat-template-kwargs '{"enable_thinking":true}'`. |
+| `--reasoning on` | — | Aktiviert das interne Thinking-Budget des Modells (Qwen3-spezifisch). |
 | `--no-context-shift` | — | Kontextfenster wird **nicht** verschoben wenn es voll ist — stattdessen Fehler. Verhindert stille Datenverluste. |
-| `--repeat-penalty 1.05` | — | Leichte Penalty für Wiederholungen. Wert > 1.0 unterdrückt Loops. |
-| `--top-k 20` | — | Nur die 20 wahrscheinlichsten nächsten Tokens werden berücksichtigt. |
+| `--repeat-penalty 1.05` | — | Leichte Penalty für Wiederholungen. |
+| `--top-k 20` | — | Nur die 20 wahrscheinlichsten nächsten Tokens. |
 | `--min-p 0.01` | — | Tokens mit Wahrscheinlichkeit < 1 % des wahrscheinlichsten Tokens werden ausgeschlossen. |
-| `-ngl 999` | — | Alle Layer auf die GPU laden (999 = „alle"). Bei zu wenig VRAM reduzieren. |
-| `-fa on` | — | Flash Attention — schnellere Attention-Berechnung, weniger VRAM für den Attention-Pass. |
-| `--kv-unified` | — | Einheitlicher KV-Cache über alle Schichten. Effizienter bei langen Kontexten. |
-| `--cache-type-k q4_0` | — | KV-Cache Keys in 4-Bit quantisiert. Spart ~75 % VRAM gegenüber fp16 — nötig für 256K Kontext auf einer 24-GB-GPU. |
+| `-ngl 999` | — | Alle Layer auf die GPU laden. |
+| `-fa on` | — | Flash Attention. |
+| `--kv-unified` | — | Einheitlicher KV-Cache über alle Schichten. |
+| `--cache-type-k q4_0` | — | KV-Cache Keys 4-Bit quantisiert. Nötig für 256K Kontext auf einer 24-GB-GPU. |
 | `--cache-type-v q4_0` | — | KV-Cache Values ebenfalls 4-Bit quantisiert. |
-| `--cont-batching` | — | Continuous Batching: neue Anfragen werden in laufende Batches eingefügt — höherer Durchsatz bei mehreren parallelen Anfragen. |
-| `--main-gpu 0` | — | GPU-Index (0 = erste des Containers) für Nicht-Tensor-Operationen. |
-| `--gpus '"device=1"'` (Coder) | — | Docker: nur GPU 1 dem Coder-Container zuweisen. |
-| `--gpus '"device=2"'` (Judge) | — | Docker: nur GPU 2 dem Judge-Container zuweisen. |
-
-### Coder-Server (Port 8001) — optimiert für Coding-Aufgaben
-
-| Parameter | Wert | Erklärung / Wirkung |
-|---|---|---|
-| `-c 262144` | 256K Tokens | Sehr großes Kontextfenster: gesamte Codebasis + langer Gesprächsverlauf passt rein. **Sehr hoher VRAM-Bedarf.** Reduziere auf `65536` wenn VRAM knapp. |
-| `-n 16384` | 16K Tokens | Maximale Ausgabelänge pro Anfrage. Für Kommentieraufgaben (`/update_doku`) nötig. |
-| `--temp 0.2` | — | Niedrige Temperatur: deterministisch, konsistenter Code. Erhöhe auf `0.4–0.6` für kreativere Lösungsansätze. |
-| `--top-p 0.95` | — | Nucleus Sampling: 95 % der Wahrscheinlichkeitsmasse. Passend zu temp 0.2. |
-| `--batch-size 1024` | — | Prompt-Verarbeitungs-Batch. Größer = schnelleres Einlesen langer Dateien. |
-| `--ubatch-size 512` | — | Micro-Batch für GPU-Kernel. Muss ≤ batch-size sein. |
-| `--parallel 2` | — | 2 gleichzeitige Request-Slots. Nützlich wenn pi agent schnell Folgeanfragen schickt. |
-
-### Judge-Server (Port 8002) — optimiert für Reviews
-
-| Parameter | Wert | Erklärung / Wirkung |
-|---|---|---|
-| `-c 262144` | 256K Tokens | Großes Kontextfenster: nötig bei langen /optimize-Runden, wo der Gesprächsverlauf stark anwächst. |
-| `-n 16384` | 16K Tokens | Lange Reviews und Begründungen passen vollständig in die Ausgabe. |
-| `--temp 0.1` | — | Sehr niedrige Temperatur: maximale Konsistenz und Reproduzierbarkeit der Urteile. |
-| `--top-p 0.9` | — | Etwas enger als beim Coder — weniger Variation im Urteil gewünscht. |
-| `--batch-size 512` | — | Kleiner als beim Coder — Judge bekommt selten sehr lange Prompts. |
-| `--ubatch-size 256` | — | Entsprechend kleiner. |
-| `--parallel 1` | — | Judge-Aufgaben sind immer sequenziell im Workflow, daher 1 Slot ausreichend. |
+| `--cont-batching` | — | Continuous Batching. |
+| `-c 262144` | 256K | Großes Kontextfenster für langen Gesprächsverlauf im Optimize-Loop. |
+| `-n 16384` | 16K | Maximale Ausgabelänge. |
+| `--temp 0.2` | — | Deterministisch — Coder-Rolle. Der Judge-System-Prompt gleicht die etwas höhere Temperatur aus. |
+| `--parallel 2` | — | 2 Slots, damit pi agent Folgeanfragen schnell hintereinander stellen kann. |
+| `--gpus '"device=1"'` | — | Standard: GPU 1. Überschreibbar: `GPU_DEVICE=0 ./start-single.sh`. |

 ---

 ## GPU-Konfiguration und VRAM

-### Aktuelles Setup (1 GPU pro Server)
+### Aktuelles Setup (1 GPU, 1 Server)

-Jeder Server bekommt eine dedizierte GPU — dadurch kein VRAM-Konflikt:
+Ein einzelner Container bedient beide Rollen sequenziell:

 ```
 GPU 0  NVIDIA T600       →  Display / Monitor (nicht für KI genutzt)
-GPU 1  RTX 3090 (24 GB)  →  qwen36-27b-coder  (Port 8001)
-GPU 2  RTX 3090 (24 GB)  →  qwen36-27b-judge  (Port 8002)
+GPU 1  RTX 3090 (24 GB)  →  qwen36-27b-single  (Port 8001, Coder + Judge)
 ```

-Die Skripte verwenden `--gpus '"device=1"'` (Coder) bzw. `'"device=2"'` (Judge).
-Innerhalb des Containers ist dies stets `CUDA:0`, daher `--main-gpu 0` ohne `--tensor-split`.
+Da Coder und Judge nicht gleichzeitig inferieren, gibt es keinen VRAM-Konflikt.
+Die Umschaltung zwischen den Rollen erfolgt ausschließlich über den System-Prompt —
+der Container läuft ohne Unterbrechung durch.

-### VRAM-Abschätzung für das 27B IQ4_XS-Modell (eine GPU)
+### VRAM-Abschätzung für das 27B IQ4_XS-Modell

 | Komponente | Größe (ca.) |
 |---|---|
@ -194,36 +178,28 @@ Innerhalb des Containers ist dies stets `CUDA:0`, daher `--main-gpu 0` ohne `--t
 | KV-Cache bei 65 536 Tokens (q4_0) | ~2–3 GB |
 | **Summe (262k Kontext)** | **~22–24 GB** |

-Bei einer **24-GB-GPU** ist 262k Kontext knapp kalkuliert. Wichtig: keine anderen Prozesse
+Bei einer **24-GB-GPU** ist 262k Kontext knapp kalkuliert. Keine anderen Prozesse
 dürfen nennenswert VRAM belegen (z. B. TTS-Dienste, Ollama). Prüfen mit:
 ```bash
 nvidia-smi --query-gpu=index,memory.used,memory.free --format=csv
 ```

-Falls der VRAM nicht reicht: Kontext in den Startskripten auf `131072` oder `65536` reduzieren.
+Falls der VRAM nicht reicht: Kontext in `start-single.sh` auf `131072` oder `65536` reduzieren.

 ### Anpassung für andere GPU-Konfigurationen

 ```bash
-# 2 GPUs (beide für KI, keine Display-GPU):
-  --gpus '"device=0"'   # Coder
-  --gpus '"device=1"'   # Judge
+# Andere GPU verwenden:
+GPU_DEVICE=0 ./start-single.sh

-# 1 GPU (beide Server auf gleicher GPU — nicht empfohlen, VRAM-Konflikt):
-  --gpus '"device=0"'   # beide Server
-  --tensor-split 0.5,0.5  # Modell hälftig aufteilen
-  -c 65536               # Kontext stark reduzieren
-
-# 2 GPUs für einen Server (wenn sehr großer Kontext nötig):
+# 2 GPUs für einen Server (sehr großer Kontext):
+# start-single.sh anpassen:
  --gpus '"device=0,1"' \
  --tensor-split 0.5,0.5 \
  --main-gpu 0 \
  -c 262144
 ```

-Bei einer **16-GB-GPU** ist die Modellgröße allein schon grenzwertig.
-Entweder ein kleineres Modell verwenden oder die Quantisierung erhöhen (IQ3_XS, Q4_K_M).
-
 ---

 ## Parameter-Tuning-Guide
@ -232,23 +208,18 @@ Entweder ein kleineres Modell verwenden oder die Quantisierung erhöhen (IQ3_XS,

 | Wert | Eignung |
 |---|---|
-| `0.0–0.1` | Maximale Reproduzierbarkeit. Gut für Judge/Review. |
-| `0.1–0.3` | Guter Kompromiss für Coding. **Empfohlen für Coder.** |
-| `0.4–0.6` | Kreativere Lösungen, mehr Varianz. Sinnvoll für Prototyping. |
-| `0.7–1.0` | Kreativschreiben, Brainstorming. Für Coding meist zu viel Rauschen. |
+| `0.0–0.1` | Maximale Reproduzierbarkeit. |
+| `0.1–0.3` | Guter Kompromiss für Coding. **Aktuell gesetzt: 0.2.** |
+| `0.4–0.6` | Kreativere Lösungen. |
+| `0.7–1.0` | Für Coding meist zu viel Rauschen. |

 ### Kontextgröße (`-c`)

-Je größer der Kontext, desto mehr VRAM braucht der KV-Cache.
-Faustregel: KV-Cache ≈ `context_size × layers × head_dim × 2 × bytes_per_element`.
-Bei q8_0 (1 Byte/Element) und Qwen3-27B (28 Schichten, 128 Head-Dim, 32 Heads):
-KV-Cache ≈ `context_size × 28 × 128 × 32 × 2 × 1 Byte ≈ context_size × 0,23 MB`
-
 | Kontext | KV-Cache (q4_0) | Empfehlung |
 |---|---|---|
 | 32 768 | ~1,9 GB | 1 × 16-GB-GPU |
-| 65 536 | ~3,7 GB | 1 × 24-GB-GPU |
-| 131 072 | ~7,5 GB | 2 × 16-GB-GPU |
+| 65 536 | ~3,7 GB | 1 × 24-GB-GPU (konservativ) |
+| 131 072 | ~7,5 GB | 1 × 24-GB-GPU |
 | 262 144 | ~8–10 GB | 1 × 24-GB-GPU (q4_0) — **aktuell gesetzt** |

 ### KV-Cache-Quantisierung
@ -257,31 +228,35 @@ KV-Cache ≈ `context_size × 28 × 128 × 32 × 2 × 1 Byte ≈ context_size ×
 |---|---|---|
 | `f16` | 100 % (Basis) | Referenz |
 | `q8_0` | ~50 % | Kaum merklich schlechter |
-| `q4_0` | ~25 % | Merklicher Qualitätsverlust bei langen Kontexten — aber nötig für 256K Kontext auf 2× 24 GB. **Aktuell gesetzt.** |
+| `q4_0` | ~25 % | Merklicher Qualitätsverlust bei langen Kontexten — aber nötig für 256K Kontext auf 24 GB. **Aktuell gesetzt.** |

-### Parallelität (`--parallel`)
+---

-Mehr parallele Slots erhöhen den Durchsatz bei gleichzeitigen Anfragen, aber jeder Slot
-reserviert Speicher im KV-Cache. Im pi-coder-Workflow sind echte Parallelaufrufe selten,
-daher ist `--parallel 1` für den Judge ausreichend. Coder `--parallel 2` bietet Puffer
-wenn pi agent Folgeanfragen schnell hintereinander schickt.
+## Tests ausführen
+
+```bash
+./run-tests.sh
+```
+
+Keine npm-Installation nötig — nutzt den integrierten `node:test`-Runner und
+`--experimental-strip-types` für TypeScript. Testet Parsing-Logik, Konfigurationskonsistenz
+und Extension-Guards gegen Regressionen.

 ---

 ## Dateien

-| Datei | Zweck |
+| Datei / Verzeichnis | Zweck |
 |---|---|
-| `pi-coder-judge-extension.ts` | pi agent Extension (Kommandos, Tools, Hooks) |
+| `pi-coder-judge-extension.ts` | pi agent Extension (Kommandos, Tools, Hooks, Rollen-Logik) |
 | `models.json` | Provider- und Modell-Konfiguration für pi agent |
-| `test-utils.ts` | Unit-Tests für Hilfsfunktionen der Extension |
-| `run-tests.sh` | Unit-Tests ausführen (TypeScript-Stripping + node) |
-| `start-servers.sh` | Beide Server parallel starten (empfohlen) |
-| `start-coder.sh` | Nur Coder-Container starten (Port 8001) |
-| `start-judge.sh` | Nur Judge-Container starten (Port 8002) |
-| `stop-servers.sh` | Beide Container stoppen |
-| `status.sh` | Laufstatus beider Server anzeigen |
-| `install_servers_and_pi_coder_extension.sh` | Extension + models.json nach `~/.pi/agent/` kopieren |
+| `settings.json` | pi-agent-Settings (Default-Modell, aktivierte Modelle) — wird von Install-Skript deployt |
+| `run-tests.sh` | Tests ausführen |
+| `tests/` | Testdateien (pure-logic, config, extension-guards, scripts) |
+| `start-single.sh` | Single-Server starten (Port 8001, Coder + Judge) |
+| `stop-servers.sh` | Container stoppen |
+| `status.sh` | Laufstatus anzeigen |
+| `install_servers_and_pi_coder_extension.sh` | Extension + models.json + settings.json nach `~/.pi/agent/` deployen |
 | `examples/` | Demo-Projekte (Python, Rust, Go, C, Bash, HTML/JS) für Live-Demos |
 | `examples/restore-all.sh` | Examples nach Demo-Lauf in Ausgangszustand zurücksetzen |

@ -289,18 +264,18 @@ wenn pi agent Folgeanfragen schnell hintereinander schickt.

 ## pi-Kommandos (Kurzübersicht)

-| Kommando | Modell | Beschreibung |
+| Kommando | Persona | Beschreibung |
 |---|---|---|
 | `/coder <auftrag>` | Coder | TASK.md anlegen, Implementierung starten |
 | `/judge [fokus]` | Judge | Code-Review gegen TASK.md + letzten Commit |
 | `/fix [hinweis]` | Coder | Judge-Kritik beheben, committen |
 | `/shipit` | Judge | Finale Freigabeprüfung |
-| `/optimize <auftrag> [--rounds N] [--with-doku] [--continue] [--interactive]` | beide | Vollautomatische Schleife bis PASS (Standard: 2 Runden, Runde 1: Quick-Judge) |
-| `/optimize ... [--no-tests] [--approve-concerns] [--test-cmd "cmd"] [--test-timeout N]` | beide | Test-Erkennung überspringen / PASS WITH CONCERNS direkt shippern |
+| `/optimize <auftrag> [--rounds N] [--with-doku] [--continue] [--interactive]` | beide | Vollautomatische Schleife bis PASS (Standard: 2 Runden) |
+| `/optimize ... [--no-tests] [--approve-concerns] [--test-cmd "cmd"] [--test-timeout N]` | beide | Test-Erkennung überspringen / PASS WITH CONCERNS akzeptieren |
 | `/patch <änderung>` | Coder | Gezielte Minimaländerung ohne Review |
 | `/quick_check [was]` | Judge | Schnelle Prüfung der letzten Änderung |
 | `/version` | — | Versionsnummer erhöhen (SemVer + Git-Tag) |
-| `/update_doku` | Coder | Code kommentieren + README + Bedienungsanleitung |
+| `/update_doku` | Coder | Code kommentieren + README + Bedienungsanleitung + LICENCE.md |
 | `/plan <auftrag>` | Coder | Implementierungsplan in PLAN.md (kein Code) |
 | `/continue` | Coder | Unterbrochenen Prozess fortsetzen |
 | `/cancel` | — | Laufenden Loop nach aktuellem Schritt abbrechen |
@ -310,6 +285,15 @@ Ausführliche Beschreibung aller Kommandos mit Beispielen: siehe **BEDIENUNGSANL

 ---

+## PASS WITH CONCERNS — Verhalten
+
+Im `/optimize`-Loop gilt `PASS WITH CONCERNS` **nicht** als bestanden — der Coder erhält
+einen weiteren Fix-Auftrag, genau wie bei `FAIL`. Erst sauberes `PASS` beendet die Schleife.
+
+Opt-out: `--approve-concerns` lässt `PASS WITH CONCERNS` als bestanden gelten.
+
+---
+
 ## Live-Aktivitätsstatus

 Während der Ausführung zeigt pi_coder in der Statuszeile, was gerade passiert —
@ -320,11 +304,11 @@ inklusive eines laufenden `[MM:SS]`-Timers während jeder LLM-Inference-Phase:
 | Coder implementiert | `◉ Coder implementiert: Login-Flow mit JWT [01:23]` |
 | edit-Tool aktiv | `Editiere src/main.py…` |
 | git commit | `Git-Commit…` |
-| Judge (Quick-Check, Runde 1) | `◉○ Runde 1/2: Quick-Check [00:47]` |
-| Judge (voller Review, Runde 2) | `●◉ Runde 2/2: Judge — TASK.md + letzter Commit + Tests [02:15]` |
+| Judge (Runde 1) | `◉○ Runde 1/2: Judge — TASK.md + letzter Commit + Tests [00:47]` |
+| Judge (Runde 2) | `●◉ Runde 2/2: Judge — TASK.md + letzter Commit + Tests [02:15]` |
 | Tests laufen | `●○ Runde 1/2: Tests laufen (pytest, max. 120s)…` |
 | Fix-Phase | `●◉ Runde 2/2: Coder fixt — fehlendes Null-Check [01:05]` |
 | ShipIt | `●●◉ ShipIt — finale Freigabe [00:33]` |
-| Interactive-Pause (--interactive) | `⏸ PASS – warte auf /continue…` |
+| Interactive-Pause | `⏸ PASS – warte auf /continue…` |

 Der Timer beweist, dass die LLM tatsächlich arbeitet. Steht er still, hängt der Prozess.