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>

public/docs/changelog.json

@@ -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",