Space-Theme/planning

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).