nexus/docs/audits/2026-07-31/stability-v0.2.60/IMPLEMENTATION_AND_ACCEPTANCE.md

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