# CS-R Intake

CS-R Intake ist eine eigenständige Linux-Anwendung für die Annahme und technische
Prüfung gespendeter Computer. Sie erkennt das aktuelle Gerät über eine stabile
Hardware-ID, verbindet es mit der Inventarverwaltung und speichert alle Arbeiten
auch ohne Netzwerk lokal.

## Ablauf in der Werkstatt

1. `csr-intake-x86_64.run` auf dem zu prüfenden Linux-Rechner starten.
2. Beim ersten Einsatz unter **Einstellungen** das Werkstatt-WLAN verbinden und
   **WLAN speichern** aktiviert lassen.
3. Das Gerät wird über DMI-UUID oder Hersteller und Seriennummer erkannt.
4. Die Inventarverwaltung liefert die vorhandene Gerätenummer oder vergibt eine neue.
5. Neue Geräte und Geräte im Status **Eingang** erhalten automatisch einen Kurzscan
   mit Modell, CPU, RAM und Datenträgern.
6. Danach kann der Techniker die Anwendung schließen oder die Inspektion starten.
7. Prüfstände und Ergebnisse werden als **Inspektion** synchronisiert. Offline
   gespeicherte Ergebnisse bleiben in der Warteschlange und werden später gesendet.

Die Oberfläche konzentriert sich auf **Gerät**, **Inspektion** und **Einstellungen**.
Reparaturen, Berichte und die Synchronisationswarteschlange sind über das Menü erreichbar.

## Funktionen

- automatische Hardware-ID und serverseitig vergebene Gerätenummer
- Schutz vor doppelten Datensätzen
- gespeichertes Werkstatt-WLAN mit geschütztem Passwort
- umschaltbare deutsche oder US-Tastaturbelegung
- geräteabhängige Tests für Akku, Touchpad, Webcam und mehrere Laufwerke
- getrennte Ergebnisse für Hardwarefehler, nicht verfügbaren Test,
  Einrichtungsproblem, nicht geprüft und nicht vorhanden
- Wiederaufnahme nach Neustart oder Stromunterbrechung
- Reparaturnotizen und erneute Prüfung betroffener Komponenten
- druckbarer Abschlussbericht mit Messwerten und Freigabe
- dauerhafte Offline-Warteschlange mit sicheren Wiederholungen
- zentrale Sprache, Testdauer und Grenzwerte
- verifizierbarer Build mit Versions- und Prüfsummenmanifest

## Anwendung starten

Die Release-Datei enthält Oberfläche und Hardware-Scanner. Sie entpackt geprüfte
Programmdateien in den Benutzer-Cache und speichert Einstellungen, Berichte und die
Offline-Warteschlange standardmäßig unter `~/.local/share/csr-intake`.

```bash
chmod +x csr-intake-x86_64.run
./csr-intake-x86_64.run
```

Ein anderer Datenordner kann mit `--data /pfad/zum/ordner` gewählt werden:

```bash
./csr-intake-x86_64.run --data "$HOME/csr-intake-daten"
./csr-intake-x86_64.run --version
./csr-intake-x86_64.run --check-bundle
```

Die Anwendung ist für x86-64 Linux gebaut. Sie benötigt eine grafische Sitzung,
Python 3, SQLite und NetworkManager. Einzelne Diagnosen verwenden Systemwerkzeuge
wie `smartctl`, `stress-ng`, `ffmpeg`, `arecord`, `lsusb` und `xdg-open`. Fehlt ein
Werkzeug, wird der Test als **nicht verfügbar** und nicht als Hardwarefehler bewertet.

## Konfiguration

Diese Dateien entstehen im Datenordner unter `config/`:

```text
inventory.json
inventory-api-key
inventory-server.crt
workshop-wifi.json
workshop.json
```

API-Schlüssel und WLAN-Passwort gehören nie in Git. Ein privates CA-Zertifikat darf
nur als öffentliches Zertifikat gespeichert werden. Sensible Konfigurationsdateien
sind nur für den Besitzer lesbar.

## Projekt bauen und prüfen

Voraussetzungen sind Rust, Cargo, Python 3 sowie die Entwicklungsbibliotheken für
X11, Wayland und OpenGL. Der vollständige Build führt Rust-, Python- und Rauchtests
aus und erzeugt anschließend genau ein verteilbares Artefakt:

```bash
bash scripts/build-release.sh
./dist/csr-intake-x86_64.run --check-bundle
```

Das Ergebnis liegt in `dist/csr-intake-x86_64.run`. `build/release.json` enthält
Build-ID, Versionen und SHA-256-Prüfsummen der eingebetteten Programme. Die CI stellt
bei jedem erfolgreichen Build eine neutrale `.run`-Datei ohne Zugangsdaten als
Artefakt bereit.

Für eine werkstattgebundene Datei können `inventory-api-key` und
`inventory-server.crt` vor dem Build in `.bundle-secrets/` abgelegt werden. Der Build
bettet sie dann zusammen mit der Serveradresse ein und setzt die fertige Datei auf
Modus `0700`. Beim ersten Start werden fehlende Konfigurationsdateien unter
`config/` angelegt; vorhandene Werte bleiben erhalten. Eine solche Datei enthält
einen lesbaren Zugangsschlüssel und darf nur wie ein Passwort weitergegeben werden.

## Projektaufbau

| Pfad | Inhalt |
| --- | --- |
| `gui/` | Bedienoberfläche und geführte Tests |
| `scanner/` | Hardwareerkennung und Messwerte |
| `scripts/` | Build, Synchronisation und lokale Datenwerkzeuge |
| `tests/` | Python- und Rauchtests |
| `config.example/` | Beispiel für die Inventarverbindung |

Der Inventory-Server wird in einem eigenen Repository gepflegt. Weitere Einzelheiten
zum Arbeitsablauf stehen in [WERKSTATT-ABLAUF.md](WERKSTATT-ABLAUF.md).