The only gate that boots real machines never plays the example stacks, where all four dataplane defects were found by hand

[stephrobert]

Ce que la porte joue aujourd'hui, et ce qu'elle ne joue pas

runtime-proof.yml est la seule porte de ce dépôt qui démarre de vraies
machines : deux jobs en matrice, incus et incus-ovn, Incus installé depuis
Zabbly, des conteneurs qui bootent pour de bon.

Elle joue les suites de conformance. Elle ne joue aucune stack
d'exemple.

Or les trois stacks d'examples/stacks/ sont exactement la population où les
défauts de plan de données se manifestent : #475, #481, #483 et #484 y ont tous
été trouvés, à la main, la nuit du 2026-08-26. Chacune de ces stacks n'est jouée
que lorsque quelqu'un le décide, et le registre examples/stacks/surveyed.md
montre des rejeux espacés de semaines.

Ce qui est demandé

La porte planifiée applique les trois stacks sous --vm incus-ovn, exécute les
assertions fonctionnelles de #503, puis détruit — et son verdict porte sur ce
que les machines font, pas sur le code de sortie de terraform apply.

L'entrée existe déjà : chaque stack porte son feint.yaml (#189), donc
feint up --runtime incus-ovn est la commande, et non une recette recopiée dans
un fichier de workflow.

Challenge — les quatre choses qui décident si c'est utile ou nuisible

Le budget. Une stack sous OVN coûte des dizaines de secondes par machine, et
la conformance complète a mesuré 1676 s à elle seule. Trois stacks appliquées,
testées et détruites s'ajoutent à une exécution qui dure déjà. Il faut donc dire
si elles tiennent dans le même job, dans un job parallèle, ou dans une porte
planifiée distincte — et à quelle fréquence. Une porte nocturne qui déborde son
budget se fait couper, et un job coupé est un verdict inventé.

Le verdict doit nommer la stack et l'assertion. « runtime-proof a échoué »
est du bruit ; « stack Outscale, le répartiteur ne distribue vers aucun
arrière-plan » est un constat. C'est la leçon de #501, et #502 en fait la règle
pour l'ouverture d'issue.

Le nettoyage n'est pas optionnel. Une stack dont la destruction échoue laisse
des conteneurs, des réseaux et des jeux de règles derrière elle — mesuré, c'est
#493 — et un runner qui les hérite rendra un verdict faux à l'exécution
suivante. La porte vérifie le delta, comme le fait déjà toute campagne
manuelle ici : zéro instance, zéro réseau fnt-, aucune ACL ajoutée. Un delta
non nul est un échec, même si toutes les assertions sont passées.

Et elle reste planifiée, pas une garde de pull request. #125 fixe le
critère : quatorze exécutions planifiées vertes consécutives avant promotion.
Ce compteur est à zéro depuis dix nuits (#501), et ajouter des stacks à une
porte déjà rouge ne fera que la rendre rouge autrement. Cette issue se traite
après #501, sinon elle mesure le même silence avec plus d'étapes.

Ce dont elle dépend

• An example stack that applies cleanly proved nothing: four defects hid behind a green apply, and no test says what its machines must actually do #503 écrit les assertions ; sans elles, jouer les stacks ne prouve rien de
  plus qu'un apply vert, ce qui est précisément la mesure qui a laissé passer
  quatre défauts.
• The Scaleway ssh suite has been red on ten of the last twelve scheduled nights, and it fails without a word: an assertion with no guard, and a grep -c that returns 1 on zero #501 rend la porte lisible ; A red scheduled runtime-proof tells nobody: ten silent nights, a streak counter at zero in a job summary, and the issue-opening mechanism already exists in drift.yml #502 fait qu'un rouge se sache.
• Nothing configures a machine after Terraform creates it: an Ansible inventory from the state, and a playbook that runs #482 donne aux machines quelque chose à configurer, donc à tester.

Le test qui échoue sans le correctif

• Une stack dont une machine ne démarre pas rend la porte rouge, en nommant la
  stack et la machine — aujourd'hui aucune exécution planifiée ne le verrait.
• Une destruction incomplète rend la porte rouge, même toutes assertions
  passées, et nomme ce qui est resté sur l'hôte.
• Une exécution qui n'a pas pu appliquer une stack le dit, et ne rapporte pas
  les assertions de cette stack comme sautées sans motif.

Origine

Demandé par le mainteneur le 2026-08-26 : étendre la preuve adossée au runtime
aux stacks d'exemple, avec de vrais tests montrant que tout fonctionne.

[stephrobert]

Decision, 2026-08-28: this goes next, and today is the argument

conformance:functional is the only gate that boots real machines and applies the example stacks. Nothing in CI runs it.

Today it earned that sentence. It is what surfaced the isolation-detach race — an ACL deleted while the daemon resolved it at incus start, killing machines behind a green apply. Finding it cost three pull requests (#577, #578, and the diagnosis that preceded them), and the defect was older than the whole range bisected: the detach pass on accept dates from 2026-08-26 and Start had never held the lock.

No leg of runtime-proof.yml plays the stacks, and conformance skips the stack suites without a runtime. So a defect that only appears when a real apply races a real accept had no gate at all.

The value is not hypothetical and not a matter of coverage arithmetic: the gate that would have caught today's three-PR defect on the day it landed is the one this issue asks for.

What it has to carry, from what today measured:

• the doorstep at both ends — the run failed at second zero three times on a dirty host before anyone knew why;
• the mode named in the output, because evidence:update silently overrode FEINT_VM and manufactured two false attributions;
• a red that names the stack and the machine, which functional.sh already does (platform-web-a (i-…) is 'stopped', not 'running');
• and the intermittency budget: this class of defect struck 9 times in 13 runs. A gate that runs the suite once and calls a green a proof is measuring luck.