docs: ticket 14 (kampfformeln) aufloesen, nachtraege an 01 07 08 11, registry-liste und initiative ins glossar

.scratch/rustkeep-1.0/issues/01-effekt-vokabular.md

@@ -116,6 +116,22 @@ color  = "cyan"
 `data/` kennt nur `char` und ein Farbnamen-Enum, `ui/theme.rs` übersetzt in `ratatui::Color` — `game/`
 und `data/` bleiben damit weiterhin ratatui-frei.
 
+### Nachtrag aus Ticket 14: `damage` skaliert, und `flee` ist die achte Aktion
+
+Die `damage`-Aktion oben kennt nur `amount = 12`, also einen festen Wert. Ein Waffenangriff soll aber
+das `damage`-Attribut des Angreifers verwenden — das war gar nicht ausdrückbar. Die Menge ist deshalb
+immer:
+
+```
+menge = amount + scale * damage-Attribut(Verursacher)      # beide optional, Standard 0
+```
+
+Eine Formel für alles: Basisangriff `scale = 1.0` · Feuerball `amount = 20` · Wuchtschlag
+`scale = 1.5` · Mischformen beides. Keine zwei Modi, kein Sonderfall für `core:attack`.
+
+Dazu **`flee` als achte Aktion** — Ticket 11 hat Flucht zu einer Fähigkeit gemacht, und die braucht
+eine Aktion, die sie ausführt. Der Katalog hat damit acht Einträge.
+
 ### Bewusst nicht entschieden
 
 Das **Bedingungsvokabular** für `condition`. Es kommt aus Ticket 08, damit Quests und Modifikatoren

.scratch/rustkeep-1.0/issues/07-game-state-baum.md

@@ -162,6 +162,25 @@ nicht auswertbar — die Funktion wüsste nicht, gegen wen geschlagen wird. Der
 Dazu kommt `events: Vec<Event>` als Feld in `Game`: Ticket 08 arbeitet Events als Warteschlange ab,
 weil synchrones Feuern über `self.quests` iterieren müsste, während `self.apply` erneut läuft.
 
+### Nachtrag aus Ticket 14
+
+**`enemies` ist der laufende Kampf, nicht die Etage.** Das stand oben nie ausdrücklich da und wäre
+sonst falsch geraten worden: Bei Grid-Erkundung mit Menü-Kampf griffe sonst der Skelettkrieger drei
+Räume weiter jeden Zug mit an. Leer bedeutet kein Kampf; gefüllt wird die Liste von der Etage (10).
+
+Zwei neue Felder am `Creature`:
+
+- `initiative: i32` — einmal beim Betreten des Kampfes gewürfelt. Bewusst ein Zahlenwert am Wesen und
+  keine Reihenfolgeliste aus `CreatureRef`: Die wäre eine **zweite** Indexliste mit demselben
+  Ungültigkeitsproblem beim Tod eines Gegners.
+- `cooldowns: HashMap<AbilityId, u32>` — Abklingzeiten in Zügen.
+
+Dazu der RNG-Seed als Feld in `Game`, damit Nachladen nicht neu würfelt.
+
+Und die Antwort auf die Frage, die 07 offen an 14 gereicht hatte: **Tote Gegner werden am Ende von
+`Game::execute` entfernt**, nach dem Leerarbeiten der Event-Warteschlange. Innerhalb eines Zuges
+bleiben Indizes stabil.
+
 ### Auflagen an andere Tickets
 
 - **08 Event- und Trigger-System**: Form von `QuestProgress`; das Bedingungsvokabular, das 01 bereits

.scratch/rustkeep-1.0/issues/08-event-trigger-system.md

@@ -102,6 +102,20 @@ Stufe (c) kann niemand ein eigenes Event *auslösen* — ein namespaced Event w
 Kommt Scripting (Ticket 13), wird `emit_event` eine gewöhnliche Aktion und die Liste bekommt eine
 `Custom(String)`-Variante. Ein Zusatz, kein Umbau.
 
+### Nachtrag aus Ticket 14: elf Events statt neun
+
+`combat_started` und `combat_ended { outcome: Victory | Fled }` kommen dazu. Ohne sie ist „gewinne drei
+Kämpfe" nicht formulierbar, und `combat_ended` **braucht** die Unterscheidung — sonst zählt Weglaufen
+als Erfolg.
+
+Beide mit `source = Player`, ohne `target`. Platzierung im Zugablauf aus 14: `combat_started` bei
+Schritt 1 neben `turn_started`, `combat_ended` bei Schritt 5 direkt nach dem `retain` — dann ist die
+Gegnerliste bereits leer und ein Trigger sieht den Endzustand statt einer halb aufgeräumten
+Zwischenstufe.
+
+Keine dritte Variante für den Tod des Helden: `creature_died` mit `source = Player` deckt ihn ab, und
+danach gibt es ohnehin keinen Trigger mehr, der etwas davon hätte.
+
 ### Warteschlange statt Rekursion
 
 Events landen in `Game.events: Vec<Event>` und werden nach der laufenden Aktion in einer Schleife

.scratch/rustkeep-1.0/issues/11-ui-geruest-screen-modell.md

@@ -120,6 +120,11 @@ Trank.
 `MainMenu` (trägt die Ladewarnungs-Zeile aus 04) · `CharacterCreation` (Registry-Schleife aus 02) ·
 `Explore` · `Combat` · `Inventory` · `CharacterSheet` · `QuestLog` · `Shop` · `Dialog` · `Confirm`
 
+**Nachtrag aus Ticket 14: `GameOver` als elfter Screen**, Vollbild. Die lazy Variante — zurück ins
+`MainMenu` mit einer Meldungszeile — wurde bewusst verworfen: Ein Abstiegs-Roguelike lebt davon, dass
+der Lauf am Ende *erzählt* wird (Etage, Zug, Gold, Todesursache). Das ist der Moment, für den man fünf
+Etagen gespielt hat, und kein anderer Screen kann ihn übernehmen.
+
 Kein `ItemDetail`-Popup: Die Inventarliste zeigt Details in einer Seitenspalte, das ist ein Layout und
 kein Screen. `Shop` bleibt getrennt von `Dialog`, weil Handel zwei Listen nebeneinander braucht und
 der Dialog eine Textfläche mit Antwortoptionen.

.scratch/rustkeep-1.0/issues/14-kampfformeln-und-rundenablauf.md

@@ -1,7 +1,7 @@
 # 14 — Kampfformeln und Rundenablauf
 
 Type: grilling
-Status: open
+Status: resolved
 Blocked by: 01
 
 ## Question
@@ -41,3 +41,183 @@ Eine Frage fällt zusätzlich an, die 07 nur benennen konnte: **Wann werden tote
 nicht — eine Aktion, die mitten im Zug einen Gegner tötet, verschiebt die Adressen aller
 nachfolgenden. Der Rundenablauf muss festlegen, ob am Zugende, am Rundenende oder gar nicht
 kompaktiert wird (Alternative: Tote bleiben mit einem Flag stehen).
+
+## Answer
+
+Begriffe im [Glossar](../../../CONTEXT.md). **Zahlen gehören nicht hierher** — die Map hält Balancing
+getrennt; hier stehen Formeln und Ablauf.
+
+### Rundenablauf
+
+**Ein Zug = Spielerhandlung plus alle Gegnerreaktionen.** Nicht jede Handlung ein eigener Zug: Bei drei
+Gegnern tickte ein Gift-Debuff sonst viermal pro Runde, und ein Tastendruck erzeugte vier Züge — das
+bräche die Zusage aus 11, die Ticket 12 gerade gemessen hat.
+
+Reihenfolge über **Initiative**, einmal beim Betreten des Kampfes aus `dexterity` plus Wurf gewürfelt
+und als `i32` **am Wesen** gehalten. Ausdrücklich *nicht* als Reihenfolgeliste aus `CreatureRef`: Die
+wäre eine zweite Indexliste, die beim Tod eines Gegners genauso ungültig wird wie die erste. Ein
+Zahlenwert am Wesen verschwindet mit ihm, die Sortierung stimmt weiter. Gleichstand geht an den
+Spieler — deterministisch und zu seinen Gunsten.
+
+`dexterity` speist damit Initiative *und* Ausweichen. Absicht, aber 15 sollte es beim Balancing wissen.
+
+```
+Game::execute(cmd, reg):
+  1. turn_started (+ combat_started, falls der Kampf gerade beginnt) in die Warteschlange
+  2. befristete Modifikatoren ticken, Ausdauer regeneriert, Abklingzeiten sinken
+  3. Teilnehmer handeln in Initiativreihenfolge, Spieler-Command an seinem Platz
+     -> Abbruch, sobald der Held tot ist
+  4. nach JEDER einzelnen Handlung die Warteschlange leerarbeiten (bis leer oder 100)
+  5. retain auf tote Gegner, danach ggf. combat_ended
+  6. turn += 1
+```
+
+Schritt 4 nach jeder Handlung statt einmal am Zugende: Sonst schlägt ein Gegner zu, den ein
+Dornenpanzer eine Handlung zuvor getötet hat. Schritt 5 erst **nach** dem Leeren: Sonst zeigt ein
+Trigger auf `creature_died` auf einen bereits entfernten Gegner. Innerhalb eines Zuges müssen Indizes
+stabil bleiben — über Zuggrenzen hinweg hält ohnehin niemand ein `CreatureRef`, die UI liest neu.
+
+Genau **eine** Handlung pro Zug, kein Ausdauer-Budget. `max_stamina` ist die Ressource für
+Fähigkeiten — das beantwortet die Frage „wozu sonst" aus dem Ticketkörper.
+
+Stirbt der Held mitten im Zug, bricht der Zug ab (laufende Handlung samt Warteschlange noch zu Ende).
+Zwei weitere Gegner, die auf eine Leiche einschlagen, erzeugen nur Kampflog und Trigger auf ein Wesen,
+das die Runde nicht mehr erlebt.
+
+### Formeln
+
+```
+p_treffer = clamp(hit_chance(A, gegen=B) - dexterity(B) * AUSWEICH, 0.05, 0.95)
+
+roh    = attribute(damage, A, gegen=B)      # 01-Stapelung, bedingte Modifikatoren inklusive
+krit   = rand() < clamp(critical_chance(A), 0.0, 1.0)
+roh    = roh * critical_factor(A)   falls krit
+r      = clamp(resistance(B, typ), -1.0, 0.8)
+final  = max(1, round(roh * (1.0 - r)))
+
+p_flucht = clamp(0.5 + (dexterity(Held) - dexterity(schnellster Gegner)) * FLUCHT, 0.1, 0.9)
+```
+
+**Die Frage aus dem Ticketkörper löst sich auf.** Ob `critical_factor` den Rohschaden oder den
+geminderten multipliziert, ist mathematisch belanglos: `roh × kf × (1−r)` ist dasselbe wie
+`roh × (1−r) × kf`. Festzulegen war nur, dass beide multiplikativ *bleiben*.
+
+Drei Klemmbereiche, jeder mit Grund:
+
+- **Resistenz bei `0.8`** — bei `1.0` wäre ein Wesen immun, und Immunität ist keine Zahl, sondern ein
+  Spielabbruch. Nach unten bis `-1.0`, damit Verwundbarkeit ausdrückbar bleibt („Untote nehmen
+  doppelten heiligen Schaden").
+- **`max(1, …)`** — ein Treffer macht nie null, sonst gibt es Kämpfe, die rechnerisch nie enden.
+- **`0.05 / 0.95` beim Treffen** — sonst wird ein hochgezüchteter Verteidiger unangreifbar und ein
+  hochgezüchteter Angreifer unfehlbar. Beides Sackgassen, die man erst auf Etage 5 bemerkt.
+
+Keine Schadensstreuung für 1.0: Der Krit liefert die Varianz bereits, Streuung wäre ein zweiter
+Zufallsknopf ohne eigene Entscheidung dahinter.
+
+### Zufall
+
+Eigener xorshift64* — acht Zeilen statt einer Dependency. Der Seed liegt als Feld in `Game` und damit
+**im Speicherstand**.
+
+Das ist keine Implementierungsfrage, sondern eine Spielentscheidung: **Nachladen würfelt nicht neu.**
+Derselbe Angriff führt nach dem Laden zum selben Ergebnis, Save-Scumming läuft ins Leere. Ein
+Abstiegs-Roguelike lebt von Entscheidungen mit Konsequenzen.
+
+### Fähigkeiten — die Bestellung aus Ticket 02
+
+```toml
+[[abilities]]
+id       = "core:power_strike"
+name     = "Wuchtschlag"
+symbol   = "!"
+color    = "red"
+cost     = 15          # Ausdauer
+cooldown = 3           # Zuege
+condition = [ … ]      # optional, Grammatik aus 08
+actions  = [ { action = "damage", scale = 1.5, damage_type = "blunt", target = "target" } ]
+```
+
+**Nur Ausdauer, kein zweiter Ressourcenpool.** Mana wäre ein zweites Attribut, eine zweite
+Regeneration, eine zweite Anzeige und eine zweite Sperrregel. Die Decke: Ein Mod, der Mana will,
+bräuchte ein Engine-Attribut — ein Nachtrag an 01, kein Problem, das ein Modder selbst lösen kann.
+
+**Abklingzeit in Zügen**, als `cooldowns: HashMap<AbilityId, u32>` am `Creature`. Sie als befristete
+Modifikatoren zu tarnen wäre clever und genau die Sorte Cleverness, die man um drei Uhr nachts
+entziffert.
+
+**Gesperrt heißt**: Ausdauer < `cost`, oder `cooldown > 0`, oder `condition` unerfüllt. Auslösen ergibt
+dann `Outcome::Rejected("Nicht genug Ausdauer")` aus Ticket 12 und **kostet keinen Zug**. Die Regel
+steht im Spielkern, nicht in der UI — sonst kennt ein Script sie nicht.
+
+**Ausdauer regeneriert pro Zug** um einen festen Betrag. Das gibt `Wait` aus Ticket 11 seinen Zweck und
+macht Ausdauer zu einer Entscheidung statt zu einem Countdown.
+
+Eine misslungene Flucht ist übrigens `TurnPassed`, keine Zurückweisung: Der Versuch hat stattgefunden,
+die Gegner haben gehandelt. `Rejected` bleibt dem Fall vorbehalten, dass gar nichts passiert ist.
+
+### Gegner — die achte Registry
+
+Beim Aufschreiben der KI fiel eine Lücke auf, die seit 02 offen lag: **Wesen stehen in keiner
+Registry.** 02 hatte fünf, 07 ergänzte Affixe, 08 Quests — woher Gegnerdefinitionen kommen, hat nie
+jemand gesagt, obwohl 10 sie in Räume setzen und 16 Beute an sie hängen muss.
+
+```toml
+[[creatures]]
+id      = "core:skeleton"
+name    = "Skelett"
+symbol  = "s"
+color   = "white"
+tags    = ["core:undead"]
+base    = { max_health = 30, damage = 6, hit_chance = 0.7, dexterity = 3 }
+abilities = ["core:attack", "core:bone_throw"]
+ai = [
+  { condition = [ { check = "attribute", who = "self", attribute = "health", below = 0.3 } ],
+    ability = "core:flee" },
+  { ability = "core:attack" },        # ohne condition = greift immer
+]
+```
+
+`ai` ist eine **geordnete Liste**, der erste passende *und verfügbare* Eintrag gewinnt — dieselbe
+Bedingungsgrammatik wie überall sonst, kein neues Vokabular. Passt nichts, **setzt der Gegner aus**;
+einer, der die Runde blockiert, wäre schlimmer als einer, der nichts tut.
+
+Eine `ai`-Liste **ohne bedingungslosen letzten Eintrag** gibt eine Ladewarnung über die Maschinerie aus
+04. Das ist fast immer ein Versehen, und zur Laufzeit erkennt man es nur daran, dass ein Gegner
+gelegentlich stillsteht — die teuerste Sorte Fehler.
+
+Boss-Phasen sind damit *nicht* gelöst, aber vorbereitet: Die Liste trägt sie, was fehlt, ist der
+Phasenbegriff.
+
+### Balance als Daten — ausdrückliche Ausnahme zu Ticket 03
+
+Fünf Stellknöpfe entstehen hier: `AUSWEICH`, `FLUCHT`, Ausdauer-Regeneration, Resistenz-Deckel und
+Treffer-Klemmbereich. Sie liegen als `[balance]`-Tabelle in TOML und verschmelzen **feldweise** über
+die Ladereihenfolge.
+
+Das widerspricht der Ganz-oder-gar-nicht-Regel aus 03, und zwar bewusst: Ein Mod, der nur `AUSWEICH`
+dreht, müsste sonst alle fünf Werte abschreiben, und ein sechster Knopf in der nächsten Engine-Version
+bräche ihn stillschweigend.
+
+Die Ausnahme bleibt eng, weil ihre Begründung eng ist: **`[balance]` hat ein festes, der Engine
+bekanntes Schema.** Genau das fehlte bei Inhalt mit offenen Feldern — Modifikator- und Aktionslisten
+bräuchten einen Merge-Algorithmus, und das war 03s Argument gegen feldweises Patchen. Hier greift es
+nicht.
+
+Standardwerte liegen in der Engine, nicht in `core`. Dann ist ein Mod, der einen Knopf dreht, eine
+Zeile lang.
+
+### Vier Nachträge an geschlossene Tickets
+
+| Ticket | Nachtrag |
+|---|---|
+| **01** | `damage`-Aktion: `menge = amount + scale * damage-Attribut(Verursacher)`, beide Felder optional (Standard 0). Deckt Basisangriff (`scale = 1.0`), Feuerball (`amount = 20`) und Wuchtschlag (`scale = 1.5`) mit *einer* Formel. Dazu `flee` als **achte Aktion** |
+| **07** | `initiative: i32` und `cooldowns: HashMap<AbilityId, u32>` am `Creature`; RNG-Seed in `Game`; **`enemies` ist der laufende Kampf**, nicht die Etage |
+| **08** | `combat_started` und `combat_ended { outcome: Victory \| Fled }` — die Eventliste wächst auf **elf**. Der Tod des Helden braucht keine dritte Variante, `creature_died` mit `source = Player` deckt ihn ab |
+| **11** | **`GameOver`** als elfter Screen, Vollbild. Bewusst nicht die lazy Variante mit einer Meldungszeile im Hauptmenü: Ein Abstiegs-Roguelike lebt davon, dass der Lauf am Ende erzählt wird — Etage, Zug, Gold, Todesursache |
+
+### Auflagen an andere Tickets
+
+- **10 Raum-Prefab-Format**: füllt `Game.enemies`; Kampfbeginn ist ein Prefab-Ereignis.
+- **15 Progression**: was bei Sieg passiert (EXP), und die Zahlen hinter allen Formeln inklusive der
+  fünf `[balance]`-Knöpfe.
+- **16 Loot-Tabellen**: Beute hängt an der `creatures`-Registry, die hier entstanden ist.