docs: m3-befunde in tickets 01, 08 und 14 zurueckgetragen, dreizehnte registry ins glossar

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

@@ -71,6 +71,28 @@ Level ≥ 3" wird zu zwei Einträgen dupliziert — oder der Modder hängt beide
 Bedingungen werden an **zwei** Stellen ausgewertet: beim Feuern eines Triggers und beim Auslesen eines
 Attributs (bedingte Modifikatoren aus 01). Letzteres erzwingt den Nachtrag an Ticket 07, siehe unten.
 
+### Nachträge aus M3
+
+Beim Bauen kamen zwei Prüfungen dazu, die oben fehlten:
+
+- **`health_below`** mit einem Anteil (0.0–1.0). Die `ai`-Listen aus 14 brauchen „unter 30 % Leben", und
+  das ist mit `attribute` nicht ausdrückbar: `health` ist **Zustand**, kein Attribut (01), und ein
+  *Verhältnis* lässt sich mit `at_least`/`below` auf einem absoluten Wert nicht formulieren.
+- **`chance`** am Trigger. Dieses Ticket nennt „Flammendes Schwert: 20 % Chance, Brennen auszulösen" als
+  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
+
+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.
+
+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.
+
 ### Neun Events, feste Liste
 
 | Event | Nutzlast über `source`/`target` hinaus |
@@ -144,6 +166,12 @@ Gegen Zyklen — Trigger A löst B aus, B löst A aus — ein schlichter Zähler
 Zug**, danach Abbruch mit Warnzeile. Kein Zyklenerkennungs-Graph; der Zähler fängt denselben Fall und
 ist eine Zeile.
 
+**Befund aus M3: die Warteschlange war ein Stack.** Die erste Umsetzung nahm `Vec::pop()`, also LIFO —
+ein Folge-Event drängelte sich vor die schon wartenden. Genau das sollte die Warteschlange verhindern
+(„hängt es hinten an, statt den Stack zu vertiefen"). Jetzt `VecDeque` mit `pop_front`. Die Formulierung
+oben war richtig, die Umsetzung nicht, und **kein Test hat es gemerkt** — Reihenfolge fällt erst auf,
+wenn zwei Trigger um dasselbe Ziel konkurrieren.
+
 Trigger werden bei jedem Event **gesucht, nicht indiziert** — dieselbe Entscheidung wie „kein
 Attribut-Cache" in 07 und aus demselben Grund: Ein Index müsste bei jedem An- und Ablegen, jedem Loot
 und jedem Affix-Wechsel gepflegt werden, also genau das Invalidierungsproblem, das 07 vermieden hat.