# Nexus: Seiten- und Agent-First-Evaluation

**Datum:** 2026-07-27
**Commit-Basis:** `3bc7622` plus uncommittete Design-Migration im Working Tree
**Routen:** 18 registrierte Routen
**Ziel:** Nexus als alleinige tägliche Mission-Control-Oberfläche und
agent-first Control Plane über OpenClaw, mit OpenAI als primärem Provider
innerhalb von OpenClaw

## Kurzurteil

Nexus ist inzwischen ein visuell eigenständiges und deutlich kohärenteres
Operations-Cockpit. Das Task-System, Agentenprofil und die Gateway-Anbindung
bilden eine belastbare Basis. Für das konkretisierte Produktziel ist es aber
noch kein vollständiger Ersatz für die tägliche OpenClaw-Oberfläche und noch
keine durchgehend agent-first Control Plane.

**Zielreife: 40 / 100**
**Entscheidung:** **No-Go für OpenClaw-UI-Unabhängigkeit**, aber **brauchbare
interne Alpha als Dashboard und Task-Orchestrierung**.

Die frühere Bewertung von 54/100 maß die Release-Reife des damaligen
Funktionsumfangs. Die aktuelle 40/100 misst den größeren, nun verbindlichen
Zielumfang: tägliche OpenClaw-Bedienparität in Nexus, OpenAI als Primärprovider
in OpenClaw und dauerhafte agentische Steuerung.

**Architekturkorrektur:** Die ursprüngliche Fassung dieser Evaluation nahm
einen direkten OpenAI-Pfad in Nexus und einen optionalen OpenClaw-Adapter an.
Verbindlich ist stattdessen `Nexus -> OpenClaw -> OpenAI`. Die Zielreife bleibt
bei 40/100, weil die unveränderten Security-, Session-, Control-, Eval- und
Bedienlücken den produktiven End-to-End-Betrieb weiterhin blockieren.

## Bewertungsmodell

| Bereich | Gewicht | Reife | Gewichteter Beitrag |
|---|---:|---:|---:|
| OpenClaw-UI-Unabhängigkeit / Steuerungsparität | 25 % | 28 | 7,0 |
| Agent-first Workflows | 20 % | 35 | 7,0 |
| OpenAI-over-OpenClaw Providersteuerung | 15 % | 20 | 3,0 |
| Seiten-UX, Design und Accessibility | 15 % | 74 | 11,1 |
| Domäne und Backend-Architektur | 10 % | 70 | 7,0 |
| Security und Governance | 10 % | 25 | 2,5 |
| Tests, Tracing, Evals und Observability | 5 % | 40 | 2,0 |
| **Gesamt** | **100 %** |  | **39,6 -> 40** |

## Evidenz und Grenzen

- Der aktuelle Kernfluss Dashboard -> Agents -> Agent Detail -> Projects wurde
  in diesem Lauf bei `1440 x 1000` im Browser erfasst und visuell geprüft.
- Nach einem vollständigen Routen-Reload war die Preview-Authentifizierung
  nicht mehr verfügbar. Deshalb wurden die übrigen 14 Routen anhand ihrer
  aktuellen Vue-Komponenten, Stores, Routerziele, API-Aufrufe und
  Backend-Verträge geprüft.
- Es wurde kein produktiver OpenClaw-, PostgreSQL-, Proxy- oder
  Provider-End-to-End-Lauf ausgeführt.
- Dies ist keine vollständige WCAG-, Penetrations- oder Lastprüfung.
- Bestehende Codeänderungen wurden in diesem Evaluationsschritt nicht
  funktional verändert.

## Frischer visueller Kernfluss

### 1. Dashboard - visuell stark, funktional teilweise

![Dashboard](screenshots/01-dashboard.jpg)

Die Live-Orchestrierung besitzt klare Hierarchie und genügend Arbeitsfläche.
Status- und Task-Leisten sind sinnvoll verdichtet. Kritisch bleiben die
nicht-funktionale Suchaffordance, der lokale statt persistente
„Agent hinzufügen“-Vorgang und fehlende Run-/Trace-Aktionen.

### 2. Agents - gute Übersicht, unvollständige Steuerung

![Agents](screenshots/02-agents.jpg)

Rollen, Status und Gateway-Zustand sind schnell erfassbar. Es fehlen
Lebenszyklusaktionen wie Erstellen, Importieren, Aktivieren, Deaktivieren,
Neustarten und Capability-/Policy-Übersichten.

### 3. Agent Detail - gute Diagnosebasis, kein vollständiges Agent Cockpit

![Agent Detail](screenshots/03-agent-detail.jpg)

Profil, aktuelle Aktivität und Config-Dateien bilden eine brauchbare Basis.
Sessions, Runs, Tools, Freigaben, Budgets, Evals und Lifecycle-Steuerung fehlen.
„Zurück zum Team“ navigiert weiterhin auf das nicht registrierte `/team` und
wird durch den Wildcard-Redirect maskiert.

### 4. Projects - Kernaktion vorhanden, Zustand nicht erklärt

![Projects](screenshots/04-projects.jpg)

Ein Projekt kann angelegt werden. Wenn der Operations-Snapshot nicht geladen
ist, bleibt danach eine große leere Fläche ohne klaren Empty-, Error- oder
Reconnect-Zustand. Agenten, Runs, Ziele, Artefakte und Budgets sind nicht Teil
der Portfolioansicht.

## Evaluation aller 18 Seiten

Skala: 1 = Platzhalter/Blocker, 3 = brauchbare Teilfunktion, 5 = Zielzustand.

| Route | Reife | Was heute funktioniert | Was verbessert werden muss / fehlt | Priorität |
|---|---:|---|---|---|
| `/login` | 3,5/5 | Owner-Login, Passwortsichtbarkeit, Rate-Limit-Feedback | Recovery, 2FA/Passkeys, Session-/Geräteverwaltung, sauberer Return-to-Route-Flow | P1 |
| `/dashboard` | 3/5 | Live-Topologie, Status, Fokus-Tasks, Iris-Modal, Modellwechsel | Echte Command Bar; „Agent hinzufügen“ persistieren; Run-IDs, Trace, Kosten, Tool-Aufrufe, Pause/Resume/Cancel; klare Offline-/Error-Zustände | P0 |
| `/memory` | 2/5 | Liste, Suche, Lesen | Erstellen, Bearbeiten, Löschen, Quellen/Freshness, Versionen, Scope, Retrieval-Tests, Retention und Memory Policies | P1 |
| `/docs` | 2/5 | Liste, Kategorien, Suche, Lesen | Upload, Authoring, Sync/Import, Versionen, Zitierbarkeit, Ingestion-Status, Freigaben und Knowledge-Tests | P1 |
| `/agents/:id` | 2,5/5 | Profil, Live-Zusammenfassung, Aktivität, erlaubte Config-Dateien speichern | Defekten `/team`-Backlink korrigieren; Runs/Sessions, Lifecycle, Tools/Rechte, Budgets, Secrets-Referenzen, Evals und Restart | P0 |
| `/security` | 1,5/5 | Read-only Statusübersicht | Tatsächliche Policy-/Auth-Lage statt nur Konfigurationswerte; Remediation, Sessions, Schlüsselrotation, Audit, 2FA/Passkeys und Security Alerts | P0 |
| `/incidents` | 2/5 | Incident-Liste und Detail lesen | Erstellen, Acknowledge, Zuweisen, Severity/Timeline, Remediation-Aktionen, Verknüpfung mit Run/Task, Resolve und Postmortem | P1 |
| `/calendar` | 2/5 | Cron-/Upcoming-Liste und Refresh | Erstellen, Bearbeiten, Pause/Resume, Run now, Retry, Löschen, Zeitzone, Owner, Run-Historie und Fehlerdetails | P0 |
| `/projects` | 2/5 | Projekt anlegen, Karten aus Operations-Snapshot öffnen | Explizite Loading/Empty/Error-Zustände; Ziele, Agententeam, Runs, Tasks, Artefakte, Kosten, Health und Automationen | P1 |
| `/projects/:id` | 2,5/5 | Projekt bearbeiten/archivieren, zugehörige Tasks lesen | Task/Run direkt anlegen und delegieren; Ziel/KPI, Team, Artefakte, Timeline, Budget und Automationen | P1 |
| `/tasks` | 4/5 | Erstellen, Board, Statuswechsel, Iris-Waiting, Detailpanel, Subtasks, Editieren | Board-Level-Fehler sichtbar machen; Run-/Trace-Bezug, Abhängigkeiten, Bulk-Aktionen, einheitliche Approval Queue, Cancel/Retry/Resume | P1 |
| `/tasks/:id` | 4/5 | Vollständiges Editieren, Status/Priorität, Assignee, Due Date, Subtasks, Aktivität/Kommentare | Agent Run, Tool-Aufrufe, Outputs/Artefakte, Approval-Historie, Retry/Resume/Cancel und Abhängigkeitsgraph | P1 |
| `/agents` | 3/5 | Agenteninventar, Gateway-Status, Profileinstieg | Create/Import/Disable/Delete/Restart, Filter, Capability- und Permission-Summary, Run-Last und Kosten | P1 |
| `/models` | 1,5/5 | Read-only Routing-Liste | OpenAI-Primärpolicy über OpenClaw, Modellkatalog, sichere Auth-Profil-/Secret-Referenzen, Defaults, Fallbacks, Limits, Preis/Qualität/Latenz und Tests | P0 |
| `/activity` | 2/5 | Snapshot-Timeline, Typfilter, Sortierung, Pagination | Autoritativer Event-Stream, Suche, Run-/Correlation-ID, Actor, Diff, Export, Retention und sichere Payload-Ansicht | P1 |
| `/chat` | 1,5/5 | Einzelne Iris-Nachrichten an `/api/v1/chat`, lokale Conversation-ID | Persistente Threadliste, Streaming, Anhänge, Tool-/Approval-Karten, Run-Erstellung, Stop/Retry/Resume, Kontextkontrolle; „Preview“ ablösen | P0 |
| `/notifications` | 2,5/5 | Liste, Read/Read-all, Tastaturbedienung | Loading/Error darstellen; Task-Detail statt nur Board; Acknowledge/Snooze, Preferences, Kanäle, Routingregeln und Approval-Aktionen | P1 |
| `/settings` | 2,5/5 | Profil, Passwort, Benutzerverwaltung | Gateway-/Provider-Setup, OpenAI-Status und sichere OpenClaw-Secret-Referenzen, Modellpolitik, Tool-Rechte, Approval Policies, Budgets, Connectoren, Retention, Rollen und Audit | P0 |

## Produktweite Kernbefunde

### 1. Sichtbare Kernaktionen sind teilweise inert oder nur lokal

- Die Suchleisten in beiden Shells sind keine Inputs und öffnen keine Command
  Palette.
- „Ask Iris“ in der Legacy-Topbar besitzt keinen Click-Handler.
- „Agent hinzufügen“ auf dem Dashboard fügt einen Agenten nur in den lokalen
  Pinia-Zustand ein; es entsteht kein Agent im Backend oder Runtime-System.
- Mehrere Stores schlucken Fehler und zeigen dann leere oder scheinbar
  erfolgreiche Flächen.

Für eine agent-first Oberfläche sind dies Hard Blocker, weil genau diese
Affordanzen den primären Arbeitsweg versprechen.

### 2. Der OpenClaw-Pfad ist korrekt, die OpenAI-Primärpolicy aber unvollständig

`IAgentRuntime` bietet nur Status und Chat. Der einzige registrierte Adapter ist
`OpenClawRuntime`; das entspricht der verbindlichen Zielarchitektur.
`ModelRoutingService` führt jedoch zwei DeepSeek-Ziele und ein OpenAI-Ziel auf.
Damit ist OpenAI noch nicht als primärer Provider für die relevanten
Agentenrollen belegt. Es fehlen eine sichere OpenClaw-Auth-Profilverwaltung,
rollenbezogene OpenAI-Policies, Live-Providerbeleg, dauerhafte
Session-/Subagent-Korrelation, Streaming, Tool-Lifecycle, Freigaben und Tracing.

### 3. Die Task-Domäne ist der stärkste agentische Kern

Task Board, Task Detail, Child Tasks, Handoffs, Aktivität, Approval-Aktionen und
die zehn Nexus-MCP-Tools bilden den besten vorhandenen Baustein. Das MCP ist
aber noch auf die Task-Domäne begrenzt und deckt weder Runs/Sessions noch Tools,
Provider, Zeitpläne, Wissen oder Artefakte ab.

### 4. Live-Orchestrierung ist noch keine autoritative Run-Ansicht

Agentenstatus und Aktivität werden gepollt; Teile der „Thinking“-Darstellung
werden präsentativ aus Texten abgeleitet. Token- und Kostenwerte sind in der
Agent-Mapping-Schicht derzeit Defaultwerte. Für operative Entscheidungen
braucht die Ansicht dauerhafte Run-, Event-, Usage- und Trace-Daten.

### 5. Security blockiert eine produktive Control Plane

- `AddAuthorization()` besitzt keine authenticated-by-default Fallback Policy.
  Mehrere `/api/v1`-Controller sind nicht mit `[Authorize]` geschützt.
- Bridge und MCP akzeptieren einen bekannten, vom Aufrufer gesetzten
  `X-Agent-Id` als Identität, bevor ein starker Service-Nachweis verlangt wird.
- Die Task-Board-/Stale-Endpunkte sind `[AllowAnonymous]` und autorisieren
  teilweise über denselben Header.
- `docs/gateway-api-research.md` enthält credential-artige Literalwerte. Diese
  müssen als kompromittiert behandelt, rotiert, aus dem Working Tree und
  gegebenenfalls aus der Git-Historie entfernt werden.

Die Security-Seite zeigt Konfigurationswerte, macht diese strukturellen
Release-Blocker aber nicht sichtbar.

## Unabhängigkeit von der OpenClaw-Oberfläche: Capability-Parität

| Capability | Aktueller Stand | Lücke |
|---|---|---|
| Gateway Health/Version | Vorhanden | Konfiguration, Reload, Update und Recovery fehlen |
| Agenteninventar/Config | Teilweise | Vollständiger Lifecycle und Policies fehlen |
| Chat | Teilweise | Persistente Sessions, Streaming, Tools und Run-Steuerung fehlen |
| Tasks/Delegation | Stark | Run-/Trace-/Artifact-Bezug und einheitliche Approvals fehlen |
| Sessions/Runs | Fehlt | Listen, starten, resume, branch, cancel, retry, terminate |
| Subagenten/Handoffs | Task-Handoff teilweise | Run-Hierarchie, Spawn/Stop und Ownership fehlen |
| Tool-Katalog/Rechte | Fehlt | Schema, Namespace, Allowlist, Approval Policy, Audit |
| Cron/Schedules | Read-only UI | Vollständiger CRUD- und Ausführungs-Lifecycle fehlt |
| Modelle/Provider | Read-only/hardcodiert | OpenAI-Primärpolicy in OpenClaw, sichere Auth-Profile, Routing, Fallbacks und Live-Beleg fehlen |
| Memory/Docs | Read-only | Ingestion, Schreiben, Kuratierung, Versionen und Tests fehlen |
| Dateien/Artefakte | Config-Markdown teilweise | Allgemeiner Upload/Download, Versionierung, Run-Zuordnung fehlt |
| Channels/Connectors | Fehlt | Einrichtung, Status, Rechte und Datenfreigaben fehlen |
| Nodes/Hosts | Fehlt | Inventar, Health und kontrollierte Runtime-Aktionen fehlen |
| Approvals | Task-Approval teilweise | Zentrale Tool-/Run-/Datenfreigaben fehlen |
| Traces/Evals/Usage | Fehlt/teilweise abgeleitet | Autoritative Runs, Tool-Traces, Kosten, Latenz und Eval-Suites fehlen |
| Secrets | Fehlt | Sichere Verwaltung, Rotation und Referenzen fehlen |
| Incidents/Notifications | Read-mostly | Operative Bearbeitung, Eskalation und Remediation fehlen |

## Empfohlene Zielarchitektur

Der vorhandene C#-Stack und OpenClaw-Pfad werden gezielt ausgebaut:

1. **Nexus bleibt Product Control Plane:** ASP.NET Core besitzt Nutzer, RBAC,
   Projekte, Tasks, menschliche Freigaben und das Control-Plane-Audit.
2. **OpenClaw bleibt verpflichtende Runtime:** Agenten, Sessions, Subagenten,
   Tools, Cron, Channels, Nodes und Modellrouting bleiben dort autoritativ.
3. **OpenAI wird Primärprovider in OpenClaw:** Credentials liegen ausschließlich
   in OpenClaw; Nexus zeigt und ändert nur sichere Referenzen und Policies.
4. **Typisierte Gateway-Fassade:** Der generische Gatewayclient wird in sichere
   Read-/Control-Verträge mit Scopes, Schema, Idempotenz, Versionsprüfung,
   Approval und Audit aufgeteilt.
5. **Keine doppelte Runtime:** Nexus korreliert OpenClaw-Sessions mit Tasks,
   Projekten, Approvals und Artifacts, baut aber keinen zweiten Session Store.

Siehe den kanonischen Zielvertrag:
[`docs/AGENT_FIRST_MISSION_CONTROL.md`](../../../AGENT_FIRST_MISSION_CONTROL.md)
und die vollständige
[`docs/MISSION_CONTROL_ROADMAP.md`](../../../MISSION_CONTROL_ROADMAP.md).

Relevante Primärquellen:

- [OpenClaw Gateway und Runtimekonzept](https://docs.openclaw.ai/)
- [OpenClaw Provider und Modellreferenzen](https://docs.openclaw.ai/providers)
- [OpenClaw Operator-Scopes](https://docs.openclaw.ai/gateway/operator-scopes)
- [OpenAI API-Key-Sicherheit](https://developers.openai.com/api/docs/guides/production-best-practices#api-keys)
- [Evaluation best practices](https://developers.openai.com/api/docs/guides/evaluation-best-practices#single-agent-architectures)

## Priorisierte Roadmap

### P0 - Control-Plane-Grundlage und Vertrauen

1. Authenticated-by-default erzwingen, Agent-/Service-Identität stark
   authentifizieren, negative Proxy-End-to-End-Tests ergänzen und
   credential-artige Werte rotieren/entfernen.
2. Durable-Run-Domäne mit Session, Parent/Child, Events, Tools, Approvals,
   Artefakten, Usage und Audit einführen.
3. OpenAI in OpenClaw als Primärprovider konfigurieren, sichere
   Auth-Profil-/Secret-Referenzen verwenden und den realen
   Nexus-OpenClaw-OpenAI-Pfad Ende-zu-Ende belegen.
4. Globale Command Bar und „Ask Iris“ auf jeder Seite funktional machen;
   sichtbare lokale/platzhalterhafte Aktionen entweder persistieren oder klar
   als Simulation kennzeichnen.
5. Agent-, Session-, Tool-/Permission-, Model-/Provider-, Secret- und
   Schedule-Lifecycle als erste OpenClaw-Paritätsstufe liefern.
6. Defekten `/team`-Backlink, fehlende Route-/Session-Hydration und
   verschluckte Kernfehler schließen.

### P1 - Agentischer Betriebsalltag

1. Run Explorer mit Streaming, Trace, Tool-Aufrufen, Approval-Karten,
   Cancel/Retry/Resume und Artefakten.
2. Kontextuelle Delegation und Automatisierung auf Project, Task, Incident,
   Doc und Calendar.
3. Memory-/Docs-Ingestion, Versionierung, Herkunft/Freshness und
   Retrieval-Evals.
4. Zentrale Approval Inbox, operative Notifications und Incident-Remediation.
5. Modellrouting mit OpenAI-Defaults, Fallbacks, Budgets, Limits,
   Kosten-/Latenz-/Qualitätsvergleich.
6. Autoritativer Event-Stream mit Korrelation, Retention, Suche und Export.

### P2 - Plattformreife

1. Channels, Connectors, Nodes/Hosts und kontrollierte Gateway-Administration.
2. Eval-Dashboard, Regression-Datasets, Prompt-/Policy-Versionen und
   Qualitätsgates.
3. Run-/Agent-Templates, wiederverwendbare Automationen und Projekt-Playbooks.
4. Granulare Rollen, Mandanten-/Teamgrenzen, Aufbewahrung und Compliance.

## Abnahme für „kein OpenClaw-Wechsel mehr“

- Ein kompletter Workflow von Absicht -> Plan -> Agent/Subagent -> Tool
  Approval -> Artefakt -> Review -> Abschluss ist ausschließlich in Nexus
  bedienbar.
- Runs und Sessions können nach Reload oder Neustart fortgesetzt werden.
- Jede riskante Aktion besitzt Policy, Freigabe und Audit-Eintrag.
- Jede Modellinferenz aus Nexus läuft über OpenClaw; OpenAI ist dort als
  Primärprovider nachgewiesen und Nexus besitzt keinen direkten OpenAI-Pfad.
- Alle 18 Routen besitzen Route-, Loading-, Empty-, Error-, Keyboard- und
  Responsive-Smoke-Tests.
- Reale Provider-/Gateway-/PostgreSQL-/Proxy-End-to-End-Tests sind grün.
- Tool-Auswahl, Argumente, Ergebnisqualität, Kosten und Latenz werden durch
  reproduzierbare Evals geprüft.

## Schlussfolgerung

Nexus sollte nicht neu begonnen werden. Die vorhandene Task-Domäne,
Backend-Schichtung, Gateway-Abstraktion und neue Designsprache sind wertvoll.
Der nächste Meilenstein darf jedoch keine weitere reine Seitenrunde sein:
Zuerst müssen Security, eine typisierte OpenClaw Control Plane, der belegte
OpenAI-Primärbetrieb in OpenClaw und die universelle Iris-/Session-Steuerung den
tatsächlichen Control-Plane-Kern bilden.
