# Nexus Mission Control Roadmap **Status:** Kanonische Produkt- und Umsetzungsroadmap **Stand:** 2026-07-31 **Priorisierung:** Abhängigkeiten und Risikoreduktion statt willkürlicher Kalendertermine **Ziel:** Nexus ersetzt die OpenClaw-Oberfläche im täglichen Betrieb, nicht die OpenClaw-Runtime. ## 1. Verbindliches Zielbild Nexus wird die zentrale, agent-first Mission-Control-Oberfläche für alle alltäglichen Steuerungs-, Überwachungs- und Freigabeaufgaben. Die technische Ausführung bleibt bewusst eindeutig: ```text Browser / Owner -> Nexus UI -> Nexus API (Auth, RBAC, Policies, Approvals, Audit) -> typisierte OpenClaw-Gateway-Fassade -> OpenClaw Gateway (Agents, Sessions, Tools, Cron, Channels, Nodes, Routing) -> OpenAI (primärer Modellprovider) ``` Zusätzlich greifen OpenClaw-Agenten über die kontrollierte Nexus-MCP- oder TaskBridge-Schnittstelle auf Nexus-eigene Projekte und Tasks zu. Verbindliche Architekturregeln: - Nexus ruft OpenAI **nicht direkt** auf und speichert keinen OpenAI-API-Schlüssel. - OpenClaw ist der verpflichtende Runtime- und Gateway-Pfad für jede Modell-/Agentenausführung. - OpenAI wird innerhalb von OpenClaw als primärer Provider konfiguriert. - Exakte Modellreferenzen werden als explizite `provider/model`-Policies in OpenClaw verwaltet; das konkrete Modell bleibt eine Betriebsentscheidung und wird nicht dauerhaft in der Nexus-Domäne fest verdrahtet. - Browser-Clients sprechen weder OpenClaw noch OpenAI direkt an. - Nexus bildet keine zweite, konkurrierende Agentenruntime und keinen zweiten Session Store. - Die OpenClaw-Oberfläche darf für Recovery und Break-glass-Betrieb verfügbar bleiben, darf aber für den normalen Arbeitsalltag nicht erforderlich sein. ## 2. System-of-Record und Ownership | Bereich | Autoritative Quelle | Nexus-Aufgabe | |---|---|---| | Nutzer, Rollen, RBAC | Nexus | Authentifizieren, autorisieren, verwalten | | Projekte und fachliche Tasks | Nexus | CRUD, Zustände, Abhängigkeiten, Delegation | | Menschliche Entscheidungen und Freigaben | Nexus | Policy, Entscheidung, Audit, Eskalation | | Produktziele, KPIs und Budgets | Nexus | Planen, überwachen, mit Runs korrelieren | | OpenClaw-Agentenkonfiguration | OpenClaw | Sicher lesen und über typisierte Mutationen steuern | | Modelle, Provider und Auth-Profile | OpenClaw | Status, Policies und sichere Secret-Referenzen bedienen | | Sessions und Subagent-Runs | OpenClaw | Suchen, anzeigen, starten und kontrollieren | | Tool-Katalog und Runtime-Tool-Policy | OpenClaw | Effektive Rechte darstellen und kontrolliert ändern | | Cron Jobs und Run-Historie | OpenClaw | Vollständigen Lifecycle in Nexus bedienen | | Channels, Nodes und Gatewayzustand | OpenClaw | Betriebsansicht und kontrollierte Aktionen anbieten | | Modellinferenz und Provider-Usage | OpenAI über OpenClaw | Kosten/Usage über OpenClaw korrelieren und auswerten | | Control-Plane-Audit | Nexus | Jede Mutation, Freigabe und Korrelation dauerhaft protokollieren | Nexus darf Projektionen und zeitlich begrenzte Read Models für schnelle Oberflächen speichern. Jede Projektion zeigt Quelle, Zeitpunkt und Freshness; bei Konflikten bleibt OpenClaw für Runtimezustand autoritativ. ## 3. Aktuelle Basis Bereits vorhanden und weiterzuverwenden: - Vue-/Pinia-Frontend mit 21 benannten Seiten (Login plus 20 authentifizierte Views) und einheitlicher Mission-Control-Designsprache - ASP.NET-Core-API, PostgreSQL, JWT-/Refresh-Session-Grundlage - `IAgentRuntime` mit `OpenClawRuntime` als einzig registriertem Runtime-Adapter - Protocol-v4-`IGatewayConnector` für Challenge/Hello, RPC-Korrelation, Capabilities, Scopes, Events, Timeouts, Reconnect und Versionspinning - ein owner-only Attach-&-Adopt-Flow mit begrenzter Discovery, Probe, read-only Pairing, einem persistierten `primary`-Profil, Adoption ohne Runtime-Datenkopie und separatem Management-Scope-Upgrade - browser-sicherer `IOpenClawControlService` für Tasks, Sessions, Approvals, Cron, Activity, Models und Agents - live Agent-Inventar über `agents.list`, erlaubte Bootstrap-Dateien über `agents.files.*`, read-only Workspace-Browsing und schema-basiertes `config.*` mit Hashkonflikt, Diff und Read-back-Verifikation - vollständiger typisierter Cron-Kern-Lifecycle mit Liste, Detail, Create, Edit, Enable/Disable, Delete, Sofortlauf und paginierter Run-Historie - redigierter `models.authStatus` und der offizielle, in Nexus gerenderte `wizard.*`-Flow - funktionale Mutationen für Task-Cancel, Session-Abort, Session-Model, Approval-Entscheidung, Agent-Dateien, Config und Cron - funktionale Task-Domäne mit Parent-/Child-Tasks, Handoffs und MCP-/Bridge-Zugriff - echte Arbeitsflächen für `/runs`, `/models` und `/activity` - OpenClaw-gebundene Dashboard-, Agent-, Calendar-, Notification-, Security- und Settings-Flächen mit ehrlichen Loading-/Empty-/Error-Zuständen Noch nicht ausreichend: - OpenClaw `2026.7.1` registriert noch keine offiziell unterstützte externe Nexus-/Generic-Operator-Client-ID. Nexus imitiert keine interne Gateway-Identität; der produktive Connector bleibt deshalb blockiert. - Reales Remote-Pairing, bewusster Scope-Upgrade und Live-Schreibtests für Agent-Dateien, Config und Cron an eindeutig benannten Testobjekten sind noch nicht abgenommen. - OpenAI ist noch nicht durch einen realen, wiederholbaren `Nexus -> OpenClaw -> OpenAI -> Nexus`-Smoke als Primärprovider belegt. - Runstart, Resume, Retry, Branching, Subagenten, Tools, Channels und Nodes sind nicht durchgängig bedienbar. - Agent-Lifecycle-Aktionen wie Create, Enable/Disable, Restart und Delete fehlen noch; beliebige Workspace-Dateien bleiben mangels sicherem OpenClaw-Write-RPC absichtlich read-only. - Der lokale Idempotency-Ledger bleibt ein Single-Writer-Vertrag und deckt noch nicht jede zukünftige Gateway-Mutation ab. - Security-, Audit-, E2E- und Eval-Gates reichen für eine produktive Agenten-Control-Plane noch nicht aus. Produktionscheckpoint v0.2.59 vom 2026-07-31: - Gitea Run 362 hat Commit `144edf58fe5928a3e04816f4435ea574d64211a1` mit grünen Backend-, Frontend-, Security- und Deploymentjobs ausgeliefert. - PostgreSQL und die HTTP-Runtime zu Baos OpenClaw sind auf Produktion stabil gesund. Docker-DNS verwendet `openclaw-gateway:18789`; der Release-Gate akzeptiert keinen `Degraded`-Healthstatus mehr. - 363 Backendtests und 25 Browsertests bestehen in CI. Fünf explizite Docker-/Toxiproxy-Integrationsfälle bleiben ohne CI-Opt-in sichtbar übersprungen. - Auth-Grenzen, SPA-Routing, Security-Header und der korrigierte Loginfehler sind live geprüft. Credentialed Owner-Flows, Gateway-Pairing, OpenClaw-Schreibvorgänge und der OpenAI-End-to-End-Run bleiben offen. Die vollständige Evidenz und der daraus abgeleitete Plan stehen in [Production release v0.2.59](audits/2026-07-31/production-release-v0.2.59/PRODUCTION_VALIDATION_AND_NEXT_PLAN.md). Stabilitätscheckpoint v0.2.60 (Release Candidate) vom 2026-07-31: - `/health/live`, `/health/ready` und `/health` trennen Prozesszustand, PostgreSQL-Readiness und vollständige OpenClaw-Diagnose. Deploy und Rollback verwenden dieselben Gates; ein OpenClaw-Ausfall hält die Recovery-Oberfläche erreichbar. - Die ungenutzte Antiforgery-Route ist entfernt. Refresh und Logout behalten das strikte Secure-/HttpOnly-Cookie und weisen explizite Cross-Site-Browser- Aufrufe anhand von `Origin` und `Sec-Fetch-Site` ab. - OpenAPI beschreibt den gemeinsamen `ProblemDetails`-Vertrag einschließlich stabilem Code und Trace-ID. Alle 20 authentifizierten Views verwenden die gemeinsame Loading-/Empty-/Error-/Offline-/Stale-/Partial-Schicht und erhalten sichtbare Daten bei Background-Refresh. - `global.json`, `VERSION`-Parität, OCI-Provenienz, Browsertelemetrie-Schalter, High/Critical-Abhängigkeitsgates, checksum-verifiziertes Gitleaks und ein verpflichtender PostgreSQL-/Toxiproxy-CI-Job bilden den neuen Releasevertrag. - Lokal bestehen 383 nicht-containerisierte Backendtests, 42 Frontendtests, Typecheck, Produktionsbuild und 26 kontrollierte Playwright-Tests. Die fünf Containerfälle sind lokal mangels Docker übersprungen und müssen im Linux-CI mit null Skips bestehen. Credentialed Produktion, Task-Board-Last und echte OpenClaw-Schreibpfade bleiben eigene Gates. Die genaue Implementierungs- und Evidenzgrenze steht in [Stability v0.2.60](audits/2026-07-31/stability-v0.2.60/IMPLEMENTATION_AND_ACCEPTANCE.md). ## 4. Prioritätsdefinition - **P0:** Blockiert sicheren End-to-End-Betrieb oder das Kernversprechen „alles in Nexus steuerbar“. - **P1:** Wird für den vollständigen täglichen Agentenbetrieb benötigt. - **P2:** Erhöht Plattformreife, Skalierung, Komfort oder Governance. - **P3:** Strategische Erweiterung nach belegter Kernreife. Ein Meilenstein gilt nur dann als abgeschlossen, wenn Implementierung, negative Tests, Bediennachweis, Fehlerzustände, Audit und Dokumentation gemeinsam fertig sind. ## 5. Meilensteine ### M0 — Architektur- und Dokumentationsvertrag **Priorität:** P0 **Ergebnis:** Alle Beteiligten bauen gegen dieselbe Zielarchitektur. - [x] Verbindlichen Pfad `Nexus -> OpenClaw -> OpenAI` dokumentieren. - [x] Runtime-, Provider- und Domänen-Ownership trennen. - [x] Direkte OpenAI-Anbindung in Nexus explizit ausschließen. - [x] Seiten- und Capability-Evaluation auf das korrigierte Zielbild abstimmen. - [ ] Architekturentscheidungen als ADRs für Gatewaygrenze, Secret Ownership, Session Ownership und Audit/Korrelation ergänzen. - [ ] Begriffe `Task`, `Run`, `Session`, `Subagent`, `Approval` und `Artifact` als gemeinsames Glossar festschreiben. **Abnahme:** README, Zielvertrag, Evaluation, Roadmap und Obsidian-Mirror widersprechen sich nicht. ### M1 — Vertrauensgrenze und OpenAI über OpenClaw **Priorität:** P0 **Ergebnis:** Ein echter, sicherer Nexus-Auftrag wird über OpenClaw mit OpenAI ausgeführt und ist Ende-zu-Ende nachweisbar. Security: - Authenticated-by-default für die API erzwingen. - Benutzer-, Service- und Agentenidentitäten stark trennen und caller-kontrollierte Header niemals als alleinigen Nachweis akzeptieren. - Gatewayzugriff mit kleinstmöglichen Operator-Scopes aufteilen: read, write, approvals und admin nur dort, wo erforderlich. - Credential-artige Literale rotieren, aus Arbeitsbaum und gegebenenfalls Historie entfernen sowie Secret-Scanning als Gate ergänzen. - Gatewayversion pinnen oder als explizit kompatiblen Bereich validieren. - Transport, Reconnect, Timeout, Retry und Circuit-Breaker-Verhalten definieren. OpenAI-Konfiguration in OpenClaw: - OpenAI-Credentials ausschließlich in OpenClaw über Umgebungsvariable, Secret Provider oder sichere Auth-Profile verwalten. - Primärmodell und erlaubte `openai/...`-Modelle explizit in OpenClaw setzen. - Rollenbezogene Modellpolitik, Aliase, optionale Fallbacks, Limits und Budgets definieren. - Nexus zeigt Verbindungsstatus, Provider, Modellpolicy, letzte Prüfung und Fehler an, aber niemals Secretwerte. - Ein Live-Smoke-Test belegt: `Nexus -> OpenClaw session -> OpenAI model -> OpenClaw result -> Nexus`. - Audit und Telemetrie belegen den tatsächlich verwendeten Provider und das Modell, ohne Prompts, personenbezogene Daten oder Secrets unnötig zu loggen. **Checkpoint 2026-07-30:** Authenticated-by-default, Device-Key/-Token- Persistenz, Endpoint-/TLS-Bindung, read-only-first Setup, Capability-Prüfung, bewusster Admin-Scope-Upgrade und secret-sichere Modell-Authstatus-Projektion sind lokal umgesetzt. Der Connector verwendet keine reservierte interne OpenClaw-Identität. Offen bleiben die offiziell unterstützte externe Nexus-/Generic-Client-ID, reales Pairing und Scope-Upgrade sowie der End-to-End-Nachweis mit OpenAI. **Abnahme:** Kein Netzwerkpfad von Nexus zu OpenAI ist nötig; ein realer OpenAI-Lauf über OpenClaw ist wiederholbar grün und ein ungültiges oder unberechtigtes Gatewaykommando scheitert sichtbar und sicher. ### M2 — Typisierte OpenClaw Control Plane **Priorität:** P0 **Ergebnis:** Nexus kann OpenClaw sicher erweitern, ohne rohe RPC-Aufrufe in Views oder Domänendiensten zu verteilen. - Den generischen Gatewayclient hinter domänenspezifischen Verträgen kapseln: - `IOpenClawGatewayReadClient` - `IOpenClawGatewayControlClient` - Sessions/Run Service - Agent Service - Model/Auth-Profile Service - Tool/Approval Service - Cron Service - Channel Service - Node Service - Config/Recovery Service - `InvokeToolAsync` als private Low-Level-Implementierung behandeln. - Gateway-Schema und path-scoped Config-Schema entdecken und vor Mutationen validieren. - Pro Operation erforderliche Scope, Risiko, Approval und Auditpayload deklarativ hinterlegen. - Jede Mutation erhält Idempotency Key, Correlation ID, Actor, Target, erwartete Version und nachvollziehbares Ergebnis. - Optimistische Versionsprüfung für Config-Mutationen und klaren Konfliktflow ergänzen. - Read Models mit `source`, `observedAt`, `staleAfter` und Reconnectzustand versehen. - Fehler nicht in leere Listen umwandeln; offline, unauthorized, stale, incompatible und partial müssen unterscheidbar sein. **Checkpoint 2026-07-30:** `IGatewayConnector`, `IOpenClawControlService` und separate Setup-, Agent-Configuration-, Wizard- und Run-Services kapseln den verwendeten RPC-Umfang. Read Models tragen State, Recovery und Beobachtungszeit; Methoden-, Scope-, Versions- und Hashfehler bleiben unterscheidbar. Agent-Dateien, Config und Cron verwenden Idempotenz, Correlation, Audit und optimistische Hashprüfung. Offen bleiben getrennte Fachverträge für Tools, Channels und Nodes sowie ein transaktionaler Multi-Replica-Ledger. **Abnahme:** Kein Frontend- oder Domänencode ruft generische OpenClaw-Methoden direkt auf; alle privilegierten Mutationen besitzen Contract-, Auth-, Negativ- und Audit-Tests. ### M3 — Universeller agent-first Einstieg, Sessions und Runs **Priorität:** P0/P1 **Ergebnis:** Ziele werden von jeder Seite aus an Iris übergeben; Ausführungen bleiben über Reloads hinweg auffindbar und steuerbar. - Globale Command Bar und alle sichtbaren „Ask Iris“-Einstiege funktional vereinheitlichen. - Kontext der aktuellen Route und ausgewählter Objekte explizit anzeigen und vor dem Senden editierbar machen. - Iris-Chat standardmäßig als Modal/Drawer öffnen und Streaming, Stop, Retry sowie nachvollziehbare Fehler bieten. - Session Explorer mit Liste, Suche, Filtern, Verlauf, Freshness und Detailansicht liefern. - Session starten, senden, verzweigen, archivieren und — soweit OpenClaw es unterstützt — zurücksetzen oder kompaktieren. - OpenClaw-Session und Subagent-Task mit Nexus-Projekt, Task, Owner und Control-Audit korrelieren. - Subagenten starten, Hierarchie anzeigen, Status/Logs verfolgen, abbrechen und Ergebnis übernehmen. - Dashboard-Live-Orchestrierung auf autoritative Session-/Run-Ereignisse umstellen; keine rein aus Text abgeleiteten Betriebszustände. - Reload-/Reconnect-Recovery und Deep Links zu Session, Agent, Task und Artifact ergänzen. **Abnahme:** Ein Owner kann ausschließlich in Nexus einen Auftrag formulieren, Subagenten beobachten, einen riskanten Schritt freigeben, den Lauf stoppen und nach einem Reload wiederfinden. ### M4 — Agenten, Modelle, Tools und Approvals **Priorität:** P1 **Ergebnis:** Die zentralen Runtime-Ressourcen sind ohne OpenClaw-UI sicher bedienbar. Agenten: - Erstellen oder aus erlaubten Vorlagen importieren. - Aktivieren, deaktivieren, neu starten und kontrolliert entfernen. - Rolle, Workspace, Modellpolicy, Capability-Profil, Tools und Budget anzeigen. - Drift zwischen gewünschter Policy und OpenClaw-Istzustand erkennen. Modelle und Provider: - OpenAI-Verbindungs- und Auth-Profilstatus anzeigen. - Primärmodell, rollenbezogene Aliase, Allowlist und Fallbacks über OpenClaw verwalten. - Modellkatalog, Fähigkeiten, Limits und gemessene Qualität darstellen. - Policyänderungen mit Diff, Version, Approval und Rollback absichern. - Budget- und Usage-Grenzen mit Warnung und kontrolliertem Fallback ergänzen. Tools und Freigaben: - OpenClaw-Tool-Katalog, Schemas und effektive Toolrechte darstellen. - Toolprofile sowie Allow-/Deny-Regeln global und pro Agent steuern. - Approval Inbox für Exec, Plugin, Config, externe Datenweitergabe und irreversible Aktionen liefern. - Zeitlimit, Begründung, Entscheider, Policyversion und Ergebnis jeder Freigabe protokollieren. - Tool-Ausgaben als nicht vertrauenswürdige Daten behandeln und Prompt-Injection-/Exfiltrationsgrenzen sichtbar machen. **Checkpoint 2026-07-30:** Agent-Inventar und Bootstrap-Dateien stammen live aus OpenClaw; erlaubte Dateien sind mit Expected Hash und Read-back editierbar, zusätzliche Workspace-Dateien read-only. Standing Orders werden kontrolliert in `AGENTS.md` gepflegt. `/models` zeigt den Live-Katalog und ausschließlich den redigierten `models.authStatus`. Agent-Lifecycle, Tool-Katalog/-Policies, Modell-Policy-Mutationen, Budgets und Evals bleiben offen. **Abnahme:** Ein Modell-, Tool- oder Agentenwechsel ist ohne rohe `openclaw.json`-Bearbeitung möglich, lässt sich zurückverfolgen und kann keine Secrets offenlegen. ### M5 — Scheduler und Automationen **Priorität:** P1 **Ergebnis:** Alle regelmäßigen Agentenabläufe sind in Nexus plan- und kontrollierbar. - Cron Jobs auflisten, suchen, erstellen, kopieren und bearbeiten. - Aktivieren, pausieren, fortsetzen, sofort ausführen und entfernen. - Zeitzone, Session Mode, Zielagent, Payload, Delivery/Webhook, Owner und Projektbezug konfigurieren. - Nächsten Lauf, letzte Ausführung, Run-Historie, Dauer, Fehler und Retry darstellen. - Vorlagen für wiederkehrende Reports, Wartung, Recherche und Incident Checks anbieten. - Admin-relevante Mutationen über Approval und Scope Gate absichern. - Retry-/Backoff-, Missed-run- und Alerting-Policies definieren. **Checkpoint 2026-07-30:** Liste, Detail, Create, Edit, Enable/Disable, Delete, Sofortlauf und paginierte OpenClaw-Run-Historie sind typisiert umgesetzt. Mutationen benötigen Owner, lokale Managementfreigabe, `operator.admin`, Idempotency Key und bei vorhandenen Jobs den aktuellen Ressourcenhash. Ein Sofortlauf wird nur als eingereiht gemeldet; der tatsächliche Ausgang stammt aus `cron.runs`. Command-Payloads und `on-exit` bleiben durch `AllowCommandCron=false` gesperrt. Offen bleiben Live-Schreibabnahme, Copy/Templates und umfassende Retry-/Missed-run-/Alerting-Policies. **Abnahme:** Ein Scheduler-Workflow kann vollständig in Nexus angelegt, probeweise ausgeführt, pausiert, diagnostiziert und entfernt werden. ### M6 — Knowledge, Workspaces und Artifacts **Priorität:** P1 **Ergebnis:** Agentenwissen und Outputs sind kontrollierbar, versioniert und mit Arbeit verknüpft. - Memory-Einträge erstellen, bearbeiten, archivieren und löschen. - Dokumente hochladen, importieren, schreiben, versionieren und freigeben. - Quelle, Owner, Scope, Freshness, Retention und Ingestionstatus anzeigen. - Retrieval-Tests und zitierbare Provenienz ergänzen. - Workspace-Dateien über erlaubte Roots browsen und bearbeiten. - Schreibzugriffe mit Diff, Allowlist, Backup, Validierung und Approval absichern. - Artifacts hochladen, anzeigen, herunterladen, versionieren und mit Session, Task, Projekt sowie Incident verknüpfen. - Sensible Daten klassifizieren und Export-/Retention-Policies anwenden. **Checkpoint 2026-07-30:** Die Standard-Agentdateien werden über `agents.files.*` verwaltet. Weitere Dateien wie `DREAMS.md` oder `memory/YYYY-MM-DD.md` werden über `agents.workspace.*` angezeigt und bleiben mangels sicherem beliebigem Workspace-Write-RPC read-only. Die eigenständigen Nexus-Flächen für Memory, Docs, Ingestion, Versionierung und Artifacts sind damit noch nicht abgeschlossen. **Abnahme:** Ein Agent kann aus Nexus freigegebenes Wissen nutzen, ein Artifact erzeugen und dessen Herkunft bis zum Auftrag und Tool-Aufruf nachvollziehbar machen. ### M7 — Operations, Governance und Recovery **Priorität:** P1 **Ergebnis:** Mission Control steuert nicht nur Agenten, sondern auch den sicheren Betriebsalltag. - Zentrale Approval Inbox mit Filtern, SLA, Eskalation und Batch-Entscheidung für ausschließlich risikoarme, gleichartige Fälle. - Benachrichtigungsregeln, Kanäle, Snooze, Acknowledge und Quiet Hours. - Incidents erstellen, bestätigen, zuweisen, eskalieren, beheben, schließen und als Postmortem dokumentieren. - Session-, Task-, Tool- und Providerereignisse mit Incidents korrelieren. - Security Center mit tatsächlicher Policy-/Auth-Lage, Remediation und Evidenz statt reiner Konfigurationsanzeige. - Nutzer-Sessions, Geräte, 2FA/Passkeys, Schlüsselrotation und Recovery Codes. - Autoritativer Audit-/Event-Stream mit Actor, Korrelation, Diff, Suche, Export und Retention. - Gateway-Recovery mit Version, Health, kontrolliertem Reload, Backup, Rollback und Break-glass-Prozedur. **Abnahme:** Kritische Fehler und riskante Aktionen können in Nexus erkannt, freigegeben, behoben und vollständig auditiert werden. ### M8 — Channels, Connectors, Nodes und Parität **Priorität:** P2 **Ergebnis:** Auch OpenClaw-nahe Infrastruktur muss im Alltag nicht separat bedient werden. - Channels verbinden, Status/Capabilities prüfen, Logs filtern und kontrolliert trennen. - Connectorrechte, Datenfreigaben und Approval Policies verwalten. - Nodes/Hosts inventarisieren, pairen, Health und Capabilities anzeigen. - Node-Aktionen erlaubnis- und approval-basiert ausführen. - Gateway-Konfiguration über Live-Schema, strukturierte Formulare und Diff pflegen; keine unvalidierte Raw-JSON-Konsole als Hauptweg. - Updates und Reloads mit Kompatibilitätsprüfung, Wartungsmodus, Backup und Rollback steuern. - Optional Voice-, Media- und Mobile/PWA-Oberflächen ergänzen, sobald die Control-Plane-Gates stabil sind. **Checkpoint 2026-07-30:** Settings enthält einen schema-basierten OpenClaw-Configeditor mit `config.schema.lookup`, `config.get`, `config.patch`, `baseHash`, Diff-Vorschau und `replacePaths`. Der offizielle `wizard.*`-Flow wird sicher gerendert, sobald die verbundene Instanz ihn mit Managementfreigabe und `operator.admin` bewirbt. Channels, Nodes, Update-/Reload- und Recovery-Parität bleiben offen. **Abnahme:** Die dokumentierte tägliche OpenClaw-UI-Checkliste besitzt für jeden normalen Vorgang einen sicheren Nexus-Workflow. ### M9 — Observability, Kosten, Evals und Release-Reife **Priorität:** P2 **Ergebnis:** Qualität, Kosten und Betriebssicherheit sind messbar und regressionsfest. - Autoritative Provider-, Modell-, Token-, Kosten- und Latenzdaten erfassen. - Trace-/Run-Explorer für Session-, Tool-, Approval-, Artifact- und Fehlerereignisse liefern. - Budgets und Alerts pro Projekt, Agent, Modell und Zeitraum. - Eval-Datasets für Instruction Following, funktionale Korrektheit, Tool-Auswahl und Argumentgenauigkeit pflegen. - Prompt-, Agenten-, Modell- und Policyversionen in Vergleichsläufen messen. - Qualitäts-, Kosten-, Security- und Latenzschwellen als Release Gates. - E2E-Tests über Browser, Nexus, OpenClaw, OpenAI und PostgreSQL. - Alle Routen auf Auth, Loading, Empty, Error, Keyboard und 375/768/1024/1440/1920 px testen. - Last-, Reconnect-, Timeout-, Queue-, Recovery- und Chaos-Szenarien prüfen. - Runbooks, Backup/Restore und Rollback regelmäßig als Game Day testen. **Checkpoint 2026-07-31:** Das v0.2.60-Stabilitätsfundament implementiert separate Readiness, einen generierten Fehlervertrag, gemeinsame UI-Recovery, ein SDK-/Versionsgate, Supply-Chain-Scans und verpflichtende Containerverträge. Der kontrollierte Browserlauf deckt alle 20 authentifizierten Views und fünf Breiten ab. Offen bleiben der grüne Linux-/Docker-Run, credentialed Produktionsprüfung, der 1.000/10.000-Task-Board-Lastnachweis sowie reale OpenClaw-/OpenAI-End-to-End-Evidenz. **Abnahme:** Ein Release ist nur möglich, wenn technische Checks und ein repräsentativer realer Agenten-Workflow gemeinsam grün sind. ### M10 — Strategische agent-first Erweiterungen **Priorität:** P3 **Ergebnis:** Nach belegter Kernreife wird Nexus vom Cockpit zum proaktiven Operationssystem. - Ziel- und Outcome-Management mit Agentenplänen, KPIs und Abbruchkriterien. - Wiederverwendbare Agenten-, Workflow- und Projekt-Playbooks. - Simulation/Dry Run für riskante oder kostenintensive Ausführungen. - Policy-basierte Auto-Approvals für eng begrenzte, reversible Aktionen. - Proaktive Opportunity-, Risk- und Drift-Erkennung mit menschlicher Bestätigung. - Multi-Workspace-/Teamgrenzen und delegierte Administration. - Agentenqualitäts-SLOs, automatische Regressionserkennung und modellabhängige Routingoptimierung. ## 6. Auswirkungen auf die 18 bestehenden Seitenfamilien | Route | Zielrolle | Verbindliche Verbesserungen | Meilenstein | |---|---|---|---| | `/login` | Sicherer Zugang | Recovery, Return-to-Route, 2FA/Passkeys, Geräte/Sessions | M1, M7 | | `/dashboard` | Mission Overview | echte Command Bar, autoritative Run-Hierarchie, Queue, Providerstatus, Usage, Fehler/Recovery | M1, M3, M9 | | `/memory` | Wissensspeicher | CRUD, Scope, Provenienz, Freshness, Retention, Retrieval-Evals | M6, M9 | | `/docs` | Knowledge Ingestion | Upload/Authoring, Import/Sync, Versionen, Zitate, Freigaben | M6 | | `/agents/:id` | Agent Cockpit | live Bootstrap-Dateien, Standing Orders und read-only Workspace vorhanden; Lifecycle, Sessions, Subagenten, Tools, Modellpolicy, Budget, Evals offen | M3, M4, M9 | | `/security` | Security Center | echte Auth-/Policylage, Findings, Remediation, Rotation, Sessions, Audit | M1, M7 | | `/incidents` | Incident Operations | Create/Ack/Assign, Timeline, Run-Bezug, Remediation, Resolve, Postmortem | M7 | | `/calendar` | Automation Scheduler | Cron-CRUD, Enable/Disable, Sofortlauf und History vorhanden; Live-Abnahme, Templates, Retry-Policy und Delivery-Härtung offen | M5 | | `/projects` | Portfolio | Ziele, Team, Runs, Tasks, Artifacts, Budget, Health, Automationen | M3, M6, M9 | | `/projects/:id` | Project Control | Delegation, Runstart, KPIs, Team, Timeline, Budget, Playbooks | M3, M6, M10 | | `/tasks` | Agent Work Queue | Run-/Approval-Bezug, Dependencies, Bulk, Retry/Resume/Cancel, ehrliche Fehler | M3, M7 | | `/tasks/:id` | Task Control | Session/Run, Tools, Approvals, Artifacts, Abhängigkeiten, Replay | M3, M6 | | `/agents` | Runtime Workforce | Live-Inventar vorhanden; Create/Import, Enable/Disable/Restart, Capabilities, Permissions, Last und Kosten offen | M4, M9 | | `/models` | OpenAI Policy via OpenClaw | redigierter Authstatus vorhanden; Primärmodell, Allowlist, Aliase, Fallbacks, Limits und Tests offen | M1, M4 | | `/activity` | Audit/Event Stream | autoritative Events, Correlation ID, Actor, Diff, Suche, Export, Retention | M2, M7 | | `/runs` | Run Control | Start/Resume/Retry/Branch, Deep Links, Trace, Tools, Artifacts und dauerhafte Korrelation | M2, M3, M7 | | `/notifications` | Action Inbox | Loading/Error, Ack/Snooze, Preferences, Routing, Approval-/Incident-Aktionen | M7 | | `/settings` | Control-Plane Setup | Attach & Adopt, Management-Gate, Configschema und Wizard vorhanden; offizielle Client-ID, Live-Pairing, Tools, Approvals und Retention offen | M1, M4, M7, M8 | Seit dem 2026-07-31-Checkpoint liefern die fachlichen Task-, Projekt-, Notification-, Cron-, Config-, Approval-, Session- und Agent-Datei-Mutationen ein gemeinsames `OperationResultDto`. Das globale Ergebnisfenster verlinkt Primär- und Folgeobjekte; Task Detail, Run Control, Calendar, Agent Detail, Activity, Notifications und Settings konsumieren die jeweilige Deep-Link- Auswahl. Damit ist die querschnittliche Ergebnisnavigation umgesetzt. Offen bleiben die in der Tabelle genannten fachlichen Funktionen und die externen Live-/Lastgates, nicht ein weiterer paralleler Frontend-Ergebnisvertrag. Iris Chat ist kein eigener Route mehr. Er bleibt als persistenter, kontextueller Dashboard-Dialog und globales Ziel für „Ask Iris“. ## 7. Vorgeschlagene neue Arbeitsflächen Diese Routen sind Produktvorschläge. Sie dürfen erst in Navigation oder Deep Links erscheinen, wenn Route und funktionsfähiges Ziel registriert sind. | Vorgeschlagene Route | Zweck | Alternative bei kleinerem Scope | |---|---|---| | `/runs/:id` | dauerhafte Deep-Link-Ansicht eines korrelierten Laufs (umgesetzt) | `/agents/:id?session=...` | | `/tools` | Katalog, Schemas, effektive Rechte und Policies | Tab in Agent Detail | | `/approvals` | zentrale menschliche Freigaben | Notifications-Filter als erster Slice | | `/artifacts` | Outputs, Dateien, Herkunft und Versionen | Project-/Task-Tab | | `/channels` | Channelstatus, Capabilities und Logs | Settings-Tab | | `/nodes` | Hosts, Pairing, Health und erlaubte Aktionen | Settings-Tab | | `/evals` | Datensätze, Vergleiche und Qualitätsgates | Models-Tab | `/runs` und der dauerhafte `/runs/:id`-Pfad sind umgesetzt. Approvals können bis zur benötigten Inbox-Tiefe in Run Control und Notifications bleiben. Tools, Channels und Nodes können initial als Tabs starten, solange Navigation und Informationsarchitektur nicht überladen werden. ## 8. Querschnittsabhängigkeiten ```mermaid flowchart TD M0["M0 Architekturvertrag"] --> M1["M1 Trust + OpenAI über OpenClaw"] M1 --> M2["M2 Typisierte Gateway Control Plane"] M2 --> M3["M3 Sessions, Runs, Iris"] M2 --> M4["M4 Agents, Models, Tools, Approvals"] M2 --> M5["M5 Scheduler"] M3 --> M6["M6 Knowledge + Artifacts"] M3 --> M7["M7 Operations + Governance"] M4 --> M7 M5 --> M7 M6 --> M8["M8 Ecosystem-Parität"] M7 --> M8 M3 --> M9["M9 Observability + Evals"] M4 --> M9 M5 --> M9 M8 --> M10["M10 Strategische Erweiterungen"] M9 --> M10 ``` M3 bis M5 dürfen vertikal in kleine Slices zerlegt werden. Sie dürfen aber nicht die M1-/M2-Vertrauensgrenze umgehen. ## 9. Nächster empfohlener Implementierungsslice **Slice: „Official external identity and controlled live acceptance“** 1. Upstream eine offiziell unterstützte externe `nexus`- oder generische Operator-Client-ID verwenden und Nexus auf die erste unterstützende OpenClaw-Version pinnen; keine reservierte interne Identität imitieren. 2. Auf Baos ausdrücklich freigegebener OpenClaw-Instanz read-only verbinden, die konkrete Pairing-Request-ID freigeben lassen und Agent-/Cron-Inventar gegen den erwarteten Bestand abgleichen, ohne Runtime-Daten zu kopieren. 3. Den bewussten Admin-Scope-Upgrade separat pairen und Endpoint-, Device-, TLS-, Scope- und Capability-Bindung im Security Center belegen. 4. Ausschließlich an eindeutig benannten Testobjekten je einen Hashkonflikt-/Read-back-Test für Agent-Datei und Config sowie Create/Edit/ Run/History/Delete für Cron durchführen. Andere Ressourcen bleiben unangetastet. 5. OpenAI ausschließlich in OpenClaw als Primärprovider für Iris konfigurieren und einen echten, dauerhaft korrelierten `Nexus -> OpenClaw -> OpenAI -> Nexus`-Run ausführen. 6. Provider-/Modellreferenz, Events, Stop/Retry, Reload-Recovery, Audit und Negativfälle ohne Prompt-, Delivery- oder Secret-Leak belegen. Dieser Slice löst den externen Identitätsblocker und liefert den ersten vollständigen Beweis, dass Attach & Adopt sowie ein normaler agent-first Arbeitsablauf ohne Wechsel in die OpenClaw-Oberfläche sicher funktionieren. ## 10. Definition of Done für „kein OpenClaw-Wechsel mehr“ Das Produktversprechen gilt erst als erfüllt, wenn: 1. ein Owner den vollständigen Ablauf `Absicht -> Plan -> Agent/Subagent -> Tool -> Approval -> Artifact -> Review` ausschließlich in Nexus bedienen kann; 2. OpenClaw für alle Runtimezustände autoritativ bleibt, während Nexus diese zuverlässig, aktuell und steuerbar projiziert; 3. jede Modellinferenz aus Nexus nachweislich über OpenClaw läuft und OpenAI dort der primäre Provider ist; 4. kein OpenAI-Secret in Browser, Nexus-Konfiguration, Datenbank oder Logs benötigt oder offengelegt wird; 5. alle normalen Agenten-, Session-, Tool-, Cron-, Modell-, Approval-, Knowledge-, Incident- und Recovery-Aufgaben Nexus-Workflows besitzen; 6. jede riskante Mutation Scope, Policy, Approval, Idempotenz und Audit besitzt; 7. Offline-, Partial-, Stale-, Unauthorized- und Incompatible-Zustände für den Operator verständlich und handlungsfähig sind; 8. reale E2E-, Security-, Eval-, Recovery-, Accessibility- und Responsive-Gates grün sind; 9. die OpenClaw-Oberfläche nur noch für dokumentierten Break-glass- oder Plattformentwicklungsbetrieb gebraucht wird. ## 11. Bewusste Nicht-Ziele - Kein direkter OpenAI-Adapter oder OpenAI-Schlüssel in Nexus. - Keine zweite Agentenruntime, kein zweiter OpenClaw-Session Store. - Keine ungeprüfte Raw-Config-Konsole als primärer Verwaltungsweg. - Keine direkte Browser-Gateway-Verbindung. - Keine Navigation zu nicht registrierten oder leeren Routen. - Kein kosmetisches „Control“-UI ohne wirksame Mutation, Fehlerfeedback und Audit. - Keine komplette Kopie jeder OpenClaw-Entwickleroberfläche; Nexus bildet die Owner- und Operations-Workflows ab. ## 12. Primärquellen OpenClaw: - [Modelle und `provider/model`-Policies](https://docs.openclaw.ai/models) - [Gateway-Protocol-v4-Vertrag](https://docs.openclaw.ai/gateway/protocol) - [Gateway-Client und Geräteidentität](https://docs.openclaw.ai/gateway/clients) - [Stable Client-ID-Registry `2026.7.1`](https://github.com/openclaw/openclaw/blob/v2026.7.1/packages/gateway-protocol/src/client-info.ts) - [Operator-Scopes und Least Privilege](https://docs.openclaw.ai/gateway/operator-scopes) - [Gateway-Konfiguration](https://docs.openclaw.ai/gateway/configuration) - [Offizieller Setup-Wizard](https://docs.openclaw.ai/reference/wizard) - [Background Tasks](https://docs.openclaw.ai/automation/tasks) - [Cron-Operationen und erforderliche Scopes](https://docs.openclaw.ai/cli/cron) - [Tools Invoke HTTP API](https://docs.openclaw.ai/gateway/tools-invoke-http-api) - [Gateway Troubleshooting](https://docs.openclaw.ai/gateway/troubleshooting) OpenAI: - [API-Key-Sicherheit und Produktionsbetrieb](https://developers.openai.com/api/docs/guides/production-best-practices#api-keys) - [Eval-Kriterien für einzelne Agenten](https://developers.openai.com/api/docs/guides/evaluation-best-practices#single-agent-architectures)