Richard/Deploymentcenter
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source 
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
2026-08-31 10:46:34 +02:00
co-authored by Claude Opus 5
parent b4450c5f63
commit 60731c5104
5 changed files with 1396 additions and 60 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/TESTUMGEBUNG.md
+353 -25
View File
@@ -1,6 +1,6 @@
# Linux-Testumgebung — Anleitung für Agenten
**Stand: 28.08.2026** · Gilt projektübergreifend für alle Agenten und Entwickler, die auf der
**Stand: 31.08.2026** · Gilt projektübergreifend für alle Agenten und Entwickler, die auf der
geteilten Test-VM arbeiten.
> **Diese Datei ist die maßgebliche Fassung.** Sie liegt im Deploymentcenter-Repo unter
@@ -8,6 +8,15 @@ geteilten Test-VM arbeiten.
> den Projektrepos zeigen hierher. Wer etwas an der Umgebung ändert, ändert es **hier** und
> kopiert danach auf die VM — nicht umgekehrt.
>
> **Das ist zweimal unterblieben**, zuletzt am 31.08.2026 bemerkt: Auf der Maschine lag noch der
> Stand vom 26.08. — ohne das gesamte Testkit-Kapitel und mit verschobenen Abschnittsnummern, so
> dass der Verweis „§4.6, Fremdmeldungen" dort bei „Erhöhte Rechte" landete. Wer die Datei hier
> ändert, kopiert sie **im selben Arbeitsgang**:
>
> ```bash
> scp docs/TESTUMGEBUNG.md testvm-<projekt>:~/TESTUMGEBUNG.md
> ```
>
> **Bewusst nicht unter `public/`:** Diese Datei nennt eine interne Adresse, einen Benutzernamen
> und den Weg, `sudo` zeitweise freizuschalten. `/docs/` auf dem Deploymentcenter ist öffentlich
> erreichbar; dort gehört das nicht hin. Das Testkit-Skript dagegen schon — es enthält nichts
@@ -61,7 +70,7 @@ mkdir -p ~/.ssh && chmod 700 ~/.ssh && echo '<INHALT DER .pub-DATEI>' >> ~/.ssh/
### 2.3 SSH-Konfiguration (auf dem eigenen Rechner)
```
Host testvm
Host testvm-<projekt>
HostName 192.168.40.48
User richard
IdentityFile ~/.ssh/testvm_<projekt>
@@ -70,11 +79,21 @@ Host testvm
ServerAliveCountMax 4
```
**Der Aliasname trägt das Projekt.** Ein Agent hat genau einen Namen, unter dem er die Maschine
erreicht, und dieser Name sagt, mit welchem Schlüssel er das tut. Ein gemeinsamer Alias `testvm`
für alle wäre bequemer und macht die Trennung aus 2.1 wieder zunichte: Der Schlüssel wird dann
nach Zufall gewählt, und ein Entzug trifft entweder niemanden oder alle.
⚠️ **Kein `ControlMaster`/`ControlPath` eintragen, wenn der Client unter Windows läuft** —
Windows-OpenSSH unterstützt Verbindungs-Multiplexing nicht und scheitert mit
„Failed to connect to new control master". Stattdessen mehrere Prüfschritte pro Aufruf bündeln.
Test: `ssh testvm "hostname"`
Test: `ssh testvm-<projekt> "hostname"`
> **Bestand (31.08.2026):** Auf dem Arbeitsplatz existiert bisher nur `polytrader-vm` mit
> `~/.ssh/polytrader_vm` — ein Schlüssel, den alle Projekte mitbenutzen. Wer den nächsten Agenten
> aufsetzt, legt für ihn einen eigenen an und benennt bei der Gelegenheit den alten Eintrag nach
> `testvm-polytrader` um. Bis dahin schlagen die Beispiele in dieser Datei wörtlich fehl.
---
@@ -92,7 +111,7 @@ Test: `ssh testvm "hostname"`
| JetBrains Rider | vorhanden | |
| Docker | **nicht** installiert | |
| Node.js | **nicht** installiert | |
| jq | **nicht** installiert | Wird auch nicht gebraucht — das Testkit liest JSON mit `python3` |
| jq | vorhanden (nachträglich) | Das Testkit benutzt es **nicht** — es liest JSON mit `python3`, damit es auch auf einer Maschine ohne jq läuft |
**Nicht vorhandene Werkzeuge dürfen installiert werden** — aber bitte in der Belegungsliste
(Abschnitt 7) vermerken, damit andere wissen, was sich geändert hat.
@@ -116,8 +135,23 @@ der im WebUI etwas anklickt.
### 4.1 Einmal einrichten
Das Skript liegt im Deploymentcenter-Repo unter `public/testkit/dc-testkit.sh` und wird mit
`deploy.py` ins Webroot ausgeliefert. Auf der VM:
**Der Agent läuft nicht auf der VM, sondern auf dem Arbeitsplatz.** Claude Code blockiert die
Maschine bis zum Neustart (siehe 9) — deshalb arbeitet er über SSH von außen. Daraus folgt die
Aufteilung:
| Was | Wo | Warum dort |
|---|---|---|
| `dc-testkit` | **auf der VM**, `~/bin/dc-testkit` | Dort läuft der Test: Sandkasten, Update-Agent, Display |
| `dc-testkit-remote` | **auf dem Arbeitsplatz** | Dort sitzt der Agent |
| Konfiguration | **auf dem Arbeitsplatz**, `~/.config/dc-testkit/<projekt>` | Dort liegen auch die Projekt-Repos — und damit die Token (4.2) |
| Werkbank-Token | **auf dem Arbeitsplatz**, in der `.mcp.json` des Repos | Es muss nirgends sonst hin |
**Auf der VM liegt keine Konfiguration.** `dc-testkit-remote` setzt `DC_TESTKIT_CONFIG` bewusst
ins Leere: Sonst gälte drüben, was irgendwann einmal jemand eingetragen hat. Genau daran ist es
gescheitert — dort lag ein altes Laufzeit-Token, während das richtige Werkbank-Token des Projekts
längst ein anderes war, und `doctor` meldete trotzdem „Bereit".
**Auf der VM** (einmal je Maschine):
```bash
mkdir -p ~/bin
@@ -125,6 +159,45 @@ curl -fsSL https://dc.mhdf.de/testkit/dc-testkit.sh -o ~/bin/dc-testkit
chmod +x ~/bin/dc-testkit
```
**Auf dem Arbeitsplatz** (einmal je Arbeitsplatz):
```bash
mkdir -p ~/bin
curl -fsSL https://dc.mhdf.de/testkit/dc-testkit-remote.sh -o ~/bin/dc-testkit-remote
chmod +x ~/bin/dc-testkit-remote
```
Danach läuft jeder Aufruf über den Wrapper — mit dem Projekt-Slug als erstem Argument:
```bash
dc-testkit-remote polytrader doctor
dc-testkit-remote polytrader run
dc-testkit-remote polytrader --skript pruefplan.sh
```
**Warum ein Wrapper und nicht `ssh` von Hand?** Aus demselben Grund, aus dem es `dc-testkit`
überhaupt gibt: Sonst baut jeder Agent seine eigene Fassung derselben SSH-Zeile. Vier Dinge gehen
dabei zuverlässig schief:
1. **Das Token stünde in `ps aux`.** `ssh vm 'DC_TOKEN=xyz dc-testkit run'` legt es offen — der
Befehlsstring **ist** die Befehlszeile der entfernten Shell, und auf einer geteilten Maschine
liest jeder andere Benutzer fremde Befehlszeilen. Der Wrapper schickt es über die
Standardeingabe; von dort geht es direkt in die Umgebung, und die liest nur, wem der Prozess
gehört.
2. **`~/bin` liegt über SSH nicht im PATH.** `~/.profile` nimmt es auf, wird aber nur von einer
**Login-Shell** gelesen — und `ssh vm 'befehl'` startet keine. Die Antwort wäre
`Kommando nicht gefunden`: sieht aus wie ein fehlgeschlagener Bezug und ist keiner. Der
Wrapper ruft `bash -l`.
3. **Quoting durch drei Ebenen.** Ein `--title "Update bricht ab"` muss durch lokale Shell, SSH
und entfernte Shell. Ohne Sorgfalt kommt der Titel dort zerlegt an und die Meldung trägt den
halben Text. Der Wrapper schickt den Befehl über die Standardeingabe, nicht durch das Quoting.
4. **Kein Verbindungs-Multiplexing unter Windows.** Jeder Aufruf kostet einen vollen Aufbau durch
den Tunnel; `--skript` bündelt einen ganzen Prüfplan in einen.
> ⚠️ **Was `dc-testkit-remote` nicht kann:** alles, was einen Bildschirminhalt zurückbringt.
> Aufnahmen entstehen mit `shot` auf der VM unter `/tmp/<projekt>_<name>.png` und werden danach
> abgeholt — dafür bleibt `scp` der Weg (5.8).
> ⚠️ **Beides — dieser Download und `dc-testkit license` — setzt Deploymentcenter 2.6.1 voraus.**
> Ist die Fassung auf dem Server älter, fehlt der Endpunkt `/api/license/v1/dev-key`. Er fällt
> dabei **nicht** mit 404 auf: Die Lizenz-API antwortet bei unbekannten Pfadsegmenten mit ihrer
@@ -136,10 +209,30 @@ chmod +x ~/bin/dc-testkit
> der Fassung: Im Webroot lag die Datei nur unter `/public/testkit/`, die Route auf `/testkit/`
> fehlte in der `.htaccess`. Wer vor 2.7.1 ein 404 sah, hat deshalb nicht unbedingt einen zu alten
> Server vor sich. Ausweichweg für alte Stände:
> `scp public/testkit/dc-testkit.sh testvm:~/bin/dc-testkit`
> `scp public/testkit/dc-testkit.sh testvm-<projekt>:~/bin/dc-testkit`
> — und für den Arbeitsplatz `cp public/testkit/dc-testkit-remote.sh ~/bin/dc-testkit-remote`.
Dann je Projekt eine Konfiguration — **das Token gehört in die Datei, nicht in die Befehlszeile**,
sonst steht es in der Shell-History:
Dann je Projekt eine Konfiguration. **Der bessere Weg ist `DC_PROJECT_DIR`** — dann steht das
Token nur an einer Stelle, in der `.mcp.json` des Projekts (4.2):
```bash
mkdir -p ~/.config/dc-testkit
cat > ~/.config/dc-testkit/polytrader <<'EOF'
DC_REMOTE=testvm-polytrader
DC_PROJECT=polytrader
DC_PROJECT_DIR=J:/Softwareprojekte/PolytraderSharp/PolyTraderSharp
DC_CHANNEL=prod
DC_DISPLAY=:99
EOF
chmod 600 ~/.config/dc-testkit/polytrader
```
`DC_PROJECT_DIR` ist der Pfad **auf dem Arbeitsplatz** — dort liegt das Repo mit der `.mcp.json`.
Was in den Projektverzeichnissen auf der VM liegt, spielt keine Rolle; der Agent arbeitet nie
von dort aus.
Wo es kein Projekt-Repo gibt, kommt das Token in die Datei — **nie in die Befehlszeile**, sonst
steht es in der Shell-History:
```bash
mkdir -p ~/.config/dc-testkit
@@ -155,28 +248,136 @@ chmod 600 ~/.config/dc-testkit/config
Arbeitet ein Agent an mehreren Projekten, hält er je Projekt eine eigene Datei und wählt sie über
`DC_TESTKIT_CONFIG=~/.config/dc-testkit/polytrader dc-testkit …`.
**Ein Testagent gehört zu genau einem Projekt** (siehe 4.8). Bei ihm steht der Pfad fest in seinem
Prompt und nicht in seinem Gedächtnis — wer die Datei vergisst, prüft stillschweigend das falsche
Projekt und meldet dorthin.
Was in der Datei stehen darf:
| Schlüssel | Bedeutung | Vorgabe |
|---|---|---|
| `DC_URL` | Instanz, gegen die gearbeitet wird | `https://dc.mhdf.de` |
| `DC_TOKEN` | Werkbank-Token des Projekts (4.2) | — |
| `DC_PROJECT_DIR` | Projekt-Repo; ohne `DC_TOKEN` wird es aus dessen `.mcp.json` gelesen | — |
| `DC_PROJECT` | Slug des Projekts | — |
| `DC_CHANNEL` | Release-Kanal | `prod` |
| `DC_INSTANCE` | Maschinenkennung, an der der DEV-Schlüssel hängt | Kurzname des Rechners |
| `DC_DISPLAY` | Virtuelles Display dieses Projekts (5.5, 5.8) | — (dann keine Oberflächenprüfung) |
`DC_INSTANCE` nur setzen, wenn mehrere Testläufe auf **derselben** Maschine auseinandergehalten
werden müssen. Sie muss über Läufe hinweg gleich bleiben: Wechselt sie, sucht der Server jedes Mal
einen anderen Schlüssel heraus, bis die Grenze von zwölf je Projekt greift.
**Rangfolge:** Schalter auf der Befehlszeile schlägt Umgebungsvariable schlägt Datei schlägt
Vorgabe. Bis 1.1.0 war das genau verkehrt herum — die Datei überschrieb die Umgebung, und
`DC_PROJECT=x dc-testkit report` meldete stillschweigend in das Projekt aus der Datei. Auf einer
Maschine mit mehreren Projekten ist das die teuerste Sorte Fehler: Es geht nichts kaputt, es landet
nur alles am falschen Ort.
Prüfen, ob alles steht:
```bash
dc-testkit doctor
```
`doctor` ist die einzige Auskunft, der zu trauen ist — aber nur, wenn er selbst aktuell ist. Er
prüft deshalb seit 1.1.0 als Erstes den eigenen Stand gegen die ausgelieferte Fassung:
```bash
dc-testkit selfupdate # auf die ausgelieferte Fassung bringen
dc-testkit selfupdate --pruefen # nur nachsehen, nichts ändern
```
> **Warum das gebraucht wurde.** Das Skript liegt auf jeder Maschine als Kopie und altert dort
> still. Am 31.08.2026 lag auf der Test-VM eine Fassung, die 236 Zeilen älter war als die
> ausgelieferte — beide meldeten `1.0.0`. Deshalb sagte `doctor` dort „Bereit", während die
> aktuelle Fassung drei fehlende Rechte des Tokens angemeckert hätte. **Die Fassungsnummer wird
> bei jeder Änderung hochgezählt**; ohne das ist die Selbstprüfung wertlos. Sie sagt das auch:
> gleiche Nummer bei anderem Inhalt ist ein Befund, kein Achselzucken.
>
> Ist die eigene Fassung **neuer** als die ausgelieferte, meldet `doctor` einen Entwicklungsstand
> und rät ausdrücklich **nicht** zum `selfupdate` — das holte die ältere Fassung zurück.
> `selfupdate` verweigert diesen Rückschritt von sich aus; `--force` hebt die Sperre auf.
### 4.2 Das Werkbank-Token
Ein Mensch legt es **einmal je Projekt** an — im WebUI unter *System → Tokens*:
**Es existiert wahrscheinlich schon.** Jedes angebundene Projekt hat eines — es steht in der
`.mcp.json` des Projekt-Repos, wo der MCP-Adapter es ohnehin braucht:
```json
{ "mcpServers": { "deploymentcenter": { "env": { "DC_TOKEN": "dc_master_…" } } } }
```
Das Testkit holt es sich von dort. Dazu zeigt `DC_PROJECT_DIR` auf das Repo — gesucht wird im
Verzeichnis selbst und eine Ebene tiefer:
```bash
DC_PROJECT_DIR=~/RiderProjects/PolyTraderSharp
```
Damit gibt es das Geheimnis **einmal je Projekt**, nicht zusätzlich in
`~/.config/dc-testkit/config`. Zwei Ablagen desselben Tokens heißt: Beim nächsten Wechsel wird
eine davon vergessen. Genau so war es auf der Test-VM — dort lag in der Testkit-Konfiguration
noch ein altes Laufzeit-Token (`watchdog:ping`, `bugtracker:report`, ohne Bindung), während das
richtige Werkbank-Token des Projekts längst ein anderes war. `doctor` meldete trotzdem „Bereit",
und die Rechte fehlten erst dort, wo sie gebraucht wurden.
> **`.mcp.json` kommt über Git nicht mit.** Sie ist per `.gitignore` ausgeschlossen — auf einer
> frisch geklonten Maschine fehlt sie deshalb **immer**. Das ist kein Fehler im Repo und keiner
> in den Rechten. Das Token muss von Hand dorthin, aus der `.mcp.json` des Projekts auf dem
> Arbeitsplatz. `dc-testkit` sagt genau das, statt an einem 401 zu scheitern:
>
> ```
> Fehler Kein Werkbank-Token.
>
> In ~/RiderProjects/PolyTraderSharp liegt keine .mcp.json mit einem DC_TOKEN.
>
> Das ist kein Fehler im Repo: .mcp.json ist per .gitignore ausgeschlossen
> und wird ueber Git NICHT mitgeliefert.
> ```
>
> Ein Platzhalter (`"${DC_TOKEN}"`) zählt dabei nicht als Token — sonst liefe der Aufruf mit
> einer Zeichenkette los, die der Server nur mit 401 beantworten kann.
**Wenn wirklich keines existiert**, legt ein Mensch es an — im WebUI unter
*Token-Verwaltung → ➕ Token erstellen*:
| Feld | Wert |
|---|---|
| Typ | Master |
| Besitzerart | `dev_agent` |
| Projekt | der Slug des Projekts |
| Projekt | der Slug des Projekts — **nicht leer** |
| Rechte | `bugtracker:manage`, `license:dev`, `updateservice:read` |
Mehr braucht es nicht, und mehr sollte es nicht sein. `bugtracker:manage` schließt Lesen und
Melden ein, `license:dev` schließt `updateservice:read` ein — zwei Häkchen genügen also.
`bugtracker:manage` schließt Lesen und Melden ein, `license:dev` schließt `updateservice:read`
ein — zwei Häkchen genügen also.
**Nicht `*` vergeben.** Ein Token mit allen Rechten auf einer geteilten Testmaschine darf auch
Releases veröffentlichen und Lizenzen fremder Projekte anfassen.
#### Warum die Projektbindung nicht optional ist
**Ein Token je Projekt, gebunden an dieses Projekt.** Ein „allgemeines Token für die ganze VM"
klingt praktischer und ist es nicht — aus zwei Gründen, die in verschiedene Richtungen wirken:
**Es reicht nicht weit genug.** Ein Testlauf prüft die Auslieferung *eines Produkts*: dessen
Release aus der Ablage, dessen Lizenzschlüssel, dessen Update. Beim Ausstellen des
DEV-Schlüssels prüft der Server die Bindung ausdrücklich und lässt hier **keine** Ausnahme für
Werkbank-Token zu. Ein an `deploymentcenter` gebundenes Token bekommt für `polytrader` ein
`403 project_forbidden` — ein Lizenzschlüssel öffnet die Release-Ablage eines Produkts, und das
ist etwas anderes als eine Meldung.
**Und es reicht zu weit.** Ein Token **ohne** Bindung ist nicht etwa eingeschränkt, sondern
uneingeschränkt: Der Server leitet daraus kein Heimatprojekt ab, also ist für ihn *jede* Meldung
eine Heimmeldung. Damit fällt der gesamte Schutz für Fremdmeldungen weg — keine
Begründungspflicht, keine Deckelung auf `medium`, kein Eingang in `triage_external`, kein
`reported_from`. Meldungen landen unmittelbar in der offenen Liste fremder Projekte und
verderben die Zahlen, auf denen die Supervisor-Detektoren kalibrieren.
Die bezeugte Herkunft ist der Punkt: Melden drei Projekte dasselbe, ist das eine Aussage über
die Sache. Ohne Bindung ist es eine Aussage über niemanden.
**Zu `*`:** Die vorhandenen Projekt-Token tragen durchweg Vollzugriff. Das läuft, deckt die drei
gebrauchten Rechte ab — und erlaubt auf einer **geteilten** Maschine eben auch
`updateservice:publish`. Ein Release aus einem Testlauf heraus wäre für Kunden sofort sichtbar.
Wer die Token neu ausstellt, schneidet sie auf die drei Rechte zu.
### 4.3 DEV-Lizenzschlüssel selbst holen
@@ -220,6 +421,18 @@ dc-testkit update # Update auf latest
dc-testkit verify
```
Drei weitere Aufrufe reichen den jeweiligen Modus des `update-agent` durch. Sie verändern den
Sandkasten nicht — außer `repair`, der genau dafür da ist:
| Aufruf | Wofür |
|---|---|
| `dc-testkit check` | Gibt es überhaupt ein Update? Antwortet, ohne etwas zu holen |
| `dc-testkit list` | Welche Fassungen führt der Server in diesem Kanal? |
| `dc-testkit repair` | Integritätsreparatur — stellt her, was im Sandkasten fehlt oder nicht zur Prüfsumme passt |
`repair` gehört in einen Prüfplan, weil es der Weg ist, den ein Kunde nach einem abgebrochenen
Update nimmt. Ein Modus, den niemand testet, ist im Ernstfall genau der, der nicht funktioniert.
Oder alles auf einmal, mit automatischer Meldung dessen, was scheitert:
```bash
@@ -497,6 +710,39 @@ und das Schreiben der Konfiguration bleiben ungeprüft. Ein kopfloser Installati
(`--action install --answers antworten.json`) würde diese Lücke schließen; er steht in der
[Roadmap](./ROADMAP.md) unter G1.
### 4.8 Ein Agent, der nur prüft
Ein **Prüfagent** ist etwas anderes als ein Entwickleragent, der nebenbei testet. Er gehört zu
genau einem Projekt, läuft auf dieser Maschine — und **behebt nichts**.
Der Unterschied ist keine Geschmacksfrage. Wer einen Fix schreibt und ihn anschließend selbst
abnimmt, prüft gegen die Erwartung, die er beim Schreiben hatte. Genau dagegen ist der Tracker
gebaut: `resolve` behauptet „ich habe es behoben, in Build X"; `confirm` behauptet nichts, sondern
bestätigt den Fix eines anderen (siehe 4.5, „Der Lebenslauf").
| Der Prüfagent tut | Er tut **nicht** |
|---|---|
| Auslieferung und Update gegen den Sandkasten prüfen (4.4) | Code des Projekts ändern |
| Oberflächen begutachten (5.8) | `dc-testkit resolve` aufrufen |
| Befunde melden — auch in fremden Projekten (4.5, 4.6) | Die Roadmap ändern |
| Prüfaufträge übernehmen und mit `confirm` oder erneuter Meldung schließen | Ein Item beheben, das er selbst gemeldet hat |
**Diese Trennung erzwingt derzeit kein Recht.** `bugtracker:manage` ist ein einziger Schreib-Scope:
Wer bestätigen darf, darf auch `resolve`, `bulk_update` und die Roadmap umschreiben. Bis es ein
eigenes `bugtracker:verify` gibt, steht die Grenze **nur im Prompt des Agenten** — und gehört
deshalb dort ausdrücklich hinein. Der fertige Textbaustein dafür ist **E** in
[AGENT_PROMPT_TEMPLATE.md](AGENT_PROMPT_TEMPLATE.md).
**Gegen welche Fassung?** Jede Meldung trägt die geprüfte Fassung mit, gelesen aus der
`manifest.json` im Sandkasten. Ohne sie kann der Server nicht unterscheiden, ob ein Befund neu ist
oder ob die Maschine schlicht einen älteren Stand fährt — und legt im Zweifel ein Regressionsitem
an (4.5). Für einen Agenten, der nichts anderes tut als prüfen, ist das die wichtigste einzelne
Angabe überhaupt.
**Was ihn einrichtet**, steht in [AGENTEN_ANBINDEN.md](AGENTEN_ANBINDEN.md); die Reihenfolge ist
dort dieselbe wie für jeden anderen Agenten, nur mit anderem Prompt-Baustein und anderer
Abnahmefrage.
---
## 5. Konventionen für mehrere Projekte
@@ -619,6 +865,11 @@ sudo rm /etc/sudoers.d/99-testing
Das hebt den Schutz für das Konto vollständig auf — vertretbar auf einer Test-VM hinter VPN, aber
nicht dauerhaft und niemals auf einer Produktivmaschine.
> **Stand 31.08.2026: `/etc/sudoers.d/99-testing` liegt dort und gilt.** Aus „befristet" ist
> „dauerhaft" geworden — der Weg, den solche Freigaben immer nehmen, wenn das Entfernen nicht
> zum selben Arbeitsgang gehört. Wer als Nächstes etwas mit `sudo` erledigt, nimmt sie danach
> zurück. Ein Prüfagent braucht sie nicht.
**Für das Testkit wird das nicht gebraucht.** Es arbeitet vollständig im Benutzerkontext.
### 5.7 GUI-Anwendungen ohne Bildschirm testen
@@ -642,7 +893,28 @@ Bildschirmfotos schicken. Das Verfahren hat sich am 26.08.2026 bewährt und **si
zutage gefördert**, darunter einen, der sämtliche Tabellen der Anwendung unsichtbar machte.
Drei Werkzeuge, alle installiert: **Xvfb** (virtuelles Display), **xdotool** (Klicken und Tippen),
**ImageMagick** (`import` für Aufnahmen, `convert` zum Zuschneiden).
**ImageMagick** (`import` für Aufnahmen, `convert` zum Zuschneiden). `dc-testkit doctor` sagt seit
1.1.0, ob sie da sind und ob das eigene Display frei ist.
**Den immer gleichen Teil nimmt das Testkit ab** — Display starten, aufnehmen, abräumen. Setze
dazu `DC_DISPLAY` in deiner Konfiguration (die Nummer steht in Abschnitt 7):
```bash
dc-testkit display status # frei, belegt oder verwaister Socket?
dc-testkit display start # Xvfb auf DC_DISPLAY, Vorgabe 1600x1000x24
dc-testkit shot 1_start # nach /tmp/<projekt>_1_start.png
dc-testkit display stop # nur das eigene, nie fremde
```
Das sind genau die drei Stellen, an denen ein selbstgeschriebenes Skript regelmäßig danebengreift:
`DISPLAY` nicht gesetzt (dann landet alles auf `:0`, dem echten Desktop), `pkill Xvfb` ohne Nummer
(das erschlägt die Sitzungen aller anderen Projekte), Dateinamen ohne Projektpräfix (zwei Läufe
überschreiben sich gegenseitig). `display start` verweigert `:0` und `:1` von sich aus und erkennt
einen verwaisten Socket, statt an ihm zu scheitern.
**Was projektspezifisch bleibt**, ist der Klickplan dazwischen — Fenstername, Koordinaten,
Wartezeiten. Den kapselt das Testkit bewusst nicht: Er ist bei jedem Programm anders, und ein
Werkzeug, das ihn zu erraten versucht, wäre unzuverlässiger als das Rezept unten.
Anders als `xvfb-run` wird das Display hier **dauerhaft** gestartet, damit sich zwischen den
Aufnahmen navigieren lässt:
@@ -681,7 +953,7 @@ kill $APP 2>/dev/null; sleep 2; pkill -f "Xvfb $DISP" 2>/dev/null
Danach die Bilder abholen und ansehen:
```bash
scp testvm:'/tmp/polytrader_*.png' .
scp testvm-polytrader:'/tmp/polytrader_*.png' .
```
**Was sich dabei bewährt hat:**
@@ -730,11 +1002,20 @@ nutzen, Port 3389 ist offen) — nötig ist es für die Sichtprüfung nicht.
## 7. Belegung (bei Änderungen fortschreiben)
**Erhoben am 31.08.2026 von der Maschine selbst**, nicht aus dieser Datei fortgeschrieben — sie
war zu dem Zeitpunkt vier Projekte im Rückstand. Wer etwas anlegt, trägt es hier ein; wer sich
darauf verlassen will, prüft nach:
```bash
ssh testvm-<projekt> 'sudo mariadb -e "SHOW DATABASES;"; ls /opt ~; ss -tlnp; ls /tmp/.X11-unix/; pgrep -a Xvfb'
```
**Datenbanken**
| Datenbank | Benutzer | Projekt | seit |
|---|---|---|---|
| `polytrader_test` | `polytrader_test`@localhost | PolyTrader | 26.08.2026 |
| `ibkrtrader_test` | `ibkrtrader_test`@localhost | IBKRTrader | vor 31.08.2026 |
**Dienste**
@@ -742,41 +1023,81 @@ nutzen, Port 3389 ist offen) — nötig ist es für die Sichtprüfung nicht.
|---|---|---|---|---|
| `polytrader.service` | `polytrader` | `/opt/polytrader` | PolyTrader | 26.08.2026 |
Am 31.08.2026 lief keiner dieser Dienste — wie es Abschnitt 8 verlangt.
**Verzeichnisse**
| Projekt | Publish-Verzeichnis | Dienst |
|---|---|---|
| PolyTrader | `~/polytrader-test` | `/opt/polytrader` |
| IBKRTrader | `~/ibkrtrader-test` | — |
| ClawdDotNet | `~/clawddotnet-test` | — |
| Predictalytics | `~/predictalytics` ⚠️ | — |
⚠️ **`~/predictalytics` bricht die Konvention aus 5.2** (`~/<projekt>-test`). Aus dem Namen ist
nicht mehr abzulesen, ob dort ein Testlauf oder eine Arbeitskopie liegt — und genau diese Frage
stellt sich, wenn jemand aufräumt. Beim nächsten Anfassen umbenennen.
Quellbäume liegen daneben unter `~/RiderProjects/<Projekt>` (5.2): ClawdDotNet, Deploymentcenter,
IBKRTrader, PolyTraderSharp, Predictalytics.
**Werkbank-Token** (Vergabe siehe 4.2)
| Projekt | Token angelegt | Rechte |
|---|---|---|
| *noch keins* | | |
Die richtigen existieren längst — je Projekt eines, in der `.mcp.json` des Repos auf dem
Arbeitsplatz:
| Projekt | Token | Bindung | Rechte |
|---|---|---|---|
| PolyTrader | `DEV-Polytrader` | `polytrader` | `*` |
| IBKRTrader | `DEV-IBKRTrader` | `ibkrtrader` | `*` |
| Deploymentcenter | `DEV-Deploymentcenter` | `deploymentcenter` | `*` |
| ClawdDotNet | — | — | `.mcp.json` enthält nur den Platzhalter |
Alle sind `dev_agent` und korrekt gebunden. Zu `*` siehe die Anmerkung am Ende von 4.2.
⚠️ **Auf der VM kommt davon nichts an.** Unter `~/RiderProjects/` liegt keine einzige
`.mcp.json` — die Repos sind dort frisch geklont, und die Datei ist per `.gitignore`
ausgeschlossen. In `~/.config/dc-testkit/config` steckt stattdessen ein altes Sub-Token
(„PolyTrader Avalonia (Dev, alle Umgebungen)", `watchdog:ping` + `bugtracker:report`, ohne
Bindung). Damit sind `license`, `install`, `update`, `verify`, `run`, `next`, `comment`,
`resolve` und `confirm` gesperrt; übrig bleibt `report`.
**Zu beheben ist das nicht durch ein neues Token**, sondern indem das vorhandene
`DEV-Polytrader` auf die Maschine kommt — als `.mcp.json` im Projektverzeichnis, auf das dann
`DC_PROJECT_DIR` zeigt. `dc-testkit doctor` benennt seit 1.1.0 jeden dieser Punkte einzeln und
nennt die Herkunft des benutzten Tokens.
**X-Displays** (Vergabe siehe 5.5)
| Display | Projekt | Stand |
|---|---|---|
| `:0` | echter Desktop — **nie belegen** | |
| `:0`, `:1` | echter Desktop und Anmeldebildschirm — **nie belegen** | |
| `:99` | PolyTrader | 26.08.2026 |
| `:98` | Predictalytics | reserviert |
| `:97` | ClawdDotNet | reserviert |
| `:96` | IBKRTrader | reserviert |
| `:95` abwärts | frei für künftige Projekte | |
**Ports** (Stand 26.08.2026)
Am 31.08.2026 lief **kein** Xvfb; belegt waren nur `:0` und `:1`. Dass `:1` existiert, stand hier
bisher nicht — es gehört zum Anmeldebildschirm und ist genauso tabu wie `:0`.
**Ports** (Stand 31.08.2026)
| Port | Belegt durch |
|---|---|
| 22 | SSH |
| 53 | systemd-resolved (nur localhost) |
| 631 | CUPS (localhost, IPv4 **und** IPv6) |
| 3306 | MariaDB (nur localhost) |
| 3389 | RDP |
| 5000 | vorhandener Dienst (nur IPv6-localhost) |
| 631 | CUPS |
| 5000 | vorhandener Dienst (localhost, IPv4 **und** IPv6) |
Port 5000 war hier als „nur IPv6-localhost" geführt. Das stimmt nicht mehr — wer ihn für einen
Testdienst nehmen wollte, wäre auf beiden Familien kollidiert.
**Nachträglich installiert:** MariaDB 11.8.6, Xvfb, xdotool, ImageMagick, x11-utils
(alle am 26.08.2026 für PolyTrader).
(alle am 26.08.2026 für PolyTrader), jq (undatiert, von unbekannter Hand — das Testkit braucht
es nicht).
---
@@ -823,6 +1144,13 @@ Danach Abschnitt 7 nachziehen.
Neustart; mehrere Reparaturversuche waren erfolglos, es wird auf ein Update gewartet. Agenten
arbeiten deshalb **über SSH von außen**. (Speichermangel ist **nicht** die Ursache — die
Maschine hat 31 GB, davon 25 GB frei.)
**Für Prüfagenten ist das die bestimmende Einschränkung.** Ein Prüfagent je Projekt läuft
nicht *auf* der Maschine, sondern auf einem Arbeitsplatz und greift über `testvm-<projekt>`
zu. Daraus folgt zweierlei: Er kann `node` und damit den MCP-Adapter dort ohnehin nicht
benutzen (der ist auch nicht installiert), und er sollte mehrere Prüfschritte pro
SSH-Aufruf bündeln — Verbindungs-Multiplexing steht ihm unter Windows nicht zur Verfügung
(2.3).
- **Verbindungs-Multiplexing funktioniert nicht mit Windows-OpenSSH** (siehe 2.3).
- **Der Installationsdialog ist nicht kopflos prüfbar** (siehe 4.7). Damit bleiben die Auflösung
von `setup.json` und das Schreiben der Konfiguration ungeprüft.