Integrate servant management into Falukant family dynamics: Added support for servant-related logic in FalukantFamilyWorker, including daily and monthly processing of servant data. Updated SQL queries to handle servant attributes and integrated servant discretion modifiers into relationship calculations, enhancing family interaction and satisfaction tracking.

docs/FALUKANT_DAEMON_HANDOFF.md

@@ -54,6 +54,7 @@ Ehe-Malus „≤ 15“ gilt pro Ehe, wenn **irgendeine** berührende Liebschaft
 1. `migrations/001_falukant_family_lovers.sql`
 2. Optional: `migrations/002_falukant_family_rename_legacy_columns.sql` bei Altbestand
 3. `migrations/003_falukant_family_marriage_buffs.sql` — Ehe-Buffs (`marriage_gift_buff_days_remaining`, `marriage_pending_feast_bonus`, `marriage_house_supply`, `marriage_no_lover_bonus_counter`); Daily-Tick schreibt Zufriedenheit + Zähler via `QUERY_UPDATE_MARRIAGE_STATE_AND_BUFFS`.
+4. `migrations/004_falukant_servants_daemon.sql` — Dienerschaft: Tick-Idempotenz + `servant_discretion_modifier` (Stammdaten-Dienerfelder kommen aus dem Backend). Siehe [`FALUKANT_SERVANTS_DAEMON.md`](./FALUKANT_SERVANTS_DAEMON.md).
 
 ### Ehe-Buffs (Daemon)
 

docs/FALUKANT_SERVANTS_DAEMON.md

@@ -0,0 +1,27 @@
+# Falukant: Dienerschaft im YpDaemon
+
+Umsetzung gemäß Projektspezifikation (Daily/Monthly, Handoff).
+
+## Voraussetzungen
+
+1. **Backend:** Stammdaten in `falukant_data.user_house` (`servant_count`, `servant_quality`, `servant_pay_level`, `household_order`) — z. B. Migration aus YourPart3.
+2. **Daemon:** `migrations/004_falukant_servants_daemon.sql` ausführen (Tick-Spalten + `servant_discretion_modifier` + `servants_underfunded`).
+
+## Code
+
+- Logik: `src/worker/falukant_servants.rs`
+- SQL: `src/worker/sql.rs` (Abschnitt Dienerschaft)
+- Ausführung: **`FalukantFamilyWorker`** ruft bei gesetztem Servant-Schema **vor** Liebschafts-Daily/Monthly `run_daily` / `run_monthly` auf (keine Race mit Liebschafts-Ticks).
+
+## WebSocket
+
+Wie Spec: `falukantUpdateFamily` mit `reason`: `daily` oder `monthly`, danach `falukantUpdateStatus` — **kein** eigener Diener-`reason`.
+
+## Liebschaften (B7 Teil)
+
+`QUERY_GET_ACTIVE_LOVER_ROWS_FOR_DAILY` liefert `servant_disc_u1` / `servant_disc_u2` (MAX `servant_discretion_modifier` je `user_house` des Partners). Die Sichtbarkeits-Drift addiert `(u1+u2)/2 / 4` auf `v_net`.
+
+## Noch offen (Backlog)
+
+- **B8 Untergrund:** siehe [`FALUKANT_UNDERGROUND_INVESTIGATE_AFFAIR.md`](./FALUKANT_UNDERGROUND_INVESTIGATE_AFFAIR.md) (`investigate_affair` im `UndergroundWorker`).
+- **Feinbalancing** (B9).

docs/FALUKANT_UNDERGROUND_INVESTIGATE_AFFAIR.md

@@ -0,0 +1,49 @@
+# Untergrund: `investigate_affair`
+
+Wie die anderen Underground-Tasks: Zeile in `falukant_data.underground` mit `result IS NULL`, nach ≥1 Tag verarbeitet der `UndergroundWorker`.
+
+## Typ in der Datenbank
+
+In `falukant_type.underground` einen Eintrag mit **`tr = 'investigate_affair'`** und Backend-Logik, die den Auftrag anlegt.
+
+## Semantik (Spec: Liebschaften & Untergrund)
+
+| Feld | Bedeutung |
+|------|-----------|
+| `performer_id` | Charakter-ID des Ausspionierenden |
+| `victim_id` | Charakter-ID des Opfers (mit Liebschaft) |
+| `parameters` (JSON) | `goal`: `"expose"` (Standard) oder `"blackmail"`; optional `relationship_id` (int): feste Liebschaft — sonst **höchster `discoveryScore`** unter allen aktiven `lover`-Beziehungen |
+
+### `discoveryScore` (Auswahl der Ziel-Liebschaft)
+
+Gewichtung u. a.: `visibility`, `discretion`, `acknowledged`, Kinder (hidden/public, Deckel +20), Altersstufen, Haushalt/Diener (Leak-Bonus, Deckel +15), mehrere aktive Liebschaften, `status_fit`.
+
+### Erfolg
+
+- `successChance = clamp(20 + discoveryScore * 0.55, 5, 95)` (Prozent)
+- Wurf 0–100: `roll ≤ successChance * 0.55` → voller Erfolg; `roll ≤ successChance` → Teilerfolg; sonst Fehlschlag
+
+### `goal = expose`
+
+Voller/Teilerfolg: Sichtbarkeit und Diskretion des Ziel-`relationship_state` werden angepasst, Ruf des **Opfers** (`victim_id`) sinkt. Ab `visibility ≥ 60` nach Anpassung: **Sofort-Skandalprüfung** mit WebSocket (`falukant_family_scandal_hint`, `falukantUpdateFamily` mit `reason: scandal`, `falukantUpdateStatus`).
+
+### `goal = blackmail`
+
+Voller/Teilerfolg: geringere Sichtbarkeits-/Diskretions-Effekte als bei `expose`; **`blackmailAmount`** aus Basisformel (Ruf, Sichtbarkeit, Stand, Kinder) × `outcomeFactor` (1.0 / 0.55).
+
+### Fehlschlag
+
+`status: failed`, `outcome: failure`, `discoveries: null`, Hinweis `no proof` — keine DB-Änderungen an Liebschaft/Ruf.
+
+## Ergebnis-JSON (`result`)
+
+Mindestens: `status`, `outcome`, `discoveries` (Pflichtfelder laut Spec), `visibilityDelta`, `reputationDelta`, optional `blackmailAmount`, `discoveryScore`, `successChance`, `roll`, `tier`, `notes`.
+
+## WebSocket
+
+- Nach jedem Job: **`underground_processed`** (wie bisher).
+- Bei ausgelöstem **Skandal** (nur `expose` mit ausreichender Sichtbarkeit und bestandenem Wurf): wie oben.
+
+## Idempotenz
+
+Weiterhin nur Zeilen mit **`result IS NULL`**; nach Verarbeitung wird `result` gesetzt (Daemon fasst den Auftrag nicht erneut an).