docs: record v0.2.60 production acceptance [skip ci]

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

@@ -2,8 +2,8 @@
 
 **Stand:** 2026-07-31
 
-**Status:** Release Candidate; lokale Verträge grün, Linux-/Docker-CI und
-Produktionsdeployment noch auszuführen
+**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
@@ -11,16 +11,17 @@ Prüfbereichs.
 
 ## Ergebnis
 
-Der erste Stabilitäts- und Fehlerabbau-Slice ist implementiert. Nexus trennt
-jetzt Prozess-Liveness, Datenbank-Readiness und vollständige Runtime-Diagnose,
+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 Produktions- oder OpenClaw-Abnahme. Der
-credentialed Owner-Audit, Task-Board-Lastnachweis und jeder produktive
+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
@@ -124,7 +125,7 @@ Primäransicht nicht länger wegen einer fehlerhaften Sekundärabfrage.
 | 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 | 384 bestanden; fünf Containerfälle mangels lokalem Docker explizit übersprungen |
+| 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 |
@@ -135,30 +136,50 @@ 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
 
-Der erste verpflichtende Containerlauf (Gitea Run 363) erfüllte seinen Zweck
-und blockierte das Deployment: Alle fünf Fälle fanden einen fehlerhaft
-geordneten EF-Core-Modellsnapshot für
-`AgentProposal.ProvisionRequests`. Die Snapshotbeziehung ist korrigiert und ein
-nicht-Docker-Regressionstest baut beide Navigationen jetzt bereits im normalen
-Backendjob auf. Ein neuer grüner Containerlauf bleibt vor Deployment zwingend.
-
-### Vor Deployment
-
-1. Der neue Gitea-Linuxjob muss alle fünf vorhandenen PostgreSQL-/Toxiproxy-
-   Containerfälle bestehen, null überspringen und Docker als erreichbar melden.
-2. Der Gitleaks-Vollhistorienjob, OpenAPI-Diff, Dependency-Gates und die übrigen
-   Backend-/Frontendjobs müssen grün sein.
-3. Das versionierte Image muss mit SHA-Provenienz gebaut und durch dieselben
-   Readiness-/Diagnosegates deployt werden.
-
-### Nach Deployment, ohne Owner-Sitzung
-
-- `/health/live`, `/health/ready`, `/health`, `/login`, Security-Header und ein
-  unauthentifizierter geschützter API-Aufruf werden öffentlich geprüft.
-- Die Produktion muss `v0.2.60` und den ausgelieferten Git-SHA melden.
-
 ### Mit separater Owner-Sitzung
 
 - Alle 20 authentifizierten Produktionsviews werden read-only auf Navigation,
@@ -183,10 +204,11 @@ Backendjob auf. Ein neuer grüner Containerlauf bleibt vor Deployment zwingend.
 
 ## Nächste Reihenfolge
 
-1. Linux-/Docker-CI und Deployment-Smoke für v0.2.60 abschließen.
-2. Bao meldet sich im In-App-Browser als Owner an; danach 20 Seiten read-only
+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