17 KiB
Roadmap
Zentrale Liste aller offenen Vorhaben. Sie löst die beiden „Vorgeschlagene Reihenfolge"-Abschnitte in der Bestandsaufnahme und im Konzepte-Dokument ab — die bleiben als Befund bzw. Konzept bestehen, gepflegt wird nur noch hier.
Kürzel (S4, K2, T4, F-A1, …) verweisen auf die Bestandsaufnahme.
A — Beschlossen (aus dem OpenAlice-Vergleich, Juli 2026)
Hintergrund: Konzeptvergleich mit 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).
A1 — Taskboard
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 impliziteUseChatContext-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 rekursivessend_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 Frontmatterrequire_approval(Task gilt erst nach Review als done) undacceptance(Abnahmekriterien, gegen die das Ergebnis geprüft wird). - Task-Typen
approvalundhuman_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_commentan 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 (Dateiformat, Wahrheitsaufteilung Datei/DB, Scanner-Verhalten, Invarianten, Migration).
A2 — Staging-Freigabe für irreversible Aktionen (F-A1 + S4)
Konzept-Doc: Staging-Konzept.
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)
Konzept-Doc: Audit-Konzept.
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":
- Dauerhafter Kern — Identity, Soul, unveränderliche Regeln. Schlank, damit der Prompt-Cache (T1) stabil bleibt.
- Nachladbare Skills/Toolsets — fachliche Abläufe und selten genutzte Tools
werden erst auf Anforderung geladen (
list_toolsets→load_toolset). - 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.
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.
B — Offen aus der Bestandsaufnahme
| 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 |
| 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), B11/T8 (max_tokens setzen), B13 (instanceId-Inkonsistenz), F-A6-Rest (UI zum Setzen/Rotieren der Secrets) |
Kleinbugs, in einem Aufwasch. B10 geht im Historie-Umzug (A6) auf |
Erledigt seit der letzten Fortschreibung: B4 vollständig (Preise kommen live vom
/models-Endpunkt, unbekannte Modelle werden sichtbar gemeldet).
B-DC — Deploymentcenter-Anbindung
WatchDog und LicenseLabrador sind durch das Deploymentcenter 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).
Offen:
| Punkt | Was | Bemerkung |
|---|---|---|
| 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: pack-and-deploy mit <Version> aufrufen, dann update-agent |
ohne Release hat die Update-Prüfung nichts zu finden. Versionsnummer selbst ist erledigt (Directory.Build.props → ReleaseInfo) |
| 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 |
C — Offen aus dem Finanz-/Analyse-Konzept
Punkte 1–2 von dort (atomares Schreiben, Backup/Restore inkl. UI) sind umgesetzt.
| # | Was | 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) |
D — Toolkandidaten (unbeschlossen)
WebSearch, Http (generisch mit Allowlist), Shell (sandboxed), Git, Vision. Notify ist gestrichen — geht in A5 auf.
Vorgeschlagene Reihenfolge
| # | Vorhaben | Begründung |
|---|---|---|
| 1 | A1 Taskboard | Fundament; löst sechs bestehende Punkte auf einmal |
| 2 | A3 Audit-Log | klein, sofort nützlich; muss vor A2 da sein, damit Freigaben protokolliert werden |
| 3 | A2 Staging-Freigabe | größter Sicherheitsgewinn; Voraussetzung für unbeaufsichtigten Betrieb |
| 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 |
| — | 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 Matrix | eigenes Konzept-Doc zuerst; Scope klären, dann einordnen |
Leitlinie der Reihung: erst Nachvollziehbarkeit und Kontrolle (Audit, Staging), dann Fähigkeiten — ein Agent, der unbeaufsichtigt läuft, braucht zuerst Bremsen, dann PS.
Umsetzung mit Opus 4.6 — Einstufung
Die Entwicklung erfolgt mit Opus 4.6. Die meisten Vorhaben sind damit gut machbar, sofern die hier notierten Vorgaben mitgegeben werden. 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.
| 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 |
Generell: Neue Subsysteme (Scanner, Staging, Audit, Replikator) kommen mit Tests nach der Teststrategie — 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.