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>
