# Nexus v0.2.60 — Stabilität und Recovery **Stand:** 2026-07-31 **Status:** In Produktion deployt; technische Releasegates grün, credentialed Owner-Abnahme, Lastnachweis und produktive OpenClaw-Writes separat offen **Scope:** Nexus-Repository und kontrollierte Browser-Fixtures. Keine produktive OpenClaw-Mutation; Maxis Ressourcen lagen vollständig außerhalb des Prüfbereichs. ## Ergebnis Der erste Stabilitäts- und Fehlerabbau-Slice ist implementiert und deployt. Nexus trennt jetzt Prozess-Liveness, Datenbank-Readiness und vollständige Runtime-Diagnose, liefert einen generierten gemeinsamen Fehlervertrag und zeigt auf allen 20 authentifizierten Views einheitliche Loading-, Empty-, Error-, Offline-, Stale- und Partial-Zustände. Releaseversion, Containerprovenienz, Dependency- und Secret-Scans sowie die echten PostgreSQL-/Toxiproxy-Verträge sind Teil der CI-Freigabe. Das ist noch keine vollständige authentifizierte Produktions- oder OpenClaw-Abnahme. Der Owner-Audit, Task-Board-Lastnachweis und jeder produktive OpenClaw-Schreibvorgang bleiben getrennte Gates. ## Implementierter Vertrag ### Health, Deployment und Version - `GET /health/live` ist ein reiner Prozesscheck. - `GET /health/ready` prüft ausschließlich Pflichtabhängigkeiten mit dem Tag `ready`; PostgreSQL-Ausfall liefert HTTP 503. - `GET /health` bleibt die vollständige Diagnose. Ein OpenClaw-Ausfall ergibt `Degraded`, ohne die Nexus-Recovery-Oberfläche durch Readiness zu sperren. - Der API-Container wird über `/health/ready` geprüft. Web wartet auf einen gesunden API-Container; API wartet auf gesundes PostgreSQL. - Deployment prüft zuerst die lokale Container-Readiness, danach öffentliche Readiness und den vollständigen Runtimezustand. Rollback verwendet dieselben Gates und akzeptiert HTTP 404 für `/health/ready` nur bei einem sichtbaren Notfall-Rollback auf Versionen vor v0.2.60. - `global.json` verlangt .NET `10.0.100` mit `latestFeature`-Roll-forward. `VERSION` ist die Releasequelle; Frontendpaket und OCI-Labels werden dagegen geprüft. Images tragen Version und exakten Git-SHA. ### Auth und Browsergrenze - Die ungenutzte `/api/v1/auth/csrf`-Route und Antiforgery-Registrierung sind entfernt. Kein Client sendete das Token und keine Mutation validierte es. - Das Refresh-Cookie bleibt `Secure`, `HttpOnly` und `SameSite=Strict`. - Refresh und Logout weisen explizite Cross-Site-Browseraufrufe anhand von `Origin` und `Sec-Fetch-Site` ab. API-Clients ohne Browser-Provenienzheader benötigen weiterhin das gültige Cookie und unterliegen den normalen Limits. - Login-, Refresh- und Rate-Limit-Fehler verwenden denselben strukturierten Problemvertrag. - Nach einem fehlgeschlagenen Refresh leitet das Frontend genau einmal zum Login um und erhält das Rückkehrziel. - Ein persistierter Refresh-Hash bleibt über eine neu erzeugte Serviceinstanz verwendbar und wird anschließend rotiert. Ein echter Containerneustart wird zusätzlich im produktionsnahen Releaseprofil geprüft. ### Gemeinsame Fehler- und Recovery-Schicht Backendfehler verwenden `application/problem+json` mit: - `code`, `status`, `title`, `detail`, `traceId`; - optional `operationId`, `currentRevision`, `retryAfterSeconds`, `remaining`; - den stabilen Codes `validation_failed`, `unauthenticated`, `forbidden`, `conflict`, `not_found`, `unsupported_capability`, `dependency_unavailable`, `timeout`, `rate_limited` und `internal_error`. Durable Agent-Proposal-, Run- und andere Operationsendpunkte behalten ihre typisierten Envelopes für Zustände wie `partial`, `failed` und `in_doubt`. Diese Zustände müssen dauerhaft untersuchbar bleiben und werden nicht als flüchtige HTTP-Ausnahme versteckt. Der Frontendadapter normalisiert während der Kompatibilitätsphase zusätzlich ältere `message`-/`error`-Payloads. Ein OpenAPI-Schema-Transformer beschreibt diese Erweiterungen im eingecheckten 3.1-Vertrag. Der generierte TypeScript-Client speist `AppProblem` und `toAppProblem`; Views raten die Transportstruktur nicht selbst. `AsyncStatePanel` stellt Loading, Empty, Error, Offline, Stale und Partial semantisch dar, zeigt nur technische Trace-/Operation-Metadaten und bietet die passende Recovery-Aktion. Sichere GETs dürfen begrenzt wiederholt werden; Mutationen werden nie automatisch wiederholt. Sichtbare Daten bleiben bei Background-Refresh oder einem Fehler einer sekundären Detailabfrage erhalten. Migriert wurden: - Dashboard und Task Strip; - Agents, Agent Detail, Agent Create und Proposal Detail; - Projects, Project Detail, Task Board und Task Detail; - Run Control und Run Detail; - Calendar, Memory, Docs und Incidents; - Models, Activity, Notifications, Security und Settings. Memory, Docs und Incidents verlieren ihre bereits sichtbare Liste nicht mehr, wenn nur eine Detail- oder Suchabfrage fehlschlägt. Agent Detail blockiert die Primäransicht nicht länger wegen einer fehlerhaften Sekundärabfrage. ### CI und Supply Chain - Ein separater verpflichtender Linux-Job führt alle als `DockerIntegration` oder `ToxiproxyIntegration` markierten Tests mit beiden Opt-ins aus. Fehlendes Docker ist ein Jobfehler, kein Skip. - Frontend und Backend blockieren High/Critical-Produktionsabhängigkeiten. - Gitleaks `8.30.1` wird als Upstream-Artefakt geladen, über einen gepinnten SHA-256 geprüft und gegen die vollständige Git-Historie ausgeführt. - Drei überprüfte historische Fingerprints sind exakt baselined; die aktuelle Arbeitskopie ist redigiert. Eine eventuelle Credential-Rotation oder History-Rewrite bleibt ein gesonderter, ausdrücklich freizugebender Sicherheitsvorgang. - Das Fixture-Playwright-Profil deaktiviert Browsertelemetrie. Das Produktionsimage aktiviert nur den allow-listeten bestehenden Browsermetrikpfad über `VITE_BROWSER_TELEMETRY_ENABLED=true`. ## Lokale Abnahme | Gate | Ergebnis | |---|---| | Frontend Typecheck | grün | | Frontend Unit Tests | 13 Dateien, 42 Tests bestanden | | Frontend Production Build | grün | | Playwright | 26/26 bestanden | | Geschützte Routen | alle 20 in kontrollierten Fixtures geprüft | | Viewports | 375, 768, 1024, 1440 und 1920 px ohne Seitenoverflow | | Browserverträge | Deep Links, Query-Deduplizierung, ein SSE-Resync, Task-Board-Refresh, Done-Pagination, Drag-and-drop und 503-Recovery grün | | Backend | 386 bestanden; fünf Containerfälle mangels lokalem Docker explizit übersprungen | | PostgreSQL-Ausfall | echter Npgsql-Healthcheck gegen einen nicht erreichbaren Endpoint liefert im Readiness-Vertrag 503 | | Version | `VERSION` und Frontendpaket beide `0.2.60`; .NET-Pin wird als 10.0.101 aus dem erlaubten Feature-Band aufgelöst | | Abhängigkeiten | keine bekannten pnpm-Produktionslücken; keine High/Critical-NuGet-Funde | | Compose/Workflows | Compose valide, Deploy-Shell syntaktisch valide, CI- und Rollback-YAML parsebar | | OpenAPI | neu generiert; entfernte CSRF-Route, neue Readiness-Route und Problemfelder enthalten | Playwright arbeitet mit kontrollierten API-Fixtures. Diese Ergebnisse beweisen die UI- und Transportverträge, nicht die echte Produktionsdatenqualität oder OpenClaw-/OpenAI-Ausführung. ## CI- und Produktionsevidenz Die verpflichtenden Gates haben vor der Freigabe mehrere reale Fehler gefunden: - Run 363 blockierte einen fehlerhaft geordneten EF-Core-Modellsnapshot für `AgentProposal.ProvisionRequests`. - Anschließende Läufe zeigten, dass drei historische Taskmigrationen ohne EF-Metadaten nicht entdeckt wurden. Alle 13 Migrationen sind jetzt registriert; der Snapshot weist keinen ausstehenden Modellunterschied auf. - Der Toxiproxy-Reconcile-Fall deckte zuerst einen leeren serialisierten `agents.create`-Payload und danach fehlendes Read-back-Inventar im Testadapter auf. Beide Grenzen besitzen Regressionstests. - Der OpenAPI-Build erzeugte anfangs einen flüchtigen Data-Protection-Key. Die Extraktion arbeitet jetzt ohne persistente Schlüssel; CI prüft den Key-Repository-Dateizähler vor und nach beiden .NET-Builds. Der finale Gitea Run 372 deployte Commit `f87b9ef298f8a13ed7e044f9850024aa50fbbed0` mit folgender Evidenz: | Gate | Produktionsergebnis | |---|---| | Backend, Job 818 | 386 Tests bestanden | | PostgreSQL/Toxiproxy, Job 819 | 5/5 bestanden, null übersprungen | | Frontend, Job 820 | 13 Dateien/42 Tests, Build und 26/26 Playwright bestanden | | Security, Job 821 | gepinntes Gitleaks 8.30.1 ohne Leak; Dependency-Gates grün | | Deployment, Job 822 | alle Container gesund; lokale und öffentliche Readiness sowie vollständige Diagnose grün | Der öffentliche Smoke-Test bestätigte anschließend: - `/health/live` und `/health/ready`: HTTP 200 `Healthy`; - `/health`: HTTP 200 mit PostgreSQL `Healthy` und OpenClaw-HTTP-Runtime `Online`; - `/login`: HTTP 200, CSP, HSTS, `DENY`, `no-referrer` und eingeschränkte Browserberechtigungen; - geschützte OpenClaw-API: HTTP 401 als `application/problem+json` mit `unauthenticated` und Trace-ID; - Cross-Site-Refresh und -Logout: HTTP 403 als strukturierter `forbidden`- Fehler. Im In-App-Browser blieb die Loginseite ohne Console-Fehler bedienbar. Es wurden keine Zugangsdaten eingegeben oder ausgelesen. ## Offene Abnahmegates ### Mit separater Owner-Sitzung - Alle 20 authentifizierten Produktionsviews werden read-only auf Navigation, Requests, Konsole, Refresh/Reload/Logout, echte Agent-/Cron-/Modell-/Security- Daten, SSE-Freshness, Tastatur und Overflow geprüft. - Kein OpenClaw-Schreibtest wird dabei ausgeführt. ### Noch nicht Teil dieses Release-Slices - Task Board mit 1.000 Tasks und 10.000 Activities: k6-p95, SQL-Statementzählung, `EXPLAIN (ANALYZE, BUFFERS)` und wiederholte Navigation-bis-Karten-sichtbar-Messung. - Produktive Protocol-v4-Verbindung und Management. OpenClaw `2026.7.1` registriert weiterhin keine offiziell unterstützte externe Nexus-/Generic- Operator-ID. Die neuen offiziellen Seiten zu [Gateway clients](https://docs.openclaw.ai/gateway/clients) und [external apps](https://docs.openclaw.ai/gateway/external-apps) ändern den geschlossenen Connect-Schema-/Client-ID-Vertrag noch nicht. - Ein echter `Nexus -> OpenClaw -> OpenAI -> Nexus`-Run, Wegwerf-Cron oder Testagent. Diese Mutationen benötigen nach erfülltem Identity-Gate eine separate Owner-Freigabe. ## Nächste Reihenfolge 1. Bao meldet sich im In-App-Browser als Owner an; danach 20 Seiten read-only auditieren und jeden Fund mit Route, API, Trace-ID und Regressionstest erfassen. 2. Den Refresh-Vertrag über einen kontrollierten API-Containerneustart mit echter Owner-Sitzung belegen. 3. Task-Board-Datensatz und Last-/SQL-/Browserbudgets isoliert beweisen; nur gemessene Engpässe optimieren. 4. OpenClaw-Client-ID auf dem ersten kompatiblen Stable-Tag erneut prüfen und erst dann read-only pairen. 5. Danach Run Explorer, Agent Lifecycle, Notifications/Incidents, Calendar, Knowledge und Security in der bestehenden Roadmap-Reihenfolge schließen.