# Werkstattablauf

## Geräteerkennung

Beim Start liest das Livesystem geschützte DMI-Felder einmal als `root` und stellt
sie der unprivilegierten Anwendung nur lesbar bereit. 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.

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 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 auch gespeicherte Prüfungen
des zuvor bearbeiteten Computers wieder 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. UEFI- und BIOS-Start
2. persistente Daten nach Neustart
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
9. kontrolliertes Herunterfahren