feat: Demo-Examples (Python/Rust/Go/C) mit Protokoll-Templates und Restore-Skript

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

examples/c-linkedlist/README.md

@@ -0,0 +1,48 @@
+# C Linked List
+
+Vollständige einfach-verkettete Liste — bis auf `list_free()`, das als leerer Stub vorliegt.
+Jeder Programmlauf leckt den gesamten Listen-Speicher.
+
+## Aktueller Stand
+
+```
+linked_list.h   Interface: node_new, list_prepend, list_append, list_print, list_free, list_length
+linked_list.c   Alles implementiert — außer list_free() (Stub, tut nichts)
+main.c          Baut Liste 1–5, gibt sie aus, ruft list_free() auf (ohne Wirkung)
+```
+
+## Demo 1: `/quick_check` als Diagnose
+
+```
+/quick_check "Gibt es Speicherlecks oder sonstige Probleme in diesem C-Projekt?"
+```
+
+Der Judge analysiert den Code und identifiziert das leere `list_free()` als Speicherleck-Quelle.
+
+## Demo 2: `/fix` für gezieltes Nacharbeiten
+
+```
+/fix "Implementiere list_free() korrekt, sodass valgrind --leak-check=full sauber ist."
+```
+
+Coder implementiert die Funktion, committet. Kein vollständiger Judge-Loop —
+ideal für kleine, klar abgegrenzte Fixes.
+
+## Demo 3: `/patch` für Minimal-Erweiterungen
+
+```
+/patch "Ergänze list_search(head, value) in Header und Implementierung.
+        Gibt den ersten Node* mit dem gesuchten Wert zurück, oder NULL."
+```
+
+pi-coder wendet einen unified diff an (`apply_patch`-Tool), ohne den vollständigen Loop.
+
+## Manueller Build
+
+```bash
+gcc -Wall -Wextra -o ll_demo linked_list.c main.c
+./ll_demo
+
+# Mit Leak-Check:
+valgrind --leak-check=full ./ll_demo
+```