sasedev-knowledge/docs/rules/210-WORKFLOW.md

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 :

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 :

deltas/<X.Y.Z>/<tranche>.md
history/<X.Y.Z>/<tranche>.md

Les archives échangées sont séparées :

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 :

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 attendue, 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é.

Le cycle normal prépare le prompt de la release N+1 pendant les dernières phases de N, après la revue d'horizon qui a suffisamment défini la prochaine mission et avant la clôture stable de N. Comme le commit/tag/rapport post-tag définitifs de N n'existent pas encore à ce moment, le prompt versionné ne doit pas inventer leur SHA ou leur résultat : il exige que l'introduction de la session suivante fournisse l'archive taggée et le rapport post-tag réels et qu'ils soient vérifiés avant développement.

Si une stable historique a été fermée sans prompt de la release suivante parce que la mission n'était pas encore décidée, le prompt peut exceptionnellement être créé au démarrage réel de cette release ; cette situation est un rattrapage et non le cycle normal.

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.

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 suffisamment décidée par la revue d'horizon. Lorsqu'elle l'est, ce prompt fait partie des artefacts de fin de la release courante afin que la stable publiée contienne déjà son handoff vers la suite. Les éléments post-tag encore inconnus restent à vérifier au démarrage suivant plutôt qu'à être inventés.

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.