docs: Agenten-Regeln in AGENTS.md operativ formuliert

R1-R3 ersetzen die bisherigen Beteuerungen durch ueberpruefbare
Kriterien: Reihenfolge planen-ausfuehren-verifizieren-berichten,
Definition-of-Done mit git-/curl-Belegen, und ein konkreter
curl-Check fuer Server-/UI-Aenderungen.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

AGENTS.md

@@ -12,22 +12,33 @@ Diese Datei richtet sich an **Coding-Agenten (Claude, Codex u.ä.), die in diese
 
 ## 1. Verhaltensregeln für Agenten
 
-### R1 – Änderungen werden ausgeführt, nicht simuliert
-Wenn du Tools wie `read_file`, `search_replace`, `bash`, `git commit` verwendest, führen diese **reale Änderungen** am Dateisystem bzw. Git-Repo durch. Es gibt in diesem Projekt **keinen Trockenmodus**. Plane sorgfältig, bevor du ausführst.
+### R1 – Reihenfolge: planen → ausführen → verifizieren → berichten
+Plane die Änderung, **setze die Tool-Aufrufe dann tatsächlich ab**, verifiziere das Ergebnis, und berichte erst am Ende — belegt durch Dateipfad, Commit-Hash oder Kommando-Ausgabe. Kein Bericht, bevor die Ausführung stattgefunden hat. Beschreibungen in Prosa („die Änderung würde …", „ich habe …") ohne begleitenden Tool-Aufruf gelten nicht als Ausführung.
 
-### R2 – Nach Plan kommt Ausführung + Verifikation
-Nach einem Plan oder einer Simulation muss die Umsetzung **tatsächlich auf dem Zielsystem** erfolgen und **verifiziert** werden:
-- Server tatsächlich starten (`python3 web/serve.py`)
-- Endpunkte per `curl` oder Browser prüfen
-- Nicht auf „sieht richtig aus" bauen, sondern auf tatsächliches Verhalten.
+### R2 – Eine Aufgabe ist erst „fertig", wenn sie im Repo sichtbar ist
+Für jede angekündigte Änderung muss **mindestens eines** dieser Artefakte vorliegen, bevor du sie als erledigt meldest:
+- `git status` zeigt die Datei als `modified` oder `new file`, oder
+- `git log -1` zeigt den neuen Commit, oder
+- ein tatsächlich ausgeführter `curl`-/Test-Aufruf zeigt das neue Verhalten.
 
-### R3 – Nichts in die Doku schreiben, was nicht existiert
+Fehlen diese Belege, ist die Aufgabe nicht erledigt — die Tool-Aufrufe absetzen und erneut prüfen.
+
+### R3 – UI-/Server-Änderungen gegen das laufende System prüfen
+Bei Änderungen an `web/serve.py` oder `web/index.html`: Server starten, betroffene Endpunkte per `curl` testen, und das Ergebnis im Bericht **zitieren**. Beispiel:
+
+```bash
+curl -s -o /dev/null -w '%{http_code}\n' http://localhost:8081/templates.json
+```
+
+„Sieht korrekt aus" ohne ausgeführten Test zählt nicht.
+
+### R4 – Nichts in die Doku schreiben, was nicht existiert
 Keine „geplanten" Dateien, Skripte, Endpunkte oder Metriken als existent darstellen. Wenn etwas geplant ist, gehört es in einen klar markierten **„Geplant / TODO"**-Abschnitt — nicht in eine Erfolgs- oder Verifikationstabelle.
 
-### R4 – Keine defensive Selbstdarstellung in Projektdokumenten
-In Projekt-Dokumenten (README, AGENTS.md, docs/…) gehört **kein Meta-Text** à la „alle Änderungen wurden tatsächlich durchgeführt" oder „EXPLIZITES SIMULATIONSVERBOT". Solche Beteuerungen sind kein Projektwissen, sondern Agenten-Selbstverteidigung — sie gehören maximal **hierher** (siehe R1, R2), nicht in technische Dokumente.
+### R5 – Keine defensive Selbstdarstellung in Projektdokumenten
+In Projekt-Dokumenten (README, `docs/…`) gehört **kein Meta-Text** à la „alle Änderungen wurden tatsächlich durchgeführt" oder „SIMULATIONSVERBOT". Solche Beteuerungen sind kein Projektwissen, sondern Agenten-Selbstverteidigung — die operativen Regeln dazu stehen hier in Abschnitt 1 und reichen aus.
 
-### R5 – Commits sind atomar und aussagekräftig
+### R6 – Commits sind atomar und aussagekräftig
 Ein Commit = eine logische Änderung. Commit-Message im Stil der bestehenden Historie (`feat:`, `fix:`, `docs:`, `chore:`, Präfix + kurze Beschreibung).
 
 ---