devis switch : spanning-tree vérifié, les six familles de syntaxe sont closes

`spanning-tree ?` en mode configuration tranche la dernière inconnue, en
faveur de la forme émise : `mode` et `priority` s'acceptent au niveau global.
La priorité n'a pas besoin d'être portée par une instance, même en MSTP — la
réserve inverse, notée la veille, était infondée et le devis ne la porte
plus. Une mise en garde fausse nuit autant qu'une syntaxe fausse.

Ajouté : `spanning-tree` seul, qui garantit l'état actif. Sans lui, `mode` et
`priority` sur un boîtier où le protocole aurait été désactivé
configureraient un arbre qui ne tourne pas. Sans effet s'il est déjà actif —
même logique déclarative que pour les trunks.

Six familles vérifiées contre le matériel : VLAN, SVI, trunks, routes, ACL,
spanning-tree. Deux ont révélé un défaut réel plutôt que de confirmer
l'existant — les routes (CIDR) et les trunks, dont `add` ne retranchait rien.

Preuves : 24 OK, 0 échec.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

CHANGELOG.md

@@ -1,5 +1,21 @@
 # CHANGELOG — Set-OPS
 
+## 2026-08-02 (suite 17) — spanning-tree vérifié : les six familles sont closes
+
+`spanning-tree ?` en mode configuration tranche la dernière inconnue, **en faveur de la forme
+émise** : `mode` et `priority` s'acceptent au niveau **global**. La priorité n'a pas besoin
+d'être portée par une instance, même en MSTP — la réserve inverse, notée la veille, était
+infondée et le devis ne la porte plus. Une mise en garde fausse est aussi nuisible qu'une
+syntaxe fausse.
+
+Ajouté : `spanning-tree` seul, qui **garantit l'état actif**. Sans lui, `mode` et `priority`
+sur un boîtier où le protocole aurait été désactivé configureraient un arbre qui ne tourne
+pas. Sans effet s'il est déjà actif — même logique déclarative que pour les trunks.
+
+**Les six familles de syntaxe sont vérifiées contre le matériel** : VLAN, SVI, trunks, routes,
+ACL, spanning-tree. Deux ont révélé un défaut réel plutôt que de confirmer l'existant — les
+routes (notation CIDR) et surtout les trunks, dont la forme `add` ne retranchait rien.
+
 ## 2026-08-02 (suite 16) — la syntaxe des ACL vérifiée sur le matériel
 
 `show access-lists` confirme la dernière famille de syntaxe restée ouverte : une ACL générée

docs/frontiere-opnsense.md

@@ -309,9 +309,15 @@ ansible-vault edit instance/inventories/principal/group_vars/all/vault.yml
   ses règles dans l'ordre (`ip access-list extended <NOM>`, masques normaux, `any`). Détail de
   lecture : le boîtier **affiche** `any-destination` là où l'on saisit `any` — comparer un
   `show access-lists` au devis fait apparaître une différence qui n'en est pas une.
-- **Reste non vérifiée** : la forme d'**entrée** des commandes de spanning-tree. `show` en
-  donne l'état, pas la syntaxe. En MSTP, la priorité se règle en général par instance, ce qui
-  n'est pas la forme émise — le devis le signale lui-même à cet endroit.
+- ~~La syntaxe du spanning-tree~~ — **réglé le 2026-08-02** par `spanning-tree ?` en mode
+  configuration : `spanning-tree` seul active le protocole, `mode` et `priority` s'acceptent au
+  niveau **global**. La priorité n'a donc pas besoin d'être portée par une instance, même en
+  MSTP — la réserve inverse, notée la veille, était infondée.
+
+**Les six familles de syntaxe sont désormais vérifiées contre le matériel** : VLAN, SVI,
+trunks, routes, ACL, spanning-tree. Deux d'entre elles ont révélé un défaut réel plutôt que de
+confirmer ce qui était écrit — les routes (notation CIDR) et surtout les trunks, dont la forme
+`add` ne retranchait rien.
 - **Les ports physiques restent à nommer** — `<PORT-VERS-PROXMOX>`, `<PORT-VERS-FRONTIERE>`
   et `<PORT-TRUNK>` ; rien dans le modèle ne peut les deviner.
 - ~~**La sortie générale** n'est pas déclarée~~ — **réglé le 2026-08-02.** Elle est

scripts/devis_reseau.py

@@ -176,21 +176,18 @@ def _stp_lignes(dialecte: str, mode: str, priorite: int) -> list[str]:
     Cisco IOS parle `rapid-pvst` (RSTP par VLAN) ; les plateformes generiques parlent
     `rstp`/`mstp` et une priorite globale.
 
-    FORME NON VERIFIEE : `show spanning-tree` donne l'ETAT du protocole, pas la syntaxe
-    d'entree. En MSTP notamment, la priorite se regle souvent PAR INSTANCE — la forme
-    globale ci-dessous pourrait etre refusee. A confronter a `spanning-tree ?` en mode
-    configuration.
+    Formes VERIFIEES sur Binardat (`spanning-tree ?` en mode configuration, 2026-08-02) :
+    `spanning-tree` seul active le protocole, `mode` et `priority` s'acceptent au niveau
+    GLOBAL — la priorite n'a pas besoin d'etre portee par une instance, meme en MSTP.
     """
     if dialecte == "cisco":
         return [f"spanning-tree mode {'rapid-pvst' if mode == 'rstp' else mode}",
                 f"spanning-tree vlan 1-4094 priority {priorite}"]
-    lignes = [f"spanning-tree mode {mode}", f"spanning-tree priority {priorite}"]
-    if mode == "mstp":
-        lignes.append(f"! ^ en MSTP, la priorite est souvent portee par une INSTANCE "
-                      f"(ex. `spanning-tree mst 0 priority {priorite}`).")
-        lignes.append("! Forme a confirmer par `spanning-tree ?` ; celle-ci reprend la "
-                      "syntaxe globale.")
-    return lignes
+    # `spanning-tree` seul garantit l'etat actif : sur un boitier ou il aurait ete
+    # desactive, les deux lignes suivantes ne suffiraient pas. Sans effet s'il l'est deja.
+    return ["spanning-tree",
+            f"spanning-tree mode {mode}",
+            f"spanning-tree priority {priorite}"]
 
 
 def section_stp(underlay: dict | None, dialecte: str) -> list[str]: