ClawdDotNet/docs/Roadmap.md

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.

Gepflegt wird nur noch dieses Dokument. Was aus den alten Papieren wurde, steht in Abschnitt 7.

---

Wie das hier zu lesen ist

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.

---

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.

Drei Dinge stehen im Weg:

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.

---

1 — Reihenfolge

Was als Nächstes ansteht, mit Begründung. Alles darunter in Abschnitt 3.

#	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
2	A5 entscheiden: Matrix oder Rocket.Chat	Kostet keine Umsetzung, löst aber drei blockierte Punkte auf einmal. Deshalb früh	2
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
4	Delegationstiefe begrenzen (B8)	Behebt eine echte Verklemmung. Kleiner Eingriff, aber am Agent-Gate — mit Test A13 aus der Teststrategie	3.3
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
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
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
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
—	DC1 „Fehler melden"	Zwischendurch; der Client steht, es fehlt die Schaltfläche	3.5
—	Hygiene-Paket	Zwischendurch, unabhängig von allem	3.7

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.

---

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)
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, Audit-Konzept.

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
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
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
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
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
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. 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 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 ersetzt: eine Adresse, ein Token, dazu Update-Prüfung, Fehler-Stream und Bugtracker. Watchdog läuft pro Instanz.

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

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
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. Stand: 585 grün, 6 übersprungen.

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 ist deshalb Pflichtlektüre vor jeder Abgabe

---

4 — Ideenspeicher

Nicht beschlossen. Steht hier, damit es nicht verlorengeht — nicht, weil es demnächst gebaut wird.

Tool-Kandidaten

Tool	💭 Nutzen	Bemerkung
WebSearch	Agenten können heute nur bekannte Domains abrufen, aber nichts finden. Brave/Tavily/SearXNG	Bauplan liegt vor: Umsetzungsplan. 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. 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

---

5 — Erledigt

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

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

Generell: Neue Subsysteme kommen mit Tests nach der Teststrategie. 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.

Dokument	Wofür
Taskboard-Konzept	Dateiformat, Wahrheitsaufteilung Datei/DB, Scanner-Verhalten, Invarianten
Audit-Konzept	Schema, Provenance-Regeln, Receipts
Staging-Konzept	Policy-Auflösung, Plan-Freeze, Fortsetzung nach Freigabe — Bauplan für Punkt #1
Memory-Konzept	Modell, Schlüssel-Semantik, Abrufreihenfolge
Agentenkommunikation-Konzept	Fünf Phasen, Korrelation, Nachrichtenspeicher
RocketChat-Nextcloud-Konzept	Rocket.Chat gebaut; Nextcloud, Rückweg und ChannelRouter offen. Enthält die Messung gegen die echte Instanz
Deploymentcenter-Integration	Wie Heartbeat, Fehler-Stream, Bugtracker und Updates verdrahtet sind
umsetzungsplaene/	Vier Detailpläne: FileRW-Papierkorb, AgentInspector, AgentEditor-Härtung, WebSearch

Weiter gültig — Handbücher

Dokument	Wofür
Oberflaechen-Leitfaden	Arbeiten an ClawdDotNet.Desktop: Schichtschnitt, Fäden, Avalonia-12-Fallen, Prüfliste
ToolDevelopmentGuide	Ein neues Agenten-Tool bauen
InstanceSetupGuide	Eine Instanz einrichten
Teststrategie	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/.

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