État

Ces pages ont été vérifiées par rapport aux modules aux étiquettes listées dans Modules. Quand le README d’un module et son code divergent, les pages suivent le code.

Prouvé en conditions réelles

Un codec testé dans le processus prouve le codec. Voici les endroits où l’on a interrogé la plateforme elle-même :

Compilé, non exécuté

• Show/Hide/Raise sous Win32 : la table de décision est testée unitairement, les appels sur le thread de la fenêtre sont seulement compilés.
• L’Attach de la zone de notification Windows.
• La boucle DOM de webcanvas (run_js.go) : derrière une étiquette de compilation js && wasm, elle est donc hors de la couverture mesurée ; les applications qui l’utilisent l’exercent.
• Le Run natif d’application : l’ouverture d’une vraie fenêtre est exclue de sa barrière de couverture ; le contrat, la traduction des événements et le compteur de disponibilité sont couverts.

Non fait

• Les zones de notification Windows et Linux ignorent MenuItem.Icon : une ligne avec une icône se dessine sans elle.
• Le back-end Wayland de window ne sait pas faire Raise : xdg-shell n’a pas de telle requête, et xdg-activation exige un jeton issu d’une action de l’utilisateur lui-même.
• Android : android/arm64 uniquement, car c’est la seule cible Android que Go sait lier sans cgo.
• window.Screens renvoie ErrScreensUnsupported sur js/wasm.

Ce que la CI couvre

Le 2026-10-10, les cinq manques que cette page listait ont été comblés :

Les dix-sept bibliothèques et outils font donc tous désormais une compilation croisée pour les six architectures Linux 64 bits, et les dix-neuf ont tous une barrière à 100 % de couverture des instructions. app-template et gallery sont des applications de navigateur et se compilent pour js/wasm, qui est leur seule cible.

Sécurité

Mesuré avec govulncheck (au niveau des symboles : seul le code que le module peut atteindre) le 2026-10-10 :

• 15 des 19 modules atteignaient du code vulnérable : dans la bibliothèque standard de go1.27.1 (html/template, net/http, crypto/tls, mime/multipart ; corrigé dans go1.27.2) et dans golang.org/x/net v0.58.0 (http2, via gRPC dans data ; corrigé dans v0.60.0).
• Corrigé le soir même. La CI de chaque module compile avec go1.27.2, et chaque module exige x/net v0.60.0. C’est une dépendance indirecte dans la plupart d’entre eux, que Renovate ne met pas à jour : elle a donc été relevée à la main. Un second passage de govulncheck sur les 19 modules ne trouve aucune vulnérabilité atteignable.
• Publiés : android v0.16.0, app-template v0.5.0, application v0.8.0, bricolint v0.4.1, data v0.4.0, mvvm v0.15.0, mvvmlint v0.4.1, mvvmtk v0.15.0, painter v0.16.0, skin v0.3.0, svg v0.7.0, tray v0.15.0, webcanvas v0.4.1, window v0.89.0, chaque version déduite de son API par gorelease. Le 2026-10-11 : toolkit v0.329.0, puis tui v0.62.0, desktop v0.20.0, gallery v0.7.0 et isoicons v0.4.0. Pour ces quatre-là, gorelease ne peut pas charger le graphe de modules, qui atteint github.com/ajroetker/go-highway/hwy/goat v0.0.0, une version jamais publiée (ajroetker/go-highway#73) : leurs versions ont donc été déduites avec apidiff sur linux, darwin et windows, selon la même règle.
• Les workflows des 23 dépôts (31 fichiers) ont été audités avec actionlint et wfaudit : aucun déclencheur privilégié, aucune permission d’écriture au niveau du workflow, aucun jeton laissé dans un checkout téléversé, aucune expression non fiable dans une étape shell. Chaque workflow déclare ses permissions, si bien qu’aucun ne dépend du jeton par défaut d’un dépôt.