Le principe LIVING / COLD

Le postulat

Tout artefact de projet a une température. Soit il est LIVING : mutable, en cours de négociation, encore discutable. Soit il est COLD : gelé par une décision consciente, plus discutable sans passer par un processus explicite.

Cette distinction est binaire (avec une nuance LIVING-GELÉ temporaire) mais elle est omniprésente : chaque Business Epic, chaque Feature, chaque Récit porte son badge de chaleur visible dans la CLI.

Les trois températures

Badge	Méta-état(s)	Signification
LIVING	IN_PROGRESS	L'objet est en construction active. Son contenu peut changer à chaque session. Aucun engagement n'a été pris.
LIVING-GELÉ	BLOCKED	L'objet est temporairement arrêté (attente de décision, dépendance externe). Son contenu reste mutable, mais aucune avancée ne se fait.
COLD	DONE, ARCHIVED	Une porte de décision a été franchie. Des artefacts ont été gelés à ce moment. Les rouvrir exige un processus explicite.

Pourquoi cette distinction est vitale

Sans elle, l'IA — et souvent l'humain pressé — confond trois régimes de travail :

1. Explorer : créer, générer, proposer. Tout est possible, rien ne compte.
2. Délibérer : peser, comparer, choisir. Certaines options tombent.
3. Graver : acter. Cette décision devient la fondation des suivantes.

Si tout est LIVING en permanence, aucune décision ne stabilise — on tourne en rond, chaque session redéfaire la précédente. C'est la pathologie « projet sans mémoire ».

Si tout est COLD d'emblée, chaque interrogation devient un drame, chaque pivot un aveu d'échec. C'est la pathologie « projet rigide ».

Le kit impose explicitement les trois régimes et leur séparation.

Comment la bascule se produit

Le passage LIVING → COLD se produit uniquement à une porte de décision (G1 à G4, ou Re-G1 dans la boucle MVP→G1), via node sdlc/sdlc.js move. La transition :

1. Vérifie les préconditions humaines (checklist interactive).
2. Exécute les invariants et checks automatisés.
3. Si GO, exécute la transition — et gèle les artefacts listés dans freeze.

Exemple concret (extrait de sdlc/schema.js) pour la porte G1 (BE : VISION_EN_COURS → ENGAGE) :

freeze: [
  '.product/.epics/{id}/asis.md',
  '.product/.epics/{id}/tobe.md',
  '.product/.epics/{id}/ehs.md',
  '.product/.epics/{id}/lbc.md',
  '.product/.epics/{id}/okrs.md',
  '.product/.epics/{id}/decision.md',
]

Ces fichiers étaient LIVING avant G1. Après G1 ils sont COLD : l'IA peut encore les lire et les citer, mais toute modification exige de passer par un nouveau processus explicite (re-ouvrir un cycle de vision via la boucle MVP→G1, produire un événement justifiant la remise en LIVING).

Depuis la v3 (ADR-0009), un deuxième cas illustre particulièrement bien la patience LIVING : le prd.md d'une Feature reste LIVING à travers deux statuts (fe.PRD_EN_COURS puis fe.FAB_PLAN_EN_COURS) et n'est figé qu'à G3, en même temps que spec.md et plan-fab.md. Cette durée prolongée de LIVING est délibérée : elle permet au PRD d'évoluer pendant la décomposition en USs, moment où l'équipe découvre des détails qui remettent parfois en cause le cadrage initial.

La boucle BLOCKED — un état intermédiaire

Certains objets se retrouvent bloqués en cours de cycle : dépendance non résolue, décision externe attendue, ressource indisponible. La machine d'états prévoit des statuts BLOCKED → méta-état BLOCKED → heat LIVING-GELÉ (aka living-frozen).

Cet état n'est pas COLD : il signale que le travail est en pause, pas qu'une décision a figé l'artefact. Le retour à IN_PROGRESS ne nécessite pas une porte — seulement la levée du blocage.

Qui peut (dé)geler quoi ?

Action	Autorisation
Créer un artefact LIVING	L'agent IA, l'humain, un script
Modifier un artefact LIVING	Idem
Geler un artefact (LIVING → COLD)	Uniquement node sdlc/sdlc.js move via une porte
Déplacer un artefact (BLOCKED ↔ IN_PROGRESS)	La CLI, via transitions dédiées (pas nécessairement une porte)
Dégeler un artefact (COLD → LIVING)	Processus explicite : archiver l'ancienne version, ouvrir une nouvelle itération avec un nouvel ID ou une reprise conscient. Jamais d'édition silencieuse.

Signes que LIVING/COLD est respecté

• Les commits chore(sdlc): <ID> <FROM>→<TO> [<PORTE>] sont nombreux — chaque gel est tracé.
• git log sur un fichier COLD montre : « créé en LIVING, modifié plusieurs fois, figé à telle date, non modifié depuis ».
• Les sessions IA prennent le temps d'identifier la chaleur de chaque artefact avant d'y toucher.
• Les rouvertures d'artefacts COLD sont rares, et toujours accompagnées d'un événement markdown qui explique pourquoi.

Signes que LIVING/COLD est violé

• Un fichier censé être COLD (ex: ehs.md d'un BE en statut ENGAGE) est modifié sans commit CLI correspondant.
• L'IA propose des « améliorations » à des artefacts gelés sans passer par une porte.
• Le registre sdlc-registry.json et les fichiers dans .product/ dérivent : les objets semblent LIVING dans l'un, COLD dans l'autre.
• Personne ne sait dire, à un moment donné, quel artefact est gelé.

Pourquoi le mot « LIVING »

Le contraire intuitif de COLD aurait été WARM ou HOT. Le choix de LIVING souligne que tant qu'un artefact n'est pas gelé, il est vivant : il respire, il change, il compose avec les autres artefacts vivants. Le gel le rend mort à la modification — mais vivant à la lecture. Un artefact COLD est toujours lu, jamais écrit.

Voir aussi : Herméneutique · Juste assez · Les 4 portes · Invariant sécurité.