Refactor production cost calculations and SQL query: Updated the QUERY_GET_BEST_PRODUCTION to align profit calculations with the new logic for selling prices based on knowledge levels. Enhanced documentation to clarify the ranking criteria and the relationship between production costs and pricing strategies. Adjusted related functions in director.rs to ensure consistency across the application.

docs/FALUKANT_DIRECTOR_PRODUCTION_COST.md

@@ -41,13 +41,17 @@ effektiv_stückkosten = raw × (1 − discount)
 | `PRODUCTION_HEADROOM_DISCOUNT_PER_STEP` | `0.035` | Rabatt pro Headroom-Stufe |
 | `PRODUCTION_HEADROOM_DISCOUNT_CAP` | `0.14` | maximaler Gesamtrabatt |
 
-## Worth in SQL (`QUERY_GET_BEST_PRODUCTION`)
+## Ranking in SQL (`QUERY_GET_BEST_PRODUCTION`)
 
-Sortierung nach **regionalem Erlös pro Zeiteinheit**:
+Sortierung nach **Gewinn pro Minute**, mit **demselben Verkaufs-Modell** wie `DirectorWorker::compute_piece_price_for_percent` / `compute_piece_sell_price` in `director.rs`:
 
-`(sell_cost * worth_percent/100) / production_time`
+1. **Regionaler Basispreis:** `sell_cost × (worth_percent / 100)` — mit Fahrzeug `MAX(worth_percent)` über alle Filialregionen des Users, sonst nur Region der Direktor-Filiale.
+2. **Wissensband:** effektiver Verkaufspreis = Basis × **`0.6 + 0.4 × (k/100)`** mit k = Wissen 0…100 (linear zwischen 60 % und 100 % der Basis). Entspricht `min_price + (max_price − min_price) × k/100` mit `min = 0.6 × Basis`, `max = Basis`.
+3. **k:** `(2 × knowledge Spielercharakter + knowledge Direktor) / 3` aus `falukant_data.knowledge` (Produktzeilen für Charakter bzw. Direktor).
+4. **Stückkosten:** wie `piece_production_cost` (siehe oben).
+5. **Formel:** `(Verkaufspreis/Stück − Stückkosten) / production_time`. **Steuer** im Ranking nicht abgezogen.
 
-Damit entspricht die Auswahl in etwa **„Erlös pro Minute“** (Listenpreis × Markt in der Region ÷ Dauer einer Produktionscharge). **Wissen** fließt hier **nicht** in die Reihenfolge ein (Wissen wirkt bei euch auf Qualität/Preis beim Verkauf, nicht auf die Produktwahl). Die **Stückkosten** kommen nur aus der Rust-Formel beim Abbuchen.
+**UI / Node:** Sollte dieselbe Preislogik wie der Daemon nutzen. Weicht `calcRegionalSellPriceSync` ab (z. B. 70 % statt 60 % unterhalb der Basis), Frontend an **diese** Rust-Formel anpassen — nicht umgekehrt den Daemon „blind“ an eine abweichende UI koppeln.
 
 ## Parallelproduktionen