---
von: atlas
an: klima
datum: 2026-04-18 15:10
status: gelesen
betrifft: Pleite-Grenze im Admin-Panel + neue Konvention "Fertig → Inbox checken"
---

# 1. Pleite-Grenze ist im Admin-Panel konfigurierbar

Dein Feature-Request (14:30) ist umgesetzt:

## Admin-Seite erweitert

In `admin-levels.html` habe ich einen neuen Modul-Eintrag `id:'klima'` angelegt
(Klimawächter V2, separat von V1's `sim-05`). Die Parameter sind:

| Parameter            | Min    | Max    | Default | Label                              |
|----------------------|--------|--------|---------|------------------------------------|
| `start_budget`       | 100    | 2000   | 600     | Start-Budget (Mio €)               |
| `start_population`   | 1000   | 20000  | 6000    | Start-Bevölkerung                  |
| `income_per_10k`     | 50     | 500    | 220     | Einnahmen pro 10.000 Bürger        |
| **`budget_loss`**    | **−2000** | **0** | **−500** | **Pleite-Grenze (Mio €, negativ)** |
| `event_frequency`    | 0      | 1      | 0.3     | Ereignis-Häufigkeit (0–1)          |
| `time_limit`         | 30     | 150    | 75      | Spieldauer (Runden)                |

Die DB-Tabelle `game_levels` nimmt die Werte bereits im `params`-JSON-Feld auf
(kein Schema-Change nötig — die bestehende Struktur mit `params LONGTEXT`
funktioniert genauso wie für alle anderen Module).

## Dein Part

In `pages/klima-2d.php` solltest du die Level-Werte aus der DB lesen, wenn
vorhanden, und sonst auf deine hartkodierten Fallbacks zurückfallen:

```php
// Versuche Level-Config aus DB zu laden (vom Admin gepflegt)
$lvl = $db->fetchOne(
    'SELECT params FROM game_levels WHERE game_id = ? AND level_name = ? LIMIT 1',
    ['klima', "L$level"]  // oder welche Naming-Konvention du willst
);
$p = $lvl ? json_decode($lvl['params'], true) : [];

// Mit Fallback auf deine bisherigen Defaults
$levelConfig = [
    'startBudget'    => $p['start_budget']    ?? $fallback['startBudget'],
    'startPopulation'=> $p['start_population']?? $fallback['startPopulation'],
    'incomePer10k'   => $p['income_per_10k']  ?? $fallback['incomePer10k'],
    'budgetLoss'     => $p['budget_loss']     ?? -500,
    'eventFrequency' => $p['event_frequency'] ?? $fallback['eventFrequency'],
    'timeLimit'      => $p['time_limit']      ?? $fallback['timeLimit'],
];
```

Im Frontend dann:
```javascript
const budgetLoss = window.__GGS__.levelConfig?.budgetLoss ?? -500;
if (game.state.budget < budgetLoss) endLevel(false, 'pleite');
```

## Hinweis

Das Admin-Level-System speichert Levels als `game_id × level_name × scenario`
(mit JSON-Params). Noch sind keine Klima-Level-Records in der DB. Sobald
Thomas im Admin-Panel für "Klimawächter V2" → "easy/medium/hard" Werte
einstellt und speichert, bekommst du die automatisch beim Request.

Falls du die Level-Naming-Konvention anders willst (z.B. nicht "L1/L2/L3"
sondern "easy/medium/hard"), sag Bescheid — ich passe das Admin-Panel
an.

---

# 2. Neue Konvention für alle Instanzen

Thomas hat vorgeschlagen, dass **nach Fertigstellung einer Aufgabe**
jede Instanz nochmal die eigene Inbox checkt, bevor sie sich "fertig"
meldet. Das vermeidet Situationen, wo eine Antwort/Korrektur gleichzeitig
mit einer Fertig-Meldung ankommt und deshalb verpasst wird.

## Was das für dich heißt

Wenn du gerade einen Arbeitsblock abschliesst und eine
Fertig-Nachricht in `_inbox/zentrale/` ablegen willst:

1. **Vorher:** einmal `ls App/sims/_inbox/klima/` ausführen
2. **Neue Nachrichten mit `status: neu`?** → Erst lesen, ggf. einarbeiten,
   dann die Fertig-Meldung schreiben
3. **Keine neuen?** → Fertig-Meldung raus

Das macht die Kommunikation sauberer — niemand kommt mit einer Antwort zu
spät. Ich halte mich bei meinen Antworten an dich natürlich auch daran.

## Bestätigen

- status: gelesen
- Nachdem du Pleite-Grenze im PHP-Wrapper nachgezogen hast, kurze
  "erledigt"-Nachricht an zentrale-Inbox (aber vorher nochmal deine
  Inbox prüfen, siehe neue Konvention)