Refactor production cost calculation in DirectorWorker: Updated the cost formula to depend on product category rather than certificate level, introducing a base cost and headroom discount mechanism. Modified SQL queries to retrieve product category and user certificate for accurate cost assessment. Enhanced documentation for clarity on the new cost structure and its implications for production management.

docs/FALUKANT_DIRECTOR_PRODUCTION_COST.md

@@ -1,40 +1,30 @@
 # Director: Stückkosten Produktion (Balancing)
 
-## Problem
+## Modell
 
-Die DB wählt das „beste“ Produkt über `QUERY_GET_BEST_PRODUCTION` (Worth-Formel mit `- 6 * ftp.category`), während der Daemon früher **nur** `certificate * 6` pro Stück abgebucht hat – **ohne** die Produktklasse. Dadurch konnten Stückkosten und Worth-Ranking auseinanderlaufen.
+- **`falukant_user.certificate`** begrenzt nur, **welche** Produkte wählbar sind (`ftp.category <= certificate` in `QUERY_GET_BEST_PRODUCTION`). Es gibt **keine** höheren Stückkosten nur wegen eines höheren Zertifikats.
+- Die **Stückkosten** hängen von der **Produktklasse** (`falukant_type.product.category`) und einer **Basis** ab; optional **Headroom-Rabatt**, wenn das Zertifikat über der Klasse des produzierten Guts liegt.
 
-## Aktuelle Formel (Rust, `DirectorWorker::calc_one_piece_cost`)
+## Formel (Rust, `DirectorWorker`)
 
 ```
-raw = certificate × PRODUCTION_COST_PER_CERT_LEVEL
-    + product_category × PRODUCTION_COST_PER_PRODUCT_CATEGORY
-effektiv = raw × (1 − headroom_discount)
+raw = PRODUCTION_COST_BASE + product_category × PRODUCTION_COST_PER_PRODUCT_CATEGORY
+headroom = max(0, certificate − product_category)
+discount = min(headroom × PRODUCTION_HEADROOM_DISCOUNT_PER_STEP, PRODUCTION_HEADROOM_DISCOUNT_CAP)
+effektiv = raw × (1 − discount)
 ```
 
-- `product_category` kommt aus `QUERY_GET_BEST_PRODUCTION` (`ftp.category`).
-- **Headroom** = `max(0, certificate − product_category)`  
-  Wenn du **nicht** am Klassenlimit produzierst (Zertifikat höher als nötig für das Produkt), gibt es einen kleinen Rabatt (Effizienz / Reserve).
-
-Konstanten in `src/worker/director.rs` (anpassen zum Feintuning):
-
 | Konstante | Standard | Bedeutung |
 |-----------|----------|-----------|
-| `PRODUCTION_COST_PER_CERT_LEVEL` | `6.0` | wie früher `×6` pro Zertifikatsstufe |
-| `PRODUCTION_COST_PER_PRODUCT_CATEGORY` | `1.0` | Material pro Produktklasse |
+| `PRODUCTION_COST_BASE` | `6.0` | fixer Basisanteil pro Stück |
+| `PRODUCTION_COST_PER_PRODUCT_CATEGORY` | `1.0` | Material / Komplexität je Produktklasse |
 | `PRODUCTION_HEADROOM_DISCOUNT_PER_STEP` | `0.035` | Rabatt pro Headroom-Stufe |
 | `PRODUCTION_HEADROOM_DISCOUNT_CAP` | `0.14` | maximaler Gesamtrabatt |
 
-## Spielerfortschritt
-
-- **Höheres Zertifikat** allein erhöht die Basis-Stückkosten linear – entspricht **besserer** Produktpalette (`ftp.category <= certificate` in SQL).
-- **Höhere Produktklasse** erhöht `raw` über `product_category` (bessere Ware = mehr Material).
-- **Zertifikat über der Produktklasse** (Headroom) senkt die effektiven Kosten – Belohnung, wenn du nicht immer nur am Limit produzierst.
-
 ## Worth in SQL
 
-Die Worth-Zeile in `QUERY_GET_BEST_PRODUCTION` sollte bei größeren Formeländerungen **mit** angepasst werden, damit der Director weiterhin sinnvoll sortiert.
+`QUERY_GET_BEST_PRODUCTION` sortiert nach einer Worth-Zeile (u. a. `- 6 * ftp.category`). Bei größeren Formeländerungen Worth **mit** anpassen, damit der Director weiterhin sinnvoll sortiert.
 
 ## Parallelproduktionen
 
-`MAX_PARALLEL_PRODUCTIONS` (aktuell 2) bestimmt, wie viele Linien pro Tick Geld binden – unabhängig von der Stückkostenformel; bei Liquiditätsproblemen ggf. auf `1` setzen.
+`MAX_PARALLEL_PRODUCTIONS` (aktuell 2) bestimmt, wie viele Linien pro Tick Geld binden — unabhängig von der Stückkostenformel.