fix(installation): un poste ne s'installait pas depuis une console ordinaire

[lostmind84]

Le signalement

Sur le forum des supermarchés coopératifs, capture à l''appui : bannière affichée, puis

iex : Impossible de convertir la valeur «System.String» en type «System.Management.Automation.SwitchParameter».
Au caractère Ligne:1 : 96
+ ... tent.com/lostmind84/OpenScale/main/deploy/windows/bootstrap.ps1 | iex
    + CategoryInfo          : MetadataError: (:) [Invoke-Expression], ArgumentTransformationMetadataException
    + FullyQualifiedErrorId : RuntimeException,Microsoft.PowerShell.Commands.InvokeExpressionCommand

Le caractère 96 est exactement le premier caractère de iex dans la commande publiée — donc la position n''accusait ni le fichier, ni la ligne, ni la variable.

La cause

bootstrap.ps1 déclare [switch]$Relaunched et écrivait, quarante lignes plus bas :

$relaunched = Join-Path $env:TEMP 'openscale-bootstrap.ps1'

Les noms de variables PowerShell sont insensibles à la casse : ces deux-là sont la même variable, et celle d''un paramètre est typée. Un chemin rangé dans une [switch] lève. $ErrorActionPreference = ''Stop'', posé trois lignes après le param, transformait l''erreur en terminating et la faisait ressortir attribuée à l''Invoke-Expression appelant.

Pourquoi c''est passé en livraison : la ligne vit dans la branche d''auto-élévation, qui ne s''exécute que dans une console non élevée. Une installation lancée depuis une fenêtre administrateur la saute entièrement.

C''est le troisième défaut de la famille du 01/08/2026, dans une troisième forme.

Le garde-fou

TestNoLocalVariableCollidesWithAParameterByCaseAlone refuse, dans tous les .ps1 du dépôt, une affectation à un nom qui ne diffère d''un paramètre déclaré que par la casse.

La règle porte sur la casse et non sur le fait d''affecter un paramètre, parce que ce dépôt en affecte exprès : $AccountPassword reçoit ce qui vient d''être tapé, $Pilot s''allume sur une réponse. Ceux-là écrivent le nom qu''ils ont déclaré ; une casse qui diverge est quelqu''un qui croit ouvrir une variable neuve.

Il suit les portées. Une première version comptait 15 signalements dont 14 faux — un -Directory d''une fonction contre un $directory de trois autres, qui sont quatre portées et pas une collision. if, foreach et try n''ouvrent pas de portée, ce qui est précisément par où le défaut est passé.

Il a trouvé une seconde collision réelle, dans make.ps1 : $version = Or-Else $Version … écrasait le paramètre -Version au lieu de le compléter — sans lever, une chaîne entrant dans une [string], mais en effaçant ce que l''opérateur avait demandé.

Vérifications

• Reproduit avant de toucher quoi que ce soit, au banc et non par lecture : le script réel passé à iex dans une console non élevée, Invoke-WebRequest et Start-Process bouchonnés, rend l''erreur du forum au message, à la catégorie et à l''identifiant près.
• Le même banc sur le fichier corrigé va jusqu''à « l''installation continue dans la nouvelle fenetre ».
• Le test éprouvé en cassant : collision plantée de l''autre côté du here-string de 60 lignes de common.ps1, attribuée à la bonne fonction.
• 3 115 tests Go (3 103 verts, 12 écartés) sur 35 paquets, 0 échec. go vet et gofmt sans remarque.

Ce qui n''est PAS prouvé

Aucun poste n''a été installé pour de bon : le banc s''arrête à l''appel d''élévation, et tout ce qui suit — release, empreinte, les trois questions, install.ps1 — reste non exercé sur ce chemin.

Le test lit les scripts par un découpage de texte et non par l''analyseur de PowerShell : il neutralise les chaînes d''une ligne, pas les here-strings. Celui de common.ps1 ne le trompe pas, son corps étant équilibré en accolades, mais par chance et non par construction.