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