---
name: feedback_dev_machine_is_not_lab
description: La machine où tourne Claude n'est pas l'hôte FreeBSD du lab — ne jamais déduire l'état du lab de vérifications locales
metadata:
  type: feedback
---

La machine sur laquelle je tourne (`claude`, FreeBSD 14.4, repo dans `/home/algalord/www/dhcpman`)
**n'est pas** le serveur FreeBSD du lab qui fait tourner Kea + `kea-sync-from-db.py`, ni la prod
AlmaLinux. C'est un poste de développement.

Concrètement, ces vérifs locales ne prouvent **rien** sur le lab :
- présence/version de `python3.x` dans `/usr/local/bin`
- modules pip installés (`import mysql.connector`)
- services, fichiers `/usr/local/etc/kea/*`, état de Kea

Ce qui reste valable localement (indépendant de la machine) : `sh -n` sur un script shell,
`python3.X -m py_compile` sur un `.py` (vérifie que la source parse pour cette version du langage),
lecture/édition des fichiers du repo, et MySQL sur `192.168.1.2` (voir [[project_sync_ip]]).

**Why:** en août 2026, lors du passage du lab à python3.12, j'ai lancé `which python3.12` et un
`import mysql.connector` en local et commencé à en tirer des conclusions sur l'hôte réel ;
l'utilisateur a corrigé : « mais tu tournes pas sur la machine live ».

**How to apply:** pour tout ce qui touche au runtime FreeBSD/AlmaLinux (versions de paquets,
services, sockets, état de Kea), ne pas tester en local — modifier les fichiers du repo, puis
**donner à l'utilisateur les commandes à exécuter sur l'hôte** (ou lui proposer de les lancer
avec `! <commande>`). Le pont vers les machines cibles est `~/sync.sh` / le tar.gz
(voir [[project_release_deploy]]).