Deploymentcenter

49 Commits 1 Branch 0 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
Deploymentcenter BotandClaude Opus 5	60731c5104	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>	2026-08-31 10:46:34 +02:00
Deploymentcenter BotandClaude Opus 5	eeda6c911e	fix(tokens): Supervisor-Rechte im Formular, Vollzugriff nicht mehr vorangekreuzt Aufgefallen bei der Frage, wo man ein Werkbank-Token anlegt. Drei Befunde an derselben Stelle: 1. DIE SUPERVISOR-RECHTE FEHLTEN IM FORMULAR TokenManager::KNOWN_SCOPES kennt supervisor:read, :manage und :report seit 2.6.0 - die Ankreuzliste bot sie nie an. Ein Werkbank-Token liess sich ueber die Oberflaeche also gar nicht so ausstellen, wie die Anleitung es verlangt: dc_findings, dc_finding_summary und dc_metrics im MCP-Adapter waeren mit "unauthorized" gescheitert, und der Grund waere nirgends zu sehen gewesen. 2. "ALLE RECHTE" WAR DIE VORGABE Wer ein Agenten-Token anlegte und den Haken uebersah, gab damit alles heraus - Releases veroeffentlichen und Tokens ausstellen inbegriffen. Die gefaehrlichste Auswahl gehoert nicht in die Vorgabe. Vorangekreuzt ist jetzt "Bugtracker verwalten", also der dokumentierte Normalfall; der Vollzugriff traegt eine Warnung und muss ausdruecklich gewaehlt werden. 3. DIE ANSICHT HIESS "MASTER-TOKEN ERSTELLEN" Deshalb fand niemand das Werkbank-Token: Es entsteht an genau dieser Stelle, nur mit anderem Identitaetstyp. Der Name der Ansicht versprach etwas anderes, als sie kann - und widersprach der eigenen Regel "kein Master-Token an einen Agenten". Heisst jetzt "Token erstellen", mit einem Hinweiskasten fuer den Agentenfall. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-30 13:54:55 +02:00
Deploymentcenter BotandClaude Opus 5	93aabfece3	feat(agenten): Vorlage in vier Bausteine, Anbindungsanleitung, Tooltips (#75 ) VORLAGE ZERLEGT docs/AGENT_PROMPT_TEMPLATE.md war ein Block von 300 Zeilen, den jedes Projekt vollstaendig einkopierte - auch die, in denen der MCP-Adapter laeuft und die Werkzeuge ihre Beschreibung selbst mitbringen. Jetzt vier Bausteine: A Grundhaltung, gilt immer. Vier Regeln, kurz. B Mit MCP-Adapter: die Reihenfolge, die in keiner Werkzeugbeschreibung steht - erst nachsehen, dann uebernehmen, dann arbeiten. C Ohne MCP: der REST-Weg, vollstaendig. Nur wo kein Adapter laeuft. D Auf der Test-VM. Ein Projekt mit Adapter traegt damit eine halbe Seite statt zweihundert Zeilen, die das Modell nie liest und die auseinanderlaufen, sobald sich die Schnittstelle aendert. Loest #75 (vormals C4). NEU: docs/AGENTEN_ANBINDEN.md Was einmalig je Projekt zu tun ist - fuer den Menschen, nicht fuer den Agenten: Werkbank-Token, Adapter, welche Bausteine, Roadmap-Uebernahme, Test-VM. Dazu zwei Abschnitte, die sonst gefehlt haetten: - Was NICHT an die anderen Projekte geht: Testinstanz und tests/e2e gehoeren zum Deploymentcenter und werden nicht je Projekt nachgebaut. Uebernehmen laesst sich die Haltung dahinter - Befund bekommt Item UND Testfall, bekannte Befunde blockieren nicht, fehlende Voraussetzung heisst uebersprungen und nicht rot. - Vier Pruefragen an den Agenten nach der Einrichtung. Antwortet er auf "was steht als Naechstes an" mit dem Inhalt einer Markdown-Datei, fehlt Baustein A oder der Adapter laeuft nicht. WEBUI Die Spaltenkoepfe der Bereichsuebersicht waren Zeichen ohne Erklaerung - wer die Legende nicht gelesen hat, und das ist der Normalfall, riet was 🧊 heisst. Jetzt title= samt Fragezeichen-Zeiger und gepunkteter Linie, damit ueberhaupt erkennbar ist, dass da etwas zu holen ist. Auch Rang, Item, Ziel, Wer und Doku in der Vorhabenliste, und der Fortschritt mit dem Hinweis, warum Zurueckgestelltes und Verworfenes nicht in den Nenner zaehlt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-30 13:25:45 +02:00

Author

SHA1

Message

Date

Deploymentcenter BotandClaude Opus 5

60731c5104

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>

2026-08-31 10:46:34 +02:00

Deploymentcenter BotandClaude Opus 5

eeda6c911e

fix(tokens): Supervisor-Rechte im Formular, Vollzugriff nicht mehr vorangekreuzt

Aufgefallen bei der Frage, wo man ein Werkbank-Token anlegt. Drei Befunde an
derselben Stelle:

1. DIE SUPERVISOR-RECHTE FEHLTEN IM FORMULAR

   TokenManager::KNOWN_SCOPES kennt supervisor:read, :manage und :report seit
   2.6.0 - die Ankreuzliste bot sie nie an. Ein Werkbank-Token liess sich
   ueber die Oberflaeche also gar nicht so ausstellen, wie die Anleitung es
   verlangt: dc_findings, dc_finding_summary und dc_metrics im MCP-Adapter
   waeren mit "unauthorized" gescheitert, und der Grund waere nirgends zu
   sehen gewesen.

2. "ALLE RECHTE" WAR DIE VORGABE

   Wer ein Agenten-Token anlegte und den Haken uebersah, gab damit alles
   heraus - Releases veroeffentlichen und Tokens ausstellen inbegriffen. Die
   gefaehrlichste Auswahl gehoert nicht in die Vorgabe. Vorangekreuzt ist
   jetzt "Bugtracker verwalten", also der dokumentierte Normalfall; der
   Vollzugriff traegt eine Warnung und muss ausdruecklich gewaehlt werden.

3. DIE ANSICHT HIESS "MASTER-TOKEN ERSTELLEN"

   Deshalb fand niemand das Werkbank-Token: Es entsteht an genau dieser
   Stelle, nur mit anderem Identitaetstyp. Der Name der Ansicht versprach
   etwas anderes, als sie kann - und widersprach der eigenen Regel "kein
   Master-Token an einen Agenten". Heisst jetzt "Token erstellen", mit einem
   Hinweiskasten fuer den Agentenfall.

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

2026-08-30 13:54:55 +02:00

Deploymentcenter BotandClaude Opus 5

93aabfece3

feat(agenten): Vorlage in vier Bausteine, Anbindungsanleitung, Tooltips (#75 )

VORLAGE ZERLEGT

docs/AGENT_PROMPT_TEMPLATE.md war ein Block von 300 Zeilen, den jedes Projekt
vollstaendig einkopierte - auch die, in denen der MCP-Adapter laeuft und die
Werkzeuge ihre Beschreibung selbst mitbringen. Jetzt vier Bausteine:

  A  Grundhaltung, gilt immer. Vier Regeln, kurz.
  B  Mit MCP-Adapter: die Reihenfolge, die in keiner Werkzeugbeschreibung
     steht - erst nachsehen, dann uebernehmen, dann arbeiten.
  C  Ohne MCP: der REST-Weg, vollstaendig. Nur wo kein Adapter laeuft.
  D  Auf der Test-VM.

Ein Projekt mit Adapter traegt damit eine halbe Seite statt zweihundert Zeilen,
die das Modell nie liest und die auseinanderlaufen, sobald sich die
Schnittstelle aendert. Loest #75 (vormals C4).

NEU: docs/AGENTEN_ANBINDEN.md

Was einmalig je Projekt zu tun ist - fuer den Menschen, nicht fuer den Agenten:
Werkbank-Token, Adapter, welche Bausteine, Roadmap-Uebernahme, Test-VM. Dazu
zwei Abschnitte, die sonst gefehlt haetten:

  - Was NICHT an die anderen Projekte geht: Testinstanz und tests/e2e gehoeren
    zum Deploymentcenter und werden nicht je Projekt nachgebaut. Uebernehmen
    laesst sich die Haltung dahinter - Befund bekommt Item UND Testfall,
    bekannte Befunde blockieren nicht, fehlende Voraussetzung heisst
    uebersprungen und nicht rot.
  - Vier Pruefragen an den Agenten nach der Einrichtung. Antwortet er auf
    "was steht als Naechstes an" mit dem Inhalt einer Markdown-Datei, fehlt
    Baustein A oder der Adapter laeuft nicht.

WEBUI

Die Spaltenkoepfe der Bereichsuebersicht waren Zeichen ohne Erklaerung - wer
die Legende nicht gelesen hat, und das ist der Normalfall, riet was 🧊 heisst.
Jetzt title= samt Fragezeichen-Zeiger und gepunkteter Linie, damit ueberhaupt
erkennbar ist, dass da etwas zu holen ist. Auch Rang, Item, Ziel, Wer und Doku
in der Vorhabenliste, und der Fortschritt mit dem Hinweis, warum
Zurueckgestelltes und Verworfenes nicht in den Nenner zaehlt.

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

2026-08-30 13:25:45 +02:00