Weboberflaeche hinzugefuegt und Fachlogik nach App herausgeloest (#493, #494)

- ClawdDotNet.Web: Kestrel im Prozess der Anwendung, Token-Absicherung (TokenGate mit FixedTimeEquals), Endpunkte unter /api, Ereignisstrom unter /events (Server-Sent Events) und fortlaufendes Log-Streaming.

- Weboberflaeche (wwwroot/): Vollstaendiges Single-Page-Frontend mit nativem HTML5, CSS3 und ES-Modulen ohne Buildschritt (strikt textContent, #-Routing, sofortiger Login-Sprung bei fehlendem Token, Light/Dark-Theme, lokale Barlow-Schriften).

- ClawdDotNet.App: Fachlogik aus den Avalonia-ViewModels in Dienste herausgeloest (AgentAdministration, JobAdministration, ServiceAdministration, RunCoordinator) und ueber InstanceChange synchronisiert.

- Tests: ClawdDotNet.Web.Tests und ClawdDotNet.App.Tests hinzugefuegt, alle 684 Tests erfolgreich.

docs/Roadmap.md

@@ -1,345 +1,696 @@
 # ClawdDotNet — Roadmap
 
-**Dies ist die einzige Vorhabenliste.** Vor dem 2026-08-23 lag der Stand über eine
-Bestandsaufnahme, drei Konzeptpapiere, vier Umsetzungspläne und zwei
-Deploymentcenter-Dokumente verteilt — jedes mit eigener Reihenfolge, teils
-widersprüchlich. Alles davon ist hier zusammengeführt.
+**Der Stand steht nicht mehr in dieser Datei.** Er steht im
+[Deploymentcenter](https://dc.mhdf.de), seit dem 2026-08-30. Was hier zwischen
+den `dc:roadmap`-Markern steht, ist eine **erzeugte Kopie** und darf älter sein
+als der echte Stand — sie kommt von `deploy/roadmap/roadmap_block.py --write`
+und wird bei jedem Lauf überschrieben. Dort niemals von Hand etwas ändern.
 
-Gepflegt wird nur noch dieses Dokument. Was aus den alten Papieren wurde, steht in
-[Abschnitt 7](#7--woher-das-hier-kommt).
+Was diese Datei behält, ist die Hälfte, die eine Tabellenzelle nie getragen
+hat: **warum** etwas so entschieden wurde, woran ein Zurückgestelltes wieder
+ansteht, und woher die Reihenfolge kommt. Verbunden ist beides über die
+Item-Nummer.
 
----
+| | Wahrheit | Die andere Seite hält |
+|---|---|---|
+| Status, Reihenfolge, Zielfassung, Bearbeiter | **Deploymentcenter** | eine erzeugte Kopie zwischen Markern |
+| Begründung, Auslöser, Herleitung | **diese Datei** | einen Verweis (`doc_anchor`) |
 
-## Wie das hier zu lesen ist
+Der Live-Stand kommt aus `dc_roadmap` — **mit `project_slug: "clawddotnet"`**,
+solange Item 176 unter `deploymentcenter` offen ist. Ein Vorhaben, das etwas werden
+soll, entsteht als Item über `dc_report` und wird mit `dc_roadmap_set`
+eingeplant; *danach* schreibt man die Begründung hierher. So kann ein Punkt,
+der nur in einer Datei steht, gar nicht erst entstehen.
 
-| Zeichen | Bedeutung |
-|---|---|
-| ✅ | erledigt |
-| 📋 | **beschlossen**, noch nicht gebaut — kann jederzeit angefasst werden |
-| ❓ | **Entscheidung nötig**, bevor gebaut werden kann |
-| ❄️ | zurückgestellt — wartet auf eine Entscheidung oder ein anderes Vorhaben |
-| 💭 | **Idee**, nicht beschlossen — bewusst geparkt, damit sie nicht verlorengeht |
-
-Die **Herkunft**-Spalte trägt das alte Kürzel (S4, K2, B9, T4, F-A1, C1, DC1 …). Damit
-bleiben die archivierten Papiere auffindbar, ohne dass man sie lesen muss.
-
-**Bauplan** heißt: Es gibt ein Dokument, das die Umsetzung im Detail beschreibt. Wer den
-Punkt anfasst, liest es zuerst.
+Wo die alten Papiere geblieben sind, steht in Abschnitt 5.
 
 ---
 
 ## 0 — Stand
 
 Der Kern trägt. Engine, Taskboard, Audit, Gedächtnis, Budget, Sicherung und die
-Oberfläche sind gebaut und getestet (585 Tests grün, Build fehlerfrei, keine bekannten
-Sicherheitslücken in den Paketen). Die Sicherheitsbefunde S1–S7 und die Bugs B1–B5,
-B11, B12 aus der Bestandsaufnahme sind abgearbeitet.
+Oberfläche sind gebaut und getestet, der Build ist fehlerfrei, in den Paketen sind
+keine Sicherheitslücken bekannt. Die Sicherheitsbefunde S1–S7 und die Bugs B1–B5, B11,
+B12 aus der Bestandsaufnahme sind abgearbeitet — sie stehen als erledigte Items im
+Block unten.
 
-Drei Dinge stehen im Weg:
+> **Die „585 Tests grün" standen hier ohne Plattform — und das war der Fehler.** Sie
+> stammen von Windows. Auf der Zielplattform sind es am 2026-08-31 **587 von 591
+> grün, drei rot**. Zwei der drei sind mit `[LinuxFact]` markiert und laufen unter
+> Windows gar nicht erst; sie decken genau die Symlink-Grenze ab, die #373 aufgemacht
+> hat. Eine Zahl ohne die Maschine, auf der sie entstand, sagt hier nichts mehr —
+> gemessen wird ab jetzt auf der Test-VM (siehe
+> `Deploymentcenter/docs/TESTUMGEBUNG.md`).
 
-1. **Die Freigabe-Ansicht fehlt.** Staging ist gebaut und greift — aber niemand kann
-   freigeben. Damit ist der unbeaufsichtigte Betrieb, für den das ganze A2-Vorhaben da
-   war, nicht möglich.
-2. **A5 ist unentschieden.** Rocket.Chat ist gebaut und bedient denselben Zweck, für den
-   Matrix vorgesehen war. Solange das offen ist, hängen Streaming (K4), der
-   Notfallkanal und ein Teil von A6 in der Luft.
-3. **Agenten können sich gegenseitig verklemmen.** `AgentComm.send_message` hat keine
-   Tiefenbegrenzung; A→B→A blockiert bis zum Timeout. Bekannt seit Juli, unverändert.
+**Zielbetrieb (festgelegt am 2026-08-23):** Linux, ausschließlich. Eine Maschine mit
+Desktopumgebung (Ubuntu Desktop), 24/7 durchlaufend, die Avalonia-Oberfläche läuft
+immer mit — zum Konfigurieren, Überwachen und Freigeben. Windows ist keine Zielplattform
+mehr; die vorhandenen Windows-Zweige bleiben vorerst nur als **Migrationspfad** stehen
+(siehe #190). Das ändert die Reihenfolge und macht aus einem bekannten Randfall einen
+Blocker.
+
+**Davor stehen zwei kritische Befunde** (Bereich `FIX`, Ränge 1 und 2). Sie sind neu
+und gehen allem anderen vor: Die Workspace-Grenze hält beim Schreiben nicht, was sie
+zusagt (#373), und das eingestellte Log-Verzeichnis ist wirkungslos, weil ein relativer
+Pfad gegen das Arbeitsverzeichnis aufgelöst wird (#375). Beide sind auf der
+Zielplattform gefunden worden, beide sind unter Windows nicht sichtbar. Die Herleitung
+steht in Abschnitt 3.
+
+Danach stehen vier Dinge im Weg:
+
+1. **Auf Linux liegt der Hauptschlüssel im Klartext** (#190). Alles, was **neue**
+   Zugangsdaten anzieht — MCP-Konnektoren, Browser-Logins —, steht dahinter.
+2. **Die Freigabe-Ansicht fehlt** (#191). Staging ist gebaut und greift — aber
+   niemand kann freigeben. Damit ist der unbeaufsichtigte Betrieb, für den das
+   ganze Vorhaben da war, nicht möglich.
+3. **Die Chat-Frage ist unentschieden** (#181). Rocket.Chat ist gebaut und bedient
+   denselben Zweck, für den Matrix vorgesehen war. Solange das offen ist, hängen
+   Streaming, der Notfallkanal und ein Teil des Spiegels in der Luft.
+4. **Agenten können sich gegenseitig verklemmen** (#206). `AgentComm.send_message`
+   hat keine Tiefenbegrenzung; A→B→A blockiert bis zum Timeout. Bekannt seit Juli,
+   unverändert.
+
+### Der Vergleich mit Grok Bot
+
+Am 2026-08-23 gegen xAIs Grok Bot gehalten (Cloud-VM mit eigenem Browser, Terminal,
+MCP, acht Office-Konnektoren, Freigabe-Gates, Mehr-Bot-Betrieb). Ergebnis in einem Satz:
+Der Vorsprung liegt ausschließlich in der **Reichweite in die Welt** — Browser, Shell,
+MCP, Vision. In allem, was entscheidet, ob man so etwas unbeaufsichtigt laufen lässt,
+liegt ClawdDotNet vorn und teilweise dort, wo Grok Bot nichts hat: Audit mit gestempelter
+Herkunft, Receipts, Kosten pro Lauf, Budget-Guard, ein Gedächtnis, das man einsehen,
+korrigieren und sichern kann, Modellfreiheit über OpenRouter, Workspace-Trennung je Agent
+(Grok Bot teilt sich ausdrücklich *einen* Computer über alle Bots), Selbstbetrieb.
+Telegram und Rocket.Chat sind als Fernbedienung mehr, als Grok Bot anbietet.
+
+Die vier Lücken sind als #196 (Shell), #197 (MCP), #199 (Vision) und #200 (Browser)
+aufgenommen. Die Leitlinie bleibt unverändert: **erst Bremsen, dann PS.** Mehr Reichweite
+ohne Freigabe-Ansicht und ohne dichte Schlüsselablage wäre genau der falsche Tausch.
 
 ---
 
-## 1 — Reihenfolge
+## 1 — Stand aus dem Deploymentcenter
 
-Was als Nächstes ansteht, mit Begründung. Alles darunter in Abschnitt 3.
+<!-- dc:roadmap stand=2026-08-31T13:27Z items=97 projekt=clawddotnet -->
 
-| # | Vorhaben | Warum an dieser Stelle | Bereich |
+<!-- 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. **[FIX] #373 — PathBoundary.Canonicalize bricht bei nicht existierendem Pfadabschnitt ab - Symlink-Schutz greift beim Schreiben nie**
+2. **[FIX] #375 — Log-Verzeichnis aus den Einstellungen wird ignoriert - instance.logDirectory './Logs' gewinnt und wird gegen das Arbeitsverzeichnis aufgeloest**
+3. **[DEC] #180 — E10 entscheiden: Womit wird der Hauptschluessel unter Linux gebunden?**
+4. **[SEC] #190 — L1: Der Hauptschluessel liegt unter Linux im Klartext**
+
+### FIX — Kritische Befunde — vor allem anderen
+
+| | Vorhaben | Stand | Ziel |
 |---|---|---|---|
-| **1** | **Freigabe-Ansicht** (Rest von A2) | Der einzige Punkt, der echten Betrieb blockiert. Die Dienst-API steht vollständig; es fehlt eine Seite mit Liste und zwei Schaltflächen | [3.1](#31--kontrolle-und-sicherheit) |
-| **2** | **A5 entscheiden**: Matrix oder Rocket.Chat | Kostet keine Umsetzung, löst aber drei blockierte Punkte auf einmal. Deshalb früh | [2](#2--offene-entscheidungen) |
-| **3** | **FileRW-Papierkorb** | Kleinster Eingriff mit realer Wirkung: `delete` ist heute endgültig, ein Aufruf mit `path: "."` räumt einen Workspace ab. Danach kann `FileRW.delete` von `approve` auf `auto` — das entlastet die Freigabe-Ansicht sofort | [3.2](#32--agenten-fähigkeiten) |
-| **4** | **Delegationstiefe begrenzen** (B8) | Behebt eine echte Verklemmung. Kleiner Eingriff, aber am Agent-Gate — mit Test A13 aus der [Teststrategie](Teststrategie.md) | [3.3](#33--kommunikation-zwischen-agenten) |
-| **5** | **Output-Scrubbing** | Muss **vor** allem stehen, was Tool-Ergebnisse dauerhaft speichert (Agentenkommunikation Phase 2, MySQL-Spiegel). Sonst legen wir einen Speicher an, der nachträglich bereinigt werden müsste | [3.1](#31--kontrolle-und-sicherheit) |
-| **6** | **C1 Marktkalender** | Spart ab dem ersten Tag Geld: Ein `*/30`-Cron läuft heute auch Sonntag um 3 Uhr. Der Haken im Scanner ist schon da (`IMarketCalendar`) | [3.6](#36--finanz-und-analyse) |
-| **7** | **A4 Skills/Toolsets** | Größter Token-Hebel nach dem Caching, und Voraussetzung dafür, dass Agenten viele Tools haben können, ohne dass jeder Schritt teuer wird | [3.2](#32--agenten-fähigkeiten) |
-| **8** | **Historie-Umzug in die Instanz-DB** | Löst B10 (O(n²)-Schreiblast) und K6 (unbegrenzte Historie) in einem Zug und ist Voraussetzung für A6 | [3.4](#34--daten-und-speicher) |
-| — | **DC1 „Fehler melden"** | Zwischendurch; der Client steht, es fehlt die Schaltfläche | [3.5](#35--betrieb-und-auslieferung) |
-| — | **Hygiene-Paket** | Zwischendurch, unabhängig von allem | [3.7](#37--hygiene) |
+| #373 | PathBoundary.Canonicalize bricht bei nicht existierendem Pfadabschnitt ab - Symlink-Schutz greift beim Schreiben nie | 📋 Offen | — |
+| #375 | Log-Verzeichnis aus den Einstellungen wird ignoriert - instance.logDirectory './Logs' gewinnt und wird gegen das Arbe... | 📋 Offen | — |
 
-Leitlinie: **erst Bremsen, dann PS.** Ein Agent, der unbeaufsichtigt läuft, braucht
-Nachvollziehbarkeit und Kontrolle, bevor er mehr können soll. Deshalb stehen Freigabe,
-Papierkorb, Tiefenbegrenzung und Scrubbing vor den Fähigkeiten.
+### DEC — Offene Entscheidungen
+
+| | Vorhaben | Stand | Ziel |
+|---|---|---|---|
+| #180 | E10 entscheiden: Womit wird der Hauptschluessel unter Linux gebunden? | 📋 Offen | — |
+| #181 | E1 entscheiden: Matrix oder Rocket.Chat? | 📋 Offen | — |
+| #182 | E4 entscheiden: ask_agent behalten oder ersatzlos streichen? | 📋 Offen | — |
+| #183 | E2 entscheiden: Nextcloud-Identitaet - Dienstkonto oder Benutzer je Agent? | 📋 Offen | — |
+| #184 | E3 entscheiden: Oeffentliche Freigabe-Links erlauben oder hart sperren? | 📋 Offen | — |
+| #185 | E5 entscheiden: Notfallkanal-Reihenfolge instanzweit oder je Agent? | 📋 Offen | — |
+| #186 | E6 entscheiden: catchUp je Task abschaltbar machen? | 📋 Offen | — |
+| #187 | E7 entscheiden: Prioritaet bei mehreren faelligen Tasks - strikt oder gewichtet? | 📋 Offen | — |
+| #188 | E8 entscheiden: Aufbewahrungsdauer der Agentenkommunikation | 📋 Offen | — |
+| #189 | E9 entscheiden: Automatische Orderausfuehrung - ueberhaupt? | 📋 Offen | — |
+
+### SEC — Kontrolle und Sicherheit
+
+| | Vorhaben | Stand | Ziel |
+|---|---|---|---|
+| #190 | L1: Der Hauptschluessel liegt unter Linux im Klartext | 📋 Offen | — |
+| #191 | Freigabe-Ansicht: gestagte Aufrufe sichtbar machen und freigeben | 📋 Offen | — |
+| #192 | Output-Scrubbing: Secret-Werte zentral aus allen Tool-Ergebnissen maskieren | 📋 Offen | — |
+| #193 | Tool-Ergebnisse als untrusted content rahmen | 📋 Offen | — |
+| #194 | Secret-UI: Zugangsdaten setzen und rotieren | 📋 Offen | — |
+| #237 | Audit-Log und Receipts (A3, F-A2) | ✅ Erledigt | — |
+| #238 | Staging-Kern (A2, F-A1, S4) | ✅ Erledigt | — |
+| #249 | S1: SqlGuard statt Teilzeichenketten-Pruefung | ✅ Erledigt | — |
+| #250 | S2: YouTubeUrl und ArgumentList gegen Options-Injection | ✅ Erledigt | — |
+| #251 | S3: UrlSanitizer gegen API-Key-Leak ins Modell | ✅ Erledigt | — |
+| #252 | S5: UrlGuard, Redirects einzeln geprueft | ✅ Erledigt | — |
+| #253 | S6: WorkspacePath auf Verzeichnisgrenzen | ✅ Erledigt | — |
+| #254 | S7: SecretProtector mit DPAPI | ✅ Erledigt | — |
+| #255 | K5: Budget-Guard (F-A3) | ✅ Erledigt | — |
+
+### CAP — Agenten-Faehigkeiten
+
+| | Vorhaben | Stand | Ziel |
+|---|---|---|---|
+| #195 | FileRW-Papierkorb statt endgueltigem Loeschen | 📋 Offen | — |
+| #196 | L4: Shell-Tool mit echter Sandbox | 📋 Offen | — |
+| #197 | L5: MCP-Client fuer stdio- und HTTP-Server | 📋 Offen | — |
+| #198 | A4: Skills und Toolsets - dreischichtiger Prompt statt "alles immer" | 📋 Offen | — |
+| #199 | L6: Vision - Bild-Content-Blocks im OpenRouterClient | 📋 Offen | — |
+| #200 | L7: Browser-Tool mit Live-Ansicht | 📋 Offen | — |
+| #201 | Memory-Flush vor der Compaction | 📋 Offen | — |
+| #202 | Memory-Auto-Injection relevanter Abstracts | 📋 Offen | — |
+| #203 | Die Compaction laeuft nach dem API-Aufruf - der ueberfuellte Prompt ist da schon bezahlt | 📋 Offen | — |
+| #204 | AgentInspector: ein Supervisor-Agent, der die anderen beurteilen kann | 📋 Offen | — |
+| #205 | AgentEditor haerten: Aenderungen an Identity.md und Soul.md freigabepflichtig | 📋 Offen | — |
+| #239 | Taskboard (A1, F-A4, F-A5) | ✅ Erledigt | — |
+| #240 | Langzeitgedaechtnis (K1) | ✅ Erledigt | — |
+| #256 | B1 und B14: Compaction mit sicherem Schnittpunkt, kein doppelter System-Prompt | ✅ Erledigt | — |
+| #257 | B2: Chat-Laeufe je Agent serialisiert | ✅ Erledigt | — |
+| #258 | B3 und T5: maxCumulativeTokens von maxContextTokens getrennt | ✅ Erledigt | — |
+| #259 | B4: Prompt und Completion getrennt erfasst, Preise live vom /models-Endpunkt | ✅ Erledigt | — |
+| #260 | B5 und T2: Tool-Ergebnisse zentral gekappt | ✅ Erledigt | — |
+| #261 | B6 und B7: gegenstandslos, seit der Scanner die Delay-Schleifen ersetzt | ✅ Erledigt | — |
+| #262 | B11 und T8: max_tokens aus LoopGuard.MaxResponseTokens | ✅ Erledigt | — |
+| #263 | B12: Retry mit Backoff fuer 429 und 5xx | ✅ Erledigt | — |
+| #264 | T1 und T9: Prompt-Caching mit Breakpoints, cached_tokens gemessen | ✅ Erledigt | — |
+| #265 | T3: guenstiges Modell fuer die Zusammenfassung | ✅ Erledigt | — |
+| #266 | T7: durch die Assignee-Semantik des Taskboards beantwortet | ✅ Erledigt | — |
+
+### COMM — Kommunikation zwischen Agenten
+
+| | Vorhaben | Stand | Ziel |
+|---|---|---|---|
+| #206 | B8: AgentComm.send_message hat keine Tiefenbegrenzung - A nach B nach A verklemmt | 📋 Offen | — |
+| #207 | Agentenkommunikation Phase 1: ParentRunId und RootRunId | 📋 Offen | — |
+| #208 | Agentenkommunikation Phase 2: Nachrichtenspeicher AgentMessages mit FTS5 | 📋 Offen | — |
+| #209 | Agentenkommunikation Phase 3: ask_agent mit Tiefe 1 und Zykluspruefung | 🧊 Zurueckgestellt — Ausloeser: sobald E4 entschieden ist - ask_agent eng gefasst behalten oder ersatzlos streichen | — |
+| #210 | Agentenkommunikation Phase 4: Paar-Ansicht an den Datenbestand anschliessen | 🧊 Zurueckgestellt — Ausloeser: sobald Phase 2 steht und die Tabelle AgentMessages Daten fuehrt | — |
+| #211 | Agentenkommunikation Phase 5: AgentCommAnalysis | 📋 Offen | — |
+
+### DATA — Daten und Speicher
+
+| | Vorhaben | Stand | Ziel |
+|---|---|---|---|
+| #212 | Historie-Umzug in die Instanz-DB (loest B10 und K6) | 📋 Offen | — |
+| #213 | A6: MySQL-Spiegel als nachgelagerte Kopie | 🧊 Zurueckgestellt — Ausloeser: sobald der Historie-Umzug durch ist und E1 entschieden - der Server kommt gegebenenfalls mit der Chat-Entscheidung | — |
+| #241 | Atomares Schreiben nach dem File.Replace-Muster | ✅ Erledigt | — |
+| #242 | Speicher-Fundament: WAL, busy_timeout, Pooling, Schreib-Warteschlange | ✅ Erledigt | — |
+| #243 | Sicherung und Wiederherstellung | ✅ Erledigt | — |
+| #273 | Fruehjahrsputz: die automatische Sicherung war nie gestartet | ✅ Erledigt | — |
+| #274 | Fruehjahrsputz: doppelte Sicherungs-Einstellungen ueberschrieben einander | ✅ Erledigt | — |
+
+### OPS — Betrieb und Auslieferung
+
+| | Vorhaben | Stand | Ziel |
+|---|---|---|---|
+| #214 | L2: 24/7-Betriebsform unter Linux | 📋 Offen | — |
+| #215 | L3: Release-Strecke linux-x64 (DC3) | 📋 Offen | — |
+| #216 | DC1: Schaltflaeche "Fehler melden" in der Oberflaeche | 📋 Offen | — |
+| #217 | DC2: Bugtracker-Tool fuer Agenten | 📋 Offen | — |
+| #218 | Deploymentcenter-SDK von 2.6.0 auf 2.7.0 nachziehen | 📋 Offen | — |
+| #219 | DC4: SDK als Git-Submodul statt Cross-Repo-Pfad | 📋 Offen | — |
+| #220 | DC5: Evaluator-Cron einrichten (Betreiberaufgabe) | 📋 Offen | — |
+| #221 | Release-Guard beim Upload: ein frisches Produktverzeichnis steht ohne .htaccess da | 📋 Offen | — |
+| #222 | DC8: Die Signaturpflicht laesst sich ueber den empfohlenen Weg nicht einschalten | 🧊 Zurueckgestellt — Ausloeser: sobald LaunchUpdateAgent --require-signature durchreicht; ist unter deploymentcenter gemeldet | — |
+| #244 | Zugangsschutz: Lizenzschluessel als Basic-Auth zur Release-Ablage (DC 2.4) | ✅ Erledigt | — |
+| #245 | Update anwenden (DC6) | ✅ Erledigt | — |
+| #246 | Erstinstallation (DC7) | ✅ Erledigt | — |
+| #247 | Linux-Portierung der Bibliotheken | ✅ Erledigt | — |
+| #269 | Alt-Scheduler abgeloest - alles ist ein Task | ✅ Erledigt | — |
+| #270 | Deploymentcenter ersetzt WatchDog und LicenseLabrador | ✅ Erledigt | — |
+| #271 | DC3: Release-Strecke win-x64 | ✅ Erledigt | — |
+| #272 | Avalonia-Portierung, WinForms entfernt | ✅ Erledigt | — |
+
+### FIN — Finanz und Analyse
+
+| | Vorhaben | Stand | Ziel |
+|---|---|---|---|
+| #223 | C1: Marktkalender - Laeufe ausserhalb der Handelszeiten ueberspringen | 📋 Offen | — |
+| #224 | C2: Indikatoren im Code rechnen statt im Modell | 📋 Offen | — |
+| #225 | C3: dataAsOf wird geliefert, aber von nichts ausgewertet | 📋 Offen | — |
+| #226 | C4: Termine und Fundamentaldaten | 📋 Offen | — |
+| #227 | C5: Bestandsregister - stock_add ist eine Wissenssammlung, kein Bestand | 📋 Offen | — |
+| #228 | C6: Nachrichten-Entdopplung | 📋 Offen | — |
+| #229 | C7: Ergebnisregister AgentOutput am Lauf | 📋 Offen | — |
+| #230 | C8: Falsifizierbare Aussagen als Leistungsmass | 📋 Offen | — |
+| #231 | Leerlaufquote: Laeufe ohne greifbares Ergebnis zaehlen | 📋 Offen | — |
+| #232 | stock_add aus FileRW herausloesen | 📋 Offen | — |
+
+### HYG — Hygiene
+
+| | Vorhaben | Stand | Ziel |
+|---|---|---|---|
+| #233 | B9: index_Count-Race in FileRWTool | 📋 Offen | — |
+| #234 | B13: instanceId-Inkonsistenz zwischen RunAsync und SendMessageAsync | 📋 Offen | — |
+| #235 | DST-Randfall: eine nicht existierende Ortszeit wird uebersprungen statt verschoben | 📋 Offen | — |
+| #236 | 45 Nullable-Build-Warnungen | 📋 Offen | — |
+| #248 | Paket-Anhebungen gegen verwundbare transitive Fassungen | ✅ Erledigt | — |
+| #267 | K3: Testfundament | ✅ Erledigt | — |
+| #268 | Fruehjahrsputz: NU1903 und NU1902 geschlossen | ✅ Erledigt | — |
+
+<!-- /dc:roadmap -->
 
 ---
 
-## 2 — Offene Entscheidungen
+## 2 — Woher die Reihenfolge kommt
 
-Diese Punkte kann niemand bauen, bevor sie entschieden sind. Sie kosten kein
-Entwicklungsbudget, nur eine Festlegung.
+Der Rang eines Items ist keine Meinung, sondern das Ergebnis von fünf Regeln. Sie
+stehen hier, weil sie sich aus der Zahl allein nicht ablesen lassen.
 
-| # | Frage | Was daran hängt | Empfehlung aus dem Konzept |
-|---|---|---|---|
-| **E1** ❓ | **Matrix oder Rocket.Chat?** Rocket.Chat ist gebaut und bedient A5. Bleibt Matrix Ziel, oder entfällt A5? | K4 (Streaming), ob der `ChannelRouter` Pflicht oder Kür ist, wo A6 wohnt | Keine — bewusst offengelassen ([RocketChat-Konzept §4](RocketChat-Nextcloud-Konzept.md)) |
-| **E2** ❓ | **Nextcloud-Identität**: ein Dienstkonto mit Ordnern je Agent, oder je Agent ein eigener Benutzer? | Zuschnitt des Nextcloud-Tools | Dienstkonto |
-| **E3** ❓ | **Öffentliche Freigabe-Links** grundsätzlich erlauben (mit Freigabe) oder hart sperren? | Voreinstellung `allowPublicShares` | offen |
-| **E4** ❓ | **`ask_agent` behalten** (eng gefasst, Tiefe 1) oder ersatzlos streichen und alles über Tasks? | Zuschnitt von Phase 3 der Agentenkommunikation | behalten, eng gefasst |
-| **E5** ❓ | **Notfallkanal-Reihenfolge** instanzweit oder je Agent einstellbar? | Kleinigkeit am `ChannelRouter` | instanzweit |
-| **E6** ❓ | **`catchUp: true\|false`** je Task abschaltbar machen? | Verhalten des Scanners bei verpassten Terminen | offen |
-| **E7** ❓ | **Priorität bei mehreren fälligen Tasks**: strikt oder gewichtet? | Reihenfolge im Scanner | offen |
-| **E8** ❓ | **Aufbewahrungsdauer** der Agentenkommunikation | Vorgabewert im Speicher | unbegrenzt, bis A6 steht; dann 180 Tage lokal |
-| **E9** ❓ | **Automatische Orderausführung** — überhaupt? | Der gesamte Handels-Zweig. Broker-API, Teilausführungen, rechtlicher Rahmen — eigene Kategorie, kein Nebenprodukt der Analyse-Agenten | bewusst **nicht** vorgesehen |
+**Kritische Befunde stehen vor allem anderen** (Bereich `FIX`, seit dem 2026-08-31).
+Ein Fehler, der eine zugesicherte Grenze bricht oder den Betrieb auf der Zielplattform
+trifft, wird behoben, bevor ein weiteres Feature oder ein kleinerer Fehler angefasst
+wird. Der Bereich hat deshalb die Ränge unterhalb von 5 für sich.
+
+Das Aufnahmekriterium ist eng gefasst, damit der Bereich nicht zum zweiten Rücken
+für alles Dringliche wird: **entweder** die Software sagt eine Grenze zu, die sie
+nicht hält, **oder** der Befund verhindert den Linux-Betrieb, für den das Ganze gebaut
+ist. „Wichtig" allein genügt nicht — dafür gibt es den Rang.
+
+**Erst Bremsen, dann PS.** Ein Agent, der unbeaufsichtigt läuft, braucht
+Nachvollziehbarkeit und Kontrolle, bevor er mehr können soll. Deshalb stehen
+Schlüsselablage, Freigabe, Papierkorb, Tiefenbegrenzung und Scrubbing vor den
+Fähigkeiten — und die vier Reichweiten-Punkte #196, #197, #199, #200 dahinter, in
+dieser Reihenfolge.
+
+**Was den Betrieb blockiert, geht vor.** #190, #191, #214 und #215 sind zusammen die
+Bedingung dafür, dass die Zielmaschine überhaupt unbeaufsichtigt laufen und Updates
+bekommen kann.
+
+**Entscheidungen kosten kein Budget und lösen mehrere Punkte auf einmal.** Deshalb
+stehen #180 ganz vorn und #181 auf Rang 50 — beide kosten nur eine Festlegung.
+
+**Was nichts blockiert, rückt nach hinten.** Der Marktkalender (#223) und der
+Historie-Umzug (#212) waren nie durch die Plattform blockiert und blockieren selbst
+nichts. Der ganze Finanzteil ist bewusst nachgelagert: ClawdDotNet soll zuerst als
+allgemeiner Agenten-Client felsenfest sein, die handelsspezifischen Werkzeuge kommen
+danach.
+
+Zur Mechanik: `roadmap_rank` gilt in diesem Projekt **projektweit**, nicht je Bereich —
+die durchgehende Reihenfolge oben hängt daran. Wer einen Eintrag im WebUI innerhalb
+seines Bereichs verschiebt, schreibt den ganzen Bereich auf 10/20/30 um und verschiebt
+ihn damit auch gegenüber allen anderen Bereichen. Als Item 177 unter `deploymentcenter` gemeldet.
 
 ---
 
-## 3 — Beschlossen und offen
+## 3 — Begründungen
 
-### 3.1 — Kontrolle und Sicherheit
+Nicht jedes Vorhaben braucht eine Herleitung; die meisten sind eine Zeile wert und
+mehr nicht — die steht in der Beschreibung des Items. Hier steht, was mehr braucht.
 
-Bauplan: [Staging-Konzept](Staging-Konzept.md), [Audit-Konzept](Audit-Konzept.md).
+### [FIX] #373 — PathBoundary.Canonicalize fällt offen aus
 
-| Punkt | Herkunft | Stand | Was |
-|---|---|---|---|
-| Audit-Log + Receipts | F-A2, A3 | ✅ | Append-only auf SQLite. Herkunft wird von der Engine gestempelt, nie vom Agenten behauptet. Einträge unveränderlich, Korrekturen sind neue Einträge. Receipts verknüpfen Lauf ↔ Task mit Schritten, Tokens, Kosten |
-| Staging-Kern | F-A1, S4, A2 | ✅ | `PermissionGate` ist zum Durchsetzungspunkt ausgebaut. Policy `auto\|approve\|deny` je Tool/Aktion, Plan-Freeze (der eingefrorene Aufruf wird ausgeführt, nicht ein neu formulierter), atomarer Übergang `pending → approved`, Fortsetzung über Folge-Task statt pausiertem Lauf |
-| **Freigabe-Ansicht** | A2 | 📋 **#1** | Seite in `src/ClawdDotNet.Desktop`: offene Vorschläge listen, freigeben, ablehnen (mit Grund). `StagingService.ListPendingAsync/ApproveAsync/RejectAsync` steht bereit, `AppHost.Staging` reicht ihn durch. **Ohne sie liegt jeder gestagte Aufruf unbeantwortet** |
-| **Output-Scrubbing** | — | 📋 **#5** | Bekannte Secret-Werte aus dem Register des `SecretProtector` werden zentral aus **allen** Tool-Ergebnissen maskiert, bevor sie in Kontext, Historie, Audit-`Arguments` oder Spiegel gelangen. Ein Filter an `ExecuteToolCallAsync`. Schließt die Lücke, die S3 nur für URLs schloss |
-| Untrusted Content rahmen | K2-Rest | 📋 | Tool-Ergebnisse als Daten rahmen (`<untrusted_content>`) und im Kern-Prompt verankern, dass daraus keine Anweisungen befolgt werden. Staging nimmt die Schärfe, die Rahmung bleibt nötig — Finanzinhalte auf X und in Newslettern sind genau der Ort, an dem gezielt manipuliert wird |
-| Secret-UI | F-A6-Rest | 📋 | Oberfläche zum Setzen und Rotieren der Zugangsdaten. Die Verschlüsselung (S7, DPAPI) steht |
-| Audit-Export | — | 💭 | JSONL-Export für externe Auswertung. Passt zum A6-Spiegel |
+Gefunden am 2026-08-31 auf der Linux-Test-VM, Stand `7406497`. Zwei `[LinuxFact]`-Tests
+schlagen fehl, die unter Windows nie gelaufen sind — die in Abschnitt 0 genannten
+grünen Tests stammen von dort.
 
-### 3.2 — Agenten-Fähigkeiten
+`Canonicalize` löst jeden Pfadabschnitt einzeln auf und ruft für einen noch nicht
+existierenden Abschnitt `File.ResolveLinkTarget`. Der Aufruf gibt für einen fehlenden
+Pfad **nicht `null` zurück, sondern wirft `FileNotFoundException`** — eine
+`IOException`. Der `catch` darunter verlässt daraufhin die *gesamte* Auflösung mit
+`return full`, also mit dem unaufgelösten Pfad.
 
-| Punkt | Herkunft | Stand | Was |
-|---|---|---|---|
-| Taskboard | A1, F-A5, F-A4 | ✅ | Markdown + YAML-Frontmatter im `SharedWorkspace`, Zustand in der DB. Scanner im 60-s-Takt statt Delay-Schleifen, atomares Claiming (at-most-once), Startup-Reconciliation, `blocked_by` mit Auto-Dispatch, Blocker-Eskalation, Reopen über `task_comment`. Assignee entscheidet: `@new`, `@<agent>`, `@human`. Bauplan: [Taskboard-Konzept](Taskboard-Konzept.md) |
-| Langzeitgedächtnis | K1 | ✅ | Typisierte Tabelle statt JSON im State-Store. Scope `agent`/`shared`, optionaler `Key` (erneutes Merken aktualisiert statt anzulegen), Wichtigkeit steuert die Reihenfolge bei Kappung. Bauplan: [Memory-Konzept](Memory-Konzept.md) |
-| **FileRW-Papierkorb** | — | 📋 **#3** | `delete` verschiebt in einen Papierkorb je Workspace statt endgültig zu löschen; ein Cron-Task räumt nach X Tagen auf. Danach kann `FileRW.delete` im Staging von `approve` auf `auto`. Bauplan: [Umsetzungsplan](umsetzungsplaene/UMSETZUNGSPLAN-FileRW-Papierkorb-Cleanup.md) |
-| **A4 Skills/Toolsets** | T6 | 📋 **#7** | Dreischichtig statt „alles immer im System-Prompt": schlanker Dauerkern (hält den Prompt-Cache stabil), nachladbare Skills als `SKILL.md` mit Frontmatter (`list_toolsets` → `load_toolset`, bei vielen Skills stattdessen `skill_search`), Hot-Reload über `FileSystemWatcher` mit Debounce. Tool-Fehlermeldungen nennen die gültigen Parameter, statt das Modell raten zu lassen. **Agenten dürfen Skills aus Erfahrung selbst schreiben — aber erst nach Freigabe (A2) aktiv**, sonst ist es ein Injection-Kanal in künftige Läufe |
-| Memory-Flush vor Compaction | — | 📋 | Bevor der `ContextCompactor` zusammenfasst, bekommt der Agent ein eng begrenztes Fenster, Dauerhaftes per `memory_store` zu sichern — sonst wirft die Compaction Wissen weg. Harte Grenzen: max. 3–5 Schritte, einziges Tool `memory_store`, Timeout, günstiges Modell, höchstens einmal je Zyklus |
-| Memory-Auto-Injection | — | 📋 | Relevante Abstracts automatisch einblenden (Relevanzschwelle, Deckel ~200 Tokens). **In die Nutzernachricht, nie in den System-Prompt** — sonst verfällt der Prompt-Cache |
-| Proaktive Compaction | T4 | 📋 | `CompactIfNeededAsync` läuft heute **nach** dem API-Aufruf und nutzt die `promptTokens` der gerade bezahlten Anfrage — der überfüllte Prompt wurde also schon bezahlt. Vor dem Senden prüfen (`EstimateTokens` gibt es), gemessene Werte zur Kalibrierung |
-| AgentEditor härten | — | 📋 | Änderungen an `Identity.md`/`Soul.md` bleiben im laufenden Betrieb möglich, werden aber freigabepflichtig, nachvollziehbar und rücknehmbar. **Reihenfolge: nach AgentInspector.** Bauplan: [Umsetzungsplan](umsetzungsplaene/UMSETZUNGSPLAN-AgentEditor-Haertung.md) |
-| AgentInspector | — | 📋 | Ein Supervisor-Agent kann beurteilen, ob die anderen tun, was sie sollen — über Audit-Log, Taskboard und lesenden Zugriff auf fremde Workspaces. Heute geht nur die Selbstauskunft, und die ist als Kontrollinstrument wertlos. Bauplan: [Umsetzungsplan](umsetzungsplaene/UMSETZUNGSPLAN-AgentInspector-Supervisor.md) |
-| Memory-Verfall | — | 💭 | Alte, unwichtige Beobachtungen nach einer Frist entfallen lassen |
-| Task-Archivierung | — | 💭 | `done`/`canceled` nach einer Frist archivieren, damit `tasks/` nicht zuwächst |
-| Werkzeugwunsch | — | 💭 | Agenten bekommen in den Kern-Prompt den Hinweis, sich zu melden, wenn ihnen ein Werkzeug fehlt. Der Weg ist da — ein Task an `@human`. Gehört zum Prompt-Kern von A4 |
+**Warum das die erste Baustelle ist.** Die Symlink-Hälfte der Workspace-Grenze ist
+damit für jeden Pfad wirkungslos, dessen letzter Abschnitt noch nicht existiert — also
+für **jeden Schreibvorgang**. Betroffen sind `WorkspacePath` (das ist S6, #253, und das
+gilt als erledigt), `FtpTool` und der Zip-Slip-Schutz in `BackupService`. Der
+`catch`-Zweig ist im Quelltext ausdrücklich als „weist im Zweifel ab" kommentiert und
+verhält sich genau umgekehrt: Der unaufgelöste Pfad besteht die Präfixprüfung gerade
+deshalb.
 
-### 3.3 — Kommunikation zwischen Agenten
+Die Gegenseite desselben Fehlers trifft den Normalbetrieb, nicht nur den Angriffsfall:
+Liegt der Workspace selbst hinter einer Verknüpfung, sperrt er sich selbst aus.
 
-Bauplan: [Agentenkommunikation-Konzept](Agentenkommunikation-Konzept.md). **Nichts davon
-ist gebaut** — mit einer Ausnahme: Die Ansicht (Phase 4) steht bereits als
-`AgentChatsPageView` und wartet nur auf den Datenbestand aus Phase 2.
+Vorgabe für die Umsetzung: den fehlenden Abschnitt vor dem Aufruf abfangen und ihn
+unverändert übernehmen, statt die Schleife zu verlassen — das ist es, was der
+XML-Kommentar ohnehin zusagt. Der `catch (IOException)` darf den Pfad danach nicht
+mehr unaufgelöst durchreichen, sondern muss ihn als unbestimmbar melden. Beide
+Linux-Tests müssen grün werden, und der Fall „letzter Abschnitt existiert noch nicht,
+davor liegt eine Verknüpfung nach draußen" gehört als eigener Test dazu. Er ist
+derjenige, den die vorhandenen Tests nicht abdeckten.
 
-| Punkt | Herkunft | Stand | Was |
-|---|---|---|---|
-| **Delegationstiefe begrenzen** | B8 | 📋 **#4** | `AgentComm.send_message` ist ein synchroner Aufruf ohne Tiefenbegrenzung. A→B→A verklemmt echt: A hält sein Gate, während es auf B wartet — ruft B nun A, wartet B auf As Gate. Löst nur der Timeout auf. Test A13 der [Teststrategie](Teststrategie.md) deckt genau das ab und **fehlt bis heute** |
-| Phase 1 — Korrelation | — | 📋 | `ParentRunId` + `RootRunId` in Audit-Log und Receipts, von der Engine gestempelt. Eine Delegationskette wird damit zu einer Abfrage. Voraussetzung für alles Weitere |
-| Phase 2 — Nachrichtenspeicher | — | 📋 | Tabelle `AgentMessages` + FTS5, alle Wege gleich behandelt, beide Richtungen festgehalten. **Erst nach dem Output-Scrubbing** (#5) |
-| Phase 3 — `ask_agent` | — | ❄️ | Tiefe 1 mit Zyklusprüfung, Rückbau von `AgentComm`/`AgentSpawn`. Wartet auf E4 |
-| Phase 4 — Paar-Ansicht | — | ✅/❄️ | Auswahl, Filterung und Darstellung sind fertig; es fehlt genau eine Abfrage (`AgentChatsPageViewModel.LoadMessages`), sobald Phase 2 steht |
-| Phase 5 — `AgentCommAnalysis` | — | 📋 | Analyse-Tool, das findet, wo die Zusammenarbeit klemmt. Wer es bekommt, ist offen |
-| `@human`-Tasks mitschreiben | — | 💭 | Gäbe die Paar-Ansicht auch für Mensch↔Agent, fast ohne Zusatzaufwand. Vorschlag: ja, aber nach Phase 4 |
+### [FIX] #375 — Log-Verzeichnis wird gegen das Arbeitsverzeichnis aufgelöst
 
-### 3.4 — Daten und Speicher
+Gefunden am selben Tag, auf derselben Maschine. Zwei Ansichten derselben Anwendung
+widersprachen sich: Die Einstellungsseite zeigte
+`~/.local/share/clawddotnet/Logs`, die Info-Seite `~/clawddotnet-test/publish/Logs`.
+Auf der Platte gewinnt die zweite — die Info-Seite sagt die Wahrheit, das Feld in den
+Einstellungen ist wirkungslos.
 
-| Punkt | Herkunft | Stand | Was |
-|---|---|---|---|
-| Atomares Schreiben | — | ✅ | `File.Replace`-Muster. Es war bereits eine `TokenUsage.json` beschädigt worden |
-| Speicher-Fundament | — | ✅ | WAL, `busy_timeout`, Pooling, Schreib-Warteschlange im Prozess. Vorher gab es `database is locked` — das sah nach einer SQLite-Grenze aus, war aber fehlende Konfiguration |
-| Sicherung + Wiederherstellung | — | ✅ | ZIP mit Manifest und Prüfsummen, `VACUUM INTO` für die DB, Secrets wahlweise auf Passphrase umgeschlüsselt (PBKDF2 + AES-GCM) oder ausgelassen — DPAPI allein überlebt den Rechnerwechsel nicht, und genau dann braucht man das Backup. Rotation, Restore mit Vorschau, Zeitplan |
-| **Historie-Umzug** | K6, B10 | 📋 **#8** | `ChatHistory.json` zieht in die Instanz-DB: aktive Tabelle + Archiv-Tabelle mit FTS5 und `history_search`-Tool. Löst zugleich B10 — heute wird bei **jedem** Chat-Eintrag die vollständige Historie und der vollständige Kontext als eingerücktes JSON neu geschrieben (O(n²); bei 500 Nachrichten mehrere MB pro Nachricht). Migration nur nach frischem Backup, alte JSON erst nach verifiziertem Import löschen |
-| A6 MySQL-Spiegel | — | ❄️ | **SQLite bleibt die einzige Wahrheit.** MySQL ist reiner nachgelagerter Spiegel: empfängt nur vom Replikator, die App liest im Betrieb **nie** daraus. Outbox-Muster an der vorhandenen Schreib-Warteschlange, idempotente Upserts, nie blockierend. Zeilen tragen `instance_id`. **Der Restore-Pfad Spiegel → frische SQLite muss existieren und getestet sein** — gleiche Regel wie beim Backup. Wartet auf den Historie-Umzug und auf E1 (der Server kommt ggf. mit A5) |
-| MySQL-Gedächtnis | — | 💭 | Zweite `IMemoryRepository`-Implementierung, wenn mehrere Rechner dazukommen |
+`InstanceConfig.LogDirectory` ist mit `"./Logs"` vorbelegt, und
+`InstanceDirectoryManager` schreibt genau diesen Wert in jede neu angelegte
+`InstanceSettings.json`. Der Wert ist damit nie leer, der Zweig auf
+`settings.AppSettings.LogDirectory` in `AppHost` ist unerreichbar. `Path.GetFullPath`
+löst ohne Basis gegen das **Arbeitsverzeichnis des Prozesses** auf.
 
-### 3.5 — Betrieb und Auslieferung
+**Warum das hierher gehört und nicht in die Hygiene.** Der Zielbetrieb ist ein
+durchlaufender Dienst unter `/opt/clawddotnet` mit eigenem Dienstkonto (#214, #215).
+Ein systemd-Dienst ohne `WorkingDirectory` startet in `/`; dann zeigt `./Logs` auf
+`/Logs`, das ein Dienstkonto nicht anlegen kann. Im jetzigen Zustand schreibt die
+Anwendung stattdessen in ihr eigenes Installationsverzeichnis — das ein Update
+überschreibt. Der Befund blockiert damit denselben Betrieb, für den #214 und #215 da
+sind, und muss vor ihnen weg.
 
-WatchDog und LicenseLabrador sind durch das
-[Deploymentcenter](Deploymentcenter-Integration.md) ersetzt: eine Adresse, ein Token,
-dazu Update-Prüfung, Fehler-Stream und Bugtracker. Watchdog läuft pro Instanz.
+Die Pflichtliste des [Oberflächen-Leitfadens](Oberflaechen-Leitfaden.md) führt genau
+diesen Fall: „Keine relativen Pfade … zeigt unter Linux ins Leere."
 
-| Punkt | Herkunft | Stand | Was |
-|---|---|---|---|
-| Zugangsschutz | DC-2.4 | ✅ | Lizenzschlüssel als Basic-Auth-Zugang zur Release-Ablage. Benutzername wird als `lic_<sha256[0..16]>` abgeleitet — **die Ableitung muss auf beiden Seiten zeichengenau übereinstimmen, wer eine Seite ändert, sperrt die gesamte Installationsbasis aus** |
-| Update anwenden | DC6 | ✅ | Agent liegt im Paket (Prüfsumme geprüft), Rückfrage in der Oberfläche, geordnetes Herunterfahren vor dem Agentenstart, `maintenance` an den Watchdog |
-| Erstinstallation | DC7 | ✅ | `--action install` + `setup.json`, live durchgespielt (Login, Katalog, Token mit Rechteschranke) |
-| Release-Strecke | DC3 | ✅/📋 | Erledigt für `win-x64`/`dev` ([`deploy/publish.py`](../deploy/publish.py)). **Offen:** `linux-x64` — die Portierung, auf die das wartete, ist durch — und `prod` |
-| **DC1 „Fehler melden"** | DC1 | 📋 | Der Client steht, es fehlt die Schaltfläche in der Oberfläche |
-| DC2 Bugtracker-Tool | DC2 | 📋 | Agenten-Tool, das den Claim/Lease-Workflow des Deploymentcenters nutzbar macht |
-| DC4 SDK als Submodul | DC4 | 📋 | Heute ein Cross-Repo-Pfad (`..\..\..\Deploymentcenter\…` in `ClawdDotNet.App.csproj`) — auf einem anderen Rechner baut das nicht. Als Git-Submodul unter `external/`. Betrifft auch die CI |
-| DC5 Evaluator-Cron | DC5 | 📋 | Betreiberaufgabe: Cron einrichten, Token ausstellen, `parent_source` pflegen. **Ohne den Cron ist die Überwachung wertlos** |
-| DC8 Signaturpflicht | DC8 | ❄️ | Schlüssel steht, ab 0.1.2 wird signiert, Prüfung beidseitig getestet. **Blockiert:** `--require-signature` gibt es nur als Kommandozeilenschalter; `UpdateClient.LaunchUpdateAgent` — der empfohlene Weg — reicht ihn nicht durch. Selbst nachbauen hieße `--restart`, `--wait-for-pid` und `--wait-timeout` verlieren. Gemeldet |
-| Release-Guard beim Upload | — | 📋 | Veröffentlichen löst `regenerateForProject` nicht aus; ein frisches Produktverzeichnis steht bis zum nächsten Sechs-Stunden-Turnus ohne `.htaccess` da. Ein Aufruf am Ende von `publish` würde das Fenster schließen. **Betreiberseite** |
-| Linux-Betrieb | — | 📋 | Der Kern ist portabel: alle Bibliotheks- und Testprojekte auf `net10.0`, kein `DllImport`, keine Registry, kein `System.Drawing`. Windows steckt noch an drei Stellen — DPAPI, Groß-/Kleinschreibung bei Pfadvergleichen, Zeitzonen-IDs. Der teure Teil (8.900 Zeilen WinForms) ist mit der Avalonia-Portierung entfallen |
-| systemd-Dienst | — | 💭 | Kopfloser Betrieb. `ClawdDotNet.App` läuft bereits ohne Fenster — der Schichtschnitt ist genau dafür da. `NonInteractiveLicensePrompt` und `ConsoleLicensePrompt` liegen ungenutzt bereit |
+Vorgabe für die Umsetzung: Ein relativer Wert wird gegen `instance.WorkingDirectory`
+aufgelöst, nicht gegen das Arbeitsverzeichnis — das Feld steht bereits mit absolutem
+Pfad in der Datei und war offensichtlich so gemeint. Die Vorbelegung wandert auf einen
+absoluten Pfad unter `AppPaths.DataDirectory`, und bestehende `"./Logs"`-Einträge
+werden beim Laden migriert. Solange beides offen ist, ist das Feld auf der
+Einstellungsseite eine Lüge: Es lässt sich ändern und ändert nichts.
 
-### 3.6 — Finanz und Analyse
+### [DEC] #180 — E10: Womit wird der Hauptschlüssel unter Linux gebunden?
 
-Dieser Block ist bewusst **nachgelagert**: ClawdDotNet soll zuerst als allgemeiner
-Agenten-Client felsenfest sein, die handelsspezifischen Werkzeuge kommen danach.
+Secret Service (gnome-keyring über D-Bus) oder systemd-creds mit TPM2.
 
-| Punkt | Herkunft | Stand | Was |
-|---|---|---|---|
-| **C1 Marktkalender** | C1 | 📋 **#6** | Zwei Bausteine: `onlyWhenMarketOpen: "NYSE"` im Task-Frontmatter (der Lauf wird schlicht übersprungen, wirkt ohne Zutun des Modells) und ein `MarketCalendar`-Tool für Fragen des Agenten. Handelskalender ändern sich selten — eine gepflegte Datei reicht, keine externe Abhängigkeit. Der Haken im Scanner ist da |
-| C2 Indicators | C2 | 📋 | Gleitende Durchschnitte, RSI, ATR, Volatilität, Korrelation, Drawdown, Positionsgröße nach Risiko — **im Code gerechnet**. Sprachmodelle rechnen unzuverlässig, und die Zahlenkolonnen müssen dafür durch den Kontext. Spart Tokens *und* verbessert die Qualität |
-| C3 Datenaktualität | C3 | 📋 | `DirectAPI` liefert `dataAsOf` mit, aber nichts wertet es aus — ein Agent kann ungehindert auf drei Tage alten Kursen argumentieren. `maxAgeSeconds` je Tool: ablehnen oder unübersehbar kennzeichnen, nicht stillschweigend durchreichen |
-| C4 Termine und Fundamentaldaten | C4 | 📋 | Earnings, Dividenden, Splits, SEC EDGAR (8-K, 10-Q, 13F — frei und gut strukturiert), Wirtschaftstermine. Für „Finanznachrichten" ist der Kalender oft wichtiger als der Kurs |
-| C5 Bestandsregister | C5 | 📋 | `stock_add` ist eine Wissenssammlung, kein Bestand. Eigene Tabelle mit Positionen, auch rein zur Beobachtung. Grundlage für C7/C8 |
-| C6 Nachrichten-Entdopplung | C6 | 📋 | Dieselbe Meldung läuft über zehn Quellen — man zahlt zehnmal, und der Agent hält es für zehn unabhängige Signale. Das verzerrt die Einschätzung systematisch. `SeenItems` mit Prüfsumme über den normalisierten Titel plus Ähnlichkeitsabgleich |
-| C7 Ergebnisregister | C7 | 📋 | Tabelle `AgentOutput` am Lauf: Art, Betreff, Verweis. Macht aus „Kosten pro Lauf" die nützlichere Größe **Kosten pro Ergebnis**. Fällt weitgehend aus den A3-Receipts ab |
-| C8 Falsifizierbare Aussagen | C8 | 📋 | Das eigentliche Leistungsmaß. Der Agent legt sich fest (Subjekt, Aussage, Horizont, Konfidenz); ein Auflösungs-Task prüft gegen die tatsächlichen Kurse — kein Mensch muss bewerten. Daraus Trefferquote, **Brier-Score** (misst, ob die Konfidenz ehrlich war — ein Agent, der bei 0,9 nur in 60 % recht hat, ist überheblich, das bleibt bei reiner Trefferquote unsichtbar) und Vergleich gegen eine Nulllinie. **Unter 30 aufgelösten Aussagen keine Rangliste, nur Rohzahlen** — sonst optimiert man Rauschen. Braucht C5 und C7 |
-| Leerlaufquote | — | 📋 | Die wirksamste einfache Kennzahl: Läufe ohne greifbares Ergebnis. 40 % Leerlauf heißt meist Zeitplan-Problem — genau das, was C1 löst. Aus vorhandenen Daten |
-| `stock_add` herauslösen | T6 | 📋 | Fachfremdes Feature, das das `FileRW`-Schema für alle aufbläht, auch für Agenten, die es nie nutzen |
-| Orderausführung | — | 💭 | Siehe E9. Eigene Kategorie, ausdrücklich kein Nebenprodukt |
+**Empfehlung: Secret Service als Standard**, Backend über `CLAWD_SECRET_BACKEND`
+umschaltbar. Der Vorbehalt gehört dazu: Mit Autologin — und den brauchen wir für
+#214 — entsperrt sich der Keyring von selbst. Dann schützt er nur noch gegen andere
+Benutzer, nicht gegen den Zugang zur Maschine. Wer das nicht will, nimmt TPM2; es
+überlebt zudem einen Neustart ohne Menschen.
 
-### 3.7 — Hygiene
+Steht vor #190, weil die Antwort das Backend bestimmt, das dort gebaut wird.
 
-Kleinbugs, in einem Aufwasch zu erledigen.
+### [SEC] #190 — L1: Der Hauptschlüssel liegt unter Linux im Klartext
 
-| Punkt | Herkunft | Stand | Was |
-|---|---|---|---|
-| `index_Count`-Race | B9 | 📋 | `FileRWTool` ruft `index_Count` auf, nachdem das Lock freigegeben ist — Race mit parallelen `stock_add`, plus ein überflüssiges vollständiges Parsen. Der Zähler ist innerhalb des Locks ohnehin bekannt |
-| `instanceId`-Inkonsistenz | B13 | 📋 | `RunAsync`/`ChatAsync` bekommen `instanceId` als Parameter, `SendMessageAsync`/`SpawnAgentAsync` nutzen das Feld `_instanceId`, das nur bei `SetAgentConfigProvider` gesetzt wird — sonst leer. In Produktion unkritisch |
-| DST-Randfall | — | 📋 | Eine bei der Zeitumstellung nicht existierende Ortszeit („02:30" im Frühjahr) wird übersprungen statt verschoben. Tests R4/R5 der [Teststrategie](Teststrategie.md) |
-| Nullable-Warnungen | — | 📋 | 45 Build-Warnungen, Schwerpunkt `Mail` (basisnah) und `WebFetch`/`DirectAPI` (handelsnah) |
-| Paket-Anhebungen | — | ✅ | `SQLitePCLRaw.bundle_e_sqlite3` 2.1.13 und `SharpCompress` 0.48.0 stehen als **direkte Verweise, obwohl kein Code sie aufruft** — sie heben verwundbare transitive Fassungen an. Sehen aus wie toter Ballast und sind es nicht |
+`SecretKeyStore.Wrap` bindet den Schlüssel unter Windows per DPAPI ans Benutzerkonto
+und gibt ihn sonst ungewrappt zurück; der einzige Schutz ist dann `0600` aus
+`AppPaths.RestrictToOwner`. Auf einer dauerhaft laufenden, netzgebundenen Maschine ist
+das die erste Baustelle.
 
-### 3.8 — Tests
+**Der Migrationspfad ist der eigentliche Aufwand, nicht das Backend.** Die bestehenden
+Werte sind DPAPI-verschlüsselt und auf Linux nicht lesbar — `SecretProtector.UnprotectV1`
+wirft dafür bewusst. Der Weg ist gebaut: Backup **mit Passphrase** auf Windows ziehen
+(PBKDF2 + AES-GCM), auf Linux zurückspielen. Ohne Passphrase muss jeder Wert neu
+eingetragen werden. **Die Windows-Zweige bleiben deshalb stehen, bis der Umzug durch
+ist.**
 
-Grundlage: [Teststrategie](Teststrategie.md). Stand: 585 grün, 6 übersprungen.
+Vorgabe für die Umsetzung: erst der getestete Migrationspfad, dann das neue Backend.
+Ein Test, der beweist, dass ein ungewrappter Schlüssel nicht mehr geschrieben wird,
+gehört dazu — der Eingriff ist klein, die Folge eines Fehlers ist es nicht.
 
-| Punkt | Stand | Was |
-|---|---|---|
-| **A13** | 📋 | `send_message` A→B→A wird nach `maxDelegationDepth` abgebrochen statt zu verklemmen. Gehört zwingend zu Reihenfolge-Punkt #4 |
-| R4/R5 | 📋 | Zeitumstellung Oktober (feuert genau einmal) und März (wird nicht übersprungen) |
-| Oberfläche | — | Hat **keine** Testabdeckung. Die leisen Fehler (Fäden, unbegrenzt wachsende Listen, nicht behandeltes Fenster-Schließen) fallen ausschließlich beim Laufen auf — Abschnitt 4 des [Oberflächen-Leitfadens](Oberflaechen-Leitfaden.md) ist deshalb Pflichtlektüre vor jeder Abgabe |
+### [SEC] #191 — Freigabe-Ansicht
+
+Der einzige Punkt, der echten Betrieb blockiert. Die Dienst-API steht vollständig
+(`StagingService.ListPendingAsync/ApproveAsync/RejectAsync`, durchgereicht über
+`AppHost.Staging`); es fehlt eine Seite mit Liste und zwei Schaltflächen.
+
+Die dritte Schaltfläche **„Immer erlauben"** gleich mitnehmen: gibt frei *und* setzt
+die Policy für dieses Tool auf `auto`. Kostet fast nichts und ist der Unterschied
+zwischen einer Liste, die man täglich abarbeitet, und einer, die von selbst leer wird.
+
+Bauplan: [Staging-Konzept](Staging-Konzept.md).
+
+### [SEC] #192 — Output-Scrubbing
+
+Muss **vor** allem stehen, was Tool-Ergebnisse dauerhaft speichert — also vor #208
+(Nachrichtenspeicher) und #213 (Spiegel) — und vor #196, #197, #200, deren Ergebnisse
+voller Zugangsdaten sind. Schließt die Lücke, die S3 nur für URLs schloss.
+
+### [CAP] #195 — FileRW-Papierkorb
+
+Kleinster Eingriff mit realer Wirkung: `delete` ist heute endgültig, ein Aufruf mit
+`path: "."` räumt einen Workspace ab. Danach kann `FileRW.delete` von `approve` auf
+`auto` — das entlastet #191 sofort.
+
+Bauplan: [Umsetzungsplan](umsetzungsplaene/UMSETZUNGSPLAN-FileRW-Papierkorb-Cleanup.md).
+
+### [CAP] #196 — L4: Shell-Tool
+
+**Hochgestuft durch die Linux-Festlegung.** Der Punkt stand im Ideenspeicher, weil
+„sandboxed" unter Windows ein Versprechen war, das man nicht halten kann — unter Linux
+geht es, mit `bwrap` oder `systemd-run`, eigenem Mount-Namespace und Allowlist. Löst
+nebenbei die hartverdrahteten yt-dlp/ffmpeg-Aufrufe im `SocialMediaManagerTool` ab.
+
+**Die Sandbox ist die Funktion, nicht das Drumherum.** Erst festlegen, was garantiert
+wird (Mount-Namespace, Netz, Zeit, Ausgabe), dann bauen; jede Garantie mit einem Test,
+der den Ausbruch versucht.
+
+### [CAP] #197 — L5: MCP-Client
+
+Größter Reichweiten-Hebel pro Aufwand: macht fremde Konnektoren zur Konfigurationssache
+statt zum C#-Projekt. Das ist der Großteil von Grok Bots Konnektor-Vorsprung.
+stdio-Server (`npx`/`uvx`) laufen auf Linux nebenbei.
+
+**Voreinstellung `approve` für fremde Tools ist eine Invariante, kein Vorschlag** —
+sonst importiert man sich eine Policy-Lücke. Fremde Tool-Schemata sind Fremdeingaben:
+Namenskollisionen, Schema-Validierung, Ergebniskappung wie bei eigenen Tools.
+
+Nimmt dem `Http`-Tool aus dem Ideenspeicher die Dringlichkeit. Zusammen mit #198 denken —
+Toolsets und nachladbare Server sind dasselbe Problem: nicht alles immer im Prompt.
+
+### [CAP] #198 — A4: Skills und Toolsets
+
+Größter Token-Hebel nach dem Caching — und ohne Toolsets ertrinkt der Prompt in den
+Tools, die #197 hereinbringt.
+
+**Agenten dürfen Skills aus Erfahrung selbst schreiben — aber erst nach Freigabe
+aktiv**, sonst ist es ein Injection-Kanal in künftige Läufe.
+
+### [CAP] #200 — L7: Browser-Tool mit Live-Ansicht
+
+Größte Wirkung, größtes Risiko. Erst wenn #190, #191, #192 und #204 stehen.
+
+Der Bauplan gehört **vor** die erste Zeile Code: Umfang, Sitzungshaltung, Live-Ansicht
+und die Injection-Rahmung sind zusammen kein Auftrag, sondern ein Dokument. Der Grund,
+warum Chromium headed auf einem eigenen X-Display läuft und nicht auf der Sitzung des
+Benutzers: Agent und Mensch sollen sich nicht ins Fenster greifen. Der Grund für
+`x11vnc`: Es ist zugleich der Weg für Erstanmeldungen — **der Mensch loggt sich einmal
+von Hand ein, die Session bleibt im Profilverzeichnis, das Modell sieht die Zugangsdaten
+nie.**
+
+**Zwischenstufe mit einem Großteil des Nutzens und einem Bruchteil des Risikos:**
+`WebFetch` um gerendertes DOM und Cookie-Sessions erweitern, ohne Klick-Automatik.
+
+### [COMM] #206 — B8: `send_message` ohne Tiefenbegrenzung
+
+`AgentComm.send_message` ist ein synchroner Aufruf ohne Tiefenbegrenzung. A→B→A
+verklemmt echt: A hält sein Gate, während es auf B wartet — ruft B nun A, wartet B auf
+As Gate. Löst nur der Timeout auf.
+
+**Mit Vorsicht**: Der Eingriff sitzt am Agent-Gate, an dem schon einmal ein Deadlock
+lauerte. Erst Invarianten festlegen, dann bauen. Test A13 der
+[Teststrategie](Teststrategie.md) deckt genau das ab und **fehlt bis heute** — er ist
+Teil des Vorhabens, nicht ein Nachtrag.
+
+### [COMM] #209 — Phase 3: `ask_agent` (zurückgestellt)
+
+**Auslöser: sobald #182 (E4) entschieden ist.** Solange offen ist, ob `ask_agent` eng
+gefasst bleibt oder alles über Tasks läuft, ist der Zuschnitt von Phase 3 nicht
+bestimmbar. Empfehlung im Konzept: behalten, eng gefasst, Tiefe 1 mit Zyklusprüfung.
+
+### [COMM] #210 — Phase 4: Paar-Ansicht (zurückgestellt)
+
+**Auslöser: sobald #208 steht und `AgentMessages` Daten führt.** Auswahl, Filterung und
+Darstellung sind fertig — `AgentChatsPageView` steht. Es fehlt genau eine Abfrage in
+`AgentChatsPageViewModel.LoadMessages`. Zurückgestellt, nicht offen: Es gibt nichts zu
+bauen, solange die Tabelle leer ist.
+
+### [DATA] #212 — Historie-Umzug in die Instanz-DB
+
+Löst zwei Dinge in einem Zug. B10: Heute wird bei **jedem** Chat-Eintrag die
+vollständige Historie und der vollständige Kontext als eingerücktes JSON neu geschrieben
+— O(n²), bei 500 Nachrichten mehrere MB pro Nachricht. K6: unbegrenzte Historie.
+
+Migration nur nach frischem Backup, alte JSON erst nach verifiziertem Import löschen.
+Voraussetzung für #213.
+
+### [DATA] #213 — A6: MySQL-Spiegel (zurückgestellt)
+
+**Auslöser: sobald #212 durch ist und #181 entschieden — der Server kommt
+gegebenenfalls mit der Chat-Entscheidung.**
+
+**SQLite bleibt die einzige Wahrheit.** MySQL ist reiner nachgelagerter Spiegel:
+empfängt nur vom Replikator, die App liest im Betrieb **nie** daraus. Outbox-Muster an
+der vorhandenen Schreib-Warteschlange, idempotente Upserts, nie blockierend. Zeilen
+tragen `instance_id`. **Der Restore-Pfad Spiegel → frische SQLite muss existieren und
+getestet sein** — gleiche Regel wie beim Backup, und Teil der Definition of Done.
+
+### [OPS] #214 — L2: 24/7-Betriebsform
+
+Ohne systemd-Unit, Autologin und unterbundene Sitzungssperre ist „läuft durch" eine
+Behauptung. Klein, aber Voraussetzung für alles Unbeaufsichtigte. **Kein kopfloser
+Betrieb**: Die Oberfläche läuft laut Zielbetrieb immer mit.
+
+### [OPS] #215 — L3: Release-Strecke `linux-x64`
+
+Ohne sie gibt es auf der Zielmaschine kein Update. `deploy/publish.py` nimmt `--rid`
+schon entgegen, die Vorgabe steht noch auf `win-x64`. Der `win-x64`-Zweig bleibt vorerst
+als Ausweichweg.
+
+Dazu gehört die Linux-CI: **bis dahin sind die 585 grünen Tests eine Windows-Aussage.**
+
+### [OPS] #218 — Deploymentcenter-SDK von 2.6.0 auf 2.7.0 nachziehen
+
+Zwei brechende Änderungen im Changelog: Der Befundzustand aus
+`/api/supervisor/v1/observe` und `/status` heißt jetzt `finding_status`, und die
+Nachprüfungs-Status aus 2.6.1 müssen in eigenen Auswertungen eingeordnet werden —
+`awaiting_verification` und `in_verification` zählen **nicht** als offener Fehler,
+`fix_insufficient` schon.
+
+Danach die Fassungszeile in [CLAUDE.md](../CLAUDE.md) hochsetzen und `dc_link_project`
+aufrufen. Der Grund für beides: Ohne die Angabe muss beim nächsten Mal die gesamte
+Historie gelesen werden.
+
+### [OPS] #222 — DC8: Signaturpflicht (zurückgestellt)
+
+**Auslöser: sobald `UpdateClient.LaunchUpdateAgent` `--require-signature` durchreicht.**
+Ist unter `deploymentcenter` gemeldet.
+
+Der Schlüssel steht, ab 0.1.2 wird signiert, die Prüfung ist beidseitig getestet.
+`--require-signature` gibt es aber nur als Kommandozeilenschalter, und der empfohlene
+Weg reicht ihn nicht durch. Selbst nachbauen hieße `--restart`, `--wait-for-pid` und
+`--wait-timeout` verlieren — dafür ist der Gewinn zu klein.
+
+### [FIN] #223 — C1: Marktkalender
+
+Spart ab dem ersten Tag Geld: Ein `*/30`-Cron läuft heute auch Sonntag um 3 Uhr.
+
+Zwei Bausteine, und der erste ist der wichtige: `onlyWhenMarketOpen: "NYSE"` im
+Task-Frontmatter wirkt **ohne Zutun des Modells** — der Lauf wird schlicht übersprungen.
+Das Tool für Fragen des Agenten ist die Zugabe. Handelskalender ändern sich selten;
+eine gepflegte Datei reicht, keine externe Abhängigkeit. Der Haken im Scanner ist schon
+da (`IMarketCalendar`).
+
+### [FIN] #230 — C8: Falsifizierbare Aussagen
+
+Das eigentliche Leistungsmaß. Der Agent legt sich fest (Subjekt, Aussage, Horizont,
+Konfidenz); ein Auflösungs-Task prüft gegen die tatsächlichen Kurse — kein Mensch muss
+bewerten.
+
+Der **Brier-Score** ist der Grund, warum es nicht bei der Trefferquote bleibt: Er misst,
+ob die Konfidenz ehrlich war. Ein Agent, der bei 0,9 nur in 60 % der Fälle recht hat,
+ist überheblich — bei reiner Trefferquote bleibt das unsichtbar.
+
+**Unter 30 aufgelösten Aussagen keine Rangliste, nur Rohzahlen** — sonst optimiert man
+Rauschen. Braucht #227 und #229.
 
 ---
 
 ## 4 — Ideenspeicher
 
-Nicht beschlossen. Steht hier, damit es nicht verlorengeht — nicht, weil es demnächst
-gebaut wird.
+Nicht beschlossen und **bewusst keine Items**: Wer etwas nicht übernehmen kann, hat kein
+Vorhaben. Steht hier, damit es nicht verlorengeht — nicht, weil es demnächst gebaut wird.
 
 ### Tool-Kandidaten
 
-| Tool | 💭 Nutzen | Bemerkung |
+| Tool | Nutzen | Bemerkung |
 |---|---|---|
-| **WebSearch** | Agenten können heute nur bekannte Domains abrufen, aber nichts *finden*. Brave/Tavily/SearXNG | Bauplan liegt vor: [Umsetzungsplan](umsetzungsplaene/UMSETZUNGSPLAN-WebSearch-Tool.md). **Ausdrücklich zuletzt** — größter Sicherheitshebel, deshalb erst nach Papierkorb, Inspector und AgentEditor-Härtung |
-| **Nextcloud** | Ort, an dem Agenten Ergebnisse ablegen. Datei lokal erzeugen → hochladen → Link zurück in den Chat | Nextcloud hat keine API, die Inhalte *erzeugt*. Für PDF/XLSX kann Collabora als Konverter dienen. Bauplan: [RocketChat-Nextcloud-Konzept §5](RocketChat-Nextcloud-Konzept.md). Lohnt sich unabhängig vom Ausgang von E1 |
-| **Http** | Generisches REST-Tool mit Allowlist je Agent | `DirectAPI` ist fest auf Finanz-Provider verdrahtet — jede neue API erfordert heute Code |
-| **Shell** | Sandboxed, mit Kommando-Allowlist | Ersetzt die hartcodierten yt-dlp/ffmpeg-Aufrufe |
-| **Git** | Für den „Senior Developer"-Agenten | |
-| **Vision** | Charts und Screenshots analysieren | |
-| ~~Notify~~ | — | **Gestrichen**, geht in A5 auf |
+| **WebSearch** | Agenten können heute nur bekannte Domains abrufen, aber nichts *finden*. Brave/Tavily/SearXNG | Bauplan liegt vor: [Umsetzungsplan](umsetzungsplaene/UMSETZUNGSPLAN-WebSearch-Tool.md). **Spät** — großer Sicherheitshebel, deshalb erst nach Papierkorb, Inspector und AgentEditor-Härtung. Gehört zwischen #199 und #200 |
+| **Nextcloud** | Ort, an dem Agenten Ergebnisse ablegen. Datei lokal erzeugen → hochladen → Link zurück in den Chat | Nextcloud hat keine API, die Inhalte *erzeugt*. Für PDF/XLSX kann Collabora als Konverter dienen. Bauplan: [RocketChat-Nextcloud-Konzept §5](RocketChat-Nextcloud-Konzept.md). Lohnt sich unabhängig vom Ausgang von #181 |
+| **Http** | Generisches REST-Tool mit Allowlist je Agent | `DirectAPI` ist fest auf Finanz-Provider verdrahtet — jede neue API erfordert heute Code. **Weniger dringend seit #197**: Wo es einen MCP-Server gibt, braucht es kein eigenes REST-Tool |
+| **Git** | Für den „Senior Developer"-Agenten | Über #197 womöglich ohne eigenen Code zu haben |
+| **CollectionStore** | Schematisierte JSON/SQLite-Dokumenten-DB für Agenten | Ermöglicht strukturierte Tabellen/Sammlungen (z. B. Aktienanalysen, Kundenprofile) mit Schema-Validierung, Revisionshistorie und reinen Soft-Deletes. Bauplan: [Orchestrator-Erweiterungskonzept 2026 §3](Orchestrator-Erweiterungskonzept-2026.md) |
+| **ask_supervisor** | Erste Klärungsstufe vor `ask_human` | Agent befragt den leitenden Supervisor bei Unklarheiten. Erst bei Dissens Eskalation an den Menschen via Telegram/Rocket.Chat. Bauplan: [Orchestrator-Erweiterungskonzept 2026 §5](Orchestrator-Erweiterungskonzept-2026.md) |
+| ~~Shell~~ | — | **Beschlossen als #196** — unter Linux ist die Sandbox baubar |
+| ~~Vision~~ | — | **Beschlossen als #199** |
+| ~~Browser~~ | — | **Beschlossen als #200** — ganz hinten |
+| ~~Notify~~ | — | **Gestrichen**, geht in der Chat-Anbindung auf |
 
 ### Weitere Ideen
 
-| Idee | 💭 |
+| Idee | Bemerkung |
 |---|---|
-| Rocket.Chat Realtime/DDP statt Polling | Antwortzeit ~1 s statt ~30 s. Optional, Phase 6 |
-| Collabora-Konvertierung | Berichte in Büroformaten. Hängt an E-Frage 5 (ist der `convert-to`-Endpunkt freigebbar?) |
-| `ChannelRouter` + Eskalation | Erkennt den Ausfall des Chat-Kanals und weicht auf Telegram aus. **Kein Nice-to-have**, sobald der Chat der Hauptweg ist — sonst ist er ein Einzelpunkt, dessen Ausfall niemand meldet. Hängt an E1 |
-| K4 Streaming | ❄️ Zurückgestellt bis E1 entschieden ist — Matrix streamt nicht |
+| Audit-Export als JSONL | Für externe Auswertung. Passt zum Spiegel #213 |
+| Memory-Verfall & Task-Flush | Alte, unwichtige Beobachtungen nach einer Frist entfallen lassen; bei Task-Abschluss selektiver Memory-Commit und Kontext-Reset. [Orchestrator-Erweiterungskonzept 2026 §3](Orchestrator-Erweiterungskonzept-2026.md) |
+| Scratchpad-Lifecycle | `scratch/t-<id>.md` bei `done`/`canceled` atomar nach `archive/` verschieben und nach Frist bereinigen |
+| Hybride State-Graphs | Deterministische Pflichtschritte mit agentischer Autonomie über deklarative YAML-Pipelines kombinieren |
+| Multi-Agenten-Debatten & Judge-Agent | Arbeiter-Kritiker-Zyklen mit maximal 3 Runden und Schiedsrichter-Entscheidung durch den Supervisor |
+| Ephemere Worker mit Budget-Cap | Kurzlebige Subagenten für Parallel-Jobs; Budget per CAS vorab reserviert, `RootRunId` vererbt |
+| Mid-Execution Priority Injects | Eilmeldungen von Monitor-Agenten (z. B. Ad-hoc-Zahlen) vor dem nächsten Step in den Kontext einspeisen |
+| 5-Stufen Schutz vor Amoklauf | Soft-Deletes, Rate-Limits, Quarantäne-Circuit-Breaker und 1-Klick-Rollback via RunId-Audit |
+| Multi-LLM Fallback & Evals | Primär- und Fallback-Modell je Agent; Test-Runner zum quantitativen Modell- und Prompt-Vergleich |
+| Dynamische Prompt-Templates | Scriban/Liquid-Variablen (`{{team_roster}}`) in `Identity.md`/`Soul.md` für dynamische Teamerkennung |
+| `ext_clitools/` Struktur | Einheitliche Ablage externer Binaries (`ffmpeg`, `yt-dlp`, `typst`) im Build-Prozess |
+| Task-Archivierung | `done`/`canceled` nach einer Frist archivieren, damit `tasks/` nicht zuwächst |
+| Werkzeugwunsch | Agenten bekommen in den Kern-Prompt den Hinweis, sich zu melden, wenn ihnen ein Werkzeug fehlt. Der Weg ist da — ein Task an `@human`. Gehört zum Prompt-Kern von #198 |
+| `@human`-Tasks mitschreiben | Gäbe die Paar-Ansicht auch für Mensch↔Agent, fast ohne Zusatzaufwand. Nach #210 |
+| MySQL-Gedächtnis | Zweite `IMemoryRepository`-Implementierung, wenn mehrere Rechner dazukommen |
+| Kern als Dienst, Oberfläche als Client | Heute hostet `ClawdDotNet.Desktop` den `AppHost` **in-process**; damit leben die Agenten im UI-Prozess — ein Absturz der Oberfläche nimmt sie mit, und genau die Oberfläche hat keine Testabdeckung. Der Schichtschnitt gäbe die Trennung her, der `AppHost` ist die Naht. **Notiert, nicht beschlossen** — lohnt sich, sobald der erste UI-Absturz eine Nacht Agentenarbeit kostet. Bis dahin trägt #214 |
+| Rocket.Chat Realtime/DDP statt Polling | Antwortzeit ~1 s statt ~30 s |
+| Collabora-Konvertierung | Berichte in Büroformaten. Hängt daran, ob der `convert-to`-Endpunkt freigebbar ist |
+| `ChannelRouter` + Eskalation | Erkennt den Ausfall des Chat-Kanals und weicht auf Telegram aus. **Kein Nice-to-have**, sobald der Chat der Hauptweg ist — sonst ist er ein Einzelpunkt, dessen Ausfall niemand meldet. Hängt an #181 |
+| K4 Streaming | Hängt an #181 — Matrix streamt nicht |
+| Orderausführung | Siehe #189. Eigene Kategorie, ausdrücklich kein Nebenprodukt |
 
 ---
 
-## 5 — Erledigt
+## 5 — Woher das hier kommt
 
-Damit die Chronik nicht mit den alten Papieren verschwindet.
-
-**Sicherheit:** S1 `SqlGuard` statt Teilzeichenketten-Prüfung · S2 `YouTubeUrl` +
-`ArgumentList` gegen Options-Injection · S3 `UrlSanitizer` gegen API-Key-Leak ins Modell ·
-S4 `PermissionGate` zum Durchsetzungspunkt ausgebaut (in A2 aufgegangen) · S5 `UrlGuard`,
-Redirects einzeln geprüft · S6 `WorkspacePath` auf Verzeichnisgrenzen · S7
-`SecretProtector` (DPAPI).
-
-**Bugs:** B1/B14 Compaction — sicherer Schnittpunkt, kein doppelter System-Prompt ·
-B2 Chat-Läufe je Agent serialisiert · B3/T5 `maxCumulativeTokens` von `maxContextTokens`
-getrennt · B4 Prompt/Completion getrennt erfasst, Preise live vom `/models`-Endpunkt ·
-B5/T2 Tool-Ergebnisse zentral gekappt · B6/B7 gegenstandslos, seit der Scanner die
-Delay-Schleifen ersetzt · B11/T8 `max_tokens` aus `LoopGuard.MaxResponseTokens` ·
-B12 Retry mit Backoff für 429/5xx.
-
-**Konzepte:** K1 Gedächtnis · K3 Testfundament · K5 Budget-Guard (F-A3) · A1 Taskboard
-(mit F-A4, F-A5) · A3 Audit-Log (F-A2) · A2-Kern.
-
-**Token:** T1/T9 Prompt-Caching mit Breakpoints, `cached_tokens` gemessen · T3 günstiges
-Modell für die Zusammenfassung · T7 durch die Assignee-Semantik des Taskboards
-beantwortet.
-
-**Betrieb:** Alt-Scheduler abgelöst — `AgentScheduler`, `ToolJobScheduler` und
-`SchedulerDelay` gelöscht, alles ist ein Task · Atomares Schreiben · Backup und Restore
-inkl. Oberfläche · Deploymentcenter statt WatchDog und LicenseLabrador · DC3 (win-x64),
-DC6, DC7, Zugangsschutz 2.4 · Avalonia-Portierung, WinForms entfernt.
-
-**Frühjahrsputz 2026-08-23:** automatische Sicherung war nie gestartet · doppelte
-Sicherungs-Einstellungen auf der Einstellungsseite überschrieben die der Sicherungsseite ·
-NU1903 und NU1902 geschlossen.
-
----
-
-## 6 — Modell-Einstufung
+### Modell-Einstufung
 
 Die Entwicklung läuft mit Opus 4.6. Die meisten Vorhaben sind damit gut machbar, sofern
-die hier notierten Vorgaben mitgegeben werden. Die zwei ursprünglich für Opus 5 / Fable
-markierten Stellen sind inzwischen gebaut — die Begründung bleibt stehen, weil sie
-erklärt, *warum* es so gebaut ist.
+die in Abschnitt 3 notierten Vorgaben mitgegeben werden. Drei Punkte sind markiert:
 
-| Vorhaben | Einstufung | Vorgabe |
+| Vorhaben | Einstufung | Warum |
 |---|---|---|
-| ✅ A1 Scanner-Kern | war ⚠️ Opus 5 / Fable | At-most-once, Claim-CAS, Zusammenspiel mit den serialisierten Chat-Läufen — genau die Fehlerklasse, die hier schon einmal schiefging. Gebaut mit Property-Tests für die Invarianten |
-| ✅ A2 Fortsetzung nach Freigabe | 4.6 mit Vorgabe | **Kein pausierter, im Speicher gehaltener Lauf.** Der Lauf endet beim Staging regulär, die Freigabe erzeugt einen Folge-Task mit dem eingefrorenen Aufruf. Echtes Suspend/Resume wäre Fable-Terrain — und ist damit unnötig |
-| Freigabe-Ansicht | 4.6 | Reine Oberflächenarbeit gegen eine fertige API |
-| Delegationstiefe (B8) | ⚠️ **mit Vorsicht** | Fasst das Agent-Gate an, an dem schon ein Deadlock lauerte. Erst Invarianten festlegen, dann bauen, Test A13 zwingend |
-| Output-Scrubbing | 4.6 | Ein zentraler Filter an `ExecuteToolCallAsync`, Werte aus dem Secret-Register |
-| A4 Skills | 4.6 | `FileSystemWatcher` mit Debounce (~500 ms); agentengeschriebene Skills erst nach Freigabe aktiv |
-| Memory-Flush vor Compaction | 4.6 mit Anleitung | Der `ContextCompactor` hatte B1/B14 — die bestehenden Paarungs-Tests müssen unverändert grün bleiben |
-| Historie-Umzug + FTS5 | 4.6 | Migration nur nach frischem Backup; alte JSON erst nach verifiziertem Import löschen |
-| A6 MySQL-Spiegel | 4.6 mit Anleitung | Outbox mit Wasserzeichen, idempotente Upserts, nie blockieren. **Der getestete Restore-Pfad ist Teil der Definition of Done** |
-| C1, C2 | 4.6 | Reine Fachlogik, deterministisch testbar |
+| #206 Delegationstiefe | ⚠️ **mit Vorsicht** | Fasst das Agent-Gate an, an dem schon ein Deadlock lauerte. Erst Invarianten, dann bauen, Test A13 zwingend |
+| #196 Shell | ⚠️ **mit Vorsicht** | Die Sandbox ist die Funktion. Jede Garantie mit einem Test, der den Ausbruch versucht |
+| #200 Browser | ⚠️ **eigener Bauplan zuerst** | Nicht als ein Auftrag umsetzbar |
+
+Zwei ursprünglich für ein stärkeres Modell markierte Stellen sind inzwischen gebaut. Die
+Begründung bleibt stehen, weil sie erklärt, *warum* es so gebaut ist:
+
+- **Der Scanner-Kern**: At-most-once, Claim-CAS, Zusammenspiel mit den serialisierten
+  Chat-Läufen — genau die Fehlerklasse, die hier schon einmal schiefging. Gebaut mit
+  Property-Tests für die Invarianten.
+- **Die Fortsetzung nach Freigabe**: **Kein pausierter, im Speicher gehaltener Lauf.**
+  Der Lauf endet beim Staging regulär, die Freigabe erzeugt einen Folge-Task mit dem
+  eingefrorenen Aufruf. Echtes Suspend/Resume wäre eine Nummer größer gewesen — und ist
+  damit unnötig.
 
 Generell: Neue Subsysteme kommen mit Tests nach der [Teststrategie](Teststrategie.md).
 Bei den markierten Punkten sind die Invarianten-Tests kein Nice-to-have, sondern die
 Absicherung dafür, dass ein schwächeres Modell sie umsetzen darf.
 
----
-
-## 7 — Woher das hier kommt
-
 ### Weiter gültig — Baupläne
 
-Aus der Roadmap verlinkt. Wer einen Punkt anfasst, liest das zugehörige Dokument.
+Wer einen Punkt anfasst, liest das zugehörige Dokument zuerst.
 
 | Dokument | Wofür |
 |---|---|
 | [Taskboard-Konzept](Taskboard-Konzept.md) | Dateiformat, Wahrheitsaufteilung Datei/DB, Scanner-Verhalten, Invarianten |
 | [Audit-Konzept](Audit-Konzept.md) | Schema, Provenance-Regeln, Receipts |
-| [Staging-Konzept](Staging-Konzept.md) | Policy-Auflösung, Plan-Freeze, Fortsetzung nach Freigabe — **Bauplan für Punkt #1** |
+| [Staging-Konzept](Staging-Konzept.md) | Policy-Auflösung, Plan-Freeze, Fortsetzung nach Freigabe — **Bauplan für #191** |
 | [Memory-Konzept](Memory-Konzept.md) | Modell, Schlüssel-Semantik, Abrufreihenfolge |
 | [Agentenkommunikation-Konzept](Agentenkommunikation-Konzept.md) | Fünf Phasen, Korrelation, Nachrichtenspeicher |
 | [RocketChat-Nextcloud-Konzept](RocketChat-Nextcloud-Konzept.md) | Rocket.Chat gebaut; Nextcloud, Rückweg und `ChannelRouter` offen. Enthält die Messung gegen die echte Instanz |
 | [Deploymentcenter-Integration](Deploymentcenter-Integration.md) | Wie Heartbeat, Fehler-Stream, Bugtracker und Updates verdrahtet sind |
+| [Orchestrator-Erweiterungskonzept-2026](Orchestrator-Erweiterungskonzept-2026.md) | Kollaborationsmuster, Schematisierte DB, Gedächtnis-Hygiene, Amoklauf-Schutz, Fallbacks |
 | [umsetzungsplaene/](umsetzungsplaene/) | Vier Detailpläne: FileRW-Papierkorb, AgentInspector, AgentEditor-Härtung, WebSearch |
 
 ### Weiter gültig — Handbücher
 
 | Dokument | Wofür |
 |---|---|
-| [Oberflaechen-Leitfaden](Oberflaechen-Leitfaden.md) | Arbeiten an `ClawdDotNet.Desktop`: Schichtschnitt, Fäden, Avalonia-12-Fallen, Prüfliste |
+| [Oberflaechen-Leitfaden](Oberflaechen-Leitfaden.md) | Arbeiten an `ClawdDotNet.Desktop`: Schichtschnitt, Fäden, Avalonia-12-Fallen, Prüfliste. Die Oberfläche hat **keine** Testabdeckung — Abschnitt 4 ist deshalb Pflichtlektüre vor jeder Abgabe |
 | [ToolDevelopmentGuide](ToolDevelopmentGuide.md) | Ein neues Agenten-Tool bauen |
 | [InstanceSetupGuide](InstanceSetupGuide.md) | Eine Instanz einrichten |
 | [Teststrategie](Teststrategie.md) | Was wie getestet wird, Fallkatalog |
 
 ### Archiviert
 
-Vollständig in dieses Dokument überführt. Sie bleiben als Begründung und Herkunft
-lesbar, werden aber **nicht mehr fortgeschrieben** — siehe [docs/archiv/](archiv/).
+Vollständig überführt. Sie bleiben als Begründung und Herkunft lesbar, werden aber
+**nicht mehr fortgeschrieben** — siehe [docs/archiv/](archiv/).
 
 | Dokument | Was daraus wurde |
 |---|---|
-| `Bestandsaufnahme-2026-07.md` | S1–S7, B1–B14, K1–K6, T1–T9, F-A1…F-A7 — erledigte in Abschnitt 5, offene in 3.1/3.2/3.7 |
-| `Konzepte-Backup-Finanz-Analyse.md` | Backup ✅; Finanzteil als C1–C6; Leistungsanalyse als C7/C8 und Leerlaufquote |
-| `Linux-Portierung-Analyse.md` | Die drei Kernstellen und das `linux-x64`-Release in 3.5. Der teure Teil (WinForms) ist entfallen |
+| `Bestandsaufnahme-2026-07.md` | S1–S7, B1–B14, K1–K6, T1–T9, F-A1…F-A7 — als Items im Block oben |
+| `Konzepte-Backup-Finanz-Analyse.md` | Backup erledigt; Finanzteil als #223–#228, Leistungsanalyse als #229/#230 und Leerlaufquote |
+| `Linux-Portierung-Analyse.md` | Die drei Kernstellen und das `linux-x64`-Release. Der teure Teil (WinForms) ist entfallen |
 | `Lizenz-HardwareId-v2-Implementierungsvorschlag.md` | **Gegenstandslos** — LicenseLabrador ist durch das Deploymentcenter ersetzt |
-| `Deploymentcenter-Anbindung-Review.md` | Befunde behoben, in 3.5 aufgegangen |
-| `Deploymentcenter-2.4-Integrationsplan.md` | DC-Punkte in 3.5, inklusive der blockierten Signaturpflicht und der Betreiber-Restpunkte |
+| `Deploymentcenter-Anbindung-Review.md` | Befunde behoben |
+| `Deploymentcenter-2.4-Integrationsplan.md` | Als #216–#222 |
 | `ClawdDotNet_StartPrompt.md` und die drei Prompt-Anhänge | Entwicklungs-Prompts der Anfangszeit. Eine Regel gilt weiter: die Pflichtfelder `fetchedAt`/`dataAsOf`/`source` der Internet-Tools |
+
+### Die frühere Fassung dieser Datei
+
+Bis zum 2026-08-30 führte diese Datei den Zustand selbst: Statustabellen mit den
+Markern ✅📋❓❄️💭, eine Reihenfolgetabelle von 0 bis 14 und eine Chronik des Erledigten. Alles
+davon liegt jetzt im Deploymentcenter — 95 Items, die alte Kennung steht im Titel
+(`S1`, `B8`, `C1`, `L1`, `DC4` …), damit die archivierten Papiere auffindbar bleiben.
+
+Die Übernahme lief über [deploy/roadmap/import_items.py](../deploy/roadmap/import_items.py);
+den Zustandsblock oben schreibt
+[deploy/roadmap/roadmap_block.py](../deploy/roadmap/roadmap_block.py) `--write`,
+den Abgleich fährt dasselbe Skript mit `--check`.