Richard/Deploymentcenter
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(2.8.0): Pruefen duerfen, ohne beheben zu duerfen

Browse Source 
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
2026-08-31 10:59:57 +02:00
co-authored by Claude Opus 5
parent 51aa526f35
commit 8274a6c0ac
12 changed files with 518 additions and 31 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/AGENTEN_ANBINDEN.md
+10 -6
View File
@@ -108,8 +108,8 @@ Prüfen, ohne Claude zu starten:
printf '%s\n' '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{}}' '{"jsonrpc":"2.0","id":2,"method":"tools/list"}' | node mcp/deploymentcenter-mcp.mjs printf '%s\n' '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{}}' '{"jsonrpc":"2.0","id":2,"method":"tools/list"}' | node mcp/deploymentcenter-mcp.mjs
``` ```
Erwartet: 15 Werkzeuge. Kommt nichts, liegt es am Pfad oder daran, dass `node` Erwartet: 16 Werkzeuge (seit 2.8.0, mit `dc_confirm`). Kommt nichts, liegt es am
nicht im PATH steht. Pfad oder daran, dass `node` nicht im PATH steht.
--- ---
@@ -184,10 +184,14 @@ Der Token-Punkt ist der, an dem es beim ersten Mal hängt: Auf der VM liegt unte
beheben und soll es auch nicht versuchen — Baustein E sagt ihm, dass er sich in 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. 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 Die Rollengrenze steht in [TESTUMGEBUNG.md](TESTUMGEBUNG.md) §4.8. Seit 2.8.0
sich heute **nicht** über Rechte erzwingen: `bugtracker:manage` erlaubt auch trägt sie ein Recht: **`bugtracker:verify` statt `bugtracker:manage`** erlaubt
`resolve` und das Ändern der Roadmap. Bis es ein `bugtracker:verify` gibt, ist übernehmen, kommentieren, bestätigen und melden — aber kein `resolve`, kein
Baustein E das Einzige, was die Grenze zieht — er darf deshalb nicht gekürzt `status`, kein `bulk_update` und kein Schreiben an der Roadmap.
Das Recht verhindert den Aufruf, nicht die Absicht: Ein Agent kann trotzdem
anfangen, den Fehler selbst zu suchen und zu beheben, statt ihn zu melden.
Baustein E sagt ihm, dass er das nicht tut — er darf deshalb nicht gekürzt
werden. werden.
--- ---
docs/AGENT_PROMPT_TEMPLATE.md
+16 -6
View File
@@ -86,7 +86,11 @@ Beschreibungen nicht sagen, ist die Reihenfolge:
- `dc_search` — gibt es das schon? Vor jeder neuen Meldung - `dc_search` — gibt es das schon? Vor jeder neuen Meldung
**Am Ende** **Am Ende**
- `dc_resolve` mit `resolved_in_build` — nur im eigenen Projekt - `dc_resolve` mit `resolved_in_build` — „ich habe es behoben". Nur im eigenen
Projekt
- `dc_confirm` mit `verified_in_build` — „der Fix eines **anderen** trägt".
Schließt das Item. Nicht dasselbe wie `dc_resolve`, und nie für den eigenen
Fix
- `dc_release`, wenn du nicht weiterkommst. Ein gehaltenes Item sperrt es für - `dc_release`, wenn du nicht weiterkommst. Ein gehaltenes Item sperrt es für
alle anderen bis zum Lease-Ende alle anderen bis zum Lease-Ende
@@ -104,7 +108,8 @@ Beschreibungen nicht sagen, ist die Reihenfolge:
**Prüfaufträge erkennen.** Kommt ein Item mit Status `in_verification` oder **Prüfaufträge erkennen.** Kommt ein Item mit Status `in_verification` oder
`awaiting_verification` aus `dc_next_task`, lautet die Aufgabe **nicht** `awaiting_verification` aus `dc_next_task`, lautet die Aufgabe **nicht**
„behebe das", sondern „trägt der Fix?". In `resolved_in_build` steht, gegen „behebe das", sondern „trägt der Fix?". In `resolved_in_build` steht, gegen
welche Fassung zu prüfen ist. Trägt er: `status = closed` mit Notiz. Trägt er welche Fassung zu prüfen ist. Trägt er: `dc_confirm` mit `verified_in_build` —
der Fassung, die du **tatsächlich** geprüft hast, nicht der erwarteten. Trägt er
nicht: den Fehler ganz normal erneut melden — das Item wandert von selbst auf nicht: den Fehler ganz normal erneut melden — das Item wandert von selbst auf
`fix_insufficient`, es entsteht kein neues. `fix_insufficient`, es entsteht kein neues.
@@ -463,10 +468,15 @@ 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 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. 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 **Du behebst nichts.** Du änderst keinen Code des Projekts, rufst nie `resolve`
resolve` auf und änderst nie die Roadmap. Was als „behoben in Build X" gilt, auf und änderst nie die Roadmap. Was als „behoben in Build X" gilt, entscheidet,
entscheidet, wer den Fix geschrieben hat. Du entscheidest etwas anderes, und nur wer den Fix geschrieben hat. Du entscheidest etwas anderes, und nur das: ob er
das: ob er trägt. trägt.
Trägt dein Token `bugtracker:verify` statt `bugtracker:manage`, weist der Server
diese Aufrufe ohnehin ab. Verlass dich nicht darauf: Das Recht verhindert den
Aufruf, nicht den Einfall, den Fehler eben selbst zu suchen. Der Einfall ist das
Problem — er kostet dich die Unbefangenheit, mit der du prüfst.
### Jede Sitzung beginnt gleich ### Jede Sitzung beginnt gleich
docs/TESTUMGEBUNG.md
+35 -7
View File
@@ -349,8 +349,13 @@ und die Rechte fehlten erst dort, wo sie gebraucht wurden.
| Projekt | der Slug des Projekts — **nicht leer** | | Projekt | der Slug des Projekts — **nicht leer** |
| Rechte | `bugtracker:manage`, `license:dev`, `updateservice:read` | | Rechte | `bugtracker:manage`, `license:dev`, `updateservice:read` |
`bugtracker:manage` schließt Lesen und Melden ein, `license:dev` schließt `updateservice:read` `bugtracker:manage` schließt Lesen, Melden und Prüfen ein, `license:dev` schließt
ein — zwei Häkchen genügen also. `updateservice:read` ein — zwei Häkchen genügen also.
**Für einen reinen Prüfagenten (4.8) reicht weniger**, und weniger ist hier besser:
`bugtracker:verify` statt `manage`, dazu `license:dev`. Dann kann dieses Token melden,
übernehmen, kommentieren und bestätigen — aber nichts als behoben ausgeben und die Roadmap nicht
anfassen.
#### Warum die Projektbindung nicht optional ist #### Warum die Projektbindung nicht optional ist
@@ -727,11 +732,26 @@ bestätigt den Fix eines anderen (siehe 4.5, „Der Lebenslauf").
| Befunde melden — auch in fremden Projekten (4.5, 4.6) | Die Roadmap ändern | | 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 | | 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: **Seit 2.8.0 trägt ein Recht diese Trennung** — vorher stand sie nur im Prompt.
Wer bestätigen darf, darf auch `resolve`, `bulk_update` und die Roadmap umschreiben. Bis es ein `bugtracker:verify` erlaubt genau das, was ein Prüfstand braucht:
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 | | `bugtracker:verify` | `bugtracker:manage` |
[AGENT_PROMPT_TEMPLATE.md](AGENT_PROMPT_TEMPLATE.md). |---|---|---|
| `next`, `claim`, `release` | ja | ja |
| `comment` | ja | ja |
| `confirm` | ja | ja |
| melden (`report`) | ja | ja |
| `resolve` | **nein** | ja |
| `status`, `update`, `bulk_update` | **nein** | ja |
| Roadmap schreiben | **nein** | ja |
`bugtracker:manage` schließt `verify` ein; vorhandene Token verlieren nichts. Dass `status` bei
`manage` bleibt, ist Absicht: Darüber ließe sich sonst jeder Zustand setzen — auch `resolved` —
und die Trennung wäre um einen Aufruf herum umgangen.
**Trotzdem gehört die Grenze in den Prompt.** Ein Recht verhindert den Aufruf, aber nicht, dass
ein Agent anfängt, den Fehler selbst zu suchen und zu beheben, statt ihn zu melden. Der fertige
Textbaustein 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 **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 `manifest.json` im Sandkasten. Ohne sie kann der Server nicht unterscheiden, ob ein Befund neu ist
@@ -739,6 +759,14 @@ oder ob die Maschine schlicht einen älteren Stand fährt — und legt im Zweife
an (4.5). Für einen Agenten, der nichts anderes tut als prüfen, ist das die wichtigste einzelne an (4.5). Für einen Agenten, der nichts anderes tut als prüfen, ist das die wichtigste einzelne
Angabe überhaupt. Angabe überhaupt.
Dasselbe gilt beim Bestätigen: `confirm` schickt die geprüfte Fassung als `verified_in_build` mit,
nicht im Fließtext. Der Server hält sie neben `resolved_in_build` — der Behauptung des Behebenden
(„ab 1.4.3 ist es weg") steht damit die Beobachtung des Prüfenden gegenüber („in 1.4.5 nicht mehr
aufgetreten"). Gehen die beiden auseinander, wurde gegen etwas anderes geprüft als angekündigt,
und das ist sichtbar statt verschwunden. Bis 2.8.0 war beides `status=closed` mit einem
Kommentar — eine bestätigte Nachprüfung war von „jemand hat das Item zugemacht" nicht zu
unterscheiden.
**Was ihn einrichtet**, steht in [AGENTEN_ANBINDEN.md](AGENTEN_ANBINDEN.md); die Reihenfolge ist **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 dort dieselbe wie für jeden anderen Agenten, nur mit anderem Prompt-Baustein und anderer
Abnahmefrage. Abnahmefrage.
mcp/README.md
+2 -1
View File
@@ -118,7 +118,8 @@ printf '%s\n' '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{}}' '{"js
| `dc_next_task` | Naechstes Item exklusiv uebernehmen | | `dc_next_task` | Naechstes Item exklusiv uebernehmen |
| `dc_report` | Bug, Feature-Request oder Idee melden — auch gegen ein fremdes Projekt | | `dc_report` | Bug, Feature-Request oder Idee melden — auch gegen ein fremdes Projekt |
| `dc_comment` | Fortschritt festhalten | | `dc_comment` | Fortschritt festhalten |
| `dc_resolve` | Item abschliessen | | `dc_resolve` | Item abschliessen: "ich habe es behoben, in Build X" |
| `dc_confirm` | Nachpruefung bestaetigen: "der Fix eines ANDEREN traegt". Schliesst das Item und haelt in `verified_in_build` fest, wogegen geprueft wurde |
| `dc_release` | Uebernommenes Item zurueckgeben | | `dc_release` | Uebernommenes Item zurueckgeben |
**Roadmap** **Roadmap**
mcp/deploymentcenter-mcp.mjs
+33
View File
@@ -532,6 +532,39 @@ const TOOLS = [
}), }),
}, },
{
name: 'dc_confirm',
description:
'Bestaetigt, dass der Fix eines ANDEREN traegt, und schliesst das Item. Das ist '
+ 'nicht dc_resolve: resolve behauptet "ich habe es behoben, in Build X", confirm '
+ 'behauptet nichts, sondern haelt eine Beobachtung fest - gegen dieses Paket '
+ 'geprueft, Fehler nicht mehr da. Nur fuer Items, die auf Nachpruefung warten '
+ '(awaiting_verification, in_verification, resolved, fix_insufficient). Traegt der '
+ 'Fix NICHT, ist die Antwort keine Bestaetigung, sondern eine erneute Meldung ueber '
+ 'dc_report - das Item wechselt dann von selbst auf fix_insufficient. '
+ 'verified_in_build immer angeben: ohne sie steht spaeter "bestaetigt" am Item, '
+ 'aber nicht, wogegen.',
annotations: { destructiveHint: true },
inputSchema: {
type: 'object',
properties: {
id: { type: 'integer' },
verified_in_build: {
type: 'string',
description: 'Fassung, gegen die geprueft wurde - aus dem Paket, nicht geraten.',
},
notes: { type: 'string', description: 'Was geprueft wurde.' },
},
required: ['id'],
},
run: (args) => call('POST', '/api/bugtracker/v1/manage/', {
query: { action: 'confirm', id: args.id },
body: {
verified_in_build: args.verified_in_build,
notes: args.notes,
},
}),
},
{ {
name: 'dc_resolve', name: 'dc_resolve',
description: description:
public/api/bugtracker/v1/manage/index.php
+62 -2
View File
@@ -38,7 +38,36 @@ use Deploymentcenter\Modules\Bugtracker\BugRepo;
Http::beginJson(['GET', 'POST', 'OPTIONS'], true); Http::beginJson(['GET', 'POST', 'OPTIONS'], true);
const READ_ACTIONS = ['list', 'get', 'stats', 'projects']; 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(); $db = Db::init();
$repo = new BugRepo($db); $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)); 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']; $author = $context['actor'];
// Zwei Einschraenkungen, weil Lesen und Schreiben hier verschieden weit reichen. // 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)]); 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': case 'update':
requireItemId($itemId); requireItemId($itemId);
assertProject($repo, $context, $itemId); assertProject($repo, $context, $itemId);
public/docs/changelog.json
+51 -1
View File
@@ -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.", "_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, "schema": 1,
"current": "2.7.1", "current": "2.8.0",
"versions": [ "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", "version": "2.7.1",
"date": "2026-08-30", "date": "2026-08-30",
public/testkit/dc-testkit.sh
+37 -5
View File
@@ -1624,16 +1624,48 @@ cmd_confirm() {
build="$(detect_build || true)" build="$(detect_build || true)"
# 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 verified_in_build "${build:-}" notes "$note")
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."
local text="Nachpruefung bestanden${build:+ (geprueft gegen $build)}." local text="Nachpruefung bestanden${build:+ (geprueft gegen $build)}."
[ -n "$note" ] && text="$text $note" [ -n "$note" ] && text="$text $note"
local payload api POST "/api/bugtracker/v1/manage?action=status&id=$id" \
payload=$(json_object status closed notes "$text") "$(json_object status closed notes "$text")" \
api POST "/api/bugtracker/v1/manage?action=status&id=$id" "$payload" \
|| die "Bestaetigung nicht angenommen: $(api_error)" || 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:+ - geprüft gegen $build}" ok "Item #$id bestaetigt und geschlossen${build:+ - geprueft gegen $build}"
} }
cmd_comment() { cmd_comment() {
sql/migrations/017_verify_scope.sql
+61
View File
@@ -0,0 +1,61 @@
-- 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);
src/Core/TokenManager.php
+11 -1
View File
@@ -34,6 +34,12 @@ final class TokenManager
'*', '*',
'bugtracker:report', 'bugtracker:report',
'bugtracker:read', 'bugtracker:read',
// Nachpruefen: ein Item uebernehmen, kommentieren und bestaetigen -
// aber nicht beheben. Getrennt von manage, weil "der Fix eines
// anderen traegt" etwas anderes behauptet als "ich habe es behoben".
// Wer beides darf, prueft irgendwann gegen die eigene Erwartung, und
// ein Pruefstand, der auch beheben darf, faengt an zu beheben.
'bugtracker:verify',
'bugtracker:manage', 'bugtracker:manage',
'watchdog:ping', 'watchdog:ping',
'watchdog:read', 'watchdog:read',
@@ -543,7 +549,11 @@ final class TokenManager
* @var array<string,list<string>> * @var array<string,list<string>>
*/ */
private const IMPLIED_SCOPES = [ private const IMPLIED_SCOPES = [
'bugtracker:manage' => ['bugtracker:read', 'bugtracker:report'], 'bugtracker:manage' => ['bugtracker:read', 'bugtracker:report', 'bugtracker:verify'],
// Wer pruefen darf, muss lesen und melden koennen: Traegt der Fix
// nicht, ist die Antwort eine erneute Meldung - der Weg, auf dem das
// Item selbst nach fix_insufficient wechselt.
'bugtracker:verify' => ['bugtracker:read', 'bugtracker:report'],
'bugtracker:report' => ['bugtracker:read'], 'bugtracker:report' => ['bugtracker:read'],
'updateservice:publish' => ['updateservice:read'], 'updateservice:publish' => ['updateservice:read'],
'watchdog:evaluate' => ['watchdog:read'], 'watchdog:evaluate' => ['watchdog:read'],
src/Modules/Bugtracker/BugRepo.php
+105
View File
@@ -1792,6 +1792,111 @@ final class BugRepo
} }
/** Markiert ein Item als geloest. */ /** Markiert ein Item als geloest. */
/**
* Bestaetigt, dass der Fix eines anderen traegt - und schliesst das Item.
*
* NICHT dasselbe wie resolveItem(). "resolve" behauptet "ich habe es
* behoben, in Build X" und setzt resolved_in_build. "confirm" behauptet
* nichts ueber die Ursache, sondern haelt eine Beobachtung fest: gegen
* dieses Paket geprueft, Fehler nicht mehr da.
*
* Beides in einen Aufruf zu legen hiesse, den Unterschied zwischen Fixen
* und Pruefen einzuebnen - und genau der ist der Grund, warum es das
* Pruefverfahren gibt. Wer einen Fix schreibt und ihn selbst abnimmt,
* prueft gegen die Erwartung, die er beim Schreiben hatte.
*
* Der geprueften Fassung wegen ist $verifiedInBuild wichtig: Ohne sie
* steht spaeter zwar "bestaetigt" am Item, aber nicht, wogegen. Weicht sie
* von resolved_in_build ab, ist die Aussage schwaecher - und man sieht es.
*
* @return bool false, wenn es das Item nicht gibt oder es in einem Zustand
* steht, in dem es nichts zu bestaetigen gibt.
*/
public function confirmItem(
int $itemId,
?string $verifiedInBuild = null,
?string $notes = null,
string $author = 'agent'
): bool {
$stmt = $this->db->prepare('
SELECT status, resolved_in_build
FROM bugtracker_items
WHERE id = :id
');
$stmt->execute([':id' => $itemId]);
$item = $stmt->fetch();
if ($item === false) {
return false;
}
// Bestaetigen laesst sich nur, was jemand als behoben ausgegeben hat.
// Ein offenes Item zu "bestaetigen" waere keine Nachpruefung, sondern
// ein Schliessen mit schmueckendem Beiwort - und es stuende hinterher
// als geprueft in einer Statistik, die genau das messen soll.
$pruefbar = [
'resolved',
self::STATUS_AWAITING_VERIFICATION,
self::STATUS_IN_VERIFICATION,
self::STATUS_FIX_INSUFFICIENT,
];
if (!in_array((string)$item['status'], $pruefbar, true)) {
throw new \InvalidArgumentException(sprintf(
'Item #%d steht auf "%s". Bestaetigen laesst sich nur, was als behoben '
. 'ausgegeben wurde (%s).',
$itemId,
(string)$item['status'],
implode(', ', $pruefbar)
));
}
$build = $verifiedInBuild !== null && trim($verifiedInBuild) !== ''
? mb_substr(trim($verifiedInBuild), 0, 64)
: null;
$update = $this->db->prepare('
UPDATE bugtracker_items
SET status = "closed",
status_changed_at = UTC_TIMESTAMP(),
verified_at = UTC_TIMESTAMP(),
verified_in_build = :build,
verified_by = :author,
resolved_at = COALESCE(resolved_at, UTC_TIMESTAMP()),
claimed_by = NULL,
claimed_at = NULL,
lease_until = NULL
WHERE id = :id
');
$update->execute([
':build' => $build,
':author' => mb_substr($author, 0, 190),
':id' => $itemId,
]);
$gemeldet = $item['resolved_in_build'] !== null ? (string)$item['resolved_in_build'] : null;
$abweichung = $build !== null && $gemeldet !== null && $build !== $gemeldet;
$this->addComment(
$itemId,
$author,
sprintf(
'Nachpruefung bestanden%s%s%s',
$build !== null ? sprintf(', geprueft gegen "%s"', $build) : '',
$abweichung ? sprintf(' (behoben laut Tracker in "%s")', $gemeldet) : '',
$notes !== null && $notes !== '' ? '. ' . $notes : '.'
),
'verified'
);
$this->notify('bug.verified', $itemId, [
'verified_in_build' => $build,
'resolved_in_build' => $gemeldet,
]);
return true;
}
public function resolveItem( public function resolveItem(
int $itemId, int $itemId,
string $resolvedInBuild, string $resolvedInBuild,
tests/e2e/suite_bugtracker.py
+93
View File
@@ -364,6 +364,99 @@ def _(ctx):
ctx['freies_item'] = item ctx['freies_item'] = item
@test('bugtracker', 'Bestaetigen haelt die geprueften Fassung fest, nicht nur den Status')
def _(ctx):
"""confirm ist nicht resolve.
resolve behauptet "ich habe es behoben, in Build X"; confirm haelt eine
Beobachtung fest - gegen dieses Paket geprueft, Fehler weg. Kam beides als
status=closed im Bestand an, war die Frage "wurde das je gegen ein
ausgeliefertes Paket geprueft?" nicht beantwortbar.
"""
r = ctx.client.post('/api/bugtracker/v1/manage',
query={'action': 'confirm', 'id': ctx['bug_id']},
body={'verified_in_build': BUILD,
'notes': 'Automatischer Testlauf.'})
erwarte_erfolg(r)
danach = ctx.client.get('/api/bugtracker/v1/manage',
query={'action': 'get', 'id': ctx['bug_id']})
erwarte_erfolg(danach)
erwarte(danach.feld('item', 'status') == 'closed',
"Nach der Bestaetigung sollte das Item geschlossen sein, ist aber %r."
% danach.feld('item', 'status'))
erwarte(danach.feld('item', 'verified_at') is not None,
"verified_at fehlt - dann ist eine bestaetigte Nachpruefung von einem "
"schlichten Schliessen nicht zu unterscheiden.")
erwarte(danach.feld('item', 'verified_in_build') == BUILD,
"verified_in_build sollte %r sein, ist %r."
% (BUILD, danach.feld('item', 'verified_in_build')))
@test('bugtracker', 'Bestaetigen geht nur, wo es etwas zu bestaetigen gibt')
def _(ctx):
"""Ein offenes Item zu bestaetigen waere ein Schliessen mit schmueckendem
Beiwort - und stuende hinterher als geprueft in der Statistik."""
neu = ctx.client.post('/api/bugtracker/v1/report', body={
'project_slug': PROJEKT,
'title': 'Automatischer Testlauf: nichts zu bestaetigen',
'environment': 'testing',
'build_version': BUILD,
'client_ref': 'e2e-confirm-offen-%d' % int(time.time()),
})
erwarte_erfolg(neu)
r = ctx.client.post('/api/bugtracker/v1/manage',
query={'action': 'confirm', 'id': _item_id(neu)},
body={'verified_in_build': BUILD})
erwarte_fehler(r, http=409, code='not_verifiable')
@test('bugtracker', 'Pruefen und Beheben sind verschiedene Rechte')
def _(ctx):
"""bugtracker:verify erlaubt bestaetigen, aber nicht beheben.
Ohne diese Trennung stand die Rollengrenze eines Pruefagenten nur in
seinem Prompt: Wer bestaetigen durfte, durfte auch resolve, bulk_update
und die Roadmap umschreiben.
"""
ausstellung = ctx.client.post('/api/tokens/v1/provision', body={
'client_name': 'e2e-pruefer',
'instance_id': 'testrunner-verify',
'scopes': ['bugtracker:verify'],
'environment': 'testing',
})
erwarte_erfolg(ausstellung)
pruefer = ausstellung.feld('sub_token')
if not pruefer:
ueberspringen('Kein sub_token in der Antwort: %s' % ausstellung.kurz(200))
ziel = ctx.client.post('/api/bugtracker/v1/report', body={
'project_slug': PROJEKT,
'title': 'Automatischer Testlauf: Rechtetrennung',
'environment': 'testing',
'build_version': BUILD,
'client_ref': 'e2e-verify-scope-%d' % int(time.time()),
})
erwarte_erfolg(ziel)
item = _item_id(ziel)
# Darf er nicht: beheben.
verboten = ctx.client.post('/api/bugtracker/v1/manage', token=pruefer,
query={'action': 'resolve', 'id': item},
body={'resolved_in_build': BUILD})
erwarte_status(verboten, 401, 403)
# Darf er: uebernehmen und kommentieren.
erwarte_erfolg(ctx.client.post('/api/bugtracker/v1/manage', token=pruefer,
query={'action': 'claim', 'id': item}, body={}))
erwarte_erfolg(ctx.client.post('/api/bugtracker/v1/manage', token=pruefer,
query={'action': 'comment', 'id': item},
body={'comment': 'Automatischer Testlauf.'}))
@test('bugtracker', 'Unbekannte Aktion wird abgewiesen') @test('bugtracker', 'Unbekannte Aktion wird abgewiesen')
def _(ctx): def _(ctx):
r = ctx.client.get('/api/bugtracker/v1/manage', query={'action': 'alles-loeschen'}) r = ctx.client.get('/api/bugtracker/v1/manage', query={'action': 'alles-loeschen'})