# `event_race` — Ereignisbasiertes Gateway (erstes Ereignis gewinnt)

**Zweck:** Mehrere Warte-Optionen laufen gleichzeitig; die Option, die zuerst komplett abgeschlossen ist, gewinnt — alle übrigen werden storniert. Deckt Muster ab wie „Genehmigung ODER 14-Tage-Frist ODER Widerruf-Signal".

**Parameter**

| Name | Pflicht? | Default | Beschreibung |
|---|---|---|---|
| `option` (`id`) | **ja** (min. 2) | *(md5 des Zweigs)* | Ein Warte-Zweig; `id` benennt die Option |
| `option`/`task` | **ja** | — | Tasks der Option (Sequenz je Zweig) |

**Eingangswerte:** Kontext der enthaltenen Tasks; `assign_to` an einem wartenden Kind-Task wird automatisch übernommen.

**Ausgangswerte:**
- `<task_id>_winner` — `id` der Gewinner-Option (danach per `if` verzweigen)

**XML-Beispiel**

```xml
<task type="event_race" id="antwort_oder_frist">
  <option id="genehmigt">
    <task type="approve_reject" id="er_approve">…</task>
  </option>
  <option id="frist_um">
    <task type="wait_until" id="er_frist"><config><relative>+14 days</relative></config></task>
  </option>
  <option id="zurueckgezogen">
    <task type="signal_wait" id="er_sig"><config><signal>antrag_zurueckgezogen</signal>
      <korrelation>{{vkz}}</korrelation></config></task>
  </option>
</task>
```

**Hinweis (Engine-Modell):** Es darf höchstens EINE Option interaktive Tasks (Formular/Genehmigung) enthalten — die übrigen Optionen müssen aus passiven Warte-Tasks bestehen (`wait_until`, `signal_wait`, `schedule_resume`, `external_trigger`, `escalate`), weil die Engine pro Aufruf nur eine Formularseite ausliefern kann. Mindestens zwei Optionen sind nötig.