← ContinuumCONTENT HISTORYWHAT CHANGED · RULE-BASED ANALYSIS
Update to Continuum
Snapshot Sep 30, 2026 · 23:14 UTC · version 0.5.1
Collection source: not recorded for this historical snapshot.
First saved snapshot
No earlier snapshot is available to establish a change.
Compare saved observations
Download comparison JSONFull technical diff · 0 changed fields
Full snapshot data
{
"name": "gerer-environnement-azer",
"description": "Use when Azer's working environment, retained operational errors, or active recovery checkpoint must be read or updated.",
"included_files": [],
"skill_md_contents": "---\nname: gerer-environnement-azer\ndescription: Use when Azer's working environment, retained operational errors, or active recovery checkpoint must be read or updated.\n---\n# Gérer l’environnement d’Azer\n\n## Fonction\nGérer les trois objets opérationnels distincts d’Azer dans `Environnement Continuum Azer` : `Cartographie Ordinateur Azer.md`, `Erreurs retenues.md` et `Reprise active Azer.md`. Ils ne remplacent ni Verbatim, ni Continuité, ni Histoire, ni trace d’exécution.\n\n## Déclenchement\n- un changement matériel affecte l’atelier, ses accès, capacités, chemins ou limites ;\n- une erreur retenue peut éviter une répétition ou modifier une méthode ;\n- un chantier long ou stateful exige un checkpoint pour reprendre sans rejouer un effet.\n\n## Procédure\n1. Résoudre les objets par l’Index de la Source Canonique et employer le chemin d’écriture faisant autorité.\n2. Mettre à jour la Cartographie seulement pour l’état courant utile au travail ; remplacer ou retirer une valeur fausse au lieu de créer un historique.\n3. Inscrire une erreur retenue avec identifiant durable, contexte, symptôme, cause établie ou supposée, conséquences, correction, prévention et statut, seulement si son enseignement est réutilisable.\n4. Tenir `Reprise active Azer.md` comme checkpoint courant : statut, horodatage, cap, acquis, contraintes, dépendances, effets non rejouables, limites et prochaine action utile. Remplacer l’état devenu obsolète ; ne pas y recopier la conversation, les logs ou le raisonnement privé.\n5. Pour une écriture canonique, appliquer `proteger-concurrence` et `gerer-transactions` seulement lorsque le risque ou l’état partagé le justifie. Un succès explicite suffit par défaut ; ne pas faire une seconde écriture de miroir par cérémonie.\n\n## Interdits\n- ne jamais transformer ces objets en journal exhaustif ou en second Verbatim ;\n- ne jamais conserver un checkpoint `EN COURS` devenu faux ;\n- ne jamais déduire un état volatile sans le rafraîchir lorsqu’un événement connu l’a rendu douteux.\n\n## Preuve\nChaque objet concerné porte l’état courant suffisant à sa fonction, sur le chemin canonique autoritaire ; une reprise peut partir du checkpoint sans rejouer aveuglément un effet matériel.\n\n## Arrêt\nNe mettre à jour aucun objet lorsqu’aucun changement matériel ne le requiert.\n"
}SHA-256: 0605c54e80a3d28908980959d2774c40f1529559ab3166ac524cbc68416faf29