# S.A.W. 3.2 — SDD Another Way

## Spécification normative du protocole

## 1. Statut du document

Ce document définit le protocole documentaire de **S.A.W. — SDD Another Way**, version 3.2.

Révision normative : `3.2.0-2026-09-27`.

S.A.W. 3.2 remplace S.A.W. 3.1. Elle définit le protocole sans dépendre d'un utilitaire, d'un agent, d'un IDE ou d'un système de gestion de versions.
Il a été prouvé par la mise en application de SAW sur plusieurs projets que le LLM servant à coder pouvait fort bien suivre et s'occuper de la "bureacratie" sans avoir besoin d'un utilitaire séparé. En dehors de cette utilisation rationnelle et cohérente de la méthode, cette dernière peut être entièrement suivie "manuellement", elle a été conçue pour cela. Mais puisque l'IA est déjà présente pour produire le code, l'utiliser pour le suivi des documents de la méthode semble naturel et logique.

Il décrit :

- les artefacts obligatoires ;
- leur contenu ;
- leurs règles de mutation ;
- le cycle de vie d'un lot ;
- les validations ;
- la fermeture ;
- la capitalisation ;
- le regroupement structuré de projets dans une Application.

Le protocole manuel constitue la référence.

Un projet S.A.W. MUST rester utilisable sans agent particulier, sans IDE et sans système de gestion de versions imposé.

La présente version n'autorise pas l'exécution parallèle de plusieurs lots dans un même projet. Des projets distincts d'une même Application MAY être exécutés simultanément selon la section 20 bis, lorsque leur contrat de parallélisme est explicite.

## 2. Vocabulaire normatif

Les mots suivants ont une signification normative stable, quelle que soit la langue du document :

| Mot | Signification |
|---|---|
| `MUST` | Obligation absolue. |
| `MUST NOT` | Interdiction absolue. |
| `SHOULD` | Recommandation forte. Tout écart SHOULD être justifié. |
| `SHOULD NOT` | Pratique fortement déconseillée. Tout écart SHOULD être justifié. |
| `MAY` | Possibilité facultative. |

## 3. Objet de S.A.W.

S.A.W. est une méthode de délégation et de continuité fondée sur un protocole documentaire léger.

Un « projet S.A.W. » est une unité de pilotage documentaire. Il MAY représenter une application entière, une sous-fonction ou un autre périmètre de travail identifiable ; il ne suppose ni un projet distinct au sens organisationnel habituel, ni un dépôt de code séparé. Chaque unité conserve néanmoins sa propre racine documentaire et ses artefacts de projet.

La taille de l'équipe ou du projet n'est pas un critère d'applicabilité de S.A.W.

S.A.W. se distingue par l'absence de dépendance matérielle ou logicielle propre à la méthode.

Il n'impose notamment :

- aucun matériel spécifique ;
- aucun script ;
- aucun preset ;
- aucun environnement Python ;
- aucun IDE ;
- aucun système de gestion de versions ;
- aucun agent ou fournisseur de LLM.

Un système capable de conserver et de modifier des fichiers Markdown suffit à appliquer la méthode manuellement.

L'humain reste au centre des décisions.

Aucune décision n'est automatique.

Une vérification déterministe ou une opération documentaire MAY être automatisée.

Cette automatisation MUST NOT se substituer à une décision humaine exigée par le protocole.

Il permet de conserver explicitement :

- l'intention ;
- le périmètre ;
- les règles ;
- les décisions ;
- l'état du travail ;
- les connaissances acquises ;
- les validations ;
- les écarts entre intention et résultat.

Les artefacts Markdown constituent le protocole.

Le protocole est directement applicable avec des fichiers Markdown.

## 4. Principes

### 4.1 Transparence

Toute règle gouvernant le travail MUST être lisible dans les artefacts.

Un comportement indispensable MUST NOT résider uniquement dans :

- un programme ;
- un plugin ;
- un prompt caché ;
- un runtime externe ;
- une conversation antérieure.

### 4.2 Indépendance

S.A.W. MUST NOT imposer :

- Git ;
- un autre système de gestion de versions ;
- un IDE ;
- un agent ;
- un fournisseur de LLM ;
- un système de branches.

### 4.3 Source de vérité

Les fichiers Markdown sont la source de vérité.

Une représentation propriétaire MUST NOT faire autorité à leur place.

### 4.4 Séparation des responsabilités

Chaque artefact répond à une question distincte.

Une information SHOULD rester dans l'artefact auquel elle appartient.

Les autres artefacts SHOULD la référencer sans la recopier.

### 4.5 Répartition des traitements

```text
opération déterministe   → programme ou commande
compréhension sémantique → LLM
intention durable        → Markdown
validation métier        → humain
```

### 4.6 Proportionnalité

Une automatisation SHOULD retirer davantage de complexité qu'elle n'en introduit.

## 5. Artefacts

S.A.W. définit dix artefacts requis.

### 5.1 Artefacts globaux

| Artefact | Question |
|---|---|
| `README.md` | Comment travailler dans ce projet ? |
| `PROJECT.md` | Qu'est-ce que le projet et pourquoi existe-t-il ? |
| `RULES.md` | Quelles règles actives gouvernent le projet ? |
| `STATUS.md` | Quel est l'état courant des lots ? |
| `LEDGER.md` | Quelles décisions durables ont été prises et pourquoi ? |
| `HISTORY.md` | Quelles opérations significatives ont été effectuées, par qui et quand ? |

Les six artefacts globaux sont requis, y compris `HISTORY.md`, sans exception liée à la taille du projet. La forme du journal SHOULD être indiquée dans `README.md` pour que les exécutants sachent comment consigner les opérations.

### 5.2 Artefacts d'un lot

| Artefact | Question |
|---|---|
| `SPEC-xxx.md` | Que doit accomplir le lot ? |
| `FINDINGS-xxx.md` | Qu'a-t-on appris pendant le lot ? |
| `GATES-xxx.md` | À quelles conditions le lot peut-il être fermé ? |
| `CONVERGENCE-xxx.md` | Qu'a-t-on obtenu et pourquoi le lot est-il fermé ? |

## 6. Organisation disque

### 6.1 Lot principal

```text
/
├── README.md
├── PROJECT.md
├── RULES.md
├── STATUS.md
├── LEDGER.md
├── HISTORY.md
├── SAW-3.2-SPECIFICATION.md
└── Specs/
    └── 001-export-pdf/
        ├── SPEC-001.md
        ├── FINDINGS-001.md
        ├── GATES-001.md
        └── CONVERGENCE-001.md
```

`CONVERGENCE-001.md` MAY être absent avant la préparation de la fermeture.

`HISTORY.md` MUST être présent à la racine du projet selon la section 14 bis.

Le fichier de la spécification exécutable de la version de S.A.W. appliquée MUST être copié à la racine du projet. Son nom de fichier, sa version et sa révision MUST permettre de l'identifier sans ambiguïté. Ce fichier est une référence normative distribuée avec le projet ; il ne constitue pas un artefact de projet supplémentaire.

### 6.2 Sous-lot

```text
Specs/
└── 001-export-pdf/
    └── 001-002-pdf-a/
        ├── SPEC-001-002.md
        ├── FINDINGS-001-002.md
        ├── GATES-001-002.md
        └── CONVERGENCE-001-002.md
```

Le lot parent conserve son identifiant.

`LOT-001` MUST NOT devenir `LOT-001-000` après sa création.

### 6.3 Noms

Les noms de fichiers normatifs sont en anglais.

Les noms de dossiers utilisent :

```text
<identifiant-numérique>-<nom-court>
```

Le nom court SHOULD être :

- descriptif ;
- stable ;
- écrit en minuscules ;
- séparé par des tirets ;
- indépendant de l'état du lot actif.

## 7. Identifiants

### 7.1 Règles générales

Tout identifiant MUST être unique dans le projet.

Tout identifiant MUST être immuable.

Un identifiant retiré, annulé ou rendu obsolète MUST NOT être réutilisé.

L'identifiant fait autorité.

Un lien Markdown est facultatif.

### 7.2 Formes canoniques

| Élément | Forme | Exemple |
|---|---|---|
| Lot | `LOT-nnn` | `LOT-001` |
| Sous-lot | `LOT-nnn-nnn` | `LOT-001-002` |
| Exigence | `REQ-<lot>-nnn` | `REQ-001-003` |
| Exigence de sous-lot | `REQ-<lot>-<sous-lot>-nnn` | `REQ-001-002-003` |
| Finding | `F-<lot>-nnn` | `F-001-010` |
| Finding de sous-lot | `F-<lot>-<sous-lot>-nnn` | `F-001-002-010` |
| Gate | `G-<lot>-nnn` | `G-001-004` |
| Gate de sous-lot | `G-<lot>-<sous-lot>-nnn` | `G-001-002-004` |
| Décision | `D-nnn` | `D-023` |
| Règle | `R-nnn` | `R-012` |
| Événement d'historique | `EVT-nnnnnn` | `EVT-000042` |

Les segments numériques utilisent trois chiffres complétés par des zéros, sauf `EVT`, qui en utilise six.

`EVT` est utilisé seulement si le projet choisit le format détaillé de `HISTORY.md`.

### 7.3 Références d'archives

Une incarnation archivée utilise une référence de la forme :

```text
LOT-001-OBSOLETE-001
```

Cette référence n'est pas un nouvel identifiant logique de lot.

L'identifiant logique reste `LOT-001`.

Le suffixe distingue les incarnations conservées du même lot logique.

Une référence d'archive attribuée MUST être unique et MUST NOT être réutilisée.

### 7.4 Références

Référence minimale :

```markdown
Source: F-001-010
```

Référence avec lien facultatif :

```markdown
Source: [F-001-010](../Specs/001-export-pdf/FINDINGS-001.md#f-001-010)
```

Un lien cassé ne rend pas l'identifiant invalide.

## 8. Dates et personnes

### 8.1 Format par défaut

Le format par défaut est :

```text
YYYY-MM-DDTHH:mm:ss
```

Exemple :

```text
2026-09-24T15:10:00
```

### 8.2 Projet international

Un projet international SHOULD imposer un décalage UTC :

```text
YYYY-MM-DDTHH:mm:ss±HH:mm
```

Exemple :

```text
2026-09-24T15:10:00+02:00
```

Le choix du format MUST être inscrit dans `RULES.md` lorsqu'il diffère du format par défaut.

### 8.3 Identité humaine

Une validation humaine exige un nom libre.

S.A.W. n'impose ni adresse électronique, ni compte, ni signature cryptographique.

Plusieurs personnes MAY être indiquées.

S.A.W. ne détermine pas si une personne possède l'autorité requise.

## 9. Obsolescence et remplacement

### 9.1 Marquage

Un élément qui cesse d'être actif MUST rester présent.

Son titre MUST commencer par :

```text
[OBSOLETE]
```

Une date MAY être ajoutée :

```text
[OBSOLETE 2026-09-24]
```

Un élément remplacé MUST contenir :

```text
Replaced by: <identifiant>
```

Le remplaçant MUST contenir :

```text
Replaces: <identifiant>
```

La forme normative est `Replaced by`.

### 9.2 Conservation

Le contenu d'un élément marqué `[OBSOLETE]` MUST être conservé.

Il MUST NOT être réécrit après son obsolescence.

Une correction typographique MAY être effectuée si elle ne change pas le sens.

### 9.3 Remplacement complet d'un document de lot

Le document actif conserve le nom canonique :

```text
SPEC-001.md
```

La première version entièrement remplacée devient :

```text
SPEC-001-OBSOLETE-001.md
```

Les remplacements suivants utilisent :

```text
SPEC-001-OBSOLETE-002.md
SPEC-001-OBSOLETE-003.md
```

Le suffixe `OBSOLETE-nnn` identifie une archive documentaire.

Il ne crée pas un nouveau lot logique.

Un objectif réellement différent MUST recevoir un nouvel identifiant de lot.

### 9.4 Remplacement complet d'un lot

Une incarnation obsolète MAY être conservée dans un dossier suffixé :

```text
001-export-pdf-OBSOLETE-001/
```

Ses fichiers SHOULD utiliser le même suffixe.

Le remplacement actif reprend le chemin canonique du même lot logique.

`STATUS.md` MUST contenir une ligne pour l'incarnation obsolète et une ligne pour l'incarnation active.

## 10. `README.md`

### 10.1 Responsabilité

`README.md` définit le protocole de travail du projet.

Il MUST rester le point d'entrée universel.

Il MUST NOT contenir :

- la définition détaillée du produit ;
- les règles techniques détaillées ;
- l'état détaillé des lots ;
- l'historique des décisions.

### 10.2 Sections minimales

```markdown
# S.A.W. project protocol

## 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
```

### 10.3 Bootstrap obligatoire

Pour travailler sur un lot, l'ordre de lecture est :

```text
1. README.md
2. PROJECT.md
3. RULES.md
4. Toutes les décisions actives de LEDGER.md
5. Les décisions obsolètes explicitement référencées
6. STATUS.md
7. SPEC-xxx.md
8. FINDINGS-xxx.md
9. GATES-xxx.md
10. CONVERGENCE-xxx.md, si ce fichier existe
```

La lecture de toutes les décisions actives est obligatoire.

Le ledger ne contient que des décisions durables. Cette lecture évite qu'une décision applicable soit écartée par une détection de pertinence imparfaite.

Une décision obsolète non référencée MAY ne pas être lue intégralement.

`HISTORY.md` ne fait pas partie du bootstrap habituel. Il SHOULD être consulté lorsque la chronologie d'une opération aide à une reprise, une réconciliation ou un audit.

### 10.4 Renvoi depuis un lot

Les artefacts d'un lot MUST commencer par un renvoi court vers le `README.md` racine.

Exemple :

```markdown
> Before working on this lot, read the repository root README.md.
```

Les instructions du bootstrap MUST NOT être recopiées dans les fichiers du lot.

### 10.5 Autonomie documentaire

Depuis `README.md`, un exécutant MUST pouvoir retrouver toutes les règles nécessaires à l'application du protocole dans le projet, sans conversation antérieure ni convention locale non écrite.

La section `Protocol reference` MUST identifier la version et la révision de S.A.W. appliquées. Elle MUST indiquer que le projet suit la méthode S.A.W. décrite dans le fichier de spécification exécutable copié à la racine du projet, et contenir un lien Markdown direct vers ce fichier. Une référence à une version courante non identifiée ne suffit pas.

Une transmission annoncée comme autonome MUST inclure ce fichier de spécification exécutable et les documents nécessaires au bootstrap. La référence normative est donc toujours disponible localement à la racine du projet ; elle ne constitue pas un onzième type d'artefact de projet.

Exemple :

```markdown
## Protocol reference

This project follows S.A.W. 3.2, as described in [SAW-3.2-SPECIFICATION.md](SAW-3.2-SPECIFICATION.md).

Revision: `3.2.0-2026-09-27`
```

Les procédures applicables MUST être consultées avant leur exécution. Il n'est pas nécessaire de recopier toute la méthode dans chaque artefact.

L'autonomie documentaire suppose les compétences nécessaires au travail demandé. Elle MUST NOT supposer la connaissance de décisions ou de procédures propres au projet qui ne seraient pas écrites.

## 11. `PROJECT.md`

### 11.1 Responsabilité

`PROJECT.md` définit ce qui est construit et pourquoi.

Lorsque le projet S.A.W. correspond à une sous-fonction d'une Application, ce fichier en définit le périmètre propre et sa contribution à l'ensemble.

Il est très stable.

### 11.2 Sections minimales

```markdown
# Project

## Purpose
## Problem
## Users and actors
## Scope
## Out of scope
## Stable functional characteristics
## Glossary
```

### 11.3 Contenu exclu

`PROJECT.md` MUST NOT contenir :

- l'état des lots ;
- les tâches courantes ;
- les choix techniques détaillés ;
- l'historique des décisions.

### 11.4 Identifiants

Les éléments de `PROJECT.md` ne reçoivent pas d'identifiant par défaut.

Un identifiant MAY être ajouté si une référence stable est nécessaire.

## 12. `RULES.md`

### 12.1 Responsabilité

`RULES.md` contient les contraintes actives du projet.

Il peut notamment définir :

- les plateformes ;
- les langages ;
- les runtimes ;
- l'architecture ;
- les bibliothèques imposées ou interdites ;
- la sécurité ;
- les tests ;
- les conventions ;
- le format des dates.

### 12.2 Forme d'une règle initiale

Une règle présente dès la création du projet ne nécessite pas de décision du ledger.

```markdown
## R-001 — Rule title

Status: ACTIVE
Source: Initial project rule

Rule:
The project MUST ...

Rationale:
...

Replaces: None
Replaced by: None
```

`Rationale` est facultatif.

### 12.3 Évolution d'une règle

Toute règle ajoutée ou modifiée après l'initialisation MUST référencer une décision du ledger.

Ancienne règle :

```markdown
## [OBSOLETE 2026-09-24] R-001 — Rule title

Status: OBSOLETE
Replaced by: R-008
Decision: D-023

Rule:
The project MUST ...
```

Nouvelle règle :

```markdown
## R-008 — New rule title

Status: ACTIVE
Source: D-023
Replaces: R-001

Rule:
The project MUST ...
```

L'ancienne règle conserve son texte.

### 12.4 Circuit d'évolution

Une évolution issue d'un finding suit ce circuit :

```text
Finding
→ décision humaine
→ LEDGER.md
→ ancienne règle marquée [OBSOLETE], si nécessaire
→ nouvelle règle active
```

### 12.5 Portée d'une évolution

Toute évolution d'une règle MUST préciser son champ d'application dans la règle ou par référence à sa décision : travaux futurs, lot courant, résultats déjà fermés désignés, ou ensemble des résultats concernés.

La décision MUST consigner l'examen des lots potentiellement affectés et les suites retenues. L'absence d'action nécessaire MUST être indiquée explicitement lorsqu'elle est la conclusion de cet examen.

Pour un lot en cours, l'effet sur les validations acquises MUST être traité selon la section 17.10.

Une nouvelle règle MUST NOT rouvrir automatiquement un lot fermé. Si un résultat fermé devient incompatible avec une règle qui lui est applicable, la décision MUST identifier ce résultat et le traitement retenu. Une reprise éventuelle reste une décision humaine et suit les sections 18.6 et 19.3.

La convergence antérieure reste inchangée tant que le lot n'est pas repris. Elle atteste la fermeture dans son contexte d'origine, et non la conformité à toutes les règles futures.

## 13. `STATUS.md`

### 13.1 Responsabilité

`STATUS.md` donne l'état courant des lots.

Il ne constitue pas un historique détaillé.

Il ne suit pas les personnes ou les agents ayant travaillé sur les lots.

### 13.2 Forme minimale

```markdown
| Lot reference | Parent | Title | Status | Replaced by | Comment |
|---|---|---|---|---|---|
| LOT-001 | — | Export PDF | Closed | — | — |
| LOT-002-OBSOLETE-001 | — | Old import | Obsolete | LOT-004 | Replaced |
| LOT-003 | — | Mobile mode | Cancelled | — | No longer required |
```

`Lot reference` contient l'identifiant canonique ou la référence d'une incarnation archivée.

Un lot apparaît dans `STATUS.md` à partir de l'état `Planned`.

Un brouillon MAY rester absent.

Toutes les incarnations obsolètes reconnues MUST apparaître.

### 13.3 Autorité

`STATUS.md` est l'unique autorité sur l'état courant d'un lot.

L'état MUST NOT être recopié dans `SPEC`, `FINDINGS`, `GATES` ou `CONVERGENCE` comme état courant faisant autorité.

### 13.4 Informations de reprise

Avant de transmettre ou d'interrompre le travail sur un lot, les artefacts MUST permettre d'identifier :

- le résultat disponible et son emplacement, ou l'absence de résultat ;
- le travail restant connu ;
- les blocages éventuels et les conditions de leur levée ;
- la prochaine action ou décision nécessaire.

`STATUS.md` MUST fournir un résumé courant ou les références permettant de retrouver ces informations. Une section complémentaire par lot MAY être utilisée si la colonne `Comment` ne suffit pas.

Les connaissances à l'origine d'un blocage restent dans `FINDINGS`, les validations restantes dans `GATES`, et l'intention ainsi que les dépendances dans `SPEC`. Ces informations SHOULD être référencées plutôt que recopiées.

Ce minimum de reprise ne constitue pas un journal d'activité. Une phrase MAY suffire si elle fournit toutes les informations nécessaires. Il MUST être actualisé lorsque la situation décrite change.

## 14. `LEDGER.md`

### 14.1 Responsabilité

`LEDGER.md` conserve les décisions durables.

Il MUST NOT devenir :

- un journal de bord ;
- une liste de tous les problèmes ;
- une copie des findings ;
- une liste de toutes les commandes exécutées.

### 14.2 Forme d'une décision

```markdown
## D-023 — Decision title

Date: 2026-09-24T15:10:00
Decided by: Alice Martin
Source: F-001-010
Related: LOT-001, R-012

Decision:
...

Reason:
...

Consequences:
...

Replaces: None
Replaced by: None
```

Champs obligatoires :

- `Date` ;
- `Decided by` ;
- `Decision` ;
- `Reason`.

Champs facultatifs :

- `Source` ;
- `Related` ;
- `Consequences` ;
- `Replaces` ;
- `Replaced by`.

Une décision initiale MAY utiliser :

```text
Source: None
```

Plusieurs décideurs MAY être inscrits s'ils possèdent l'autorité nécessaire.

Le caractère facultatif d'un champ ne dispense pas de conserver les informations exigées par une autre section. En particulier, la portée et les conséquences d'une évolution de règle MUST être documentées conformément à la section 12.5.

### 14.3 Mutation

Une décision validée est immuable.

Une correction de fond produit une nouvelle décision.

L'ancienne décision devient `[OBSOLETE]` et référence la nouvelle.

Une correction typographique sans changement de sens MAY être effectuée.

## 14 bis. `HISTORY.md`

### 14 bis.1 Responsabilité et couverture

`HISTORY.md` est le journal chronologique des opérations significatives effectuées sur le projet documentaire. Il décrit les actes exécutés ; `LEDGER.md` conserve les décisions durables et leurs raisons, `STATUS.md` l'état courant, et les autres artefacts leur contenu propre. Une entrée d'historique ne remplace aucune de ces écritures.

`HISTORY.md` MUST exister à la racine du projet, au même titre que les autres artefacts globaux requis. Le format détaillé de la section 14 bis.2 reste facultatif.

L'exécutant MUST y consigner les opérations importantes qui modifient le projet documentaire : création et transitions d'un lot ; évolution d'une exigence, règle ou gate ; enregistrement d'une décision ou d'un finding ; validation ; convergence ; reprise ou réconciliation. Des opérations proches MAY être regroupées dans une même entrée intelligible. Les lectures, recherches et commandes sans effet documentaire MAY rester hors du journal. `HISTORY.md` ne constitue pas un journal exhaustif de développement mais un guide de lecture du cycle complet de conception. Les détails sont dans les autres journaux.

### 14 bis.2 Format détaillé

Chaque opération MAY être décrite par un événement identifié et des champs explicites, ce qui facilite le filtrage et le rapprochement avec les autres artefacts :

```markdown
## EVT-000042 — Requirement replaced

Date: 2026-09-24T16:42:18+02:00
Actor: Codex
Operation: Replace requirement
References: LOT-001, REQ-001-002, REQ-001-007
Documents: Specs/001-base64-cli/SPEC-001.md
Decision: D-003
Outcome: Applied

Summary:
REQ-001-002 was preserved as obsolete and replaced by REQ-001-007.
Reciprocal replacement references were added.
```

Dans ce format, `Date` suit la section 8 ; `Actor` nomme l'exécutant ; `References` identifie les objets concernés ; `Documents` donne leurs chemins relatifs à la racine du projet ; `Decision` renvoie à une décision du ledger, ou vaut `None` ; `Outcome` indique le résultat constaté, par exemple `Started`, `Applied`, `Interrupted` ou `Reconciled`. `Summary` MAY rester bref.

Les identifiants `EVT-nnnnnn` sont propres au format détaillé. S'ils sont utilisés, ils MUST être uniques et SHOULD être croissants ; une correction ou une réconciliation SHOULD référencer l'événement antérieur concerné.

### 14 bis.3 Écriture, correction et reprise

Le journal est tenu par ajout à la fin du fichier. Les entrées existantes MUST être conservées ; une correction SHOULD être faite par une nouvelle entrée précisant ce qui change. Une opération simple SHOULD être notée après son 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. Une tenue manuelle sommaire MAY ne consigner que le résultat vérifié.

Un événement `Started` sans résultat ultérieur signale une opération à vérifier. Pour toute reprise, l'exécutant MUST comparer les artefacts et appliquer la section 22.8 ; il MUST NOT déduire l'état réel du seul journal. S'il constate une écriture non consignée, il SHOULD ajouter une entrée de réconciliation sans inventer une date ou un acteur historique.

Le journal permet de reconstruire la chronologie des événements consignés, mais ne garantit ni la capture de chaque édition manuelle, ni la restitution exacte des anciennes versions de fichiers. Les archives, historiques de gates, convergences et éventuels mécanismes de versionnement conservent les contenus antérieurs selon leurs propres règles.

## 15. `SPEC-xxx.md`

### 15.1 Responsabilité

`SPEC` définit l'intention du lot.

Elle ne contient pas :

- les règles globales ;
- le journal de travail ;
- les findings ;
- les résultats des gates ;
- la conclusion de fermeture.

### 15.2 Sections minimales

```markdown
# LOT-001 — Lot title

> Before working on this lot, read the repository root README.md.

Parent: None
Created: 2026-09-24T10:00:00

## Objective
## Context
## In scope
## Out of scope
## Requirements
## Important cases
## Dependencies
## Known constraints
```

`Parent` et `Created` sont facultatifs.

`Status` MUST NOT apparaître comme état faisant autorité.

### 15.3 Exigence active

```markdown
### REQ-001-001 — Requirement title

The system MUST ...
```

### 15.4 Exigence remplacée

```markdown
### [OBSOLETE 2026-09-25] REQ-001-001 — Requirement title

Replaced by: REQ-001-006
Decision: D-031

The system MUST ...
```

Nouvelle exigence :

```markdown
### REQ-001-006 — New requirement title

Replaces: REQ-001-001
Decision: D-031

The system MUST ...
```

### 15.5 Mutation

Avant `In-progress`, la spec MAY être complétée sans décision du ledger.

Après `In-progress` :

- une correction sans changement de sens MAY être faite sans décision ;
- un ajout, un retrait ou un changement de sens MUST référencer une décision du ledger ;
- le contenu remplacé MUST rester visible ;
- l'identifiant remplacé MUST NOT être réutilisé.

## 16. `FINDINGS-xxx.md`

### 16.1 Responsabilité

`FINDINGS` conserve les connaissances acquises pendant le lot.

Un finding n'est pas automatiquement une décision.

### 16.2 Forme d'un finding

```markdown
# Findings — LOT-001

> Before working on this lot, read the repository root README.md.

## F-001-010 — Finding title

Status: OPEN
Found at: 2026-09-24T11:20:00

Finding:
...

Evidence:
...

Impact:
...

Destinations:
- Local
```

`Evidence` et `Impact` sont facultatifs.

L'auteur du finding n'est pas exigé.

### 16.3 États

États possibles :

```text
OPEN
RESOLVED LOCALLY
PROMOTED TO LEDGER
PROMOTED TO RULE
DEFERRED TO LOT
DISCARDED
```

Plusieurs états terminaux MAY être combinés lorsqu'un finding possède plusieurs destinations.

`OPEN` ne se combine pas avec un état terminal.

`DISCARDED` ne se combine pas avec une promotion.

Un finding `DISCARDED` MUST contenir une raison.

### 16.4 Destinations

Destinations possibles et cumulables :

```text
Local
Ledger: D-xxx
Rule: R-xxx
New lot: LOT-xxx
Discarded
```

La création d'un lot depuis un finding est une décision humaine.

Un finding `OPEN` n'interdit pas automatiquement `Ready-to-close`.

Il MUST être examiné avant la fermeture.

Sa destination finale MUST alors être renseignée.

### 16.5 Traitement requis à la fermeture

Un finding MUST NOT rester `OPEN` à la fermeture.

Chaque finding MUST posséder un ou plusieurs états terminaux cohérents avec ses destinations. Les décisions, règles et lots référencés MUST exister ; un lot destinataire MUST être au moins `Planned`.

Une résolution locale MUST expliquer suffisamment le traitement effectué pour permettre sa compréhension ultérieure. Un rejet MUST conserver sa raison.

Le traitement du finding MUST être achevé, mais le travail confié à un lot ultérieur MAY rester à réaliser. Ce report ne dispense pas d'accepter explicitement un éventuel écart aux exigences actives du lot fermé.

## 17. `GATES-xxx.md`

### 17.1 Responsabilité

`GATES` définit les conditions de fermeture.

Il ne décrit pas l'implémentation.

Il MUST NOT devenir une seconde spec.

### 17.2 Création

`GATES` est créé avec le lot.

Les gates MUST être définies avant le passage à `Planned`.

Après `In-progress`, tout ajout, retrait ou changement de sens d'une gate MUST référencer une décision du ledger.

### 17.3 Types

Types autorisés :

```text
AUTO
LLM
HUMAN
```

`AUTO` produit un verdict déterministe.

`LLM` produit une analyse sémantique.

`HUMAN` réserve le verdict à un humain.

Un agent ou un LLM MAY lancer une gate `AUTO`.

Le type reste `AUTO` si le verdict provient d'une commande déterministe.

Toute validation métier MUST être de type `HUMAN`, sauf décision humaine démontrant l'absence d'impact métier.

### 17.4 États

États autorisés :

```text
TO TEST
PASS
FAIL
N/A
```

Le passage à `N/A` exige :

- une décision humaine ;
- une entrée dans le ledger.

### 17.5 Gate AUTO

```markdown
## G-001-001 — Build succeeds

Type: AUTO
Status: TO TEST
Defined at: 2026-09-24T10:00:00

Condition:
The build completes successfully.

Method:
dotnet build -m:1

Tested at:
Evaluated result:
Result:
Evidence:
```

### 17.6 Gate LLM

```markdown
## G-001-002 — Rules consistency

Type: LLM
Status: TO TEST
Defined at: 2026-09-24T10:00:00

Condition:
No active requirement contradicts an active rule.

Evaluated at:
Evaluated result:
Evaluator:
Rationale:
```

Une gate LLM MUST conserver :

- une justification concise ;
- l'identification du modèle lorsqu'elle est disponible.

### 17.7 Gate HUMAN

```markdown
## G-001-003 — User journey validation

Type: HUMAN
Status: TO TEST
Defined at: 2026-09-24T10:00:00

Condition:
The user journey is accepted.

Validated at:
Validated by:
Evaluated result:
Comment:
```

Pour obtenir `PASS`, une gate HUMAN MUST contenir :

- un horodatage ;
- le nom de l'humain.

Le commentaire et les preuves sont facultatifs.

Un LLM MUST NOT déclarer une gate HUMAN satisfaite.

### 17.8 Historique des tests

Une gate `FAIL` MAY redevenir `TO TEST`, puis `PASS`.

Une gate `PASS` dont la validation n'est plus applicable MUST revenir à `TO TEST` selon la section 17.10.

Les tentatives antérieures MUST être conservées dans une section :

```markdown
### Test history
```

Avant toute réinitialisation ou nouvelle évaluation, le verdict précédent, sa date, l'identification du résultat évalué, les preuves ou justifications disponibles et l'identité du validateur lorsqu'elle est requise MUST être conservés dans cet historique. Cette obligation s'applique aussi aux tentatives réussies.

### 17.9 Gates actives, obsolètes et non applicables

Une gate active est une condition de fermeture qui n'a pas été retirée ou remplacée par obsolescence. Seules les gates actives participent au verdict courant.

| Situation | Effet sur la fermeture |
|---|---|
| Gate active `PASS`, validation encore applicable | Condition satisfaite. |
| Gate active `N/A`, avec décision humaine applicable | Condition déclarée non applicable. |
| Gate active `TO TEST` ou `FAIL` | Fermeture interdite. |
| Gate obsolète | Conservée pour l'histoire ; exclue du verdict courant. |

Le retrait ou le remplacement d'une gate MUST conserver sa définition et son historique, appliquer le marquage de la section 9 et, après démarrage, référencer la décision du ledger. Un remplacement MUST utiliser un nouvel identifiant et des références réciproques. Un retrait sans remplacement MUST en indiquer la raison.

Le marquage `[OBSOLETE]` est distinct du champ `Status` de la gate ; il ne constitue pas un cinquième verdict.

Une gate `N/A` reste active. Sa décision MUST préciser la raison et les conditions de non-applicabilité. Le retrait d'une gate et son passage à `N/A` MUST NOT être confondus.

### 17.10 Validité après modification

Toute modification du résultat, d'une exigence, d'une règle applicable ou d'une condition de validation susceptible d'affecter une validation acquise MUST entraîner un examen de son impact.

Cet examen MUST être consigné brièvement dans `GATES`, directement ou par référence à une décision documentant cet impact. Les gates affectées MUST revenir à `TO TEST` après conservation de leurs résultats antérieurs. Si l'impact ne peut pas être déterminé, toutes les gates actives autres que les gates `N/A` dont la décision reste applicable MUST être réévaluées.

Le maintien d'un `PASS` à la suite d'une modification examinée MUST être justifié. Une validation HUMAN affectée MUST être obtenue à nouveau auprès d'un humain ; une justification technique ne peut pas s'y substituer.

L'applicabilité des décisions `N/A` MUST également être réexaminée. Si leurs conditions ne sont plus remplies, les gates concernées MUST revenir à `TO TEST`. Un nouveau passage à `N/A` exige une nouvelle décision humaine inscrite dans le ledger.

Si ces opérations rendent une gate active `TO TEST` ou `FAIL` alors que le lot est `Ready-to-close`, le lot MUST revenir à `In-progress` avant de poursuivre le travail.

### 17.11 Identification du résultat évalué

Chaque évaluation MUST identifier suffisamment le résultat examiné pour déterminer sur quoi porte le verdict et si celui-ci reste applicable au résultat présenté à la fermeture.

Cette identification MUST être conservée dans `GATES`, directement ou par référence. Le champ `Evaluated result` MAY désigner une version de document, une livraison nommée, une copie conservée ou une révision lorsque le projet utilise un système de gestion de versions. Plusieurs gates portant sur le même résultat MAY référencer une identification commune.

Un chemin désignant un contenu susceptible de changer ne suffit pas à lui seul à distinguer des résultats successifs.

Cette obligation n'impose ni Git, ni empreinte cryptographique, ni archivage complet à chaque essai. Le projet choisit un moyen proportionné permettant de distinguer les résultats effectivement évalués.

## 18. `CONVERGENCE-xxx.md`

### 18.1 Responsabilité

`CONVERGENCE` certifie la fermeture d'un lot.

Il compare :

- les exigences actives de la spec ;
- le résultat réel ;
- les évolutions d'intention visibles dans la spec ;
- les éléments essentiels des findings ;
- les résultats essentiels des gates.

Il ne recopie ni la spec, ni les findings, ni les gates.

Pour chaque exigence active, la convergence MUST permettre d'établir qu'elle est satisfaite ou qu'un écart précisément identifié a été accepté par une décision humaine référencée.

Des identifiants regroupés avec une conclusion commune MAY suffire. Une matrice exhaustive et la duplication du texte des exigences ne sont pas exigées. Une exigence active MUST NOT être omise de cet examen.

La section `Result obtained` MUST identifier le résultat finalement accepté et permettre de le rapprocher des résultats évalués dans `GATES` selon la section 17.11.

### 18.2 Sections minimales

```markdown
# Convergence — LOT-001

> Before working on this lot, read the repository root README.md.

Closed at: 2026-09-24T16:00:00
Closed by: Alice Martin
Decision: None
Convergence: TOTAL

## Result obtained
## Differences from active requirements
## Essential gate results
## Findings disposition
## Residual work
## Closure decision
## Historical convergences
```

### 18.3 Niveaux

Valeurs autorisées :

```text
TOTAL
PARTIAL
```

`TOTAL` signifie que toutes les exigences actives sont satisfaites.

`PARTIAL` signifie qu'au moins un écart a été accepté par l'humain.

Une convergence partielle exige une entrée dans le ledger contenant :

- la décision ;
- la raison ;
- la date ;
- l'identité de l'humain.

Une divergence non acceptée interdit la fermeture.

L'acceptation d'un écart et une convergence `PARTIAL` MUST NOT neutraliser une gate active `FAIL` ou `TO TEST`. Les conditions de fermeture de la section 17.9 restent applicables.

### 18.4 Décision de fermeture

Une fermeture totale ordinaire ne nécessite pas d'entrée dans le ledger.

Les autres cas exigent une entrée dans le ledger.

Cela inclut :

- une convergence partielle ;
- une gate déclarée `N/A` ;
- un écart accepté pendant la fermeture ;
- toute décision exceptionnelle de fermeture.

### 18.5 Stabilité

Après fermeture, la convergence courante est stable.

Elle MUST NOT être modifiée tant que le lot n'est pas repris.

Si le lot devient `Obsolete` ou `Abandoned` sans reprise, sa convergence MUST être conservée sans modification.

### 18.6 Reprise

Lorsqu'un lot fermé, obsolète ou abandonné est repris avec modification :

1. toute convergence existante MUST être lue ;
2. la reprise MUST être décidée par un humain et inscrite dans le ledger, après vérification des préconditions de la section 19.3 ;
3. si une fermeture antérieure existe, les sections de sa fermeture courante MUST être copiées sans perte dans une nouvelle entrée de `Historical convergences`, puis les sections courantes MUST être réinitialisées ;
4. les résultats antérieurs des gates MUST être conservés dans `Test history` ;
5. toutes les gates actives applicables MUST revenir à `TO TEST`, et les décisions `N/A` MUST être réexaminées selon la section 17.10 ;
6. le lot revient à `In-progress` dans `STATUS` après ces préparations ;
7. toutes les validations applicables MUST être obtenues à nouveau avant une nouvelle fermeture.

Un lot devenu `Obsolete` avant toute fermeture MAY ne pas posséder de convergence. Dans ce cas, une convergence historique MUST NOT être inventée. Un éventuel brouillon de convergence MUST être identifié comme tel et conservé avant sa réinitialisation ; il ne constitue pas une fermeture antérieure.

Chaque entrée historique MUST conserver au minimum :

- l'ancien niveau de convergence ;
- l'ancienne date de fermeture ;
- l'ancien responsable de fermeture ;
- l'ancien résultat ;
- les anciens écarts ;
- l'ancienne décision de fermeture.

Les entrées déjà présentes dans `Historical convergences` MUST rester inchangées.

### 18.7 Réactivation sans modification

Un lot `Abandoned` MAY redevenir valide sans nouvelle validation si :

- aucune modification n'est apportée au résultat ;
- aucune règle active nouvelle ne l'invalide ;
- un humain décide explicitement la réactivation ;
- le ledger contient la motivation, l'identité et la date.

Dans ce cas :

- la convergence n'est pas réinitialisée ;
- le lot redevient `Closed` ;
- les gates ne sont pas rejouées.

## 19. États d'un lot

### 19.1 États autorisés

```text
Draft
Planned
In-progress
Blocked
Stand-by
Ready-to-close
Closed
Cancelled
Obsolete
Abandoned
```

### 19.2 Signification

| État | Signification |
|---|---|
| `Draft` | Fichiers en préparation. Le lot n'est pas encore reconnu comme planifié. |
| `Planned` | Spec et gates définies. Le lot peut être commencé. |
| `In-progress` | Lot actuellement exécuté. |
| `Blocked` | Exécution impossible tant que le blocage n'est pas traité. |
| `Stand-by` | Lot parent suspendu pendant l'exécution d'un sous-lot. |
| `Ready-to-close` | Travail terminé, gates actives `PASS` encore valables ou `N/A` autorisées. Fermeture humaine en attente. |
| `Closed` | Lot fermé après convergence et décision humaine. |
| `Cancelled` | Lot arrêté avant fermeture et non remplacé. |
| `Obsolete` | Lot remplacé, fermé ou non. |
| `Abandoned` | Résultat précédemment fermé, ensuite abandonné sans remplacement. |

### 19.3 Table normative des transitions

Cette table définit les transitions autorisées. Toute transition absente de la table MUST NOT être effectuée. Les procédures détaillées référencées complètent ses préconditions et effets ; les scénarios de la section 26 les illustrent.

Toute transition MUST respecter la séquentialité de la section 20. L'entrée dans un état occupant le créneau actif exige que ce créneau soit libre ou déjà occupé par le même lot, sauf transfert coordonné du parent à son sous-lot.

`Ledger non requis` signifie que la transition seule n'exige pas de décision durable ; les autres décisions éventuellement nécessaires restent soumises au protocole.

| Départ | Arrivée | Préconditions | Décision humaine et ledger | Effets documentaires obligatoires |
|---|---|---|---|---|
| `Draft` | `Planned` | Identifiant attribué, spec et gates définies ; section 21.2. | Ledger non requis. | Inscrire le lot dans `STATUS`. |
| `Planned` | `In-progress` | Bootstrap effectué ; créneau disponible ou transfert parent/sous-lot conforme à la section 20.3. | Démarrage décidé par un humain ; ledger non requis. | Mettre à jour `STATUS` et, pour un sous-lot, suspendre son parent. |
| `In-progress` | `Blocked` | Un blocage empêche l'exécution. | Ledger non requis pour constater le blocage. | Documenter le blocage, sa condition de levée et les informations de reprise ; mettre à jour `STATUS`. |
| `Blocked` | `In-progress` | Condition de levée satisfaite ; décisions nécessaires obtenues. | Ledger non requis pour cette transition seule. | Actualiser les informations de reprise, examiner l'impact sur les validations et mettre à jour `STATUS`. |
| `In-progress` | `Stand-by` | Démarrage d'un sous-lot identifié et autorisé par un humain. | Ledger non requis pour le transfert seul. | Conserver les informations de reprise du parent ; coordonner les deux états dans `STATUS` selon la section 20.3. |
| `Stand-by` | `In-progress` | Sous-lot ayant motivé la suspension `Closed`, `Cancelled` ou `Obsolete` ; créneau libre. | Retour décidé par un humain ; ledger non requis pour cette transition seule. | Examiner le résultat du sous-lot et son impact sur les validations du parent ; actualiser les informations de reprise et `STATUS`. |
| `In-progress` | `Ready-to-close` | Travail terminé ; toutes les gates actives `PASS` encore valables ou `N/A` autorisées. | Ledger non requis, hors décisions nécessaires aux gates. | Vérifier les résultats et décisions de gates ; mettre à jour `STATUS`. |
| `Ready-to-close` | `In-progress` | Correction demandée, fermeture refusée ou validation devenue invalide. | Décisions de correction selon leur nature ; ledger non requis pour le retour seul. | Consigner le motif dans les artefacts concernés, traiter les validations affectées et mettre à jour `STATUS`. |
| `Ready-to-close` | `Closed` | Procédure de fermeture achevée, aucune cause de refus. | Acceptation humaine ; ledger dans les cas de la section 18.4. | Finaliser `CONVERGENCE`, achever les mises à jour approuvées, puis mettre `STATUS` à jour. |
| `Draft`, `Planned`, `In-progress`, `Blocked`, `Stand-by`, `Ready-to-close` | `Cancelled` | Arrêt avant fermeture, sans remplacement, selon la section 19.6. Pour un parent suspendu, sort du sous-lot explicitement résolu. | Décision humaine inscrite dans le ledger. | Conserver les fichiers et inscrire l'état final dans `STATUS`, même pour un brouillon absent jusque-là. |
| `Draft`, `Planned`, `In-progress`, `Blocked`, `Stand-by`, `Ready-to-close`, `Closed` | `Obsolete` | Remplaçant identifié. Pour un parent suspendu, sort du sous-lot explicitement résolu. | Décision humaine inscrite dans le ledger. | Conserver les fichiers et toute convergence ; établir les références de remplacement et les lignes de `STATUS` selon la section 9. |
| `Closed` | `Abandoned` | Résultat non retenu, sans remplacement. | Décision humaine motivée inscrite dans le ledger. | Conserver la convergence inchangée ; mettre à jour `STATUS`. |
| `Closed`, `Obsolete`, `Abandoned` | `In-progress` | Reprise avec modification ; créneau disponible ou transfert parent/sous-lot autorisé. Pour `Obsolete`, sort du remplaçant explicitement résolu. | Décision humaine inscrite dans le ledger avant application. | Préparer la reprise selon la section 18.6, puis mettre à jour `STATUS`. |
| `Abandoned` | `Closed` | Résultat inchangé et aucune règle active applicable ne l'invalide ; section 18.7. | Décision humaine motivée, datée et nominative dans le ledger. | Conserver la convergence et les gates ; mettre à jour `STATUS` sans nouvelle validation. |

### 19.4 Application des transitions de travail

Une correction demandée pendant la fermeture MUST faire repasser le lot à `In-progress`. Si cette correction révèle un blocage, la transition `In-progress → Blocked` est ensuite appliquée.

Une opération interrompue entre plusieurs écritures MUST être traitée selon la section 22.8 ; elle n'autorise pas une transition supplémentaire.

### 19.5 Conditions des transitions exceptionnelles

Toute transition d'annulation, d'obsolescence, d'abandon, de reprise ou de réactivation exige une décision humaine inscrite dans le ledger.

L'annulation ou le remplacement depuis `Ready-to-close` est direct lorsque les préconditions de la table sont satisfaites ; un retour préalable à `In-progress` n'est pas nécessaire.

La reprise d'un lot `Obsolete` MUST résoudre explicitement le sort de son remplaçant et préserver les archives immuables. Il MUST rester une seule incarnation active du lot logique.

### 19.6 Annulation, obsolescence et abandon

`Cancelled` signifie :

- le lot n'a pas été fermé ;
- il ne sera pas réalisé ;
- il n'est pas remplacé.

`Obsolete` signifie :

- le lot est remplacé ;
- son remplaçant est indiqué ;
- la décision est dans le ledger.

`Abandoned` signifie :

- le lot a été fermé ;
- son résultat n'est plus retenu ;
- aucun lot ne le remplace ;
- la raison est dans le ledger.

Aucun fichier existant ne doit être détruit.

Un lot annulé ou obsolète avant fermeture MAY ne pas avoir de convergence.

Une convergence existante MUST être conservée.

## 20. Séquentialité

### 20.1 Règle générale et raison de la séquentialité

Dans chaque projet S.A.W., les lots sont exécutés les uns après les autres.

Cette séquentialité résulte du workflow documentaire : dans le flux nominal, un lot ne libère le passage vers le lot suivant qu'après sa fermeture. Cette fermeture impose l'examen des findings, l'évaluation de toutes les gates applicables, la convergence et l'acceptation humaine requise. La séquentialité protège ainsi la continuité de l'intention, des validations et de l'état connu avant de poursuivre.

Les sorties `Cancelled` et `Obsolete` peuvent également libérer le créneau selon les transitions autorisées, mais elles constituent des traitements exceptionnels documentés. Elles MUST NOT être employées pour contourner une gate ou simuler une fermeture nominale.

Un seul lot MAY occuper le créneau de travail actif de ce projet.

Les états occupant ce créneau sont :

```text
In-progress
Blocked
Ready-to-close
```

Il MUST donc exister au plus un lot de ce projet dans l'ensemble de ces trois états.

Un parent `Stand-by` constitue la seule suspension normale associée à ce créneau.

### 20.2 Blocage

Un lot `Blocked` bloque l'exécution de tous les autres lots du même projet.

Le processus reprend lorsque ce lot devient :

- `In-progress` ;
- `Cancelled` ;
- `Obsolete`.

### 20.3 Sous-lot

Le démarrage d'un sous-lot place son parent en `Stand-by`.

Avant ce transfert, le parent MUST être `In-progress` et le sous-lot MUST satisfaire les préconditions de son démarrage ou de sa reprise. Le parent suspendu et le sous-lot concerné MUST être identifiables dans `STATUS`.

Le sous-lot devient l'unique lot `In-progress`.

Le passage du parent à `Stand-by` MUST être écrit avant celui du sous-lot à `In-progress`. Une interruption entre ces écritures relève de la section 22.8.

Après fermeture, annulation ou obsolescence du sous-lot, le retour du parent à `In-progress` est manuel.

Ce retour MUST attendre que le créneau actif soit libre et MUST comprendre l'examen de l'effet du résultat du sous-lot sur le travail et les validations du parent.

### 20.4 Portée de la séquentialité

Le créneau actif, le blocage et les transitions des sections 19 et 20 sont propres à un projet. L'exécution simultanée de plusieurs lots d'un même projet reste hors périmètre de cette version.

## 20 bis. Application et parallélisme entre projets

### 20 bis.1 Définition et intention architecturale

Le terme anglais `Application` désigne un ensemble de projets S.A.W. qui contribuent à une même application. Ces projets MAY correspondre à une fonctionnalité, à un domaine entier tel que la saisie de factures ou les impressions, ou à une partie de fonctionnalité. Ils n'ont pas besoin d'être des projets organisationnels ni des bases de code distincts. Un projet MAY aussi rester autonome, sans appartenir à une Application documentée.

La simple présence d'un répertoire parent nommé Application ne rend pas le parallélisme valide. Lorsqu'une Application sert à organiser des projets exécutables en parallèle, elle MUST exprimer l'intention, les responsabilités et la cohérence de ce découpage dans ses propres artefacts Markdown.

Une Application structurée MUST être placée au-dessus des racines de ses projets et contenir :

- `README.md`, bootstrap de travail à l'échelle de l'Application ;
- `APPLICATION.md`, nature, finalité et périmètre de l'Application ;
- `RULES.md`, règles globales applicables aux projets membres ;
- `STATUS.md`, suivi global de réalisation des projets ;
- `PROJECTS.md`, inventaire, périmètres et chemins des projets membres ;
- `LEDGER.md`, décisions architecturales et de coordination durables ;
- `HISTORY.md`, journal des opérations significatives de coordination.

`PROJECTS.md` MUST recenser tous les projets membres de l'Application. Chaque nom de projet MUST être distinct dans cette liste et chaque chemin MUST permettre d'identifier sans ambiguïté la racine du projet correspondant. Chaque entrée MUST préciser son périmètre, ses responsabilités et ses dépendances connues.

Exemple d'organisation :

```text
my-application/
├── README.md
├── APPLICATION.md
├── RULES.md
├── STATUS.md
├── PROJECTS.md
├── LEDGER.md
├── HISTORY.md
├── api/
│   ├── README.md
│   ├── PROJECT.md
│   └── ...
└── client/
    ├── README.md
    ├── PROJECT.md
    └── ...
```

Dans cet exemple, `PROJECTS.md` pourrait contenir :

```markdown
| Project | Path | Scope |
|---|---|---|
| API | api/ | Application service and public interface |
| Client | client/ | User interface |
```

Le `README.md` de l'Application répond à la même question qu'un README de projet : comment travailler dans le périmètre concerné. Il MUST diriger vers `APPLICATION.md`, `RULES.md`, les décisions pertinentes de `LEDGER.md`, `STATUS.md`, puis vers le projet concerné. Le `README.md` de chaque projet membre MUST commencer par demander la lecture du `README.md` de l'Application avant son bootstrap local.

Le `RULES.md` de chaque projet membre MUST commencer par demander la lecture et l'application du `RULES.md` de l'Application. Il ne répète pas les règles globales ; il ne contient que les règles locales ou les précisions et exceptions explicitement référencées. Chaque `SPEC` d'un projet membre MUST commencer par demander la lecture du `README.md` de l'Application et du `README.md` de son projet.

Le `STATUS.md` de l'Application est une vue de coordination des projets et de leurs dépendances ; il MUST identifier sa date ou son origine de mise à jour. Il ne fait pas autorité sur l'état d'un lot : le `STATUS.md` de chaque projet reste seul autoritaire pour ses lots.

L'Application ne possède pas de lots. Une gate, une convergence ou un résultat de livraison réellement transversal MUST être gouverné par un projet d'intégration distinct, membre de l'Application, avec ses propres artefacts et gates.

### 20 bis.2 Contrat de parallélisme et exécution simultanée

Le découpage d'une Application en plusieurs projets S.A.W. permet d'exécuter simultanément des lots appartenant à des projets différents uniquement lorsqu'une autorité architecturale identifiée est en mesure de garantir que ces projets peuvent progresser sans risque incompatible. Cette garantie MUST être inscrite dans une décision du `LEDGER.md` de l'Application avant le démarrage parallèle.

Cette décision, appelée contrat de parallélisme, MUST identifier :

- les périmètres et responsabilités de chaque projet concerné ;
- leurs dépendances et interfaces ;
- les ressources, fichiers ou zones de produit partagés ;
- le propriétaire de chaque zone modifiable ;
- la justification de l'indépendance permettant l'exécution simultanée ;
- le mécanisme de coordination et de résolution de conflit lorsqu'une écriture partagée reste nécessaire.

Chacun possède ses propres lots, identifiants, `STATUS.md`, décisions et créneau actif. L'unicité des identifiants s'apprécie dans chaque projet ; une référence entre projets SHOULD donc préciser le nom du projet source et celui du projet cible.

La présence d'un lot `In-progress`, `Blocked` ou `Ready-to-close` dans un projet n'occupe pas le créneau d'un autre projet. Un blocage dans un projet ne bloque pas automatiquement les lots des autres projets. Dans chacun d'eux, la règle d'un seul lot actif des sections 19 et 20 continue de s'appliquer.

Les dépendances, décisions et ressources partagées qui touchent plusieurs projets MUST être rendues explicites dans le contrat de parallélisme et référencées par les artefacts des projets concernés. Les documents de l'Application ne font pas autorité sur l'état d'un lot ou sur une décision propre à un projet.

L'organisation SHOULD éviter que plusieurs projets modifient simultanément les mêmes fichiers de produit. Si ce partage est nécessaire, les organisateurs MUST définir et appliquer un mécanisme de coordination des écritures et de résolution des conflits avant de lancer ces travaux en parallèle. Ils peuvent, par exemple, utiliser Git, comparer les différences et fusionner les modifications, ou organiser les écritures dans le temps. Ce besoin résulte de leur découpage et de leurs ressources partagées ; le choix du mécanisme leur appartient. S.A.W. n'impose ni Git, ni autre outil de coordination, ni exécution simultanée effective.

## 21. Création d'un lot

### 21.1 Brouillon physique

La création physique MAY produire :

```text
SPEC-xxx.md
FINDINGS-xxx.md
GATES-xxx.md
```

`CONVERGENCE-xxx.md` n'est pas nécessaire à ce stade.

### 21.2 Lot reconnu

Le lot devient `Planned` lorsque :

- son identifiant est attribué ;
- sa spec est suffisamment définie ;
- ses gates sont définies ;
- il est inscrit dans `STATUS.md`.

Avant cela, il reste `Draft`.

### 21.3 Modification après démarrage

Après `In-progress` :

- une correction sans changement de sens ne nécessite pas de décision ;
- tout changement de sens de la spec ou des gates exige une décision du ledger ;
- les informations remplacées restent conservées.

## 22. Cycle de vie

### 22.1 Bootstrap

Le contexte est reconstruit selon l'ordre défini dans `README.md`.

Avant de poursuivre le travail, les incohérences susceptibles d'affecter l'intention, les validations ou l'état du lot MUST être résolues selon la section 22.8. Les informations de reprise définies à la section 13.4 MUST être consultées lorsqu'elles existent.

### 22.2 Intention

`SPEC` définit le résultat attendu.

`GATES` définit les conditions de fermeture.

### 22.3 Exécution

Le lot passe à `In-progress` par décision humaine.

Les connaissances nouvelles sont ajoutées à `FINDINGS`.

Les changements d'intention sont historisés dans `SPEC`.

L'effet des modifications sur les validations acquises MUST être examiné selon la section 17.10. Les informations nécessaires à une interruption ou une transmission MUST être conservées selon la section 13.4.

### 22.4 Validation

Chaque gate active applicable est évaluée selon son type et sur un résultat identifié.

Un lot ne peut devenir ou rester `Ready-to-close` que si toutes ses gates actives sont :

- `PASS` avec une validation encore applicable au résultat présenté ;
- ou `N/A` avec une décision humaine enregistrée dont les conditions restent remplies.

### 22.5 Convergence

La convergence compare l'intention active au résultat réel.

Elle indique `TOTAL` ou `PARTIAL`.

Elle établit le traitement de chaque exigence active, identifie le résultat accepté et résume les gates ainsi que la destination des findings conformément à la section 18.1.

### 22.6 Capitalisation

Avant fermeture :

- tous les findings sont examinés et possèdent un traitement terminal conforme à la section 16.5 ;
- les décisions durables sont inscrites dans le ledger ;
- les règles approuvées sont mises à jour ;
- les nouveaux lots décidés sont créés ou planifiés ;
- le travail résiduel est enregistré.

### 22.7 Fermeture

La fermeture est toujours décidée par un humain.

Après acceptation :

- `CONVERGENCE` est finalisé ;
- les mises à jour transversales approuvées sont écrites ;
- `STATUS` passe le lot à `Closed`.

Toute modification effectuée pendant la préparation de la fermeture MUST être soumise aux mêmes règles de validité des gates que pendant l'exécution. L'acceptation humaine MUST porter sur le résultat et les écarts effectivement présentés dans la convergence finalisée.

### 22.8 Opérations documentaires interrompues

Une décision enregistrée ne prouve pas, à elle seule, que toutes ses conséquences documentaires ont été appliquées.

Pour une opération comportant plusieurs écritures :

1. la décision humaine requise MUST être obtenue et, lorsque le protocole l'exige, inscrite dans le ledger avant son application ;
2. les contenus et résultats antérieurs à conserver MUST être préservés avant leur remplacement ou leur réinitialisation ;
3. les artefacts gouvernés, les références et les validations affectées MUST être mis à jour ;
4. leur cohérence MUST être vérifiée ;
5. le changement d'état constatant l'achèvement de l'opération MUST être écrit dans `STATUS` en dernier parmi les artefacts d'état et de contenu ; l'entrée de résultat dans `HISTORY.md` suit cette vérification.

Un état autorisant la reprise du travail, tel que `In-progress`, est enregistré après les préparations documentaires requises et avant les modifications du résultat. Les transferts parent/sous-lot suivent l'ordre particulier de la section 20.3.

Lorsqu'une opération a été interrompue, l'exécutant MUST comparer les écritures réalisées à la décision enregistrée et identifier celles qui restent à effectuer. Si la décision détermine sans ambiguïté la suite, l'opération MUST être achevée conformément à cette décision, sans en inventer une nouvelle ni redemander une acceptation déjà documentée.

Si une décision requise est absente, ambiguë ou incompatible avec les autres artefacts, une clarification humaine MUST être obtenue avant de poursuivre les opérations qui en dépendent. Une nouvelle décision durable MUST être inscrite dans le ledger lorsqu'elle est nécessaire. Lorsqu'aucune décision n'est requise, une écriture documentaire incomplète MAY être achevée à partir des faits conservés et des règles applicables, sans inventer d'information.

`STATUS` reste l'autorité sur l'état enregistré. Une incohérence avec une convergence ou une décision MUST NOT être résolue en effaçant une validation, une décision ou une fermeture antérieure. La réparation MUST préserver les traces existantes et respecter les transitions autorisées.

Cette procédure exige une réconciliation manuelle des informations, sans imposer de mécanisme transactionnel ni d'outil. Les événements correspondants SHOULD être consignés dans `HISTORY.md` selon la section 14 bis ; le journal ne remplace pas la comparaison des artefacts.

## 23. Procédure manuelle de fermeture

La procédure normative est :

```text
1. Lire les artefacts selon le bootstrap et résoudre les incohérences bloquantes.
2. Identifier le résultat présenté et les gates actives ; vérifier les retraits et remplacements.
3. Vérifier les verdicts des gates AUTO actives applicables.
4. Vérifier les évaluations des gates LLM actives applicables.
5. Vérifier les validations des gates HUMAN actives applicables.
6. Vérifier que les validations portent sur le résultat présenté et restent valables ; refaire celles qui sont nécessaires.
7. Refuser la fermeture si une gate active reste TO TEST ou FAIL.
8. Vérifier les décisions et les conditions de non-applicabilité des gates actives N/A.
9. Établir, pour chaque exigence active, sa satisfaction ou l'écart à faire accepter.
10. Examiner les exigences obsolètes et leurs remplacements.
11. Examiner chaque finding et préparer son traitement terminal ainsi que ses destinations.
12. Préparer CONVERGENCE et qualifier la convergence TOTAL ou PARTIAL.
13. Obtenir les décisions humaines requises et les inscrire dans le ledger.
14. Mettre à jour RULES avec la portée et les conséquences des évolutions approuvées.
15. Créer ou planifier les lots ultérieurs décidés par l'humain.
16. Achever le traitement des findings ; réexaminer l'effet des modifications sur les validations et les écarts, puis revenir aux contrôles concernés si nécessaire.
17. Vérifier l'absence de cause de refus et inscrire Ready-to-close si ce n'est pas déjà l'état courant.
18. Présenter à l'humain le résultat identifié, la convergence et les décisions associées pour acceptation de la fermeture.
19. Après acceptation, finaliser CONVERGENCE et achever les mises à jour approuvées ; vérifier leur cohérence.
20. Passer le lot à Closed dans STATUS en dernier.
```

L'humain MAY accepter un écart pendant la fermeture.

Cette décision MUST être inscrite dans le ledger.

Si l'écart exige une modification du résultat, un lot `Ready-to-close` MUST revenir à `In-progress` avant cette modification. Les gates affectées MUST être traitées selon la section 17.10.

L'humain conserve le dernier mot sur l'acceptation du résultat. Cette acceptation MUST NOT contourner les conditions normatives de fermeture.

## 24. Refus de fermeture

La fermeture MUST être refusée si :

- une gate active est `TO TEST` ou `FAIL` ;
- une gate HUMAN active applicable n'a pas de validation humaine identifiée et datée ;
- une gate active `N/A` ne possède pas sa décision ou les conditions de celle-ci ne sont plus remplies ;
- un retrait ou remplacement de gate ne respecte pas les règles de mutation ;
- une validation acquise n'est plus applicable au résultat présenté ;
- le résultat présenté ou son rapport aux résultats évalués ne peut pas être identifié ;
- une exigence active n'a pas été examinée ;
- un écart n'est ni corrigé ni accepté ;
- un finding reste `OPEN`, n'a pas été examiné ou ne possède pas un traitement terminal et des destinations conformes ;
- une décision obligatoire manque ;
- une incohérence documentaire affectant l'intention, les validations ou l'état du lot reste non résolue ;
- la convergence ne peut pas être établie.

Après refus, un lot `Ready-to-close` revient à `In-progress`. Un lot déjà `In-progress` y reste, ou devient `Blocked` si l'exécution est impossible ; un lot déjà `Blocked` le reste tant que la condition de levée n'est pas satisfaite. Ces opérations suivent la table de la section 19.3.

## 25. Rôle de l'humain

Les opérations suivantes sont réservées à l'humain :

- modifier significativement `PROJECT.md` ;
- approuver une évolution de `RULES.md` ;
- décider d'un changement de sens après le démarrage d'un lot ;
- valider une gate HUMAN ;
- déclarer une gate `N/A` ;
- accepter un écart ;
- accepter une convergence partielle ;
- créer un lot depuis un finding ;
- fermer un lot ;
- annuler, remplacer, abandonner ou reprendre un lot.

Une automatisation MAY préparer ces opérations.

Elle MUST demander la décision humaine avant de les rendre effectives.

## 26. Scénarios de référence

Ces scénarios illustrent la table normative de la section 19.3 et les procédures associées. Leur présentation abrégée ne dispense pas des contrôles de validité, de traçabilité et de cohérence exigés par le protocole.

### 26.1 Lot nominal

```text
1. Créer SPEC, FINDINGS et GATES.
2. Compléter SPEC et GATES.
3. Inscrire le lot Planned.
4. Passer le lot In-progress.
5. Exécuter le travail.
6. Consigner les findings.
7. Passer toutes les gates actives sur un résultat identifié.
8. Passer le lot Ready-to-close.
9. Préparer une convergence TOTAL.
10. Obtenir l'acceptation humaine.
11. Finaliser CONVERGENCE.
12. Passer le lot Closed.
```

Aucune entrée de fermeture dans le ledger n'est obligatoire.

### 26.2 Finding produisant une règle

```text
1. Créer F-001-010.
2. Confirmer le finding.
3. Obtenir une décision humaine D-023 précisant la portée de la règle et les lots affectés.
4. Marquer l'ancienne règle [OBSOLETE], si nécessaire.
5. Créer la nouvelle règle.
6. Référencer D-023 dans RULES.
7. Marquer le finding PROMOTED TO LEDGER et PROMOTED TO RULE.
8. Résumer cette destination dans CONVERGENCE.
9. Appliquer aux lots concernés les suites décidées, notamment la revalidation des gates affectées.
```

### 26.3 Fermeture partielle

```text
1. Toutes les gates actives sont PASS encore valables ou N/A autorisé.
2. Un écart subsiste.
3. L'humain accepte l'écart.
4. Le ledger reçoit la décision, la raison, la date et l'identité.
5. CONVERGENCE indique PARTIAL.
6. Le travail résiduel est décrit.
7. L'humain ferme le lot.
```

### 26.4 Sous-lot

```text
1. LOT-001 est In-progress.
2. L'humain crée LOT-001-002.
3. LOT-001 passe Stand-by.
4. LOT-001-002 devient l'unique lot In-progress.
5. LOT-001-002 est fermé, annulé ou rendu obsolète.
6. Après examen du résultat du sous-lot et de son impact sur les validations du parent, l'humain replace LOT-001 en In-progress si le créneau est libre.
```

### 26.5 Lot remplacé

```text
1. L'humain décide le remplacement.
2. Le ledger reçoit la décision.
3. Les fichiers existants et toute convergence sont conservés.
4. Les références réciproques de remplacement sont ajoutées.
5. Le remplacement actif utilise le chemin canonique approprié.
6. La cohérence des artefacts et des références est vérifiée.
7. STATUS inscrit l'ancien lot Obsolete et le nouvel état documentaire du remplacement.
```

### 26.6 Reprise d'un lot fermé

```text
1. Lire l'ancienne convergence.
2. Décider la reprise dans le ledger.
3. Déplacer la convergence précédente dans Historical convergences.
4. Réinitialiser la convergence courante.
5. Conserver les résultats des gates dans Test history, remettre les gates actives applicables à TO TEST et réexaminer les décisions N/A.
6. Passer le lot In-progress lorsque les préparations sont achevées et le créneau disponible.
7. Réaliser les modifications.
8. Refaire les validations.
9. Produire une nouvelle convergence.
10. Obtenir une nouvelle fermeture humaine.
```

### 26.7 Réactivation sans modification

```text
1. LOT-001 est Abandoned.
2. L'humain confirme qu'aucune modification n'est nécessaire.
3. Les règles actives sont vérifiées.
4. Le ledger reçoit la décision motivée, datée et signée nominalement.
5. La convergence existante reste inchangée.
6. LOT-001 redevient Closed.
```

## 27. Critères de conformité d'un projet

La conformité à S.A.W. 3.2 exige le respect de toutes les obligations normatives applicables.

La liste suivante constitue un contrôle synthétique et ne remplace pas ces obligations :

- les dix types d'artefacts requis sont définis ;
- les six artefacts globaux requis existent, y compris `HISTORY.md` ;
- chaque lot reconnu possède une spec, des findings et des gates ;
- chaque lot fermé possède une convergence ;
- le bootstrap est explicite ;
- le fichier de spécification exécutable de la méthode appliquée est copié à la racine du projet ;
- la section `Protocol reference` du `README.md` identifie la version et la révision du protocole, indique que le projet suit la méthode décrite dans ce fichier et y mène par un lien Markdown direct ;
- une transmission autonome contient les références et les informations nécessaires à la reprise ;
- les identifiants sont uniques ;
- les informations obsolètes sont conservées ;
- les décisions durables sont dans le ledger ;
- les opérations significatives sont consignées par ajout dans `HISTORY.md` selon le niveau de détail choisi ;
- les validations humaines sont identifiées et datées ;
- les résultats évalués et acceptés sont identifiables et les validations restent applicables ;
- seules les gates actives participent au verdict courant, avec des décisions `N/A` applicables lorsqu'elles sont utilisées ;
- chaque exigence active est examinée et chaque finding possède un traitement terminal à la fermeture ;
- la portée des évolutions de règles et leurs effets sur l'existant sont documentés ;
- aucun lot n'est fermé automatiquement ;
- les transitions autorisées et la séquentialité sont respectées dans chaque projet, y compris lorsqu'il appartient à une Application ;
- toute Application qui autorise le parallélisme possède ses artefacts requis, un inventaire exhaustif de ses projets et un contrat de parallélisme approuvé ;
- le statut global d'une Application est identifiable comme une vue de coordination et ne contredit pas les statuts autoritaires des projets ;
- les opérations documentaires interrompues sont réconciliées avant de poursuivre le travail qui en dépend ;
- le projet reste utilisable sans dépendance à un agent, à un IDE ou à un système de gestion de versions.

## 28. Hors périmètre de cette version

Cette version ne définit pas :

- l'exécution parallèle de lots au sein d'un même projet S.A.W. ;
- la gestion des droits et autorités humaines ;
- l'authentification ;
- la signature cryptographique ;
- un système de gestion de versions ;
- un fournisseur de LLM ;
- une interface graphique ;
- un format propriétaire.

## 29. Résumé du protocole

```text
Lire avant d'agir.
Définir l'intention et les gates.
Exécuter un seul lot à la fois par projet S.A.W.
Conserver les findings.
Historiser les changements de sens.
Valider selon la nature de chaque gate.
Identifier le résultat évalué et réexaminer les validations après modification.
Comparer l'intention au résultat.
Faire décider l'humain.
Capitaliser les décisions durables.
Tenir un historique proportionné aux moyens du projet.
Conserver les informations nécessaires à la reprise.
Réconcilier les écritures interrompues avant de poursuivre.
Ne rien détruire silencieusement.
```