ci(#15091): les gardes des copies de reference ai-01 sont en prose, pas en organe (4 acceptances) #15228

Trois réserves de la review NanoClaw du 2026-09-08T17:27:57Z sur #15214 (tête c9f3cfcd), déposées avant merge parce qu'elles sont réelles et qu'aucune ne se lève par une phrase. Elles forment une seule classe : la garde existe en prose, pas en organe.

A — le harnais de contrôle n'est câblé à aucun workflow

scripts/ci/docker/linux-runner/persist/ai-01/test-dryrun-sizing-control.sh (70 assertions) ne tourne que si quelqu'un le lance à la main. Un test qui n'est appelé par rien est un test qui cessera de passer sans que personne l'apprenne — et il ne restera de lui que la confiance qu'il a value.

Le câblage est presque gratuit : le script s'injecte déjà par variables d'environnement (COURSIA_DRYRUN_ROOT, COURSIA_DRYRUN_SYSTEMCTL) et n'a besoin d'aucun service. Un job bash -n + exécution suffit.

Acceptance A : un workflow exécute la suite sur PR touchant persist/ai-01/**, et il ROUGIT si une assertion tombe — vérifié par un contrôle positif (casser volontairement une assertion doit faire échouer le job).

B — deux refus restent NON couverts, et la plateforme est la cause

Les refus symlink (cible et répertoire .d) et ACL étendues ne sont pas exercés : sur Git Bash ln -s fabrique une copie, donc [ -L ] est faux et le refus n'est jamais atteint. La suite les déclare non-exercables=2 plutôt que de les compter verts, mais déclarer n'est pas couvrir.

Acceptance B : ces deux refus sont exercés là où la plateforme le permet — dans le même conteneur Linux que A, où ln -s et setfacl fonctionnent.

C — « byte-identique » et « déployé et vivant » sont des mesures datées

Elles étaient vraies le 2026-09-08. Rien ne détecterait une dérive dépôt↔machine ensuite : les copies de référence peuvent diverger du vivant en silence, et c'est précisément l'état dans lequel elles étaient avant #15091.

Acceptance C : un organe compare périodiquement les copies de référence aux fichiers vivants et signale l'écart. Il ne déploie rien — il mesure et dit.

D — l'artefact tracké ne booterait pas tel quel

Le couple unité + drop-in commité demande 16 vCPU pour un budget de 8 : déployé naïvement sur un hôte neuf, assert_cpu_budget refuse et le service reste failed. C'est voulu et le README le dit — mais la garde est le README, et un README ne s'exécute pas.

Acceptance D : soit l'arbitrage de dimensionnement est appliqué dans les copies de référence (ce qui les rend déployables), soit un garde mécanique refuse un install naïf. Le choix dépend de #15091.

Origine : review clusterManager-Myia sur #15214. A, B et C sont des gardes futures, pas des défauts de cette PR — c'est la raison pour laquelle elles sont déposées ici plutôt que d'y bloquer le merge. D dépend de l'arbitrage de #15091.