Eine Roadmap statt neun verteilter Listen

Der Stand lag ueber eine Bestandsaufnahme, drei Konzeptpapiere, vier
Umsetzungsplaene und zwei Deploymentcenter-Dokumente verteilt - jedes mit
eigener Reihenfolge, teils widersprueglich. Alle offenen Punkte daraus sind
in docs/Roadmap.md zusammengefuehrt.

Aufbau der neuen Roadmap
- Statusvokabular: erledigt / beschlossen-offen / Entscheidung noetig /
  zurueckgestellt / Idee. Damit steht das Geparkte sichtbar drin, statt in
  einem Konzeptpapier zu verschwinden.
- Herkunft-Spalte traegt das alte Kuerzel (S4, K2, B9, T4, F-A1, C1, DC1),
  damit die archivierten Papiere auffindbar bleiben, ohne sie zu lesen.
- Abschnitt 1 Reihenfolge, 2 offene Entscheidungen, 3 die Vorhaben nach
  Bereich, 4 Ideenspeicher, 5 Chronik des Erledigten, 6 Modell-Einstufung,
  7 Herkunftskarte.

Was dabei sichtbar wurde
- Neun Entscheidungen blockieren Arbeit, ohne dass sie Aufwand kosten -
  allen voran Matrix oder Rocket.Chat. Sie stehen jetzt gesammelt in
  Abschnitt 2 statt verstreut in den Diskussionsteilen der Konzepte.
- B8 (keine Tiefenbegrenzung bei AgentComm) ist unveraendert offen. Das ist
  keine Theorie: A haelt sein Gate, waehrend es auf B wartet - ruft B nun A,
  warten beide bis zum Timeout. Der Testfall A13 dafuer fehlt bis heute.
- Die vier Umsetzungsplaene vom 2026-08-05 sind alle unumgesetzt und waren
  in keiner Roadmap verzeichnet.

Archiv
Sechs Dokumente ziehen nach docs/archiv/: Bestandsaufnahme, Konzepte
Backup/Finanz/Analyse, Linux-Portierung-Analyse, Lizenz-HardwareId-v2
(gegenstandslos - LicenseLabrador ist ersetzt), Deploymentcenter-Review und
der 2.4-Integrationsplan. Sie bleiben als Begruendung lesbar, werden aber
nicht mehr fortgeschrieben; das README ordnet jedes einzeln ein und warnt,
dass ihre Quelltext-Verweise ins Leere gehen koennen.

Bauplan bleibt Bauplan
Taskboard, Audit, Staging, Memory, Agentenkommunikation, RocketChat und
Deploymentcenter-Integration bleiben in docs/ - sie sind die Detailvorgabe
fuer die Umsetzung, nicht Vorhabenlisten. Jedes bekommt oben eine Zeile,
die seine Rolle und den Umsetzungsstand nennt und auf die Roadmap zeigt.
Dasselbe fuer die vier Umsetzungsplaene: die Reihenfolge gilt in der
Roadmap, nicht im Plan.

Nebenbei repariert: Taskboard-Konzept und Teststrategie verwiesen auf
AgentScheduler und ToolJobScheduler, die seit der Scanner-Konsolidierung
geloescht sind. Alle Dokument-Verweise in docs/ sind geprueft.

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

docs/Roadmap.md

@@ -1,355 +1,345 @@
-# Roadmap
+# ClawdDotNet — Roadmap
 
-**Stand: 2026-08-23** (Frühjahrsputz). Was seither gilt:
+**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.
 
-| Bereich | Stand |
-|---|---|
-| A1 Taskboard | **erledigt** — Dateiformat, Scanner mit Claiming, `task_*`-Tool, Migration, Tests |
-| A3 Audit-Log | **erledigt** — append-only auf SQLite, Engine stempelt die Herkunft |
-| A2 Staging | **halb** — Gate, Policy, Ablage und Dienst stehen und greifen; **die Freigabe-Ansicht fehlt.** Bis sie da ist, legt ein Agent Vorschläge ab, die niemand freigeben kann |
-| Oberfläche | **portiert** — neun Bereiche nativ in Avalonia, Entwurf aus `Mockup/` umgesetzt. Die WinForms-Fassung ist entfernt (Tag `vor-fruehjahrsputz-2026-08`) |
-| Rocket.Chat | Tool umgesetzt und registriert. **Damit steht A5 zur Entscheidung an** — siehe unten |
-| Pakete | keine bekannten Sicherheitslücken mehr; `SharpCompress` und `SQLitePCLRaw.bundle_e_sqlite3` sind als Anhebung direkt verwiesen |
-
-Die vier [Umsetzungspläne](umsetzungsplaene/) vom 2026-08-05 sind **alle noch offen**:
-FileRW-Papierkorb, AgentInspector, AgentEditor-Härtung, WebSearch. Ihre Reihenfolge
-steht in den Dokumenten selbst; sie sind hier nicht doppelt eingeordnet.
+Gepflegt wird nur noch dieses Dokument. Was aus den alten Papieren wurde, steht in
+[Abschnitt 7](#7--woher-das-hier-kommt).
 
 ---
 
-Zentrale Liste aller offenen Vorhaben. Sie löst die beiden „Vorgeschlagene
-Reihenfolge"-Abschnitte in der [Bestandsaufnahme](Bestandsaufnahme-2026-07.md) und im
-[Konzepte-Dokument](Konzepte-Backup-Finanz-Analyse.md) ab — die bleiben als Befund bzw.
-Konzept bestehen, gepflegt wird nur noch hier.
+## Wie das hier zu lesen ist
 
-Kürzel (S4, K2, T4, F-A1, …) verweisen auf die Bestandsaufnahme.
+| 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.
 
 ---
 
-## A — Beschlossen (aus dem OpenAlice-Vergleich, Juli 2026)
+## 0 — Stand
 
-Hintergrund: Konzeptvergleich mit [OpenAlice](https://github.com/TraderAlice/OpenAlice)
-(AGPL-3.0 — Konzepte übernehmen ja, Code nein). Übernommen werden Taskboard,
-Staging-Freigabe, Audit-Log und das Skill-Modell. Die Inbox-Idee entfällt zugunsten
-der geplanten Matrix-Migration (A5).
+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.
 
-### A1 — Taskboard — **erledigt**
+Drei Dinge stehen im Weg:
 
-Aufgaben als Markdown-Dateien mit YAML-Frontmatter im `SharedWorkspace`:
-`title`, `status` (`backlog | todo | in_progress | done | canceled`), `priority`,
-`assignee`, optional `when` (`at` | `every` | `cron` **mit Zeitzone**).
-
-- **Scanner statt Delay-Schleifen**: Ein Takt (~60 s) prüft, was fällig ist.
-  Persistiert werden nur Last-Fired-Marker — ein fehlgeschlagener Lauf bleibt der
-  einzige Versuch für diesen Termin, kein automatischer Retry-Sturm.
-- **Assignee bestimmt die Ausführung**: `@new` = frischer Lauf ohne Historie,
-  `@<agent>` = bestehender Agent mit seinem Kontext, `@human` = wartet auf uns.
-  Das ersetzt das implizite `UseChatContext`-Flag (T7) durch eine explizite Angabe
-  am Auftrag.
-- **Agenten-Tool**: `task_create`, `task_list`, `task_update`, `task_comment`.
-  Agent-zu-Agent-Delegation läuft künftig über Tasks statt über rekursives
-  `send_message`.
-- **Migration**: Die improvisierten `coordination/*.md`-Dateien der Agenten
-  (task_*, status_*, broadcast) gehen im Taskboard auf.
-
-**Detailbauplan** (aus dem Fünf-Repo-Vergleich, Juli 2026 beschlossen):
-
-- Status zusätzlich mit **`in_review`**; im Frontmatter **`require_approval`**
-  (Task gilt erst nach Review als done) und **`acceptance`** (Abnahmekriterien,
-  gegen die das Ergebnis geprüft wird).
-- **Task-Typen `approval` und `human_input`** — ein Mensch ist einfach ein
-  Assignee; seine Antwort ist das Task-Ergebnis und Input für Folgetasks.
-- **Atomares Claiming**: Die DB verhindert, dass zwei Läufe denselben Task
-  ziehen. Der Scanner arbeitet mit **Claim-before-run** (at-most-once — ein
-  doppelter Tick findet den Claim bereits vergeben) und
-  **Startup-Reconciliation**: Beim Start wird Soll (Frontmatter) gegen Ist
-  (Marker/Claims) abgeglichen, verpasste Läufe werden erkannt statt still
-  übersprungen.
-- **`blocked_by`-Abhängigkeiten** mit Auto-Dispatch: Wird der letzte Blocker
-  fertig, wird der wartende Task automatisch angestoßen. Meldet ein Agent einen
-  Blocker, fällt der Task und der Zuständige (Lead/Benutzer) wird benachrichtigt
-  (**Blocker-Eskalation**).
-- **Reopen-/Feedback-Semantik**: Ergebnis + Kritik gehen per `task_comment` an
-  denselben Agenten zur Nachbesserung zurück, statt einen neuen Task von vorn
-  zu beginnen.
-
-Damit erledigt oder aufgegangen:
-
-| Punkt | Warum |
-|---|---|
-| F-A5 Task-Queue | das Taskboard **ist** die Queue |
-| F-A4 Run-Historie | Läufe werden am Task verknüpft und persistiert |
-| B8 Rekursion `send_message` | Delegation über Tasks ist strukturell zyklenfrei |
-| B6 `Task.Delay`-Überlauf | Scanner-Modell kennt keine langen Delays |
-| B7 Cron in Lokalzeit | Frontmatter-`when` ist zeitzonen-explizit |
-| T7 `RunAsync` vs. `ChatAsync` | Assignee-Semantik beantwortet die Frage |
-
-Verzahnung: Das Marktkalender-Flag (`onlyWhenMarketOpen`, siehe C1) gehört ins
-Frontmatter, nicht in einen eigenen Mechanismus.
-
-Konzept-Doc: [Taskboard-Konzept](Taskboard-Konzept.md) (Dateiformat,
-Wahrheitsaufteilung Datei/DB, Scanner-Verhalten, Invarianten, Migration).
-
-### A2 — Staging-Freigabe für irreversible Aktionen (F-A1 + S4) — **Kern erledigt, Ansicht offen**
-
-> **Der offene Rest ist die Freigabe-Ansicht.** `StagingService` bietet
-> `ListPendingAsync`, `ApproveAsync` und `RejectAsync`, `AppHost.Staging` reicht ihn
-> an die Oberfläche durch — aber kein Ansichtsmodell ruft sie auf. Ein gestagter
-> Aufruf liegt damit unbegrenzt in der Ablage. Solange das so ist, ist jede Aktion
-> auf `Approve` faktisch eine Aktion auf `Deny`, nur ohne Rückmeldung an den Agenten.
-
-Konzept-Doc: [Staging-Konzept](Staging-Konzept.md).
-
-Irreversible Aktionen (Mail senden, X posten, DB-Schreibzugriff, Datei löschen,
-perspektivisch Orders) werden **gestaged statt ausgeführt**: Vorschlag → Review im
-Hauptfenster → Freigabe/Ablehnung. Pro Tool/Aktion konfigurierbar:
-`auto | approve | deny`.
-
-Das bisher wirkungslose `PermissionGate` (S4) wird dabei zum zentralen
-Durchsetzungspunkt ausgebaut: Policy-Prüfung, Staging-Entscheidung und Audit-Hook
-(A3) an einer Stelle statt ad-hoc in jedem Tool. S4 wird nicht separat bearbeitet,
-sondern geht hier auf.
-
-Ergänzungen (Juli 2026 beschlossen):
-
-- **Plan-Freeze**: Freigegeben wird ein eingefrorener, konkreter Aufruf — Tool,
-  Aktion und exakte Argumente zum Zeitpunkt des Stagings. Ausgeführt wird genau
-  das Eingefrorene; jede nachträgliche Änderung ist eine neue Freigabe.
-- **Approval-Records**: Jede Entscheidung (Freigabe wie Ablehnung) wird als
-  Datensatz im Audit-Log (A3) verankert — wer, wann, was, mit welchem Ergebnis.
-
-Sicherheitswirkung: Eine Prompt-Injection (K2) kann dann nur noch einen Vorschlag
-erzeugen, keine Ausführung.
-
-### A3 — Audit-Log (F-A2) — **erledigt**
-
-Konzept-Doc: [Audit-Konzept](Audit-Konzept.md).
-
-Jeder Tool-Aufruf wird protokolliert: Agent, Lauf/Session, Zeitstempel, Argumente,
-Ergebnis-Status. Append-only (JSONL oder SQLite-Tabelle auf dem vorhandenen
-`SqliteStorage`).
-
-Designregeln (aus dem OpenAlice-Provenance-Konzept):
-
-- Herkunft wird **von der Engine gestempelt**, nie vom Agenten behauptet.
-- Einträge sind unveränderlich; Korrekturen sind neue Einträge.
-- Unbekannte Herkunft wird als unbekannt markiert, nicht geraten.
-- Worker-Typ (Modell/Engine) und verantwortliche Session sind getrennte Begriffe.
-
-Ergänzung (Juli 2026 beschlossen) — **Receipts**: Jeder abgeschlossene Task/Lauf
-erhält einen Abschluss-Beleg mit Ergebnis-Verweis, Schritten, Tokens und Kosten
-(Verknüpfung `RunUsage` ↔ Task). Damit fällt C7 („Kosten pro Ergebnis")
-weitgehend als Abfallprodukt ab.
-
-Das Audit-Log ist zugleich das Fundament für das Ergebnisregister (C7) und die
-Tool-Fehlerquote aus der Leistungsanalyse.
-
-### A4 — Skill-/Toolset-Modell (ersetzt T6)
-
-Dreischichtig statt „alles immer im System-Prompt":
-
-1. **Dauerhafter Kern** — Identity, Soul, unveränderliche Regeln. Schlank, damit der
-   Prompt-Cache (T1) stabil bleibt.
-2. **Nachladbare Skills/Toolsets** — fachliche Abläufe und selten genutzte Tools
-   werden erst auf Anforderung geladen (`list_toolsets` → `load_toolset`).
-3. **Selbstkorrigierende Tool-Fehler** — Fehlermeldungen nennen die gültigen
-   Parameter/Aktionen, statt das Modell raten zu lassen.
-
-Mechanik (Juli 2026 beschlossen, nach GoClaw-Vorbild): Skills liegen als
-`SKILL.md` mit Frontmatter (`name`, `description`) im Instanz- bzw.
-Agenten-Verzeichnis. Bei wenigen Skills werden die Kurzbeschreibungen inline in
-den Prompt eingebettet, bei vielen gibt es stattdessen ein `skill_search`-Tool.
-Änderungen an Skill-Dateien werden per Hot-Reload übernommen.
-
-Dazu Hermes' Selbstverbesserungs-Idee: **Agenten dürfen Skills aus Erfahrung
-selbst schreiben** (das AgentEditor-Tool ist die Vorstufe). Wichtig: Ein Skill
-ist Prompt-Input — agentengeschriebene Skills werden erst nach Freigabe (A2)
-aktiv, sonst wäre das ein Injection-Kanal in künftige Läufe.
-
-### A5 — Matrix/Element-Migration
-
-Beschlossene Richtung: Die Kommunikation (Benachrichtigungen, Berichte, Chat mit
-Agenten) wird auf Element/Matrix umgestellt.
-
-- Ersetzt die im OpenAlice-Vergleich erwogene Inbox — Berichte landen in
-  Matrix-Räumen.
-- Der Tool-Kandidat **Notify** entfällt und geht hierin auf.
-- Betroffen: Telegram-Tool (Rolle klären), WebView-Chat (bleibt er Haupt-UI?),
-  Streaming K4 (Matrix streamt nicht — nach dieser Entscheidung neu bewerten).
-
-Scope ist noch unbestimmt — braucht ein eigenes Konzept-Doc, bevor es in die
-Reihenfolge eingeordnet wird.
-
-**Kollision, seit Rocket.Chat steht (August 2026):** Das
-[Rocket.Chat-Tool](../src/ClawdDotNet.Tools.RocketChat/) ist umgesetzt und im
-`AppHost` registriert — es bedient genau den Zweck, für den A5 Matrix vorsah.
-Entweder A5 entfällt und Rocket.Chat wird der Weg, oder wir betreiben zwei
-Chat-Wege nebeneinander. Das ist **die nächste offene Grundsatzentscheidung**;
-siehe [RocketChat-Nextcloud-Konzept](RocketChat-Nextcloud-Konzept.md).
-
-### A6 — MySQL-Replikations-Spiegel (optional)
-
-Beschlossen Juli 2026. **SQLite bleibt die einzige Wahrheit** — gearbeitet wird
-ausschließlich auf der Instanz-DB. MySQL ist ein reiner, nachgelagerter Spiegel:
-Er empfängt nur INSERT/UPDATE/DELETE vom Replikator; die App liest im Betrieb
-**nie** daraus. Einziger Lesezweck: Wiederherstellung, falls die SQLite korrupt
-ist — daneben steht der Spiegel externen Auswertungen (Dashboards, Ad-hoc-SQL)
-offen, ohne die Agenten-Maschine zu berühren.
-
-Leitplanken:
-
-- **Outbox-Muster** an der vorhandenen Schreib-Warteschlange von `SqliteStorage`:
-  Replikations-Einträge lokal puffern, idempotente Upserts nach MySQL.
-  Nie blockierend — ist MySQL nicht erreichbar, staut die Outbox und holt auf.
-- Mehrere Instanzen replizieren in denselben Spiegel; Zeilen tragen `instance_id`.
-- **Restore-Pfad (Spiegel → frische SQLite) muss existieren und getestet sein** —
-  gleiche Regel wie beim Backup: ein ungeprüftes Restore ist eine Vermutung.
-- Kein Koordinationspunkt: Claiming, Locks, Taskboard-Zustand bleiben lokal.
-  Die Regel „nur der Replikator schreibt, niemand liest im Betrieb" gehört ins
-  Konzept-Doc.
-- Sicherheit: TLS zur Datenbank, Zugangsdaten über `SecretProtector`;
-  Output-Scrubbing der Tool-Ergebnisse wird wichtiger, weil Kontext-Daten
-  künftig auch im Spiegel liegen.
-- Ergänzt das ZIP-Backup, ersetzt es nicht — Identity/Soul, Settings, Workspace
-  und Telegram-Session bleiben Sache des Instanz-Backups.
-
-**Voraussetzung — Historie-Umzug:** `ChatHistory.json` zieht in die Instanz-DB um
-(aktive Tabelle + Archiv-Tabelle mit FTS5-Volltextindex und `history_search`-Tool,
-siehe K6 in Abschnitt B). Das löst
-nebenbei B10 (O(n²)-Schreiblast) und gibt K6 seine Form; erst danach schützt der
-Spiegel auch die Historie. Zeitlich passt A6 zu dem Server, der ggf. mit A5
-(Matrix) ohnehin dazukommt.
+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.
 
 ---
 
-## B — Offen aus der Bestandsaufnahme
+## 1 — Reihenfolge
 
-| Punkt | Was | Stand |
-|---|---|---|
-| T4 | Proaktiv statt reaktiv kompaktieren | offen, unverändert |
-| K2-Rest | Untrusted Content als Daten rahmen (`<untrusted_content>`) | A2 nimmt die Schärfe; die Rahmung selbst bleibt nötig |
-| K4 | Streaming | **zurückgestellt** bis A5 entschieden ist |
-| K6 | Historie **archivieren + durchsuchbar machen** (FTS5-Index, `history_search`-Tool) statt nur rotieren | beschlossen; Teil des Historie-Umzugs (Voraussetzung von A6) |
-| 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 | beschlossen (GoClaw-Muster) |
-| Memory-Auto-Injection | Relevante Memory-Abstracts werden automatisch eingeblendet (Relevanzschwelle, Deckel ~200 Tokens), **in die Nutzernachricht, nie in den System-Prompt** (Prompt-Cache T1) | beschlossen; löst den offenen Punkt „Automatische Einblendung" im [Memory-Konzept](Memory-Konzept.md) |
-| Output-Scrubbing | Bekannte Secret-Werte (Register des `SecretProtector`) werden zentral aus **allen** Tool-Ergebnissen maskiert, bevor sie in Kontext, Historie oder Spiegel (A6) gelangen | beschlossen; schließt die Lücke, die S3 nur für URLs schloss |
-| Hygiene-Paket | B9 (`index_Count`-Race), B13 (`instanceId`-Inkonsistenz), F-A6-Rest (UI zum Setzen/Rotieren der Secrets) | Kleinbugs, in einem Aufwasch. B11/T8 (`max_tokens`) ist erledigt — `AgentEngine` setzt es aus `LoopGuard.MaxResponseTokens`. B10 geht im Historie-Umzug (A6) auf |
+Was als Nächstes ansteht, mit Begründung. Alles darunter in Abschnitt 3.
 
-Erledigt seit der letzten Fortschreibung: B4 vollständig (Preise kommen live vom
-`/models`-Endpunkt, unbekannte Modelle werden sichtbar gemeldet). Beim Frühjahrsputz
-dazugekommen: die automatische Sicherung lief ins Leere — die Oberfläche bot sie an
-und schrieb die Uhrzeit weg, aber der `BackupScheduler` wurde nie gestartet. Jetzt
-verdrahtet.
+| # | Vorhaben | Warum an dieser Stelle | Bereich |
+|---|---|---|---|
+| **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) |
 
-Neu aufgenommen (aus der Ideensammlung, die dabei aufgelöst wurde):
+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.
 
-| Punkt | Was |
-|---|---|
-| Werkzeugwunsch | Agenten bekommen in den Kern-Prompt den Hinweis, sich zu melden, wenn ihnen ein Werkzeug fehlt, das es noch nicht gibt. Der Weg dafür ist da — ein Task an `@human` (A1). Gehört zum Prompt-Kern von A4 |
+---
 
-### B-DC — Deploymentcenter-Anbindung
+## 2 — Offene Entscheidungen
+
+Diese Punkte kann niemand bauen, bevor sie entschieden sind. Sie kosten kein
+Entwicklungsbudget, nur eine Festlegung.
+
+| # | 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 |
+
+---
+
+## 3 — Beschlossen und offen
+
+### 3.1 — Kontrolle und Sicherheit
+
+Bauplan: [Staging-Konzept](Staging-Konzept.md), [Audit-Konzept](Audit-Konzept.md).
+
+| 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 |
+
+### 3.2 — Agenten-Fähigkeiten
+
+| 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 |
+
+### 3.3 — Kommunikation zwischen Agenten
+
+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.
+
+| 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 |
+
+### 3.4 — Daten und Speicher
+
+| 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 |
+
+### 3.5 — Betrieb und Auslieferung
 
 WatchDog und LicenseLabrador sind durch das
 [Deploymentcenter](Deploymentcenter-Integration.md) ersetzt: eine Adresse, ein Token,
-und dazu Update-Prüfung, Fehler-Stream und Bugtracker. Watchdog läuft wieder pro
-Instanz (ein Monitor je Instanz, mit Gesundheitsprüfungen und angekündigtem Ende).
+dazu Update-Prüfung, Fehler-Stream und Bugtracker. Watchdog läuft pro Instanz.
 
-Offen:
+| 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 |
 
-| Punkt | Was | Bemerkung |
+### 3.6 — Finanz und Analyse
+
+Dieser Block ist bewusst **nachgelagert**: ClawdDotNet soll zuerst als allgemeiner
+Agenten-Client felsenfest sein, die handelsspezifischen Werkzeuge kommen danach.
+
+| 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 |
+
+### 3.7 — Hygiene
+
+Kleinbugs, in einem Aufwasch zu erledigen.
+
+| 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 |
+
+### 3.8 — Tests
+
+Grundlage: [Teststrategie](Teststrategie.md). Stand: 585 grün, 6 übersprungen.
+
+| Punkt | Stand | Was |
 |---|---|---|
-| DC1 | Oberfläche „Fehler melden" | Client vorhanden, Schaltfläche fehlt |
-| DC2 | Agenten-Tool für den Bugtracker | macht den Claim/Lease-Workflow des Deploymentcenters nutzbar |
-| DC3 | Release-Strecke | **erledigt für win-x64/dev** ([`deploy/publish.py`](../deploy/publish.py), 0.1.1 veröffentlicht). Offen: `linux-x64` — die Portierung, auf die das wartete, ist durch — und `prod` |
-| DC4 | SDK als Git-Submodul unter `external/` statt Cross-Repo-Pfad | betrifft auch die CI |
-| DC5 | Betreiber: Evaluator-Cron einrichten, Token ausstellen, `parent_source` pflegen | **ohne den Cron ist die Überwachung wertlos** |
-| DC6 | Update anwenden statt nur melden | **erledigt.** Agent liegt im Paket (Prüfsumme geprüft), Rückfrage in der Oberfläche, geordnetes Herunterfahren vor dem Agentenstart, `maintenance` an den Watchdog |
-| DC7 | Erstinstallation über `--action install` + `setup.json` | **erledigt.** Setup-Kette live durchgespielt (Login, Katalog, Token mit Rechteschranke), Round-Trip SDK-Writer → SettingsManager trägt. `fileWindows`/`fileLinux` gesetzt |
-| DC8 | Signaturpflicht (`--require-signature`) | Schlüssel steht, ab 0.1.2 wird signiert, Prüfung beidseitig getestet. **Blockiert:** `LaunchUpdateAgent` reicht den Schalter nicht durch — aus der Anwendung heraus nicht erzwingbar (gemeldet) |
-
-Details: [Deploymentcenter 2.2–2.4 Integrationsplan](Deploymentcenter-2.4-Integrationsplan.md).
-Der Zugangsschutz aus 2.4 (Lizenzschlüssel als Basic-Auth-Zugang zur Release-Ablage) ist
-bereits umgesetzt — er muss im **ersten** veröffentlichten Release enthalten sein.
+| **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 |
 
 ---
 
-## C — Offen aus dem Finanz-/Analyse-Konzept
+## 4 — Ideenspeicher
 
-Punkte 1–2 von dort (atomares Schreiben, Backup/Restore inkl. UI) sind umgesetzt.
+Nicht beschlossen. Steht hier, damit es nicht verlorengeht — nicht, weil es demnächst
+gebaut wird.
 
-| # | Was | Bemerkung |
+### Tool-Kandidaten
+
+| Tool | 💭 Nutzen | Bemerkung |
 |---|---|---|
-| C1 | Marktkalender (`onlyWhenMarketOpen` + `MarketCalendar`-Tool) | Scheduler-Teil gehört ins Taskboard-Frontmatter (A1) |
-| C2 | `Indicators`-Tool — deterministische Berechnung | Qualität hoch, Tokens runter |
-| C3 | Datenaktualität erzwingen (`maxAgeSeconds`) | |
-| C4 | Termine & Fundamentaldaten (Earnings, EDGAR, Wirtschaftskalender) | |
-| C5 | Bestandsregister (Positionen) | Grundlage für C7/C8 |
-| C6 | Nachrichten-Entdopplung (`SeenItems`) | |
-| C7 | Ergebnisregister (Stufe 2, „Kosten pro Ergebnis") | fällt weitgehend aus den A3-Receipts ab |
-| C8 | Falsifizierbare Aussagen + Auflösung, Brier-Score (Stufe 3) | braucht C5, C7 und einen Auflösungs-Task (A1) |
+| **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 |
+
+### Weitere Ideen
+
+| Idee | 💭 |
+|---|---|
+| 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 |
 
 ---
 
-## D — Toolkandidaten (unbeschlossen)
+## 5 — Erledigt
 
-WebSearch, Http (generisch mit Allowlist), Shell (sandboxed), Git, Vision.
-Notify ist gestrichen — geht in A5 auf.
+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.
 
 ---
 
-## Vorgeschlagene Reihenfolge
+## 6 — Modell-Einstufung
 
-| # | Vorhaben | Begründung |
+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.
+
+| Vorhaben | Einstufung | Vorgabe |
 |---|---|---|
-| ✅ | A1 Taskboard | Fundament; löste sechs bestehende Punkte auf einmal |
-| ✅ | A3 Audit-Log | klein, sofort nützlich; musste vor A2 da sein, damit Freigaben protokolliert werden |
-| **1** | **A2 — Freigabe-Ansicht** | Der Rest von A2 und das einzige Stück, das jetzt wirklich blockiert: Ohne sie liegen gestagte Aufrufe unbeantwortet. Kleiner Umfang, große Wirkung |
-| 2 | FileRW-Papierkorb | [eigener Plan](umsetzungsplaene/UMSETZUNGSPLAN-FileRW-Papierkorb-Cleanup.md); kleinster Eingriff, entschärft ein reales Risiko und erlaubt, `FileRW.delete` von `Approve` auf `Auto` zu senken |
-| 3 | A5 entscheiden: Matrix oder Rocket.Chat | Blockiert K4 (Streaming) und färbt auf A6 ab. Entscheidung, keine Umsetzung — deshalb früh |
-| 4 | C1 Marktkalender | spart sofort Kosten; nutzt A1-Frontmatter |
-| 5 | A4 Skills/Toolsets | Token-Hebel, Cache-stabil |
-| 6 | C2 Indicators | Qualität + Kosten |
-| 7 | C7 + C8 Ergebnisregister, Aussagen | das eigentliche Leistungsmaß; braucht A3 |
-| — | DC1 „Fehler melden"-Schaltfläche | zwischendurch; der Client steht, es fehlt der Knopf |
-| — | Hygiene-Paket (B) | zwischendurch, unabhängig |
-| — | Historie-Umzug in die Instanz-DB | löst B10 + K6; Voraussetzung für A6 |
-| — | A6 MySQL-Spiegel | nach dem Historie-Umzug; natürliches Zuhause auf dem A5-Server |
-| — | A5 umsetzen | erst nach der Entscheidung aus Zeile 3; der gewählte Weg bekommt dann sein Konzept-Doc |
+| ✅ 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 |
 
-Leitlinie der Reihung: erst Nachvollziehbarkeit und Kontrolle (Audit, Staging),
-dann Fähigkeiten — ein Agent, der unbeaufsichtigt läuft, braucht zuerst Bremsen,
-dann PS.
+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.
 
 ---
 
-## Umsetzung mit Opus 4.6 — Einstufung
+## 7 — Woher das hier kommt
 
-Die Entwicklung erfolgt mit Opus 4.6. Die meisten Vorhaben sind damit gut
-machbar, sofern die hier notierten Vorgaben mitgegeben werden.
+### Weiter gültig — Baupläne
 
-> Die beiden hier markierten Stellen sind inzwischen gebaut: Der **Scanner-Kern**
-> (A1) steht samt Claiming und Reconciliation, die **Fortsetzung nach Freigabe**
-> (A2) folgt der Vorgabe unten — der Lauf endet beim Staging regulär, kein Suspend.
-> Die Tabelle bleibt als Begründung stehen, warum es so gebaut wurde. Zwei Stellen
-berühren Nebenläufigkeits-Invarianten bzw. Engine-Querschnitte — sie sind für
-Opus 5 / Fable markiert oder durch eine Architektur-Vorgabe entschärft.
+Aus der Roadmap verlinkt. Wer einen Punkt anfasst, liest das zugehörige Dokument.
 
-| Vorhaben | Einstufung | Vorgabe / Begründung |
-|---|---|---|
-| A1: Dateiformat, Frontmatter-Parsing, `task_*`-Tool, Migration | 4.6 | klar spezifizierbar, gut testbar |
-| A1: **Scanner-Kern** (atomares Claiming, Auto-Dispatch, Reconciliation) | ⚠️ **Opus 5 / Fable** | At-most-once-Semantik, Claim-CAS und das Zusammenspiel mit den seit B2 serialisierten Chat-Läufen sind genau die Fehlerklasse, die hier schon einmal schiefging. Falls doch 4.6: erst Konzept-Doc, Umsetzung strikt dagegen, Property-Tests für die Invarianten („nie zwei Claims auf einen Task", „kein Dispatch bei offenem Blocker", „doppelter Tick = ein Lauf") |
-| A2: Gate, Policy, Staging-Queue, Review-UI, Approval-Records | 4.6 | mit der folgenden Architektur-Vorgabe |
-| A2: **Fortsetzung nach Freigabe** | 4.6 nur mit Vorgabe | **Kein pausierter, im Speicher gehaltener Lauf.** Vorgabe: Der Lauf endet beim Staging regulär — das Tool liefert „zur Freigabe vorgelegt" als Ergebnis, der Agent schließt ab. Die Freigabe erzeugt einen Folge-Task (A1), der den Agenten mit dem **eingefrorenen** Aufruf weckt. Echtes Suspend/Resume eines laufenden `ChatAsync` wäre Fable-Terrain — und ist mit dieser Vereinfachung unnötig |
-| A3: Audit-Log + Receipts | 4.6 | append-only, klares Schema, keine Nebenläufigkeitsfallen |
-| A4: Skills | 4.6 | `FileSystemWatcher` mit Debounce (~500 ms); agentengeschriebene Skills erst nach Freigabe aktiv (siehe A4) |
-| Memory-Flush vor Compaction | 4.6 mit Anleitung | Harte Grenzen: max. 3–5 Schritte, einziges Tool `memory_store`, Timeout, günstiges Modell (wie T3), höchstens einmal je Compaction-Zyklus. Vorsicht: Der ContextCompactor hatte B1/B14 — die bestehenden Paarungs-Tests müssen unverändert grün bleiben |
-| Memory-Auto-Injection | 4.6 | in die Nutzernachricht, nie in den System-Prompt (sonst verfällt der Prompt-Cache T1); Deckel ~200 Tokens |
-| Output-Scrubbing | 4.6 | ein zentraler Filter an der Stelle, wo Tool-Ergebnisse in den Kontext gelangen (`ExecuteToolCallAsync`); Werte aus dem Secret-Register |
-| Historie-Umzug + FTS5 + `history_search` | 4.6 | Migration nur nach frischem Backup; alte JSON-Dateien 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 Marktkalender, C2 Indicators | 4.6 | reine Fachlogik, deterministisch testbar |
+| 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** |
+| [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 |
+| [umsetzungsplaene/](umsetzungsplaene/) | Vier Detailpläne: FileRW-Papierkorb, AgentInspector, AgentEditor-Härtung, WebSearch |
 
-Generell: Neue Subsysteme (Scanner, Staging, Audit, Replikator) kommen mit Tests
-nach der [Teststrategie](Teststrategie.md) — die Invarianten-Tests sind bei den
-markierten Punkten kein Nice-to-have, sondern die Absicherung dafür, dass ein
-schwächeres Modell sie umsetzen darf.
+### 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 |
+| [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/).
+
+| 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 |
+| `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 |
+| `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 |