# Planung und Quellen

Dieser Ordner fasst Ideen, Skizzen, Kopien von Mockups und andere Rohdaten zusammen, die nicht im Webroot liegen sollen.

Beispiele:
- Notizen zur UI-Story oder zum Menüfluss
- Wireframes im SVG/PNG-Format
- Prototyp-Dateien (.psd, .xd, .fig, ...)
- Auszug aus Konzeptpapiere oder Projekt-Backlog

Trage neue Einträge ein, bevor du sie weiterverarbeitest und eventuell in `web/` übernimmst.

---

## Offene Punkte & Plan: Auto-Cost + Temperatur-UI (SSOT v1.2)

### Kontext (SSOT)
- Auto-Cost (Kosten/Bauzeit automatisch aus Effekten ableiten) gemäß SSOT v1.2.
- Temperatur bleibt **als °C gespeichert** und soll in der UI angezeigt werden.

### Entscheidungen
- **Auto-Cost-Profile (Option 3):**
  - `auto_cost_profile` im Blueprint hat Vorrang.
  - Fallback über Tags (z. B. `auto_cost:resource` → Profil `resource`).
  - Profile zentral in **neuer** Konfig `config/auto_cost_profiles.json`.
  - Optionaler `auto_cost_override` pro Blueprint für gezielte Abweichungen.

### ToDos (geplant)
1) **UI-Temperatur dynamisch anbinden**
   - Ressourcen-Partial erweitert (Desktop/Mobile).
   - UI-Update liest `planet.temperature_c` aus State-Response.

2) **Auto-Cost/Score berechnen (SSOT-konform)**
   - Effekt-Schema auf `amount` ausrichten.
   - Effekte: produce/consume/convert/capacity_add/queue_slots_add/points_add/modifier_add/grant_capability.
   - Deterministische Score → cost/build_time Ableitung.

3) **Auto-Cost-Profile & Weights**
   - Neue Konfig `config/auto_cost_profiles.json` mit Profilen + Tag-Mapping.
   - Gewichtstabelle/Multiplikatoren per Profil (dynamisch erweiterbar).

4) **EventQueue-Integration (generisches Modul)**
   - Auto-Cost nur bei `auto_cost: true` oder fehlenden `cost/build_time`.
   - Bestehende Blueprints mit festen Kosten bleiben unverändert.
   - **EventQueue gilt pro Planet (planet_id), nicht account-weit.**
   - **Getrennte Queues pro Kategorie** (z. B. Gebäude, Schiffe, Verteidigung, Klonen):
     - Jede Kategorie hat **eigene Slot-Limits** (z. B. Gebäude: 2/Planet; Schiffe: 10/Werft; Verteidigung: 100/Station).
     - Slots entstehen durch passende Gebäude/Capabilities je Kategorie.
   - **Gemeinsame Job-Tabelle** mit `job_type` (Kategorie) + `planet_id`, damit Abarbeitung/Services wiederverwendbar bleiben.
   - Module registrieren neue `job_type`/Limits deklarativ (kein Kernel-Patch).
   - **Queue-Löschung (modulgesteuert)**:
     - Job-Record enthält `origin_module` (welches Modul den Eintrag erzeugt hat).
     - Job-Record enthält `is_deletable` (true/false), damit das System Löschbarkeit prüft.
     - Beim Löschen wird **ein Modul-Event** (z. B. `onEventCancelled`) an `origin_module` gesendet.
       - Queue-gebundene Typen (Build/Forschung/Produktion) verdichten `queue_position` und berechnen Start/Finish neu.
       - Fixzeit-Events (z. B. Flottenbewegungen) bleiben unverändert; keine Positions-Verdichtung.
   - **Forschung**: nutzt dieselbe Job-Tabelle, aber **account-weiten Scope** (z. B. `scope_type=account`, `scope_id=user_id`) und `job_type=research`.

### Akzeptanzkriterien (grün wenn …)
- UI zeigt `temperature_c` für aktuellen Planeten (°C) in Desktop + Mobile.
- Auto-Cost berechnet deterministisch aus Effekten & Profil-Weights.
- `auto_cost_profile` überschreibt Tag-Fallback; `auto_cost_override` wirkt auf einzelnes Blueprint.
- BuildQueue nutzt Auto-Cost nur bei `auto_cost` oder fehlenden Kosten.

### Risiken/Notizen
- Effekt-Schema mismatch (`value` vs `amount`) muss konsistent gelöst werden.
- Unvollständige BuildQueue-Integration darf bestehende Flows nicht brechen.
- Konfig muss erweiterbar bleiben (neue Kategorien zur Laufzeit).