# PROMPT — Bench Client Linux (binaire Go / Rust)

## 🎯 Objectif

Concevoir un **programme binaire autonome** nommé `bench-client`, exécuté sur des machines **Linux x86\_64**, destiné à collecter des informations système, exécuter des benchmarks contrôlés, produire un JSON structuré et l’envoyer à un backend HTTP.

Ce programme **remplace un script Bash complexe** et est piloté par un **fichier de configuration YAML distant**.

---

## 🧠 Rôle attendu

Tu es un **développeur système senior (Linux / Go ou Rust)**. Tu dois produire un binaire **robuste, lisible, extensible**, orienté production.

---

## 🖥️ Environnement cible

- OS : Linux (Debian, Ubuntu, Proxmox VE, dérivés)
- Arch : x86\_64
- Lancement : `sudo ./bench-client`
- Langage : **Go (priorité)** ou **Rust**
- Binaire déjà compilé (aucune compilation sur la machine cible)
- Pas de dépendances runtime externes (hors outils système)

---

## 🧩 Déploiement (hors programme)

Un script shell externe (déjà existant) :

1. installe les outils système requis
2. télécharge le binaire
3. télécharge `config.yaml` depuis un serveur HTTP
4. exporte `API_TOKEN`
5. exécute `bench-client`

Le **binaire ne gère PAS l’installation**.

---

## ⚙️ Configuration distante (OBLIGATOIRE)

Le programme doit charger un fichier `config.yaml` distant qui pilote :

- les sections actives/inactives
- les outils à utiliser
- les paramètres des benchmarks
- les limites de sécurité
- les pondérations du score
- l’URL du backend

### Contraintes

- Le token **NE DOIT PAS** être dans la config
- Le token est fourni via `API_TOKEN`
- La config distante doit être :
  - validée
  - bornée (timeouts, tailles max)
  - mise en cache localement
  - utilisable en fallback si HTTP indisponible

---

## 🏗️ Architecture interne

### Core

- parsing des arguments :
  - `--config-url`
  - `--debug`
  - `--dry-run`
- chargement config YAML
- validation des paramètres
- orchestration des collecteurs

---

### Collecteurs (pattern obligatoire)

Chaque collecteur implémente :

- `Check()` → outil présent / droits OK
- `Run(ctx)` → exécution avec timeout
- `Parse(output)` → données structurées
- `Raw()` → sortie brute optionnelle

Les collecteurs doivent être **indépendants**.

---

## 🔧 Outils systèmes à piloter

### Informations système

- `lscpu`
- `free`
- `lsblk`
- `ip`
- `dmidecode` (root)
- `lspci`
- `lsusb`
- `ethtool` (root)
- `iw`
- `smartctl` (root)
- `aplay`, `arecord`, `pactl`
- `systemd-detect-virt`
- `pveversion`
- `xrandr`, `xdpyinfo`, `swaymsg`

### Benchmarks

- `sysbench cpu`
- `sysbench memory`
- `fio` (non destructif)
- `iperf3 -J`

Si un outil est absent :

- afficher WARN
- continuer l’exécution

---

## 📊 Benchmarks

- CPU : sysbench single + multi
- RAM : sysbench memory
- Disque : fio randrw
- Réseau : iperf3 bidirectionnel JSON
- GPU : placeholder (désactivé par défaut)

### Pondérations par défaut

- CPU : 40 %
- RAM : 20 %
- Disque : 20 %
- Réseau : 10 %
- GPU : 10 %

Tous les benchmarks doivent :

- avoir un timeout
- être annulables via context
- afficher une progression CLI

---

## 🖨️ Sortie CLI (temps réel)

Le programme doit afficher :

- progression globale `[step/total]`
- état : OK / WARN / ERROR
- logs en direct des benchmarks
- couleurs ANSI si TTY
- mode `--debug` :
  - commandes exécutées
  - sorties brutes
  - JSON sauvegardé dans `/tmp`

Exemple :

```
[3/8] CPU : lscpu… OK (12C / 24T)
[6/8] Disk bench : fio… OK (R=520MB/s W=480MB/s)
```

---

## 📦 JSON final

Le JSON généré doit contenir :

- `device_identifier`
- `bench_client_version`
- `hardware`
  - cpu
  - ram
  - gpu
  - storage
  - network
  - audio
  - motherboard
  - os
- `results`
  - cpu
  - memory
  - disk
  - network
  - gpu
  - global\_score
- `raw_info` (si debug activé)

Le JSON est :

- validé
- envoyé via HTTP POST
- header :
  ```
  Authorization: Bearer $API_TOKEN
  ```

---

## 🔐 Sécurité

- aucun benchmark destructif
- timeouts stricts
- limites configurables
- pas de commandes arbitraires
- pas de secrets dans le binaire

---

## 🎯 Résultat attendu

Un **bench-client binaire** :

- stable
- lisible
- extensible
- piloté par config distante
- capable de remplacer totalement le script Bash existant