5.7 KiB
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 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.
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.