Falukant: Daemon-Handoff für Ehe und Hausfrieden

Dieses Dokument beschreibt den Stand nach Phase A und die Rolle des externen Daemons (Übergabe Backend ↔ YpDaemon).

1. Was im Projekt jetzt vorhanden ist

Backend-/API-seitig vorhanden:

relationship_state.marriage_satisfaction
relationship_state.marriage_public_stability
aktive Liebschaften mit:
- visibility
- discretion
- maintenance_level
- status_fit
- months_underfunded
- acknowledged
user_house mit:
- servant_count
- servant_quality
- servant_pay_level
- household_order
Family-API liefert jetzt zusätzlich:
- householdTension
- householdTensionScore
- householdTensionReasons

Direkte Spieleraktionen vorhanden:

POST /api/falukant/family/marriage/spend-time
POST /api/falukant/family/marriage/gift
POST /api/falukant/family/marriage/reconcile
POST /api/falukant/houses/order

2. Daily-Input für den externen Daemon

Pro betroffenem Falukant-User:

falukant_user.id
user.id / user.hashed_id
aktive Ehe-relationship mit relationship_state
aktive Liebschaften mit relationship_state
Kinder mit:
- birth_context
- legitimacy
- public_known
Haus mit:
- servant_count
- servant_quality
- servant_pay_level
- household_order
Charakter mit:
- reputation
- title_of_nobility

3. Was der Daemon täglich berechnen soll

Ehe

Drift von marriage_satisfaction
Drift von marriage_public_stability
Einfluss aus:
- sichtbaren Liebschaften
- unterfinanzierten Liebschaften
- Standesunterschieden
- Dienerschaft / Haushaltsordnung
- zu jungen Liebschaften

Hausfrieden

Der Daemon soll intern einen numerischen Spannungswert pflegen oder berechnen:

householdTensionScore 0..100

Einflussfaktoren:

sichtbare Liebschaften
anerkannte Liebschaften
unterfinanzierte Liebschaften
Kinder aus Liebschaften
Haushaltsordnung
Dienerschaft
schwache Ehe

UI-Ableitung:

0..24 => low
25..59 => medium
60..100 => high

4. Was der Daemon zurückschreiben soll

Pflicht:

relationship_state.marriage_satisfaction
relationship_state.marriage_public_stability
lover-state-Felder bei Änderungen:
- visibility
- discretion
- months_underfunded
- optional notes_json / flags_json
falls eigener Persistenzwert eingeführt wird:
- household_tension_score

Wenn kein eigener Persistenzwert eingeführt wird:

der Daemon darf den Spannungswert auch nur berechnen
die API kann ihn weiterhin aus Ehe, Liebschaften, Kindern und Haus ableiten

5. Socket-/Refresh-Verhalten

Wenn Daily-/Monthly-Verarbeitung Ehe oder Hausfrieden betrifft:

falukantUpdateFamily mit reason: "daily" oder reason: "monthly"
danach falukantUpdateStatus

Wenn ein Sonderereignis entsteht:

reason: "scandal" zusätzlich

6. Wichtige Phase-A-Regel

Die neuen Direktaktionen geben nur Sofortimpulse:

spend-time
gift
reconcile
house/order

Der Daemon ist weiterhin verantwortlich für:

Rückdrift
Gegenkräfte
Langzeiteffekte
Balancing

Kurz:

UI/Backend setzen kleine direkte Impulse
der Daemon bestimmt die dauerhafte Entwicklung

Anhang: Abgleich YpDaemon (dieses Repo)

Thema	Stand in YpDaemon
Ehe-Zufriedenheit, Buffs, Drift (`marriage_drift_*`)	`FalukantFamilyWorker` + Migrationen `001`/`003`, siehe `FALUKANT_DAEMON_HANDOFF.md`
`marriage_public_stability` (Daily-Drift)	Migration `005`, `QUERY_GET_MARRIAGE_ROWS` / `QUERY_UPDATE_MARRIAGE_STATE_AND_BUFFS`, Logik in `falukant_family.rs` (Einfluss: sichtbare/unterfinanzierte/anerkannte Liebschaften, Stand, Alter, Haushalt/Diener, schwache Ehe)
`household_tension_score` (0..100)	Migration `005`, berechnet im Daily-Tick, persistiert in `user_house`; UI-Band low/medium/high weiterhin aus Score ableitbar (0–24 / 25–59 / 60–100)
Liebschaften (visibility, discretion, …, `acknowledged`, `months_underfunded`)	Daily-Query erweitert; Tension-Aggregation nutzt diese Felder
Dienerschaft / `household_order`	`falukant_servants.rs` + Migration `004`; zusätzlich in Ehe-Stabilität und Haus-Spannung
WebSocket	Bei Änderung von Ehe oder Spannung: `falukantUpdateFamily` mit `reason: "daily"` (wie bisher)
HTTP-Routen (`spend-time`, `gift`, …)	Liegen im Backend (nicht im Daemon-Repo)

4.5 KiB Raw Blame History Unescape Escape