Implement lover relationship management features: Add endpoints for creating, acknowledging, and managing lover relationships in the FalukantController. Enhance backend models with RelationshipState for tracking relationship statuses. Update frontend components to display and manage lover details, including marriage satisfaction and household tension. Improve localization for new features in multiple languages.

2026-03-20 11:37:46 +01:00
parent c7d33525ff
commit 2977b152a2
29 changed files with 4551 additions and 86 deletions
--- a/docs/FALUKANT_LOVERS_CONCEPT.md
+++ b/docs/FALUKANT_LOVERS_CONCEPT.md
@@ -115,9 +115,6 @@ Jede Liebhaber-Beziehung sollte mindestens diese Werte tragen:
 - `statusFit`: passt die Beziehung zum Stand der Spielfigur
 - `householdTension`: Spannungen im eigenen Haus
 - `scandalRisk`: Risiko für Gerüchte, Erpressung oder Entdeckung
-
-Optional später:
-
 - `fertilityRisk`
 - `politicalValue`
 - `churchOffense`
--- a/docs/FALUKANT_LOVERS_DAEMON_HANDOFF.md
+++ b/docs/FALUKANT_LOVERS_DAEMON_HANDOFF.md
@@ -0,0 +1,263 @@
+# Falukant: Übergabedokument für den externen Daemon
+
+## Zweck
+
+Dieses Dokument ist die technische Übergabe an den externen Daemon, der nicht Teil dieses Projekts ist.
+
+Es beschreibt:
+
+- welche Daten der Daemon lesen muss
+- welche Regeln er anwenden soll
+- welche Felder er zurückschreiben muss
+- welche Ereignisse und Nebenwirkungen erwartet werden
+
+Die fachlichen Regeln selbst stehen in:
+
+- [FALUKANT_LOVERS_DAEMON_SPEC.md](/mnt/share/torsten/Programs/YourPart3/docs/FALUKANT_LOVERS_DAEMON_SPEC.md)
+
+Die lokale technische Datenbasis dieses Projekts steht in:
+
+- [FALUKANT_LOVERS_TECHNICAL_CONCEPT.md](/mnt/share/torsten/Programs/YourPart3/docs/FALUKANT_LOVERS_TECHNICAL_CONCEPT.md)
+
+## Architekturgrenze
+
+Wichtig:
+
+- dieses Backend hält die Datenstruktur und liefert Family-/UI-Daten
+- der eigentliche Tick-Lauf für Kosten, Ansehen, Ehezufriedenheit und Kinder passiert im externen Daemon
+- der externe Daemon ist damit zuständig für die periodische Spiellogik
+
+Dieses Projekt ist nicht zuständig für:
+
+- die Scheduler-Ausführung
+- Tick-Zeitpunkte
+- operative Daemon-Laufzeit
+
+## Datenquelle
+
+Der externe Daemon arbeitet auf folgenden Tabellen:
+
+- `falukant_data.relationship`
+- `falukant_data.relationship_state`
+- `falukant_data.character`
+- `falukant_data.child_relation`
+- `falukant_data.falukant_user`
+- `falukant_type.relationship`
+- `falukant_type.title`
+
+Optional später:
+
+- Notification-Tabellen
+- Frömmigkeits- oder Kirchen-bezogene Tabellen
+
+## Mindestdatensatz pro Tick
+
+Für jede aktive Liebschaft muss der Daemon laden:
+
+- `relationship.id`
+- `relationship.character1_id`
+- `relationship.character2_id`
+- `relationship_type.tr`
+- `relationship_state.lover_role`
+- `relationship_state.affection`
+- `relationship_state.visibility`
+- `relationship_state.discretion`
+- `relationship_state.maintenance_level`
+- `relationship_state.status_fit`
+- `relationship_state.monthly_base_cost`
+- `relationship_state.months_underfunded`
+- `relationship_state.active`
+- `relationship_state.acknowledged`
+- `relationship_state.last_daily_processed_at`
+- `relationship_state.last_monthly_processed_at`
+
+Zusätzlich pro beteiligter Figur:
+
+- `character.id`
+- `character.user_id`
+- `character.gender`
+- `character.birthdate`
+- `character.reputation`
+- `character.title_of_nobility`
+
+Zusätzlich für Geld:
+
+- `falukant_user.id`
+- `falukant_user.money`
+
+Zusätzlich für Ehekontext:
+
+- aktive Beziehung vom Typ `married`, `engaged` oder `wooing`
+- `relationship_state.marriage_satisfaction`
+
+Zusätzlich für Kinderprüfung:
+
+- bestehende `child_relation` für dieselben Eltern
+
+## Pflichtlogik Daily Tick
+
+Der externe Daemon muss täglich:
+
+1. Sichtbarkeit anpassen
+2. Diskretion anpassen
+3. Ehezufriedenheit anpassen
+4. Ansehen anpassen
+5. Skandalchance prüfen
+6. Zustände speichern
+7. optionale Benachrichtigung oder Log-Einträge erzeugen
+
+### Daily Input
+
+- alle aktiven `lover`-Beziehungen
+- zugehörige Ehebeziehung, falls vorhanden
+- Standesgruppe
+- das jüngere Alter der beiden Beteiligten `minAge`
+
+### Daily Output
+
+Rückzuschreiben:
+
+- `relationship_state.visibility`
+- `relationship_state.discretion`
+- `relationship_state.marriage_satisfaction` der Ehebeziehung
+- `character.reputation`
+- `relationship_state.last_daily_processed_at`
+
+Optional:
+
+- Notification
+- Ereignislog
+
+## Pflichtlogik Monthly Tick
+
+Der externe Daemon muss monatlich:
+
+1. Monatskosten berechnen
+2. Geld abbuchen
+3. Unterversorgung behandeln
+4. Kinderchance prüfen
+5. ggf. Kind anlegen
+6. Folgen auf Ansehen und Ehe anwenden
+7. Zustände speichern
+
+### Monthly Output
+
+Rückzuschreiben:
+
+- `falukant_user.money`
+- Geldfluss-Log
+- `relationship_state.months_underfunded`
+- `relationship_state.affection`
+- `relationship_state.discretion`
+- `relationship_state.visibility`
+- `relationship_state.last_monthly_processed_at`
+- ggf. `child_relation`
+- ggf. neuer Kind-Charakter
+
+## Formeln
+
+Die verbindlichen Regeln und Formeln kommen aus:
+
+- [FALUKANT_LOVERS_DAEMON_SPEC.md](/mnt/share/torsten/Programs/YourPart3/docs/FALUKANT_LOVERS_DAEMON_SPEC.md)
+
+Der externe Daemon soll insbesondere exakt übernehmen:
+
+- Standesgruppen
+- Monatskostenformel
+- Unterversorgungsfolgen
+- Ehezufriedenheitslogik
+- Reputationslogik
+- Altersmalus bei zu jungen Liebschaften
+- Sichtbarkeits- und Diskretionslogik
+- Skandalchance
+- Kinderwahrscheinlichkeit
+
+## Idempotenz
+
+Der externe Daemon muss idempotent arbeiten.
+
+Pflicht:
+
+- Daily Tick nie zweimal für denselben Ingame-Tag auf dieselbe Beziehung anwenden
+- Monthly Tick nie zweimal für denselben Ingame-Monat auf dieselbe Beziehung anwenden
+
+Pflichtfelder dafür:
+
+- `last_daily_processed_at`
+- `last_monthly_processed_at`
+
+## Transaktionsanforderungen
+
+Folgende Monthly-Vorgänge müssen atomar laufen:
+
+- Geldabbuchung
+- Statusänderung der Liebschaft
+- Kind-Erzeugung
+- Folgeänderung an Ansehen oder Ehe
+
+Empfehlung:
+
+- pro verarbeiteter Beziehung eine DB-Transaktion
+
+## Kind-Erzeugung
+
+Bei erfolgreicher Monatsprüfung auf Kind:
+
+1. neues Kind in `falukant_data.character` anlegen
+2. neue `child_relation` anlegen
+3. Felder setzen:
+   - `birth_context = lover`
+   - `legitimacy = hidden_bastard`
+   - `public_known = false`
+
+Wenn der Daemon Kinder nicht selbst anlegen soll, muss er stattdessen ein klar definiertes Create-Event an dieses Backend oder an ein anderes Backend-Modul senden. Standardempfehlung ist aber direkte DB-Erzeugung im Daemon.
+
+## Gleichbehandlung der Geschlechter
+
+Der externe Daemon muss dieselben Regeln für männliche und weibliche Spielfiguren anwenden.
+
+Das betrifft:
+
+- Kosten
+- Reputationswirkung
+- Ehezufriedenheit
+- Skandalrisiko
+- Status- und Sichtbarkeitslogik
+
+Unterschiedlich ist nur die biologische Kinderentstehung im aktuellen Modell.
+
+## Was dieses Backend dafür bereitstellt
+
+Dieses Projekt stellt aktuell bereit:
+
+- Datenstruktur für `relationship_state`
+- Datenstruktur für `child_relation`-Erweiterungen
+- Family-API mit lesbaren Zuständen
+
+Später kann dieses Backend zusätzlich bereitstellen:
+
+- Komfort-Endpunkte für Lover-Aktionen
+- Admin-/Debug-Ansichten
+- eventuelle Helper-Endpoints für den Daemon
+
+## Erwartete externe Deliverables
+
+Damit die externe Daemon-Umsetzung vollständig ist, werden dort mindestens benötigt:
+
+1. Daily-Tick-Job
+2. Monthly-Tick-Job
+3. SQL- oder ORM-Zugriff auf die Falukant-Tabellen
+4. saubere Transaktionslogik
+5. Schutz gegen doppelte Verarbeitung
+6. Logging oder Monitoring für Tick-Fehler
+
+## Definition of Done für die Übergabe
+
+Die Übergabe an den externen Daemon gilt als vollständig, wenn:
+
+1. Datenfelder und Tabellen eindeutig definiert sind
+2. Daily- und Monthly-Inputs beschrieben sind
+3. Daily- und Monthly-Outputs beschrieben sind
+4. die verbindliche Fachlogik referenziert ist
+5. Idempotenz- und Transaktionsanforderungen klar sind
+6. Kinder aus Liebschaften technisch beschrieben sind
--- a/docs/FALUKANT_LOVERS_DAEMON_SPEC.md
+++ b/docs/FALUKANT_LOVERS_DAEMON_SPEC.md
@@ -0,0 +1,775 @@
+# Falukant: Daemon-Spezifikation für Liebhaber, Mätressen, Ehezufriedenheit und uneheliche Kinder
+
+## Zweck
+
+Dieses Dokument beschreibt die konkrete Server- und Daemon-Logik für außereheliche Beziehungen im Familiensystem von Falukant. Es ergänzt das Grundkonzept in [FALUKANT_LOVERS_CONCEPT.md](/mnt/share/torsten/Programs/YourPart3/docs/FALUKANT_LOVERS_CONCEPT.md) um exakte Regeln für:
+
+- laufende Kosten
+- laufende Änderungen von Ansehen
+- neues System `Ehe-Zufriedenheit`
+- standesabhängige Wirkung von Ehe und Liebschaften
+- mögliche Kinder aus Liebschaften
+- gendergleiche Behandlung im Regelwerk
+
+Das Dokument ist bewusst daemon-orientiert, also als Grundlage für periodische Verarbeitung im Backend.
+
+## Bewusst vertagte Themen
+
+Zwei Themen werden in dieser Spezifikation ausdrücklich nur vorgemerkt und nicht in die erste Umsetzung gezogen:
+
+### Dienerschaft
+
+`Dienerschaft` ist ein interessanter späterer Ausbau, weil sie gut zu Diskretion, Repräsentation, Hausstand und Kosten passt. Für die erste Version wird sie jedoch nicht als eigenes System modelliert.
+
+Für Phase 1 gilt deshalb:
+
+- Dienerschaft ist nur indirekt in den Unterhaltskosten enthalten
+- keine eigenen Diener-Slots, Rollen oder Haushaltsobjekte
+- keine gesonderte Interaktion mit Heimlichkeit oder Hofstatus
+
+Später kann daraus ein eigenes Hausstands- oder Hofsystem entstehen.
+
+### Balancing
+
+Die in diesem Dokument genannten Zahlen sind Regelrahmen für die technische Umsetzung, nicht finale Produktionswerte.
+
+Für Phase 1 gilt deshalb:
+
+- Formeln und relative Verhältnisse sind wichtiger als absolute Zahlen
+- Kosten-, Ansehens- und Zufriedenheitswerte werden später nach realen Spieltests feinjustiert
+- Balancing ist eine eigene Nachphase und kein Blocker für die erste technische Integration
+
+## Leitprinzipien
+
+### 1. Gleichbehandlung der Geschlechter
+
+Die Regeln für Ansehen, Ehezufriedenheit, Unterhalt, Skandal und soziale Bewertung gelten für männliche und weibliche Spielfiguren gleich.
+
+Das heißt:
+
+- dieselbe Beziehungsform erzeugt dieselben Grundkosten
+- dieselbe Sichtbarkeit erzeugt dieselben Reputationsfolgen
+- dieselbe Standeslage erzeugt dieselben Modifikatoren
+- dieselbe Untreue erzeugt dieselbe Wirkung auf die Ehe
+
+Biologische Unterschiede betreffen nur die Frage, ob aus einer konkreten Paarung natürlich ein Kind entstehen kann. Die soziale und spielmechanische Behandlung bleibt gleich.
+
+### 2. Stand vor Moral
+
+Das System bewertet nicht abstrakt „Treue“ oder „Untreue“, sondern:
+
+- wie geordnet die Situation ist
+- wie standesgemäß sie geführt wird
+- wie sichtbar sie ist
+- ob Ehe, Haus und Erbfolge destabilisiert werden
+
+### 2a. Zu jung ist reputationsschädlich
+
+Sehr junge Liebschaften sollen im Daemon nie neutral behandelt werden.
+
+Das heißt:
+
+- eine Beziehung kann technisch erlaubt sein
+- sie kann aber trotzdem das Ansehen zusätzlich belasten
+- dieser Malus kommt zusätzlich zu Sichtbarkeit, Skandal und Stand
+- der Altersmalus gilt geschlechtsunabhängig
+
+### 3. Daemon statt Einmal-Effekt
+
+Kosten, Ehezufriedenheit, Sichtbarkeit und Ansehen werden nicht nur beim Anlegen oder Beenden einer Beziehung verändert, sondern laufend im Daemon fortgeschrieben.
+
+## Bestehende Anknüpfungspunkte
+
+Das System passt auf die vorhandenen Strukturen:
+
+- Beziehungen werden bereits über `Relationship` geführt in [relationship.js](/mnt/share/torsten/Programs/YourPart3/backend/models/falukant/data/relationship.js)
+- Kinder werden bereits über `ChildRelation` geführt in [child_relation.js](/mnt/share/torsten/Programs/YourPart3/backend/models/falukant/data/child_relation.js)
+- Ansehen ist bereits auf dem Charakter vorhanden in [character.js](/mnt/share/torsten/Programs/YourPart3/backend/models/falukant/data/character.js)
+- Stand ist bereits über `titleOfNobility` abbildbar in [title_of_nobility.js](/mnt/share/torsten/Programs/YourPart3/backend/models/falukant/type/title_of_nobility.js)
+- `lover` ist bereits ein vorhandener Beziehungstyp
+
+## Neue Spielwerte
+
+## A. Pro Spielfigur: Ehezufriedenheit
+
+Neuer Charakter- oder Ehewert:
+
+- `marriageSatisfaction`
+- Wertebereich `0..100`
+- Standardwert bei frischer Ehe: `55`
+
+Interpretation:
+
+- `0..19`: offene Ehekrise
+- `20..39`: stark belastet
+- `40..59`: angespannt bis normal
+- `60..79`: stabil
+- `80..100`: sehr stabil
+
+Wichtig:
+
+- Ehezufriedenheit gehört zur Ehebeziehung, nicht zur Person allein.
+- Technisch ist dafür eine eigene Beziehungstabelle oder eine Erweiterung der Ehe-`Relationship` sinnvoll.
+- Für eine erste Version kann der Wert aber auf der Ehebeziehung gespeichert werden.
+
+## B. Pro Liebhaber-Beziehung
+
+Für jede Beziehung vom Typ `lover` werden zusätzliche Felder benötigt.
+
+Pflichtfelder:
+
+- `loverRole`
+  - `secret_affair`
+  - `lover`
+  - `mistress_or_favorite`
+- `affection`
+  - `0..100`
+- `visibility`
+  - `0..100`
+- `discretion`
+  - `0..100`
+- `maintenanceLevel`
+  - `0..100`
+- `statusFit`
+  - `-2..2`
+- `monthlyBaseCost`
+  - integer
+- `active`
+  - boolean
+- `acknowledged`
+  - boolean
+- `exclusive`
+  - boolean optional
+
+Abgeleitete, nicht zwingend gespeicherte Werte:
+
+- `monthlyTotalCost`
+- `reputationDeltaDaily`
+- `marriageDeltaDaily`
+- `scandalRiskDaily`
+- `pregnancyChanceMonthly`
+
+## C. Optionaler Kinderwert
+
+Für Kinder aus Liebschaften wird kein neues Kindmodell benötigt. `ChildRelation` reicht, benötigt aber zusätzlich:
+
+- `legitimacy`
+  - `legitimate`
+  - `acknowledged_bastard`
+  - `hidden_bastard`
+- `birthContext`
+  - `marriage`
+  - `lover`
+- `publicKnown`
+  - boolean
+
+## Standesgruppen
+
+Für alle Daemon-Berechnungen werden Adelstitel auf vier Gruppen verdichtet:
+
+### Gruppe 0: niedrige Stände
+
+- `noncivil`
+- `civil`
+- `sir`
+
+### Gruppe 1: wohlhabende Bürger und lokale Oberschicht
+
+- `townlord`
+- `by`
+- `landlord`
+
+### Gruppe 2: niederer und mittlerer Adel
+
+- `knight`
+- `baron`
+- `count`
+- `palsgrave`
+- `margrave`
+- `landgrave`
+
+### Gruppe 3: hoher Adel und Herrschaft
+
+- `ruler`
+- `elector`
+- `imperial-prince`
+- `duke`
+- `grand-duke`
+- `prince-regent`
+- `king`
+
+Diese Gruppen steuern:
+
+- Toleranz gegenüber sichtbaren Liebschaften
+- erforderliches Unterhaltsniveau
+- Wirkung auf Ehezufriedenheit
+- Strafe bei Skandal
+
+## Taktung im Daemon
+
+Empfohlene Verarbeitung:
+
+- `daily tick`: alle 24 Ingame-Stunden
+- `monthly tick`: alle 30 Ingame-Tage
+
+Aufteilung:
+
+### Daily Tick
+
+- Sichtbarkeit und Diskretion anpassen
+- Ehezufriedenheit anpassen
+- Ansehen anpassen
+- Skandalrisiko prüfen
+- Ereignisse auslösen
+
+### Monthly Tick
+
+- Unterhaltskosten abbuchen
+- Beziehungskosten neu berechnen
+- Kinderchance prüfen
+- Statuswechsel prüfen
+
+## Kostenmodell
+
+## 1. Grundkosten pro Monat
+
+### secret_affair
+
+- Basis: `10`
+
+### lover
+
+- Basis: `30`
+
+### mistress_or_favorite
+
+- Basis: `80`
+
+Diese Werte sind Ingame-Basiswerte und sollen relativ zu Falukant-Geldwerten noch feinjustiert werden.
+
+## 2. Standesmultiplikator
+
+### Gruppe 0
+
+- `x 1.0`
+
+### Gruppe 1
+
+- `x 1.6`
+
+### Gruppe 2
+
+- `x 2.6`
+
+### Gruppe 3
+
+- `x 4.0`
+
+Begründung:
+
+- Höhere Stände können sich die Beziehung leisten.
+- Gleichzeitig muss sie teurer sein, weil „standesgemäß“ mehr Aufwand verlangt.
+
+## 3. Unterhaltsfaktor
+
+`maintenanceFactor = 0.6 + (maintenanceLevel / 100) * 1.2`
+
+Beispiele:
+
+- `0` => `0.6`
+- `50` => `1.2`
+- `100` => `1.8`
+
+Niedrige Versorgung spart kurzfristig Geld, erhöht aber später Sichtbarkeit, Unzufriedenheit und Skandalrisiko.
+
+## 4. Status-Fit-Kosten
+
+Wenn `statusFit < 0`, steigen Kosten für Diskretion und Konfliktpflege:
+
+- `statusFit = -1` => `+15 %`
+- `statusFit = -2` => `+35 %`
+
+## 5. Monatsformel
+
+`monthlyTotalCost = round(baseCost * rankMultiplier * maintenanceFactor * statusFitModifier)`
+
+## 6. Folgen bei Nichtzahlung
+
+Wenn der Monatsbetrag nicht vollständig gezahlt werden kann:
+
+- `affection -8`
+- `discretion -6`
+- `visibility +8`
+- `marriageSatisfaction -4` falls verheiratet
+- `reputation -1` sofort, falls `visibility >= 40`
+
+Bei zwei aufeinanderfolgenden Monaten Unterversorgung:
+
+- tägliches Skandalrisiko zusätzlich `+2 %`
+
+## Ehezufriedenheit: Grundmodell
+
+## 1. Basistendenz pro Tag
+
+Jede bestehende Ehe bewegt sich täglich leicht Richtung `55`, wenn keine besonderen Faktoren wirken.
+
+Formel:
+
+- wenn `marriageSatisfaction > 55`: `-1` alle 3 Tage
+- wenn `marriageSatisfaction < 55`: `+1` alle 5 Tage
+
+So bleiben Ehen nicht dauerhaft extrem, wenn nichts passiert.
+
+## 2. Modifikatoren durch Liebschaften
+
+Nur wenn eine aktive Ehe und mindestens eine aktive Liebschaft existiert.
+
+### Gruppe 0
+
+- heimliche Liebschaft: `-1` pro Tag
+- lover: `-2` pro Tag
+- Mätresse/Favorit: `-3` pro Tag
+
+### Gruppe 1
+
+- heimliche Liebschaft: `-1` pro Tag
+- lover: `-1` pro Tag
+- Mätresse/Favorit: `-2` pro Tag
+
+### Gruppe 2
+
+- heimliche Liebschaft: `0 bis -1` pro Tag
+- lover: `-1` pro Tag
+- Mätresse/Favorit: `-1` pro Tag
+
+### Gruppe 3
+
+- heimliche Liebschaft: `0`
+- lover: `0`
+- Mätresse/Favorit: `+1 / 0 / -1` je nach Ordnung
+
+Für Gruppe 3 gilt:
+
+- `+1`, wenn:
+  - `visibility <= 35`
+  - `maintenanceLevel >= 65`
+  - `marriageSatisfaction >= 45`
+  - nur eine aktive Mätresse/Favorit vorhanden
+- `0`, wenn die Lage geordnet, aber nicht positiv ist
+- `-1`, wenn die Beziehung sichtbar Unruhe erzeugt
+
+Das bildet den gewünschten Spezialfall ab:
+
+- Bei einem König kann eine diskrete, geordnete Nebenbeziehung die Ehe sogar entlasten oder stabilisieren.
+- Dieselbe Lage kippt ins Negative, wenn sie chaotisch oder öffentlich demütigend wird.
+
+## 3. Zusätzliche Ehemodifikatoren
+
+### Positive Faktoren
+
+- Ehepartner regelmäßig beschenkt: `+1` pro Tag für 5 Tage
+- großes Fest oder Hochzeitspflege: `+2..+5` einmalig
+- keine aktive Liebschaft und hohe Versorgung des Hauses: `+1` alle 4 Tage
+
+### Negative Faktoren
+
+- sichtbare Liebschaft `visibility >= 60`: `-2` pro Tag
+- Liebschaft mit `minAge <= 15`: zusätzlich `-1` pro Tag
+- Kind aus Liebschaft wird bekannt: `-8` einmalig
+- zwei oder mehr aktive Liebschaften: `-2` pro Tag zusätzlich
+- Unterhaltsausfall bei Mätresse/Favorit: `-1` pro Tag
+
+## Ansehen: Grundmodell
+
+Ansehen wird im Daily Tick pro aktiver Liebschaft angepasst.
+
+## 1. Basiswert pro Beziehungsform
+
+### secret_affair
+
+- `-0.2` pro Tag
+
+### lover
+
+- `-0.4` pro Tag
+
+### mistress_or_favorite
+
+- `-0.6` pro Tag
+
+Diese Werte sind Rohwerte vor Modifikatoren.
+
+## 2. Sichtbarkeitsfaktor
+
+`visibilityFactor = 0.4 + (visibility / 100) * 1.6`
+
+Beispiele:
+
+- `0` => `0.4`
+- `50` => `1.2`
+- `100` => `2.0`
+
+## 3. Standesmodifikator auf Reputationsverlust
+
+### Gruppe 0
+
+- `x 1.8`
+
+### Gruppe 1
+
+- `x 1.3`
+
+### Gruppe 2
+
+- `x 1.0`
+
+### Gruppe 3
+
+- `x 0.7`
+
+Aber:
+
+- bei Gruppe 3 gilt nur dann `0.7`, wenn die Beziehung geordnet ist
+- bei Skandal, Erbfolgedruck oder offener Demütigung springt Gruppe 3 auf `1.5`
+
+## 4. Ordnungsbonus
+
+Wenn alle Bedingungen erfüllt sind:
+
+- `maintenanceLevel >= 65`
+- `discretion >= 60`
+- `visibility <= 35`
+- maximal eine aktive Mätresse/Favorit
+
+dann:
+
+- Gruppe 2: `+0.1` Ansehen pro Tag statt Malus bei `mistress_or_favorite`
+- Gruppe 3: `+0.2` Ansehen pro Tag statt Malus bei `mistress_or_favorite`
+
+Das repräsentiert:
+
+- geordneten Überfluss
+- höfische Attraktivität
+- kontrollierte Nebenbeziehung ohne Hauschaos
+
+Für `secret_affair` und normalen `lover` gibt es keinen positiven Reputationswert.
+
+## 5. Tagesformel
+
+`dailyReputationDelta = baseValue * visibilityFactor * rankModifier`
+
+Dann:
+
+- Ordnungsbonus anwenden, falls aktiv
+- auf `[-3, +1]` pro Tag je Beziehung begrenzen
+
+## 5a. Altersmalus bei zu jungen Liebschaften
+
+Zusätzlich zur normalen Reputationsformel wird ein eigener Altersmalus berechnet.
+
+Grundlage ist immer das jüngere Alter der beiden Beteiligten:
+
+- `minAge <= 13`: `ageReputationDelta = -1.5` pro Tag
+- `minAge <= 15`: `ageReputationDelta = -0.8` pro Tag
+- `minAge <= 17`: `ageReputationDelta = -0.3` pro Tag
+- `minAge >= 18`: `ageReputationDelta = 0`
+
+Dann gilt:
+
+`finalDailyReputationDelta = dailyReputationDelta + ageReputationDelta`
+
+Zusatzregel:
+
+- wenn `minAge <= 15` und `visibility >= 50`, zusätzlicher Malus `-0.5` pro Tag
+
+Damit gilt dann:
+
+`finalDailyReputationDelta = dailyReputationDelta + ageReputationDelta + visibilityYoungPenalty`
+
+Interpretation:
+
+- junge Beziehungen sind schon im privaten Bereich reputationsschädlich
+- sichtbare junge Beziehungen schaden noch stärker
+- der Malus kommt zusätzlich zu allen übrigen Skandal- und Sichtbarkeitsfolgen
+
+## 6. Harte Malus-Ereignisse
+
+Zusätzliche Einmal-Effekte:
+
+- öffentliches Gerücht: `-3`
+- kirchlicher Tadel: `-5`
+- bekanntes Kind aus Liebschaft: `-6`
+- Erbfolgestreit durch uneheliches Kind: `-10`
+- zwei sichtbare Liebschaften gleichzeitig: `-4`
+
+## Sichtbarkeit und Diskretion
+
+Diese Werte verändern sich täglich.
+
+## Sichtbarkeit + pro Tag
+
+- `+1`, wenn `maintenanceLevel < 35`
+- `+1`, wenn `affection < 30`
+- `+2`, wenn `statusFit = -2`
+- `+1`, wenn bereits ein Ehekonflikt aktiv ist
+
+## Sichtbarkeit - pro Tag
+
+- `-1`, wenn `discretion >= 60`
+- `-1`, wenn `maintenanceLevel >= 70`
+
+## Diskretion + pro Tag
+
+- `+1`, wenn `maintenanceLevel >= 70`
+
+## Diskretion - pro Tag
+
+- `-1`, wenn `maintenanceLevel < 35`
+- `-1`, wenn `visibility > 60`
+
+Beide Werte bleiben in `0..100`.
+
+## Skandalrisiko
+
+Tägliche Grundchance:
+
+`baseScandalChance = 1 %`
+
+Modifikatoren:
+
+- `+ visibility / 25`
+- `+2 %`, wenn verheiratet
+- `+2 %`, wenn `statusFit = -2`
+- `+3 %`, wenn `maintenanceLevel < 25`
+- `+3 %`, wenn zwei oder mehr aktive Liebschaften bestehen
+- `+6 %`, wenn `minAge <= 13`
+- `+3 %`, wenn `minAge <= 15`
+- `+1 %`, wenn `minAge <= 17`
+- `-2 %`, wenn `discretion >= 75`
+- `-2 %`, wenn Gruppe 3 und Beziehung geordnet als Mätresse/Favorit geführt wird
+
+Deckel:
+
+- Minimum `0 %`
+- Maximum `25 %` pro Tag
+
+Mögliche Ereignisse:
+
+- Gerücht
+- Ehekrach
+- Forderung nach höherem Unterhalt
+- kirchlicher Tadel
+- Erpressung
+- Kind wird bekannt
+
+## Kinder aus Liebschaften
+
+## 1. Grundsatz
+
+Kinder aus Liebschaften sind möglich.
+
+Sie sollen:
+
+- nicht die Ehe ersetzen
+- das Familiensystem erweitern
+- vor allem bei höheren Ständen politische und soziale Reibung erzeugen
+
+## 2. Technische Bedingung
+
+Im aktuellen biologischen Modell nur bei gegengeschlechtlicher Paarung.
+
+Die soziale Behandlung bleibt gleich:
+
+- weibliche und männliche Spielfiguren erzeugen dieselben Ansehens- und Ehefolgen
+- das System bewertet nicht unterschiedlich nach Geschlecht
+
+## 3. Monatschance auf Kind
+
+Nur wenn:
+
+- Beziehung aktiv ist
+- beide Figuren im fruchtbaren Altersbereich sind
+- `affection >= 45`
+- `maintenanceLevel >= 30`
+- kein Sperrstatus aktiv
+
+Empfohlene Monatswahrscheinlichkeit:
+
+### secret_affair
+
+- `2 %`
+
+### lover
+
+- `4 %`
+
+### mistress_or_favorite
+
+- `6 %`
+
+Modifikatoren:
+
+- `+2 %`, wenn `affection >= 75`
+- `-2 %`, wenn `visibility >= 70` und Beziehung instabil ist
+- `-3 %`, wenn eine Figur deutlich über den Fruchtbarkeitsgrenzen liegt
+
+Deckel:
+
+- Minimum `0 %`
+- Maximum `12 %`
+
+## 4. Status des Kindes
+
+Bei Geburt aus Liebschaft:
+
+- `birthContext = lover`
+- `legitimacy = hidden_bastard` standardmäßig
+
+Wenn die Spielfigur das Kind anerkennt:
+
+- `legitimacy = acknowledged_bastard`
+- `publicKnown = true`
+
+Das Kind darf nicht automatisch Erbe werden.
+
+Nur explizite spätere Sonderregeln dürfen Erbfolgedruck erzeugen.
+
+## 5. Folgen eines Kindes aus Liebschaft
+
+### Sofortfolgen
+
+- `marriageSatisfaction -8`
+- `reputation -4`
+
+### Wenn öffentlich bekannt
+
+- Gruppe 0: zusätzlich `-4`
+- Gruppe 1: zusätzlich `-5`
+- Gruppe 2: zusätzlich `-6`
+- Gruppe 3: zusätzlich `-8`
+
+### Wenn Kind anerkannt wird
+
+- laufende Monatskosten `+20..+80` je Stand
+- zusätzliche Ereignisse zu Versorgung, Namen und Status
+
+## Standesabhängigkeit der Ehe
+
+Die Ehe darf nicht in allen Ständen gleich funktionieren.
+
+## Gruppe 0
+
+- Ehe ist vor allem ökonomische Stabilität
+- Liebschaften belasten den Haushalt direkt
+- Ehezufriedenheit reagiert stark negativ
+
+## Gruppe 1
+
+- Ehe ist Haus- und Rufgemeinschaft
+- diskrete Affären sind denkbar, aber riskant
+- sichtbare Liebschaften schaden deutlich
+
+## Gruppe 2
+
+- Ehe ist Hauspolitik und Nachfolgeordnung
+- Mätressen können vorkommen, aber nur kontrolliert
+- Ehezufriedenheit reagiert weniger moralisch, stärker auf öffentliche Ordnung
+
+## Gruppe 3
+
+- Ehe ist Dynastie, Bündnis und Hofordnung
+- eine diskrete Mätresse/Favorit kann den ehelichen Druck senken, solange:
+  - die offizielle Ehe respektiert bleibt
+  - keine Erbfolge bedroht wird
+  - kein öffentlicher Gesichtsverlust entsteht
+
+Deshalb ist bei hohen Ständen ein positiver Effekt auf die Ehe ausdrücklich zulässig, aber nur in geordneten Fällen.
+
+## Empfohlene Umsetzung im Daemon
+
+Reihenfolge pro Daily Tick:
+
+1. aktive Ehen laden
+2. aktive Liebschaften laden
+3. Sichtbarkeit und Diskretion fortschreiben
+4. Ehezufriedenheit pro Ehe fortschreiben
+5. Ansehen pro Charakter fortschreiben
+6. Skandalereignisse prüfen
+7. Benachrichtigungen schreiben
+
+Reihenfolge pro Monthly Tick:
+
+1. Monatskosten je Liebschaft berechnen
+2. Geld abbuchen
+3. Unterversorgungsfolgen anwenden
+4. Kinderchance prüfen
+5. neue Kinder aus Liebschaften anlegen
+6. Folgeereignisse erzeugen
+
+## Minimale technische Erweiterungen
+
+Für eine erste umsetzbare Version werden mindestens benötigt:
+
+### Beziehungserweiterung
+
+- Zusatzfelder an `relationship` oder neue Nebentabelle `relationship_state`
+
+### Ehewert
+
+- `marriage_satisfaction` an Ehebeziehung
+
+### Kind-Zusatzfelder
+
+- `legitimacy`
+- `birth_context`
+- `public_known`
+
+### Daemon-Konfiguration
+
+- täglicher Falukant-Familienjob
+- monatlicher Falukant-Familienjob
+
+## MVP-Empfehlung
+
+Für die erste produktive Version empfehle ich diesen Schnitt:
+
+### Enthalten
+
+- aktive Liebschaften
+- Monatskosten
+- tägliche Ansehensänderung
+- Ehezufriedenheit
+- standesabhängige Unterschiede
+- Kinderchance aus Liebschaften
+- sichtbare Darstellung in FamilyView
+
+### Noch nicht im MVP
+
+- Erpressungsketten
+- kirchliche Sonderereignisse
+- gerichtliche Konflikte
+- Sonderrechte unehelicher Kinder
+- komplexe Hofintrigen
+- Dienerschaft als eigenes System
+- finales Balancing aller Zahlenwerte
+
+## Abnahmekriterien
+
+Die erste technische Umsetzung gilt als korrekt, wenn:
+
+1. jede aktive Liebschaft monatlich Kosten erzeugt
+2. jede aktive Liebschaft täglich das Ansehen verändert
+3. verheiratete Figuren täglich Ehezufriedenheit verändern
+4. hohe Stände bei geordneter Mätresse/Favorit einen neutralen oder leicht positiven Eheeffekt haben können
+5. sichtbare oder schlecht versorgte Liebschaften zu Ansehensverlust führen
+6. Kinder aus Liebschaften entstehen können
+7. weibliche und männliche Spielfiguren regelgleich behandelt werden
+
+## Offene Implementierungsfrage
+
+Vor dem Coden sollte noch genau entschieden werden:
+
+- ob die Zusatzwerte direkt in `relationship` landen
+- oder in eine neue Tabelle wie `falukant_data.relationship_state`
+
+Fachlich ist beides möglich. Für Wartbarkeit und spätere Ereignisse ist eine eigene Zustands-/Detailtabelle sauberer.
--- a/docs/FALUKANT_LOVERS_IMPLEMENTATION_BACKLOG.md
+++ b/docs/FALUKANT_LOVERS_IMPLEMENTATION_BACKLOG.md
@@ -0,0 +1,478 @@
+# Falukant: Implementierungs-Backlog für Liebhaber, Mätressen, Ehezufriedenheit und Kinder aus Liebschaften
+
+## Zweck
+
+Dieses Backlog übersetzt die Fach- und Technikdokumente in konkrete Umsetzungspakete.
+
+Grundlagen:
+
+- [FALUKANT_LOVERS_CONCEPT.md](/mnt/share/torsten/Programs/YourPart3/docs/FALUKANT_LOVERS_CONCEPT.md)
+- [FALUKANT_LOVERS_DAEMON_SPEC.md](/mnt/share/torsten/Programs/YourPart3/docs/FALUKANT_LOVERS_DAEMON_SPEC.md)
+- [FALUKANT_LOVERS_TECHNICAL_CONCEPT.md](/mnt/share/torsten/Programs/YourPart3/docs/FALUKANT_LOVERS_TECHNICAL_CONCEPT.md)
+
+Das Backlog ist absichtlich in Reihenfolge angeordnet. Spätere Pakete bauen auf früheren auf.
+
+## Rahmen
+
+Nicht Teil der ersten Umsetzung:
+
+- eigenes Dienerschaftssystem
+- finales Balancing
+- große Ereignisketten rund um Kirche, Gericht oder Hofintrigen
+
+## Paket B1: Datenmodell vorbereiten
+
+### Ziel
+
+Die Datenbasis für Ehezufriedenheit, Liebschaftsstatus und Kinder aus Liebschaften anlegen.
+
+### Aufgaben
+
+1. Migration für `falukant_data.relationship_state` anlegen
+2. Modell [relationship_state.js](/mnt/share/torsten/Programs/YourPart3/backend/models/falukant/data/relationship_state.js) anlegen
+3. Associations in [associations.js](/mnt/share/torsten/Programs/YourPart3/backend/models/associations.js) ergänzen
+4. `child_relation` um `legitimacy`, `birth_context`, `public_known` erweitern
+5. Modell [child_relation.js](/mnt/share/torsten/Programs/YourPart3/backend/models/falukant/data/child_relation.js) anpassen
+
+### Betroffene Dateien
+
+- [backend/models/associations.js](/mnt/share/torsten/Programs/YourPart3/backend/models/associations.js)
+- [backend/models/falukant/data/child_relation.js](/mnt/share/torsten/Programs/YourPart3/backend/models/falukant/data/child_relation.js)
+- neue Migrationen in [backend/migrations](/mnt/share/torsten/Programs/YourPart3/backend/migrations)
+- neue Datei [backend/models/falukant/data/relationship_state.js](/mnt/share/torsten/Programs/YourPart3/backend/models/falukant/data/relationship_state.js)
+
+### Abhängigkeiten
+
+- keine
+
+### Done
+
+- Datenbank kann die neuen Felder speichern
+- Sequelize kann `Relationship` plus `state` laden
+- `ChildRelation` kennt neue Legitimitätsfelder
+
+## Paket B2: Backfill und Defaults
+
+### Ziel
+
+Bestehende Ehen und Liebschaften mit Startwerten versorgen.
+
+### Aufgaben
+
+1. Backfill-Migration oder Reparaturskript für bestehende `married`-Beziehungen
+2. Backfill-Migration oder Reparaturskript für bestehende `lover`-Beziehungen
+3. Fallback-Logik im Backend ergänzen, falls für alte Datensätze noch kein State existiert
+
+### Betroffene Dateien
+
+- neue Migration oder Tool in [backend/migrations](/mnt/share/torsten/Programs/YourPart3/backend/migrations) oder [backend/tools](/mnt/share/torsten/Programs/YourPart3/backend/tools)
+- [backend/services/falukantService.js](/mnt/share/torsten/Programs/YourPart3/backend/services/falukantService.js)
+
+### Abhängigkeiten
+
+- B1
+
+### Done
+
+- alle alten `married`- und `lover`-Beziehungen haben nutzbare Zustandswerte
+- Family-Lesezugriffe brechen nicht bei fehlendem State
+
+## Paket B3: Family-Lesepfade erweitern
+
+### Ziel
+
+Die bestehenden API-Daten für Familie so erweitern, dass das Frontend sofort lesen und anzeigen kann.
+
+### Aufgaben
+
+1. `getFamily()` in [falukantService.js](/mnt/share/torsten/Programs/YourPart3/backend/services/falukantService.js) um `state`-Daten erweitern
+2. für Ehebeziehungen `marriageSatisfaction` und `marriageState` liefern
+3. für `lovers` Rollen-, Kosten-, Sichtbarkeits- und Risikofelder liefern
+4. Hilfsmethoden für Standesgruppe und Vorschauwerte ergänzen
+
+### Betroffene Dateien
+
+- [backend/services/falukantService.js](/mnt/share/torsten/Programs/YourPart3/backend/services/falukantService.js)
+
+### Abhängigkeiten
+
+- B1
+- B2
+
+### Done
+
+- `GET /api/falukant/family` liefert die neuen Datenfelder
+- keine UI-Aktion nötig, aber Daten sind vollständig lesbar
+
+## Paket B4: Family-UI lesend ausbauen
+
+### Ziel
+
+Die neuen Daten im Familienbereich sichtbar machen, ohne schon alle Interaktionen einzubauen.
+
+### Aufgaben
+
+1. Ehebereich in [FamilyView.vue](/mnt/share/torsten/Programs/YourPart3/frontend/src/views/falukant/FamilyView.vue) um `Ehe-Zufriedenheit` ergänzen
+2. `lovers`-Bereich mit Rolle, Sichtbarkeit, Diskretion, Unterhalt, Reputationseffekt und Eheeffekt erweitern
+3. Kinderkennzeichnung für `legitimate`, `hidden_bastard`, `acknowledged_bastard` ergänzen
+4. I18n-Schlüssel in den Falukant-Locales ergänzen
+
+### Betroffene Dateien
+
+- [frontend/src/views/falukant/FamilyView.vue](/mnt/share/torsten/Programs/YourPart3/frontend/src/views/falukant/FamilyView.vue)
+- [frontend/src/i18n/locales/de/falukant.json](/mnt/share/torsten/Programs/YourPart3/frontend/src/i18n/locales/de/falukant.json)
+- [frontend/src/i18n/locales/en/falukant.json](/mnt/share/torsten/Programs/YourPart3/frontend/src/i18n/locales/en/falukant.json)
+- [frontend/src/i18n/locales/es/falukant.json](/mnt/share/torsten/Programs/YourPart3/frontend/src/i18n/locales/es/falukant.json)
+
+### Abhängigkeiten
+
+- B3
+
+### Done
+
+- FamilyView zeigt neue Zustände lesbar an
+- uneheliche Kinder sind UI-seitig unterscheidbar
+
+## Paket B5: Berechnungslogik im Service kapseln
+
+### Ziel
+
+Alle Formeln in wiederverwendbare Backend-Helfer auslagern, bevor Daemon-Jobs gebaut werden.
+
+### Aufgaben
+
+1. `getRankGroup(...)` implementieren
+2. `calculateLoverMonthlyCost(...)` implementieren
+3. `calculateMarriageDelta(...)` implementieren
+4. `calculateReputationDeltaFromLover(...)` implementieren
+5. `calculateDailyVisibilityDelta(...)` und `calculateDailyDiscretionDelta(...)` implementieren
+6. `calculateDailyScandalChance(...)` implementieren
+7. `calculateMonthlyPregnancyChance(...)` implementieren
+
+### Betroffene Dateien
+
+- [backend/services/falukantService.js](/mnt/share/torsten/Programs/YourPart3/backend/services/falukantService.js)
+
+### Abhängigkeiten
+
+- B1
+- B2
+
+### Done
+
+- Daemon-Jobs können auf zentrale Helper zugreifen
+- keine Formel liegt verstreut in mehreren Jobs
+
+## Paket B6: Daily-Tick-Übergabe an externen Daemon
+
+### Ziel
+
+Die tägliche Spiellogik so spezifizieren und übergeben, dass der externe Daemon sie korrekt ausführen kann.
+
+### Aufgaben
+
+1. Übergabedokument für den externen Daemon erstellen
+2. Daily Input- und Output-Felder festlegen
+3. Idempotenzanforderungen für `last_daily_processed_at` festlegen
+4. Datenabhängigkeiten für Ehe, Liebschaften und Stand definieren
+5. Benachrichtigungs- und Ereignisfolgen beschreiben
+
+### Betroffene Dateien
+
+- [docs/FALUKANT_LOVERS_DAEMON_HANDOFF.md](/mnt/share/torsten/Programs/YourPart3/docs/FALUKANT_LOVERS_DAEMON_HANDOFF.md)
+- [docs/FALUKANT_LOVERS_DAEMON_SPEC.md](/mnt/share/torsten/Programs/YourPart3/docs/FALUKANT_LOVERS_DAEMON_SPEC.md)
+
+### Abhängigkeiten
+
+- B5
+
+### Done
+
+- der externe Daemon hat eine vollständige Daily-Tick-Übergabe
+- Daily-Logik ist ohne Rückfragen implementierbar
+
+## Paket B7: Monthly-Tick-Übergabe an externen Daemon
+
+### Ziel
+
+Die monatliche Spiellogik so spezifizieren und übergeben, dass der externe Daemon sie korrekt ausführen kann.
+
+### Aufgaben
+
+1. Monthly Input- und Output-Felder festlegen
+2. Geldabbuchung und Moneyflow-Anforderungen beschreiben
+3. Unterversorgung und Zustandsänderungen beschreiben
+4. Kind-Erzeugung und Folgeeffekte beschreiben
+5. Idempotenzanforderungen für `last_monthly_processed_at` festlegen
+6. Transaktionsanforderungen definieren
+
+### Betroffene Dateien
+
+- [docs/FALUKANT_LOVERS_DAEMON_HANDOFF.md](/mnt/share/torsten/Programs/YourPart3/docs/FALUKANT_LOVERS_DAEMON_HANDOFF.md)
+- [docs/FALUKANT_LOVERS_DAEMON_SPEC.md](/mnt/share/torsten/Programs/YourPart3/docs/FALUKANT_LOVERS_DAEMON_SPEC.md)
+
+### Abhängigkeiten
+
+- B5
+
+### Done
+
+- der externe Daemon hat eine vollständige Monthly-Tick-Übergabe
+- Monatslogik ist ohne Rückfragen implementierbar
+
+## Paket B8: Kinder aus Liebschaften technisch ermöglichen
+
+### Ziel
+
+Kinder aus aktiven Liebschaften erzeugen und korrekt markieren.
+
+### Aufgaben
+
+1. `createChildFromLoverRelationship(...)` implementieren
+2. `processLoverBirths(...)` in den Monthly Tick integrieren
+3. `ChildRelation` korrekt mit `birthContext = lover` anlegen
+4. `legitimacy = hidden_bastard` als Startwert setzen
+5. erste Folgeeffekte auf Ansehen und Ehezufriedenheit anwenden
+
+### Betroffene Dateien
+
+- [backend/services/falukantService.js](/mnt/share/torsten/Programs/YourPart3/backend/services/falukantService.js)
+- [backend/models/falukant/data/child_relation.js](/mnt/share/torsten/Programs/YourPart3/backend/models/falukant/data/child_relation.js)
+- [docs/FALUKANT_LOVERS_DAEMON_HANDOFF.md](/mnt/share/torsten/Programs/YourPart3/docs/FALUKANT_LOVERS_DAEMON_HANDOFF.md)
+
+### Abhängigkeiten
+
+- B7
+
+### Done
+
+- Kinder aus Liebschaften können entstehen
+- sie sind von legitimen Kindern technisch unterscheidbar
+
+## Paket B9: Notifications und Folgeereignisse MVP
+
+### Ziel
+
+Die wichtigsten Ergebnisse für Spieler sichtbar machen.
+
+### Aufgaben
+
+1. Notifikationstypen für Kosten, Unterversorgung, Gerücht, Skandal und Kind ergänzen
+2. Benachrichtigungstexte definieren
+3. Daily- und Monthly-Tick an die Notification-Logik anbinden
+
+### Betroffene Dateien
+
+- [docs/FALUKANT_LOVERS_DAEMON_HANDOFF.md](/mnt/share/torsten/Programs/YourPart3/docs/FALUKANT_LOVERS_DAEMON_HANDOFF.md)
+- bestehende Notification-Modelle oder Services im Backend
+- ggf. [frontend/src/views/falukant/OverviewView.vue](/mnt/share/torsten/Programs/YourPart3/frontend/src/views/falukant/OverviewView.vue) indirekt, falls Benachrichtigungen dort auftauchen
+
+### Abhängigkeiten
+
+- B6
+- B7
+- B8
+
+### Done
+
+- Spieler sehen relevante Familienfolgen aktiv
+
+## Paket B10: Lover-Aktionen im Backend
+
+### Ziel
+
+Interaktive Steuerung von Liebschaften serverseitig ermöglichen.
+
+### Aufgaben
+
+1. `setLoverMaintenance(...)`
+2. `setLoverDiscretionMode(...)`
+3. `acknowledgeLover(...)`
+4. `endLoverRelationship(...)`
+5. `giftLover(...)`
+6. Router- und Controller-Anbindung
+
+### Betroffene Dateien
+
+- [backend/services/falukantService.js](/mnt/share/torsten/Programs/YourPart3/backend/services/falukantService.js)
+- [backend/controllers/falukantController.js](/mnt/share/torsten/Programs/YourPart3/backend/controllers/falukantController.js)
+- [backend/routers/falukantRouter.js](/mnt/share/torsten/Programs/YourPart3/backend/routers/falukantRouter.js)
+
+### Abhängigkeiten
+
+- B3
+- B5
+
+### Done
+
+- Backend bietet alle Kernaktionen für Lovers an
+
+## Paket B11: Lover-Aktionen im Frontend
+
+### Ziel
+
+Die neuen Interaktionen in `FamilyView` und ggf. Dialogen bedienbar machen.
+
+### Aufgaben
+
+1. Action-Buttons in [FamilyView.vue](/mnt/share/torsten/Programs/YourPart3/frontend/src/views/falukant/FamilyView.vue) ergänzen
+2. API-Aufrufe anbinden
+3. Feedback- und Confirm-Dialoge integrieren
+4. Zustandsänderungen direkt im UI sichtbar machen
+
+### Betroffene Dateien
+
+- [frontend/src/views/falukant/FamilyView.vue](/mnt/share/torsten/Programs/YourPart3/frontend/src/views/falukant/FamilyView.vue)
+- ggf. neue API-Helfer in `frontend/src/api`
+
+### Abhängigkeiten
+
+- B10
+
+### Done
+
+- Unterhalt, Anerkennung, Diskretion und Beenden sind im UI nutzbar
+
+## Paket B12: Anerkennung unehelicher Kinder
+
+### Ziel
+
+Uneheliche Kinder später sichtbar anerkennen können.
+
+### Aufgaben
+
+1. Backend-Methode `acknowledgeLoverChild(...)`
+2. Route und Controller
+3. UI-Aktion im Familienbereich
+4. direkte Folgeeffekte auf Ansehen und Ehe einbauen
+
+### Betroffene Dateien
+
+- [backend/services/falukantService.js](/mnt/share/torsten/Programs/YourPart3/backend/services/falukantService.js)
+- [backend/controllers/falukantController.js](/mnt/share/torsten/Programs/YourPart3/backend/controllers/falukantController.js)
+- [backend/routers/falukantRouter.js](/mnt/share/torsten/Programs/YourPart3/backend/routers/falukantRouter.js)
+- [frontend/src/views/falukant/FamilyView.vue](/mnt/share/torsten/Programs/YourPart3/frontend/src/views/falukant/FamilyView.vue)
+
+### Abhängigkeiten
+
+- B8
+- B11
+
+### Done
+
+- uneheliche Kinder können anerkannt werden
+- Status und Folgen ändern sich sichtbar
+
+## Paket B13: Admin- und Testhilfen
+
+### Ziel
+
+Die neue Mechanik testbar und debugbar machen.
+
+### Aufgaben
+
+1. Admin- oder Tool-Zugriff auf `relationship_state`
+2. Debug-Skript für `30 Tage simulieren`
+3. Plausibilitätsprüfungen für fehlende States
+4. Reparaturskript für inkonsistente Kinderdaten
+
+### Betroffene Dateien
+
+- [backend/tools](/mnt/share/torsten/Programs/YourPart3/backend/tools)
+- ggf. [backend/services/adminService.js](/mnt/share/torsten/Programs/YourPart3/backend/services/adminService.js)
+- [docs/FALUKANT_LOVERS_DAEMON_HANDOFF.md](/mnt/share/torsten/Programs/YourPart3/docs/FALUKANT_LOVERS_DAEMON_HANDOFF.md)
+
+### Abhängigkeiten
+
+- B6
+- B7
+- B8
+
+### Done
+
+- Entwickler können Systemzustände nachvollziehen und korrigieren
+
+## Paket B14: QA und Balancing-Vorbereitung
+
+### Ziel
+
+Noch kein finales Balancing, aber die technische Basis für spätere Feinjustierung schaffen.
+
+### Aufgaben
+
+1. Konfigurationspunkte für Kosten- und Reputationswerte zentralisieren
+2. Grundtests für Daily- und Monthly-Tick definieren
+3. Testfälle für Standesgruppen definieren
+4. Testfälle für weibliche und männliche Spielfiguren spiegeln
+5. Testfälle für Kinder aus Liebschaften definieren
+
+### Betroffene Dateien
+
+- [docs/FALUKANT_LOVERS_DAEMON_HANDOFF.md](/mnt/share/torsten/Programs/YourPart3/docs/FALUKANT_LOVERS_DAEMON_HANDOFF.md)
+- ggf. Testverzeichnis im Backend
+
+### Abhängigkeiten
+
+- B6
+- B7
+- B8
+
+### Done
+
+- Werte sind zentral auffindbar
+- spätere Balancing-Runden können auf Testfällen aufsetzen
+
+## Empfohlene Reihenfolge
+
+Für eine saubere erste Lieferung:
+
+1. B1
+2. B2
+3. B3
+4. B4
+5. B5
+6. B6
+7. B7
+8. B8
+9. B9
+10. B10
+11. B11
+12. B12
+13. B13
+14. B14
+
+## MVP-Schnitt
+
+Wenn eine erste spielbare Version schneller geliefert werden soll, reicht zunächst:
+
+1. B1
+2. B2
+3. B3
+4. B4
+5. B5
+6. B6
+7. B7
+8. B8
+
+Damit wären bereits vorhanden:
+
+- sichtbare Liebhaber-Details
+- Ehezufriedenheit
+- laufende Kosten
+- laufende Ansehensänderung
+- Kinder aus Liebschaften
+
+Noch nicht enthalten im MVP:
+
+- volle Interaktionssteuerung
+- Anerkennung unehelicher Kinder
+- Admin-Tools
+- spätere Balancing-Infrastruktur
+
+## Nächster konkreter Schritt
+
+Wenn direkt implementiert werden soll, ist der erste technische Einstieg:
+
+- B1 Datenmodell vorbereiten
+
+Das ist der sauberste Startpunkt, weil danach alle weiteren Pakete darauf aufbauen können.
--- a/docs/FALUKANT_LOVERS_TECHNICAL_CONCEPT.md
+++ b/docs/FALUKANT_LOVERS_TECHNICAL_CONCEPT.md
@@ -0,0 +1,503 @@
+# Falukant: Technisches Konzept für Liebhaber, Mätressen, Ehezufriedenheit und Kinder aus Liebschaften
+
+## Ziel
+
+Dieses Dokument beschreibt die technische Umsetzung für Backend, Daemon und UI. Es basiert auf:
+
+- [FALUKANT_LOVERS_CONCEPT.md](/mnt/share/torsten/Programs/YourPart3/docs/FALUKANT_LOVERS_CONCEPT.md)
+- [FALUKANT_LOVERS_DAEMON_SPEC.md](/mnt/share/torsten/Programs/YourPart3/docs/FALUKANT_LOVERS_DAEMON_SPEC.md)
+
+Es soll als direkte Arbeitsgrundlage für Migrationen, Modelle, Service-Methoden, Daemon-Jobs und Frontend-Anpassungen dienen.
+
+## Umsetzungsstrategie
+
+Die Umsetzung sollte in drei technischen Stufen erfolgen:
+
+### Stufe 1: Datenbasis und Lesepfade
+
+- neue Beziehungsdetaildaten anlegen
+- Ehezufriedenheit technisch einführen
+- Family-API erweitern
+- UI nur lesend erweitern
+
+### Stufe 2: Externe Daemon-Logik
+
+- tägliche und monatliche Falukant-Familienlogik an den externen Daemon übergeben
+- Kosten, Ansehen, Sichtbarkeit, Diskretion und Ehezufriedenheit laufen dort automatisch
+- Kinder aus Liebschaften werden über den externen Daemon ermöglicht
+
+### Stufe 3: Interaktive Spielmechanik
+
+- UI-Aktionen für Unterhalt, Diskretion, Anerkennung, Beenden
+- Ereignisse, Warnungen und Benachrichtigungen
+- spätere Vertiefung wie Skandal- oder Kirchenereignisse
+
+## Datenmodell
+
+## 1. Bestehende Tabellen, die genutzt werden
+
+- `falukant_data.relationship`
+- `falukant_data.child_relation`
+- `falukant_data.character`
+
+## 2. Empfohlene neue Tabelle
+
+Empfohlen wird eine neue Detailtabelle:
+
+- `falukant_data.relationship_state`
+
+Begründung:
+
+- `relationship` enthält aktuell nur die grobe Beziehung
+- Liebhaber-/Ehedaten sind zustandsorientiert
+- die Detailwerte wachsen voraussichtlich weiter
+- eine Nebentabelle ist sauberer als `relationship` mit vielen Spezialspalten zu überladen
+
+## 3. Tabelle `relationship_state`
+
+### Primärbezug
+
+- `relationship_id`
+
+### Spalten für Ehe
+
+- `marriage_satisfaction` integer not null default `55`
+- `marriage_public_stability` integer not null default `55`
+
+`marriage_public_stability` ist optional, aber sinnvoll für spätere Ereignisse. Für MVP kann er schon angelegt, aber noch wenig genutzt werden.
+
+### Spalten für Liebschaften
+
+- `lover_role` string nullable
+  - `secret_affair`
+  - `lover`
+  - `mistress_or_favorite`
+- `affection` integer not null default `50`
+- `visibility` integer not null default `15`
+- `discretion` integer not null default `50`
+- `maintenance_level` integer not null default `50`
+- `status_fit` integer not null default `0`
+- `monthly_base_cost` integer not null default `0`
+- `months_underfunded` integer not null default `0`
+- `active` boolean not null default `true`
+- `acknowledged` boolean not null default `false`
+- `exclusive_flag` boolean not null default `false`
+- `last_monthly_processed_at` date nullable
+- `last_daily_processed_at` date nullable
+
+### Spalten für spätere Erweiterung
+
+- `notes_json` jsonb nullable
+- `flags_json` jsonb nullable
+
+## 4. Erweiterung `child_relation`
+
+Neue Spalten:
+
+- `legitimacy` string not null default `legitimate`
+  - `legitimate`
+  - `acknowledged_bastard`
+  - `hidden_bastard`
+- `birth_context` string not null default `marriage`
+  - `marriage`
+  - `lover`
+- `public_known` boolean not null default `false`
+
+## 5. Optionale Erweiterung `relationship`
+
+Für bessere Auswertung kann zusätzlich sinnvoll sein:
+
+- `ended_at`
+- `ended_reason`
+
+Das ist für MVP nicht zwingend, aber nützlich.
+
+## Migrationen
+
+Benötigte Migrationen:
+
+### Migration 1
+
+- neue Tabelle `falukant_data.relationship_state`
+
+### Migration 2
+
+- neue Spalten an `falukant_data.child_relation`
+
+### Migration 3 optional
+
+- Backfill für bestehende Beziehungen
+
+Regeln für Backfill:
+
+- bei `relationshipType = married`
+  - `marriage_satisfaction = 55`
+- bei `relationshipType = lover`
+  - `lover_role = lover`
+  - `affection = 50`
+  - `visibility = 20`
+  - `discretion = 45`
+  - `maintenance_level = 50`
+  - `status_fit = 0`
+  - `monthly_base_cost = 30`
+
+## Sequelize-Modelle
+
+## 1. Neues Modell
+
+Neue Datei:
+
+- [relationship_state.js](/mnt/share/torsten/Programs/YourPart3/backend/models/falukant/data/relationship_state.js)
+
+## 2. Associations
+
+In [associations.js](/mnt/share/torsten/Programs/YourPart3/backend/models/associations.js):
+
+- `Relationship.hasOne(RelationshipState, { foreignKey: 'relationshipId', as: 'state' })`
+- `RelationshipState.belongsTo(Relationship, { foreignKey: 'relationshipId', as: 'relationship' })`
+
+## 3. ChildRelation-Erweiterung
+
+In [child_relation.js](/mnt/share/torsten/Programs/YourPart3/backend/models/falukant/data/child_relation.js):
+
+- `legitimacy`
+- `birthContext`
+- `publicKnown`
+
+## Backend-Service-Konzept
+
+Hauptort:
+
+- [falukantService.js](/mnt/share/torsten/Programs/YourPart3/backend/services/falukantService.js)
+
+## 1. Neue interne Hilfsmethoden
+
+Empfohlene neue interne Methoden:
+
+- `getRankGroup(titleLabelTr)`
+- `calculateLoverMonthlyCost(relationship, state, character)`
+- `calculateMarriageDelta(relationship, state, character, spouseCharacter, context)`
+- `calculateReputationDeltaFromLover(relationship, state, character, context)`
+- `calculateDailyVisibilityDelta(state, context)`
+- `calculateDailyDiscretionDelta(state, context)`
+- `calculateDailyScandalChance(relationship, state, character, context)`
+- `calculateMonthlyPregnancyChance(relationship, state, charA, charB)`
+- `applyLoverMonthlyCosts(transactionDate?)`
+- `applyLoverDailyEffects(transactionDate?)`
+- `processLoverBirths(transactionDate?)`
+- `triggerLoverScandalEvent(...)`
+
+## 2. Erweiterung `getFamily`
+
+Die Familienausgabe in [falukantService.js](/mnt/share/torsten/Programs/YourPart3/backend/services/falukantService.js) muss `lovers` detaillierter liefern.
+
+Zusätzliche API-Felder je Lover:
+
+- `relationshipId`
+- `role`
+- `affection`
+- `visibility`
+- `discretion`
+- `maintenanceLevel`
+- `statusFit`
+- `monthlyCost`
+- `reputationEffect`
+- `marriageEffect`
+- `acknowledged`
+- `canBecomePublic`
+- `riskState`
+
+Zusätzliche API-Felder für Ehe:
+
+- `marriageSatisfaction`
+- `marriageState`
+  - `stable`
+  - `strained`
+  - `crisis`
+
+## 3. Neue Service-Aktionen
+
+Für spätere UI-Steuerung:
+
+- `setLoverMaintenance(hashedUserId, relationshipId, maintenanceLevel)`
+- `setLoverDiscretionMode(hashedUserId, relationshipId, mode)`
+- `acknowledgeLover(hashedUserId, relationshipId)`
+- `endLoverRelationship(hashedUserId, relationshipId)`
+- `giftLover(hashedUserId, relationshipId, giftType)`
+
+Diese Methoden müssen in Stufe 1 noch nicht voll sichtbar sein, sollten aber im Konzept vorgesehen werden.
+
+## API-Konzept
+
+## 1. Bestehende Family-Route erweitern
+
+Bestehender Endpunkt:
+
+- `GET /api/falukant/family`
+
+Erweitern um:
+
+- `marriageSatisfaction`
+- `lovers` mit Detailfeldern
+- `householdTension` optional
+
+## 2. Neue Endpunkte
+
+Empfohlene neue Endpunkte:
+
+- `POST /api/falukant/family/lover/:relationshipId/maintenance`
+- `POST /api/falukant/family/lover/:relationshipId/discretion`
+- `POST /api/falukant/family/lover/:relationshipId/acknowledge`
+- `POST /api/falukant/family/lover/:relationshipId/end`
+- `POST /api/falukant/family/lover/:relationshipId/gift`
+
+## 3. Antwortschema
+
+Jede mutierende Aktion sollte zurückgeben:
+
+- aktualisierte Liebhaber-Daten
+- aktualisierte Ehe-Zufriedenheit
+- aktualisierte Geldmenge
+- aktualisiertes Ansehen
+- optionale Nachricht für UI
+
+## Daemon-Integration
+
+## 1. Tatsächliche Daemon-Lage
+
+Der operative Daemon ist nicht Teil dieses Projekts. Dieses Projekt stellt daher:
+
+- Datenmodell
+- Backfill
+- Family-API
+- UI-Anzeige
+- Fach- und Übergabedokumente
+
+Der externe Daemon ist zuständig für:
+
+- Daily Tick
+- Monthly Tick
+- Geldabbuchung
+- Ansehensänderung
+- Ehezufriedenheit
+- Kinder aus Liebschaften
+
+Die operative Übergabe dafür steht in:
+
+- [FALUKANT_LOVERS_DAEMON_HANDOFF.md](/mnt/share/torsten/Programs/YourPart3/docs/FALUKANT_LOVERS_DAEMON_HANDOFF.md)
+
+## 2. Neue Benachrichtigungstypen
+
+Es sollten neue Falukant-Benachrichtigungen eingeführt werden:
+
+- `loverCostPaid`
+- `loverUnderfunded`
+- `loverRumor`
+- `loverScandal`
+- `loverChildHidden`
+- `loverChildKnown`
+- `marriageCrisis`
+
+## Kindererzeugung technisch
+
+## 1. Vorhandene Strukturen nutzen
+
+Neue Kinder aus Liebschaften sollen dieselbe Charakter- und `ChildRelation`-Logik nutzen wie bestehende Kinder.
+
+## 2. Erzeugungsort
+
+Die Kind-Erzeugung soll vom externen Daemon ausgeführt oder angestoßen werden. Dieses Backend muss dafür die Zielstruktur stabil bereitstellen.
+
+## 3. Anerkennung eines Kindes
+
+Spätere Service-Methode:
+
+- `acknowledgeLoverChild(hashedUserId, childCharacterId)`
+
+Wirkung:
+
+- `legitimacy = acknowledged_bastard`
+- `publicKnown = true`
+- Ansehen anpassen
+- Ehe-Zufriedenheit anpassen
+
+## Frontend-Konzept
+
+Hauptansicht:
+
+- [FamilyView.vue](/mnt/share/torsten/Programs/YourPart3/frontend/src/views/falukant/FamilyView.vue)
+
+## 1. Ehebereich erweitern
+
+Im Ehe- oder Partnerbereich anzeigen:
+
+- `Ehe-Zufriedenheit`
+- textlicher Status
+  - `stabil`
+  - `angespannt`
+  - `krisenhaft`
+- kurzer Hinweis, ob aktive Liebschaften die Ehe belasten oder stabilisieren
+
+## 2. Lovers-Bereich ausbauen
+
+Aktuell existiert nur Name plus Zuneigung. Neu anzeigen:
+
+- Rolle
+- Zuneigung
+- Sichtbarkeit
+- Diskretion
+- Unterhaltsniveau
+- Monatskosten
+- aktueller Einfluss auf Ansehen
+- aktueller Einfluss auf Ehe-Zufriedenheit
+- Risikostatus
+
+## 3. Aktionen im UI
+
+Pro Liebschaft:
+
+- Unterhalt erhöhen oder senken
+- Diskretion priorisieren
+- öffentlich anerkennen
+- beschenken
+- Beziehung beenden
+
+## 4. Farbliche Zustände
+
+### Grün
+
+- geordnet
+- geringe Sichtbarkeit
+- Ehe stabil oder neutral
+
+### Gelb
+
+- steigende Sichtbarkeit
+- mittlere Ehebelastung
+- Unterhalt knapp
+
+### Rot
+
+- Skandalrisiko hoch
+- Ehekrise
+- unterfinanziert
+- Kind öffentlich geworden
+
+## 5. Kinder aus Liebschaften in FamilyView
+
+Im Kinderbereich kenntlich machen:
+
+- legitimes Kind
+- uneheliches verborgenes Kind
+- anerkanntes uneheliches Kind
+
+Es braucht keine sensationelle Darstellung, aber klare Kennzeichnung.
+
+## I18n-Bedarf
+
+Benötigte neue Übersetzungsbereiche in:
+
+- [frontend/src/i18n/locales/de/falukant.json](/mnt/share/torsten/Programs/YourPart3/frontend/src/i18n/locales/de/falukant.json)
+- [frontend/src/i18n/locales/en/falukant.json](/mnt/share/torsten/Programs/YourPart3/frontend/src/i18n/locales/en/falukant.json)
+- [frontend/src/i18n/locales/es/falukant.json](/mnt/share/torsten/Programs/YourPart3/frontend/src/i18n/locales/es/falukant.json)
+
+Neue Schlüsselgruppen:
+
+- `falukant.family.marriageSatisfaction.*`
+- `falukant.family.lovers.role.*`
+- `falukant.family.lovers.visibility`
+- `falukant.family.lovers.discretion`
+- `falukant.family.lovers.maintenance`
+- `falukant.family.lovers.monthlyCost`
+- `falukant.family.lovers.reputationEffect`
+- `falukant.family.lovers.marriageEffect`
+- `falukant.family.lovers.risk.*`
+- `falukant.family.children.legitimacy.*`
+
+## Admin- und Debug-Bedarf
+
+Für Entwicklung und Balancing später sinnvoll:
+
+- Admin-Sicht auf `relationship_state`
+- Möglichkeit, `marriageSatisfaction`, `visibility`, `discretion`, `maintenanceLevel` zu setzen
+- optionales Debug-Tool zum Simulieren von 30 Tagen
+
+Das sollte nicht Teil des ersten Spieler-UI sein, aber früh mitgedacht werden.
+
+## Technische Risiken
+
+### 1. Tick-Duplikate
+
+Wenn Daily- oder Monthly-Ticks mehrfach laufen, werden Kosten und Ansehen doppelt verrechnet.
+
+Gegenmaßnahme:
+
+- `last_daily_processed_at`
+- `last_monthly_processed_at`
+- idempotente Verarbeitung pro Beziehung und Tag/Monat
+
+### 2. Dateninkonsistenz
+
+Eine `lover`-Beziehung ohne `relationship_state` würde Berechnungen brechen.
+
+Gegenmaßnahme:
+
+- beim Lesen fehlende States automatisch erzeugen
+- oder beim Start ein Reparaturskript
+
+### 3. Kindererzeugung doppelt
+
+Bei konkurrierenden Prozessen könnte ein Kind zweimal entstehen.
+
+Gegenmaßnahme:
+
+- Transaktion
+- Sperre pro Beziehung und Tick
+- eindeutige Monatsverarbeitung
+
+## Empfohlene Implementierungsreihenfolge
+
+### Paket 1
+
+- Migrationen
+- Modell `RelationshipState`
+- Associations
+- Backfill
+
+### Paket 2
+
+- Family-Service erweitert lesen
+- API-Felder ausliefern
+- UI in `FamilyView` lesend erweitern
+
+### Paket 3
+
+- Übergabe Daily Tick
+- Übergabe Monthly Tick
+- Abstimmung zu Geldabbuchung
+- Abstimmung zu Ansehen und Ehezufriedenheit
+
+### Paket 4
+
+- Kinder aus Liebschaften
+- Benachrichtigungen
+- UI-Aktionen
+
+### Paket 5
+
+- Ereignisse
+- spätere Dienerschaft
+- Balancing-Phase
+
+## Definition of Done
+
+Die technische Erstumsetzung ist abgeschlossen, wenn:
+
+1. `lover`-Beziehungen Detailzustand besitzen
+2. Ehezufriedenheit technisch existiert
+3. Family-API alle neuen Daten ausliefert
+4. Daily- und Monthly-Tick für den externen Daemon vollständig beschrieben sind
+5. Monatskosten- und Statuslogik extern ausführbar definiert sind
+6. Kinder aus Liebschaften technisch entstehen können
+7. `FamilyView` die neuen Daten sichtbar macht
+8. weibliche und männliche Spielfiguren regelgleich behandelt werden
--- a/docs/FALUKANT_UI_WEBSOCKET.md
+++ b/docs/FALUKANT_UI_WEBSOCKET.md
@@ -0,0 +1,192 @@
+# Falukant: UI-Anpassung – WebSocket & Familie / Liebschaften
+
+Dieses Dokument beschreibt die Nachrichten, die der externe Falukant-Daemon für Familien-, Ehe- und Liebschaftsänderungen sendet, damit die UI gezielt reagieren kann.
+
+Transport:
+- Alle Clients erhalten denselben Broadcast.
+- Die UI muss nach `user_id` filtern und nur Events für die eingeloggte Session verarbeiten.
+
+## 1. Übersicht der Events
+
+| `event` | Pflichtfelder | Typische UI-Reaktion |
+|---------|----------------|----------------------|
+| `falukantUpdateFamily` | `user_id`, `reason` | Gezielter Refresh von Familie, Liebschaften und je nach `reason` auch Geld oder Ruf |
+| `falukantUpdateStatus` | `user_id` | Allgemeiner Falukant-Status-/Spielstands-Refresh |
+| `children_update` | `user_id` | Kinderliste und Familienansicht aktualisieren |
+| `falukant_family_scandal_hint` | `relationship_id` | Optionaler Hinweis oder Logeintrag; kein `user_id` |
+
+## 2. JSON-Payloads
+
+### 2.1 `falukantUpdateFamily`
+
+```json
+{
+  "event": "falukantUpdateFamily",
+  "user_id": 123,
+  "reason": "daily"
+}
+```
+
+`reason` ist immer genau einer dieser festen Strings:
+- `daily`
+- `monthly`
+- `scandal`
+- `lover_birth`
+
+Es gibt keine weiteren `reason`-Werte.
+
+### 2.2 `falukantUpdateStatus`
+
+```json
+{
+  "event": "falukantUpdateStatus",
+  "user_id": 123
+}
+```
+
+Dieses Event wird typischerweise direkt nach `falukantUpdateFamily` mit derselben `user_id` gesendet.
+
+### 2.3 `children_update`
+
+```json
+{
+  "event": "children_update",
+  "user_id": 123
+}
+```
+
+Dieses Event tritt bei Geburt aus einer Liebschaft auf, meist zusammen mit:
+- `falukantUpdateFamily` mit `reason: "lover_birth"`
+- `falukantUpdateStatus`
+
+### 2.4 `falukant_family_scandal_hint`
+
+```json
+{
+  "event": "falukant_family_scandal_hint",
+  "relationship_id": 456
+}
+```
+
+Hinweis:
+- Dieses Event enthält kein `user_id`.
+- Die UI kann es ignorieren oder optional nur für Log-/Toast-Zwecke verwenden.
+- Die eigentliche nutzerbezogene Aktualisierung läuft über `falukantUpdateFamily` mit `reason: "scandal"`.
+
+## 3. Fachliche Bedeutung von `reason`
+
+### `reason: "daily"`
+
+`daily` ist der Sammelgrund für tägliche Änderungen im Familien- und Liebschaftssystem.
+
+Darunter fallen insbesondere:
+- tägliche Drift und Änderung der Ehezufriedenheit
+- Ehe-Buffs und temporäre Zähler wie Geschenk-, Fest- oder Haus-Effekte
+- tägliche Liebschaftslogik für aktive Beziehungen
+- Rufverlust bei zwei oder mehr sichtbaren Liebschaften
+- Zufalls-Mali wie Gerücht oder Tadel
+
+Wichtig:
+- Es gibt kein separates Event für „nur Ehe-Buff“.
+- Es gibt kein separates Event für „nur zwei sichtbare Liebschaften“.
+- Es gibt kein separates Event für „nur Gerücht/Tadel“.
+- Alles davon erscheint in der UI ausschließlich als `falukantUpdateFamily` mit `reason: "daily"`.
+
+### `reason: "scandal"`
+
+`scandal` wird zusätzlich zu einem gelungenen Skandalwurf gesendet.
+
+Typischer Ablauf:
+- optional `falukant_family_scandal_hint`
+- `falukantUpdateFamily` mit `reason: "scandal"`
+- `falukantUpdateStatus`
+
+Danach kann für denselben Nutzer am selben Tag zusätzlich noch `daily` folgen.
+
+### `reason: "monthly"`
+
+`monthly` steht für Monatsverarbeitung, insbesondere:
+- laufende Kosten
+- Unterversorgung
+- Geldänderungen
+
+### `reason: "lover_birth"`
+
+`lover_birth` signalisiert ein neues Kind aus einer Liebschaft.
+
+Meist folgen zusammen:
+- `falukantUpdateFamily` mit `reason: "lover_birth"`
+- `children_update`
+- `falukantUpdateStatus`
+
+## 4. Empfohlene Handler-Logik
+
+```text
+onMessage(json):
+  if json.user_id exists and json.user_id != currentUserId:
+    return
+
+  switch json.event:
+    case "falukantUpdateStatus":
+      refreshPlayerStatus()
+      return
+
+    case "children_update":
+      refreshChildrenAndFamilyView()
+      return
+
+    case "falukantUpdateFamily":
+      switch json.reason:
+        case "daily":
+          refreshFamilyAndRelationships()
+          refreshReputationIfNeeded()
+          break
+        case "monthly":
+          refreshMoney()
+          refreshFamilyAndRelationships()
+          break
+        case "scandal":
+          showScandalToastOptional()
+          refreshFamilyAndRelationships()
+          refreshReputationIfNeeded()
+          break
+        case "lover_birth":
+          refreshChildrenAndFamilyView()
+          break
+      return
+
+    case "falukant_family_scandal_hint":
+      // optional: nur als Hinweis verarbeiten
+      return
+```
+
+## 5. Deduplizierung
+
+Am selben Tag kann ein Nutzer mehrere relevante Events erhalten, zum Beispiel:
+- `scandal`
+- danach `daily`
+- danach `falukantUpdateStatus`
+
+Die UI sollte deshalb:
+- Refreshes bündeln oder entprellen
+- idempotente Reloads verwenden
+- nicht davon ausgehen, dass jeder fachliche Effekt einen eigenen `reason` hat
+
+## 6. Welche Daten sollten neu geladen werden?
+
+| Situation | Sinnvolle Reaktion |
+|-----------|--------------------|
+| Jede `falukantUpdateFamily` | Family-/Relationship-Daten neu laden |
+| `reason: "monthly"` | Family-Daten plus Geld/Status neu laden |
+| `reason: "daily"` | Family-Daten neu laden, bei Bedarf auch Ruf-/Statusdaten |
+| `reason: "scandal"` | Family-Daten plus Ruf-/Statusdaten neu laden |
+| `children_update` / `lover_birth` | Kinderdaten und FamilyView neu laden |
+
+## 7. Sonderfälle
+
+| Fall | Verhalten |
+|------|-----------|
+| NPC ohne `user_id` | Keine nutzerbezogenen Family-Socket-Events |
+| Mehrere Events kurz hintereinander | Normal; UI sollte damit robust umgehen |
+| Nur `falukantUpdateStatus` ohne Family-Event | Kann von anderen Falukant-Workern kommen |
+
--- a/docs/FALUKANT_UNDERGROUND_AFFAIR_DAEMON_HANDOFF.md
+++ b/docs/FALUKANT_UNDERGROUND_AFFAIR_DAEMON_HANDOFF.md
@@ -0,0 +1,180 @@
+# Falukant: Daemon-Handoff für `investigate_affair`
+
+## Zweck
+
+Dieses Dokument beschreibt die Auswertung der Untergrundaktivität `investigate_affair` im externen Daemon.
+
+Es ergänzt:
+
+- [FALUKANT_UNDERGROUND_AFFAIR_PLAN.md](/mnt/share/torsten/Programs/YourPart3/docs/FALUKANT_UNDERGROUND_AFFAIR_PLAN.md)
+- [FALUKANT_LOVERS_DAEMON_SPEC.md](/mnt/share/torsten/Programs/YourPart3/docs/FALUKANT_LOVERS_DAEMON_SPEC.md)
+- [FALUKANT_LOVERS_DAEMON_HANDOFF.md](/mnt/share/torsten/Programs/YourPart3/docs/FALUKANT_LOVERS_DAEMON_HANDOFF.md)
+
+## Betroffene Daten
+
+Der externe Daemon liest:
+
+- `falukant_data.underground`
+- `falukant_type.underground`
+- `falukant_data.relationship`
+- `falukant_data.relationship_state`
+- `falukant_data.character`
+- optional `falukant_data.child_relation`
+
+Relevant ist jeweils:
+
+- Untergrundaktivität vom Typ `investigate_affair`
+- `performer_id`
+- `victim_id`
+- `parameters.goal`
+  - `expose`
+  - `blackmail`
+- `result`
+
+## Erwarteter Input
+
+Eine Aktivität ist für den Daemon verarbeitbar, wenn:
+
+- `underground_type.tr = investigate_affair`
+- `result.status = pending`
+
+Der Daemon soll dann beim Opfer prüfen:
+
+- aktive Liebschaften
+- Sichtbarkeit und Diskretion dieser Liebschaften
+- evtl. bekannte uneheliche Kinder
+- Stand und Ansehen des Opfers
+
+## Ergebnis-Schema in `underground.result`
+
+Der Daemon schreibt nach der Auswertung ein JSON mit folgender Struktur:
+
+```json
+{
+  "status": "resolved",
+  "outcome": "success",
+  "discoveries": {
+    "relationshipId": 123,
+    "loverRole": "secret_affair",
+    "visibility": 42,
+    "acknowledged": false,
+    "publicKnownChild": false
+  },
+  "visibilityDelta": 12,
+  "reputationDelta": -3,
+  "blackmailAmount": 1500,
+  "notes": "Affair was uncovered and partially exposed."
+}
+```
+
+Erlaubte Werte:
+
+- `status`
+  - `pending`
+  - `resolved`
+  - `failed`
+- `outcome`
+  - `success`
+  - `partial`
+  - `failure`
+
+## Auswertung: `goal = expose`
+
+Ziel:
+
+- Liebschaft öffentlich machen
+- Sichtbarkeit stark erhöhen
+- ggf. Skandal auslösen
+
+Empfohlene Wirkung:
+
+- `relationship_state.visibility +10..25`
+- optional `relationship_state.discretion -5..15`
+- sofortiger Reputationsschaden beim Opfer
+- bei sehr sichtbarer oder junger Beziehung zusätzliche Skandalchance
+
+Zusätzliche Empfehlung:
+
+- wenn die Beziehung bereits fast öffentlich war, darf `outcome = partial` gesetzt werden statt voller Erfolg
+
+## Auswertung: `goal = blackmail`
+
+Ziel:
+
+- belastendes Wissen gewinnen
+- keinen sofortigen vollen öffentlichen Effekt erzeugen
+- ein Erpressungspotenzial vorbereiten
+
+Empfohlene Wirkung:
+
+- `relationship_state.visibility +3..10`
+- `blackmailAmount` setzen
+- kleiner oder kein sofortiger Reputationsschaden
+- optional separates Log oder spätere Forderung
+
+Wenn ihr noch kein echtes Erpressungssystem habt:
+
+- `blackmailAmount` trotzdem setzen
+- `notes` befüllen
+- UI zeigt den Vorgang als abgeschlossen mit Erpressungssumme
+
+## Mindestregeln für Erfolg
+
+Erfolgswahrscheinlichkeit sollte steigen bei:
+
+- hoher vorhandener Sichtbarkeit
+- niedriger Diskretion
+- mehreren aktiven Liebschaften
+- bereits bekannten unehelichen Kindern
+
+Erfolgswahrscheinlichkeit sollte sinken bei:
+
+- hoher Diskretion
+- niedriger Sichtbarkeit
+- standesgemäß geführter Mätresse/Favorit auf hohem Rang
+
+## Folgewirkungen auf Lovers-System
+
+Bei Erfolg darf der Daemon auslösen:
+
+- `falukant_family_scandal_hint`
+- `falukantUpdateFamily` mit `reason = scandal`
+- zusätzlich normale Status-Updates
+
+Wenn `goal = expose`, sollte mindestens eine dieser Wirkungen eintreten:
+
+- Sichtbarkeit steigt
+- Ruf sinkt
+- Skandalwahrscheinlichkeit steigt
+
+Wenn `goal = blackmail`, sollte mindestens eine dieser Wirkungen eintreten:
+
+- `blackmailAmount > 0`
+- kleiner Sichtbarkeitsanstieg
+- interner Merker für spätere Forderung
+
+## UI-Erwartung
+
+Das Frontend dieses Projekts erwartet derzeit:
+
+- `type`
+- `goal`
+- `status`
+- `additionalInfo.blackmailAmount`
+
+Optional nutzbar später:
+
+- `discoveries`
+- `visibilityDelta`
+- `reputationDelta`
+- `notes`
+
+## Definition of Done
+
+Die externe Umsetzung gilt als ausreichend, wenn:
+
+1. `investigate_affair`-Einträge mit `status = pending` verarbeitet werden
+2. `result.status` danach nicht mehr `pending` ist
+3. `goal = expose` und `goal = blackmail` verschieden behandelt werden
+4. mindestens Sichtbarkeit oder Reputationswirkung zurückgeschrieben wird
+5. `blackmailAmount` bei Erpressung gesetzt werden kann
--- a/docs/FALUKANT_UNDERGROUND_AFFAIR_PLAN.md
+++ b/docs/FALUKANT_UNDERGROUND_AFFAIR_PLAN.md
@@ -0,0 +1,67 @@
+# Falukant: Restplan für Liebschafts-Ermittlung im Untergrund
+
+## Ziel
+
+Die neue Untergrundaktivität `investigate_affair` soll nicht nur auswählbar sein, sondern einen vollständigen technischen Pfad bekommen:
+
+- Aktivität anlegen
+- Aktivität in der UI sichtbar machen
+- Ergebnisstruktur vorbereiten
+- externe Daemon-Auswertung eindeutig beschreiben
+
+## Arbeitspakete
+
+## UGA1. Aktivitätstyp im System verankern
+
+Status: abgeschlossen
+
+- Untergrundtyp `investigate_affair` anlegen
+- Ziele `expose` und `blackmail` definieren
+- UI-Auswahl in `UndergroundView` ergänzen
+- Produktions-SQL für Bestandsdatenbank bereitstellen
+
+## UGA2. Aktivitätenliste im Frontend nutzbar machen
+
+Status: abgeschlossen
+
+- echten GET-Endpunkt für Untergrundaktivitäten bereitstellen
+- `UndergroundView.loadActivities()` aktivieren
+- Aktivitäten mit Typ, Ziel, Status und Zusatzinformation anzeigen
+
+## UGA3. Ergebnisstruktur für spätere Auswertung definieren
+
+Status: abgeschlossen
+
+- Ergebnisformat für `underground.result` dokumentieren
+- Zustände `pending`, `resolved`, `failed` festlegen
+- Felder für `discoveries`, `visibilityDelta`, `reputationDelta`, `blackmailAmount` vorbereiten
+
+## UGA4. Externe Daemon-Übergabe für Liebschafts-Ermittlung
+
+Status: abgeschlossen
+
+- Handoff-Dokument für den externen Daemon ergänzen
+- beschreiben, wie `investigate_affair` gelesen und aufgelöst wird
+- beschreiben, welche Folgewirkungen auf Liebschaften, Ansehen und Erpressung entstehen dürfen
+
+## UGA5. Spätere Ausbaustufe
+
+Status: bewusst offen
+
+- echte Erpressungszustände im Spielmodell
+- UI für Forderungen, Schweigegeld, Gegenmaßnahmen
+- eigene WebSocket-Events für abgeschlossene Untergrund-Ergebnisse
+
+## Definition of Done
+
+Der lokale Teil gilt als fertig, wenn:
+
+1. `investigate_affair` im Untergrundformular auswählbar ist
+2. neue Aktivitäten in der Aktivitätenliste sichtbar sind
+3. Typ, Ziel und Status in der UI lesbar sind
+4. ein eindeutiges Result-Schema für den externen Daemon dokumentiert ist
+5. die externe Daemon-Übergabe die neue Aktivität vollständig beschreibt
+
+## Restgrenze
+
+Die tatsächliche Erfolgs-/Misserfolgsberechnung, das Aufdecken von Liebschaften und die Erpressungswirkung werden nicht in diesem Projekt ausgeführt, sondern im externen Daemon.