0.1.0-alpha.3

docs/rules/210-WORKFLOW.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/210-WORKFLOW.md -->
-<!-- version: 6 -->
+<!-- version: 7 -->
 
 # Workflow artifact rules
 
@@ -197,6 +197,43 @@ Un projet qui possède une convention de message différente MAY utiliser un map
 
 Le repository ne doit jamais mélanger deux tranches non clôturées dans un même commit.
 
+## Remise automatique des commandes opérateur
+
+Après production d'un history destiné à être appliqué par l'opérateur, le générateur MUST remettre spontanément les commandes nécessaires pour fermer cette tranche. Il ne doit pas attendre une demande séparée du type « je commit avec quel message ? ».
+
+Lorsque les valeurs Git sont établies par le projet ou par les sorties opérateur de la session, le bloc remis MUST utiliser les valeurs réelles : archive history, message de commit, remote et branche. Le générateur MUST NOT inventer un remote, une branche ou une politique de tag non établis. Une valeur encore inconnue doit être signalée explicitement ou résolue par une commande de découverte sûre avant la commande qui en dépend.
+
+Pour une livraison ZIP et une tranche non stable, le handoff couvre normalement dans cet ordre :
+
+```text
+apply history archive
+    ↓
+git add / staged whitespace check / status
+    ↓
+commit avec le message attendu
+    ↓
+push de la branche courante
+    ↓
+apply du delta suivant ou du fix déjà livré
+```
+
+Lorsqu'un history `FAIL`, `PARTIAL` ou `BLOCKED` conduit à un `.fix.N`, le bloc de commandes ferme d'abord la tranche constatée sous son identité propre puis autorise seulement l'application du correctif. Lorsqu'un history `PASS` conduit à la tranche planifiée suivante, le même ordre s'applique.
+
+Pour la première clôture `rel.N[/fix.M]` qui établit réellement la stable, le bloc MUST utiliser le message de commit stable `X.Y.Z`, puis fournir séparément les commandes de tag et de vérification applicables. Le tag MUST NOT être créé avant le commit stable et son push lorsque le projet exige que la branche canonique distante porte d'abord ce commit.
+
+Le handoff de publication MUST également indiquer exactement ce que l'opérateur doit remettre au générateur pour produire la preuve post-tag applicable. Pour une archive source générée par la forge à partir du tag, cela inclut normalement :
+
+- le ZIP téléchargé depuis le tag canonique ;
+- le SHA du commit stable local observé avant ou pendant le tag ;
+- le commit déréférencé localement par le tag ;
+- la référence distante du tag ;
+- pour un tag annoté, le commit distant déréférencé `refs/tags/vX.Y.Z^{}` afin de ne pas confondre l'objet tag avec son commit ;
+- toute autre preuve explicitement requise par la politique locale de publication.
+
+Le rapport `publish.*` est produit seulement à partir des artefacts et preuves réellement disponibles après publication. Il MUST NOT être prérempli avec un `PASS` futur.
+
+[`../templates/006-OPERATOR_COMMAND_HANDOFF.md`](../templates/006-OPERATOR_COMMAND_HANDOFF.md) fournit le pattern de rendu des blocs de commandes. Il complète le présent contrat sans devenir une seconde source normative.
+
 ## Manifest de suppression
 
 Lorsqu'un delta supprime des chemins, un manifest de suppression MAY être utilisé pour permettre une application fiable de l'archive.