073d52ab7d382e2cbcca80ecb5b34ef9e04bbef4
4
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Deploymentcenter BotandClaude Opus 5
|
8274a6c0ac |
feat(2.8.0): Pruefen duerfen, ohne beheben zu duerfen
Der Unterschied zwischen "ich habe es behoben" und "der Fix eines anderen traegt" ist das Rueckgrat des Pruefverfahrens aus 2.6.1. Er stand bisher nur in der Anleitung - im Datenbestand und in den Rechten kam beides gleich an. RECHTE bugtracker:manage war ein einziger Schreib-Scope: Wer eine Nachpruefung bestaetigen durfte, durfte auch resolve, update, bulk_update und die Roadmap umschreiben. Fuer einen Pruefstand ist das zu viel - und wer einen Fix schreibt und ihn selbst abnimmt, prueft gegen die Erwartung, die er beim Schreiben hatte. bugtracker:verify deckt jetzt ab, was ein Pruefer braucht: next, claim, release, comment, confirm, report. Nicht mehr. manage schliesst es ein (IMPLIED_SCOPES), vorhandene Token verlieren nichts. "status" bleibt bewusst bei manage. Darueber liesse sich sonst jeder Zustand setzen, auch "resolved" - der Umweg um genau diese Trennung. DATENBESTAND Eine bestaetigte Nachpruefung war nicht von "jemand hat das Item zugemacht" zu unterscheiden: dc-testkit confirm setzte status=closed und schrieb den Rest in einen Kommentar. Damit war die eine Frage, fuer die das Verfahren gebaut ist, nicht beantwortbar - wurde dieses Item je gegen ein ausgeliefertes Paket geprueft? Ein Kommentartext laesst sich nicht zaehlen und nicht filtern. Migration 017 legt verified_at, verified_in_build und verified_by an. Kein eigener Status daneben: Ein bestaetigtes Item IST geschlossen, die Bestaetigung ist eine Eigenschaft dieses Abschlusses. Ein zweiter Wert waere dieselbe Falle, die 016 beim is_roadmap-Flag vermieden hat. verified_in_build steht neben resolved_in_build, weil beide verschiedene Fragen beantworten und auseinandergehen koennen - genau das ist der interessante Fall. Das eine ist die Behauptung des Behebenden, das andere die Beobachtung des Pruefenden. confirm laesst sich nur auf Items anwenden, die jemand als behoben ausgegeben hat (resolved, awaiting_verification, in_verification, fix_insufficient). Ein offenes Item zu "bestaetigen" waere ein Schliessen mit schmueckendem Beiwort - und stuende hinterher als geprueft in einer Statistik, die genau das misst. Antwort: 409 not_verifiable. MCP dc_confirm. Der Adapter hatte dc_next_task und dc_resolve, aber keinen Weg, eine Nachpruefung abzuschliessen; dc_comment kennt nur action_taken, keinen Status. Ein Pruefagent ueber MCP konnte einen Auftrag uebernehmen und dann nichts damit anfangen. 16 Werkzeuge statt 15. TESTKIT dc-testkit confirm nutzt die Aktion und schickt die gepruefte Fassung als Feld. Antwortet der Server mit 404, faellt es auf den alten Weg zurueck und sagt, dass die Fassung dann nur im Kommentar landet. Drei neue e2e-Faelle: dass confirm die gepruefte Fassung festhaelt, dass es nur dort geht, wo es etwas zu bestaetigen gibt, und dass ein verify-Token kommentieren, aber nicht beheben darf. 147 bestanden, 0 uebersprungen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
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> |
||
|
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> |
||
|
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>
|