feat: ship agent-first mission control v0.2.57

2026-07-31 22:39:47 +02:00
parent 3bc7622977
commit f5552218bc
535 changed files with 95242 additions and 8791 deletions
@@ -0,0 +1,86 @@
+# Dashboard orchestration focus
+
+## Outcome
+
+The dashboard is now an orchestration stage: compact operational status frames
+the top, compact focus tasks frame the bottom, and Iris enters only when the
+owner invokes the topbar action.
+
+This is a `distill` correction for an operational product surface. It preserves
+the established Galaxy/Glass direction and all existing dashboard stores,
+requests, events, task data, chat messages, agent actions, and route behavior.
+
+## Implementation
+
+- Removed the permanently visible `360px` Iris rail from the dashboard
+  workspace.
+- Made the existing topbar action an explicit `Iris Chat` trigger with
+  `aria-haspopup="dialog"`, `aria-expanded`, and `aria-controls`.
+- Rendered the existing `IrisChat.vue` data and send handler inside a native
+  modal dialog. The dialog is absent by default, focuses the message field,
+  closes through its named button or Escape, and returns focus to the trigger.
+- Reduced the operations status surface to one `46px` row. Narrow layouts keep
+  active/planning/blocker signals and remove lower-priority idle/cost detail.
+- Reduced the task surface to one `44px` focus row with priority, state, title,
+  and owner retained through visible or accessible text.
+- Increased the first multi-row auto-layout offset to avoid node overlap and
+  introduced compact agent cards at `680px` and below.
+- Replaced the affected blank inline icon slots with the installed Lucide
+  components.
+
+No backend, API, store, service, DTO, route, permission, chat-send, task, or
+agent-selection contract changed.
+
+## Measured geometry
+
+At `1440 x 1000`:
+
+| Surface | Before | After | Change |
+| --- | ---: | ---: | ---: |
+| Live orchestration | `774 x 731px` | `1152 x 808px` | `+48.8%` width, `+10.6%` height |
+| Iris rail | `360 x 902px` | absent until invoked | full workspace width recovered |
+| Operations status | `57px` high | `46px` high | `-19%` |
+| Focus tasks | `87px` high | `44px` high | `-49%` |
+
+## Operated proof
+
+- Default state: Iris dialog absent and `aria-expanded="false"`.
+- Pointer path: Iris Chat open -> named close button -> dialog removed -> focus
+  returned to Iris Chat.
+- Keyboard path: Iris Chat open -> input focused -> Escape -> dialog removed ->
+  focus returned to Iris Chat.
+- Input path: message text enables the named send action; the existing send
+  handler remains unchanged.
+- Native dialog top layer and backdrop passed at desktop and `375px`.
+- No page overflow, clipped nodes, or node intersections at `375`, `680`,
+  `681`, `768`, `1024`, `1440`, or `1920px`.
+
+The after-state used a temporary controlled browser fixture so the layout could
+be exercised without credentials or external API dependency. The fixture and
+temporary QA entry were removed after capture. Evidence maturity is controlled
+local browser proof, not deployment evidence.
+
+## Evidence
+
+- `screenshots/dashboard-orchestration-before-1440.png`
+- `screenshots/dashboard-orchestration-before-693.png`
+- `screenshots/dashboard-orchestration-after-1440.png`
+- `screenshots/dashboard-orchestration-after-375.png`
+- `screenshots/dashboard-iris-modal-after-1440.png`
+- `screenshots/dashboard-iris-modal-after-375.png`
+
+## Technical gates
+
+```text
+vue-tsc --noEmit -> passed
+vitest run        -> passed (1 file, 2 tests)
+vite build        -> passed (1,873 modules)
+git diff --check  -> passed; line-ending notices only
+```
+
+The Codex `pnpm` wrapper attempted a package-manager bootstrap before executing
+the repository scripts. Restricted registry access and its non-interactive
+dependency-purge prompt blocked that wrapper path; the already-installed local
+script binaries above completed successfully.
+
+No commit, push, or deployment was performed.
@@ -0,0 +1,60 @@
+# Dashboard sidebar unification
+
+## Outcome
+
+The dashboard now renders the same `AppSidebar.vue` component as every other
+authenticated route. This removes the final visible navigation fork without
+changing dashboard content, domain state, stores, API contracts, or route
+registration.
+
+## Implementation
+
+- Replaced the dashboard-only `Sidebar.vue` render in `NexusLayout.vue` with
+  `AppSidebar.vue`.
+- Preserved the dashboard task count through the existing task store.
+- Bound the active destination to the current Vue Router route.
+- Kept the existing mobile close event and backdrop behavior.
+- Aligned the dashboard topbar and backdrop breakpoint with the shared
+  sidebar's `900px` overlay breakpoint.
+
+## Rendered proof
+
+| Evidence | Viewport | Result |
+| --- | --- | --- |
+| Dashboard before | `1440 x 900` | Separate sidebar confirmed |
+| Settings reference | `1440 x 900` | Shared component authority |
+| Dashboard after | `1440 x 900` | Matches shared sidebar |
+| Dashboard mobile | `375 x 812` | Overlay, categories, Settings, and footer visible |
+| Same-viewport comparison | `1440 x 900` | Identical sidebar geometry and styling |
+
+Evidence files are stored under `screenshots/`.
+
+## Interaction and geometry
+
+- Dashboard -> Agents -> Dashboard passed.
+- Dashboard -> Settings passed at `375px`.
+- Active states use `aria-current="page"`.
+- The overlay closes after navigation.
+- No document-level horizontal overflow at `375`, `768`, `1024`, `1440`, or
+  `1920px`.
+- At `768px`, the sidebar is hidden off-canvas and the named topbar toggle is
+  visible.
+- Browser console: no errors. Existing fixture/API fallback warnings remain.
+
+## Technical gates
+
+```text
+pnpm typecheck  -> passed
+pnpm test       -> passed (1 file, 2 tests)
+pnpm build      -> passed (1,873 modules)
+git diff --check -> passed; line-ending notices only
+```
+
+## Severity result
+
+- P0: none
+- P1: none
+- P2: none
+
+Evidence maturity: controlled local browser proof. No commit, push, or
+deployment was performed.
@@ -0,0 +1,290 @@
+# 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.