# Nexus Route- und Agent-first-Evaluation **Stand:** 2026-07-30 **Bewertungsbasis:** aktueller Working Tree, registrierte Routen in `frontend/src/router.ts`, Implementierungs- und Testnachweise in `ACCEPTANCE_EVIDENCE.md` sowie die ausdrücklich als Simulation markierte Browser-QA vom 2026-07-30 **Ziel:** Nexus als browser-sichere, agent-first Mission Control über OpenClaw, mit OpenAI als primärem Provider innerhalb von OpenClaw ## Gesamturteil Nexus ist inzwischen eine belastbare **Control-Plane-Implementierung**, aber noch kein nachgewiesener vollständiger Ersatz für die OpenClaw-Oberfläche im Produktionsbetrieb. - **Architektur- und Implementierungsreife:** etwa **78/100** - **Reife als täglicher OpenClaw-Ersatz:** etwa **55/100** - **Produktionsnachweis:** etwa **30/100** Diese Werte sind bewusst getrennt. Gute lokale Tests und eine saubere Architektur ersetzen weder ein reales Gateway-Pairing noch einen credentialed `Nexus -> OpenClaw -> OpenAI -> Nexus`-Lauf. Die Anwendung ist bereits agent-first in Einstieg und Grundworkflow: `Ctrl/Cmd+K`, globales Iris-Modal, Objektkontext und korrelierte durable Runs reduzieren den Weg von einer Mission zu einer Agentenausführung deutlich. Sie ist noch nicht vollständig agent-native: Ein Agent kann noch nicht alle Runtime-, Tool-, Provider-, Schedule-, Connector- und Recovery-Aufgaben innerhalb von Nexus durchführen. ## Bewertungsmaßstab Die Route-Wertung für Agent-first-Reife verwendet: - **1/5:** notwendige Basisfläche, aber kein Agentenworkflow; - **2/5:** globaler Iris-/Command-Einstieg, überwiegend lesend; - **3/5:** agentenrelevanter Kontext oder einzelne echte Aktionen; - **4/5:** kontextgebundene Ausführung und operativer Rückkanal; - **5/5:** vollständiger, autoritativer Agentenworkflow ohne Ausweichfläche. „Funktioniert“ bedeutet in diesem Dokument: im Code vorhanden und durch die genannte lokale Evidence gestützt. Es bedeutet nicht automatisch, dass die Funktion gegen das reale Ziel-Gateway bewiesen wurde. ## Gesamtwertung nach Dimension | Dimension | Reife | Evidenz | Wichtigste Grenze | |---|---:|---|---| | Security Boundary | 9/10 | Authentifizierte Fallback-Policy; nur Auth-/Health-Ausnahmen anonym; `X-Agent-Id` ist kein Credential; owner-only OpenClaw-Mutationen; negative Auth-/Rollen-/Header-Tests | MFA/Passkeys, aktive Geräte-/Sessionverwaltung und Zielumgebungs-Härtung fehlen; JSONL-Idempotency-Ledger ist noch Single Writer | | Gateway Readiness | 7/10 | Protocol v4; Default-Pin auf bestätigtem Stable-Tag `2026.7.1`; striktes Loopback; persistente Ed25519-Geräteidentität und Device-Token; Pairing Request ID bis zur UI | Kein reales Pairing, Token-Reuse, Versionsfehler- oder Reconnect-Proof gegen das Ziel-Gateway | | Effizienz der UI-Kommunikation | 7/10 | Browser spricht nur mit Nexus; authentifiziertes SSE zuerst; `Last-Event-ID`; Gap-/Heartbeat-/Connection-Signale; begrenzter Reconnect; 60-s-Fallback; gefilterte und debouncte Consumer | Events invalidieren häufig noch breite Aggregate; zwei Dashboard-Live-Sync-Module und separate Live-Pipelines erzeugen Drift-/Doppelarbeit-Risiko | | Durable Runs | 8/10 | Persist-before-dispatch; Liste, Detail, Historie, exakter Stop, korrelierter Retry, Task-/Projekt-/Session-/Actor-/Trace-Bezug und Gap-Reconciliation | Same-run-Resume ist korrekt `unsupported`; Tool-Trace, Approvals, Artefakte, Usage, Branch/Handoff und Live-E2E fehlen | | Agent-first UX | 7/10 | Globale Command Palette; Objekt-Navigation; kontextuelles Iris; vorausgefüllter Run für Task/Projekt/Agent; Run Control als Operatorfläche | Kontext enthält nur Route/Typ/ID; keine serverseitig angereicherte Objektakte, keine natürliche Command-Ausführung mit Plan/Freigabe, wenige proaktive Agentenaktionen | | Truthful Telemetry | 9/10 | Kein erfundenes Thinking, keine hartcodierten Fortschritte/Kosten/Laufzeiten; unbekannte Werte bleiben „Nicht gemeldet“; Tokens/Fortschritt nur aus gemeldeten Quellen | Autoritative Kosten, Latenz, Tool-Usage und vollständige Run-Usage werden noch nicht geliefert | | Täglicher OpenClaw-Ersatz | 5/10 | Kernübersicht, Chat, Runs, Sessions, Approvals, Modelle, Cron-Run-now, Agents und Recovery-Diagnostik sind erreichbar | Agent-Lifecycle, Tools/Policies, Provider/Auth-Profile, vollständiges Cron CRUD, Nodes/Channels/Connectoren, Secrets, Artefakte und Recovery bleiben unvollständig | | Production Proof | 3/10 | Automatisierte lokale Baseline ist grün; aktuelle Browser-QA deckt alle Seitenrouten und den simulierten Run-Lifecycle mit klar markierter Fixture ab | Kein credentialed Zielsystem-E2E, kein reales Pairing, kein Live-Event-Soak, keine Ziel-PostgreSQL-Migrationsabnahme | ## Kommunikationspfad und UI-Optimierung Der beabsichtigte Vertrauenspfad ist im aktuellen Code sauber: ```text Browser -> Nexus Auth / RBAC / Policy -> typisierte Nexus-OpenClaw-Fassade -> OpenClaw Gateway -> OpenAI und Tools ``` Der Browser erhält weder OpenClaw- noch OpenAI-Credentials. OpenClaw bleibt autoritative Runtime für Agents, Sessions, Models, Cron, Approvals und Gateway-Events. Nexus besitzt Benutzer, Projekte, Produkt-Tasks und die durable Run-/Korrelationsprojektion. ### Was bereits effizient ist - `GET /api/v1/openclaw/events` ist der primäre Live-Pfad. - Der Client sendet den Cursor sowohl als `Last-Event-ID` als auch optionalen Query-Parameter und kann aus dem begrenzten Backend-Buffer wiederaufsetzen. - Reconnect verwendet 2, 5, 10 und maximal 30 Sekunden Backoff. - Polling ist für OpenClaw-Übersicht, Runs, Chat und Agenten nur der **60-Sekunden-Fallback**, wenn der Eventstream nicht live ist. - Run-Consumer reagieren nur auf `openclaw.run`, `openclaw.gap` und `openclaw.connection` und debouncen 350 ms. - Chat reagiert nur auf Session-, Run- und Gateway-Ereignisse und debounct 400 ms. - Agenten debouncen 500 ms; Modelle werden nur bei Gateway-, Connection- oder Sessionereignissen zusätzlich neu geladen. - Heartbeats lösen keinen fachlichen Refresh aus. ### Was noch nicht optimal ist Die Live-Consumer sind **nach Eventtyp gezielt**, die Datenaktualisierung ist aber noch nicht vollständig gezielt: 1. `stores/openclaw.ts` lädt nach jedem Nicht-Heartbeat-Ereignis das gesamte `/api/v1/openclaw/overview`-Aggregat neu. 2. `stores/agents.ts` lädt bei jedem Nicht-Heartbeat-Ereignis erneut die ganze Agentenliste. Bei demselben Gateway-Ereignis können deshalb Overview-, Agenten- und Run-Requests parallel entstehen. 3. Runs laden nach einem passenden Ereignis die Run-Liste und bei offenem Detail zusätzlich die vollständige Historie. 4. `stores/liveSync.ts` und `stores/live-sync.ts` sind inhaltlich doppelte Module mit demselben Pinia-Store-Namen. Parallel existieren der allgemeine Dashboard-SSE-Pfad, direkte Dashboard-Live-Abonnements im Agent Detail und der neue OpenClaw-SSE-Pfad. 5. Nexus-Domainflächen wie Dashboard, Board und Notifications besitzen weiterhin eigene 30-Sekunden-Poller. Das ist fachlich getrennt von OpenClaw, erhöht aber die Gesamtzahl gleichzeitiger Refreshpfade. **Empfohlene Zielstruktur:** genau ein authentifizierter Live-Orchestrator, normalisierte Entity-Stores und eine Event-zu-Invalidierungs-Matrix. Wenn ein Event bereits die sichere Projektion enthält, sollte der Store lokal patchen; sonst sollte er nur das betroffene Endpoint-Aggregat laden. Ein `openclaw.gap` bleibt der korrekte Anlass für einen vollständigen autoritativen Refresh. ## Route-für-Route-Evaluation `/` und `/:pathMatch(.*)*` sind reine Redirects auf `/dashboard` und keine eigenständigen Produktflächen. Die folgenden 19 registrierten Seitenrouten sind die eigentliche UI. | Route | Aktueller Nutzen | OpenClaw-Anbindung und Autorität | Agent-first | Wichtigste fehlende Features | |---|---|---|---:|---| | `/login` | Login, Redirect zur ursprünglich angeforderten Route, Fehlermeldung und Rate-Limit-Countdown | Nexus Auth ist autoritativ; schützt die gesamte OpenClaw-Fassade indirekt | 1/5 | Passkeys/2FA, Recovery, Geräte- und aktive Sessionverwaltung | | `/dashboard` | Verdichtete Live-Orchestrierung, Agentenmodal, gemeldete Telemetrie, Task-Leiste; Iris bleibt platzsparend verborgen | Gemischte Projektion: OpenClaw-Agenten/-Sessions plus Nexus-Tasks; Modellwechsel geht über Nexus an OpenClaw | 4/5 | Direkter Run-Start/Stop im Graph, echte Session-/Tool-/Approval-Kanten, normalisierte eventbasierte Patches statt mehrerer Poll-/SSE-Pfade | | `/memory` | Memory-Liste, Suche, Reader, Lade-/Leer-/Fehlerzustände | Inhalt ist Nexus-/Workspace-owned; nur globaler OpenClaw-Status und Iris-Kontext | 2/5 | Ingestion, Scope, Provenienz, Freshness, Retention, Retrieval-Evals und agentengesteuerte Kuratierung | | `/docs` | Kategorien, Suche, Dokumentliste und Reader | Dokumente sind Nexus-/Workspace-owned; kein autoritativer OpenClaw-Sync | 2/5 | Upload/Import, Versionen, Freigabe, Zitate, Syncstatus und Zuordnung zu Agent/Run | | `/agents/:id` | Agentenstatus, Aktivität, Zusammenfassung und Editor für Identitäts-/Policy-Dateien mit Validierung und Backup | Runtime-/Historienanteile kommen über Backend/OpenClaw; Konfigurationsdateien bleiben Nexus-/Workspace-verwaltet; Reload ist explizit nicht unterstützt | 4/5 | Create/import, enable/disable/restart, effektive Toolrechte, Budget/Evals, Driftanzeige und kontrolliertes Gateway-Apply/Reload | | `/security` | Nexus-Authstatus, Token-/Cookie-/Passwortzustand sowie effektive Gateway-, Scope- und Approval-Grenze | Nexus Security plus read-only OpenClaw-Trust-/Capability-Projektion | 2/5 | Remediation-Aktionen, effektive Policy-Matrix, Scope-Diffs, Geräte-/Sessionverwaltung, MFA/Passkeys und Security-Audit-Timeline | | `/incidents` | Incident-Dateien lesen; aktuelle fehlgeschlagene Runtime-Tasks erkennen; Recovery-Link zu Run Control | Incident-Akte ist Nexus-owned, Runtime-Failure-Slice kommt aus OpenClaw | 2/5 | Create/ack/assign/escalate/resolve, automatische Eventkorrelation, Runbook-Ausführung, Postmortem und dauerhafte Run-/Trace-Links | | `/calendar` | OpenClaw-Jobs, nächste/letzte Ausführung und owner-bestätigtes „Run now“ | `cron.list` und `cron.run`; OpenClaw ist autoritativ | 3/5 | Create/edit, enable/pause/delete, Zeitzone, vollständige Historie, Retry, Ergebnis-/Run-Korrelation | | `/projects` | Nexus-Projektportfolio und Projektanlage; Detailnavigation | Nexus ist autoritativ; dynamische Command-Suche kann geladene Projekte öffnen | 2/5 | Runtime-Rollup pro Projekt, Agents/Runs/Approvals/Budget/Artefakte und direkte Delegation | | `/projects/:id` | Projekt bearbeiten/archivieren und zugehörige Tasks sehen | Nexus-Projekt bleibt autoritativ; Command Palette kann einen `projectId`-korrelierten Run vorbereiten | 3/5 | Eingebettete Run-Liste, Automationspolicy, Budget, Artefakte, Statusrückfluss und „Iris übernimmt“-Workflow | | `/tasks` | Vollständiges Kanban, CRUD, Statuswechsel, Child-/Waiting-/Stale-Sicht und OpenClaw-Runtime-Strip | Task ist Nexus-owned; Live-Dashboard-Sync und OpenClaw-Übersicht laufen parallel; Übergabe zu Run Control vorhanden | 3/5 | Sichtbare persistente Task↔Run/Session-Korrelation auf Karten, Inline-Start/Stop/Retry/Approval und einheitlicher Live-Store | | `/tasks/:id` | Task bearbeiten, Status, Child-Tasks, Kommentare und Aktivität | Nexus ist autoritativ; Command Palette bereitet einen `taskId`-korrelierten durable Run vor | 4/5 | Verknüpfte Runs/Sessions direkt anzeigen, Tool-/Approval-/Artefakt-Timeline, Run-Ergebnis zurückschreiben und Replay | | `/agents` | OpenClaw-nahe Agenteninventur mit Status, Modell, Aufgabe und nur gemeldeter Progressanzeige | Runtimezustand über Nexus-Fassade/OpenClaw; statische Fallbacks liefern nur beschreibende Metadaten, keine erfundene Telemetrie | 3/5 | Lifecycle, Import/Create, Capability-/Toolpolicy, Budget, Health-Historie, Drift und Bulk-Aktionen | | `/runs` | Stärkste Operatorfläche: durable Run starten, Work Graph, Tasks, Sessions, Approvals, Cron, Events, Capabilities, Cancel/Abort/Resolve/Run-now | OpenClaw ist Runtime-Autorität; Nexus ist durable Ledger-, Policy- und Korrelationsschicht | 4/5 | Same-run-Resume oder belegte Alternative, Branch/Handoff, Tooltrace, Artefakte, Usage/Cost, bessere Run-Filter und Ende-zu-Ende-Ergebnisfluss | | `/runs/:id` | Durable Run, exakter Zustand, Stop/Retry, Transitionen, redigierte Gateway-Historie, Korrelationen, Gap-Warnung und Reconcile | Nexus-Run-Ledger plus OpenClaw-Ausführung/-Historie; Resume wird ehrlich als unsupported gezeigt | 4/5 | Same-run-Resume, Tool-/Approval-/Artefakt-Timeline, Token/Kosten/Latenz, Child-Runs, Branch/Handoff und positives Live-Gateway-Proof | | `/models` | Live-Katalog, Providerfilter, Verfügbarkeit, Kontextgröße und aktuelle Sessionnutzung | `models.list`; OpenClaw ist autoritativ, Browser sieht keine Secrets | 2/5 | OpenAI-Auth-Profilstatus, Primary/Alias/Fallback-Policy, Limits/Budgets, Testlauf und kontrollierte Default-Änderung | | `/activity` | Gemeinsame Suche/Filterung für OpenClaw- und Nexus-Ereignisse mit Detailansicht | Gemischte, klar markierte Quellen; OpenClaw-Runtime-Events bleiben von Nexus-Events unterscheidbar | 3/5 | Durchgängige Correlation-/Trace-Links, Actor/Diff, Pagination, Export, Retention, Run-Deep-Link und direkte Recovery | | `/notifications` | Nexus-Benachrichtigungen, Mark-read/Mark-all und Zusammenfassung offener OpenClaw-Approvals | Nexus besitzt Notifications; OpenClaw besitzt Approvalstatus | 2/5 | Inline allow/deny, exakte Objekt-Deep-Links, Snooze, Quiet Hours, Routingpräferenzen, Eskalation und Incident-Aktionen | | `/settings` | Profil, Passwort, User-Administration und Gatewaydiagnostik mit Version, Device ID, Scopes und Pairing Request ID | Nexus-Konfiguration plus read-only OpenClaw-Verbindungs-/Pairingzustand; Secrets bleiben außerhalb des Browsers | 2/5 | Pairing-Abschlussworkflow, validierte Provider-/Auth-Profil-/Policy-Formulare, Config-Diff, Backup, kontrollierter Reload/Rollback und Connectorverwaltung | ## Ist Nexus sinnvoll für OpenClaw und „agent first“ optimiert? **Ja, architektonisch und im Kernworkflow. Noch nicht vollständig operativ.** Positiv: 1. Das Frontend kennt keine OpenClaw-Transportdetails und keine Provider-Secrets. 2. OpenClaw-Aktionen laufen durch Auth, Rolle, Capability-Prüfung, Idempotency, Correlation, Trace und Audit. 3. Die Command Palette macht Agents, Sessions, Tasks und Projekte zu adressierbaren Arbeitsobjekten. 4. Iris erhält auf jeder authentifizierten Route einen begrenzten, serverseitig als nicht vertrauenswürdig markierten Kontext. 5. Runs sind nicht mehr nur flüchtige Chataktionen, sondern durable, korrelierte Objekte mit eigener URL und Historie. 6. Unbekannte Runtimewerte werden nicht länger durch optisch überzeugende Fantasiewerte ersetzt. Noch nicht ausreichend: 1. Der Iris-Kontext enthält nur Surface, Route, Entity-Typ und ID. Für eine wirklich agent-first Bedienung sollte das Backend nach Autorisierung eine kompakte Objektakte mit Zustand, erlaubten Aktionen, Freshness und Korrelationen ergänzen. 2. Die Command Palette startet Navigation oder öffnet Formulare, führt aber noch keinen strukturierten natürlichen Befehl mit Planvorschau, Risikoklasse, Approval und Ergebnisrückgabe aus. 3. Agenten können über Nexus noch nicht ihren vollständigen Lifecycle, ihre effektiven Tools, Provider-Policies, Schedules, Connectoren und Secrets kontrollieren. 4. Ein Run endet in der UI noch nicht als vollständiges Arbeitsprodukt aus Tooltrace, Freigaben, Artefakten, Usage, Bewertung und Rückschreiben in Task/Projekt. 5. Ohne echte Evals ist nicht belegt, dass Iris das richtige Tool mit den richtigen Argumenten wählt und eine fachlich korrekte Mission abschließt. ## Evidence: Simulation, lokale Abnahme und Live-Nachweis ### Lokal automatisiert abgenommen Die aktuelle Acceptance Evidence dokumentiert: | Gate | Ergebnis | |---|---| | Backend-Tests | 271 bestanden, 0 fehlgeschlagen, 0 übersprungen | | `pnpm typecheck` | bestanden | | `pnpm test` | 6 Dateien, 11 Tests bestanden | | `pnpm build` | bestanden, 1.897 Module transformiert | Damit sind Security-Invarianten, Gateway-Protokoll, Pairingpersistenz, Mutationsmetadaten, Eventprojektion, durable Run-Domain, Context-Sanitizing und Frontend-Stores lokal abgesichert. ### QA-Simulation Die operierte Browser-QA vom 2026-07-30 nutzte `scripts/qa/openclaw-ui-mock.mjs`. Die Antworten waren mit `X-Nexus-QA-Fixture` markiert und die UI zeigte `QA SIMULATION`. Die aktuelle Evidence belegt: - alle 19 Seitenrouten bei 1440 px ohne Dokument-Overflow oder sichtbare Alerts; `/login` leitete die bestehende authentifizierte Session erwartbar zu `/dashboard` weiter; - alle 18 authentifizierten Seiten bei 375 px ohne Dokument-Overflow sowie Dashboard, Run Control, Run Detail, Task Board, Calendar und Settings zusätzlich bei 768, 1024 und 1920 px; - Command Palette per Button und `Ctrl/Cmd+K`, Escape-Schließen und Fokus-Rückgabe; - globales und seitenbezogenes Iris-Modal mit erhaltenem Route-/Objektkontext; - Task-korreliertes Vorausfüllen eines neuen Runs; - simulierten exakten Stop sowie Retry als neuen korrelierten Run mit unveränderter Quellhistorie; - eine leere Browserkonsole für Warnungen und Fehler im finalen Lauf. Diese Evidence belegt **nicht**: - ein reales OpenClaw Gateway; - ein echtes Device Pairing; - einen OpenAI-Providerlauf; - reale Gateway-SSE-Replay-/Gap-Bedingungen; - die positive `/runs/:id`-Route gegen einen echten Run. ### Noch nicht live bewiesen - Remote-/Container-Pairing mit realer Request ID und wiederverwendetem Device-Token; - Version-Pin und kontrollierter Fehlermodus gegen den installierten Gateway; - vollständiger `Nexus -> OpenClaw -> OpenAI -> Nexus`-Lauf; - Start, Live-Events, Approval/Tool, Ergebnis, Stop/Retry und Reconnect im selben realen Szenario; - Anwendung und Rücklesetest der neuen EF-Migration in Ziel-PostgreSQL; - Multi-Replica-Idempotency und längerer Event-Soak. ## Priorisierte Schritte bis zu einem belastbaren täglichen Ersatz ### P0 — Produktionswahrheit 1. Reales Device Pairing und Gateway-Reconnect in der Zieltopologie beweisen. 2. Einen OpenAI-over-OpenClaw-Run mit Provider-/Modellnachweis, negativem Authfall, Audit und Event-Replay vollständig aufzeichnen. 3. Ziel-PostgreSQL migrieren und Run-Ledger/History nach Neustart rücklesen. ### P1 — Eine vollständige Agentenmission 1. Run um Tooltrace, Approval-Timeline, Artefakte, Usage und Ergebnis erweitern. 2. Task/Projekt zeigen ihre korrelierten Runs und übernehmen autoritative Ergebnisse. 3. Branch/Handoff und eine belegte Resume-Strategie ergänzen. 4. Iris-Befehle als strukturierte, bestätigbare Pläne mit Policy-Vorschau ausführen. ### P1 — OpenClaw nicht mehr öffnen müssen 1. Agent-Lifecycle und effektive Tool-/Approval-Policies. 2. OpenAI-Auth-Profile, Modellrouting, Fallbacks, Budgets und Limits. 3. Vollständiges Cron CRUD und Run-Historie. 4. Nodes, Channels, Connectoren, Pairing und kontrollierte Config-Reload-/Rollback-Flächen. 5. Incident- und Notification-Lifecycle mit operativen Aktionen. ### P2 — Skalierung und Qualität 1. Die doppelten Live-Sync-Module und parallelen Streams in einen Live-Orchestrator konsolidieren. 2. Eventpayloads normalisiert patchen und Aggregate nur bei Gap oder echter Invalidierung nachladen. 3. Den lokalen JSONL-Ledger vor horizontaler Skalierung durch einen geteilten transaktionalen Idempotency-Store ersetzen. 4. Agenten-Evals für Toolauswahl, Argumentgenauigkeit, Policy-Verhalten und fachliches Ergebnis als Release-Gate einführen. ## Schlussfolgerung Nexus ist jetzt sinnvoll auf OpenClaw ausgerichtet und deutlich agent-first: Die Vertrauensgrenze stimmt, Live-Kommunikation ist SSE-first, Ausführungen werden durable, und der globale Einstieg ist objektbezogen. Die Behauptung „Nexus ersetzt OpenClaw im Alltag“ wäre trotzdem noch verfrüht. Die nächste Qualitätsstufe entsteht nicht durch weitere read-only Seiten, sondern durch einen real belegten, vollständigen Missionsloop und durch das Schließen der verbleibenden Control-Flächen. Bis dahin sollte OpenClaw als Break-glass-/Recovery-Oberfläche verfügbar bleiben.