1

planning/README.md

@@ -9,3 +9,60 @@ Beispiele:
 - 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).