feat(roadmap): Roadmap des Deploymentcenters uebernommen (I9)

61 Eintraege aus docs/ROADMAP.md stehen jetzt als Items im Deploymentcenter:
17 offen, 24 erledigt, 7 zurueckgestellt, 13 verworfen. Keine Waisen, jedes
Item mit doc_anchor. Der Abgleich laeuft ohne Befund durch.

Die Datei behaelt, was eine Tabellenzelle nicht traegt: die Begruendungen.
Der Zustand steht zwischen dc:roadmap-Markern und wird erzeugt.

  - scripts/roadmap_import.py: wertet die Datei aus und uebertraegt sie.
    Wiederholbar ueber client_ref, legt fehlende Themenbereiche an, wartet
    bei Drosselung. Die Prioritaet liest es aus dem Abschnitt "Als
    Naechstes" - solange die Datei die Quelle ist, soll auch die Prioritaet
    von dort kommen.
  - docs/ROADMAP.md: Statustabellen raus, erzeugter Block rein,
    21 Ueberschriften und 14 Querverweise auf Item-Nummern umgestellt,
    Abschnitt H mit Item-Nummern versehen.

WAS DIE UEBERNAHME ZUTAGE FOERDERTE

  - G8 war zweimal vergeben: einmal offen, einmal erledigt. Genau die
    Kollision handvergebener Kennungen, gegen die der Entwurf argumentiert.
    Beide sind eigene Items.
  - Bereich H fehlte in roadmap_epics - Migration 016 hatte nur A-G und I
    gesetzt. Die Waisenerkennung meldete es. Das Importskript legt fehlende
    Bereiche jetzt an, ueberschreibt aber keine vorhandenen: Ein
    Uebernahmeskript darf anlegen, kuratierte Angaben nicht ueberschreiben.
  - "Item #42" stand als erfundenes Beispiel im Rueckkanal-Absatz - und #42
    gibt es wirklich, in predictalytics. Der Abgleich hat es gemeldet, ein
    Mensch haette es nie bemerkt.
  - Vier Marker waren veraltet (E1, E2, I8, D1).

BEHOBEN: spliceBlock() zerstoerte Dateien, die den Marker erwaehnen

strpos() nahm die erste Fundstelle von "<!-- dc:roadmap". Erwaehnt eine Datei
den Marker im Fliesstext - und die Einleitung einer ordentlichen Roadmap tut
genau das - setzte der Splice dort an und ueberschrieb den halben Dateikopf.
check() klammerte aus demselben Grund Prosa aus statt des Blocks.

Es trifft also ausgerechnet die Dateien, die das Verfahren beschreiben. Der
echte Block wird jetzt am Zeilenanfang samt "stand=" erkannt; das Blockende
wird ab dem Anfang gesucht, nicht ab Dateibeginn.

BEHOBEN: IPv6-Erkennung im Testlauf war launisch

erreichbar() prueft seit jeher IPv6 mit einem blossen connect(). Auf dieser
Strecke gelingt der Verbindungsaufbau zeitweise, waehrend danach nichts mehr
fliesst - der Lauf blieb dann auf IPv6 und jede Anfrage lief 21 Sekunden in
einen Timeout. Weil es launisch war, sah es mal nach einem Haenger und mal
nach einem sauberen Lauf aus. Geprueft wird jetzt bis zur Antwort:
TLS-Handschlag und ein HTTP-HEAD.

WebUI: Verweise im Inhalt hatten keine Farbregel und erschienen im
Browservorgabeblau auf schwarzem Grund. Der Bereichsverweis der Roadmap
springt ausserdem auf die Liste statt auf die Uebersicht - dort wirkt der
Filter, den er setzt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/ROADMAP.md

@@ -1,11 +1,22 @@
 # Roadmap
 
-Der eine Ort für alles Geplante, Zurückgestellte und bewusst Verworfene.
+Die Begründungen zu allem Geplanten, Zurückgestellten und bewusst Verworfenen.
 
-Bis 2.6.0 lagen diese Angaben über mehrere Entwurfsdokumente verstreut — mit
-der Folge, dass eine Liste offener Punkte noch als offen galt, obwohl der Code
-sie längst erledigt hatte. Deshalb: **Was hier steht, gilt. Wer etwas umsetzt,
-zieht den Eintrag hier nach.**
+**Der Zustand steht nicht hier, sondern im Deploymentcenter** — WebUI → Roadmap,
+oder `dc_roadmap` über den MCP-Adapter. Was unten zwischen den
+`<!-- dc:roadmap -->`-Markern steht, ist eine **erzeugte Kopie**: `php
+cli/roadmap.php --write` schreibt sie, und beim nächsten Lauf wird sie
+überschrieben. Von Hand dort nichts ändern.
+
+Alles außerhalb der Marker ist von Hand geschrieben und bleibt unberührt. Das
+ist der Teil, der eine Tabellenzelle nicht überlebt: warum etwas so entschieden
+wurde, woran man erkennt, dass ein Zurückgestelltes wieder ansteht, und warum
+ein Verworfenes verworfen bleibt.
+
+Bis 2.6.0 lagen diese Angaben über mehrere Entwurfsdokumente verstreut, bis
+2.7.0 standen Zustand und Begründung nebeneinander in dieser Datei — beides mit
+derselben Folge: Ein Punkt galt als offen, obwohl der Code ihn längst erledigt
+hatte. Seither hat kein Feld zwei Pfleger.
 
 Die abgelösten Entwürfe liegen unter [archiv/](./archiv/) — sie enthalten die
 ausführliche Begründung, aber keinen gültigen Stand mehr.
@@ -25,33 +36,135 @@ ausführliche Begründung, aber keinen gültigen Stand mehr.
 
 ---
 
-## Als Nächstes
+<!-- dc:roadmap stand=2026-08-29T21:48Z items=61 projekt=deploymentcenter -->
 
-1. **[I8] Migration 016 ausführen** — ohne sie steht das Roadmap-Modul, das
-   2.7.0 mitbringt, vor leeren Spalten
-2. **[I9] Diese Datei selbst übernehmen** — das Verfahren einmal hier
-   durchlaufen, bevor die anderen Projekte es aus der Anleitung bekommen
-3. **[B1] Befunde in der Oberfläche** — sie sind derzeit nur über API und MCP
-   erreichbar. Ohne Sicht auf die Befunde ist alles Weitere blind
-4. **[G5] `dc-testkit findings`** — dasselbe von der Test-VM aus, und
-   Voraussetzung für G8
-5. **[G8] Testartefakt oder echter Befund?** — die Frage, an der sich
-   entscheidet, ob Befunde aus Testläufen etwas wert sind
-6. **[A4] Symbol-Upload und `dc_symbolicate`** — Stacktraces aus gestrippten
-   Binaries auflösen, ohne dass Quelltext das Haus verlässt
+<!-- ERZEUGT - nicht von Hand aendern. Dieser Block wird bei jedem Lauf von
+     `php cli/roadmap.php --write` ueberschrieben. Der Zustand wird im
+     Deploymentcenter gepflegt, nicht hier. Prosa gehoert AUSSERHALB der
+     Marker - dort bleibt sie unberuehrt. -->
 
-Davor stehen die Betriebsaufgaben ⚙️ aus Abschnitt E — ohne sie laufen zwei
-der fünf serverseitigen Detektoren gar nicht.
+### Als Naechstes
 
-**Diese Liste ist die letzte ihrer Art.** Ab I9 ergibt sie sich aus Reihenfolge
-und Status und wird erzeugt, statt hier fortgeschrieben zu werden — sie ist
-genau die Sorte Angabe, die von Hand zuverlässig veraltet.
+1. **[B] #69 — Befunde im WebUI: Liste, Filter nach Detektor, Einstufen**
+2. **[G] #93 — dc-testkit supervisor — prüfen, ob eine Anbindung wirklich meldet**
+3. **[G] #96 — Testartefakt oder echter Befund? — die offene Frage**
+4. **[A] #65 — Symbol-Upload und dc_symbolicate**
 
-Nicht mehr auf der Liste: der Supervisor im ausgelieferten Programm. Verworfen,
-siehe H.
+### A — Supervisor und Befunde
+
+| | Vorhaben | Stand | Ziel |
+|---|---|---|---|
+| #65 | Symbol-Upload und dc_symbolicate | 📋 Offen | — |
+| #62 | Detektor-Katalog mit stabilen Namen (Modules/Supervisor/Catalog.php) | ✅ Erledigt | `2.6.0` |
+| #63 | Fünf serverseitige Detektoren im Tick: novel.error_signature, silence.heartbeat, deviation.self, deviation.fleet, reg... | ✅ Erledigt | `2.6.0` |
+| #64 | Supervisor-Client für .NET und PHP | ❌ Verworfen | — |
+| #66 | novel.log_template — Logzeilen-Schablonen, die noch nie auftraten | 🧊 Zurueckgestellt — Ausloeser: sobald Logauszüge strukturiert hereinkommen. Heute liefert nichts sie in einer Form, aus der sich Schablonen bilden l... | — |
+| #67 | Längsschnitt für regression.build | 🧊 Zurueckgestellt — Ausloeser: wenn Fehlzuordnungen auffallen. Nötig wäre eine Historie der app_version je Monitor; das Feld wird heute überschrieben. | — |
+| #68 | Schwellen der serverseitigen Detektoren an echten Daten nachprüfen | 📋 Offen | — |
+
+### B — Oberflaeche
+
+| | Vorhaben | Stand | Ziel |
+|---|---|---|---|
+| #69 | Befunde im WebUI: Liste, Filter nach Detektor, Einstufen | 📋 Offen | — |
+| #70 | Fremdmeldungen sichtbar (triage_external in Filter, Abzeichen, Bearbeiten) | ✅ Erledigt | `2.6.0` |
+| #71 | Monitoren ein Projekt zuweisen | 📋 Offen | — |
+
+### C — Projektlandschaft
+
+| | Vorhaben | Stand | Ziel |
+|---|---|---|---|
+| #72 | Projektübergreifend melden (dev_agent, evidence, triage_external, affects) | ✅ Erledigt | `2.6.0` |
+| #73 | Beziehungen zwischen Projekten (dc_project_links, integrated_version) | ✅ Erledigt | `2.6.0` |
+| #74 | Rückkanal: „was du gemeldet hast, ist behoben" | ✅ Erledigt | `2.6.1` |
+| #75 | Agent-Prompt-Vorlage in den Projekten durch MCP ablösen | 📋 Offen | — |
+
+### D — Werkzeuganbindung (MCP)
+
+| | Vorhaben | Stand | Ziel |
+|---|---|---|---|
+| #76 | stdio-Adapter ohne Fremdabhängigkeiten | ✅ Erledigt | `2.6.0` |
+| #77 | Fremddaten im Werkzeugergebnis abgegrenzt kennzeichnen | ✅ Erledigt | `2.6.0` |
+| #78 | Abgleich: Werkzeugliste gegen openapi.php | 📋 Offen | — |
+| #79 | Entfernter MCP-Server unter /mcp mit OAuth | 🧊 Zurueckgestellt — Ausloeser: wenn mehrere Maschinen oder Personen dranhängen. Dann aber mit OAuth statt Bearer-Token in einer Konfigurationsdatei ... | — |
+| #80 | dc_roadmap und dc_roadmap_set — Planungsstand als Werkzeug | ✅ Erledigt | `2.7.0` |
+
+### E — Betrieb
+
+| | Vorhaben | Stand | Ziel |
+|---|---|---|---|
+| #81 | Migrationen 013 und 014 auf dem Server ausführen | ✅ Erledigt | `2.7.0` |
+| #82 | PHP-Seite prüfen — die Testinstanz tut das jetzt bei jedem Deployment | ✅ Erledigt | `2.7.0` |
+| #83 | Monitoren ein Projekt zuordnen (watchdog_monitors.project_slug) | 📋 Offen | — |
+| #84 | Je Projekt ein Werkbank-Token (dev_agent) anlegen | 📋 Offen | — |
+| #85 | Supervisor-Vorbereitungen in den Projekten zurückbauen | 📋 Offen | — |
+
+### F — Quelltext-Zugriff
+
+| | Vorhaben | Stand | Ziel |
+|---|---|---|---|
+| #86 | Stufe 0 — Diagnose-Agent läuft auf eigener Maschine mit lokalem Checkout | ✅ Erledigt | — |
+| #87 | Stufe 1 — Quelltext-Index im DC, nur Ausschnitte | 🧊 Zurueckgestellt — Ausloeser: wenn ein Agent autonom rund um die Uhr laufen soll, ohne dass eine eigene Maschine läuft. Solange Claude Code den Che... | — |
+| #88 | Stufe 2 — nur Metadaten: Signaturen, Aufrufgraph, keine Rümpfe | 🧊 Zurueckgestellt — Ausloeser: falls selbst Ausschnitte zu viel sind. Signaturen, Aufrufgraph und Doc-Kommentare ohne Methodenkörper reichen zur Tri... | — |
+
+### G — Testumgebung
+
+| | Vorhaben | Stand | Ziel |
+|---|---|---|---|
+| #93 | dc-testkit supervisor — prüfen, ob eine Anbindung wirklich meldet | 📋 Offen | — |
+| #96 | Testartefakt oder echter Befund? — die offene Frage | 📋 Offen | — |
+| #89 | Kopfloser Installationsmodus fuer den update-agent | 📋 Offen | — |
+| #90 | DEV-Lizenzschluessel zur Selbstbedienung (POST /api/license/v1/dev-key, Scope license:dev) | ✅ Erledigt | `2.6.1` |
+| #91 | dc-testkit — ein Weg fuer Lizenz, Auslieferung und Meldung | ✅ Erledigt | `2.6.1` |
+| #92 | Werkbank-Token je Projekt auf der Test-VM hinterlegen | 📋 Offen | — |
+| #94 | Test-Monitore aus dem Flottenvergleich heraushalten | 📋 Offen | — |
+| #95 | Befunde tragen die Umgebung, ausserhalb production eine Stufe niedriger | ✅ Erledigt | `2.6.1` |
+| #97 | Nachpruefung als Arbeitsschlange (awaiting_verification, in_verification, fix_insufficient) | ✅ Erledigt | `2.6.1` |
+| #98 | Auswertung über meta_json: wie oft fällt ein Fix durch die Prüfung? | 🧊 Zurueckgestellt — Ausloeser: wenn die Frage „wie oft trägt ein Fix nicht?" tatsächlich gestellt wird. Seit 2.6.1 schreibt jeder Statuswechsel stru... | — |
+
+### I — Roadmap im Deploymentcenter
+
+| | Vorhaben | Stand | Ziel |
+|---|---|---|---|
+| #107 | Diese Datei selbst übernehmen — Einträge A1–H als Items anlegen, Kennungen auf Item-IDs umstellen | ✅ Erledigt | `2.7.0` |
+| #99 | Migration 016: epic, roadmap_rank, target_build, defer_trigger, doc_anchor, Status deferred, Tabelle roadmap_epics | ✅ Erledigt | `2.7.0` |
+| #100 | Modules/Bugtracker/Roadmap.php — Sicht, Reihenfolge, Erzeugung, Abgleich | ✅ Erledigt | `2.7.0` |
+| #101 | /api/bugtracker/v1/roadmap.php — list, epics, next, active, render, check, set, move, reorder, epic | ✅ Erledigt | `2.7.0` |
+| #102 | WebUI-Modul Roadmap: Übersicht, Liste, Aufnahmeliste, Themenbereiche | ✅ Erledigt | `2.7.0` |
+| #103 | cli/roadmap.php --write/--check/--list | ✅ Erledigt | `2.7.0` |
+| #104 | dc_roadmap, dc_roadmap_set im MCP-Adapter | ✅ Erledigt | `2.7.0` |
+| #105 | Übernahmeleitfaden für die anderen Projekte | ✅ Erledigt | `2.7.0` |
+| #106 | Migration 016 auf dem Server ausführen | ✅ Erledigt | `2.7.0` |
+| #108 | Die anderen Projekte übernehmen (myapp, polytrader, predictalytics) | 📋 Offen | — |
+| #109 | --check in scripts/deploy.py einhängen | 📋 Offen | — |
+| #110 | Auswertung: wie lange steht ein Vorhaben in welcher Lage? | 🧊 Zurueckgestellt — Ausloeser: wenn die Frage „warum dauert das so lange?" tatsächlich gestellt wird. status_changed_at und das strukturierte meta_j... | — |
+
+### H — Verworfen
+
+| | Vorhaben | Stand | Ziel |
+|---|---|---|---|
+| #111 | Supervisor-Beobachter im ausgelieferten Programm (auch regelbasiert, ohne Sprachmodell) | ❌ Verworfen | — |
+| #112 | Sprachmodell-Supervisor auf der Kundenmaschine | ❌ Verworfen | — |
+| #113 | Quelltext mit dem Client ausliefern, auch verschlüsselt | ❌ Verworfen | — |
+| #114 | Deploy-Key oder Repo-Token im Client | ❌ Verworfen | — |
+| #115 | Obfuskation als Schutz einplanen | ❌ Verworfen | — |
+| #116 | MCP-Werkzeuge 1:1 aus OpenAPI erzeugen | ❌ Verworfen | — |
+| #117 | publish, provision, deactivate als MCP-Werkzeug | ❌ Verworfen | — |
+| #118 | Befunde puffern, wenn das DC ausfällt | ❌ Verworfen | — |
+| #119 | Benachrichtigung je Befund | ❌ Verworfen | — |
+| #120 | Lokale Befund-Oberfläche in den Anwendungen | ❌ Verworfen | — |
+| #121 | enforceProject() pauschal für dev_agent öffnen | ❌ Verworfen | — |
+| #122 | Feste Schwellwerte je Kennzahl als Hauptweg | ❌ Verworfen | — |
+
+<!-- /dc:roadmap -->
 
 ---
 
+## Begründungen
+
+Ab hier von Hand. Jede Überschrift trägt die Item-Nummer, unter der das
+Vorhaben im Deploymentcenter steht.
+
 ## A — Supervisor und Befunde
 
 Der Supervisor beantwortet die Frage „ist das ungewöhnlich?". Die Frage „ist
@@ -74,17 +187,8 @@ Abschnitt 0.
 > **Error-Reporting und Bugtracker** besser aufgehoben. Die werden
 > weiterentwickelt.
 
-| | Vorhaben | Stand |
-|---|---|---|
-| A1 | Detektor-Katalog mit stabilen Namen (`Modules/Supervisor/Catalog.php`) | ✅ 2.6.0 |
-| A2 | Fünf serverseitige Detektoren im Tick: `novel.error_signature`, `silence.heartbeat`, `deviation.self`, `deviation.fleet`, `regression.build` | ✅ 2.6.0 |
-| A3 | ~~Supervisor-Client für .NET und PHP~~ | ❌ verworfen, siehe H |
-| A4 | **Symbol-Upload und `dc_symbolicate`** | 📋 |
-| A5 | `novel.log_template` — Logzeilen-Schablonen, die noch nie auftraten | 🧊 |
-| A6 | Längsschnitt für `regression.build` | 🧊 |
-| A7 | Schwellen der serverseitigen Detektoren an echten Daten nachprüfen | 📋 |
 
-### A4 — Symbol-Upload und `dc_symbolicate` 📋
+### [A] #65 — Symbol-Upload und `dc_symbolicate`
 
 Der Packager lädt beim `publish` die PDB bzw. Sourcemap mit hoch, verknüpft mit
 `commit_sha`. Ausgeliefert wird ein gestripptes Binary. Der Kunde bekommt
@@ -98,12 +202,12 @@ Fehlermeldung überhaupt etwas anfangen kann.
 Betroffen: `client-dotnet/Deploymentcenter.Packager`, ein Ablageort für
 Symboldateien, `dc_symbolicate` im MCP-Adapter.
 
-### A5 — `novel.log_template` 🧊
+### [A] #66 — `novel.log_template`
 
 **Auslöser:** sobald Logauszüge strukturiert hereinkommen. Heute liefert nichts
 sie in einer Form, aus der sich Schablonen bilden ließen.
 
-### A6 — Längsschnitt für `regression.build` 🧊
+### [A] #67 — Längsschnitt für `regression.build`
 
 `regression.build` vergleicht heute die beiden höchsten Fassungen im Feld im
 **Querschnitt** — verschiedene Maschinen zur selben Zeit, nicht dieselbe
@@ -113,7 +217,7 @@ deshalb auch von der Maschine kommen statt von der Fassung.
 **Auslöser:** wenn Fehlzuordnungen auffallen. Nötig wäre eine Historie der
 `app_version` je Monitor; das Feld wird heute überschrieben.
 
-### A7 — Schwellen nachprüfen 📋
+### [A] #68 — Schwellen nachprüfen
 
 Die serverseitigen Detektoren rechnen mit gesetzten, aber nirgends
 nachgeprüften Werten: `SIGMA = 3.0` für `deviation.self` und `deviation.fleet`,
@@ -127,15 +231,18 @@ selbst, sobald gesichtet wird.
 
 ---
 
+### [A] #64 — Supervisor-Client für .NET und PHP
+
+Verworfen. Die Begründung steht in Abschnitt H, beim Beobachter im
+ausgelieferten Programm — dieser Client wäre sein Einbauteil gewesen und fällt
+mit ihm weg.
+
+---
+
 ## B — Oberfläche
 
-| | Vorhaben | Stand |
-|---|---|---|
-| B1 | **Befunde im WebUI: Liste, Filter nach Detektor, Einstufen** | 📋 |
-| B2 | Fremdmeldungen sichtbar (`triage_external` in Filter, Abzeichen, Bearbeiten) | ✅ 2.6.0 |
-| B3 | Monitoren ein Projekt zuweisen | 📋 |
 
-### B1 — Befunde im WebUI 📋
+### [B] #69 — Befunde im WebUI
 
 Befunde sind heute nur über `/api/supervisor/v1/findings` und die MCP-Werkzeuge
 erreichbar. Für die Sichtung durch einen Menschen fehlt die Ansicht — und damit
@@ -146,34 +253,28 @@ mit `observed`/`baseline`, und die Statuswechsel (`acknowledged`, `promoted`,
 `resolved`, `ignored`). Beim Übernehmen in ein Bugtracker-Item die Verknüpfung
 über `supervisor_findings.bug_item_id` setzen — die Spalte gibt es bereits.
 
-### B3 — Monitoren ein Projekt zuweisen 📋
+### [B] #71 — Monitoren ein Projekt zuweisen
 
 `watchdog_monitors.project_slug` wird administrativ gesetzt, nicht vom Agenten
 gemeldet. Dafür fehlt das Bedienelement in der Monitor-Verwaltung. Bis dahin
-nur per SQL — siehe E1.
+nur per SQL — siehe #81.
 
 ---
 
 ## C — Projektlandschaft
 
-| | Vorhaben | Stand |
-|---|---|---|
-| C1 | Projektübergreifend melden (`dev_agent`, `evidence`, `triage_external`, `affects`) | ✅ 2.6.0 |
-| C2 | Beziehungen zwischen Projekten (`dc_project_links`, `integrated_version`) | ✅ 2.6.0 |
-| C3 | **Rückkanal: „was du gemeldet hast, ist behoben"** | ✅ 2.6.1 — als Arbeitsschlange, nicht als Benachrichtigung |
-| C4 | Agent-Prompt-Vorlage in den Projekten durch MCP ablösen | 📋 |
 
-### C3 — Rückkanal ✅
+### [C] #74 — Rückkanal
 
 Wird ein Item behoben, das ein anderes Projekt gemeldet hat, erfährt dieses
 Projekt heute nichts davon. Folge: Es meldet denselben Punkt in drei Monaten
 erneut und baut seinen Workaround nie zurück.
 
 `GET /api/updateservice/v1/changelog?since=…` liefert bereits `action_items`.
-Zu ergänzen ist der Abgleich über `bugtracker_item_affects`: „Item #42, das du
+Zu ergänzen ist der Abgleich über `bugtracker_item_affects`: „Das Item, das du
 gemeldet hast, ist in 2.7.0 erledigt."
 
-Das schließt den Kreis, den C1 geöffnet hat. Ohne ihn ist der Meldeweg ein
+Das schließt den Kreis, den #72 geöffnet hat. Ohne ihn ist der Meldeweg ein
 Briefkasten ohne Leerung.
 
 **Gelöst in 2.6.1 — aber anders als hier ursprünglich gedacht.** Der Entwurf
@@ -198,7 +299,7 @@ Was bleibt: Wer einen Workaround gebaut hat, muss den Prüfauftrag auch
 annehmen. Nimmt ihn niemand an, wird nach 30 Tagen ungeprüft geschlossen — mit
 einem Vermerk, der das ausdrücklich sagt.
 
-### C4 — Prompt-Vorlage entlasten 📋
+### [C] #75 — Prompt-Vorlage entlasten
 
 [AGENT_PROMPT_TEMPLATE.md](./AGENT_PROMPT_TEMPLATE.md) ist in jedes Projekt
 einkopiert, samt der von Hand gepflegten Versionszeile.
@@ -226,15 +327,8 @@ trägt jedes Projekt alles mit.
 
 ## D — Werkzeuganbindung (MCP)
 
-| | Vorhaben | Stand |
-|---|---|---|
-| D1 | stdio-Adapter mit 13 Werkzeugen, ohne Fremdabhängigkeiten | ✅ 2.6.0 |
-| D2 | Fremddaten im Werkzeugergebnis abgegrenzt kennzeichnen | ✅ 2.6.0 |
-| D3 | Abgleich: Werkzeugliste gegen `openapi.php` | 📋 |
-| D4 | Entfernter MCP-Server unter `/mcp` mit OAuth | 🧊 |
-| D5 | `dc_roadmap` und `dc_roadmap_set` — Planungsstand als Werkzeug | ✅ 2.7.0 (siehe I) |
 
-### D3 — Abgleich Werkzeugliste ↔ OpenAPI 📋
+### [D] #78 — Abgleich Werkzeugliste ↔ OpenAPI
 
 Adapter und OpenAPI beschreiben dieselben Endpunkte. Ohne Abgleich laufen sie
 auseinander, und es fällt erst auf, wenn ein Werkzeug ins Leere greift.
@@ -244,7 +338,7 @@ von Hand oder aus `deploy.py` heraus läuft. Eine echte Pipeline wäre ein
 eigenes Vorhaben und lohnt erst, wenn es mehr zu prüfen gibt als diese eine
 Zusage.
 
-### D4 — Entfernter Server 🧊
+### [D] #79 — Entfernter Server
 
 **Auslöser:** wenn mehrere Maschinen oder Personen dranhängen. Dann aber mit
 OAuth statt Bearer-Token in einer Konfigurationsdatei — sonst liegt dasselbe
@@ -257,22 +351,15 @@ der Aufwand nicht.
 
 Kein Code, aber Voraussetzung dafür, dass Gebautes wirkt.
 
-| | Aufgabe | Stand |
-|---|---|---|
-| E1 | Migrationen 013 und 014 auf dem Server ausführen | ⚙️ |
-| E2 | PHP-Seite von 2.6.0 prüfen — auf der Entwicklungsmaschine lief kein Lint | ⚙️ |
-| E3 | Monitoren ein Projekt zuordnen (`watchdog_monitors.project_slug`) | ⚙️ |
-| E4 | Je Projekt ein Werkbank-Token (`dev_agent`) anlegen | ⚙️ |
-| E5 | Supervisor-Vorbereitungen in den Projekten zurückbauen | ⚙️ |
 
-**E3 ist Voraussetzung für `deviation.fleet` und `regression.build`.** Ohne
+**#83 ist Voraussetzung für `deviation.fleet` und `regression.build`.** Ohne
 Zuordnung überspringen beide Detektoren die betroffenen Monitore; die übrigen
 drei laufen weiter.
 
-**E4 vor E5.** Ohne Werkbank-Token laufen `dc_link_project` und `dc_report` aus
+**#84 vor #85.** Ohne Werkbank-Token laufen `dc_link_project` und `dc_report` aus
 den Projekten heraus ins Leere.
 
-**E2 gehört auf die Test-VM.** Die gesamte PHP-Seite von 2.6.0 — Migrationen
+**#82 gehört auf die Test-VM.** Die gesamte PHP-Seite von 2.6.0 — Migrationen
 013 und 014, der Supervisor-Endpunkt, das projektübergreifende Melden — wurde
 auf einer Maschine ohne PHP geschrieben. Weder Lint noch ein Lauf haben sie je
 gesehen. Seit 2.6.1 gibt es die geteilte Test-VM (Abschnitt G); dort gehört das
@@ -284,7 +371,7 @@ php cli/migrate.php
 php cli/tick.php            # ohne --quiet: zeigt den Detektorlauf
 ```
 
-**E5 ist reiner Rückbau geworden.** In mehreren Projekten wurden
+**#85 ist reiner Rückbau geworden.** In mehreren Projekten wurden
 Vorbereitungen für einen lokalen Supervisor begonnen — UI-Steuerelemente,
 teilweise ein KI-Agent. Da der Client-Supervisor verworfen ist (H), fällt das
 ersatzlos weg; nichts tritt an seine Stelle. Was an den Vorbereitungen wertvoll
@@ -302,13 +389,8 @@ Der Auftrag zum Einfügen steht in
 Die Software bleibt geschlossen. Es gibt keine öffentliche Stelle, an der
 Quelltext zu sehen ist. Drei Stufen, in aufsteigender Preisgabe:
 
-| | Stufe | Stand |
-|---|---|---|
-| F1 | **Stufe 0** — Diagnose-Agent läuft auf eigener Maschine mit lokalem Checkout | ✅ Der gegenwärtige Weg |
-| F2 | **Stufe 1** — Quelltext-Index im DC, nur Ausschnitte | 🧊 |
-| F3 | **Stufe 2** — nur Metadaten: Signaturen, Aufrufgraph, keine Rümpfe | 🧊 |
 
-### F2 — Quelltext-Index Stufe 1 🧊
+### [F] #87 — Quelltext-Index Stufe 1
 
 **Auslöser:** wenn ein Agent autonom rund um die Uhr laufen soll, ohne dass
 eine eigene Maschine läuft. Solange Claude Code den Checkout ohnehin lokal hat,
@@ -325,7 +407,7 @@ Neuer Scope `source:read`, nie an Client-Token, verschlüsselt abgelegt, Budget
 je Token und Tag, jeder Abruf im Prüfprotokoll. Der Unterschied zwischen „darf
 nachschlagen" und „darf mitnehmen".
 
-### F3 — Stufe 2 🧊
+### [F] #88 — Stufe 2
 
 **Auslöser:** falls selbst Ausschnitte zu viel sind. Signaturen, Aufrufgraph
 und Doc-Kommentare ohne Methodenkörper reichen zur Triage, aber nicht zum
@@ -338,20 +420,8 @@ Nachbauen.
 Die geteilte Linux-Test-VM. Anleitung: **[TESTUMGEBUNG.md](./TESTUMGEBUNG.md)** — dort
 steht auch, was auf der Maschine belegt ist.
 
-| | Vorhaben | Stand |
-|---|---|---|
-| G1 | **Kopfloser Installationsmodus fuer den `update-agent`** | 📋 |
-| G2 | DEV-Lizenzschluessel zur Selbstbedienung (`POST /api/license/v1/dev-key`, Scope `license:dev`) | ✅ 2.6.1 |
-| G3 | `dc-testkit` — ein Weg fuer Lizenz, Auslieferung und Meldung | ✅ 2.6.1 |
-| G4 | Werkbank-Token je Projekt auf der Test-VM hinterlegen | ⚙️ |
-| G5 | **`dc-testkit supervisor` — prüfen, ob eine Anbindung wirklich meldet** | 📋 |
-| G6 | Test-Monitore aus dem Flottenvergleich heraushalten | 📋 |
-| G7 | Befunde tragen die Umgebung, ausserhalb `production` eine Stufe niedriger | ✅ 2.6.1 |
-| G8 | **Testartefakt oder echter Befund? — die offene Frage** | 📋 |
-| G8 | Nachpruefung als Arbeitsschlange (`awaiting_verification`, `in_verification`, `fix_insufficient`) | ✅ 2.6.1 |
-| G9 | Auswertung über `meta_json`: wie oft fällt ein Fix durch die Prüfung? | 🧊 |
 
-### G1 — Kopfloser Installationsmodus 📋
+### [G] #89 — Kopfloser Installationsmodus
 
 `update-agent --action install` ist ein Dialog mit Auswahllisten und Passwortabfrage. Ein
 Agent kann ihn nicht treiben: Auswahllisten brauchen Pfeiltasten an einem echten Terminal,
@@ -369,7 +439,7 @@ ohnehin an die Release-Ablage.
 
 Betroffen: `client-dotnet/Deploymentcenter.UpdateAgent/Installation.cs`.
 
-### G5 — `dc-testkit findings` 📋
+### [G] #93 — `dc-testkit findings`
 
 Die Nahtstelle zwischen Testumgebung und Supervisor, die heute fehlt.
 
@@ -389,13 +459,13 @@ Dahinter `GET /api/supervisor/v1/findings?project_slug=…`. Derselbe Zuschnitt
 wie `dc_findings` im MCP-Adapter — die Abfrage existiert, es fehlt nur der Weg
 dorthin von der VM aus.
 
-Das ist zugleich die Voraussetzung für G8: Ohne Sicht auf die eigenen Befunde
+Das ist zugleich die Voraussetzung für #96: Ohne Sicht auf die eigenen Befunde
 kann niemand entscheiden, ob einer ein Artefakt des Prüfstands war.
 
 Das Token braucht dafür zusätzlich `supervisor:read`; heute trägt es auf der
 VM nur `bugtracker:manage` und `license:dev` (§4.2 der Anleitung).
 
-### G6 — Test-Monitore aus dem Flottenvergleich 📋
+### [G] #94 — Test-Monitore aus dem Flottenvergleich
 
 `deviation.fleet` bildet Kohorten aus (Projekt, `app_version`) und meldet, wer
 daraus ausschert. `watchdog_monitors` hat **kein** Feld für die Umgebung.
@@ -415,7 +485,7 @@ Zwei Wege, beide vertretbar:
 Solange auf der VM kein Monitor mit Produktivfassung läuft, ist nichts kaputt.
 Es fällt nur genau dann auf, wenn es zu spät ist — deshalb hier vermerkt.
 
-### G7 — Umgebung am Befund ✅ 2.6.1
+### [G] #95 — Umgebung am Befund
 
 Testläufe **sollen** Befunde erzeugen — ein Lauf, der einen Fehler auslöst, den
 es vorher nicht gab, hat genau das getan, wofür er da ist. Die Detektoren
@@ -427,7 +497,7 @@ niedriger eingestuft — nicht weil es unwichtig wäre, sondern weil dort
 systematisch mehr Rauschen entsteht. Wer beides gleich hoch einstuft, liest
 bald keines von beiden mehr.
 
-### G8 — Testartefakt oder echter Befund? 📋
+### [G] #96 — Testartefakt oder echter Befund?
 
 **Die eigentlich schwierige Frage.** Ein Testlauf meldet „API-Aufruf
 fehlgeschlagen". Liegt das daran, dass auf der VM keine Live-Zugangsdaten
@@ -478,7 +548,7 @@ ist keine Umsetzung, sondern eine Lesehaltung: beim Sichten nicht fragen
 „warum ist das fehlgeschlagen", sondern „wie hat sich die Software dabei
 verhalten".
 
-### G9 — Auswertung der Statuswechsel 🧊
+### [G] #98 — Auswertung der Statuswechsel
 
 **Auslöser:** wenn die Frage „wie oft trägt ein Fix nicht?" tatsächlich gestellt
 wird. Seit 2.6.1 schreibt jeder Statuswechsel strukturiertes `meta_json`
@@ -489,12 +559,12 @@ Eine eigene Tabelle verdient sich erst bei Fragen über Items hinweg — Median
 Prüfdauer, Quote durchgefallener Fixes je Projekt. Vorher wäre sie eine zweite
 Wahrheit über denselben Vorgang.
 
-### G4 — Werkbank-Token auf der Test-VM ⚙️
+### [G] #92 — Werkbank-Token auf der Test-VM
 
 Ohne das Token laufen `dc-testkit license` und `dc-testkit report` ins Leere. Je Projekt eines
 anlegen (Besitzerart `dev_agent`, Rechte `bugtracker:manage` und `license:dev`), auf der VM
 unter `~/.config/dc-testkit/` hinterlegen und in der Belegungsliste vermerken. Deckt sich mit
-E4 — dasselbe Token traegt beides.
+#84 — dasselbe Token traegt beides.
 
 ---
 
@@ -506,22 +576,8 @@ genau diese drei Dinge bereits führt. Zwei Pfleger für dasselbe Feld.
 
 Ab 2.7.0 gilt die Arbeitsteilung: **Zustand im DC, Begründung hier.**
 
-| | Vorhaben | Stand |
-|---|---|---|
-| I1 | Migration 016: `epic`, `roadmap_rank`, `target_build`, `defer_trigger`, `doc_anchor`, Status `deferred`, Tabelle `roadmap_epics` | ✅ 2.7.0 |
-| I2 | `Modules/Bugtracker/Roadmap.php` — Sicht, Reihenfolge, Erzeugung, Abgleich | ✅ 2.7.0 |
-| I3 | `/api/bugtracker/v1/roadmap.php` — list, epics, next, active, render, check, set, move, reorder, epic | ✅ 2.7.0 |
-| I4 | WebUI-Modul **Roadmap**: Übersicht, Liste, Aufnahmeliste, Themenbereiche | ✅ 2.7.0 |
-| I5 | `cli/roadmap.php --write/--check/--list` | ✅ 2.7.0 |
-| I6 | `dc_roadmap`, `dc_roadmap_set` im MCP-Adapter | ✅ 2.7.0 |
-| I7 | Übernahmeleitfaden für die anderen Projekte | ✅ 2.7.0 — [ROADMAP_MIGRATION.md](./ROADMAP_MIGRATION.md) |
-| I8 | **Migration 016 auf dem Server ausführen** | ⚙️ |
-| I9 | **Diese Datei selbst übernehmen** — Einträge A1–H als Items anlegen, Kennungen auf Item-IDs umstellen | 📋 |
-| I10 | Die anderen Projekte übernehmen (myapp, polytrader, predictalytics) | 📋 |
-| I11 | `--check` in `scripts/deploy.py` einhängen | 📋 |
-| I12 | Auswertung: wie lange steht ein Vorhaben in welcher Lage? | 🧊 |
 
-### I1–I7 — der gebaute Teil ✅
+### [I] #99 ff. — Migration, Modul, Endpunkt, Oberfläche, CLI und Leitfaden
 
 Kein neues Modul und keine Roadmap-Tabelle: Ein Roadmap-Eintrag **ist** ein
 `bugtracker_item`. Es fehlten nur vier Angaben, die ein Backlog nicht braucht
@@ -544,20 +600,20 @@ Ohne benannten Anlass ist ein Vorhaben nicht zurückgestellt, sondern vergessen
 und die Regel gehört an die Stelle, an der geschrieben wird, nicht nur in ein
 Formular.
 
-### I9 — diese Datei übernehmen 📋
+### [I] #107 — diese Datei übernehmen
 
 Die Einträge A1–G9 stehen noch als handvergebene Kürzel hier. Sie werden Items;
 die Abschnitte werden Themenbereiche (in Migration 016 bereits angelegt).
 Danach ersetzt ein erzeugter Block die Statustabellen, und die Prosa bleibt.
 
-**Reihenfolge:** erst I8 (Migration), dann I9, dann I11 (Abgleich im Deploy).
-I10 kommt zuletzt — die anderen Projekte bekommen ein Verfahren, das hier
+**Reihenfolge:** erst #106 (Migration), dann #107, dann #109 (Abgleich im Deploy).
+#108 kommt zuletzt — die anderen Projekte bekommen ein Verfahren, das hier
 einmal durchlaufen ist, nicht eines aus der Anleitung.
 
 Bis dahin gilt diese Datei unverändert weiter. Sie ist erst abgelöst, wenn der
 Block darin steht.
 
-### I12 — Verweildauern 🧊
+### [I] #110 — Auswertung der Verweildauern
 
 **Auslöser:** wenn die Frage „warum dauert das so lange?" tatsächlich gestellt
 wird. `status_changed_at` und das strukturierte `meta_json` aus 2.6.1 tragen
@@ -570,36 +626,27 @@ die Antwort bereits; eine Auswertung daneben lohnt erst, wenn jemand sie liest.
 Diese Punkte sind geprüft und abgelehnt. **Nicht erneut vorschlagen** — und
 falls doch, dann nur mit einem Argument, das hier noch nicht steht.
 
-| Vorschlag | Warum nicht |
-|---|---|
-| ❌ **Supervisor-Beobachter im ausgelieferten Programm** (auch regelbasiert, ohne Sprachmodell) | Zu viele Baustellen für den Ertrag. Er hätte in jeder Anwendung Einbau, Rückbau bestehender Vorbereitungen, eigenen Zustand auf Kundenhardware, ein weiteres Token im Binary und eine zweite Fassungspflege gebraucht — und dabei überwiegend das gemeldet, was Error-Reporting und Bugtracker ohnehin abdecken. Der Code war fertig und ist am 29.08.2026 wieder entfernt worden; er liegt in der Historie, falls die Abwägung je anders ausfällt. **Stattdessen:** Error-Reporting und Bugtracker weiterentwickeln, Befunde serverseitig ermitteln |
-| ❌ Sprachmodell-Supervisor auf der Kundenmaschine | API-Schlüssel läge auf fremder Hardware; Kontext im Speicher fremder Maschinen; kann nicht im Minutentakt hinsehen; hat keinen Verlauf und sieht die Flotte nicht; antwortet zweimal verschieden auf dieselbe Lage |
-| ❌ Quelltext mit dem Client ausliefern, auch verschlüsselt | Der Client muss entschlüsseln können, also kann es der Kunde auch |
-| ❌ Deploy-Key oder Repo-Token im Client | Dekompiliert in Minuten |
-| ❌ Obfuskation als Schutz einplanen | Verzögert, verhindert nicht |
-| ❌ MCP-Werkzeuge 1:1 aus OpenAPI erzeugen | 24 Endpunkte; Werkzeugdefinitionen liegen dauerhaft im Kontextfenster. Ein aufgeblähter Adapter wäre schlechter als die Prompt-Vorlage, die er ersetzt |
-| ❌ `publish`, `provision`, `deactivate` als MCP-Werkzeug | Ein Release gehört in die CI, nicht an ein Werkzeug, das ein Modell im Zweifel „hilfreich" auslöst |
-| ❌ Befunde puffern, wenn das DC ausfällt | Eine wachsende Warteschlange in einer ohnehin auffälligen Anwendung ist genau der Schaden, den der Supervisor verhindern soll |
-| ❌ Benachrichtigung je Befund | Ein Befund behauptet nicht, dass etwas kaputt ist. Wer bei jeder Auffälligkeit alarmiert, hat nach einer Woche einen Kanal, den niemand mehr liest |
-| ❌ Lokale Befund-Oberfläche in den Anwendungen | Zweite Wahrheit, die nur den eigenen Ausschnitt kennt. Der Client hält keine Historie vor |
-| ❌ `enforceProject()` pauschal für `dev_agent` öffnen | Hätte auch `publish` und `setup` in fremden Projekten erlaubt. Die Ausnahme wird je Aufrufstelle gesetzt |
-| ❌ Feste Schwellwerte je Kennzahl als Hauptweg | Finden nur, woran vorher jemand gedacht hat. Die tragenden Detektoren vergleichen gegen eigenen Verlauf, Vorversion oder Flotte |
+| | Vorschlag | Warum nicht |
+|---|---|---|
+| #111 ❌ **Supervisor-Beobachter im ausgelieferten Programm** (auch regelbasiert, ohne Sprachmodell) | Zu viele Baustellen für den Ertrag. Er hätte in jeder Anwendung Einbau, Rückbau bestehender Vorbereitungen, eigenen Zustand auf Kundenhardware, ein weiteres Token im Binary und eine zweite Fassungspflege gebraucht — und dabei überwiegend das gemeldet, was Error-Reporting und Bugtracker ohnehin abdecken. Der Code war fertig und ist am 29.08.2026 wieder entfernt worden; er liegt in der Historie, falls die Abwägung je anders ausfällt. **Stattdessen:** Error-Reporting und Bugtracker weiterentwickeln, Befunde serverseitig ermitteln |
+| #112 ❌ Sprachmodell-Supervisor auf der Kundenmaschine | API-Schlüssel läge auf fremder Hardware; Kontext im Speicher fremder Maschinen; kann nicht im Minutentakt hinsehen; hat keinen Verlauf und sieht die Flotte nicht; antwortet zweimal verschieden auf dieselbe Lage |
+| #113 ❌ Quelltext mit dem Client ausliefern, auch verschlüsselt | Der Client muss entschlüsseln können, also kann es der Kunde auch |
+| #114 ❌ Deploy-Key oder Repo-Token im Client | Dekompiliert in Minuten |
+| #115 ❌ Obfuskation als Schutz einplanen | Verzögert, verhindert nicht |
+| #116 ❌ MCP-Werkzeuge 1:1 aus OpenAPI erzeugen | 24 Endpunkte; Werkzeugdefinitionen liegen dauerhaft im Kontextfenster. Ein aufgeblähter Adapter wäre schlechter als die Prompt-Vorlage, die er ersetzt |
+| #117 ❌ `publish`, `provision`, `deactivate` als MCP-Werkzeug | Ein Release gehört in die CI, nicht an ein Werkzeug, das ein Modell im Zweifel „hilfreich" auslöst |
+| #118 ❌ Befunde puffern, wenn das DC ausfällt | Eine wachsende Warteschlange in einer ohnehin auffälligen Anwendung ist genau der Schaden, den der Supervisor verhindern soll |
+| #119 ❌ Benachrichtigung je Befund | Ein Befund behauptet nicht, dass etwas kaputt ist. Wer bei jeder Auffälligkeit alarmiert, hat nach einer Woche einen Kanal, den niemand mehr liest |
+| #120 ❌ Lokale Befund-Oberfläche in den Anwendungen | Zweite Wahrheit, die nur den eigenen Ausschnitt kennt. Der Client hält keine Historie vor |
+| #121 ❌ `enforceProject()` pauschal für `dev_agent` öffnen | Hätte auch `publish` und `setup` in fremden Projekten erlaubt. Die Ausnahme wird je Aufrufstelle gesetzt |
+| #122 ❌ Feste Schwellwerte je Kennzahl als Hauptweg | Finden nur, woran vorher jemand gedacht hat. Die tragenden Detektoren vergleichen gegen eigenen Verlauf, Vorversion oder Flotte |
 
 ---
 
 ## Pflege dieser Datei
 
-**Bis I9 abgeschlossen ist**, gilt weiterhin von Hand:
-
-- Ein Vorhaben umgesetzt? Zeile auf ✅ setzen und die Fassung dazuschreiben.
-- Etwas verworfen? Nach H, **mit Begründung**. Die Begründung ist der Wert des
-  Eintrags, nicht die Ablehnung.
-- Etwas zurückgestellt? Nach 🧊, **mit Auslöser**. Ohne Auslöser ist es nicht
-  zurückgestellt, sondern vergessen.
-- Ausführliche Herleitungen gehören ins Archiv, nicht hierher. Diese Datei soll
-  lesbar bleiben.
-
-**Danach** gilt die Arbeitsteilung aus Abschnitt I:
+Die Umstellung ist vollzogen (#107, 29.08.2026). Es gilt die Arbeitsteilung
+aus Abschnitt I:
 
 | | Wahrheit | Die andere Seite hält |
 |---|---|---|
@@ -616,3 +663,9 @@ falls doch, dann nur mit einem Argument, das hier noch nicht steht.
   Rückgabewert 1 heißt: Ein Absatz verweist auf ein Item, das es nicht gibt.
 - 🧊 und ❌ behalten ihren Absatz hier. Der Statuswert allein sagt nicht, warum —
   und ohne das Warum schlägt es der nächste Agent wieder vor.
+- Ausführliche Herleitungen gehören ins Archiv, nicht hierher. Diese Datei soll
+  lesbar bleiben.
+- **Keine erfundenen Item-Nummern im Fließtext.** Bei der Übernahme stand im
+  Rückkanal-Absatz eine ausgedachte Beispielnummer — und die gab es wirklich, in
+  `predictalytics`. Der Abgleich hat es gemeldet; ein Mensch hätte es nie
+  bemerkt. Für Beispiele deshalb „das Item" schreiben, nicht „Item Nummer x".