fix(benchmarks): validate energy harness float32 outputs and carbon units - #469

Symptôme

W0-2 / ⚪8 : le harnais comparait les valeurs des octets sérialisés au lieu des
composantes float32 et ne produisait pas de résultat carbone par 1 000 tokens.
Cette PR est empilée sur #468 ; aucune fusion n'est effectuée par Codex.

Cause racine

Contrat de représentation et unités manquants : EmbeddingEngine renvoie des
blobs float32, et le calcul carbone doit recevoir explicitement ses facteurs.
Les deux chemins d'orchestration du capteur rendaient aussi son cycle de vie
plus difficile à vérifier.

Changement

Le runner valide les arguments avant modèle ou sudo. --carbon-intensity
(gCO2eq/kWh) et --embodied (taux déjà alloué, gCO2eq/s) sont obligatoires.
L'équivalence décode les blobs avec numpy.frombuffer(dtype=float32) et refuse
les sorties invalides ou au-delà de la tolérance explicitée. Le dénominateur
vient des vrais masques d'attention du tokenizer, comptés hors phases mesurées.

run.sh orchestre seul l'autorisation et le capteur ; la charge Python reste
non privilégiée. Le rapport archive les octets effectivement analysés, les
unités, les paramètres, le commit et les hashes sources. Le README décrit la
frontière CPU+GPU+ANE et les limites de l'estimation.

Preuve

Sur le même fixture float32 [0.5] puis nextafter(..., 1) :

La version initiale non suivie a été conservée localement pour reproduire ce
contre-exemple (SHA256 du script initial :
231e2fe24b11464ccc9c9f8dbf1ac75dfd863c5ca22c063f50ee39dbcf70cc6b).
Il s'agit d'un test arithmétique, pas d'une mesure d'énergie.

.venv/bin/python -S benchmarks/energy/run_embedding_energy.py \
  --duration-seconds 20 --repetitions 2 --validate-only
# exit 2 : the following arguments are required: --carbon-intensity, --embodied

La désactivation des site-packages (-S) prouve que ce refus ne dépend pas du
chargement de NumPy ou du modèle. Les tests du shell utilisent un faux sudo
et un faux capteur, sans mesure physique ni demande de mot de passe.

Validation finale du diff commité c16b84e9, le 2026-09-06 sur macOS ARM64,
Python 3.13.7 : verrouillage, Ruff (1 412 fichiers), craftsmanship et Pyright
(zéro diagnostic) passent. Couche : 145 passed en 32,55 s. Suite complète :
7 547 passed, 221 skipped, 123 subtests passed en 148,43 s.
Charge avant : 3,00 pour 10 cœurs ; disque libre avant/après : 66 GiB.

CI complète verte au même SHA :
run 34034623118.
Déclenchement workflow_dispatch nécessaire car la base de cette PR est la
branche W0-1 et l'ancien filtre de branches ne couvrait que main.

Les commandes de gates sont celles du contrat : synchronisation verrouillée
dev+sqlite+lint, Ruff check/format, craftsmanship, environnement Pyright prescrit
par CONTRIBUTING, Pyright, tests de tests_py/benchmarks/, puis suite complète.
PostgreSQL est explicitement inaccessible à localhost:1 ; les données de test
sont jetables. Logs : /private/tmp/cortex-green-w0-2-final-gates.log.

Conformité

• Périmètre W0-2 : harnais autorisé par le propriétaire et tests associés.
• Caps : nouveaux modules et fonctions sous les limites ; baseline inchangée.
• Aucun import de production modifié, aucun modèle sous /tmp.
• Aucun fallback silencieux : paramètres, modèle, équivalence et capteur sont
  contrôlés et les erreurs sont explicites.
• Constantes physiques et équations sourcées dans le code et le README ; aucun
  facteur carbone par défaut et aucun gain énergétique prétendu.
• Aucune base de production, aucune opération de maintenance ou fusion.

Candidats issues

Une validation physique du protocole reste à effectuer avec les facteurs et
la durée choisis par le propriétaire. La puissance CPU+GPU+ANE n'est pas la
consommation totale de la machine. La tolérance du probe n'est pas une borne
universelle d'erreur de l'inférence sur tous appareils et textes.

Runbook

Le propriétaire fournit les facteurs sourcés et lance benchmarks/energy/run.sh
depuis un terminal interactif, selon le README. Lui seul saisit son mot de passe
pour autoriser le capteur macOS. Aucune mesure physique n'a été lancée par cette PR.