# Director: Stückkosten Produktion (Balancing)

## Was der Daemon **nicht** macht (häufige Missverständnisse)

- **Nicht** `6 × Kategorie` (also kein reiner Multiplikator nur aus der Klassennummer).
- **Nicht** `2 × Kategorie` — im **ypdaemon**-Stand gibt es diese Formel **nicht**.
- **Nicht** „höheres Zertifikat ⇒ höhere Stückkosten“: Das Zertifikat **begrenzt** nur die Produktpalette (`ftp.category <= certificate`); es wird **nicht** als `Zertifikat × 6` o. Ä. auf die Kosten drauf multipliziert.

Die **kanonische** Berechnung lebt in Rust: `DirectorWorker::piece_production_cost` in `src/worker/director.rs` (gleiche Logik beim **Produktionsstart** und bei der **Kostenbasis für Steuer/Marge beim Verkauf** über `resolve_production_piece_cost`).

## Modell

- **`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 (Erfahrung/Reserve, nicht „Strafe“ fürs Zertifikat).

## Formel (Rust, `DirectorWorker`)

```
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_stückkosten = raw × (1 − discount)
```

**Ausgeschrieben mit den Standardkonstanten:**  
`raw = 6 + 1 × product_category` (Kategorie mindestens 1), dann Rabatt nur bei Headroom.

**Beispiele** (Standardkonstanten, ohne Rundung):

| Kategorie | Zertifikat | raw | Headroom | effektiv (ca.) |
|-----------|------------|-----|----------|----------------|
| 1 | 4 | 7 | 3 | 7 × (1 − min(0,105; 0,14)) ≈ **6,27** |
| 4 | 4 | 10 | 0 | **10** |

**Chargenkosten** beim Start einer Linie: `effektiv_stückkosten × Stückzahl` (Stückzahl bis 100 pro Linie, siehe `create_single_production`).

| Konstante | Standard | Bedeutung |
|-----------|----------|-----------|
| `PRODUCTION_COST_BASE` | `6.0` | fixer Basisanteil pro Stück |
| `PRODUCTION_COST_PER_PRODUCT_CATEGORY` | `1.0` | Aufschlag pro Produktklasse (additiv zu 6, **nicht** „6×Kategorie“) |
| `PRODUCTION_HEADROOM_DISCOUNT_PER_STEP` | `0.035` | Rabatt pro Headroom-Stufe |
| `PRODUCTION_HEADROOM_DISCOUNT_CAP` | `0.14` | maximaler Gesamtrabatt |

## Ranking in SQL (`QUERY_GET_BEST_PRODUCTION`)

Sortierung nach einer **Legacy/UI-Formel** (historisch C++), damit die Reihenfolge zur **Produkt-Ertrags-Tabelle** passt — **nicht** identisch mit dem tatsächlichen Verkauf im Tick (`compute_piece_sell_price` in `director.rs`).

1. **Effektiver Markt-Prozentsatz:** `worth_percent + (2 × knowledge Spielercharakter + knowledge Direktor) / 3`, dann `× sell_cost / 100`. `worth_percent`: mit Fahrzeug `MAX(worth_percent)` über alle Filialregionen des Users, sonst nur Region der Direktor-Filiale.
2. **Spielercharakter:** genau **einer** je User (`character.id` maximal unter `health > 0`), nicht alle `JOIN character ON user_id`.
3. **Kosten im Ranking:** **`6 × category`** (linear, ohne Headroom-Rabatt wie bei `piece_production_cost`).
4. **Formel:** `(sell_cost × (effektiver Prozentsatz) / 100 − 6 × category) / (300 × production_time)`. **Steuer** im Ranking nicht abgezogen.

**Hinweis:** Echter Stückpreis und Buchführung nutzen weiter `piece_production_cost` und das 60 %–100 %-Band auf der Basis — nur die **Auswahl „beste Produktion“** folgt der Legacy-Formel, damit Daemon und UI dieselbe Rangfolge zeigen.

## Parallelproduktionen

`MAX_PARALLEL_PRODUCTIONS` (aktuell 2) bestimmt, wie viele Linien pro Tick Geld binden — unabhängig von der Stückkostenformel.