# #007 Worker und Vorgänge
**Status:** erledigt
**Meilenstein:** v0.1.0
**Labels:** backend
**Geschätzt:** 3 h   **Tatsächlich:** 0 h 15 min

## Ziel
Eigener Worker-Prozess mit pg-boss; die Oberfläche legt Vorgänge an und zeigt deren Fortschritt.

## Aufgaben
- [x] Worker-Einstieg, gebündelt per esbuild
- [x] pg-boss-Queues je Vorgangsart, Zeitpläne
- [x] Modell `Vorgang` für Status/Ergebnis in der Oberfläche
- [x] Docker-Compose produktiv: web, worker, db, migrate; Master-Key nur im Worker

## Akzeptanzkriterien
- [x] Vorgang wird im Web angelegt, im Worker ausgeführt, Ergebnis sichtbar

## Abhängigkeiten
#003

## Notizen / Entscheidungen
- **Eine Warteschlange `sshkv-vorgang` statt einer je Art:** Der Job trägt nur die Vorgangs-ID; die Art steht im `Vorgang`. Eine Handler-Tabelle (`src/worker/handler.ts`) wächst mit den Issues.
- **Kein automatisches Wiederholen** (`retryLimit: 0`): Ein halb ausgeführter Schreibvorgang auf einem Host soll ein Mensch ansehen.
- **Start nur aus WARTEND** per bedingtem Update – zugleich die Sperre gegen doppelte Ausführung.
- **Fehlermeldungen:** Nur `VorgangsFehler` erreichen die Oberfläche, alles andere wird „Interner Fehler“; ins Log nur Name und Meldung.
- **Compose:** Datenbank in einem `internal`-Netz; Master-Key als Secret ausschließlich im Worker. Docker-Secrets ohne Swarm sind Bind-Mounts mit den Rechten der Host-Datei – deshalb `chown 1001:1001` und `chmod 400` (siehe Kopf von `docker-compose.yml`).