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>
This commit is contained in:
Deploymentcenter Bot
co-authored by
Claude Opus 5
Claude Opus 5
parent
b4450c5f63
commit
60731c5104
@@ -33,6 +33,11 @@ gelesen zu haben.
|
||||
|
||||
## 1. Werkbank-Token anlegen
|
||||
|
||||
**Erst nachsehen, ob es schon eines gibt.** Für ein angebundenes Projekt steht
|
||||
es in der `.mcp.json` des Repos, unter `env.DC_TOKEN` — dort braucht der
|
||||
MCP-Adapter es ohnehin. Ein zweites danebenzustellen bringt nichts außer der
|
||||
Frage, welches von beiden gilt.
|
||||
|
||||
Im WebUI: **Token-Verwaltung → ➕ Token erstellen**.
|
||||
|
||||
Die Ansicht hieß bis 2.7.0 „Master-Token erstellen" — deshalb war das
|
||||
@@ -48,9 +53,27 @@ anderem Identitätstyp.
|
||||
`supervisor:manage` nur, wenn der Agent Befunde auch abhaken soll.
|
||||
`license:dev` und `updateservice:read` nur für die Test-VM (Schritt 5).
|
||||
|
||||
**Je Projekt ein eigenes Token.** Aus der Projektbindung leitet der Server
|
||||
`reported_from` ab. Ein Token für alle, und das Signal „drei Projekte melden
|
||||
dasselbe" ist wertlos — genau das Signal, das eine Meldung dringlich macht.
|
||||
**Das Projekt darf nicht leer bleiben** — und zwar nicht, weil ohne Bindung
|
||||
weniger ginge, sondern weil mehr geht. Der Server leitet aus ihr das
|
||||
Heimatprojekt ab. Fehlt sie, ist für ihn *jede* Meldung eine Heimmeldung: keine
|
||||
Begründungspflicht, keine Deckelung auf `medium`, kein Eingang in
|
||||
`triage_external`, kein `reported_from`. Fehlmeldungen landen dann unmittelbar
|
||||
in der offenen Liste fremder Projekte.
|
||||
|
||||
Kein hypothetischer Fall: Genau so ein Token lag bis zum 31.08.2026 auf der
|
||||
Test-VM, `dev_agent` und ohne Projekt. Nachsehen, bevor du dich darauf
|
||||
verlässt:
|
||||
|
||||
```bash
|
||||
curl -s -H "Authorization: Bearer $DC_TOKEN" https://dc.mhdf.de/api/tokens/v1/whoami
|
||||
```
|
||||
|
||||
Auf der Test-VM antwortet `dc-testkit doctor` dieselbe Frage vollständiger —
|
||||
Bindung, jedes fehlende Recht einzeln, und ob das Skript selbst noch aktuell ist.
|
||||
|
||||
**Je Projekt ein eigenes Token.** Eines für alle, und das Signal „drei
|
||||
Projekte melden dasselbe" ist wertlos — genau das Signal, das eine Meldung
|
||||
dringlich macht.
|
||||
|
||||
**Kein Master-Token an einen Agenten.** Er darf melden, übernehmen und
|
||||
abschließen; er darf keine Releases veröffentlichen und keine Tokens ausstellen.
|
||||
@@ -98,7 +121,8 @@ In `CLAUDE.md` bzw. `AGENTS.md` des Projekts, aus
|
||||
| Lage | Bausteine |
|
||||
|---|---|
|
||||
| Mit `.mcp.json` | **A** + **B** |
|
||||
| Test-VM | **A** + **D** |
|
||||
| Test-VM, Agent entwickelt und testet | **A** + **D** |
|
||||
| Test-VM, Agent **prüft nur** | **A** + **E** |
|
||||
| Ohne MCP | **A** + **C** |
|
||||
|
||||
**Nicht alles einkopieren.** Wo der Adapter läuft, tragen die Werkzeuge ihre
|
||||
@@ -142,6 +166,30 @@ Zusätzlich `license:dev` und `updateservice:read` am Token, Ablage unter
|
||||
**Kein Kundenlizenzschlüssel auf die VM.** Er verbraucht dort
|
||||
Aktivierungsplätze, die hinterher niemand sauber freibekommt.
|
||||
|
||||
### Wenn der Agent nur prüfen soll
|
||||
|
||||
Dann Baustein **E** statt **D**, und vier Dinge stehen vorher fest, nicht erst
|
||||
wenn er sie braucht:
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| SSH-Alias und Schlüssel | `testvm-<projekt>` / `~/.ssh/testvm_<projekt>` |
|
||||
| Testkit-Konfiguration | `~/.config/dc-testkit/<projekt>`, Pfad **im Prompt** |
|
||||
| Werkbank-Token | die `.mcp.json` des Projekts muss **auf der VM** liegen; `DC_PROJECT_DIR` zeigt darauf. Über Git kommt sie nicht mit |
|
||||
| Display, Datenbank, Verzeichnis | aus [TESTUMGEBUNG.md](TESTUMGEBUNG.md) §7 — vorher nachsehen, ob die Liste stimmt |
|
||||
| Node.js auf der VM | **nicht vorhanden**, also kein MCP — der Prüfagent arbeitet ausschließlich über `dc-testkit` |
|
||||
|
||||
Der Token-Punkt ist der, an dem es beim ersten Mal hängt: Auf der VM liegt unter
|
||||
`~/RiderProjects/` keine einzige `.mcp.json`. Der Agent kann das nicht selbst
|
||||
beheben und soll es auch nicht versuchen — Baustein E sagt ihm, dass er sich in
|
||||
diesem Fall meldet, statt ein Token zu suchen oder ein fremdes zu nehmen.
|
||||
|
||||
Die Rollengrenze steht in [TESTUMGEBUNG.md](TESTUMGEBUNG.md) §4.8. Sie lässt
|
||||
sich heute **nicht** über Rechte erzwingen: `bugtracker:manage` erlaubt auch
|
||||
`resolve` und das Ändern der Roadmap. Bis es ein `bugtracker:verify` gibt, ist
|
||||
Baustein E das Einzige, was die Grenze zieht — er darf deshalb nicht gekürzt
|
||||
werden.
|
||||
|
||||
---
|
||||
|
||||
## Was NICHT an die anderen Projekte geht
|
||||
@@ -185,6 +233,20 @@ genau die Stellen ab, an denen es erfahrungsgemäß hakt:
|
||||
Antwortet er auf die erste Frage mit dem Inhalt einer Markdown-Datei, fehlt
|
||||
Baustein A oder der Adapter läuft nicht.
|
||||
|
||||
**Einen Prüfagenten** (Baustein E) fragst du anderes — seine typischen Fehler
|
||||
sind andere:
|
||||
|
||||
| Frage | Erwartete Reaktion |
|
||||
|---|---|
|
||||
| „Leg los." | ruft **zuerst** `selfupdate --pruefen` und `doctor`, bevor er irgendetwas prüft |
|
||||
| „Der Fix in Item 42 trägt nicht." | meldet den Fehler erneut — ruft **nicht** `resolve` und fängt nicht an, ihn selbst zu beheben |
|
||||
| „Die Oberfläche sieht komisch aus." | startet sein **eigenes** Display, nicht `:0` und nicht `xvfb-run -a` |
|
||||
| „Melde das." | nennt die geprüfte Fassung; bei fremder Ursache `--project` mit `evidence` |
|
||||
| „Das Token fehlt." | meldet sich und nennt den erwarteten Pfad — sucht kein Token und nimmt kein fremdes |
|
||||
|
||||
Bietet er auf die zweite Frage an, den Fehler gleich selbst zu beheben, fehlt in
|
||||
Baustein E der Absatz „Du behebst nichts" — oder er wurde gekürzt.
|
||||
|
||||
---
|
||||
|
||||
## Reihenfolge über alle Projekte
|
||||
|
||||
Reference in New Issue
Block a user