feat: when-filter am trigger schliesst die luecke aus m3

condition fragt Wesen, when filtert das Ereignis. Getrennt, weil dieselbe
Bedingungsgrammatik auch beim Auslesen eines Attributs laeuft — dort gibt es
kein Event, und eine Nutzlast-Pruefung in condition waere im Trigger sinnvoll
und am Modifikator immer falsch, ohne dass der Modder es sieht.

Nutzlast zurueck: damage_type und prefab. critical und amount bleiben draussen,
bis jemand sie fordert.

Dazu Item.triggers/actions/abilities und Trigger-Suche in der Ausruestung —
mods/core/items.toml belegt es mit einem Dornenpanzer, der NUR Feuer
reflektiert.

45 Tests.

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

@@ -82,16 +82,46 @@ Beim Bauen kamen zwei Prüfungen dazu, die oben fehlten:
   Motivbeispiel, hat aber kein Feld dafür festgelegt. Ohne es bräuchte jeder Wahrscheinlichkeitseffekt
   ein Script — und Scripting liegt laut 13 hinter 1.0.
 
-### Offene Lücke aus M3: ein Trigger sieht sein Event nicht
+### Nachtrag: `when` — der Ereignisfilter am Trigger
 
-Die Events oben tragen Nutzlast (Schadenstyp, Prefab-ID, Menge) — **die Bedingungsgrammatik kann sie
-nicht prüfen.** `Check` sieht nur Wesen, nie das Ereignis. Damit ist „Dornenpanzer reflektiert nur
-Feuer" oder „nur bei kritischen Treffern" derzeit nicht formulierbar.
+Die Lücke, die M3 aufgedeckt hat: Die Events oben tragen Nutzlast, aber **die Bedingungsgrammatik kann
+sie nicht prüfen** — `Check` fragt immer ein *Wesen* (`who`), nie das Ereignis. „Dornenpanzer
+reflektiert nur Feuer" war damit nicht formulierbar.
 
-In M3 wurden `Event.damage_type` und `Event.label` deshalb gestrichen: Felder, die niemand auslesen
-kann, sind Kommentare in Feldform. Was fehlt, ist eine Prüfungsfamilie über die Nutzlast — etwa
-`{ check = "damage_type", value = "fire" }`. Zu entscheiden, bevor Affixe und Gegenstands-Trigger
-kommen (M4), denn dort werden solche Effekte erwartet.
+Gelöst wird das mit einem **eigenen Feld am Trigger**, nicht mit einer weiteren Prüfung in `condition`:
+
+```toml
+[[triggers]]
+on   = "damage_taken"
+when = { damage_type = "fire" }
+condition = [ { check = "has_tag", who = "target", value = "core:undead" } ]
+actions = [ { action = "damage", amount = 3, damage_type = "fire", target = "target" } ]
+```
+
+**`condition` fragt Wesen, `when` filtert das Ereignis.** Der Grund für die Trennung ist der
+Auswertungskontext: Dieselbe Bedingungsgrammatik läuft auch beim **Auslesen eines Attributs** (bedingte
+Modifikatoren aus 01), und dort gibt es kein Event. Eine Nutzlast-Prüfung in `condition` wäre also eine
+Prüfung, deren Wahrheitswert vom Kontext abhängt — im Trigger sinnvoll, am Modifikator immer falsch. Der
+Modder sähe das nicht, er sähe nur, dass sein Modifikator nie greift. Genau die stille Falle, die dieses
+Projekt an anderen Stellen bewusst vermieden hat (Ring heilt beim Anlegen; `level` gegen `base.level`).
+
+Was Ticket 08 ursprünglich verhindern wollte, waren **zwei Bedingungsgrammatiken über Wesen**, die
+auseinanderdriften. Ein Ereignisfilter ist keine zweite Fassung davon, sondern eine andere Frage: nicht
+*wer*, sondern *was gerade passiert ist*.
+
+**Nutzlast, die zurückkommt:** `damage_type` (bei `attack_hit` und `damage_taken`) und `prefab` (bei
+`room_entered`, sonst wäre die Quest „betrete die Bibliothek" nicht formulierbar). `critical` und
+`amount` bleiben draußen — für beide gibt es kein Beispiel, das jemand *gefordert* hat, und das ist der
+Unterschied zwischen einem Bedarf und einer Idee. Sie kosten später je ein Feld, ohne dass der Filter
+sich ändert.
+
+**Form:** eine Tabelle mit optionalen Feldern, alle vorhandenen müssen zutreffen (implizit UND, wie bei
+`condition`). **Ein Wert je Feld, keine Negation** — dasselbe Argument wie beim ODER-Verbot oben: Wer
+Feuer *und* Eis reflektieren will, schreibt zwei Trigger. Fehlt ein Feld, wird nicht gefiltert; das ist
+die Negation, die man meistens meint.
+
+Die Decke: Häufen sich Filter mit fünf Feldern und Ausnahmen, ist das das Signal, dass Stufe (c) fällig
+ist — nicht, dass der Filter eine Sprache werden soll.
 
 ### Neun Events, feste Liste