Der Dritte Architecture

Stand: 2026-04-26

Diese Datei ist die zentrale technische Architekturuebersicht fuer Der Dritte. Sie beschreibt die tragenden Systemgrenzen, Datenfluesse, Sicherheitsgates und Betriebsmechaniken. Detaildokumente bleiben in docs/, insbesondere docs/prompt-architecture.md, docs/architecture/three-stage-rooms-spec.md, docs/decisions/ und docs/operations/.

1. Systemkontext

Der Dritte ist eine Expo-/React-Native-App mit Supabase als Backend. Zwei Personen arbeiten in getrennten privaten Raeumen an einem Konflikt und wechseln erst nach Readiness und Prozessvertrag in einen gemeinsamen moderierten Raum. Die Mediation selbst wird serverseitig in Supabase Edge Functions orchestriert.

flowchart LR
  subgraph Users["Menschen im Konflikt"]
    A["Person A"]
    B["Person B"]
  end

  subgraph Client["Expo / React Native App"]
    Screens["Screens + Navigation"]
    ChatHook["useChatRoom"]
    MediationClient["services/mediation.ts"]
    LocalI18n["i18next + locale files"]
    Purchases["RevenueCat client"]
    ObservabilityClient["Sentry + PostHog"]
  end

  subgraph Supabase["Supabase Project"]
    Auth["Auth + OAuth + password reset"]
    Postgres["Postgres + RLS + RPCs"]
    Realtime["Realtime channels"]
    Edge["Edge Functions"]
  end

  subgraph External["External Services"]
    LLM["OpenAI-compatible LLM endpoint"]
    RevenueCat["RevenueCat webhooks/API"]
    Email["Auth email delivery"]
    Alerts["Safety alert webhook"]
    Sentry["Sentry"]
    PostHog["PostHog"]
  end

  A --> Screens
  B --> Screens
  Screens --> ChatHook
  Screens --> LocalI18n
  Screens --> Purchases
  ChatHook --> MediationClient
  ChatHook --> Postgres
  ChatHook --> Realtime
  MediationClient --> Edge
  Screens --> Auth
  Edge --> Postgres
  Edge --> LLM
  Edge --> Alerts
  Edge --> Email
  RevenueCat --> Edge
  Purchases --> RevenueCat
  ObservabilityClient --> Sentry
  ObservabilityClient --> PostHog
  Edge --> Sentry
  Edge --> PostHog

2. Schichten und Verantwortungen

flowchart TB
  subgraph App["Client Application"]
    Navigator["AppNavigator"]
    Screens["screens/*"]
    Components["components/*"]
    Hooks["hooks/*"]
    Services["services/* + lib/db/*"]
    I18n["i18n/*"]
  end

  subgraph Backend["Supabase Backend"]
    Rpc["Postgres RPCs"]
    Views["Security-definer Views"]
    Rls["RLS Policies"]
    EdgeMediate["mediate Edge Function"]
    EdgeAux["auxiliary Edge Functions"]
  end

  subgraph Core["Mediation Core"]
    Middleware["middleware.ts"]
    Safety["safety-handler.ts"]
    Routing["routing.ts + stage-routing.ts"]
    Context["context-builder.ts"]
    Flow["mediation-flow.ts"]
    Llm["llm.ts"]
    Persistence["message-persistence.ts"]
    Essence["essence-generator.ts"]
    Memory["memory-loader.ts + memory-writer.ts"]
  end

  Navigator --> Screens
  Screens --> Components
  Screens --> Hooks
  Hooks --> Services
  Screens --> I18n
  Services --> Rpc
  Services --> Views
  Services --> EdgeMediate
  Services --> Rls
  EdgeMediate --> Middleware
  Middleware --> Safety
  Safety --> Routing
  Routing --> Context
  Context --> Flow
  Flow --> Llm
  Flow --> Persistence
  Flow --> Essence
  Flow --> Memory
  EdgeAux --> Rpc

3. Room Lifecycle

Die Room-Architektur trennt private Vorbereitung und gemeinsamen Raum bewusst. Person A erhaelt beim Erstellen sofort private_a; Person B erhaelt private_b erst beim Join. Der gemeinsame Thread entsteht erst bei shared_active.

stateDiagram-v2
  [*] --> waiting: createRoom()
  waiting: Person A private_a exists

  waiting --> private_phase: join_room_by_code()
  private_phase: private_a + private_b

  private_phase --> ready_phase: both set_ready_for_shared_room(true)
  ready_phase --> private_phase: either side retracts readiness
  ready_phase --> shared_active: activate_shared_room()
  shared_active: shared thread exists

  private_phase --> paused: pause_room()
  ready_phase --> paused: pause_room()
  shared_active --> paused: pause_room()

  paused --> private_phase: resume_room()
  paused --> ready_phase: resume_room()
  paused --> shared_active: resume_room()

  private_phase --> closed: explicit close
  ready_phase --> closed: explicit close
  shared_active --> closed: exit gate or explicit close
  waiting --> closed: explicit close

  private_phase --> terminated_safety: safety termination
  ready_phase --> terminated_safety: safety termination
  shared_active --> terminated_safety: safety termination
  terminated_safety --> [*]
  closed --> [*]

Wichtige Invarianten:

• waiting erlaubt Person A bereits private Mediation.
• private_phase ist der Standardzustand nach dem Join von Person B.
• ready_phase ist reversibel, solange der Shared Room nicht aktiviert wurde.
• shared_active ist der einzige regulaere Zustand fuer den gemeinsamen Thread.
• paused, closed und terminated_safety machen Chat-Interaktion read-only.
• Legacy-Status active wird defensiv weiter akzeptiert.

4. Mediation Request Pipeline

Der normale Mediationsturn laeuft ueber die mediate Edge Function. Spezial- Actions wie Bootstrap, Shared-Message-Gate, Essence-Generierung und Prozessvertrag werden vor dem generischen LLM-Flow abgefangen.

flowchart TD
  Request["Client invokes mediate"] --> Cors["CORS + origin check"]
  Cors --> Auth["authenticateRequest"]
  Auth --> Validate["validateRequest + thread access"]

  Validate --> Action{"action"}
  Action -->|translate| Translate["handleTranslateAction"]
  Action -->|bootstrap_private| BootstrapPrivate["handleBootstrapPrivateAction"]
  Action -->|bootstrap_shared| BootstrapShared["handleBootstrapSharedAction"]
  Action -->|send_shared| SharedGate["handleSendSharedAction"]
  Action -->|generate_essence| ManualEssence["handleManualEssenceAction"]
  Action -->|confirm_contract|getContract["Process contract handlers"]
  Action -->|mediate or empty| Generic["Generic mediation flow"]

  Generic --> Terminated{"Room terminated_safety?"}
  Terminated -->|yes| TerminationMsg["Return termination message"]
  Terminated -->|no| SessionSafety{"3+ safety incidents in 60min?"}
  SessionSafety -->|yes| MarkTerminated["Set room -> terminated_safety"]
  SessionSafety -->|no| Safety["Two-stage safety gate"]

  Safety -->|escalation| SafetyResponse["Referral / pause / hotline response"]
  Safety -->|pass| Memory["Load memory overlay if enabled"]
  Memory --> Mode["selectMediationMode"]
  Mode --> Context["buildConversationContext"]
  Context --> Scope{"private or shared"}

  Scope -->|private| SituationGate["assessIntensity + evaluateTransition"]
  SituationGate --> PromptPrivate["Build private prompt"]

  Scope -->|shared sync| Barrier{"Both participants spoke?"}
  Barrier -->|no| Ack["Persist barrier ACK"]
  Barrier -->|yes| Contract{"Process contract confirmed?"}
  Contract -->|no| ContractMsg["Return contract prompt"]
  Contract -->|yes| PromptShared["Build shared prompt"]

  Scope -->|shared async| PromptShared
  PromptPrivate --> Llm["LLM call + forbidden output retry"]
  PromptShared --> Llm
  Llm --> Persist["Persist mediator message"]
  Persist --> Essence["Maybe generate GFK essence card"]
  Essence --> Response["Return JSON response"]

5. Shared Room v2

Shared Room v2 trennt rohe User-Nachrichten von mediatorischer Sichtbarkeit. Jede Shared-Nachricht wird zuerst durch send_shared bewertet. Nur visibility = direct ist fuer die andere Person als Rohtext sichtbar; bei visibility = mediated sieht die andere Seite nur die Mediator-Reformulierung.

sequenceDiagram
  autonumber
  participant User as Participant
  participant App as React Native App
  participant Edge as mediate/send_shared
  participant DB as Postgres
  participant LLM as LLM
  participant Other as Other Participant App

  User->>App: send shared message
  App->>Edge: action=send_shared
  Edge->>DB: load room + recent messages
  Edge->>Edge: evaluateSharedMessage()
  Edge->>DB: insert user message with visibility

  alt visibility = mediated
    Edge->>LLM: buildMediatedReframePrompt()
    LLM-->>Edge: mediator reframe
    Edge->>DB: insert mediator message
    DB-->>Other: realtime mediator message
  else visibility = direct
    DB-->>Other: realtime raw user message
    opt trend needs interjection
      Edge->>LLM: buildInterjectionPrompt()
      LLM-->>Edge: mediator interjection
      Edge->>DB: insert mediator message
      DB-->>Other: realtime mediator message
    end
  end

  Edge-->>App: gate result

Shared Room v2 Gates:

• message-gate.ts erkennt Eskalation, Beschuldigung, Beleidigung,

Ultimaten und nachlaufende Intensitaetsmuster.

• room_participants.full_mediation erzwingt auf Wunsch einer Person volle

Mediation fuer alle Nachrichten der Gegenseite.

• rooms.shared_mode = sync aktiviert das Barrier Gate: Der Mediator antwortet

substantiell erst, wenn beide Seiten seit der letzten substantiellen Mediatornachricht geschrieben haben.

• rooms.shared_mode = async bypassed die Barrier und erlaubt Antwort pro

Nachricht.

6. Datenmodell und Sichtbarkeit

erDiagram
  PROFILES ||--o{ ROOMS : creates
  PROFILES ||--o{ ROOM_PARTICIPANTS : joins
  ROOMS ||--o{ ROOM_PARTICIPANTS : has
  ROOMS ||--o{ THREADS : owns
  THREADS ||--o{ MESSAGES : contains
  ROOMS ||--o{ ESSENCES : legacy_summaries
  ROOMS ||--o{ ESSENCE_CARDS : structured_cards
  ROOMS ||--o{ PROCESS_CONTRACTS : governs
  ROOMS ||--o{ SAFETY_INCIDENTS : records
  ROOMS ||--o{ ROOM_EVENTS : emits
  PROFILES ||--o{ USER_MEMORY : owns
  PROFILES ||--o{ DYAD_MEMORY : user_a
  PROFILES ||--o{ DYAD_MEMORY : user_b

  PROFILES {
    uuid id PK
    text display_name
    text language
    boolean memory_consent
    boolean safety_memory_objection
  }

  ROOMS {
    uuid id PK
    uuid created_by FK
    room_status status
    text invite_code
    text relationship_type
    text transition_mode
    text shared_mode
    jsonb intensity_assessment
    jsonb intensity_trail
  }

  ROOM_PARTICIPANTS {
    uuid id PK
    uuid room_id FK
    uuid user_id FK
    participant_role role
    boolean ready_for_shared_room
    boolean full_mediation
  }

  THREADS {
    uuid id PK
    uuid room_id FK
    thread_scope scope
  }

  MESSAGES {
    uuid id PK
    uuid thread_id FK
    sender_type sender_type
    uuid sender_user_id
    uuid target_user_id
    text visibility
    jsonb metadata
  }

  ESSENCE_CARDS {
    uuid id PK
    uuid room_id FK
    text trigger_phase
    text observation_person_a_lang
    text observation_person_b_lang
    text feelings_person_a
    text feelings_person_b
    text needs_person_a
    text needs_person_b
  }

  PROCESS_CONTRACTS {
    uuid id PK
    uuid room_id FK
    jsonb rules
    boolean confirmed_a
    boolean confirmed_b
  }

  USER_MEMORY {
    uuid id PK
    uuid user_id FK
    user_memory_kind kind
    jsonb content
    text confidence
    timestamptz expires_at
  }

  DYAD_MEMORY {
    uuid id PK
    uuid user_a_id FK
    uuid user_b_id FK
    dyad_memory_kind kind
    jsonb content
    text visible_to
    boolean asymmetry_context
  }

Sichtbarkeitsprinzipien:

• RLS schuetzt Tabellen standardmaessig nach Raumteilnahme und Thread-Scope.
• room_state_view entkoppelt Partner-/Readiness-Status von rekursiven

RLS-Abfragen.

• essence_cards_view zeigt jeder Person nur eigene Gefuehle und Beduerfnisse,

aber gemeinsame Beobachtung, Common Ground und naechsten Schritt.

• Shared-Nachrichten der Gegenseite sind nur sichtbar, wenn

messages.visibility = direct.

• Mediatornachrichten koennen per target_user_id gezielt nur einer Person

angezeigt werden.

• user_memory ist pro User sichtbar; dyad_memory.visible_to kann both,

mediator_only oder eine spezifische User-ID sein.

7. Sicherheitsarchitektur

Safety ist serverseitig und fail-safe. Der Client zeigt Safety-Banner und Read-only-Zustaende, aber die eigentliche Entscheidung liegt in der Edge Function und in der Datenbank.

flowchart TD
  UserText["User message"] --> Unambiguous{"Unambiguous crisis regex?"}
  Unambiguous -->|yes| Hotline["hotline_referral"]
  Unambiguous -->|no| Ambiguous{"Ambiguous safety regex?"}
  Ambiguous -->|yes| Classifier["LLM safety classifier"]
  Ambiguous -->|no| HighRisk{"High-risk structural pattern?"}

  Classifier -->|crisis| Hotline
  Classifier -->|classifier error or low confidence| Distress["distress_pause fail-safe"]
  Classifier -->|non-crisis| HighRisk

  HighRisk -->|yes| Human["human_referral"]
  HighRisk -->|no| DistressCheck{"Distress pattern after context threshold?"}
  DistressCheck -->|yes| Distress
  DistressCheck -->|no| Pass["Normal mediation"]

  Hotline --> Incident["Insert safety_incidents"]
  Human --> Incident
  Distress --> Incident
  Incident --> Count{"3+ incidents in 60 minutes?"}
  Count -->|yes| Terminate["rooms.status = terminated_safety"]
  Count -->|no| SafetyMessage["Persist safety response"]

Zentrale Regeln:

• Akute Safety-Signale werden nicht durch Message-Count-Gates abgeschwaecht.
• Ambige Safety-Signale werden klassifiziert; Fehler fuehren zu

distress_pause.

• Drei Safety-Incidents innerhalb von 60 Minuten terminieren die Session.
• terminated_safety blockiert weitere substanzielle Mediation ohne LLM Call.
• Output-Guardrails pruefen Mediatorantworten gegen verbotene Muster und

triggern einmalig einen Retry mit strengerer Temperatur.

8. Prompt-, Memory- und Essence-System

Das Mediation Operating System ist eine serverseitige Pipeline aus Moduswahl, Prompt-Komposition, LLM Call, Validierung, Persistenz und strukturierter Verdichtung.

flowchart LR
  Context["Conversation context"] --> Mode["Mediation mode"]
  Mode --> StageRouting["stage-routing.ts"]
  StageRouting --> PromptBlocks["Prompt builders + prompt registry"]
  PromptBlocks --> MemoryOverlay["Optional memory overlay"]
  MemoryOverlay --> LLMCall["callLLM"]
  LLMCall --> OutputRules["FORBIDDEN_OUTPUT validation"]
  OutputRules --> Persist["Persist mediator output"]
  Persist --> TurnLog["Structured turn log"]
  Persist --> EssenceTrigger{"Essence trigger?"}
  EssenceTrigger -->|after_private| PrivateEssence["Private GFK extraction"]
  EssenceTrigger -->|after_shared| SharedEssence["Shared GFK card"]
  EssenceTrigger -->|manual| ManualEssence["Manual GFK card"]
  PrivateEssence --> Cards["essence_cards / essences"]
  SharedEssence --> Cards
  ManualEssence --> Cards
  Cards --> RoomEvents["room_events notification"]

Die Prompt-Architektur ist bewusst modular. Details zu Modi, Overlays, Versionierung, strukturiertem Shared Output und Prompt-Invariant-Tests stehen in docs/prompt-architecture.md.

Memory ist opt-in und fail-open:

• memory_consent schaltet langfristige User-/Dyad-Memory-Nutzung frei.
• memory_ab_group erlaubt Treatment/Control per Feature Flag.
• Ladefehler blockieren keine Mediation.
• Memory-Writing ist serverseitig und durch Invariant-Tests abgesichert.

9. Auth, Billing und Betrieb

flowchart TB
  subgraph AuthFlow["Auth"]
    OAuth["Email / Google / Apple"]
    Callback["Deep link callback"]
    Session["Supabase session"]
    Reset["Password reset screen"]
  end

  subgraph BillingFlow["Billing"]
    Paywall["PaywallScreen"]
    PurchasesSDK["RevenueCat SDK"]
    Webhook["revenuecat-webhook"]
    Wallet["credit wallet RPCs"]
  end

  subgraph Ops["Operations"]
    SentryClient["Client Sentry"]
    SentryEdge["Edge Sentry HTTP sender"]
    PostHogClient["Client PostHog"]
    PostHogEdge["Edge PostHog events"]
    Runbooks["docs/operations/*"]
  end

  OAuth --> Callback
  Callback --> Session
  Callback --> Reset
  Paywall --> PurchasesSDK
  PurchasesSDK --> Webhook
  Webhook --> Wallet
  Wallet --> Paywall
  Session --> Paywall
  SentryClient --> Runbooks
  SentryEdge --> Runbooks
  PostHogClient --> Runbooks
  PostHogEdge --> Runbooks

Operative Leitplanken:

• Supabase Auth ist Source of Truth fuer Sessions und User IDs.
• Der Client fordert fuer Edge Calls ein aktuelles Access Token an.
• RevenueCat verwaltet Store-Produkte; Supabase haelt den nutzbaren

Nachrichten-/Abo-Zugriff.

• Sentry faengt Client- und Edge-Fehler; PostHog trackt Produkt- und

Memory-A/B-Signale.

• Safety-Alerting und E-Mail-Setup sind in docs/operations/ dokumentiert.

10. CI und Release-Gates

flowchart LR
  Push["Push / Pull Request"] --> Format["Prettier / auto-format workflow"]
  Push --> CI["CI workflow"]
  CI --> I18n["i18n completeness"]
  CI --> Lint["ESLint"]
  CI --> DbSecurity["Supabase security preflight"]
  CI --> PgTap["Supabase pgTAP"]
  CI --> Typecheck["TypeScript typecheck"]
  CI --> EdgeCheck["Deno Edge typecheck"]
  CI --> Unit["Node unit tests"]
  CI --> PromptTests["Prompt + injection + barrier + safety tests"]
  CI --> Build["Expo build validation"]
  CI --> E2E{"E2E secrets available?"}
  E2E -->|yes| Maestro["Maestro E2E"]
  E2E -->|no| Skip["Skip with reason"]

Lokale Kernbefehle:

11. Architekturentscheidungen

Die wichtigsten Entscheidungen sind explizit als ADRs abgelegt:

• docs/decisions/ADR-001-async-as-default.md
• docs/decisions/ADR-002-essenz-sichtbarkeit-rls.md
• docs/decisions/ADR-003-deep-process-hold.md
• docs/decisions/ADR-004-shielded-async.md
• docs/decisions/ADR-005-kein-ml-klassifikator.md
• docs/decisions/ADR-006-anti-symmetrie.md
• docs/decisions/adr-shared-room-v2.md

Wenn sich Datenmodell, Room Lifecycle, Safety Gates, Prompt-Orchestrierung oder Sichtbarkeit aendern, muss diese Datei zusammen mit dem betroffenen ADR oder Detaildokument aktualisiert werden.

Der Dritte - Vision

Stand: 2026-05-13 Produktstand: App-Version 0.4.2, React Native/Expo, Supabase, OpenAI-kompatible LLM-Pipeline Quellen: Vision Paper, Pitch Deck, docs/vision.md, README.md, CLAUDE.md, Launch-/Co-Founder-Audits

1. Der Satz

Der Dritte ist ein gemeinsamer digitaler Freund zur Verständigung zwischen Menschen.

Neutral. Wohlwollend. Nicht wertend.

Kein Therapeut. Kein Ratgeber. Kein Richter. Kein heimlicher Entscheider. Der Dritte ist ein ruhiger Resonanzraum zwischen zwei Menschen, die eigentlich miteinander reden müssten, aber gerade nicht wissen, wie.

Die langfristige Vision ist nicht "noch ein Chatbot". Die Vision ist ein neues Werkzeug für Verständigung in einer lauten Welt: leise genug, um nicht zu eskalieren; strukturiert genug, um nicht nur Trost zu spenden; klar genug, um auch Grenzen zu setzen.

2. Das Problem

Viele Gespräche scheitern nicht an fehlendem Willen.

Sie scheitern an Timing, Sprache und innerer Überforderung.

Menschen wissen oft, was sie fühlen, aber nicht, wie sie es sagen können, ohne zu verletzen, zu eskalieren oder sich selbst zu verlieren. Der Inhalt ist oft klar. Die Beziehung, das Team oder die gemeinsame Arbeit ist oft noch nicht verloren. Das Problem liegt in der Übersetzung:

• zwischen Gefühl und Aussage
• zwischen Bedürfnis und Vorwurf
• zwischen Innenwelt und Dialog
• zwischen strategischer Differenz und persönlicher Kränkung

Der Dritte entsteht für genau diesen Zwischenraum.

3. Die Produktthese

Der Dritte ist ein Mediation Operating System.

Das bedeutet: Die App antwortet nicht einfach auf Nachrichten. Sie führt zwei Menschen durch einen strukturierten Prozess:

1. Erst sortiert jede Seite allein.
2. Dann erkennt das System Konflikttyp, Intensität, Grenzen und gemeinsame Muster.
3. Erst danach entsteht ein gemeinsamer Raum.
4. Dort vermittelt Der Dritte nicht Rohtexte, sondern Essenzen, Brücken und konkrete nächste Schritte.
5. Wenn ein Thema nicht in die App gehört, sagt das System das.

flowchart TD
  A["Innere Überforderung"] --> B["Privater Raum"]
  B --> C["Klären: Was meine ich wirklich?"]
  C --> D["Einordnen: Konflikttyp, Intensität, Grenze"]
  D --> E{"Sicher vermittelbar?"}
  E -->|ja| F["Gemeinsamer Raum"]
  E -->|nein| G["Safe Frame + Weiterverweis"]
  F --> H["Essenzen statt Rohtexte"]
  H --> I["Konkreter nächster Schritt"]
  I --> J["Mehr Verständigung, weniger Eskalation"]

Der Dritte ist damit kein Gesprächspartner. Er ist der Prozess, der das Gespräch wieder möglich macht.

4. Was Der Dritte tut

Der Dritte hilft zwei Menschen:

• Gedanken zu sortieren
• Sprache zu entschärfen
• Bedürfnisse hinter Vorwürfen sichtbar zu machen
• Perspektiven zu spiegeln, ohne Partei zu ergreifen
• Muster und Konflikttypen zu erkennen
• Sprachbarrieren zu überbrücken
• Gespräche zu verlangsamen, wenn Langsamkeit sicherer ist
• Grenzen zu erkennen und an professionelle Hilfe weiterzuverweisen

Die KI übernimmt keine Deutungshoheit. Sie sagt nicht, wer recht hat. Sie formuliert nicht den "richtigen" Ausgang. Ihre Arbeit ist begrenzt auf Übersetzen, Zusammenfassen, Entschärfen, Strukturieren, Einordnen und Halten.

Der Mensch bleibt Autor seiner Beziehung, seines Unternehmens und seiner Entscheidung.

5. Was Der Dritte nicht tut

Der Dritte ist bewusst begrenzt.

Er tut nicht:

• urteilen
• diagnostizieren
• manipulieren
• juristisch, steuerlich oder finanziell beraten
• therapeutische Dauerbegleitung ersetzen
• in Gewalt-, Suizid-, Missbrauchs- oder massiven Machtasymmetrie-Fällen normal weitervermitteln
• private Aussagen der einen Seite ungefiltert an die andere Seite weitergeben

Der Dritte darf abbrechen, verlangsamen, pausieren oder an Menschen verweisen. Dieses Nein ist kein Edge Case, sondern Teil der Produktethik.

6. Der aktuelle Wedge: Co-Founder und Geschäftspartner

Die ursprüngliche Vision ist breit: Paare, Familie, Freundschaften, Arbeit, Co-Founder. Der aktuelle Beta-Wedge ist enger:

Zwei Co-Founder oder Geschäftspartner, die in einem festgefahrenen strategischen Konflikt stecken.

Typische Konflikte:

• Pricing: Discount vs. Wert halten
• Hiring: Senior vs. zwei Junior-Rollen
• Pivot: SMB vertiefen vs. Enterprise gehen
• Governance: Wer entscheidet final?
• Equity / Vertrag / Exit: nicht in der App lösen, aber sauber in professionelle Klärung überführen
• Burnout / Kapazität: nicht "besser kommunizieren", sondern Belastungsgrenze und Vertretung klären

Warum dieser Wedge:

• Der Schmerz ist konkret und teuer.
• Zwei-Personen-Konflikte passen exakt zur Architektur.
• Co-Founder brauchen keine generische Empathie, sondern Entscheidungsklarheit.
• Zahlungsbereitschaft ist wahrscheinlicher als bei diffusen Alltagskonflikten.
• Das Produkt kann hier zeigen, dass "Mediation OS" mehr ist als nette Sprache.

Langfristig bleiben Partner, Familie, Freunde und Work-Konflikte relevante Beziehungstypen. Kurzfristig ist Co-Founder der stärkste Lernmarkt.

7. Die Haltung

Der Ton des Produkts ist kein Dekor. Er ist das Produkt.

Der Dritte arbeitet mit:

• Langsamkeit
• Klarheit
• Würde
• Neutralität
• konkreter Sprache
• transparenten Grenzen
• Respekt vor beiden Innenwelten

Der Dritte soll nicht beeindrucken. Er soll entlasten.

Der beste Output ist nicht die eleganteste Formulierung, sondern der Moment, in dem zwei Menschen wieder verstehen, worüber sie eigentlich sprechen.

8. Das Drei-Raum-Modell

Der Produktkern ist räumlich, nicht nur conversational.

stateDiagram-v2
  [*] --> Waiting: Room erstellen
  Waiting --> PrivateA: Person A startet privat
  PrivateA --> PrivateBoth: Person B tritt per Code bei
  PrivateBoth --> Ready: beide markieren sich bereit
  Ready --> Shared: gemeinsamer Raum
  Shared --> Paused: Pause
  Paused --> Shared: Fortsetzen
  Shared --> Closed: Abschluss
  Shared --> SafetyTerminated: Safety-Termination

Privater Raum

Jede Person spricht zunächst allein mit Der Dritte. Dort darf sie ungefiltert, ehrlich und noch nicht perfekt formuliert sein. Ziel ist nicht Performance, sondern Klärung.

Prinzip: Klarheit vor Kommunikation.

Gemeinsamer Raum

Erst wenn beide Seiten vorbereitet sind, entsteht ein gemeinsamer Raum. Der Dritte bringt nicht die privaten Rohtexte ein. Er bringt Essenzen ein: Bedürfnisse, Beobachtungen, gemeinsame Punkte, Widersprüche, nächste Schritte.

Prinzip: Verstehen vor Reaktion.

Essenzen

Essenzen sind der rote Faden. Sie halten fest, was im Konflikt sichtbar wurde, ohne die Beteiligten festzulegen. Sie sind Brücke, nicht Urteil.

Prinzip: Orientierung vor Entscheidung.

9. Das Mediation Operating System

Der aktuelle Produktstand ist bereits mehr als ein MVP-Chat. Der Kern liegt in supabase/functions/mediate/.

flowchart LR
  Client["Expo App"] --> Edge["Supabase Edge Function: mediate"]
  Edge --> Safety["Safety: Regex + LLM Classifier"]
  Safety --> Routing["Routing: Scope, Intensität, Beziehungstyp"]
  Routing --> Stage["Stage Routing: Private / Shared / Referral"]
  Stage --> Prompt["Prompt Builder"]
  Prompt --> LLM["OpenAI-kompatibler LLM Call"]
  LLM --> Guard["Output Guardrails"]
  Guard --> Persist["Postgres + RLS + Realtime"]
  Persist --> Client
  Persist --> Essence["GFK-Essenzkarten"]
  Persist --> Analytics["PostHog + Sentry"]

Aktuell implementierte Kernfähigkeiten:

10. Co-Founder Strategy Mediation

Für Co-Founder reicht "ich verstehe beide Seiten" nicht.

Der Dritte muss dort eine zweite Ebene beherrschen: strategische Entscheidungsarbeit. Das bedeutet nicht, Entscheidungen zu treffen. Es bedeutet, Entscheidbarkeit herzustellen.

Im Co-Founder-Modus soll Der Dritte sichtbar machen:

• worin beide übereinstimmen
• worin sie sich widersprechen
• ob der Konflikt eine Strategie-, Governance-, Kapazitäts-, Rechts-/Finanz- oder Exit-Frage ist
• welche Voraussetzung vor einer Entscheidung fehlt
• welcher kleine Schritt mit Owner, Zeitraum und Review sinnvoll ist
• wann der professionelle Rahmen wichtiger ist als weitere Chat-Mediation

flowchart TD
  A["Co-Founder-Konflikt"] --> B{"Konflikttyp"}
  B --> C["Strategie / Pricing / Pivot"]
  B --> D["Governance / Rollen"]
  B --> E["Kapazität / Burnout"]
  B --> F["Equity / Vertrag / Exit"]
  C --> G["Optionen, Kriterien, Owner, Review"]
  D --> H["Decision Rule als Arbeitsvereinbarung"]
  E --> I["Belastungsgrenze + Vertretung klären"]
  F --> J["Safe Frame: Fragenliste für Anwalt / Steuer / Advisor"]
  G --> K["Draft Next Step"]
  H --> K
  I --> K
  J --> L["Professioneller Rahmen"]

Das Co-Founder-Overlay übernimmt bewusst nur Vokabular und Denkmodelle aus Strategy OS. Es übernimmt keine fremde Codebasis. Die richtige Integration ist eine Spec-Ehe, keine Code-Ehe.

11. Sicherheit als Produktversprechen

Sicherheit ist nicht nur Compliance. Sicherheit ist Teil der Nutzererfahrung.

Der Dritte muss in drei Richtungen sicher sein:

1. Emotional sicher: keine Schuldzuweisungen, keine Eskalation, keine ungefilterten Rohtexte.
2. Fachlich sicher: keine Therapie-, Rechts-, Steuer-, Finanz- oder Vertragsberatung.
3. Systemisch sicher: keine Prompt-Injection, keine Datenschutzverletzung, keine RLS-Lecks.

flowchart TD
  M["Neue Nachricht"] --> R{"Unambiguous Safety Pattern?"}
  R -->|ja| S["Sofortige Eskalation / Hotline / Termination"]
  R -->|nein| L{"LLM Safety Classifier"}
  L -->|distress| P["Pause anbieten"]
  L -->|human_referral| H["Menschliche Hilfe empfehlen"]
  L -->|safe| B{"Boundary Pattern?"}
  B -->|Founder legal/finance/exit| F["Safe Frame + Fragenliste"]
  B -->|nein| O["Normale Mediation"]

Die App ist dann gut, wenn sie nicht alles in der App lösen will.

12. Sprache und Internationalität

Der Dritte ist mehrsprachig, weil Konflikte oft genau dort härter werden, wo Menschen in einer Zweitsprache über Gefühle sprechen müssen.

Die Produktthese:

Jeder spricht seine Sprache. Der Dritte vermittelt in der jeweils passenden Sprache.

Aktuell existieren 26 UI-Locale-Dateien. Die Mediation unterstützt bilingualen Output. Für Beta sind Deutsch und Englisch die Primärsprachen; weitere Sprachen sind Produktreichweite, aber vor Public Launch braucht die Safety-/Co-Founder-Sprache Native Review.

Mehrsprachigkeit ist kein Feature für später. Sie ist Teil des Kerns: Verständigung scheitert oft an Übersetzung, also muss das Produkt Übersetzung als Beziehungsschutz verstehen.

13. Geschäftsmodell

Der Dritte ist als B2C-Produkt gedacht, nicht als Enterprise-Workshop-Plattform.

Aktuelle Monetarisierungslogik:

• Token-Pakete für einzelne Mediationen
• Abos für regelmäßige Nutzung
• RevenueCat für iOS/Android Purchases
• Supabase-Wallet als Produkt- und Web-Fallback

Die Beta-Hypothese:

Wenn Co-Founder nach dem Onboarding in einem realen strategischen Konflikt einen klareren nächsten Schritt sehen, sind 5-10% der Onboarding-Completers bereit, für weitere Mediation zu zahlen.

Diese Zahl ist keine Wahrheit. Sie ist die Lernschwelle für die nächste Phase.

14. Warum jetzt

Klassische Mediation ist wertvoll, aber:

• teuer
• termingebunden
• oft zu spät im Konflikt
• für kleine, häufige Reibungen zu schwergewichtig

Coaching ist wertvoll, aber:

• nicht immer beidseitig
• nicht immer verfügbar
• oft auf Reflexion statt gemeinsamen Prozess ausgelegt

Generische KI ist mächtig, aber:

• hat keine Rollenbindung
• hat keine gemeinsame Raumarchitektur
• hat keine harte Mediationsethik
• kann zu viel sagen, wo sie stoppen müsste

Der Dritte wirkt vor der Eskalation, zwischen den Gesprächen und nach emotionalen Momenten. Er hält den Raum, bis Menschen ihn selbst wieder halten können.

15. North Star

Der North Star ist nicht "mehr Chat-Nachrichten".

Der North Star ist:

Zwei Menschen verlassen eine schwierige Unterhaltung mit mehr Klarheit, weniger Eskalation und einem kleinen nächsten Schritt, den beide als tragfähig erleben.

Mögliche Produktmetriken:

• Anteil Sessions mit konkretem Next Step
• Anteil Shared Rooms ohne Eskalation
• Zeit bis erste sinnvolle Essence
• Referral-Qualität bei Themen außerhalb der App
• Conversion von erstem echten Konflikt zu Erstkauf
• qualitative Beta-Rückmeldung: "Hat das geholfen, das Gespräch anders zu führen?"

Die wichtigste Anti-Metrik:

Nutzer fühlen sich zwar verstanden, aber der eigentliche Konflikt bleibt unverändert diffus.

Der Dritte darf warm sein. Er darf aber nicht nur trösten.

16. Roadmap-Logik

flowchart LR
  A["Phase 1: Diagnose + Compliance"] --> B["Phase 2: Pre-Beta-Härtung"]
  B --> C["Phase 3: Co-Founder Beta"]
  C --> D["Phase 4: Public Launch"]
  D --> E["Phase 5+: Provider, TMS, Eval, Group Mediation"]

Jetzt

• Compliance und Store-Readiness fertigstellen
• Co-Founder Schnitt C2 umsetzen: Boundary-Follow-up UX und Health-Capacity Classifier
• RevenueCat-/Webhook-/PostHog-Produktionschecks abschließen
• Beta-Recruiting für Co-Founder/Geschäftspartner vorbereiten

Beta

• Fokus auf reale Co-Founder-Konflikte, nicht weitere synthetische Audits
• Lernen, ob Two-Room + Strategy Overlay als Demo und realer Konfliktfluss trägt
• Messen, ob Nutzer nach einer echten Klärung zahlen
• Herausfinden, wo die App stoppen muss, ohne nutzlos zu wirken

Launch

• Native Review für Safety- und Co-Founder-Sprache
• Privacy/ToS/App-Store-Risiken schließen
• Funnel und Observability stabilisieren
• App-Store- und Web-Positionierung auf den stärksten Wedge zuschneiden

Später

• Prompt-Eval-Framework statt Bauchgefühl
• TMS und i18n-Qualitätssicherung
• Multi-Provider-LLM-Abstraktion
• Group Mediation
• Handoff-Protokolle zu menschlichen Mediatoren, Coaches, Anwälten oder Therapeut:innen

17. Produktprinzipien

1. Klarheit vor Kommunikation. Kein gemeinsamer Raum, bevor beide Seiten zumindest eine erste eigene Sortierung haben.
2. Essenz statt Rohtext. Der Dritte überträgt nicht private Verletzung, sondern formuliert die brauchbare Struktur dahinter.
3. Langsamer ist oft sicherer. Async ist kein Downgrade, sondern Schutz.
4. Grenzen sind Feature, nicht Mangel. Eine gute Mediation weiß, wann sie keine Mediation mehr sein darf.
5. Neutral heißt nicht flach. Der Dritte darf klar benennen, was strukturell sichtbar ist.
6. Keine Lösung ohne Owner. Besonders im Co-Founder-Modus braucht jeder nächste Schritt Verantwortlichkeit, Zeitraum und Review.
7. Der Mensch entscheidet. Das System hält Rahmen, Sprache und Orientierung; die Entscheidung bleibt bei den Beteiligten.

18. Einordnung in einen Satz

Der Dritte ist die App für den Moment, in dem zwei Menschen noch miteinander wollen, aber nicht mehr gut miteinander können.

Sie gibt ihnen keinen Richter. Sie gibt ihnen keinen Therapeuten. Sie gibt ihnen einen Dritten.

Leise. Wohlwollend. Nicht perfekt. Aber hilfreich.

Der Dritte

Hinweis: Dieses Dokument ist ein deploybarer Fallback aus dem Contributors-Projektprofil. Sobald eine Projektquelle README, Vision oder Architektur liefert, wird sie hier bevorzugt gerendert.

Audit Snapshot

Der Dritte gibt Geschäftspartnern einen gemeinsamen Klärungsraum, bevor Konflikte eskalieren oder verdrängt werden.

Reifegrad

• Vorhanden: Web-App, MVP-Flow, Shared-Chat-Visual, klare Zielgruppe und Konfliktlogik.
• Fehlt: Beta-Plan, Privacy-Review, Store-Submission-Erfahrung, Native-Speaker-Prüfung.

Lead Ask

Beta-Test-Koordinator/in: Mediator/in oder Coach mit GFK/NVC-Verständnis, der eine kleine Beta mit Co-Founder-Teams strukturiert, schützt und auswertet.