# 1. Deal Status Machine

## Status

- **Status:** Proposed
- **Date:** 2026-03-06
- **Author:** openclaw

## Problem

Die Geschäftslogik für Anfrage->Angebot->Verhandlung->Deal ist komplex; ohne dokumentierte Zustandsregeln entstehen Inkonsistenzen.

## Lösung

Wir führen eine Statusmaschine ein, die alle erlaubten Übergänge und Guard Conditions definiert. Die Maschine umfasst folgende Zustände:

- `REQUESTED`
- `OFFERED`
- `NEGOTIATING`
- `ACCEPTED`
- `REJECTED`
- `EXPIRED`

## Zustandsübergänge

| Von | Nach | Guard Condition |
|-----|------|-----------------|
| REQUESTED | OFFERED | Angebot muss von einem Benutzer erstellt werden |
| OFFERED | NEGOTIATING | Verhandlung muss vom Empfänger gestartet werden |
| NEGOTIATING | ACCEPTED | Akzeptanz durch den Empfänger |
| NEGOTIATING | REJECTED | Ablehnung durch den Empfänger |
| NEGOTIATING | EXPIRED | Ablauf der Verhandlungszeit |
| OFFERED | REJECTED | Ablehnung durch den Empfänger |
| OFFERED | EXPIRED | Ablauf der Angebotszeit |
| REQUESTED | REJECTED | Ablehnung durch den Empfänger |
| ACCEPTED | EXPIRED | Ablauf der Deal-Zeit |

## Fehlerszenarien

- **Race Conditions:** Mehrere Benutzer versuchen gleichzeitig einen Status zu ändern. Lösung: Transaktionen mit Versionierung.
- **Doppelte Annahmen:** Ein Benutzer akzeptiert ein Angebot, während ein anderer es bereits abgelehnt hat. Lösung: Zustandsprüfungen vor jeder Änderung.

## Referenz

- Backend Validierungen und Tests werden direkt aus dieser ADR abgeleitet.