project-memorylisted

# project-memory Substrat de mémoire structurée par mission, à 3 couches (Cold / Warm / Hot). Colonne vertébrale d'une mission de conseil : garantit que les décisions humaines (golden data) ne sont jamais écrasées par une régénération IA, mutualise la mémoire entre tous les agents/skills d'une mission, et rend la pensée auditable. Ce skill est **LLM-driven** : tu exécutes chaque opération toi-même via Read / Write / Edit sur des fichiers `.md`. Il n'y a pas de moteur Python. La fiabilité du substrat dépend entièrement de ta discipline à suivre les gestes ci-dessous dans l'ordre. Ce skill est le **moteur** ; il est en général invoqué par `project-init` (à l'init) ou par un agent métier (en cours de mission). Le point d'entrée du cycle de vie d'un projet est `project-init`, pas ce skill. ## Règles dures (jamais d'exception) 1. **Immuabilité Cold.** Ne jamais éditer le **corps** d'une décision au statut `Active`. Le seul Edit in-place autorisé sur un fichier `Décisions/` est le flip de statut dans le frontmatter (Active -> Révisée ou Abrogée, avec mise à jour de `Révisé par`), exécuté exclusivement par `revise_decision` ou `abrogate_decision`. Tout autre Edit d'une décision Active est une corruption du substrat. 2. **Index après chaque écriture.** Après TOUTE écriture dans `Décisions/`, `Synthèses/` ou `Logs/`, régénérer immédiatement l'`_Index.md` du dossier touché, puis le `_memory/_Index.md` racine. C'est une étape à part entière, jamais omise. 3. **Frontmatter conforme