Vision und Scope

English · Deutsch

Letzte Aktualisierung: 22. Mai 2026 (D-054: Continuous-Learning-Loop in den Scope aufgenommen; learning-retrieval-Providertyp)

Vision

Geef.Atelier ist eine Text-Manufaktur: ein Atelier aus spezialisierten KI-Rollen (Executor, Reviewer, optional Advisor), das je nach Werkstück unterschiedlich besetzt wird. Der Unterschied zu einem klassischen "GPT-Wrapper" ist nicht Bedienung oder Preis, sondern dass die Maschine vor der Arbeit entscheidet, wie sie arbeitet (adaptive Crew-Komposition) und während der Arbeit transparent macht, was sie tut (Prozess-Sichtbarkeit über Iterations- und Findings-Trail).

Das Projekt ist die produktive Anwendung des Geef SDK: Es nutzt das GEEF-Pipeline-Pattern (Grounding / Execution / Evaluation / Finalize) und die Erweiterungen (Convergence-Policies, Evaluation-Strategies, Advisor-Pattern, EventSink, Middleware), um Texte in Höchstqualität zu erzeugen.

Leitsterne

Adaptive Crew-Komposition — Der Klassifikator erkennt die Textsorte und stellt aus einem getaggten Reviewer-/Advisor-Pool die passende Crew zusammen. Spezialisierung passiert über Daten (Reviewer-Profile, Crew-Templates), nicht über Code-Branches.
Prozess-Transparenz — Jeder Run hinterlässt einen vollständigen Trail: alle Iterationen, alle Findings, alle Advisor-Konsultationen. Vertrauen entsteht durch Nachvollziehbarkeit.
Modell-Pluralismus — Reviewer nutzen bewusst andere Modelle als der Executor, um echte Außenperspektive zu erzeugen statt Selbstbestätigung.

In Scope

Generische Pipeline für beliebige Textsorten (juristische Schriftsätze, Fachartikel, Marketing, akademische Texte, Briefe, Gedichte, …)
Mehrbenutzer-Hosting auf eigenem Docker-Server: DB-basierte Benutzerverwaltung (BCrypt), Run-Sichtbarkeit pro Nutzer isoliert, Admin-Override per expliziten Umschaltern
Web-UI (Blazor Server) für Auftragserteilung, Live-Status, Ergebnis-Abholung
MCP-Server-Schnittstelle, damit externe KI-Clients (Claude Desktop, Claude Code, Custom-Agents) Aufträge erteilen und Ergebnisse abholen können — Auth über statisches Bearer-Token oder self-hosted OAuth 2.1
Multi-Provider-LLM-Support: OpenRouter (Pay-per-Token) sowie Subscription-CLIs (Claude Code, Codex) über einen lokalen Proxy; Reviewer/Advisor bewusst mit Fremd-Modellen
Quellen-Übergabe in mehreren Formen: Datei-Upload (PDF, DOCX, TXT, MD), URLs, Freitext-Briefing, Stil-Referenztexte; semantische Wissensbasis (Vector-Store-RAG) und Run-lokale Attachments
Fire-and-Forget-Workflow: Auftrag starten, später Status prüfen, am Ende Ergebnis abholen — keine Mensch-im-Loop-Eingriffe während des Runs
Persistente Run-Historie mit vollständigem Iterations-Trail
Run-Fortsetzung: einen fehlgeschlagenen oder abgebrochenen Run ab dem letzten Draft-Text (Seed-Modus) oder mit frischer Pipeline (Clean-Modus) fortsetzen — D-046
Datei-Export in den Formaten md / html / pdf / docx / txt / json über die Finalizer-Pipeline (D-044); die fünf Finalizer-Profil-Typen (FileExport, MetadataEnrich, ExternalSink, Transform) sind als Teil des Crew-Systems implementiert
Grounding-Anreicherung in mehreren Formen: Tavily-Websuche (tavily), semantische Vector-Store-RAG (vector-store), kuratierter Fixtext für Style-Guides und Glossare (static-context), gezieltes URL-Fetching mit SSRF-Schutz (url-fetch), Tavily-Newssuche mit Datumsfilter (news-search), akademische Literaturrecherche bei arXiv / Semantic Scholar / OpenAlex (academic-search) und generisches REST-Endpoint-Grounding mit SSRF-Schutz und JSONPath-Extraktion (rest-api); jeder Provider unterstützt optional einen KI-Refinement-Pass (D-050–D-052); domänen-bewusste Abfrage aus dem Learning-Store (learning-retrieval, D-054)
Continuous-Learning-Loop (D-054): Ein opt-in-learning-extractor-Finalizer extrahiert strukturierte Fakten aus abgeschlossenen Runs und stößt fire-and-forget einen dedizierten Qualitäts-Gate-Run an (learning-evaluation-Crew). Nur Learnings, die das Gate konvergent durchlaufen (drei strenge Reviewer, AbortOnCritical=true, Multi-Modell-Pluralismus), werden als Approved im Learning-Store gespeichert (LearningEntries-Tabelle, getrennter Namespace von der kuratierten Wissensbasis). Der learning-retrieval-Grounding-Provider spielt sie gewichtet nach Domänen-Ähnlichkeit in spätere Runs ein. Verwaltungs-UI unter /crew/learnings; MCP-Tool list_learnings. Drei Schutzmechanismen gegen Model Collapse: (1) getrennter Namespace, (2) auditierbares Gate, (3) ausschließlich strukturierte Fakten

Out of Scope (vorerst)

Echte Mandantenfähigkeit / Multi-Tenant-Isolation (das System ist Mehrbenutzer, aber single-tenant: ein Admin, gemeinsame Konfiguration; pro Nutzer ist nur die Run-Sichtbarkeit isoliert)
Öffentlicher Zugang ohne Auth
Mensch-im-Loop zwischen Iterationen (bewusst nicht implementiert; Fire-and-Forget bleibt das Modell)
Mobile Apps oder native Clients
Kommerzielles Hosting, Billing, Abrechnung
Ungefiltertes Cross-Run-Self-RAG (bewusst verworfen; der Continuous-Learning-Loop oben bietet gegatetes Cross-Run-Lernen mit drei Schutzmechanismen gegen Model Collapse)
Domänen-spezifische Datenbank-Connectors (z.B. juristische Datenbanken wie dejure.org oder Beck-Online) — später optional
Direkter „Export”-Button in der Briefing-UI: ein mit einem Klick erreichbarer Export-Button in der Run-/Briefing-Oberfläche ist nicht implementiert. (Datei-Export in md/html/pdf/docx/txt/json ist implementiert, aber ausschließlich über die Finalizer-Pipeline, die im Crew-Template konfiguriert wird — siehe „In Scope” oben.)

Zielnutzer

Mehrere benannte Benutzerkonten, verwaltet durch einen Admin. Die Anwendung ist nicht mandantenfähig (keine Tenant-Trennung von Konfiguration oder Crew-Daten), aber jeder Nutzer sieht nur seine eigenen Runs; der Admin kann optional alles einsehen. Authentifizierung ist Pflicht, weil die App über das öffentliche Internet erreichbar ist (Server-Hosting).

Hosting-Umgebung

Docker-Container auf eigenem Server
Postgres ist bereits als Datenbankdienst auf dem Server vorhanden — das Projekt nutzt diese existierende Postgres-Instanz, kein separater DB-Container nötig (außer für lokale Entwicklung)
Reverse-Proxy (Traefik / Nginx) übernimmt TLS-Terminierung
API-Keys, Connection-Strings, Auth-Secrets über Environment-Variablen / Docker Secrets
Persistente Datenhaltung in Postgres (inkl. pgvector für die semantische Wissensbasis); hochgeladene Quellen werden indexiert in der Datenbank gehalten

Erfolgs-Kriterium für das Skeleton

Status: Dieses Skeleton-Erfolgskriterium ist seit Mai 2026 vollständig erfüllt; die App läuft produktiv. Die unten als „danach“ genannten Erweiterungen (Quellen-Upload/RAG, Crew-Komposition, Advisor-Pässe) sind inzwischen ausgeliefert. Die folgende Liste bleibt als ursprüngliche Definition des Minimal-Ziels erhalten.

Das Walking Skeleton (siehe 03-walking-skeleton-plan.md) ist erfolgreich, wenn:

Ein Auftrag mit reinem Text-Briefing über die Web-UI startbar ist.
Die Pipeline mit Anthropic als Executor und zwei festen Reviewern (z.B. mit OpenAI-Modell) durchläuft, ohne dass der User eingreifen muss.
Während des Runs ein Live-Status in der UI sichtbar ist (aktuelle Phase, Iteration, Findings).
Nach Abschluss der finale Text in der UI angezeigt wird.
Derselbe Workflow auch über den MCP-Server funktioniert (Auftrag absetzen, Status abfragen, Ergebnis abholen via MCP-Tools).
Die ganze Anwendung als Docker-Container deploybar ist und sich an die existierende Postgres-Instanz anbindet.

Alles weitere (Quellen-Upload, Klassifikator, dynamische Crew, Advisor, Multi-Format-Export) sind Erweiterungen nach dem Skeleton.