# S.A.W. 3.2 — Spécification exécutable

Version 3.2 ; révision normative `3.2.0-2026-09-27`. Ce document définit le protocole documentaire S.A.W. (SDD Another Way), remplace 3.1 et sert de référence manuelle. `MUST` = obligation, `MUST NOT` = interdiction, `SHOULD`/`SHOULD NOT` = recommandation forte/déconseil fort (justifier tout écart), `MAY` = faculté ; ces sens valent quelle que soit la langue. Appliquer toutes les obligations pertinentes ; les exemples ne créent pas de dérogation. Un projet MUST rester utilisable avec des fichiers Markdown seuls, sans agent, fournisseur de LLM, IDE, programme, script, preset, Python, matériel, Git, branches, autre gestionnaire de versions ou format propriétaire imposés. Les Markdown font autorité ; aucune règle indispensable ne peut résider seulement dans un outil, plugin, prompt caché, runtime ou conversation antérieure. Une commande/programme MAY traiter le déterministe, un LLM la compréhension sémantique, Markdown l'intention durable ; la validation métier revient à l'humain. L'automatisation MAY vérifier et préparer des opérations documentaires, MUST NOT se substituer aux décisions humaines. Elle SHOULD retirer plus de complexité qu'elle n'en ajoute.

## 1. Périmètres, artefacts et emplacements

Un **projet S.A.W.** est une unité de pilotage documentaire, quelle que soit sa taille : application entière, domaine, fonction ou autre périmètre identifiable, sans dépôt ni projet organisationnel distinct exigé. Chaque projet possède une racine documentaire et ses propres artefacts. Conserver explicitement intention, périmètre, règles, décisions, état, connaissances, validations et écarts. Chaque artefact répond à sa question ; une information SHOULD rester dans son artefact et être référencée ailleurs plutôt que recopiée.

| Artefact global | Rôle | Obligation |
|---|---|---|
| `README.md` | Protocole de travail, point d'entrée universel | Requis |
| `PROJECT.md` | Produit, raison et périmètre | Requis |
| `RULES.md` | Contraintes actives | Requis |
| `STATUS.md` | État courant des lots | Requis |
| `LEDGER.md` | Décisions durables et raisons | Requis |
| `HISTORY.md` | Opérations significatives, acteur et date | Requis dans cette version `-EXEC` |

| Artefact par lot reconnu | Rôle |
|---|---|
| `SPEC-xxx.md` | Intention et exigences |
| `FINDINGS-xxx.md` | Connaissances acquises |
| `GATES-xxx.md` | Conditions de fermeture |
| `CONVERGENCE-xxx.md` | Résultat, écarts et certification de fermeture ; MAY être absent avant sa préparation, MUST exister pour un lot fermé |

Placer les six globaux requis à la racine, puis chaque lot principal sous `Specs/<numéro>-<nom-court>/` avec ses quatre fichiers canoniques ; placer un sous-lot sous le dossier parent dans `<numéro-parent>-<numéro-enfant>-<nom-court>/`. Copier aussi à la racine le fichier **exécutable** de la version appliquée de S.A.W. ; son nom, sa version et sa révision MUST l'identifier sans ambiguïté. Il est la référence normative distribuée, sans devenir un type d'artefact supplémentaire. Les noms des fichiers normatifs sont en anglais. Le nom court de dossier SHOULD être descriptif, stable, en minuscules avec tirets et indépendant de l'état du lot. Le parent garde son identifiant : `LOT-001` MUST NOT devenir `LOT-001-000`.

## 2. Identifiants, références, dates et conservation

Chaque identifiant MUST être unique dans son projet et immuable ; un identifiant retiré, annulé ou obsolète MUST NOT être réutilisé. L'identifiant fait autorité, le lien Markdown est facultatif et un lien cassé ne l'invalide pas. Formes (`n` = chiffre, chaque segment numérique a trois chiffres sauf `EVT` à six) : `LOT-nnn`, sous-lot `LOT-nnn-nnn`, `REQ-<lot>-nnn`, `REQ-<lot>-<sous-lot>-nnn`, `F-<lot>-nnn`, `F-<lot>-<sous-lot>-nnn`, `G-<lot>-nnn`, `G-<lot>-<sous-lot>-nnn`, `D-nnn`, `R-nnn`, `EVT-nnnnnn` (seulement si le format détaillé de `HISTORY` est choisi). Une référence d'incarnation archivée comme `LOT-001-OBSOLETE-001` est unique, jamais réutilisée et ne crée pas de nouvel identifiant logique : celui-ci reste `LOT-001`. Référencer un objet par son identifiant (`Source: F-001-010`), avec lien facultatif.

Horodatage par défaut : `YYYY-MM-DDTHH:mm:ss`. Un projet international SHOULD imposer `YYYY-MM-DDTHH:mm:ss±HH:mm` ; tout choix différent du défaut MUST figurer dans `RULES.md`. Une validation humaine exige un nom libre ; plusieurs personnes MAY figurer, sans adresse, compte ni signature cryptographique imposés. S.A.W. ne détermine pas leur autorité.

Tout élément cessant d'être actif MUST rester présent avec un titre commençant par `[OBSOLETE]` (date facultative : `[OBSOLETE YYYY-MM-DD]`). Un remplacement MUST porter `Replaced by: <id>` sur l'ancien et `Replaces: <id>` sur le nouveau ; `Replaced by` est la forme normative. Le contenu obsolète MUST être conservé et MUST NOT être réécrit, sauf correction typographique sans changement de sens. Lors du remplacement complet d'un document de lot, garder le nom canonique pour l'actif (`SPEC-001.md`) et archiver successivement `SPEC-001-OBSOLETE-001.md`, `...-002.md` ; le suffixe désigne une archive, pas un nouveau lot. Un objectif réellement différent MUST recevoir un nouveau `LOT`. Une incarnation complète obsolète MAY être conservée dans `001-nom-OBSOLETE-001/` ; ses fichiers SHOULD porter le même suffixe, le remplacement actif reprend le chemin canonique, et `STATUS` MUST contenir une ligne pour chaque incarnation obsolète reconnue et pour l'active. Aucun fichier existant ne doit être détruit.

## 3. Bootstrap et contrats des artefacts globaux

`README.md` MUST rester le point d'entrée universel et permettre de retrouver toutes les règles applicables sans mémoire de conversation ni convention locale non écrite. Sections minimales : `# S.A.W. project protocol`, puis `## Purpose of this file`, `## Protocol reference`, `## Mandatory bootstrap`, `## Starting a lot`, `## Working on a lot`, `## Validating a lot`, `## Closing a lot`, `## Mutation rules`, `## Human-only decisions`. Ne pas y mettre définition détaillée du produit, règles techniques détaillées, état détaillé des lots ni historique des décisions. `Protocol reference` MUST indiquer version et révision appliquées, déclarer que le projet suit la méthode décrite dans le fichier exécutable copié à la racine et fournir un lien Markdown direct vers lui ; une « version courante » non identifiée ne suffit pas. Une transmission dite autonome MUST inclure cette spécification et les documents nécessaires au bootstrap. Consulter les procédures applicables avant exécution ; la compétence dans le travail demandé peut être supposée, mais MUST NOT l'être pour des décisions ou procédures locales non écrites.

Pour tout travail sur un lot, lire **dans cet ordre** : `README.md` → `PROJECT.md` → `RULES.md` → toutes les décisions **actives** de `LEDGER.md` → décisions obsolètes explicitement référencées → `STATUS.md` → `SPEC` → `FINDINGS` → `GATES` → `CONVERGENCE` si présent. La lecture de toutes les décisions actives est obligatoire ; une décision obsolète non référencée MAY ne pas être lue entièrement. `HISTORY` n'est pas dans le bootstrap habituel mais SHOULD être consulté quand la chronologie aide reprise, réconciliation ou audit. Tous les artefacts du lot MUST commencer par un renvoi court vers le `README.md` racine (par exemple `> Before working on this lot, read the repository root README.md.`), sans y recopier le bootstrap.

`PROJECT.md` définit le produit, pourquoi il existe et, dans une Application, sa contribution et son périmètre propre. Sections minimales : `# Project`, puis `## Purpose`, `## Problem`, `## Users and actors`, `## Scope`, `## Out of scope`, `## Stable functional characteristics`, `## Glossary`. Il est très stable ; MUST NOT contenir état des lots, tâches courantes, choix techniques détaillés ou historique des décisions. Ses éléments n'ont pas d'identifiant par défaut, mais MAY en recevoir un pour une référence stable. Une modification significative est réservée à l'humain.

`RULES.md` contient les contraintes actives (plateformes, langages, runtimes, architecture, bibliothèques imposées/interdites, sécurité, tests, conventions, dates). Une règle initiale n'exige pas de ledger ; forme : `## R-nnn — Title`, `Status: ACTIVE`, `Source: Initial project rule`, `Rule: ...`, `Replaces: None`, `Replaced by: None` ; `Rationale` facultatif. Après initialisation, toute règle ajoutée ou modifiée MUST référencer une décision du ledger ; préserver l'ancien texte sous `## [OBSOLETE date] R-...` avec `Status: OBSOLETE`, `Replaced by: R-...`, `Decision: D-...`, et créer la nouvelle règle `Status: ACTIVE`, `Source: D-...`, `Replaces: R-...`. Pour un finding : finding → décision humaine → ledger → ancienne règle obsolète si besoin → nouvelle règle active. Toute évolution MUST préciser sa portée dans la règle ou sa décision : travaux futurs, lot courant, résultats fermés désignés ou tous résultats concernés. La décision MUST examiner les lots potentiellement affectés, consigner les suites et signaler explicitement qu'aucune action n'est nécessaire si tel est le constat. Pour les lots en cours, traiter les validations selon §7. Une règle nouvelle MUST NOT rouvrir automatiquement un lot fermé : identifier toute incompatibilité applicable et son traitement dans la décision ; une reprise reste humaine (§8–9). La convergence antérieure reste inchangée jusqu'à une reprise et atteste le contexte d'origine.

`STATUS.md` est **l'unique autorité** sur l'état courant des lots, sans historique détaillé ni suivi des personnes/agents. Table minimale : `Lot reference | Parent | Title | Status | Replaced by | Comment`. Une référence est l'identifiant canonique ou celui d'une incarnation archivée ; inscrire le lot dès `Planned` (un brouillon MAY être absent) et toutes les incarnations obsolètes reconnues. Ne recopier l'état comme autorité dans aucun autre artefact. Avant interruption/transmission, les artefacts MUST indiquer le résultat disponible et son emplacement (ou son absence), le travail restant connu, les blocages et leurs conditions de levée, et la prochaine action/décision ; `STATUS` MUST en donner un résumé courant ou des références, éventuellement dans une section par lot. Référencer plutôt que dupliquer : causes dans `FINDINGS`, validations dans `GATES`, intention/dépendances dans `SPEC`. Mettre ces informations à jour quand elles changent ; une phrase suffisante n'est pas un journal d'activité.

`LEDGER.md` ne garde que les décisions durables et leurs raisons, ni journal de bord, liste de problèmes/commandes ou copie des findings. Forme : `## D-nnn — Title` ; champs obligatoires `Date`, `Decided by`, `Decision`, `Reason` ; facultatifs `Source`, `Related`, `Consequences`, `Replaces`, `Replaced by` (`Source: None` autorisé pour l'initial). Plusieurs décideurs autorisés MAY être indiqués. Une autre clause peut rendre une information obligatoire même si son champ est facultatif, notamment la portée/les conséquences d'une règle. Une décision validée est immuable : une correction de fond crée une nouvelle décision, marque l'ancienne `[OBSOLETE]` et lie les deux ; seule une correction typographique sans changement de sens MAY être directe.

## 4. Historique des opérations

`HISTORY.md` est **obligatoire** dans cette version `-EXEC` : son absence MUST bloquer la planification, la validation et la fermeture d'un lot. Il journalise chronologiquement les actes significatifs du projet documentaire, sans remplacer `LEDGER`, `STATUS` ni les autres artefacts. Son existence et sa forme SHOULD être annoncées dans `README.md`. L'exécutant MUST y consigner création/transitions de lots, évolution d'exigence/règle/gate, décision/finding, validation, convergence, reprise/réconciliation ; des opérations proches MAY être groupées en une entrée intelligible ; lectures, recherches et commandes sans effet documentaire MAY être omises. Ce n'est pas un journal exhaustif de développement. Le format détaillé reste facultatif.

Format détaillé MAY utiliser `EVT-nnnnnn` dans le titre, puis `Date`, `Actor`, `Operation`, `References`, `Documents`, `Decision`, `Outcome`, `Summary` : date selon §2 ; acteur = exécutant ; références = objets ; documents = chemins relatifs à la racine ; décision = identifiant du ledger ou `None` ; outcome constaté (`Started`, `Applied`, `Interrupted`, `Reconciled`) ; résumé MAY être bref. Si les `EVT` sont employés, ils MUST être uniques et SHOULD croître ; correction/réconciliation SHOULD référencer l'événement concerné. Conserver les entrées par ajout ; une opération simple SHOULD être notée après application ; pour une opération composée, une entrée de début et une entrée de résultat sont conseillées si le niveau de détail choisi le permet, tandis qu'une tenue manuelle sommaire MAY ne noter que le résultat vérifié. Un `Started` sans résultat appelle vérification : comparer les artefacts selon §10, sans inférer l'état du seul journal. Une écriture non consignée SHOULD susciter une réconciliation sans inventer date ou acteur historique. Le journal permet de reconstruire les faits consignés, sans garantir capture de chaque édition ni anciennes versions ; archives, historiques de gates, convergences et éventuel versionnement gardent leurs contenus selon leurs règles.

## 5. SPEC et FINDINGS

`SPEC-xxx.md` définit l'intention du lot, sans règles globales, journal de travail, findings, résultats de gates ni conclusion. Structure minimale : `# LOT-nnn — Title` ; renvoi au README racine ; `## Objective`, `## Context`, `## In scope`, `## Out of scope`, `## Requirements`, `## Important cases`, `## Dependencies`, `## Known constraints`. `Parent` et `Created` sont facultatifs ; `Status` MUST NOT y faire autorité. Une exigence active a `### REQ-... — Title` puis son texte normatif. Avant `In-progress`, la spec MAY être complétée sans décision ; après, correction de forme/sans changement de sens MAY rester directe, mais ajout, retrait ou changement de sens MUST référencer une décision du ledger, conserver l'ancien texte visible et ne jamais réutiliser son identifiant. L'ancienne exigence porte `[OBSOLETE date]`, `Replaced by: REQ-...`, `Decision: D-...` ; la nouvelle porte `Replaces: REQ-...`, `Decision: D-...`.

`FINDINGS-xxx.md` conserve les connaissances, sans transformer automatiquement un finding en décision. Structure : `# Findings — LOT-...` ; renvoi au README ; chaque `## F-... — Title` porte `Status`, `Found at`, `Finding`, `Destinations` ; `Evidence` et `Impact` facultatifs, auteur non exigé. États : `OPEN`, `RESOLVED LOCALLY`, `PROMOTED TO LEDGER`, `PROMOTED TO RULE`, `DEFERRED TO LOT`, `DISCARDED`. Plusieurs terminaux MAY se combiner pour plusieurs destinations ; `OPEN` ne se combine pas avec terminal ; `DISCARDED` ne se combine pas avec promotion et MUST donner une raison. Destinations cumulables : `Local`, `Ledger: D-...`, `Rule: R-...`, `New lot: LOT-...`, `Discarded`. Créer un lot depuis un finding requiert une décision humaine. `OPEN` n'interdit pas automatiquement `Ready-to-close`, mais chaque finding MUST être examiné et traité avant fermeture : aucun `OPEN`, états terminaux cohérents avec destinations, références existantes, lot destinataire au moins `Planned`, résolution locale suffisamment expliquée, rejet motivé. Le traitement du finding doit être achevé ; le travail d'un lot ultérieur MAY rester à faire, sans dispenser d'accepter explicitement un écart éventuel aux exigences actives du lot fermé.

## 6. GATES : définition, verdicts, preuves

`GATES-xxx.md` définit les conditions de fermeture, sans décrire l'implémentation ni devenir une seconde spec. Le créer avec le lot ; définir les gates **avant** `Planned`. Après `In-progress`, ajout, retrait ou changement de sens MUST référencer une décision du ledger. Types exclusifs : `AUTO` (verdict déterministe, même lancé par agent/LLM), `LLM` (analyse sémantique), `HUMAN` (verdict humain). Toute validation métier MUST être `HUMAN`, sauf décision humaine démontrant l'absence d'impact métier. Verdicts : `TO TEST`, `PASS`, `FAIL`, `N/A`. Passer à `N/A` exige décision humaine inscrite au ledger ; celle-ci MUST préciser raison et conditions de non-applicabilité.

Chaque gate a `## G-... — Title`, `Type`, `Status`, `Defined at`, `Condition`. Pour `AUTO`, définir `Method`, puis conserver `Tested at`, `Evaluated result`, `Result`, `Evidence`. Pour `LLM`, conserver `Evaluated at`, `Evaluated result`, `Evaluator`, `Rationale` ; la justification concise est obligatoire, ainsi que l'identification du modèle lorsqu'elle est disponible. Pour `HUMAN`, conserver `Validated at`, `Validated by`, `Evaluated result`, `Comment` ; `PASS` exige horodatage et nom de l'humain, commentaire/preuves facultatifs ; un LLM MUST NOT la déclarer satisfaite. Toute évaluation MUST identifier assez le résultat examiné pour juger sa validité à la fermeture, dans `GATES` ou par référence : version de document, livraison nommée, copie conservée ou révision de VCS peuvent convenir ; plusieurs gates MAY partager une identification. Un chemin vers un contenu changeant, seul, ne distingue pas deux résultats. Aucun Git, hash ou archivage complet n'est imposé : choisir un moyen proportionné.

Une gate active (non retirée/remplacée) participe seule au verdict courant : `PASS` valable satisfait, `N/A` avec décision applicable dispense, `TO TEST`/`FAIL` interdit la fermeture ; une gate obsolète est historique. `[OBSOLETE]` n'est pas un cinquième verdict. Retrait/remplacement MUST conserver définition et historique, appliquer §2 et, après démarrage, référencer le ledger ; un remplacement MUST avoir nouvel identifiant et liens réciproques ; un retrait sans remplaçant MUST être motivé. `N/A` reste active et ne doit pas être confondu avec retrait.

Une gate `FAIL` MAY redevenir `TO TEST` puis `PASS`. Avant toute réinitialisation **ou nouvelle évaluation**, préserver dans `### Test history` le verdict antérieur, sa date, l'identification du résultat évalué, preuves/justifications disponibles et identité du validateur si requise, y compris pour un ancien `PASS`. Toute modification du résultat, d'une exigence, d'une règle applicable ou d'une condition de validation pouvant affecter un acquis MUST déclencher un examen d'impact consigné brièvement dans `GATES` ou par décision référencée. Les gates affectées MUST repasser `TO TEST` après archivage de leurs résultats ; si l'impact est indéterminable, réévaluer toutes les gates actives sauf `N/A` encore applicables. Justifier tout `PASS` maintenu après examen ; une validation `HUMAN` affectée MUST être refaite par un humain. Réexaminer les décisions `N/A` : si leurs conditions cessent, repasser `TO TEST` ; un nouveau `N/A` exige une nouvelle décision humaine au ledger. Si une gate active devient `TO TEST`/`FAIL` pendant `Ready-to-close`, revenir à `In-progress` avant de poursuivre.

## 7. CONVERGENCE et fermeture

`CONVERGENCE-xxx.md` certifie la fermeture en comparant exigences actives, résultat réel, évolutions d'intention visibles dans `SPEC`, findings essentiels et résultats essentiels des gates, sans recopier ces artefacts. Pour **chaque** exigence active, établir satisfaction ou écart précis accepté par décision humaine référencée ; des identifiants groupés avec conclusion commune MAY suffire, sans matrice ni copie exhaustive du texte. Identifier dans `Result obtained` le résultat finalement accepté et le rapprocher des résultats évalués dans `GATES`. Structure minimale : `# Convergence — LOT-...` ; renvoi au README ; `Closed at`, `Closed by`, `Decision`, `Convergence` ; `## Result obtained`, `## Differences from active requirements`, `## Essential gate results`, `## Findings disposition`, `## Residual work`, `## Closure decision`, `## Historical convergences`.

`Convergence` vaut `TOTAL` si toutes les exigences actives sont satisfaites, `PARTIAL` si au moins un écart est accepté par l'humain. Une `PARTIAL` exige au ledger décision, raison, date et identité humaine ; une divergence non acceptée interdit fermeture. Aucun écart accepté ni `PARTIAL` ne neutralise `FAIL`/`TO TEST`. Une fermeture totale ordinaire n'exige pas d'entrée au ledger ; `PARTIAL`, gate `N/A`, écart accepté pendant fermeture et toute décision exceptionnelle en exigent une. Après fermeture, convergence courante stable : MUST NOT la modifier avant reprise ; la conserver inchangée si lot `Obsolete`/`Abandoned` sans reprise.

**Procédure manuelle de fermeture, dans cet ordre logique :** (1) bootstrap et résolution des incohérences bloquantes ; (2) identifier résultat présenté, gates actives, retraits/remplacements ; (3) vérifier `AUTO`, `LLM`, `HUMAN`, validité de leurs résultats et décisions/conditions `N/A`, refaire les validations nécessaires et refuser si gate active `FAIL`/`TO TEST` ; (4) examiner chaque exigence active, les obsolètes et remplacements, chaque finding et sa destination ; (5) préparer `CONVERGENCE` `TOTAL`/`PARTIAL` ; (6) obtenir les décisions humaines nécessaires et les inscrire au ledger, mettre à jour `RULES` avec portée/conséquences, créer/planifier les lots décidés, achever les findings et réexaminer les validations/écarts affectés en reprenant les contrôles nécessaires ; (7) vérifier l'absence de refus, passer `Ready-to-close` si nécessaire ; (8) présenter à l'humain le résultat identifié, la convergence et les décisions associées, obtenir son acceptation ; (9) finaliser `CONVERGENCE` et les mises à jour transversales approuvées, contrôler leur cohérence ; (10) passer `STATUS` à `Closed` **en dernier**. Toute modification pendant la préparation de fermeture suit les règles de validité des gates ; l'acceptation porte sur le résultat et les écarts effectivement présentés dans la convergence finalisée. L'humain MAY accepter un écart pendant fermeture, avec décision au ledger ; si l'écart exige une modification du résultat, revenir de `Ready-to-close` à `In-progress` avant de modifier et réexaminer les gates. L'acceptation humaine MUST NOT contourner les conditions normatives.

Refuser la fermeture si : gate active `TO TEST`/`FAIL` ; gate `HUMAN` applicable sans humain nommé et daté ; `N/A` sans décision applicable ; mutation de gate irrégulière ; validation invalide pour le résultat présenté ; résultat ou lien aux résultats évalués non identifiable ; exigence active non examinée ; écart ni corrigé ni accepté ; finding `OPEN`, non examiné ou sans traitement/destination conforme ; décision obligatoire absente ; incohérence documentaire pertinente non résolue ; convergence impossible. Après refus, `Ready-to-close` → `In-progress` ; `In-progress` y reste ou devient `Blocked` si travail impossible ; `Blocked` y reste jusqu'à levée du blocage, selon §9.

## 8. Reprise, réactivation et capitalisation

Pour reprendre **avec modification** un lot `Closed`, `Obsolete` ou `Abandoned` : lire toute convergence ; obtenir avant application la décision humaine au ledger et les préconditions de §9 ; si fermeture antérieure, copier sans perte ses sections courantes dans une nouvelle entrée `Historical convergences`, puis réinitialiser les sections courantes ; conserver les résultats de gates dans `Test history`, remettre toutes les gates actives applicables à `TO TEST`, réexaminer `N/A` selon §6 ; ensuite seulement enregistrer `In-progress` dans `STATUS`, modifier, refaire toutes les validations applicables et obtenir une nouvelle fermeture humaine. Une obsolescence avant fermeture MAY n'avoir aucune convergence : ne pas inventer de fermeture historique ; identifier et conserver tout brouillon avant réinitialisation. Chaque entrée historique MUST garder au minimum ancien niveau, date, responsable, résultat, écarts et décision de fermeture ; ne pas modifier les entrées historiques précédentes.

Un lot `Abandoned` MAY redevenir `Closed` **sans modification ni nouvelle validation** seulement si le résultat est inchangé, aucune règle active nouvelle ne l'invalide et un humain décide explicitement la réactivation dans le ledger avec raison, date et identité. Conserver convergence et gates ; mettre à jour `STATUS`.

Avant fermeture, traiter tous les findings, inscrire les décisions durables, mettre à jour les règles approuvées, créer/planifier les lots décidés et enregistrer le travail résiduel. Les décisions humaines réservées sont : modification significative de `PROJECT`, évolution de `RULES`, changement de sens de spec/gates après démarrage, verdict `HUMAN`, `N/A`, acceptation d'écart/`PARTIAL`, lot créé depuis finding, fermeture, annulation, remplacement, abandon, reprise et réactivation. Une automatisation MAY les préparer mais MUST demander la décision humaine avant de les rendre effectives.

## 9. États, transitions et séquentialité d'un projet

États autorisés : `Draft` (fichiers en préparation, non planifié), `Planned` (spec/gates définies), `In-progress` (exécution), `Blocked` (exécution empêchée), `Stand-by` (parent suspendu pour sous-lot), `Ready-to-close` (travail fini, gates valables, attente de fermeture humaine), `Closed` (convergence et acceptation humaines), `Cancelled` (arrêt avant fermeture, sans remplacement), `Obsolete` (remplacé, fermé ou non), `Abandoned` (résultat fermé ensuite écarté sans remplacement). **Seules** les transitions ci-dessous sont permises ; toute autre MUST NOT être effectuée. Chaque transition respecte le créneau actif, ses préconditions et les procédures référencées. « Ledger non requis » ne dispense pas d'une décision exigée pour une autre raison.

| Départ → arrivée | Préconditions, décision et effets obligatoires |
|---|---|
| `Draft → Planned` | Identifiant attribué, spec suffisamment définie et gates définies ; ledger non requis ; inscrire dans `STATUS`. |
| `Planned → In-progress` | Bootstrap achevé, créneau disponible ou transfert conforme ; démarrage décidé par humain, sans ledger pour la transition ; actualiser `STATUS`, suspendre le parent si sous-lot. |
| `In-progress → Blocked` | Blocage réel ; ledger non requis pour constat ; documenter cause, levée et reprise, puis `STATUS`. |
| `Blocked → In-progress` | Condition de levée satisfaite et décisions nécessaires obtenues ; ledger non requis pour transition ; actualiser reprise, examiner validations, puis `STATUS`. |
| `In-progress → Stand-by` | Sous-lot identifié et démarrage autorisé par humain ; ledger non requis pour transfert ; garder reprise du parent et coordonner `STATUS`. |
| `Stand-by → In-progress` | Sous-lot responsable `Closed`/`Cancelled`/`Obsolete`, créneau libre ; retour décidé par humain, sans ledger pour transition ; examiner résultat/validations du parent, actualiser reprise et `STATUS`. |
| `In-progress → Ready-to-close` | Travail fini, toutes gates actives `PASS` valables ou `N/A` autorisées ; ledger non requis hors décisions de gates ; vérifier et mettre `STATUS` à jour. |
| `Ready-to-close → In-progress` | Correction, refus ou validation invalide ; décisions de correction selon leur nature, pas de ledger pour retour seul ; consigner motif, traiter gates et actualiser `STATUS`. |
| `Ready-to-close → Closed` | Procédure achevée et aucune cause de refus ; acceptation humaine, ledger selon §7 ; finaliser convergence et mises à jour approuvées, puis `STATUS`. |
| `Draft/Planned/In-progress/Blocked/Stand-by/Ready-to-close → Cancelled` | Arrêt avant fermeture sans remplacement ; résoudre explicitement le sort du sous-lot si parent suspendu ; décision humaine au ledger ; conserver fichiers et inscrire état final dans `STATUS`, même si brouillon absent jusque-là. |
| `Draft/Planned/In-progress/Blocked/Stand-by/Ready-to-close/Closed → Obsolete` | Remplaçant identifié ; résoudre le sous-lot si parent suspendu ; décision humaine au ledger ; conserver fichiers/convergence, lier les remplacements et inscrire les incarnations dans `STATUS`. |
| `Closed → Abandoned` | Résultat non retenu sans remplaçant ; décision humaine motivée au ledger ; conserver convergence inchangée, actualiser `STATUS`. |
| `Closed/Obsolete/Abandoned → In-progress` | Reprise avec modification, créneau disponible/transfert autorisé ; si `Obsolete`, résoudre le sort du remplaçant ; décision humaine préalable au ledger ; préparer §8, puis `STATUS`. |
| `Abandoned → Closed` | Résultat inchangé, aucune règle active applicable invalidante ; décision humaine motivée, datée et nominative au ledger ; conserver convergence/gates et actualiser `STATUS` sans revalider. |

Une correction demandée pendant la fermeture MUST passer par `In-progress`, puis éventuellement `Blocked`. Une opération documentaire interrompue suit §10 et ne crée aucune transition supplémentaire. Toute annulation, obsolescence, abandon, reprise ou réactivation exige décision humaine au ledger. Depuis `Ready-to-close`, annulation ou remplacement peut être direct. Reprendre `Obsolete` MUST résoudre le remplaçant, préserver les archives et laisser une seule incarnation active du lot logique. `Cancelled` = non fermé/non réalisé/sans remplaçant ; `Obsolete` = remplacé avec remplaçant et décision ; `Abandoned` = fermé puis résultat non retenu sans remplacement avec raison. Un lot annulé/obsolète avant fermeture MAY ne pas avoir de convergence ; conserver toute convergence existante.

**Un seul créneau actif par projet** : au plus un lot parmi `In-progress`, `Blocked`, `Ready-to-close`. Le lot `Blocked` bloque tous les autres lots du même projet jusqu'à `In-progress`, `Cancelled` ou `Obsolete`. Nominalement, le lot suivant attend la fermeture (findings traités, gates évaluées, convergence, acceptation humaine). `Cancelled`/`Obsolete` MAY aussi libérer le créneau comme exceptions documentées, MUST NOT servir à contourner une gate ou simuler une fermeture. `Stand-by` est la seule suspension normale du parent. Pour démarrer un sous-lot, parent MUST être `In-progress`, sous-lot prêt à démarrer/reprendre et les deux identifiables dans `STATUS` ; inscrire **d'abord** le parent `Stand-by`, **ensuite** le sous-lot comme seul `In-progress` ; une interruption entre écritures suit §10. Après fermeture/annulation/obsolescence du sous-lot, le retour du parent est manuel, attend un créneau libre et examine l'effet du sous-lot sur son travail et ses validations. Aucun parallélisme de lots au sein d'un même projet n'est défini.

## 10. Création, exécution et écritures interrompues

Un brouillon physique MAY comprendre `SPEC`, `FINDINGS`, `GATES` sans convergence. Le lot devient `Planned` quand identifiant attribué, spec assez définie, gates définies et inscription dans `STATUS` ; avant, il reste `Draft`. Après `In-progress`, correction sans changement de sens ne requiert pas de décision ; toute modification du sens de `SPEC`/`GATES` exige décision du ledger et conservation des informations remplacées. Reconstruire le contexte par le bootstrap ; avant de travailler, résoudre les incohérences touchant intention, validations ou état, et consulter les informations de reprise. L'humain décide le démarrage ; consigner les nouvelles connaissances dans `FINDINGS`, les changements d'intention dans `SPEC`, réexaminer les validations après modification et maintenir les informations de reprise. Évaluer chaque gate active applicable selon son type sur un résultat identifié. `Ready-to-close` n'est possible et ne reste valable qu'avec `PASS` applicable ou `N/A` autorisé pour toutes les gates actives.

Une décision enregistrée ne prouve pas que ses effets ont été écrits. Pour toute opération à plusieurs écritures : **(1)** obtenir la décision humaine requise et la consigner au ledger avant application si exigé ; **(2)** préserver contenus/résultats antérieurs avant remplacement/réinitialisation ; **(3)** mettre à jour artefacts gouvernés, références et validations affectées ; **(4)** vérifier la cohérence ; **(5)** écrire dans `STATUS` le changement d'état constatant l'achèvement **en dernier** parmi contenu et état, puis l'entrée de résultat dans `HISTORY`. Un état autorisant la reprise (`In-progress`) est enregistré après préparations documentaires et avant modification du résultat ; pour parent/sous-lot, respecter l'ordre §9. En cas d'interruption, MUST comparer les écritures à la décision et repérer ce qui manque. Si la décision règle clairement la suite, MUST achever sans nouvelle décision ni redemander une acceptation déjà documentée. Si décision nécessaire absente, ambiguë ou incompatible, obtenir clarification humaine avant le travail dépendant et inscrire une nouvelle décision durable si nécessaire ; sans décision requise, MAY achever depuis les faits conservés et règles applicables sans inventer d'information. `STATUS` reste l'autorité enregistrée ; ne jamais résoudre une incohérence en effaçant ancienne validation/décision/fermeture ; préserver les traces et transitions autorisées. Réconciliation manuelle sans outil/transaction imposés ; consigner les événements dans `HISTORY` selon §4 sans le prendre pour preuve suffisante des artefacts.

## 11. Application et parallélisme entre projets

Une **Application** est un ensemble de projets S.A.W. contribuant à une même application (fonction, domaine ou partie de fonction), sans dépôt ni projet organisationnel séparé exigé ; un projet MAY aussi être autonome. Un simple dossier parent ne valide pas le parallélisme. Une Application structurée est au-dessus des racines de ses projets et MUST posséder `README.md` (bootstrap global), `APPLICATION.md` (nature/finalité/périmètre), `RULES.md` (règles globales), `STATUS.md` (suivi des projets), `PROJECTS.md` (inventaire/périmètres/chemins), `LEDGER.md` (décisions architecturales et coordination) et `HISTORY.md` (opérations significatives de coordination, selon §4). `PROJECTS.md` MUST recenser **tous** les membres avec nom distinct, chemin non ambigu, périmètre, responsabilités et dépendances connues.

Le README de l'Application MUST diriger vers `APPLICATION`, `RULES`, les décisions pertinentes de son `LEDGER`, `STATUS`, puis le projet. Le README de chaque projet membre MUST commencer en demandant de lire le README de l'Application avant le bootstrap local ; son `RULES` MUST commencer en demandant de lire et appliquer le `RULES` global, sans le recopier, et ne garder que règles locales ou précisions/exceptions explicitement référencées. Chaque `SPEC` membre MUST commencer en demandant de lire le README de l'Application et celui du projet. Le `STATUS` d'Application est une vue de coordination des projets/dépendances avec date ou origine de mise à jour ; le `STATUS` du projet seul fait autorité pour ses lots. L'Application ne possède pas de lots : gate, convergence ou livraison transversale MUST être gouvernée par un projet d'intégration membre avec ses propres artefacts/gates.

Deux projets membres MAY exécuter leurs lots simultanément **seulement** si une autorité architecturale identifiée garantit leur progression sans risque incompatible et consigne **avant** le parallélisme une décision dans le `LEDGER` de l'Application : le **contrat de parallélisme**. Il MUST identifier, pour chaque projet concerné, périmètre/responsabilités, dépendances/interfaces, ressources/fichiers/zones de produit partagés, propriétaire de chaque zone modifiable, justification de l'indépendance, coordination et résolution des conflits si écriture partagée. Chaque projet garde ses lots, identifiants, `STATUS`, décisions et créneau ; l'unicité des identifiants est locale au projet, donc les références interprojets SHOULD nommer source et cible. Un lot actif/bloqué/prêt à fermer dans un projet n'occupe pas le créneau d'un autre et son blocage ne bloque pas automatiquement les autres. Dépendances, décisions et ressources communes MUST être explicites dans le contrat et référencées dans les projets concernés ; documents d'Application ne font pas autorité sur état/décision propres à un projet. Éviter SHOULD les modifications simultanées des mêmes fichiers de produit ; si indispensables, définir et appliquer **avant** travaux parallèles un mécanisme de coordination des écritures et de résolution de conflits (outil libre, Git facultatif). Aucun parallélisme effectif ni outil n'est imposé.

## 12. Vérification de conformité et limites

Un projet conforme respecte **toutes** les obligations applicables ci-dessus, notamment : six artefacts globaux requis dont `HISTORY.md` même pour un très petit projet, les quatre types de lot (convergence pour tout lot fermé), bootstrap et référence exécutable locale/versionnée liée directement dans README, transmission autonome et reprise documentée, identifiants uniques, conservation des obsolètes, décisions durables au ledger, opérations significatives ajoutées à `HISTORY` selon §4, validations humaines datées/nominatives, résultats évalués/acceptés identifiables, gates actives seules comptées avec `N/A` décidé, examen de chaque exigence active et traitement terminal de chaque finding, portée/effets des règles, fermeture humaine, transitions/séquentialité, réconciliation des interruptions, indépendance des outils. Une Application permettant le parallélisme exige ses artefacts, inventaire exhaustif et contrat approuvé ; son statut global doit rester une vue de coordination cohérente avec les statuts autoritaires des projets. Cette synthèse ne remplace aucune clause précédente.

Hors périmètre de 3.2 : parallélisme de lots dans un projet, gestion des droits/autorités humaines, authentification, signature cryptographique, VCS, fournisseur LLM, interface graphique et format propriétaire. Règle d'exécution : lire avant d'agir, définir intention/gates, exécuter un lot à la fois par projet, conserver findings et changements de sens, valider chaque gate sur un résultat identifiable, comparer intention/résultat, faire décider l'humain, capitaliser, documenter reprise, réconcilier toute interruption et ne rien détruire silencieusement.