bao/nexus
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
38282e4f7f1efed185f5aef9165d50411d713aab
nexus/docs/MISSION_CONTROL_ROADMAP.md
T

32 KiB
Raw Blame History

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:

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.

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.

  • Verbindlichen Pfad Nexus -> OpenClaw -> OpenAI dokumentieren.
  • Runtime-, Provider- und Domänen-Ownership trennen.
  • Direkte OpenAI-Anbindung in Nexus explizit ausschließen.
  • 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.

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

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:

OpenAI:

Reference in New Issue View Git Blame Copy Permalink