CEO-Audit: 54/100

[Delqhi]

CEO-Audit: 54/100

Mein Urteil: OpenSIN Chat hat einen starken, differenzierbaren Produktkern. Das Repository und der Produktionsbetrieb wirken aber derzeit wie ein schnell gewachsenes Founder-/Agentenprojekt: sehr viele Features, enorme Änderungsfrequenz, widersprüchliche Dokumentation und ein nicht reproduzierbarer Produktionsprozess.

Es ist kein schlechtes Produkt. Es ist ein gutes Produkt, das momentan durch zu viel Ballast und zu wenig operative Disziplin gefährdet wird.

Die Live-Seite konnte meine Browser-Umgebung nicht direkt rendern. Der Abruf endete mit einem Cache-Fehler. Die Live-Beurteilung stützt sich deshalb auf die aktuellen produktionsbezogenen Issues, Live-Browser-Audits, Deployment-Skripte und Smoke-Tests im Repository – nicht auf eine frische visuelle Bildschirmaufnahme.

Bewertung

Bereich | Punkte | Urteil -- | -- | -- Produktidee und Differenzierung | 8/10 | Sehr stark Politische Recherche und Quellen | 7/10 | Wertvoll, aber noch nicht zuverlässig genug abgesichert UX und Produktklarheit | 5/10 | Zu viele Funktionen und Bedienelemente Architektur und Wartbarkeit | 5/10 | Leistungsfähig, aber stark gewachsen Security | 4/10 | Einige gute Maßnahmen, aber gravierende Widersprüche CI/CD und Produktion | 3/10 | Aktuell größtes Unternehmensrisiko Dokumentation und Governance | 2/10 | Unzuverlässig und widersprüchlich Gesamt | 54/100 | Viel Potenzial, noch nicht scale-ready

---

Die wichtigsten Erkenntnisse

1. Der vorhandene CEO-Bericht ist nicht vertrauenswürdig

Der Bericht vom 8. Juli behauptet oben gleichzeitig:

• Note A und 90/100

• „alle kritischen Schulden behoben“

• „production-ready“

Weiter unten nennt derselbe Bericht jedoch weiterhin mehr als 24 God-Files, ungefähr 1.651 Inline-require()-Aufrufe, lediglich zwei TypeScript-Dateien gegenüber 477 JavaScript-Dateien, rund 23 Prozent Server-Coverage und ein Blackbox-CI-System. Am Ende berechnet er außerdem nur 85/100 und erklärt, was für 90 Punkte noch fehlt.

CEO-Entscheidung: Bericht ersetzen oder klar als historisches, nicht verifiziertes Agentenergebnis archivieren. Solche Dokumente dürfen nicht den Unternehmenszustand beschönigen.

---

2. Im öffentlichen Repository befinden sich kritische Betriebsinformationen

Der öffentliche Deployment-Guide enthält einen konkreten Standard-Authentifizierungstoken, die öffentliche VM-IP, den SSH-Benutzer, interne Ports, Container- und Hostnamen, Produktionspfade und Backup-Verzeichnisse.

Zusätzlich verwendet ein Wartungsskript denselben konkreten Wert als Standardpasswort für einen Administrator. Wird keine Umgebungsvariable gesetzt, erstellt es damit tatsächlich einen Passwort-Hash.

Das widerspricht unmittelbar der eigenen Security Policy, laut der veröffentlichte Demo- oder Onboarding-Zugangsdaten sofort als kompromittiert gelten und rotiert werden müssen. Die Policy behauptet außerdem, dass ceo-audit.yml und secrets-scan.yml dies in CI verhindern – mindestens ceo-audit.yml existiert im aktuellen Repository jedoch nicht.

Sofortmaßnahme

1. Betroffenen Authentifizierungstoken und alle davon abgeleiteten Zugangsdaten rotieren.

2. Standardpasswort vollständig aus Skript und Dokumentation entfernen.

3. Skript ohne ausdrücklich übergebenes Passwort hart abbrechen lassen.

4. Öffentliche Betriebsdetails in ein privates Infrastructure-/Operations-Repository verschieben.

5. Git-Historie auf weitere Secrets oder Zugangsdaten prüfen.

---

3. Die Produktionsbereitstellung ist nicht reproduzierbar

Das Deployment-Skript:

• baut standardmäßig nur das Frontend,

• führt vorher keinen verpflichtenden Lint-, Test- oder Typecheck aus,

• synchronisiert main direkt auf den Server,

• kopiert Server-Quellverzeichnisse mit docker cp in einen bereits laufenden Container,

• startet denselben Container neu,

• baut das Docker-Image nur optional mit REBUILD_IMAGE=1,

• behandelt den externen Live-Healthcheck nicht als verpflichtendes Gate.

Dadurch kann Produktion einen Zustand enthalten, den kein Docker-Image und kein Commit exakt repräsentiert. Neue Abhängigkeiten, Migrationen oder Build-Schritte können fehlen, obwohl die JavaScript-Dateien schon live kopiert wurden.

Das ist das größte Unternehmensrisiko im Projekt.

Zielzustand

Commit → echte CI → unveränderliches Image → Staging → Smoke-Test → Production → Rollback-fähiges vorheriges Image

Kein docker cp mehr in Produktionscontainer. Keine lokalen Builds mehr als Produktionsquelle. Kein direktes Hot-Patching von main.

---

4. Das vorhandene GitHub-CI ist faktisch ein Platzhalter

Die einzige geprüfte CI-Datei enthält einen Job, der lediglich einige Texte ausgibt. Der Kommentar sagt, dass die eigentliche CI über einen Webhook auf der OCI-VM läuft. Der GitHub-Job wartet aber nicht wirklich auf das externe Ergebnis und führt selbst weder Tests noch Linting aus.

Gleichzeitig behauptet das Lint-Runbook:

• es gebe einen Root-Befehl yarn lint:ci,

• es gebe .github/workflows/tests.yml,

• es gebe .github/workflows/ceo-audit.yml.

Der Root-Befehl ist nicht im aktuellen package.json enthalten und die beiden genannten Workflow-Dateien existieren nicht.

CEO-Entscheidung: Entweder die GitHub Actions tatsächlich implementieren oder alle Behauptungen über nicht vorhandene Qualitäts-Gates entfernen. Scheinbare CI ist gefährlicher als offen fehlende CI.

---

5. Das Produkt verliert seinen Fokus

Der eigentliche Wert ist sehr klar:

Politische Dokumente, Bundestagsdaten, belastbare Quellen, Recherche und professionelle Berichte.

Das README positioniert OpenSIN Chat genau so, listet daneben aber eine extrem breite Plattform auf:

• zahlreiche LLM-Anbieter,

• sechs Vector-Datenbanken,

• MCP,

• Codeausführung,

• Bildgenerierung,

• Videogenerierung,

• sieben TTS-Systeme,

• Prominentenstimmen,

• interaktive Diagramme,

• diverse Agenten und generische Dateigeneratoren.

Auch in der primären Chat-Oberfläche sind Deep Research, Bildgenerierung, Videogenerierung und Berichte alle als aktivierte Agentenmodi definiert.

Das ist technologisch beeindruckend, aber geschäftlich problematisch: Der Nutzer versteht nicht mehr, weshalb OpenSIN Chat besser ist als ein allgemeiner KI-Chat.

Produktkern, den ich behalten würde

• Dokumenten-Chat und RAG

• nachvollziehbare Quellen

• Bundestags- und Politiker-Datenbank

• politische Recherche

• Deep Research

• professionelle PDF-/DOCX-Berichte

• Notizen und Arbeitsbereiche

• relevante Diagramme für politische Daten

• Rollen, Berechtigungen und Audit-Protokolle

Aus dem Kernprodukt entfernen oder hinter „Experimentell“ verstecken

• Videogenerierung

• allgemeine Bildgenerierung

• Prominenten-TTS

• sieben parallel angebotene TTS-Systeme

• selten verwendete LLM- und Vector-DB-Anbieter

• allgemeine Codeausführung

• Community-Plugins und MCP für normale Benutzer

• Spezialintegrationen ohne nachgewiesene Nutzung

---

6. Videogenerierung und Prominenten-TTS sollten aus dem Kern entfernt werden

Die Videogenerierung kann bis zu fünf Minuten warten, pollt externe Dienste, lädt zurückgegebene URLs direkt herunter und puffert das komplette Video im Arbeitsspeicher. Eine klare maximale Dateigröße oder eine erkennbare URL-Allowlist ist in diesem Pfad nicht vorhanden.

Der cvoice-Provider enthält feste Stimmen-IDs und Namen mehrerer realer deutscher Prominenter. Außerdem überträgt er Antworttexte an einen externen Anbieter und lädt die vom Anbieter zurückgegebene Audio-URL direkt herunter.

Das verursacht:

• zusätzliche Security-Oberfläche,

• Datenschutz- und Compliance-Fragen,

• potenzielle Persönlichkeitsrechts- und Markenrisiken,

• höheren Supportaufwand,

• Ablenkung vom eigentlichen Produkt.

CEO-Entscheidung: Prominenten-TTS vollständig entfernen. Videogenerierung aus dem Standardprodukt entfernen und höchstens als getrenntes experimentelles Plugin weiterführen.

---

7. Das Repository enthält zu viele widersprüchliche Dokumente

Es existieren unter anderem:

• MASTER-PLAN.md

• FUTURE-PLAN.md

• ROADMAP.md

• mehrere CEO-Audit-Berichte

• ein Production-Readiness-Report

• mehrere Deployment-Guides

• docs/architecture.md und docs/ARCHITECTURE.md

• docs/user-guide.md und docs/USER_GUIDE.md

• Root- und In-App-Kopien vieler Dokumente

• alte OpenAFD-Unterlagen

• .github/ISSUES_FOUND/

• alte einzelne Design- und Audit-Berichte

Der Master-Plan vom 29. Juni bezeichnet sich noch als „aktiv“, enthält zahlreiche inzwischen veraltete Aufgaben, doppelte Dateiangaben und alte technische Probleme.

Das README behauptet außerdem, es gebe einen automatischen Produktionsdeploy, während die Auto-Deploy-Dokumentation ausdrücklich sagt, dass der Produktions-Auto-Deploy noch einzurichten ist.

Behalten

• README.md

• SECURITY.md

• CONTRIBUTING.md

• ein aktueller Architekturüberblick

• ein Self-Hosting-Guide

• eine API-Referenz

• ein Nutzerhandbuch

• ADRs für dauerhafte Architekturentscheidungen

Archivieren oder entfernen

• alte CEO-Audits

• MASTER-PLAN.md

• alte Production-Readiness-Berichte

• einzelne abgeschlossene Design-Issue-Dokumente

• OpenAFD-Video-Dokumente

• .github/ISSUES_FOUND/

• persönliche Produktionsanleitungen

• doppelte Groß-/Kleinschreibungsvarianten

• alte Deployment-Varianten ohne aktiven Maintainer

GitHub Issues und Projects sollten der aktuelle Arbeitsstand sein – nicht zehn konkurrierende Markdown-Pläne.

---

8. README und Branding sind sichtbar veraltet

Das README verweist auf mehrere Screenshots unter docs/screenshots/, die im geprüften Stand nicht vorhanden waren. Es bindet außerdem weiterhin ein „OpenAFD Chat“-Video in das OpenSIN-README ein.

Die Root-Metadaten nennen als Homepage opensin.delqhi.com, während Produkt und Live-Demo sinchat.delqhi.com verwenden.

Die absichtliche Migration alter openafd_*-LocalStorage-Schlüssel sollte dagegen vorerst erhalten bleiben: Der Code nennt ausdrücklich den 1. Januar 2027 als geplantes Entfernungsdatum.

Entfernen: alte Branding-Dateien und Videos.
Behalten: klar dokumentierte Kompatibilitätsmigration bis zum festgelegten Ablaufdatum.

---

9. Dependency- und Toolchain-Inseln

Das Projekt verwendet unterschiedliche und teilweise doppelte Toolchains:

• Root: ESLint 10

• Frontend: ESLint 9

• Frontend: TypeScript 6 plus zusätzlich TypeScript 7

• Server: TypeScript 7

• Root-Skripte nutzen Yarn für den Server und npm für das Frontend

• einzelne Workspaces besitzen eigene Lockfiles

• Root und Workspaces enthalten teilweise doppelte Runtime-Abhängigkeiten.

Besonders der Collector ist eine Versionsinsel: ältere Transformer-, LangChain-, PDF-, Puppeteer-, Moment- und Prettier-Versionen sowie eine Git-Abhängigkeit aus dem ursprünglichen Mintplex-Umfeld.

CEO-Entscheidung: Eine Node-Version, ein Paketmanager, ein ESLint-Major und ein TypeScript-Major. Collector entweder modernisieren oder als separat versionierten Dienst abspalten.

---

10. Docker ist unnötig privilegiert

Die Compose-Datei verleiht dem App-Container SYS_ADMIN. Der Produktions-Override entfernt diese Berechtigung nicht. Außerdem bindet der Basis-Compose-Port ohne 127.0.0.1-Präfix; ob der Port extern erreichbar ist, hängt somit von Host-Firewall und Deployment-Konfiguration ab, obwohl SECURITY.md einen reinen Localhost-Bind behauptet.

Der Docker-Build:

• pinnt das Ubuntu-Image nicht auf einen Digest,

• verwendet weiterhin einen AnythingLLM-CDN-Link für Chromium,

• installiert mehrere Werkzeuge über externe Curl-/Downloadpfade,

• baut Server, Collector, Browserautomation und Frontend in ein großes System.

Änderung

• SYS_ADMIN entfernen

• cap_drop: [ALL]

• security_opt: [no-new-privileges:true]

• Port explizit an 127.0.0.1 binden

• App und Browser-/Collector-Worker trennen

• Images per Digest pinnen

• optionalen Chromium-Code nicht in das Kernimage packen

---

Was ich konkret entfernen würde

Sofort aus dem Produkt

• cvoice-Prominentenstimmen

• Videogenerierungsmodus

• nicht konfigurierte oder nicht genutzte Agentenmodi

• sichtbare „alles kann alles“-Provider-Auswahl für normale Benutzer

Aus dem öffentlichen Repository

• konkrete Produktionszugangsdaten und Standardpasswörter

• VM-IP, SSH-Benutzer, Tunnel-IDs und persönliche Rechnerpfade

• alte OpenAFD-Videos und Branding-Artefakte

• veraltete CEO-/Readiness-Berichte

• Master- und Future-Pläne, die nicht mehr gepflegt werden

• alte Audit-Fundlisten

• Deployment-Dokumente für nicht mehr verwendete Umgebungen

• unmaintained Cloud-Deployment-Stubs

In ein privates Ops-Repository verschieben

• produktive Servernamen

• SSH-Kommandos

• Cloudflare-Konfiguration

• Backup-Pfade

• Recovery-Befehle

• Infrastrukturdiagramme mit echten Adressen

• Produktionsdeploy-Skripte und Secrets-Konfiguration

Nur optional installieren

• Chromium und Videowerkzeuge

• OCR

• lokale Transformer

• Datenbanktreiber für MySQL, MSSQL und PostgreSQL

• alternative Vector-Datenbanken

• TTS-/STT-Anbieter

• MCP und Community-Plugins

---

30-Tage-Plan

Tage 1–2: Sicherheitsstopp

• Zugangsdaten rotieren

• Standardpasswort entfernen

• öffentliche Betriebsinformationen bereinigen

• Secret-Scan über gesamte Git-Historie

• Video- und cvoice-Funktionen deaktivieren

• SYS_ADMIN entfernen

Woche 1: Produktion beherrschbar machen

• echte GitHub-CI mit Lint, Typprüfung, Tests und Build

• immutable Docker-Images mit Commit-SHA

• Staging-Deployment

• Migrationen vor App-Start

• produktiver Smoke-Test mit echten Assertions

• Rollback auf vorheriges Image

Das vorhandene Live-E2E-Skript macht überwiegend Screenshots und Logausgaben, besitzt aber kaum harte Assertions. Es prüft sogar administrative Endpunkte und führt einen programmatischen Root-Login aus. Das sollte in eine echte, isolierte Playwright-Suite mit Testbenutzer umgebaut werden.

Woche 2: Produkt radikal fokussieren

Primäre Navigation nur noch:

1. Chats und Projekte

2. Quellen und Dokumente

3. Politische Daten

4. Recherche

5. Berichte

6. Administration

Alles andere in ein verborgenes Labor oder komplett entfernen.

Woche 3: Repository bereinigen

• eine zentrale Dokumentationsquelle

• alte Berichte nach docs/archive/ oder löschen

• kaputte Screenshots ersetzen

• Video-Dateien in Releases oder externes Storage verschieben

• Toolchain vereinheitlichen

• Collector separat behandeln

Woche 4: Qualität messbar machen

Verpflichtende Release-Kriterien:

• Quellenverweise zeigen garantiert das richtige Dokument

• Upload und Verarbeitung funktionieren

• Chat senden und wechseln funktioniert

• Light/Dark/Mobile funktionieren

• keine Browser-Console-Errors

• keine offenen P0-/P1-Probleme

• Backup-Restore wurde praktisch getestet

• Rollback wurde praktisch getestet

---

Endurteil

OpenSIN Chat sollte nicht neu gebaut werden. Der Kern ist zu wertvoll und bereits zu weit entwickelt.

Es braucht stattdessen einen Entfernungs- und Konsolidierungssprint:

Weniger Features, weniger Dokumente, weniger Deployment-Wege, weniger Anbieter – dafür zuverlässige Quellen, sichere Produktion und ein glasklares politisches Rechercheprodukt.

Ich habe keine Änderungen, Issues oder Pull Requests im Repository erstellt. Der sinnvollste nächste Schritt ist ein Cleanup-Branch mit getrennten Paketen für Security P0, CI/CD, Produkt-Scope und Repository-Bereinigung.