Skip to content

Un essai à blanc avant de déplacer de vrais écrans - #724

Merged
mgth merged 1 commit into
v6from
feat/dry-run-the-topology
Sep 16, 2026
Merged

mgth merged 1 commit into
v6from
feat/dry-run-the-topology

Conversation

@mgth

@mgth mgth commented Sep 16, 2026

Copy link
Copy Markdown
Owner

Demandé avant le premier apply réel. Le menu contextuel gagne « Show what it would run », au-dessus d'Apply : l'agent répond avec les lignes de commande et ne change rien.

Rien du tout — y compris la mise en page

Le piège était là. apply enregistre d'abord (le changement système déclenche une reconstruction qui recharge la mise en page sauvegardée), donc un essai à blanc qui aurait gardé cette écriture aurait réécrit la chose même qu'il prévisualise. La sauvegarde est sautée en mode sec, et l'événement DisplayChanged aussi — l'envoyer aurait jeté l'édition de la fenêtre pour un changement qui n'a pas eu lieu.

La même fonction, un exécuteur échangé

Une prévisualisation écrite à côté aurait dérivé de ce qu'apply fait, en silence, et la première fois que quelqu'un l'aurait remarqué serait la fois où il lui faisait confiance. Le mode sec ne diffère qu'en un point : ce que l'exécuteur fait de la ligne.

Le gap guard est dans la liste, à sa place : il écrit avant la passe principale, et une liste qui l'omettait aurait sous-estimé ce que presser Apply fait.

Ce que l'essai à blanc ne peut pas dire, et le dit

La procédure relit le compositeur entre ses passes : les positions sont calculées sur les tailles qu'il rapporte après les échelles (son arrondi natif/échelle fait autorité et diffère d'un pixel assez souvent pour compter), et la passe de réaffirmation existe précisément parce qu'on ne peut pas prévoir ce qu'il fera d'une position. Un essai à blanc ne change rien, donc n'a rien de neuf à lire : ses positions sont une prédiction, et la réaffirmation est absente de la liste. La fenêtre le dit en toutes lettres au-dessus des commandes.

L'effet de bord, qui vaut peut-être plus

Rendre apply sûr à appeler l'a rendu testable. Deux coutures — la lecture des sorties, l'exécution — et la procédure a enfin des tests. Elle n'avait jamais été exécutée par personne :

  • un essai à blanc n'exécute rien et dit ce qu'il aurait fait ;
  • un vrai apply exécute exactement la liste que l'essai à blanc avait promise — la propriété pour laquelle l'essai à blanc vaut quelque chose ;
  • un compositeur simulé qui remet obstinément une sortie en place se fait dire deux fois puis signaler, au lieu d'être combattu indéfiniment ;
  • un apply qui ne change rien ne ferme même pas les écarts du moteur — règle sur le moteur, pas optimisation : un moteur qui tourne avec ses écarts les garde.

Le premier test a été falsifié (retirer le gap guard de la liste sèche le fait tomber).

🤖 Generated with Claude Code

Demandé par le mainteneur avant son premier apply réel. Le menu contextuel
gagne « Show what it would run », au-dessus d'Apply : l'agent répond avec les
lignes de commande et ne change rien.

**Rien du tout** : ni les écrans, ni la mise en page. Le piège était là —
apply enregistre d'abord (le changement système déclenche une reconstruction
qui recharge la mise en page *sauvegardée*), donc un essai à blanc qui aurait
gardé cette écriture aurait réécrit la chose même qu'il prévisualise.

C'est **la même fonction** dans les deux cas, avec l'exécuteur échangé. Une
prévisualisation écrite à côté aurait dérivé de ce qu'apply fait, en silence,
et la première fois que quelqu'un l'aurait remarqué serait la fois où il lui
faisait confiance.

Le gap guard est dans la liste, à sa place : il écrit **avant** la passe
principale, et une liste qui l'omettait aurait sous-estimé ce que presser
Apply fait.

Ce que l'essai à blanc ne peut pas dire, et le dit : la procédure relit le
compositeur entre ses passes — les positions sont calculées sur les tailles
qu'il rapporte *après* les échelles, et la passe de réaffirmation existe
parce qu'on ne peut pas prévoir ce qu'il fera d'une position. Un essai à
blanc ne change rien, donc n'a rien de neuf à lire : ses positions sont une
**prédiction** et la réaffirmation est absente de la liste.

Effet de bord qui vaut peut-être plus que la fonctionnalité : rendre apply
sûr à appeler l'a rendu **testable**. Deux coutures (la lecture des sorties,
l'exécution) et la procédure a enfin des tests — l'ordre des passes, la
relecture qui rend l'arrondi du compositeur autoritaire, et la boucle de
réaffirmation. Rien de tout ça n'avait jamais été exécuté par personne. Un
compositeur simulé qui remet obstinément une sortie en place se fait dire
deux fois puis signaler ; un apply qui ne change rien ne ferme même pas les
écarts du moteur.

Et un test dit la propriété pour laquelle l'essai à blanc vaut quelque chose :
un vrai apply exécute exactement la liste que l'essai à blanc avait promise.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@mgth
mgth merged commit e4fe7aa into v6 Sep 16, 2026
3 checks passed
@mgth
mgth deleted the feat/dry-run-the-topology branch September 16, 2026 20:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant