Deploymentcenter/docs/ROADMAP.md

# Roadmap

Die Begründungen zu allem Geplanten, Zurückgestellten und bewusst Verworfenen.

**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.

---

## Status-Kennzeichnung

| | Bedeutung |
|---|---|
| ✅ | Erledigt und ausgeliefert |
| 🔨 | In Arbeit |
| 📋 | Geplant, als Nächstes dran |
| 🧊 | **Zurückgestellt** — bewusst nicht jetzt, Auslöser genannt |
| ❌ | **Verworfen** — mit Begründung, nicht erneut vorschlagen |
| ⚙️ | Betriebsaufgabe, kein Code |

---

<!-- dc:roadmap stand=2026-08-30T11:25Z items=61 projekt=deploymentcenter -->

<!-- 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. -->

### Als Naechstes

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**

### 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 | ✅ Erledigt | `2.7.0` |

### 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
das schlimm?" beantwortet das Deploymentcenter, wo Verlauf, Flotte und
Quelltext bekannt sind. Diese Trennung ist die Grundentscheidung des ganzen
Entwurfs — siehe [archiv/SUPERVISOR_MCP_DESIGN.md](./archiv/SUPERVISOR_MCP_DESIGN.md),
Abschnitt 0.

> **Der Supervisor lebt nur noch auf der Serverseite.** Ein Beobachter im
> ausgelieferten Programm ist verworfen (H) — er hätte zu viele Baustellen
> aufgemacht und wäre den Mehraufwand nicht wert gewesen. Was bleibt:
>
> - die **serverseitigen Detektoren**, die auf ohnehin eingehenden Daten
>   arbeiten und nichts in den Anwendungen brauchen
> - der Eingang `POST /api/supervisor/v1/observe` für alles, was von außen
>   meldet — heute Prüfwerkzeuge und Testläufe
> - der **Katalog** als gemeinsame Sprache für Befundnamen
>
> Der Zweck, den ein Client-Beobachter erfüllt hätte, ist bei
> **Error-Reporting und Bugtracker** besser aufgehoben. Die werden
> weiterentwickelt.


### [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
`at 0x4a2f`, du bekommst `UserAuthService.cs:42`.

Der Gewinn: Berichte werden so gut wie mit einem Debug-Build, **ohne dass
Quelltext das Haus verlässt**. Das ist der Hebel, der den größten Nutzen pro
Aufwand bringt — und die Voraussetzung dafür, dass ein Diagnose-Agent mit einer
Fehlermeldung überhaupt etwas anfangen kann.

Betroffen: `client-dotnet/Deploymentcenter.Packager`, ein Ablageort für
Symboldateien, `dc_symbolicate` im MCP-Adapter.

### [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.

### [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
Maschine vor und nach dem Update. Bei gemischten Kohorten kann ein Unterschied
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.

### [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`,
`MIN_COHORT = 5`, `REGRESSION_RATIO = 1.25`, `NOVEL_WINDOW_MIN = 120` — alle in
`ServerDetectors`.

Beurteilbar erst, wenn eine Weile echte Daten durchgelaufen sind. Die Frage
lautet für jeden Wert gleich: Wie viele der erzeugten Befunde hat jemand als
brauchbar eingestuft? Der Status `ignored` an den Befunden beantwortet das von
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


### [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
auch der einzige Weg, `supervisor:manage` sinnvoll zu nutzen.

Gebraucht wird: Zählung je Detektor als Einstieg, dahinter die Einzelbefunde
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.

### [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 #81.

---

## C — Projektlandschaft


### [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`: „Das Item, das du
gemeldet hast, ist in 2.7.0 erledigt."

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
sah eine Benachrichtigung vor. Gebaut wurde stattdessen eine Arbeitsschlange,
und das ist die bessere Antwort auf dieselbe Frage:

- **Passiv:** Wer erneut meldet, bekommt die Auskunft von selbst. Der
  Report-Endpunkt vergleicht `build_version` gegen `resolved_in_build` und
  antwortet mit `known_fixed_in`, statt ein Regressionsitem anzulegen.
- **Aktiv:** Ein veröffentlichter Fix stellt sein Item auf
  `awaiting_verification`. Damit steht es in `?action=next` — auch beim
  meldenden Fremdprojekt, über `bugtracker_item_affects`. Der Melder wird also
  gefragt, ob der Fix bei ihm wirkt.

**Warum keine Zustellstrecke.** Agenten fragen ohnehin nach Arbeit. Ein Status,
der in der Warteschlangenabfrage vorkommt, *ist* die Zustellung — ohne
Speicher, ohne Entstörung, ohne Quittungen. Der Workaround-Fall, der die ganze
Diskussion trug, ist damit erledigt: Er brauchte keinen Push, sondern einen
Anlass, noch einmal hinzusehen.

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.

### [C] #75 — Prompt-Vorlage entlasten

[AGENT_PROMPT_TEMPLATE.md](./AGENT_PROMPT_TEMPLATE.md) ist in jedes Projekt
einkopiert, samt der von Hand gepflegten Versionszeile.

**Der Zuschnitt hat sich mit 2.6.1 geändert.** Ursprünglich stand hier
„durch MCP ablösen". Inzwischen gibt es drei Wege zum Deploymentcenter, und
keiner löst die anderen ab:

| Wo der Agent arbeitet | Weg | Was er braucht |
|---|---|---|
| Projektverzeichnis mit `.mcp.json` | MCP-Adapter | keine Vorlage |
| Linux-Test-VM | `dc-testkit` | Kurzfassung, kein `curl` |
| alles Übrige | REST direkt | die volle Vorlage |

Die Vorlage bleibt also — sie ist der Rückfallweg und beschreibt zugleich, was
`dc-testkit` tut. Zu tun ist trotzdem etwas: In Projekten **mit** eingerichtetem
Adapter kann sie auf die Kurzfassung schrumpfen, und die handgepflegte
Versionszeile ersetzt in allen Fällen `dc_link_project`.

Das ist der Punkt, an dem es sich lohnt, die Vorlage in drei Bausteine zu
zerlegen statt in einen Block: Grundlagen, „mit MCP", „auf der Test-VM". Heute
trägt jedes Projekt alles mit.

---

## D — Werkzeuganbindung (MCP)


### [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.

Das Projekt hat **keine CI-Strecke**. Als Erstes reicht deshalb ein Skript, das
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.

### [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
Token auf jeder Maschine. Solange der stdio-Adapter je Projekt reicht, lohnt
der Aufwand nicht.

---

## E — Betrieb

Kein Code, aber Voraussetzung dafür, dass Gebautes wirkt.


**#83 ist Voraussetzung für `deviation.fleet` und `regression.build`.** Ohne
Zuordnung überspringen beide Detektoren die betroffenen Monitore; die übrigen
drei laufen weiter.

**#84 vor #85.** Ohne Werkbank-Token laufen `dc_link_project` und `dc_report` aus
den Projekten heraus ins Leere.

**#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
geprüft, bevor es auf den Produktivserver geht. Mindestens:

```bash
find src public cli -name '*.php' -print0 | xargs -0 -n1 php -l
php cli/migrate.php
php cli/tick.php            # ohne --quiet: zeigt den Detektorlauf
```

**#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
ist, ist die Überlegung, **worauf** zu achten wäre — die gehört als Prüfung in
die Testläufe oder als Fehlermeldung in den Bugtracker, nicht in ein
Beobachterteil.

Der Auftrag zum Einfügen steht in
[SUPERVISOR_INTEGRATION_GUIDE.md](./SUPERVISOR_INTEGRATION_GUIDE.md).

---

## F — Quelltext-Zugriff für die Diagnose

Die Software bleibt geschlossen. Es gibt keine öffentliche Stelle, an der
Quelltext zu sehen ist. Drei Stufen, in aufsteigender Preisgabe:


### [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,
wäre das zusätzliche Angriffsfläche ohne Gegenwert.

Falls es kommt, dann als Schnittstelle, die **nie ein Ganzes herausgibt**:

```
GET /api/source/v1/snippet?commit=a21536f&file=…&line=42&context=40
GET /api/source/v1/search?q=…&limit=20
```

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".

### [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
Nachbauen.

---

## G — Testumgebung und Selbstbedienung

Die geteilte Linux-Test-VM. Anleitung: **[TESTUMGEBUNG.md](./TESTUMGEBUNG.md)** — dort
steht auch, was auf der Maschine belegt ist.


### [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,
und ein Agent darf grundsaetzlich kein Passwort eingeben.

Folge: `dc-testkit install` prueft die **Auslieferung** in ein leeres Verzeichnis — denselben
Pfad, den der Installer intern nimmt, mit Download, SHA256, Signatur, Staging und Rollback.
Ungeprueft bleiben damit die Aufloesung von `setup.json` und das Schreiben der Konfiguration.
Das ist genau der Teil, der je Anwendung anders aussieht und deshalb am ehesten bricht.

Gebraucht wird `--action install --answers antworten.json`: dieselben Felder, die der Dialog
erfragt, aus einer Datei. Fehlt ein Pflichtfeld, bricht der Lauf ab, statt zu fragen. Das
Installationskonto bliebe dabei aussen vor — mit einem DEV-Lizenzschluessel kommt der Agent
ohnehin an die Release-Ablage.

Betroffen: `client-dotnet/Deploymentcenter.UpdateAgent/Installation.cs`.

### [G] #93 — `dc-testkit findings`

Die Nahtstelle zwischen Testumgebung und Supervisor, die heute fehlt.

Ein Testlauf erzeugt Befunde — teils durch `novel.error_signature` aus den
gemeldeten Fehlern, teils künftig direkt über `observe`. Sehen kann man sie von
der VM aus nicht: `dc-testkit` kennt `doctor`, `license`, `install`, `update`,
`run`, `projects` und `report`, aber nichts zum Supervisor.

Gebraucht wird wenig:

```
dc-testkit findings              # was hat dieser Lauf ausgelöst?
dc-testkit findings --env all    # auch das, was in production auffiel
```

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 #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).

### [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.

Bekommt die Test-VM einen Monitor mit demselben Projekt und derselben Fassung
wie die Produktivinstallationen, landet sie in deren Kohorte — und fällt dort
zwangsläufig auf: andere Maschine, andere Last, andere Plattenbelegung. Das
Ergebnis wären Befunde, die nichts über die Software aussagen, dafür aber die
Kohortenwerte verschieben und damit echte Ausreißer verdecken.

Zwei Wege, beide vertretbar:

- ein Feld `environment` an `watchdog_monitors`, und `deviation.fleet` sowie
  `regression.build` sehen nur `production` an
- oder eine Kennzeichnung über `group_key`, ohne Schemaänderung

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.

### [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
laufen deshalb in jeder Umgebung.

Unterschieden wird zweifach: über `environment` am Befund, und über den
Schweregradhinweis. Was außerhalb von `production` auffällt, ist eine Stufe
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.

### [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
liegen — oder wäre es beim Kunden genauso passiert?

Vollständig automatisch ist das nicht zu beantworten. Vier Ansätze, die
zusammen den Aufwand aber klein halten:

**1. Der Prüfstand sagt, was ihm fehlt.**
Die Testumgebung weiß, was sie *nicht* hat: keine Zahlungs-API, kein echter
SMTP, DEV-Lizenz statt Kundenlizenz. Wird das einmal als Liste hinterlegt und
bei jeder Meldung mitgeschickt, lässt sich ein Befund, der eine bekannte Lücke
berührt, sofort als `environment_limited` kennzeichnen. Das ist der billigste
Schritt und nutzt Wissen, das ohnehin vorhanden und stabil ist.

**2. Die Umkehrung: nicht das Scheitern zählt, sondern der Umgang damit.**
Der wichtigste Gedanke hier. Fehlende Zugangsdaten sind ein Artefakt — *wie die
Software darauf reagiert*, ist es nicht. Läuft sie in eine endlose
Wiederholung? Schluckt sie den Fehler? Bleibt Zustand halb geschrieben zurück?
Landet das Passwort im Protokoll?

Das sind Produktionsbefunde, auch wenn der Auslöser künstlich war — denn in
Produktion laufen Zugangsdaten ab, werden rotiert, fällt eine Gegenstelle aus.
**Der Prüfstand ist damit kein Störfaktor, sondern eine billige
Fehlereinspeisung.** Ein `retry.storm`, ausgelöst durch fehlende Zugangsdaten,
ist ein echter Befund.

**3. Vergleich über Umgebungen statt Beurteilung des Einzelfalls.**
Feuert derselbe Detektor mit demselben `subject` auch in `production`, ist die
Frage beantwortet. Feuert er ausschließlich in `development`, ist er
verdächtig. Das ist dieselbe Mechanik wie bei `deviation.fleet`, nur über
Umgebungen statt über Installationen — Populationen vergleichen, nicht
Einzelbefunde deuten.

**4. Einmal entscheiden, nicht jedes Mal.**
Was übrig bleibt, entscheidet ein Mensch oder ein Agent — aber **je Signatur,
nicht je Vorkommnis**. Dafür gibt es das Vorbild bereits: `IgnoreRules` im
Bugtracker (Muster, Begründung, Trefferzähler). Ein Befund, der einmal als
Artefakt eingestuft wurde, bleibt es für seine Signatur und zählt trotzdem
weiter hoch — fällt er plötzlich häufiger an, sieht man es.

Die Kosten sind damit eine Entscheidung je neuer Signatur, nicht je Lauf. Das
ist tragbar; alles darüber hinaus wäre Rätselraten mit mehr Schritten.

**Reihenfolge:** 1 und 4 zuerst — beide klein und sofort wirksam. 3 ergibt sich
fast von selbst, sobald Befunde aus beiden Umgebungen nebeneinander liegen. 2
ist keine Umsetzung, sondern eine Lesehaltung: beim Sichten nicht fragen
„warum ist das fehlgeschlagen", sondern „wie hat sich die Software dabei
verhalten".

### [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`
(`from`, `to`, `actor`, `since`) in `bugtracker_comments`. Damit lassen sich
Verweildauern und Durchläufe auswerten, **ohne** eine Historientabelle daneben.

Eine eigene Tabelle verdient sich erst bei Fragen über Items hinweg — Median der
Prüfdauer, Quote durchgefallener Fixes je Projekt. Vorher wäre sie eine zweite
Wahrheit über denselben Vorgang.

### [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
#84 — dasselbe Token traegt beides.

---

## I — Roadmap im Deploymentcenter

Diese Datei war bis 2.6.1 der einzige Ort für Planung — und pflegte damit
Status, Reihenfolge und Zuständigkeit von Hand, neben einem Bugtracker, der
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.**


### [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
und eine Planung schon — Themenbereich, Reihenfolge, Zielfassung und der
Auslöser für Zurückgestelltes.

**Die Zugehörigkeit ist ein Feld.** Ein Item steht auf der Roadmap, wenn es ein
`epic` hat. Ein zweites Kennzeichen daneben wären zwei Angaben, die dasselbe
behaupten und auseinanderlaufen können.

**Die Kennung ist die Item-ID.** Handvergebene Kürzel (`A12`) erzeugen die
schlimmste Fehlerart: Beide Seiten sind für sich stimmig und meinen
Verschiedenes, weil die Kennung nach einer Löschung neu vergeben wurde.
AUTO_INCREMENT vergibt nie zweimal dieselbe Nummer — eine gelöschte Zeile
hinterlässt eine hängende Referenz, und die *meldet* der Abgleich.

**Zurückstellen verlangt einen Auslöser.** `status = deferred` ohne
`defer_trigger` wird abgelehnt, in Repository, API und Oberfläche gleichermaßen.
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.

### [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 #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.

### [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
die Antwort bereits; eine Auswertung daneben lohnt erst, wenn jemand sie liest.

---

## H — Verworfen

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 |
|---|---|---|
| #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

Die Umstellung ist vollzogen (#107, 29.08.2026). Es gilt die Arbeitsteilung
aus Abschnitt I:

| | Wahrheit | Die andere Seite hält |
|---|---|---|
| Status, Reihenfolge, Zielfassung, Bearbeiter | **Deploymentcenter** | den erzeugten Block zwischen `<!-- dc:roadmap -->`-Markern |
| Begründung, Auslöser, Verworfenes | **diese Datei**, außerhalb der Marker | den Verweis `doc_anchor` am Item |

- Ein Vorhaben entsteht **immer im DC**, nie hier. `dc_report` legt es an,
  `dc_roadmap_set` hebt es auf die Roadmap, dann erst kommt die Prosa dazu.
  So kann ein Punkt, der nur in einer Datei steht und den niemand angeht, gar
  nicht erst entstehen.
- Zwischen den Markern **nichts von Hand ändern**. `php cli/roadmap.php --write`
  überschreibt es beim nächsten Lauf.
- Vor dem Ausliefern `php cli/roadmap.php --check --project=deploymentcenter`.
  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".