0.0.2-alpha.4

docs/rules/210-WORKFLOW.md

@@ -0,0 +1,123 @@
+<!-- file: docs/rules/210-WORKFLOW.md -->
+<!-- version: 1 -->
+
+# Workflow local Knowledge
+
+## Unité de travail
+
+`VERSION` est l'identité canonique de la tranche courante. Une tranche est livrée par un delta, validée dans l'environnement opérateur, puis clôturée par un history qui enregistre l'observation réelle.
+
+Le cycle normal est :
+
+```text
+delta
+-> application opérateur
+-> gate applicable
+-> résultat PASS / FAIL / PARTIAL / BLOCKED
+-> history observé
+-> application du history
+-> git add / diff --cached --check / status
+-> commit
+-> push
+-> tranche suivante ou fix
+```
+
+Le delta suivant ne doit pas être appliqué avant matérialisation Git du history précédent.
+
+## Chemins et archives canoniques
+
+Les contrats de tranche vivent sous :
+
+```text
+deltas/<X.Y.Z>/<tranche>.md
+history/<X.Y.Z>/<tranche>.md
+```
+
+Les archives échangées sont séparées :
+
+```text
+sasedev-knowledge-<X.Y.Z>-<tranche>.delta.zip
+sasedev-knowledge-<X.Y.Z>-<tranche>.history.zip
+```
+
+Un history n'est jamais inclus dans le delta qu'il valide. Le delta suivant peut être livré dans la même réponse que le history précédent lorsque sa préparation est déjà déterminée, mais son application reste postérieure au commit/push du history.
+
+## Contrat d'un delta
+
+Un delta contient des fichiers complets à ajouter ou remplacer. Les suppressions éventuelles sont explicites via un manifeste de suppression lorsque le mécanisme d'application l'exige ; elles ne reposent pas sur une instruction manuelle ambiguë.
+
+Le document de delta indique au minimum :
+
+- baseline requise et version obtenue ;
+- mission et scope ;
+- fichiers/contrats réellement concernés ;
+- hors-scope et décisions différées pertinentes ;
+- gate opérateur reproductible ;
+- transition autorisée après chaque statut attendu.
+
+Un delta doit être applicable sans reconstruire à la main des patchs depuis une conversation.
+
+## Contrat d'un history
+
+Aucun history `PASS` n'est créé avant réception des preuves opérateur réelles. Une prévalidation de génération peut détecter des erreurs, mais ne constitue jamais le résultat autoritaire de la tranche.
+
+Le history enregistre au minimum :
+
+- tranche et baseline observées ;
+- statut `PASS / FAIL / PARTIAL / BLOCKED` ;
+- preuves réellement exécutées et leurs résultats utiles ;
+- anomalies/limites pertinentes ;
+- décision de transition.
+
+Un history appliqué et committé devient immuable. Un futur fix crée son propre history ; il ne remplace pas le résultat précédent.
+
+## Plans et REPLAN
+
+Une release multi-responsabilités possède un plan versionné. Le plan décrit mission, état acquis, scope, hors-scope, validation, trajectoire prévisionnelle, déclencheurs de REPLAN, clôture/transition et revue d'horizon lorsque pertinente.
+
+Les tranches de la trajectoire sont des sous-sections `###` de `## Trajectoire prévisionnelle`.
+
+Un REPLAN modifie uniquement les parties devenues fausses ou insuffisantes. Les deltas/histories gardent la chronologie détaillée ; le plan reste un document de pilotage vivant et non un journal de terminal.
+
+## Fixes
+
+Un `FAIL`, `PARTIAL` ou `BLOCKED` est conservé. Une correction bornée au même scope utilise `.fix.N`. Le history en échec est appliqué, committé et poussé avant le fix.
+
+Un fix ne doit pas absorber silencieusement une nouvelle fonctionnalité. Si le diagnostic révèle une responsabilité transverse ou une mission différente, le plan est replanifié explicitement.
+
+## Handoff opérateur
+
+Après livraison d'un history, les commandes de matérialisation Git sont fournies automatiquement. Pour `origin/master` établi dans ce dépôt, une tranche non stable suit normalement :
+
+```bash
+git add -A
+git diff --cached --check
+git status --short
+git commit -m "<VERSION>"
+git push origin master
+git status --short
+```
+
+Les commandes ne sont pas différées à une réponse ultérieure. Lorsque le delta suivant est prêt, son application est indiquée après ce bloc afin que l'ordre soit sans ambiguïté.
+
+## Prompts et changement de session
+
+Un prompt de démarrage versionné décrit la baseline exacte, les sources requises, la mission et les vérifications nécessaires pour ouvrir une release. Il ne complète pas silencieusement des données manquantes par un état supposé d'une conversation ou d'un workspace non vérifié.
+
+Une coupure de session au milieu d'une tranche ne change pas `VERSION`. Si nécessaire, un handoff local décrit l'état exact, les décisions acquises, les preuves déjà obtenues et ce qui reste à exécuter.
+
+Le pattern normal de nouvelle session est [`../templates/001-NEW_SESSION_PROMPT.md`](../templates/001-NEW_SESSION_PROMPT.md).
+
+## Stable et publication
+
+La première clôture `rel.N[/fix.M]` réellement `PASS` est committée avec le message produit `X.Y.Z`; les clôtures échouées conservent leur identifiant de tranche dans le message de commit conformément à la gouvernance locale.
+
+Le tag stable `vX.Y.Z` est créé seulement après le commit stable. L'archive téléchargée depuis ce tag est la baseline de publication autoritaire ; l'absence de `.git` dans cette archive est normale.
+
+Le rapport post-tag `sasedev-knowledge-X.Y.Z-publish.001-report.md` est une preuve distincte. Il vérifie le tag/archive réellement publiés et ne doit pas être préfabriqué comme preuve du delta `rel.1`.
+
+Le prompt d'une release suivante n'est préparé que si sa mission est réellement décidée. Aucune version future n'est inventée pour remplir un handoff.
+
+## Immutabilité des artefacts historiques
+
+Les deltas, histories et prompts déjà committés ne sont pas réécrits pour adopter une convention plus récente, corriger une esthétique ou masquer un échec passé. Une correction de contrat durable s'applique aux artefacts futurs et est documentée chez son owner local.