feat: ship agent-first mission control v0.2.57

docs/PROJECT_EVALUATION_2026-07-26.md

@@ -0,0 +1,132 @@
+# Nexus – Projektevaluation
+
+**Datum:** 2026-07-26
+**Commit:** `3bc7622977f4a6c2f2e98ab4aa856a2e45c3cf49`
+**Gesamtwertung:** **54 / 100**
+**Release-Entscheidung:** **No-Go für öffentlich erreichbare Produktion**, bis
+die P0-Zugriffskontrollen und die kritischen Navigations-/Responsive-Defekte
+geschlossen und regressionsgetestet sind.
+
+## Bewertungsmodell
+
+Die Gesamtwertung kombiniert Code- und Architekturprüfung, Test-/Build-Evidenz,
+Security-Spot-Check, vollständiges Route-Audit und responsive Sichtprüfung.
+Die Bewertung misst Release-Reife, nicht nur Code-Menge oder Feature-Umfang.
+
+Validiert wurden 189 grüne Backend-Tests im offiziellen .NET-10-SDK-Container,
+2 grüne Frontend-Tests und ein erfolgreicher Frontend-Production-Build.
+
+| Bereich | Gewicht | Wertung | Begründung |
+|---|---:|---:|---|
+| Architektur und Modularität | 15 % | 74 | Starke Backend-Schichtung und Integrationsabstraktionen; Frontend-Migration ohne klare Grenze |
+| Backend und Domäne | 15 % | 78 | Reife Services, Repositories, Migrationen und Task-Bridge |
+| Frontend Engineering | 15 % | 50 | Typisiert und buildbar, aber zwei Shells, tote Routen, doppelte Stores und Hydration-Fehler |
+| Security | 20 % | 30 | Gute kryptografische Bausteine, aber zwei strukturelle P0-Zugriffskontrolllücken |
+| UX und Product Design | 15 % | 41 | Gute Produktidentität, aber starke Kontrast-, Kohärenz- und Responsive-Probleme |
+| Tests und QA | 10 % | 55 | Fokussierte Backend-Tests; Frontend-Suite für 18 Seiten deutlich zu klein |
+| Delivery und Operations | 5 % | 82 | Gute CI/CD-, Backup- und Rollback-Basis |
+| Dokumentation und Wartbarkeit | 5 % | 48 | Umfangreich, aber wichtige Auth-, Route- und Versionsangaben sind veraltet |
+
+Gewichtete, gerundete Gesamtwertung: **54 / 100**.
+
+## Lunara Design Evaluation
+
+**Briefqualität:** Nicht anwendbar – geprüft wurde eine bestehende
+Implementierung ohne neu gelieferten Design-Brief.
+**Qualitätsgate:** **41 / 100 – nicht bestanden**.
+**Evidenz:** [`audits/2026-07-26/PAGE_AUDIT.md`](audits/2026-07-26/PAGE_AUDIT.md)
+und die 29 zugehörigen Screenshots.
+
+| # | Kategorie | 0–5 | Begründung |
+|---:|---|---:|---|
+| 1 | Produktspezifität | 4 | Klare Mission-Control-Identität und agentenspezifische Inhalte |
+| 2 | Informationshierarchie | 2 | Dichte Boards, sehr kleine Texte und konkurrierende Panels |
+| 3 | Aufgaben- und Handlungsklarheit | 2 | Mehrere Platzhalteraktionen und unklare Leerzustände |
+| 4 | Claim-/Evidenzintegrität | 2 | Security-Darstellung und README überzeichnen den tatsächlichen Schutz |
+| 5 | Komposition und Spacing | 2 | Überlappungen im Dashboard, zu große Leerflächen in Detailseiten |
+| 6 | Typografie | 2 | Wiederholt zu klein und zu schwach gewichtet |
+| 7 | Kontrast und Lesbarkeit | 1 | Breites systemisches Problem in Texten und Controls |
+| 8 | Iconografie | 3 | Lucide-Basis ist passend; Emoji und unlabeled Icons brechen die Konsistenz |
+| 9 | Komponenten- und Shell-Kohärenz | 1 | V2-Dashboard und Legacy-App wirken wie zwei Produkte |
+| 10 | Interaktionszustände | 2 | Basiszustände vorhanden, sichtbare Aktionen teils inert |
+| 11 | Motion-Disziplin | 3 | Keine übermäßige Animation; Statusmotion grundsätzlich zurückhaltend |
+| 12 | Responsive-Verhalten | 1 | Dashboard 375–1024 px kritisch defekt; Task Board mobil unzureichend |
+| 13 | Input-Anpassung | 2 | Settings brauchbar; Chat/Board und Touch-Flows schwach |
+| 14 | Semantik, Keyboard, Accessibility | 1 | Clickbare Articles, unlabeled Buttons, kleine Targets und Kontrast |
+| 15 | Kognitive Last und Recovery | 2 | Hohe Informationsdichte, versteckte Redirects, schwache Recovery |
+| 16 | Sprache und Content-Konsistenz | 2 | Deutsch/Englisch-Mix und uneinheitliche Mikrotexte |
+| 17 | Loading, Empty und Error | 2 | Teilweise vorhanden, aber leere Module und fehlende nächste Aktionen |
+| 18 | Laufzeitstabilität | 3 | Build stabil; Router- und Hydrationfehler bleiben |
+| 19 | Visual-QA-Reife | 1 | Mehrere offensichtliche Breakpoint-Regressionen |
+| 20 | Eigenständigkeit / Anti-Slop | 3 | Eigenständige Richtung, aber unfertige generische Module |
+|  | **Gesamt** | **41 / 100** | **Hard Blocker vorhanden** |
+
+## Stärken, die erhalten werden sollten
+
+- Die Agent-/Task-Domäne ist konkret und nicht generisch.
+- Backend-Schichten und Runtime-Abstraktion bieten eine belastbare
+  Weiterentwicklungsbasis.
+- Task-Bridge und Statusvalidierung sind ein sinnvoller Integrationskern.
+- Deployment, Backup und Rollback sind nicht nur als Wunsch, sondern als
+  Workflows vorhanden.
+- Mehrere Detailseiten besitzen bereits eine brauchbare Informationsarchitektur.
+- Die violette Galaxy-Richtung des Dashboards ist grundsätzlich
+  wiedererkennbar; sie muss responsiv und systemweit konsistent umgesetzt
+  werden, nicht verworfen.
+
+## Release-Blocker und Roadmap
+
+### P0 – vor jeder öffentlichen Freigabe
+
+- Globale authenticated-by-default Authorization Policy einführen; öffentliche
+  Routen explizit markieren.
+- Agent-Command-Endpunkt rollen- oder policybasiert schützen.
+- Bridge nur mit stark authentifiziertem Service-Context zulassen; öffentliche
+  Caller-Header am Proxy entfernen.
+- Negative End-to-End-Tests über die reale Proxygrenze hinzufügen.
+- Dashboard-Navigation auf registrierte Ziele begrenzen.
+- Dashboard bei 375, 768 und 1024 px ohne Überlappung, Abschneiden oder
+  unzugängliche Kernaktion ausliefern.
+
+### P1 – Stabilisierungsmeilenstein
+
+- Eine kanonische App-Shell und ein gemeinsames Navigationsmodell festlegen.
+- Store-Hydration nach Login korrigieren.
+- `/team`-Backlink, tote V2-Links und Wildcard-Maskierung korrigieren.
+- `Critical` über Datenmodell, Mapper, Formulare und Tests konsistent
+  roundtrip-fähig machen.
+- Doppelte Live-Sync-Store-Dateien konsolidieren.
+- Task Board für Mobilgeräte als Status-Segmente oder Liste gestalten.
+- Route-, Store-, Accessibility- und Responsive-Regressionstests ergänzen.
+
+### P2 – Qualitäts- und Wartbarkeitspass
+
+- Kontrast, Mindestschriftgrößen, Focus States und Accessible Names
+  systematisch korrigieren.
+- Projects, Models, Activity und Chat aus dem generischen ModuleView lösen.
+- README, Route-Dokumentation, Versionen und Screenshots aktualisieren.
+- .NET SDK über `global.json` pinnen.
+- Produktionspfade konfigurierbar machen.
+- Bootstrap-Secrets aus persistenten Logs entfernen.
+
+## Definition of Done für die nächste Evaluation
+
+- Alle P0-Punkte sind in Code und Tests geschlossen.
+- `dotnet test` läuft mit .NET 10 vollständig grün.
+- `pnpm test` und `pnpm build` sind grün.
+- Jede registrierte Route hat einen automatisierten Smoke-Test.
+- Kein Navigationseintrag führt über den Wildcard-Redirect zurück.
+- Login lädt alle benötigten Stores ohne manuellen Refresh.
+- Dashboard und Task Board bestehen visuelle Prüfungen bei 375, 768, 1024,
+  1440 und 1920 px.
+- Keyboard-Navigation, Accessible Names und Kontrast der Kernflows sind
+  nachweisbar geprüft.
+- Ein Live-Smoke-Test bestätigt PostgreSQL, OpenClaw, SSE und Proxyverhalten.
+
+## Schlussurteil
+
+Nexus hat eine ernstzunehmende Backend- und Betriebsbasis und sollte
+weiterentwickelt, nicht ersetzt werden. Der nächste sinnvolle Schritt ist aber
+keine neue Feature-Runde. Zuerst braucht das Projekt eine kurze,
+evidenzgetriebene Stabilisierung, die Zugriffskontrolle, UI-Konvergenz,
+Responsive-Verhalten und Frontend-Regressionsschutz gemeinsam schließt.