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
|
||||
|
||||
@@ -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
|
||||
|
||||
+353
-25
@@ -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.
|
||||
|
||||
Reference in New Issue
Block a user