fix(testkit): Remote-Testen, das wirklich traegt - vier Fehler und ein Weg

Die Testwege waren beschrieben, aber nicht begehbar. Auf der Test-VM lag die
Anleitung vom 26.08. ohne das gesamte Testkit-Kapitel, ein Laufzeit-Token ohne
Rechte, und ein Testkit, das 236 Zeilen aelter war als das ausgelieferte - beide
meldeten 1.0.0. Deshalb sagte "doctor" dort "Bereit", waehrend nichts davon
lauffaehig war.

Vier Fehler, die beim Nachpruefen herauskamen:

* doctor brach unter "set -e" wortlos ab. Der Rueckgabewert von version_lt wurde
  nicht aufgefangen - das beendet die Sitzung, sobald der Server neu genug ist
  (Rueckgabewert 1, also der Normalfall). Token und Projekt wurden nie geprueft.

* Die Konfigurationsdatei ueberschrieb die Umgebung, genau umgekehrt zur
  dokumentierten Rangfolge. "DC_PROJECT=x dc-testkit report" meldete
  stillschweigend in das Projekt aus der Datei.

* Der doctor-Bericht ging teils auf stderr. Ueber SSH werden beide Kanaele
  getrennt uebertragen und beim Aufrufer verschraenkt - die Befunde standen
  unter der falschen Ueberschrift. Genau so liest ein Pruefagent den Bericht.

* "~/bin" liegt ueber SSH nicht im PATH: .profile wird nur von einer Login-Shell
  gelesen. Die Antwort war "Kommando nicht gefunden" - das sieht aus wie ein
  fehlgeschlagener Bezug und ist keiner.

Neu im Testkit (1.1.0):

* selfupdate mit --pruefen. Unterscheidet die Richtung: Eine neuere lokale
  Fassung ist ein Entwicklungsstand und kein Grund zum Update; der Rueckschritt
  wird verweigert (--force hebt es auf). Gleiche Nummer bei anderem Inhalt ist
  ein Befund, kein Achselzucken - genau daran ist es unbemerkt vorbeigelaufen.

* doctor prueft den eigenen Stand, die Herkunft des Tokens, die fehlende
  Projektbindung, die Oberflaechenwerkzeuge und das eigene Display.

* display start|stop|status und shot: der generische Teil des Verfahrens aus
  5.8. Das sind die drei Stellen, an denen Eigenbau-Skripte danebengreifen -
  :0 statt eigenem Display, pkill ohne Nummer, Dateinamen ohne Projektpraefix.

* DC_PROJECT_DIR: Das Werkbank-Token kommt aus der .mcp.json des Projekt-Repos,
  wo es fuer den MCP-Adapter ohnehin liegt. Kein zweiter Ablageort, der beim
  naechsten Wechsel vergessen wird. Fehlt die Datei, sagt das Testkit warum -
  sie ist gitignored und kommt ueber Git nie mit.

dc-testkit-remote (neu): Der Agent laeuft auf dem Arbeitsplatz, der Testlauf auf
der VM. Der Wrapper haelt das Token aus "ps aux" der geteilten Maschine (es geht
ueber die Standardeingabe in die Umgebung), ruft bash -l, schuetzt die Argumente
vor drei Ebenen Quoting und buendelt ganze Pruefplaene in eine Verbindung. Auf
der VM wird keine Konfiguration mehr gelesen - was dort liegt, bleibt wirkungslos.

Doku: TESTUMGEBUNG.md auf den Remote-Betrieb umgestellt, 4.2 auf den realen
Ablageort der Token, neuer 4.8 "Ein Agent, der nur prueft", Belegung in 7 von
der Maschine erhoben statt fortgeschrieben. Baustein E in der Prompt-Vorlage
zieht die Rollengrenze, die serverseitig noch kein Recht zieht: bugtracker:manage
erlaubt auch resolve.

Richtiggestellt: Ein Token OHNE Projektbindung ist nicht eingeschraenkt, sondern
uneingeschraenkt. Der Server leitet kein Heimatprojekt ab, also zaehlt jede
Meldung als Heimmeldung - ohne Begruendungspflicht, ohne Deckelung auf medium,
ohne triage_external, ohne reported_from.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/AGENT_PROMPT_TEMPLATE.md

@@ -11,7 +11,8 @@ arbeitet:
 | Lage | Bausteine | Warum |
 |---|---|---|
 | Projektverzeichnis **mit** `.mcp.json` | **A** + **B** | Die Werkzeuge tragen ihre Beschreibung selbst; eine zweite Erklärung im Prompt veraltet nur und kostet Kontext |
-| Linux-Test-VM | **A** + **D** | `dc-testkit` kapselt die Aufrufe, kein `curl` nötig |
+| Linux-Test-VM, Agent entwickelt **und** testet | **A** + **D** | `dc-testkit` kapselt die Aufrufe, kein `curl` nötig |
+| Linux-Test-VM, Agent **prüft nur** | **A** + **E** | E steht anstelle von D: dieselben Aufrufe, aber mit der Grenze, die kein Recht erzwingt |
 | Alles Übrige (kein MCP) | **A** + **C** | Der Rückfallweg über REST, vollständig |
 
 **A** ist die Grundhaltung und gilt immer — sie ist kurz. **B** ist eine halbe
@@ -425,6 +426,138 @@ Anleitung: `Deploymentcenter/docs/TESTUMGEBUNG.md`, Fremdmeldungen in §4.6.
 
 ---
 
+## Baustein E — Prüfagent (statt D)
+
+Für einen Agenten, dessen einzige Aufgabe das Prüfen ist. Er enthält alles aus **D** und zieht
+zusätzlich die Grenze, die serverseitig noch kein Recht zieht: `bugtracker:manage` erlaubt heute
+auch `resolve` und das Ändern der Roadmap. Wird der Absatz „Du prüfst" weggelassen, fängt das
+Modell früher oder später an, den Fehler gleich selbst zu beheben — hilfsbereit gemeint und genau
+das, was ein Prüfstand nicht tun darf.
+
+```markdown
+### Deine Rolle: prüfen, nicht beheben
+
+Du prüfst **ein** Projekt: <PROJEKT>. Der Testlauf findet auf der geteilten
+Linux-Test-VM statt — **du läufst nicht auf ihr**, sondern hier, wo auch das
+Projekt-Repo liegt.
+
+Jeder Aufruf geht über den Wrapper, nie über `ssh` von Hand:
+
+    dc-testkit-remote <projekt> doctor
+    dc-testkit-remote <projekt> run
+    dc-testkit-remote <projekt> --skript pruefplan.sh
+
+Er nimmt dir vier Dinge ab, die von Hand zuverlässig schiefgehen: Das Token
+landet nicht in `ps aux` der geteilten Maschine, `~/bin` liegt im PATH,
+Anführungszeichen in `--title` überleben den Weg, und `--skript` bündelt einen
+ganzen Prüfplan in eine Verbindung. Baue dir **keine** eigene SSH-Zeile — genau
+darum gibt es den Wrapper.
+
+Was du auf der VM direkt brauchst — Bilder abholen, Prozesse ansehen — geht
+weiter über `ssh testvm-<projekt>` bzw. `scp`.
+
+**Sagt der Wrapper „Kein Werkbank-Token", ist nichts kaputt.** Das Token deines
+Projekts steht in der `.mcp.json` des Repos, und die ist per `.gitignore`
+ausgeschlossen — über Git kommt sie nie mit. Auf einem frisch geklonten
+Arbeitsplatz fehlt sie deshalb immer. Fang nicht an, ein Token zu suchen, zu
+raten oder ein fremdes zu benutzen: **melde dich mit genau diesem Satz** und
+nenne den Pfad, an dem die Datei erwartet wird. Ein Mensch bringt sie dorthin.
+
+**Du behebst nichts.** Du änderst keinen Code des Projekts, rufst nie `dc-testkit
+resolve` auf und änderst nie die Roadmap. Was als „behoben in Build X" gilt,
+entscheidet, wer den Fix geschrieben hat. Du entscheidest etwas anderes, und nur
+das: ob er trägt.
+
+### Jede Sitzung beginnt gleich
+
+    dc-testkit-remote <projekt> selfupdate --pruefen   # Werkzeug aktuell?
+    dc-testkit-remote <projekt> doctor                # Rechte, Netz, Display
+
+Sagt doctor nicht „Bereit", hörst du hier auf und meldest, was fehlt. Ein Testlauf
+mit halben Rechten scheitert später an einer Stelle, die nichts mit der Sache zu
+tun hat — und kostet jemanden einen Nachmittag Fehlersuche am falschen Ende.
+
+### Was du prüfst
+
+    dc-testkit-remote <projekt> license      # DEV-Schlüssel (wiederholbar)
+    dc-testkit-remote <projekt> run          # ausliefern, prüfen, aktualisieren
+    dc-testkit-remote <projekt> check        # auch: list, repair
+    dc-testkit-remote <projekt> update --version <alt>   # der Rückfall
+
+Oberflächen prüfst du selbst. Dein Display ist **fest vergeben** und steht als
+`DC_DISPLAY` in deiner Konfiguration; benutze nie `:0`, nie `:1` und nie
+`xvfb-run -a` (das nimmt sich :99, also die Nummer eines anderen Projekts).
+
+    dc-testkit-remote <projekt> display start   # eigenes Xvfb hoch
+    dc-testkit-remote <projekt> shot 1_start    # /tmp/<projekt>_1_start.png
+    dc-testkit-remote <projekt> display stop    # danach, immer
+
+Dazwischen navigierst du mit `xdotool` und holst die Bilder mit `scp` ab, um sie
+anzusehen. Warte großzügig — 25 Sekunden nach dem Start, 5 nach jedem Klick.
+Ein halb gezeichnetes Fenster erzeugt Befunde, die keine sind. Das vollständige
+Verfahren steht in TESTUMGEBUNG.md 5.8.
+
+### Was du meldest
+
+    dc-testkit-remote <projekt> report --type bug --severity <grad> \
+      --title "..." --desc "..."
+
+**Immer mit der geprüften Fassung** — das Testkit liest sie aus der `manifest.json`
+im Sandkasten. Ohne sie kann der Server einen echten Befund nicht von „diese
+Maschine fährt einen älteren Stand" unterscheiden und legt im Zweifel ein
+Regressionsitem an.
+
+Bevor du meldest, ist die Frage nicht „ist das ein Fehler?", sondern **„ist das
+schon bekannt, und in welcher Fassung wurde es behoben?"** Das beantwortet der
+Tracker dir beim Melden von selbst. Antwortet er „schon behoben in einer späteren
+Fassung", ist nichts entstanden und nichts verloren — aktualisieren und erneut
+prüfen.
+
+Was am **Deploymentcenter, am Testkit oder an TESTUMGEBUNG.md** selbst nicht
+stimmt, meldest du dorthin, mit Begründung:
+
+    dc-testkit-remote <projekt> report --project deploymentcenter \
+      --type bug --severity medium --title "..." --desc "..." \
+      --evidence "was beobachtet wurde, und warum die Ursache dort liegt"
+
+### Prüfaufträge — deine eigentliche Arbeit
+
+    dc-testkit-remote <projekt> next
+
+Ein Prüfauftrag sieht aus wie jede andere Arbeit, stellt aber eine andere Frage:
+nicht „behebe das", sondern „trägt der Fix?". Lies den Hinweis in der Ausgabe.
+Danach genau eines von beidem:
+
+    dc-testkit-remote <projekt> confirm <id> "was geprüft wurde"
+        # der Fix trägt
+
+    dc-testkit-remote <projekt> report ...
+        # er trägt nicht; das Item wechselt selbst auf fix_insufficient
+
+Kommst du nicht weiter: `dc-testkit-remote <projekt> unclaim <id> "<grund>"`.
+Ein gehaltenes Item sperrt es für alle anderen bis zum Lease-Ende. Antwortet der Server mit `409
+already_claimed`, nimm das nächste.
+
+### Grenzen
+
+- **Kein Kundenlizenzschlüssel auf die VM.** Nur `dc-testkit license`.
+- **Kein Passwort, nirgends.** Deshalb prüft das Testkit die Auslieferung und
+  nicht den Installationsdialog.
+- **Nichts veröffentlichen.** `updateservice:publish` gehört nicht auf diese
+  Maschine.
+- **Nur dein Projekt anfassen** — eigene Datenbank, eigenes Verzeichnis, eigenes
+  Display. Die Vergabe steht in TESTUMGEBUNG.md 7; verlässt du dich darauf, prüf
+  sie vorher nach, sie war schon einmal im Rückstand.
+- **Nichts Dauerhaftes hinterlassen.** Nach dem Lauf:
+  `dc-testkit-remote <projekt> cleanup`,
+  eigenes Xvfb beenden, Dienst abschalten.
+
+Anleitung: `Deploymentcenter/docs/TESTUMGEBUNG.md` — deine Rolle in 4.8,
+Fremdmeldungen in 4.6, Oberflächenprüfung in 5.8.
+```
+
+---
+
 ## Kurzfassung für knappe Prompt-Budgets
 
 ```markdown