# Trading Tool

Webbasiertes Go/MariaDB-System für Trading-Anfragen, dynamische Workflows und abteilungsbezogene Quests.

## Enthalten

- Go Webserver mit `net/http` und `html/template`
- Pocket ID / OIDC Login
- MariaDB Datenbank
- automatische Migrationen
- Admin-Konfiguration
- Trading-Anfragen für Ankauf und Verkauf
- Workflow-Regeln mit `condition_json` und `actions_json`
- Quest-Templates
- Quest-Abhängigkeiten: nur die erste Quest ist offen, Folgequests warten
- automatische Freischaltung der nächsten Quest nach Abschluss der vorherigen Quest
- automatische Request-Statusberechnung
- Abteilungsportale unter `/departments`
- Auftragnehmer-Rückmeldungen, Blocker, Änderungswünsche und Abschlussmeldungen
- Dockerfile und Docker Compose

## Start

```bash
cp .env.example .env
# Pocket ID Werte in .env eintragen
docker compose up --build
```

App: http://localhost:8080

Pocket ID Callback URL:

```text
http://localhost:8080/auth/callback
```

## Wichtige Routen

- `/` Trading Dashboard
- `/requests/new` neue Anfrage
- `/departments` Abteilungsportale
- `/departments/{id}/quests` Quest-Ansicht einer Abteilung
- `/admin` Konfiguration

## Workflow Conditions

`condition_json` entscheidet, wann eine Workflow-Regel greift. Beispiele:

```json
{
  "kind": "buy",
  "item_category": "weapon",
  "quantity_min": 1,
  "price_min": 1000
}
```

Unterstützte Felder:

- `kind`
- `item_category`
- `quantity_min`
- `quantity_max`
- `price_min`
- `price_max`

`actions_json` enthält die Quest-Template-Typen in Reihenfolge:

```json
["logistics_quote", "mining_procure", "crafting_order", "delivery"]
```

Die Reihenfolge erzeugt automatisch Abhängigkeiten. Quest 2 wartet auf Quest 1, Quest 3 wartet auf Quest 2 usw.

## Statuslogik

Requests:

- `new`
- `in_progress`
- `blocked`
- `fulfilled`
- `cancelled`

Quests:

- `waiting`
- `open`
- `accepted`
- `in_progress`
- `blocked`
- `change_requested`
- `done`
- `cancelled`

Wenn alle Quests eines Requests `done` sind, wird der Request automatisch auf `fulfilled` gesetzt.
Wenn eine Quest `blocked` ist, wird der Request auf `blocked` gesetzt.
Wenn eine Quest abgeschlossen wird, werden wartende Folgequests automatisch geöffnet, sobald alle Abhängigkeiten erledigt sind.

## Hinweise zur Produktionsnutzung

Dieses Paket ist deutlich robuster als der erste Prototyp, ersetzt aber keine finale Sicherheits- und Lastprüfung für deine konkrete Umgebung. Vor echter Produktion solltest du mindestens erledigen:

- HTTPS und sichere Reverse-Proxy-Konfiguration
- langes zufälliges `SESSION_SECRET`
- restriktive `admin_emails`
- Backups für MariaDB
- Monitoring/Logging
- eventuell CSRF-Schutz für schreibende Formulare
- rollenbasierte Einschränkung pro Abteilung, falls nicht jeder eingeloggte Nutzer jede Abteilung sehen darf

## Fehlerbehebung: `[mysql] invalid connection`

Diese Version setzt die MariaDB-Verbindungen bewusst kurzlebiger und führt Migrationen ohne `multiStatements=true` aus. Das verhindert, dass die App alte oder von MariaDB geschlossene TCP-Verbindungen aus dem Pool wiederverwendet.

Nach dem Update bitte neu bauen:

```bash
docker compose down
docker compose up --build
```

Falls du vorher mit einer leeren Testdatenbank gearbeitet hast und komplett neu starten möchtest:

```bash
docker compose down -v
docker compose up --build
```