nexus/docs/audits/2026-07-30/openclaw-agent-first-hardening/ROUTE_AND_AGENT_FIRST_EVALUATION.md

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:

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.