# 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.
