# Werkstattablauf

## Geräteerkennung

Beim Start liest die Anwendung die verfügbaren DMI-Felder. Bevorzugt wird eine
gültige System-UUID. Fehlt sie, wird eine gehashte Kombination aus Hersteller und
Seriennummer verwendet. Platzhalter wie `To be filled by O.E.M.` sind ungültig.
Falls der Linux-Benutzer einzelne DMI-Felder nicht lesen darf, müssen die Rechte auf
dem Werkstattrechner passend eingerichtet werden.

Die Hardware-ID wird an `POST /api/v1/devices/resolve/` gesendet. Der Server ordnet
sie einem vorhandenen Gerät zu oder vergibt atomar eine neue Gerätenummer. UUID und
Seriennummer können als Aliase dasselbe Gerät bezeichnen. Widersprüche werden zur
manuellen Prüfung abgelehnt.

## Automatische Erfassung

Für neue Geräte und Geräte in **Eingang** startet ein Kurzscan. Erfasst werden
Hersteller, Modell, CPU, installierter RAM sowie Größe und Art aller Laufwerke. Die
Daten werden revisionsgesichert über den Intake-Endpunkt geschrieben. Ein Gerät in
einem späteren Prozessschritt wird durch den automatischen Scan nicht überschrieben.

## Inspektion

Jeder Prüfschritt besitzt eine Aktion, eine verständliche Anleitung, ein sichtbares
Ergebnis und eine Wiederholungsmöglichkeit. Verfügbare Schritte umfassen Display,
Tastatur, Touchpad, WLAN, Lautsprecher, Mikrofon, Kamera, USB-Anschlüsse, Laden,
Temperatur, Stabilität und SMART-Daten jedes internen Laufwerks.

Ergebnisse unterscheiden:

- bestanden
- Hardwarefehler
- Test nicht verfügbar
- Einrichtungsproblem
- nicht geprüft
- nicht vorhanden
- Bestätigung erforderlich

Ein fehlendes Werkzeug oder eine fehlende Berechtigung wird niemals als
Hardwaredefekt gewertet. Optionale Hardware muss ausdrücklich als nicht vorhanden
bestätigt werden.

Beim Start einer Prüfung wird der Zustand **Inspektion** an den Server gesendet.
Zwischenstände und der Abschluss verwenden unveränderliche Anforderungs-IDs, damit
ein Verbindungsabbruch keine doppelten Einträge erzeugt. Ein Abschluss benötigt
einen Technikernamen und vollständig bewertete Prüfschritte.

## Unterbrechung und Offlinebetrieb

Der lokale Prüfstand wird atomar gespeichert. Nach einem Neustart öffnet die
Anwendung die letzte unvollständige Prüfung mit Messwerten und Notizen. Noch nicht
bestätigte Uploads liegen in `outbox/inspections/`; bestätigte Uploads werden nach
`outbox/sent/` verschoben. Beim nächsten Start werden gespeicherte Prüfungen erneut
in die Warteschlange aufgenommen.

## Reparaturen und Bericht

Eine Reparatur enthält Bauteil, Tätigkeit, Ersatzteil, Techniker und Zeitpunkt. Der
vorherige Befund bleibt erhalten und der betroffene Test wird erneut geöffnet. Der
HTML-Abschlussbericht enthält Spezifikationen, Laufwerks- und Akkuzustand,
Messwerte, Mängel, Reparaturverlauf und technische Freigabe.

## WLAN und Inventarverbindung

Das Werkstatt-WLAN wird erst nach erfolgreicher Verbindung gespeichert. Die Datei
`config/workshop-wifi.json` ist nur für den Besitzer lesbar und kann in den
Einstellungen ersetzt oder gelöscht werden. Das Passwort wird über die
Standardeingabe an NetworkManager übergeben und erscheint nicht in Prozessargumenten.

Die Inventarverbindung benötigt:

```json
{"url": "https://inventory.example.org"}
```

Der API-Schlüssel liegt separat in `config/inventory-api-key`. Für einen privaten
HTTPS-Server kann `config/inventory-server.crt` die öffentliche CA enthalten.
Zertifikats- und Hostnamenprüfung bleiben aktiv.

## Abnahme eines neuen Builds

Vor dem Werkstatteinsatz sind mindestens diese Punkte auf echter Hardware zu prüfen:

1. Start der eigenständigen Datei in der vorgesehenen Linux-Umgebung
2. persistente Daten nach Neustart der Anwendung und des Rechners
3. automatische Wiederverbindung mit dem WLAN
4. richtige Gerätezuordnung und Dublettenwarnung
5. Intake-Synchronisation ohne Überschreiben späterer Zustände
6. Ein- und Ausgabegeräte sowie jedes Laufwerk
7. Offline-Warteschlange und Wiederholung nach Verbindungsabbruch
8. druckbarer Bericht