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>

docs/AGENTEN_ANBINDEN.md

@@ -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
 ```
 
-Erwartet: 15 Werkzeuge. Kommt nichts, liegt es am Pfad oder daran, dass `node`
-nicht im PATH steht.
+Erwartet: 16 Werkzeuge (seit 2.8.0, mit `dc_confirm`). Kommt nichts, liegt es am
+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
 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
-sich heute **nicht** über Rechte erzwingen: `bugtracker:manage` erlaubt auch
-`resolve` und das Ändern der Roadmap. Bis es ein `bugtracker:verify` gibt, ist
-Baustein E das Einzige, was die Grenze zieht — er darf deshalb nicht gekürzt
+Die Rollengrenze steht in [TESTUMGEBUNG.md](TESTUMGEBUNG.md) §4.8. Seit 2.8.0
+trägt sie ein Recht: **`bugtracker:verify` statt `bugtracker:manage`** erlaubt
+übernehmen, kommentieren, bestätigen und melden — aber kein `resolve`, kein
+`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.
 
 ---

docs/AGENT_PROMPT_TEMPLATE.md

@@ -86,7 +86,11 @@ Beschreibungen nicht sagen, ist die Reihenfolge:
 - `dc_search` — gibt es das schon? Vor jeder neuen Meldung
 
 **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
   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
 `awaiting_verification` aus `dc_next_task`, lautet die Aufgabe **nicht**
 „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
 `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
 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
-resolve` auf und änderst nie die Roadmap. Was als „behoben in Build X" gilt,
-entscheidet, wer den Fix geschrieben hat. Du entscheidest etwas anderes, und nur
-das: ob er trägt.
+**Du behebst nichts.** Du änderst keinen Code des Projekts, rufst nie `resolve`
+auf und änderst nie die Roadmap. Was als „behoben in Build X" gilt, entscheidet,
+wer den Fix geschrieben hat. Du entscheidest etwas anderes, und nur das: ob er
+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
 

docs/TESTUMGEBUNG.md

@@ -349,8 +349,13 @@ und die Rechte fehlten erst dort, wo sie gebraucht wurden.
 | Projekt | der Slug des Projekts — **nicht leer** |
 | Rechte | `bugtracker:manage`, `license:dev`, `updateservice:read` |
 
-`bugtracker:manage` schließt Lesen und Melden ein, `license:dev` schließt `updateservice:read`
-ein — zwei Häkchen genügen also.
+`bugtracker:manage` schließt Lesen, Melden und Prüfen ein, `license:dev` schließt
+`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
 
@@ -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 |
 | 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:
-Wer bestätigen darf, darf auch `resolve`, `bulk_update` und die Roadmap umschreiben. Bis es ein
-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
-[AGENT_PROMPT_TEMPLATE.md](AGENT_PROMPT_TEMPLATE.md).
+**Seit 2.8.0 trägt ein Recht diese Trennung** — vorher stand sie nur im Prompt.
+`bugtracker:verify` erlaubt genau das, was ein Prüfstand braucht:
+
+| | `bugtracker:verify` | `bugtracker:manage` |
+|---|---|---|
+| `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
 `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
 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
 dort dieselbe wie für jeden anderen Agenten, nur mit anderem Prompt-Baustein und anderer
 Abnahmefrage.