Deploymentcenter BotandClaude Opus 5
8274a6c0ac
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>
62 lines
2.7 KiB
SQL
62 lines
2.7 KiB
SQL
-- Migration 017: Eine bestaetigte Nachpruefung wird im Datenbestand sichtbar
|
|
--
|
|
-- Additive Migration. Der Migrator toleriert 1050/1060/1061/1062/1091.
|
|
--
|
|
-- WOZU
|
|
--
|
|
-- Der Unterschied zwischen "ich habe es behoben" und "der Fix eines anderen
|
|
-- traegt" ist das Rueckgrat des Pruefverfahrens aus Migration 015. Er stand
|
|
-- bisher nur in der Anleitung. Im Datenbestand kam beides als status='closed'
|
|
-- an - `dc-testkit confirm` setzte den Status und schrieb den Rest in einen
|
|
-- Kommentar.
|
|
--
|
|
-- Damit war die eine Frage, fuer die das ganze Verfahren gebaut ist, nicht
|
|
-- beantwortbar: Wurde dieses Item gegen ein ausgeliefertes Paket geprueft -
|
|
-- oder hat jemand es zugemacht? Ein Kommentartext ist keine Antwort darauf;
|
|
-- er laesst sich nicht zaehlen, nicht filtern und nicht auswerten.
|
|
--
|
|
-- Drei Spalten, die genau das festhalten:
|
|
--
|
|
-- verified_at wann bestaetigt
|
|
-- verified_in_build gegen welche Fassung geprueft wurde
|
|
-- verified_by wer geprueft hat
|
|
--
|
|
-- WARUM NICHT EIN EIGENER STATUS
|
|
--
|
|
-- Ein Status "verified" neben "closed" waere ein zweites Kennzeichen fuer
|
|
-- dieselbe Sache - dieselbe Falle, die Migration 016 beim is_roadmap-Flag
|
|
-- vermieden hat. Ein bestaetigtes Item IST geschlossen; die Bestaetigung ist
|
|
-- eine Eigenschaft dieses Abschlusses, kein anderer Zustand. Jede Auswertung
|
|
-- ueber offene und geschlossene Items bliebe sonst richtig nur, solange sie
|
|
-- an beide Werte denkt.
|
|
--
|
|
-- WARUM verified_in_build NEBEN resolved_in_build
|
|
--
|
|
-- Sie beantworten verschiedene Fragen und koennen auseinandergehen - genau
|
|
-- das ist der interessante Fall. resolved_in_build ist eine Behauptung des
|
|
-- Behebenden ("ab 1.4.3 ist es weg"), verified_in_build die Beobachtung des
|
|
-- Pruefenden ("in 1.4.5 nicht mehr aufgetreten"). Stimmen sie ueberein, wurde
|
|
-- gegen genau den angekuendigten Build geprueft. Weicht der gepruefte ab, ist
|
|
-- die Aussage schwaecher, und man sieht es.
|
|
--
|
|
-- WARUM KEIN verified_from FUER DAS PRUEFENDE PROJEKT
|
|
--
|
|
-- Das steht schon in verified_by: Der Akteur wird serverseitig aus dem Token
|
|
-- abgeleitet und nicht aus dem Rumpf uebernommen (wie created_by). Ein
|
|
-- zweites Feld dafuer waere eine zweite Wahrheit.
|
|
|
|
ALTER TABLE bugtracker_items
|
|
ADD COLUMN verified_at DATETIME NULL AFTER resolved_at;
|
|
|
|
ALTER TABLE bugtracker_items
|
|
ADD COLUMN verified_in_build VARCHAR(64) NULL AFTER verified_at;
|
|
|
|
ALTER TABLE bugtracker_items
|
|
ADD COLUMN verified_by VARCHAR(190) NULL AFTER verified_in_build;
|
|
|
|
-- Auswertung "was wurde in Fassung X bestaetigt" und "was ist geschlossen,
|
|
-- ohne je geprueft worden zu sein". Die zweite Frage ist die wichtigere: Sie
|
|
-- misst, wie belastbar die Zahl der geschlossenen Items ueberhaupt ist.
|
|
ALTER TABLE bugtracker_items
|
|
ADD KEY ix_bt_verified (verified_at, verified_in_build);
|