USB-AIO für automatische Geräteprüfung

WERKSTATT-ABLAUF.md

@@ -0,0 +1,92 @@
+# 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