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_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