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>
This commit is contained in:
Deploymentcenter Bot
co-authored by
Claude Opus 5
Claude Opus 5
parent
51aa526f35
commit
8274a6c0ac
@@ -38,7 +38,36 @@ use Deploymentcenter\Modules\Bugtracker\BugRepo;
|
||||
Http::beginJson(['GET', 'POST', 'OPTIONS'], true);
|
||||
|
||||
const READ_ACTIONS = ['list', 'get', 'stats', 'projects'];
|
||||
const WRITE_ACTIONS = ['claim', 'next', 'release', 'comment', 'status', 'update', 'resolve', 'bulk_update'];
|
||||
const WRITE_ACTIONS = ['claim', 'next', 'release', 'comment', 'confirm', 'status', 'update', 'resolve', 'bulk_update'];
|
||||
|
||||
// Welches Recht eine schreibende Aktion verlangt.
|
||||
//
|
||||
// Bis 2.7.1 war das eine einzige Antwort: bugtracker:manage fuer alles. Wer
|
||||
// eine Nachpruefung bestaetigen durfte, durfte damit auch resolve, update,
|
||||
// bulk_update und die Roadmap umschreiben - und ein Pruefagent, der beheben
|
||||
// darf, faengt an zu beheben. Die Trennung stand nur in seinem Prompt.
|
||||
//
|
||||
// bugtracker:verify deckt ab, was ein Pruefstand braucht: ein Item
|
||||
// uebernehmen, kommentieren, bestaetigen, zurueckgeben. Nicht mehr.
|
||||
// bugtracker:manage schliesst verify ein (IMPLIED_SCOPES), vorhandene Token
|
||||
// verlieren also nichts.
|
||||
//
|
||||
// "status" bleibt bewusst bei manage: Darueber liesse sich jeder Zustand
|
||||
// setzen, auch "resolved" - das waere der Umweg um genau diese Trennung.
|
||||
// Traegt ein Fix nicht, ist die Antwort des Pruefenden eine erneute Meldung
|
||||
// (bugtracker:report, in verify enthalten); das Item wechselt dann von selbst
|
||||
// nach fix_insufficient.
|
||||
const ACTION_SCOPES = [
|
||||
'claim' => 'bugtracker:verify',
|
||||
'next' => 'bugtracker:verify',
|
||||
'release' => 'bugtracker:verify',
|
||||
'comment' => 'bugtracker:verify',
|
||||
'confirm' => 'bugtracker:verify',
|
||||
'status' => 'bugtracker:manage',
|
||||
'update' => 'bugtracker:manage',
|
||||
'resolve' => 'bugtracker:manage',
|
||||
'bulk_update' => 'bugtracker:manage',
|
||||
];
|
||||
|
||||
$db = Db::init();
|
||||
$repo = new BugRepo($db);
|
||||
@@ -58,7 +87,10 @@ if ($isWrite && $method !== 'POST') {
|
||||
Http::fail(405, 'method_not_allowed', sprintf('Die Aktion "%s" erwartet POST.', $action));
|
||||
}
|
||||
|
||||
$context = ApiAuth::requireScope($db, $isWrite ? 'bugtracker:manage' : 'bugtracker:read');
|
||||
$context = ApiAuth::requireScope(
|
||||
$db,
|
||||
$isWrite ? (ACTION_SCOPES[$action] ?? 'bugtracker:manage') : 'bugtracker:read'
|
||||
);
|
||||
$author = $context['actor'];
|
||||
|
||||
// Zwei Einschraenkungen, weil Lesen und Schreiben hier verschieden weit reichen.
|
||||
@@ -212,6 +244,34 @@ switch ($action) {
|
||||
|
||||
Http::ok(['message' => sprintf('Status von #%d auf "%s" gesetzt.', $itemId, $status)]);
|
||||
|
||||
case 'confirm':
|
||||
requireItemId($itemId);
|
||||
// Wie bei "status": Auch ein fremdes Item darf bestaetigt werden,
|
||||
// solange es zur Nachpruefung gehalten wird. Wer den Fehler gemeldet
|
||||
// hat, ist oft der Einzige, der bestaetigen kann, dass der Fix bei ihm
|
||||
// wirkt - auch wenn das Item einem anderen Projekt gehoert.
|
||||
assertProject($repo, $context, $itemId, false, true);
|
||||
|
||||
try {
|
||||
$confirmed = $repo->confirmItem(
|
||||
$itemId,
|
||||
Http::str('verified_in_build') ?? Http::str('build'),
|
||||
Http::str('notes'),
|
||||
$author
|
||||
);
|
||||
} catch (\InvalidArgumentException $e) {
|
||||
// Ein Item, an dem es nichts zu bestaetigen gibt. Das ist eine
|
||||
// verletzte Regel, kein fehlendes Item - und die Meldung sagt,
|
||||
// welche Zustaende in Frage kaemen.
|
||||
Http::fail(409, 'not_verifiable', $e->getMessage());
|
||||
}
|
||||
|
||||
if (!$confirmed) {
|
||||
Http::fail(404, 'not_found', sprintf('Item #%d existiert nicht.', $itemId));
|
||||
}
|
||||
|
||||
Http::ok(['message' => sprintf('Nachpruefung von #%d bestaetigt, Item geschlossen.', $itemId)]);
|
||||
|
||||
case 'update':
|
||||
requireItemId($itemId);
|
||||
assertProject($repo, $context, $itemId);
|
||||
|
||||
@@ -1,8 +1,58 @@
|
||||
{
|
||||
"_comment": "Einzige Quelle der Wahrheit fuer den Changelog. Wird von /docs/changelog.php gerendert und von GET /api/updateservice/v1/changelog?since=X ausgeliefert. Neue Eintraege oben einfuegen.",
|
||||
"schema": 1,
|
||||
"current": "2.7.1",
|
||||
"current": "2.8.0",
|
||||
"versions": [
|
||||
{
|
||||
"version": "2.8.0",
|
||||
"date": "2026-08-31",
|
||||
"summary": "Remote-Testen, das traegt. Die Testwege waren beschrieben, aber nicht begehbar: Auf der Test-VM lag die Anleitung von vor zwei Fassungen, ein Token ohne die noetigen Rechte und ein Testkit, das aelter war als das ausgelieferte - beide meldeten dieselbe Fassungsnummer. Deshalb sagte doctor dort \"Bereit\", waehrend kein einziger Auslieferungstest laufen konnte. Dazu die Trennung, die dem Pruefverfahren bisher fehlte: bugtracker:verify erlaubt, eine Nachpruefung zu bestaetigen, ohne zu erlauben, den Fehler selbst zu beheben.",
|
||||
"actionRequired": false,
|
||||
"changes": [
|
||||
{
|
||||
"area": "server",
|
||||
"breaking": false,
|
||||
"title": "bugtracker:verify - pruefen duerfen, ohne beheben zu duerfen",
|
||||
"text": "bugtracker:manage war ein einziger Schreib-Scope: Wer eine Nachpruefung bestaetigen durfte, durfte damit 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. Genau dagegen ist das Verfahren aus 2.6.1 gebaut, aber die Grenze stand nur in der Anleitung. bugtracker:verify deckt jetzt ab, was ein Pruefer braucht: uebernehmen, kommentieren, bestaetigen, zurueckgeben. bugtracker:manage schliesst es ein, vorhandene Token verlieren also nichts. \"status\" bleibt bewusst bei manage - darueber liesse sich sonst jeder Zustand setzen und die Trennung umgehen."
|
||||
},
|
||||
{
|
||||
"area": "server",
|
||||
"breaking": false,
|
||||
"title": "confirm ist eine eigene Aktion und hinterlaesst, wogegen geprueft wurde",
|
||||
"text": "Eine bestaetigte Nachpruefung war im Datenbestand 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? Neu: POST .../manage?action=confirm mit verified_in_build. Migration 017 legt verified_at, verified_in_build und verified_by an. Weicht die geprueften Fassung von resolved_in_build ab, wurde gegen etwas anderes geprueft als angekuendigt, und man sieht es. Bestaetigen laesst sich nur, was als behoben ausgegeben wurde; ein offenes Item zu \"bestaetigen\" antwortet 409 not_verifiable."
|
||||
},
|
||||
{
|
||||
"area": "mcp",
|
||||
"breaking": false,
|
||||
"title": "dc_confirm - Pruefauftraege liessen sich annehmen, aber nicht abschliessen",
|
||||
"text": "Der Adapter hatte dc_next_task und dc_resolve, aber keinen Weg, eine Nachpruefung zu bestaetigen; dc_comment kennt nur action_taken, keinen Status. Ein Pruefagent ueber MCP konnte einen Prueffauftrag also uebernehmen und dann nichts damit anfangen. Jetzt 16 Werkzeuge statt 15."
|
||||
},
|
||||
{
|
||||
"area": "testkit",
|
||||
"breaking": false,
|
||||
"title": "dc-testkit 1.1.0: kennt seinen eigenen Stand, prueft Rechte und Display",
|
||||
"text": "Vier Fehler: doctor brach unter \"set -e\" wortlos nach der Health-Pruefung ab, sobald der Server neu genug war - Token und Projekt wurden nie geprueft. Die Konfigurationsdatei ueberschrieb die Umgebung statt umgekehrt, \"DC_PROJECT=x dc-testkit report\" meldete also stillschweigend in das Projekt aus der Datei. Der Bericht ging teils auf stderr und stand ueber SSH unter der falschen Ueberschrift. Und \"~/bin\" liegt ueber SSH nicht im PATH, weil .profile nur von einer Login-Shell gelesen wird. Neu: selfupdate (mit Richtungspruefung - eine neuere lokale Fassung ist ein Entwicklungsstand und kein Grund zum Update), doctor prueft den eigenen Stand, die Token-Herkunft, die fehlende Projektbindung und das eigene Display, sowie display start|stop|status und shot fuer die Oberflaechenpruefung."
|
||||
},
|
||||
{
|
||||
"area": "testkit",
|
||||
"breaking": false,
|
||||
"title": "dc-testkit-remote: der Agent laeuft auf dem Arbeitsplatz, der Test auf der VM",
|
||||
"text": "Claude Code laesst sich auf der Test-VM nicht betreiben, Agenten arbeiten also ueber SSH von aussen - dort liegen auch die Projekt-Repos und damit die Werkbank-Token in deren .mcp.json. Der Wrapper haelt das Token aus \"ps aux\" der geteilten Maschine (es geht ueber die Standardeingabe in die Umgebung), ruft bash -l, schuetzt Argumente vor drei Ebenen Quoting und buendelt ganze Pruefplaene in eine Verbindung. Auf der VM wird keine Konfiguration mehr gelesen: Sonst gilt drueben, was irgendwann jemand eingetragen hat - genau daran ist es gescheitert."
|
||||
},
|
||||
{
|
||||
"area": "security",
|
||||
"breaking": false,
|
||||
"title": "Interne Anleitungen bleiben aus dem Webroot",
|
||||
"text": "docs/TESTUMGEBUNG.md und docs/TESTINSTANZ.md gingen bei jedem Deployment mit hoch. Erreichbar waren sie dort nicht - aber nur, weil die Rewrite-Regel ^docs/ auf public/docs/ umleitet und dort nichts Gleichnamiges liegt. Faellt mod_rewrite aus oder aendert jemand die Reihenfolge, liegen interne Adresse, Benutzername und der Weg zur sudo-Freischaltung offen. Beide Dateien sagen in ihrem eigenen Kopf, dass sie da nicht hingehoeren; deploy.py schliesst sie jetzt pfadgenau aus."
|
||||
},
|
||||
{
|
||||
"area": "docs",
|
||||
"breaking": false,
|
||||
"title": "Baustein E: ein Agent, der nur prueft",
|
||||
"text": "Die Prompt-Vorlage hatte nur den Entwickleragenten, der nebenbei testet. Baustein E beschreibt das Umgekehrte und zieht die Rollengrenze ausdruecklich: kein resolve, keine Roadmap, und bei fehlendem Token eine Meldung statt eines Ratespiels - .mcp.json ist gitignored und kommt ueber Git nie mit. TESTUMGEBUNG.md 4.8 beschreibt die Rolle, 4.2 den tatsaechlichen Ablageort der Token, und die Belegung in 7 ist von der Maschine erhoben statt fortgeschrieben - sie war vier Projekte im Rueckstand."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"version": "2.7.1",
|
||||
"date": "2026-08-30",
|
||||
|
||||
@@ -1624,16 +1624,48 @@ cmd_confirm() {
|
||||
|
||||
build="$(detect_build || true)"
|
||||
|
||||
local text="Nachpruefung bestanden${build:+ (geprueft gegen $build)}."
|
||||
[ -n "$note" ] && text="$text $note"
|
||||
|
||||
# Eigene Aktion, nicht "status=closed" mit schmueckendem Kommentar.
|
||||
#
|
||||
# Bis 2.7.1 war es genau das - und damit war eine bestaetigte Nachpruefung
|
||||
# im Datenbestand nicht von "jemand hat das Item zugemacht" zu
|
||||
# unterscheiden. Die eine Frage, fuer die das Verfahren gebaut ist ("wurde
|
||||
# das gegen ein ausgeliefertes Paket geprueft?"), war nicht beantwortbar,
|
||||
# weil die Antwort in einem Kommentartext stand.
|
||||
#
|
||||
# Die gepruefte Fassung geht deshalb als Feld mit, nicht im Fliesstext:
|
||||
# Der Server haelt sie in verified_in_build und kann sie gegen
|
||||
# resolved_in_build stellen. Gehen die beiden auseinander, wurde gegen
|
||||
# etwas anderes geprueft als angekuendigt - und das sieht man dann.
|
||||
local payload
|
||||
payload=$(json_object status closed notes "$text")
|
||||
payload=$(json_object verified_in_build "${build:-}" notes "$note")
|
||||
|
||||
api POST "/api/bugtracker/v1/manage?action=status&id=$id" "$payload" \
|
||||
|| die "Bestaetigung nicht angenommen: $(api_error)"
|
||||
if ! api POST "/api/bugtracker/v1/manage?action=confirm&id=$id" "$payload"; then
|
||||
case "$API_STATUS" in
|
||||
404)
|
||||
# Ein Server vor 2.8.0 kennt die Aktion nicht. Der alte Weg
|
||||
# bleibt richtig - er sagt nur weniger.
|
||||
warn "Dieser Server kennt 'confirm' noch nicht - alter Weg (status=closed)."
|
||||
warn " Die gepruefte Fassung landet dann nur im Kommentar."
|
||||
|
||||
ok "Item #$id bestaetigt und geschlossen${build:+ - geprüft gegen $build}"
|
||||
local text="Nachpruefung bestanden${build:+ (geprueft gegen $build)}."
|
||||
[ -n "$note" ] && text="$text $note"
|
||||
|
||||
api POST "/api/bugtracker/v1/manage?action=status&id=$id" \
|
||||
"$(json_object status closed notes "$text")" \
|
||||
|| die "Bestaetigung nicht angenommen: $(api_error)"
|
||||
;;
|
||||
409)
|
||||
# Kein Fehler des Aufrufers, sondern eine Aussage ueber das
|
||||
# Item: Da ist nichts, was sich bestaetigen liesse.
|
||||
die "Nichts zu bestaetigen: $(api_error)"
|
||||
;;
|
||||
*)
|
||||
die "Bestaetigung nicht angenommen: $(api_error)"
|
||||
;;
|
||||
esac
|
||||
fi
|
||||
|
||||
ok "Item #$id bestaetigt und geschlossen${build:+ - geprueft gegen $build}"
|
||||
}
|
||||
|
||||
cmd_comment() {
|
||||
|
||||
Reference in New Issue
Block a user